I think it depends upon what you're trying to do. Sending vector graphics commands (for GUI, 2D CAD, etc.) across something like SPI (or via a FIFO buffer or small dual port RAM) might be adequate.
For games using raster graphics, if there was sprite capability and a relatively static background (or good scrolling support), that same approach might still be viable.

Maybe a block of shared memory that either CPU can temporarily control, but that isn't the frame buffer? Just brainstorming.

Yes, that's what I meant—something like this:



The idea is that the MCU only intermediates the interaction between the CPU and an external bank of video RAM. It is not involved in generating the video signals at all. (The CPU can then have direct access to the RAM if it wants to… not sure how useful that would be, though).

In the beam racing implementation where the 25MHz 6502 has about 8% free time during vertical retrace which is equivalent to a 2MHz 6502, I'm thinking of implementing the ReGIS (Remote Graphic Instruction Set) so commands and small set of data can be set via serial port.
Bill

How would the MCU see the external/shared block of RAM? Most MCUs do not have an external memory bus - I can't think of any, but they may exist.

Not suggesting this is a good example, but my Ruby board originally used an ATmega to generate composite video. 320x240 monochrome.

Rubishy video here: https://www.youtube.com/watch?v=09zhGUbVxdU

It communicated to the 6502 via - well, let's just say a parallel interface. The 6502 sent it standard ASCII text which the ATmega printed to the screen, there were commands to move the cursor, clear the screen, plot points, lines, circles, triangles, and read points back from the screen.

The VDU codes I used are the exact same codes that the BBC Micro used. This was by design so I could run BBC Basic.

What let that down was the free cycles left over on the ATmega after the beam racing video generator. Not a lot. It averaged something like 70% of all CPU cycles were used to just maintain the display, so it wasn't fast at accepting commands and doing the video update. Yes, a faster MCU would have been much better, however with having a large amount of experience with ATmegas that's what I chose.

It used the 2nd SPI channel clocked at 8Mhz to output bytes back to back. you have a total of 64µS per line to include the front porch, backporch and hsync, so there were cycles left over with just 40 bytes of video data and a few more to make the timings up, so keeping the image to the left of centre gave you free cycles there, then at the end of the frame, you have all the free cycles during the vertical sync before it starts again. It was all done on a single 64µS interrupt.

