@ersmith said:
Here's a test program that shows the setup_pins() function is working fine -- it responds correctly to any combination of settings I enter on the terminal. So I don't think your problem lies there, it must be somewhere else in your program.
You were obviously right. I didn't realize that I called the status code from different cogs. And then of course the ORing together of the pin-status takes place, and one cog setting it high can't be overridden by the other one. Oh well.
As we discussed the variable relocation, etc, the problem with port selecting went down, so I repost this.
In 5.9.2 and 5.9.3 (Windows) I can not select a serial port. Only automatic selection works. This cause the lag while programming as (it seems that) it tries com1 first.
Trying out the new version of FlexSpin for the P1 by running my robot leg controller program. It would not compile with the error:
"Version 5.9.3 Compiled on: Sep 27 2021
Hexapod Leg Master - v7.pasm
C:/Users/bobma/OneDrive/Documents/Propeller Tool/Library/My Designs/Hexapod/Hexapod Leg Master - v7.pasm:9884: error: fit 496 failed: pc is 608
child process exited abnormally"
the line it is pointing to is:
LMM_FCACHE_END
fit 496
Couldn't find any information on this searching the forum and checking the Flexspin docs. This program does compile using the PropTool 2.5.3.
A separate question, is it possible to open PST similar to the way the it is used on PropTool?
@DiverBob said:
Trying out the new version of FlexSpin for the P1 by running my robot leg controller program. It would not compile with the error:
"Version 5.9.3 Compiled on: Sep 27 2021
Hexapod Leg Master - v7.pasm
C:/Users/bobma/OneDrive/Documents/Propeller Tool/Library/My Designs/Hexapod/Hexapod Leg Master - v7.pasm:9884: error: fit 496 failed: pc is 608
child process exited abnormally"
the line it is pointing to is:
LMM_FCACHE_END
fit 496
Couldn't find any information on this searching the forum and checking the Flexspin docs. This program does compile using the PropTool 2.5.3.
A separate question, is it possible to open PST similar to the way the it is used on PropTool?
That just tends to happen with large programs.
BTW, if you want small code, enable bytecode mode. Same bytecode as PropTool generates, but Flexspin is much better at it, if I dare say so.
Now I'm stumped, after getting the FlexProp error message mentioned on post #694, I decided to go back to the Prop Tool to continue work there instead. Now the Prop Tool won't start up without an error (Stack Overflow and List index out of bounds) during the app startup. I was successfully using Prop Tool immediately before I shut it down to try out FlexProp. I removed the program at least 4 times now and get the same error message each time I re-install. The only thing that change is that I ran FlexProp before this. I have re-started and fully rebooted the computer (Win10) several times with with no change. Not sure what running FlexProp could possibly do to that would affect PropTool.
I did go back to FlexProp but continue to get the same error there also. The program I'm trying to compile isn't even close to pushing the limits of the P1, the whole reason for using FlexProp is for its ability to create PASM code, I prefer to use Prop Tool due to the interface if the only way to compile is to enable bytecode mode.
I'm open to suggestions but I'm ready to re-install my latest Win10 backup if I can't proceed.
The good news is that after a lot of work I was finally able to get the Prop Tool to work again. It required hacking the Registry after removing the application to manually delete all startup references used by the Prop tool. Reinstalled and it is working correctly with the exception of the View Info dialog which isn't displaying anything on the right side of the dialog but appears to be trying to show 3 characters of the info that is normally displayed on the right side in the upper left quadrant of the dialog. Just wanted to pass on this info since I posted the issue earlier.
@pik33 said:
As we discussed the variable relocation, etc, the problem with port selecting went down, so I repost this.
In 5.9.2 and 5.9.3 (Windows) I can not select a serial port. Only automatic selection works. This cause the lag while programming as (it seems that) it tries com1 first.
FlexProp hasn't changed, but Windows apparently has... some recent Windows update appears to have broken the way FlexProp scans for serial ports, so I don't think any FlexProp version will work correctly now. I'll try to find a work-around.
@pik33 said:
As we discussed the variable relocation, etc, the problem with port selecting went down, so I repost this.
In 5.9.2 and 5.9.3 (Windows) I can not select a serial port. Only automatic selection works. This cause the lag while programming as (it seems that) it tries com1 first.
FlexProp hasn't changed, but Windows apparently has... some recent Windows update appears to have broken the way FlexProp scans for serial ports, so I don't think any FlexProp version will work correctly now. I'll try to find a work-around.
5.5.1 and earlier are OK on the same 2 Windows 10 computers I use, while 5.9.x are not. While 5.9.x cannot detect and cannot allow me to select the port, it still can program the P2 after a several seconds delay.
Maybe experimenting with several version of Flexprop at once ( SimpleSound...) made a problem? If yes, what can I delete to get a "factory reset"? I noticed 5.5.x versions display the new blue feather icon now instead of the Alladin's lamp as before.
@pik33 said:
As we discussed the variable relocation, etc, the problem with port selecting went down, so I repost this.
In 5.9.2 and 5.9.3 (Windows) I can not select a serial port. Only automatic selection works. This cause the lag while programming as (it seems that) it tries com1 first.
FlexProp hasn't changed, but Windows apparently has... some recent Windows update appears to have broken the way FlexProp scans for serial ports, so I don't think any FlexProp version will work correctly now. I'll try to find a work-around.
5.5.1 and earlier are OK on the same 2 Windows 10 computers I use, while 5.9.x are not. While 5.9.x cannot detect and cannot allow me to select the port, it still can program the P2 after a several seconds delay.
Maybe experimenting with several version of Flexprop at once ( SimpleSound...) made a problem? If yes, what can I delete to get a "factory reset"? I noticed 5.5.x versions display the new blue feather icon now instead of the Alladin's lamp as before.
We might want check that the changes Eric merged from my serial port stuff didn't potentially cause this too...as there was a timeout related change added to the checkp2_and_init() function. That is common code and so would have affected the Windows platforms too.
@ersmith said:
FlexProp hasn't changed, but Windows apparently has... some recent Windows update appears to have broken the way FlexProp scans for serial ports, so I don't think any FlexProp version will work correctly now. I'll try to find a work-around.
5.5.1 and earlier are OK on the same 2 Windows 10 computers I use, while 5.9.x are not. While 5.9.x cannot detect and cannot allow me to select the port, it still can program the P2 after a several seconds delay.
Sorry about that... I was confused by a Windows update problem I had.
This was a very difficult bug to track down, because the serial scanning code (in flexprop/src/checkserial.tcl) literally did not change between flexprop versions, and has been the same for a very long time. It turns out that the problem is a packaging issue in flexprop 5.9.x; a .dll that Tcl needs to read the registry did not get included. I hope to have a new version uploaded this weekend.
@ersmith I have a bit of mischief to report with FlexBASIC's INT() function. It doesn't seem to be truncating floats correctly. The following code shows the problem:
dim n as single
for n = 1.2 to 6.0 step 0.1
print n, n * 10.0, int(n * 10.0)
next n
Notice in the third column how "23" repeats:
2.1000 21.000 21 <--- ok
2.2000 22.000 22 <--- ok
2.3000 23.000 23 <--- ok
2.4000 24.000 23 <--- whoops
2.5000 25.000 24 <--- off by one (as will each successive number from this point on)
That little critter made a difference of about 60 nautical miles in my nav program. lol.
@JRoark said:
@ersmith I have a bit of mischief to report with FlexBASIC's INT() function. It doesn't seem to be truncating floats correctly. The following code shows the problem:
dim n as single
for n = 1.2 to 6.0 step 0.1
print n, n * 10.0, int(n * 10.0)
next n
Notice in the third column how "23" repeats:
I think your problem is that you're stepping by 0.1 (which has no exact representation in floating point) and hence accumulating a little bit of error each time. Moreover, the INT(n) function truncates the input value; so at some point n gets set to 2.399999 (which gets printed as 2.4000) and then int(n*10.0) will be 23. There are two work-arounds: (1) count by integers rather than 0.1 (integer arithmetic is exact, at least for small floating point numbers), and (2) use ROUND(x) instead of INT(x).
(Floating point is tricky and filled with gotcha's like this.)
I've put the Windows version of FlexProp 5.9.4 up on my Patreon page and on github. The compiler changes are:
- Added some error checking for parameters of CPU/coginit/cognew
- Added --charset=C for changing runtime character set
- Fixed Spin2 round(), trunc(), and float() operators for variable expressions
- Fixed multiply by -1 when local variables are on the stack
- Fixed expansion of macros which contain other macros
- Fixed ABORT in Spin functions with no return statements
- Fixed C _clkfreq constant in multiple enums problem
- Implemented subset of try/catch for C++
- Improved Catalina compatibility for spin2cpp
- Various improvements to the nu code backend
There are also a few GUI fixes, such as making the serial port detection work properly again on Windows 10.
Only Windows binaries are included in this release. There is a Tcl/Tk conflict with MacOS 12.0.1 which prevents FlexProp from working on that platform, and I'm still investigating ways to work around that.
@JRoark said:
@ersmith I betcha that bug would go away with double-precision math.
No, it'll just push the problem a bit later. Try this program on Linux, for example (it'll probably compile on Windows too). With FLOAT defined as float the problem happens at 23, with it defined as double it happens around 47:
#include <stdio.h>
#if 0
#define FLOAT float
#define F(x) (x ## f)
#else
#define FLOAT double
#define F(x) (x)
#endif
int main()
{
FLOAT n;
for (n = F(1.2); n <= F(6.0); n += F(0.1)) {
printf("%.15g, %.15g, %d\n", n, n * F(10.0), (int)(n*F(10.0)));
}
return 0;
}
(And this confirms that it isn't a FlexSpin bug, it's an inherent issue with floating point...)
@ersmith (You know I’m just messing with you, right)? The error was indeed the nut behind this keyboard. I redid the loop using integers and its now flawless.
One of the things I’m fighting is years of bad habits due to 64-bit BASICs (and 80-bit in the case of Microsoft!), so considerations of this sort just werent on my radar. Its now a matter of “digging in” and getting used to being much closer to the machine and learning about the underpinnings of the compiler.
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
The good old Atari 8-bit has floating point library written using BCD - 0.1 has a proper representation and no such kind of errors.
@pik33 said:
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
>
I'm thinking there might be some confusion between .spin and .spin2
Has there been any headway on defining this? As in letting the compiler know 100% what dialect it is going to see. And if not, can we talk about it?
It's been forever and my memory is fuzzy, basic stamp did add something at the very top of the file like {pbasic1} and the editor enforced it.
I suspect it starts to get confusing to have a file ending in .spin having code written in .spin, and then get renamed .spin2; while in the same program including files with extension .spin having .spin2 code.
It gets really confusing when expert-mode spin programs were written with awareness of the final bytecode and used tricks to shave off a few bytes.
There's also assumptions about operator precedence. Again the more expert performers tend to drop the safety parentheses.
Also if ~ comes before a literal, it can only be spin1 code??? Again there's good reasons for the changes, but it may help to say at the start what accent of spin is being used.
@pik33 said:
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
>
I'm thinking there might be some confusion between .spin and .spin2
Has there been any headway on defining this? As in letting the compiler know 100% what dialect it is going to see. And if not, can we talk about it?
It's been forever and my memory is fuzzy, basic stamp did add something at the very top of the file like {pbasic1} and the editor enforced it.
I suspect it starts to get confusing to have a file ending in .spin having code written in .spin, and then get renamed .spin2; while in the same program including files with extension .spin having .spin2 code.
With PropTool/PNut, the set of programs that can be confused as either Spin1 or Spin2 is very small. Flexspin is more lenient (partially because Spin1/Spin2 are handled mostly by the same code)...
Then again, why would you ever change the file extension between .spin and .spin2?
It gets really confusing when expert-mode spin programs were written with awareness of the final bytecode and used tricks to shave off a few bytes.
Yeah that tends to happen, lol. Well, flexspin in bytecode mode can do a lot of the weird bytecode-isms without having to make sphaghetti in your code. And a few you couldn't do at all before. (totally not bragging >,>)
@whicker said:
Has there been any headway on defining this? As in letting the compiler know 100% what dialect it is going to see. And if not, can we talk about it?
In FlexProp the .spin extension always means Spin 1, and the .spin2 extension always means Spin2. I think PropTool is the same.
The main difference between FlexProp and PropTool is that FlexProp allows Spin 1 files to be built for P2, and Spin 2 files for P1 -- that is, the language and processor are independent. PropTool, by contrast, assumes Spin 1 is always P1, and Spin 2 is always P2.
I didn't manage to compile anything for P2 in this mode (I hadn't tried anything simple, they were my "normal" programs) - it generates segmentation faults while compiling. Considering this is early beta, it may be normal at this stage, so I simply try this with every new Flexprop version, still with the same result. Waiting for 6.0.0.
I didn't manage to compile anything for P2 in this mode (I hadn't tried anything simple, they were my "normal" programs) - it generates segmentation faults while compiling. Considering this is early beta, it may be normal at this stage, so I simply try this with every new Flexprop version, still with the same result. Waiting for 6.0.0.
That's because it's only available for P1. Probably shouldn't segfault though. Try nucode mode for P2, that is at least supposed to work.
@pik33 said:
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
I think I've finally figured out what's going on with SimpleSound. The ordering of objects/variables was a red herring -- even old versions of FlexProp had a bug that caused bad code to be generated, but it happened not to hurt anything with the original ordering (where objects were interleaved with variables). The root cause was that it wasn't scanning the arguments of coginit() for uses of member variables, and so was incorrectly marking reSound.init() as being a "static" function (one that doesn't use member variables). This caused data to be written to the wrong place in memory, since reSound.init() does, in fact, use some member variables.
If you replace the flexspin.exe in flexprop/bin with the one in this .zip file, it should work (fingers crossed).
@pik33 said:
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
I think I've finally figured out what's going on with SimpleSound. The ordering of objects/variables was a red herring -- even old versions of FlexProp had a bug that caused bad code to be generated, but it happened not to hurt anything with the original ordering (where objects were interleaved with variables). The root cause was that it wasn't scanning the arguments of coginit() for uses of member variables, and so was incorrectly marking reSound.init() as being a "static" function (one that doesn't use member variables). This caused data to be written to the wrong place in memory, since reSound.init() does, in fact, use some member variables.
Owie ouch....
Could we write such metadata as comments into the listing/asm output for debugging purposes?
@pik33 said:
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
I think I've finally figured out what's going on with SimpleSound. The ordering of objects/variables was a red herring -- even old versions of FlexProp had a bug that caused bad code to be generated, but it happened not to hurt anything with the original ordering (where objects were interleaved with variables). The root cause was that it wasn't scanning the arguments of coginit() for uses of member variables, and so was incorrectly marking reSound.init() as being a "static" function (one that doesn't use member variables). This caused data to be written to the wrong place in memory, since reSound.init() does, in fact, use some member variables.
If you replace the flexspin.exe in flexprop/bin with the one in this .zip file, it should work (fingers crossed).
I'm probably doing something wrong, but the infinite loop blinks at ~200 ms, like it should, when placed before "fopen".
But, it's more like 2000 ms when placed after fopen.
Any idea why that is?
int main()//RJA
{
//Note: Clock frequency set with enum in Platform.h
//check clock freq
int cf = _clockfreq();
printf("clock freq= %d\n", cf);
mount("/sd", _vfs_open_sdcard());
FILE* f;
f= fopen("/sd/test.dat", "w");
for (;;)
{
_pinnot(57);
_waitms(100);
}
Comments
You were obviously right. I didn't realize that I called the status code from different cogs. And then of course the ORing together of the pin-status takes place, and one cog setting it high can't be overridden by the other one. Oh well.
As we discussed the variable relocation, etc, the problem with port selecting went down, so I repost this.
In 5.9.2 and 5.9.3 (Windows) I can not select a serial port. Only automatic selection works. This cause the lag while programming as (it seems that) it tries com1 first.
Trying out the new version of FlexSpin for the P1 by running my robot leg controller program. It would not compile with the error:
"Version 5.9.3 Compiled on: Sep 27 2021
Hexapod Leg Master - v7.pasm
C:/Users/bobma/OneDrive/Documents/Propeller Tool/Library/My Designs/Hexapod/Hexapod Leg Master - v7.pasm:9884: error: fit 496 failed: pc is 608
child process exited abnormally"
the line it is pointing to is:
LMM_FCACHE_END
fit 496
Couldn't find any information on this searching the forum and checking the Flexspin docs. This program does compile using the PropTool 2.5.3.
A separate question, is it possible to open PST similar to the way the it is used on PropTool?
That just tends to happen with large programs.
BTW, if you want small code, enable bytecode mode. Same bytecode as PropTool generates, but Flexspin is much better at it, if I dare say so.
Now I'm stumped, after getting the FlexProp error message mentioned on post #694, I decided to go back to the Prop Tool to continue work there instead. Now the Prop Tool won't start up without an error (Stack Overflow and List index out of bounds) during the app startup. I was successfully using Prop Tool immediately before I shut it down to try out FlexProp. I removed the program at least 4 times now and get the same error message each time I re-install. The only thing that change is that I ran FlexProp before this. I have re-started and fully rebooted the computer (Win10) several times with with no change. Not sure what running FlexProp could possibly do to that would affect PropTool.
I did go back to FlexProp but continue to get the same error there also. The program I'm trying to compile isn't even close to pushing the limits of the P1, the whole reason for using FlexProp is for its ability to create PASM code, I prefer to use Prop Tool due to the interface if the only way to compile is to enable bytecode mode.
I'm open to suggestions but I'm ready to re-install my latest Win10 backup if I can't proceed.
The good news is that after a lot of work I was finally able to get the Prop Tool to work again. It required hacking the Registry after removing the application to manually delete all startup references used by the Prop tool. Reinstalled and it is working correctly with the exception of the View Info dialog which isn't displaying anything on the right side of the dialog but appears to be trying to show 3 characters of the info that is normally displayed on the right side in the upper left quadrant of the dialog. Just wanted to pass on this info since I posted the issue earlier.
I was about to recommend deleting the Prop Tool registry settings.
Seen that before...
Don't think it has anything at all to do with FlexProp though.
FlexProp hasn't changed, but Windows apparently has... some recent Windows update appears to have broken the way FlexProp scans for serial ports, so I don't think any FlexProp version will work correctly now. I'll try to find a work-around.
5.5.1 and earlier are OK on the same 2 Windows 10 computers I use, while 5.9.x are not. While 5.9.x cannot detect and cannot allow me to select the port, it still can program the P2 after a several seconds delay.
Maybe experimenting with several version of Flexprop at once ( SimpleSound...) made a problem? If yes, what can I delete to get a "factory reset"? I noticed 5.5.x versions display the new blue feather icon now instead of the Alladin's lamp as before.
We might want check that the changes Eric merged from my serial port stuff didn't potentially cause this too...as there was a timeout related change added to the checkp2_and_init() function. That is common code and so would have affected the Windows platforms too.
Sorry about that... I was confused by a Windows update problem I had.
This was a very difficult bug to track down, because the serial scanning code (in flexprop/src/checkserial.tcl) literally did not change between flexprop versions, and has been the same for a very long time. It turns out that the problem is a packaging issue in flexprop 5.9.x; a .dll that Tcl needs to read the registry did not get included. I hope to have a new version uploaded this weekend.
Thanks for the bug report,
@ersmith I have a bit of mischief to report with FlexBASIC's INT() function. It doesn't seem to be truncating floats correctly. The following code shows the problem:
Notice in the third column how "23" repeats:
That little critter made a difference of about 60 nautical miles in my nav program. lol.
I think your problem is that you're stepping by 0.1 (which has no exact representation in floating point) and hence accumulating a little bit of error each time. Moreover, the INT(n) function truncates the input value; so at some point n gets set to 2.399999 (which gets printed as 2.4000) and then int(n*10.0) will be 23. There are two work-arounds: (1) count by integers rather than 0.1 (integer arithmetic is exact, at least for small floating point numbers), and (2) use ROUND(x) instead of INT(x).
(Floating point is tricky and filled with gotcha's like this.)
I've put the Windows version of FlexProp 5.9.4 up on my Patreon page and on github. The compiler changes are:
There are also a few GUI fixes, such as making the serial port detection work properly again on Windows 10.
Only Windows binaries are included in this release. There is a Tcl/Tk conflict with MacOS 12.0.1 which prevents FlexProp from working on that platform, and I'm still investigating ways to work around that.
@ersmith I betcha that bug would go away with double-precision math. (See what I did there? Was that sly or what? Lol!)
I’m gonna play with Round() a bit. I missed that somehow. Thanks for the response!
No, it'll just push the problem a bit later. Try this program on Linux, for example (it'll probably compile on Windows too). With FLOAT defined as float the problem happens at 23, with it defined as double it happens around 47:
(And this confirms that it isn't a FlexSpin bug, it's an inherent issue with floating point...)
Maybe n*10.0 +.5 fixes that?
@ersmith (You know I’m just messing with you, right)? The error was indeed the nut behind this keyboard. I redid the loop using integers and its now flawless.
One of the things I’m fighting is years of bad habits due to 64-bit BASICs (and 80-bit in the case of Microsoft!), so considerations of this sort just werent on my radar. Its now a matter of “digging in” and getting used to being much closer to the machine and learning about the underpinnings of the compiler.
Thanks for your help!
Serial ports work now (and SimpleSound doesn't - I tried to debug this, still with no result, but this thing cannot even compute the sample frequency properly or outputs garbage instead of clkfreq - very strange thing.)
The good old Atari 8-bit has floating point library written using BCD - 0.1 has a proper representation and no such kind of errors.
>
I'm thinking there might be some confusion between .spin and .spin2
Has there been any headway on defining this? As in letting the compiler know 100% what dialect it is going to see. And if not, can we talk about it?
It's been forever and my memory is fuzzy, basic stamp did add something at the very top of the file like {pbasic1} and the editor enforced it.
I suspect it starts to get confusing to have a file ending in .spin having code written in .spin, and then get renamed .spin2; while in the same program including files with extension .spin having .spin2 code.
It gets really confusing when expert-mode spin programs were written with awareness of the final bytecode and used tricks to shave off a few bytes.
There's also assumptions about operator precedence. Again the more expert performers tend to drop the safety parentheses.
Also if ~ comes before a literal, it can only be spin1 code??? Again there's good reasons for the changes, but it may help to say at the start what accent of spin is being used.
With PropTool/PNut, the set of programs that can be confused as either Spin1 or Spin2 is very small. Flexspin is more lenient (partially because Spin1/Spin2 are handled mostly by the same code)...
Then again, why would you ever change the file extension between .spin and .spin2?
Yeah that tends to happen, lol. Well, flexspin in bytecode mode can do a lot of the weird bytecode-isms without having to make sphaghetti in your code. And a few you couldn't do at all before. (totally not bragging >,>)
In FlexProp the .spin extension always means Spin 1, and the .spin2 extension always means Spin2. I think PropTool is the same.
The main difference between FlexProp and PropTool is that FlexProp allows Spin 1 files to be built for P2, and Spin 2 files for P1 -- that is, the language and processor are independent. PropTool, by contrast, assumes Spin 1 is always P1, and Spin 2 is always P2.
I didn't manage to compile anything for P2 in this mode (I hadn't tried anything simple, they were my "normal" programs) - it generates segmentation faults while compiling. Considering this is early beta, it may be normal at this stage, so I simply try this with every new Flexprop version, still with the same result. Waiting for 6.0.0.
That's because it's only available for P1. Probably shouldn't segfault though. Try nucode mode for P2, that is at least supposed to work.
"Spin2 files for P1" That's a neat trick! I'm sure there's some limitations, but good to know.
I like Spin2 a lot more than Spin1...
I think I've finally figured out what's going on with SimpleSound. The ordering of objects/variables was a red herring -- even old versions of FlexProp had a bug that caused bad code to be generated, but it happened not to hurt anything with the original ordering (where objects were interleaved with variables). The root cause was that it wasn't scanning the arguments of coginit() for uses of member variables, and so was incorrectly marking reSound.init() as being a "static" function (one that doesn't use member variables). This caused data to be written to the wrong place in memory, since reSound.init() does, in fact, use some member variables.
If you replace the flexspin.exe in flexprop/bin with the one in this .zip file, it should work (fingers crossed).
It works! Tested 2 C programs that use simple sound and they both work with that file.
Glad you were able to sort that out.
Owie ouch....
Could we write such metadata as comments into the listing/asm output for debugging purposes?
* It works!
I'm probably doing something wrong, but the infinite loop blinks at ~200 ms, like it should, when placed before "fopen".
But, it's more like 2000 ms when placed after fopen.
Any idea why that is?