[Patch] CD-ROM model selection

[EluanCM]

This patch allows CD-ROM model selection from a list of available models and also alters some of the UI behaviour. Beware that I can't do UIs

-CD-ROM settings will now only be enabled when an IDE or SCSI controller is selected.
-Specific CD-ROM models may be restricted by interface type.
-Speed selection may also be fixed for a specific model.

I've included only one model with the patch: the AZT CDA 468-02I IDE drive which is the model that the SGIDECD.SYS driver from one of my hdd dumps wants. There is potential for a database here.
(Again this patch was inspired by my desire to run unmodified bios/hdd dumps from my old computers.)

The patch is bz2-zipped because the automatically generated wx-resources.cpp is too large.

[omarsis81]

Could you please add some screenshots of how it would look like?
I feel it is a step closer to real emulation! I always wanted something like this and HDDs too

[EluanCM]

Here you go

(Yeah, the "-02I" being detected as an "-01I" by the DOS driver happens on the real thing )

[omarsis81]

Is it possible to make the same for hard disks?

[EluanCM]

PCem only supports one CD-ROM drive, so implementing this for HDDs would be a little different.
-Have a list of models for each interface
-After selecting the HDD for the channel, give an option to define CHS just like it is today (for the PCemHD model) or select a real model, which would fix the CHS for PCem and for the image creation step.
-I would suggest not using the "Type xx" nomenclature, because the meaning varies by BIOS.
-As with the CD-ROMs, creating the database with the correct strings would need a real working one of each model (or at least one of each series). This is the real hard part.

[omarsis81]

-As with the CD-ROMs, creating the database with the correct strings would need a real working one of each model (or at least one of each series). This is the real hard part.

Why is needed a real unit? To extract the BIOS or firmware? I have tons of optical drives.
Or just copy the string by hand?

[leilei]

I'm sure i've got a few of my past CD-ROM drives' strings from random old hardware detection log files...


