DOS ain't dead

CandyMan 15.10.2018, 22:07	Dark Debugger (Announce) Post reply
	Dark Debugger - protected V86 mode debugger for Dos based on deglucker with build in assembler (FASM) It is possible to download program from (search DD.7Z file): https://drive.google.com/drive/folders/0B_wEiYjzVkC0ZGtkbENENzF1Nms

RayeR

CZ,
16.10.2018, 06:12

@ CandyMan

Dark Debugger

Post reply

> Dark Debugger - protected V86 mode debugger for Dos based on deglucker with
> build in assembler (FASM)

On my PC (core i7-2600k) it just reboots - no error message. Even in safe mode (no drivers/TSR). When I run it under JEMMEX it says it's already in pmode.

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

CandyMan

16.10.2018, 09:30
(edited by CandyMan, 16.10.2018, 10:15)

@ RayeR

Dark Debugger

Post reply

> On my PC (core i7-2600k) it just reboots - no error message. Even in safe
> mode (no drivers/TSR). When I run it under JEMMEX it says it's already in
> pmode.
I cannot find the bug because at me and on the emulator is working. Whether you used XMS driver? Did you run DD without XMS?
Download deglucker, check whether he is working and write.
http://vagsoft.chat.ru/files/dg0_04.zip
http://vagsoft.chat.ru/files/dg5_9may.zip

RayeR

CZ,
18.10.2018, 03:54

@ CandyMan

Dark Debugger

Post reply

I have found that DD doesn't like XHDD.SYS driver (previously UIDE) - cause reboot. When I skipped loading it the DD starts and seems to be working...

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

Japheth

Germany (South),
16.10.2018, 10:48

@ RayeR

Dark Debugger

Post reply

> On my PC (core i7-2600k) it just reboots - no error message. Even in safe
> mode (no drivers/TSR). When I run it under JEMMEX it says it's already in
> pmode.

On my PC it runs. However, the system "tends" to reboot rather easily afterwards, so one can hardly call it stable.

Also, the debugger puts the system in v86 mode, thus preventing any protected-mode software from starting. And there's virtually no documentation, except for a help screen when pressing F1.

---
MS-DOS forever!

CandyMan 17.10.2018, 18:16 @ Japheth	Dark Debugger Post reply
	Dark Debugger is a perfect debugger in order to unpack protected executable files. Inside the archive is an instruction how to do it.

Japheth

Germany (South),
18.10.2018, 11:16

@ CandyMan

Dark Debugger

Post reply

> Dark Debugger is a perfect debugger in order to unpack protected executable
> files. Inside the archive is an instruction how to do it.

The only file in the archive DD.7Z was DD.EXE - no text files.

---
MS-DOS forever!

CandyMan 18.10.2018, 17:02 @ Japheth	Dark Debugger Post reply
	> The only file in the archive DD.7Z was DD.EXE - no text files. Yesterday I uploaded new archive.

Japheth

Germany (South),
18.10.2018, 19:17

@ CandyMan

Dark Debugger

Post reply

> > The only file in the archive DD.7Z was DD.EXE - no text files.
> Yesterday I uploaded new archive.

Ok, got it.

I noticed 2 problems:

1. when uninstalling ( alt-x ), the debugger will become deactivated, but not all of its DOS memory is released.

2. if DOS is loaded high ( MS-DOS 7.1 ), after launching the debugger the system becomes unstable ( reboots when more than one program is started ). My guess is the debugger does something silly with the A20 gate.

---
MS-DOS forever!

CandyMan

22.10.2018, 18:26

@ Japheth

Dark Debugger

Post reply

> If DOS is loaded high ( MS-DOS 7.1 ), after launching the debugger the
> system becomes unstable ( reboots when more than one program is started ).
> My guess is the debugger does something silly with the A20 gate.
I uploaded new version. I added also an option of freeing previously allocated of memory.
An only bug I found which is using the 16-bit LGDT/LIDT instruction (the computer could reboot when the debugger was loaded above 16MB).

Japheth

Germany (South),
23.10.2018, 15:59

@ CandyMan

Dark Debugger

Post reply

> I uploaded new version. I added also an option of freeing previously
> allocated of memory.

Thanks.

The "reboot" problem is indeed related to the A20-gate. As you probably know ( or not ), a V86-monitor should ensure that the A20 gate never becomes disabled. Jemm does manage this by directly trapping accesses to ports 92h and 6xh. However, now that the cause of the problem is known, it is pretty minor, because I can always ensure that your debugger is loaded at an extended address where A20 IS zero.

---
MS-DOS forever!

CandyMan 23.10.2018, 19:37 @ Japheth	Dark Debugger Post reply
	In newer computers so as my there is already no A20 gate, is as if all the time was enabled.

Dark Debugger (Announce)

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger

Dark Debugger