We can immediately conclude that JM is backwards. A zero will become '7' and a '1' will become '8'. But if the test is wrong, 7 will be added to the decimal digits. In fact, the program fails so quickly I would doubt it has even reached 0x1FF. That is way beyond the end of the program so it can't possibly correspond to a CALL CPUER. So one has to wonder if maybe the test failed and we didn't add the 7. 10 + 7 + 0x30 = 65 which is the letter 'A' so that part is handling digits 'A' through 'F'. But if it is greater than or equal to 10 then we add 7 and then add 0x30. If it is less 10 then 0x30 is added to A register. Note that the code looks at the value in A register. However, looking at the 78=: we can come up with a pretty good guess what went wrong. Which is the BYTEO routine and in particular BYT02 which converts the bottom 4 bits of A register into an ASCII character. In other words, it would seem your 8080 emulator is failing on the code to convert a binary value to hexadecimal in ASCII. Though instead of a hexadecimal address your emulator printed 78=. Looking at CPUER you can see that it is printing the return address after the CPU HAS FAILED! ERROR EXIT= message. Or even just detect CALL CPUER as a special case.īut cpudiag.asm tries to help you as much as possible. That routine is at 0圆89 so you could stop your emulator when it reaches there and note the return address indicates which of the many CALL CPUER instructions was hit. Notice that it will run an 8080 instruction or two and if it doesn't get the results it expects a CALL CPUER is done. cpudiag.asm is designed to point out the general location of the error. I'll tell you what that is at the end of the question to not spoil your examination. Look very closely and you'll find that JM did something wrong. Here's the first two instructions you posted (slightly abridged): Instructions Ran: 79 In those cases a full trace showing all register contents and values being read from or written to memory can catch the mistake quicker. Sometimes a mistake can be made, the results saved into memory and only when read back much later is the difference in program counter apparent. When they differ your know your emulator made a mistake and it will likely be at the instruction or a few before it. Have the correct emulator and yours output the program counter for each instruction executed. If the error occurs after thousands or millions of instructions then it would be more fruitful to compare it against an 8080 emulator that gets the correct output. I'm new to emulating so could anyone give me a hint or point me in the right direction on how to debug this?įor a failure that happens so quickly (at most 89 instructions) I'd recommend simply looking at what your emulator does at each instruction and determine if did everything correctly. Here are the last 10 instructions run by the emulator before failing: Instructions Ran: 79 I get the error: CPU HAS FAILED! ERROR EXIT=78=:Īnd added myself that there was a JMP to 0000 from 0圆98. I've already implemented the CP/M CALL function at 0x05, offset the program at 0x100 and fixed the offset at byte 112 + 0x100, as per this site: I'm using cpudiag.bin from to test my emulator.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |