DOS ain't dead

JEMM386 v5.81 hangs when i run it with MOVEXBDA parameter.

My conventional memory structure is:

0x0000..0x9A80-1 - free memory (618KB)
0x9A80..0x9D80-1 - used by GRUB4DOS (12KB)
0x9D80..0x9F00-1 - XBDA (6KB)
0x9F00..0xA000-1 - some BIOS non used garbage (4KB)

> JEMM386 v5.81 hangs when i run it with MOVEXBDA parameter.
>
> My conventional memory structure is:
>
> 0x0000..0x9A80-1 - free memory (618KB)
> 0x9A80..0x9D80-1 - used by GRUB4DOS (12KB)
> 0x9D80..0x9F00-1 - XBDA (6KB)
> 0x9F00..0xA000-1 - some BIOS non used garbage (4KB)

Read the documentation - this may happen, it's "expected behavior".

---
MS-DOS forever!

> Read the documentation - this may happen, it's "expected behavior".

In my opinion, this is because JEMM386 does not check whether memory size is equal to the XBDA segment:
MemW[$413] shl 6 = MemW[$40E]
If not, he should refrain from moving the XBDA.

> In my opinion, this is because JEMM386 does not check whether memory size
> is equal to the XBDA segment:
> MemW[$413] shl 6 = MemW[$40E]
> If not, he should refrain from moving the XBDA.

In my opinion it is because AHCI expects some alignment of its structures which Jemm cannot easily guarantee, especially if it moves itself into an UMB first.

You may try UMBPCI & UMBM, umbm.exe has got an /xbda option - it's "better" aligned, because umbm doesn't have to "move itself" ( although I've forgotten the details ).

Or perhaps try jemm with option NOHI!

Btw, what is the status of the "dark debugger"? Is that something that you created - or at least are involved with? I find it a very interesting project.

---
MS-DOS forever!

> > In my opinion, this is because JEMM386 does not check whether memory
> size
> > is equal to the XBDA segment:
> > MemW[$413] shl 6 = MemW[$40E]
> > If not, he should refrain from moving the XBDA.
>
> In my opinion it is because AHCI expects some alignment of its structures
> which Jemm cannot easily guarantee, especially if it moves itself into an
> UMB first.
>
> You may try UMBPCI & UMBM, umbm.exe has got an /xbda option - it's "better"
> aligned, because umbm doesn't have to "move itself" ( although I've
> forgotten the details ).
>
> Or perhaps try jemm with option NOHI!
>
> Btw, what is the status of the "dark debugger"? Is that something that you
> created - or at least are involved with? I find it a very interesting
> project.

I added a few lines to the code in INIT.ASM (security is there anything below XBDA) and now it doesn't hang.

if ?MOVEXBDA and ?MOVEXBDAPM
    push ebx
    test bV86Flags,V86F_MOVEXBDA
    jz nomovexbda
    movzx eax,word ptr ds:[@XBDA]   ;does XBDA exist?
    and eax,eax
    jz nomovexbda
  if 1                       
    mov cx,ds:[@MEM_SIZE]
    shl cx,6
    cmp ax,cx
    jnz nomovexbda
  endif
...

I was also able to modify UMBM so that it transfers GRUB4DOS and XBDA data to UMB, thanks to which I have 22KB more conventional memory.

The dark debugger has been completed and so far I have no plans to change anything.

Hello Japheth, hello CandyMan,

> > In my opinion, this is because JEMM386 does not check whether memory
> size
> > is equal to the XBDA segment:
> > MemW[$413] shl 6 = MemW[$40E]
> > If not, he should refrain from moving the XBDA.
> In my opinion it is because AHCI expects some alignment of its structures
> which Jemm cannot easily guarantee, especially if it moves itself into an
> UMB first.

Not checking whether [@MEM_SIZE] shl 6 == [@XBDA] seems like a bad idea, if you ask me.

Also, I see that JEMM16.ASM does have this particular check. So I am mystified as to why INIT.ASM lacks the same check.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I added a few lines to the code in INIT.ASM (security is there anything
> below XBDA) and now it doesn't hang.

Ok, thanks! It's fixed in github.

---
MS-DOS forever!

> Not checking whether [@MEM_SIZE] shl 6 == [@XBDA] seems like a bad idea, if
> you ask me.

I didn't ask, but nevertheless thank you!

Btw., the world is full of bad ideas - it's almost a unique human feature. If I recall correctly, Nietzsche once said: Man cannot be admired enough for his capabilities to survive under the most adverse conditions - but if it comes to his ideas ( = ideology ), he transforms to a complete idiot. ( please forgive my rather "free" translation! )

---
MS-DOS forever!

Hello Japheth,

> I didn't ask, but nevertheless thank you!
> Btw., the world is full of bad ideas - it's almost a unique human feature.

Thanks for the fix!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> The dark debugger has been completed and so far I have no plans to change
> anything.

And please could you add an option (or make other version) to run DD in some "normal" VGA videomode to make it available for a wider audience not only you - for those with "modern" VESA-crippled nVidioted videocards?

---
DOS gives me freedom to unlimited HW access.

> And please could you add an option (or make other version) to run DD in
> some "normal" VGA videomode to make it available for a wider audience not
> only you - for those with "modern" VESA-crippled nVidioted videocards?

Dark Debugger uses 90x50 text mode which is supported by every VGA card.

> Dark Debugger uses 90x50 text mode which is supported by every VGA card.

If I remember some time ago you wrote about some specific high density VESA textmode, was it changed? BTW didn't you mean 80x50 that is VGA std? Unfortunatelly my GTX 670 (and probably newer nvidias) are not compatible enough so I got only black screen :(

---
DOS gives me freedom to unlimited HW access.

> If I remember some time ago you wrote about some specific high density VESA
> textmode, was it changed?

I use high density mode in another debugger (SD32/64 for my home use) for programs launched with dos extender and not in the Dark Debugger. DD always used 90x50 text mode.

Code below also crashes my computer when JEMM386 is loaded:
        mov     ax,0201h
        mov     bx,64K-512
        push    0xF000
        pop     es
        mov     cx,1
        mov     dx,80h
        int     13h
        ret


I tried again and running dd.exe / dd32.exe just got this mess:
http://rayer.g6.cz/1tmp/dd32.jpg

---
DOS gives me freedom to unlimited HW access.

I have the same thing when I try to set a text mode greater than 132 columns (my NVIDIA graphics card thinks this is graphics mode and displays an invalid image similar to your screenshot).

Probably your text mode greater than 80 columns is not supported.

Try this version of DD32 (80/90 columns):
https://megawrzuta.pl/download/29ce9a283a91e264c6ed544ea6d31dd4.html

> Code below also crashes my computer when JEMM386 is loaded:

Well, then don't do that...

---
MS-DOS forever!

Enabling A20 line via port 92h also crash with JEMM386 loaded.
        org     100h
        in      al,92h
        or      al,2
        out     92h,al
        ret

> Enabling A20 line via port 92h also crash with JEMM386 loaded.

The NOA20 option should disable Jemm's port 92h trapping. However, IIRC, since Jemm resides in extended memory it needs A20 to be always on, so I'm not sure that NOA20 makes Jemm really ignore what happens with A20 - perhaps this option only controls what's mapped in at address 100000h-10FFFFh. Might be a good idea to look into the source code ...

Anyway, on the machines that are available for testing I couldn't reproduce your crash.

---
MS-DOS forever!

Thank you. I loaded 80c version and when hit Pause it popped up with readable text mode and seems to work but when I hit Esc or CTRL+C/CTRL+ALT+C I got another mess (a bit less messy) like this: http://rayer.g6.cz/1tmp/dd32-80c.jpg
Looks like the font generator gets filled by FFh...
90c version didn't work (same as before).

---
DOS gives me freedom to unlimited HW access.

> ...
> Looks like the font generator gets filled by FFh...
In the original DeGlucker, the font was swapped when switching the video mode. Now I know it's not the right way.

Please try this version:
https://megawrzuta.pl/download/094b8eac6800202f7b982671405ec0fb.html

Hi, I tried new build but still have some problem when I switch to debugee program or exit I got font blocks like this
https://ibb.co/7WJ9W7f
(should be a file manager running std txt 80x25)

---
DOS gives me freedom to unlimited HW access.

Try this version:
https://megawrzuta.pl/download/eaa5cd2e47100de33d863e1ee7fcd050.html

I tried this but got the same result.

---
DOS gives me freedom to unlimited HW access.

I am not able to correct it myself. I am asking you for help. Could you please take a look at the code I am sharing with you and make your corrections?
Thanks!

https://megawrzuta.pl/download/c118c7db61e2de544c0439303776b36f.html

I'm currently checking an old graphics app in a vga 16-color mode. This app used to work, but on newer cards the output is "scattered" ( or perhaps it's not the "newer cards", but the "newer cpus").

As it has turned out, I had to make this change:


;    mov     al,ah
;    xchg    al,[bx]
    mov al,[bx]
    mov [bx],ah


Using XCHG with memory operands is usually a bad idea, but even more so in the vga "plane" modes. Better do a clean read to fill the "latch" register, then the write. I guess it's also "significantly" faster.

---
MS-DOS forever!