And the contents of a CD doesn't fit onto an SD card? If one can't play the real thing, then perhaps reading the CD data from the SD card could be a good compromise?
IMHO, reading the CD data from SD card would be the only sane solution.
The main point is to remove the need for fully-working original hardware, and that includes all of those pieces of spinning-plastic that have become scratched over the decades.
The entire PC-CD library (and most others) is available on sites-that-should-not-be-named as perfect bin/cue rips.
Anyone that wants to can rip their own PCE-CDs, and compare the results against a database of known-good copies.
Low level CD-ROM access is a huge pain to emulate, even in software emulators, and it's often why you're forced to rip the disc instead, but when you rip the disc, you typically lose access to the redbook audio. Even cd-emulators tend not to emulate redbook audio, even if the image has it.
I've been working on game translations for the last couple of years, and Mednafen seems to have absolutely no problem emulating and playing CD audio from a .bin file, and it even did a great job of matching 5th-generation video-playback limits when I tested it against real-hardware.
In the case of the PCE, I think the cd-rom is just a regular off-the-shelf NEC SCSI drive, and the expansion interface board is just a bridge+sram.
Basically, yes, but with a few important wrinkles, like the ADPCM subsystem.
As a first generation SCSI CD-ROM drive, there are a few proprietary undocmented SCSI commands that it responds to.
Nothing that Kevtris couldn't figure out, especially since open-source software emulators already exist to use as reference for the commands themselves.
The SegaCD likewise appears to use off-the-shelf Sony cd-rom units and JVC manufactured units using the same Sony IC's, except the entire "segacd" unit is the interface and bridge board.
IMHO the problem with the SegaCD would be less with the CD unit, and more with the fact that it's a totally different 4.5th-generation SuperAmiga-type computer that runs in parallel to the base MegaDrive, and just DMAs data to the MegaDrive's VDC for actual display ... while the original MegaDrive can still access the VDC to add some of its own work to the mix.
It's one of the first multiprocessing systems that developers had to deal with, and one heck of a kludge of a design.
One can always ask for an Nt Mini ++ with a 5CEA9 at 301K LE and 12Mbit of block RAM (that's > 1MBytes) for just 350$ extra (that's the full price of the FPGA)
If memory serves aside SFII (2MBytes) all PCE card games are <= 512KBytes .... and can fit ..... just saying.
PCE HuCards go up to 1MB (except for the bank-switched SFII with 2.5MB).
PCE ArcadeCard games allow for 2.25MB of RAM.
There's probably no need for more block RAM (even with the 128KB video memory on the SuperGrafx and the 64KB of ADPCM RAM, and, say another 32KB for CD read-ahead).
I suspect that Kevtris has already hit upon the solution for the PCE's fast memory access speed ... it may only a real issue on instruction reads (1..7 consecutive bytes).
AFAIK, the minimum non-consecutive memory accesses would be the 3-cycle PHA/PHX/PXY instructions, with a 1-byte read, and 1-byte write all in 3 cycles ... followed by the next instruction read.
But ... at the end of the day ... everyone here is benefiting from Kevtris's personal-passion-and-drive in creating these things for fun. He's put far more time-and-effort into these than anyone could even expect from a fully-paid-employee.
He can choose what he wants to work on, and the rest of us are just along for the ride, and enjoying the wonderful results.