Jump to content
IGNORED

Access Jaguar CD from Skunkboard-loaded code?


Recommended Posts

I thought I'd be clever and test my Cinepak demo changes by putting a working cinepak video disk into the jaguar CD and then uploading the demo/player program I built using my skunkboard.  However, it just sits there on the Atari licensing logo.  The CD doesn't even seem to spin up.

 

Does anyone know if I need to do something extra to initialize the Jag CD when I'm running code from the skunk, or from BJL for that matter?  Init something that got skipped in the CD BIOS for example?  Manually read in the disc TOC?

Link to comment
Share on other sites

  • Swear
  • Copy the BIOS to $3000
  • Swear
  • Call CD_setup
  • Swear
  • Call CD_mode
  • Swear some more, invoke curses
  • Call CD_initm
  • Call upon all you hold dear to smite something, anything
  • Start the GPU code
  • Wonder in bemusement at whoever thought this was a good idea
  • Call CD_gettoc (@$2c00)

 

and then you can use CD_read

 

..maybe... if the Gods smile on you... and the Drive actually spins.... and the planets align.... and you don't get a read error.

 

Good luck, you are gonna need it.

  • Like 1
  • Thanks 1
  • Haha 2
Link to comment
Share on other sites

16 hours ago, CyranoJ said:
  • Swear
  • Copy the BIOS to $3000
  • Swear
  • Call CD_setup
  • Swear
  • Call CD_mode
  • Swear some more, invoke curses
  • Call CD_initm
  • Call upon all you hold dear to smite something, anything
  • Start the GPU code
  • Wonder in bemusement at whoever thought this was a good idea
  • Call CD_gettoc (@$2c00)

 

and then you can use CD_read

Hehe, thanks.  Including the swearing, the only thing unique to the skunk here is  the "Copy the BIOS to $3000" part, right?  Is the physical BIOS ROM accessible from my code, or will I just need to -ii a copy of it into my program when compiling?

Link to comment
Share on other sites

1 minute ago, cubanismo said:

Hehe, thanks.  Including the swearing, the only thing unique to the skunk here is  the "Copy the BIOS to $3000" part, right?  Is the physical BIOS ROM accessible from my code, or will I just need to -ii a copy of it into my program when compiling?

You can get to it by 'banking in' the Jaguar CD, or just copy the binary to $3000 (which is easier)

Link to comment
Share on other sites

Hrm, I must have skipped too many of the cursing and swearing steps.  I did some reading I should have done before asking here (The "Jaguar CD-ROM" chapter of the Atari docs) and noticed the CD_getoc step is unique to non-boot CD usage as well, but I'm not even getting that far.  I dropped a bunch of skunk console writes in and the code doesn't make it past "jsr CD_mode" right at the beginning.  I used this little jcp script to load the CD bios, based on the .db script from Belboz's SDK:

jcp -n "${JAG_CDFILES}/cdbios45.tx" 0x3000
jcp -n "${JAG_CDFILES}/cdbios45.dta" 0x3e00

The cpkdemo code does things in a slightly different order than suggested by @CyranoJ:

  • CD_setup
  • CD_mode <- Never returns from this
  • -> Inserted my CD_getoc here, as suggested in the Jaguar CD-ROM docs, much earlier than suggested, but it's not getting here regardless.
  • Start the GPU
  • CD_initf

I couldn't glean anything from the VLM cdboot code.  I looked at the BIOS code and CD_mode seems to loop (until the mode is acked?) infinitely, so I assume that's where things are stuck.  printf is about the limit of my jag debugging skills at this point.  Any suggestions on things I should poke at, and how to poke them?  I'm hoping I don't have to go sprinkle skunk console writes all over the CDBIOS and rebuild it (Thanks for the pointer to the source though).  Is it possible the Skunk is interfering with the I2S communication or something?  Has someone actually bootstrapped the CDROM successfully from a skunk boot, or am I potentially attempting the impossible here?  I know there was talk of emulated CD support on the skunk at some point, but I kind of assumed that would just be done by re-implementing all the BIOS calls in terms of host or USB dongle reads, not using actual I2S.

Link to comment
Share on other sites

		move.w  #$1865,$f00000
		move.l  #0,$dfff00            			; Switch off CD-Boot-image!

		lea		cdbios_start(pc),a0				; Install CD-Bios
		move.l  #(cdbios_e-cdbios_start)/4,d0	
		lea		$3000.w,a1
