Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
CandyMan

10.02.2023, 10:04
 

Bug in JEMM (Developers)

Here it is:

    @DbgOutS <"launching Int 19h",10>,?RBTDBG
    mov ds:[bptable.pInt06], offset fastboot_1
    mov eax,19h
    call Exec_Int
fastboot_1:

It should be like this:

    ...
    mov ds:[bptable.pInt19], offset fastboot_1
    ...


FASTBOOT did not work because of this.

Japheth

Homepage

Germany (South),
10.02.2023, 13:10

@ CandyMan

Bug in JEMM

> Here it is:
>
> @DbgOutS <"launching Int 19h",10>,?RBTDBG
> mov ds:[bptable.pInt06], offset fastboot_1
> mov eax,19h
> call Exec_Int
> fastboot_1:
>

> It should be like this:
>
> ...
> mov ds:[bptable.pInt19], offset fastboot_1
> ...

>
> FASTBOOT did not work because of this.

Nice find - and a very good opportunity to test the PL0 debugger variant Deb386. In theory it should work in those circumstances, but so far I only tested the Jemm initialization with it.

---
MS-DOS forever!

Japheth

Homepage

Germany (South),
11.02.2023, 03:37

@ Japheth

Bug in JEMM

> > Here it is:
> >
> >     @DbgOutS <"launching Int 19h",10>,?RBTDBG
> >     mov ds:[bptable.pInt06], offset fastboot_1
> >     mov eax,19h
> >     call Exec_Int
> > fastboot_1:
> >

> > It should be like this:
> >
> >     ...
> >     mov ds:[bptable.pInt19], offset fastboot_1
> >     ...

> >
> > FASTBOOT did not work because of this.

How did you come to your conclusion? Does the modification work for you? At first glance the suggestion sounds plausible, but actually isn't correct - the current code does what it is supposed to do. I checked this with the debugger. Changing the value of bptable.pInt19 instead of bptable.pInt06 results in an exception 06 when Ctrl-Alt-Del is pressed ( see the comment in restorevecs; the _first_ bp has to be modified, and the first bp is bptable.pInt06 ).

---
MS-DOS forever!

CandyMan

15.02.2023, 17:38

@ Japheth

Bug in JEMM

Japheth, what do you think about JEMM storing and restoring the size of XBDA (first byte) when returning to realmode and FASTBOOT?
When I load JEMM, my BIOS uses XBDA to read from disk and clears the first byte of it. This only happens when VDS is enabled because with the NOVDS option this is not the case.

Japheth

Homepage

Germany (South),
16.02.2023, 05:21

@ CandyMan

Bug in JEMM

> Japheth, what do you think about JEMM storing and restoring the size of
> XBDA (first byte) when returning to realmode and FASTBOOT?
> When I load JEMM, my BIOS uses XBDA to read from disk and clears the first
> byte of it. This only happens when VDS is enabled because with the NOVDS
> option this is not the case.

I also have a machine that clears the first byte of the XBDA. Is this a known bug or even documented behavior?

---
MS-DOS forever!

CandyMan

16.02.2023, 12:07

@ Japheth

Bug in JEMM

> I also have a machine that clears the first byte of the XBDA. Is this a
> known bug or even documented behavior?

This seems to be common with newer BIOSes that are not as compatible as they used to be.

CandyMan

23.02.2023, 16:47

@ Japheth

Bug in JEMM

HX dos extender (I think HXLDR32.EXE) does not load programs with PE header below address 0x0040 (some compressed exe files).

Here sample test file to download:
https://megawrzuta.pl/download/16704c1d07e0f88f630585b2e06c0724.html

Japheth

Homepage

Germany (South),
23.02.2023, 17:30

@ CandyMan

Bug in JEMM

> HX dos extender (I think HXLDR32.EXE) does not load programs with PE header
> below address 0x0040 (some compressed exe files).
>
> Here sample test file to download:
> https://megawrzuta.pl/download/16704c1d07e0f88f630585b2e06c0724.html

Yes, I remember some obscure packed binaries that hx's PE loader cannot load. Not worth for further investigation, IMO.

---
MS-DOS forever!

Back to the board
Thread view  Mix view  Order
22049 Postings in 2034 Threads, 396 registered users, 83 users online (0 registered, 83 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum