Thanks to the work of @Wuerfel_21, looks like it might be relatively easy to support multiple video output types (HDMI with sound, VGA, LCD) and multiple external RAM types (PSRAM, HyperRam).
The latter should enable 16-bit graphics, which would be a huge improvement.
Also want to fix up the math so that objects in distance are rendered better...
Got it to the state where it will compile in Prop Tool, Spin Tools, and PNut. But, it only runs correctly in FlexProp.
Why that is, not sure. Think it might be the presence of many DAT sections in the SpinGraphics file.
This appears to mess up the hubexec call addressing. But, not 100% sure about that.
Tried a bunch of things, but haven't made it work in anything but FlexProp.
Want to do a little work improving this version first though (because doesn't need external RAM).
Mainly want to get VGA driver so that basepin doesn't have to be #0.
Also want to have multiple cogs for rendering to get to 60 fps and improve math, for distant objects...
Hmm, if you can't get 60 FPS in a single cog like that, I think you might be doing something really wrong.
Classic column-rendering games store their textures rotated (compared to the usual way), i.e. such that all the pixels in a column are together. I think the best way to do it would be to block-read the whole column (for 64x64 8bpp, that's 16 longs) into cog ram and then use altgb+getbyte to grab the pixels in the inner loop. Writing can be sped up by using WRFAST+WFBYTE (yes, even writing a single item can be faster using FIFO)
There seem to be a bunch of other spots with unpipelined CORDIC ops or Hub RAM reads. See also my recent attempts at documenting all the stupid tricks: https://p2docs.github.io/faster.html
Probably harder to do: The natural direction (i.e. axis of constant Z) for floor/ceiling rendering is horizontal. Doom has a data structure (visplane_t) to transpose columns into rows for rendering (i.e. collect all the columns and then spit out the rows), but I don't remember how that works.
@Rayman said:
There appears to be a difference between a call to #address and #@address in Prop Tool. Is this documented anywhere?
Think found it in Spin2 manual.
Also, can get absolute address with #@@, but seems can't use absolute address with Prop Tool hubexec calls.
If you are building a Spin2 program (file contains PUB sections), PropTool/PNut will not give you real hub addresses in DAT, ever (because it only knows those after linking and there's no mechanism to backpatch them). So writing programs that jump between cog and hub is significantly handicapped. (There's a reason I often release Flexspin-only code...)
Must be that flexprop came out with spin2 first and so this used that.
Think Chip had some argument that relative addressing is better because you can swap in code from uSD or something and run it. But don’t think anybody ever do that in real life…
Pondering the bother to worth ratio here of making it work with prop tool…
If you want it to work, you have to fix up pointers at runtime. When the cog launches, PTRB contains the load/run address, which will then let you work out where everything else is. This is really annoying and basically prevents direct calls between hub/cog code.
Seems like giving Spin Tools a go would be quick and easy as the command line details for FlexProp are out in the open. Be mindful about spaces in command line -- encase in parenthesis to prevent problems (I had to do with with my PNut stuff because I put PNut into the Propeller Tool library which has a space in the path).
loadp2 has a bug in its flash programming code that only manifests on Windows (there's a thread somewhere else in the forums). The work-around is to use proploader instead for flashing, the command line would look like:
Sounds like there's hope for getting this to work in both FlexProp and Spin Tools IDE.
For the latter, @macca says he can add the "@@@" operator to access the real hub address for jumps and tables directly.
So, this already works in FlexProp: call #@@@Wait1msSub
It will probably never work in PNut or Prop Tool, but guess that's the way it is...
As @Wuerfel_21 and @macca reminded me, the work around is to use the value that is provided to the PASM2 cog in the ptrb register, the base address of the object.
You can then add this to the value provided by "loc #Wait1msSub" and then jump to the result.
Only problem is that a code like this one makes A LOT of hub calls and this would eat a bunch of cog space, so don't want to do it... Not to mention losing the ptrb register...
So now, the only thing to be mindful of is if a PASM2 routine is in cogexec or hubexec space.
Figured so, but just did: call #@@@DrawBackground
Where DrawBackGround is in cogexec space and this, suppose obviously, doesn't work.
So, if something gets moved between the two spaces, need to add or remove the "@@@" as needed.
Suppose that actually ads some clarity to the code as you can tell what is in cog and what is in hub...
@Rayman said:
As @Wuerfel_21 and macca reminded me, the work around is to use the value that is provided to the PASM2 cog in the ptrb register, the base address of the object.
It's not the object base address (PBASE), it's the cog launch address, which is slightly different. Obviously if the cog code doesn't start at the top of the first DAT section all bets are off, but in interpreted Spin there's also the object header that lives at PBASE and precedes DAT data.
Comments
I think it is 640x480 @ 60Hz.
The display looks correct, just not horizontally centered...
It looks like you have some timing problems. Maybe too much time to/from the horizontal sync pulse.
Decided it's time to fix this up...
Thanks to the work of @Wuerfel_21, looks like it might be relatively easy to support multiple video output types (HDMI with sound, VGA, LCD) and multiple external RAM types (PSRAM, HyperRam).
The latter should enable 16-bit graphics, which would be a huge improvement.
Also want to fix up the math so that objects in distance are rendered better...
Got it to the state where it will compile in Prop Tool, Spin Tools, and PNut. But, it only runs correctly in FlexProp.
Why that is, not sure. Think it might be the presence of many DAT sections in the SpinGraphics file.
This appears to mess up the hubexec call addressing. But, not 100% sure about that.
Tried a bunch of things, but haven't made it work in anything but FlexProp.
Want to do a little work improving this version first though (because doesn't need external RAM).
Mainly want to get VGA driver so that basepin doesn't have to be #0.
Also want to have multiple cogs for rendering to get to 60 fps and improve math, for distant objects...
There appears to be a difference between a call to #address and #@address in Prop Tool. Is this documented anywhere?
Think found it in Spin2 manual.
Also, can get absolute address with #@@, but seems can't use absolute address with Prop Tool hubexec calls.
Hmm, if you can't get 60 FPS in a single cog like that, I think you might be doing something really wrong.
Classic column-rendering games store their textures rotated (compared to the usual way), i.e. such that all the pixels in a column are together. I think the best way to do it would be to block-read the whole column (for 64x64 8bpp, that's 16 longs) into cog ram and then use altgb+getbyte to grab the pixels in the inner loop. Writing can be sped up by using WRFAST+WFBYTE (yes, even writing a single item can be faster using FIFO)
There seem to be a bunch of other spots with unpipelined CORDIC ops or Hub RAM reads. See also my recent attempts at documenting all the stupid tricks: https://p2docs.github.io/faster.html
Probably harder to do: The natural direction (i.e. axis of constant Z) for floor/ceiling rendering is horizontal. Doom has a data structure (visplane_t) to transpose columns into rows for rendering (i.e. collect all the columns and then spit out the rows), but I don't remember how that works.
If you are building a Spin2 program (file contains PUB sections), PropTool/PNut will not give you real hub addresses in DAT, ever (because it only knows those after linking and there's no mechanism to backpatch them). So writing programs that jump between cog and hub is significantly handicapped. (There's a reason I often release Flexspin-only code...)
This is a trip down memory lane…
Must be that flexprop came out with spin2 first and so this used that.
Think Chip had some argument that relative addressing is better because you can swap in code from uSD or something and run it. But don’t think anybody ever do that in real life…
Pondering the bother to worth ratio here of making it work with prop tool…
@Wuerfel_21 think it gets 37 fps, so maybe not horrible?
Two cogs should get it done.
Was also reading something by lode somebody on how to do sprites. Bought an ancient book to help with that although maybe don’t need it…
Played around trying to get this to work in Prop Tool and not getting anywhere... Feels like Spin2+PASM2+Hubexec is just broke in Prop Tool...
PT uses a very old version of PNut -- I wonder if it would work with the latest?
No luck... Maybe somebody can say if I'm doing something wrong...
I've reduced the assembly in "raycast5b_SpinGraphics1g_test.spin2" to basically this:
'DAT 'main loop MainLoop 'Fill offscreen buffer debug ("B") call #\@Wait1msSub debug ("A") jmp #MainLoopWhere the Wait1msSub has a "drvnot #56" added to it, so can see if working with Eval board.
This is outside of the cog, so is hubexec.
Tried every call incarnation can think of, but nothing works...
If you want it to work, you have to fix up pointers at runtime. When the cog launches, PTRB contains the load/run address, which will then let you work out where everything else is. This is really annoying and basically prevents direct calls between hub/cog code.
Yeah, think giving up on that. Thanks.
Now thinking about resurrecting SpinEdit so can use FlexProp directly .
Or maybe hacking spin tools ide is better…
Seems like giving Spin Tools a go would be quick and easy as the command line details for FlexProp are out in the open. Be mindful about spaces in command line -- encase in parenthesis to prevent problems (I had to do with with my PNut stuff because I put PNut into the Propeller Tool library which has a space in the path).
Since I get irritated with someone in the forums gives me "this should work" advice, I thought I should try what I suggested.
This is just step 1, but I think it's good.
It works! See attached.
What I'm using:
Compile:
C:\MyPrograms\flexprop\bin\flexspin.exewith
-2 -l --tabs=2 -D_BAUD=230400 -O1 --charset=utf8 -I "C:/Users/jmcph/Documents/Propeller Tool/Library" "${file.loc}\${file}"Run:
C:\MyPrograms\flexprop\bin\loadp2.exewith
-p ${serial} -b 230400 "${file.loc}\${file.name}.binary"That said, I have not had any luck with loading to flash. This is the output I see in Spin Tools, even after 8x the FIFO size.
Per guidance from Eric, one can now load the flash with proploader from inside Spin Tools.
Load Flash:
C:\MyPrograms\flexprop\bin\proploader.exewith
-2 -D baud-rate=230400 -p ${serial} "${file.loc}\${file.name}.binary" -eThanks, Eric, for the assist.
[deleted by JM]
[deleted by JM] -- see following post by Eric for fix.
loadp2 has a bug in its flash programming code that only manifests on Windows (there's a thread somewhere else in the forums). The work-around is to use proploader instead for flashing, the command line would look like:
I've updated the GUI to 7.4.2, and this uses proploader by default rather than loadp2 for flashing.
Sounds like there's hope for getting this to work in both FlexProp and Spin Tools IDE.
For the latter, @macca says he can add the "@@@" operator to access the real hub address for jumps and tables directly.
So, this already works in FlexProp:
call #@@@Wait1msSubIt will probably never work in PNut or Prop Tool, but guess that's the way it is...
As @Wuerfel_21 and @macca reminded me, the work around is to use the value that is provided to the PASM2 cog in the ptrb register, the base address of the object.
You can then add this to the value provided by "loc #Wait1msSub" and then jump to the result.
Only problem is that a code like this one makes A LOT of hub calls and this would eat a bunch of cog space, so don't want to do it... Not to mention losing the ptrb register...
So now, the only thing to be mindful of is if a PASM2 routine is in cogexec or hubexec space.
Figured so, but just did:
call #@@@DrawBackgroundWhere DrawBackGround is in cogexec space and this, suppose obviously, doesn't work.
So, if something gets moved between the two spaces, need to add or remove the "@@@" as needed.
Suppose that actually ads some clarity to the code as you can tell what is in cog and what is in hub...
It's not the object base address (PBASE), it's the cog launch address, which is slightly different. Obviously if the cog code doesn't start at the top of the first DAT section all bets are off, but in interpreted Spin there's also the object header that lives at PBASE and precedes DAT data.
@Wuerfel_21 This is making my head hurt. Glad we can use @@@ in FlexProp and hopefully Spin Tools IDE soon.