DME/KLR data logging

[johnb]

Never trust AI as a source of reference info, especially for obscure stuff like this. If we go through the instruction set pdf and capture all the details in text form, we could probably use it as a prompt and get really good results - like "here's the instruction set reference, now tell me what this piece of code does". It's very good at stuff like that.

[whalenlg]

Exactly - that's why I have the Assembly dump in 1 window, MCS-48 Manual in the 2nd window and then Gemini in the 3rd window.....
It's actually been pretty helpful in creating a Verilog cycle accurate hardware model of the 8048 so far.

[whalenlg]

@johnb , @andyb

Really great work on this topic from both of you!

I'm working on a debugger for this code and found a few things that stump me:
What look like functions (because the immediate opcode before them is a "ret", but I can't find any path to call these):
Address:
2FE
6FE
9FE
AFE
DFE
3FA
FB0
Others:
CA1 - strange target address
FF5 $0F32 doesn't exist

Let me know what you think about what I am seeing.

[johnb]

@johnb , @andyb

Really great work on this topic from both of you!

I'm working on a debugger for this code and found a few things that stump me:
What look like functions (because the immediate opcode before them is a "ret", but I can't find any path to call these):
Address:
2FE
6FE
9FE
AFE
DFE
3FA
FB0
Others:
CA1 - strange target address
FF5 $0F32 doesn't exist

Let me know what you think about what I am seeing.

Ah yes, memory banks! For the last 3 in your list, this should explain it: https://jhnbyrn.github.io/951-KLR-PAGES ... _code.html

The short version is, you have to subtract 0x800 from the actual address to find the value that's used to call it.

As for the others, where there's a long list of nops with a ret or something at the end, I'm not sure (it might be the same explanation but I haven't checked).

[whalenlg]

Ah yes, memory banks! For the last 3 in your list, this should explain it: https://jhnbyrn.github.io/951-KLR-PAGES ... _code.html

The short version is, you have to subtract 0x800 from the actual address to find the value that's used to call it.

As for the others, where there's a long list of nops with a ret or something at the end, I'm not sure (it might be the same explanation but I haven't checked).

Thanks - I did look that through and was able to resolve 15-20 others that way (along with some very good comments!).

(1) 2FE, 6FE, 9FE, AFE, DFE. - these look like odd stubs just before the start of a new routine:
Pretty much:
0x2b5 ret
// BIG GAP
0x2fe movp a,@a (opcode A3)
0x2ff ret. (opcode 83)

Not sure what to do with these.

3FA
0x39d ret
// END diagnostic function
// BIG GAP
0x3fa anl a,#$60
There is no call to 03FA or 0BFA anywhere I could find (not even in the jmpp @a code related to the ADC routines)

FB0 - I think there's an error in the disassembly code listing
0xfa8 ret
// end count cycles
// call exp. smoothing and rotate 16-bit values
0xfa9 call $0608. -- This is Opcode D4 which should call into the page at E00-E08 so it really should read E08 (which is valid)
0xfab call $07B0 -- This is Opcode F4 which should call into the page at F00-FFF, so it should read 0FB0 which is valid
0xfad call $07B0 - same as above
0xfaf ret
0xfb0 xch a,r6

CA1 - refers to address 03FC, but based on the opcode of 74, the range should be B00-BFF, but there is no code alignment at 0BFC
Same for FBO - jp target of 0F32 doesn't exist

[whalenlg]

Hi @johnb , @andyb ,

Besides those questions - trying to build a full memory map from your comments, pages. See .pdf on where I am at.

Any other clues to the other memory locations?

Thanks!

87KLR951.xlsx.pdf

(37.06 KiB) Downloaded 32 times

[andyb]

(1) 2FE, 6FE, 9FE, AFE, DFE. - these look like odd stubs just before the start of a new routine:
Pretty much:
0x2b5 ret
// BIG GAP
0x2fe movp a,@a (opcode A3)
0x2ff ret. (opcode 83)

Not sure what to do with these.

My guess is that they are a scheme to trigger a breakpoint in the debugger the original developers used. The idea being that if the program counter gets there, something bad must have happened. The (0xa3, 0x83) opcode sequence isn't used anywhere in functional code. I reckon they had an instruction set simulator running on a mini computer and configured it to stop the simulation if it saw that sequence. I'm probably wrong though.

I've run out of time to think about the rest of your post. I'll be back later.

[andyb]

FB0 - I think there's an error in the disassembly code listing
0xfa8 ret
// end count cycles
// call exp. smoothing and rotate 16-bit values
0xfa9 call $0608. -- This is Opcode D4 which should call into the page at E00-E08 so it really should read E08 (which is valid)
0xfab call $07B0 -- This is Opcode F4 which should call into the page at F00-FFF, so it should read 0FB0 which is valid
0xfad call $07B0 - same as above
0xfaf ret
0xfb0 xch a,r6

Yes, I agree that these call instructions call the addresses you give, but I think the disassembly is correct. The top bit of the target address comes from the currently selected memory bank (as John's notes describe).

I verified in my simulator that memory bank 1 is selected when these instructions execute.

[andyb]

CA1 - refers to address 03FC, but based on the opcode of 74, the range should be B00-BFF, but there is no code alignment at 0BFC

Again, I agree that BFC is the target of the call at location CA1. But I think the code at BFC is perfectly valid. It is conditional jump, that when my simulator gets here, the jump is taken, which leads to a "jmp $04FE" which actually jumps to BFE, which does the funny looking "mov p a,@a; ret" pattern you mentioned. But the result is that we end up returning from the call having done approximately nothing.

It's not clear why the code was written this way, but I guess it made sense during development for some reason.

[andyb]

Besides those questions - trying to build a full memory map from your comments, pages. See .pdf on where I am at.

Any other clues to the other memory locations?

Thanks!87KLR951.xlsx.pdf

I don't know any more at the moment, but I'd definitely like to fill that table out.