I haven't worked on this project in a while, so I decided to try to add ethernet. And I let some magic smoke out!

And I succeeded... for about a day before disaster. I used the discontinued Ethernet shield for Seeed Studio. It is intended for Arduino use, but since this is almost an arduino, I thought it ought to work, and I could hack up the software to work.

The Cat-644 has a funny design: the external video RAM address lines, are shared with the SPI bus. When the computer wants to read or write the SD card, it must do so during the vertical blanking portion of the display between video frames, What happens when you try to read the SD card in the middle of active video? On the Atmega chips, the SPI functionality overrides general I/O functionality, so the SD card takes priority, and the video display is garbled for a few scan lines. The SD card driver I wrote will disable the VGA DAC, making those lines black, which is much less noticable.

So I go into my cat-os code and disable both the sdcard and vga driver init functions, and get working on an ethernet driver.

I got it to initialize, bind to an IP address, and response to pings from my desktop computer. So far, so good.

A little detail: The Wiznet5100 chip used on this ethernet board runs on 3.3v, but is advertised as having 5v tolerant I/O. I figured I could put it on the Cat-644 SPI bus, and use a slave-select line to talk to it. After I used one of the unused PORTA pins on the Atmega, I thought I could hook the SD card and VGA. Turn it on.

I had it set up so things init in the order of: serial, keyboard, ethernet, sdcard, vga.

Serial comes up, and shows ethernet bound to an ip address. I can ping the computer. But I can't init the sd card, and the screen is garbled. I play around with wires making sure nothing got loose: usually a garbled screen means a bad ram address line. Then it hit me, PORTB must not be released by something.

I finally figured out what it was. It turns out the Wiznet5100 chip in this ethernet board does NOT float the MISO line when SS is high!. That's right: when the Wiznet is de-selected, it will still hold MISO high or low, jamming the bus. The atmega is driving the pin one way, and the wiznet is going the other!

Also, this happened: The whole computer turned off and wouldn't turn back on. DIsconeecting the Wiznet board resulting in a perfectly working Cat-644 with sdcard and video. The Wiznet board itself: If you apply power to it, the chip gets really hot. Measuring across the power input, its shorted out to .6 volts. The Wiznet ethernet chip is now a brain dead melted diode!

Lessons learned:

1. Don't assume that SPI devices release the bus unless they really say they do. It turns out there's a note in Wiznet's documentation that says 'unlike other devices', and then suggests using an alternate pin on the chip.... A pin called SPIEN. The problem with SPIEN, it has opposite logic to SS: When SS is low, SPIEN must be high. The docs suggest using an inverter to make it behave like other devices. Sounds like a workaround to a hardware bug... they couldn't built that into the chip?!

2. 5V tolerant I/O means well behaved I/O. Two 5v devices pulling in opposite directions is dangerous enough; if one is barely 5V tolerant, then it will probably loose the battle.a

3. The Wiznet chip died, and in doing so sucked down enough current to effectively short out the rest of the power. This may have been what protected the rest of the computer.

Next Steps:

Well, there is a lot of stuff to do on this project. I am taking a break from the electronics portion of it, and should mostly focus on software. I need to get two key parts working: the filesystem, and an interpreter. After that, I can think about new hardware improvements like ethernet or extra ram. The Cat-644 already features a serial port, so there's your crude networking right there!