cyclone3d wrote on 2021-09-18, 04:38:
So... What if you used the internals of a real CD-ROM drive and just replaced the laser unit with an emulator and then also had a way to make the drive think that a CD had been ejected and a new one put in. That seems like it would be a simple way to make it work and not be too expensive as a lot of the hardware would already be there and you wouldn't have to worry about driver support either.
Short version: if I understand you correctly, few to none optical pick-up units (OPUs) are understood/reverse-engineered to the point where they can be "replaced with an emulator" (most if not all are undocumented)
See: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6066758/ for work on three very specific OPUs.
And even if they were, no dumps of discs at that level exist. If such image files existed, they'd probably be pretty huge anyways, much larger than a typical disc image. (I will ask a friend for a few more specifics.)
[EDIT] Because the transitions of pits and lands are actually analog, as the laser slowly moves into and out of pits, due to how the non return to zero PLL and the zero cross detection work, if stored at 8-bit 10 MSPS (mega samples per second), a typical audio CD would be encoded at approximately 34GB/hour.
It would make more sense to store the EFM after decoding, which would be about 2-3 times the size of the data, but the EFM is decoded after the OPU, usually by the Servo DSP. EFM can contain the errors from copy protection and extra length runs that break the EFM format used in copy protection too. (thanks to smally_dd86 for the details here).
[EDIT] Here's a block diagram for the Panasonic CD-R/RW Drive CW-7586-B, an 8x CD-R 4x CD-RW 32x CD drive, picked at random. This is typically around the depth of documentation you can get on a typical optical drive, as you can see, it doesn't explain near what you need to do to replace part of it with an emulator. You don't stand a chance of getting thorough detailed info on the servo DSP without signing an NDA, and you would have had to have done so when the drive was new. Anyhow, it also kinda shows you what's going on inside. And as drives get newer, more and more of these functions get condensed into fewer and fewer chips. So very quickly, whether by intent/design or by evolution, obtaining access to the "raw data" becomes rather impossible, and you always have to deal with how the drive's firmware, plus the drivers, plus the OS, decodes and interprets the data. So... emulating at the level of ISO/BIN+CUE/NRG/etc. is by far the easier option.
[EDIT] http://bugworkshop.blogspot.com/2015/05/mitsu … b-cd-rw_31.html for a teardown of the CW-7586-B, which lists a BOM for the controller board. Good luck finding datasheets! 😀
Reverse engineering is pretty much the only direction this can go in, and there's too many drives, all similar but not identical at the functional level, let alone a lower level. You'd have to pick a very specific drive to emulate, and even then, "replacing the laser with an emulator" would tie your production to a limited supply of obsolete drive controller boards.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen