6502.org

I'm away mess around with Z80 but recent discussions about cheap video and Chad's progress with serial VGA are quite interesting even though I've not understand the details of designs being discussed. Since W65C02 can run at 25.175MHz-VGA (in fact 36MHz-SVGA), my thought is running 6502 as fast as possible so it can do more work during vertical blanking period. 25MHz 6502 can do the work of 2MHz 6502 in the 86mS video blanking period.

Wonderful thing about CPLD is it can be modified easily to check out new design concepts, so I think I'll break out my overclock board again.
Bill

Edit, never mind using overclock board; I need to disconnect 6502's data line from RAM and hook them up to CPLD separately. overclock board is too fragile for major operation. I'll find another victim to operate on...

Ok had a little think about this and wondered if there is a variant. Apologies if you know this stuff already but writing it down helps me think.

The two forms in the cheap video cookbook both need cpu to execute dummy 2 byte instruction, where firstly the address bus clocks a character generator ROM eg2315 where the ROM address is driven by ram- one byte for each char, and the character ROM outputs are serialized at the dot clock frequency.
The other approach is the address bus clocks ram directly and the ram data bus is serialized. This uses more memory as a frame buffer is needed with a bit for each pixel.

Dr jefyl posted an interesting abuse of 65c02 unused opcodes, which are all safe on 65c02.
viewtopic.php?f=4&t=1945

I was wondering if, instead of a frame buffer and clocking data out of ram, the fast 5bit opcode output is instead serialized. Here the cpu is not fed a dummy opcode but actually executes the 5bit opcodes. There is an efficiency loss as instead of 8bits per memory byte we now only get 5, but this is enough for a 5x7 font at the least.

It is still cloudy to me but I think this approach results in simpler hardware. Make sense? Comments?

Not sure there. My approach uses lots of dummy two byte instructions (from a rom in parallel with most of the video ram) so the ram is addressed at the same address as the executing code. And as discussed earlier, it uses a *lot* of memory, for a bitmapped monochrome output - a touch under 60k.

In my context I want the freedom to be able to set/clear any pixel in the visible range, rather than be restricted to a tiny 5x7 font by the hardware.

Neil

Recently Chad posted much the same idea, and I salute you both for thinking of it.

I'm a little too sleepy ATM to fully consider the tradeoffs. One thing, Vince: be sure you do get a clear handle on the difference between a bit-mapped display and one that uses a Character Generator. If the 5 bits extracted from each opcode go directly to the shift reg then it's bitmapped.

But I kinda think if you want a 5x7 font then each character needs 6 pixels worth of width in order to provide a space between adjacent characters. So, would the hardware add that blank extra pixel of space? It's easily doable. Just a little weird, is all. Usually folks opt for bitmapping so they can achieve full freedom to turn on or off any pixel. (Neil mentions this in the preceding post.) But the extra pixel added by hardware would always be blank (off).

Speaking of 65C02 undefined opcodes, there's some startling potential there. Not that we're obliged to use that potential, but there's definitely scope for creativity. More on the subject here. -- Jeff

Yes you are right, I had confused the two. However on reflection I don’t think this approach would work with an external char gen ROM as The 5bit space does not give enough bits to drive a meaningful ASCII set.

But as you mention, a design time decision could be taken for alphanumeric or graphic framebuffer, both with external serializer. For alphanumeric the shift reg would shift out an extra blank separator bit for each 5bits as you mention, and the cpu cycle (not clock) would run at a 1/6 of the dot clock, or 1/5 for framebuffer.

But I think the real value of this approach is to run the cpu cycle at the dot clock speed, but now the abused op-codes drives a 5bit ADC to get 31 gray scales (inc black) plus blanking. A back of napkin calculation for a 60hz 52us active video scan line with a 20mhz 65c02 could display 260 horizontal pixels assuming 4cycle instruction.

I'm curious to try a simple 'cheap VGA' scheme where a pico captures full frames of screen RAM using a 1 cycle nop slide (or Lancaster's $a9 etc). The PicoVGA project supports various mappings of screen memory to the display (text, various graphics pages, presumably could even convert from apple 7bit craziness, etc) but would remain essentially a peripheral driven by the CPU.

But I'm new to the hardware side of things. What's a low chipcount way to toggle the CPU so a RAM read sees a fixed constant value on the bus rather than RAM contents? Is there such a thing as a bi-directional 2:1 bus selector? e.g. where a signal controls whether the CPU sees the actual databus or a constant input? or some kind of bus transceiver with a latched value I could set somehow? I already have signals for /ram, /io and /rom along with r/w, and running a simple 65c02 + VIA. My current setup is more or less this schematic.

Given that capability you could have a simple frame capture routine in ROM:

- stash the current frame start address on the IO page (since we won't be able to see RAM shortly). e.g. in VIA's T2 counter registers
- start a VIA T1 countdown based on the frame length + setup time in this routine
- enable a pico "start capture" signal on a VIA pin, which toggles RAM to be invisible to the CPU
- perform an indirect jump to the frame data to start the slide, i.e. JMP (frame_start)
- CPU increments through the frame data at one cycle per byte while the pico captures the databus
- the timer expires at the end of the frame and triggers a ROM-resident frame_end interrupt which re-enables RAM and resumes normal operations

An 80x24 text page would only cost 2K cycles / frame, and a CGA 320x200x16 color frame would cost 32K cycles which would still give a decent frame rate even though it fills half the addressable memory. It'd be easy to switch graphic layout dynamically or do double buffering by switching the frame start location.

I think my RAM IC is actually 128K so I guess I could cheat by just filling one bank of it with nops [ed: this won’t work since pico still needs to see original ram on the bus…] but I like the idea of sticking within the original memory footprint and using some hardware to force the memory scan if it's not too difficult.

Does this sound feasible?

If minimizing hardware is a goal, then instead of multiplexing the data bus for another processor to display the data, a simpler solution is running 6502 at video clock of 25.175mhz and fetch the video data itself. This also has the advantage of a fast 6502 that has more throughput to do other tasks when not busily displaying video data. I talked about that in “6502 as a VGA controller”. The last post showed the resulting hardware that’s quite simple.

viewtopic.php?f=4&t=6517&p=106962&hilit=Vga65#p106954

Bill