Software description

This is a quick overview of the software structure and some parts are superficially described. See detail documentation in the source code comments.

The software compiles with AVR-GCC. Download the source at the downloads page.

Modules

The following diagram shows how the modules calls each other. Note that not all modules and not all connections are shown in the diagram.

MMC2IEC software block diagram

mmc2iec.c

This file contains the main function, which calls various initialize functions and repeatedly calls the interface handler.

interface.c

In this file the parsing and responding to IEC commands is implemented. This includes interpreting user commands, composing the C64 BASIC listings and transferring native, D64 or T64 files.

IEC_driver.c

The low level I/O to the IEC bus with its quirky handshaking and some of the IEC protocol is implemented in this module. As of v0.7 this module has been tested successfully against a DTV as well as a C64, and with another 1541 device on the bus.

d64driver.c

Read only implementation of listing and accessing files in a D64 image.

t64driver.c

Read only implementation of listing and accessing files in a T64 image.

fat.c

This module implements FAT16 and FAT32 with read and write access, as well as directory manipulation. It requires a hefty amount of resources from the AVR. See source for details.

sdcard.c

This module implements communication with SD cards using hardware SPI. The driver has shown its value over time, in that it has worked with every SD and MMC card I have thrown at it.

Comments

Implementing the IEC protocol was a nightmare. The different states of LISTEN/UNLISTEN, TALK/UNTALK and the way commands were transferred was backwards to say the least. I'm not sure if I have the implementation correct yet. But it to works for SAVE and LOAD at least.

You can enable debug printing of IEC commands to the UART by setting the UART_DEBUG define in config.h.

It was tempting to make the ATN signal of the IEC bus interrupt handled, as the ATN signal is supposed to have a "stop everything and listen" meaning. But after further analysis I concluded that it would only complicate things. After all, the protocol allows for a significant delay from ATN to the device says "I'm listening".

In fact the implementation does not use interrupts at all, it is completely sequential. Whenever needed, execution is blocked until a given operation is complete. This fact is critical in the IEC_driver, because the communication might have come out of sync, and there you are, waiting for a handshake that never comes. To solve this, all loops in IEC_driver have timeouts. This is also true for loops in the SD-Card driver.

 

Previous: Introduction  -  Next: Hardware description