Content

MMC Hardware

2009-03-13T01:41:26.985Z

MMC Interface Hardware Details

The interface is a simple one with a single byte location used as the data port and one byte used for the control register.

Data register: Allows a single byte to be written or read from the MMC. Bytes that are written to this location are sent to the card at the clock speed selected from the Control register. Bytes read from this location are always one transfer old. Regardless of speed selected the time to transfer a single byte is greater than the cycle time for a read in the bus of the color computer. When data is read from the card the write data line is held high sending an effective value of 255 to the write pin of the MMC.

Control register: Allows control of MMC clock and CS assertion

Bits	7	6	5	4	3	2	1	0
	SPD	N/U	N/U	N/U	N/U	N/U	CS1	CS0

Bit 7: clock speed bit. Bit set is slow speed, bit cleared is fast speed bit. Clock is either Color computer Clock E / 8 (1.78Mhz/8 or .89Mhz/8) or E&Q combined to achieve a double rate clock of 1.78Mhz*2 at high speed or .89Mhz*2 at low speed.
Bits 6-2: Not used. Reserved for future use
Bit 1: CS for MMC #2 Bit set will select card number 2 and bit cleared will deselect card #2.
Bit 0: CS for MMC #1 Bit set will select card number 1 and bit cleared will deselect card #1.

Prototype Design

First implementation was to use discrete logic (which was a complete failure). After trying some simple logic designs with Atmel's free FPGA software I decided to give programmable logic a try and purchased the evaluation kit.
The choice to use the Atmel AT1508 FPGA was based on cost. I was able to purchase an evaluation kit from DigiKey for less than $100. Aproxametly 50% of the logic within the FPGA was used and there are still many unused I/O pins available for future use.
Use of the 74LVC245 was required to reliably level shift the MMC clock and data pins from 5.0v to 3.3v. I tried other options such as mosfets and transistors, but I was unable to get them to ramp up in speed to E clock (even at slow speed .89Mhz).

During development I created a few prototype boards the first was an attempt to use discrete logic.

The second board almost worked, however several tries at converting the logic levels from 3.3v to 5v caused me to create a third board.

The third and final prototype worked with little effort (after the CPLD logic was correct!)

IDE/ATA Interface

2009-03-13T02:31:31.883Z

Project History

Design

Back in 1995 I began working on an IDE interface for the coco. It seemed like a good and inexpensive way for any old 8 bit computer to have a hard drive. The idea was not all that complex in itself, after all IDE drives only require an interface. One of the largest problems to face was that IDE uses a 16 bit data bus. At first look of the specifications it seemed as though 8 bit transfers would be possible. As fate would have it, 8 bit transfers were only available if the IDE drive supported it (and only a few do!).

The Solution

It was now quite apparent that 16 bit transfers would need to be implemented. There are many ways to implement this technology, but I chose the least expensive route. By using two 8 bit latches (one for read and one for write) it is possible to capture the extra 8 bits that the CPU cannot see for each read or write to the data registers. All other IDE register only use 8 bits.

Functionality

By using an 8 bit latch for writing a sector, it is possible to fool the drive into seeing 16 bits for each cycle. First the upper 8 bits are written by the CPU to the write latch. During this write, the device does not see any change of state. The next step is for the CPU to write to the devices data register. When this register is accessed the latch is also enabled, sending 16 bits to the drive at one time. A read from the drive is done in reverse. First the CPU reads 8 bits from the drives data register, at the same time the read latch captures the extra 8 bits the CPU cannot access. This extra 8 bits is then read from the 'read' latch, and the cycle happens all over again.

Specifics

One more important thing to remember is that IDE drives have a sector size of 512 bytes. OS-9 from Tandy uses 256 byte sectors. The process of writing and reading a sector of 512 bytes could be seen as very inefficient to only return 256 bytes. By using a driver that only reads/writes to the drive register (bypassing the latches) a 256 byte sector is then created. Some may see this as wasteful, but the gain in speed seems like a logical choice to me. This is the way I implemented the first driver that I created. Using a Maxtor 210MB IDE drive I was able to format out to get 105MB. In the prototype the address range that the interface was set to use is (hex) $FF70-FF78. The first 8 bytes were the IDE drive registers while the 9th byte was used to map the latches.

Home

2009-03-13T01:15:06.889Z

If you are looking for my Blog that used to be located at this address it is now located here.

test2

2010-09-10T19:25:19.785Z

test

2010-09-10T19:01:24.499Z

MMC/SD Interface V2

2010-04-04T17:36:54.155Z

Another MMC/SD interface

After years of not creating any new hardware for my CoCos I decided it was time to break out the soldering iron again and make something new.

I really like storage projects, because it is great being able to use my computers without floppy drives or hard drives. There is just something really nice about a computer that does not have any moving parts.

Back in 2003 I created (using a CPLD) a SPI bus for the coco. The enabled me to use MMC/SD cards with the CoCo for storage. My first MMC Interface prototype worked very good and allowed for two cards that could be hot swapped at any time.

The things that I did not like about the project were the complexity of the CPLD, the number of wires to connect to the CoCo, etc. So that got me thinking, is there a way one could implement a SPI bus in software and use some existing I/O lines in the CoCo?

