DOS ain't dead

Well, I tired multiple versions of 16-bit FreeDOS kernels on Book8088 2.0, but they all get stuck at InitDisk function. It seems that InitDisk has problem with CF2IDE and detects the wrong disk parameters.

It came preinstalled with MS-DOS 6.22 and that works ok. I just wanted to put something lighter like a slimmer version of FreeDOS 1.3 or SvarDOS.

Also, if someone knows: where should I report the bug so FreeDOS kernel people see it?

> @ecm
> Attaching images doesn't work for me on GitHub so I'm sending you the image
> here:
>

Received, I will reply on github soon.

---
l

@ecm
Attaching images doesn't work for me on GitHub so I'm sending you the image here:

> > > as listed in
> > > https://github.com/skiselev/8088_bios/blob/master/src/floppy1.inc and
> > > https://github.com/skiselev/8088_bios/blob/master/src/floppy2.inc ,
> > Xi8088
> > > BIOS handles floppy part of int 13h only.
> >
> > That is not the problem. The problem is that the BIOS in version 0.9.4
> > fails to set DS to its data segment if it encounteres an an unsupported
> > function
> >
> https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L89
> >
> >
> https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L94
> >
> > But it writes to it at
> >
> https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L128
> >
> > In later versions that seems to be handled differently, an the current
> > binary for Xi8088 seems to work under 86box.
>
> This specific bug seems to be fixed in BIOS version 0.9.9 by commit
> https://github.com/skiselev/8088_bios/commit/8799088bce5ca1c088631ba065f98794054dbf9a

yeah, with 0.9.9 or newer xi8088 BIOS, it seems to boot fine even if LBA support is not disabled.

> Now CH375 driver doesn't work. I even tried several version. Book gets
> stucked after loading the driver wether it found the drive or not.
>
> I'll try to see if this also happens with 8086 kernel. If it does, I'll try
> an older kernel.

I identified the commit that broke the driver:
https://github.com/FDOS/kernel/issues/130

But I don't really know what's happening here, so I'm not of any help with solving this. :)

>
> It actually works on 2042 (8086 with FAT32) from Sourceforge. With LBA
> support turned off of course.

This 2043 release from 2021 works too:
https://github.com/FDOS/kernel/releases/tag/ke2043

> > Now CH375 driver doesn't work. I even tried several version. Book gets
> > stucked after loading the driver wether it found the drive or not.
> >
> > I'll try to see if this also happens with 8086 kernel. If it does, I'll
> try
> > an older kernel.
>
> Doesn't work with 8086 kernel either.
>
> I don't remember it ever working on FreeDOS, but it worked on EDR-DOS
> kernel (with FAT32) and MS-DOS kernel (whithout FAT32).

It actually works on 2042 (8086 with FAT32) from Sourceforge. With LBA support turned off of course.

> Now CH375 driver doesn't work. I even tried several version. Book gets
> stucked after loading the driver wether it found the drive or not.
>
> I'll try to see if this also happens with 8086 kernel. If it does, I'll try
> an older kernel.

Doesn't work with 8086 kernel either.

I don't remember it ever working on FreeDOS, but it worked on EDR-DOS kernel (with FAT32) and MS-DOS kernel (whithout FAT32).

Now CH375 driver doesn't work. I even tried several version. Book gets stucked after loading the driver wether it found the drive or not.

I'll try to see if this also happens with 8086 kernel. If it does, I'll try an older kernel.

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

Fixed in the most recent version of the kernel. Now it boots without problems.

> I did some more testing and noticed some weird behavior. My Dell 316SX
> won't boot the drives w/it's native BIOS.

Where exactly does this hang? The 386 BIOS does not support LBA. If it hangs before the FreeDOS Kernel messages, the boot loader may be the cause. I saw that the XT-IDE for the Dell machine also does not support LBA.

> > I had some problems with CF Cards so I just managed to try it a 5
> minutes
> > ago.
> >
> > And it works!
>
>
> Glad you got it to work.
>
>
> I did some more testing and noticed some weird behavior. My Dell 316SX
> won't boot the drives w/it's native BIOS. XT-IDE r624 in my NIC's ROM
> socket is required for some reason. Instead I booted a floppy (MS DOS 7.1)
> to run some tests.
>
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0183.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0184.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0186.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0187.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0189.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0190.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0191.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0192.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0193.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0194.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0196.jpg&x=756&y=491&a=true
> https://nextcloud.iww.rwth-aachen.de/index.php/app...2k/zIMG_0197.jpg&x=756&y=491&a=true

you're not only "lost" a sector, but a cylinder.
and both XTIDE BIOS and system BIOS can cause such problem.
but why/when will this happen is not known right now.

> > I had some problems with CF Cards so I just managed to try it a 5
> minutes
> > ago.
> >
> > And it works!
>
>
> Glad you got it to work.
>
>
> I did some more testing and noticed some weird behavior. My Dell 316SX
> won't boot the drives w/it's native BIOS. XT-IDE r624 in my NIC's ROM
> socket is required for some reason. Instead I booted a floppy (MS DOS 7.1)
> to run some tests.
>

