It is currently Fri Jan 19, 2018 2:40 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Dec 18, 2017 10:47 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
I have been working on expanding a Famicom Tiny Tune Adventures cart (VRC4e) with the following upgrades:

  • 512k Flash PRG ROM
  • 512k Flash CHR ROM
  • 32k W-RAM
  • John's Missing Pulse Detector + 74LS168 counter to select games with reset button

The goal here is for the cart to boot up normally as Tiny Tune Adventures, then cycle through 4 additional games as you press Reset on the Famicom.

Here are the games I am trying to use:

  • Crisis Force (VRC4e)
  • Gradius II (VRC4b)
  • Bio Miracle (VRC4b)
  • Ganbare Goemon 2 (VRC2b)

(Side note: I do not know a good way to find out the 'x' in VRC4'x'! The iNES mapper narrows it down to 2, then I had to run the ROM in fceux and set breakpoints on VRC4 registers to figure it out!)

Anyway. I did some footwork ahead of time and hacked each of these games into VRC4e. I did this using fceux and setting breakpoints on writes to all VRC4 registers, then changed the address written to for all of these. Once I got the cartridge built, I loaded these hacked games onto my ROMs, and had some varying degrees of success.

  • Bio Miracle - Perfect.
  • Crisis Force - Worked, but had some minor graphical glitches, playable
  • Gradius II - Worked perfectly occasionally if I cycled through the games quickly (i.e. tap reset quickly) and landed on it, otherwise crash.
  • Ganbare Goemon 2 - same as Gradius II.

First thing I tried is putting the games in a different order in PRG ROM. (I wanted to test if it was specific to where I had them in ROM, etc.). In fact, all 4 games appeared to boot up this way, at least more likely to succeed (not a very thorough test...). This tells me that something left behind from the previous game could make or break the next game. Since I do not remove bias from the VRC4 chip or the RAM chip, it is definitely possible to bring VRC4 control registers and data in W-RAM through to the next game, which may be relying on power-up states. Hmm...

I have a Game Genie modified for use with Famicom. Cleverly, I hooked the Tiny Tunes cart through the Game Genie and I was able to power up, press reset the correct number of times, and then press Start. This created a pseudo cold-start condition into each game. Ganbare Goemon 2 never worked this way. Gradius II starts with incorrect CHR data (i.e. incorrect CHR page selected or something), then you press start and everything clears up and looks normal, lets you select your weapon options, and as soon as the game starts, you die immediately. Then the level starts over and you die again, and again a 3rd time for game over. Everything else works. This feels like one of those Konami pirate gotchas kicking in or something. The other 2 games did work fine from the Game Genie cold start.

Leftovers in RAM got me thinking more about W-RAM. I am only supposed to have 2k W-RAM and I had hooked up the full 32k using additional PRG address lines from the PRG-ROM. 32k in fact would map RAM over top of some of the VRC4 control registers if you kept counting up 32k from $6000! I am thinking that would be a bad thing.

Also, I had connected my RAM chip's R/W pin directly to the VRC4 chip instead of using the diode/82pF/1kohm noise filter as populated in carts that came with W-RAM. (I found this looking at pictures in NesCartDB) I added this filter and undid my extra address lines (connected my 4 MSB address lines to GND on the RAM chip). This FIXED the graphical issues in Crisis Force. Not quite sure what was technically happening but that fixed it. No other effect noticed in any other game.

Next I was reading more in the NesDev wiki article on VRC2/VRC4 and I found this, specific to Ganbare Goemon 2:

Quote:
Several games, including Contra (J) and Ganbare Goemon 2 (J), rely on the two Data pins being connected to each other, and so expect to be able to read the written value back. In these cases, the LSB agrees with the last value written and the upper seven bits are open bus, e.g. both LDA $6100 and LDA $6000 will return $60|latch. Returning neither open bus nor 0x00 will work, and these games will lock almost immediately after execution begins. Fortunately, no games ever rely on any other behavior.


I ran Ganbare Goemon 2 in fceux and set it to break on reads from $6000 and $6100. It STAs to those registers and immediately LDAs them back, so I just NOPped out the LDAs. That FIXED Ganbare Goemon 2. That game always works now in the Tiny Tunes cartridge, no tapping of reset required, cold boot via Game Genie OK. However, I do not understand this one. If I had W-RAM available in the range $6000-$6FFF, why wouldn't it have stored the write to $6000 in the RAM chip and read it back?? And why did it sometimes run if I quickly cycled through games and landed on Ganbare Goemon 2? Hmm...

