exxos's Atari, Amiga & retro forum

Yep (rev 1)

I will gladly help testing as well. Also can burn my own ROMs. TF536 is Inside my CDTV and working amazing.

What was result?

Bartek has been sent the ROM for testing and the developer also now has a Viper530 fitted to their CDTV. Dalek has also asked to test and I'm trying to make that happen.

Thanks.

I've been testing several builds with alexh/bartek and the cdtv developer on my rev1 with latest rc3 firmware.

I was hoping at some stage when @terriblefire has some idle hands could he please send us a TF536 firmware build without the flashy boot rom at f00000? We are able to test other accelerators but stuck on the TF536 with what seems to be the leftover boot rom from the TF360 which hides the start of the cdtv extended rom.

Still a way to go but the developer has fixed a few things already and is aware of all the timing/buffer issues in cdtv.device. cdfs.library, strap and so on.

dalek wrote: 06 Jul 2021 14:35 I've been testing several builds with alexh/bartek and the cdtv developer on my rev1 with latest rc3 firmware.

I was hoping at some stage when @terriblefire has some idle hands could he please send us a TF536 firmware build without the flashy boot rom at f00000? We are able to test other accelerators but stuck on the TF536 with what seems to be the leftover boot rom from the TF360 which hides the start of the cdtv extended rom.

Still a way to go but the developer has fixed a few things already and is aware of all the timing/buffer issues in cdtv.device. cdfs.library, strap and so on.

Yeah i could do that after i get back from vacation.

terriblefire wrote: 06 Jul 2021 23:00 Yeah i could do that after i get back from vacation.

Thanks! Enjoy your holidays :)

Hi all, quick introduction: I’m the guy who has been working on bugfixing/patching various resident modules in the CDTV OS ROM to get the CD-ROM drive working under ’030/32-bit Fast RAM.. My intention is to make the ROM images available free of charge to anyone who wants them. I am not interested in any financial gain. In fact, this has only made me poorer so far and had me questioning my sanity many times, but has been worth it.

I’ve used Ghidra to resource cdtv.device, cdstrap, cdfs.library and bookmark.device so they can be built with vasm and I’m using Commodore’s DoBuild to build proper ROM images (I guess amitools will work just as well, but this is what I started out with and I’m too lazy to switch atm). Besides the aforementioned AllocMems that needed fixing in cdtv.device, cdstrap and cdfs.lib it was also necessary to disable caching for the DMAC Autoconfig I/O address space, disable caching of the CDTV Extended ROM space, and tweak the timing of some calls to the TriPort interface by inserting a NOP between two subsequent writes to a TriPort register. Even with all caching disabled, the 68030 still seems to be a tad too fast for the 6525 and will give unpredictable results with the original ROM code (it fails to put the CD-ROM drive in command mode every now and then which results in DMA timeouts and stalled I/Os). Maybe it’s due to the more advanced pipelining of the 68030, but that’s really beyond my level of expertise. There’s still one edge case in CMD_READ that needs a timer.device based wait to replace a busy loop, and I had it in place, but it needs refactoring because of the messy way IORequests work (the code can be run under the calling Task’s context or the device driver Task context which is a bit of a headache to handle).

Regarding the 68030 CPU caching: My current implementation uses the MMU’s TT0 register to disable caching for the whole 24-bit address range using a resident module with high priority (unfortunately 16MB is the finest granularity the TTx registers allow). This coarse method is used instead of MMU tables, because ROM space is very limited (this only costs me one PMOVE instruction). Of course, this is only done if a 68030 is detected. The idea behind this is that this guarantees a functioning CD-ROM drive on systems that don’t have MMU.lib installed. E.g. when booting off a CD-ROM or floppy. Users with MMU.lib can configure a more finegrained cache-inhibit for the DMAC Autoconfig area and the CDTV OS ROMs once the system boots up.

The ROMs will also include further bugfixes for bookmark.device, cdg.library and other small improvements.

The current dev build works rock solid on my Viper 530 (68030/50Mhz), but I really want to make it work with the TF536 as well. Early tests by dalek are encouraging (he managed to boot and play Xenon II amongst other things), but there are some outstanding issues and I will probably be able to iterate faster and rule out setup specific issues with with a TF536 of my own, which is currently being built to order for me (thx go0se!!!).

@terriblefire: I have thankfully used your research into the AllocMem issue for this project. Although I haven’t used your resourced cdtv.device (I had disassembled, but not resourced, cdtv.device 1.0 a long time ago for an unrelated project and ultimately resourced the 2.30 as well), but your resourced cdtv.device did help me understand some sections of cdtv.device that I did not understand previously, for which I owe you a debt of gratitude. I want to keep circulation of the alpha and beta builds of my ROM images to a minimum, but if you want a copy, just drop me a PM. That also goes for anyone else who has a 68030 and a CDTV player and wants to test drive (just don’t blame me if your CDTV catches fire ;-) )

This project hasn’t been publicly announced anywhere yet (except here, now), but I expect that should happen soon once I get some loose ends tied up.

Excellent work. This is what's been missing from the CDTV for years.