The CoCo 4 - Some Ideas

Photo of a CoCo 4 We all know and love the CoCo3. It's a great little computer. Unfortunately, it has fallen behind modern computers. Some of it's drawbacks are actually positive, while some aren't. Personally, I'm a big fan of the 6809 and 6309 processors - I don't care if they're slow compared to modern CPUs, they're just so much more fun to program. We also aren't faced with 'modern' bloatware, where you need a liquid cooled 300Mhz 64bit processor and 64 Megs of RAM just to run a word processor above the speed of a crawl.

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:

-Four 8 bit SIMM sockets capable of handling 2 Megs of RAM or more.
-RAM clocked at 16Mhz, 16 bit wide data.
-One standard CoCo cartridge port.
-Keyboard connector (either regular CoCo type or PC AT type, it doesn't matter).
-Two CoCo joystick ports able to be read at 8 bit ADC resolution.
-Two 8 bit DAC audio outputs.
-64K of ROM, including the 32K CoCo3 ROM plus 32K 'CoCo4' ROM.
-One slightly enhanced bitbanger serial port (with extra lines for hardware handshaking with modems, yet still able to accept 4 pin din connectors).
-Four internal 'CoCo4' card slots.
-NO CPU onboard.
-NO video generator onboard.

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.


The Video:

I propose that the first slot be occupied by a video card. A 4Mhz read rate using 16 bit wide data would allow for only 2.2 times the resolution of a CoCo3. But with with the addition of a 256 byte FIFO buffer for the data things look better. The video resolution wouldn't have to be locked to the bus frequency and the memory accesses happening in the horizontal border could now actually be used for image data. This would give us another 35% resolution boost to 2.93 times better resolution than the CoCo3 and this is assuming we stick to the same sync NTSC frequencies and border sizes. It could do better still if we set optimized sync frequencies and vertical scan sizes.

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 CPU:

I propose we use 63C09E CPUs at 4Mhz and stick them on plug-in cards - with the clock rate being selectable between 1, 2 and 4Mhz. Although the 63C09 is rated for 3Mhz operation, going to 4Mhz is not a problem. I've ran the 6309 in my CoCo with a clock doubler circuit for years and it barely goes above room temperature - and that circuit generates some vicious timing signals that won't be happening here. The important things that need to be on this card are a GIME compatible MMU to allow the CPU to address 2 Meg of RAM (Some simple solution might also be implemented to allow addressing above 2 Megs), and GIME compatible interrupt select/timer generator. There will also need to be added logic to interface the CPUs 8 bit data path with the bus' 16 bit wide data. (convert even/odd addesses into upper/lower byte selects.)

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.


The Extras:

With three CPUs, a lot of neat things can be accomplished. You could have one CPU devoted to a time consuming task, another CPU devoted to some other task, and the main CPU running whatever program it is you're running. The neat thing is that since all three CPUs have identical capabilities, any one of them could be assigned to to anything you want. You CAN have a software sound chip, math co-processor, graphics co-processor or fully buffered serial communications. Heck, you could even run a GUI environment without putting any drain on the CPU that's running applications.

-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):

Although some of the new hardware may not be directly compatible with previous CoCos, there is a way that full compatibility can be retained. Lets say we gave it a 'CoCo3' mode - here's how it would work;

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:

-While the 63C09 can run at 4Mhz, a lot of the other hardware in the CoCo cannot. For that reason, it would be a good idea to have a seperate 2Mhz clock rate driving the cartridge port & support circuitry. For this to be possible, a 1 cycle wait state would have to be imposed on the CPU if it's clock is out of sync with the 2Mhz clock when it tries reading or writing to hardware.

-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!)


Expandability:

The reason I think the CoCo4 should have the 4 card slots, seperate CPU and video cards is because that way it would be easier to upgrade the system without having to change the entire board at a big expense.

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.

Click here to return to Sock Master's page.
I can be contacted by e-mail at the following address: sock@axess.com.