DOS ain't dead

> 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

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

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

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

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.

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

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?

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

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

> 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

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

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.

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

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

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

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

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

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.

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

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

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

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

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

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