Anyone every coded a CDTV data read routine without using the OS ?

[jotd]

I want to extend CD32Load so it supports the CDTV drive.

For CD32 there's Rob Northen CD loader, then modified by Psygore to read partial files. I already figured out the part where it loads CD sectors (2048 bytes, cooked) into memory.

But for CDTV there's nothing. I got access to cdtv.device (resourced by Stephen J. Leary, now taken down from github apparently) but of course it uses the system and tasks and interrupts, and signals...

I wanted to create a simple code to read sectors but I have a hard time doing it. There's the scsi command then the DMA, then... It's not possible to use this cdtv.device as-is as the games I want to run kill the OS. And I want to avoid preloading the files (JST already does that) or swapping the OS (not enough mem), to be able to run 512k chip OS killer games on CDTV.

Rob Northen routine didn't install a level 2 interrupt, it just polled interrupt handler. What I'm looking for is:


reading sectors into memory by only banging into CDTV device base ($E90000)

So I can replace/switch to this routine and be able to run most 512k NDOS/OS killer games on a CDTV. A few examples

- Magic Pockets
- Chuck Rock
- Leander

those use files too big that they can't be preloaded on the remaining 512k. But with hardware CD loading they could run.

Handling audio would be a bonus, pretty much useless at the time being.

for example init code would be:

MPS6525_PRA EQU $b1
MPS6525_PRB EQU $b3
MPS6525_PRC EQU $b5
MPS6525_DDRA EQU $b7
MPS6525_DDRB EQU $b9
MPS6525_DDRC EQU $bb
MPS6525_CR EQU $bd
MPS6525_AIR EQU $bf

lea $E90000,A5
move.b #0,MPS6525_DDRA(a5)
move.b #$FF,MPS6525_PRB(a5)
move.b #$FF,MPS6525_DDRB(a5)
move.b #$20,MPS6525_PRC(a5)
move.b #0,MPS6525_DDRC(a5)

[Toni Wilen]

I am quite sure no one has ever done it. Most likely due to lack of information. It isn't as "automatic" as CD32, lots of signals need to manually read and set using 6525 "triport" IO chip and DMAC.

I have been planning to do audio CD playback software (like I did for CD32) for years now but never found enough time and interest.. Technically it should not be that difficult.

Get 6525 datasheet and CDTV schematics first. It will help greatly.

I can help when there is some code

[jotd]

Hi Toni

Great news. I was saying to myself that I was asking too much. Probably reading the schematics and all should help, but I'm not an electronics kind of guy

So I assembled a quick patchwork of the resourced cdtv device I had, polled the interrupts and I could read the track I wanted It's pretty simple once you know which registers to write to. As you said once, the DMA is able to write the tracks directly into memory, without having to post-process them.

Now I have to figure out how to handle errors, no disk in drive and all, but at least the nominal case works (well on WinUAE that is... I don't have a real CDTV machine anyway)

(and I didn't know that audio wasn't supported yet, not sure if there are a lot of games around supporting it... and if there are, they probably run perfectly on winuae with CD32 setup )

That's really beyond all my expectationsfor that week, I've wanted to do that job for a long time now, never had the courage, and now in 2 hours after discovering the resourced cdtv device code I did something that works.

(the resourced cdtv device code must have taken quite some time to Stephen, now it's used for the gaming cause )

[Toni Wilen]

Originally Posted by jotd

Hi Toni

Great news. I was saying to myself that I was asking too much. Probably reading the schematics and all should help, but I'm not an electronics kind of guy

There is no need to understand electronics much. Schematics still can be used to confirm 6525 IO pin connections. Basically every status signal connects to 6525.

For example one of the signals is called /STCH (="status change") which CD activates when mechanism wants to tell that something changed (CD removed, inserted, CD play stop etc). NOTE: active low.

All required registers (base+):

0x41: DMAC ISTR
0x43: DMAC CNTR
0xA1: CD command register (read replies, write command bytes)
0x80: DMAC WTC (length)
0x84: DMAC ACR (address)
0xb0-0xbe: 6525 (0=register 0, 2=register 1,4=register 2,..)
0xe0: DMAC START
0xe2: DMAC STOP
0xe4: DMAC CINT (clear interrupt)
0xe8: DMAC FLUSH

btw, usual warning: because there are no other drivers than CDTV ROM built-in, emulation most likely isn't always correct. (Correct as in what hardware actually does but only "correct enough" to work with the driver)

[jotd]

Yes Toni that's normal. The routine needs to be tested on CDTV (that I don't have...) because of possible timing issues, little surprises... like the CD32.

thanks for the support.

[CaptFuture]

I somehow missed this thread initially. The answer to your question is: yes, I have :-)

My goal was more or less the same as yours, jotd, although I was planning to directly patch games so as to reduce the amount of memory even further and allow many 1MB games to be patched too. I started this project a few years ago by reverse engineering cdtv.device (before Stephen did even) and I even have a proof of concept, but I got side tracked (as I usually do). The goal for this code is to run on unmodified stock CDTV players (1MB Chip, 68000, remote controller).

I have implemented direct sector reads, but also very rudimentary ISO9660 support so you can even load files by using the filename. It even compensates for the DMA bug by using an internal buffer and padding the reads. Basic CDDA playback support is also there as well as bookmark and cardmark support. The code is highly unoptimized and the loads disable all intrerrupts and just poll the DMAC ISTR register to see when a transfer is done, but it works fine without the OS present :-)

The reason why the project has stalled is because like an idiot I decided to choose Batman: The Movie as the first game to patch, which is really 3 different games in one. It also suffered from feature creep, because I kept adding stuff like second controller button suport in some levels, adding in the copper backgrounds from the Atari ST version of the game on the racing levels, implemented a pause menu with preferences, selectable CD audio music soundtracks, multi language support based on CDTV language settings (it does English, Dutch and German atm) and saving and reading hiscores and prefs from bookmark memory. What started as a reference patch/example of how to use my library has now ballooned into a bloated, over engineered piece of code which is the worst possible exampe of how to use my library :-)

The library code itself is still very much buggy and alpha status, but I guess I could throw it on GitHub in the near future including maybe the patch source to Batman: The Movie. It might motivate me to actually finish this library and hopefully even motivate others to contribute. It was always my intention to open source all of this. I understand your use case is different, but my code is written pretty modular so you can copy/rip the pieces you are interested in for your project. All code is written 100% relocatable.

[jotd]

that would be a good boost for my CDTVload project (like CD32load but for CDTV).

Personally I just used Stephen resourced CDTV device to read a track but no ISO support, etc... so I was planning to merge CD32 loading module (which works) with CDTV raw read but it's more complicated as it seems.

Next idea was to rewrite raw to ISO read in C and integrate the sector read. But didn't do it.

So your project would be perfect for my CDTVLoad project. And patching games directly using your code is a waste of time anyway, since whdload slaves already do it, plus protection removal plus 2/3 button support, etc...

[alexh]

The person re-writing the CDTV Extended ROM to work with accelerators with 32-bit fast RAM understands more about the low-level workings of the CDTV and the OS components than anyone I've ever met. He has recently re-sourced cdfs.library to fix bugs with timers (which were just loops that don't work with 030+).

If anyone can do it or advise on how to it is Mijo Saftic.

https://cdtvland.com/

[CaptFuture]

Originally Posted by jotd

that would be a good boost for my CDTVload project (like CD32load but for CDTV).

I will see if I can push some code to GitHub next week. I need to add some docs to highlight bugs and general usage.

So your project would be perfect for my CDTVLoad project. And patching games directly using your code is a waste of time anyway, since whdload slaves already do it, plus protection removal plus 2/3 button support, etc...

LOL, I think you're being very presumptive in deciding what is or is not a waste of my time.

Slaves are fine for 512K games, but become problematic with a lot of 1MB games that do not have enough RAM left on the system to accomodate the slave and the cutdown WHDLoad implementation as well as the game code itself.

My library is currently 4K in size, 2K of which is a read buffer that could even be dropped if you can do non-buffered reads. I'm willing to bet that is a lot less than your CDTVLoad implementation and thus stands a much better chance of fitting in the constricted 1MB space of a stock CDTV player.

My use case also implements saving and reading to bookmark memory, so that CDTV users can finally save prefs and hiscores in games. The slaves do not support this CDTV specific functionality.

The downside is of course that it is a lot less scalable than leveraging slaves, because it requires manual patch work for every game, although many slaves are open sourced so they can be used as a reference. I think there is space for both CDTVLoad to do the low hanging fruit using slaves, and my solution to bring games to CDTV that could otherwise never work on a stock CDTV.

[CaptFuture]

Originally Posted by alexh

The person re-writing the CDTV Extended ROM to work with accelerators with 32-bit fast RAM understands more about the low-level workings of the CDTV and the OS components than anyone I've ever met. He has recently re-sourced cdfs.library to fix bugs with timers (which were just loops that don't work with 030+).

If anyone can do it or advise on how to it is Mijo Saftic.

https://cdtvland.com/

Well, yes. Guilty as charged, Alex. (Captain Future is my handle and that is my website). That is the "other" project I am working on that has caused this library to be put on the back burner. :-)

[jotd]

LOL, I think you're being very presumptive in deciding what is or is not a waste of my time.

let me rephrase that: you're not redoing all work behind all whdload ECS slaves singlehandedly, even by copying some code that is open sourced (where you'd have to credit the authors btw). Now you're the presumptive one lol.

About saving scores/etc... I gave that up on the CD32 for space reasons. I hope the CDTV bookmark space is big enough. The problem of those consoles is that you can't possibly hold all savegames/highscore for all games. You have to make choices.

If you share your source code, I'll try to reuse it to restart my project. And if I'll succeeed you'll get proper credit.

[CaptFuture]

Originally Posted by jotd

let me rephrase that: you're not redoing all work behind all whdload ECS slaves singlehandedly, even by copying some code that is open sourced (where you'd have to credit the authors btw). Now you're the presumptive one lol.

For someone who has been offered help, you seem to have a very odd way of communicating your responses. I don't expect an explicit thank you from you or anyone, but both your replies so far are giving off a very negative vibe.

Your first reply was a bit condescending, labeling a lot of my work as "a waste of time", without really knowing what my projects goals and personal goals are.

Your second reply is hinting at the possibility that I would copy other people's work, possibly not even crediting them in the process, which I find even more offensive. If you read my previous post, you'll see I wrote slaves can be "referenced" for which locations need patching. Nowhere did I suggest that flatout copying other people's work was the plan, and of course the original writers of the slave code would be acknowledged for their work, even when the code would be only used as a reference. I really don't like that you're hinting at the possibility that not crediting work of others is an option that I would be considering.

You're not really increasing my enthusiasm to help you with your project.

[jotd]

I'm very surprised as "waste of time" for me means: "waste of your time". It wasn't condescending, it's just that I've been down that route and it's frustrating to re-do what others have done, and stumble on the same issues etc. Better do what hasn't been done already. Just an advice.

You're the one who resurrected that old thread, now if you don't want to help anymore, well, bummer. I'll carry on with other projects. I don't even have a CDTV. Having some code ready to use would be an opportunity to create something quickly and which works to fill a gap for the CDTV community. But if there isn't an offer for you library anymore, well, too bad, I'll focus on something else.

[CaptFuture]

You're still free to use my library when it is released as it will be released under GPL. Or you can write your own, I don't really care what you do.