11 Jan
2017
11 Jan
'17
12:10 p.m.
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085 and
D8741A peripheral controller dumps both containing several opcodes that two
disassemblers aren't recognising and any docs I've been looking through for
either 8085 instructions or the UPI instruction set don't seem to feature
them either.
The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
0x08 nearly always follows a 0x01 LXI B instruction, the others don't seem
to have an obvious pattern.
I've pondered if 0x10 is INC @R0 because the binary for that is 0001 000x
where x is either 0 or 1.
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
11 Jan
11 Jan
12:16 p.m.
Another possibility could be self-modifying mode, something somewhere else
could be writing over this code once it's running. Though that would be
assuming it's in RAM. Though the code around these instructions seems
confusing. Looking at the values it almost looks like it's ASCII text and
not actual code data. I see numbers in the 0x40 and 0x60 range which are
the ASCII lowercase and uppercase letters. Along with 0x20 which is a
space. Perhaps try interpreting the data as data instead of code?
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham <binarydinosaurs at gmail.com>
wrote:
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085 and
D8741A peripheral controller dumps both containing several opcodes that two
disassemblers aren't recognising and any docs I've been looking through for
either 8085 instructions or the UPI instruction set don't seem to feature
them either.
The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
0x08 nearly always follows a 0x01 LXI B instruction, the others don't seem
to have an obvious pattern.
I've pondered if 0x10 is INC @R0 because the binary for that is 0001 000x
where x is either 0 or 1.
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
12:21 p.m.
Sorry for the double reply.
It's definitely ASCII data and not code. There's also seems to be some
other constant data in the middle, but translating the byte values as ASCII
gives:
"Telephone Details [few odd bytes]Select "
Where [few odd bytes] is 01 04 05 08 which is presumable some other
constant data, or some delimiters related to the strings.
Hayden
On Wed, Jan 11, 2017 at 10:16 AM, Hayden Kroepfl <perlpowers at gmail.com>
wrote:
Another possibility could be self-modifying mode,
something somewhere else
could be writing over this code once it's running. Though that would be
assuming it's in RAM. Though the code around these instructions seems
confusing. Looking at the values it almost looks like it's ASCII text and
not actual code data. I see numbers in the 0x40 and 0x60 range which are
the ASCII lowercase and uppercase letters. Along with 0x20 which is a
space. Perhaps try interpreting the data as data instead of code?
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham <binarydinosaurs at gmail.com
wrote:
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085
and
D8741A peripheral controller dumps both containing several opcodes that
two
disassemblers aren't recognising and any docs I've been looking through
for
either 8085 instructions or the UPI instruction set don't seem to feature
them either.
The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
0x08 nearly always follows a 0x01 LXI B instruction, the others don't seem
to have an obvious pattern.
I've pondered if 0x10 is INC @R0 because the binary for that is 0001 000x
where x is either 0 or 1.
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
12:31 p.m.
Hi all,
Well, this is ROM dumps of a telephone system so that would make sense for
some of it, but surely a disassembler should also recognise that it's ASCII
string data and treat it accordingly? I can imagine a freeware disassembler
maybe making that mistake but the second one is commercial.
I'll have a closer look at DASMx's parameters when I get home, that's the
freeware one but it seems to make a better job of it than the commercial
version, though both the D8741A and ROM dumps produce the same unknown
opcodes.
If anyone knows of others please shout up.
Cheers!
On 11 January 2017 at 17:21, Hayden Kroepfl <perlpowers at gmail.com> wrote:
Sorry for the double reply.
It's definitely ASCII data and not code. There's also seems to be some
other constant data in the middle, but translating the byte values as ASCII
gives:
"Telephone Details [few odd bytes]Select "
Where [few odd bytes] is 01 04 05 08 which is presumable some other
constant data, or some delimiters related to the strings.
Hayden
On Wed, Jan 11, 2017 at 10:16 AM, Hayden Kroepfl <perlpowers at gmail.com>
wrote:
feature
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
Another possibility could be self-modifying mode,
something somewhere
else
could be writing over this code once it's
running. Though that would be
assuming it's in RAM. Though the code around these instructions seems
confusing. Looking at the values it almost looks like it's ASCII text and
not actual code data. I see numbers in the 0x40 and 0x60 range which are
the ASCII lowercase and uppercase letters. Along with 0x20 which is a
space. Perhaps try interpreting the data as data instead of code?
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham <
binarydinosaurs at gmail.com
wrote:
> Hi folks,
>
> Any 8085 assembler geeks in the house?
>
> Official Intel docs don't seem to be helping with this one, I have 8085
> and
> D8741A peripheral controller dumps both containing several opcodes that
> two
> disassemblers aren't recognising and any docs I've been looking through
> for
> either 8085 instructions or the UPI instruction set don't seem to > them either.
>
> The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
>
> 0x08 nearly always follows a 0x01 LXI B instruction, the others don't
seem
> to have an obvious pattern.
>
> I've pondered if 0x10 is INC @R0 because the binary for that is 0001
000x
where x
is either 0 or 1.
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
12:38 p.m.
Well unless the code is running a disassembler has no real clue, because as
you can see ASCII corresponds mostly to completely valid instructions,
mainly the MOV reg,reg instructions. Depending on how the code's written it
could be basically impossible for a disassembler to tell.
For example you could have code that calls a function that takes inline
arguments, as such you'd have a JSR (or whatever the 8085 equiv is)
followed by data, not instructions. In that subroutine it would change the
return pointer on the stack to jump over those instructions.
The other way a disassembler could do it would be to actually run the code
and see where the code path goes. But then there's no guarantee that it
actually reaches all code points. A smart disassembler can guess based off
jumps and a starting point, but it still doesn't help it the case I
mentioned above.
Disassembly always requires some human element as it can't possibly handle
all cases. Tools like IDA and such typically don't disassemble until you
manually pick and entry point, then it disassembles as far as it can safely
assume from there. You then have to find other code paths yourself. For a
static disassembler you may have to hand hold it, especially if there's
self modifying code which could mess up the disassembly of multi-byte
instructions for a few instructions past the invalid one.
Hayden
On Wed, Jan 11, 2017 at 10:31 AM, Adrian Graham <binarydinosaurs at gmail.com>
wrote:
Hi all,
Well, this is ROM dumps of a telephone system so that would make sense for
some of it, but surely a disassembler should also recognise that it's ASCII
string data and treat it accordingly? I can imagine a freeware disassembler
maybe making that mistake but the second one is commercial.
I'll have a closer look at DASMx's parameters when I get home, that's the
freeware one but it seems to make a better job of it than the commercial
version, though both the D8741A and ROM dumps produce the same unknown
opcodes.
If anyone knows of others please shout up.
Cheers!
On 11 January 2017 at 17:21, Hayden Kroepfl <perlpowers at gmail.com> wrote:
8085
0xDD
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
Sorry for the double reply.
It's definitely ASCII data and not code. There's also seems to be some
other constant data in the middle, but translating the byte values as
ASCII
gives:
"Telephone Details [few odd bytes]Select "
Where [few odd bytes] is 01 04 05 08 which is presumable some other
constant data, or some delimiters related to the strings.
Hayden
On Wed, Jan 11, 2017 at 10:16 AM, Hayden Kroepfl <perlpowers at gmail.com>
wrote:
and
Another possibility could be self-modifying mode,
something somewhere
else
> could be writing over this code once it's running. Though that would be
> assuming it's in RAM. Though the code around these instructions seems
> confusing. Looking at the values it almost looks like it's ASCII text > not actual code data. I see numbers in the
0x40 and 0x60 range which
are
the ASCII
lowercase and uppercase letters. Along with 0x20 which is a
space. Perhaps try interpreting the data as data instead of code?
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham <
binarydinosaurs at gmail.com
> > wrote:
>
>> Hi folks,
>>
>> Any 8085 assembler geeks in the house?
>>
>> Official Intel docs don't seem to be helping with this one, I have >> and
>> D8741A peripheral controller dumps both containing several opcodes
that
>> two
>> disassemblers aren't recognising and any docs I've been looking
through
> for
> either 8085 instructions or the UPI instruction set don't seem to
feature
> them either.
>
> The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
>
> 0x08 nearly always follows a 0x01 LXI B instruction, the others don't
seem
> to have an obvious pattern.
>
> I've pondered if 0x10 is INC @R0 because the binary for that is 0001
000x
>> where x is either 0 or 1.
>> By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and >> could be XRL A,R5 but can't match
the others. Also the surrounding
code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
12:49 p.m.
On Wed, 11 Jan 2017, Adrian Graham wrote:
Well, this is ROM dumps of a telephone system so that
would make sense for
some of it, but surely a disassembler should also recognise that it's ASCII
string data and treat it accordingly? I can imagine a freeware disassembler
maybe making that mistake but the second one is commercial.
"mistake"?
Maybe give you an out-of-channel text message?, but it did what you asked
for, which was to interpret that section as CODE.
Sometime, try creating a .COM file in MS-DOS that starts with
DEC BP
POP DX
The loader in MS-DOS recognizes that as Mark Zbikowski's initials, and
will process the file as an .EXE, instead of .COM (disunirregardless of
.COM V .EXE file extension)
I'll have a closer look at DASMx's parameters
when I get home, that's the
freeware one but it seems to make a better job of it than the commercial
version, though both the D8741A and ROM dumps produce the same unknown
opcodes.
If anyone knows of others please shout up.
Yes, wouldn't it be nice if a disassembler would have the smarts to
recognize that certain bites are text, to decipher 32 bit floating point
numbers, parse and display AES DIRectory entries, notice and invert
BIG-endian V little-endian numbers, look up what any INT call is heading
for, recognize string terminator characters, and spell check any text that
it finds, . . .
1:01 p.m.
Quite realistic would be for a disassembler that couldn't recognize an
opcode to display it as
DB 1A ; Esc
DB 65 ; 'e'
DB 09
Code immediately following an unconditional JMP is likely to be data, but
could just as easily be the destination of some other JMP, so a
disassemble can't make assumptions.
A disassembler does not convert bytes into code. It merely assists YOU in
doing that.
1:08 p.m.
On Wed, Jan 11, 2017 at 6:01 PM, Fred Cisin <cisin at xenosoft.com> wrote:
Quite realistic would be for a disassembler that
couldn't recognize an
opcode to display it as
DB 1A ; Esc
DB 65 ; 'e'
DB 09
I once used a disassembler (I can't remember for what CPU) that would
put a comment on each line giving the ascii character equivalents of the
bytes.
So you would get something like (totally ficticious instruction set) :
0100 48 65 6C ST R8 (656C) ; Hel
You (the user) could then decide if the instruction or text made more
sense. Of course it didn't help with, say floating point numbers, or RAD50
strings or...
Code immediately following an unconditional JMP is
likely to be data, but
could just as easily be the destination of some other JMP, so a disassemble
can't make assumptions.
A disassembler does not convert bytes into code. It merely assists YOU in
doing that.
Yes, like all tools, you have to think when you are using it.
-tony
1:48 p.m.
I always go through the code and put a extra return after
each unconditional jump or return.
My disassemblers always make a list and count of addresses accessed
by any non-indirect reference. If I see a blank line in the code,
without any references, I get suspicious.
How can the code execute this location if it is never referenced??
I can then tell my assembler to treat that location differently.
I can tell it it is a DB field for instance.
I then rerun the disassembler again to see if it cleans things up.
It usually takes several passes to get things straightened out.
Any disassembler, worth playing with, has such directives.
As was mentioned, the disassembler has no way of knowing what
the bytes are there for. Say the code did some type of indirect
access into the table based on some value passed through a serial
port ( where 35-94 are the only valid values ). How would you expect the
disassembler to figure that out.
I was disassembling 4004 code a while back. I came on a number
of illegal operations( using my disassembler ).
It turned out that it was the use of an instruction that was unusual.
It was the conditional jump. If it had no condition, it would always
skip over the address ( next byte ) and not jump.
It was used as a SKIP instruction. It would allow a single byte to be
executed at the entry to a common routine. The address field was
an instruction for a different entry point, into the routine.
I added the SKIP to my disassembler [?]
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Tony Duell
<ard.p850ug1 at gmail.com>
Sent: Wednesday, January 11, 2017 10:08:28 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Unknown 8085 opcodes
On Wed, Jan 11, 2017 at 6:01 PM, Fred Cisin <cisin at xenosoft.com> wrote:
Quite realistic would be for a disassembler that
couldn't recognize an
opcode to display it as
DB 1A ; Esc
DB 65 ; 'e'
DB 09
I once used a disassembler (I can't remember for what CPU) that would
put a comment on each line giving the ascii character equivalents of the
bytes.
So you would get something like (totally ficticious instruction set) :
0100 48 65 6C ST R8 (656C) ; Hel
You (the user) could then decide if the instruction or text made more
sense. Of course it didn't help with, say floating point numbers, or RAD50
strings or...
Code immediately following an unconditional JMP is
likely to be data, but
could just as easily be the destination of some other JMP, so a disassemble
can't make assumptions.
A disassembler does not convert bytes into code. It merely assists YOU in
doing that.
Yes, like all tools, you have to think when you are using it.
-tony
2:29 p.m.
On 1/11/2017 10:48 AM, dwight wrote:
My disassemblers always make a list and count of
addresses accessed
by any non-indirect reference. If I see a blank line in the code,
without any references, I get suspicious.
How can the code execute this location if it is never referenced??
I can then tell my assembler to treat that location differently.
The disassembler
we developed would make lists of addresses that were
referenced in the code by other than control change instructions. That
flag when referenced when the disassembler made one of its passes would
favor making the field a data definition based on the instruction
operation vs. making it a disassembly of an opcode.
Our disassembler used and constructed a master symbol table that could
be referenced to the system symbols, which in this case would be blank.
But we could pre-seed the symbol table with defines, and they would take
precedence over the dynamic ones from the disassembler's work. This way
as other said, you could manually analyzed and re-run the disassembler
as you guess functions, and the symbols would propagate thru the
resulting disassembly would get more and more clear with re-running.
I've not seen many that can do what the Pick disassembler could do (not
a Pick product, but ran on Pick with compatibility to that assembler) as
easily as ours could. Sounds a lot like dwight did this though.
thanks
Jim
1:28 p.m.
On 11/01/2017 17:49, "Fred Cisin" <cisin at xenosoft.com> wrote:
.COM V .EXE file extension)
Heh, point taken. I did actually run the code through a debugger with an
entry point and asked it to produce a listing from that so I'm not just
stabbing in the dark.
--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?
I'll have a closer look at DASMx's
parameters when I get home, that's the
freeware one but it seems to make a better job of it than the commercial
version, though both the D8741A and ROM dumps produce the same unknown
opcodes.
If anyone knows of others please shout up.
Yes, wouldn't it be nice if a disassembler would have the smarts to
recognize that certain bites are text, to decipher 32 bit floating point
numbers, parse and display AES DIRectory entries, notice and invert
BIG-endian V little-endian numbers, look up what any INT call is heading
for, recognize string terminator characters, and spell check any text that
it finds, . . . 
11:33 p.m.
On 01/11/2017 11:16 AM, Hayden Kroepfl wrote:
Looking at the values it almost looks like it's
ASCII text and
not actual code data.
BINGO!!
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham
<binarydinosaurs at gmail.com>
wrote:
> Example 8085 code fragment:
>
> 3440 1792 09 DAD B
> 3441 1793 01 01 08 LXI B,0801H
> 3442 1796 08 UNRECOGNIZED
> 3443 1797 12 STAX D
> 3444 1798 0D DCR C
> 3445 1799 54 MOV D,H
> 3446 179A 65 MOV H,L
> 3447 179B 6C MOV L,H
> 3448 179C 65 MOV H,L
> 3449 179D 70 MOV M,B
> 3450 179E 68 MOV L,B
> 3451 179F 6F MOV L,A
> 3452 17A0 6E MOV L,M
> 3453 17A1 65 MOV H,L
> 3454 17A2 20 RIM
> 3455 17A3 44 MOV B,H
> 3456 17A4 65 MOV H,L
> 3457 17A5 74 MOV M,H
> 3458 17A6 61 MOV H,C
> 3459 17A7 69 MOV L,C
> 3460 17A8 6C MOV L,H
> 3461 17A9 73 MOV M,E
> 3462 17AA 01 04 05 LXI B,0504H
> 3463 17AD 08 UNRECOGNIZED
> 3464 17AE 17 RAL
> 3465 17AF 53 MOV D,E
> 3466 17B0 65 MOV H,L
> 3467 17B1 6C MOV L,H
> 3468 17B2 65 MOV H,L
> 3469 17B3 63 MOV H,E
> 3470 17B4 74 MOV M,H
> 3471 17B5 20 RIM
>
>
08 = CR
54 65 6c 65 70 68 6f 6e 65 20 44 65 74 61 69 6c 73 =
"Telephone Details"
53 65 6c 65 63 74 20 = "Select "
Jon
11:45 p.m.
On Wed, Jan 11, 2017 at 8:33 PM, Jon Elson <elson at pico-systems.com> wrote:
On 01/11/2017 11:16 AM, Hayden Kroepfl wrote:
Looking at the values it almost looks like it's ASCII text and
not actual code data.
BINGO!!
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham
<binarydinosaurs at gmail.com>
wrote:
> Example 8085 code fragment:
>
> 3440 1792 09 DAD B
> 3441 1793 01 01 08 LXI B,0801H
> 3442 1796 08 UNRECOGNIZED
> 3443 1797 12 STAX D
> 3444 1798 0D DCR C
> 3445 1799 54 MOV D,H
> 3446 179A 65 MOV H,L
> 3447 179B 6C MOV L,H
> 3448 179C 65 MOV H,L
> 3449 179D 70 MOV M,B
> 3450 179E 68 MOV L,B
> 3451 179F 6F MOV L,A
> 3452 17A0 6E MOV L,M
> 3453 17A1 65 MOV H,L
> 3454 17A2 20 RIM
> 3455 17A3 44 MOV B,H
> 3456 17A4 65 MOV H,L
> 3457 17A5 74 MOV M,H
> 3458 17A6 61 MOV H,C
> 3459 17A7 69 MOV L,C
> 3460 17A8 6C MOV L,H
> 3461 17A9 73 MOV M,E
> 3462 17AA 01 04 05 LXI B,0504H
> 3463 17AD 08 UNRECOGNIZED
> 3464 17AE 17 RAL
> 3465 17AF 53 MOV D,E
> 3466 17B0 65 MOV H,L
> 3467 17B1 6C MOV L,H
> 3468 17B2 65 MOV H,L
> 3469 17B3 63 MOV H,E
> 3470 17B4 74 MOV M,H
> 3471 17B5 20 RIM
>
>
08 = CR
54 65 6c 65 70 68 6f 6e 65 20 44 65 74 61 69 6c 73 = "Telephone Details"
53 65 6c 65 63 74 20 = "Select "
Jon
12:17 p.m.
Hi Adrian
It looks like text, not code.
54 T
65 e
6c l
65 e
70 p
68 h
6f o
6e n
65 e
20 space
Henrik
Adrian Graham skrev 2017-01-11 18:10:
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085 and
D8741A peripheral controller dumps both containing several opcodes that two
disassemblers aren't recognising and any docs I've been looking through for
either 8085 instructions or the UPI instruction set don't seem to feature
them either.
The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
0x08 nearly always follows a 0x01 LXI B instruction, the others don't seem
to have an obvious pattern.
I've pondered if 0x10 is INC @R0 because the binary for that is 0001 000x
where x is either 0 or 1.
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
Cheers!
12:19 p.m.
On Wed, Jan 11, 2017 at 9:10 AM, Adrian Graham <binarydinosaurs at gmail.com>
wrote:
Hi folks,
Any 8085 assembler geeks in the house?
A uProcessor geek, but not 8085 :(
However, Wikipedia mentions:
" Undocumented instructions
A number of undocumented instructions and flags were discovered by two
software engineers, Wolfgang Dehnhardt and Villy M. Sorensen in the process
of developing an 8085 assembler. These instructions use 16-bit operands and
include indirect loading and storing of a word, a subtraction, a shift, a
rotate, and offset operations.[7]
7. Dehnhardt, Wolfgang; M. Sorensen, Villy (January 1979). "Unspecified
8085 op codes enhance programming". Electronics. McGraw-Hill: 144?145. ISSN
0013-5070."
-- Charles
4:26 p.m.
On 1/11/17 12:19 PM, Charles Anthony wrote:
On Wed, Jan 11, 2017 at 9:10 AM, Adrian Graham
<binarydinosaurs at gmail.com>
wrote:
I geek 8085 and Z80. When you see a mess like that its sure bet to look
at it with
a text analyser or DDT like tool that will display the code as text if
it is.
PC people would not think to do that as its rare for them to see 7Bit ASCII
and the tools commonly used might not either.
The tool I use for that is Resource (8080/8085 intel mnemonics) or Zesource
(z80 mnemonics) and dis48 for 8035/48/39/49. They run under CPM so you
need a system or an emulator like MyZ80 or Dave Dunfields
Altair/Northstar emulator.
Resource and its kin are directed disassemblers and when done they do
reliably
assemble back to the binary.
FYI if you want to see tightly packed code the TU58 controller (8085 based)
is a good example as it all fits in a 2K Eprom and only 256 bytes of ram.
Allison
Hi folks,
Any 8085 assembler geeks in the house?
A uProcessor geek, but not 8085 :(
However, Wikipedia mentions:
" Undocumented instructions
A number of undocumented instructions and flags were discovered by two
software engineers, Wolfgang Dehnhardt and Villy M. Sorensen in the process
of developing an 8085 assembler. These instructions use 16-bit operands and
include indirect loading and storing of a word, a subtraction, a shift, a
rotate, and offset operations.[7]
7. Dehnhardt, Wolfgang; M. Sorensen, Villy (January 1979). "Unspecified
8085 op codes enhance programming". Electronics. McGraw-Hill: 144?145. ISSN
0013-5070."
-- Charles
4:35 p.m.
On 01/11/2017 01:26 PM, allison wrote:
PC people would not think to do that as its rare for
them to see 7Bit
ASCII and the tools commonly used might not either.
I think that you sell "PC People" a bit short. The free version of IDA
Pro does recognize stuff like that, the last time I checked.
--Chuck
9:26 p.m.
What kind of people are PC people?
Are Mac users PC people.
I can across a professional python coder ( claimed 6 years
of experience ) that didn't realize that ASCII were just bits in a
pattern and you could use the computer to treat that pattern
as a number. As a number, you could add and subtract from
it.
Maybe that is a PC person. I'm typing on a laptop PC right now.
Maybe I'm a PC person and didn't know it.
Dwight
________________________________
From: cctech <cctech-bounces at classiccmp.org> on behalf of Chuck Guzis <cclist
at sydex.com>
Sent: Wednesday, January 11, 2017 1:35:46 PM
To: General Discussion: On-Topic Posts
Subject: Re: Unknown 8085 opcodes
On 01/11/2017 01:26 PM, allison wrote:
PC people would not think to do that as its rare for
them to see 7Bit
ASCII and the tools commonly used might not either.
I think that you sell "PC People" a bit short. The free version of IDA
Pro does recognize stuff like that, the last time I checked.
--Chuck
12:23 p.m.
On Wed, Jan 11, 2017 at 5:10 PM, Adrian Graham
<binarydinosaurs at gmail.com> wrote:
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085 and
D8741A peripheral controller dumps both containing several opcodes that two
disassemblers aren't recognising and any docs I've been looking through for
either 8085 instructions or the UPI instruction set don't seem to feature
them either.
The codes are 0x08, 0x10, 0x18, 0x28, 0x38,0xD9, 0xDD and 0xED.
0x08 nearly always follows a 0x01 LXI B instruction, the others don't seem
to have an obvious pattern.
I've pondered if 0x10 is INC @R0 because the binary for that is 0001 000x
where x is either 0 or 1.
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
I'm no programmer, but that looks like ascii text to me. Have you
tried decoding it
as such?
-tony
1:56 p.m.
On 11/01/2017 17:23, "Tony Duell" <ard.p850ug1 at gmail.com> wrote:
Indeed, this is the same fragment:
1797 : 12 0D 54 65 6C 65 70 68 " Teleph" db 012H,
00DH, 054H, 065H, 06CH, 065H, 070H, 068H
179F : 6F 6E 65 20 44 65 74 61 "one Deta" db 06FH,
06EH, 065H, 020H, 044H, 065H, 074H, 061H
17A7 : 69 6C 73 01 04 05 08 17 "ils " db 069H,
06CH, 073H, 001H, 004H, 005H, 008H, 017H
17AF : 53 65 6C 65 63 74 20 6E "Select n" db 053H,
065H, 06CH, 065H, 063H, 074H, 020H, 06EH
17B7 : 75 6D 62 65 72 20 74 6F "umber to" db 075H,
06DH, 062H, 065H, 072H, 020H, 074H, 06FH
17BF : 20 63 68 61 6E 67 65 01 " change " db 020H,
063H, 068H, 061H, 06EH, 067H, 065H, 001H
17C7 : 06 00 08 1B 0D 31 20 20 " 1 " db 006H,
000H, 008H, 01BH, 00DH, 031H, 020H, 020H
17CF : 20 50 42 58 20 45 78 74 " PBX Ext" db 020H,
050H, 042H, 058H, 020H, 045H, 078H, 074H
17D7 : 2E 20 20 20 44 69 72 65 ". Dire" db 02EH,
020H, 020H, 020H, 044H, 069H, 072H, 065H
17DF : 63 74 20 4C 69 6E 65 01 "ct Line " db 063H,
074H, 020H, 04CH, 069H, 06EH, 065H, 001H
17E7 : 09 00 08 1A 0D 32 20 20 " 2 " db 009H,
000H, 008H, 01AH, 00DH, 032H, 020H, 020H
17EF : 06 50 72 65 2D 44 69 61 " Pre-Dia" db 006H,
050H, 072H, 065H, 02DH, 044H, 069H, 061H
17F7 : 6C 20 50 61 75 73 65 20 "l Pause " db 06CH,
020H, 050H, 061H, 075H, 073H, 065H, 020H
17FF : 28 73 65 63 73 29 01 0C "(secs) " db 028H,
073H, 065H, 063H, 073H, 029H, 001H, 00CH
1807 : 01 08 25 0D 20 20 20 31 " % 1" db 001H,
008H, 025H, 00DH, 020H, 020H, 020H, 031H
180F : 2E 35 20 20 20 32 2E 30 ".5 2.0" db 02EH,
035H, 020H, 020H, 020H, 032H, 02EH, 030H
1817 : 20 20 20 32 2E 35 20 20 " 2.5 " db 020H,
020H, 020H, 032H, 02EH, 035H, 020H, 020H
181F : 20 33 2E 30 20 20 20 33 " 3.0 3" db 020H,
033H, 02EH, 030H, 020H, 020H, 020H, 033H
1827 : 2E 35 20 20 20 34 2E 30 ".5 4.0" db 02EH,
035H, 020H, 020H, 020H, 034H, 02EH, 030H
182F : 01 12 00 08 22 0D 34 20 " " 4 " db 001H,
012H, 000H, 008H, 022H, 00DH, 034H, 020H
1837 : 20 06 50 42 58 2F 4F 75 " PBX/Ou" db 020H,
006H, 050H, 042H, 058H, 02FH, 04FH, 075H
183F : 74 73 69 64 65 20 4C 69 "tside Li" db 074H,
073H, 069H, 064H, 065H, 020H, 04CH, 069H
1847 : 6E 65 20 50 61 75 73 65 "ne Pause" db 06EH,
065H, 020H, 050H, 061H, 075H, 073H, 065H
184F : 20 28 73 65 63 73 29 01 " (secs) " db 020H,
028H, 073H, 065H, 063H, 073H, 029H, 001H
18
I was trying to work out why this phone system does nothing but 3 distinct
separate loops before heading off doing.....something. Obviously a delay
timer waiting for something else to start but why 3 different ones and not
one long one. Interrupts disabled too.
--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?
3463 17AD 08
UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
I'm no programmer, but that looks like ascii text to me. Have you
tried decoding it
as such?
12:34 p.m.
Looks more like data, than code.
........Telephone Details.....Select
On Wed, 11 Jan 2017, Adrian Graham wrote:
By the same reasoning 0xD9 could be XRL A,R1 (opcode
11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08 LXI B,0801H
3442 1796 08 UNRECOGNIZED
3443 1797 12 STAX D
3444 1798 0D DCR C
3445 1799 54 MOV D,H
3446 179A 65 MOV H,L
3447 179B 6C MOV L,H
3448 179C 65 MOV H,L
3449 179D 70 MOV M,B
3450 179E 68 MOV L,B
3451 179F 6F MOV L,A
3452 17A0 6E MOV L,M
3453 17A1 65 MOV H,L
3454 17A2 20 RIM
3455 17A3 44 MOV B,H
3456 17A4 65 MOV H,L
3457 17A5 74 MOV M,H
3458 17A6 61 MOV H,C
3459 17A7 69 MOV L,C
3460 17A8 6C MOV L,H
3461 17A9 73 MOV M,E
3462 17AA 01 04 05 LXI B,0504H
3463 17AD 08 UNRECOGNIZED
3464 17AE 17 RAL
3465 17AF 53 MOV D,E
3466 17B0 65 MOV H,L
3467 17B1 6C MOV L,H
3468 17B2 65 MOV H,L
3469 17B3 63 MOV H,E
3470 17B4 74 MOV M,H
3471 17B5 20 RIM
1:12 p.m.
There is a fairly steep learning curve, but you may
want to consider getting a MAME simulation of the device running.
There are some pretty powerful tools in the debugger for analyzing
things like I/O port references etc. and it can deal with debugging
in environments where multiple microprocessors are running.
On 1/11/17 9:10 AM, Adrian Graham wrote:
Hi folks,
Any 8085 assembler geeks in the house?
2749
days inactive
2750
days old
22 comments
14 participants
participants (14)
-
aek＠bitsavers.org -
ajp166＠verizon.net -
ard.p850ug1＠gmail.com -
binarydinosaurs＠gmail.com -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
cisin＠xenosoft.com -
dkelvey＠hotmail.com -
elson＠pico-systems.com -
henrik＠datalinesweden.se -
imp＠bsdimp.com -
jwsmail＠jwsss.com -
perlpowers＠gmail.com -
witchy＠binarydinosaurs.co.uk