The CoCo SDC is available with a 3d printed case (case color may vary), or if you’d like to print your own, as an assembled circuit board.
The CoCo SDC provides floppy drive emulation and more for all Tandy/Radio Shack Color Computers and Dragon 32/64/Tano. Comes complete with case as pictured. Extended Color BASIC is required on CoCo 1/2. SD card is NOT included.
CoCo SDC (assembled PCB)
The CoCo SDC provides floppy drive emulation and more for all Tandy/Radio Shack Color Computers and Dragon 32/64/Tano. Assembled PCB only. Extended Color BASIC is required on CoCo 1/2. SD card is NOT included.
3d printed case for CoCo SDC
A 3d printed plastic case for your CoCo SDC. Includes screws and back plate. Case only, no circuit board included. Random color selection of black, white, or marble.
One of the big shortcomings of the MC-10 is the very small amount of ram available on a stock machine. Only 4 kilobytes of ram is provided to the system, not much for programs, and not even enough to display a hi-res screen (256×192, B&W).
There are ram modules that plug into the expansion port of course, but these don’t provide for memory access to the MC6847 VDG chip in the computer. Meaning that even with a ram expansion, video memory is limited to 4K.
The two pics below show available ram in basic, and the VDG displaying the hi-res screen. You can see how the VDG displays the same video information lower on the screen as what is displayed up top. This is because only 12 address lines (out of 13) are connected from the VDG to memory, so the address rolls over after 4K.
Available ram in basic, and hi-res video on a 4K machine
To remedy this, long ago someone came up with an 8K internal mod that provides more memory for the system, and enough to display a full screen of hi-res graphics. An article in the September 1983 issue of Color Computer Magazine, by Dennis Kitsz, details just such a ram modification.
Though I believe this is the mod most people have used over the years to upgrade their MC-10 to 8K, there are several errors in the article to watch out for. Most notably, the enable on the 74LS139 should be connected directly to ground rather than any E clock, or pin 8 of u12. Pin 8 of u12 is the expansion port /SEL line, and while things will run ok as long as nothing is plugged in, any cart that uses /SEL will cause a garbled video screen.
Anyway, I was recently asked by Steve Strowbridge (host of CoCoTalk) to modify his MC-10 to 8K as well as install one of my composite boards, so that he could make some videos on the MC-10.
I’d never actually done one before, though I had seen the article and noted the errors. So I pulled out the article again and looked it over. Thinking about how this mod was done for a bit, I decided there was a better way to do this.
The MC-10 has a perfectly useable system for gating address lines over from the MCU at the appropriate time, so rather than use a 74LS125 and 74LS139, why not simply extend the existing method by a bit (or more, for more memory).
The stock method uses two 74LS367A hex buffers to gate twelve address lines (A11..A0). We can simply piggyback another LS367A atop one of these and gate additional lines.
To go with this I selected an 8K SRAM, getting the chip count on the mod down from four, to two. To implement the mod, I removed the two existing static rams, placed a socket in place of one of them which I put the 8K sram into (a mostly compatible pinout) with several of the pins bent out of the socket as needed to make the proper connections.
Some pics of the finished mod
This, along with the piggybacked LS367A, and point-to-point connections made as needed resulted in what I think is a better mod that accomplishes the same goal. 8K of internal ram available to both the MCU and VDG.
With the 8K mod installed
Testing the video ram with a full hi-res display
As this can easily be extended to a 32K mod, I have plans to draw one up with proper PCBs for a cleaner installation. This was a fun little foray into modding the MC-10! 🙂
Some time ago, while thinking about the CoCoVGA display system, it occurred to me that when a system is equipped with the CoCoVGA, it’s no longer necessarily tied to the NTSC carrier frequency.
This opens up possibilities for easily overclocking the system. At the heart of the CoCo1/2 design is the SAM, or Synchronous Address Multiplexer. This integrated circuit performs DRAM access and refresh, provides for interleaved memory access between the VDG and CPU, and supplies the system clocks (Q, E, and VDG clock), tying the whole system together.
A SAM chip
Normally the SAM would derive it’s master clock from a crystal circuit using a frequency of 14.31818MHz. This is divided by 16 for the CPU clocks and by 4 for the VDG clock. By utilizing SAM speed registers, the CPU clocks can be doubled (master divided by 8), but in this condition DRAM is no longer refreshed and VDG access to memory is disabled.
Prototype SAM accelerator
The SAM must run at it’s base frequency in order to provide these essential functions, so my approach is to overclock the SAM itself in order to achieve stable double-speed operation (1.79MHz CPU). To achieve the desired clock, the SAM is driven directly by the other circuitry on the accelerator board with a clock rate of 28.63636MHz.
The programmable logic on the board intercepts writes to the SAM speed control registers, preventing them from reaching the SAM, and instead varies the master clock. This allows for easy switching from standard single-speed operation to double-speed.
Because the SAM always thinks it’s at single speed, DRAM and interleaved VDG memory access are handled normally, but at twice the rate. This does require 150ns or faster DRAMs, and possibly 2MHz rated PIAs (similar to the CoCo3).
This is an easy upgrade for CoCoVGA equipped machines, but will require updated CoCoVGA firmware and the aforementioned chip ratings. Completely compatible in single speed, there is only one minor difference at double-speed that may be unexpected. Because the entire system is overclocked by 100%, the VDG interrupts will fire twice as fast as well. VSYNC is at 120Hz in double-speed mode with this board, and HSYNC is doubled as well.
Stable memory with RC delays on DRAM strobes (over 1.5 billion verified writes)
This shouldn’t pose a problem to the programmer, as it’s exceedingly easy to skip every other IRQ if you really want a lower rate or otherwise adjust the code to use the appropriate timing. At this date, the only stable double-speed CoCo1/2 machines will be using this 120Hz system.
Most things will work just fine, but at 2x. Things using the interrupts for timing might need adjustment to run at the higher rate. At any rate, the double-speed poke was essentially useless on the CoCo1/2 due to the lack of DRAM refresh. With one of these accelerator boards, it’s stable and useable.
In the following video, you can see the CoCo running a short BASIC program, switching between .89MHz and 1.79MHz printing characters on the 32 column screen. The speed difference is apparent, and the transition from one mode to the other seamless!
Switching between speeds
Running the system at 1.79MHz does require DRAMs with a 150ns speed rating or faster, but many CoCos that have been upgraded in the past may already meet this requirement. I’m not certain yet whether or not the PIAs require upgrading to 2MHz rated parts as found in the CoCo3 (presumably for double-speed use), but those parts are readily available if needed. Just for fun, I popped a SAM board into a CoCo1 ‘F’ board I had open while programming CoCoVGA boards for shipment. It ran just fine, and though I didn’t test it extensively, it flawlessly did over 40 passes of the memory test I wrote before I shut it down (~8 million verified writes).
SAM board in a CoCo1
At the time of this writing, I’m about to receive REV02 boards, which include reliability patches I had to make to the initial prototype. I intend to release these as an optional item for CoCoVGA users that want more performance out of their system. And thanks to improvements to the CoCoVGA logic by Brendan Donahe, they’ll also enjoy the crisp video output on their monitor, even at 1.79MHz!
To make the serial ports on the Mega mini MPI more useful. I plan on designing several modules that will connect to the UART header on the side for connection to other devices.
The first of these is a dual USB serial bridge module that will allow direct connection via a USB cable to a modern Mac or PC for a hi-speed serial connection.
They use an FT232 serial USB to UART bridge IC, which I chose because of it’s capabilities, ease of use, and it’s good driver support for modern OSes.
Mega mini USB module, assembled prototype
Connection speeds of up to 921600 baud are supported, with some initial tests showing sustained transfer rates on the CoCo of 52KB per second at .89MHz on a CoCo2, and 78KB per second on a CoCo3 at 1.79MHz.
.89MHz transfer test at top, 1.79MHz at bottom
You can see the prototype module connected to the Mega mini in this next picture. I need to design a 3d printed case for the module soon to bring it all together.
The GIME-X project is a collaborative effort involving Gary Becker and myself. Gary heads up the CoCo3FPGA project and so has done a lot of work implementing the CoCo3 in FPGA form.
We had previously worked together on getting the analog board add-on for the CoCo3FPGA project produced, and when Gary approached me with the idea of working on an FPGA based GIME chip replacement I was delighted. Especially as this was something I’d already been thinking about, as well as it being something that would be really useful, as original GIMEs are not available to replace dead ones.
A 1987 version GIME
Gary is handling the Verilog, while I’m responsible for designing and building the hardware. I decided to go with a lower-end Altera Cyclone IV FPGA in the 144 pin QFP package for cost and ease of use/manufacturing. It was also a device I’d previously used in the CoCoVGA design, so I had some experience with it, and it was more than up to the task at hand.
So I designed a PCB that would plug into the GIMEs PLCC socket.
The board has the necessary FPGA, level translating buffers (5v to 3.3v logic), regulators, oscillator, flash, and DACs to pull a replacement together. In addition to the normal functionality of the GIME, enhancements are added, such as VGA video output and additional graphics modes.
We’ve made a lot of progress, going through a few revisions of the hardware until we had that part sorted out. At this stage we have a working board and configuration, and are refining the Verilog while testing it with various hardware and software working on making it as compatible as possible.
Artifact colors will be simulated on the VGA output for games that use them. I made the following video shortly after that was implemented.
Simulated composite artifacts
As we get nearer to completion of the GIME-X project ad prepare for production there are a number of things to consider to help it go smoothly.
One of the larger hurdles involved in making a board that plugs into the GIME socket is the PLCC plug that will be required.
While such a thing is available out there, they are clearly not a high demand item, and range from ridiculously expensive (as in over $100 each) to merely annoyingly so. The cheapest I’ve found is still $10 per part, a significant amount when the other components are added up as well.
68-pin PLCC plug
Add to this that most of them are very high profile, and not useful because of clearance considering where the GIME is situated on the board (partially underneath the keyboard).
Luckily for prototyping efforts, I was able to modify the least expensive plug available to get just enough clearance with the design. This is an option for production, but expensive, time consuming, and even then still has barely adequate clearance.
What to do?
After some thought, and studying the adapters I modified for use on the prototypes, I came up with an idea. The plug uses pins with a 1.27mm spacing, which are too long, resulting in the need to trim them for a lower profile. Shorter pins are available as SMT headers. By combining these with a 3d printed block for the plug body, I have a solution that is inexpensive (about $1 per plug), and no more trouble to manufacture with than modifying the expensive ones.
SMT headers and 3d printed plug
3d printed PLCC plug installed
Another benefit is that these are also of the lowest profile possible, giving me more clearance for the GIME-X. They also fit more deeply into the socket for a more secure fit.
Every millimeter counts (3d plug on right)
So there you have it, an easily available and more economical solution for the PLCC plug.
Other additions to the design also seem appropriate as the project nears completion. For instance, an NTSC encoder and analog circuitry to support composite and s-video connections, as well as support for >512K memory expansions.
To these ends, I’ve revised the design for the next prototype boards, which you can see here…
Improved design with NTSC video and >512K support
GIME-X prototype (w/NTSC circuit), note the upper address support to the E2 ram board
Soon after this revision, some minor changes were made to the NTSC circuit, which has resulted in what I believe will be the final hardware for the GIME-X. Having reached this point, I thought it was time to see some images displayed on real hardware, showing off some of the new GIME-X video modes.
So I wrote a picture viewer app for the CoCo and a some tools on my MacBook to convert stuff. Here are some examples of the 640×225-16 color, 320×225-256 color, and 640×112-256 color modes. These are phone pics of the actual image being displayed by the CoCo on a VGA monitor. Click on the image for a larger version
Note: These are just random images taken from the internet and used solely for the purpose of testing this hardware. If any of the originators or rights-holders of these images object, let me know and they’ll be removed.
640×225 – 16 color GIME-X images on VGA
320×225 – 256 color GIME-X images on VGA
640×112 – 256 color GIME-X images on VGA
Another feature that we really wanted to add to the GIME-X was system acceleration. I’m very happy to be able to say that we were able to do that, achieving an enhanced ‘turbo’ mode which clocks the entire system at 2.86MHz.
This is a significant speed increase adding more than a million additional CPU cycles per second. Here’s a clip showing a quick comparison of the three CPU speeds supported; .89MHz, 1.79MHz, and 2.86MHz.