Yellowbook standard isn't applicable here. PCE cds predate that.
Meh, I would've responded sooner, but I lost a post a few days ago - browser crash. Anyway, you didn't at all find saying this counter-intuitive, that PCE CDs somehow predate Yellowbook ?? What else would they be following ?? They use Yellowbook mode 1 data sectors, they're not anything else, then you have the mixed mode CD layout, like the extended 3 second pregap rule when it comes to track type transitions that we were previously talking about, all of which comes from Yellowbook... Moreover, a CD-R is based on Orangebook which is meant to allow everyone to burn Redbook or Yellowbook type discs, and CD-Rs in fact work on all NEC systems (
burning software would only know how to do Yellowbook, not something custom NEC might've done) which also support CD+G discs, though that apparently came with an updated revision of Redbook.
Yellowbook is an extension to Redbook that was developed in
1985 by Sony and Phillips because the industry wanted reliable digital data storage (audio discs have no CRC checking) etc. You'd have to believe Hudson/NEC created their own data sector format here... No, they got licensing from Sony/Phillips obviously... I suspect you've been misled by inaccurate information, possibly by Wikipedia or other places... I discovered it because I was googling around enough trying to understand why you would've said this. So first note on the Compact Disc page, they have the correct information:
For the first few years of its existence, the CD was a medium used purely for audio. However, in 1985 the Yellow Book CD-ROM standard was established by Sony and Philips,
HOWEVER, on the CD-ROM page, they have a clear error:
"the Yellow Book, created by Sony and Philips in 1988, was the first extension of Compact Disc Digital Audio."
In actuality, all that happened in 1988 was that the ISO and ECMA groups adopted Yellowbook as a standard (
it was also extended, CD-ROM/XA, by adding "mode 2" type data sectors). They gave out free information with that standard too, whereas normally you had to pay Sony/Phillips to get a full copy of Yellowbook. Anyhow, it had in fact been around for 3 years, available for licensing from Sony/Phillips, so plenty of time for NEC to have developed a system around it. Wiki says that NEC released their first CD add-on unit in 1988 (I'm trusting it here), so yeah, that's 3 years later... That timeline fits! If both Yellowbook and NEC's CD unit were released in 1988, NEC would've had to work pretty damn fast to support it... But yeah, you can verify that many documents state 1985 as the year Yellowbook was developed (
it seems the 1988 error is widespread though). I just kept digging further which is how I found this error because reading that both were released in 1988 just didn't make sense; NEC couldn't have worked that fast so somebody had the wrong year. Sure enough, it was whatever wiki-knucklehead that edited that CD-ROM page.
Except thats not what I'm seeing in the code. The cd electronics has a register the holds the pq-code for the current frame. Bios monitors that register (and &'s it with a mask ) looking for a particular bit to be turned on. Then it starts loading into memory, and starts executing code when the read finishes.... (it's a 1 sector read, the ipl)
Please note, it is not requesting to read a particular sector. It checks the bit, and then starts reading....
As far as I can tell, it doesn't read the TOC until -after- it has checked for a bootable cd.
I'll keep looking into the bios, though. I haven't drilled all the way down into all of the routines to see what is going on.
Alright, I did a simple test to put this to bed. I put a plain music CD in a drive I have that has no top cover so I can fully see the laser (connected via IDE to USB) - it's a useful drive I have around for other purposes. Anyway, then I fired up some emulators, MagicEngine and Ootake, booted with the System Card 3, and within ONE second, the Audio CD Player menu had booted showing you all available tracks on the CD, ready to play 'em, etc. The laser never really moved from the inner-most center of the CD to the outer-most, it stayed right there at the beginning of the CD... So, simply put, that tells me that the BIOS read the TOC, looped through all tracks, detected them as all of type 'audio' and acted accordingly. The laser didn't seek from the start to the end of the CD as you have suggested, looking for the first sector that is of type data as the first course of action. Again, that info is all right in the TOC, so why would you first blindly seek-scan the whole disc
Don't get lost in BIOS assembly, just think intuitively about it...
I tried another test with Ys IV as well. I burned a test disc where I removed track 2 from the CUE file, so the whole disc was all audio, except for the final data track. So within a second, the laser flew from left to right, all the way to the end of the disc and started booting the game, etc. Booting took ~3 seconds once it was there.
What I don't know is how seeking works exactly though, is it efficient or blindly linear, like if you ask the laser to seek to a LBA that is at the end of the CD or wherever, does it predict/compute a distance to move so it can be done quickly, possibly over/under-shooting in the process and then read the sector's Q subcode data and move accordingly (recovering), OR, does it read every sector's Q subcode data from start to finish until it finally gets to that sector that was asked for, etc. Cause if it's completely linear, then your suggestion about seeking the first sector that is of type data makes sense - It'll work and you wouldn't have to know the exact LBA in this case.
But anyhow, the relevancy of the 2 tests is that it clearly knows *in advance* from the TOC whether all tracks are of type 'audio' (
in which case it boots the CD player menu) OR if there is at least one data track to try to boot from, etc. Conclusion: It scans the TOC first, as is normal and intuitive. As for how it seeks that data track, once it knows from the TOC that there is at least one, you could be correct about not using the LBA. It doesn't sound intuitive to me, but the technique you're describing based on the code could work. Perhaps it's a faster comparison in the seeking process, detecting a data sector versus the 4-byte comparison of the LBA. Not sure the easiest or fastest way to detect a data sector over an audio one, though. SectorHeader[15] would equal 01, indicating a mode 1 sector, but that means reading the sector data (which would slow things down), so rather, there'd have to be further flagging in the Q subcode data that's read in seek operations and that'd require less comparison op-codes for detection, etc.
Hey, Necro's avatar is back, slightly newer and improved! Or wait, is that exactly the same ?? The coloring or something seemed different to me at first. I guess it's the same.
