I'm helping reverse engineer a small embedded device. We've successfully extracted some code fragments, which have been identified as 8051 machine code. However, it's using some kind of instruction set extension using a 0xa5 opcode prefix. I know this is used by several different instruction set extensions, so I need to look these up and see which ones make sense.

So far I've found and ruled out:

  • Philips/NXP 51MX
  • Intel MCS-251

What others are there?

For interest value, here are some of the extended instructions:

  0023 A5               DB 85h  ; illegal opcode
  0024 6130             AJMP L0002

  005F A5               DB 85h  ; illegal opcode
  0060 817C             AJMP L0010

  0065 A5               DB 85h  ; illegal opcode
  0066 00               NOP

  0068 A5               DB 85h  ; illegal opcode
  0069 A674             MOV @R0, 74h

2 Answers 2


Check out bunnie’s work on SD card controllers. One family they looked at (AX211) was actually using a5 for extended opcodes.

  • It's not an AX211, but this looks extremely like the AX208, complete with the ability to run code out of RAM. There seem to be a whole family of these with very similar features to the one we've got here, so that looks very plausible. Unfortunately the AX208 datasheet doesn't actually contain the instruction encoding so I can't tell for sure! Sep 18, 2021 at 21:58
  • Also, if anyone knows of any more 8051 extensions, I'd love to know about them. Thanks! Sep 18, 2021 at 21:58
  • The page I linked has some details on the instructions although they don’t seem to match your examples. Maybe you can inject a debugger stub like they did and observe how the cpu state changes when these opcodes are executed.
    – Igor Skochinsky
    Sep 19, 2021 at 0:42
  • Apparently I wasn't looking closely enough; I don't think it's an AXC51 core. The disassembled code looks fine from a distance but when you look more closely it doesn't appear to make a lot of sense. Yes, this is probably going to need a debugger stub. Sep 20, 2021 at 19:10

The CPU actually turned out to be an AC1082 from JL: it's intended for the MP3 player market. It's an 8051 clone with (I think) 8 kB of RAM and a combined XDATA/CODE address space, allowing it to run code out of RAM; plus, it's got a really good set of 16-bit extension instructions which include direct XDATA access using an address in a register pair, so you don't have to indirect through DPTR. It looks like a really interesting thing.

It's not documented as such that anyone can find, but here is an SDK for it. It's got macros for generating the extended instructions, but there's no documentation on what they actually do and some of them aren't obvious. I'm still trying to get my hands on hardware to actually do some testing with.

You can find the reverse engineering effort in the Reddit thread here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.