also the CD-ROM model thing crossed my mind while pondering about figuring to create CD-ROM drive sound. I procrastinated too much on capturing my old whirry Mitsumi 4X. (by the way there's exactly one youtube video about this particular drive and it's playing a music cd so it's not whirring)

EDIT: That drive's string as pulled from an old detection log

Code: Select all

MITSUMI CD-ROM        !B

[ecksemmess]

Wow, fantastic work EluanCM! You're really on a roll lately with these patches. I'd love to see this approach adapted to HDDs as well.

[dns2kv2]

Yea i agree with the idea too, also the idea if pcem can extract bios drive types table from supported machine bios and use it when creating harddisk image.

https://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes.c

[EluanCM]

Why is needed a real unit? To extract the BIOS or firmware? I have tons of optical drives.
Or just copy the string by hand?

ATAPI CD-ROM drives, for example, respond to the SCSI INQUIRY and the ATAPI IDENTIFY commands slightly differently. Getting all these strings would be needed. This is only part of the problem for emulation, though: the reply for these commands also contains supported transfer modes, etc. Luckily, emulating the CD "speed" (e.g. 16x) is enough to create a convincing behaviour and just setting the strings creates a good illusion.

HDDs do not have a "speed" rating, so they would have good names but everything else completely equal according to the machine/controller being used, AFAIK.

I'm sure i've got a few of my past CD-ROM drives' strings from random old hardware detection log files...


also the CD-ROM model thing crossed my mind while pondering about figuring to create CD-ROM drive sound. I procrastinated too much on capturing my old whirry Mitsumi 4X. (by the way there's exactly one youtube video about this particular drive and it's playing a music cd so it's not whirring)

EDIT: That drive's string as pulled from an old detection log

Code: Select all

MITSUMI CD-ROM        !B

Every time I power up one of my old PCs, the sound of the PSU turning on, HDD spinning up and calibrating, the 5 1/4 and then the 3 1/2 drives seeking, etc REALLY bring me back in a way emulation can't. I'm really fond of your effort to preserve the sounds!

BTW: your string doesn't sound very useful!

Wow, fantastic work EluanCM! You're really on a roll lately with these patches. I'd love to see this approach adapted to HDDs as well.

Thanks!

Yea i agree with the idea too, also the idea if pcem can extract bios drive types table from supported machine bios and use it when creating harddisk image.

https://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes.c

This is interesting, I didn't know it was well structured between vendors.

[leilei]

Every time I power up one of my old PCs, the sound of the PSU turning on, HDD spinning up and calibrating, the 5 1/4 and then the 3 1/2 drives seeking, etc REALLY bring me back in a way emulation can't. I'm really fond of your effort to preserve the sounds!

Thanks!
Another thing stopping me is how there was no visualizations of an old CD-ROM drive working in action (unlike floppy and hard drives) for more detail study. Understandable, being laser devices... i'd also have to throw in artificial stalling times and such for the drive in question, and doing that for the floppy drives was already a big hack for getting the old bootup seek times.

CD drive noise is something very overlooked for some systems emulated IMO. NeoGeoCD, Dreamcast, etc.. all need their loud drives in software

BTW: your string doesn't sound very useful!

I believe the real model name's a CRMC-FX400 but i'd have to yank out the drive from a dead system to find out and I don't feel like doing that now. I did unearth the firmware revision from a system.dat (dragging it into a throwaway win98 install, booting in safe mode and viewing device manager) however. B05


Also maybe there can be a generic "ATAPI CD-ROM ##X" name alternative to "PCem PCemCD" too. I've seen one drive in the wild showing in device manager like that before. Probably a Windows 9x fallback name though like GENERIC IDE HARD DISK TYPE 47 etc

[leilei]

Here's some models I scraped from info (rather than the actual drives)

Code: Select all

        {
                "MATSHITA",
                "CR-571",
                "53R141", 
                "CR-571", // unknown
                "1.0e",

                "",
                "1.0e",
                "CR-571-B",
                "Matsushita CR-571 2X",
                "matsushita_cr-571_2x",
                CD_MODEL_INTERFACE_IDE,
                2,
        },
        {
                "MITSUMI",
                "CD-ROM        !B",
                "53R141", 
                "CD-ROM        !B", 
                "B05",

                "",
                "B05",
                "MITSUMI CD-ROM        !B",
                "MITSUMI CRMC-FX400 4X",
                "mitsumi_crmc-fx400",
                CD_MODEL_INTERFACE_IDE,
                4,
        },

Earlier Packard Bells use a Matsushita 2X so I tried to put that in, but isn't enough to initialize with the driver given.

[omarsis81]

Here there is another CD-ROM string. What else should I provide?

20200224215650.JPG (172.62 KiB) Viewed 23929 times

[SarahWalker]

Committed at rev 1509.

[MiraiMiracle]

Wow! That is a great patch I ever seen!

I always wanted to emulate other CD-ROM emulators in PCem, didn't I?

[te_lanus]

Committed at rev 1509.

Seems this has introduced a small bug. If you enter a emulated pc, it'll see the cdrom, but iy=f you go out and then go into another emulated pc, it won' see the cdrom, the only way to bypass is to close pcem completely between switching emulated machines. tested with commit git up to commit-063a40d

[EluanCM]

Here's some models I scraped from info (rather than the actual drives)

Code: Select all

        {
                "MATSHITA",
                "CR-571",
                "53R141", 
                "CR-571", // unknown
                "1.0e",

                "",
                "1.0e",
                "CR-571-B",
                "Matsushita CR-571 2X",
                "matsushita_cr-571_2x",
                CD_MODEL_INTERFACE_IDE,
                2,
        },
        {
                "MITSUMI",
                "CD-ROM        !B",
                "53R141", 
                "CD-ROM        !B", 
                "B05",

                "",
                "B05",
                "MITSUMI CD-ROM        !B",
                "MITSUMI CRMC-FX400 4X",
                "mitsumi_crmc-fx400",
                CD_MODEL_INTERFACE_IDE,
                4,
        },

Earlier Packard Bells use a Matsushita 2X so I tried to put that in, but isn't enough to initialize with the driver given.

These look nice. I have one such Packard Bell (the Legend 100CD, which uses the PB520r), I will take a look at the default driver when I have some free time.

Here there is another CD-ROM string. What else should I provide?
20200224215650.JPG

All the relevant strings should be accessible under Linux with sg_ident and hdparm. Under Windows and DOS I don't know. (If you have access to a hardware that PCem emulates, you can always do the dirty hack of replacing the PCem strings with unique ones and comparing what's in the POST/SETUP/Driver message/Windows registry between PCem and real hardware and recreate them. But this is a last resort and I will deny suggesting this!)

Seems this has introduced a small bug. If you enter a emulated pc, it'll see the cdrom, but iy=f you go out and then go into another emulated pc, it won' see the cdrom, the only way to bypass is to close pcem completely between switching emulated machines. tested with commit git up to commit-063a40d

Can you give details? I've tried changing between lots of configs with and without drives (both ide and scsi) and all seems to work.

[te_lanus]

Seems this has introduced a small bug. If you enter a emulated pc, it'll see the cdrom, but iy=f you go out and then go into another emulated pc, it won' see the cdrom, the only way to bypass is to close pcem completely between switching emulated machines. tested with commit git up to commit-063a40d

Can you give details? I've tried changing between lots of configs with and without drives (both ide and scsi) and all seems to work.

Seems it's to do with trying to run Redhat 3.0.3 on a machine, and then trying to run anything else afterwards.

[EluanCM]

Here there is another CD-ROM string. What else should I provide?
20200224215650.JPG

I will reply your PM here just to keep it documented
These are the fields and how you get them: (not in order)

From sg_inq -u:

Code: Select all

char    *vendor_8;
char    *model_16;
char    *firmware_4;

From hdparm -i or sg_inq -a:

Code: Select all

char    *serial2_20;
char    *firmware2_8;
char    *model2_40;

I can't get any of my old or new drives to respond to INQUIRY with the EVPD bit set, so these are missing:

Code: Select all

char    *model_and_firmware_40;
char    *serial_20;

A standard way to construct model_and_firmware_40 seems to be model_16 + firmware_4 or just model_16.
And serial_20 is hopefully equal to serial2_20.
Maybe someone else can help you with DOS or Windows, I have never researched this.

If you play with sg_* you may notice the complexity of the SCSI protocol. Fortunately we can make (most) drivers play nice just with these strings.

Attached is a small patch for Sarah for a cosmetic fix.