As much as we all love the CoCo3, a lot of us would also love to have an updated version of the CoCo - A new 'CoCo4' that keeps the magic of what makes a CoCo a CoCo but expands upon it to give it new capabilities.
Here's my vision of what this CoCo4 could be. I know the chances of one being made are very small, but I can dream can't I? I've tried to keep the ideas from getting too wild or too difficult to put into hardware. The omission of all sorts of gadgets is deliberate. If we added too much junk onto our CoCo4, it would be impossible for us to build and it wouldn't really be a CoCo in spirit anymore. This idea is still a dramatic leap forward - at least, I think so.
The Main board includes:
You might start thinking I am crazy at this point - no CPU, no video, keep the damned bitbanger port but add hardware handshaking lines to it?!? All will be explained. I'm trying to keep things minimal and also compatible with the CoCo3. Yes, there ARE big enhancements here somewhere and it'll be explained.
The four internal card slots are where things start getting interesting. Each slot has a bus clock of 4Mhz and a data path 16 bits wide. You get 4Mhz from dividing the 16Mhz memory access rate by four - each slot is clocked 1/4 out of phase from each other and is able to access memory independently at a rate of 4Mhz without conflicting with each other.
Since there is a buffer added between the memory bus and the image generator, we can use a variable (not synced with the bus) clock generator for the video. This would allow the card to generate almost any resolution/frequency you want - so long as the video circuitry doesn't unload all the data stored in the buffer to the screen before new data can be re-loaded off the 4Mhz bus.
At NTSC (60hz TV or CM-8) sync frequencies, it could do UP TO:
465 X 240 in 256 colors (non interlaced)
465 X 480 in 256 colors (interlaced)
930 X 240 in 16 colors (non interlaced)
930 x 480 in 16 colors (interlaced)
With a multisync monitor, it could do up to:
256 x 480 in 256 colors (non interlaced)
320 x 400 in 256 colors (non interlaced)
512 x 240 in 256 colors (non interlaced)
512 x 480 in 16 colors (non interlaced)
640 x 400 in 16 colors (non interlaced)
800 x 600 in 4 colors (non interlaced)
1024 x 480 in 4 colors (non interlaced)
1024 x 864 in 2 colors (non interlaced)
I know it's not up to modern standards, but it's still a dramatic improvement. 256 colors in high resolutions would be nice, but it just can't be squeezed out of a 4Mhz 16 bit wide bus. Getting higher resolutions/more colors would either require too many compromises elsewhere, or throw too many problems into this design idea.
One cool thing to add before I skip to the next part - The video generator does NOT have to be register compatible with the GIME/CoCo3 graphics modes. It can have it's own set of registers for controlling resolution,sync frequencies, video addressing and colors. This would simplify design a LOT, and I'll explain how it would STILL be CoCo3 compatible later on.
The reason the MMU and timer interrupt generator are on the card rather than the motherboard is because this way, each CPU has control over it's own memory and interrupts. Each CPU? That's right, We could use 3 of them! With each CPU running independently at 4Mhz, it would give us over SIX TIMES more processor power than a 6309 CoCo3.
-A game could use one CPU for music and sound effects, one CPU for all the graphics, and the main CPU wouldn't have to waste time on these things and concentrate on the game itself.
-A communications program could devote one CPU to running the RS232, another CPU for driving the screen, leaving the main CPU to run the program itself.
-In OS-9, one CPU could drive the screen or disk I/O while another CPU does serial communications or whatever. Apart from the main CPU running twice as fast as before, it wouldn't get slowed down by putting text on the screen or have to worry about I/O. Even a HALT disk controller wouldn't slow things down or cause lost serial I/O if it halted only the CPU that was driving disk I/O.
You get the idea. Although I didn't include a sound chip, full RS232 hardware, a math co-processor, a graphics co-processor or anything else fancy, the fact that we have three all-purpose CPUs online allows us to have all these things and more. A 4Mhz CPU IS fast enough to emulate a GOOD RS232 using the bitbanger port at 38400 baud or an 8 voice sound chip using the DACs...etc...if it were devoted to the task.
Compatibility (CoCo 3 Mode):
The main processor can be set to run at 1 or 2Mhz to keep running speed similar to a CoCo 3, or it could be set to 4Mhz to run old programs faster. Everything this CPU does is exactly the same as on a CoCo3 so there's no problem there. But since the hardware (like graphics settings for instance) isn't used the same way anymore, what happens? Well, the CPU will just think it's setting a CoCo3 graphics mode and write to RAM (or possibly the FF00-FFFF area could be rigged up as a bi-directional port where one CPU only reads what the other wrote there and not what it itself wrote there & vice versa).
One of the other CPUs (CoCo3 software knows nothing about them so it won't know how to use them anyway) can continuously monitor the 'CoCo 3' hardware register locations and translate them into equivalent 'Coco 4' equivalents for the new hardware on the fly. This will add a bit of a delay between when the first CPU set something and when that something actually went to the hardware but even a 150 cycle delay would make almost everything work perfectly - even my demos. There are some things that this can't be applied to like joysticks or the disk drive, but these things can retain direct compatibility. The really big issue here was that making a new graphics adapter with extended capabilities AND keeping it register compatible with the GIME would make it unneccesarily complex to design. This simple trick of using one of the extra processors to translate hardware usage would greatly simplify design. New CoCo4 software could simply address the new hardware directly, so a CPU would not have to be 'wasted' for this when running CoCo4 software.
Since the CoCo cartridge port is retained, we would still be able to use our old disk controllers, multi-paks, RS-232 paks and even cartridge games.
Technical quibbles that need to be ironed out:
-With the RAM clocked at 16Mhz and the 3 CPUs running at 4Mhz, there is no problem of having the CPUs all use memory at the same time because they're clocked out of phase with each other. But there would be a problem if more than one CPU tried to access the 2Mhz hardware at the same time. There would have to be additional wait states imposed on any CPU that tried to access hardware while it was already being accessed by another CPU.
-There would need to be a way for each CPU to set it's own interrupt vectors. (We wouldn't want to have all the CPUs running the exact same interrupt routine each time an interrupt happened...) Maybe the IRQ,FIRQ and NMI vectors could be stored on each CPU card as a few bytes of static RAM that can be altered by the CPU. RESET would stay constant to make booting up possible.
-Although all 3 CPUs jump to the same ROM routine on RESET or powerup, they could then go their seperate ways with conditional branching. It could be done by having one particular address always return an I.D. number (1 to 3) when read by each CPU.
-Each CPU can decide what triggers an interrupt and what doesn't by having all the different sources supplied on the CPU card connector. The GIME compatible interrupt select hardware on the card could then be set to let specific interrupts through to the CPU while masking others.
-I'm not all too sure how this could be accomplished, but it would be nice for the cartridge halt line to only halt a specified CPU. The cartridge would then have access to that CPU's bus without affecting the other CPUs. That way the disk drive would still work, yet not necessarily have to halt all three CPUs. (Imagine uninterrupted serial communications, sound effects or animated graphics WHILE the drive is loading or saving data!)
I decided to have the full 16 bits of the data bus available to all 4 slots in the event that we might want to plug in a 16 bit CPU instead of a 63C09. It also opens the possibility of making a 6309 card that runs at 8Mhz (If we use the 4Mhz 16 bit data path effectively, it pretty much gives us 8Mhz throughput with 8 bit data if we cache it).
The graphics capabilities could also be upgraded with the change of a card. Heck, if you got REALLY creative you could be able to rig up a card that transfered the contents of the CoCo4's video memory (at 8Mbytes/sec) to seperate VRAM so that you could view SVGA resolutions without the the bus speed limitations getting in the way.