DOS ain't dead

> This may be a wrong format specifier, if the kernel is compiled without
> FAT32 support, because then CLUSTER is defined as unsigned short, and the
> format specified %lu in the DebugPrintf call indicates unsigned long:
>
> https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/initdisk.c#L496
>
> https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/hdr/portab.h#L296

Oh, I get it. You mean the numbers look strange because of the wrong printf specifier?

> Oh, I get it. You mean the numbers look strange because of the wrong printf
> specifier?

Yes, while it is a bug I do not think it is directly related to your problem. https://github.com/FDOS/kernel/issues/122

> > Oh, I get it. You mean the numbers look strange because of the wrong
> printf
> > specifier?
>
> Yes, while it is a bug I do not think it is directly related to your
> problem. https://github.com/FDOS/kernel/issues/122

Neither do I. It shouldn't affect anything.

Anyway, that's a good eye for bugs. :) I needed a few seconds to find it even after you mentioned it.

> > > Oh, I get it. You mean the numbers look strange because of the wrong
> > printf
> > > specifier?
> >
> > Yes, while it is a bug I do not think it is directly related to your
> > problem. https://github.com/FDOS/kernel/issues/122
>
> Neither do I. It shouldn't affect anything.
>
> Anyway, that's a good eye for bugs. :) I needed a few seconds to find it
> even after you mentioned it.

This would be the next DebugPrintf to be printed:
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/config.c#L347

It gets not printed, so the kernel hangs before it. PreConfig is called by init_kernel right after dsk_init.
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/main.c#L345

So the system hangs in anything called by dsk_init().
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/initdisk.c#L1440

You may put some DebugPrintf in initdisk.c, so see where it actually hangs. Or run the kernel under a debugger. But the first one is probably easier for the start...

> Neither do I. It shouldn't affect anything.
>

This triggeres undefined behaviour and could cause all sort of trouble. For example segfaults in memory protected systems. Very dangerous in general...

> > I built 8086 and 80186 (should be NEC V20 compatible) in fat16 and fat32
> > variants with the DEBUG flag on.
>
> Well, 80186 build refuses to boot on NEC V20.
>

This is the 186 check: https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/cpu.asm#L51

And as I just mentioned here: https://retrocomputing.stackexchange.com/questions...id-the-i186-use-interrupt-6-for-invalid-opcodes

I do detect the NEC V20 as an 186 class machine: https://hg.pushbx.org/ecm/ldebug/file/7f3440d5824d/source/init.asm#l3071

This can be adapted to the kernel's CPU detection.

Meanwhile you could patch an uncompressed kernel to skip the conditional branch that skips to the error message display. Or boot into lDebug, if possible, and trace into the early kernel init to skip the error.

---
l

I just wanted to run FreeDOS on Book8088 and now I have to hack FreeDOS kernel. Well...

Let's leave that for when I have more time, patience and brain power.

I'll just run FreeDOS userspace on EDR-DOS kernel for now.

I might try it again when I get Sergey's BIOS chip with BIOS_8088.

Edit:

What is the license of EDR-DOS kernel?

> This is the 186 check:
> https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/cpu.asm#L51
>
> And as I just mentioned here:
> https://retrocomputing.stackexchange.com/questions...id-the-i186-use-interrupt-6-for-invalid-opcodes
>
> I do detect the NEC V20 as an 186 class machine:
> https://hg.pushbx.org/ecm/ldebug/file/7f3440d5824d/source/init.asm#l3071
>
> This can be adapted to the kernel's CPU detection.
>
> Meanwhile you could patch an uncompressed kernel to skip the conditional
> branch that skips to the error message display. Or boot into lDebug, if
> possible, and trace into the early kernel init to skip the error.

Reported the 186 check missing NECs to the kernel at https://github.com/FDOS/kernel/issues/123

---
l

> I just wanted to run FreeDOS on Book8088 and now I have to hack FreeDOS
> kernel. Well...
>
> Let's leave that for when I have more time, patience and brain power.
>
> I'll just run FreeDOS userspace on EDR-DOS kernel for now.
>
> I might try it again when I get Sergey's BIOS chip with BIOS_8088.
>
> Edit:
>
> What is the license of EDR-DOS kernel?

I'm using and changing Enhanced DR-DOS according to this 2022-07-07 license agreement from DRDOS, Inc. (in the EDR-DOS repo) which refers to "CP/M and its derivatives". While others have argued that this doesn't cover (E)DR-DOS as it is too far from CP/M, my interpretation is supported by the copyright statements that date back as far as 1976 in the EDR-DOS sources.

Quoth same file as in the repo, also hosted at https://pushbx.org/ecm/download/edrdos/license.htm

> From: Bryan Sparks <*****@drycanyon.com> Thu, Jul 7, 8:04 AM
> To: Scott Chapman <******@mischko.com>
>
> Hmmm. Well, what you describe wasn't my intent but I get that this was unclear.
> It was also some time ago.
>
> Not sure how to "officially" clear this up except to modify the original email content
> removing the constraint to the website/group that was mentioned. So, perhaps, this
> will suffice:
>
> "Let this paragraph represent a right to use, distribute, modify, enhance, and otherwise
> make available in a nonexclusive manner CP/M and its derivatives. This right comes from
> the company, DRDOS, Inc.'s purchase of Digital Research, the company and all assets,
> dating back to the mid-1990's. DRDOS, Inc. and I, Bryan Sparks, President of DRDOS,
> Inc. as its representative, is the owner of CP/M and the successor in interest of
> Digital Research assets."
>
> It's a bit clumsy but this may get the intent cleared and authority upon which it is
> granted.
>
> Thanks for the email.
>
> Bryan

---
l

> I'm using and changing Enhanced DR-DOS according to
> this
> 2022-07-07 license agreement from DRDOS, Inc. (in the EDR-DOS repo)
> which refers to "CP/M and its derivatives". While others have argued that
> this doesn't cover (E)DR-DOS as it is too far from CP/M, my interpretation
> is
> supported
> by the copyright statements that date back as far as 1976 in the
> EDR-DOS sources.
>

To be honest this interpretation doesn't sound too legaly reliable. :)

But, well... I'm not a lawyer. And I don't plan to use it for commercial use, so it should be fine anyway, even according to the previous license.

I'll switch to FreeDOS anyway, one day when we make it work on Book8088.

XT-class BIOSes don't usually support LBA, so the DOS kernel has to use CHS to access the sectors on the disk.

Many DOS implementations (probably at least FreeDOS and MS-DOS, not sure) detect the disk geometry from the information in the FAT boot sector, so you cannot just write any random filesystem image to the SD card with Linux's dd command and expect it to work properly.

When creating the filesystem you need to use the same geometry that the Book8088's BIOS uses.

At least MS-DOS and FreeDOS also require that the disk is partitioned. The starting sectors of the partitions in the partition table also need to be compatible with the actual geometry.

> XT-class BIOSes don't usually support LBA, so the DOS kernel has to use CHS
> to access the sectors on the disk.
>
> Many DOS implementations (probably at least FreeDOS and MS-DOS, not sure)
> detect the disk geometry from the information in the FAT boot sector, so
> you cannot just write any random filesystem image to the SD card with
> Linux's dd command and expect it to work properly.
>
> When creating the filesystem you need to use the same geometry that the
> Book8088's BIOS uses.
>
> At least MS-DOS and FreeDOS also require that the disk is partitioned. The
> starting sectors of the partitions in the partition table also need to be
> compatible with the actual geometry.

