Dear 6502 Community;
I am currently making/designing a 256K computer using the 6502, and I was wondering if there was a simple way to share the same (banked) memory with the CPU and the VGA card.

The VGA card has a pixel frequency of ~25MHz, and the 6502 will work on ~13Mhz/~6Mhz.
I was planning on alternating the use of shared memory, with each getting 20ns, 50 MHz, of memory's time.
I planned to add registers for the 6502, to alleviate timing problems, and buffers for the VGA because it's multiple fetch sequences.
The memory map for the 6502 will be 16k of system shared RAM, 32k of banked RAM, and then 16k of system ROM.
The VGA card will require 64k of banked RAM to work, and 6502 should be able to read from that memory too.
I have tested almost everything for the VGA, and the way I changed the ram data was by only accessing the memory during the blanking periods, but that is too slow for a 6502, ~30-40KHz at worst.
I hope that I was able to explain it,
Adrian Kelly.

Can you tell us a little more about these "registers" and "buffers" and how they work?

_________________
Curt J. Sampson - github.com/0cjs

Welcome, Adrian!

If you've got a rough block diagram, that would help me and maybe others. I think there's an advantage if the CPU only ever needs to write to the display memory for the VGA system to read.

I briefly flirted with a shared memory system when starting my SBC but gave up - mostly because I wanted an easy life, but one plan I had to completely eliminate the timing was to use dual-port RAM. The downside is that they're expensive.

But timing - that's the crux. Because the 6502 only needs half a cycle for the RAM, then the other half can be used for the video generator - which is great when we're talking about NTSC/PAL range video frequencies, but when you get higher, then as you're seeing, timing goes a bit critical.

The other thing that might put you off is the practicality of it - just how long to clear 64KB of RAM? Or to scroll it? The 65816's block move instructions run at 7 cycles a byte. then even drawing a line, at one byte per pixel, a full diagonal of 800 pixels will start to take a noticeable amount of time.

And then it's banked RAM too... It's a great sounding project (and do have a look at the Foenix project to see how she did it there), but I fear it's not going to be easy...

Cheers,

-Gordon

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

You can get something of a bandwidth win if you arrange RAM such that video can read 16 or 32 bits each time: video accesses are nicely sequential so the reads are predictable and all the data read is useful. The CPU continues to access the same RAM 8 bits wide as usual. I think Apple III did something like this.

Thank you [plural] for your replies!

The registers are going to be TI 74374 and the buffers are the TI 74244.
The registers' inputs are going to be connected to the CPU, and the outputs are going to be connected to the mem.
The registers will only set whenever the CPU is in the writing phase.
The registers will only output the set data to the memory when the 50Mhz clock is low.

The same applies when the CPU is requesting the Data from the memory, but the set and enable pins' inputs are reversed, and so is the I/O.

The VGA is going to use buffers because it would be faster than the CPU and there will be multiple fetch cycles, still faster than CPU.
The buffers' inputs will be connected to the VGA and the outputs are going to connect to the mem.
The buffers will only output when the 50MHz clock is high, and when the cycle number is proper.
The same applies when the VGA needs to retrieve the data from the memory, but the IO is reversed and the enable changes a little in the cycle side.
(I am not trying to be demeaning I am just trying my best to fully explain the circuit)
I have also read of the BusEnable pin on the 65c02 so I will check that out also.



Sorry, I don't have a rough diagram yet, will try to post it soon.
Also, I would like to give the user, me, full access to the memory because there is only one video mode that takes up the full 64k.

Once again thank you [plural] for your responses and I will soon get a diagram out there,
Sincerely,
Adrian.