My first test (and failure) of Battletoads! :)

[jwdonal]

Hey guys, I've been working on implementing some mappers for my VeriNES. I couldn't help but implement mapper 7 (AxROM) to test Battletoads. Here is a link to the post on my site (more details and video there):

https://rm-rfroot.net/nes_fpga/index.ph ... toads.html

I have known (and unknown) bugs in my NES (mostly PPU) which I have yet to fix but I just wanted to give Battletoads a shot to see if it would even run. If any of you gurus out there notice something that you think you know what the problem might be - PLEASE chime in!!

Pz!

Jonathon

[tokumaru]

Well, there are some obvious mirroring issues there... Did you implement the name table selection used by AxROM?

[tepples]

See that garbage sprite at the top left while the flicker is happening? That's a clue that there's a problem with sprite 0 hit. Either the background isn't scrolled right (which indicates a CPU or PPU timing problem), or the wrong background is loaded (which could indicate a mirroring problem, as tokumaru mentioned).

[jwdonal]

Hmmm...ok. Well, I'm pretty sure that I have the mapper implemented correctly. I also implemented mappers 2 and 3 and the majority of those games all work perfectly. I implemented mapper 7 in a similar way as mapper 2 with respect to PRG bank selection bits (except that mapper 7 doesn't have a fixed bank). So I'm pretty confident that the PRG bank selection bits are in the correct position. The one thing that is the big difference (well not that big) is being able to control the H/V mirroring bit. Maybe I need to invert the polarity of the H/V mirror control bit from the mapper? I was just using the same polarity as I had originally implemented for the fixed H/V mirror bit. I'll invert the polarity and see what happens. Worth a shot!! I will let you know if it fixes anything. Thanks for the help guys!

[Disch]

being able to control the H/V mirroring bit. Maybe I need to invert the polarity of the H/V mirror control bit from the mapper?

This mapper never uses H or V mirroring. It's always 1-screen. It switches between "1ScA" and "1ScB"

[tokumaru]

So I'm pretty confident that the PRG bank selection bits are in the correct position.

Probably, since the game IS running.

The one thing that is the big difference (well not that big) is being able to control the H/V mirroring bit.

AxROM doesn't have H/V selection, it uses single screen mirroring, meaning that the same name table is visible in all 4 slots, and that bit selects which name table ($2000 or $2400) this is.

[jwdonal]

Ok, so now I'm definitely confused. I'm going to try to be more specific with what I was thinking.

I was thinking that the M bit shown in the AxROM control register is supposed to control which PPU address line (i.e. bit 11 or 10) is connected to the PPU CHR-RAM address bit 10 as it does with the blob of solder used in NROM/UxROM/CNROM games. Is that not correct?

Another way of saying it is that the AxROM control register bit M is just a "dynamic"/"real-time" replacement for the static/fixed blob of solder used by NROM/UxROM/CNROM games.

Is that completely incorrect? Haha.

THANKS!!

[Disch]

NT mirroring is the same idea as bankswapping.

You have 4 "slots": $2000, $2400, $2800, $2C00

And there are 2 physical nametables: NTA, NTB

The mirroring mode just changes which nametables are put in which slots.

Horizontal mirroring:
- NTA at $2000 and $2400
- NTB at $2800 and $2C00

Vertical mirroring:
- NTA at $2000 and $2800
- NTB at $2400 and $2C00

One screen A ("1ScA"):
- NTA at $2000, $2400, $2800, and $2C00
- NTB not accessable

One screen B ("1ScB"):
- NTA not accessable
- NTB at $2000, $2400, $2800, and $2C00

[tepples]

Hmmm...ok. Well, I'm pretty sure that I have the mapper implemented correctly. I also implemented mappers 2 and 3 and the majority of those games all work perfectly. I implemented mapper 7 in a similar way as mapper 2 with respect to PRG bank selection bits (except that mapper 7 doesn't have a fixed bank).

UNROM (mapper 2) minus its fixed bank is BNROM (mapper 34), used in Deadly Towers. BNROM with 1-screen mirroring is AOROM (mapper 7).

The "dynamic real-time replacement for the blob" is present in MMC1 (mapper 1), MMC3 (mapper 4), and most other ASIC mappers. MMC1 boards can use all four common mirroring configurations (AABB horizontal, ABAB vertical, AAAA single A, and BBBB single B). MMC3 is either less flexible or more flexible depending on the board: mapper 4 boards support only horizontal and vertical, while mapper 118 boards (TKSROM and TLSROM) support arbitrary assignment of A and B, allowing diagonal and L-shaped mirroring as well.

[tokumaru]

I was thinking that the M bit shown in the AxROM control register is supposed to control which PPU address line (i.e. bit 11 or 10) is connected to the PPU CHR-RAM address bit 10 as it does with the blob of solder used in NROM/UxROM/CNROM games.

The blob of solder selects which bit gets routed to CIRAM A10 (it's either CHR A10 or CHR A11), but AxROM doesn't rout anything, it just sends to A10 the bit that was written to the mapper last. This means that only one name table is accessible at a time, the one defined by the M bit.

[jwdonal]

The blob of solder selects which bit gets routed to CIRAM A10 (it's either CHR A10 or CHR A11), but AxROM doesn't rout anything, it just sends to A10 the bit that was written to the mapper last. This means that only one name table is accessible at a time, the one defined by the M bit.

HOLY CRAP! Okay, that was a huge mis-understanding on my part! Thanks SOOO much tokumaru. That was a _very_ important bit of information. I was thinking that the M bit changed the routing of the address lines just like the blob of solder (only dynamically)! Now I understand!!!

I'm going to go ahead and implement this now and see what happens!!

YOU GUYS ROCK!!

Pz!

Jonathon

[jwdonal]

YOU GUYS ARE A-W-E-S-O-M-E!!

IT'S WORKING!!! Well, at least 100x better anyway. There are still some very obvious bugs but I think my implementation of the mapper and mirroring is now correct. I'm guessing that the remaining bugs are rooted at the most basic level of my PPU logic (which as I said before has known bugs).

But WHO CARES!! I'm running playable versions of Battletoads and Marble Madness on my emu!!!! KICK-ASS!!!!!!!!!!!!!!!!!!!!!!

Haha, and is it just me or is the segment starting at 1:34 of my new Battletoads video hilarious?! She is bouncing all over the place and to the beat of the music no less! LOLOL. If someone has any idea how the music could possibly be causing the screen to move up and down I'd love to hear from you. In the previous test video the music was making the screen flicker on/off, but now it's moving up and down. Haha.

I seriously cannot thank you guys enough. I am so excited about this!!! And if anyone sees any other obvious issues that they think they know the cause just lemme know!!!

Oh, and the new videos of both Battletoads and Marble Madness (which FYI I totally suck at) are on the site listed in my original posting. Much of what I said on my site is just a copy of what I wrote here.

Pz!!

Jonathon

[*Spitfire_NES*]

nice work brother!

[Dwedit]

The sound is horrific right now. Even old Nesticle, which didn't emulate sweeps, volume envelopes, or even duty cycle, at least had the correct pitch.

[jwdonal]

nice work brother!

Thanks!

The sound is horrific right now. Even old Nesticle, which didn't emulate sweeps, volume envelopes, or even duty cycle, at least had the correct pitch.

It's probably just my audio encoder. When I compare the audio from Nestopia to that of my emu it sounds exactly identical. Seriously, the input audio port on my computer is messed up and sounds like junk.