RomRaider

Chuckle...

I figured there were some poor people who have waited for 16 bit definitions for ages on here, so I'd dive in. Takes some getting used to, different table architecture altogether.

Which CPU type did you select, the Z or Y1 version?
I'm wondering if we need to set a page register globally first so it offsets all the address by the register value.

Can't remember, I think it was Y1.

^ y5

The biggest problem I have had is that there is not a reference manual available that is specific to our 16bit processor. Most of the hardware and port addresses are incorrect from the y3 manual

I was hoping you'd chime in

Hmm.. y5, like you say, have not seen any literature on that implementation...

Also, about addressing. There are many subroutines that use a different zk and yk offset, so you can't just set it to 02 globally. When zk is changed you will find that direct addressing or extended addressing is used so I usually check xrefs for an address in both formats. I haven't found a way to name an indirect address, I usually just comment them all. ek is always 02 so ida automatically converts all extended addresses, I don't believe there is a way to designate k registers per subroutine.

That's what I was worried about reading through elevenpoint7five's description - there are too many exceptions to the Z, Y always equals 2 rule. Oh well... manual it is till we figure out something better.

I'm getting the hang of it - have A4SHCOOH halfways defined already, including all the CELs.

It is not just "16bit" problem to tackle.



M32R compiler use any but link (return adrress) register as a base at any time and there are a lot of clusters used (learning, SSM, CELs, etc ).

If you can list the ones that are correct and incorrect with an update we can update the IDA config file.
I did this for the SH7058 and submitted it to Hex-Rays and they're going to incorporate my changes into future releases.

Does this help with the instruction set?
http://cache.freescale.com/files/microc ... PU16RM.pdf

Ok, well I've found a quicker way of resolving the references in the 16 bit roms, using the same user referenced offset trick (ctrl R).

Say you have a line like this:

Using a user referenced offset of 0x20000, with base as plain number and signed operand ticked off will give you this:

Slightly quicker than adding and commenting

Now if only there was somebody on here who was super adept at IDC scripts, that could rip through the whole rom and do this

The other thing that struck me is that somewhere in the processor module procedure used by IDA, Z is set to 0. A quick and dirty would be to reset it to 2.

No idea how to...

Yes. Edit > Segment > Change Segment Registers and set the default offset.

Ok, got it - managed to change it and reanalyse the rom - doesn't translate the addresses, however. The user reference offset works relatively well.

It does work for some references to the 0x20000 section. Did you they setting Y = 0x2?
http://www.hex-rays.com/products/ida/su ... /524.shtml

Anyone looking for a 6816 simulator can try here.
When using the simulator load a 192kB version of the ROM so the data is in the correct address range.
d.load "full_path_to_192kB_file.hex"
To set the CPU to 68HC16Y1:
sys.cpu M68HC16Y
To set the registers correctly:
r.set iz 0x20000
r.set pc 0x00220
r.set sp 0x208F6

Some basics of 16bit CPU initialization.
The first 6 words of the ROM are the initialization values. They are:
0000: 0220 - each byte sets one of the K register nibbles in this order: xx ZK SK PK
0002: 0220 - this is the lower 16 bits of the program counter (PC). The full value is PK & PC to make a 20 bit address
0004: 08F6 - this is the lower 16 bits of the stack pointer (SP). The full value is SK & SP to make a 20 bit address
0006: 0000 - this is the lower 16 bits of the Z index register (IZ). The full value is ZK & IZ to make a 20 bit address

The address range from 0x0008 to 0x01FF is for various reset vectors addresses.
All on-board peripherals are accessed using the IY register. The YK extension register is always set to 0xf. So peripheral modules are all at the top of the addressable range above 0xFF0000, typically starting around 0xFFF400. The actual peripheral modules are not well documented for the 68HC16Y5 CPU. So using documentation for the Y1, Y3 and other series may not give accurate module addressing.
Note: the CPU has 20 different addressing modes.

If you need a compiler, I ran across this.

The only problem with blindly setting the offset to 0x20000 is that it may not always be a correct assumption.
The operand for this opcode is a signed offset to be applied to the contents of the IZ register. In the case above you are assuming ZK = 2 and IZ = 0000.
What if in the calling subroutine IZ was modified and set to a value other than 0x0000. Then when you get to this routine and apply the manual offest (0x20000), the resulting address is not valid.
For example:
in this case IZ has been modified to add 0x234 to its current value and then you add the offset 0x15E4 to load a byte into A.

You really need to keep track of the register modifications when using indexed addressing.