100% SPIN NTSC video driver
ericball
Posts: 774
Including the WAITVID instruction in SPIN has always seemed a little pointless to me. Although the video generator can be used to for other reasons, SPIN is too slow to generate video. Or is it?
Attached is a a demonstration of generating NTSC video with just SPIN code. It's admittedly low resolution (32 pixels across and only 4 colors for the whole screen), but it does prove it's possible. (It's also a testament to how tolerant TVs are to out-of-spec signals.)
Useless - yep. Well, unless you want a giant 2 character display. The problem is the cog is fully utilized, so there's no advantage to using the SPIN routine instead of a PASM driver.
There's also a quirk I haven't figured out. In theory it should be possible to change "colors" in NTSC_demo.spin after COGNEW and have it change onscreen, but it doesn't work.
Timing notes:
1. Constant 0 is fastest, followed by global and local VARs (at least the first 8), small constants, 32bit constants, and DAT being the slowest.
2. The reason I had to create the p+=8 section was it would lose sync if put in the normal spot after the inner REPEAT.
3. WAITVID( lvar, LONG[lvar][2] ) takes 1232 cycles, which means there's only time for 3 WAITVIDs per line at 80MHz.
4. Trying to handle PAL colors would take additional cycles, making it basically impossible in SPIN.
Attached is a a demonstration of generating NTSC video with just SPIN code. It's admittedly low resolution (32 pixels across and only 4 colors for the whole screen), but it does prove it's possible. (It's also a testament to how tolerant TVs are to out-of-spec signals.)
Useless - yep. Well, unless you want a giant 2 character display. The problem is the cog is fully utilized, so there's no advantage to using the SPIN routine instead of a PASM driver.
There's also a quirk I haven't figured out. In theory it should be possible to change "colors" in NTSC_demo.spin after COGNEW and have it change onscreen, but it doesn't work.
Timing notes:
1. Constant 0 is fastest, followed by global and local VARs (at least the first 8), small constants, 32bit constants, and DAT being the slowest.
2. The reason I had to create the p+=8 section was it would lose sync if put in the normal spot after the inner REPEAT.
3. WAITVID( lvar, LONG[lvar][2] ) takes 1232 cycles, which means there's only time for 3 WAITVIDs per line at 80MHz.
4. Trying to handle PAL colors would take additional cycles, making it basically impossible in SPIN.
Comments
Since Prop2 will be 8x faster, 256 pixels should be possible horizontally on it - in spin!