you can test it with 86box, with 8088 machine with XT-IDE and a disk image with CHS=1006/16/63, partitioned and formatted with DOS 3.31, and boot with FreeDOS 2043-86 kernel (F16/F32 doesn't matter) and you can get same error:

(I even tried latest snapshot uploaded in github, but it makes no difference)

> > XT-class BIOSes don't usually support LBA, so the DOS kernel has to use
> CHS
> > to access the sectors on the disk.
> >
> > Many DOS implementations (probably at least FreeDOS and MS-DOS, not
> sure)
> > detect the disk geometry from the information in the FAT boot sector, so
> > you cannot just write any random filesystem image to the SD card with
> > Linux's dd command and expect it to work properly.
> >
> > When creating the filesystem you need to use the same geometry that the
> > Book8088's BIOS uses.
> >
> > At least MS-DOS and FreeDOS also require that the disk is partitioned.
> The
> > starting sectors of the partitions in the partition table also need to
> be
> > compatible with the actual geometry.
>
> you can test it with 86box, with 8088 machine with XT-IDE and a disk image
> with CHS=1006/16/63, partitioned and formatted with DOS 3.31, and boot with
> FreeDOS 2043-86 kernel (F16/F32 doesn't matter) and you can get same
> error:
>
> (I even tried latest snapshot uploaded in github, but it makes no
> difference)

There may also be something wrong with FreeDOS. I noticed that for some reason ST-DOS's partition mounter can parse logical partitions that are created with MS-DOS 6.22, but it has problems parsing logical partitions that are created with FreeDOS. FreeDOS is probably not fully following the specification of the MS-DOS partition table. FreeDOS doesn't have problems parsing partition tables that are created with its own FDISK though.

FreeDOS is clearly doing something differently than MS-DOS, but I haven't investigated what exactly is the difference.

Different versions of MS-DOS also create different partition tables and parse them differently, and they may not be 100% compatible with each other. MS-DOS 3.31 is a relatively old version, and FreeDOS only aims to be compatible with MS-DOS 6.22.

I recommend at least creating the partition tables and filesystems with the same operating system that is going to use them.

> > > XT-class BIOSes don't usually support LBA, so the DOS kernel has to
> use
> > CHS
> > > to access the sectors on the disk.
> > >
> > > Many DOS implementations (probably at least FreeDOS and MS-DOS, not
> > sure)
> > > detect the disk geometry from the information in the FAT boot sector,
> so
> > > you cannot just write any random filesystem image to the SD card with
> > > Linux's dd command and expect it to work properly.
> > >
> > > When creating the filesystem you need to use the same geometry that
> the
> > > Book8088's BIOS uses.
> > >
> > > At least MS-DOS and FreeDOS also require that the disk is partitioned.
> > The
> > > starting sectors of the partitions in the partition table also need to
> > be
> > > compatible with the actual geometry.
> >
> > you can test it with 86box, with 8088 machine with XT-IDE and a disk
> image
> > with CHS=1006/16/63, partitioned and formatted with DOS 3.31, and boot
> with
> > FreeDOS 2043-86 kernel (F16/F32 doesn't matter) and you can get same
> > error:
> >
> > (I even tried latest snapshot uploaded in github, but it makes no
> > difference)
>
> There may also be something wrong with FreeDOS. I noticed that for some
> reason ST-DOS's partition mounter can parse logical partitions that are
> created with MS-DOS 6.22, but it has problems parsing logical partitions
> that are created with FreeDOS. FreeDOS is probably not fully following the
> specification of the MS-DOS partition table. FreeDOS doesn't have problems
> parsing partition tables that are created with its own FDISK though.
>
> FreeDOS is clearly doing something differently than MS-DOS, but I haven't
> investigated what exactly is the difference.
>
> Different versions of MS-DOS also create different partition tables and
> parse them differently, and they may not be 100% compatible with each
> other. MS-DOS 3.31 is a relatively old version, and FreeDOS only aims to be
> compatible with MS-DOS 6.22.
>
> I recommend at least creating the partition tables and filesystems with the
> same operating system that is going to use them.

same HD image booted with QEMU and DOS 6.22 shows no problem:

> you can test it with 86box, with 8088 machine with XT-IDE and a disk image
> with CHS=1006/16/63, partitioned and formatted with DOS 3.31, and boot with
> FreeDOS 2043-86 kernel (F16/F32 doesn't matter) and you can get same
> error:
>
> (I even tried latest snapshot uploaded in github, but it makes no
> difference)

Can you upload an image like that? If it fails in 86box on a Linux host too I could try to debug it.

---
l

> > you can test it with 86box, with 8088 machine with XT-IDE and a disk
> image
> > with CHS=1006/16/63, partitioned and formatted with DOS 3.31, and boot
> with
> > FreeDOS 2043-86 kernel (F16/F32 doesn't matter) and you can get same
> > error:
> >
> > (I even tried latest snapshot uploaded in github, but it makes no
> > difference)
>
> Can you upload an image like that? If it fails in 86box on a Linux host too
> I could try to debug it.

if you have uudecode and xdelta3, you can create one yourself:

1. create empty file with specified size
`dd if=/dev/zero of=512M_CF.null bs=16384 count=31689`

2. save below block as `512M_CF.uue` and run `uudecode 512M_CF.uue` to generate `512M_CF.xdt`
->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-

begin 644 512M_CF.xdt
MUL/$``0:-3$R35]#1BYI;6<O+S4Q,DU?0T8N;G5L;"\$A6^$@(```(4$3!(C
M4"[@^C/`CM"\`'R+]%`'4!_[_+\`!KD``?*EZAT&``"^O@>S!(`\@'0.@#P`
M=1R#QA#^RW7OS1B+%(M,`HON=!J`/`!T]+Z+!JP\`'0+5KL'`+0.S1!>Z_#K
M_K\%`+L`?+@!`E?-$U]S##/`S1-/=>V^HP;KT[["!K_^?8$]5:IUQXOUZ@!\
M``!);G9A;&ED('!A<G1I=&EO;B!T86)L90!%<G)O<B!L;V%D:6YG(&]P97)A
M='-Y<W1E;0!-:7-S`(`!`0`&#__M/P```.%X#P!5J@#K*)!)0DT@(#,N,P`"
M$`$``@`"``#X^``_`!``^C/MN,`'CMC$'AP`B!;]`0K2>0B)'B0`C`8F`([%
MCM6\`'S\'C;%-G@`ORI\N0L`\Z0?Q@8N``^_>`"X*GRKD:O[BA;]`<T3H!``
MF/<F%@`#!@X`Z',`Z'D`NP`%4^B@`%^^<0&Y"P"0\Z9U5X/'%;$+D$PFBT<<
MF8L."P`#P4CW\3T4`'\"L!26H1$`L033Z.@R`/\V)`#$'FT!Z#``Z%L`*_!V
M#>@=`%+W)@L``]A:Z^E;BBX5`/\N;0&^BP'K5)`!!B0`$2XF`,.A&`#V)AH`
MD:$D`(L6)@#W\9*+#A@`]O$JS)'^Q8;IT,[0S@KQAO*'RL._!0"X`0+-$W(#
ML`'#@/P1=/CJOM4!Z!T`OJL!Z!<`,\#-%C;'!G($-!+J``#__[0.NP<`S1"L
M/"1U],,``'``24\@4UE335-$3U,*#4YO;BU3(&1I<VL@;W)E<G)O<B0*#5)E
M<&QA8V4@86YD('-T<FEK>2!K97D@=VAE;B!R96%D>0H-)`H-1&)O;W0@9F%I
M;'5R920@@%6J^/___P``_P`!/!4!=B0,(Q4`@6,0`#$#`('X``$<3@%S)`%%
M)`$\)`$3%@$Q)0DF)`AE"28!&20!%B0.`!0(`(???#.'X```@8```*Z\``"#
MOX0`+`H9@AD+>D!L`0N"85`("S=I!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
M``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`@````04`!X```0``A("`
M``02A("````!!0`'@``!``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
M``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`@````04`!X```0``A("`
M``02A("````!!0`'@``!``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
M``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`@````04`!X```0``A("`
M``02A("````!!0`'@``!``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
M``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`@````04`!X```0``A("`
M``02A("````!!0`'@``!``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
M``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`@````04`!X```0``A("`
M``02A("````!!0`'@``!``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
M``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`@````04`!X```0``A("`
M``02A("````!!0`'@``!``"$@(``!!*$@(````$%``>```$``(2`@``$$H2`
M@````04`!X```0``A("```02A("````!!0`'@``!``"$@(``!!*$@(````$%
M``>```$``(2`@``$$H2`@````04`!X```0``A("```02A("````!!0`'@``!
:``"$@(``!!*#R8````$%`$:N``$``(/)@```
`
end

->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-

3. get/install/compile `xdelta3`, and run `xdelta3 -d -s 512M_CF.null 512M_CF.xdt 512M_CF.img`

then you should able to boot it on 86box(A drive with FreeDOS, and 512M_CF.img [CHS=1006/16/63] as IDE 0:0, press "a" key on XT-IDE boot delay prompt)

> if you have uudecode and xdelta3, you can create one yourself:

Had to install sharutils and xdelta3 on my Debian machine but I think I've got this part now.

> then you should able to boot it on 86box(A drive with FreeDOS, and
> 512M_CF.img [CHS=1006/16/63] as IDE 0:0, press "a" key on XT-IDE boot delay
> prompt)

Trying to boot a known-good 1440 KiB FAT12 diskette image using XTIDE results in the display of "Error 2h!", either with my boot loader (-D_COMPAT_FREEDOS -D_LBA=0 -D_USE_PART_INFO=0) or with FreeDOS's native boot loader. The same error occurs when I first eject the diskette from the drive.



What machine type did you set up? On the "Machine" page I chose "Machine type" 8088, "Machine" Generic XT clone, "CPU type" Intel 8088, "Speed" 16, "Memory" 640 KiB. On the "Storage controllers" page I chose "HD Controller" [ISA] PC/XT XTIDE, "FD Controller" Internal controller. On the "Hard disks" page I have my "IDE (0:0)" with C:H:S 1006:16:63, 495 MiB, "Speed" RAM Disk (max. speed). On the "Floppy & CD-ROM drives" page I selected "Type" 3.5" 1.44M (presumably they mean 90mm 1440 KiB) for the first drive, "Turbo timings" off, "Check BPB" on.

Also, whenever I hard reset the machine it pops up this screen:

Generic Turbo XT Bios 1987

System error #04, Continue?

Pressing any key in response to this seems to continue to boot as expected.

---
l

I uploaded the diskette image I am trying to boot to https://pushbx.org/ecm/test/20240204.2/

---
l

> I uploaded the diskette image I am trying to boot to
> https://pushbx.org/ecm/test/20240204.2/

Oops, loading HimemX on that image is a mistake and won't work. But it doesn't get that far to begin with, so whatever.

---
l

> > if you have uudecode and xdelta3, you can create one yourself:
>
> Had to install sharutils and xdelta3 on my Debian machine but I think I've
> got this part now.
>
> > then you should able to boot it on 86box(A drive with FreeDOS, and
> > 512M_CF.img [CHS=1006/16/63] as IDE 0:0, press "a" key on XT-IDE boot
> delay
> > prompt)
>
> Trying to boot a known-good 1440 KiB FAT12 diskette image using XTIDE
> results in the display of "Error 2h!", either with my boot loader
> (-D_COMPAT_FREEDOS -D_LBA=0 -D_USE_PART_INFO=0) or with
> FreeDOS's native boot loader. The same error occurs when I first eject the
> diskette from the drive.
>
>
>
> What machine type did you set up? On the "Machine" page I chose "Machine
> type" 8088, "Machine" Generic XT clone, "CPU type" Intel 8088, "Speed" 16,
> "Memory" 640 KiB. On the "Storage controllers" page I chose "HD Controller"
> [ISA] PC/XT XTIDE, "FD Controller" Internal controller. On the "Hard disks"
> page I have my "IDE (0:0)" with C:H:S 1006:16:63, 495 MiB, "Speed" RAM Disk
> (max. speed). On the "Floppy & CD-ROM drives" page I selected "Type" 3.5"
> 1.44M (presumably they mean 90mm 1440 KiB) for the first drive, "Turbo
> timings" off, "Check BPB" on.
>
> Also, whenever I hard reset the machine it pops up this screen:
>
> Generic Turbo XT Bios 1987
>
> System error #04, Continue?
>
> Pressing any key in response to this seems to continue to boot as expected.

As you mentioned on the freedos-devel mailing list:

> You don't need a real Book8088 for testing. 86Box "Xi8088" machine with XT-IDE(CHS=1006/16/63) can reproduce this bug.

I switched the "Machine" to Xi8088, "CPU type" NEC V20, "Speed" 16, "FPU" 8087, "Memory" 640 KiB. Now it boots my FreeDOS diskette at least!

---
l

> As you mentioned on the freedos-devel mailing list:
>
> > You don't need a real Book8088 for testing. 86Box "Xi8088" machine with
> XT-IDE(CHS=1006/16/63) can reproduce this bug.
>
> I switched the "Machine" to Xi8088, "CPU type" NEC V20, "Speed" 16, "FPU"
> 8087, "Memory" 640 KiB. Now it boots my FreeDOS diskette at least!

I ran "sys c: /verbose" from my diskette then ran "ldebug /c=g=ffff:0" to restart. Pressing "C" for XTIDE to boot off the hard drive results in the FreeDOS kernel loading, no hang. FreeCOM comes up and asks for the date and time (as there is no autoexec.bat). After those prompts the C:\> shell prompt is displayed.

So I'll probably need to know more about your exact configuration to reproduce the error.

---
l

Maybe related to https://github.com/FDOS/kernel/issues/84 (OW 8086 build fails to boot)

> > if you have uudecode and xdelta3, you can create one yourself:
>
> Had to install sharutils and xdelta3 on my Debian machine but I think I've
> got this part now.
>
> > then you should able to boot it on 86box(A drive with FreeDOS, and
> > 512M_CF.img [CHS=1006/16/63] as IDE 0:0, press "a" key on XT-IDE boot
> delay
> > prompt)
>
> Trying to boot a known-good 1440 KiB FAT12 diskette image using XTIDE
> results in the display of "Error 2h!", either with my boot loader
> (-D_COMPAT_FREEDOS -D_LBA=0 -D_USE_PART_INFO=0) or with
> FreeDOS's native boot loader. The same error occurs when I first eject the
> diskette from the drive.
>
>
>
> What machine type did you set up? On the "Machine" page I chose "Machine
> type" 8088, "Machine" Generic XT clone, "CPU type" Intel 8088, "Speed" 16,
> "Memory" 640 KiB. On the "Storage controllers" page I chose "HD Controller"
> [ISA] PC/XT XTIDE, "FD Controller" Internal controller. On the "Hard disks"
> page I have my "IDE (0:0)" with C:H:S 1006:16:63, 495 MiB, "Speed" RAM Disk
> (max. speed). On the "Floppy & CD-ROM drives" page I selected "Type" 3.5"
> 1.44M (presumably they mean 90mm 1440 KiB) for the first drive, "Turbo
> timings" off, "Check BPB" on.
>
> Also, whenever I hard reset the machine it pops up this screen:
>
> Generic Turbo XT Bios 1987
>
> System error #04, Continue?
>
> Pressing any key in response to this seems to continue to boot as expected.

You may choose machine "Xi8088" as it use (almost) same BIOS as Book8088.

> Maybe related to https://github.com/FDOS/kernel/issues/84 (OW 8086 build
> fails to boot)

I used the gcc compiled kernels that I host at https://pushbx.org/ecm/download/fdkernel.zip or https://pushbx.org/ecm/download/old/fdkernel/ -- Perhaps others can try the kernel.sys file from those on the Book8088?

---
l

> I ran "sys c: /verbose" from my diskette then ran "ldebug /c=g=ffff:0" to
> restart. Pressing "C" for XTIDE to boot off the hard drive results in the
> FreeDOS kernel loading, no hang. FreeCOM comes up and asks for the date and
> time (as there is no autoexec.bat). After those prompts the
> C:\> shell prompt is displayed.
>
> So I'll probably need to know more about your exact configuration to
> reproduce the error.

With https://pushbx.org/ecm/test/20240204.2/updated.img I ran the debugger from drive A: and recorded this layout of the drive C: DPB. Looks fine. Fairly large FAT but it should be fine.

---
l

> > Maybe related to https://github.com/FDOS/kernel/issues/84 (OW 8086 build
> > fails to boot)
>
> I used the gcc compiled kernels that I host at
> https://pushbx.org/ecm/download/fdkernel.zip or
> https://pushbx.org/ecm/download/old/fdkernel/ -- Perhaps others can try the
> kernel.sys file from those on the Book8088?

I compiled it witch Watcom C. It boots in Xi8088 86box if only ecm's floppy is attached. If I attach my drive C image from a few days earlier, the kernel hangs on boot like when running on Book8088.

> Maybe related to https://github.com/FDOS/kernel/issues/84 (OW 8086 build
> fails to boot)

it is not the case, tried github action compiled gcc build in https://github.com/FDOS/kernel/actions/runs/7771227274#artifacts but nothing is changed.

> > I ran "sys c: /verbose" from my diskette then ran "ldebug /c=g=ffff:0"
> to
> > restart. Pressing "C" for XTIDE to boot off the hard drive results in
> the
> > FreeDOS kernel loading, no hang. FreeCOM comes up and asks for the date
> and
> > time (as there is no autoexec.bat). After those prompts the
> > C:\> shell prompt is displayed.
> >
> > So I'll probably need to know more about your exact configuration to
> > reproduce the error.
>
> With https://pushbx.org/ecm/test/20240204.2/updated.img I ran the debugger
> from drive A: and recorded this layout of the drive C: DPB. Looks fine.
> Fairly large FAT but it should be fine.
>
>

tried to boot your updated.img in my 86box but it stalls here:

> XT-class BIOSes don't usually support LBA, so the DOS kernel has to use CHS
> to access the sectors on the disk.
>

XT IDE universal BIOS is not "an usual" XT BIOS. It's a modern implementation of a BIOS extension that enables the use of IDE drives on retro machines that usually didn't support them.

Citing Lo-tech Wiki:
> The Vintage-Computer.com XT-IDE Community Project has developed several
> variations of an 8-bit ISA card that enables standard ATA (IDE) disks (and
> hence SATA or Compact Flash) to be used in an XT-class machine. The boards
> uses LBA addressing, and hence supports drives up to 137GB.

The rest of post is also offpoint. We didn't really usually try a random images. We figured out that the geometry is important early on in the topic.

The biggest problem is that FreeDOS fdisk didn't work on the machine. So it wasn't possible to partition the disk on the machine.

We did try some unusual things like trying to use FreeDOS sys on an MS-DOS partitioned disk because that is one of rare things we could try.

CF cards partitioned under an alternative FreeDOS 1.3 machine didn't work on the Book8088 either.

P.S. I appreciate anyone willing to try to help, but please read the whole topic carefully before replying. Often times what you suggest has been already tried several times.

> I switched the "Machine" to Xi8088, "CPU type" NEC V20, "Speed" 16, "FPU"
> 8087, "Memory" 640 KiB. Now it boots my FreeDOS diskette at least!

That's pretty similar to Book8088. Although it doesn't have 8087. You could order it separatelly but it gets hot easy and draws a lot of battery so almost none is using it.

I also think the clock is smaller. I can't remember the exact values, but I'll retest and let you know.

Although, the turbo is switched off by default.

Unfortunately not testable on a real machine as it doesn't come with a floppy controller. It does come wiht an 8-bit ISA extension board, but I didn't find any cheap and available 8-bit flopy controllers online so we can try something like that.

> tried to boot your updated.img in my 86box but it stalls here:
>

Try booting FAT16 variant also to exclude any bugs with FAT32 kernel. It should also support FAT12/FAT16 but I had some problems while testing recently.

> I used the gcc compiled kernels that I host at
> https://pushbx.org/ecm/download/fdkernel.zip or
> https://pushbx.org/ecm/download/old/fdkernel/ -- Perhaps others can try the
> kernel.sys file from those on the Book8088?

Sure. I'll try it later today.

> It does come wiht an 8-bit ISA extension board, but I didn't
> find any cheap and available 8-bit flopy controllers online so we
> can try something like that.

I currenlty know about these projects:

Deluxe Floppy + Serial 8-bit ISA card = $50
https://monotech.fwscart.com/details/p6083514_19478745.aspx

8-bit ISA Floppy + serial card = ~ $60
https://shop.bluelavasystems.com/products/isa-8bit...-density-floppy-1-44-mb-2-88-mb-boot-rom-serial

Quad Flop - Four port 8-bit ISA floppy controller = $59,9
https://texelec.com/product/quad-flop-four-port-isa-floppy-controller/

Monster Floppy - -||- = $100 (?)
https://www.tindie.com/products/weird/monster-fdc/

> > > Maybe related to https://github.com/FDOS/kernel/issues/84 (OW 8086
> build
> > > fails to boot)
> >
> > I used the gcc compiled kernels that I host at
> > https://pushbx.org/ecm/download/fdkernel.zip or
> > https://pushbx.org/ecm/download/old/fdkernel/ -- Perhaps others can try
> the
> > kernel.sys file from those on the Book8088?
>
> I compiled it witch Watcom C. It boots in Xi8088 86box if only ecm's floppy
> is attached. If I attach my drive C image from a few days earlier, the
> kernel hangs on boot like when running on
> Book8088.

I got a little bit further. GCC and Watcom C kernel hang on my previous image. HOWEVER: if I scatter around some printf in initdisk.c (ProcessDisk()), the Watcom kernel boots fine with the image (have not tested GCC).

So my assumption is that the stack gets corrupted. I am not yet sure where exactly...

Here is the link to the image: https://nextcloud.iww.rwth-aachen.de/index.php/s/rtJRKk6ifYY8kRo

It still contains the EDR kernel, so 86box has to be booted for example with ECMs diskette.img.

This may be the problematic line: https://github.com/FDOS/kernel/blob/431be02b0a1067b89be1867103994dc34540e4c9/kernel/initdisk.c#L657

At least a printf in front of it prints, and a printf after it not. Interestingly, this fails when called the second time.

DriveParam start is printed right at the start of LBA_Get_Drive_Parameters. DriveParam 1 right before the INT13 call linked above. DriveParam 2 right after the INT13 call. This one is missing...

It indeed seems to be a BIOS related bug. INT13,41h fails the second time it is called. One can circumvent this by disabling the kernel LBA support via SYS CONFIG GLOBALENABLELBASUPPORT=0. And in fact the kernel than boots perfectly fine, at least in my case. I uploaded a LBA-disabled kernel to : https://nextcloud.iww.rwth-aachen.de/index.php/s/Sp8df8AiwAoXssg

Bocke can you please test this a last time?

Thanks, Bernd

> The biggest problem is that FreeDOS fdisk didn't work on the machine. So it
> wasn't possible to partition the disk on the machine.

I will prepare a fix for FDISK. Theoretically there is command line parameter /x to disable LBA. Problem is, that the BIOS gets queried for LBA support even if LBA is disabled. And that is a problem if INT13,41h is broken.

I will modify FDISK such LBA that support is not even queried if LBA is disabled via /x parameter.

> It indeed seems to be a BIOS related bug. INT13,41h fails the second time
> it is called. One can circumvent this by disabling the kernel LBA support
> via SYS CONFIG GLOBALENABLELBASUPPORT=0. And in fact the
> kernel than boots perfectly fine, at least in my case. I uploaded a
> LBA-disabled kernel to :
> https://nextcloud.iww.rwth-aachen.de/index.php/s/Sp8df8AiwAoXssg
>
> Bocke can you please test this a last time?
>
> Thanks, Bernd

yeah it works on Xi8088+XT-IDE now, hopefully it will work on real Book8088.


BTW trying to ask for confirmation in VCF:
https://forum.vcfed.org/index.php?threads/xtide-universal-bios.18240/post-1364795

> > The biggest problem is that FreeDOS fdisk didn't work on the machine. So
> it
> > wasn't possible to partition the disk on the machine.
>
> I will prepare a fix for FDISK. Theoretically there is command line
> parameter /x to disable LBA. Problem is, that the BIOS gets
> queried for LBA support even if LBA is disabled. And that is a problem if
> INT13,41h is broken.
>
> I will modify FDISK such LBA that support is not even queried if LBA is
> disabled via /x parameter.

A modified FDISK is uploaded to https://nextcloud.iww.rwth-aachen.de/index.php/s/D4sEZfG7LmHeWqy

This hopefully works on the Book8088 if started with parameter /x. At least this works for me under 86Box with Xi8088 machine and XT-IDE. It previously did not.

Let me make a coffee and I will slowly test it out.

Expect the answer in 30-45 minutes.

Before I try anything, let me first post XTIDE BIOS settings:







Those are programmed in and it seems they can't be changed without reflashing.

But it also seems XT-IDE BIOS has an option of directly flashing to some types of EEPROMS. Does this work on Book8088 I don't know. I tried reflashing the values directly from XT-IDE options but that didn't work.

You can get these settings by running a small utility that comes wiht XT-IDE BIOS called xtidecfg.com.

Uhm.. Images get messed-up during upload. I'll try to upload elsewhere. Give me a sec.

https://i.imgur.com/GnCnytF.jpg
https://i.imgur.com/haJkyx3.jpg
https://i.imgur.com/Zr7qVj3.jpg

> https://i.imgur.com/Zr7qVj3.jpg

this is indeed an interesting find!!!

so it seems that it somewhat supports LBA, but not always (in all options).
therefore LBA enforing kernels may make a difference.

> This may be the problematic line:
> https://github.com/FDOS/kernel/blob/431be02b0a1067b89be1867103994dc34540e4c9/kernel/initdisk.c#L657
>
> At least a printf in front of it prints, and a printf after it not.
> Interestingly, this fails when called the second time.
>
> DriveParam start is printed right at the start of
> LBA_Get_Drive_Parameters. DriveParam 1 right before the INT13
> call linked above. DriveParam 2 right after the INT13 call.
> This one is missing...
>
>

Is it possibly related to the Trace Flag bug? Or Direction Flag being set to DOWN randomly in the interrupt call? Fixed by the PR being merged today: https://github.com/FDOS/kernel/pull/81

Please try with this patch merged but LBA enabled in the kernel CONFIG block.

---
l

> Is it possibly related to the Trace Flag bug? Or Direction Flag being set
> to DOWN randomly in the interrupt call? Fixed by the PR being merged today:
> https://github.com/FDOS/kernel/pull/81
>
> Please try with this patch merged but LBA enabled in the kernel CONFIG
> block.

The kernel I compiled today should already have your changes. But I double-check...

> > This may be the problematic line:
> >
> https://github.com/FDOS/kernel/blob/431be02b0a1067b89be1867103994dc34540e4c9/kernel/initdisk.c#L657
> >
> > At least a printf in front of it prints, and a printf after it not.
> > Interestingly, this fails when called the second time.
> >
> > DriveParam start is printed right at the start of
> > LBA_Get_Drive_Parameters. DriveParam 1 right before the
> INT13
> > call linked above. DriveParam 2 right after the INT13 call.
> > This one is missing...
> >
> >
>
> Is it possibly related to the Trace Flag bug? Or Direction Flag being set
> to DOWN randomly in the interrupt call? Fixed by the PR being merged today:
> https://github.com/FDOS/kernel/pull/81
>
> Please try with this patch merged but LBA enabled in the kernel CONFIG
> block.

Also possible it doesn't like being called with Disabled Interrupts, which would probably make my patch make it fail worse / earlier.

---
l

> Also possible it doesn't like being called with Disabled Interrupts, which
> would probably make my patch make it fail worse / earlier.

Ok I double-checked. The tested kernel has your patch applied. It hangs if I enable LBA.

FDISK hangs too if it tries to use INT13,41h. In this case interrupts should be enabled?!? But would have to look into the Watcom RTL source to be sure...

> > Also possible it doesn't like being called with Disabled Interrupts,
> which
> > would probably make my patch make it fail worse / earlier.
>
> Ok I double-checked. The tested kernel has your patch applied. It hangs if
> I enable LBA.
>
> FDISK hangs too if it tries to use INT13,41h. In this case interrupts
> should be enabled?!? But would have to look into the Watcom RTL source to
> be sure...

Can you grab an image of the used XTIDE into a file and note down the address it enters the XTIDE module when called by int 13h? You can use lDebug like so:

ldebug
k idebios.bin
r bxcx = 10000
w SEGMENT:0

---
l

> > Also possible it doesn't like being called with Disabled Interrupts,
> which
> > would probably make my patch make it fail worse / earlier.
>
> Ok I double-checked. The tested kernel has your patch applied. It hangs if
> I enable LBA.
>
> FDISK hangs too if it tries to use INT13,41h. In this case interrupts
> should be enabled?!? But would have to look into the Watcom RTL source to
> be sure...

I changed the CPU for 86Box from V20 to 8088. Same effect, system hangs...