And that leads me to where I am now tonight. All games work, except Gradius II is behaving just like Ganbare Goemon used to behave. I have to hit reset a lot and land on Gradius II for it to work. Gradius II does read and write to $6000+, but it is expecting to find W-RAM there.

Does anyone have any ideas why this tapping reset thing works for Gradius II and why I can not cold start that game on my VRC4e board? My RAM chip clearly works in Crisis Force and Gradius II, or else I could not imagine those games would be able to run at all without it functioning correctly. So I don't really suspect the RAM chip I guess. I do not know what to try next.


Attachments:
File comment: Front Side
vrc4_front_side.JPG
vrc4_front_side.JPG [ 377.15 KiB | Viewed 716 times ]
File comment: Back Side
vrc4_back_side.JPG
vrc4_back_side.JPG [ 340.32 KiB | Viewed 716 times ]
Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 11:11 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6640
Location: Seattle
The only guess I have is: is your 74'168 incrementing its count when reset starts, or when it ends?


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 11:54 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
lidnariq wrote:
The only guess I have is: is your 74'168 incrementing its count when reset starts, or when it ends?

It increments when reset starts. "John's Missing Pulse Detector" looks for a gap larger than 1 msec on the PRG A0 line. When it detects this gap, its output rises to high. When A0 starts toggling again, its output goes low again.

74'168 is a positive edge triggered counter, so it will increment when you press in reset and will stay the same when you let go of reset. I tested that the count sequence is correct out of the '168. The 2 least significant output bits connect to the most significant 2 address bits of the flash ROM, so as to split it up into 4 equal pieces for the 4 games I put on there.

It is hard to see in the picture, but I do deselect the original Mask ROMs. I have removed the solder and inserted a small plastic tube into the PCB to isolate the /CS pins, and I control them with some gates and using the most significant bit of the '168.

I think you are onto something with that though. I will take some plots tomorrow what happens to A0 and the counter clock when I press reset, thanks.


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 12:55 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
Here are some scope plots. This shows when selecting Gradius II when it fails to run. PRG A0 toggles for a little bit and then stops dead. A0 stops indefinitely in this condition. Because A0 stopped, it does clock the 74'168 as a side-effect, but the A0 stops toggling well ahead of this (shown in a scope plot to be 1.8 msec per the intended behavior of the missing pulse detector). Therefore, the resulting 74'168 clock is only a side-effect, and not the cause of this.

Also note, this issue only occurs with Gradius II and none of the other games in the cartridge.

How is it possible for A0 to stop toggling? Can the 6502 actually stop? I can see how it would run off and do crazy random stuff but I did not know it was possible to actually stop.

On an unrelated note, here is the W24257AJ RAM chip that I used. This chip was scavenged from an old hard drive.


Attachments:
A0_overview.png
A0_overview.png [ 23.89 KiB | Viewed 655 times ]
A0_stopping.png
A0_stopping.png [ 18.31 KiB | Viewed 655 times ]
Resulting_missing_pulse_detection.png
Resulting_missing_pulse_detection.png [ 20.35 KiB | Viewed 655 times ]
Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 1:08 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6640
Location: Seattle
Ben Boldt wrote:
How is it possible for A0 to stop toggling? Can the 6502 actually stop?
While /RESET is asserted, the 2A03 sets all of its outputs to high impedance.