Looking at the schematic of the CoCo I figured I would find something that I could use. I determined that I could use the single bit sound output, the cassette input bit, the cassette motor control and the *SCS line for a clock. I quickly layed out a schematic and got to building.

Components for the project

As part of the design I put some constraints on myself:

Only use parts that I had on hand
No CPLD or other programmable logic
No more than 2-3 discrete logic parts
The final design should fit nicely inside of the coco
This design would work in any CoCo
Build a suitable OS-9 driver

Checking with my spare parts area I found a few 74HCT245 parts that would work for level shifting from 5v to 3.3v. I also had a couple of 3.3V regulators in the pile of parts. Finally I found a spare circuit board, some wire wrap wire, and some old ribbon cable. Now I had everything I needed.

Schematic design

My schematic was drawn on a regular piece of paper, I need to get it into a schematic capture program and get a nice picture of it uploaded here.

Basically there are 4 pins on the 6821 PIA that I am using and two wires for power. For a total of 6 wires that must be connected to the CoCo. The final design was changed as during debugging I determined that I could not use *SCS and so I would need an additional I/O line to create a software clock. More information on this later.

Finding a suitable CoCo

This should have been an easy task. Unfortunately I only have one working CoCo 3 and so I was not about to start doing hardware prototyping on it. So I went into the pile of extra CoCo 2 and CoCo 1 systems that I had here at the house.

I chose to use a 64k CoCo2 with extended color basic:

Getting my development environment ready

I planned on using a few things for development to speed things up.

A laptop with Ubuntu Linux loaded that has a 9 pin serial port on the back
A copy of the Nitros9 project source
DriveWire Java Beta version
SuperDriver
Drivewire HDB-DOS for the Color Computer 2
Obviously I needed reference material for communicating with the hardware. This is a really good site for help with MMC/SD communication.

Wiring up the design

Most of my projects take days to wire up and test and debug. This project only uses 4 I/O lines and 2 for power.
The board took a couple of hours to wire up and connect internally in the CoCo. Nothing really out of the ordinary.

Testing the design

After wiring up the design into the CoCo I used DECB to poke and peek the correct locations on the PIA and tested the inputs and outputs to verify that things were working. I have a binary ripple counter with 4 LEDs and some connectors for checking clocks and so that is what I connected to the *SCS line and tested it with a peek to $ff40.

Below is a snapshot of the board that I created wired into my computer:

Writing the driver

At first when I started I figured that I would use my old MMC driver as a basis for the new driver. Then as I started looking into the code I remembered all the pain and frustration of trying to create a driver that needed to handle 512 byte sectors in a 256 byte sector environment. After messing around with my old code for a few hours the thought occurred to me that I could use Cloud-9's SuperDriver and prevent a lot of extra work. Thankfully there is an example low level driver template that is included with SuperDriver that allows you to build your own custom low level driver and use it with SuperDriver.

Coding a low level driver using SuperDriver

Using the low level tempate I started to copy most of my existing MMC code over and started adding code to handle SD and SDHC cards. Some additional commands and a small amount of extra code is all that is required to handle the 3 different cards.

As debugging started I found myself removing a lot of the code for SD and SDHC cards to make sure that things were working properly with the hardware. So currently the driver only implements MMC cards. The other problem was that in my spare parts bin I only had slots for MMC cards. I plan on purchasing a couple of SD card slots to I can get the driver working with SD and SDHC cards soon.
The working driver code can be downloaded here.

Testing the driver

Using DriveWire and Nitros9 source made making the boot disks a quick and easy process. About 20 seconds between changes and I was rebooted on the CoCo testing out the latest driver changes. This is where things started to get really complicated and other things did not go to well with my original design. I spent a few days testing and debugging the code. Finally it was clear that another hardware change was going to be required to make the project work.

Some custom makefiles and using drivewire Java version made things go even faster. After a rebuild I just simply re-launched drivewire using the default.set option to specify the location of the .DSK image that was just rebuilt. Once the server was up I could reset the CoCo and load in the new driver changes for testing.

I also used the DriveWire option to have a headless CoCo. This allowed me to telnet to localhost on port 6810 and not use a monitor or the keyboard on the CoCo for testing.

Debugging the hardware/software

The use of *SCS was a problem as this gave me a SPI mode 3 type interface (clock normally high) and this is not technically what MMC/SD/SDHC cards typically use. I needed a clock that was normally low and would clock high during data transfer(SPI mode 0). I had to go back to the CoCo schematic and find another PIA I/O line that would work for a software clock.

After implementing the new hardware change I had to re-write the driver to use the new clocking bit. This caused a few more bugs and fixed some other bugs. Finally almost a week after starting the project I was able to read and write data to the card.

Implementing low level driver drive size detection

One of the nice features of using SuperDriver is that ability for the low level driver to report the media size during format operations. This was a very nice feature and so I decided that I would implement the code required to support this operation.
Using CMD9 of the MMC/SD card will return the CSD register (128 bits of data). In this register from the card you will find the C_SIZE, C_SIZE_MULT and the WRITE_BLOCK_SIZE values. Using these three values you can determine the size of the card. For SDHC cards the CSD register format is a little different and calculating the size of the card is slightly different. To decode the bits for each of these important values I created the following spreadsheet. This gave me an idea of where the bits where and how my bytes I would need to store them.

