sburrow wrote:
BigDumbDinosaur wrote:
Jeff's observations in this regard stand. The 65C816's bus cycle is the same whether in emulation or native mode. The 816 always emits the bank bits during Ø2 low. In emulation mode, only the absolute long addressing modes will cause a non-zero bank to be generated. Indexing over the top of bank $00 using absolute (16-bit) addressing modes will wrap around without incrementing the bank. Therefore, your latch circuit should be the same as it would be in a purely 816 circuit.[/color]
Let's do a hypothetical. Say we reset and we are in Emulation mode, Bank 0. I then go to Native mode, play around with Bank 1 or something. Then I suddenly want Emulation mode again, but in Bank 1. If I am understanding correctly, I would then re-enter Emulation mode, but be 'stuck' in Bank 1, lest I call those absolute long addressing modes. With the '273, I would be forced back automatically to Bank 0 regardless of where I was beforehand. Am I understanding this correctly?
It may seem natural to think of Native Mode as being something that turns on many extra capabilities. But I think better insights are revealed if we switch things around and think of Emulation Mode as something that turns
off certain capabilities.
When the '816 was created, the designers had their hands full, giving Native Mode its extensive sophistication. Then the last step of the design process was deciding how to inhibit certain features in order to implement Emulation Mode. And it would be senseless of them to waste any extra effort. Their goal was to
do the minimum possible in order to ensure that 6502 code can run with no surprises in Emulation Mode.
Certain measures could not be avoided. For example, it was necessary to take deliberate steps to ensure that A, X and Y always remain 8-bit, regardless of any value that might get loaded into the P register.
But one thing the designer's
didn't have to bother with is the new opcodes introduced on the '816. '816 opcodes don't appear in 6502 code, so it would be wasted effort to take deliberate measures to prevent their execution. So, no deliberate measures were taken, and many of the new opcodes execute with complete success!
Others suffer partial or complete failure, but these are generally just incidental effects rather than a deliberate effort. For example, MVP and MVN end up being badly crippled simply because X and Y are restricted to 8 bits.
Published documentation doesn't always make it clear how the new opcodes will behave in Emulation Mode, but I think it's fairly safe to use the following assumption: barring inescapable factors (for example, the issue noted re MVP and MVN), all the new opcodes will work.
For example, BDD mentioned the absolute long addressing modes, but I believe the Direct Indirect Long modes will work as well. (And all these modes can cause the Bank Address to briefly deviate from zero.)
And I think even Long control transfers will execute successfully, causing the Bank Address to become non-zero for extended periods until you JML or RTL back to bank zero. I wasn't able to verify this. But the Eyes and Lichty manual describes PBR as being
initialized to zero at power on. I don't see any reason why it would need to held at zero
continuously, so I expect the designers took a laissez faire approach and merely caused PBR to
begin at zero.
I hope these remarks are helpful. Chad needn't be concerned about getting stuck in a non-zero bank. He can jump out of that bank just as easily as he jumped in.
-- Jeff