what if you could do some manipulation of the character ROM section of memory to do fully bitmapped graphics?
Sadly, I've gotten this idea stuck in my head and I've been hashing out on a piece of paper how you might do it. An "80-Graphix" character generator that gives you 128 programmable graphics symbols would be pretty straightforward, although it would require both a board piggybacked into the character ROM socket with a 20-ish pin cable running to it from the internal expansion connector. But what I've been *really* been pondering beyond that is a way to give you the option of a full 320x200 bitmap. (For the purpose of brainstorming I'm ignoring the fact that 80 column PETs exist for the time being.)
Basically you get 10 useful address lines from the ROM socket. A3-A9 are generated by the data byte coming from VRAM, while A0-A2 are generated by the row counter. (A10 is the line that selects GRAPHICS or BUSINESS character sets and is controlled via an I/O port so it's not very useful. You'll notice we're missing 1 bit from the data byte as well. The top bit controls an inverter, making the top 128 characters appear as reverse-video copies of the bottom 128 that actually exist in the ROM.) For the 8000 bytes needed for 320x200 we'll need three more address lines. My thought is you could tap them from the top 3 address lines in one of the VRAM sockets. The simplest implementation then would essentially be the same as a "Character Generator" video system, but the screen would be broken into 8 zones which each used its own character set. (To treat it like a full-screen frame buffer you'd fill each block of 128 memory positions with the value 0 through 127 so the "data" provides the addressing. Confusing, eh?)
The thing I don't like about that is that ROM-centric addressing system is laid out so the 8 lines of 8 bits that make up a character are stored sequentially. This is fine for character graphics but it makes for a very non-linear framebuffer. (You'd have 1000 "cells" to deal with, which means when drawing lines you'll have to do some odd calculations when a line crosses between cells. It's certainly doable... I think that's how the TI 9918 video generator essentially worked when it was in "graphics mode", but it's weird.) Because of the way the addresses are generated I'm not sure there's a great way to fix that, and I guess it's not a huge deal.
The problem with this brute-force implementation of either the 128 character or the "full bitmap" version is that when it's switched on you'll lose normal characters unless you program them into the CHAR-RAM first. (And for every graphics character you'll lose a regular one.) For the 128 character version a thought I had was to put a probe on that "invert" line and use it as a chip select to chose whether a charact0er fetches from ROM or CHAR-RAM. You'd lose reverse-video characters (and all your graphics characters would be "backwards", but that's not a huge problem) but it makes it relatively easy to mix text and graphics. You could do the same thing with the "full-bitmap" version, for that matter, (in which case you'd fill only the parts of VRAM you want graphics on with the appropriate 128-255 value) but the other alternative I pondered would be to grab all 10 address lines from a VRAM socket and combine them with the 3 row addresses (A0-A2 from the charrom socket) and get your 13 address lines that way. In this scenario you'd ignore the values stored in the "main" VRAM... except for one thing. You could decide which *single character* you're willing to sacrifice (out of the 128), and put a 7 bit decoder on the board that works as the RAM/ROM select. (For instance, if you're willing to lose the "@" character just look to see if the data byte coming in on ROM socket A3-A9 is all zeros, and if it is enable CHAR-RAM to output to the shift register instead of the character ROM.)
Of course to write to the CHAR-RAM in either version you'll need 10-13 address lines, 8 data lines, chip select(s), and R/W signals. All of those are available on the internal expansion connector so you could run a shielded ribbon cable from that to the piggyback board in the character ROM socket. (Which also has pins in a VRAM socket, and potentially a clip or two to legs on other ICs.) Mapping the board at 0x9000 through 0xAFFF is the logical choice for the 8k version. (It would come with the bonus that when you're not using the board for graphics you could load extension ROM images into it.)
Unfortunately, when I think about this the chip count is intimidating, particularly for the full-fledged version. I imagine you'd need some MUX-es on the RAM address lines (like the 74157s in the original's video logic), and for 13 lines you'll need four. You might also want some '244 buffers on the data lines, maybe another buffer on the output side, a small handful of gates, plus a RAM chip and a socket for the character ROM. That's turning into a pretty big daughterboard.
Bleah. Probably best to forget it.
). So you are right that diagnostic RAM had better be in low RAM.