|
Ah, the wonders of low-level assembly programming. I was a teaching assistant for an assembly course this semester at school, and one of the students was running a program in the debugger. (Specifically, Microsoft CodeView running in DOSBox.) F10, F10, F10, until she got to the load instruction that would fill the cx register. Press F10 again, and suddenly, the debugger shows "cx = DEAD." She freaks out a bit, I freak out a lot. We're both worried that something really bad happened, then I realized that DEAD is actually a number in hex. I look through the data segment, and I see a AD DE in there (yay Intel byte reversal!). I check through the code a bit, and even though it looks like the data segment is being initialized properly, it's still reading from the Program Segment Prefix. So, I find the Wikipedia article on the PSP and see that address 05h in the PSP has a cross-segment jump to CP/M compatibility code. But, there's nothing at address DEAD (at least, nothing sensible). So I go searching through the DOSBox code for that string, and I find these lines: // far call to interrupt 0x21 - faked for bill & ted
// lets hope nobody really uses this address
sSave(sPSP,cpm_entry,RealMake(0xDEAD,0xFFFF));
As it turns out, because DOSBox doesn't implement CP/M compatibility, they simply made it jump to DEAD instead, just to make sure that if anyone tried running a CP/M program they would get the picture. And the assembler just happened to put the variable in the right place that the load pulled the DEAD instead of random nonsense.I can only imagine the problems that can manifest when you're dealing directly with hardware, and don't have access to commented source code. |