Refactor multicog VGA driver to re-utilize initialization code as buffer space about jcap HOT 10 CLOSED

176 longs aren't as much as you think :) Which isn't to say that a driver couldn't be done in that space, I just haven't checked your code in that respect.

What is the timing like ATM? Could you potentially get away with only two scan lines which need buffering?

from jcap.

@konimaru That's the point I'm actually trying to highlight haha; 176 isn't that much space, so re-using initialization code space will help. Right now, the main driver code (sans initialization code) is ~134 longs, and that's without the sprite engine yet.

For 640 x 480 @ 60 Hz, the amount of time over 4 lines that the driver has available to populate the scanline buffer is ~127 microseconds. Best case scanario (all instructions take 4 cycles, so basically ignoring missed jumps and hub memory access) is I can execute 2,540 instructions during this time. Right now @ 40 tiles per scanline I'm at ~2,277 counting all instructions as 4 cycles; so honestly it's probably blowing it as is.

from jcap.

Going down to two lines per cog would rob me of two horizontal sync regions worth of buffer population time, so that's out since I'm already basically at capacity.

This is definitely an area of concern I'll have to address. The thing is though it's only an issue for 40 tile wide screens which is the highest I want to support (most games fall between 30 and 40). The next highest compatible width is 20 but that's honestly too low to make a respectable game from.

from jcap.

There are two possible branches to consider at this point:

1. I go from 2 cogs/4 lines each to 4 cogs/1 line each, which would essentially give me 3 entire scan lines worth of time to generate the data for only one (instead of attempting to leverage the horizontal sync areas of 4 lines to find time for 4 lines worth of data).

or...

2. I switch over to a method where there is no interlacing, there is only a cog dedicated to pulling in raw (i.e. already dereferenced from the tile map/palette and colored) video data from Main RAM which is populated by dedicated "render" cogs. This would result in essentially a "backwards" waitvid, where each long contains 4 8-bit pixels worth of data and I just print them sequentially. This means a LOT more waitvids per line, which means a much lower maximum horizontal video resolution of 256 pixels. Which, to be honest, isn't a deal-breaker as it's still a valid resolution displayable by VGA monitors AND it's actually closer to what classic arcade games displayed via CRT.

For now I'm going to keep working at the current paradigm and leverage some of Chip's high-res VGA driver tricks to see what I can squeeze into the driver in terms of instructions and out in terms of execution time per render.

from jcap.

Regarding 2, scanline drivers are available for up to 800 pixels per line (256, 320, 400, 800) so I wouldn't worry to much about it (someone else did all the work already).

from jcap.

Interesting, potatohead over at the Propeller 1 forum made it sound like 256 was the max resolution with that method

from jcap.

Don't know about that, I just have a 400x300 with overlay in front of me and it's doing fine :)

from jcap.

Haha well there you go. Then, honestly, that is probably going to be the next thing I do after I take a crack at wrapping up the current effort. Because, and this is a pretty big deal, when I add in sprites their pixel colors will be based on the palette of the tile they're in. This would limit me essentially to monochromatic backgrounds wherever a sprite might need to venture so that I could leave enough colors to define objects so that they don't look like trash haha

from jcap.

http://m.wolframalpha.com/input/?i=%2831.777557100298+us+*+4%29+%2F+10.4166667+nanoseconds

from jcap.

Made unecessary by dual-Propeller development.

from jcap.