80c535 disassembly

[alfa166]

Hello,

I'm trying to understand my radio, a Becker BE2560, as used in the alfa romeo 166.
The radio part uses an 80c535 from Siemens, which should be 8051 compatible.
I've dumped the eprom, and cannot make any sense of the program.

The first 17 bytes are:

C0 D0 70 03 E9 80 08 50 03 29 80 03 C9 C3 99 C3 22

//
                             // CODE
                             // CODE:0000-CODE:1fff
                             //
                             *************************************************************
                             *                            FUNCTION                        
                             *************************************************************
                             undefined  FUN_CODE_0000 ()
             undefined         ACC:1          <RETURN>
                             FUN_CODE_0000
       CODE:0000  c0  d0           PUSH       PSW
       CODE:0002  70  03           JNZ        LAB_CODE_0007
       CODE:0004  e9              MOV        A,R1
       CODE:0005  80  08           SJMP       LAB_CODE_000f
                             LAB_CODE_0007                                   XREF[1]:     CODE:0002 (j)  
       CODE:0007  50  03           JNC        LAB_CODE_000c
       CODE:0009  29              ADD        A,R1
       CODE:000a  80  03           SJMP       LAB_CODE_000f
                             LAB_CODE_000c                                   XREF[1]:     CODE:0007 (j)  
       CODE:000c  c9              XCH        A,R1
       CODE:000d  c3              CLR        CY
       CODE:000e  99              SUBB       A,R1
                             LAB_CODE_000f                                   XREF[2]:     CODE:0005 (j) ,  CODE:000a (j)  
       CODE:000f  c3              CLR        CY
       CODE:0010  13              RRC        A
       CODE:0011  93              MOVC       A,@A+DPTR
       CODE:0012  f5  f0           MOV        B,A
       CODE:0014  d0  d0           POP        PSW
                             *************************************************************
                             *                            FUNCTION                         
                             *************************************************************
                             undefined  FUN_CODE_0016 ()
             undefined         ACC:1          <RETURN>
                             FUN_CODE_0016
       CODE:0016  22              RET

Which makes no sense, especially not since the 17th byte is 0x22, i.e. "RET".

An 8051 (or derivative) starts its program at 0x0000, so where does it return to?

 

[Nigel Goodwin]

Is it a separate EPROM?, because if it is, the address lines 'might' be connected wrongly, this was commonly done to simplify the PCB layout on various items over the years. It doesn't matter which way round you connect the address lines, because each combination still refers to a single individual byte in the memory.

Obviously, the EPROM has to be programmed in that same order - but if you read it back in normal addressing order, it makes no sense.

Just a thought?.

But as it's in a radio, it probably hasn't got a separate EPROM?, in which case it could be code protected in some way - it would be unusual to be able to read the code from a commercial device.

 

[Papabravo]

It kind of looks like an interpreter or threaded code executor similar to ones I have seen. The MOVC instruction is a big clue. It might be handy to dig deeper to see if there is any other stuff that makes sense. If I were you I'd look for all of the single byte return instructions, work backwards to find the entry points. Then look for call instructions to those entry points. If you fail to find anything that looks like that it might be a clue that there is an interpreter or threaded code execution machine going on.

You also want to focus on interrupt routine entry points. Good coding practice will have error safe recovery for unexpected interrupts that are not being used. Actual interrupt code as well as EI and DI instructions (or their equivalents) will be useful things to find.

Here are the interrupt vector addresses for the basic 8051. Your variant may or may not have others.

 

[alfa166]

I've confirmed A7..A0 and A12..A8 from the eprom are directly wired to the 80c535.

A7..A0 through an octal latch, because of von Neumann architecture, and A12..A8 directly.

Therefore, and since this is an 80C535 with no internal rom, it doesn't make sense.

 

[alfa166]

Might it be I've read the EPROM wrong, LSB as opposed to MSB?

 

[alfa166]

It kind of looks like an interpreter or threaded code executor similar to ones I have seen. The MOVC instruction is a big clue. It might be handy to dig deeper to see if there is any other stuff that makes sense. If I were you I'd look for all of the single byte return instructions, work backwards to find the entry points. Then look for call instructions to those entry points. If you fail to find anything that looks like that it might be a clue that there is an interpreter or threaded code execution machine going on.

You also want to focus on interrupt routine entry points. Good coding practice will have error safe recovery for unexpected interrupts that are not being used. Actual interrupt code as well as EI and DI instructions (or their equivalents) will be useful things to find.

Here are the interrupt vector addresses for the basic 8051. Your variant may or may not have others.

View attachment 140914

There a two ways to interpret this:
1. the interrupt address holds a vector, i.e. an address to jump to
2. the interrupt routine is executed from the address jumped to.

The documentation isn't all to clear ..

 

[Papabravo]

