_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Note that native mode acts differently in some cases on bank crossing, compared to emulation mode. In fact there are lots of caveats and special cases for native mode, which fortunately we don't have to worry about here.

Hi Ed,

I need to "outsource" some routines in emulation mode to another bank than bank0. I ran out of ROM space in Bank0. I only want to "outsource" initialization routines that are called once on a cold or warm restart of the computer. In order to not change too much of the ROM I would like to stay in emulation mode. So does JSL work and execute code in another bank and does RTL return to Bank0 again? Or should I rather look into a solution that copies those routines from a higher bank to RAM and executes the code in Bank0?

Regards

Peter

According to the data sheet, "7.8 All Opcodes Function in All Modes of Operation" (page 53). I have not tested JML, JSL or RTL operation in emulation mode, so I can't confirm this. However...

If an interrupt hits while operating in emulation mode, PB will not be pushed to the stack, even though that register is forced to $00 by the 65C816 when it acknowledges the interrupt. What this means is if your "far" subroutine is being executed when an IRQ hits, the '816 will not return to it when RTI is executed. PC will indeed be reloaded with the address of the interrupted instruction but PB will continue to be loaded with $00.

Is there any reason why you need to run the '816 in emulation mode, yet call far subroutines?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That interrupts won't save the Bank register was clear to me already. The reason is, that this is an existing system with a full ROM and now I added some hardware that needs large (2kbyte) initialization code. It is no problem to disable interrupts during that time. I want to stay in emulation mode, so I do not have to touch the rest of the system, i.e. I want to be able to call old-ROM routines from within my initialization code. If I go to native mode I have to test the whole ROM to make sure it really is compatible with emulation mode, that I wanted to avoid.

Another option would be perhaps to just duplicate the mentioned ROM Routines and just those into the upper ROM and make sure that these are ok. I'll have a look into it.

As BDD says, JSL/RTL should work for you, as would JML. I don't have a working 816 system right now to check it on.

(I reckon you could make a bank-aware emulation-mode interrupt handler by storing the destination bank byte in page zero when you cross banks. It will of course add a few cycles to your handler. There'd be a cycle or two of inconsistency as you make the transition. I think you could solve that too, by making an ABI call through known addresses, where the trampoline code is replicated in the target bank, or by masking interrupts if you don't use NMI.)

The Eyes and Lichty manual touches on the topic of mode switching during interrupt handling. There was a point when I was transitioning POC V1.0 from emulation mode to full native mode where my foreground code was all native but the interrupt handlers were still emulation mode. When the interrupt hit, the MPU was, of course, in native mode, so PB got pushed. What I did was kind of convoluted. First thing I did was stash the 16 bit stack pointer at $0000FE. Next I pushed all registers, switched to emulation mode and set the (8 bit) stack pointer to $FD and executed the ISR. When it was time to return, I went back to native mode, reloaded the stack pointer from $0000FE, retrieved the registers from the (native mode) stack and RTIed. It worked, but obviously was a lot of hoop-jumping.

BTW, if an NMI hit while servicing an IRQ, all bets were off.


Unless the old code makes use of undocumented instructions and/or the 65C02-specific bit twiddlers, or has dependency issues (e.g., reliance on ZP behavior when indirectly addressing through $FF) it should run without any problem in native mode.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The problem with calling existing routines is that in native mode you might be in another Bank than Bank0 and the existing routines do a normal RTS, which does not pull the Bank register form stack. So for each routine you need to have a wrapper. I thought about that as well.

As it is, what I have done now is that my initialization routine switches to native mode just do move the initialization code for the hardware from a higher bank in ROM to RAM in bank 0, switches back to emulation and then calls the code just loaded to the RAM. This uses only very little ROM space in the emulation ROM area (in my case limited to 256bytes) and avoids all problems with mixing native and emulation mode during startup. So that's the solution in my case, even after that a native OS will be loaded, but for this the hardware must already be initialized. So kind a hen and egg problem.

Let me try to rephrase this topic to see if I've understood everything: If you're thinking of building a 65c02 SBC computer, use a 65816 instead, seriously, you'll thank me later. Even if you never, ever switch into native mode and only stick with 64k forever:

1. You get all the additional 65c02 instructions in emulated mode -- not only the original 6502 instructions (I think this might be a common misunderstanding). That's stuff like BRA, STZ and JMP (abs,X). So you can, if you really, really want to, just use it as a 65c02. This means you can use all the "normal" assemblers, too. Put a sticker over the chip and nobody needs to ever know it's not a 65c02!

