Well it's definitely a bummer to determine that my goal is literally just on the wrong side of the possibility barrier.
The real reason I was striving for the 640x480 resolution was so that my system would could be compatible with any VGA monitor, instead of just being compatible with multi-sync and arcade monitors.
If odd horizontal resolutions like 512 and 380 etc. are only going to be supported by a slim cross-section of hardware, then the effort-to-benefit ratio is a bit too skewed to justify devoting any more effort towards it. Though, I definitely am going to revisit it to see just how close I can get.
In the meantime, I'm going to switch over to developing the video driver for the authentic 15.72 kHz "CGA" standard arcade monitor resolution. Much slower video rate and lower resolution means developing a driver on easy mode. A lot of the information you guys have offered in this thread will still be very useful for its development, so thanks everyone!
I suspect you would find that 800x600 is a commonly supported resolution by many monitors. It can be down sampled to 400x300 as well and this still fits nicely with the hub timing of an 80MHz propeller.
However I think a common resolution to target for the retro arcade games of old is 288x224. I've managed to push some display drivers to hit this resolution with WHOP but it may not be well handled by all monitors. You could also get that easily from Quarter VGA 320x240 resolution with an outer black or colored border. I think Kuroneko has managed to do a 320 pixel wide single COG based scanline driver but still signalled as VGA. You should take a look if you get a chance. His work is very impressive.
The real reason I was striving for the 640x480 resolution was so that my system would could be compatible with any VGA monitor, instead of just being compatible with multi-sync and arcade monitors.
The VGA driver I'm using generates 320x240 in full color but the signalling is 640x480@60Hz, it just duplicates the pixels but the timings are standard VGA, no problems with any monitor or modern TV with VGA inputs.
That's 15 cycles total, so it should work with a 96MHz clock
The question is whether you can squeeze the rendering into the same cog along with the 160 register line RAM (which could overwrite any initialization portions).
@ericball Don't forget that the DJNZ termination adds another 4 clock cycles, so the next required waitvid after the loop ends would likely be delayed too much at those pixel rates. Hitting the wall there unfortunately.
@rogloh
Good point, one possibility is to extend the lineram buffer by one long and populate it with black (front porch), then skip the missing WAITVID from a timing perspective.
Front porch length is less critical as the sync pulse will reset the line timing.
Perhaps what *might* work out as a hack is to make use of the fact that the "counter" variable in the loop above would be already decremented to 0 at the end of the loop and could then be interpreted as a black color in the final WAITVID that happens after the end of the loop. It all depends on the specific timing of the D bus and what is currently read from D register at the WHOP time. You might just get lucky at these speeds such that D is always 0 in the extra clock cycles after the loop ends and not some other random garbage. Not sure but possibly worth an experiment for people that use 96MHz Propellers.
However, if I was willing to overclock to get 640x480 from a COG I'd likely just push it to 100MHz then stream VGA pixels out at 25MHz directly from the HUB RAM scanline buffer that holds the 640 pixels. Yeah its still not true 25.175 MHz VGA but it still works. Certainly analog VGA monitors and even LCDs to some extent are reasonably forgiving with the dotclock in my personal experience (at least using various Sony/Dell/Samsung gear). It seemed to me to be the vertical refresh frequency that needs to be more tightly constrained.
Comments
The real reason I was striving for the 640x480 resolution was so that my system would could be compatible with any VGA monitor, instead of just being compatible with multi-sync and arcade monitors.
If odd horizontal resolutions like 512 and 380 etc. are only going to be supported by a slim cross-section of hardware, then the effort-to-benefit ratio is a bit too skewed to justify devoting any more effort towards it. Though, I definitely am going to revisit it to see just how close I can get.
In the meantime, I'm going to switch over to developing the video driver for the authentic 15.72 kHz "CGA" standard arcade monitor resolution. Much slower video rate and lower resolution means developing a driver on easy mode. A lot of the information you guys have offered in this thread will still be very useful for its development, so thanks everyone!
However I think a common resolution to target for the retro arcade games of old is 288x224. I've managed to push some display drivers to hit this resolution with WHOP but it may not be well handled by all monitors. You could also get that easily from Quarter VGA 320x240 resolution with an outer black or colored border. I think Kuroneko has managed to do a 320 pixel wide single COG based scanline driver but still signalled as VGA. You should take a look if you get a chance. His work is very impressive.
https://github.com/konimaru/waitvid.2048
The VGA driver I'm using generates 320x240 in full color but the signalling is 640x480@60Hz, it just duplicates the pixels but the timings are standard VGA, no problems with any monitor or modern TV with VGA inputs.
loop WAITVID lineram, #%0123 ADD loop, d1 DJNZ counter, #loopThat's 15 cycles total, so it should work with a 96MHz clockThe question is whether you can squeeze the rendering into the same cog along with the 160 register line RAM (which could overwrite any initialization portions).
Good point, one possibility is to extend the lineram buffer by one long and populate it with black (front porch), then skip the missing WAITVID from a timing perspective.
Front porch length is less critical as the sync pulse will reset the line timing.
However, if I was willing to overclock to get 640x480 from a COG I'd likely just push it to 100MHz then stream VGA pixels out at 25MHz directly from the HUB RAM scanline buffer that holds the 640 pixels. Yeah its still not true 25.175 MHz VGA but it still works. Certainly analog VGA monitors and even LCDs to some extent are reasonably forgiving with the dotclock in my personal experience (at least using various Sony/Dell/Samsung gear). It seemed to me to be the vertical refresh frequency that needs to be more tightly constrained.