superfury wrote on 2020-02-01, 22:39:

OK. So it's basically impossible on a plain XT/AT/Compaq Deskpro 386, except for being able to change the DMA controller by quickly writing the count registers to 0(although it will still transfer 1 byte, which will cause an incomplete command of 1/512 bytes being transferred of a sector, then erroring out?).

Dunno, you'd have to test it yourself.

superfury wrote on 2020-02-01, 22:39:

Well, UniPCemu currently just increases the sector numbers monotonically, from 1 up to SPT(as the backend file uses) as it reads it from the backend file. Once it reaches SPT+1(sector>SPT to be exact), it resets back to 1(SPT in DMA mode with MT, otherwise parameter 6 of the command used) with documented head logic(depending on MT bit). It leaves it to the backend file format (either img file or dsk image file) to figure out the data backend and where the sector is on the disk, just requesting said sector id from the disk and retrieving it, assuming it goes on monotonically(e.g. gaps in the sectors available will error out(e.g. read 3 sectors from sector 1 onwards with only sectors 1,3,4(...) defined and sector 2 missing in the backend. Sector 2 will error out in that case when it's reading it(essentially 'passing the index hole twice' as a real FDC would handle it(at least looking at the logical way of finding a sector number on a formatted disk with unknown ordering)))).

To properly support IMD or teledisk you can't rely on sectors being numbered in order like that.

crazyc wrote on 2020-02-01, 22:49:

superfury wrote on 2020-02-01, 22:39:

OK. So it's basically impossible on a plain XT/AT/Compaq Deskpro 386, except for being able to change the DMA controller by quickly writing the count registers to 0(although it will still transfer 1 byte, which will cause an incomplete command of 1/512 bytes being transferred of a sector, then erroring out?).

Dunno, you'd have to test it yourself.

Perhaps I will. Although it's probably an unused feature?

crazyc wrote on 2020-02-01, 22:49:

superfury wrote on 2020-02-01, 22:39:

Well, UniPCemu currently just increases the sector numbers monotonically, from 1 up to SPT(as the backend file uses) as it reads it from the backend file. Once it reaches SPT+1(sector>SPT to be exact), it resets back to 1(SPT in DMA mode with MT, otherwise parameter 6 of the command used) with documented head logic(depending on MT bit). It leaves it to the backend file format (either img file or dsk image file) to figure out the data backend and where the sector is on the disk, just requesting said sector id from the disk and retrieving it, assuming it goes on monotonically(e.g. gaps in the sectors available will error out(e.g. read 3 sectors from sector 1 onwards with only sectors 1,3,4(...) defined and sector 2 missing in the backend. Sector 2 will error out in that case when it's reading it(essentially 'passing the index hole twice' as a real FDC would handle it(at least looking at the logical way of finding a sector number on a formatted disk with unknown ordering)))).

To properly support IMD or teledisk you can't rely on sectors being numbered in order like that.

Got a point there. UniPCemu does support reading and writing DSK format disk images(which as far as I can see is like that teledisk format, but more simplified?), but it currently assumes that the sector numbers are, indeed as you've said, in ascending order. It also flat out ignores the C,H(which),S fields inside the sector's header(just assumes they're all in ascending order, with the very first one being sector number 1). It does check the other fields, though(the head and track number), but completely ignores the sector number of the sector being read, written or looked up(lookup just gives the result, which isn't verifying the sector number against the requested one 😖).

Just modified the handling of the reading, writing, formatting and read ID commands to (with the exception of formatting) find the requested sector number on the track, then using said found sector on the track, instead of actually using the nth sector on the track. Reading/writing/Read ID now actually uses a lookup first to find the sector number on the track(any order), then using normal read/write/reading of sector info to read/write/Read ID said sector.

Of course formatting does still use the order of sectors as they're within the image, but it will only increment from 1 to SPT(and requires the format 4-byte block to match those sector IDs) when using IMG files.
But when using DSK files, it changes behaviour: it will use the current sector ID(from 1 to SPT) to read the sector information. Then it verifies the sector's identified C/H/S(from the sector information block) against the 4-byte format block. If it doesn't match, it fails the command.
The rest is still the same: if sector size matches, it will fill said sector with the fill byte as specified in the format command.
So the disk's sector number when formatting won't behave like the Read/Write/ReadID commands(searching the entire track for the sector number and using that one) but instead taking the nth sector(indicated by the current sector number(from 1 to the disk track's SPT) as formatting progresses) and using said number as a index for the selected sector(and verifying that track ID in the given order).

Edit: Just modified the lookup to search within the physical track, on the selected head, then searching for a full sector ID match(Cylinder, Head and Sector ID matching the values to read/write). So it will compare the current idea of the track with the track ID on the sector, the current head with the head ID on the sector and the current sector number to read with the Sector ID on the sector now.

Although it will still require the disk format to order it's cylinder and heads in ascending order without gaps. So e.g. cylinder 0 head 0; cylinder 0 head 1; cylinder 1 head 0; cylinder 1 head 1...
But it won't assume the sectors within a track to be from 1 to n anymore(with a slight exception case for formatting a track).

OK. Just found out that Windows NT 3.1 only can boot it's first disk when using a 80386. When using the 80486 or Pentium CPU emulation, it simply ends up with a black screen?

Edit: OK. The same happens with a 80386. The CPU itself hasn't changed. The only thing that did change was the FDC itself. So I introduced some weird bug somewhere...
Edit: OK. Also changed the DMA page register to be precalculated for simple optimization and MMU memory mapping to be a bit more simple... Hmmm...
Edit: OK. So far managed to get the changes that cause it down to:
- DMA pending initialization for new transfers starting or new sectors transferring(e.g. continuing read/write/verify for past-initial sector sectors(each 512 bytes)).
- DACK signal handling timing.
- lockup MSR of the unresponding waiting for reset FDC
- sector increase transfer finish detection (only for non-DMA transactions).

Edit: OK. Enabling the lockup to effectively clear the MSR's command busy, RQM, have data for CPU, and nonDMA bits causes the booting Windows NT 3.1 to hang?
Edit: Just verified the others. All others were correct behaviour, it's the lockup with Sense Interrupt that's causing issues somehow? It ignores writes for new commands and makes the CPU read ST0 with the error code, then doesn't read/write anything anymore until a reset occurs(which it never does)?

Hmmmm... What does actually happen when the FDC receives a Sense Interrupt command(0x08) with no reset pending or interrupt? Of course, it will give 0x80 as the error code(invalid command) but what after that's received by the OS? Will the controller lock up? Or is this standby state a different thing altogether? Dosbox and Bochs don't seem to do this? They just return a 1-byte result, then resume normal operation for new commands?

Edit: Yay:/ Great timing to have the CMOS data destroyed somehow and the Compaq BIOS spewing out all kinds of errors! 😖
Edit: A quick reconfiguration of the CMOS RAM and settings later it's fixed again.
Edit: OK. The hang still occurs and this issue with an invalid Sense Interrupt command still occurs during directly after the NT boot loader?

Edit: Managed to 'fix' said issue by making the Sense Interrupt without IRQ or reset pending report ST0 as an error(0x80|(ST0&0x3F)) like Dosbox/Bochs do, but then entering normal result phase with the resulting ST0 and current cylinder for the selected drive. No error being thrown in that case.
That manages to get NT 3.1 workstation setup disk 1 booting properly again.

Just have been thinking about something: what exactly clears the disk changed flag?

All the documentation I find says when the FDC seeks the disk, but is that only when executing disk seek(0xF) commands? What about read(ID/sector)/write/format commands? And read/write with implicit seek?

Hmmm... It's even more specific, according to Bochs? Only when changing to a different track it's cleared for all kinds of seeks? That's just for the seek command, implicit read/write seeks and next sector EOT cylinder increments after reading/writing a sector.

superfury wrote on 2020-02-03, 07:29:

Just have been thinking about something: what exactly clears the disk changed flag?

It's a function of the drive not the controller so different drives might be different. The common Teac fd-55gfr manual (https://deramp.com/downloads/floppy_drives/te … %20FD-55GFR.pdf) says it's cleared when a disk is inserted and a step pulse occurs.

crazyc wrote on 2020-02-03, 16:34:

superfury wrote on 2020-02-03, 07:29:

Just have been thinking about something: what exactly clears the disk changed flag?

It's a function of the drive not the controller so different drives might be different. The common Teac fd-55gfr manual (https://deramp.com/downloads/floppy_drives/te … %20FD-55GFR.pdf) says it's cleared when a disk is inserted and a step pulse occurs.

OK. That's also according to Bochs and fully implemented now.

Just tried a Wind0ws NT 3.1 reinstall on the 80386 and just as on the 80486, it crashes on floppy.sys early during the first boot after setup reboots for the first time for the graphical portion of the setup.
It says some kind of Unknown Hard error in said sys file. It starts booting, displaying the blue screen with OS and memory, then suddenly speeds up(probably HLTing the CPU) to 40% speed, then loads some more hard disk and almost immediately after said speedup crashes on floppy.sys with said error. I don't see any floppy commands being executed other than during the BIOS part of booting until the boot sector of the HDD is loaded.

What happens when you try to read the last sector on a disk?

Since it reaches EOT on this disk in MT mode, the head will flip and the sector number will reset. Also, the cylinder number would increase to out of bounds.

As far as I know, with the BIOS booting up seeking the disks to detect 40/80-track disks, it seeks past the amount of physical cylinders, which gets stuck to the last physical cylinder. The logical count will increase, however. Then it seeks back to track 0, keeping in mind the TRK0 signal to detect when it's actually at track 0. With 40 tracks(starting at track 48 or 8, don't exactly remember), it will reach physical track 0 early, thus detecting a 40-track drive. But on 80-track drives, it will successfully not reach track 0 in time, thus detecting it as a 80-track drive.

Now, how will this affect implicit seeks? UniPCemu keeps two tracks of the 'current track': the current idea of the controller(currentcylinder) and the physical drive's track number(physicalcylinder). When it seeks past the last track during a seek command, it will increase currentcylinder, but not increase physicalcylinder(clamped to 39(40 tracks) or 79(80 tracks) usually).
Does the same kind of effect happen when the track number increases due to EOT being read/written?
So what's the result(CHS in the result phase) and the physical(physicalcylinder) and controller's idea(currentcylinder) cylinder location when e.g. track 79 head 1 sector 18 is read? Currently, currentcylinder can increase infinitely, while physicalcylinder is clamped to the amount of cylinders on the drive/disk.
What would correct behaviour be? (Of course, reading/writing/formatting when current!=physical errors it out)

Edit: Hmmm... One thing I notice with NT, is that it only sends writes to the DOR, then nothing is done after that? No proper reset or IRQ?

Edit: I keep getting the c0000221 Unexpected Hard Error on FLOPPY.SYS?
Edit: Tried older versions of UniPCemu(up to the beginning of December) as well, even the builds that I remember to have worked(from when I fixed the VGA display when booting), but the all crash in exactly the same way: with said BSOD on FLOPPY.SYS!

Just tried NT 4.0 workstation again, installing it from Windows 95 instead of booting it directly.

It copies some files over(which takes a while), then reboots into NT 4.0 itself.

But then I get the error message:

1STOP; 0x0000007B (0xFDC13BD4,0xC0000034,0x00000000,0x00000000).
2INACCESSABLE BOOT DEVICE

Searching a bit on Google, I find this: https://www.bleepingcomputer.com/forums/t/830 … nt-workstation/

gavinseabrook says there:

You receive a "Stop 0x0000007B" error message when you try to start your computer after you move the dynamic hard disk When you […]
Show full quote

You receive a "Stop 0x0000007B" error message when you try to start your computer after you move the dynamic hard disk
When you start your Windows 2000-based computer, you receive the following Stop error message:
STOP: 0x0000007b (0xf881b84c,0xc0000034,0x00000000,0x00000000)
INACCESSIBLE_BOOT_DEVICE

0xc00000034 STATUS_OBJECT_NAME_NOT_FOUND
Cause
This error message may occur if the primary disk group identity of the hard disk does not match the primary disk group identity that is stored in the registry. This mismatch may occur if all the following conditions are true: • You configure the hard disk that contains the system partition as a dynamic disk on a computer that is running Windows 2000.
• You remove the hard disk from the computer, and then install the hard disk in a second Windows 2000-based computer.
• You import the hard disk to a disk group that contains dynamic disks on the second Windows 2000-based computer.
• You return the hard disk from the second computer to the first computer.

So some CPU error still? Or perhaps some weird HDD error?