lidnariq wrote:
You might just be able to put an LED across the outputs of the PAL (into pins 11&12 of the '670 footprint) and see when it lights.
It'll only be lit for 350ns on each read/write, so you may need a relatively short loop to be able to see it. Or maybe just a dark room?
As you noticed, only A11-A15 go to the PAL, so the window can't be anything finer.
Hmm...
I remembered that I actually bought a cheap $60 USB scope a couple years ago and opened it up for the first time today.
It looks like I can just barely make out the CLK signal going to the Flip Flops from the PAL (says it's sampling at 2.5 MHz), so I think I ought to be able to see the WE and RE lines going to the 670.
Unfortunately, it looks like I can't. It's actually constantly reading half the voltage of the other pins read when they are high (not sure I trust the displayed voltage on this scope). Maybe this PAL isn't programmed to control those lines because they decided not to with the 670 not in place? Might need to actually have one with the populated RAM to check. For now, I think I like your theory of 0x580x-5FFx, though, as I'm not sure why they'd need the lower address lines going to the PAL if not for this.
krzysiobal wrote:
Very good:
Can I ask for ROM so that I can test it on my fpga cartridge?
BTW. 168-in-1 multicart does not have any external register, but it still remembers the position of last chosen game after resetting console.
Never mind, I found that I have this ROM with date of 2011-11-04 so probably it's not so new (and PRG & CHR CRC matches the one you said).
If your PRG and CHR match my CRCs than I'm sure you've got the same thing as me. As MLX mentioned earlier, it looks like it was successfully dumped before. I was just basing my knowledge on google searches that said no known good dumps existed, and the one I found to compare with my dump was indeed bad. It looks like someone else did have a good dump, and it's nice to have confirmation that my dump matches someone else's.
As for the resetting, I can think of two ways of keeping the game list position on reset:
1. If they can free up a byte somewhere in all the games you can store it internally. (Maybe reducing the stack size of the games by 1?)
2. If the reset vector for each game writes its own menu values to internal RAM before switching to the bank where the MENU is, that should work.
In any case, this game's menu code was clearly designed with the RAM in place, and not changed when it was removed. Otherwise, the list wrapping wouldn't have required it to work properly. Also, the Cheat/Hacks/Trainers value might have worked as well.
Note that because the RAM is missing, on the actual cart, the menu selections that are supposed to affect gameplay don't work properly. For example, all versions of The New Human/Super Man #(Dino Riki, I think?) have him shooting clones of himself. On the emulator with RAM enabled, the projectiles are different (fireballs, boomerangs, clones) when different versions are selected. Title screen color similarly is different with RAM, and the same on the actual cart (my copy without the RAM).