Some BIOSes report the disk sizes a few cylinders (mostly one) smaller than the disk actually is to store "hidden" information or simply for compatibility reasons and when calling INT 13 CHS functions. This is "by design" and not an error per se.

Free FDISK may be told to actively test for such hidden sectors via altering its INI file or via environment variable set FFD_CHECKEXTRA=ON. But it is disabled by default.

To make sure no problems arise I recommend FDISKing the disk with the combination yielding the smaller cylinder count, if you plan to transfer the CF from system to system.

> I had some problems with CF Cards so I just managed to try it a 5 minutes
> ago.
>
> And it works!


Glad you got it to work.


I did some more testing and noticed some weird behavior. My Dell 316SX won't boot the drives w/it's native BIOS. XT-IDE r624 in my NIC's ROM socket is required for some reason. Instead I booted a floppy (MS DOS 7.1) to run some tests.

> > as listed in
> > https://github.com/skiselev/8088_bios/blob/master/src/floppy1.inc and
> > https://github.com/skiselev/8088_bios/blob/master/src/floppy2.inc ,
> Xi8088
> > BIOS handles floppy part of int 13h only.
>
> That is not the problem. The problem is that the BIOS in version 0.9.4
> fails to set DS to its data segment if it encounteres an an unsupported
> function
> https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L89
>
> https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L94
>
> But it writes to it at
> https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L128
>
> In later versions that seems to be handled differently, an the current
> binary for Xi8088 seems to work under 86box.

This specific bug seems to be fixed in BIOS version 0.9.9 by commit https://github.com/skiselev/8088_bios/commit/8799088bce5ca1c088631ba065f98794054dbf9a

> as listed in
> https://github.com/skiselev/8088_bios/blob/master/src/floppy1.inc and
> https://github.com/skiselev/8088_bios/blob/master/src/floppy2.inc , Xi8088
> BIOS handles floppy part of int 13h only.

That is not the problem. The problem is that the BIOS in version 0.9.4 fails to set DS to its data segment if it encounteres an an unsupported function
https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L89
https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L94

But it writes to it at https://github.com/skiselev/8088_bios/blob/6da84ae09804002ae29080cd64dc85e58f46ae9f/floppy2.inc#L128

In later versions that seems to be handled differently, an the current binary for Xi8088 seems to work under 86box.

> > The following part of the Xi8088 BIOS (not XT-IDE) overwrites the INT10
> > handler address. May be the root of the cause. DS being zero is a side
> > effect of the intr() call FDISK performs, and by itself should not do
> any
> > harm. It is restored before intr() returns.
> >
> >
>
> Seems that Eric was on the right path, and XT-IDE hands off the INT13 call
> to the Xi8088 BIOS. This in turn seems to mess things up.

as listed in https://github.com/skiselev/8088_bios/blob/master/src/floppy1.inc and https://github.com/skiselev/8088_bios/blob/master/src/floppy2.inc , Xi8088 BIOS handles floppy part of int 13h only.

there is another bug report in https://github.com/skiselev/8088_bios/issues/46

> The following part of the Xi8088 BIOS (not XT-IDE) overwrites the INT10
> handler address. May be the root of the cause. DS being zero is a side
> effect of the intr() call FDISK performs, and by itself should not do any
> harm. It is restored before intr() returns.
>
>

Seems that Eric was on the right path, and XT-IDE hands off the INT13 call to the Xi8088 BIOS. This in turn seems to mess things up.

The following part of the Xi8088 BIOS (not XT-IDE) overwrites the INT10 handler address. May be the root of the cause. DS being zero is a side effect of the intr() call FDISK performs, and by itself should not do any harm. It is restored before intr() returns.

> > For completeness: FDISK also hangs in LBA mode when running under the
> EDR
> > kernel.
> >
> > I will try to debug the INT 13 call FDISK does with ldebug, by setting a
> > breakpoint to C800:145B.
>
> I set up a conditional break point under lDebug with
> bp new c800:145b when=ah==41
>
> Sadly it can not set the breakpoint into the ROM because, well, its
> read-only. I can set the breakpoint to the EDR INT13 stub, but is there
> perhaps another way around this?

No, using the stub is the way to go. If there is no stub (eg debugging before DOS installs its handler, or if a DOS does not have such a stub at all) then you can create a small handler like this:

a 0:5E0
 jmp (ri13s):(ri13o)
 .
r v0 = ri13p ; preserve if to reset
r dword [0:13 * 4] = 5E0
bp new ptr ri13p when AH == 41

---
l

> For completeness: FDISK also hangs in LBA mode when running under the EDR
> kernel.
>
> I will try to debug the INT 13 call FDISK does with ldebug, by setting a
> breakpoint to C800:145B.

If it is ROM you will not be able to set a breakpoint. However, you can set a breakpoint in a RAM handler such as the DOS's int 13h handler then step into the ROM.

