Debugging 8088 programs

[reenigne]

You're saying ORG needs to be the offset, so if I do a far jump to FF80:0000, then ORG should be 0 right?

Right. (The far jump needs to start at address FFFF:0000 or 16 bytes before the end of the file).

Or did you mean the scenario for when it's being run under DOS debug at 100?

In that case, ORG 100h is the right value (and is probably the default, especially if outputting a .com file).

And if your far jump is to FF70:0100 then "ORG 100h" will be right for both.

 

[Chuck(G)]

One gripe that I've had for microcomputer / microcontroller assemblers is that they don't include features from mainframe assemblers.

For example, anyone who's programmed a Cray using CAL knows the difference between the origin counter and the location counter.

Using a separate location counter, I can assemble code that will be moved later with no issues. (origin != location). Yes, you can do this with assembly functions or explicit arithmetic, but it's not as nice as the feature being built into the assembler--and it's more prone to error.

...and microcontroller assemblers are pretty much a joke in terms of capabilities.

 

[otacon14112]

One gripe that I've had for microcomputer / microcontroller assemblers is that they don't include features from mainframe assemblers.

For example, anyone who's programmed a Cray using CAL knows the difference between the origin counter and the location counter.

Using a separate location counter, I can assemble code that will be moved later with no issues. (origin != location). Yes, you can do this with assembly functions or explicit arithmetic, but it's not as nice as the feature being built into the assembler--and it's more prone to error.

...and microcontroller assemblers are pretty much a joke in terms of capabilities.

That's really cool. I wish I would have had a chance to learn Crays. And the most common thing I've used microcontrollers for (namely Microchip PICs such as the PIC16F690) were for being the middle man between systems and an LCD screen. I didn't find MPASM particularly difficult, but I didn't use a lot of the PIC's features, either.

Right. (The far jump needs to start at address FFFF:0000 or 16 bytes before the end of the file).



In that case, ORG 100h is the right value (and is probably the default, especially if outputting a .com file).

And if your far jump is to FF70:0100 then "ORG 100h" will be right for both.

Haha, that's clever! Thanks

 

[Trixter]

Right, but that isn't the case when the program is run as a boot ROM. So it needs to set up the stack manually for the boot ROM case (unless the CPU's initial values happen to be suitable). I suppose the program could detect whether it's running as a .com or a boot ROM and then have different code paths, but that kind of defeats the point of using this for debugging the boot ROM case (you want the two situations to be as similar as possible).

Fair enough, but it doesn't take much to simply get a block of code working in debug. You can set SS to whatever you want, you can start tracing from any location, etc. There's no reason to jump through tons of hoops in the original code just to debug it.