After reading through the forum archive, I had reason to re-evaluate several assumptions. This has led to a synthesis of ideas which are new to me but might be well known or infeasible. One of these concerns video display on vintage computer systems.

A quick analysis of vintage home computers from 1979-1982 finds that the most popular systems used 6502 or Z80. While other micro-processors, such as RCA1802, TMS9900 and MC6809 were arguably more pleasant to program, such systems were a rounding error. Even among 6502 systems, many were a rounding error compared to Commodore's vertical integration.

It is also apparent that there were two popular configurations. Specifically, 6502 with 6845 derivative or Commodore custom chip working on alternate bus phases. The other configuration was Z80 with software interrupt to populate a shift register. This was a common feature of early Sinclair designs (ZX80, ZX81, ZX Spectrum) and Galaksija.

I previously assumed that Z80 was significantly more powerful ansd that it was possible to blow 80% of this power on software refresh and thereby achieve the cheaper configuration. However, it is easy to dispute this assumption. Although 6502 and Z80 are not directly comparable, 2MHz 6502 preferable as a bytecode interpreter and 4MHz Z80 preferable to perform single precision floating point. However, this does not explain the cheapest video configuration.

Perhaps Z80 is preferable for 15.6kHz interrupt due to the steady timing of the four phase clock? Well, that is complete bunkum.

Perhaps Z80 has an advantage with 16 bit index registers? I presume yes. This is demonstrated clearly with reference to mvk's Gigatron (which I note uses a suspiciously Sinclair style logo while being loosely based upon 6502 and this may be pertinent to my consideration). A Gigatron approximates 640*480 pixel VGA with 160*120 bytes of memory. This is arranged in 32KB RAM such that the bottom 2KB is contiguous and the remaining 120 pages have a 160:96 byte split for display and variables. Historically, this would have been a more forgiving 40 bytes or 80 bytes per line of screen. However, this would lead to an arrangement of 3 or 6 lines of screen per page and a mere sliver of 16 bytes unused. It would also be possible to overscan with up to 51 bytes per line. However, this creates problems elsewhere. For example, line or character drawing must handle 3, 5 or 6 lines per page.

The worst problem is that software screen refresh with 8 bit counters is economically uncompetitive. A hypothetical 6502 with 320*240 monochrome bitmap display is unfavorable against ZX Spectrum with 320*256 block color bitmap display using the same contiguous amount RAM for bitmap and only requiring additional RAM for color. That is a problem. If we are unable to cross page boundary in a fixed unit of time, we get 6 lines of 320 pixels followed by 16 bytes doing nothing. Repeat this down the full display and the shortfall is 16 lines. Ignoring the smaller display and the additional difficulty of drawing on it, there is the difficulty of using 40 fragments of 16 bytes. This would be trivial with contemporary knowledge of memory allocation. However, this may not have been known (or implemented) in this era. As noted by GARTHWILSON, legacy equipment can be utilized more effectively with contemporary techniques. The fraught problem of memory allocation is one such technique.

I don't like this state of affairs. It is possible to coax a 6845 into rastering a bitmap of 20KB or more with the advantage of hardware scrolling. However, it is apparent that the big draw in this arrangement is a hardware counter exceeding 8 bits. This analysis may open unexplored opportunities. For example, 65816, with 16 bit index registers and block copy instructions may be ideal for software refresh. It can easily shift more than 50 million bits per second. Monochrome 1024*768 may be desirable. However, we are skipping ahead to 1983 and, even here, the first use of 65816 was in Apple IIgs, which was already supplied with dedicated video hardware. But what about 1982? A year so fine that some people are still living in it.

I don't like to say this, boys, girls, and other assortments, but our mortal sworn enemies, Federico Faggin's Fanboys, the Glitchy Zilches of Zilog, [mild insults with dubious rhyme and meter continue unabated for several pages] with three 16 bit registers might beat 6502. If we count
abuse of 16 bit stack pointer, as was typical on 6800 and 6809, that's another - Hey! Stop waving those ridiculous EXX and EX DE,HL opcodes around like cheap, two barrel revolvers! Someone might get shot in the little-endian!

Thankfully, we have a secret weapon. A denizen so devious, you could put a doctorate on him and call him Dr Jefyll and who is - perhaps - the incumbent Chair of Cunning at Cunningham College. When Dr Jefyll suggested rastering and blitting by using three latches in a ring and finding a timeslice for 6502, the suggestion passed with little more than a murmur, for this is a mere routine suggestion and one of many. Irrespectively, even if you invoke Dr Jefyll in the mythical, the hypothetical or the chimerical, I implore you to consider a mantra, an abbreviation and a way of life:

