8085 Address Decoding
Alexis Kotlowy
thrashbarg at kaput.homeunix.org
Wed Jan 25 19:09:39 CST 2017
On 26/01/2017 10:17, Adrian Graham wrote:
> Evening folks,
>
> Could a stuck bit or floating pin cause this address sequence?
>
> 0.142261562500000,'3896' (0x0F38) 0000111100111001
> 0.142262937500000,'3897' (0x0F39) 0000111100111010
> 0.142264250000000,'3898' (0x0F3A) 0000111100111011
> 0.142265562500000,'3899' (0x0F3B) 0000111100111100
> 0.142266937500000,'3900' (0x0F3C) 0000111100111101
> 0.142268250000000,'3901' (0x0F3D) 0000111100111110
> 0.142269562500000,'3902' (0x0F3E) 0000111100111111
> 0.142270937500000,'61618' (0xF0B2) 1111000010110010 (should be 0x0FB2?)
> 0.142271937500000,'61619' (0xF0B3) 1111000010110011 (should be 0x0FB3?)
> 0.142261562500000,'3896' (0x0F38) 0000111100111001
> 0.142262937500000,'3897' (0x0F39) 0000111100111010
> 0.142264250000000,'3898' (0x0F3A) 0000111100111011
> 0.142265562500000,'3899' (0x0F3B) 0000111100111100
> 0.142266937500000,'3900' (0x0F3C) 0000111100111101
> 0.142268250000000,'3901' (0x0F3D) 0000111100111110
> 0.142269562500000,'3902' (0x0F3E) 0000111100111111
> 0.142270937500000,'61618' (0xF0B2) 1111000010110010
> 0.142271937500000,'61619' (0xF0B3) 1111000010110011
> 0.142261562500000,'3896' (0x0F38) 0000111100111001
> 0.142262937500000,'3897' (0x0F39) 0000111100111010
> 0.142264250000000,'3898' (0x0F3A) 0000111100111011
> 0.142265562500000,'3899' (0x0F3B) 0000111100111100
> 0.142266937500000,'3900' (0x0F3C) 0000111100111101
> 0.142268250000000,'3901' (0x0F3D) 0000111100111110
> 0.142269562500000,'3902' (0x0F3E) 0000111100111111
> 0.142270937500000,'61618' (0xF0B2) 1111000010110010
> 0.142271937500000,'61619' (0xF0B3) 1111000010110011
>
> My Executel ROM disassembly puts this block of code between 0x0F38 and
> 0x0F3E:
>
> 0F38 L0F38:
> 0F38 : 7B "{" [4] mov a,e
> 0F39 : 95 " " [4] sub l
> 0F3A : 5F "_" [4] mov e,a
> 0F3B : 7A "z" [4] mov a,d
> 0F3C : 9C " " [4] sbb h
> 0F3D : 57 "W" [4] mov d,a
> 0F3E : C9 " " [10] ret
>
> Does that make sense? I might not have a full disassembly since L0F38 is
> only called from two places and neither of them jump back to 0x0FB2 but I
> know that doesn't necessarily mean it's wrong.
>
> Cheers,
>
Hi Adrian,
The instruction at 0x0F3E is RET, so it's going to read two bytes off
the stack and jump to it. This is what you're seeing at 0xF0B2 and
0xF0B3. I'd suggest you look at how RAM is addressed at the top of
memory space and see if it's correct.
Alexis.
More information about the cctech
mailing list