Why did WDC bother with emulation mode?

A bit late to the part but a couple of points.

Firstly, I read somewhere (I can’t locate the papaer now) that the NMOS style timings and behaviours were demanded to make the porting of the Woz disc routines to the Apple II GS easier. I’m not sure how true that is but it is plausible. Certainly the emulation cycle counts and behaviours didn’t seem to fall out naturally when I made a vhdl 65816. I suspect by the time the 65816 finally shipped much of the reasons for the compatibility were moot.

Secondly it is possible to make an OS that uses both emulation mode (to run existing software) and native mode to run the main kernel. I’ve done that on a prototype OS here which allows most code to run in native mode but also interoperates with older BBC Micro filing system and utility ROMs which are run in an emulation mode virtual-ish machine-ish sandbox kind of thing. It’s not great in that the context switches between emulation and native modes for interrupts is a bit slow and hairy but as proof of concept it works. If Acorn had wanted to make a 65816 operating system that had broad appeal this might have worked as it would have been able to launch with an existing software library. [Acorn did make a 65816 operating system for their Communicator product but that wasn’t really mass-market]

2 Likes

My recollection is that the C02 improved the timing of RMW operations, and the 816 changed some of those - but not all - back to the NMOS timing. As noted, my understanding is that it was done for the Apple disk routines. But I haven’t collected any citations!

ASL LSR ROL and ROR are 1 clock faster on a C02 unless crossing a page boundary. This is put back to the NMOS timing on the 65C816

ADC and SBC take an extra cycle if D if set, and another crossing page boundaries (but on the C02 they set flags). The 816 does not take the extra cycle but keeps the flag behaviour.

JMP ($xxFF) was buggy on the NMOS part and fixing this made it take 1 cycle longer on the 65C02. This was put back to NMOS timing on the 816 but remains bug free.

1 Like

Table 3-1 Addressing Mode Summary on page 24 of the 65c816 datasheet lists the timing differences with the NMOS 6502 (there are not many).

But like I mentioned I do believe we are pretty much at the limit of how well we are going to understand this chip without making a simulation of every single transistor (I would certainly trust a simulation more than the datasheet, plus it has the advantage of being more convenient to test on than the real thing.)

Ah, I found something definitive, if not precisely to the point, as we might be comparing NMOS, C02, and 816 timings, and we usually only get two of them compared. Anyhow, found on the 6502 forum, a quote from one of Bruce’s documents:

Unfortunately, this is not always documented correctly, as some 65C02 documentation mistakenly assumes that DEC and INC have the same timing as ASL, LSR, ROL, and ROR; namely that INC abs,X and DEC abs,X take 6 cycles when a page boundary is not crossed, which is, once again, incorrect. DEC abs,X and INC abs,X always take 7 cycles.

Yeah, and that’s a whole other can of worms and one reason why I think it’s sometimes best to just not worry about cycle times at all - I don’t want to find out I’ve been optimizing my code wrong. When there’s a hardware timer you can query before and after your code runs it’s usually easier to trust than claiming that you’ve cycle counted everything perfectly (also assuming datasheets/documentation is perfect).

Get it working first is the main thing. as long as you are in the ball park is OK for me.

1 Like

Yeah and at the end of the day how much wall clock time you spend waiting and power consumption is what matters not how many clock cycles.