Ok, I've tried XM6i.
It does concatenate both ROM30.DAT and the existing IPLROM30.DAT to get somewhat the full rom, which is totally wrong : the upper region of ROM30.DAT contains the beggining of the ROM debugger, and the lower region of IPLROM30.DAT have the end.
So, XM6i generate a ROM with probably a corrupted ROM debugger, which iss not a problem unless you use it. Personnally, I use it a lot via the gdb backend in my toolchain.
3.) The dump tool is from the XM6i developer. Maybe only a part of the memory area will be saved which is necessary to work with XM6i.
IMO, in machine emulation, you can't reach the near 100% of accuracy with just a "part" of a rom. Don't you think ?
4.) XM6i detect the dumped ROM (without the 1024 bytes of junk) as correct ROM.
Even a full 128KB of zero file will work... I've tried, it only check for the size.
(Well, I guess... Since I don't have the source code)
I've already said this some time ago : XM6 suffers a lot from bad ROM management. It seems this have not changed in XM6i. Maybe we should send to the author the next full 256KB ROM dump ?
PS: I think this tool will not dump the needed area but let us see.
It will dump the higher 256KB of the IPLROM, the part that should normally be used by XM6i. But I think that's not enough...
In futur, we should try to get the full 1MB of rom in each released X68K. So no more corrupted dump, or roms part merging/splitting/messing things. (Yeah, I have heard the X68030 and XVI could use a slighly different CGROM as well. So, ...)
