Video Interface in a (fast) 6502 System

[cbscpe]

I'm looking for ideas how to make a video interface for a 6502 system. So far I have only played around with two solutions. One is no video interface but just a UART to communicate with the 6502 system. The other is using interleaved access to the 6502 memory, i.e. in during low-phase of PHI2 the video controller reads the RAM and with the results creates the video interface. Now I have the situation that neither is feasible. For one reason I have only a serial port to send changes made to the video RAM section and on the other hand a serial interface is not working, as applications are allowed to write directly to the video RAM. Also the access time and the speed of the system do not allow that the video controller is stealing half of the bus-time. But I want to send all changes made to the video RAM via a small interface to an external video controller. Any idea is much appreciated.

Thanks

Peter

[White Flame]

One option, since it seems you can no longer interleave video & CPU access, is to stop the CPU and perform full-speed DMA to video memory. You can do that per line to keep buffers small, per frame, or per command set to have CPU-controlled dirty updates.

The Commodore 64 actually does this in addition to bus interleaving, since it needs to read an additional 40 bytes of character data every 8 lines beyond what the interleaved bandwidth allows.

[BigDumbDinosaur]

White Flame wrote:

One option, since it seems you can no longer interleave video & CPU access, is to stop the CPU and perform full-speed DMA to video memory. You can do that per line to keep buffers small, per frame, or per command set to have CPU-controlled dirty updates.

What would you recommend he use as a DMA controller?

[Dr Jefyll]

White Flame wrote:

One option [...] is to stop the CPU and perform full-speed DMA to video memory.

That'd work well. But it's possible the video memory might need to be dual-ported. And, as BDD notes, there's also the question of DMA hardware.

Decisions like this are all about tradeoffs. And there's an alternative scheme (with alternative tradeoffs) that in some cases will be a win.

If you're willing to tolerate temporarily cessation of normal CPU activity, then you should consider the so-called Cheap Video scheme made popular by Don Lancaster. This involves manipulating a CPU by disconnecting its data bus from RAM and sending it dummy op-codes -- essentially NOP's. In response the CPU produces an ascending sequence on its address bus, fulfilling a function like that of a DMA controller. Each burst corresponds to one horizontal scan line. There's no intermediate storage -- bytes fetched from RAM get fed in real time straight to an optional Character Generator ROM then to the shift register that outputs the video.

Although the system is highly unconventional, its complexity is quite manageable. That (and especially not needing a DMA controller) is what made the system so popular! For more detail please see the section, "Cheap Video and Lying To the Machine," here. That's not a complete treatment of the subject, however. If anyone's interested, I'll suggest a few different hardware approaches. With my own variations, I've used Cheap Video in three different SBC's!

-- Jeff

[nyef]

Another approach, if your CPU is fast enough, might be to hang a couple of resistors off of a port somewhere and bit-bang black-and-white NTSC video directly. I don't know if I've heard of this being done with a 6502, but it's definitely been done with an AVR. That said, getting the timing right on such a system is tricky, and getting useful work done while also having a working display is even trickier.

[Rob Finch]

Quote:

I'm looking for ideas how to make a video interface for a 6502 system.

What kind of video display would you like ? VGA ? HDMI ? NTSC ? Character graphics only or Hi-res color ? I would suggest not going with NTSC as this is an older standard, being phased out. VGA is considered an older standard these days, but maybe the easiest to build an interface for.
You could use the

Quote:

Cheap Video scheme made popular by Don Lancaster.

on the farside of dual-ported memory. This would require a second 6502 processor.

If the processor is fast enough (and the required resolution low enough) you could use something like a dual-port memory (eg CY7C132) as line buffer and use a horizontal sync interrupt to load the buffer.

One needs to know the bandwidth (MB/s) one can live with, both for the video display and for video support by the processor. With a 20MHz 6502 and using 1/2 cycle for the video, there's 20MB/s video memory bandwidth available with only a byte wide memory. Using a two-cycle 'NOP' transfer interrupt to a dual-port buffer would limit video to about 10MB/s. That's enough for about a 256x480x8bpp VGA display. However that would probably consume too much cpu time, especially if you’re trying to run a serial port at the same time. At lower resolutions it might be better to try and drive a character oriented display. Using 9x9 character bitmaps and a 160x100 character screen, chunky graphics of 480x300 are possible.
The C64 drove an 320x200x1bpp display at 1MHz, so one would expect to be able to drive at best about 20x the display with a 20MHz 6502.

[cbscpe]

