Update to v106r75 release.
byuu says: So tired ... so much left to do still ... sigh. If someone's up for some code golf, open to suggestions on how to handle the INTNEST control register. It's the only pure 16-bit register on the system, and it breaks my `map`/`load`/`store<uint8,16,32>` abstraction. Basically what I suspect happens is when you access INTNEST in 32-bit mode, the upper 16-bits are just undefined (probably zero.) But `map<uint32>(INTNEST)` must return a uint32& or nothing at all. So for the time being, I'm just making store(ControlRegister) check if it's the INTNEST ID, and clearing the upper bits of the written byte in that case. It's hacky, but ... it's the best I can think of. I added LDX, which is a 900H-only instruction, and the control register map is for the 900/H CPU. I found the detailed differences between the CPUs, and it doesn't look likely that I'm gonna support the 900 or 900/H1 at all. Not that there was a reason to anyway, but it's nice to support more stuff when possible. Oh well. The 4-byte instruction fetch queue is going to have to get implemented inside fetch, or just not implemented at all ... not like I'd be able to figure out the details of it anyway. The manual isn't clear on how the MULA flags are calculated, but since MUL doesn't set any flags, I assume the flags are based on the addition after the multiplication, eg: uint32 a = indirect<int16>(XDE) * indirect<int16>(XHL); uint32 b = reg16; //opcode parameter uint32 c = a + b; //flags set based on a+b No idea if it's right or not. It doesn't set carry or half-carry, so it's not just simply the same as calling algorithmAdd. Up to almost 70KB, not even halfway done, don't even have a disassembler started yet. There's a real chance this could overtake the 68K for the biggest CPU core in higan, although at this point I'm still thinking the 68K will end up larger.
Showing with 628 additions and 264 deletions