logic
commented
7 months ago (Sorry for the late reply, it's been a while since I looked at any of this.)
I've never looked at the SH7042 datasheets, but I wouldn't automatically assume any sort of backwards compatibility here; at the very least, you'll need to account for RAM/ROM/register segment size and location differences for your application.
On the opcode side: this might actually be okay, depending on how different the earlier version is. Typically later revs are supersets of previous functionality, so you might be able to avoid this part, but it's probably an exercise worth going through just to be formal about it.
If the datasheets are laid out anything like the later ones, there's a bunch of ad-hoc little scripts in the extras directory that I used to help extract the opcode tables and eventually massage them into a module the disassembler can use (see sh2dis/sh7052.py and sh2dis/sh7055.py as the final result). They're messy and organic; assume that they won't work out of the box and you'll need to tweak them a bit to get things the way you want it.
I'd use that as a point of comparison between the different instruction sets; you'll want to check if the earlier SoCs had any different branching instructions, and if so, you'll need to add them to sh2dis/sh2.py. You might also need to adjust sh2dis/sh2opcodes.py. But honestly? I'd be really surprised if either needed to be touched for an earlier rev like this.
Once you've set that up, you'll want to figure out how to distinguish your new processor type, and set up addressable RAM, ROM, and register segments for it; see get_segments in sh2dis/__main__.py for an example of how I wired this up (I just keyed off the size of the ROM; this might not work for you, so another heuristic or a command line option might be needed). The datasheet should have what you need to set these appropriately (note, for example, that the register segments are the same between the two models I already set up, and will probably be the same for you, but the RAM segment will almost certainly differ based on your application and the size of the ROM image).
Unless you're working with a similar platform/problem space as I was, you can probably ignore everything in sh2dis/mitsubishi.py; that's a bunch of heuristics-based approaches to automatically format 1D/2D/3D tables in a more human-consumable way, along with identifying standard stuff on that platform like the MUT table, immobilizer, etc. There's also a scan for specific use of mova, which was an identifiable quirk of how their compiler settings produced jump tables that naive disassembly couldn't catch.
This is probably a good place to mention that while sh2dis tries to do relatively naive register tracking, this really only works because the target ROMs I was working with at the time were compiled without optimization, and "naive was good enough". Your application might require a more clever approach.
Best of luck, and please feel free to send pull requests if you get things far enough along that you think it'd be useful for others.
I see the disassembler was designed to decode the binary for SH7052 and SH7055. I want to make it work with a SH7042 code, but not sure if the code was designed to be backward compatible with the previous line. I'd need to revise the whole datasheet for SH7040 series to find out the answer myself, but I want to assume the author already has more context on the matter to readily answer it.