Hmmmm... So looking at the booting process of Windows NT 4's boot disk, it sets the EOT fields to 0xF, so limiting it to sector 15 within the track. That causes issues with the way the FDC handles it's maximum sector before switching heads.

So I've changed it back to the old value(depend on the drive's geometry instead) for now.

Edit: Seems like the changes I've made based on the http://www.isdaman.com/alsos/hardware/fdc/floppy.htm documentation, the Read Track (x2h) improved the loading a bit. It now ends the loading process at linear memory location 0x86000. So that's a bit further ahead than before.

But eventually, the very same error still occurs?

So even though the floppy disk problem itself seems to be solved now(as far as I could see with the lower cylinders), the Windows NT 4 workstation setup/ntdll.dll still crashes?

Edit: This is what happens now:

19,1,3=>49e00
29,1,4=>4a000
39,1,5=>4a200
49,1,6=>4a400
59,1,7=>4a600
69,1,8=>4a800
79,1,9=>4aa00
89,1,a=>4ac00
99,1,b=>4ae00
109,1,c=>4b000
119,1,d=>4b200
129,1,e=>4b400
139,1,f=>4b600
149,1,10=>4b800
159,1,11=>4ba00
169,1,12=>4bc00
17a,0,1=>4be00 (a,0,1=>49e00?)
18a,0,2=>4c000 (a,0,2=?4a000?)
19a,0,3=>4c200 (a,0,3=>4a200?)
20a,0,4=>4c400 (a,0,4=>4a400?)

So each track seems to reset the buffer back to some start address(49e00 in this case)?

Weird that NT4 seems to set the max sector number/track size field to 0xF, while it should be ox12 instead, according to e.g. the osdev documentation(for 18 SPT)?

I've now modified it to only obey the field when in non-DMA mode, but in DMA mode it assumes the EOT by the drive geometry(it's SPT setting to be exact), while terminating(finishing normally) the command when encountering DMA Terminal Count(functioning as a end-of-command/EOT(while finishing the command) marker for sector transfers being completed).

It's supposed to be 0x12 instead of 0xF, according to osdev? https://wiki.osdev.org/Floppy_Disk_Controller#Read.2FWrite

What about DMA modes? Is it still valid in that case? What does said field do?

superfury wrote on 2020-01-30, 08:04:

I've now modified it to only obey the field when in non-DMA mode, but in DMA mode it assumes the EOT by the drive geometry(it's SPT setting to be exact),

This is wrong. The controller has no idea about the disk geometry except what is loaded into the eot field. If it's setting eot to 15 then it probably thinks they are 5.25" 1.2MB floppies.

Hmmm... Linux's floppy driver sheds some more light:
https://github.com/torvalds/linux/blob/master … /block/floppy.c

1/* work around a bug in pseudo DMA
2 * (on some FDCs) pseudo DMA does not stop when the CPU stops
3 * sending data.  Hence we need a different way to signal the
4 * transfer length:  We use SECT_PER_TRACK.  Unfortunately, this
5 * does not work with MT, hence we can only transfer one head at
6 * a time
7 */

So, in that case, the SPT(EOT actually) field is used during most modes, but when using DMA with MT set, it is ignored and just the DMA TC is used(EOT is determined by the physical track length instead)?
Of course, without DMA(in non-DMA modes) that would mean that with all other modes(non-DMA and/or MT not set) the 6th field is actually used to terminate the transfer when having read/written said sector number or TC is set, while only with DMA and MT both set it's ignored and the transfer continues on until either TC occurs or the disk's own EOT is overflown(reaching the index hole again).

Would that be correct?

crazyc wrote on 2020-01-30, 14:47:

superfury wrote on 2020-01-30, 08:04:

I've now modified it to only obey the field when in non-DMA mode, but in DMA mode it assumes the EOT by the drive geometry(it's SPT setting to be exact),

This is wrong. The controller has no idea about the disk geometry except what is loaded into the eot field. If it's setting eot to 15 then it probably thinks they are 5.25" 1.2MB floppies.

