OK. The format.com CPU issue seems to continue, even after the improvements with regards to speed on the FDC and IMD disk emulation?

The app even hangs saying: "Verifying 1.44M". That's running "format a: /F:1.44" from the MS-DOS prompt(MS-DOS 6.22).

The CPU itself should theoretically be correct. I've manually checked if every single instruction up to 80486 or Pentium (as far as I saw them being executed) was doing it's job properly(with regards to reading and writing to registers and memory). The only thing that could be remaining is some undocumented behaviour I don't know about regarding x86 emulation? Is there perhaps missing something somewhere that isn't documented in e.g. the 80386 programmer's reference manual (everything from it is actually implemented in UniPCemu afaik, up to the smallest details I could find).

I've just tried nformat as well. Format.com seems to hang due to interrupts being permanently disabled, thus never servicing the IRQ, while nformat seems to plainly crash when starting the formatting process?
Edit: format proceeding with unconditional format seems to triple fault due to a stack overflow in real mode now?

So there's something definitely wrong with the 808X opcodes or execution somewhere, seeing as format.com doesn't require anything newer than a 808X CPU?

OK. The Windows NT 3.1 floppy.sys error message has returned after restarting setup?
Edit: That bug is gone after another bugfix and reinstall of the first part of NT 3.1 setup 😁
The cause was the requested cylinder(from the byte #2(0 is the command byte itself, with the MT, SK and F bits) of the command) wasn't matching the physical cylinder always, causing it to error out incorrectly during IMD/DSK image formats(which will allow said case to happen due to it matching against the disk image's C/H/S sector information differently(static disk images don't have that kind of information, since it's unchanging and always in ascending order)).
Another cause was invalid handling of the ST1/ST2 registers when succeeding to read a sector, which was cleared and not cleared in invalid conditions for reads and writes' result phase starting(only supposed to be cleared when succeeding the last sector).

OK. Windows NT 3.1 seems to infinitely try to execute a Read ID command when no floppy disk is inserted(requested by setup before rebooting)? Is it supposed to error out in some special way when that happens(compared to the Read Sector(s) command)?

Does anyone know the behaviour of the various FDC commands when no disk is inserted? So all data transfer commands(read/write/format/read ID) and the seek/recalibrate commands' behaviour when that happens?

I know seek and recalibrate need to succeed, because otherwise the BIOS will incorrectly detect the drives as 40-track instead of 80-track or not detect them at all?

Edit: Windows NT still seems to only issue Read ID commands with the first parameter bit 2 set, thus only Read IDs off track 1 side 1 and track 0 side 1? It doesn't seem to like what happens with it's result?

Are the results supposed to start over at sector #1(or whatever's after the Index hole on the track) when it seeks to another track, after a seek command, for Windows NT 3.1 to detect it being inserted correctly?

OK. Managed to get Windows NT 3.1 to read the floppy disk.

The weird thing is that, in order for that to work, the Read ID command has to clear the ST0 register's Seek End bit(bit 5)? Then it'll read the disk without issues?

Why would the Read ID command need to clear the Seek End flag? Also, does that also apply to the other read commands(which isn't done by UniPCemu yet)?

OK. Just noticed something weird.

When installing in UniPCemu, it displays the copying filename during the graphical part of setup with the '_'-character at the end, while according to https://www.youtube.com/watch?v=fBdyjxxNiQY it's supposed to use the decompressed filename with the _ character replaced by the actual one instead?

Is that a CPU error in UniPCemu showing? Or is there something else going on?

Edit: Hmmm... https://www.youtube.com/watch?v=B33HVblZGvk also shows the compressed filenames?
So that might not be an CPU emulation issue?
Perhaps different OS versions on Windows NT 3.1?

Hmmm... Is there any way to create a Emergency Repair Disk after Windows NT 3.1 setup completes? To test floppy disk support?

OK. Windows NT 3.1 can now read the floppy disks(at least up to 1.44MB on A, 720K on B, probably because of the BIOS drive settings in the CMOS).

Windows 95 now gets up to the point it reads two sectors from the floppy, once from the boot sector, then another one from sector 1, which enters result phase and Windows hangs somehow, never processing the IRQ? It's still pending in the FDC, the PIC has it acnowledged(and thus loaded active into the IRR register), but the CPU never gets to ACK it and actually raise the IRQ because IF seems to once again be cleared permanently?

OK. I see that the last interrupt before hanging seems to be a #GP(F500) handler, which is kind of strange for a protected-mode fault? So it's probably a V86 mode fault happening there?
The FDC itself seems to be fine, but V86 mode shouldn't throw such faults?
And if it's actually V86 mode that's faulting on that, that should definitely not happen?

OK. I see the Read Sector's result phase IRQ getting through, to 0028:C0001160 from 0028:C0004886.
I see it reading the floppy MSR, which is 0xD0.

Edit: OK. The result is completely read, but after that, the code seems to hang on some MOV of F500(the faulting value, faulting infinitely) from address 0030:C0EFFA40.
This happens at 0028:C00013B7.
Anyone knows what this is? Is that part of the FDC kernel driver, or some OS-specific stuff?

OK. So I managed to install Windows NT 3.1 from the floppy disks without visible issues, letting it create the Emergency Repair Disk during it's final part of setup.

Now, tried to use IMDU.COM supplied with the original ImageDisk program using Dosbox to convert it from IMD to IMG format. It seems like the sector size map used by UniPCemu to format the disk(to allow differently sized sectors during formatting) isn't supported by the original tools?

ImageDisk does not currently handle disks with differently sized sectors within the same track (the PC FDC cann […]
Show full quote

ImageDisk does not currently handle disks with differently sized
sectors within the same track (the PC FDC cannot write such
disks), however an extension to the .IMD file format has been
suggested to allow these type of disks to be represented:

A sector size value of 0xFF indicates that a table of sector
sizes occurs after the sector numbering/cylinder/head maps
(immediately before the data records) which contains one 16-bit
value (in little endian format) per sector which defines the
actual size of that sector.

UniPCemu does actually write such a sector map when formatting the disks, making it incompatible with the original ImageDisk software, but readable by software which does implement it.

OK. Tried MS-DOS 6.22 diskcopy(after extracting it from the setup disks) to copy the disk over to a img file, but even that one seems to mysteriously cause a stack fault in real mode, thus double and finally triple fault on said instruction trying to access the stack.

Weird that both format.com and diskcopy(since they use the FDC) seem to have issues causing a triple fault or other kind of hang trying to run them. It almost makes me think something's extremely wrong with the CPU emulation. But I've checked all the 8086 opcodes many times already, I don't know what's going wrong?
The 8086 opcodes handling: https://bitbucket.org/superfury/unipcemu/src/ … /opcodes_8086.c

The rest of the CPU checks(stuff like memory checks) should all be like documented in the 808x up to 80386 manuals at least.

OK, since diskcopy crashes(as well as format hangs), and the official tool for converting IMD disks doesn't allow the custom sector sizes, I'm checking it out the other way: create a simple pascal program(based on my TESTFD80.pas program) to read the entire disk into a file on the emulated harddisk. Then use stuff like WinImage to get the file off the disk to look at it 😁 (And ironically open it up in WinImage).
Edit: OK. Seems that WinImage can't open op the Windows NT 3.1 Emergency Repair Disk and view it's contents.

OK. Having created said disk image from the floppy, reading it with my tools seems to have something strange in the resulting disk image file: each sector is shifted down by one byte. So the first byte of the boot sector has 00, while the second byte has the EBh that's supposed to be at the first byte. The same with F0 at the first FAT byte...
So either the read function(the write function running fine) is messing up, or the image tool I just write has a serious flaw...
Edit: Nope. The DMA transfer is seemingly handled correctly (from a hardware standpoint).
So there's a simple issue with the disk dumping utility somehow?
Edit: Found the bug: the disk dumping utility I wrote had an array that had a range from 1-512, while the code used indexes from 0-511. Fixing that should fix that whole issue with the dumping.

It's still kind of weird that MS-DOS 6.22 format.com, vformat and diskcopy all either hang(format), or crash(vformat, diskcopy) and triple fault the CPU due to a real mode stack fault?

The hardware shouldn't be spamming IRQs, since it's only raising it once(For the FDC. And ofc repeatedly for IRQ0 because it's a timer).
So there's probably an CPU issue somewhere in those programs?
Format runs without issues in Windows NT 3.1. Windows 95 still crashes reading the floppy's first sector(it's very first read data command).

Then, is there a simple way to find out if the 8086 core has issues(some software that uses all 8086 opcodes, but nothing newer? Same for the 80186+, 80286+, 80386+ ones, seperated of course)?

Just improved the format track functionality of the IMD disk images a bit: when all sectors are now using the same sector size, it'll use the track header instead and not use a custom sector size map(which is defined in the specification as a proposed extension and isn't compatibile with the official software).

Just have been thinking...

What's the difference between the FDC format track's 2nd parameter byte (byte #2 "Sector Size") and the formatting packet(which is 4 bytes long)'s byte #3 "Sector Size"?

Can sizes less than 128 bytes be given with this command?
If so, is this given by the format parameter data or the format track command's 2nd parameter?

It sound kind of weird that there's actually two seperate parameters named "Sector Size" in the command? One in the sector data and one in the format track command?

Just tried Windows 95 4.0.0950 setup again. It can actually see the floppy disk being inserted, reading sectors. But eventually, it executes a Read Data command for C/H/S=0/0/1(which seems correct, according to the head and cylinder values), which somehow errors out with ST0=0x60, ST1=0x05, ST2=0x01, ST3=0x30. So it somehow can't find the first sector on the disk anymore? Strange behaviour?
Edit: It seems it's a request to read C/H/S of 0/0/2.

Edit: Just found the cause: for some weird oddball reason, the track 2 head 0 has only 1 sector in it, with a C/H/S ID of 2/3/1? That's kind of weird and perhaps the cause of the issue?

OK. The cause seems that Windows 95 setup's boot floppy creation executes a format track command with seemingly incorrect parameters for the formatting, causing it to go missing?

OK. I see Windows 95 setup doing something weird with the floppy disk controller:

I see it executing a format track command multiple times on track 0, with unchanging sector data, until eventually erroring out that:

Could not properly initialize the floppy disk that your inserted.

Error: The device was not ready.

Click OK to continue.

All times the format command executes, the same parameters are used. The results are the same Cylinder and Head values as used, with the result sector value being 1(as documented). I have no idea what the C/H values should be in this case. Should MT be used?

Thinking about it, format track doesn't have MT support, does it? So if formatting track 0 side 0, it would report the next track side 0(track 1 side 0 sector 1) in it's results for the next sector?

What's the case when the disk is double-sided?

Edit: On another note, what happens when a track size of 0 sectors is supplied to the format track command? Will it actually format the track without any sectors on it? What about the packets of 4 bytes that usually follow it? Will the command immediately complete on it's IDX line being raised?

OK. Having improved things a bit, I see the following happening:
1. Windows 95 setup executes a normal format track command, formatting track 0 head 0 with 18 normal sector values supplied through DMA.
2. It executes a Read Data command to read the data back(bytes 6,0,0,0,1,2,12h,1bh,0), thus for a 18-sector read with MT, MFM and SK set. So the command reads said data from the disk in blocks and supplies it through a DMA transfer.
3. The Read Data finishes with an IRQ(which is raised) and enters result phase.
The MSR is still 0x50(probably until it's updated by reading the result register, which will update the value with actual values for the read?). So the MSR isn't read for the result phase.
The IRQ is actually raised by the FDC, according to it's internal state of the IR line.
Looking at the PIC status, the parallel IR line is actually acnowledged and in the active IRR register waiting to be serviced. It also shows that it's still executing a IRQ0 interrupt(which has it's bit set in all ISR registers).
Edit: Simply moving the mouse around shows that the IRQ0 handler is indeed in some kind of never finishing situation?
So the FDC is actually doing what it's supposed to do, but the IRQ0 handler is somehow hanging itself up?
Anyone knows what might be the cause?
Edit: It seems to be in some kind of infinite loop at F6F6:F7F8?
Edit: It eventually gets to F6F6:F71B, which compares SS(=1799h):36C to 1, which isn't the case, thus jumping to F742, which jumps back to F7F8 at F6F6:F742(logical memory address 1066A2). Perhaps some part of the MS-DOS kernel?
Edit: Hmmm... I see a PUSH SS(opcode 16h), POP DS(opcode 1Fh) instruction in the stream of instructions, but DS isn't changing at all(DS=F6F6, SS=1799)?
Edit: Hmmm.. PUSH SS writes to SS:3FA=17CEA(linear address). It reports success having written it. It's supposed to write the correct value, as seen by the request.
Then POP DS... It request a read a SS:35A=17CEA(linear address). The result of the read is 1799h. So that's OK.
Then it tries to write to DS the value 1799h. So so far so good...
Edit: OK. The instruction finishes and it's still 1799h. But when the next instruction is supposed to start it's debugger, it's suddenly different(unchanged)?
At least, when the instruction of POP DS finishes, the registers (which are still uncommitted) contain the correct values and precalcs. So 1799h is actually loaded into DS at that point, but can still be discarded by any loading instruction that throws stuff like an exception.
Edit: And OF COURSE it's perfect timing for Visual Studio with it's debugger to hang itself up right as I'm trying to get to whatever the next instruction processing is in the debugger stepping through Windows 95's MS-DOS kernel! Yay!
Edit: OK. The watch window literally has a little box in the middle saying "Busy..." and nothing more?

Edit: Just gotten it working after cleaning out various long lists of variables from the watch window that were still there(as well as old x86 register watches that aren't used in the same way anymore).

Managed to create a little log of it running said issue:

Can anyone see something going wrong or know what's going on?