Re: Unknown 8085 opcodes

[Mouse]

>>> jsr puts
>>> fcc 'Hello, world!',13,0
>>> clra
>> Mine can't do that automatically, but it can with a little human
>> assist; the human would need to tell it that the memory after the
>> jsr is a NUL-terminated string, but that's all it would need to be
>> told.
> Not all strings are null-terminated.

Mine can also be told that it's a block of text where you tell it the
length.  I think the only sort of automatic length determination I
implemented is NUL termination, but you can specify whatever length you
want manually.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Unknown 8085 opcodes

[Fred Cisin]

Not all strings are null-terminated.  In CP/M, and MS-DOS INT21h Fn9, the
terminating character is '$' !
"If you are ever choosing a termination marker, choose something that
could NEVER occur in normal data!"
Also, strings may, instead of a terminating character, be specified with a
length, or with a start and end address.


On Thu, 12 Jan 2017, Sean Conner wrote:

 I've seen the high bit set on the last character, again mostly in the
8-bit world.

Yes, but also for "soft" spaces in Wordstar files.

That seemed to disappear when the 5150 came out,
since it it had some useful characters in the upper 128 set,
such as "enyay" (N~), and 'e' with acute accent for your "resume".
Not all that were present were useful, and
not all useful ones were present.
Thanks for the stupid smiley faces, but howzbout
"yen", "pound sterling", "trademark", "registered mark",
and "copyright"?
One of my students speculated that the choices that were made,
resulted in more stringent workplace sobriety measures.

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/12/2017 01:30 PM, Sean Conner wrote:

> I've seen the high bit set on the last character, again mostly in
> the 8-bit world.

Prime  (in PrimOS) took the approach of setting the high bit on *all*
ASCII data, which does make it stick out in a tape or core dump.

--Chuck

Re: Unknown 8085 opcodes

[Sean Conner]

It was thus said that the Great Fred Cisin once stated:
> >>jsr puts
> >>fcc 'Hello, world!',13,0
> >>clra
> or the classic:
>JMP START1
>DATA2: DB . . .
>   DB . . .
>START1: MOV DX, OFFSET DATA2 
> Which was heavily used because
>MOV DX, OFFSET DATA3
>. . .
>DATA3: DB . . .
> would pose "forward reference" or "undefined symbol" problems for some 
> assemblers.
> 
> Even for manual assembly, or 'A' mode of DEBUG.COM, it was handy to 
> already know the address of the data before you wrote the steps to access 
> it.
> 
> On Thu, 12 Jan 2017, Mouse wrote:
> >Mine can't do that automatically, but it can with a little human
> >assist; the human would need to tell it that the memory after the jsr
> >is a NUL-terminated string, but that's all it would need to be told.
> 
> Not all strings are null-terminated.  In CP/M, and MS-DOS INT21h Fn9, the 
> terminating character is '$' !
> "If you are ever choosing a termination marker, choose something that 
> could NEVER occur in normal data!"
> Also, strings may, instead of a terminating character, be specified with a 
> length, or with a start and end address.

  I've seen the high bit set on the last character, again mostly in the
8-bit world.

  -spc

Re: Unknown 8085 opcodes

[Fred Cisin]

jsr puts
fcc 'Hello, world!',13,0
clra

or the classic:
   JMP START1
   DATA2:   DB . . .
DB . . .
   START1: MOV DX, OFFSET DATA2 
Which was heavily used because

   MOV DX, OFFSET DATA3
   . . .
   DATA3: DB . . .
would pose "forward reference" or "undefined symbol" problems for some 
assemblers.


Even for manual assembly, or 'A' mode of DEBUG.COM, it was handy to 
already know the address of the data before you wrote the steps to access 
it.


On Thu, 12 Jan 2017, Mouse wrote:

Mine can't do that automatically, but it can with a little human
assist; the human would need to tell it that the memory after the jsr
is a NUL-terminated string, but that's all it would need to be told.


Not all strings are null-terminated.  In CP/M, and MS-DOS INT21h Fn9, the 
terminating character is '$' !
"If you are ever choosing a termination marker, choose something that 
could NEVER occur in normal data!"
Also, strings may, instead of a terminating character, be specified with a 
length, or with a start and end address.

Re: Unknown 8085 opcodes

[Mouse]

>> Clone [my disassembler] and look at the README if you want to get an
>> idea how it works from a user's point of view.
> I will certainly do that.  It'll be interesting how this for 8080/z80
> compares to the 30-odd-year old interactive disassembler for CP/M,
> Dazzlestar.

