Old school 8080 EPROM disassembly - is it making sense?

[SilverSolder]

I dumped the firmware out of an Intel 8080A powered vintage Fluke DMM, and ran it through the DASMx disassembler to see if anything interesting can be gleaned...

I don't know anything about the 8080A, and suspect the program author might have used "tricks" that the disassembler struggles to understand.

If anyone with 8080 experience has a minute to look at the startup code and the first few jumps just to verify that the disassembler is not doing anything crazy, it would be highly appreciated!   

[retiredfeline]

The initial bytes are the various vectors, the first being the reset vector. If you note where it jumps to you can find the "main" program which will make more sense.

[SilverSolder]

The initial bytes are the various vectors, the first being the reset vector. If you note where it jumps to you can find the "main" program which will make more sense.

From what I have gleaned, the 1970's 8080A starts executing at address 0000, no vectors or anything like that?

[retiredfeline]

That's what I mean by a vector. 0 is the reset vector. After that come interrupt vectors.

[SilverSolder]

That's what I mean by a vector. 0 is the reset vector. After that come interrupt vectors.

My understanding is that 8080A starts executing at address 0000,  it does not have a reset vector - it literally starts with the program counter at zero and gets going from there and expects the program to start there.

[retiredfeline]

You can split hairs and call it what you want but the fact that there is only limited space 8 bytes IIRC before the next vector means that in practice a jump is usually put there.

[SilverSolder]

You can split hairs and call it what you want but the fact that there is only limited space 8 bytes IIRC before the next vector means that in practice a jump is usually put there.

OK understood.  It is just a bit unusual to me that it isn't a table of addresses, but actual code being executed in those locations...

The disassembler found the following code block at 0000, which does seem to jump elsewhere as you suggest.

Code: [Select]

;
org 00000H
;
L0000:
inx h
lxi h,0407CH
call L23A0
call L2188
pop h
lxi d,00004H
dad d
lxi d,X4066
mvi c,004H
call L1EA6
dcx h
call L1E9B
xra a
sta X41BC
ret


[retiredfeline]

OK understood.  It is just a bit unusual to me that it isn't a table of addresses, but actual code being executed in those locations...

It's simpler to implement in hardware, just mov PC,#0, instead of mov PC,(0), in pseudocode.

I would question whether what you have is a valid dump. The code at 0 (I was on a mobile before) looks too complicated for a reset entry. Are there any other EPROMs? Any trickery with address lines so that EPROM halves are swapped?

Maybe someone else has already dumped this DMM EPROM and you can just download it to compare?

[SilverSolder]

The code is spread across two EPROMS and verified good with another owner who also extracted the ROM.

 I just concatenated them in the order of their designators in the diagram...  u23 and u24

Let me try to disassemble the other one separately and see if that makes more sense, thanks for the hints -

[SilverSolder]

OK so starting with the other EPROM first, the disassembled code probably looks more like you are saying?

So the code at 0000 is the reset... and L0010: could be an interrupt "vector"?

Code: [Select]

; CPU: Intel 8080 (MCS-80/85 family)
;
;
;
org 00000H
;
mvi h,0C0H
mvi m,0FFH
jmp L02DB
;
db 0BBH, 0FBH, 0F5H, 03AH
db 00CH, 041H, 0C3H, 053H
db 00CH
;
L0010:
lxi d,X401A
mvi c,00CH
jmp L2214
;
db 0F5H, 0E5H, 0D5H, 0C5H
db 02AH, 012H, 041H, 0E9H
db 0F5H, 0E5H, 0D5H, 0C5H
db 02AH, 012H, 041H, 0E9H
db 0CDH, 0AEH, 013H, 02AH
db 0C8H, 041H, 0E9H, 0FFH
db 0F5H, 0E5H, 02AH, 010H
db 041H, 0E9H, 0FFH, 0FFH
;
L0038:
out 000H
di
lxi sp,04800H
call L0091
xra a
sta X41FD
call L2938
call L01ED
L004B:
call L0214
xra a
sta X41F8
call L34A3
call L087D
call L2201
call L0E62
call L0EAB
call L0962
call L0445
call L26E0
call L0500
lxi d,04069H
call L2848
call L16B8
call L007C
jmp L004B
;
L007C:
lda X41F8
ora a
rnz
dcr a
sta X41F8
out 048H
ret
;
L0088:
out 008H
ret
;
L008B:
out 000H
ret
;
L008E:
out 040H
ret
;
[...]


[retiredfeline]

Yes, looks like you should concatenate in the order U24 + U23. Also the code starting 38H is an interrupt service routine.

Also is there any way you can hint to DASM that there is code starting at 08H, 18H, and so forth? Those are the RST vectors. There may be code there that DASM is confusing for constants due to misalignment.

[SilverSolder]

Awesome, thanks for the help - talk about missing the forest due to the trees!

The disassembler output looks better now (attached).

[edit:] added full listing with hex offsets

[SilverSolder]

[...]
Also is there any way you can hint to DASM that there is code starting at 08H, 18H, and so forth? Those are the RST vectors. There may be code there that DASM is confusing for constants due to misalignment.

Yes, there are ways to do that, it seems.  I only have a couple of hours experience with DASMx so will have to experiment with that later.

Looks like a lot of work, if you want to understand everything going on there...

[retiredfeline]

BTW the fact that the 8-bit checksum ends in 00 suggests that there may be a self-test routine inside, or is a big coincidence, so if you decide to hack the code, you should maintain the checksum at 00 by altering some unused byte somewhere.

[abyrvalg]

Small recommendation: don’t loose the time learning DASMx, it’s workflow is slow and painful by design (run a pass, look at the output, edit symbol/code/data definition file, run again, observe the changes, repeat). Try Ghidra instead, it is “interactive” - you convert to code/data/rename right in the output window and see the results immediately (with nicely highlighted syntax), follow the jumps/calls in one click (instead of searching the text for label names) and much more.

[SilverSolder]

Small recommendation: don’t loose the time learning DASMx, it’s workflow is slow and painful by design (run a pass, look at the output, edit symbol/code/data definition file, run again, observe the changes, repeat). Try Ghidra instead, it is “interactive” - you convert to code/data/rename right in the output window and see the results immediately (with nicely highlighted syntax), follow the jumps/calls in one click (instead of searching the text for label names) and much more.

Thank you, I had never heard of it.  The Ghidra site does not mention 8080 as a supported processor, but does mention Z80.   Is Z80 "good enough for Australia" when the object code is 8080?

[abyrvalg]

Yes, Z80 is backward-compatible with 8080. There are minor changes in instructions naming style (i.e. all kinds of MOVx are just MOV now), but the binary encoding remains the same.

[retiredfeline]

[Thank you, I had never heard of it.  The Ghidra site does not mention 8080 as a supported processor, but does mention Z80.   Is Z80 "good enough for Australia" when the object code is 8080?

It seems the 8085 is supported. This has just a couple more instructions over the 8080, RIM and SIM. Use that. Unfortunately the Z80 turns some unused 8080 opcodes into valid Z80 instructions and the opcode stream might confuse the disassembler.

[floobydust]

Weird, that disassembly output op-code had me wondering what they are good for:
MOV B,B (8080) or LD B,B (Z80)

For disassembling the code, the hardest part is knowing when it's code verses a table. Once I know a subroutine, I search and replace the address with a text label i.e. OUT_LCD.
Eventually the code starts to make sense.

http://popolony2k.com.br/xtras/programming/asm/nemesis-lonestar/8080-z80-instruction-set.html

[JohnnyMalaria]

Instructions that seem to have no use such as LD B,B are useful if you want to create a carefully timed routine. e.g., LD B, B takes 4 cycles and requires one byte. Of course, NOP does the same. There are some others that can be used to clear/set certain bits in the flags register, too.

There's also the possibility that the code uses many of the undocumented instructions. Unless your disassembler is savvy enough, it may just dump them as dbs or, perhaps worse, meaningless instructions. I remember many years ago being delighted that the Z80A in my ZX Spectrum supported a large set of the undocumented instructions and had an extra set of registers (the details are lost to time).

[floobydust]

Gees I have three books on 8080 and Z-80 assembly language programming on my shelf. I looked and LD r,r' does nothing but waste time if the source and target register are the same.
Point is during disassembling of code, if the instructions seem to make no sense, then you're in data/a table or offsetting instructions by a byte.

[JohnnyMalaria]

A possible reason for things like LD B,B is in self-modifying code. Back when 1K RAM was a luxury, I can imagine a clever so-and-so purposely changing code during execution. e.g., replace opcode 0x40 with 0x41 and LD B,B becomes LD B,C. Life was simple without protected mode etc

[SilverSolder]

They are VERY space constrained, there is no "fat" in these EPROMS - I can hardly believe they managed to get all the features of this DMM into just 16K.  The disassembler found three jumps out of the EPROM address space...  presumably into RAM...   self modifying code?

Ignoring branch outside ROM to 40D8 at address 25A2
Ignoring branch outside ROM to 40E9 at address 25B9
Ignoring branch outside ROM to 40CB at address 2555

[WattsThat]

Yes, jumping to ram was a common trick. It was used for what I called dynamic dispatch, store a jump opcode followed by the address which could change dynamically based upon a parser state or whatever was changing.

Those weird tables that don’t make sense might be single byte jump tables, so long as the msb of of the address is the same, you only need to store the lsb offset which saves a byte for every entry. It was common to use everything below 100h for entry points, less of course the vector locations which you’ve already figured out.

There are all kinds of ways to squeeze space in micros, almost all the tricks make disassembly more difficult. But nothing can escape patience and persistence. The code is in front of you, all you have to do is make it give up its secrets. Yeah, easy, right?

PS: When looking for self-modifying code, it is best to have memorized jmp, ret and call opcodes. It was more common in systems running out of ram.

[SilverSolder]

Small recommendation: don’t loose the time learning DASMx, it’s workflow is slow and painful by design (run a pass, look at the output, edit symbol/code/data definition file, run again, observe the changes, repeat). Try Ghidra instead, it is “interactive” - you convert to code/data/rename right in the output window and see the results immediately (with nicely highlighted syntax), follow the jumps/calls in one click (instead of searching the text for label names) and much more.

Wow...  Ghidra is one amazing tool!  It seems to have turned the object code back into a C program...   not just a disassembler, but a decompiler!  Magic...  truly amazing.

There is a pretty big difference in the result when choosing 8085 vs Z80, I ended up preferring the 8085 output.

It is pretty obvious how the program starts, and ends up in what looks like its main loop!

Code: [Select]

void RST0(void)

{
  ushort uVar1;
  short sVar2;
  undefined in_L;
  undefined *puVar3;
  byte bVar4;
 
  *(undefined *)CONCAT11(0xc0,in_L) = 0xff;
  puVar3 = (undefined *)CONCAT11(0xe0,in_L);
  do {
    *puVar3 = 0xff;
    bVar4 = (char)((ushort)puVar3 >> 8) + 1;
    puVar3 = (undefined *)((ushort)puVar3 & 0xff | (ushort)bVar4 << 8);
  } while (bVar4 != 0);
  sVar2 = 0x452c;
  do {
    uVar1 = (ushort)sVar2 >> 8;
    bVar4 = (byte)sVar2;
    sVar2 = sVar2 + -1;
  } while ((byte)((byte)uVar1 | bVar4) != 0);
  disableMaskableInterrupts();
  _DAT_ram_47fe = 0x41;
  FUN_ram_0091();
  DAT_ram_41fd = 0;
  _DAT_ram_47fe = 0x48;
  FUN_ram_2938();
  _DAT_ram_47fe = 0x4b;
  FUN_ram_01ed();
  do {
    _DAT_ram_47fe = 0x4e;
    FUN_ram_0214();
    DAT_ram_41f8 = 0;
    _DAT_ram_47fe = 0x55;
    FUN_ram_34a3();
    _DAT_ram_47fe = 0x58;
    FUN_ram_087d();
    _DAT_ram_47fe = 0x5b;
    FUN_ram_2201();
    _DAT_ram_47fe = 0x5e;
    FUN_ram_0e62();
    _DAT_ram_47fe = 0x61;
    FUN_ram_0eab();
    _DAT_ram_47fe = 100;
    FUN_ram_0962();
    _DAT_ram_47fe = 0x67;
    FUN_ram_0445();
    _DAT_ram_47fe = 0x6a;
    FUN_ram_26e0();
    _DAT_ram_47fe = 0x6d;
    FUN_ram_0500();
    _DAT_ram_47fe = 0x73;
    FUN_ram_2848();
    _DAT_ram_47fe = 0x76;
    FUN_ram_16b8();
    _DAT_ram_47fe = 0x79;
    FUN_ram_007c();
  } while( true );
}