bios:	move.l  (a0)+,(a1)+
		dbra    d0,bios

		lea		$27d0.w,a7						; relocate the stack somewhere safe

		jsr     CD_setup.w          			; Always call this first for CDs!

		moveq	#3,D0               			; Set mode to data, 2X speed
		jsr     CD_mode.w 

		lea		GPUCODE_START(pc),A0			; install GPU code
		lea		GPUCODE_END(pc),A1
		move.l  A0,D1 
		move.l  A1,D0 
		sub.l   D1,D0			    
		asr.l   #2,D0 
		movea.l #G_RAM,A1
GPUint:	move.l  (A0)+,(A1)+ 
		dbf     D0,GPUint

		movea.l #$F030C4,A0      				; where to store the requested read-function 
		jsr     CD_init.w

		move.l  #$F03050,G_PC
		move.l  #1,G_CTRL           			; start GPU

		lea     $2C00.w,a0
		jsr     CD_getoc						; load CD TOC

;;; should be good to go here!

	.QPHRASE
    dc.b    $4A,$FC,$00,$00,$00,$00
GPUCODE_START:
    dc.b    $98,$1E 
    dc.b    $30,$68,$00,$F0,$D3,$C0,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$E4,$00 
    dc.b    $E4,$00,$E4,$00,$E4,$00,$98,$00 
    dc.b    $21,$00,$00,$F0,$A4,$01,$38,$81 
    dc.b    $BC,$01,$98,$1F,$30,$C4,$00,$F0 
    dc.b    $E4,$00,$D7,$C0,$E4,$00,$8C,$1E 
    dc.b    $39,$3E,$98,$1D,$21,$00,$00,$F0 
    dc.b    $BF,$BE,$8C,$1E,$98,$1D,$21,$14 
    dc.b    $00,$F0,$BF,$BE,$E4,$00,$E4,$00
    dcb.w   147,0 	
GPUCODE_END:

cdbios_start: incbin "CDBIOS.BIN"
cdbios_e:


CDBIOS.BIN

That might help :)

  • Like 1
Link to comment
Share on other sites

OK, this is weird.  That code does not seem to work on its own.  However, there are some interesting things I learned by toying with it:

 

* It seems to get further than I was before, but it's hard to tell because...

* This line initializing MEMCON1 causes the skunkCONSOLEWRITE function to misbehave:

move.w  #$1865,$f00000

Sometimes it writes half of the lines, sometimes it skips console writes entirely, etc.  I think this is because the correct value for the skunk is $1863 (from my understanding, the skunk behaves like a 16-bit ROM)

* Dropping that line in cpkdemo's player.s gets it working with my existing modifications to read the TOC.  Sort of.  The CD spins up, the TOC clearly gets read, and things start playing. I'm hearing sound but there's no video.  The lack of video might be an issue with the cpkdemo code itself though, since this is the farthest I've gotten with that code so far, and my debug prints aren't working ?

* I didn't even have to manually download the CD BIOS for cpkdemo to work.  It appears to already be loaded at $3000 before the CD unit boots the skunk BIOS/loader code.

 

So the question now is: Why does setting what appears to be an incorrect value in MEMCON1 cause the CD BIOS code to work?  I'm going to try dumping the initial value of MEMCON1 before it's modified to verify it is indeed "incorrect," but this just seems weird either way.  The CD BIOS code shouldn't even be accessing the ROM, should it?  Maybe the other fields, like IOSPEED, are to blame though.  Will have to see.

Edited by cubanismo
s/rid/read
Link to comment
Share on other sites

MEMCON1 from boot on the skunk appears to be 0x187B.  ROMWIDTH=0x1 (16 bits), ROMSPEED=0x3 (5 cycles) Vs. ROMWIDTH=0x2 (32 bits), ROMSPEED=0x0 (10 cycles) from the sample code above.  Other fields match the sample code above.  I tried messing with values in between:

  • 0x1863 (ROMWIDTH 16 bits, ROMSPEED 10 cycles) - CD code still didn't work.  skunk console works)
  • 0x187d (ROMWIDTH 32 bits, ROMSPEED 5 cycles) - CD code almost works, but the CD starts seeking back and forth instead of reading properly after reading TOC.  skunk console does not work)

So I'm stumped again.  I don't know why the ROM width affects the CD BIOS behavior.  I'm going to go read the BIOS code some more.  Do the ROMWIDTH/ROMSPEED affect more than just the ROM address range?  I.e., are they affecting everything that routes through the cartridge/expansion slot?  I suppose that would explain why this matters.  I found this diagram that implies this:

But it's origin isn't clear.

 

I also noticed this post:

claims the CDROM BIOS is an 8-bit ROM, which seems contrary to what works here.  I did try setting an 8-bit ROM width as well, but it didn't work any better than a 16-bit ROM width.

Link to comment
Share on other sites

 Ah, I see the Jag CD Butch chip is mapped right at the ROM address range end, and the second line in your code makes sense now.  Well this sucks.  Is there no way to use the skunk HPI interfaces safely while also using Butch?  That would ruin my plan of debugging CD code via the skunk IO ?

Link to comment
Share on other sites

I did some more experiments that got me confident enough the CD is fully working now, and hacked around the skunklib interaction issue well enough I can make progress.  I hacked in the CD track parsing stuff from cpkdemo -> the "sample" player in the SDK and used that simpler code to verify I can indeed play video off the CD from a skunk-loaded player program, since I'd previously verified that code works using the non-CD path to load up a 6-second clip in DRAM.  That works fine with the MEMCON1 fix applied, so there's no issue with the CD access now.  Still working on debugging the cpkdemo lack of video.

 

To get skunk debug printouts working there, I just have to swap the MEMCON1 value before making skunklib calls.  Of course, this isn't really a valid solution when the GPU is doing CD stuff in its interrupt handler in parallel, but meh, so far when I need to send over a message, it means things already aren't working, so if it trips up the CD routines at that point, no big deal.

 

With a mind towards improving the skunklib situation, a few questions that would save me some time experimenting/reading CD BIOS code if anyone knows the answers already:

  1. Is it safe to disable the DSP interrupt on the GPU to halt CD BIOS accesses while CD ops are in progress (I'd do this when entering a skunk HPI operation)?  If so, safe to disable it indefinitely, or only for small increments of time (Some skunklib ops like file writes take quite a while)?
  2. If this is feasible, would I have to patch the CD BIOS' interrupt handler to set some semaphore value to wait for existing interrupts to complete from the 68k, or is there some status bit I can look at to determine if it's active at any given moment?

If those questions have productive answers, I could probably put together a new CD-safe version of skunk.s.  If not, probably not worth the effort unless someone has other clever ideas.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Realized I forgot to follow up on a few things here:

On 6/17/2020 at 11:08 PM, cubanismo said:

That code does not seem to work on its own. 

I now think @CyranoJ's code does work fine on its own.  Sorry for the false claim.  The problem was my efforts to verify it relied on skunklib console printouts, which I obviously later found don't work while using the CD unit's MEMCON values.

 

On 6/19/2020 at 12:40 AM, cubanismo said:

Still working on debugging the cpkdemo lack of video.

This was a fun one to debug in the end.  Both the Atari standard startup.s code cpkdemo uses and the cpkdemo's own object list code in makelist.s use a function called "InitLister" to set up the list.  The bsr to this function in the main player init code was resolving to the startup.s version in my builds, and presumably the makelist.s version in everyone else's builds, so no matter how much I tweaked the code to just fill the screen with red or whatever, I always just got a blank screen because the object processor wasn't even using my framebuffers.  The fix was to rename the makelist.s version of the function, and everything worked fine.

 

I don't know for sure why my build resolved the symbol differently, but it's likely one of two things:

  • I reworked the makefile from scratch as I have it all integrated with my revamped version of Belboz's SDK environment that uses a bunch of common makefile helper fragments and stuff.  I didn't check, but I very likely reordered the object list passed to the linker.  Hopefully I can clean up this SDK environment and make public soon as well.  There's a bunch of other goodies in here I hope people will find useful, and it'd be a great base for something like @LinkoVitch's continuous integration docker image.
  • I'm probably the first person linking this with rln, since without some patches I have locally, rln can't link the Alcyon-format cinepak binary-only object file cpkdemo relies on.  I've been meaning to clean these up and share them forever too, but haven't gotten around to it yet.  I'll do that real soon now, but given the overwhelming interest in the cinefix thread, I doubt anyone else cares that much.
  • Like 1
Link to comment
Share on other sites

40 minutes ago, cubanismo said:

I now think @CyranoJ's code does work fine on its own.  Sorry for the false claim.  The problem was my efforts to verify it relied on skunklib console printouts, which I obviously later found don't work while using the CD unit's MEMCON values.

 

Phew! Because otherwise all those ULS CD's wouldn't boot :D

  • Haha 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...