WWDJD? - What Would Dr Jefyll Do?

I have considered the problem in detail despite not having the expertise to implement it. However, there is one thing which is very obvious to me. We only require an incrementing counter which increments as fast as possible. Well, 6502 ships with a perfectly good one. We merely have to apply it in a suitable manner. So, WWDJD with a mere program counter and a lazy afternoon? I am not entirely sure what would emerge from Loughton Laboratories but it wouldn't be the craziest thing soldered together by members of this forum. Actually, it probably wouldn't be the third craziest video circuit.

Anyhow, some tidbits and morsels for your consideration:

1. A latch of arbitrary size may be used to set the upper bits of raster display. This can be used to implement double buffering, triple buffering and - for fans of Commodore's Amiga - vertical split screen.
2. A region of memory returns dummy opcodes while the lower address lines simultaneously select data for a latch or shift register. Access to the dummy opcode region may automatically set porch or a horizontal sychronization signal.
3. The dummy opcode region precedes ROM or RAM, where a processor slides into the end of a loop. With this arrangement, it is also possible vary display width. However, rastered data will occur at the end of a page.
4. Shift register dot clock may exceed 150MHz. However, this may require overclocking a micro-processor to 20MHz.
5. RRGGBBII or similar at 640*256p can be achieved with 65816 at 14MHz or thereabouts. In this configuration, display is 160KB.
6. There is no need for dual port RAM or lock out circuitry because a processor is always busy during rastering.
7. This arrangement only uses one bus phase. It is possible to implement a dual display, although this arrangement may only be useful if displays run at different resolutions and frequencies. Alternatively, DMA on unused phase may exceed display rate.
8. The selective dead cycle elimination of 65816 emulation/native mode might be useful for LORES/HIRES function. This requires suitable choice of dummy opcode.

It is possible to apply similar techniques to Z80 to obtain increased resolution. However, as is typical, 6502 matches or exceeds the performance of Z80 at half the clock speed. My work is done and order is restored to the universe.

Edit 1: Typographic errors.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Not been a lot of replies to this so Ill give it a go.

• I believe you are proposing to use the address but to clock out the frame buffer memory into a serializer for Composite display, like ZX80 et al, while feeding the data bus with dummy NOP instructions to keep the CPU happy.
• This means the CPU is only available during horizontal and vertical blanks for non display related stuff.

This sounds like a great idea. I don't know how the 816 offers over 6502 but you mention DMA. Note the 1802 had built in DMA and a very simply CRT interface chip which was basically a serializer, which you might be able to gain insight from (ignore the very low resolutions as it was a product of its time). This approach did mean that certain 3 byte instructions could not be used...
https://en.wikipedia.org/wiki/RCA_CDP1861

You might get more interest if you prototyped on a 6502 first, then moved to the 816. I think that the Acorn Atom (probably amongst others) access framebuffer memory during Phase 1 clock to, which probably means the framebuffer ram needs to be faster than regular ram.

I agree the "Program Counter And NOP Slide" is a great idea, but I didn't invent it. I learned it from Don Lancaster, in particular from The Cheap Video Cookbook.

It's true the CPU usage is 100% except during horizontal and vertical blanks, and in some situations that may be objectionable. On the plus side, it gets DMA-like performance without requiring a DMA chip, and that can be very compelling... especially if it's 1980 and Arduinos and Pis aren't available! The CPU address bus increments once every cycle, scanning through memory just as a DMA chip would do. I wrote about Cheap Video here.

I built three SBC's that use Cheap Video, and a Z-80 version of it found its way into the Timex Sinclair ZX81 and perhaps others.

ETA: as to the point about the admittedly high CPU usage, the ZX81 had a mode where it would switch off the display and free up the CPU entirely except when the machine was waiting for user input at the keyboard.

-- Jeff

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

Oh didn’t notice dr jefyls Kim clone also had video output! Nice.

Why do you need 2byte instruction and not NOP to clock address bus?

How does the opcode generator know when to stop counting and present RTS?

Any photos?

Cheers, Vincent

Ah, the KK Computer. Yes it has Cheap Video, and in fact it uses similar tricks to support some of its 6 new registers and 44 new instructions. BTW this actual working hardware, not just a proposal.

It was Lancaster who first exposed me to the idea of getting what you want by pulling the wool over the CPU's eyes and feeding it something other than the actual data read from memory.

The goal is for the address bus to increment on every clock cycle. NOP consumes 2 cycles but it's only 1 byte. So, a diet of all NOPs would mean the address bus would increment only on alternate clock cycles.

