In the past year I’ve acquired a few Arduinos (two Uno’s and one Nano). They were cheap chinese clones … and well they have sat in the drawer for most of the year … as I haven’t actually figured out much to do with them … until now.

The first cool thing is SIO2Arduino . This transforms an Arduino into a virtual floppy drive on an Atari 8 bit computer (like my 800XL). There are a couple of similar projects around, but I liked SIO2Arduino because you can use it headless or with an LCD screen and buttons. I didn’t have an LCD screen, so headless suits me fine. In headless mode, you load up an SD card with all your floppy images as well as a special AUTORUN.ATR image. This latter image is a program called SDRIVE that just boots your Atari to a menu where you can select drive images off your SD card and then reboot into the appropriate game or application. Up to now, I’d been using Aspeqt on a linux VM and a FTDI usb-serial adapter to load stuff. Which means I need my laptop going to do anything on the Atari.

So to build SIO2Arduino I needed

– An Arduino Uno or Nano
– An SD adapter to wire into the Arduino
– An SD card
– And probably an SIO plug

Out of that list, I only really had the Arduino and an SD card. For the SD card adapter, I looked at a few alternatives online on how to hack one together … but eventually I found a SD to microSD adapter and soldered wires directly to it. I have a few of these adapters so it didnt feel too bad butchering it. But it means I can load a microSD and hook it up to the Arduino. For the SIO connector, I just have some female jumper wires (like you use on Arduinos) with one end soldered directly to the SIO pins on the underside of the 800XL motherboard. The only other main thing is a button. You need some way to reset the arduino to tell it to select the ‘AUTORUN.ATR’ disk. I ended up with a toggle switch for this .. which does the job.

I hit a snag when I tried to compile the ‘sketch’. I had errors related to the file.getFilename() calls and some errors related to SDVolume. Basically the SDFat library that SIO2Arduino depends up had been updated bit in the past few years. All the getFilename() calls had to be changed to getName(…) like so;

-  file.getFilename(name);
+  file.getName(name,13);

and

-  file->getFilename((char*)&filename);
+  file->getName((char*)&filename,13);

And the SDVolume stuff that SIO2Arduino seems to want is deprecated, but you can put this define high up in SIO2Arduino.ino to stop it complaining (Not sure whether you need the extra include or not)

 #include "config.h"
+#define USE_SD_VOLUME
 #include <SdFat.h>
 #include <SdFatUtil.h>
+#include <SdVolume.h>
 #include "atari.h"

You have to change some stuff in config.h as well to tell it you want to run in headless mode. And then just wire it up to the Atari and reboot. It works pretty well.

The next Arduino project I’ve been working on is to adapt the meeprommer sketch so that I can program an old school SRAM (in my case an old 2K 6116). Meeprommer is a quick way of making a flash programmer out of an Arduino for 28C64 or 28C256 chips. The idea is that you transfer the binary you want to write to the flash rom over serial and it writes it to the flash chip. So the sketch has a lot of good stuff for sending and receiving bytes over a data bus and a simple command line interface to upload files and stuff. So meeprommer uses 74HC595 chips to do the address bus. I did not have any, but had an old 4040 counter handy, so I thought I would adapt the sketch to use that. And I wasnt that interested in the special aspects of programming 28Cxx chips.

Anyway, this turned out to be a good learning exercise in writing arduino programs with the Arduino IDE as I had to adapt the code a fair bit, first for using the 4040, and then when it came to transferring files to the Arduino, I thought using something like xmodem might be better as it was easier to do something like that from something like minicom.

Anyway, I had heaps of problems with my xmodem idea, but like a lot of things I learnt a heap along the way. So I wanted to use xmodem-crc which is basically one step up from the original xmodem such that it has a 16 bit crc code instead of an 8 bit one. The basic gist of xmodem-crc is that the sender sends 3 header bytes, a 128 byte data packet and 2 CRC bytes. ie. 133 bytes. If the receiver thinks the CRC is OK, it sends back an ACK byte and then sends the next 133 bytes. When I started to do this I kept on getting the weird scenario of the arduino only receiving ‘about 60 bytes’, which I initally thought was just plain weird. Eventually I found some forum posts that said it related to the 64 byte receive buffer on the Uno using Arduino. After redoing my code a lot, lowering baud rates to abysmal levels … I eventually came across this post on increasing the serial buffer size to 256 bytes . That effectively solved my problem. My 133 byte packets could now fit into a 256 byte buffer and it was all good. I still don’t quite understand why it never worked with the 64 byte buffer at low baud rates …. but moving forward (I will note here that that hobbytronics post is old, and the RX and TX buffer sizes are kept in different places in the more recent Arduino IDEs … but a bit of grepping and you will find the right place).

So now I had a simple xmodem file transfer going. I was just reading the CRC bytes and ignoring them by sending back a positive ACK. The  next thing to do was to add CRC checking. This did not want to work at all for a long time … and the key lesson here was just understanding how the setup() and loop() stuff really works in an Arduino. To me it is old school event-loop programming with the Arduino doing its own ‘master loop’ that includes its own regular housekeeping stuff followed by your loop() function. The bigger lesson for me was what happens to variables at the top of your loop().  I had put variable definitions at the top of my loop() that should have just been globals. Suffice to say I had some very weird behaviour … where things would seemingly half work. The other thing to watch out for if you think you’re a C programmer is simply to remember that you are running on a tiny microcontroller and things like ints are in fact 16 bit ints, so copying/pasting code (such as source to a CRC function) may not work as intended.

So the SRAM programmer project is ongoing. One thing I will note is that it is hard to debug a serial transfer program when your only means of outputting data is …. the serial port. I’ve ended up writing debug info into the SRAM, since I can read it later using the command line interface in meeprommer. Ultimately it would be nicer with a 2nd serial port. I might look into the sofware serial ports like AltSoftwareSerial.