MiSTer FPGA Forum

On a scale of 1 to 10 I wonder how difficult it would be to add USB CD-ROM drive support to boot original game discs?

Reading a cd on-the-fly would only work in the same sense that retron's read carts, by ripping them and then loading the ripped roms. There's a 0% chance the cd drive will operate with the correct seek and read times that cores need to behave properly, so you're better off simply ripping your discs to files and not adding silly overhead for illusionary ripping-on-the-fly.

Kitrinx wrote: ↑Mon May 25, 2020 8:39 pm Reading a cd on-the-fly would only work in the same sense that retron's read carts, by ripping them and then loading the ripped roms. There's a 0% chance the cd drive will operate with the correct seek and read times that cores need to behave properly, so you're better off simply ripping your discs to files and not adding silly overhead for illusionary ripping-on-the-fly.

Wouldn't /dev/cdrom behave similarly to a BIN file? I mean, at the end of the day, the ISO file is on a SD card... An SD card with it's own read/seek characteristics, often differing between makes and models.

Obviously the kernel would need USB CDROM support and main_mister would need to be able to use /dev/cdrom instead of a file on the SD, but it might just work?

"On a scale of 1 to 10, how difficult it would be to add USB CD-ROM drive support to boot original game discs?"
I would say 0.

I would just rip the games with ImgBurn or Turborip.
I use ImgBurn to rip my CDs to CUE/BIN format. Make sure you name the files accordingly before the Rip.
If you decide to rename the files afterwards, you have to edit the Cue file in ether Notepad or Notepad ++ (Notepad ++ is prefered).

Afterwards place said files in a folder, and put it on your MiSTer SD card or HDD.

dentnz wrote: ↑Wed May 27, 2020 1:37 am Wouldn't /dev/cdrom behave similarly to a BIN file? I mean, at the end of the day, the ISO file is on a SD card... An SD card with it's own read/seek characteristics, often differing between makes and models.

Obviously the kernel would need USB CDROM support and main_mister would need to be able to use /dev/cdrom instead of a file on the SD, but it might just work?

I agree with this, it's certainly something that could be implemented. If the ARM side of the DE-10 Nano was configured to mount a CD to a file directory, the FPGA core would simply read the files off the CD as if it were any other mounted media. Now a modern dvd/cd drive generally operates at a much faster speed than the original TG-16 would have, and even if you forced the drive to read at 1x speed I would expect the timings would still be imperfect, but theres no reason to think it couldn't be done.

Reed_Solomon wrote: ↑Wed May 27, 2020 4:01 am I agree with this, it's certainly something that could be implemented. If the ARM side of the DE-10 Nano was configured to mount a CD to a file directory, the FPGA core would simply read the files off the CD as if it were any other mounted media. Now a modern dvd/cd drive generally operates at a much faster speed than the original TG-16 would have, and even if you forced the drive to read at 1x speed I would expect the timings would still be imperfect, but theres no reason to think it couldn't be done.

In the case of the TG-16, I was under the impression that the file reading was done on the Linux side. The FPGA doesn't 'read the files off the CD' directly, more that the ARM seeks and reads data from the BIN, creating a sector (of varying sizes depending on CUE) and sends them across to the FPGA via HPS IO.

As I said, where Linux gets the data from is not the point - it could be a share on a network, an external USB HDD, or /dev/cdrom. I'm not entirely sure from Rysha's comment, but I suspect that she assumed the OP wanted to make the USB cdrom drive behave like the real thing... And she is right, that's not going to happen.

Sorry to talk about software emulators, but I believe some of the PCE emulators use /dev/cdrom to access CDROMs in the way that we are thinking.

https://github.com/mckayemu/hugo/blob/6 ... om.txt#L28

Emulators usually aren't tuned to the same timings as an actual console.

I haven't looked at the code here myself, but the impression I have is that it's written to expect data from the CD using the same timing characteristics as the original drive (which other drives won't have). A microSD card is going to be significantly faster than that, so Linux side is probably pre-buffering some amount of data to be read where it can, and retrieving data at comparatively instantaneous access times when it can't. A physical drive would add its own access times on top of that, and the only sure-fire way around that would be pre-buffering the entire disc before running it.

MiSTer is not a garbage can with random functions used by 1-2 people.
There must be strong reason to implement one or another feature. Supporting CD-ROM drives (same as real floppy drives) is not a reasonable feature. There is absolutely no advantage of using real CD-ROM drive which obviously won't have same seeking and reading times of original PCE CD. So in other words it won't emulate the real drive.
So dump it and place to SD card (or USB flash drive).

Strong followers of Leopold von Sacher-Masoch can do following steps:
1) find SD card of 1GB and put it into USB card reader (or find USB flash 1GB)
2) write only one CD image to it.
3) insert to MiSTer and play.
4) to play another game, repeat from step 2.

dentnz wrote: ↑Wed May 27, 2020 1:37 am
Wouldn't /dev/cdrom behave similarly to a BIN file? I mean, at the end of the day, the ISO file is on a SD card... An SD card with it's own read/seek characteristics, often differing between makes and models.

Obviously the kernel would need USB CDROM support and main_mister would need to be able to use /dev/cdrom instead of a file on the SD, but it might just work?