Lancaster's approach is to feed 5, 6 or 7 of the least-significant CPU address lines to a small ROM that's (mostly) filled with copies of the 2-byte, 2-cycle NOP-like instruction that's gonna be used (such as ORA# $00 or CMP# $C9). And the ROM is what the CPU sees during a scan. And if the goal is to have, say, 64 bytes per horizontal line then bytes 0 to 61 are filled with copies of the 2-byte "NOP." Next, byte 62 contains $20 (RTS), and byte 63's contents don't matter because it's fetched then discarded. So, the CPU does a JSR to an address to where video data is stored but instead it sees this goofy "subroutine" of a bunch of CMP# $C9 then a RTS. (Repetitions of this 64-byte pattern temporarily appear to fill a large portion of the memory space.) And that's how you output a single horizontal scan line. As the CPU fetches the illusory subroutine, the actual RAM data is simultaneously being fetched, and that's what gets serialized and output as video.

The ROM approach assumes your video data is organized so as to reside at addresses that result in the proper behavior on the LS address lines during a scan. And there's a bit of freedom to juggle things; for example it needn't always be 0 to 63. But KK sidesteps this fuss & bother entirely. Instead of a ROM, KK's fake instructions are generated by discrete logic. And instead of addresses, KK's "stop scanning now" cue is provided by a VIA timer that's freerunning at the horizontal rate. Whenever the timer reloads, the VIA outputs a transition on PB7, and that is what triggers the end of the scan by changing the CPU's diet from all $C9's to all $20's.

My first Cheap Video machine was my KIM-1, here. Later I attached two 6809's to a single memory array so they each got 50% of the memory cycles, and one of the 6809's was capable of Cheap Video. And the KK Computer is here (below). Close-up photos here.

-- Jeff

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

Interesting - I managed to find a copy of the Video cookbook actually on Don Lancaster's web page
https://www.tinaja.com/ebooks/cvcb1.pdf

Neat idea to use a PROM for the timing sync and ROM for the opcodes.

FYI, According to the excellent Grant Searl site, the Sinclair ZX80 (Timex ZX81 similar HW but with a ULA) instead uses an opcode generator where a hardwired NOP is forced onto the Data bus with a buffer, and it uses a HALT instruction to end the line. However this machine primarily shifted bits out of the ROM.

Also from Searle's site, The Jupiter Ace (An obscure body in the S-K System) did shift out of RAM so is more in keeping with what we are speaking of. As the OP commented, both these machines use Z80 CPU.

Definitely need to spend some time digesting the Video cookbook as I have never seen a direct video 6502 system before.

I think they're both Cheap Video. But it sounds as if one machine includes a Character Generator ROM, whose purpose is to translate ASCII characters fetched from RAM into the corresponding pixels which will be serialized for display. In contrast, the other machine sounds like a bit-mapped display, where RAM contains actual pixels ready for serialization, not ASCII symbols that needs to be interpreted.

BTW, Lancaster has several books dealing with homebrew video. Cheap Video Cookbook is perhaps the best single reference.

Also BTW, the MOS Technology KIM-1 was a very popular target for conversion to Cheap Video. And Character Generators were the norm, as most micros in those days didn't have enough RAM to support a bit-mapped display. (The KIM-1 came equipped with just one K of RAM!) The KK Computer was built in 1988; it has 256K of RAM, and the display is bitmapped.

-- Jeff

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

I guess you could also connect the VIA output to NMI with an appropriate handler and not need to carry the opcodes at all?

Hm, that sounds like it could be the basis for a workable system. But it wouldn't be Cheap Video, if I'm understanding you properly.

The advantage of Cheap Video is in omitting the Video Controller or DMA controller and instead letting it be the CPU which increments the address bus on every cycle. To get that behavior, the CPU data bus needs to be fetching 2-byte, 2-cycle instructions from somewhere[*] at the rate of one byte every cycle while at the same time and using the same addresses video data is being fetched from RAM at the rate of one byte every cycle. Here's an illustration from my article. If there's anything the article fails to explain adequately I'll be grateful if someone will please ask.
Nowadays we have much faster processors and memory, and it's possible to make a low-end video system that doesn't require one byte of video data to be fetched every cycle. The cycles happen at a much faster rate! But if you want high resolution and/or increased color depth, Cheap Video still bears consideration, and there's still no Video Controller or DMA controller required.

[*]Footnote: traditionally, a tiny ROM (or discrete logic) is the "somewhere" from which the dummy instructions originate. Aliasing causes the image to appear repeatedly in the address space, so a low capacity ROM will suffice, and that'll save money. But nowadays memory is drastically cheaper, and the builder may prefer to have an actual RAM or ROM full of dozens of K's of nothing but $C9 and the occasional $20.

-- Jeff

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

Sorry, my phone autocorrected something there, the word "carry" was wrong - i think it was meant to say "vary"!

What I meant was, it sounded like KK's system was using PB7 to change the value being pushed to the data bus from C9 to 60, but if you just connected PB7 straight to NMI instead then you could hardwire the forced data bus value to just C9 and let the NMI handler break the CPU out of that memory region to disengage this logic, instead of needing the data bus value to change. The NMI handler would probably then discard the top few stack entries and then RTS.

Oh! OK, thanks for the suggestion. I've thought about using an interrupt to begin each scan line, but never thought about using one to end the scan.

Tonight I'm not seeing much advantage, 'cause it's pretty easy to switch from forcing $C9's on the bus to forcing $20's (and also this method doesn't consume cycles pushing then discarding the top few stack entries). But tomorrow morning I might wake up with a different opinion. Sometimes the ol' synapses need some time to chug through all the churn!

-- Jeff

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

For some reason this is reminding me of a video system I designed for AVR years ago, in which the processor used (I think) sixteen cycles of program to output eight dots of video every microsecond - so a 48 character line across PAL spec. The annoying thing was the timing; on the AVR it is only accurate/consistent when coming out of sleep. So I actually ended up with software which spent *all* its time in an interrupt routine except for a few nanoseconds when it was asleep

I need to look at Jeff's approach further; I'm noodling an SVGA 800*600 design which conveniently runs at 5MHz for the processor and requires no cycle stealing, but the clock and sync generation takes a dozen counters and flip-flops - and I'm not sure if it will play nicely with a VIA or two. I do remember Mr Lancaster's cookbook but it was so long ago... I was already ripping off, er, building on prior research, the Microtan Tangerine video output back then.

Neil

OK, here's a thought: let's assume a stand alone system with 64k RAM (which can be got at somehow by an external processor doing real work), 64k EEPROM, a 65c02, and a couple of flipflops plus a 40MHz clock, a divide by eight, and sufficient logic to generate a blanking signal whenever the processor is addressing anything other than the video ram, and the latching/serialising.

I've assumed an 800 x 600 SVGA display (though I don't think I get all the bits, quite) with the video ram (total 60,000 = 0xea60) starting at 0x1000.

0x0000-0x0fff is visible as ram to the processor, otherwise it can see only rom; this first 4k and 0xf800-0xffff are considered blanking addresses. The line and field syncs set and reset a flip-flop each just by addressing it. The 6502 is basically being a 6845 or similar video controller, but without the ability to change anything in real time.



This doesn't *quite* meet the timing specs, and I think I lose the last byte of every line (hmm, could offset by 101 bytes perhaps?), and I still need to think about the field sync, but it has possibilities...

Neil

Glad to see some interest! Neil, I've only glanced at your post, as I have some traveling ahead to be with family this weekend. But here's one small point (and perhaps you already considered this). The snippet laid down by the vline macro could end with jmp hsync (rather than an rts). This'll help conserve cycles during the h-retrace, and that's important (or used to be). Things are easier now with faster processors.

The reason I've grown used to worrying about the h-retrace period is 'cause all my implementations (so far, at least) have used Self Modifying Code to update a single jsr scan instruction that's inside a loop, and the h-retrace is when the update occurs. You've taken a different approach and unrolled the loop. jsr line0 and jsr line1 etc etc are each separately coded, with the jump destinations precomputed. This sidesteps some complexity... at the cost of some memory. And memory is cheap. But even so, address space on the 'C02 is limited, and for that reason the SMC approach might bear consideration. (Not everyone enjoys writing SMC. But I relish the sport, and value the surprising amount that can be accomplished. )

-- Jeff

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

Jeff, it looks as if the memory space of the video ram is nearly almost exactly-ish the same as the memory space of the processor but as it will be doing nothing except running the scanning code anyway, it doesn't matter. My biggest concerns at the moment are (a) what happens at the end of a line (I like your jump idea) and (b) exactly where to put video ram within the 64kB to simplify addressing for the blanking and still maintain some stack space. I don't need five K on top of the line scan, so there is flexibility. Any code running outside of video ram addresses will automatically blank the video.

I'm going to think about less-enthusiastically sized test code to see if it works as expected on the (slower) Neolithic SBC.

I know I've commented on the aesthetics of circuit design elsewhere, but using the 65c02 as a video co-processor for a 65c02 tickles me somewhat.

Enjoy your time with the family!

Neil