Page created: 15APR2026
Significant progress has been made and the project is nearing completion. The firmware now reads and processes the table of contents from the drive, and can play tracks and skip, pause and resume. I have implemented a finite state machine (FSM) and a state acquisition routine in the firmware so that the state of the drive is always known, which allows operations triggered by the user to either proceed or be aborted as appropriate for the current state (for example, preventing a play CD operation with an open tray). Also new is a text-based user interface (TUI) that resembles a graphical CD player desktop program. The existing command line interface was convenient to have when developing and debugging because it allowed me to directly perform operations at will, but it is not a suitable interface for a CD player, unlike the new TUI. I have therefore removed the old command line interface, and I don't intend on re-introducing it. This decision also freed a lot of program space due to no longer needing to store the command strings and parsing logic.
The TUI has a configuration page, which at the moment only allows setting the serial baud rate.
The presence of the GND and +5V headers on the PCB allow a RS232 module to be connected and powered by the the ATAPIctrl board. Having a standard RS-232 interface allows me to use and test the interface with a larger range of machines. My L40 SX has recently been the test bed for the ATAPIctrl project.
The next effort will be in implementing a routine that identifies the medium type of the disc in the drive. I have only used and tested the ATAPIctrl firmware with the handful of audio CDs I have brought with me to university, and as a result, I have not yet been able to test with DVDs and non-audio CDs. The firmware needs to be able to recognise whether the inserted disc is a CD or DVD. If a CD is present, then the firmware must be able to determine if it is data, audio, or mixed-mode, and handle the case accordingly.
I also need to identify some uses for the configuration pins, which currently have no effect on functionality or start-up behaviour. Finally, I need to implement a functional mode in which another device (such as a microcontroller) can use the ATAPIctrl as a disc drive controller without the TUI. In this mode, the device will send an opcode to the ATAPIctrl, and the ATAPIctrl will in return send the requested data that corresponds to that opcode. This is the mode that will make ATAPIctrl useful in DIY CD player projects, and I expect it to not be difficult or take long to complete.
New PCB with pin headers for Ground and 5v, and I re-arranged and labelled the configuration and serial pins. A header for reset has also been introduced so that I can reset the system without power cycling it. The ICSP programming header's 5v pin is disconnected and unused, so that the board (and disc drive) cannot be powered by the programmer. This way, the board must be connected to the power supply for programming and the whole system does not draw significant current from the USB port through the programmer. The PROG PWR jumper can be closed, however, so that the ATAPIctrl board can be programmed in isolation. The power input has also been moved to the opposite side of the IDE connector, so that the connectors are positioned the same as on the disc drive.
Also new is the analog audio passthrough, which can be connected to the analog audio output at the back of the disc drive, and passes the audio signal through to a 3.5mm jack. This does work, but the board is too dense for the analog audio cable to fit. This will be therefore be removed from the next PCB and the passthrough will be implemented on a separate board.
I have moved all strings out of RAM and into program memory (~330 single-byte text characters). All of the ATAPI command packets have also been placed in program memory (12 bytes in length each). It would have been impossible to store the strings, packets and the runtime variables in the 512 bytes of RAM available in the ATmega8515 I am using, so making use of some of the 8K bytes of program memory provides a lot more overhead for firmware runtime.
The firmware is now able to issue command packets to the connected drive (at this point, only the "eject" and "load disc" functions are implemented). It is currently possible to open and close the drive tray by typing the appropriate command into the UART command line.
I have implemented drive detection and identification. The firmware first checks for the ATAPI signature (0x14 in the Byte Count HI register and 0xEB in the Byte Count LO register of the connected drive), then issues the IDENTIFY PACKET DEVICE command (opcode 0xA1) and reads the contents of the data register. The firmware can theoretically detect if a hard disk has been connected instead of an optical drive by recognising the absence of the ATAPI signature and the presence of 0x00 instead, but I don't currently have an IDE hard disk with me to test this.
At this stage, I am able to read from and write to the ATA taskfile registers, which is a pre-requirement for being able to send command and data packets to the optical drive. Memory is now becoming a concern as having too many strings in the program will cause printed text to be incorrect, or in some cases, the firmware crashes and resets. I need to move all strings out of RAM (storing constant, unchanging strings in RAM is poor practice to begin with) and into program memory, where ATAPI packets will need to be stored too.
I have managed to get the UART part of the firmware working and I have implemented a simple command line interface and command interpreter.
Over the past month or so, I drew a schematic and designed a PCB for this project in KiCad, then had it fabricated by JLCPCB. Nearly two weeks passed while the boards were being fabricated and shipped (the manufacturing takes 2-3 days, but the cheapest shipping option brings the wait up to about two weeks). I assembled a board and put together the prototyping setup. The disc drive and ATAPIctrl board are powered through a splitter by a cheap power supply with a molex plug that outputs +5V and +12V. A USBasp programmer is connected to the SPI programming header, which will be the means of uploading the firmware to the board. On the breadboard is a FT232 module (wired to the transmit, receive and ground pins of the ATAPIctrl), which is a USB to UART adapter that will allow me to communicate with the ATAPIctrl over USB from a terminal emulator on my laptop.
I designed the ATAPIctrl board for an ATmega8515 chip in a DIP package as this made the trace routing easier (routing lots of signals from a large connector to a tiny chip is a pain, and many signals conveniently just lined up when using the larger DIP part). I instead installed a TQFP-44 package on a DIP breakout board I made because the TQFP-44 variant was easier to acquire. I did not install a crystal oscillator and load capacitors (parts Y1, C2, C3) for now as I want to get this working with the ATmega8515's internal clock source first. I implemented those footprints as insurance in case I need to run the 8515 at a higher frequency than the internal oscillator.
The quick and easy part is complete. Now comes the long process of writing the firmware...