VOGONS

Common searches


First post, by Peter Swinkels

User metadata
Rank Member
Rank
Member

Looking for a way to quickly test the effect of x86 instructions I tried to use Debug.exe (copied from DOS 6.22), however DOSBox completely freezes when executing any sort of code. Even a program containing nothing but a "RET" instruction crashes. And yes, I'm aware that any screw up on my part will crash the emulated DOS environment. 😀

My question: how do I get Debug to run?

Reply 1 of 12, by llm

User metadata
Rank Newbie
Rank
Newbie

Looking for a way to quickly test the effect of x86 instructions

1. you can use visual studio with x86 inline assembler - works as long as segmented memory access or io ports access is not relevant to you, all 8/16/32bit opcodes still working
2. use Turbo/Borland C/C++ in Dosbox with Inline-Assembler + Debugger

how do I get Debug to run?

there is no need for that - use the dosbox internal debugger (way more easier): builds are available here: DOSBox debugger
and "no" you don't need to build from source yourself if even the antiqued debug.exe seems to fit your needs 😀 - beware the internal dosbox debugger is also started with "debug [EXE]" on
the command line
(the debugger is rarely changed and there is a dosbox-current build available)

btw: did you get any further with your Alley Cat analyse

Reply 2 of 12, by Peter Swinkels

User metadata
Rank Member
Rank
Member
llm wrote on 2020-02-14, 05:14:
1. you can use visual studio with x86 inline assembler - works as long as segmented memory access or io ports access is not rele […]
Show full quote

Looking for a way to quickly test the effect of x86 instructions

1. you can use visual studio with x86 inline assembler - works as long as segmented memory access or io ports access is not relevant to you, all 8/16/32bit opcodes still working
2. use Turbo/Borland C/C++ in Dosbox with Inline-Assembler + Debugger

how do I get Debug to run?

there is no need for that - use the dosbox internal debugger (way more easier): builds are available here: DOSBox debugger
and "no" you don't need to build from source yourself if even the antiqued debug.exe seems to fit your needs 😀 - beware the internal dosbox debugger is also started with "debug [EXE]" on
the command line
(the debugger is rarely changed and there is a dosbox-current build available)

btw: did you get any further with your Alley Cat analyse

Hey, thanks for replying. I got Debug to work by installing a full MS-DOS 6.22 installation onto a harddisk image. I am only interested in realmode 8086 instructions as the games I have been trying to analyze don't need anything more. Does the DOSBox debugger allow you to feed it a few instructions and execute them? Like Debug? The reason I am messing with Debug is because I realized my knowledge of the specifics on some instructions was lacking. Being able to write a short assembly language program and immediately executing it is a very useful way to see what a instruction does. Online documentation can be rather lengthy and abstract... I will get back to your question regarding my progress in another post.

Reply 3 of 12, by llm

User metadata
Rank Newbie
Rank
Newbie

Does the DOSBox debugger allow you to feed it a few instructions and execute them?

no

but as stated you can use a Visual Studio Debugger + simple x86 C/C++ Project for that (if VStudio is around)

int main()
{
__asm {
mov al, 2
mov dx,0xD007
add dx, al
}
return 0;
}

but maybe debug.exe fits already your needs

Reply 4 of 12, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

I use debugx https://sites.google.com/site/pcdosretro/enhdebug (download at bottom of page).

its simple. a - for assemble. t for trace... r ip to reset IP to a set point. d dump, e to hex byte edit codes..

or just use nasm to write simple test files

[bits 16]
[cpu 8086]
[org 0x100]
start:
mov ah,9
mov dx,msg1
int 0x21
mov ah,0x4c
int 0x21
msg: db 'sdfsdfsdf',0x0d,0x0a,'$'

--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--

Reply 5 of 12, by Peter Swinkels

User metadata
Rank Member
Rank
Member

A question: how does the CPU handle far calls in realmode? When e.g. an .exe file contains say "call far abdc:1234" does that mean the program will literally jump to that exact spot or is that what relocation items are for?

btw:
No, I haven't really made any progress with Alley Cat, and yes I am aware of several projects recreating that game.

Reply 6 of 12, by llm

User metadata
Rank Newbie
Rank
Newbie

A question: how does the CPU handle far calls in realmode? When e.g. an .exe file contains say "call far abdc:1234" does that mean the program will literally jump to that exact spot or is that what relocation items are for?

every loading segment related data/code (jumps,call,offset,etc.) are refered by the relocation table and contain only a relative segment information, dos will patch all these places (add offset) of the loading segment of the exe

so the value is different before (in the file) and after load in memory

related to "how" the call is working
https://c9x.me/x86/html/file_module_x86_id_26.html

Reply 7 of 12, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I was able to run DEBUG.EXE from Win98SE DOS (7.10) and Microsoft CodeView 4 all with DOSBox internal DOS. For DEBUG.EXE all I need to do is to fake the DOS version reporting from DOSBox with "ver set 7 10". Microsoft CodeView was my favorite code tracer and debugger for 16-bit code before I got to know about SoftICE for DOS.

Reply 8 of 12, by Peter Swinkels

User metadata
Rank Member
Rank
Member
kjliew wrote on 2020-02-15, 03:45:

I was able to run DEBUG.EXE from Win98SE DOS (7.10) and Microsoft CodeView 4 all with DOSBox internal DOS. For DEBUG.EXE all I need to do is to fake the DOS version reporting from DOSBox with "ver set 7 10". Microsoft CodeView was my favorite code tracer and debugger for 16-bit code before I got to know about SoftICE for DOS.

Did your Debug freeze when trying to execute assembled code you just entered? Even if you were certain it shouldn't freeze the OS? I see I forgot to mention my version of DOSBox, it's 0.74-3.

Reply 9 of 12, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Peter Swinkels wrote on Yesterday, 10:27:

Did your Debug freeze when trying to execute assembled code you just entered? Even if you were certain it shouldn't freeze the OS? I see I forgot to mention my version of DOSBox, it's 0.74-3.

Managed to single-step a number of instructions. Everything seemed normal, no freeze no crash. I compiled DOSBox from SVN r4301 with MSYS2/mingw-w64-x86_64. It is a native WIN64 binary.

Reply 10 of 12, by Peter Swinkels

User metadata
Rank Member
Rank
Member
kjliew wrote on Yesterday, 15:17:
Peter Swinkels wrote on Yesterday, 10:27:

Did your Debug freeze when trying to execute assembled code you just entered? Even if you were certain it shouldn't freeze the OS? I see I forgot to mention my version of DOSBox, it's 0.74-3.

Managed to single-step a number of instructions. Everything seemed normal, no freeze no crash. I compiled DOSBox from SVN r4301 with MSYS2/mingw-w64-x86_64. It is a native WIN64 binary.

Okay, what kind of code did you try? Did you use the "GO" command to execute the code?

Reply 12 of 12, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Some features of DOS debug don't work correctly with DOSBox's emulated DOS; you may need to boot real DOS in DOSBox for those to work correctly.

The "g" command encountering program termination is one thing that doesn't work: you get a crash. However, you can specify a breakpoint so that execution halts, e.g. "g 110" to break at IP=0110. Using a breakpoint works because it avoids termination. Alternatively, you can single-step ("t" and "p" commands) through code, as kjliew mentioned.