Minor release to fix some bugs, including the exported binary checksum (P1)
This was what I was waiting for but it isn't working correctly for me.
I have no idea what this actually did but while the Binary now seems to upload correctly via "Propeller Tool v2.9.3" or "propeller-load.exe" into RAM or eeprom but the code fails to run on my P1 board.
Worse than that, I thought for a while that it had distroyed something as afterwards those boards could not be programmed directly from "Spin Tools IDE v0.34.1" from the spin source either?
I repeatedly tried to re-load the code, using "propeller-load.exe" and "Spin Tools IDE v0.34.1" and each time it gave no errors (except for one that did timeout on an eeprom error but not the rest) but then the boards wouldn't boot. I tried 3 boards before getting really scared I was blowing them up somehow, 3 different generations of my board all acted the same way.
Even a PC reboot didn't allow "Spin Tools IDE v0.34.1" to program these boards (directly from the spin source), either to RAM or EEPROM though all seemed to load ok but again no boot.
I finally tired reprogramming them with my latest code via "Propeller Tool v2.9.3" from an eeprom file I had made yesterday, and magically the boards would now boot ok.
The source code for all these attempts was the same, either raw SPIN or Binary file from "Spin Tools IDE v0.34.1" or an eeprom file made with the same code & compiled via "Propeller Tool v2.9.3".
Also started to implement the selection tab/backtab function (select a group of lines and tab and shift-tab indents or back-indents them all at once). It works only with the normal line-mode selection, block selection has few quirks that needs more work.
This works well on the few lines I have tried it on, thanks, I really missed this function, I had to spend ages adding or reducing indents everytime I needed to add conditions into existing code.
@macca said:
Minor release to fix some bugs, including the exported binary checksum (P1)
This was what I was waiting for but it isn't working correctly for me.
I have no idea what this actually did but while the Binary now seems to upload correctly via "Propeller Tool v2.9.3" or "propeller-load.exe" into RAM or eeprom but the code fails to run on my P1 board.
Worse than that, I thought for a while that it had distroyed something as afterwards those boards could not be programmed directly from "Spin Tools IDE v0.34.1" from the spin source either?
I repeatedly tried to re-load the code, using "propeller-load.exe" and "Spin Tools IDE v0.34.1" and each time it gave no errors (except for one that did timeout on an eeprom error but not the rest) but then the boards wouldn't boot. I tried 3 boards before getting really scared I was blowing them up somehow, 3 different generations of my board all acted the same way.
Even a PC reboot didn't allow "Spin Tools IDE v0.34.1" to program these boards (directly from the spin source), either to RAM or EEPROM though all seemed to load ok but again no boot.
I finally tired reprogramming them with my latest code via "Propeller Tool v2.9.3" from an eeprom file I had made yesterday, and magically the boards would now boot ok.
The source code for all these attempts was the same, either raw SPIN or Binary file from "Spin Tools IDE v0.34.1" or an eeprom file made with the same code & compiled via "Propeller Tool v2.9.3".
I don't know why the uploaded program doesn't work, maybe I have changed something in the compiler, however without a binary comparison I can't tell what. Was it working with the previous 0.34.0 release ?
Can you send me the complete source (even privately if you don't want to make it public) ?
About the programming issue, that's really weird, there is absolutely nothing that an uploaded program can do to prevent the programming since it is a hardware handshake that takes places before the program is even loaded into ram. There may be timing issues where the serial loader doesn't properly recognize the programming data after a reset, but this would happen independently from the program.
@macca said:
About the programming issue, that's really weird, there is absolutely nothing that an uploaded program can do to prevent the programming since it is a hardware handshake that takes places before the program is even loaded into ram. There may be timing issues where the serial loader doesn't properly recognize the programming data after a reset, but this would happen independently from the program.
Ok I did some more testing with different programs and couldn't get release 0.34.1 to write to anything P1 <didn't test P2>, this should have occured to me before, but I was concentrating on the Binary file and forgetting the full picture.
I just renamed "spin-tools-0.34.1.jar" to "spin-tools-0.34.1.jar(buggy)" and put spin-tools-0.34.0.jar back into my spin tools folder with no other changes and Spin Tools IDE is now working again.
Is that ok or should I copy the entire contents of "spin-tools-windows-0.34.0.zip" back into my spin tools folder?
@lab_ges said:
Ok I did some more testing with different programs and couldn't get release 0.34.1 to write to anything P1 <didn't test P2>, this should have occured to me before, but I was concentrating on the Binary file and forgetting the full picture.
That's really weird. However I don't understand if the programs are uploaded correctly but doesn't work, or are not uploaded at all, which should give an error at some time.
Have you tried with something simple like blinking a led ?
I just renamed "spin-tools-0.34.1.jar" to "spin-tools-0.34.1.jar(buggy)" and put spin-tools-0.34.0.jar back into my spin tools folder with no other changes and Spin Tools IDE is now working again.
Is that ok or should I copy the entire contents of "spin-tools-windows-0.34.0.zip" back into my spin tools folder?
@lab_ges said:
Ok I did some more testing with different programs and couldn't get release 0.34.1 to write to anything P1 <didn't test P2>, this should have occured to me before, but I was concentrating on the Binary file and forgetting the full picture.
That's really weird. However I don't understand if the programs are uploaded correctly but doesn't work, or are not uploaded at all, which should give an error at some time.
Have you tried with something simple like blinking a led ?
Ok, I wrote a simple Blink.spin program and installed it using <0.34.0> and it worked fine from RAM; installed it to the eeprom also working.
Then I ran my eeprom viewer in RAM and captured a text view of the eeprom contents. {I can send you this is you like, it is very small?}
Switched to <0.34.1> and installed it to RAM where it worked fine; installed it to the eeprom also working, so it does upload.
Then I tried to run my eeprom viewer in RAM but it wouldn't run, I guess it loaded ok it just wont run.
Switched back to <0.34.0> and installed my eeprom viewer in RAM and captured a text view of the eeprom contents, a few differences but still works.
So that means <0.34.1> can write to RAM and EEPROM but more complex programs just don't seem to run.
@lab_ges said:
Ok I did some more testing with different programs and couldn't get release 0.34.1 to write to anything P1 <didn't test P2>, this should have occured to me before, but I was concentrating on the Binary file and forgetting the full picture.
That's really weird. However I don't understand if the programs are uploaded correctly but doesn't work, or are not uploaded at all, which should give an error at some time.
Have you tried with something simple like blinking a led ?
Ok, I wrote a simple Blink.spin program and installed it using <0.34.0> and it worked fine from RAM; installed it to the eeprom also working.
Then I ran my eeprom viewer in RAM and captured a text view of the eeprom contents. {I can send you this is you like, it is very small?}
Switched to <0.34.1> and installed it to RAM where it worked fine; installed it to the eeprom also working, so it does upload.
Then I tried to run my eeprom viewer in RAM but it wouldn't run, I guess it loaded ok it just wont run.
Switched back to <0.34.0> and installed my eeprom viewer in RAM and captured a text view of the eeprom contents, a few differences but still works.
So that means <0.34.1> can write to RAM and EEPROM but more complex programs just don't seem to run.
Ok, so the basics are working.
I guess something got broken in the 0.34.1 release, however without a binary comparison I can't tell what, all tests I can do are passing (all spin examples and libraries shipped with the IDE and some more downloaded from OBEX).
If you can send me the complete source code of one of the programs not working I can compare and fix the issue.
@macca said:
If you can send me the complete source code of one of the programs not working I can compare and fix the issue.
Done, I have emailed it to you at your maccasoft.com email address.
I had renamed the master program for simplicity but think I sent you the wrong zip file, so you will have to origional file name but am sure you can work it out.
@macca said:
If you can send me the complete source code of one of the programs not working I can compare and fix the issue.
Done, I have emailed it to you at your maccasoft.com email address.
I had renamed the master program for simplicity but think I sent you the wrong zip file, so you will have to origional file name but am sure you can work it out.
I found the source of the problem: I have added the checksum calculation to a function that is called recursively with data that doesn't contain a checksum, corrupting the binary.
Still wondering why the programs I have tested are working correctly.
The binary generated for your source are exactly identical to the binary generated by openspin so, hopefully, there aren't other issues with the compiler.
@macca said:
I found the source of the problem: I have added the checksum calculation to a function that is called recursively with data that doesn't contain a checksum, corrupting the binary.
Still wondering why the programs I have tested are working correctly.
The binary generated for your source are exactly identical to the binary generated by openspin so, hopefully, there aren't other issues with the compiler.
I'll publish a bugfix release tomorrow.
Thank you!
Thanks macca, great work as usual, sorry to be a bother.
Perhaps your compilier doesn't like my programming style
It is probably right, I am self taught and I sometime do things in odd ways!
If it wasn't for help from this forum I would really struggle to do some things, so thanks everyone.
The P1 checksum now should work correctly.
Hope this doesn't break something else.
Opps, I was writing my reply above at the same time as you were uploading your new version.
I Can confirm I have tested <0.34.2> and every thing I tried with <0.34.1> that failed, is now working.
Tests with Spin tools IDE <0.34.2>
Installed <0.34.2> & Uploaded my boards code directly from Spin tools IDE "upload to flash" button. WORKED
Then used Spin tools IDE to create a <.binary> version, which I uploaded in 2 different ways.
Uploaded using:-
Command line via propeller-load.exe WORKED
Propeller tool v2.9.3 WORKED
So all is looking good, granted only after 5 minutes testing much better than the prior version.
Thanks Macca
As an extra note to the above, I have a C# program that can be used to upgrade my boards, but it expects a < .eeprom> file.
So, I wanted to test if it was possible to use the output of Spin Tools IDE <.binary> file to update the board by changing the extension to < .eeprom>
So by double clicking on my newly renamed < .eeprom> file, it opened in Propeller tool v2.9.3 and uploaded to my board sucessfully via the Prop tool, so far so good.
I then tried the renamed file on my C# program but it gives an error part of the way through, probably correspending to the size difference from a fully populated
< .eeprom> file at 32K and a partly populated <.binary> file at 26K.
My guess is the binary file compresses or leaves out the Stack area or something simular and my C# program is expecting a fully populated 32K file.
As a workarround, double clicking on the < .binary> file, opened it in Propeller tool v2.9.3 and I could then save it from there as an < .eeprom> file of 32K is size and that works with my C# program with no problems.
@macca: In a comment to Chip vis-à-vis PNut, you said:
I'm a bit behind with the structure implementation and for now I'm more interested in implementing the new methods since they have renumbered the existing bytecodes.
Would you also consider enabling the use of external compilers so that we can use Propeller Tool directly with PNut and FlexProp? I don't use the graphical debug windows in PNut often, but when I need them, I do. I know it's selfish as a Windows user. Forgive me for that.
@JonnyMac said:
@macca: In a comment to Chip vis-à-vis PNut, you said:
I'm a bit behind with the structure implementation and for now I'm more interested in implementing the new methods since they have renumbered the existing bytecodes.
Would you also consider enabling the use of external compilers so that we can use Propeller Tool directly with PNut and FlexProp? I don't use the graphical debug windows in PNut often, but when I need them, I do. I know it's selfish as a Windows user. Forgive me for that.
I was thinking to add an option to invoke a generic external tool, more or less like to use a command line prompt: set a command to run from the current (or pinned) source directory, passing the source file path itself.
May be used to start flexspin, PNut in debug mode or anything else.
This won't replace the internal compiler, just add something to invoke manually.
This is mainly a bugfix release in order to allow the Atari 2600 (spin version) to compile.
While still waiting for the update PNut source to be published, this release includes some preliminary work for the structure definitions, the CON and VAR sections syntax should work, it also has some "raw" implementations, meaning that structures can actually be used to some extents. It doesn't generate the PNut bytecode, it just generates the memory/variable opcodes needed to reach the structure elements (I guess that the PNut implementation is a bit more efficent). Arrays doesn't work yet.
Also added an experimental skip pattern generator that makes use of the block selection feature:
Write the pattern in a more or less standard syntax with letters for instructions to run and vertical pipes for instructions that are to be skipped, select the vertical block and press SHIFT+ALT+P (or use the Edit -> Make skip pattern menu) to show the pattern. The generated pattern is also copied to the clipboard and can be pasted where it is used.
Other changes:
Updated SWT library to latest Eclipse release 2024-03.
Added -D define option to command line compiler
Fixed some bugs in the preprocessor #if/#else conditions checks
Fixed tab character conversion when loading files or pasting from clipboard
Also added an experimental skip pattern generator that makes use of the block selection feature:
Write the pattern in a more or less standard syntax with letters for instructions to run and vertical pipes for instructions that are to be skipped, select the vertical block and press SHIFT+ALT+P (or use the Edit -> Make skip pattern menu) to show the pattern. The generated pattern is also copied to the clipboard and can be pasted where it is used.
I think I'm the only person who uses this program but it's so quick and easy, once you understand the simple syntax. For example, my 8086 emulator has more than 200 skip patterns and it takes about one second to automatically generate them all.
As every, thank you Marco for your work on this. I am hoping that -- for Windows users, anyway -- we'll be able to use PNut as a command-line tool and have access to all of the P2 DEBUG features.
I would like to implement something like that in the editor.
BTW, I tried your program in a Windows 7 VM but seems to have some problems, I always get either "Bad file name in module P2SKP at address 0567:06A1" or "File not found in module P2SKP at address 0567:06A1", depending on how I write the file name (with or without extension).
I would like to implement something like that in the editor.
BTW, I tried your program in a Windows 7 VM but seems to have some problems, I always get either "Bad file name in module P2SKP at address 0567:06A1" or "File not found in module P2SKP at address 0567:06A1", depending on how I write the file name (with or without extension).
The problem could be that I used an ancient BASIC that supports 8.3 filenames only. I've attached a P2SKP zip file that is probably more up-to-date. Try renaming the Spin2 file to xxxx.sp2. You're very welcome to read the BASIC code and convert it to some other language. The functionality shouldn't be too difficult to follow. There might be one or two .INI file settings I don't use. I've been using the P2SKP.EXE and P2SKP.INI successfully today.
I've also attached 8086.zip which contains the full .SKP file with skip pattern constants for my 8086 emulator. I include the .SKP file by using a #include line at the start of the CON section. The 8086part.sp2 shows some of the code for rotates and shifts. Note that these are SKIPF patterns as defined by '''a and the ROLb, RORB, etc. labels have ' in front. If they were EXECF patterns the ' could be removed making them address labels that are jumped to by EXECF.
I don't use a space after every skip char as I think it wastes too much space. I do use one space to separate 8-bit patterns in lower-case from 16-bit patterns in upper-case. Using the same letter for the same function makes code easier to write and understand later.
@JonnyMac said:
As every, thank you Marco for your work on this. I am hoping that -- for Windows users, anyway -- we'll be able to use PNut as a command-line tool and have access to all of the P2 DEBUG features.
It is in the works...
I need to add the preference dialogs, and a couple of other bits, and it is done.
PS: Did you see the F1 sprint race from China? Clearly, Carlos is not leaving the team without sending a message. Personally, I hope he ends up at Red Bull, though Checo is doing a really good job this year knowing he's out of contract, too.
PS: Did you see the F1 sprint race from China? Clearly, Carlos is not leaving the team without sending a message. Personally, I hope he ends up at Red Bull, though Checo is doing a really good job this year knowing he's out of contract, too.
Yes, he really deserves a seat somewhere, better if a top-team.
Just to report a small issue using debug.
The output of this example seems to be excluding the second parenthesis inside the STRSIZE term of the debug instruction:
Comments
Hi Macca thanks for this.
This was what I was waiting for but it isn't working correctly for me.
I have no idea what this actually did but while the Binary now seems to upload correctly via "Propeller Tool v2.9.3" or "propeller-load.exe" into RAM or eeprom but the code fails to run on my P1 board.
Worse than that, I thought for a while that it had distroyed something as afterwards those boards could not be programmed directly from "Spin Tools IDE v0.34.1" from the spin source either?
I repeatedly tried to re-load the code, using "propeller-load.exe" and "Spin Tools IDE v0.34.1" and each time it gave no errors (except for one that did timeout on an eeprom error but not the rest) but then the boards wouldn't boot. I tried 3 boards before getting really scared I was blowing them up somehow, 3 different generations of my board all acted the same way.
Even a PC reboot didn't allow "Spin Tools IDE v0.34.1" to program these boards (directly from the spin source), either to RAM or EEPROM though all seemed to load ok but again no boot.
I finally tired reprogramming them with my latest code via "Propeller Tool v2.9.3" from an eeprom file I had made yesterday, and magically the boards would now boot ok.
The source code for all these attempts was the same, either raw SPIN or Binary file from "Spin Tools IDE v0.34.1" or an eeprom file made with the same code & compiled via "Propeller Tool v2.9.3".
This works well on the few lines I have tried it on, thanks, I really missed this function, I had to spend ages adding or reducing indents everytime I needed to add conditions into existing code.
Thanks @macca your efforts are appreciated.
I don't know why the uploaded program doesn't work, maybe I have changed something in the compiler, however without a binary comparison I can't tell what. Was it working with the previous 0.34.0 release ?
Can you send me the complete source (even privately if you don't want to make it public) ?
About the programming issue, that's really weird, there is absolutely nothing that an uploaded program can do to prevent the programming since it is a hardware handshake that takes places before the program is even loaded into ram. There may be timing issues where the serial loader doesn't properly recognize the programming data after a reset, but this would happen independently from the program.
Ok I did some more testing with different programs and couldn't get release 0.34.1 to write to anything P1 <didn't test P2>, this should have occured to me before, but I was concentrating on the Binary file and forgetting the full picture.
I just renamed "spin-tools-0.34.1.jar" to "spin-tools-0.34.1.jar(buggy)" and put spin-tools-0.34.0.jar back into my spin tools folder with no other changes and Spin Tools IDE is now working again.
Is that ok or should I copy the entire contents of "spin-tools-windows-0.34.0.zip" back into my spin tools folder?
That's really weird. However I don't understand if the programs are uploaded correctly but doesn't work, or are not uploaded at all, which should give an error at some time.
Have you tried with something simple like blinking a led ?
Yes, that's enough.
Ok, I wrote a simple Blink.spin program and installed it using <0.34.0> and it worked fine from RAM; installed it to the eeprom also working.
Then I ran my eeprom viewer in RAM and captured a text view of the eeprom contents. {I can send you this is you like, it is very small?}
Switched to <0.34.1> and installed it to RAM where it worked fine; installed it to the eeprom also working, so it does upload.
Then I tried to run my eeprom viewer in RAM but it wouldn't run, I guess it loaded ok it just wont run.
Switched back to <0.34.0> and installed my eeprom viewer in RAM and captured a text view of the eeprom contents, a few differences but still works.
So that means <0.34.1> can write to RAM and EEPROM but more complex programs just don't seem to run.
Ok, so the basics are working.
I guess something got broken in the 0.34.1 release, however without a binary comparison I can't tell what, all tests I can do are passing (all spin examples and libraries shipped with the IDE and some more downloaded from OBEX).
If you can send me the complete source code of one of the programs not working I can compare and fix the issue.
Thank you.
Done, I have emailed it to you at your maccasoft.com email address.
I had renamed the master program for simplicity but think I sent you the wrong zip file, so you will have to origional file name but am sure you can work it out.
I found the source of the problem: I have added the checksum calculation to a function that is called recursively with data that doesn't contain a checksum, corrupting the binary.
Still wondering why the programs I have tested are working correctly.
The binary generated for your source are exactly identical to the binary generated by openspin so, hopefully, there aren't other issues with the compiler.
I'll publish a bugfix release tomorrow.
Thank you!
Released version 0.34.2
The P1 checksum now should work correctly.
Hope this doesn't break something else.
Thanks macca, great work as usual, sorry to be a bother.
Perhaps your compilier doesn't like my programming style
It is probably right, I am self taught and I sometime do things in odd ways!
If it wasn't for help from this forum I would really struggle to do some things, so thanks everyone.
Opps, I was writing my reply above at the same time as you were uploading your new version.
I Can confirm I have tested <0.34.2> and every thing I tried with <0.34.1> that failed, is now working.
Tests with Spin tools IDE <0.34.2>
Installed <0.34.2> & Uploaded my boards code directly from Spin tools IDE "upload to flash" button. WORKED
Then used Spin tools IDE to create a <.binary> version, which I uploaded in 2 different ways.
Uploaded using:-
Command line via propeller-load.exe WORKED
Propeller tool v2.9.3 WORKED
So all is looking good, granted only after 5 minutes testing much better than the prior version.
Thanks Macca
As an extra note to the above, I have a C# program that can be used to upgrade my boards, but it expects a < .eeprom> file.
So, I wanted to test if it was possible to use the output of Spin Tools IDE <.binary> file to update the board by changing the extension to < .eeprom>
So by double clicking on my newly renamed < .eeprom> file, it opened in Propeller tool v2.9.3 and uploaded to my board sucessfully via the Prop tool, so far so good.
I then tried the renamed file on my C# program but it gives an error part of the way through, probably correspending to the size difference from a fully populated
< .eeprom> file at 32K and a partly populated <.binary> file at 26K.
My guess is the binary file compresses or leaves out the Stack area or something simular and my C# program is expecting a fully populated 32K file.
As a workarround, double clicking on the < .binary> file, opened it in Propeller tool v2.9.3 and I could then save it from there as an < .eeprom> file of 32K is size and that works with my C# program with no problems.
Hello Marco
It looks like the send mechanism does not work correct in SpinTools. The problem seems to be with included strings:
send := @tx send("Hello",13,10) | should send every character of string with tx() (but sends only the address of string, I think)Andy
Looks correct, here:
At least the binary output is the same as PNut.
Thank you Macca
Updated from version 0.32.1 to the newest, and now it works ...
Andy
@macca: In a comment to Chip vis-à-vis PNut, you said:
Would you also consider enabling the use of external compilers so that we can use Propeller Tool directly with PNut and FlexProp? I don't use the graphical debug windows in PNut often, but when I need them, I do. I know it's selfish as a Windows user. Forgive me for that.
I was thinking to add an option to invoke a generic external tool, more or less like to use a command line prompt: set a command to run from the current (or pinned) source directory, passing the source file path itself.
May be used to start flexspin, PNut in debug mode or anything else.
This won't replace the internal compiler, just add something to invoke manually.
That would be great. Thank you, Marco.
Released version 0.35.0
This is mainly a bugfix release in order to allow the Atari 2600 (spin version) to compile.
While still waiting for the update PNut source to be published, this release includes some preliminary work for the structure definitions, the CON and VAR sections syntax should work, it also has some "raw" implementations, meaning that structures can actually be used to some extents. It doesn't generate the PNut bytecode, it just generates the memory/variable opcodes needed to reach the structure elements (I guess that the PNut implementation is a bit more efficent). Arrays doesn't work yet.
Also added an experimental skip pattern generator that makes use of the block selection feature:
Write the pattern in a more or less standard syntax with letters for instructions to run and vertical pipes for instructions that are to be skipped, select the vertical block and press SHIFT+ALT+P (or use the Edit -> Make skip pattern menu) to show the pattern. The generated pattern is also copied to the clipboard and can be pasted where it is used.
Other changes:
FYI, I've written a program that generates skip patterns automatically. Please see:
https://forums.parallax.com/discussion/171125/skip-patterns-generated-automatically
Readme file is P2SKP.TXT in P2SKP.ZIP.
I think I'm the only person who uses this program but it's so quick and easy, once you understand the simple syntax. For example, my 8086 emulator has more than 200 skip patterns and it takes about one second to automatically generate them all.
As every, thank you Marco for your work on this. I am hoping that -- for Windows users, anyway -- we'll be able to use PNut as a command-line tool and have access to all of the P2 DEBUG features.
I would like to implement something like that in the editor.
BTW, I tried your program in a Windows 7 VM but seems to have some problems, I always get either "Bad file name in module P2SKP at address 0567:06A1" or "File not found in module P2SKP at address 0567:06A1", depending on how I write the file name (with or without extension).
The problem could be that I used an ancient BASIC that supports 8.3 filenames only. I've attached a P2SKP zip file that is probably more up-to-date. Try renaming the Spin2 file to xxxx.sp2. You're very welcome to read the BASIC code and convert it to some other language. The functionality shouldn't be too difficult to follow. There might be one or two .INI file settings I don't use. I've been using the P2SKP.EXE and P2SKP.INI successfully today.
I've also attached 8086.zip which contains the full .SKP file with skip pattern constants for my 8086 emulator. I include the .SKP file by using a #include line at the start of the CON section. The 8086part.sp2 shows some of the code for rotates and shifts. Note that these are SKIPF patterns as defined by
'''aand the ROLb, RORB, etc. labels have'in front. If they were EXECF patterns the'could be removed making them address labels that are jumped to by EXECF.I don't use a space after every skip char as I think it wastes too much space. I do use one space to separate 8-bit patterns in lower-case from 16-bit patterns in upper-case. Using the same letter for the same function makes code easier to write and understand later.
It is in the works...
I need to add the preference dialogs, and a couple of other bits, and it is done.
Grazie, Marco! Grazie!
PS: Did you see the F1 sprint race from China? Clearly, Carlos is not leaving the team without sending a message. Personally, I hope he ends up at Red Bull, though Checo is doing a really good job this year knowing he's out of contract, too.
Yes, he really deserves a seat somewhere, better if a top-team.
@macca
Just to report a small issue using debug.
The output of this example seems to be excluding the second parenthesis inside the STRSIZE term of the debug instruction:
While in Propeller Tool this is the output:
