FAT problems in MartyPC

[Vutshi]

@ghaerr, here is the problem I mentioned in previous issue.

The experiment is done using the latest kernel with /DEV FAT fixed.

Direct hw floppy is switched off

Second floppy with MINIX filesystem works fine, however if I use FAT floppy things become quite random. Here is the log:

Master at 300h: MartyPC Hard Drive
Slave  at 300h: not found
Booting A A
ELKS....../linux................................................................
..................
ELKS Setup .........FHt0330 f0E8E d13C8 INT f206 START
ttyS0 3f8 irq 4 8250, ttyS1 2f8 irq 3 8250
Direct console, scan kbd 80x25 emulating ANSI (2 virtual consoles)
64K ext buffers, 8K cache, 15 req hdrs
fd: no get drive fn, ndrives 2
fd0: default 360k
fd1: default 360k
hda:   31M CHS 615, 4,26
fd0:  360K CHS  40, 2,9
fd1:  360K CHS  40, 2,9
hda:(0,63960) hda1:(26,63934)
boot: BIOS drive 0, root device /dev/fd0 (0320)
PC/XT class cpu 2, syscaps 0, 640K base ram, 16 tasks, 64 files, 96 inodes
ELKS 0.9.1 (46560 text, 21408 ftext, 6848 data, 5072 bss, 53614 heap)
Kernel text 330 ftext e8e init 122c data 13c8 end 23c8 top a000 496+6+0K free
fd0: ELKS bootable, has 80 cylinders, 2 heads, and 36 sectors
MINIX-fs: mounting unchecked filesystem /dev/fd0, running fsck recommended
VFS: Mounted root device /dev/fd0 (0320) minix filesystem.
Running /etc/rc.sys script
Fri Oct 11 09:47:13 1991

ELKS 0.9.1

[5.23 secs] login: root
# mount /dev/fd1 /mnt/
fd1: probed, probably has 40 cylinders, 2 heads, and 36 sectors
bioshd(1): track read retry #1 CHS 0/0/3 count 18
fd1: probed, probably has 40 cylinders, 2 heads, and 36 sectors
FAT: me=fd,csz=2,#f=2,floc=1,fsz=2,rloc=5,#d=112,dloc=12,#s=720,ts=0
FAT: total 360k, fat12 format
# cp /mnt/msdobioshd(1): track read retry #1 CHS 0/0/7 count 18
# cp /mnt/msdos.sys /home/
bioshd(1): track read retry #1 CHS 1/0/19 count 18
bioshd(1): track read retry #1 CHS 1/0/21 count 16
bioshd(1): track read retry #1 CHS 1/0/23 count 14
bioshd(1): track read retry #1 CHS 1/0/25 count 12
# cmp /mnt/msdobioshd(1): track read retry #1 CHS 0/0/5 count 18
bioshd(1): track read retry #1 CHS 0/0/7 count 18
# cmp /mnt/msdos.sys /home/msdos.sys
bioshd(1): track read retry #1 CHS 1/0/5 count 18
bioshd(1): track read retry #1 CHS 1/0/7 count 18
bioshd(1): track read retry #1 CHS 1/0/9 count 18
bioshd(1): track read retry #1 CHS 1/0/11 count 18
Files differ at byte position 13313
# cmp /mnt/msdos.sys /home/msdos.sys
Files differ at byte position 13313
# cmp /mnt/msdos.sys /home/msdos.sys
Files differ at byte position 13313
# cp /mnt/command.com /home/
bioshd(1): track read retry #1 CHS 3/0/19 count 18
bioshd(1): track read retry #1 CHS 3/0/21 count 16
bioshd(1): track read retry #1 CHS 3/0/23 count 14
bioshd(1): track read retry #1 CHS 3/0/25 count 12
# cmp /mnt/command.com /home/command.com
Files are identical
# cmp /mnt/msdos.sys /home/msdos.sys
bioshd(1): track read retry #1 CHS 1/0/5 count 18
bioshd(1): track read retry #1 CHS 1/0/7 count 18
bioshd(1): track read retry #1 CHS 1/0/9 count 18
bioshd(1): track read retry #1 CHS 1/0/11 count 18
Files differ at byte position 13313
# cmp /mnt/command.com /home/command.com
bioshd(1): track read retry #1 CHS 3/0/3 count 18
bioshd(1): track read retry #1 CHS 3/0/5 count 18
bioshd(1): track read retry #1 CHS 3/0/7 count 18
bioshd(1): track read retry #1 CHS 3/0/9 count 18
bioshd(1): track read retry #1 CHS 3/0/11 count 18
bioshd(1): track read retry #1 CHS 3/0/13 count 18
Files differ at byte position 6145
# cmp /mnt/command.com /home/command.com
Files differ at byte position 6145
# cmp /mnt/msdos.sys /home/msdos.sys
Files differ at byte position 13313
#