In the case of the 8051 architecture, the intention of the original designers was that there should be actual code located at the vector addresses. That is partly why they are not at contiguous and adjacent locations. It is also consistent with the 8080/8085 architecture which was contemporaneous with the 8051 and it's predecessor the 8048/8041

 

[alfa166]

Thank you for that pearl of wisdom.

The address 0x0003 is jumped to when external INT1 occurs, supposing this is used, the code makes no sense.
supposing INT0 is not used, the code makes no sense either.

Could you please reply to the question itself, instead of mimicking chatgpt?

Address 0x0000 should be something like a jump.

 

[Papabravo]

Thank you for that pearl of wisdom.

The address 0x0003 is jumped to when external INT1 occurs, supposing this is used, the code makes no sense.
supposing INT0 is not used, the code makes no sense either.

Could you please reply to the question itself, instead of mimicking chatgpt?

Address 0x0000 should be something like a jump.

No need to get pissy with me I am trying to help you. If the code at the interrupt locations is not reasonable for the use of interrupts, then interrupts within the range of code we are looking at are probably not ever being enabled. This allows other code to occupy the space. Keep up the disassembly until you have covered the range of interrupts. The actual range may be particular to the "clone" of the original 8051 you are working with. If you would prefer to do this on your own, then be my guest.

 

[alfa166]

If my reaction seemed "pissy", it is because your answer allowed it.
I'm sorry that you interpreted my response in such a manner, please allow me to furnish you with more information.

The code I am showing is a dump from the eprom connected to the 80c535.

I am only only showing the first 0x17 bytes, because it is my understanding that the PC is reset to those values, hence is starts executing from those "vectors".

I have confirmed the 8kb eprom to be connected to the 80c535 in a von Neumann manner, i.e through a latch.
(P0 is connected through a latch to A7..0 (and thus D7..0) )
A12..8 are connected to P2.

Therefore, I assume, when powered up, the processor starts executing from 0x0000.

Evaluating the code however does not make sense.

I'm only trying to make sense of it.

It is not my intention to belittle anyone, but "IT-answers", the like of: "Have you tried to turn it off and on again?", might yield a "pissy-like" response.

I am the "supervisor" novell servers used to call for.



I hope you understand.

 

[Pommie]

Are you sure the address and data lines are connected in the correct order?

Mike.

 

[Papabravo]

If my reaction seemed "pissy", it is because your answer allowed it.
I'm sorry that you interpreted my response in such a manner, please allow me to furnish you with more information.

The code I am showing is a dump from the eprom connected to the 80c535.

I am only only showing the first 0x17 bytes, because it is my understanding that the PC is reset to those values, hence is starts executing from those "vectors".

I have confirmed the 8kb eprom to be connected to the 80c535 in a von Neumann manner, i.e through a latch.
(P0 is connected through a latch to A7..0 (and thus D7..0) )
A12..8 are connected to P2.

Therefore, I assume, when powered up, the processor starts executing from 0x0000.

Evaluating the code however does not make sense.

I'm only trying to make sense of it.

It is not my intention to belittle anyone, but "IT-answers", the like of: "Have you tried to turn it off and on again?", might yield a "pissy-like" response.

I am the "supervisor" novell servers used to call for.



I hope you understand.

Fine then you can figure this one out on your own. I'm outta this thread.

 

[rjenkinsgb]

I've dumped the eprom, and cannot make any sense of the program.

The first 17 bytes are:

Please provide a bit more code, eg. 32 bytes or so; both the raw EPROM dump and disassembly?

There is something screwed up in the original question:

You have 17 (decimal) bytes in the line of values.
And up to $16 (hex) in the disassembly.

And the content of the two does not match.

eg. The last byte in the line is $22 which would be at address $10.

Address $10 in the disassembly is $13 ??

 

[Ian Rogers]

Remember that the 8051 can execute external code, but as this is a 535 there is no internal Rom.

What dissasembler are you using as the first two bytes are the reset vector, It looks like you are disassembling relocatable and not direct.. As JRW said post a few lines and I'll disassemble here.. Also, I'm also surprised you were able to dump code..

 

[Nigel Goodwin]

Also, I'm also surprised you were able to dump code..

If it's an external EPROM then you simply read it in an EPROM programmer, they aren't protected or anything.

 

[Ian Rogers]

If it's an external EPROM then you simply read it in an EPROM programmer, they aren't protected or anything.

Yeah but it wouldn't be through hole surely??

 

[Nigel Goodwin]

Yeah but it wouldn't be through hole surely??

If it's not through hole, and socketed, why use an EPROM at all? - just use a device with built-in memory. The car dates back to 1996 - but I'm quite bemused to hear of any car radio using external EPROM anyway, through hole or otherwise.

My only experience of it in TV's was one particular Grundig model - when it first came out - the (presumably) mask programmed processor wasn't intiially available, so they made a small daughter board with a non-memory processor and EPROM on it (which were off the shelf parts) and plugged that in the socket for the mask programmed processor.

 

[alfa166]

