Workstation 15 Player-2nd floppy drive read via BIOS fails first time, succeeds after reboot guest

[RoopsCumbria]

Has anyone seen this, please? Currently evaluating Workstation Player as part of my dev setup, I have a problem in boot sector code, but only the first time after opening VMware. Reboots (via menus Player | Power | Restart guest) succeed as expected.

Workstation is installed under Win 8.1 (64), both floppies are connected at boot time to .img files, and I have entered the VMware BIOS and checked that both FDDs are enabled.

Code hacked about from the first boot sector I ever wrote, and copied below. This reproduces the error with the 2 lines

mov dl,0x01

but there is no error reading from the first floppy, only changing the two lines to:-

mov dl,0x00

Restarting the guest via VMware menus, the read of sector 1 (block 0) succeeds each time afterward, until VMware Workstation is stopped and restarted.

Snippet from the boot sector:-

xor ax,ax
mov es,ax

mov dl,0x00

int 0x13 ; AH = 00 for reset drive

mov al,01 ; # sectors
mov ah,02 ; read sector(s)
mov cl,1 ; 6 bits first SECTOR, and other 2 are highest 2 bits of CYL (for HDD)
mov ch,0 ; low 8 bits of CYL
mov dh,0 ; HEAD
mov dl,0x00 ; 0-based drive. 0 -> floppy0/A, 1 for floppy1/B, 80 for first HDD
mov bx,0x0600 ; ES:BX is load address. Don't use 0x7c00, as we are (probably) loaded there 🙂
clc

int 0x13

jnc ok

Any clues gratefully received.

Roops

[btmp]

Sorry, my post won't be much help and I'll be shocked if someone with enough low level knowledge comes along and actually is able to help you. This is a user forum... and as such it's a tad unlikely anyone with the understanding of how VMWare Workstation handles boot sector code will be popping by...

That much said I'm still a tad confused by your phrasing. You say "This reproduces the error with the 2 lines" but only show one line, mov dl, 1 followed by saying that switching it to mov dl, 0 works *until the VM is 'shutdown'*? You also aren't saying WHERE that code is in relation to the following code...is it before it all or is it actually the one shown after the mov es, ax (this one seems pointless tbh, maybe you meant to xor rdx,rdx to ensure it's clear instead of only moving 0 into the lowest bits?) or the one related to the floppy slot? As you're overwiting that bit in rdx for the floppy slot location and not using it elsewhere (in the posted code) I'm leaning toward that being the location you are referencing...

If it is the floppy related one it could be something as simple as VMWare Workstation not slotting the floppy where you think it should initially and might potentially even be a bug but sadly I'm just talking out my a!$ atm with guesswork. On another hand, why not try the latest v16 and see if it has the same issue with your code? I do not believe v15 is supported any longer and there might be a small chance that if it was a bug it got fixed already..

PS: I actually know next to nothing about boot sector code outside of what it's used for and how to add it for my Windows installs. 😛

I wish you good luck and would like to end my troll with a nod of /respect

[RoopsCumbria]

Fair comments 🙂

I've been checking for "Software updates" in the app, but it never offered Player 16, only an upgrade to Pro., which is expensive for a retro hobby!

Anyway, thanks for the prompt. I've downloaded Player 16 and it has the same behaviour.

First FDD has a boot menu in its boot sector. Second FDD is a typical OS boot sector for MES, a system I'm working on for fun. The boot sector is written so that it doesn't care where it is loaded

What I meant in my question was that the code (after I hacked it about looking for the problem) has 2 lines "mov dl,0x01" which give the drive number for the BIOS functions to reset the diskette drive and to read a sector by CHS address.  (Reset only really needed with real diskettes. Normally, you try to read, then if there's an error you loop perhaps 3 or 4 times doing a reset and retry). DH contains the head number and CX contains a combination of cylinder and sector number. They are in Ralf Brown's Interrupt List if you like old code!

If I change both lines, so the code tries to reset and load a sector from first FDD, it works every time. If I leave it as "mov dl,0x01" (to reset and read the second FDD) then BIOS returns with the carry flag on, meaning an error. If I then keep VMware running and hit the menu to reboot the guest, it loads and boots correctly each time after that.

"rdx"? I wish! Remember this is old 16-bit real mode, rather than UEFI boot, so the BIOS typically loads block 0 (Sector 1) at 0x0000:0x7c00 and jumps to it. The boot sector needs to load more code from disk before I can get it to switch to Protected or Long mode.

[btmp]

Workstation v16

As I said I'm not familiar with boot code and you seem to already be beyond my understanding of how boot code is processed in general (let alone with how VMWare Workstation handles it...) I wasn't even aware BIOS bootloaders were stuck with only 16 bit 😕 I don't think I've ever even looked at code prior to 32 bit..and assumed it was all 64 bit by this point.

I wish I could help you more but I'm afraid this is beyond me atm..I'd have lots of learning to do if I wanted to try me thinks and tbh I don't have a single Floppy Drive on any physical (or VMs for that matter) systems these days...

Thank you for the update to help clarify things for me and once again, Good Luck (Maybe you'll get lucky and someone who understands the VMware Workstation boot process and ASM will pop by to help)!

[wila]

Hi,

Perhaps @dariusd can share his firmware wisdom on this one (if he has time and if the BIOS is also in his domain knowledge, which I suspect it is)

--
Wil

[dariusd]

Thanks for the heads-up @wila.  I've been a bit too preoccupied lately to keep much of an eye on the forums, regrettably.

@RoopsCumbria: What a fascinating failure!  I'll try to reproduce it here and see what I can figure out... and how much of my int 13h stuff I can remember... 🙃

Just based upon your description, it might well be a defect in the floppy drive emulation.

I'll let you know what I find.

--

Darius

[dariusd · Accepted solution]

Heh.  So it turns out it's caused by something I'd long ago forgotten about... the floppy drive "change line", which is a signal used by a floppy drive to indicate that the drive's contents may have been changed (a disk removed and/or a new disk inserted) since the drive was most recently used.  That signal is propagated up from the drive through the floppy controller and is represented by BIOS using a return status of AH=06h to indicate that a disk change may have occurred.  The change line is on at power-on.

Your first read from drive 01h will return with CF set and AH=06h.  This is an expected result, because BIOS is telling you that you are accessing a "new" disk.

Your code should simply retry the read and it will work on the second attempt.  This is what GRUB2 does (along with presumably anything else that might need to read from the second drive).

The first drive does not suffer from the problem because BIOS has already read from that drive (and performed retries!) to load the boot sector containing your code, and that has cleared the change line for you.

The read from the second drive succeeds after a reboot because the reboot does not alter the drive's change line, and your attempt to read from the drive prior to the reboot would have cleared the change line at that time.

BIOS function AH=00h is not guaranteed to clear a drive's change line – as far as I can tell, some systems will clear it on BIOS drive reset if they seek the drive back to track zero during the reset (which is itself device-specific behavior) and then most likely only if the drive was not already on track 0.  What a mess!

Anyway, as far as I can tell, our emulation is within the bounds of what is expected of a physical machine's floppy drive, floppy controller and BIOS, and issuing a retry of the read (or issuing a dummy read first) is the correct way to resolve it.

Hope this helps!

--

Darius

[RoopsCumbria]

Many thanks for the helpful reply.

I'll go back to the original code, then, and test it with a real FDD as well as with VMware, because it should have looped back a few times, doing a reset & retry (putting out a "." on screen). Since it wasn't, I was misled by that.

Many thanks again for the help.

Roops