It will probably come out on the short end of that comparison.  A
multi-target disassembler will usually not be as good for any
particular machine as one designed from the ground up for only that
machine.

And, of course, there will be lots of differences which are neither
better nor worse, just different...though to someone used to one or the
other it may feel like better or worse. :-)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/12/2017 11:21 AM, Sean Conner wrote:

> 
>   But are there disassemblers that can handle somehing like:
> 
>   jsr puts
>   fcc 'Hello, world!',13,0
>   clra
>   ...
> 
>   putspulsx
>   puts1   lda ,x+
>   beq puts9
>   jsr putchar
>   bra puts1
>   puts9   pshsx
>   rts
> 
> I recall that being a somewhat common idiom in 8-bit code of the
> 80s.

Good question.  It wasn't just 8-bit code that did that.  When I was
churning out 8086 real-mode code, I used a somewhat amplified version of
that for debugging.  E.g.,

CALLDEBUGOUT
DB  "At point xx, CX=#CX, AX=#AX",0
...

The debug print routine parsed the string and inserted the (saved)
values of the specified registers.  It could even show contents of
memory pointed to by a register as well as contents of I/O ports.  Very
useful if you didn't have an ICE handy.

I do know that IDA reverts to "unknown" mode when a byte value not
corresponding to a known opcode is presented.

--Chuck

Re: Unknown 8085 opcodes

[Sean Conner]

It was thus said that the Great Chuck Guzis once stated:
> On 01/12/2017 07:35 AM, Mouse wrote:
> 
> >> Does your disassembler do flow analysis?
> > 
> > I doubt it, because none of the meanings I know for the term are 
> > anything my disassembler does.
> 
> A disassembler that can do flow analysis is a breath of fresh air when
> working with larger binaries.  Essentially, it looks at the code and
> makes some decisions about its content.
> 
> Thus, a target of an already-disassembled jump must also be code, not
> data, for example, so it's possible to disassemble large sections of
> code automatically.  Sections not referenced as code or data are held as
> "unknown" code until some guidance from the user is provided.

  But are there disassemblers that can handle somehing like:

jsr puts
fcc 'Hello, world!',13,0
clra
...

putspulsx
puts1   lda ,x+
beq puts9
jsr putchar
bra puts1
puts9   pshsx
rts

  I recall that being a somewhat common idiom in 8-bit code of the 80s.

  -spc

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/12/2017 09:52 AM, Mouse wrote:

> My disassembler defaults to disassembling as instructions, but it
> has support for the user telling it that certain areas are text, or 
> integers, or whatever.  Clone it and look at the README if you want
> to get an idea how it works from a user's point of view.

I will certainly do that.   It'll be interesting how this for 8080/z80
compares to the 30-odd-year old interactive disassembler for CP/M,
Dazzlestar.

--Chuck

Re: Unknown 8085 opcodes

[Adrian Graham]

On 12/01/2017 04:50, "dwight" <dkel...@hotmail.com> wrote:

> Even so, he said the code was
> 
> for the 8741. It is not 8085!
> 

Not strictly true, I said I saw the same opcodes in both and it was only
reading a buttload of books yesterday that showed me the errors of my ways
:)

A

> 
> From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Chuck Guzis
> <ccl...@sydex.com>
> Sent: Wednesday, January 11, 2017 7:12:43 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: Unknown 8085 opcodes
> 
> On 01/11/2017 06:45 PM, Mouse wrote:
> 
>> In case anyone is interested, I export it via git.  The thing to
>> clone is git://git.rodents-montreal.org/Mouse/disas, though it hasn't
>> had much testing off my systems and thus probably contains
>> localisms.
> 
> Does your disassembler do flow analysis?
> 
> At any rate, the best reference for "undocumented" 8085 instructions is
> the Tundra/Calmos datasheet:
> 
> http://www.datasheetarchive.com/dlmain/6365531e98b38dadd61a8399fa30d8f0c9a0aa/
> M/CA80C85
> 
> The other instructions follow the 8080.
> 
> --Chuck
> 
> 
> 

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Unknown 8085 opcodes

[Mouse]

>>> Does your disassembler do flow analysis?
>> I doubt it, because none of the meanings I know for the term are
>> anything my disassembler does.
> A disassembler that can do flow analysis is a breath of fresh air
> when working with larger binaries.  Essentially, it looks at the code
> and makes some decisions about its content.

A reasonable facility to have, though of course you need overrides in
both directions.

> Thus, a target of an already-disassembled jump must also be code,

