A user on Kaydus's nesdev Discord server mentioned wanting to be able to keep track of game stats from a game being played on an actual NES, for speedrunning purposes (automatic splits) and to keep track of things like death count. This made me think of modifications I've seen that replace the NES's RAM with dual-ported RAM, but I feel like a Game Genie-like device that watches for writes to specific RAM addresses would be a lot better because that would avoid modifying the NES, and it would work with PRG-RAM too.
I guess the obvious changes from dual ported RAM + microcontroller are that you'd need to find a 72-pin cartridge connector somewhere (and I hear they're difficult to find) and you'd probably need some sort of programmable logic to be able to react to the write fast enough.
Another option I can see would be the Everdrive N8's USB port, with a custom mapper that watches for writes in addition to performing mapper functions, if the hardware is capable of controlling the USB port like that.
Any advice or better ways to accomplish this? Or preferably a preexisting product?
NovaSquirrel wrote:
A user on Kaydus's nesdev Discord server mentioned wanting to be able to keep track of game stats from a game being played on an actual NES, for speedrunning purposes (automatic splits) and to keep track of things like death count. This made me think of modifications I've seen that replace the NES's RAM with dual-ported RAM, but I feel like a Game Genie-like device that watches for writes to specific RAM addresses would be a lot better because that would avoid modifying the NES, and it would work with PRG-RAM too.
I'm not sure a "game genie" could do this well, as the NES RAM is being accessed directly from the CPU, not via the cartridge, and you can't afford to interfer with the CPU usage during a speedrun
I guess you could do a low-key version that detects what addresses are being read from the cartridge, but then you have the issue with mappers.
The cartridge does have access to the address and data buses, so I suppose it could tell when the CPU is writing to RAM and snatch a copy of the value if the address matches one of the addresses being watched.
You could read that RAM with your program, once per frame, and print its contents to screen with 2 sprites.
Anything where you insert code in NMI might change lag frames, which can invalidate a run's timing. It has to be based on snooping writes and logging them somewhere.
I have been thinking about the exact same thing sometimes when watching speedrunners doing their splits manually. I think you could do a lot of stuff by simply watching PRG accesses, just have to configure it for each game separately. So a GameGenie-like device should be sufficient. You could test this theory on emulators quite easily, e.g., with Lua support in FCEUX.
I think many speedrunners wouldn't go for a EDN8/PowerPak solution since they seem to prefer to do attempts on original cartridges. But it would make for a cool demo.
The device could keep track of frame count based on M2. Or even cycle count, if you have enough bits in your counter.
Another idea would be to use the expansion port, but unfortunately it doesn't have the necessary signals. It has the data bus, but only A15 of the address bus. So you'd need a GameGenie-like device to pass more information via the EXP pins, but that kind of defeats the point of using the expansion port.
If all you can snoop on the
NES expansion port are A15 and D7-D0, watching for this sequence should handle the obvious cases:
- A15 = high, D7-D0 = target RAM address bits A7-A0
- A15 = high, D7-D0 = target RAM address bits A15-A8
- A15 = low, D7-D0 = target RAM value
Because the R/W signal isn't present, this logic might not catch when something is incremented.
Doesn't the cartridge port have all the signals? What prevents a Game Genie-like device from detecting writes to RAM and copying the values to show them on a built-in display?
The cartridge port has all 26 signals needed to monitor the CPU's activity: M2, PRG /CE, R/W, A14-A0, and D7-D0. But using a cartridge port device with an authentic cartridge will cause the cartridge to stick out of the front of the Control Deck. This in turn invites accusations of using a Game Genie or similar cartridge port device capable of more than just "snooPING AS usual", in particular things that invalidate a run.
Yeah I kind of like the idea of using the expansion port (if it wasn't for the obvious issues) because it seems less intrusive, although in practice people could cheat their asses off if they wanted, even if "the cartridge wasn't sticking out of the system". It's all based on trust.
While it does sound interesting, being able to read RAM on console, coming from a speedrunner perspective this would be a big no no. Looking at the RAM during a run is not allowed as it can provide an unfair advantage, like knowing what RNG seed you are on, enemy/boss patterns etc. Anything that you can't do on an original, unmodified console is not allowed. It could prove useful for practice however, but would need to be turned off for actual run attempts.
It depends what the system would do I guess.
I don't see a problem in doing automated splits like this. But if the system would show, e.g., what state the RNG is in, that of course is not OK.
thefox wrote:
I think many speedrunners wouldn't go for a EDN8/PowerPak solution since they seem to prefer to do attempts on original cartridges. But it would make for a cool demo.
I've seen many speedrunners using these things. I think in general as long as they're open about it, in most cases it's still considered an acceptable run? I'm sure rules vary a bit depending on who runs the leaderboard for any particular game, though.
tepples wrote:
The cartridge port has all 26 signals needed to monitor the CPU's activity: M2, PRG /CE, R/W, A14-A0, and D7-D0. But using a cartridge port device with an authentic cartridge will cause the cartridge to stick out of the front of the Control Deck. This in turn invites accusations of using a Game Genie or similar cartridge port device capable of more than just "snooPING AS usual", in particular things that invalidate a run.
I think if a device like this existed, it would very quickly be embraced by the speedrun community, and no one would blame the device. I t wouldn't just be some unknown thing some guy is using.
It's very easy to cheat in speedrunning if you really want to, and it happens a lot as it is. But there also exists a sense of trust, a code of honor as such (which is what caused the community to point out the blatant lies going on at Twin Galaxies), and it's usually very easy to out a cheater.
Yeah, with so many people who stream their attempts, there being witnesses and recordings not just of the successful attempts but you can also see that they "put in the time" to deserve that run. Big difference in trust from the era of people mailing in VHS tapes. Cheating still happens but there's some good ways to build a trusted reputation at least.
thefox wrote:
Yeah I kind of like the idea of using the expansion port (if it wasn't for the obvious issues) because it seems less intrusive
Breaking plastic off the console isn't intrusive? Not to mention incompatibility with different models and clones.
I don't see NES-101 not having the bottom expansion port as too different from later GameCube consoles not having the digital AV out.
I think the Everdrive would work well for that, since it won't affect the game's timing and the hardware already exists. The USB drivers make it simple to display ASCII with any terminal program, the trick would be adding that checking/output into the mappers. The USB chip doesn't come standard on the board (you can order it with it), and the cart shell doesn't have an opening for it, but I wouldn't mind installing a few for people if that's what stopping them. I have the Famicom Everdrive, haven't bothered to put the USB chip on mine yet.
About 72-pin connectors, the 2.5mm pitch ones are difficult to find, but 2.54mm is common and actually works just fine.
tepples wrote:
I don't see NES-101 not having the bottom expansion port as too different from later GameCube consoles not having the digital AV out.
...Ok? My point is, why would you use the expansion port in the first place if what you need to do works even better in the cartridge slot, which's something all systems have? Sounds like pure stubbornness to me.
@Tokumaru
It just sound likes Tepples to me
I'm just trying to anticipate how stubborn some members of the speedrunning community are likely to be.
@tepples
Oh, I didn't mean that you were stubborn but more the way of answering something in unexpected ways is very tepples like, your trademark.
I apologize for the misunderstanding. m(_ _)m (<- Japanese emoji, bowing)
I feel like if someone actually goes to the trouble to make this a product they should go all the way and make it as best as it could be, requiring a cartridge passthrough. Detecting the actual address being accessed means that it's going to work for every possible case (increments, zeropage, pointers, indexing) with no chance for false positives.
Oh, I forgot the Everdrive won't have every address signal, derp. Several of my WIP projects do see the whole bus, I'm getting a little too used to that luxury, heheh. One of them is intended for this kind of use, and it certainly is Game Genie-like. But it seems like it will be forever before I can get it to that point, it's one my bigger projects..
Everdrive N8 has Game Genie support, doesn't it (Which would require all CPU address bits to go into the FPGA)? Even if not for Game Genie, you probably need every address bit if you need every mapper to work.
Both the Everdrive and Powerpak can listen to the entirety of both buses. The major difference between the two is that the Everdrive has to relay (and can bankswitch) PRG A12,11,10, which would be useful for NSF support or some of the rare pirate mappers that use 4K-or-smaller PRG banks; while the PowerPak has to relay (and can bankswitch) CHR A2,1,0 (for MMC5 left-and-right split screen with fine scrolling).
There's probably a few other subtle differences, but that's the huge one.
Game Genie support is usually achieved by patching the ROM at load time, rather than replacing things at fetch time.
Yeah, that difference in PRG line output is why I implemented
mapper 31 for Everdrive, but not PowerPak. To get it to work on PowerPak I'd need a custom ROM loader and to cut the available PRG space in half, like its NSF player does.
For the matter at hand though, yeah I'm sure it has all the lines it needs. Don't thefox's powermappers work by snooping on controller reads? I'm sure that already proves the concept.
I think communicating with the USB without interrupting the CPU for it might be harder to solve, though.
lidnariq wrote:
Game Genie support is usually achieved by patching the ROM at load time, rather than replacing things at fetch time.
At least PowerPak patches at fetch time. Probably N8 too. I think there are some ambiguous situations when patching at load time, although it'd probably work in most of the cases.
(The problem is that, say, in MMC3 there are multiple addresses where a certain bank could be banked in, and there's no way to know which are actually used without running the program. The only protection against patching a wrong byte is the "compare" byte in most Game Genie codes, but it's not fool proof.)
Im not sure if any of you watch the Tetris world championships, but every single nes they have uses a game genie which they use to redraw the game in HD for an overlay for twitch. They also use the data to make cool stats like tetris percentage, and tracking droughts.
Im actually trying to find out exactly how they do it, or if its even a game genie, or a different cartridge.
All they tell the viewers is exactly what i just did.
Heres one of their videos, and youve being warned. Its very addicting to watch, and you may not want to go down the rabbit hole.
https://youtu.be/DdfRQjb5o9kAnd if anyone figures out how im sure we'd all love to know.
LittleRain wrote:
Im not sure if any of you watch the Tetris world championships, but every single nes they have uses a game genie which they use to redraw the game in HD for an overlay for twitch. They also use the data to make cool stats like tetris percentage, and tracking droughts.
https://www.reddit.com/r/Tetris/comments/79lrms/is_it_possible_to_replicate_the_1v1_system_they/In this thread there's a suggestion that the Game Genie is just used to apply a patch that controls the random number generator to make sure both players get the same pieces, and another poster says that the gathered stats and constructed visual is accomplished by analyzing the video itself, not by communication with the CPU.
Both of those ideas seem pretty plausible, and wouldn't require any special hardware.
I think NESpectre is related. A guy from my IGDA chapter worked on it:
https://www.youtube.com/watch?v=FSj9rw70PpkThey said they had a NES where they put "dual port RAM" in it, hooked it up to a microcontroller, and connected to that over a serial port.
Ahh very interesting. Thanks for the link!
Ive been trying to contact Trey on twitter to ask him how its done with no avail. I guess it still isnt 100%, but seems likely.
thefox wrote:
Another idea would be to use the expansion port, but unfortunately it doesn't have the necessary signals. It has the data bus, but only A15 of the address bus. So you'd need a GameGenie-like device to pass more information via the EXP pins, but that kind of defeats the point of using the expansion port.
Are you sure about that? One thing I realized when working on my
CICOprocessor is that you can infer the address from watching the data bus alone by snooping the opcode fetch cycles which contain all the address info. The expansion port also has /NMI & /IRQ signals so you'll know when the CPU is jumping to those vectors. The only thing you don't really have visibility to is when the APU frame counter IRQ fires, and DMC fetches. But perhaps if you're emulating enough of the 6502 to always keep track of what it's current address is, you could emulate those features as well.?
rainwarrior wrote:
https://www.reddit.com/r/Tetris/comments/79lrms/is_it_possible_to_replicate_the_1v1_system_they/In this thread there's a suggestion that the Game Genie is just used to apply a patch that controls the random number generator to make sure both players get the same pieces, and another poster says that the gathered stats and constructed visual is accomplished by analyzing the video itself, not by communication with the CPU.
Both of those ideas seem pretty plausible, and wouldn't require any special hardware.
It's always funny seeing people talking about their theories about how they do this, and most people who claim to know, obviously have no idea. We had people going on in the chat at CTEC too - we used a different solution for random pieces, but the ideas people had for how it worked are hilarious.
The hardware solution at CTWC is only to patch the game for though, not to parse data.
LittleRain wrote:
Im not sure if any of you watch the Tetris world championships, but every single nes they have uses a game genie which they use to redraw the game in HD for an overlay for twitch. They also use the data to make cool stats like tetris percentage, and tracking droughts.
All of this is done using video recognition software. They capture footage using cheap USB composite capture devices, and clean up the footage and draw stats, etc.