FD Debug and lDebug do allow to trace ROMs somewhat but you can't use int3 style breakpoints in a ROM. If you trace an interrupt instruction with Trace Mode zero (do not trace into the handler) then rather than write a breakpoint, the debugger will set the Trace Flag as for an ordinary instruction then run the int. This will usually cause a Trace Interrupt one instruction too late, as the iret of the handler will act like an iret done by the debugger. This bit is done here: https://hg.pushbx.org/ecm/ldebug/file/156a4890666e/source/run.asm#l3911

lDebug does allow to trace repeatedly into the silent buffer until a user-specified condition is true, though. This can be used as a poor woman's replacement for commands like GT, GNT, or P (on a loop/call) that would require a breakpoint. Just TP cccccc WHILE csip != F000_1234+3 SILENT 1 will do for a very simple example. More complicated things are possible, eg the PR (Proceed Until Return) command replacement I described in https://pushbx.org/ecm/dokuwiki/blog/pushbx/2023/0...g_and_access_variables_recent_changes_to_ldebug

---
l

> > A modified FDISK is uploaded to
> > https://nextcloud.iww.rwth-aachen.de/index.php/s/D4sEZfG7LmHeWqy
> >
>
> It actually starts, but it takes 6-10 seconds to start.

It is UPX compressed. May be the decompression that takes this time.

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

It actually starts, but it takes 6-10 seconds to start.

> For completeness: FDISK also hangs in LBA mode when running under the EDR
> kernel.
>
> I will try to debug the INT 13 call FDISK does with ldebug, by setting a
> breakpoint to C800:145B.

I set up a conditional break point under lDebug with
bp new c800:145b when=ah==41

Sadly it can not set the breakpoint into the ROM because, well, its read-only. I can set the breakpoint to the EDR INT13 stub, but is there perhaps another way around this?

> 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

I had some problems with CF Cards so I just managed to try it a 5 minutes ago.

And it works!

For completeness: FDISK also hangs in LBA mode when running under the EDR kernel.

I will try to debug the INT 13 call FDISK does with ldebug, by setting a breakpoint to C800:145B.

> 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

I uploaded it to:
https://nextcloud.iww.rwth-aachen.de/index.php/s/8cCX7KFY73MP6oz

IDE-XT ROM is located at frame C800. INT 13 vector points to EDR-DOS code at 0070:01C0. A pushf / far call combo is performed into the XT-IDE to C800:145B. The dump file starts at C800:0000 and is 64k.

Given that it has been mentioned that the Book8088 XT-IDE BIOS is involved in a crash triggered by the FreeDOS kernel and/or FDISK when they attempt to ask int 13.41 more than once whether EBIOS LBA support exists, which means that you can probably use SYS CONFIG to disable LBA checks and attempts in the FreeDOS kernel as a workaround until something in one of the BIOS handlers gets fixed:

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

I have been digging around in the XT BIOS sources a bit. They basically assume that V20 supports all 186 opcodes such as pusha, popa, immediate push, immediate shifts etc. but no 386 opcodes such as movzx.

One odd detail here:

https://www.xtideuniversalbios.org/browser/xtideun...IDE_Universal_BIOS/Src/Handlers/Int13h.asm#L122

You do not have to use a convoluted macro for an immediate shift by ONE bit because all CPU support that. In addition, the macro has the strange property that it depends on CHECK_FOR_UNUSED_ENTRYPOINTS, why that?

https://www.xtideuniversalbios.org/browser/xtideun...ios/trunk/Assembly_Library/Inc/Emulate.inc#L660

However, if that were broken, nothing would work, so that is NOT why int 13.41 causes instability if MODULE_EBIOS for LBA support is not compiled in.

I do not know whether the XT-IDE in question is compiled with local stack in BDA. Probably not, because that would be 286+ according to code comments.

So you basically get an optional CLD, lots of registers and some local stack frame get pushed and allocated, a BIOS DS and DPT pointer get loaded (NUL for unknown DL), bx=2*ah, ah gets compared to 25 and either a jump table is processed or you go to unsupported function, which uses a stack trampoline to call whatever the int13 handler outside XT-IDE was. Then most registers are copied to the stack of XT-IDE, DS is set, IF and CF are processed on stack, the local frame is released, lots of registers get restored from stack and you end with an IRET. Seems all sane at first glance. There also are checks for DL, only 13.08 is always hooked, the rest depends on whether the disk is XT-IDE handled.

Makes me wonder what the original BIOS int13 handler WITHOUT XT-IDE will do for int13.41 LBA EBIOS support check calls?

---
FreeDOS / DOSEMU2 / ...

> > yeah it works on Xi8088+XT-IDE now, hopefully it will work on real
> > Book8088.
> >
> >
>
> Do you have two hard disks connected here? Unlike my earlier tests this
> says "master" and "slave" are both detected as existing.

Ach, it shows a drive D: in the same screenshot. So you do.

---
l

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

Do you have two hard disks connected here? Unlike my earlier tests this says "master" and "slave" are both detected as existing.

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

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

> > 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

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

---
l

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

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

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

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.

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

Expect the answer in 30-45 minutes.

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

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

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

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

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

> 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/

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

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