(The bare 6502 doesn't)


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 1:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19487
Location: NE Indiana, USA (NTSC)
The 65816 has an instruction STP ($DB) that stops the CPU until reset. The 6502 has the same instruction, but with different opcodes ($02, $12, $22, $32, $42, $52, $62, $72, $92, $B2, $D2, $F2).

When not in STP or reset, the 6502 will toggle A0 at least once in the first two cycles of each instruction, and at least twice per instruction that doesn't use "implied" addressing mode. These "implied" instructions that don't access memory (e.g. LSR A, TAX, CLC) tend to be the shortest anyway, usually 2 cycles.


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 5:17 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
So, theoretically I could have an arbitrary PRG page selected in the previous game, switch to Gradius II, then Gradius II relies on the default states of PRG pages, and so it executes data from the correct page sometimes and works, or from the incorrect page sometimes which happens to contain one of these halt opcodes. That seems like a reasonable explanation.

Where can I find the default PRG pages? I looked at the source of Nestopia and FCEUX and I could not figure it out. I think I can break right away in FCEUX and find the right initial pages, but then how do I write the page? The article here says there are 4 PRG page select registers, but there are only 2 PRG windows... I am not sure what to write to these registers.

There is space in Gradius II right before the vector table where I could put some code to write correct default values to the VRC4 registers. I tried just blindly writing $00s to all VRC4 registers with this method and that was not successful fixing it but it could STILL work with reset tapping. I'm not sure what writing 00s does though, or if that could be expected to produce a consistent behavior anyway.

Also, this game never starts with correct CHR with the Game Genie 'cold start' trick. This method would hopefully have preserved the default VRC4 state which therefore appears to be wrong for this particular game...


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 5:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6640
Location: Seattle
Most ASIC mappers don't have intentionally defined power-up state; their contents may be random. This is why so many mappers have a fixed bank holding the reset vector.

The most obvious way to trip up a VRC2-using game is if the previous VRC4-using game switched the PRG banking style by writing to $9004... but that's not the problem you're reporting.


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 8:28 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
I agree lidnariq, and I will back that up by saying that the game does appear to write to most VRC4 registers, so it seems like it is doing a pretty good job initializing the VRC4 from an unknown state.

I modified the Gradius II ROM I am trying to run from VRC4b to VRC4e. This game writes to ALL of these registers:

B00x, C00x, D00x, E00x, F00x

The game also writes to 800x, 900x, and A00x where x == 0, but none of the ones where x != 0. I do not know if that means anything or not.

I modified these writes in the ROM as follows (IPS file attached):
x000 -> x000 (no change)
x002 -> x004
x001 -> x008
x003 -> x00C

I also changed the iNES mapper to reflect this change and the ROM runs perfectly in FCEUX like nothing ever happened. I was able to play deep into the game through several bosses using some cheats.

This is very strange and confusing!!


Attachments:
File comment: Gradius II (J) [!] converted from VRC4b to VRC4e
Gradius II (J) [!] VRC4e.ips [187 Bytes]
Downloaded 10 times
Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 8:43 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
lidnariq wrote:
[...]This is why so many mappers have a fixed bank holding the reset vector.

The most obvious way to trip up a VRC2-using game is if the previous VRC4-using game switched the PRG banking style by writing to $9004[...]

By this logic, have we proven that VRC4 must have a defined power-up state of $9004 so that a known bank holds the reset vector?

The only alternative would be to implement alternate vector tables on each possible page.


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 9:14 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6640
Location: Seattle
VRC4's "bank layout" control register, like MMC3's, only specifies whether the bank at $8000-$9FFF or the bank at $C000-$DFFF is switchable. The 8 KiB from $E000-$FFFF are known fixed regardless.


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 11:51 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
lidnariq wrote:
VRC4's "bank layout" control register, like MMC3's, only specifies whether the bank at $8000-$9FFF or the bank at $C000-$DFFF is switchable. The 8 KiB from $E000-$FFFF are known fixed regardless.

Okay, I understand that now, thanks.


Top
 Profile  
 
PostPosted: Thu Dec 21, 2017 4:59 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
More findings today with a logic analyzer. This is a 20-bit logic analyzer, so please bear with me that I was not able to capture the entire picture of the PRG bus. I got A0 - A15 of the PRG-ROM chip, and I got D0 - D3 of the PRG-ROM chip. A16, D4-D7, and /CS are not measured in these captures.

For this test, I disconnected all control from "John's Missing Pulse Detector" and the 74'168. Those things are completely out of the picture now.

I hard-wired the following:

  • Mask ROM /CS high
  • Flash ROM was originally divided into 4 partitions with highest 2 address bits connected to 74'168.
  • Now, Flash ROM highest address bit A18 = 0 (never use the 2 upper partitions)
  • Flash ROM A17 hooked to a toggle switch, can be set 0 or 1 manually to select Crisis Force or Gradius II.

I verified that Crisis Force still works fine every time from cold boot. Zero issues. I played the game a little and did not notice anything unusual.

Then I flipped the switch over to Gradius II. This is a true cold boot of Gradius II on this cart now, no Game Genie. It almost always has a gray screen. The reset trick does not work anymore with the cart hardwired to Gradius II. Reset does unlatch the Famicom and it starts over just like toggling power. I measured with my scope the length of time that the game executed before locking up. I made this measurement by cycling power to the Famicom about 100 times. The time varied. The shortest time until crash was 32.82 msec, and the longest time was 65.58 msec. ONE TIME out of ~100 tries the game ran and kept running. The part where it slowly draws out the word "Gradius" worked fine but everything else had wrong CHR data displayed. Looping several times, stayed the same, wrong CHR data except Gradius word being drawn out.

I have attached some scope plots. I have not yet investigated the spot where it crashed after fetching data $[x]2 from ROM chip address $[x]C031, but I ran it 3 times and that was always the last address fetched, even though the length of time executing was different. I will look into this later tonight.

lidnariq wrote:
Ben Boldt wrote:
How is it possible for A0 to stop toggling? Can the 6502 actually stop?
While /RESET is asserted, the 2A03 sets all of its outputs to high impedance.

(The bare 6502 doesn't)

The address bus did all jump high after the lockup, which does support the high impedance scenario, lidnariq.


Attachments:
File comment: Crisis Force fetching its reset vector, running normally.
Crisis Force Logic Analyzer.png
Crisis Force Logic Analyzer.png [ 34.88 KiB | Viewed 460 times ]
File comment: Gradius II Fetching the reset vector from $1FFFC:1FFFD, I forgot that I left test code on here.
Gradius II 1.png
Gradius II 1.png [ 34.19 KiB | Viewed 460 times ]
File comment: End of my RAM clear routine, jumping to the original reset vector location as intended
Gradius II 2.png
Gradius II 2.png [ 33.82 KiB | Viewed 460 times ]
File comment: Change of behavior of address buss (no particular concern)
Gradius II 3.png
Gradius II 3.png [ 33.44 KiB | Viewed 460 times ]
File comment: End of execution before lockup. The address bus all went high.
Gradius II 4.png
Gradius II 4.png [ 32.23 KiB | Viewed 460 times ]
Top
 Profile  
 
PostPosted: Thu Dec 21, 2017 5:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6640
Location: Seattle
Except that there's nothing in the 2A03 that can cause it to stop driving its outputs other than /RESET externally be driven low. (Whether by the CIC or the reset button in a Famicom)

Briefly playing around with Mesen, you shouldn't be even executing code in the $Cxxx range during the initial splash screen at all...

[Gradius II 3.png]
Those times when the bus shows C1FF and C1FE ... are supposed to be stack access at 01FF and 01FE. Right. So when I see C1F9, C1FA, C1FB in [Gradius II 4.png], that should be popping the PC and flags off the stack due to an RTI.

Kinda looks to me like something's corrupting the stack, and it's returning to data, not code. It fetches an instruction from 0xC030 (whatever that actually means) that ends with a "2" and that causes the CPU to stop executing code.

Apparently that 2 also starts the interrupt (BRK) fetch routine? I don't think anyone's actually traced down what else happens after a KIL instruction (since it's largely unrecoverable)


Top
 Profile  
 
PostPosted: Thu Dec 21, 2017 7:20 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 30
Location: Minnesota
lidnariq wrote:
C1FF and C1FE ... are supposed to be stack access at 01FF and 01FE

I am analyzing the bus at the PRG-ROM chip, which is after paging modifications made by the VRC4 chip. Do you think this can explain the 'C' part and it could have been actually accessing 01FF/01FE from the Famicom's own internal RAM chip?

I have to say, this is a lot of fun and it is all quite fascinating to me.

Edit:
I think my plan of attack tomorrow will be to get a logic analyzer dump into the scope, which thankfully fits all into 1 capture, and then zoom in to the middle and compare it to FCEUx debugger. If I can find that spot and trigger a breakpoint there right away in FCEUx, then then I could suspect that the famicom is still good at that point, and I should repeat this with the center of the right half. Otherwise if it clearly broke, go to the middle of the left half, etc, until I narrow it way down. Hopefully this leads somewhere!


Last edited by Ben Boldt on Thu Dec 21, 2017 9:41 pm, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group