What's the draw time? How many bytes / scan line can be moved?
Oh, I didn't notice this question. The driver reads only on the active video portion of the scanline. In the thread about the writing speed-record, is code that allows writing a buffer from cog ram into the SRAM at 15MBps (15 million bytes, NOT 1024*1024). HSYNC is 10.9 microseconds. 15MHz*10.9us=163px. Currently the driver runs at 224 px h. resolution, 1 pixel is 12 Propeller pixel clocks, 224*12=2688 of 3008, so about 10% of active scanline is used for overscan. Active scanline is 52.6us, so there's extra 5 microseconds, about 80px, so 224 is barely doable.
epmoyer, ok, so I think I have to build a programming cable when you get started with the driver...
Block fill is easy to do - see the HX512K fast forward thread. But instead of setting the SRAM to read mode, set it to write mode and set bus to all zeroes (or some other value). clears the memory @ 40MHz.
I made a bunch of progress on the bit mapped full color E512K driver this weekend. I started with Jasper's driver and modified it so that instead of reading from the SRAM directly it reads from a line buffer in main memory, and I changed it to output 4 pixels at a time instead of 1. At 4 pixels per waitvid the system RAM reads happen fast enough to keep up with the waitvids.
What I'll do next is move from 1 scan line buffer to 2 scan line buffers. The display driver will ping pong between them, and a separate "scan line copy" process (in a separate cog) will keep them loaded by copying data from the SRAM in lock-step.
My big realization was that the important thing in the data flow model is to minimize the time spent accessing the SRAM for display and blanking, so that the rendering code would be left with the maximum possible bandwidth for random access drawing. So with that in mind, the "scan line copy" process will blast a scan line from the SRAM into its local COG memory using Jasper's CNTRB trick to go as fast as physically possible, then will copy that scan line into the main memory scan line buffer at a slower rate (as longwords, being throttled by the hub).
A third "random access" cog will manage random access to the SRAM for rendering, and will use a semaphore to avoid colliding with the "scan line copy" cog's read bursts. This "random access" cog will use a queue located in cog RAM to prepare random access writes (as requested by user software), and will blast them out to the SRAM whenever it can get access (i.e. between the "scan line copy" cog's read bursts). Since these accesses are pre-queued in local cog ram they can also (like the SRAM read bursts) be performed at maximum speed.
The remaining trick is then to handle page swapping and page blanking. The "scan line copy" cog knows which line the display cog is on, so in the case where the last line has been queued up and the user app has indicated that a page swap is ready, the s"scan line copy" cog will use the CNTRB trick to perform a blanking fill on the current (now obsolete) page and then will swap to the other page for the next sequence of burst reads.
Again, the engine will require the Extended Address Mode version of the E512K PLD so that burst reads and random access writes can be directly addressed in both 48K pages instead of having to "walk up" to the desired address using the auto-increment mode (which would make keeping up with the scan line rendering impossible).
Ok, that sounds cool. I've not made much progress, I've been busy with other things but I hope that I can get something done tomorrow after work. and epmoyer, are you going to use that driver in Spacewar? Will it be some kind of vector or line based driver?
I plan to glue a modified version of Parallax's graphics_drv_010.spin up to this display driver as a "front end", which will allow (at the very least) plot, line, text, and vector stuff. If I recall correctly there are only one or two places in that code which actually write pixels to the image buffer, so probably once I port those couple sections then all the graphics functions will be up and working.
SpaceWar! uses the graphics_drv_010.spin library today, so if the project goes well and the rendering speeds are good then I'll port SpaceWar! over to full-color for a proof of concept.
Yep, changing the routines from tiles and bit addressing for pixels should be all it takes. The rest works nicely from there, though I think the color handling needs to be tweaked as well.
Have any numbers on the fill rate, bytes per frame, etc... yet?
No numbers yet. My plan is to walk before I run, so I'm coding for an initial alpha proof-of-concept which doesn't use the counter B trick, doesn't do auto page blanking, and only uses a single video page. I will port graphics_drv_010.spin for the alpha.
What I expect to end up with is a demo of some "graphics_drv_010.spin" style operations (lines or vector drawings or whatever) being repeatedly drawn to the buffer with no blanking using the full color palette and being displayed live. Since the alpha will not use page swapping it will be compatible with the production E512K PLD, so all theE512K owners out there (yes, I mean both of you. Hey, wake up in the back row, no napping! [noparse]:)[/noparse] will be able to run it without re-programming their PLDs (yet).
I got the line buffer copy code working last night, so I'm about 1/3 of the way to the alpha. Next third is to get the ping-pong between two line buffers working (right now I am just filling the whole screen with the first raster line), and the last third is to port graphics_drv_010.spin (which should actually be pretty easy).
Oh, and I've got an artifact which is just driving me crazy and I can't find the cause. I'll post some code tonight and see if someone can't give me some help. My very first real horizontal scan line (i.e. after the vertical over scan), is shifted slightly to the right relative to all the other scan lines and I can't put my finger on why. My display code differs from Jasper's in that it transitions into displaying 4 pixels per waitvid for the display data instead of 1. The artifact showed up as a result of that mod.
Anyway, you'll see what I'm talking about in my next code post.
Okay, my military service starts tomorrow... Sorry for not getting a release done, I figured that I should have fun with my friends while I still could instead of program the driver. I'll (most likely) continue when I get home... that'll be in 6 months or a year.
Well, it's a defense-only military so I'll be safe : P ... but well, I hope I have some motivation left after that... for Hydra programming, I mean. Thanks ^_^
If you have time make one final ZIP with the whole thing post and email it to me as well at ceo@nurve.net, and if you like I will add it to the goodies section of the HYDRA CD.
But anyway, the last working version is the one included in the thread. Current feature that I'm working on is storing tiles in SRAM, caching and preshifting them in hub ram on VBLANK. And it doesn't work (yet). I might take a laptop to the barracks somewhen in near future (I'll have 3 days off in two weeks again...) so I could work on some conversion tools for the driver.
Many years ago I was working on a 3-d DOS game right before I left for the Marines at 17. I put the final version on a floppy and left it with my parents to keep safe. They're clueless about computers and somehow when I came back they had all my junk disks but not any of the ones with my code on it! And without asking me they'd given away my oldest computer, an "antique" Tandy 1000 to save space. The source code to the game I'd been working on remained lost for years, until one day it occurred to me that there might still be a copy of the code on the hard drive of the old Tandy. I managed to locate it and finally got the code back.
I've overcome the greatest problem now (ie. I have a transparent tilemap on top of everything else, the problem was video generator messing with sometin even though pins were in input mode). So there will be a release in probably a few weeks.
And here's an important question for Andr
I'm not talking about nintendo but about forum moderators... anyway, I'll just optimize (I want to get YPS of 4 per sprite layer. YPS stands for Yoshis per scanline if you didn't know [noparse];)[/noparse] ) and test a bit and write some REALLY quick documentation and post the first REAL RELEASE today.
Woot, nice demo [noparse]:)[/noparse]
Sorry for the late reply, just been out down the shore watching the Red Arrow's doing a display [noparse]:)[/noparse]
So what was your final YPS count?
I will give it a try tonight.·It would be cool to see retro remakes of every single old game. There are definitely enough graphics drivers now and with the sram, all doable.
Just tried this out today (got my HX512 today in the mail)... ran this thing and WOW!!!!!!!! That's really all I can say at this point. This is absolutely wonderful work, and it seems like a wonderful platform for creating full games with.
Would it be possible to combine this with an SD card, IE load gfx directly from the SD card to the HX512 to save memory in the EEPROM?
Would it be possible to combine this with an SD card, IE load gfx directly from the SD card to the HX512 to save memory in the EEPROM?
Maybe, but it would be very hard and would need modifications to the driver itself, because the SD card and HX512K would have to share pins. It wouldn't be practical. However, I think I'm gonna make a compression lib (RLE+LZ maybe) so that more GFX could be fitted in the 128/256K on Hydra. Of course, all the sprites have to be decompressed in HUB RAM, but people could fit more content in their games. Also, I've started working on a platformer game that uses XVIDEO...
BTW, it's final that I have to serve only 6 months in the finnish defense force, ie. I have 4 months left : P
Comments
Oh, I didn't notice this question. The driver reads only on the active video portion of the scanline. In the thread about the writing speed-record, is code that allows writing a buffer from cog ram into the SRAM at 15MBps (15 million bytes, NOT 1024*1024). HSYNC is 10.9 microseconds. 15MHz*10.9us=163px. Currently the driver runs at 224 px h. resolution, 1 pixel is 12 Propeller pixel clocks, 224*12=2688 of 3008, so about 10% of active scanline is used for overscan. Active scanline is 52.6us, so there's extra 5 microseconds, about 80px, so 224 is barely doable.
Block fill is easy to do - see the HX512K fast forward thread. But instead of setting the SRAM to read mode, set it to write mode and set bus to all zeroes (or some other value). clears the memory @ 40MHz.
What I'll do next is move from 1 scan line buffer to 2 scan line buffers. The display driver will ping pong between them, and a separate "scan line copy" process (in a separate cog) will keep them loaded by copying data from the SRAM in lock-step.
My big realization was that the important thing in the data flow model is to minimize the time spent accessing the SRAM for display and blanking, so that the rendering code would be left with the maximum possible bandwidth for random access drawing. So with that in mind, the "scan line copy" process will blast a scan line from the SRAM into its local COG memory using Jasper's CNTRB trick to go as fast as physically possible, then will copy that scan line into the main memory scan line buffer at a slower rate (as longwords, being throttled by the hub).
A third "random access" cog will manage random access to the SRAM for rendering, and will use a semaphore to avoid colliding with the "scan line copy" cog's read bursts. This "random access" cog will use a queue located in cog RAM to prepare random access writes (as requested by user software), and will blast them out to the SRAM whenever it can get access (i.e. between the "scan line copy" cog's read bursts). Since these accesses are pre-queued in local cog ram they can also (like the SRAM read bursts) be performed at maximum speed.
The remaining trick is then to handle page swapping and page blanking. The "scan line copy" cog knows which line the display cog is on, so in the case where the last line has been queued up and the user app has indicated that a page swap is ready, the s"scan line copy" cog will use the CNTRB trick to perform a blanking fill on the current (now obsolete) page and then will swap to the other page for the next sequence of burst reads.
Again, the engine will require the Extended Address Mode version of the E512K PLD so that burst reads and random access writes can be directly addressed in both 48K pages instead of having to "walk up" to the desired address using the auto-increment mode (which would make keeping up with the scan line rendering impossible).
Post Edited (epmoyer) : 6/18/2007 3:47:54 PM GMT
SpaceWar! uses the graphics_drv_010.spin library today, so if the project goes well and the rendering speeds are good then I'll port SpaceWar! over to full-color for a proof of concept.
Post Edited (epmoyer) : 6/18/2007 11:00:54 PM GMT
Yep, changing the routines from tiles and bit addressing for pixels should be all it takes. The rest works nicely from there, though I think the color handling needs to be tweaked as well.
Have any numbers on the fill rate, bytes per frame, etc... yet?
What I expect to end up with is a demo of some "graphics_drv_010.spin" style operations (lines or vector drawings or whatever) being repeatedly drawn to the buffer with no blanking using the full color palette and being displayed live. Since the alpha will not use page swapping it will be compatible with the production E512K PLD, so all theE512K owners out there (yes, I mean both of you. Hey, wake up in the back row, no napping! [noparse]:)[/noparse] will be able to run it without re-programming their PLDs (yet).
I got the line buffer copy code working last night, so I'm about 1/3 of the way to the alpha. Next third is to get the ping-pong between two line buffers working (right now I am just filling the whole screen with the first raster line), and the last third is to port graphics_drv_010.spin (which should actually be pretty easy).
Anyway, you'll see what I'm talking about in my next code post.
Defense only huh? Canadian? [noparse];)[/noparse]
If you have time make one final ZIP with the whole thing post and email it to me as well at ceo@nurve.net, and if you like I will add it to the goodies section of the HYDRA CD.
Andre'
But anyway, the last working version is the one included in the thread. Current feature that I'm working on is storing tiles in SRAM, caching and preshifting them in hub ram on VBLANK. And it doesn't work (yet). I might take a laptop to the barracks somewhen in near future (I'll have 3 days off in two weeks again...) so I could work on some conversion tools for the driver.
And here's an important question for Andr
Sorry for the late reply, just been out down the shore watching the Red Arrow's doing a display [noparse]:)[/noparse]
So what was your final YPS count?
: P
So is that 1 Layer Background + 1 Layer Sprites + 1 Layer Foreground + 1 Layer Sprites ?
Andre'
·
Would it be possible to combine this with an SD card, IE load gfx directly from the SD card to the HX512 to save memory in the EEPROM?
Maybe, but it would be very hard and would need modifications to the driver itself, because the SD card and HX512K would have to share pins. It wouldn't be practical. However, I think I'm gonna make a compression lib (RLE+LZ maybe) so that more GFX could be fitted in the 128/256K on Hydra. Of course, all the sprites have to be decompressed in HUB RAM, but people could fit more content in their games. Also, I've started working on a platformer game that uses XVIDEO...
BTW, it's final that I have to serve only 6 months in the finnish defense force, ie. I have 4 months left : P