Infocom released a number of it’s interactive fiction titles for the Color Computer in the 1980s, just as it did for most computers of the era. The versions released for the CoCo targeted the standard 32 column text screen of course. With it’s limited text display (32×16) and no true lowercase, the standard CoCo1/2 screen is really less than ideal for interactive fiction like Zork.
With the addition of a 64 column alphanumeric mode to the CoCoVGA project, it occurred to me that this mode would be great for the Infocom adventures. So I set out to see what could be done. Source code not being available at the time, my plan was to disassemble an existing interpreter, and modify it.
In doing this, I learned quite a bit about how the Infocom games work. I’ll share here some of what I discovered.
The software for an Infocom adventure consists of two parts; the interpreter, and the ‘Z-machine’ or ‘story file’. The z-machine itself is essentially a snapshot of the memory contents of a virtual machine (computer). The interpreter executes z-machine instructions and implements them on the host machine, while also managing virtual memory, and providing I/O for the virtual machine.
In this way, Infocom was able to easily port their games to any platform, by simply writing a new interpreter. The z-machine itself being the same from system to system.
The virtual machine’s memory map consists of three major parts; Dynamic Memory, Static Memory, and High Memory. Dynamic memory contains things such as game objects/information and global variables, and may be read from and written to by the virtual machine. Static memory contains the dictionary and various language tables, and may only be read. High memory contains the virtual machine’s executable code, the ‘Z-Code”.
Dynamic and static memory are loaded into host ram on startup, and remain there. The beginning portion of high memory (the executable z-code), is loaded into host ram at startup, and additional blocks of high memory are swapped in as called for during execution.
The z-code is made up of instructions and operands for the virtual machine. The interpreter executes this code, implementing the needed functions on whatever the host system happens to be.
On the CoCo interpreter I worked on at least, the virtual memory system uses 256 byte pages. These are tracked through a table by the interpreter so they can be loaded into CoCo memory from disk and referred to as called for by the z-code being executed.
After learning enough about the interpreter and how it operates I was able to adjust things to make room for a larger video page, and alter the screen handling routines to make use of the CoCoVGA’s 64×32 W64 mode. I also discovered that the z-machine files themselves handle lowercase. The CoCo interpreters have additional code that converts everything to caps for the 32×16 alpha screen, since most CoCos do not do lowercase. I also circumvented that conversion in order to display in lowercase on the CoCoVGA since it has that capability.
Infocom adventures on the CoCoVGA 64 col mode!
Once I had completed the CoCoVGA versions, I realized it would be simple at that point to alter the code to make a 64 column version for the CoCo3. So I did that as well. I whipped up some boot track loaders to go along with the interpreter/z-machine packages and made .DSK images which can now be found on the Color Computer archive.
Please note that I left the original disk I/O routines intact, so if running on the CoCo SDC, you’ll need to switch to the stock Disk BASIC in bank 1 after mounting the .DSK image for it to run properly.
The mini-MPI that I designed earlier has been available for a while now, and finding a place with quite a few Color Computer enthusiasts out there. I had been thinking for a while about doing something with more slots as well, because there just aren’t enough original 4-slot MPIs out there. As of this writing they go for $150-$200 each, when they are available, which certainly isn’t all the time.
The point is, the community needs more MPI options… I felt the time was right to produce another design to offer alongside the mini. About the time I was starting the design, I happened to catch an episode of CoCo Talk, where sound chips and other expansions were being discussed.
During the discussion, the idea of the ultimate CoCo expansion started to take some shape. It would be a multi-slot MPI with a sound chip and serial ports. This fit in nicely with the project I was beginning, and if that’s what the group wanted, then I’d try to do just that.
The MPI portion of the design was straightforward enough, given my previous experience on the mini-MPI, which left selection of components for the extended features.
Earlier Facebook group discussions on sound chips had steered me to the Yamaha YMF-262M (OPL3) as a possibility. The ‘262 seemed a good fit for the project, and offered a lot of capability for our 8-bit CPUs to work with. Listening to the quality of sound that can be reproduced using this chip on YouTube videos and the like was enough for me. Especially once I discovered the required chips were available, and in fact, relatively cheap. I was sold on the YMF-262, or at least on trying it.
Next, selection of the serial interface components…
I had a few criteria here; it needed to be an actual serial UART, it needed to be current production, and it needed to be SMT. Researching this, it became apparent pretty quickly that of the original UART lines that existed in the past had pretty well died out except for the 16550, several examples of which are in current production in SMT quad flat packs. Price and performance pointed me straight at the NXP SC16C550B, a capable current incarnation of the 16550 rated for higher speeds and with 16-byte FIFO buffers. Two of these would offer a decent serial expansion without getting crazy on cost or board space. Selection made…
Buffers would remain the same as the mini-MPI, 74ABT16245’s, perfect for this application. For the CPLD, I decided to step up from the XC9572XL used in the the mini to the XC95144XL, just to be on the safe side capacity-wise. The 100-pin QFP was selected as sufficient IO for the project.
On to the form factor… I knew I wanted to keep this MPI as small and unobtrusive as possible while still providing four slots. After some thinking, measuring, and note taking, I had some basic dimensions. John Strong had agreed to make the cases, as he does for the mini. Giving him an outline of the basic design yielded a test print, letting me see a little more effectively just what we had so far.
Test print with original MPI and carts for comparison
As can be seen, this design will be quite a bit more compact than the originals. I made sure however to leave the same amount of space between carts for ‘ribs’ in the case top plate. This should allow for carts to be held securely in place, even longer ones with cables on the end, hopefully.
So far, this all looked good, so the next step was designing the PCB with the dimensions I had established. A few days later, I had the design files for a prototype.
Initial PCB design
A couple of weeks later, and I’ve got the parts and PCBs to build that prototype.
Initial test PCBs
We need a prototype case!
After working up the CPLD programming for the basic MPI functionality and the sound chip, it was time for some testing. MPI functionality with all the carts I had close to hand looked good after a few tweaks, and the logic was in for the OPL3 interface. Let’s try to make some sound!
Initial sound test
I tested the interface initially with a quick BASIC program that sets up 2 FM operators to produce a tone, and steps up and down in frequency to vary it a bit. Rudimentary, but we have sound!
Well, now I have to hear something better, so I hacked a quick ML player for VGM files onto some existing menu code I had for browsing and mounting files on the CoCo SDC. VGM files consist of a stream of commands; sound chip register writes, wait periods, etc., and are specific to a certain sound chip or platform. So it was fairly quick to write. I used the prototype MPI board with the CoCo SDC and one of my CoCo PSG carts installed. I used only the 512KB RAM chip on the PSG, to hold the data for streaming to the chip. It sounds terrific! Here are a couple of sample tunes played on the MPI prototype, recorded on my MacBook Pro through a direct line-in connection.
‘FM house’ an OPL3 chiptune
‘What’s love’ another OPL3 chiptune
The YMF-262M (OPL3) is also OPL2 compatible. A bit in one of the registers is set to enable OPL3 features. So of course I had to write an OPL2 player routine to see what that sounded like. Here’s an example.
‘Dune’ an OPL2 chiptune
So, this brings us up to date on the project status as of 5/9/18. The MPI functionality is done, the sound chip works, the CPLD interface for the serial UARTs is implemented (needs testing). Left to do is to build an interrupt system using the /CART (FIRQ) line, make any needed revisions to the PCB, and build a final version of the board. After that, once John has a case design, we should be good to go.
Since the last update, I’ve had a chance to test the UARTs, which provide high-speed TTL level serial communications for the MPI. I wrote some transfer code on both ends (my MacBook, and the CoCo) adding a serial load option to my chiptunes player. Here’s a couple of videos…
Initial UART tests
UART speed test
I’m very pleased with the performance of the UARTs. I was able to achieve a transfer rate of over 50Kbytes per second using a .89MHz CoCo2 and a USB to serial bridge connected to my MacBook without much trouble. 100Kbytes+ per second should be possible with a double speed CoCo3.
During development, and while using multiple sound carts, I discovered an issue I hadn’t foreseen. Cartridges that output sound on the CoCo typically use the sound_in line at the cart port in addition to any separate outputs they might include, in order for the sound to be available to the computer for use with the RF modulator, etc.
This signal is supposed to be AC coupled to this sound_in line by any sound carts. This is explicitly stated in some of the documentation, the service manual I believe, for CoCo2’s.
It apparently wasn’t a consideration that more than one or two carts might be coupled to the line simultaneously, as I’ve found that excessive loading of the line degrades sound quality considerably. This might not seem much of an issue, but I wanted to build kind of a ‘CoCo sound system’ using the MPI personally, and would want multiple sound carts connected at once. So I decided to do something about it.
My solution to this problem on the MEGA mini is to add a software controllable analog switch to the board. This switch takes the sound line from each cartridge slot, as well as the built in OPL3 circuit as a separate input, and routes only one of them to the CoCo cart port. In this way, the lines are isolated from each other, and the problem is solved!
You can see the analog switch IC in the middle of the board below, to the right of the cartridge slots on the REV03 board.
REV03 board, bottom
Speaking of software control, a brief overview of the general operation of this MPI is as follows…
Like any MPI, at the heart of the system lies the MPI register. This is an 8-bit register whose purpose is to switch the bus arbitration signals; /CTS and /SCS, as well as /CART (the cartridge interrupt), to the appropriate slot under software control.
The upper four bits of the register are the slot number (in binary) that will be connected to /CTS and /CART (these two are bundled together). The lower four bits indicate the slot that is to receive /SCS.
As you can see, although Tandy only produced MPI’s with four slots, the system will accommodate up to sixteen. This is great, because it allows us an easy way to extend MPI functionality and avoid address conflicts by assigning additional hardware to a ‘virtual slot’ somewhere above the usual four.
This is what I’ve done with the additional features available on the MEGA-mini. The YMF-262 (OPL3) sound chip is found at virtual slot 5, the UARTs occupy slot 6, and additional MEGA mini features are found at slot 16 (enhanced IRQ system, analog switch, and programmable timer).
Specific details on hardware addresses and other programming information will be available in the MEGA mini user manual which is currently in progress.
I recently received a prototype 3d printed case from John Strong for this MPI, as he will be producing the cases for me once I get production of this item underway. His design is just what I had in mind when I started this project with the aim of a compact four slot MPI. Here are a few pictures of what we have so far…
MEGA mini, prototype case
Here’s a short overview of the MEGA mini in video form…
Gary Becker’s CoCo 3 FPGA project implements a Color Computer 3 running on
an Altera DE1 Cyclone II FPGA development board.
The CPU core runs at 25MHz. Communication using just the DE1 is via serial,
using Drivewire for storage currently. Hopefully the on board SD card slot will
be used in the future.
Gary has designed an add on board that connects to the GPIO ports on the DE1,
adding 4 megabytes of RAM, two joystick ports, a WiFi module, and RTC module.
It’s known as the CoCo 3 FPGA analog board.
I was asked to help in the manufacture of some of these, so I did a re-layout of the board, also trying to refine it a bit more in how it would go together with the dev board. Here are some test boards I received back. The silkscreen graphic will be slightly different on the final boards. Originally, the analog board was to be on top, outside the plexiglass cover of the DE1. This made for some really long connectors to the GPIO sockets.
I decided we should go for mounting the analog board underneath the top cover, using appropriate standoffs, etc. In fact we will be getting new acrylic top plates made that will not have the cutouts that the DE1 plate has, just to make a neater package.
Here are a few pics of the test boards, that make it a bit more clear what I’m going for in fitting Gary’s board to the DE1. The parts are just set in place.
As I mentioned, we hope to have new top plates that will be the same size as the DE1 footprint, and no cutouts. It should look pretty good. I have a few things to reposition slightly on the board before the main run, including the WiFi module.
The silkscreen on the final boards will look like this…
The board has passed tests on the serial port, joystick(s) circuit, and SRAM. PCBs ordered.
Sample of new top plates received, they look good!
I’ve finally got the run completed and am currently shipping them all out.
I can’t wait to see where the CoCo3 FPGA project goes as it continues to develop.
For those who are interested, the project has a Yahoo group, here…
At one point I decided to do a remake of the “Lowerkit” for the CoCo 2.
This external character set board for the 6847 will allow for fonts other than the built in set in the VDU to be used. A character set for the 6847 is 2048 bytes (2k), representing 128 ASCII character codes (0 – 127).
This version uses a 16k rom chip, providing room for 8 character sets selectable in banks by dip switch.
This version was one of my earlier CoCo projects, and used standard TTL logic. Though a bit bulky, it worked just fine. I actually still have this one installed in a Tano Dragon, where it has plenty of room.
Compared to the built in ROM
The next step will be to explore moving the logic into a cpld in order to get
the board size down, and then creating final board layouts for the various
CoCo1 and CoCo2 models.
I’ve put together an excel spreadsheet that aids in the creation of fonts for
the MC6847 that can be found at the end of this page. It lets me design a font in a visual manner, and generates the hex code for the rom.
The next board
Experimenting from the MC6847 External ROM board I put together earlier, I then built this version in part to learn about using CPLDs.
I built the earlier version using 7400 series logic, and thought migrating the design to CPLD would be a good learning exercise. I decided to use Xilinx chips, as I had already built a programmer for the PLCC version of the 9500xl family.
I split the logic over 2 CPLDs as I needed more pins than one would supply (without moving to SMD). The 9572xl holds the logic for rerouting addressing to the 27C256 EPROM and handles the associated selection lines to the MC6847. The 9536xl holds a 4 bit counter and flip-flop used to handle the row addressing on the EPROM.
Outputs from these CPLDs can drive TTL inputs, and can also be configured as open-collector outputs, which I did try out, using some add-on pull-ups under the board. Useful for driving TTL with a bit more voltage than the standard output buffer allows.
As you can see, it works pretty well. I did learn quite a bit about designing the internal logic for these CPLDs using the Xilinx ISE suite.
For the next revision I’ll adapt the design to SMD, using the VQF-64 version of the 9572xl to hold all the logic, making for a more compact board.
A “final” version of the external character ROM
After my first CPLD version of the MC6847 External ROM board, I decided to make a final, more refined version. I’ve made and distributed a number of these among members of the Color Computer group, and the boards look and work great.
This version uses the 64-pin version of the Xilinx 9572xl CPLD. I’ve made use of all the available pins, some of them even just to ease laying out the board. The design includes a 3.3v regulator to run the 9572, and a mini CPLD programming header.
A description of what the DIP switches do is as follows…
MC6847 External Character ROM – REV 03
DIP SWITCH SETTINGS
1 – Enable External ROM
2 – Inverse mode
3 – All Caps mode
4…7 – Bank selection 0…15 in binary
1) – Enable External ROM
Selects between MC6847’s internal ROM, and our external ROM.
2) – Inverse mode
Inverts the normal use of the INV line. What was black on green is now green on black and vice versa.
3) – All Caps mode
To accommodate certain programs that are expecting inverted uppercase when the computer calls for a lowercase character, from the internal ROM, this mode does the following…
Decodes for any VDG calls for a lowercase character in external ROM (610h – 7A0h), and adds an offset to the address lines to the ROM chip. Also triggers inverse mode.
The results will be like using the internal MC6847 ROM, but with the external character set. Inverted uppercase in place of true lowercase characters.
4…7 – Bank Selection
Selects one of 16 character banks to use in binary
Bank 0 Bank 1 Bank 2 Bank 3
0 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1
– – – – – – – – – – – – – – – –
Switch 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7 etc….
Here are some screenshots of some alternate character sets and the different mode settings being displayed by a CoCo2 using the board. This CoCo 2 is equipped with one of my composite boards including the B&W switch. This is being used on the B&W screens.
The COCOVGA project provides VGA output for 6847 based systems. This is a collaborative project with Brendan Donahe.
This first iteration of the board operates in tandem with the MC6847. The VDG operates normally, and provides it’s usual video output to existing RF boxes and composite display options that are part of the system.
An Altera Cyclone IV FPGA monitors the buses and control signals of the MC6847 through level shifting ICs, and generates VGA video at the correct scan rate.
Though this version requires a 6847 IC to be present, we will be extending the design to fully replace the VDG in the future. We are proceeding with the “bus monitoring” version now in order to make a working VGA option available to users as soon as possible.
NTSC composite color artifacts are supported for the high resolution modes for programs that depend on them (most games on the CoCo1 and 2 for example).
At this point in the project, we have functioning development prototype boards, and working FPGA code (aside from a few issues that need to be worked out).
Design of production boards for some machines is already underway while the FPGA code is being developed further.
The first boards will be designed to fit early American CoCo2 motherboards, to be followed by boards specifically designed to fit other systems.
Here are some pictures of the prototype board and of our initial output. There is a lot of code development yet to be done, but we’re off to a great start.
Video showing simulated early NTSC artifacts (prototype board)
We have come a long way since the initial prototype you see above on this page.
Since then I’ve designed our first production board that we are now on the verge of releasing for early American motherboard CoCo2’s (vertical RF modulator).
All of the standard 6847 video modes are supported, as well as a couple of new ones. In addition to the new video modes, all modes also have color palettes that can be set by the user. Color artifacts for the CoCo’s PMODE4 screen are simulated in several different selectable formats, and those artifact colors can be set by palette register as well if desired.
One of the new modes is VG6, a 128×96, 16-color mode. This mode gives 6847 machines some much improved graphics, especially considering that we can use whatever 16 colors we wish to on a screen. We can map any color from our output palette of 512 colors to a screen color via register settings.
Here are some early screen shots using VG6 with adaptive palettes.
Another new mode implemented on our first model for release is a new Alphanumerics mode. This new mode is a 64×32 column text mode which rivals, and which I think actually outdoes the 80 column mode on the CoCo3. It can actually display more characters than an 80×24 screen, and is also in output in clean, clear VGA.
Here is a video of Brendan demonstrating the new mode…
As we moved closer to actually producing and distributing some of these VGA solutions to interested parties, it became clear that we needed to work on the rest of an installation package. A good way was needed to get the VGA generated by the video board through the CoCo’s case. Also, another feature Brendan and I wanted to add to the system was some simple manual controls for changing some of the video settings.
The solution I came up with is a small output board, with a mini-din connector and two pushbuttons. Dubbed ‘Button boards’, these mount to the CoCo top shell and plug into the VGA board via ribbon cable.
I wanted to make the installation as easy to do cleanly as possible, so I went with a mini-din connector, reasoning that round holes would be easier to do for most people (including me). This does require making a special VGA cable, but the system has worked very well so far.
Brendan requested a hardware debounce on the switches, so that’s the extra circuitry you see on the boards.
Here are some pics of a button board installed…
Update: October 2017
As of our initial release which occurred at the 2017 Tandy Assembly, Brendan and I are providing these to interested parties as we have boards available. Development is continuing, with other versions to fit the many form factors needed for the different motherboards out there are being designed, as well as pursuit of various improvements/enhancements we have thought of to add to the system.