Quite some time ago I made a few RGB to s-video adapters for the CoCo3 using the Analog Devices AD725 encoder IC. These produced some really good results and were used by a couple of people in the CoCo community for doing video capture to produce youTube videos and the like.
Initial video converter example
One unexpected thing that I discovered in working with these was that although they worked well with the ’87 version of the GIME chip found in the CoCo3, they were non-functional with the original (1986) version.
For those who are unaware, the ’86 version of the GIME chip differs from the ’87 in several respects. Among other things, memory timing errors exist in the ’86 that prompted the ’87 revision to make fixes. RGB output levels and sync timing also differ.
Discovering that whatever differences were actually enough to affect whether the video could be converted with an encoder IC like the ‘725 intrigued me. I set out to study the differences and create a converter that would work with both versions if possible.
The only signals involved in conversion are the 3 analog video channels, and the 2 sync signals. I did a pretty involved study of the signals using an oscilloscope, and though there were a number of minor differences, the chief difference, and as it turns out, the problem in conversion turned out to be the HSYNC pulse.
The HSYC pulses on both GIMEs are wider than they should be, though in the case of the ’87, it has been somewhat corrected, bringing it close enough to spec to function with the AD725 encoder. The pulse starts much too early on the ’86 however, and just won’t work.
You can see the difference in HSYNC width in the built in composite video here. The output from the 1986 GIME is pictured up top.
Composite signal – 1986 vs 1987 GIME
As you can see, the HSYNC pulse starts earlier and is nearly half a microsecond wider in the 86 version. This results in video off center on televisions. This is the composite signal however. We are using the separate syncs available at the RGB port for our converter. Here is a comparison of HSYNC at the RGB port.
GIME RGB port HSYNC – ’86 vs ’87
Even more of a difference in pulse duration here, which must be cleaned up to a certain degree by the internal conversion circuitry when generating composite in the GIME. Though both of these are pretty wide for an HSYNC pulse. For example, both PAL and NTSC video call for a pulse width of 4.7us. CGA, another 15.7KHz format, calls for a similar duration. Suffice it to say, the GIME has a wide HSYNC pulse, too wide in the case of the ’86 GIME.
Note, this did work with old CRT displays such as the CM-8 and CRT televisions as they are among the most forgiving of display types as far as signaling is concerned. For conversion with a modern encoder IC though, it’s a no go.
With what I learned of the signals, I decided to design a new converter reconstructing the sync signals as needed. I also wanted to generate (in addition to s-video) a good composite video signal from RGB, something better than the built in composite for RGB games, and possibly supporting artifact colors as well.
To do this, we need a clock for the encoder IC that is synced to the GIME clock itself, otherwise terrible artifacting results (dot crawl, etc). My solution is to tap the GIME clock circuit, and feed that signal into our converter. This 28.636MHz clock then can be divided down to provide the NTSC encoder, and also to drive the logic reconstructing the syncs. Using this method also has the benefit of not needing a clock generating circuit on the converter PCB itself. I settled on a Xilinx CPLD to handle these tasks, and designed a new board.
A new RGB2NTSC converter
The new board works very well, providing compatibility with both ’86 and ’87 GIMEs. Artifact colors on CoCo 1/2 games are also supported, over the composite connection only. The long stemmed button in the center of the board is used to adjust the color phase for artifact colors in CoCo 1/2 games. The following is a little demo video showing the converter in action.
The new converter in action
The output is very good, and I’m more or less satisfied with the state of this project. I’ll probably produce a few for release to interested members of the community to use and enjoy.
Here is a video showing the installation of the one-wire mod…
Installing the mod
Update 01/2019: I’ve designed a case for the board and have started making these available as a regular item (a handful were sold last year without cases). Converter and cable kit shown below.
A while back, I stumbled upon a project by Chris Martin, who was trying to get an SG24 video player working with the CoCo SDC on the CoCo. To this end, he had created an image converter for the individual frames.
After playing with the converter a bit, I was very interested in this idea, and decided to see if I could help get it going.
One problem I faced with a video player was getting as uninterrupted a flow of data as possible from the SD card into video memory. At the time, individual commands to read each 256 byte sector of a large file would have to be sent to the MCU, along with status polling for each sector to determine readiness of the SDC. This resulted in some undesirable delays in the byte stream and reduced the number of frames per second I’d be able to achieve.
I brought this issue to Darren Atkinson, the creator of the CoCo SDC, and he was very helpful in implementing a new stream command in the firmware. With this command it was now possible to issue a single command to the MCU, whereupon it would continue to feed sectors to the data port until either an abort command was issued, or the end of file was reached.
The sector size for this command was also increased to 512 bytes, further increasing throughput. Polling of the ready bit would still be needed to allow the MCU time to fill it’s data buffer from the SD card (roughly 1,000 cycles @.89MHz IIRC), but this could be handled with careful buffering on the CoCo side.
With the stream command implemented, I realized this could be used for not only video, but audio and other data that required fast transfer in large amounts. Maximum transfer rates with a 6309 CPU and the TFM instruction were around 180KB per second at .89MHz, and 250KB per second or more at 1.78MHz. Sufficient to do some interesting projects!
SDC media player menu
Rather than create a separate stand alone player for these different formats, I wanted to do something that would accommodate multiple streaming formats. I settled on the idea of embedded player modules in the data files. In this way, a common menu/file browser system could launch any media for playback, with the specific code needed to use it embedded in the file before the data.
I dubbed the file format as ‘CoCo SDC media file’ with an extension of .CSM on the SD card in order to be recognized by the system.
Everything is written in assembly, and the computer is operated in all-ram mode, with a 64KB machine being required. System memory for the media player is laid out as follows…
Media player files must conform to the following;
– named by the 8.3 convention with ‘CSM’ as the extension
– at least 82,944 bytes in total (header, player module, and data)
– must be an even number of 512 byte sectors (pad out the file if needed)
Here’s the format…
The first 16 bytes of a .CSM file are a text description, in CoCo specific ASCII, that will appear to the right of the file name in the menu system. Otherwise the 1,024 byte header may be used for module-specific data as needed.
Upon selection of a .CSM file by the menu system, the header and executable module code are streamed into ram at $6800-$FEFF. Code execution is then passed to the module at $6C00. At this time, the .CSM file is still mounted, though the stream command has been aborted. The module must initiate stream or sector read commands as needed during playback. The following is an example of starting streaming at the beginning of media data (sector 76) from a module.
Starting a data stream
Note that proper polling of the CoCo SDC’s status register must take place as needed to ensure accurate transfer of data.
During execution, modules may make use of the buffer areas from $0400-$37FF, as well as the module scratch space from $6800-$6BFF. Modules may not overwrite data in the $3800-$67FF region, or below $0400.
On exit, modules should shut down cleanly and jump to the return vector at $0053.
The file browser will resume where it left off, allowing selection of the next .CSM file.
I’ve written several modules for use with this system that can be found on their own pages in the software projects section. If you’d like to write your own player module and have any questions, feel free to contact me.
Here is a link to the current version of the media player and some tools….
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
First build
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 DE1 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.
Original CoCo 3 FPGA analog board on DE1
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.
Back
Top
GPIO header side
Power button side
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…
CoCo3FPGA Analog Board – REV02
Update 5/31/16…
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!
CoCo3FPGA Analog test board with new top plate on DE1
Update 7/7/16…
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…
REV02 boards
REV02 boards, closeup
Completed Analog Board on a DE1 with new top-plate and standoffs
