I modded a Super Nintendo (Super Famicom) console so I can view all cartridge lines with a logic analyzer (Agilent 16802A).
Then I recorded the boot sequence of a Super Mario World cart. I was just curious...

Now, there are some addresses and data going on before the call of the reset vector and I cannot understand why or what? The values I mean are marked red. Those values are also different for every boot, but the amount of addresses and data is always the same.

Can we find out together what this is?

From what I understend, RESET performs almost the same things an Interrupt does, i.e pushing the Processor status & Program counter to the stack however it is hacked to perform these as read cycles instead of write cycles which would explain what you're seeing here

Source: https://www.pagetable.com/?p=410

I'm not entirely sure HOW, but it seems like that this is exactly what's going on. Thank you!

Did you fully understand it? Because if I understand correctly, the PC is decremented from 0xFF to 0xFD and 0xFC to fetch the Reset Vector, right? Thing is, if I don't let the processor pull the data lines to 0, by pulling them myself to 0x77, the reset vector is still fetched from 0xFFFC and 0xFFFD. Now I am not sure if Mr. Michael Steil is completely right in his explanation.

Does anyone know of a spice simulation for the 6502 maybe?

Welcome foxchild!

Yes, you can simulate 6502 in Spice. It's really slow...
viewtopic.php?f=8&t=1768

Also you can simulate, as a switch-level simulation of the transistors, in your browser. See for example
http://visual6502.org/JSSim/expert.html ... ore=ir,res

You will see that the PC never takes on values like FFFC - it's the address bus which takes on those values. During an interrupt sequence, the address bus is forced to the vector values, internally, instead of being driven by the chip's various registers.

Edit: in your simulation, it looks like you stopped driving 77 just at the time that the machine is reading the vectors. You were driving 77 at the time of the dummy stack accesses - the vector values are not pulled from the stack, so that didn't have any effect.

Edit: don't confuse the stack accesses to 00FF and nearby, with the vector accesses at FFFD and nearby!

For a slightly fuller explanation…

On power up, the internal registers and other state of the CPU are scrambled to essentially random values. The same happens with RAM. Normally a "power supervisor" circuit is used to hold the /Reset line low until a few milliseconds after the power stabilises properly. While /Reset is low, the CPU is essentially halted, and when it goes high it takes a special kind of interrupt. This interrupt performs all of the necessary initialisation, which isn't very much, to make the CPU behave properly and start executing code from a predictable address. This first code (known as the "reset handler") is expected to do the rest of the initialisation and then pass control to the main program.

On the 6502, the reset sequence (like all interrupts) takes 7 cycles. The first two are "internal operations" which are used to select the internal microcode program for an interrupt, and then to transfer the stack pointer to the address register. The next three are used to save the PC and the status register (P) on the stack - these will be meaningless during a reset, but it's just reusing the same sequence as for a normal interrupt. Finally, the last two cycles fetch the reset vector from $FFFC/D.

The SNES actually uses a Ricoh 5A22, which is based on the 65816 core, which in turn incorporates many small improvements and bugfixes made to the 65C02 over the original NMOS version. One of these is to suppress the actual write of the stack addresses during the reset sequence; the accesses still occur, but they are reads instead. Another is that the D (decimal) and E (emulation) flags and the Data and Program Bank registers are initialised, so you may assume the CPU is in 6502-emulation and binary-arithmetic mode out of reset. Finally, the core produces a /VP (vector pull) signal, though I'm not sure whether this is exposed on the 5A22; at any rate, it would go low during the two cycles in which the vector is loaded.

Thank you for the very helpful answers! This forum is amazing.

Last two small things I don't understand now are why the 0x77 on my data bus is visible on the address bus for a brief moment and how the 0x01F7 is generated afterwards?

Btw, those are no simulations. I am recording this from real hardware with a logic analyzer. I attached a picture of the setup.

The presence of $77 on the data bus probably influences the contents of the address register during power-up. There is no significance beyond that, as the first two cycles after /Reset goes high are "internal operation" cycles with no intentional memory access by the '816 core.

Address $01F7 is in the Stack page of the 6502-emulation mode. The 6502 had only an 8-bit stack register, to which $01 was prepended to generate addresses for stack access; this is emulated in the '816 when the E bit is cleared, but in "native mode" it has a full 16-bit stack pointer. The stack register is another one that contains an unpredictable value immediately after power-up. During an interrupt, as I mentioned, three (or four in native mode) bytes are pushed onto the stack (which grows downwards), but the writes are converted into reads specifically for reset.

You might find the WDC W65C816S datasheet useful for understanding the core's operation. Not all of the external signal data will be correct for the 5A22 (in particular, it was built on an older process technology than the current WDC products), but there are big detailed tables describing what happens cycle by cycle, instruction by instruction.