Hi!
Just wanted to ask real quick if anyone here knows a way to prevent the 65816 from looking up the NMI vector in ROM? I would like to use an NMI routine but execute it completely in RAM. So it would be nice if the start address is also fetched from RAM. Is this possible?

I am working on a project with the Ricoh 5A22, which is 65816 based.

Edit: I should add that I am working on "normal" Super Nintendo hardware, so additional decoders or something similar is not a preferred solution.

If you have control of the NMI vector, you could easily point it at a jump to the actual NMI routine, and that jump(as well as the routine itself) could be in RAM.
The C64 did something similar for the IRQ vector.

Thank you! I know I could point to a jump in RAM, but I would like to change the address where the NMI vector is fetched. Do you know what I mean? The 65816 expects the NMI vector at 00FFFE and 00FFFF and I would like to store it at, i.e. 0012FE and 0012FF. Is this possible?

It is impossible to change the address the 65816(or whatever) puts on the address bus when it wants a given vector. That is built into the hardware.
If you cannot remap memory, or otherwise arrange for RAM to be in the vector locations, your only option is to use a jump or branch. That achieves the same effect, and it only costs 3 cycles.

It might help if you described something of what you're doing, and why you want the vector in RAM.
I can't think of any reason you'd want to switch out your NMI handler, because as far as I can tell, there's only one thing that can cause a NMI in the SNES, and that's VBLANK.

Indeed, I think you're stuck with the original vectors, or with adding some additional decoding to redirect those vector pull accesses.

Alright, I was afraid so...

I am simulating ROM with a microcontroller and I would like to run most code from RAM and use the uC during Vblank for something else. I will have to change plans.

Maybe I'm missing something, but if you're simulating the ROM then what is stopping you making the NMI vector point to where you want it to point?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I am simulating ROM with a uC, which is busy when VBlank is called. It doesn't provide enough resources for ROM simulation and other tasks in parallel.

OK. got it now. So, no, not without any extra hardware. The sequence is fixed in the internal widgetry inside the 816.

How far down the build route are you? My system uses a bit of shared RAM between a microcontroller (AVR) and the 6502/816 so the AVR pokes the bootloader in, then lets the 6502/816 run which can then load the rest of the OS and do what it needs to do then.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Where can I see your system? I'd be very interested!

The hardware is done, even though I could obviously still make some changes, but I am trying to prevent this so I can keep it all as simple as possible.

Have a look at: https://projects.drogon.net/6502-ruby/

Although the current incarnation is essentially the same board but with more RAM and a 65816 - quick mention here viewtopic.php?f=4&t=5725 as I've not had time yet to do more write-ups on my main blog site about it yet.

In essence, I wanted to keep things simple too, so the AVR can see the 256 byte window of SRAM using a combination of the 6502/816 executing a WAI instruction, then using the Rdy and BE signals.

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Wow! That looks really fancy!

I am building this synthesizer cartridge for the SNES: http://www.snesdrone.com

Is there still a little wiggle room? You only need the ROM emulation still to be running for the first few cycles after the NMI, to service the vector pull. And this happens - perhaps - at about the same time you want to task switch during vblank. As soon as the vector pull has happened, the uC can get on with whatever vblank-related task you have in mind. (I'm assuming that NMI happens at the start of the vblank.)

Thank you for your input! That's exactly what I have implemented now.