[ghaerr]

This appears very close to a problem previously seen in QEMU, where its BIOS issues a read error when switching drives. I've never been able to figure out fully why this is happening, but it was fixed (for QEMU only) in #1119. Take a read of that issue for more detailed information.

It seems possible the explanation in #1119 may be the same issue in MartyPC. If so, try the following quick fix in elks/arch/i86/drivers/block/bios.c:

#if RESET_DISK_CHG
    static unsigned last = 0;
    if (/*running_qemu && */ drive != last) {  // <---- comment out 'running_qemu' for now
        bios_disk_reset(1); /* fixes QEMU retry when switching drive types #1119 */
        last = drive;
    }
#endif 

The reason this fix was only added for QEMU is that a disk reset is expensive on many BIOSes and can cause real hardware to issue a reset to the FDC, which might then perform a floppy head re-sync, which is super slow.

If this fix works, we may have to add it for MartyPC, and the problem will then be how to determine programmatically that its running vs QEMU or real hardware. We can discuss that later.

[Vutshi]

Thanks, I'll try it.

I also forgot to say that with direct floppy support the problem also exists in MartyPC with FAT floppies.

[ghaerr]

I also forgot to say that with direct floppy support the problem also exists

The direct floppy driver doesn't use the messages that are displayed above, instead an entirely different method. Can you please post the error messages displayed when using the direct driver, so I can try to track that down?

[Vutshi]

Oh, apparently Direct Floppy is not running in MartyPC:

Master at 300h: MartyPC Hard Drive
Slave  at 300h: not found
Booting A A
ELKS....../linux................................................................
..........................
ELKS Setup .........FHt0330 f0F10 d1512 INT f202 START
ttyS0 3f8 irq 4 8250, ttyS1 2f8 irq 3 8250
Direct console, scan kbd 80x25 emulating ANSI (2 virtual consoles)
64K ext buffers, 8K cache, 15 req hdrs
df: CMOS df0 is unknown (15)df0 is 360k/PC (1), df1 is unknown (15)
fd: no get drive fn, ndrives 2
fd0: default 360k
fd1: default 360k
hda:   31M CHS 615, 4,26
fd0:  360K CHS  40, 2,9
fd1:  360K CHS  40, 2,9
hda:(0,63960) hda1:(26,63934)
boot: BIOS drive 0, root device /dev/fd0 (0320)
PC/XT class cpu 2, syscaps 0, 640K base ram, 16 tasks, 64 files, 96 inodes
ELKS 0.9.1 (48640 text, 24608 ftext, 8240 data, 5152 bss, 52142 heap)
Kernel text 330 ftext f10 init 1362 data 1512 end 2512 top a000 491+6+0K free
fd0: ELKS bootable, has 80 cylinders, 2 heads, and 36 sectors
MINIX-fs: mounting unchecked filesystem /dev/fd0, running fsck recommended
VFS: Mounted root device /dev/fd0 (0320) minix filesystem.
Running /etc/rc.sys script
Fri Oct 11 09:47:13 1991

ELKS 0.9.1

[5.25 secs] login: root
# mount /dev/fd1 /mnt/
fd1: probed, probably has 40 cylinders, 2 heads, and 36 sectors
bioshd(1): track read retry #1 CHS 0/0/3 count 18
fd1: probed, probably has 40 cylinders, 2 heads, and 36 sectors
FAT: me=fd,csz=2,#f=2,floc=1,fsz=2,rloc=5,#d=112,dloc=12,#s=720,ts=0
FAT: total 360k, fat12 format
# cp /mnt/msdos.sys /home/
bioshd(1): track read retry #1 CHS 1/0/19 count 18
bioshd(1): track read retry #1 CHS 1/0/21 count 16
bioshd(1): track read retry #1 CHS 1/0/23 count 14
bioshd(1): track read retry #1 CHS 1/0/25 count 12
# cmp /mnt/msdos.sys /home/msdos.sys
bioshd(1): track read retry #1 CHS 0/0/5 count 18
bioshd(1): track read retry #1 CHS 1/0/5 count 18
bioshd(1): track read retry #1 CHS 1/0/7 count 18
bioshd(1): track read retry #1 CHS 1/0/9 count 18
bioshd(1): track read retry #1 CHS 1/0/11 count 18
Files differ at byte position 13313
#

[Vutshi]

#if RESET_DISK_CHG
    static unsigned last = 0;
    if (/*running_qemu && */ drive != last) {  // <---- comment out 'running_qemu' for now
        bios_disk_reset(1); /* fixes QEMU retry when switching drive types #1119 */
        last = drive;
    }
#endif 

This trick didn't help Marty

[Vutshi]

Marty just hangs if I switch off BIOS floppy support:

Boot   [ COLD ]
RAM    [ 640 KB OK ]            Video  [ CGA ]
CPU    [ 8088 ]                 FPU    [ None ]
LPT    [ None ]                 COM    [ 03F8 02F8 ]
ROM    [ C800 ]                 Size   [ 12 KB ]
FDD    [ 2 ]


-=XTIDE Universal BIOS (XT)=- @ C800h
r631 (2025-02-01)
Released under GNU GPL v2

Master at 300h: MartyPC Hard Drive
Slave  at 300h: not found
Booting A A
ELKS....../linux................................................................
........................
ELKS Setup .........FHt0330 f0F0B d14C9 INT f202 START
ttyS0 3f8 irq 4 8250, ttyS1 2f8 irq 3 8250
Direct console, scan kbd 80x25 emulating ANSI (2 virtual consoles)
64K ext buffers, 8K cache, 15 req hdrs
df: CMOS df0 is unknown (15)df0 is 360k/PC (1), df1 is unknown (15)
hda:   31M CHS 615, 4,26

[Vutshi]

@ghaerr, does direct floppy support second FDD?

Kernel without BIOS floppy support shows only df0

./qemu.sh -fdb image/testing.IMG

[ghaerr]

@Vutshi:

does direct floppy support second FDD?

Yes, and it's well tested. However, the DF driver only reads the (emulated) CMOS in order to determine how many and what type of floppies are present, no media probing or other mechanisms are used to determine drive or floppy media type. This is displayed once at boot as "df: CMOS df0 is xxxMb (N)" where N is the CMOS drive type.

./qemu.sh -fdb image/testing.IMG

That is strange, since my QEMU shows the following which is working for two floppies, using the same QEMU arguments (both 2.88M floppy images):

Oh, apparently Direct Floppy is not running in MartyPC:

This first attempt of yours looks like MartyPC was setup for HD, not fd. DF is not mentioned at boot.

Marty just hangs if I switch off BIOS floppy support:

This attempt seems to show that MartyPC is setup for floppy, but that it may not be emulating CMOS drive type as required: (?)

df: CMOS df0 is unknown (15)df0 is 360k/PC (1), df1 is unknown (15)

This trick didn't help Marty

Perhaps try resetting both drives instead, just to see if that makes a difference:

#if RESET_DISK_CHG
    static unsigned last = 0;
    if (/*running_qemu && */ drive != last) {  // <---- comment out 'running_qemu' for now
        bios_disk_reset(0); // <- add this line 
        bios_disk_reset(1); // <- and this line
        last = drive;
    }
#endif

There seem to be two problems, 1) MartyPC isn't setting CMOS drive type, so DF can't be tested, and 2) MartyPC isn't working properly when switching drives (triggered by FAT but not MINIX) during file copies. This second problem has been seen only on QEMU but not fully understood, and cannot be repeated on real hardware. On QEMU, the message was eliminated by the RESET_DISK_CHG fix, but there were never data errors, the BIOS driver does a bios_disk_reset() after errors, and the user never gets a data read/write error. The fix only removed the BIOS retry error message.

Perhaps you might mention these issues to the MartyPC maintainer to see what he thinks. He might also know if there's a way to have the emulator report its own internal BIOS read/write sector errors for more analysis when running ELKS or DOS file copies.