Thank you very much for your valuable input. What I really need is a text only 80x24 character video buffer. So I think the idea using "DMA" with CPU Cycle stealing will be the path I will investigate. The output should be VGA (the only standard I have found that is reasonably easy to support and still readily available). So the Video Controller should translate between the Frame Buffer and VGA as I want the video to use as little as possible of the memory bandwidth. I plan to read the 80x24 byte frame buffer only 25-30 times a second, that would require a memory bandwidth of 48k - 57kbytes/second. Yes I know, I would need an intermediate buffer, but I also need CGROM etc. I will see if this can be put all into a MCU with some external support logic (there is a project at http://www.mikrocontroller.net/topic/143445 that does the VGA face).

As for the "DMA", the link Jeff provided is really very interesting. I have already heard about lying to the CPU but this really nicely explains it. I once built a GTE65SC816 based system running at 3MHz in 1996 that used a different approach to create video addresses. The system was built using 3 cards with Vero-Wire, each 233*160mm large. A CPU Card, an IO card (SCSI, IDE and Floppy) and the Video Controller/Memory. This board uses a 27C1024 (64k*16bit EPROM) and two 74HCT574 latches for video address generation. I just programmed the EPROM so it sequentially runs through all addresses like a state machine. The state machine uses 38400 states to address the RAM. Other states have been reserved to generate the control signals for LM641542 B/W STN LCD. It supports 640X480pixel B/W graphics. But it uses interleaved video access (I had a hard time to get RAM that was fast enough then)

The nice side of this setup is that it does not require any CRTC chip setup. So I could combine this with a DP-RAM. I did not even think about that RAM type, thanks for the hint. That would be a easy solution, the IDT7132/4 are still available in PDIP-48 at reasonable prices. Perhaps I can get even hold of a IDT7007 so I could support a 640*400 bitmap.

Actually, wasn't there once a CRTC chip that required a DMA channel and had a 80-character line buffer so it only needed to read the line once per character line? I think it was used in 8080 or 8085 based systems.

[tobier]

cbscpe wrote:

I'm looking for ideas how to make a video interface for a 6502 system. [...] One is no video interface but just a UART to communicate with the 6502 system.[...]

I was thinking of using Grant Searle's Monitor/Keyboard interface, that uses two AVR on a separate board that communicates with the CPU using an UART serial interface. That way, you could make your main board have a serial interface that you can plug into a computer terminal, or hook up to a monitor with composite input.

If you don't want the keyboard interface, there are other options in the schematic for connecting the monitor interface directly, skipping the UART serial interface (I2C for example).

[granati]

Hello everyone,
here a possible solution:

http://65xx.unet.bz

(see the "Text-VGA Board")

The video memory is mapped into CPU address space so access is very fast, but it is synced with PHI2 (with some wait states inserted only during write cycles). The cpu clock and video refresh rate clock are unrelated and this allow a free choice for both.

[cbscpe]

granati wrote:

(see the "Text-VGA Board")

I have a question to the Dual-Port RAM. I see that you have built your own external arbitration logic. Wouldn't it be easier to just make sure that the CPU always writes twice to the same location, either in software or hardware and just forget about arbitration? If the CPU looses arbitration on the first write he will definitively win the second time as the CRTC only reads the same location every 16millisecond. If he wins the first arbitration of the IDT7132 everything is already settled and the second write will do no harm.

[granati]

cbscpe wrote:

I have a question to the Dual-Port RAM. I see that you have built your own external arbitration logic. Wouldn't it be easier to just make sure that the CPU always writes twice to the same location, either in software or hardware and just forget about arbitration? If the CPU looses arbitration on the first write he will definitively win the second time as the CRTC only reads the same location every 16millisecond. If he wins the first arbitration of the IDT7132 everything is already settled and the second write will do no harm.

Ofcourse the heuristic method of a double-write to the same location maybe can work fine. Anyway CRTC read the same location every about 32uS with VGA timing (with VGA font 8x16 read the same location for 16 scan lines every 32uS), so i decided to sync access when CPU write in video RAM for avoid any screen disturbance. In fact the implementation is not an "arbitration logic" but a simple way to stop CPU during a write cycle in video RAM, ensuring that write is made only when CCLK of CRTC is low.
Note that is not mandatory to use a dual-port RAM: with normal RAM the circuit will be more complex because need a mux for address and 2 latch, one for read and one for write, to interface data bus, and by this way the CPU will be stopped in all read/write cycle to video RAM.
Maybe my implementation seem a few complex, but the result is very good and VGA screen is in high quality, and have the advantage to use a standard VGA monitor.

[cbscpe]

Hi, yes you are right in case of Text its every 30usec. But still enough time for the 6502 to write twice or for hardware to do the same write in two consecutive cycles. I have some dual-port RAM here so I will definitively go for DP-RAM Video Card. I will try the heuristic method and look how it works. I can always add external arbitration/clock synchronisation.

One question, why did you not use the BUSY signal?

[granati]

cbscpe wrote:

One question, why did you not use the BUSY signal?

Hello, the "busy" is useless CRTC side because it fetch byte at consecutive addresses and CRTC cant be stopped ofcourse.
For understand better the motivation of this scheme, you will take care how work the internal arbitration logic into dual port RAM:

1) if both side READ at the same location at the same time the access is full granted at both sides.
2) if one side READ and one side WRITE at the same location at the same time the port that win gain full access, so can happen:
2a) Port A (suppose that in READ operation) win the access, so read actual byte with integrity. Port B (engaged in WRITE) lose access for a few time, so write the actual byte fail.
2b) Port B (engaged in WRITE operation) win access and write correcr actual byte. Port A (engaged in READ operation) can, in this situation, read old data byte, the new data byte, or some random combination of the old and new data byte.
3) both port WRITE at the same location at the same time: one port only win the access and write, the other port have inhibited access.

In CRTC application ofcourse only case 1) and 2) can happen. The 1) not give problem: CRTC and CPU have unimpeded access to RAM (and safe). Case 2) must be avoided for screen integrity. So if CPU win access while writing maybe CRTC read a random byte (with screen disturbance). If CRTC win access CPU fail writing data.
The busy signal cant be used safety for drive RDY signal of CPU because this can happen anywhere during PHI2 (RDY setup time required).

[cbscpe]

Hi, I understand, but have you some experience having no sync, i.e. let case 2b happen? How bad does the video signal go?

[granati]

cbscpe wrote:

Hi, I understand, but have you some experience having no sync, i.e. let case 2b happen? How bad does the video signal go?

especially during scrolling, when one whole line will be moved, some random disturbance appear. If is acceptable to have a screen with no very good quality the sync circuity can be omitted.
Anyway if you want manage cursor, colour, and some video attribute (like flashing, reverse, blinking) the most complex part is the video interface, not the sync ram access. If one want only simple text without attributes a single dual port ram 2Kbx8 is enought.
In my implementation all this logic was in GAL devices: video signal are synced with pixel clock for best performance, but this can be avoided for lesser quality.