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

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.

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)

1int main()
2{ 
3    __asm {
4     mov al, 2
5     mov dx,0xD007
6    add dx, al
7  }
8  return 0;
9}

but maybe debug.exe fits already your needs

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,'$'

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.

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

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.

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.

Peter Swinkels wrote on 2020-02-16, 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.

kjliew wrote on 2020-02-16, 15:17:

Peter Swinkels wrote on 2020-02-16, 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?

Make sure the CPU core is set to normal, not dynamic.

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.