TascoDLX wrote:The model 1 bios decompresses the subcpu bios to a full 22KB, with 14 trailing zero bytes. Range is $000000 thru $0057FF.
The laseractive bios decompresses the subcpu (CD) bios without the 14 trailing zero bytes. Range is $000000 thru $0057F1.
Since the checksum is calculated from $000200 thru $0057FF, those 14 zero bytes are fairly important. You probably don't need to clear any more than that as far as the bios is concerned.
Aha, good to know. I was wondering what the cause was.
At this stage, I can open the LD drive tray and load a new disk, I just need to work out the bios command to read data from the disk. The command I thought was for reading data starts the first video track playing when I call it.
If you want more extensive notes on the LD bios, I might be able to help. The stuff I posted in the other thread is pretty condensed.
More notes would be great, the more the better. That said, I think I've found the cause of my troubles. I think you're right about 0x0120 being the code for the ROMREAD function, but they've changed the arguments. The function now needs a mode flag as a parameter to select between ROMREAD, ROMREADN, and ROMREADE, and there's only a single entry point.
I've made and been using an LDBIOS.INC file for my code, which I've based on the official CDBIOS.INC file from Sega's SDK. Here's my notes for the ROMREAD function on the LaserActive, as I typed them up this morning:
Code: Select all
; BIOS_ROMREAD - Begins reading data from the CDROM at the designated
; logical sector. The read continues until either no more data is
; received, the specified number of sectors have been read, or the
; target sector has been reached, dependending on the value specified in
; the ROMREADMODE flag.
; d0.w ROMREADMODE flag. If invalid, acts as if d1 != 0.
; d1.b Video playback flag? Seems to start video playing if not equal to 0.
; a0.l The way this is interpreted depends on the value of d0
; d0.w = ROMREADMODE_D ($120):
; a0.l address of a 32 bit logical sector number to read from
; d0.w = ROMREADMODE_N ($121):
; a0.l address of a 32 bit sector number and 32 bit sector count
; dc.l $00000001 ; First sector to read
; dc.l $00001234 ; Number of sectors to read
; d0.w = ROMREADMODE_E ($122):
; a0.l address of table of 32 bit logical sector numbers
; dc.l $00000001 ; First sector to read
; dc.l $00000123 ; Last sector to read
; cc Command has been executed
; cs Failure (Arguments were invalid)
; d1.w Result:
; $0000 = Command has been executed
; $0100 = Failure (Arguments were invalid)
I'm going to try running my dumping program again this evening using these results, and see if I can successfully read data off the disk.
Chilly Willy wrote:
Thanks for pointing that out - if it doesn't work for Nemesis on his LA, I'll make that part assembly and try again.
As to why you need to clear the ram, that's one of those "whoopsi!" events.
Seriously, checking the checksum over a range not covered by the archived code? How hard would it have been to add 14 zeroes COMPRESSED to the compressed bios? Someone did the compressed block and then probably didn't notice their error because the clearing code covered for them.
Well, I've noticed both the LaserActive bios and the standard MegaCD bioses clear the entire range of program memory in all 4 banked pages on doing a reset, it just happens in slightly different places in the code. That was probably just a bug they never knew was there, because they were always clearing the memory from day one. I'm doing a full clear of all 4 memory pages in my boot code, just in case.
In terms of bugs, I've also noticed there was code that was supposed to clear the full word ram when doing a reset, but it was completely broken in all the 1.X MegaCD bios versions, including on the LaserActive. Check the subroutine at 0x79C in the v1.00 USA SegaCD bios. Not only were they testing $A12002 (the write protect register) instead of $A12003 when trying to check if the word ram mode and assignment status, they also wrote the clear data to (a0) instead of (a0)+, so at best, it would only have cleared the first long-word of the word ram. They didn't fix this until the v2.XX bios versions. I'm sure there are more than a few other bugs in there.
TascoDLX wrote:...I don't know if the reset sequence has any timing requirements...
I want to do more testing on that later too, I suspect the timing isn't important, just the order. If I was to speculate, I'd say that internally, a reset is performed if the device responsible sees the sequence of writes 0x03, 0x02, 0x00 to register 0xA12001, while the write protect flags are all set. I suspect doing repeated writes of 0x03, 0x02, 0x00 will continue to perform a reset, as long as the write protect flags all remain set, and I suspect doing full word-wide writes of 0xFF03, 0xFF02, 0xFF00 to 0xA12000 would work too. This is all speculation though.