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

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

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.