Hsiboy wrote:
Small correction to the above, it's
Code:
7A 00 00 00
,
And here's the odd thing. If I diff the Sp808 firmware and the A6 firmware, these patterns occur in the same place in both files. In fact, there are so many null bytes
Code:
00
that occurs in exactly the same place in the two files, it has to be an artifact from the midi update.
Question is, has it been extracted incorrectly, or, is it a further later of transport packing, because the firmware was being streamed in over a uart.
Also, there are strings that appear on the screen of both devices, that are not present in the firmware.
So, either the firmware does not update everything, or there is further compression.
The entropy of the two files is below 1, so I don't think it is compressed, but either way, the firmware that was extracted earlier in this thread, is currently a dead end, because it can't currently be compiled.
the proliferation of 0x00 is because many instructions are designed to have upper bits of addresses as 0x00
Quote:
Program-Counter Relative—@(d:8, PC) or @(d:16, PC): This mode is used in the Bcc and
BSR instructions. An 8-bit or 16-bit displacement contained in the instruction is sign-extended and
added to the 24-bit PC contents to generate a branch address. Only the lower 24 bits of this branch
address are valid; the upper 8 bits are all assumed to be 0 (H'00). The PC value to which the
displacement is added is the address of the first byte of the next instruction, so the possible
branching range is –126 to +128 bytes (–63 to +64 words) or –32766 to +32768 bytes (–16383 to
+16384 words) from the branch instruction. The resulting value should be an even number.
(8) Memory Indirect—@@aa:8: This mode can be used by the JMP and JSR instructions. The
instruction code contains an 8-bit absolute address specifying a memory operand. This memory
operand contains a branch address. The upper bits of the absolute address are all assumed to be 0,
so the address range is 0 to 255 (H'0000 to H'00FF in normal mode, H'000000 to H'0000FF in
advanced mode). In normal mode the memory operand is a word operand and the branch address
is 16 bits long. In advanced mode the memory operand is a longword operand, the first byte of
which is assumed to be all 0 (H'00).
Initially promising, I found my disassembling lacking. The MAME emu has *some* support for H8's and there exists a disassembler in the tools. I couldn't get reasonable results.
Code:
PS C:\SP-808\disassemble>unidasm.exe
Usage: C:\SP-808\disassemble\unidasm.exe <filename> -arch <architecture> [-basepc <pc>]
[-norawbytes] [-xchbytes] [-flipped] [-upper] [-lower]
[-skip <n>] [-count <n>] [-octal]
Supported architectures:
8x300 h8 m68020 sc61860 upd177x
adsp21xx h8h m6803 scmp upd7725
alpha h8s2000 m68030 score7 upd7801
alpha_nt h8s2600...
I am looking at how likely it is I could write a processor module for Ghidra. The instruction set is only 69 odd instructions, but the variety of modes possible, and the many nuances look tricky. The H8 processor module doesn't look that scary, but you would need to get it pretty right, so you don't spit out garbage.
I see MAME has a few processors and looks like they build on previous versions. example H8S2600.h would have a H8S2000.h include which includes a H8300 include... and the last is simply a H8 include. but MAME processor definitions look HARD!
been looking around at some other stuff H8 hacking related to see if there are any that might help. more to come tomorrow
FAQ
Search
Login
Register
HDDGURU FILES
