Re: The Luigi Exploit - Could Pokémon be used to ACE / credits warp other games ?
Posted by: Charmy
Date: 2016-12-17 08:01:28
Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.
You can join Glitch City Research Institute to ask questions or discuss current developments.
You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.
The games are stored in flash memory, not SRAM, but yes you can.
In general, with achieving cartridge swap on more consoles, it seems tricky to know if it's truly impossible or if there was some necessary step that was missed. But probably not worth putting much thought into it if it doesn't appear to be possible.
Apparently this may NOT work on a DMG, unless you have extreme luck. (Source, read the comments)
@MelonStorm @vxbinaca Yes, there's a blocking bar on DMG (the first Gameboy.) But not only that. You will almost always crash the DMG when you remove the cartridge. I believe the reason for this is CMOS latchup. How they fixed this on GBC, if you open up the unit and look inside, is by moving the ground ping closer to the cartridge so it makes first and breaks last when you insert/remove the cartridge.
@Gameboygenius I'll have to get a DMG for testing then, I plan on using this for a game. Works fine on the GB Pocket and I don't see any difference in the placement of the contacts on the GBC slot.
To test, then.
As for getting ACE in Stadium. I mentioned the state of N64 emulation is poor. Strangely, I managed to get the GB Tower to work fine in Stadium 2 in Project64, but Stadium 1's just gives a black screen. But this means that debugging tools can be used to work out what code the emulator-in-an-emulator is using, at least.
Just an update, this does work on the SNES. ;D
Unfortunately, it doesn't work on the N64. I tested both Pokemon Stadium and Pokemon Stadium 2 on a physical N64, to no avail. It seems like the interrupt handler for the N64 takes precedence over the emulator's interrupt handler, whereas the SNES may just hand off all GB cartridge concerns to the SGB itself.
As a few points of interest, there were two unintended effects that occurred when trying to do the glitch: One was a softlock and the other was a VRAM glitch that I haven't seen before on a Game Boy. The VRAM glitch appeared to be a SNES-specific glitch due to the coloration, but idk. I'm not sure if it was an error in how the SNES handled the cartridge being removed, a side effect of the SGB's palette, or something else entirely.
Also, this doesn't seem to have been mentioned yet, but when testing on actual hardware, the game will do a hard reset about 50% of the time. I've had the best luck when pulling the cartridge straight out as quickly as possible and when inserting it by resting it on the cartridge slot and giving it a quick push with the bottom of my palm. If I remove it slowly or tilt it when pulling it out, it hard resets whenever it's pulled out much of the time. Similarly, if I insert it too slowly, it hard resets upon making contact with the cartridge reader much of the time. The issue is persistent across the DMG (latch removed), CGB, SGB, and MGB models. I haven't tested a Game Boy Light yet, since I don't have one, but I'd guess it also suffers the same fate.
Pin Name Expl.
1 VDD Power Supply +5V DC
2 PHI System Clock
3 /WR Write
4 /RD Read
5 /CS Chip Select
6-21 A0-A15 Address Lines
22-29 D0-D7 Data Lines
30 /RES Reset signal
31 VIN External Sound Input
32 GND Ground
My theory about it was that somehow, interrupts weren't diasbled. This left me to wonder if it is possible for an interrupt to execute just after a DI instruction, and then for it to re-eanble interrupts when "reti" ? If that's the case, welp this glitch isn't 100% working.
; the more the better
di
di
di
di
di
di
Also, this doesn't seem to have been mentioned yet, but when testing on actual hardware, the game will do a hard reset about 50% of the time. I've had the best luck when pulling the cartridge straight out as quickly as possible and when inserting it by resting it on the cartridge slot and giving it a quick push with the bottom of my palm. If I remove it slowly or tilt it when pulling it out, it hard resets whenever it's pulled out much of the time. Similarly, if I insert it too slowly, it hard resets upon making contact with the cartridge reader much of the time. The issue is persistent across the DMG (latch removed), CGB, SGB, and MGB models. I haven't tested a Game Boy Light yet, since I don't have one, but I'd guess it also suffers the same fate.
Oh, really ? I got this problem with my first setup (the old which polled $0001, waited for it to become $FF, and then for it NOT to be $FF), which had a 12% success rate (out of ~40 times, I got like 5 successful attempts), where all my successes had me pull the cart straight.
I like to think it comes from the pins disconnecting in an incorrect manner, but I don't quite know what could be the culprit.
According to this, this is the pin layout :
Pin Name Expl.
1 VDD Power Supply +5V DC
2 PHI System Clock
3 /WR Write
4 /RD Read
5 /CS Chip Select
6-21 A0-A15 Address Lines
22-29 D0-D7 Data Lines
30 /RES Reset signal
31 VIN External Sound Input
32 GND Ground
I don't even know what the "PHI", "CS" and "RES" pins may be used for.
I'm really clueless.
As a few points of interest, there were two unintended effects that occurred when trying to do the glitch: One was a softlock and the other was a VRAM glitch that I haven't seen before on a Game Boy.
osGbpakReadWrite
Read/write process to the Game Boy Game Pak memory
(…)
Caution is required when dealing with the returned values. This function cannot determine whether the Game Boy Game Pak has been pulled out, or whether Game Boy Game Paks have been exchanged. That is to say, a "0" (normal termination) is returned even if the Game Boy Game Pak has been removed during function operations. Thus, please confirm the status before and after calling this function to make sure the Game Boy Game Pak has not been removed.