I am day-dreaming about a new 16 bit system (65C816) with VGA graphics.

I like the approach of the video hardware jumping directly to video RAM during the high phase (or is it low...can't remember) of the CLK. That way, the CPU can blit as fast as it possibly can.

So, I'm trying to brainstorm how many pins would be needed for such a system.
Here is what I have so far:



OK, the two variables are Address bus and VGA output. Assuming a stock 640x480 VGA screen with one byte per pixel, we're at 300 KiB. So that's at least 19 pins for 512K.

Now, assuming 512 possible colors, that's 9 pins for VGA out.

That brings me to 41 pins. Ironically, the same number of pins my TinyFPGA board has free.

Am I missing anything?

I've never designed an '816 (or any 16 bit) system before. I know the '816 multiplexes the data bus for 24 bit addresses. So how would that come into play?

The intent would be that the VGA "controller" would be completely independent of the CPU. And that the CPU would simply read/write to some RAM location for video.

Thanks for any pointers.

_________________
Cat; the other white meat.

VGA requires 1 or 2 sync signals, is that included in your 9 pins?

My SBC-3 generated a 320x200 composite display using the low phase of the clock. 320x200x8bits per pixel = 64000 bytes, or 1 bank of 65816 memory. I worked quite well. Remember, the more screen size you have, the more time that is needed to keep it updated. I was able to use 2 banks and had a vertical interrupt that would allow me to switch banks during blanking for a flicker free page update.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Yes, that was including the sync signals (so 11 pins for video out).



If I could, I would have the FPGA do most of the heavy lifting. Maybe a simple blitter or some way of making windowing easier.

I'm thinking more along the lines of a "Mac Plus inspired" computer (with color). And, it's really day-dreaming at the moment.

_________________
Cat; the other white meat.

Yeah, mine was more Apple 2 in functionality. It didn't even have sprites. Good luck with your idea... I'll follow with interest in your effort.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Thanks.

Of course, I believe in baby steps. My first baby step was to design a working computer and I did that last year.
My next step is going to take a "simple" FPGA board and drop it into my 8-bit computer and design video there.

Both of the TinyFPGA boards I have are breadboard friendly. So between the two, I have 41 + 18 I/O pins. Surely I can make something happen with that. LOL

_________________
Cat; the other white meat.

I went through some thoughts on video for my current 6502 (and "in the works" '816) system - one was simply the time it will take to clear the screen, so double the size, quadruple the memory - and time taken for cpu operations )-:

640 x 480 x 8bpp is 307200 bytes, or 5 x 64K pages in an 816 system. If you can write memory at 7 clock cycles per byte then you'll need 2150400 cycles or 0.15 seconds just to clear the screen.

Then there's scrolling... Which can be done in hardware by changing the base address and making sure the video generator wraps at the right location, but if you have to do it in software then look on the bright side - you get free smooth, but slow scrolling

And at this point it starts to get somewhat messy in a small system - it's all do-able, but from a practical point of view - somewhat sub-optimal.

So a "blitter" or hardware (2D) block-move then becomes almost essential and if you give the video generator access to off-screen RAM too, then you can start to do things like blit sprites onto the screen, or tiled backgrounds (or even characters from a font) and the days of poking pixels seem long gone by then...

640x480x8 isn't totally out of the question though - it's the resolution of the Foenix system - a 65816 board with some FPGAs to help with the video (and other stuff) and their progress so-far seems encouraging.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I would go for 640*400 resolution. This gives a greater efficiency regarding the number of video ram address bits. Also for a 8bpp you would need to read the RAM at 25MHz. For perfect interleave you would need a 25MHz CPU which does not exist. So I'd rather lower the depth to 4 bits per pixel. With that 128kbyte of RAM and a 12.5MHz clock is all you need.

With regards to the number of a CPLD this would then give



A total of 63 Pins. And of course some additional bits to decode additional addresses like ROM, more RAM and IO. Should be doable with a ATF1508.

Peter