Nice that Spin Tools IDE doesn't error out on symbol names longer that 30 characters, like Prop Tool...
Had earlier shortened this to accommodate: #fPlayerDistanceToTheProjectionPlane
Took Spin Tools for a drive last night. Dadgum is it nice. I figured I would have to update some code, and I do. Everything I have been coding is in Propeller Tool.
I have a retro computing project that is a plug in cartridge to my Color Computer 3 that is P2 based. Everything about it appeared to work, except SIDcog. Haven't tracked down the issue yet, but will work with it as a standalone object to see if I can figure it.
Again, I really like just downloading and running a tool like this. It popping up the comments when you hover over a object and the ability to navigate directly to a method is awesome!
If features like this, I feel spoiled as all get out. (To use a southern expression)
Now I am going to have to add comments to each PUB to explain the more complex methods. Worth it!
PS: Thank you @JonnyMac for already having done that to all your code!
I still haven't figured out why the built in compiler in spin tools has a different result from PNUT V51a. Attached is the project I am having trouble with.
@ke4pjw said:
I still haven't figured out why the built in compiler in spin tools has a different result from PNUT V51a. Attached is the project I am having trouble with.
It is the trunc function that returns a floating point instead of the long value, all ADSRTable and samplePeriod values are wrong.
I'll do a release soon, I want to add some new things.
I have reviewed and fixed the address operators @ and @@ to ensure they are compatible with PNut and Openspin, also added the @@@ operator to return the DAT symbols absolute hub address as a constant for both spin1 and spin2. With the @@@ operator it is no longer necessary to use the loc instruction, however the source will be incompatible with PNut, but should be compatible with flexspin.
Also, implemented the editor bookmarks, like Propeller Tool.
Click on the line number column to toggle the bookmark then use the Edit -> Go to Bookmark menu items or the CTRL+num shortcut to jump to the bookmarked line.
The editor now checks if the loaded file was changed with an external tool and prompts to reload, so tools can update the source (like a skip pattern generator) and the changes will be reloaded.
Running the external tools now also closes the serial port, so tools like loadp2 or PNut can upload the binary even if you leave the terminal window open. The serial will then be reopened automatically so the output goes to the terminal (ensure there is a proper delay or wait for a keypress).
Other changes:
Fixed trunc result
Fixed table and tree theme colors
Fixed unaligned relative jump error check
Fixed PAsm instructions alignment
Refactored debug statements compiler to avoid duplicates
Revisiting Spin Tools. Seems to be the best choice right now. Was pleasantly surprised to infer from the previous comments that it is already compat with v51. Tried what I am working on that uses v51 features and everything seemed fine, except 'exp10'. This is ok in pnut, but maybe I am doing something unexpected. See line 54
Also, implemented the editor bookmarks, like Propeller Tool.
Thank you! Thank you! Thank you!
I'm pretty sure the only thing left on my "wish list" is code folding of the editor window (like the color-coded summary view in Propeller Tool). Yes, I have the outline window turned on, but it's monochrome so it's a little harder for me to locate methods.
Again, Marco, thank you for your efforts on Spin Tools. It's gone from promising to fantastic, and I know the community is thrilled with all that you've done. I certainly am.
@ke4pjw said:
FYI, V0.49.0 still shows 0.48.1 in the about screen on Windows.
If you have unpacked the new version over an existing, the old spin-tools.jar file is still there and it is loaded before the new one.
Check the lib directory, and delete the old spin-tools-0.48.1.jar file (make sure there is the new spin-tools-0.49.0.jar file).
@"R Baggett" said:
Revisiting Spin Tools. Seems to be the best choice right now. Was pleasantly surprised to infer from the previous comments that it is already compat with v51. Tried what I am working on that uses v51 features and everything seemed fine, except 'exp10'. This is ok in pnut, but maybe I am doing something unexpected. See line 54
I have compared the binaries with PNut and I don't see any critical difference. The binaries are not exactly the same because Spin Tools encodes the constants with a different opcode (that was an oversight on my side) but the actual value seems correct.
@macca A bit confused now about what "LOC" does with @@@.
But, now that have @@@, think can just replace all LOC with MOV, right?
Or, missing something?
@Rayman said:
@macca A bit confused now about what "LOC" does with @@@.
But, now that have @@@, think can just replace all LOC with MOV, right?
Or, missing something?
Yes, just use mov var, ##@@@symbol, or jmp or call.
loc with an already absolute value returns the wrong result (I guess, actually I never understood what loc actually does...).
I was getting an error that indicated 'EXP10' was unrecognized.. after reading of the old .jar files problem above, I deleted the spin tools directory and then unzipped the new file.. all is well now. I had indeed unzipped the new version over my old one. Thanks for this great IDE!
@JonnyMac said:
I'm pretty sure the only thing left on my "wish list" is code folding of the editor window (like the color-coded summary view in Propeller Tool). Yes, I have the outline window turned on, but it's monochrome so it's a little harder for me to locate methods.
Yes, code folding is very complicated to implement, there is a framework that I'm trying to use but requires some deep changes.
Again, Marco, thank you for your efforts on Spin Tools. It's gone from promising to fantastic, and I know the community is thrilled with all that you've done. I certainly am.
Feature Request: When in Dark Mode, can we have varying levels of darkness as the background? (for each block) I think extremely dark versions of the "Light" color scheme might work too.
@Rayman said:
Is this proof that pnut could implement @@@ as well?
I don't think so, I'm not using the same compiler as PNut.
I don't have a very clear understanding of PNu't source, but seems that it requires a change on how the binary image is built, some elements are moved around after compile, for example the interpreter is inserted by moving the object's memory upward to make room, this makes hard if not impossible to know the final memory location at compile time. I don't know if PNut-TS does the same, but certaininly is a better candidate to make such changes.
@ke4pjw said:
Feature Request: When in Dark Mode, can we have varying levels of darkness as the background? (for each block) I think extremely dark versions of the "Light" color scheme might work too.
Yes, guess I need to start working on customizing the color theme settings.
Took some debugging, but finally got the 90s 3D code to work in Spin Tools (with liberal use of @@@).
Code needs clean up now, but works in both Spin Tools and FlexProp, this is great.
The strange thing is when you go to call a routine in LUT.
Seems there are now two routines/labels, both called "lutstart".
There's the one in LUT and the one in the hub.
Seems like one could call either of these and get the same result.
What think am seeing is that when called like this: call #lutstart 'Now in LUT
it goes to LUTEXEC
And, when called like this: call #@@@lutstart
it goes to hubexec
The strange thing is when you go to call a routine in LUT.
Seems there are now two routines/labels, both called "lutstart".
There's the one in LUT and the one in the hub.
I'm not sure to understand, seems that you expect things to work differently than what expected with PNut, which is not. If something works differently there is probably a bug in the compiler.
The instructions above are copying the hub content to the lut ram, that's how it works since the beginning and is not dependent on the compiler (you can do the same with PNut), you have two copies of the code, one in the original hub ram location and one in LUT. That's correct.
Seems like one could call either of these and get the same result.
I guess it also depends on the code but yes, generally it is the same, except you have a considerable performance hit at each call or if the code branches because of the hubexec queue.
What think am seeing is that when called like this: call #lutstart 'Now in LUT
it goes to LUTEXEC
And, when called like this: call #@@@lutstart
it goes to hubexec
Yes, right, the latter goes to hubexec if the location is above $400, otherwise it may randomly jump to COG or LUT exec if the code is not aligned.
Just remember how the P2 works: all addresses from $000 to $1FF runs from COG ram $200 to $3FF runs from LUT ram, all addresses >=$400 runs from hub ram.
If you happen to jump to a location less than $400 you are actually jumping to COG or LUT ram, regardless if you have used the @@@ operator.
Comments
Nice that Spin Tools IDE doesn't error out on symbol names longer that 30 characters, like Prop Tool...
Had earlier shortened this to accommodate:
#fPlayerDistanceToTheProjectionPlaneBut now, think will just leave as is.
Took Spin Tools for a drive last night. Dadgum is it nice. I figured I would have to update some code, and I do. Everything I have been coding is in Propeller Tool.
I have a retro computing project that is a plug in cartridge to my Color Computer 3 that is P2 based. Everything about it appeared to work, except SIDcog. Haven't tracked down the issue yet, but will work with it as a standalone object to see if I can figure it.
Again, I really like just downloading and running a tool like this. It popping up the comments when you hover over a object and the ability to navigate directly to a method is awesome!
Great job @macca !
+1
If (when?) Marco is able to add Propeller Tool type bookmarks and code folding of the edit window, I will completely abandon Propeller Tool.
If features like this, I feel spoiled as all get out. (To use a southern expression)
Now I am going to have to add comments to each PUB to explain the more complex methods. Worth it!
PS: Thank you @JonnyMac for already having done that to all your code!
I still haven't figured out why the built in compiler in spin tools has a different result from PNUT V51a. Attached is the project I am having trouble with.
It is the trunc function that returns a floating point instead of the long value, all ADSRTable and samplePeriod values are wrong.
I'll do a release soon, I want to add some new things.
Released version 0.49.0
I have reviewed and fixed the address operators @ and @@ to ensure they are compatible with PNut and Openspin, also added the @@@ operator to return the DAT symbols absolute hub address as a constant for both spin1 and spin2. With the @@@ operator it is no longer necessary to use the loc instruction, however the source will be incompatible with PNut, but should be compatible with flexspin.
Also, implemented the editor bookmarks, like Propeller Tool.
Click on the line number column to toggle the bookmark then use the Edit -> Go to Bookmark menu items or the CTRL+num shortcut to jump to the bookmarked line.
The editor now checks if the loaded file was changed with an external tool and prompts to reload, so tools can update the source (like a skip pattern generator) and the changes will be reloaded.
Running the external tools now also closes the serial port, so tools like loadp2 or PNut can upload the binary even if you leave the terminal window open. The serial will then be reopened automatically so the output goes to the terminal (ensure there is a proper delay or wait for a keypress).
Other changes:
Enjoy!
Revisiting Spin Tools. Seems to be the best choice right now. Was pleasantly surprised to infer from the previous comments that it is already compat with v51. Tried what I am working on that uses v51 features and everything seemed fine, except 'exp10'. This is ok in pnut, but maybe I am doing something unexpected. See line 54
Thank you! Thank you! Thank you!
I'm pretty sure the only thing left on my "wish list" is code folding of the editor window (like the color-coded summary view in Propeller Tool). Yes, I have the outline window turned on, but it's monochrome so it's a little harder for me to locate methods.
Again, Marco, thank you for your efforts on Spin Tools. It's gone from promising to fantastic, and I know the community is thrilled with all that you've done. I certainly am.
FYI, V0.49.0 still shows 0.48.1 in the about screen on Windows.
However the filename does show it is V0.49.0.0 in the properties of the executable itself.
Just thought you might want to know.
Also thanks for the update!
--Terry
Odd, that's not happening for me.
Do you have a shortcut that's pointing to the older version? (I've done this)
If you have unpacked the new version over an existing, the old spin-tools.jar file is still there and it is loaded before the new one.
Check the lib directory, and delete the old spin-tools-0.48.1.jar file (make sure there is the new spin-tools-0.49.0.jar file).
@macca That did it. I didn't realize the .jar files were named differently. Now I know
Thank you!
@macca Thanks for adding @@@ ! Testing it out now...
I have compared the binaries with PNut and I don't see any critical difference. The binaries are not exactly the same because Spin Tools encodes the constants with a different opcode (that was an oversight on my side) but the actual value seems correct.
What difference you see ?
@macca A bit confused now about what "LOC" does with @@@.
But, now that have @@@, think can just replace all LOC with MOV, right?
Or, missing something?
Yes, just use mov var, ##@@@symbol, or jmp or call.
loc with an already absolute value returns the wrong result (I guess, actually I never understood what loc actually does...).
I was getting an error that indicated 'EXP10' was unrecognized.. after reading of the old .jar files problem above, I deleted the spin tools directory and then unzipped the new file.. all is well now. I had indeed unzipped the new version over my old one. Thanks for this great IDE!
Yes, code folding is very complicated to implement, there is a framework that I'm trying to use but requires some deep changes.
Thank you.
Maybe adding block colors to the outline would be good idea (easy to implement, anyways)
Is this proof that pnut could implement @@@ as well?
Feature Request: When in Dark Mode, can we have varying levels of darkness as the background? (for each block) I think extremely dark versions of the "Light" color scheme might work too.
Thank you for your work on this @macca !
I don't think so, I'm not using the same compiler as PNut.
I don't have a very clear understanding of PNu't source, but seems that it requires a change on how the binary image is built, some elements are moved around after compile, for example the interpreter is inserted by moving the object's memory upward to make room, this makes hard if not impossible to know the final memory location at compile time. I don't know if PNut-TS does the same, but certaininly is a better candidate to make such changes.
Yes, guess I need to start working on customizing the color theme settings.
Took some debugging, but finally got the 90s 3D code to work in Spin Tools (with liberal use of @@@).
Code needs clean up now, but works in both Spin Tools and FlexProp, this is great.
Might investigate if there's a way to still use LOC as think it can save a register in COG code...
Hmm... Now that think about it, wonder if this code was wrote before figured out LUT exec...
FYI changes to to trunc function solved the issues with SIDCog. All of my code work perfectly with spin-tools.
Trying to decide if compiler is handling LUT exec properly or not.
Think it is good, but it's strange...
Copying some assembly code to LUT like this:
'copy lutexec code to lut ram mov ptra,##@@@lutstart setq2 #511-16 rdlong 0,ptraThe strange thing is when you go to call a routine in LUT.
Seems there are now two routines/labels, both called "lutstart".
There's the one in LUT and the one in the hub.
Seems like one could call either of these and get the same result.
What think am seeing is that when called like this:
call #lutstart 'Now in LUTit goes to LUTEXEC
And, when called like this:
call #@@@lutstartit goes to hubexec
So, suppose it is all good.
I'm not sure to understand, seems that you expect things to work differently than what expected with PNut, which is not. If something works differently there is probably a bug in the compiler.
The instructions above are copying the hub content to the lut ram, that's how it works since the beginning and is not dependent on the compiler (you can do the same with PNut), you have two copies of the code, one in the original hub ram location and one in LUT. That's correct.
I guess it also depends on the code but yes, generally it is the same, except you have a considerable performance hit at each call or if the code branches because of the hubexec queue.
Yes, right, the latter goes to hubexec if the location is above $400, otherwise it may randomly jump to COG or LUT exec if the code is not aligned.
Just remember how the P2 works: all addresses from $000 to $1FF runs from COG ram $200 to $3FF runs from LUT ram, all addresses >=$400 runs from hub ram.
If you happen to jump to a location less than $400 you are actually jumping to COG or LUT ram, regardless if you have used the @@@ operator.
@macca Thanks. Yes, using orgh to make sure @@@ called code is above $400