6502.org

Can I return briefly to the cheap video theme? The traditional approach is to read one horizontal scan line (eg: 80 characters) with each DMA-like burst. But if the burst is not immediately converted to video then timing becomes simpler and you could read the entire 80 x 24 frame buffer in a single cheap-DMA burst (with 25-30 bursts per second).

You have various options regarding what to do with the bursts. For example they could go to a dual-port ram or a FIFO. But if the destination were a shift register, then what you have is the core of a high-bandwidth SPI interface! And of course SPI can be fed to all sorts of devices -- not just video controllers...

(BTW, if interrupt latency is a concern, it would be easy enough to arrange for the bursts to prematurely terminate. Also, cheap-DMA needn't be limited to reads -- it could also do bursts of writes to memory.)
Fascinating stuff, Peter! Can you provide more information about your '816 system? In particular I'd be curious to see a block diagram of the video system.

cheers,
Jeff

Sorry I'm joining this discussion a little late...

For an 80x25 monochrome text display you could use a schematic that's similar to the Commodore 8032 (and many others, probably): use 2K RAM with the address bus multiplexed between a CRT controller (or some self-made hardware) and the 6502 address bus, controlled by Phi2. The 2K RAM can be configured as even/odd addresses so the CRT controller can get two bytes per clock pulse but the 6502 accesses one byte at a time. When the 6502 runs at 1MHz, characters on the video display are generated at a 2MHz rate, which is more than enough for a black and white monitor at PAL or NTSC frequencies (64 microseconds per line, including sync/blanking).

Or you could use a Parallax Propeller to generate VGA or PAL/NTSC video (in color if you wish) like I do in my Propeddle project: just connect the data bus and a partially decoded address bus and the Phi2 and R/W pins to the Propeller, and run a cog that detects when the 6502 wants to read or write to the designated memory area. Another cog which can be completely asynchronous, generates the video. There is already lots of code to generate video in many different ways, you would only have to write the code to detect 6502 read/write cycles and retrieve or store data to the hub. I'd be happy to help.

===Jac

EDIT/PS if you run your 6502 at a high frequency (e.g. 14MHz) the first suggestion won't work, but the second one still can: The Propeller runs at 80MHz and should be fast enough to detect the read/write cycles at high speeds, although it may be necessary to pull the RDY line low on the 6502 for a short time (on the order of a microsecond or less) for each access to video memory, to make it possible for the Propeller to finish its job.

With dual-port SRAM, why not?

I was talking about doing it with simple, single-port SRAM and some hardware to multiplex the address bus of the RAM between the 6502 and the video hardware using the clock as source. I'm sure you know this is an often used trick in early 6502 systems because you can easily synchronize the video hardware with the 6502 clock. I suppose you could divide the clock by n if you're running the system at n MHz but the required synchronization between video and 6502 clock makes it hard to vary the 6502 clock speed.

===Jac

Another option might be to interface to a standard PC style VGA card. An interface could be built using a few latches and a small state machine.

It's getting really interesting. Thanks a lot for those inputs. I have read a lot about Propeller but never found the time to dig into this subject. I'm really tempted (but my government will kill me if I spend more time in my tinker room). I will first try the Dual-Port SRAM solution. A ISA VGA Card is a very good hint. The ISA bus is a very simple bus, and this solution has the advantage that it comes with all the chips already soldered and a CLUT is included. I'm currently bidding for one on the Bay.

@Jeff: you have to be patient. I have to go through my old (paper and handwritten) documents.

Hi,

I took the Dual-Port RAM approach, see the attached schema. The SBC (at the moment another AVR MCU but when finished my 65C816 System will be connected to it) is connected to the right side interface of the Dual-Port RAM (not connected pins of the IDT7134). The 74LS04 is not the best choice as the output is not capable of driving the RGB lines sufficient to produce a bright white. I think a 74ACT04 would do a better job. But I had none in my tinker box.

The controller produces only simple text, B/W with no attributes. The Pixelclock is fixed 25MHz. IT can generate a 640x480@60Hz or a 640x400@70Hz (with small changes to the code 640x350@70Hz should work as well, but I have no need for that). It supports 80x24, 40x24 80x25, 40x25 characters.

Arbitration must be done by "hand". But the impact on picture quality during scroll is not visible. Only during fast consecutive rewrites you can see some minor flicker. I can certainly live with it.

Peter

I like it! -- especially the fact that all the tricky video timing is of no concern to the host computer. And the host computer suffers no loss of bandwidth nor any other interference with its operation.
Adding some pullup resistors might be a good temporary (or permanent) way to produce a brighter white. As for arbitration, can you elaborate? I seem to be missing something ... unless you're referring to the lack of arbitration (and thus the slight flicker resulting from occasional collisions between the addresses fed to the two ports of the RAM).

cheers
Jeff

Hi Jeff,

yes it is the occasional collision of addresses that requires some sort of arbitration. This happens when the SBC writes to the same address as the Video is reading. If Video looses arbitration the display flickers and if the SBC looses arbitration it can happen that the byte written is wrong. So you need to deal with it because of the second case.

I like it as well because of the same reason you do. No timing conflicts.

Pull-ups have a bad draw-back as VGA requires that the signal level is 0V at the porch. Low-Level will be at least 0.1V with pull-ups on a LS-TTL gate. I think LS is just the wrong type. ACT is the correct one. At high-level it sources up to -24mA and output is still at 4V and low-Level is really 0V when you have no load (or only a resister network to ground).

Regards

Peter

OK, no doubt the second case would be a problem. But you said arbitration must be done by "hand", so can you explain that please.

BTW, if you added a bit of glue logic and maybe a bus transceiver to the video processor, both processors would then be able to read and write the dual-port RAM. Via the RAM, you could have two-way communication between the processors, and that opens some interesting possibilities... a shared-memory, multi-processor system! For starters, the video processor could manage attributes such as a cursor and blinking text... and who knows what else.

cheers
Jeff

Ok I will try to explain that a little bit further. DP-RAMs are in fact very tricky to use. So don't be to careless when using them.

Normally a Dual-Port RAM has an internal arbitration circuit. This circuit compares the addresses of the two ports. Whenever both sides access the DP-RAM (/CE=Low) and either side is doing a Write (/WE=Low) and the addresses are both the same, the circuit elects a winner based on first come first serve basis (the first side pulling /CE Low is the winner). If the writing side is the winner then the write is executed. The data read on the other side is not defined as the bits written are not all written at exactly the same time and hence the bits read can have either the previous, new or a transitory value. If the reader wins, the write is not executed until the reader releases it's port (/CE=High). Then for the data to be written successful the writer must extend it's /CE and /WE to be asserted by at least tacc (access-time) after the winning ports /CE has been de-asserted. Most DP-RAM provide a /BUSY signal that signals the loser that he has lost.

In our case, the Video Controller must not lose because of VGA signal timing constraints. So you cannot make use of /BUSY to signal the Video Controller to wait. If the Video Controller cannot make use of /BUSY, you must make sure a potential /BUSY would never have to be signaled to the Video Controller. So you need to do the arbitration by "hand", that is by dedicated external circuitry. If you do not pay attention to this, the data read by the Video Controller might be wrong (but on the next screen refresh chances are high that the correct data is read) so you might see some sort of flicker. If you don't care about the flicker you can ignore this.

However you cannot allow that data, written by the CPU, is not stored correctly. Here I took the lazy approach, I'm using a IDT7134. This device has no internal arbitration logic and writes are always executed, and simultaneous reads could return wrong values. I'm currently investigating in a circuit that delays and extends write access to times the video controller is not using the DP-RAM (i.e. /CEL is de-asserted). Such a circuitry would also allow to use a IDT7132 with arbitration logic or a IDT7007 (I have plans to use this one so I can create a 640*400 pixel bitmap graphics). Should be fairly easy using the outputs of the 74LS161A and the RDY input of a CMOS CPU.

For dual processor systems with shared-memory you need to provide a symmetric logic. This can be tricky. That's when /BUSY helps a lot, as it is only triggered if both addresses are the same. For multi-processor systems, there are also 4-port RAMs with full arbitration logic. But for shared memory designs, many DP-RAM provide semaphores in hardware. You better use these. Then you can avoid any additional synchronization circuit and implement a software access protocol. E.g. you can define data-structures logically protected by a semaphore to create a mutex. Mostly you will implement a control block queue and when you en-queue or de-queue a control block you lock the semaphore before manipulating the pointers and after the pointers are updated you can release the semaphore. Then you define a access protocol, that defines who "owns" a control block. One way is to say control blocks in the queue must not be accessed/modified. So before using it you need to de-queue the control block and you must update it before you en-queue it. With this logic you make sure that only one side is using a given address. And so you don't care about arbitration.

As for the video controller, there is not too much cpu power left in the MCU, so it is not a good idea to let the video controller do a lot processing on the video RAM, especially time critical tasks like character attributes. This you better do in hardware. You just use a second DP-RAM and a attribute register (you take something like a 74AC646 or 74AC652 which are bidirectional). Whenever you read the video RAM the attribute register is loaded with the value of the second DP-RAM and on writes you previously set the attribute register with the desired values. That's how granati implemented attributes. Attributes are then applied to video signal in hardware.

Here again I will take the lazy approach. I will do blinking for just 64 characters as in the Apple IIplus.

Are VRAM chips generally available for purchase? It seems that those would eliminate most of these issues.

Do you mean those RAM chips with the second read-only port that were once used in Graphics Adapters? They are very difficult to use. Those are dynamic RAMs with a multiplexed address bus. So your bus timing for a 6502 based system running at 10MHz will be very tight. I'm not even sure whether VRAM with such low access rates have ever been made.