You could try putting some NOP instructions at the 32-bit code entry point. Then it'll only skip the NOPs.

01 Oct 2018, 02:47

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland

Tomasz Grysztar

Ben321 wrote:

Problem is sometimes debuggers (at least with DOS Box's debugger version) have trouble following the code jump from 16bit real mode to 32bit protected mode, and end up landing on the wrong opcode (allowing several opcodes to get executed without debugging, so I can't execute anything step by step and until the debugger finally recognizes where it should be and starts the debugging process again several opcodes past the landing spot for the jump to 32bit protected mode). I did at one point use DOS Box Debugger for my debugger, and had a test program that jumped to 32bit mode from 16bit real mode, and DOS Box Debugger was terrible, so I figured that this was fairly representative of most debuggers in DOS (they just tend to have trouble with the jump to 32bit protected mode, it's part of their nature). So I have basically given up on DOS programming in assembly.

To debug a transition between real and protected mode you need either a hardware-based debugger or a good emulator. I do not recommend DOSBox for such purpose, though - it is an emulator focused on running games, not on a faithful representation of CPU operation. For example it is not able to emulate 32-bit unreal mode that some versions of fasm were using.

Ben321 wrote:

Also is "FASM for DOS" a version of FASM that runs in DOS, or a version of FASM that runs in Windows and then compiles for DOS (which then allows you to put your compiled program into a disk image via WinImage, and then load that disk image into something like VirtualBox to use it)?

It is version of fasm that runs for DOS. A version that "runs in Windows and compiles for DOS" is just a regular Win32 version of fasm. The versions are provided so that you can assemble on different systems, but the result of the assembly is always going to be the same - if you have a source of a 16-bit DOS .EXE, such program is going to be assembled no matter what variant of fasm you use.

01 Oct 2018, 07:45

Ben321

Joined: 07 Dec 2017
Posts: 61

Ben321

Tomasz Grysztar wrote:

Ben321 wrote:

Problem is sometimes debuggers (at least with DOS Box's debugger version) have trouble following the code jump from 16bit real mode to 32bit protected mode, and end up landing on the wrong opcode (allowing several opcodes to get executed without debugging, so I can't execute anything step by step and until the debugger finally recognizes where it should be and starts the debugging process again several opcodes past the landing spot for the jump to 32bit protected mode). I did at one point use DOS Box Debugger for my debugger, and had a test program that jumped to 32bit mode from 16bit real mode, and DOS Box Debugger was terrible, so I figured that this was fairly representative of most debuggers in DOS (they just tend to have trouble with the jump to 32bit protected mode, it's part of their nature). So I have basically given up on DOS programming in assembly.

To debug a transition between real and protected mode you need either a hardware-based debugger or a good emulator

For my emulator, I'm using VirtualBox with DOS 6.22 installed.

Is there any good debugger for this? One that correctly tracks wherever the CPU's code pointer points? So regardless of which mode it's in, it always keeps the code pointer at the right place, even through a transition between modes?

01 Oct 2018, 22:52

sinsi

Joined: 10 Aug 2007
Posts: 693
Location: Adelaide

sinsi

Bochs has a debug version.

02 Oct 2018, 00:46

Ben321

Joined: 07 Dec 2017
Posts: 61

Ben321

sinsi wrote:

Bochs has a debug version.

Unfortunately it looks like it's not a default feature. It looks like you need to compile yourself with certain compile options to enable it. I'm not about to set up an entire development environment just to enable one feature. If somebody can point me to a download link where they have posted their own compiled copy with debug mode enabled though, I'd be fine with that.

Is there any good debugger for this? One that correctly tracks wherever the CPU's code pointer points? So regardless of which mode it's in, it always keeps the code pointer at the right place, even through a transition between modes?

DOS has tons of debuggers, but I don't know which will suit your purpose (esp. if you're trying to run graphically using VGA atop Win9x).

There were several debuggers mentioned here in another thread (keep scrolling down for my post).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum