You can add the Pokémon Stadium titles on the list of games that use the RSP to execute code. It's used for GB emulation, mostly to process GB image data into palette indices and convert palette color samples. They also draw the result directly to the screen buffer, but that's not super important.
As for that error with the GB cart, it's looking like the thread managing the microcode is hanging, throwing a false-negative GB cart access condition. They justifiably presumed that if the thread can't return processed GB video that there's a problem with cart access, not with their microcode being loaded or running.
[edit]
I should also note one rather important thing. The actual code run on the RSP is straight R4300i code. No vector commands or anything like that. I have a partially annotated disassembly if anybody's interested.
Also, if you want to watch pak reads, the functions in question in CPSJ:
80051110 osGbpakCheckConnector()
800515B0 osGbpakPower()
80052480 osGbpakInit()
80059210 osGbpakReadId()
80059790 request SI write of data A3 to queue A0 on channel A1 at offset A2
8005C670 osGbpakReadWrite()
Throw a breakpoint down on 801214E0 to catch when it initializes the pak. Throw another one down on 80121504 to catch when the ID is loaded. Note this is done twice; one loads the thing to a control structure, the other to a buffer to verify the contents.
The header is tested for integrity twice. The N64 does a test on the header data similar to the one used by the GB, but the normal GB test is also run. Believe it or not, they copy the bootstrap over the first 0x102 of ROM and run it like normal, then overwrite it with the original contents if it runs successfully.
From the return value (0xFF), it's probably the GB Pocket bootstrap. It differs only from a standard GB bootstrap in the return value and the additional two bytes, acting as an infinite loop.
[edit]
I have a copy of the uncompressed binaries if you need some kind of checksum to identify it. What kind of sums are used anyway? You could probably set a new type as 'straight executable R4300i code' and run it as such for these special-case types.
As for that error with the GB cart, it's looking like the thread managing the microcode is hanging, throwing a false-negative GB cart access condition. They justifiably presumed that if the thread can't return processed GB video that there's a problem with cart access, not with their microcode being loaded or running.
[edit]
I should also note one rather important thing. The actual code run on the RSP is straight R4300i code. No vector commands or anything like that. I have a partially annotated disassembly if anybody's interested.
Also, if you want to watch pak reads, the functions in question in CPSJ:
80051110 osGbpakCheckConnector()
800515B0 osGbpakPower()
80052480 osGbpakInit()
80059210 osGbpakReadId()
80059790 request SI write of data A3 to queue A0 on channel A1 at offset A2
8005C670 osGbpakReadWrite()
Throw a breakpoint down on 801214E0 to catch when it initializes the pak. Throw another one down on 80121504 to catch when the ID is loaded. Note this is done twice; one loads the thing to a control structure, the other to a buffer to verify the contents.
The header is tested for integrity twice. The N64 does a test on the header data similar to the one used by the GB, but the normal GB test is also run. Believe it or not, they copy the bootstrap over the first 0x102 of ROM and run it like normal, then overwrite it with the original contents if it runs successfully.
From the return value (0xFF), it's probably the GB Pocket bootstrap. It differs only from a standard GB bootstrap in the return value and the additional two bytes, acting as an infinite loop.
[edit]
I have a copy of the uncompressed binaries if you need some kind of checksum to identify it. What kind of sums are used anyway? You could probably set a new type as 'straight executable R4300i code' and run it as such for these special-case types.
Last edited: