Why does DOS Box Debugger show this as illegal?

[ben321]

The debugger version of DOS Box says says this for one of my 32bit instructions (and yes I did properly make the jump to 32bit protected mode first).

Code: [Select]

mov  [00120000],al          [illegal]
Why is it illegal to move the content of the AL register to an explicitly defined memory address like 0x00120000?

[Frank Kotler]

Hi Ben,

I ASSume that it is "illegal" because it exceeds the limit on 16 bit addresses (64k).
  To test this, try a smaller number. I know that's not where you want al, but just to test it. You have switched to protected mode, but the DosBox debugger probably doesn't know about this. If this whole "switch to protected mode" exercise is in DosBox, I wouldn't be surprised if it didn't work at all! I thought you were working with real hardware, but I guess those days are gone...

In an earlier post, you say that labels don't work in protected mode. They do (of course!) and you should probably be using them!

Best,
Frank

[ben321]

Hi Ben,

I ASSume that it is "illegal" because it exceeds the limit on 16 bit addresses (64k).
  To test this, try a smaller number. I know that's not where you want al, but just to test it. You have switched to protected mode, but the DosBox debugger probably doesn't know about this. If this whole "switch to protected mode" exercise is in DosBox, I wouldn't be surprised if it didn't work at all! I thought you were working with real hardware, but I guess those days are gone...

In an earlier post, you say that labels don't work in protected mode. They do (of course!) and you should probably be using them!

Best,
Frank

Actually DosBox Debugger does recognize when it has switched to protected mode, because the word "real" first changes to "pr16" when you set CR0 for protected mode, and then to "pr32" when you far jump to the 32bit protected mode segment as defined in the GDT.

The way DosBox Debugger declares it as illegal is quite interesting though, because once the value has been written to that address, it no longer says it's illegal. This may just be a bug in DosBox. By the way, I was intentionally writing to a memory address over 1MB to test the state of the A20 line. If you write to high, then it actually wraps around (or should wrap around) before A20 is enabled.

[alCoPaUL]

get DOSBox-X for Classic Real Mode (MS-DOS, etc) emulation.

DOSBox is kinda "customized", but not that it restricts some stuffs but it allows some stuffs to function/go through.

like DOSBox-X is still a subset of DOSBox based on what i said.

[ben321]

get DOSBox-X for Classic Real Mode (MS-DOS, etc) emulation.

DOSBox is kinda "customized", but not that it restricts some stuffs but it allows some stuffs to function/go through.

like DOSBox-X is still a subset of DOSBox based on what i said.

I need a debugger to see each instruction getting executed and its effect on the system's state (such as switching to real mode) to make sure that my code is working as intended. The debugger version of DosBox has this. DosBox-X doesn't have any debugger version as far as I've heard. So while I can see the output via the screen window (just like in regular DosBox), I can't be sure of the internal state of the system, so bugs may exist in my code that don't present themselves normally, but when I write more code it might impact the execution of that additional code. So it's helpful to see the code as it gets executed in a debugger.

[alCoPaUL]

DOSBox-X behaves exactly like legacy DOS. you can get TASM 5 (winworldpc) and install everything and from that, youll get DOS/W32 GUI debuggers. then if those don't meet your needs, go download SoftICE (an abandonware at the moment).

[ben321]

Can somebody delete this last post I made in this thread. I can't delete my own post here. I meant to start a new thread but accidentally commented in this one.