Cd32 audio read routines using hardware

[jotd]

Hi

I ve got everything i need to read files from cd but psygore cd loader lacks audio play. I suppose it is mych simpler but still i dont have a clue how to do it.

[Cylon]

You could open cd.device and choose cmd cd_playtrack? Or do you want to _read_ audiotracks?

[Galahad/FLT]

Originally Posted by Cylon

You could open cd.device and choose cmd cd_playtrack? Or do you want to _read_ audiotracks?

He wants to play CD Audio without using the system to do it.

[Cylon]

Ah, ok. I am not allowed to post cd.device in src. Sorry.

[jotd]

I can get info from cd.device src myself. Good idea.

[Toni Wilen]

CD play uses same command as data read. Data read has bit 7 set in command byte offset 7, playback has bit cleared.

Send the command, send unpause, playback starts. Nothing else is needed, no DMA, no buffers.

Use of PIO mode to send and read status may be even easier than using DMA to send/receive commands, also keeps CD playback from stepping on data loader's toes. (I can try writing simple example later this week, this is also interesting never used PIO test case..).

Command is something like:
x4 MM SS FF MM SS FF 00 00 00 04 00 yy

First MSF = start, second MSF = stop position, x = index count, yy = checksum)

Note that CD32 does not have "play track x" command, only MSF to MSF.

[jotd]

thanks Toni.

You mean that I have to read TOC to know where to start/stop?

An example will be much appreciated.

[Toni Wilen]

Originally Posted by jotd

You mean that I have to read TOC to know where to start/stop?

Yeah but it probably is much easier to find out location of TOC in memory that loader used in cd32load loads at startup. Reading TOC is not simple single read operation.

[Toni Wilen]

Very ugly and minimal experimental CD32 CD audio "player" source attached.

- Direct Akiko hardware access
- Uses PIO CD command/status send/receive mode that no one has ever used before! (as far as I know)
- Real CD32 confirmed working
- WinUAE 3.3.1 development version required if you want to test it in emulation. 3.3.0 or older don't support Akiko PIO mode. (http://www.winuae.net/files/b/winuae.7z)
- Hardcoded to play from 00:02:00 to 01:00:00 (MSF format). Does not read TOC.
- Reads and validates status packets from CD but does not do anything with them. This is needed if you want to know when CD play ends or if some error happened.
- Stores status packets in 64k circular buffer, useful for testing what real hardware returns when trying to send invalid commands or bad parameters.
- Toggles CD led every 2 seconds. Just because I wanted some extra
- Press mouse to exit.

TODO: TOC and status packet handling. No guarantees if I feel interested enough..

EDIT: CD play status handling will be done soon.. (Detect when play command endpos has been reached)

[jotd]

Thanks Toni! I guess I could read CD TOC using Psygore "read sector" command and exploit it.

Now I've got a lot of work to do to assemble that and make the first game work.

[Toni Wilen]

Originally Posted by jotd

I guess I could read CD TOC using Psygore "read sector" command and exploit it.

It isn't that simple. TOC is not a data sector, it is subchannel data from LBA -150 to 0 (MSF 00:00:00 to 00:02:00), before actual data/audio sectors start.

Reading is two step process:
- Start "playing" from 00:00:00
- CD microcontroller starts sending TOC entry status packets, parse and convert them to more usable format.

I'll do this, it isn't that complex.

[jotd]

CD32load will soon be written by JOTD / Psygore / Toni Wilen. Thanks!

[Toni Wilen]

TOC reading works now in emulation. Real hardware testing and tweaking tomorrow..

[Toni Wilen]

I lied, I quickly transferred it and it did work immediately. (I expected lots of debugging..)

New version attached.

Updates:
- Reads TOC.
- Uses now TOC data to select track.
- Exits when play end position has been reached.

EDIT: above winuae supports -cd32log and -cd32log2 (even more cd32 logging). Should help with debugging. This was previously compile time setting.

[jotd]

Great work!
Questions:
- so statusout needs $10000 bytes of memory to work right?
- I don't see where you tell which track to play (I basically need to play a track/stop it from playing/check if it is playing)
- when does level 2 interrupt happen?

[Cylon]

should be this:

skiptoc
	lea cmd_unpause(pc),a0
	bsr.w sendcmd

	moveq #2,d0 ;track number to play (1-99)

Track #1 is usually data.

[Toni Wilen]

Originally Posted by jotd

- so statusout needs $10000 bytes of memory to work right?

No. It is just for debugging. Longest status packet is 21 bytes. (20 + checksum)

I'll update it with optional "debug" features..

- when does level 2 interrupt happen?

Anytime

It may come immediately after enable Akiko receive interrupt if there is something buffered (someone left some data). Most commands return some status data, especially TOC read can return hundreds of bytes of data.

You probably have level 2 interrupt already, just add bit #29 check from b8000004 check, if set, run "my" interrupt code (and remove the CIA access at the end!). If not, run normal level2 code.

[Toni Wilen]

Update attached.

- Debug option added, without it status output buffer can be very small.
- Some misc changes.

[jotd]

Thanks Toni.

just a few more questions:

* bcdtens
dc.b 0,10,20,30,40,50,60,70,80,90
=> isn't there a bug? this is not a BCD table but rather a decimal table am I right?

* you said it had never been done before, so how was it done?

* AFAIR no NDOS game like RNLoader used CD audio during game, except for Lotus I so I guess RN routines must have CD play/stop commands, that plus the fact that there are 13 commands and only 3 that I have identified as useful for disk reading.

I'll try to adapt that to CD32load. Could take some time, but all the logic is there so it's cool!

[Toni Wilen]

Originally Posted by jotd

* bcdtens
dc.b 0,10,20,30,40,50,60,70,80,90
=> isn't there a bug? this is not a BCD table but rather a decimal table am I right?

Ignore the label name, it is used to convert upper nybble of BCD to decimal, I didn't want to use multiplication

* you said it had never been done before, so how was it done?

I tried to match (after your report!) Akiko register area reads with real hardware. All the other unknown registers were only mirrors of existing registers (or returned only zeros) except address $28 which was interesting.

You also noticed it did not return static value. I did more tests and I noticed it seemed to always return last status byte from CD. That was big clue.

I tried writing commands to it and then check what $28 reads, it did work! Finding out related interrupt bits was not that difficult because there was only 2 unused ones.