CD BIOS questions

[Songbird]

Starting a new thread on CD BIOS and emulation questions...

 

First up is CD_ptr. I am having a problem getting another game to emulate, and it appears to be because CD_ptr never returns the correct value, even though there is no CD hardware in JagCDU thus I am hard-coding the value. Here is the original Atari CD BIOS code:

;****************************************************************
;		CD_ptr						*
;								*
; This call returns the address that the data transfers from	*
; the CD are currently at. This address will change in jumps.	*
; The size of these jumps may change at any time.		*
; This call also returns the position of the last detected read	*
; error since the start of the last CD_read command		*
;								*
;	Input:  NADA						*
;	 							*
;								*
;	Uses: NADA						*
;								*
;								*
;	Returns: a0	Address of last written data		*
;		 a1	Approximate address of most recent error*
;								*
;****************************************************************

ptr:
	move.l	PTRLOC,a0	; Get address of data
	move.l	a0,a1		; Get address of error
	add.l	#8,a1
	move.l	(a0),a0		; Get current address
	move.l	(a1),a1		; Get error address
	rts

PTRLOC resolves to $3074, and I can see a long word of zeroes in this space right after the BIOS jump table which appears correct. The thing I don't understand is why the code dereferences a0 or a1. It appears that the value stored at PTRLOC is moved to a0, then copied to a1, then 8 is added to a1. That should already give you the last read address in a0 and an approximate error address in a1 without any dereference. So this looks like a bug to me from the original BIOS.

 

Does this sound correct, or am I misreading something?

Edited June 24, 2016 by Songbird

[Songbird]

OK, after further analysis, I don't think the original code has a bug. I do think it's my JagCDU code that has the problem since I'm not actually doing a transfer using the RISC processors. I therefore need to modify CD_ptr to behave differently in emulation. So I will need to do some testing but I'm pretty sure there is no issue here with the original code.

[Fredifredo]

May be Orion_ can help you ? I did a lot of things for the JagCD ( http://onorisoft.free.fr/retro.htm )

[Songbird]

My original premise was wrong, so really the first question in this thread is a non-issue. The way the Atari code worked was to use PTRLOC as a pointer to where the current address and approximate error address were stored. Because of how I implemented JagCDU emulation, I no longer need to do that. CD_ptr generates a "fake" error address now, and if I need it to generate a real one at some point to make emulation work for other CD games, I can enhance the function pretty easily.

[JagChris]

You can always ask Mike Fulton. He's around here.

[Fredifredo]

I found something in an old CD from B&C

 

"

CDROM BIOS Assumptions

The current CDROM BIOS is based on the behavior of the BUTCH ASIC in combination with the DSA command interface to the Philips CD mechanism.

 

The following DSA codes are used:

$15/mode Set mode, This assumes the status is returned

$70/dac mode Set DAC mode, works only in audio mode, response is required and checked for error.

$18/session # Spin up at the specified session, response is required and checked for error.

$2/xx Stop the CD, response is required and checked for error.

$51/volume Set volume; Two values are currently used 0 (mute) and $ff (full volume), response is required and checked for error.

$4/xx Pause, response is required and checked for error.

$5/xx Pause release, response is required and checked for error.

$14/session # Read Long TOC, returns TOC information as documented.

$3/session # Read TOC, returns TOC information as documented.

$54/xx Get session information, response is required as documented.

$10/xx These three produce the Goto Time command

$11/xx

$12/xx

$50/xx Get disc status, response is required as documented.

Butch is used to send and receive ALL DSA data.

The bit setting and clearing as well as the latch clearing is assumed to be the same as in the current Butch chip.

 

Data is also read via the Butch chip.

The sequence used is:

1) The Butch FIFO is flushed

2) A Goto Time sequence is sent to the CD unit.

3) Butch is set up to interrupt when the Found is returned (this is checked for error).

4) Butch is set up to interrupt on the half full flag.

5) Data is read out of the FIFO 32 bytes per interrupt. This is done by reading $DFFF28 followed by reading $DFFF24. These reads are done either in a loop and interleaved with two writes or 8 reads are done at a time followed by 8 writes."