Yes, albeit with normal random CD reading delays and disk errors and the like, but this is what I mean by ripping-on-the-fly. It's just reading off the disc at some uncontrolled speed, like it's dumping the disc, and then emulating the real drive. It's the same as retron. Fake original reading. There's absolutely no point to do this vs just dumping the disc. The only thing dumping-on-the-fly can possibly do is make the experience worse due to read errors and less consistent read times. Much better to keep the code lean and bug-free than introduce this false-real-disc reading for the sake of some strange ritual.

Kitrinx wrote: ↑Wed May 27, 2020 12:38 pm The only thing dumping-on-the-fly can possibly do is make the experience worse due to read errors and less consistent read times. Much better to keep the code lean and bug-free than introduce this false-real-disc reading for the sake of some strange ritual.

You can throw in a "scratched disc mode" that produces read errors at a random rate. You know, just for the sake of authenticity

Also can load aged CD into 60x CD-ROM drive and guess will it explode or not.
I suggest to start from Sapphire. Exploding the $2000 CD is awesome.

Sorgelig wrote: ↑Wed May 27, 2020 9:07 pm Also can load aged CD into 60x CD-ROM drive and guess will it explode or not.
I suggest to start from Sapphire. Exploding the $2000 CD is awesome.

Hahaha, so true!

Sorgelig wrote: ↑Wed May 27, 2020 9:02 am MiSTer is not a garbage can with random functions used by 1-2 people.

Uhh... I'm no masochist any more than anyone looking for additional ways of playing a game when others were already possible and perfectly usable
The idea just occurred to me while I was working with two different disc burning apps to convert incompatible disc images into .bin and .cue files, something I don't find all that simple or pleasurable. I wasn't looking for authentic drive performance or even real-time performance. "On-site dumping" just seems like a logical option when the people who want to play probably own a lot of the games, and I'm guessing that more than 2 people would use it.

Sorgelig wrote: ↑Wed May 27, 2020 9:07 pm Also can load aged CD into 60x CD-ROM drive and guess will it explode or not.
I suggest to start from Sapphire. Exploding the $2000 CD is awesome.

This is also a strong argument in favor of just using Redump images and not trying to make your own. I have no desire to get Rondo of Blood out of the case, I know that.

Galgomite wrote: ↑Thu May 28, 2020 10:24 am The idea just occurred to me while I was working with two different disc burning apps to convert incompatible disc images into .bin and .cue files, something I don't find all that simple or pleasurable.

If it saves you some heartache later on down the road, CDMage is a single tool that will let you convert from one format to another. It's as simple as opening the wrong format file, and then File->Save As to save it over to the right format. I did it with a handful of wav/cue files and it worked like a charm.

TurboRip was made specifically to create correct and appropriate cue/iso/wav files.

I will indeed try Turborip (and CDMage as a backup). Most of the work is now done. Thanks everyone for the advice.
I'll still be amazed if MiSTer isn't rocking cart and CD support in a couple years, though:)

Galgomite wrote: ↑Thu May 28, 2020 8:21 pm I will indeed try Turborip (and CDMage as a backup). Most of the work is now done. Thanks everyone for the advice.
I'll still be amazed if MiSTer isn't rocking cart and CD support in a couple years, though:)

The truth is that carts and cd's have a limited shelf life. I think it was dshadoff who mentioned after he dumped and crc'd his cart and disc library, 2% had bad CRC's due to bit-rot. The increasing cost and the aging components make them an ever-decreasing concern. ROM images can be verified for accuracy, are more convenient, and have an indefinite "shelf life". Discounting the comedy of trying to somehow wrangle an interface for 20 different types of cart slots, I don't think you'll ever see them on MiSTer. Even other FPGA solutions that do have cart slots are mostly populated by flash carts, anyway.

I re-ripped my collections in 2018, to ensure I have a digital copy of everything - and to verify that I didn't have anything inauthentic.

For HuCards, I required that the rip matched another rip from an independent source, or a second copy from my own collection.
For audio CD's, I counted only unrecoverable errors (using dbPowerAmp ripping which has really impressive error-recovery techniques).

The HuCards were a 2% error rate (of at least one bit wrong).
I had a similar failure rate among my audio compact discs from that era as well.
Thankfully, the PC Engine CDROMs were all safe, and didn't need any fancy retries.

I've had one HuCard fail me over the years, and it's a very strange and sad feeling.
I never thought of anything but "on" and "off" state. Now I'm scared, realising the rot could be silent :O

Sorgelig wrote: ↑Wed May 27, 2020 9:02 am MiSTer is not a garbage can with random functions used by 1-2 people.

Strong followers of Leopold von Sacher-Masoch can do following steps:
1) find SD card of 1GB and put it into USB card reader (or find USB flash 1GB)
2) write only one CD image to it.
3) insert to MiSTer and play.
4) to play another game, repeat from step 2.

I love those kind of answers.

At the end of the day, this is about putting a cart in a slot or a CD into a drive and push a button to boot it.

NFC stickers would be a neat way to do it. Read the sticker, send a string with the core and ROM to load from disk. Basically like MRA files but stored in a slightly different way. I'm not sure how much data would fit, but maybe a QR code could do it too.

Not my idea, people have done it already: https://www.daftmike.com/2016/07/NESPi.html

Edit: I do see it having very limited use though. It's only for cart fetishists and maybe, maybe, if you want to invite friends over and have them pick up a cart to play among your massive collection. That said, human can be the "reader" as well and select the damn game