So when I started out, I thought that the mode switching would be the biggest problem. In fact, this can be handled pretty well with DEFER statements in Forth -- one version for 16-bit A, for example, the other for 8-bit A, and use IS to switch when the m bit is set.

The real problem are the memory banks. For instance, for an instruction such as load accumlator long (lda.l in Typists's), it is not enough to just load the next three bytes and de-endian them. You have to load each byte by itself, increase the PC by one, make sure the PC wraps, and then get the next byte, because you might be at the end of a bank. You can't, however, automatically increase the PC every time, because you want to use the same basic routines for, say, the stack. And of course you have to see if you're loading from a special I/O address while you're at it.

At this point, I have too much time invested not to complete it. But to anybody thinking of writing their own emulator, this is where it is going to hurt. I'd be finished and deep in Beta now if it weren't for the banked memory.

I wonder how many emulators get that right. It would be very unusual I would think to have an opcode within two bytes of the top of the bank! On a related note, I'm actually a bit surprised to see that 16-bit data accesses do cross bank boundaries, but it makes some sense. It's a case where the little-endian approach makes it easier: the address can be incremented during one access ready for the next. But it does need to be a 24-bit increment.

Yes, I admit I briefly considered including a line in KNOWN ISSUES to just avoid the whole problem -- you know, it's a crude emulator, after all -- but I'm sure I'd be the one it would come back and bite at some point. Might was well get it right while I still have a (somewhat) detailed understanding of what word does what ...

I think that's what I did in my a6502 emulator - two-byte stack operations won't wrap properly. Possibly the same for fetching two-byte pointers from zero page.