Well...usually.  It's possible the jump isn't actually a jump
instruction (just data that happens to look like one) and it's possible
it doesn't actually jump to where it appears to for any of many
possible reasons.  Hence the overrides.

My disassembler defaults to disassembling as instructions, but it has
support for the user telling it that certain areas are text, or
integers, or whatever.  Clone it and look at the README if you want to
get an idea how it works from a user's point of view.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/12/2017 07:35 AM, Mouse wrote:

>> Does your disassembler do flow analysis?
> 
> I doubt it, because none of the meanings I know for the term are 
> anything my disassembler does.

A disassembler that can do flow analysis is a breath of fresh air when
working with larger binaries.  Essentially, it looks at the code and
makes some decisions about its content.

Thus, a target of an already-disassembled jump must also be code, not
data, for example, so it's possible to disassemble large sections of
code automatically.  Sections not referenced as code or data are held as
"unknown" code until some guidance from the user is provided.

IDA Pro is one such disassembler and it's a godsend when working with
code in ROM, where data may (is usually) interleaved with instructions.
I believe that IDA can even make a stab at the processor family (e.g.
80286 vs. 8086 vs. 80386, etc.)

It's a remarkable tool.  I've used it for 8051, but I don't know if it
can do 8048.

--Chuck

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/11/2017 10:13 PM, dwight wrote:
> Sorry Chuck
> 
> It was not you I was talking about. It was the original thinking that
> a 8085 disassembler would make sense out of the original 8041 code.
> 
> Maybe I'm confused but I believe the code in question was the 8041.

It's okay--topic drift isn't unknown even here.  I get confused a lot
also--must be a symptom of age. :)

--Chuck

Re: Unknown 8085 opcodes

[Mouse]

>> [...disassembler...]
> Does your disassembler do flow analysis?

I doubt it, because none of the meanings I know for the term are
anything my disassembler does.

> At any rate, the best reference for "undocumented" 8085 instructions
> is the Tundra/Calmos datasheet: [...]

That looks like a webpage, not a datasheet, but I found a link there to
http://datasheet.datasheetarchive.com/originals/distributors/Datasheets-8/DSA-152680.pdf,
which appears to be the datasheet.  Saved, thank you!

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Unknown 8085 opcodes

[Toby Thain]

On 2017-01-11 11:45 PM, Mouse wrote:

Good list there, the onlinedebugger looked the most promising but it
doesn't do 8080/8085 either.


I built a disassembler years ago to pick apart captured malware.  By
now it handles about a dozen ISAs.  While 8080 and 8085 are not on the
list, Z-80 is; adding 8080 would be a relatively simple thing.  I've
added that to my to-do list; if someone can point me to 8080/8085
machine language documentation that would save me some searching (which


https://www.google.ca/search?q=intel+8080
lists several books and the manuals on the first page.




is something I'm not much good at in these days when frickin'
*everything* is shoehorned into a Web page).

In case anyone is interested, I export it via git.  The thing to clone
is git://git.rodents-montreal.org/Mouse/disas, though it hasn't had
much testing off my systems and thus probably contains localisms.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Unknown 8085 opcodes

[Lars Brinkhoff]

Johnny Eriksson wrote:
> from another disassembler project:
>   { 0xC9, 1, popj,   0,   "ret" },
>   { 0xCD, 3, pushj,  0,   "call %a" },

Someone with good taste, I see.

Re: Unknown 8085 opcodes

[Johnny Eriksson]

> I built a disassembler years ago to pick apart captured malware.  By
> now it handles about a dozen ISAs.  While 8080 and 8085 are not on the
> list, Z-80 is; adding 8080 would be a relatively simple thing.  I've
> added that to my to-do list; if someone can point me to 8080/8085
> machine language documentation that would save me some searching (which
> is something I'm not much good at in these days when frickin'
> *everything* is shoehorned into a Web page).

You mean something like this, from another disassembler project:

/*  Intel opcode table  */

