While things may have seemed a bit quiet lately here at CDTV Land, the CDTV OS 2.36 team has been hard at work behind the scenes all summer. There is quite a bit to talk about, although much of it involves things that you will hopefully never notice when using your CDTV. Which, in this particular case, is a good thing!
So what took so long?
The introductory page already covers what CDTV OS 2.36 brings to the table. In this article I want to talk a bit about how we got here, some of the technical challenges involved, and the legal side of getting the results into your hands. Those of you who read the equivalent article for 2.35 will know the drill.
CDTV OS 2.36 has been in various stages of being “almost finished” for quite a while now. Unfortunately, private matters caused development to grind to a halt in 2025. What can I say, sometimes life has other plans even when you’d much rather be staring at 68000 assembly code and reverse engineering 35 year old Commodore ROM code.
Luckily things became a lot more steady in the course of 2026 and what really helped bring the project back into focus was when the availability of new PiStorm firmware with support for bus arbitration was brought to my attention by a member of our team. This provided a good reason to sit down and decide exactly what should go into 2.36 and -equally important-, what would have to wait.
I already had some cool changes to the CDTV user interface working in prototype form. These were made possible by finally having finished my reverse engineering work on the monolith called playerprefs.library in mid-2024, and I am quite excited about them. However, getting those changes release ready would have widened the scope of the 2.36 release considerably, so I decided to postpone them until after 2.36.
So the focus ultimately became PiStorm support, 68040 and 68060 support, and general compatibility and stability improvements. That sounds reasonably straightforward when you put it into a single sentence, but getting there involved rather more work than I had anticipated…
Back to cdtv.device
One of the fixes in CDTV OS 2.35 addressed problems that 32-bit CPUs like the 68030 had with the CD-ROM driver cdtv.device (CD-ROM I/O just didn’t work reliably or at all). This “fix” involved adding NOP instructions at strategic points in the code to add a small delay (a NOP is an instruction that does, well.., nothing). Doing nothing can be surprisingly useful when hardware needs a little more time. That fix worked, but even though I had a good hunch of where the problem lay, it always stung that I did not know what the exact nature of the problem was. For 2.36 I wanted to find out exactly what was happening, and with an ever wider range of CPUs and accelerators to support, it was time to get to the bottom of this thing. So, out came the oscilloscope and logic analyzer!
The 6525 TriPort chip on the operating table
This is where development gets quite interesting, provided your definition of interesting includes staring at signals and trying to work out why a piece of hardware disagrees with what you think your code is doing. It is also where progress can become painfully slow. A small change requires another build, another test on real hardware, and another look at what actually happened, which can get tedious really fast.
The culprit in action… More details in a future post!
The investigation paid off, and figuring out the root cause was exhilarating! It turned out to be a RMW (read-modify-write) race condition that is created due to the way that cdtv.device (and cdg.library) sets or clears bits in the TriPort’s hardware registers. 68000 CPUs were slow enough for it not to matter, but 68030 and faster would easily trigger this race condition. Understanding the underlying problem made it possible to address it properly, and the result is now a rock solid cdtv.device that scales from the original 68000 through the various Motorola accelerators, all the way to PiStorm running Emu68. That is quite a range for a driver talking to hardware designed for the original CDTV and something I am really, really happy with.
Six fixes and a lot of head scratching
If cdtv.device required some detective work, cdg.library was the job I had been putting off for a long time. I knew it needed lots of attention and that sooner or later I would have to get down and dirty with it. With the focus of 2.36 now firmly on compatibility across different CPUs, it was time to stop dicking around and postponing the inevitable. And, as it turned out, this was where most of the development effort went for 2.36!
Fixing CD+G issues one by one.
Cdg.library is responsible for CD+G, the graphics that can accompany an audio CD. Getting the damn thing to work independently of CPU speed turned out to be a real challenge. In the end, it took six surgical fixes to get everything behaving properly! Six fixes. That sounds like something you could knock out in an afternoon, doesn’t it? Well, it wasn’t. The difficult part, of course, is finding them. Before you can make a small, precise change, you need to understand what the code is trying to do, how it interacts with the hardware, and why that interaction breaks under particular circumstances. Making changes to code you don’t own can be challenging, especially if you don’t understand the full context. A small change may appear to have fixed problem A, but it may have silently and simultaneously created new problems X and Y, because you didn’t know what you were doing!
Both cdg.library and cdtv.device access the MKE CD-ROM hardware directly. These are very low level parts of the operating system, where assumptions about timing and CPU behaviour have lots of very real consequences. Supporting faster CPUs meant working through all those assumptions that were made in 1990-1991 and addressing the problems once and for all.
I am very happy to have this work behind me. It has been challenging, sometimes frustrating, and difficult to debug, but it provides a much firmer foundation for future development. And there is something very satisfying about finally understanding a problem that has been making you scratch your head for a long time. For those interested in exactly what was going wrong and how I fixed it, I will go into much more technical detail about the various fixes in separate blog posts in the future. There is plenty to talk about, but I will spare you the assembly listings and signal traces in this article. 🙂
Moving up a level
Getting these hardware-facing components sorted also means I can spend more time on higher level parts of CDTV OS in the future. Much of that work can be developed and tested in an emulator, which makes a considerable difference to how quickly things move. Being able to try a change immediately is a luxury you learn to appreciate after testing build after build on real hardware.
The user interface changes I mentioned earlier are very much still on the agenda. I already have working prototypes, and I look forward to getting back to them., but they simply did not make the cut for 2.36. For this release, making sure the foundations were solid took priority. There is little point in getting carried away with the user interface when the code underneath still needs attention, tempting though that may be.
Patches, permissions and the legal stuff
Those of you who were around for the release of CDTV OS 2.35 may remember that distributing the finished ROM image was a challenge onto itself. My work builds on Commodore’s original CDTV system software, and that software is still copyrighted. The patch approach allows me to distribute my changes separately, with users supplying the original ROM image themselves. Docker was the delivery method for the 2.35 patch solution and this proved to be a headache for some users. For 2.36 I have a new patch solution in place that you will find is a lot easier to use: The CDTV Land Interactive Patch-O-Tron!
The Patch-O-Tron makes the patch process easy as pie. You just provide your input ROM image, select the target device(s) and it spits out the patched 2.36 ROM images. It runs fully client side (inside the browser), so at no point is any ROM image being transmitted over the internet. You can even save the webpage and use it fully offline! As with many other CDTV projects, I had the Patch-o-tron in prototype form for a while now. It was about 90% done in late 2022, with the bspatch code translated into pure JavaScript. The intention was to release it alongside 2.35 for A570/A690 that same year, but I was pretty burned out on CDTV OS 2.35 by that point in time, so I shelved the Patch-O-Tron and just updated the Docker image with the new ROM builds for A570/A690.
Finally, there has also been a welcome development in the wider Amiga world. In August 2026, Amiga Corporation and Hyperion announced a settlement ending their ongoing legal disputes. This gives me hope that distributing future CDTV Land ROM releases through official Amiga channels may finally become a realistic possibility. Something I would like to clear up in that context: although CDTV Land’s CDTV OS releases are unofficial, Amiga Corporation has always been supportive of the effort. In fact, they offered to host the CDTV OS 2.35 patch on their own servers back in 2021 when I was in touch with them. I decided to host the patch myself, but I appreciated that offer then, and I still do. I would just like to dispel the myth of Amiga Corporation being this evil entity that is somehow opposed to CDTV Land’s CDTV OS updates.
What the future will bring in terms of official distribution remains to be seen. There are legal t’s to cross and i’s to dot, and a settlement between the Amiga parties does not automatically give this project a distribution agreement. That still needs to be arranged. But where there’s a will, there’s a way. Making CDTV OS easier for people to obtain is something I would very much like to see happen, but only time will tell.
For now, I am pleased that some of the most stubborn technical work is finally done, and excited about what that makes possible next. There is plenty left that I, and like-minded people I have the pleasure of cooperating with, want to do with this machine. Thanks for reading, and for your patience while things were quiet here. An awful lot of that quiet was spent trying to get thirty-something-year-old hardware and considerably newer CPUs to agree with each other. 🙂
A heartfelt thank you goes out to the following persons, who were involved in making CDTV OS 2.36 a reality, whether through development, testing, offering suggestions, advice, moral support, or creating stuff that allows CDTV OS 2.36 to shine even more.
- CDTV Land team and friends: Chriskuta, Brufnus, Fastdruid, Oliver, Jasper79, LIV2, Stefan Reinauer.
- Captain Amygdala for creating PiStorm.
- Michal Schulz for creating Emu68.
- Arczi84 for adapting PiStorm bus arbitration firmware to work with CDTV DMAC.
- CDTV users all over the world for keeping CDTV alive!