I do have the CMOS byte at 10h(floppy disk byte) set to 67(0x43)? So that would mean: first floppy disk(the one setup uses) to 0x4, thus 1.44M floppy, while the second one(the other floppy disk) is 0x3, thus 720K.
Although I don't know for sure how the BIOS acts with the 1.44MB one? Perhaps it can't properly handle that value on the disk setting? I know that up to 720K is supported by the Compaq Deskpro 386 BIOS, but I doubt that Windows NT 4 workstation uses the BIOS for it's disk I/O?
The 720K is enough to make the BIOS work properly, mainly for it seeking 80 tracks instead of 40(required for proper booting of e.g. Windows 95's setup disk), but why would it be setting said value after it loads NT's base drivers in protected mode(it displays the message that it's detecting hardware at disk 1, so it must have loaded the drivers, shouldn't it?)?

Hmmm... After those last changes, rewriting said floppy disks using WINNT.EXE /ox and rebooting said disks, after Windows NT 4 starts it's kernel, I actually see it addressing the floppy disk with EOT=18(12h) a few times after loading the kernel?

So perhaps that's an issue with the BIOS in some weird way(Compaq Deskpro 386 rev J.4 BIOS from PCjs)?

Anyway, it seems it's probably correctly loading the files now(I think), but still crashes the OS due to once again the very same reason(perhaps some weird obfuscated CPU bug)?

Hmmmm... When looking at trying to get ATAPI.SYS working on NT 3.1 to install NT 4 from the CD-ROM drive(from the NT 3.1 OS itself with ATAPI CD-ROM support), I keep getting the error screen during setup:
https://www.betaarchive.com/forum/viewtopic.php?f=61&t=36255

It's the same as Condor.07's final screen capture:
https://ibb.co/bSKkFT

That happens during the configuration step of the HDD it seems?
Edit: OK, the same happens when I try it on Bochs?

OK. Just tried NT 3.51 build 3.51.1057.1. It crashes in exactly the same way as NT4 does(with exactly the same error message and error codes)?

Hmmmm... Just have been thinking...

Currently, the FDC stops a read/write operation when the (previously mentioned) EOT is reached(either byte 6 of the parameters or the geometry's SPT setting during DMA MultiTrack(MT) mode).

Previously, when it was successfully installing Windows NT 3.1, it stopped the transfer when either TC was reached or EOT was reached(and switching the head to head 0 during MT mode only). Said EOT finishing the command transfer(and enter results phase) was only done when in non-DMA mode. When in DMA mode, EOT had effect on the result, but not on the transfer itself(it just used TC for that).

Since having changed said behaviour to always apply(using it for DMA mode as well), the Windows NT 3.1 setup failed to install itself properly for the first reboot.

The only thing radically changing in this case(during setup), since it uses DMA mode with MT set for any transfer, is the handling of the floppy-based termination of the transfer when using the used EOT field(either disk geometry based(DMA+MT used, based on the linux floppy driver) or parameter 6-based(all other cases)).

Does the effective EOT have effect on the transfer finishing and entering the result phase during the execution phase when in DMA mode? The old code didn't(it just relied on TC only), while the new code does(and fails installing Windows NT 3.1's until first reboot(Windows NT saying in a GUI window that Windows wasn't properly installed)).

OK. With those latest improvements, Windows NT 3.1 workstation boots fine on a 80386, but on the 80486 it crashes with a message saying that windows wasn't copied/installed correctly and please run setup again?

superfury wrote on 2020-02-01, 10:51:

Does the effective EOT have effect on the transfer finishing and entering the result phase during the execution phase when in DMA mode?

The transfer ends when tc is set no matter the mode, although for the pc only dma mode matters. If eot is reached, side one only for mt mode, and tc is not set then the command results in an error. The pcjr actually relies on this.

What about non-DMA(polling?) modes? Since non-DMA doesn't use DMA, TC should probably be ignored? Then would in non-DMA mode the EOT setting be the only way to make it end a command that's transferring sectors(so, by sector overflowing(when sector>EOT and not MT))?

I've been wondering for a bit about something. The DMA modes are enabled by seting the DMA/IRQ bit in the Digital Output Register(DOR) ( http://www.isdaman.com/alsos/hardware/fdc/floppy.htm ).
Are IRQs also enabled in non-DMA modes? As it requires single-byte transfers in non-DMA mode, IRQs are optional(for each byte that's transferred, except when using a FIFO buffer)?

One little question about the FIFO, though: are FIFO buffers required to be emulated? Or are they optional? UniPCemu currently ignores said FIFO buffer size and always assumes a 1 effectively(although it never overflows the buffer as it's not refilled when it's still full for CPU reading). The same kind of thing applies to writes(the drive mechanics aren't depending on the timing for that at all). Essentially, it waits for the CPU or DMA(whichever is active) to read/write the data port before it starts to queue the next byte from/to the disk buffer(essentially allowing an unlimited timeout on the 'FIFO'). Of course, if the required read or write never comes, it will wait forever and not timeout in any way.

Nope, tc is valid in non-dma mode too otherwise there'd be no way to end the read early which is why it doesn't work properly on pcs where tc is only connected to the dmac. The nec pc100, nec pc8801 and amstrad pcw are examples of computers that work this way. ("no way to end the read early" isn't exactly true as the pcjr example above but that is abusing eot behavior and not how the controller is designed to work)

But with PC XT or AT/Compaq/more modern architectures, the only one to drive TC is DMA afaik? How is it driven with modern motherboards? Can the CPU trigger TC without a DMA transfer being active? If so, how(currently emulating XT, AT and Compaq Deskpro 386)?

superfury wrote on 2020-02-01, 21:50:

But with PC XT or AT/Compaq/more modern architectures, the only one to drive TC is DMA afaik?

crazyc wrote on 2020-02-01, 20:57:

which is why it doesn't work properly on pcs where tc is only connected to the dmac.

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

superfury wrote on 2020-02-01, 21:50:

But with PC XT or AT/Compaq/more modern architectures, the only one to drive TC is DMA afaik?

crazyc wrote on 2020-02-01, 20:57:

which is why it doesn't work properly on pcs where tc is only connected to the dmac.

OK. So the only way to actually send TC is by a DMA transfer to go from 1 left to 0 left, setting TC and thus making the floppy disk go to result phase?

And the floppy disk controller, once it goes to result phase, of course stops raising DREQ, so overflow on DMA can not happen(it can only happen when transferring more on DMA than the disk can handle) and of course in PIO mode(the polling (error code 3 in the ST0 register))?

And of course errors during transferring in DMA mode makes the controller switch to result phase, thus clearing DREQ(and I think ignoring DACK I think), which has the effect of only the CPU being able to read the result codes and send new commands(ofc sending data through PIO while in result phase causes a polling error afaik)?

Also, the floppy not knowing about EOT is obviously not the case: it can see the index hole being passed by, so it knows it's reached the end of the track?

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

OK. So the only way to actually send TC is by a DMA transfer to go from 1 left to 0 left, setting TC and thus making the floppy disk go to result phase?

I suppose but I don't know of anyone whose tried it. It's possible that different 8237 implementations (chipsets etc) might not handle that properly either. The most reliable way would probably be to do it like the pcjr which sets the controller to dma mode and polls for data, ignoring tc entirely.

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

Also, the floppy not knowing about EOT is obviously not the case: it can see the index hole being passed by, so it knows it's reached the end of the track?

Doesn't matter. Sectors may be interleaved or misnumbered entirely. Some machines use 0 based sector numbering and copy protection can do all kinds of weird things. The controller doesn't have any way to know any of this.

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

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

OK. So the only way to actually send TC is by a DMA transfer to go from 1 left to 0 left, setting TC and thus making the floppy disk go to result phase?

I suppose but I don't know of anyone whose tried it. It's possible that different 8237 implementations (chipsets etc) might not handle that properly either. The most reliable way would probably be to do it like the pcjr which sets the controller to dma mode and polls for data, ignoring tc entirely.

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?).

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

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

Also, the floppy not knowing about EOT is obviously not the case: it can see the index hole being passed by, so it knows it's reached the end of the track?

Doesn't matter. Sectors may be interleaved or misnumbered entirely. Some machines use 0 based sector numbering and copy protection can do all kinds of weird things. The controller doesn't have any way to know any of this.

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)))). Also, it will search the entire track for the used CHS address to return, in ascending CHS order I assume? So first CHS 0,0,1, then 0,0,2, 0,0,3 etc? And then passing the index hole twice when searching(meaning, reached EOT, more searching, EOT again, thus searched the entire track for the CHS address failed and aborts the process with an error?