Hello, sorry for this late reply, work interfered with hobby.
(I'm sure you can relate.)

Find below lots of bytes:
C0 D0 70 03 E9 80 08 50 03 29 80 03 C9 C3 99 C3 13 93 F5 F0 D0 D0 22 90 04 FD E0 F5 F0 B4 25 00 C0 D0 C3 94 24 D0 D0 50 13 E5 F0 B4 08 00 40 0E 64 08 60 04 74 09 80 06 E5 F0 80 02 24 09 70 01 04 FA FC 12 BF BC E5 F0 B4 08 00 40 16 64 08 60 12 E5 F0 B4 24 00 C0 D0 C3 94 08 D0 D0 40 06 74 1C 80 02 74 01 C0 E0 E4 F8 FD FA FC 79 13 E3 B4 1D 00 40 02 74 1C 79 0E 90 BA 23 12 BF FE 50 06 60 06 AA F0 80 02 AC F0 79 12 E3 B4 1C 00 40 02 74 1C 79 0E 90 BA 1B 12 BF FE 40 05 60 04 F8 80 01 FD D0 E0 F5 F0 EC 2D 12 BF F0 C0 F0 C0 E0 90 04 F9 E0 54 30 C4 F5 F0 D0 E0 25 F0 D0 F0 90 05 07 F0 EA 2D 12 BF F0 C0 F0 C0 E0 90 04 F9 E0 54 03 F5 F0 D0 E0 25 F0 D0 F0 90 05 06 F0 EC 28 12 BF F0 C0 F0 C0 E0 90 04 F9 E0 54 C0 23 23 F5 F0 D0 E0 25 F0 D0 F0 90 05 05 F0 EA 28 12 BF F0 C0 F0 C0 E0 90 04 F9 E0 54 0C 03 03 F5 F0 D0 E0 25 F0 D0 F0 90 05 04 F0 90 05 0E 74 04 F0 7C 1A 78 32 79 10 EC FF 12 9D 05 EB 54 FC F8 EF 54 1F FD 90 05 0E E0 90 05 04 14 25 82 F5 82 E4 35 83 F5 83 E0 FF E5 54 60 01 EF 7F 20 C3 CF 9F 50 03 75 07 2C EF 90 B9 DB 12 BE 16 E4 93 48 FF A3 E4 93 4D FE 79 00 EC FB 78 32 12 9D 7F 1C 90 05 0E E0 64 01 60 05 E0 14 F0 80 A6 22 90 00 23 E0 25 54 F5 F0 C3 94 99 40 03 75 F0 00 C0 F0 90 05 D3 E0 04 C5 F0 C3 95 F0 D0 F0 40 03 E0 F5 F0 AC F0 75 F0 00 78 11 E2 64 01 60 70 E2 64 06 60 6B 78 16 E2 20 E0 3D 54 01 F8 90 05 0B E0 68 60 25 74 02 12 C4 32 EC 12 BB 5D F5 F0 12 6A C0 E0 12 BB 3A 25 F0 F8 90 05 0C F0 90 05 09 E0 68 60 3B E0 04

 

[alfa166]

What makes me wonder, is that 0x0003 and 0x000b are the places where IE0 and TI0 are located.

The way I understand the manual, the PC is pointed to these addresses, instead of loading a vector.

But suppose IE0 was used, than jumping to 0x0003 yields the same nonsense:

//
// CODE
// CODE:0000-CODE:1fff
//
*************************************************************
* FUNCTION
*************************************************************
undefined FUN_CODE_0000 ()
undefined ACC:1 <RETURN>
FUN_CODE_0000
CODE:0000 c0 ?? C0h
CODE:0001 d0 ?? D0h
CODE:0002 70 ?? 70h p
CODE:0003 03 RR A
CODE:0004 e9 MOV A,R1
CODE:0005 80 08 SJMP LAB_CODE_000f
CODE:0007 50 ?? 50h P
CODE:0008 03 ?? 03h
CODE:0009 29 ?? 29h )
CODE:000a 80 ?? 80h
CODE:000b 03 ?? 03h
CODE:000c c9 ?? C9h
CODE:000d c3 ?? C3h
CODE:000e 99 ?? 99h
LAB_CODE_000f XREF[1]: CODE:0005 (j)
CODE:000f c3 CLR CY
CODE:0010 13 RRC A
CODE:0011 93 MOVC A,@A+DPTR
CODE:0012 f5 f0 MOV B,A
CODE:0014 d0 d0 POP PSW
*************************************************************
* FUNCTION
*************************************************************
undefined FUN_CODE_0016 ()
undefined ACC:1 <RETURN>
FUN_CODE_0016
CODE:0016 22 RET

 

[alfa166]

Coming week I'll try to give a schematic how the eprom and cpu are connected.

BTW, it's just straighforward '90's stuff: socketed eprom and such.
I'll try to post a picture next post.

I'm using ghidra as disassembler, btw,