VOGONS


First post, by superfury

User metadata
Rank l33t
Rank
l33t

Is there a way to verify if a CD-ROM drive is running properly(by either two CD-ROM drive performing a sector-by-sector comparison) or comparing a CD-ROM disk to a .ISO file on the harddisk(for MS-DOS of course)?

That way I might be able to find out if my emulation of .CUE disk images(with .BIN backend) is working properly?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 2 of 7, by superfury

User metadata
Rank l33t
Rank
l33t

Is there perhaps software that can create .iso files from a CD-ROM drive under MS-DOS? Then I can compare the created disk images against one made using software on Windows 10 and find out if any of the disk sectors was incorrectly read for some reason(indicating emulation errors)?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 3 of 7, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

Your question inspires me to try out next time when I play with my retro computers, I'll try whether something works to copy/pipe the raw device to a file.

As you know, even in MSDOS the CDROM is a device... so maybe there exist some analog to "cp /dev/cd<n> <file>".
maybe something like "copy /b mscdxxx0 targetfile"...

MSDOS definitely supports that... you can verify that fact with "copy con yourtextfile", after entering the text, give it EOF (^Z on MSDOS) to write the console stream buffer and return.

Reply 4 of 7, by superfury

User metadata
Rank l33t
Rank
l33t

Perhaps one problem with that. The device MSCD001(as I've called it for compatiblity using the CD-ROM driver's /D:MSCD001 parameter) contains two drives? So MS-DOS won't know which drive to use? So probably not working? There's a drive on both the master and slave, which are both handled by the same driver(with the same MSCD001 ID).

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 5 of 7, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

I am not sure whether I understand you correctly.
For each drive MSCDEX wants a different drive ID.
Look at the output of, say, MTMCDAI.SYS

drive at (master)... MTCD0...
drive at (slave)... MTCD1...

displaying the "driver names", actually devices, for MSCDEX /D option.
You also might look with any DOS system information utility that can list the available devices (and more stats like their drivers entry points too iirc)

Reply 6 of 7, by superfury

User metadata
Rank l33t
Rank
l33t

So if I understand it correctly, the drive ID's for "/D:MSCD001" are going to be MSCD0010 and MSCD0011? Or is that going to be something else? Afaik the driver itself becomes MSCD001, like EMMXXX for EMM386 afaik? Isn't that what the /D switch does? Provide a name for software to communicate with the driver?

So the seperate CD-ROM drives must have a different ID?

Config.sys line:

DEVICE=MSDOS\OAKCDROM.SYS /D:MSCD001

Autoexec.bat line:

MSCDEX /D:MSCD001

OAKCDROM.SYS reports "MSCD001" as the "Device Name" directly after the "Driver Version" (V340) and before the "Transfer Mode" (Programmed I/O).

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 7 of 7, by retardware

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

So if I understand it correctly, the drive ID's for "/D:MSCD001" are going to be MSCD0010 and MSCD0011?

Or something similar... my retro PCs are atm in the workshop. Could do some checking and verification on a 486 next week.

superfury wrote:

Or is that going to be something else?

There is no standard naming for that...

superfury wrote:

Afaik the driver itself becomes MSCD001, like EMMXXX for EMM386 afaik?

This only gives the first drives' ID...
The number indicates the device, either drive, or EMM expansion card number. Remember back then you would have needed a number of EMS cards to get maximum possible LIM EMS.

superfury wrote:

Isn't that what the /D switch does? Provide a name for software to communicate with the driver?

I think rather it tells MSCDEX which device (i.e. physical drive), as there is no way to call subdevices, for example SCSI device IDs on a particular bus. Or bus ID, master/slave on IDE bus.

superfury wrote:

So the seperate CD-ROM drives must have a different ID?

I think the IDE CD driver just does the same as the other (firmware based) com and lpt drivers do with COM1,2,... and LPT1,2, etc.
I think there is some way to append non-default (eg not the first) device numbers... like LPT: is actually LPT1, and with other printers you had to specify their numbers explicitly