What I then did was move the display over a serial line (still through the AVR which could now buffer the data very efficiently) to a "smart" terminal running on my Linux desktop. Same commands, but now I had up to 1280x1024 pixels and many colours (actually much more, but that's the limit of the Acorn MOS which was fine in 1981).

It is much faster - and can handle sprites (when I can be bothered to code them on the 65xx side) as well as sound.

Some examples:

https://www.youtube.com/watch?v=rPGCT0lah4Q

https://www.youtube.com/watch?v=ZL1VI8ezgYc

Right now it's a 115200 baud serial line from the 65xx (via the AVR) to the terminal. It's not that different in principle to the TMS9918, or the Commander x16 'VERA' chip or Gameduino, or the old Tek. 4014 terminal, or the BLIT windowing terminal (c1982).

It takes 6 bytes to plot a point, (VDU command, point command, X & Y as 16-bit numbers) Lines are drawn from the last point plotted (there is also a 'move' command, similar for circles. I can redefine characters by sending the code then 8 bytes of character data.

Moving to SPI or a parallel port through the VIA would make it much faster.

The terminal is actually the screen & keyboard handler from my BASIC interpreter - which is written in C and uses the SDL librarys. I just added in a handler for the Acorn MOS VDU commands. I could probably run the serial line faster, but I don't feel the need right now.

The next plan, if I continue with the Ruby '816 project is to use a parallel interface off the VIA to a "graphics card" which may be a Pi Zero running some bare-metal code, or an FPGA, or who knows what...

Cheers,

-Gordon

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

well i was about to propose the same idea but then re-read the thread to make sure it wasn't already mentioned... oh well, can't hurt to flesh out the idea a bit.

when the CPU wants to write to Video Memory it writes into both the Shadow RAM, and Video Circuit, which then latches the address and data to write to the actual Video RAM on the next available cycle.
now when the CPU wants to read from Video Memory it only reads from the Shadow RAM as the Video circuit has no read circuit and therefore stays off the bus.

the advantages being that the CPU and Video Clock can be seperate from eachother, you don't have to design a read circuit at all, and if the CPU clock is equal to or slower than the Video Clock and you space out your Video Circuit's Read Cycles you likely don't need any wait states at all.
disadvantages would be that your need 2 RAM ICs and that you need to spend a lot of IO pins and logic for the address bus input and latching.
though you can also bank the Video Memory on the CPU side, so instead of accessing all of it you only access a piece of it, which you specify in some internal register, saving a few pins.

I want to try this for my next SBC, if i can fit the logic and pins on an ATF1508. i would love to use an FPGA like a MachX02 as they are cheap and pretty large. but the chip shortage is relentless

also if i may add to the list:

#12 Literally Cheating:
you use a Serial Connection to a modern PC, on that PC is a program that hooks into the Serial Port and accepts commands (like drawing pixels, lines, filling shapes, etc) and then just does them inside a window on your Monitor.
alternatively if you actually want some Video Memory instead of real-time graphics command, you can have the program wait for the CPU to send a starting address for inside the Video Memory, how many bytes you want to access, and if it wants to read or write.
then after the set amount of bytes have be read/written it waits for the CPU to start the next transfer.
obviously it's not in the spirit of "retro", but it is an option! and honestly i kinda want to try it because it sounds like a fun programming challange.

I love it! Of course it's cheating, but it's still a way to output some video. And modern computers come in all shapes and sizes, and are all over the place too.

Good discussion, thanks!

Chad

I don't see this as cheating. I may be biased as thats exactly what I'm doing in my system, and I see it as no different to using some sort of external graphical processor like the TMS9918 or an FPGA... Sure, it's a modern PC rather than some old equivalent, but I could use a real BBC Micro (c1981) with nothing more than a 1-line program exchanging serial data to the screen/keyboard. It's no different to drawing lines on a Tek 4014 (c1972)? Or, as I was doing in the early 1980's doing cad/cam and 3D modelling on a Prime computer with a huge (for the time) colour graphical terminal at the end of a 9600 baud serial line.

So for me, cheat? no. Workable solution? Yes.

Retro? Well we did it this way 40+ years ago - is that retro enough?

-Gordon

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

You're quite right - another CPU doing the visuals is and has been a common tactic, and a reasonable thing to do. I recall laser printers used to have (and need to have) a more powerful CPU with more RAM than the user's computer.

Indeed. When Apple introduced the LaserWriter in 1985, it had a 68000 processor running much faster than those in the Macs of the time, in order to interpret the PostScript and control the print mechanism.

I don't know if I'd even call it cheating. That's not too different in concept from X Windows over the network, displaying an application on your computer/terminal that's running elsewhere. If that's not retro enough, you could construct something like a 1982 Bell Labs Blit terminal or a 1970's Tektronix graphics terminal instead of just drawing on your PC's screen.

Guys, what is the topic's title? Accessing video RAM. Sure you are "accessing the video RAM" of some other computer, that's fine. I'm not against that method. But, I will still call it 'cheating' for the purposes of this particular discussion. It's good to discuss it, but my original intention was to find ways for the CPU to write to some type of shared RAM.

If you want to keep discussing this style/method, by all means keep going! I'm learning I think interfacing some type of terminal is really cool and a good idea.

Just backing up my words I guess.

Chad

Back to the more integrated approach, what if you have a FIFO in between a CPU and a graphics (co)processor? Looking on Mouser, I saw 5V hardware FIFO's in the 256B to 2048B range for about ten dollars, that allow simultaneous reading and writing. Or The CPU can write drawing commands or raster data to the FIFO whenever it wants, and the graphics processor can read from the FIFO whenever it isn't prevented by video refresh needs.

Yes, and the read clock and the write clock don't need to be synchronized in any way.

A FIFO is a Dual Port RAM... that doesn't require any address lines!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

So... I had a brief moment this morning while I was waiting for a client to tell HOW something didn't work rather than just saying it's broken and urgent; and I may have gotten a bit carried away with (2) the frame buffer thing.



I'm fully committed to frame buffer style video so this was also a bit of learning for myself as I haven't gotten around to laying out framebuffer access yet. Hopefully you'll find it helpful, or at least if there are bugs they'll be spotted.

Diving straight in there are two 1KB chips that form the framebuffer. They're swapped each time V492 ticks and are selected by the flip-flop in the bottom right. When FRAME_BUFFER_0 is high then output from 'Frame Buffer 0' is fed to the shift register by the line driver. When FRAME_BUFFER_1 is high then 'Frame Buffer 1' is fed to the shift regisiter.

This is all in theory, the simulation of the 6502 is not accurate (I really only use the 65816) and the screen size is WAY to big for Logisim to simulate in reasonable time.

The six multiplexers allow either the address from the 6502 or the counter's address to be sent through to the 1K video memory. The bus transceivers keep the data that's being output to the shift register off the 6502's data line and also allow data to be written into video memory.

I've also randomly mapped some ROM in but in reality it won't work at 12MHz. The clock speed either needs to be halved again or the clock needs to be stretched when doing reads from ROM.

I think that's about it. Still seems pretty complicated for getting video out but I like it and it doesn't involve a microcontroller. Again, hope this helps!

[EDIT - I forgot to mention. I mostly use LVC chips and they won't play nicely with HC chips so if you do think of using this you'll need to swap them out for their HC equivalents]