static dispblock inteldisp[256] = {
  { 0x00, 1, inst,   0,   "nop" },
  { 0x01, 3, inst,   0,   "lxi b,%2" },
  { 0x02, 1, inst,   0,   "stax b" },
  { 0x03, 1, inst,   0,   "inx b" },
  { 0x04, 1, inst,   0,   "inr b" },
  { 0x05, 1, inst,   0,   "dcr b" },
  { 0x06, 2, inst,   0,   "mvi b,%1" },
  { 0x07, 1, inst,   0,   "rlc" },
  { 0x08, 1, unused, 0,   0 },
  { 0x09, 1, inst,   0,   "dad b" },
  { 0x0A, 1, inst,   0,   "ldax b" },
  { 0x0B, 1, inst,   0,   "dcx b" },
  { 0x0C, 1, inst,   0,   "inr c" },
  { 0x0D, 1, inst,   0,   "dcr c" },
  { 0x0E, 2, inst,   0,   "mvi c,%1" },
  { 0x0F, 1, inst,   0,   "rrc" },
  { 0x10, 2, unused, 0,   0 },
  { 0x11, 3, inst,   0,   "lxi d,%2" },
  { 0x12, 1, inst,   0,   "stax d" },
  { 0x13, 1, inst,   0,   "inx d" },
  { 0x14, 1, inst,   0,   "inr d" },
  { 0x15, 1, inst,   0,   "dcr d" },
  { 0x16, 2, inst,   0,   "mvi d,%1" },
  { 0x17, 1, inst,   0,   "ral" },
  { 0x18, 2, unused, 0,   0 },
  { 0x19, 1, inst,   0,   "dad d" },
  { 0x1A, 1, inst,   0,   "ldax d" },
  { 0x1B, 1, inst,   0,   "dcx d" },
  { 0x1C, 1, inst,   0,   "inr e" },
  { 0x1D, 1, inst,   0,   "dcr e" },
  { 0x1E, 2, inst,   0,   "mvi e,%1" },
  { 0x1F, 1, inst,   0,   "rar" },
  { 0x20, 1, inst,   I85, "rim" },
  { 0x21, 3, inst,   0,   "lxi h,%2" },
  { 0x22, 3, instw,  0,   "shld %a" },
  { 0x23, 1, inst,   0,   "inx h" },
  { 0x24, 1, inst,   0,   "inr h" },
  { 0x25, 1, inst,   0,   "dcr h" },
  { 0x26, 2, inst,   0,   "mvi h,%1" },
  { 0x27, 1, inst,   0,   "daa" },
  { 0x28, 2, unused, 0,   0 },
  { 0x29, 1, inst,   0,   "dad h" },
  { 0x2A, 3, instw,  0,   "lhld %a" },
  { 0x2B, 1, inst,   0,   "dcx h" },
  { 0x2C, 1, inst,   0,   "inr l" },
  { 0x2D, 1, inst,   0,   "dcr l" },
  { 0x2E, 2, inst,   0,   "mvi l,%1" },
  { 0x2F, 1, inst,   0,   "cma" },
  { 0x30, 1, inst,   I85, "sim" },
  { 0x31, 3, inst,   0,   "lxi sp,%2" },
  { 0x32, 3, instb,  0,   "sta %a" },
  { 0x33, 1, inst,   0,   "inx sp" },
  { 0x34, 1, inst,   0,   "inr m" },
  { 0x35, 1, inst,   0,   "dcr m" },
  { 0x36, 2, inst,   0,   "mvi m,%1" },
  { 0x37, 1, inst,   0,   "stc" },
  { 0x38, 2, unused, 0,   0 },
  { 0x39, 1, inst,   0,   "dad sp" },
  { 0x3A, 3, instb,  0,   "lda %a" },
  { 0x3B, 1, inst,   0,   "dcr sp" },
  { 0x3C, 1, inst,   0,   "inr a" },
  { 0x3D, 1, inst,   0,   "dcr a" },
  { 0x3E, 2, inst,   0,   "mvi a,%1" },
  { 0x3F, 1, inst,   0,   "cmc" },
  { 0x40, 1, inst,   0,   "mov b,b" },
  { 0x41, 1, inst,   0,   "mov b,c" },
  { 0x42, 1, inst,   0,   "mov b,d" },
  { 0x43, 1, inst,   0,   "mov b,e" },
  { 0x44, 1, inst,   0,   "mov b,h" },
  { 0x45, 1, inst,   0,   "mov b,l" },
  { 0x46, 1, inst,   0,   "mov b,m" },
  { 0x47, 1, inst,   0,   "mov b,a" },
  { 0x48, 1, inst,   0,   "mov c,b" },
  { 0x49, 1, inst,   0,   "mov c,c" },
  { 0x4A, 1, inst,   0,   "mov c,d" },
  { 0x4B, 1, inst,   0,   "mov c,e" },
  { 0x4C, 1, inst,   0,   "mov c,h" },
  { 0x4D, 1, inst,   0,   "mov c,l" },
  { 0x4E, 1, inst,   0,   "mov c,m" },
  { 0x4F, 1, inst,   0,   "mov c,a" },
  { 0x50, 1, inst,   0,   "mov d,b" },
  { 0x51, 1, inst,   0,   "mov d,c" },
  { 0x52, 1, inst,   0,   "mov d,d" },
  { 0x53, 1, inst,   0,   "mov d,e" },
  { 0x54, 1, inst,   0,   "mov d,h" },
  { 0x55, 1, inst,   0,   "mov d,l" },
  { 0x56, 1, inst,   0,   "mov d,m" },
  { 0x57, 1, inst,   0,   "mov d,a" },
  { 0x58, 1, inst,   0,   "mov e,b" },
  { 0x59, 1, inst,   0,   "mov e,c" },
  { 0x5A, 1, inst,   0,   "mov e,d" },
  { 0x5B, 1, inst,   0,   "mov e,e" },
  { 0x5C, 1, inst,   0,   "mov e,h" },
  { 0x5D, 1, inst,   0,   "mov e,l" },
  { 0x5E, 1, inst,   0,   "mov e,m" },
  { 0x5F, 1, inst,   0,   "mov e,a" },
  { 0x60, 1, inst,   0,   "mov h,b" },
  { 0x61, 1, inst,   0,   "mov h,c" },
  { 0x62, 1, inst,   0,   "mov h,d" },
  { 0x63, 1, inst,   0,   "mov h,e" },
  { 0x64, 1, inst,   0,   "mov h,h" },
  { 0x65, 1, inst,   0,   "mov h,l" },
  { 0x66, 1, inst,   0,   "mov h,m" },
  { 0x67, 1, inst,   0,   "mov h,a" },
  { 0x68, 1, inst,   0,   "mov l,b" },
  { 0x69, 1, inst,   0,   "mov l,c" },
  { 0x6A, 1, inst,   0,   "mov l,d" },
  { 0x6B, 1, inst,   0,   "mov l,e" },
  { 0x6C, 1, inst,   0,   "mov l,h" },
  { 0x6D, 1, inst,   0,   "mov l,l" },
  { 0x6E, 1, inst,   0,   "mov l,m" },
  { 0x6F, 1, inst,   0,   "mov l,a" },
  { 0x70, 1, inst,   0,   "mov m,b" },
  { 0x71, 1, inst,   0,   "mov m,c" },
  { 0x72, 1, inst,   0,   "mov m,d" },
  { 0x73, 1, inst,   0,   "mov m,e" 

Re: Unknown 8085 opcodes

[Lars Brinkhoff]

Mouse writes:
> I built a disassembler years ago to pick apart captured malware.  By
> now it handles about a dozen ISAs.  While 8080 and 8085 are not on the
> list, Z-80 is; adding 8080 would be a relatively simple thing.

Isn't 8080 just a subset of Z80?

> if someone can point me to 8080/8085 machine language documentation
> that would save me some searching

Try this:

https://github.com/larsbrinkhoff/awesome-cpus

Re: Unknown 8085 opcodes

[dwight]

Sorry Chuck

It was not you I was talking about. It was the original thinking that a 8085 
disassembler would make sense out of the original 8041 code.

Maybe I'm confused but I believe the code in question was the 8041.

Dwight



From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Chuck Guzis 
<ccl...@sydex.com>
Sent: Wednesday, January 11, 2017 9:44:27 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Unknown 8085 opcodes

On 01/11/2017 08:50 PM, dwight wrote:
> Even so, he said the code was
>
> for the 8741. It is not 8085!
>

In the interest of minimizing clutter, I didn't quote all of Mouse's
message:
--
I built a disassembler years ago to pick apart captured malware.  By
now it handles about a dozen ISAs.  While 8080 and 8085 are not on the
list, Z-80 is; adding 8080 would be a relatively simple thing.  I've
added that to my to-do list; if someone can point me to 8080/8085
machine language documentation that would save me some searching (which
is something I'm not much good at in these days when frickin'
*everything* is shoehorned into a Web page).
---

My post was right on topic.

--Chuck

Re: Unknown 8085 opcodes

[Lawrence Wilkinson]

On 11/01/17 22:20, Adrian Graham wrote:


I've got some good results with the dz80 disassembler on linux, it actually
does a decent job of recognising the text and shows it as such:

;
 db'Telephone Details'; 1799
 dwX0401; 17aa   01 04  ..
 dwX0805; 17ac   05 08  ..
;
 db17h; 17ae .
 db'Select number to change'; 17af
 dwX0601; 17c6   01 06  ..
 dwX0800; 17c8   00 08  ..
;
 db1bh,0dh; 17ca ..
 db'1   PBX Ext.   Direct Line'; 17cc
 dwX0901; 17e6   01 09  ..
 dwX0800; 17e8   00 08  ..
 dwX0d1a; 17ea   1a 0d  ..
 dwX2032; 17ec   32 20  2
;
 db20h,6; 17ee  .
 db'Pre-Dial Pause (secs)'; 17f0
 db1; 1805 .

Thanks all!


The byte before each string is the length (17h = 23 = 'Select ...change').

In the case of the PBX Ext string the 0dh is the first character, and 
the length is 1bh / 27.


The Pre-Dial string is length 1ah / 26 but I don't know what the 6 means 
(maybe some special character.)


--
Lawrence Wilkinson  lawrence at ljw.me.uk
The IBM 360/30 page   http://www.ljw.me.uk/ibm360

Re: Unknown 8085 opcodes

[dwight]

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-boun...@classiccmp.org> on behalf of Chuck Guzis 
<ccl...@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

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/11/2017 08:50 PM, dwight wrote:
> Even so, he said the code was
> 
> for the 8741. It is not 8085!
> 

In the interest of minimizing clutter, I didn't quote all of Mouse's
message:
--
I built a disassembler years ago to pick apart captured malware.  By
now it handles about a dozen ISAs.  While 8080 and 8085 are not on the
list, Z-80 is; adding 8080 would be a relatively simple thing.  I've
added that to my to-do list; if someone can point me to 8080/8085
machine language documentation that would save me some searching (which
is something I'm not much good at in these days when frickin'
*everything* is shoehorned into a Web page).
---

My post was right on topic.

--Chuck

Re: Unknown 8085 opcodes

[dwight]

Even so, he said the code was

for the 8741. It is not 8085!

Dwight


From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Chuck Guzis 
<ccl...@sydex.com>
Sent: Wednesday, January 11, 2017 7:12:43 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Unknown 8085 opcodes

On 01/11/2017 06:45 PM, Mouse wrote:

> In case anyone is interested, I export it via git.  The thing to
> clone is git://git.rodents-montreal.org/Mouse/disas, though it hasn't
> had much testing off my systems and thus probably contains
> localisms.

Does your disassembler do flow analysis?

At any rate, the best reference for "undocumented" 8085 instructions is
the Tundra/Calmos datasheet:

http://www.datasheetarchive.com/dlmain/6365531e98b38dadd61a8399fa30d8f0c9a0aa/M/CA80C85

The other instructions follow the 8080.

--Chuck

Re: Unknown 8085 opcodes

[Warner Losh]

On Wed, Jan 11, 2017 at 8:33 PM, Jon Elson  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
>> 
>> wrote:
>>
>>> Example 8085 code fragment:
>>>
>>> 3440   1792 09  DAD B
>>> 3441   1793 01 01 08LXI 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 05LXI 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
>
>
>

Re: Unknown 8085 opcodes

[Jon Elson]

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 
wrote:


Example 8085 code fragment:

3440   1792 09  DAD B
3441   1793 01 01 08LXI 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 05LXI 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

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/11/2017 06:45 PM, Mouse wrote:

> In case anyone is interested, I export it via git.  The thing to
> clone is git://git.rodents-montreal.org/Mouse/disas, though it hasn't
> had much testing off my systems and thus probably contains
> localisms.

Does your disassembler do flow analysis?

At any rate, the best reference for "undocumented" 8085 instructions is
the Tundra/Calmos datasheet:

http://www.datasheetarchive.com/dlmain/6365531e98b38dadd61a8399fa30d8f0c9a0aa/M/CA80C85

The other instructions follow the 8080.

--Chuck

Re: Unknown 8085 opcodes

[Mouse]

> Good list there, the onlinedebugger looked the most promising but it
> doesn't do 8080/8085 either.

I built a disassembler years ago to pick apart captured malware.  By
now it handles about a dozen ISAs.  While 8080 and 8085 are not on the
list, Z-80 is; adding 8080 would be a relatively simple thing.  I've
added that to my to-do list; if someone can point me to 8080/8085
machine language documentation that would save me some searching (which
is something I'm not much good at in these days when frickin'
*everything* is shoehorned into a Web page).

In case anyone is interested, I export it via git.  The thing to clone
is git://git.rodents-montreal.org/Mouse/disas, though it hasn't had
much testing off my systems and thus probably contains localisms.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Unknown 8085 opcodes

[Chuck Guzis]

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

Re: Unknown 8085 opcodes

[allison]

On 1/11/17 12:19 PM, Charles Anthony wrote:

On Wed, Jan 11, 2017 at 9:10 AM, Adrian Graham 
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

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

Re: Unknown 8085 opcodes

[Adrian Graham]

On 11/01/2017 19:24, "Al Kossow"  wrote:

> 
> since it's been brought up, and your forgot to mention IDA is a commercial
> product
> 
> http://reverseengineering.stackexchange.com/questions/1817/is-there-any-disass
> embler-to-rival-ida-pro
> 
> 
> On 1/11/17 11:08 AM, shad wrote:
>> try to  analyze your dump with IDA
>> Disassembler.

I've got some good results with the dz80 disassembler on linux, it actually
does a decent job of recognising the text and shows it as such:

;
db'Telephone Details'; 1799
dwX0401; 17aa   01 04  ..
dwX0805; 17ac   05 08  ..
;
db17h; 17ae .
db'Select number to change'; 17af
dwX0601; 17c6   01 06  ..
dwX0800; 17c8   00 08  ..
;
db1bh,0dh; 17ca ..
db'1   PBX Ext.   Direct Line'; 17cc
dwX0901; 17e6   01 09  ..
dwX0800; 17e8   00 08  ..
dwX0d1a; 17ea   1a 0d  ..
dwX2032; 17ec   32 20  2
;
db20h,6; 17ee  .
db'Pre-Dial Pause (secs)'; 17f0
db1; 1805 .

Thanks all!

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Unknown 8085 opcodes

[Henrik Stahl]

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 08LXI 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 05LXI 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!

Re: Unknown 8085 opcodes

[Adrian Graham]

On 11/01/2017 19:24, "Al Kossow"  wrote:

> 
> since it's been brought up, and your forgot to mention IDA is a commercial
> product
> 
> http://reverseengineering.stackexchange.com/questions/1817/is-there-any-disass
> embler-to-rival-ida-pro

Good list there, the onlinedebugger looked the most promising but it doesn't
do 8080/8085 either. Thanks though!

> 
> 
> On 1/11/17 11:08 AM, shad wrote:
>> try to  analyze your dump with IDA
>> Disassembler.
> 

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Unknown 8085 opcodes

[Chuck Guzis]

On 01/11/2017 09:34 AM, Fred Cisin wrote:
> Looks more like data, than code.

Indeed--the giveaway for x80 hackers is the string of seemingly
nonsensical register moves--although I've seen "trick" code that does
employ them to actually execute someone's name...

--Chuck

Re: Unknown 8085 opcodes

[Adrian Graham]

On 11/01/2017 19:08, "shad"  wrote:

> Hello Adrian,
> not sure if 8085 is supported, but try to  analyze your dump with IDA
> Disassembler.
> It's really amazing in analyzing the code, and reconstruct automatically,
> or with small effort, a readable trace of functions jumps, strings,
> symbols, etc

Hi Andrea,

The starter/full versions support 8085 but the freeware and eval versions
are 80x86 only, thanks for the idea though.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Unknown 8085 opcodes

[jim stephens]

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

Re: Unknown 8085 opcodes

[shadoooo]

Hello Adrian,
not sure if 8085 is supported, but try to  analyze your dump with IDA
Disassembler.
It's really amazing in analyzing the code, and reconstruct automatically,
or with small effort, a readable trace of functions jumps, strings,
symbols, etc

Andrea

Re: Unknown 8085 opcodes

[Adrian Graham]

On 11/01/2017 17:23, "Tony Duell"  wrote:

>> 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?

Indeed, this is the same fragment:

1797 : 12 0D 54 65 6C 65 70 68"  Teleph"db012H,
00DH, 054H, 065H, 06CH, 065H, 070H, 068H
179F : 6F 6E 65 20 44 65 74 61"one Deta"db06FH,
06EH, 065H, 020H, 044H, 065H, 074H, 061H
17A7 : 69 6C 73 01 04 05 08 17"ils "db069H,
06CH, 073H, 001H, 004H, 005H, 008H, 017H
17AF : 53 65 6C 65 63 74 20 6E"Select n"db053H,
065H, 06CH, 065H, 063H, 074H, 020H, 06EH
17B7 : 75 6D 62 65 72 20 74 6F"umber to"db075H,
06DH, 062H, 065H, 072H, 020H, 074H, 06FH
17BF : 20 63 68 61 6E 67 65 01" change "db020H,
063H, 068H, 061H, 06EH, 067H, 065H, 001H
17C7 : 06 00 08 1B 0D 31 20 20" 1  "db006H,
000H, 008H, 01BH, 00DH, 031H, 020H, 020H
17CF : 20 50 42 58 20 45 78 74" PBX Ext"db020H,
050H, 042H, 058H, 020H, 045H, 078H, 074H
17D7 : 2E 20 20 20 44 69 72 65".   Dire"db02EH,
020H, 020H, 020H, 044H, 069H, 072H, 065H
17DF : 63 74 20 4C 69 6E 65 01"ct Line "db063H,
074H, 020H, 04CH, 069H, 06EH, 065H, 001H
17E7 : 09 00 08 1A 0D 32 20 20" 2  "db009H,
000H, 008H, 01AH, 00DH, 032H, 020H, 020H
17EF : 06 50 72 65 2D 44 69 61" Pre-Dia"db006H,
050H, 072H, 065H, 02DH, 044H, 069H, 061H
17F7 : 6C 20 50 61 75 73 65 20"l Pause "db06CH,
020H, 050H, 061H, 075H, 073H, 065H, 020H
17FF : 28 73 65 63 73 29 01 0C"(secs)  "db028H,
073H, 065H, 063H, 073H, 029H, 001H, 00CH
1807 : 01 08 25 0D 20 20 20 31"  %1"db001H,
008H, 025H, 00DH, 020H, 020H, 020H, 031H
180F : 2E 35 20 20 20 32 2E 30".5   2.0"db02EH,
035H, 020H, 020H, 020H, 032H, 02EH, 030H
1817 : 20 20 20 32 2E 35 20 20"   2.5  "db020H,
020H, 020H, 032H, 02EH, 035H, 020H, 020H
181F : 20 33 2E 30 20 20 20 33" 3.0   3"db020H,
033H, 02EH, 030H, 020H, 020H, 020H, 033H
1827 : 2E 35 20 20 20 34 2E 30".5   4.0"db02EH,
035H, 020H, 020H, 020H, 034H, 02EH, 030H
182F : 01 12 00 08 22 0D 34 20"" 4 "db001H,
012H, 000H, 008H, 022H, 00DH, 034H, 020H
1837 : 20 06 50 42 58 2F 4F 75"  PBX/Ou"db020H,
006H, 050H, 042H, 058H, 02FH, 04FH, 075H
183F : 74 73 69 64 65 20 4C 69"tside Li"db074H,
073H, 069H, 064H, 065H, 020H, 04CH, 069H
1847 : 6E 65 20 50 61 75 73 65"ne Pause"db06EH,
065H, 020H, 050H, 061H, 075H, 073H, 065H
184F : 20 28 73 65 63 73 29 01" (secs) "db020H,
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?

Re: Unknown 8085 opcodes

[dwight]

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-boun...@classiccmp.org> on behalf of Tony Duell 
<ard.p850...@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 <ci...@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

Re: Unknown 8085 opcodes

[Adrian Graham]

On 11/01/2017 17:49, "Fred Cisin"  wrote:

> .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, . . .

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?

Re: Unknown 8085 opcodes

[Al Kossow]

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?
>

Re: Unknown 8085 opcodes

[Tony Duell]

On Wed, Jan 11, 2017 at 6:01 PM, Fred Cisin  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

Re: Unknown 8085 opcodes

[Fred Cisin]

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.

Re: Unknown 8085 opcodes

[Fred Cisin]

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, . . .

Re: Unknown 8085 opcodes

[Hayden Kroepfl]

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 
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  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 
> > 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 <
> > binarydinosa...@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 08LXI 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 

Re: Unknown 8085 opcodes

[Fred Cisin]

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 08LXI 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 05LXI 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

Re: Unknown 8085 opcodes

[Adrian Graham]

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  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 
> 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 <
> binarydinosa...@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 08LXI 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 05LXI 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
> >>
> >
> >
>



-- 
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk

Re: Unknown 8085 opcodes

[Tony Duell]

On Wed, Jan 11, 2017 at 5:10 PM, Adrian Graham
 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 08LXI 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 05LXI 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

Re: Unknown 8085 opcodes

[Hayden Kroepfl]

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 
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  > 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 08LXI 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 05LXI 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
>>
>
>

Re: Unknown 8085 opcodes

[Charles Anthony]

On Wed, Jan 11, 2017 at 9:10 AM, Adrian Graham 
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

Re: Unknown 8085 opcodes

[Hayden Kroepfl]

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 
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 08LXI 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 05LXI 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
>

Unknown 8085 opcodes

[Adrian Graham]

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 08LXI 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 05LXI 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