CSD Register worksheet

Running with MMC/SD storage

Unfortunately implementing a SPI bus in software is always going to be much slower then implementing one in hardware. As a resut the Megaread times for the driver in OS9 are not that great. Also remember that these times are on a CoCo 2 system running Nitros9 Level I.

OS9:date -t;megaread </sd0@;date -t
April 02, 2010 22:58:20
April 02, 2010 23:04:55

Final thoughts

Of all the projects I have worked on for the CoCo (IDE interface, MMC interface V1, and the 512k memory board) this was by far the fastest turn around time. Within one week of dreaming up the design I had a working project with a completly functioning OS-9 driver up and working.
Now the next question is, what do you do with 32GB of SDHC space on a CoCo?

Pictures of the project

llsd.asm

2010-04-05T03:07:57.051Z

0404001220d.jpg

2010-04-04T17:39:21.246Z

0404001220a.jpg

2010-04-04T17:39:16.719Z

0404001220.jpg

2010-04-04T17:39:09.069Z

0404001219a.jpg

2010-04-04T17:39:02.448Z

0404001219.jpg

2010-04-04T17:38:57.146Z

0404001218.jpg

2010-04-04T17:38:46.755Z

Slot Extender

2010-03-24T03:18:37.925Z

This project is brought to us by John over at gimechip.com

Using this board you can extend the cart slot out to a breadboard or make a y-cable.

Here are the snapshots of the board:

Below is the schematic of the board:

And most important is are the Eagle Files so you can load and play with the board files yourself.

Java DriveWire Server

2009-12-15T03:44:02.902Z

NEW: as of 2/27/2010 There is now a beta version of Java DriveWire server available for download. For more information on downloading the latest beta version of Java DriveWire server please see this link.

I would like to share the new Java DriveWire Server in action. For more information on DriveWire please see the documentation from Cloud9s web site here.

Aaron Wolfe has been hard at work converting the Linux version of DriveWire into Java and extending it to support incoming telnet sessions.

Here is a screen shot of his development Color Computer 3 running DriveWire. You will notice that it is only a Color Computer 3 with a DriveWire cartridge plugged in.

There are a couple of different ways you can connect to his CoCo. One thing to note is that this is his development computer, so there are times when it may not be up and running.

The first way is to use a telnet client and connect to home.spogbiper.com on port 6809. Screen shot below:

The other way you can connect to the server is via a web page that implements a telnet window within your browser.

This address is located at http://home.spogbiper.com:6800/anyterm.html

Multiple Telnet Sessions:

If you would like to connect to Aaron's Color Computer via telnet or the web please send him an email. Currently his only connected CoCo is also his development computer, so it might not always be up and running.

Tandy Color Computer 3 as a Web Server

2009-12-31T17:51:29.507Z

Can a Tandy Color Computer also be a web server? You bet it can. Aaron has extended Drivewire and created a simple Basic09 program that allows the CoCo to serve up web pages.

If you would like to go to his CoCo web page on the internet use this link here.

Aaron's CoCo is also serving up more pages here.

If his site is down (because of development), below is a screen shot taken 12/31/2009 of the web page:

Attached below is a copy of the original Basic09 Source code or click here to download.

ScreenHunter_01 Dec. 31 11.57.jpg

2009-12-31T17:59:14.138Z

httpd.txt

2009-12-31T18:02:57.033Z

SNAG-004.jpg

2009-12-15T04:45:25.221Z

SNAG-002.jpg

2009-12-15T04:44:25.361Z

Multiple telnet sessions

2009-12-15T04:38:06.765Z

As of 12/14/2009 I would like to report the first known case of a Tandy Color Computer 3 being available on the internet and having 3 separate Telnet sessions running at the same time.

Arron Wolfe, Boisy Pitre, and Jim Hathaway were all connected via separate telnet sessions to Aaron Wolfe's Color Computer 3 running Nitros9.

As you can see below we each left a separate file on the root of the system:

Procs List with all of our activity:

FireFox DriveWire Status.jpg

2009-12-31T19:40:09.973Z

GWT Web UI

2009-12-15T04:59:33.376Z

The new Java Drivewire server will have a web front end using the latest browser technologies like AJAX.

The interface will be how you connect and manage your drivewire server. Because the server is available via HTTP you access the page locally or over your local network on another PC.

All modern browser are supported such as

Internet Explorer
Google Chrome
Firefox
Safari
iPod touch
iPhone
etc.

The web front end is still in the early stages.

Below is a sample screen shot of the work in progress:

If you are wondering how can GWT possibly make it so easy that it will look and work the same way across browsers here are the pages being served via Linux on a Linksys NSLU2:

Google Chrome:	FireFox:
Internet Explorer:	Other

multicoco-1.jpg

2009-12-15T04:06:33.135Z

Chrome Drivewire Status.jpg

2009-12-31T19:39:34.540Z