One day in a charity shop, I spotted a beautiful Aristona CD player. As an engineer, I have always been fascinated by the different ways we store information: magnetic tape, grooves in vinyl, and optical discs. I have a soft spot for physical media, which brings back memories of growing up with cassettes and CDs.

That first find got me hooked. I picked up another player, and then another. I now have a Philips CD480, an Aristona 1371, and an Akai CD player. They sound lovely, and I enjoy using them without pretending to be a serious audiophile. If a piece of equipment makes me happy when I listen to music, that is enough for me.

I also enjoy reading the service manuals for these machines. They are unusually complete, with schematics, explanations of how the circuits work, and clear troubleshooting procedures. The boards are spacious and mostly built from through-hole components, making them easier to inspect and modify. It is impressive that such complex, mass-produced equipment can still be working decades later.


The Display Problem

The CD480's original LED display is one of the weak points I kept hearing about from other owners. It can fail, and replacements are not easy to find.

I found an existing replacement approach, but I wanted to try a different one. My goal was to make a board that fits the original display area, brings the modules closer together, and uses a modern driver. I also wanted to keep the door open for experimenting with custom display patterns later.

The basic idea is:
 

CD480 MM5450 serial data -> microcontroller translator -> I2C LED drivers -> LTP-305 matrix displays

Choosing the Displays

I started by looking through my parts box. I found a few DSP2913 and HSP200 modules, but they were a little too small for the space available. The LTP-305G and LTP-305R 5x7 LED matrix modules looked like a much better fit, and I already had some on hand.

The matrix displays give me more flexibility than a fixed 7-segment digit. The same general idea could also be adapted to other display modules, but this version is designed around the LTP-305 footprint.



Designing the Replacement Board

There is already another replacement solution for these displays. For purists, it is probably the preferable approach because it sticks with the same LED controller as the original display board.

In my opinion, the display used in the first version does not look quite right. There is an improved version, but I am not sure whether it is open source; at least, I was unable to find the project files.

Reusing the original controller would still be a bit of a gamble for me. I sourced some supposedly "new" MM5450 LED drivers from a well-known marketplace. Sure enough, the one I soldered in, despite my efforts not to stress it too much, does not seem to be fully functional. It shows signs of at least two defective or shorted segments.

That has also been my experience with quite a lot of "new old stock." The odds may not be exactly 50/50, but there is still a very good chance of receiving rejected, counterfeit, or partly defective ICs.

For that reason, I focused on making a solution based on modern LED drivers. I also wanted it to be flexible, so I could later replace the 5x7 matrix displays with 7-segment displays in the same physical space and keep the same character alignment.

I measured the original display assembly and used those measurements to position the new displays so they line up with the front panel. Then I laid out the replacement board in KiCad.

For the LED drivers, I chose the IS31FL3730. i have used them before and fiind them quite intersting and versitile led drivers both for CA CC aplications.


Schematic: schematic.pdf



The board uses two of these I2C matrix drivers, at addresses  0x60 and 0x61 to control four LTP-305G displays. Each driver handles a pair of displays. Their compact QFN packages helped me fit the electronics into the available space between the display modules.

The aim was to make the replacement sit neatly in the original display area, rather than look like a collection of separate modules added on top. I have included the KiCad design files with the project so the layout can be inspected and adapted.


The aim was to make the replacement sit neatly in the original display area, rather than look like a collection of separate modules added on top. I have included the KiCad design files with the project so the layout can be inspected and adapted.

LED driver side:


Reading the CD480's Display Data

The CD480 sends display data as a serial stream for its MM5450 display driver. I wanted to capture that existing stream and translate it for the new LED drivers.

I connected a 5V Arduino-compatible board to the clock, data, and enable signals. My first sketch captured the 36-bit frames and printed them to the serial monitor. Once I could see the raw bits, I worked out how they mapped to four characters and the status indicators.

Getting the Arduino to react quickly enough was one of the harder parts. Capturing the stream without glitches meant paying close attention to timing: a missed clock edge or a late sample could leave me decoding the wrong bits. The receive code needed to do as little work as possible while the player was sending data.

In the sketch, the clock is connected to pin 2, enable to pin 3, and data to pin 4. Interrupts handle both edges of the enable signal and each rising clock edge. When enable goes low, the receiver clears a five-byte buffer and starts a new frame. Each clock interrupt samples one data bit and packs it into the buffer, up to 36 bits. When enable goes high again, the sketch marks the frame as ready if it has collected all 36 bits; incomplete frames are ignored.

To reduce sampling overhead, the clock handler reads pin 4 directly with PIND & _BV(4) instead of calling digitalRead(). This depends on the AVR port mapping used here and would need checking when moving to another board. The interrupt handlers only capture data and update the receive state. Character decoding, serial debug output, and I2C display updates happen in the main loop, keeping the handlers short so they can respond promptly to incoming clock edges.

Receiving display data from the CD480:


From Received Bits to Matrix Characters

The next step was to turn the capture sketch into a protocol bridge. In the main loop, the Arduino checks that the frame's first bit is set, then reverses and shifts the received digit bytes to recover the original segment patterns. The  fontReverse()  function matches those patterns to characters. Those characters are then rendered using the matrix font tables and sent over I2C to the IS31FL3730 drivers, along with the status indicators. This is a character conversion, rather than a direct copy of the original display bits into the new driver's memory.



PCB

There was also a small self-inflicted complication. When designing the PCB, I did not pay enough attention to how each display's rows and columns mapped to the driver's display memory. The second module on each driver ended up needing a different mapping from the first. The wiring works, but it makes the software less straightforward. At the time, my thinking was, "I can fix that in software." Well, here we are: a small facepalm moment.
My solution was to keep two font tables: Font5x7_full for the first module in each pair and a dedicated Font5x7_180 table for the second. The display routine also reads the second table's bytes in reverse order and shifts them left by one bit to fit the driver mapping. I could calculate the transformation on the fly from a single font, but I chose to store both versions instead: a little more font storage in exchange for fewer calculations when updating the display. Next time, I would check the row and column mapping more carefully during PCB layout, even knowing that software can compensate for it later.




Final Thoughts

This project became more than simply replacing a failed display. It was also a useful exercise in understanding how the CD480 communicates with its original hardware and finding a practical way to connect that design to modern components.



The result keeps the display close to the original position and spacing without depending on increasingly questionable MM5450 stock. At the same time, the microcontroller bridge leaves room for further experiments, including different character patterns or 7-segment displays and diffrent led drivers in the same physical space. That flexibility was the main reason for taking this route, and it should make the next repair a little less of a gamble.