hmm, that's kinda surprising, BDD's POC v1.2 uses 74AC Logic and it runs at +16MHz, so even with the added complexity of your VGA circuit i still would've assumed it could easily reach ~6.3MHz.
oh well, maybe that's something for version 2 after you got this one running.
with a more optimized VGA circuit that is less intrusive on the CPU side so the CPU decoding logic can be simplied to run faster!


I'm also aiming for something like that with my SBC, but CPLDs are expensive, even just the one i have on my board costs as much as the CPU on it's own. it's hard to keep these things cheap AND fast!

and for the resoutions, i've personally come to enjoy the IBM PC like ones: 320x200 (8000 Bytes per bit per pixel) and 640x400 (32000 Bytes per bit per pixel) mostly because they just fit nicely into the nearest power of 2 with only a few bytes left over.
unlike the full versions which are slightly larger than the nearest power of 2 so you need to waste more RAM to fit them. 320x240 (9600 Bytes per bit per pixel) and 640x480 (38400 Bytes per bit per pixel).

320x200 @ 1bpp takes up 8000 Bytes exactly, it would be what i consider the "smallest comfortable resolution" with only 2 colors. doing a Block move to all of those bytes at 3.14MHz would take 17.8ms... slightly more than a single frame (16.6ms @ 60Hz)
320x200 @ 8bpp takes up 64000 Bytes, with 256 colors you can do a lot more, but you would also need to have your video circuit read bytes at 12.5MHz to keep up. also Block moving all of that would take 142.6ms (unsurprisingly, 8x more than the 1bpp version).
640x400 @ 1bpp takes up 32000 Bytes, 4x the amount of screen space, but also 4x slower to update the whole screen... 71.2ms Block Move.

however you look at it. if you want more resolution and/or color depth the update speed is going to suffer. though i guess if the goal is just to drawing shapes or rendering text that scrolls it shouldn't much of an issue, more of an inconvenience.

I'm interested to see how well it'll run!

Thanks Gordon. Every previous VGA board I made came with 320x240 with 4 colors (black, white, red, cyan). But I think you are meaning 4-bits, thus 16 colors. That would have been possible with the 6.29 MHz for sure, and it is "possible" here as well, if I added an additional RAM chip to get 16-bits wide each color latch.

And yes, the more color depth, the more RAM, the generally slower it goes.



Thank you Proxy. I mean, *could* it work? Perhaps. But my glue logic is 6 gates deep. Let's just say 10ns each gate, that's 60ns just to reach the RAM's /OE and /WE lines. Then, let's just say 20ns for the RAM to supply the pixel data (unlikely, but perhaps possible, it's rated at 55ns). And I don't latch at the very very end of the 80ns, so that's another 10ns or so delay. You can see that I'm pushing the margins. Even if the gates are faster, and my latch is nearly instantaneous... it *could* work, but it also might not. My glue logic typically isn't so deep, but the '816 has special Bank $00 requirements, and at the same time I'm wanting to optimize the use of other banks. It's not exactly easy!



Yes. So, at 3.14 MHz, using this "double duty Apple II" style of graphics, you have 8 bits of color data every 8 pixels across. That perfectly matches the 640 pixels wide with monochrome. OR I could do 320 pixels wide, but double the color depth to 4 colors. OR I could do 160 pixels wide and get 16 colors. I guess I could also get 80 pixels wide and 256 colors, but that's nearly useless.

If you double the speed to 6.29 MHz, you get 640 across with 4 colors, 320 across with 16 colors, and 160 across with 256 colors. The only way to alter these are to add more RAM chips for more bits per cycle. And, like I mentioned in a previous post, the refresh rate of this particular design is always the same, regardless of color depth. The faster the CPU, the more data you can change. But the faster the CPU, the more video memory you have available. It's a 1:1 ratio.

I chose to go with the 640x240 mono and 160x240 16-colors for various reasons. 80 column text is SO nice when programming, checking mem dumps, or whatever. I won't design a machine without that now! The 16-color mode was mainly for the 'wow' factor, and video games don't need to have super high resolution. Say you play Breakout or Tetris, no need for great resolutions. You can change the modes with a single line from the VIA. Also, now that I'm only using 32KB of video memory, when this board is in emulation mode (or has a 6502 drop in replacement) it will have the ability to display pixels on the whole screen. The previous 6.29 MHz model would only allow half of the screen to be drawn in emulation mode.

Because I'm not wanting to spend money on something that *could* marginally work, I'm totally ok with the slower speed. If/when I switch to CPLD one day, THEN I'll crank up the speed.

Thanks!

Chad