[Vutshi]

may not be emulating CMOS drive type as required

Does IBM XT have a CMOS?

[ghaerr]

Does IBM XT have a CMOS?

Upon research, apparently it does not! Some documentation shows it used motherboard DIP switches. The XT/286 introduced CMOS.

This means that the DF driver isn't configurable on XT, except that drive 0 defaults to 360k when CMOS is not readable. Drive 1 remains inaccessible.

While this doesn't show why MartyPC fails to boot on DF, something likely will have to be done to allow either non-360k drives and/or a default 360k second floppy drive.

What do you think?

[toncho11]

IBM XT 5160 has no real time clock, no battery. But Amstrad 1640 has these and it uses 8086 instead of 8088.

[Vutshi]

Regarding problem 1:

1. MartyPC isn't setting CMOS drive type, so DF can't be tested

I disabled the HDD, and the boot process progressed a little further.

GLaBIOS [ ] Reboot the Past
(C) 2022-25 640KB Released under GPLv3

Boot   [ COLD ]
RAM    [ 640 KB OK ]            Video  [ CGA ]
CPU    [ 8088 ]                 FPU    [ None ]
LPT    [ None ]                 COM    [ 03F8 02F8 ]
FDD    [ 2 ]

ELKS......../linux..............................................................
....................................
ELKS Setup .........FHt0330 f0F0B d14C9 INT f202 START
ttyS0 3f8 irq 4 8250, ttyS1 2f8 irq 3 8250
Direct console, scan kbd 80x25 emulating ANSI (2 virtual consoles)
64K ext buffers, 8K cache, 15 req hdrs
df: CMOS df0 is unknown (15)df0 is 360k/PC (1), df1 is unknown (15)
boot: BIOS drive 0, root device /dev/df0 (0400)
PC/XT class cpu 2, syscaps 0, 640K base ram, 16 tasks, 64 files, 96 inodes
ELKS 0.9.1 (48560 text, 23520 ftext, 8000 data, 5152 bss, 52382 heap)
Kernel text 330 ftext f0b init 1330 data 14c9 end 24c9 top a000 492+6+0K free
df: can't get FDC version
VFS: Unable to open root device /dev/df0 (0400) -5

SYSTEM HALTED - Press CTRL-ALT-DEL to reboot:

and here is the corresponding status of FDC:

[ghaerr]

The reason for the boot failure is the same:

df: CMOS df0 is unknown (15)df0 is 360k/PC (1), df1 is unknown (15)

The DF driver is reading non-existent CMOS and getting '15', instead of valid values of 1-5.

To fix this, change the following code in directfd.c to force a CMOS 'read' to return 1:

static unsigned char * INITPROC find_base(int drive, int type)
{
    unsigned char *base;

    type = CMOS_360k; // <--- add this line

    if (type > 0 && type <= CMOS_MAX) {
        base = probe_list[type - 1];
        printk("df%d is %s (%d)", drive, minor_types[*base].name, type);
        return base;
    }
    printk("df%d is unknown (%d)", drive, type);
    return NULL;
}

I can't fully read the "df: can't get FDC version" error message above, so this patch may not work, please try it anyway.

[Vutshi]

CMOS force read result:

ELKS......../linux..............................................................
.....................................
ELKS Setup .........FHt0330 f0F0B d14C7 INT f202 START
ttyS0 3f8 irq 4 8250, ttyS1 2f8 irq 3 8250
Direct console, scan kbd 80x25 emulating ANSI (2 virtual consoles)
64K ext buffers, 8K cache, 15 req hdrs
df: CMOS df0 is 360k/PC (1), df1 is 360k/PC (1)
boot: BIOS drive 0, root device /dev/df0 (0400)
PC/XT class cpu 2, syscaps 0, 640K base ram, 16 tasks, 64 files, 96 inodes
ELKS 0.9.1 (48560 text, 23488 ftext, 7952 data, 5152 bss, 52430 heap)
Kernel text 330 ftext f0b init 1330 data 14c7 end 24c7 top a000 492+6+0K free
df: can't get FDC version
VFS: Unable to open root device /dev/df0 (0400) -5

SYSTEM HALTED - Press CTRL-ALT-DEL to reboot:

[Vutshi]

Apparently, MartyPC has µPD765 FDC. Does ELKS support it?