v86
v86 copied to clipboard
copy
Change removable media (floppy and cdrom) while running
When using this emulator to run Windows XP, I encounter the program "setup". However, it tells me to insert the next image into drive A. Where's Drive A? Jamming a 1.44MB floppy into my laptop would probably destroy my computer and not help at all. So is there a way?
A possible solution is to upload the images into / (maybe A:) but I haven't had any luck using the filesystem yet...
Thank you in advance.
You would need this feature to install operating systems from the 1980s where they had like 10 install disks for each version of DOS.
I’m not clear on what the OS (BIOS?) is looking for to notice fdd changes. According to https://wiki.osdev.org/Floppy_Disk_Controller it sounds like changing port3F7_read to send a 1 in bit 7 when the disk door is opened (disk removed?) and again when closed (disk inserted?) should let us change the underlying buffer used by the floppy controller smoothly. Does that sound about right?
The confusing thing to me is how this works with respect to “selecting” fda or fdb—so if it’s cleared on a successful read or seek, we’d have to track the state for each of the two drives.
I also guess sometimes the guest OS could cause the floppy to pop out---that's something where noticing when unhandled commands are being sent would be good, because then we could see what to implement.
As for CD-ROM, I think the IDEInterface would need to change in a few ways... Here's my understanding of the problem based on the osdev wiki ( https://wiki.osdev.org/PCI_IDE_Controller#Ejecting_an_ATAPI_Drive ) and https://inst.eecs.berkeley.edu/~cs150/fa01/labs/project/ATAPI_Spec.pdf .
First off, when a disk is inserted, the ide controller should generate a unit attention condition that persists until it's cleared by the guest when it sends a "request sense" about it; my understanding is that this should cause all reads and stuff to error out with a "unit attention" error. At that point the controller can do what it was doing before, but with a new buffer. I think this is the first thing to implement: a button to load a CDROM into an empty cdrom controller.
For the emulator user to trigger an eject, we can do it by telling the interface to respond to queries with an error status with bit 3 (Media Change Requested) set. Then the controller should wait for the guest to send an Acknowledge Media Change command (code DB), after which the guest promises to send the eject sequence. (For a less graceful way, we could just swap the buffers and set that unit attention condition from before, but then the guest OS doesn't get a chance to e.g. prevent the eject or things like that).
For the guest OS to trigger an eject, I think there is an ATAPI command that can be implemented (see the osdev link), but it's also possible it's the start/stop unit command with the "LoEj" flag set. Here I'd want to hook on ATAPI commands and see if the guest is sending something that we're not handling.
@JoeOsborn Nice research! Would you be willing to try implementing it and sending a PR? We have pretty decent test coverage, so chance of breaking anything should be low.
I’m not clear on what the OS (BIOS?) is looking for to notice fdd changes. According to https://wiki.osdev.org/Floppy_Disk_Controller it sounds like changing port3F7_read to send a 1 in bit 7 when the disk door is opened (disk removed?) and again when closed (disk inserted?) should let us change the underlying buffer used by the floppy controller smoothly. Does that sound about right?
Yes, that makes sense. I believe in order to swap a floppy disk safely, you first safely eject it from the guest OS, then the disk is physically changed, and the guest just tries to re-read at regular intervals. So there isn't necessarily an interrupt or mechanism like in the IDE case.
The confusing thing to me is how this works with respect to “selecting” fda or fdb—so if it’s cleared on a successful read or seek, we’d have to track the state for each of the two drives.
I also guess sometimes the guest OS could cause the floppy to pop out---that's something where noticing when unhandled commands are being sent would be good, because then we could see what to implement.
I think we can safely ignore both of those for now. I'm not even sure if fdb works at the moment.
(For a less graceful way, we could just swap the buffers and set that unit attention condition from before, but then the guest OS doesn't get a chance to e.g. prevent the eject or things like that).
A non-graceful version would already be quite useful, so that's a good starting point.
