search

skiselev / floppy_bios

Multi-Floppy BIOS Extension
GNU General Public License v3.0
42 stars 8 forks source link

Automatic detection of AT delays fails on IBM 5160 XT #6

Open KyleJ61782 opened 2 years ago

KyleJ61782 commented 2 years ago

In playing with the version 2.6 firmware, I noticed that the computer kept freezing on boot, when showing the floppy firmware status information. I backed down to version 2.2 and found that startup proceeded normally and was able to increase to version 2.4 without issue. Once I bumped to 2.5, I noticed that it once again froze on boot. After performing a bisect, I determined that revision f71cbc48, "Autodetect delay type", introduced the freezing. After updating to the latest version 2.6 code and adding jmp .exit right after the sti instruction in check_delays, the 2.6 firmware booted properly.

Realistically I'm not quite sure what to do to fix that, but it appears perhaps it's detecting AT delays even though it's running on an XT and that's why it's freezing?

skiselev commented 2 years ago

This is weird. The check_delays subroutine checks if the machine is an AT by reading port 61h bit 4 and checking if that bit changes. On an XT this bit is not supposed to change, while on an AT it will be flipping approximately every 15 us. It appears that on your machine that bit somehow changes. Do you have an original IBM XT, or an XT clone? What clone? If it's based on the chipset, what chipset does it use?

KyleJ61782 commented 2 years ago

It's actually an original IBM 5160 with a 64-256KB system board modded to allow for 640KB.

KyleJ61782 commented 2 years ago

Would it be possible to do something like read the DMA channel 0 address register twice? First read would get the low address byte, second would get the high address byte, you'd toss the high and mask off everything but the low bit of the low byte as that would toggle as the DMA address is automatically incremented at each refresh? That way, I'd think you could use the same delay for both XT and AT boards as they both should use the DMA to perform RAM refresh.

KyleJ61782 commented 2 years ago

I should also add that it appears port 61h is supposed to be a write only port on an XT according to the RBIL (https://fd.lod.bz/rbil/ports/keyboard/p0060006f.html), so I'm not sure this detection method is foolproof if reading simply reads a high-Z state off of the 8255 port B data lines.

tgmaxx commented 2 years ago

In playing with the version 2.6 firmware, I noticed that the computer kept freezing on boot, when showing the floppy firmware status information. I backed down to version 2.2 and found that startup proceeded normally and was able to increase to version 2.4 without issue. Once I bumped to 2.5, I noticed that it once again froze on boot. After performing a bisect, I determined that revision f71cbc4, "Autodetect delay type", introduced the freezing. After updating to the latest version 2.6 code and adding jmp .exit right after the sti instruction in check_delays, the 2.6 firmware booted properly.

Realistically I'm not quite sure what to do to fix that, but it appears perhaps it's detecting AT delays even though it's running on an XT and that's why it's freezing?

I have the same problem. My system is the same as KyleJ61782's -- original 5160, 64-256KB motherboard.

Maxx1234 commented 2 years ago

I have the same exact FD BIOS v2.5/v2.6 problem with a Juko ST-12 and a Fujitech Jumbo Turbo Board (clone of DTK PIMTB10Z) when using Super PC/Turbo XT BIOS v3.1, Fujitech BIOS v4.1 and DTK ERSO BIOS v3.23.

Does not happen with Phoenix BIOS v2.52F and JUKO/NEL BIOS v2.32.