2. However, you get a whole bunch of instuctions from the 65816, too, even in emulation mode, stuff like TXY, TYX, and XBA. The last one is especially interesting, because even in emulation mode, you get an extra register named "B" you can swap with A. The zero page (now "direct page") can be relocated and you have extra stack relative addressing modes. Note that normal assemblers don't support these out of the box, but I'm sure this is something you can fix with macros.

For the record, the relevant part Programming the 65816 by Eyes and Lichty starts on page 58:
The drawback is that the hardware side needs a bit more work, even in emulation mode (er, could somebody confirm that?). You should include a bus tranceiver such as the 74x245 (see viewtopic.php?f=4&t=2438) for the data bus and a 74x373 latch for the addition byte of the address bus, and connect them to PHI2. You should also deal with VDA/VPA at higher clock speeds (or is that at all speeds? I admit I'm still confused after reading various topic posts). Some of the pins are different.

What would be great would be a reference design of a most basic 65816 system, however simple, something like Garth's famous complete 6502-schematic (http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU). Even if none of the 16/24-bit functions are used, it would provide a starting point for 65816 designs like the current schematic does for 6502/65c02 systems.

Yes, your one-sentence summary is spot on!

As you very nearly say, the most simple 65816 system is just like the most simple 6502 system, but with a couple of changes for the pinout differences.

As soon as you want to address more than 64k of memory, you need that latch - but maybe only one or two bits of it. You might need a bus transceiver, but it depends. You almost certainly don't need the VPA and VDA decoding, but if you're a very conservative designer, or if you're the one person who got burnt by using a particular peripheral and a particular addressing mode, you would decode them.

(There won't be a consensus on these more subtle points, because experiences and inclinations vary. You need to figure out whether you're a minimalist or a safety-first kind of person.)

Most but not quite all. When the NMOS 6502 was superseded by the 'C02, lots of extra instructions were added -- and some extra address modes as well, such as zero-page indirect without the Y postindexing. The '816 has these improvements and many more, available when you're ready to use them.

Except, some of the C02's new bit-oriented instructions were deleted on the '816 (namely, the set bit, reset bit, branch on bit set and branch on bit reset instructions). Still, I agree with the basic thrust of your post. You should just put a sticker over the part number if the chip's 816-ness intimidates you!

The explanation is lengthy, even though the actual problem is fairly minor. Multitudes of NMOS '02 users successfully dealt with it, or -- far more commonly -- simply never experienced it.

Edit: I deleted the following paragraphs, in favor of a more careful explanation here.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I think one problem might be that there is no easy-to-use 65816 emulator (there is another thread with some libraries for one, but that seems to be rather specific for one type of computer).

Maybe there would be a way to demonstrate at least some of the features the MPU offers even in 8-bit mode by adding a "showcase 65816" option to an existing emulator such as py65 ? I'm sure that's not totally trival -- you'd need a new register (B) and some whole new addressing modes (stack) and such -- but that sounds more realistic at the moment than a 65816 emulator.

Hi scotws - do you mean lib65816? I think it's pretty minimal as far as machine specificity goes, although indeed it was written as the core of a machine-specific emulator (for Sam Falvo's Kestrel, I think)

For a minimal wrapper (run65816) see
viewtopic.php?p=23982#p23982
(You might well customise that wrapper for your purposes. I'm always fiddling with the equivalent run6502 wrapper.)

There are machine-specific emulators too, for example for the Apple IIgs, which might be good for testing out short code sequences but otherwise not too useful to support a new computer design - unless you roll your sleeves up and make it fit your design.

But as for py65... I think it becomes a pretty major task when you look at all the modes and the odd interactions which happen on the 816. Oh, and I'm not sure what test suites might be available. Bruce wrote a major document which included minimal test cases for a number of oddities, but I think it remains unpublished.

Cheers
Ed

Edit: Bruce's document is now published, here: http://www.6502.org/tutorials/65c816opcodes.html

In this context, what would define "easy-to-use" for an emulator? As somebody who's done a lot of VMs and compilers and such, that's very interesting to me.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Let's start off by it not requiring a "wrapper" of any sort. Then maybe an example: py65 lets me pick the ROM file from the command line and it boots on start; that's easy to use. It also has the addresses for getc and putc hardcoded in some subroutine as magic numbers, not in a configuration file; that's not easy to use.