battletoads (single screen)

battletoads (single screen)
by Anes on 2005-09-28 (#4975)

After trying and trying i cant get battletoads to work in my emu, it hangs after the toad drop off the ship. I can hear the music but cant see any graph, the screen is blank.
I was wondering, wouldnt be single screen problem?
Im doing the following:

- when the games want to change the name table (0 or 1) i change my 4 pointers to point to the name talbe it wants (i have 0x400 * 4 external memory to handle name wich has nt data, and the appropiate functions and pointers to handle this memory area). I mean:

Code:

lpNT[0] = g_NTMEM + NT * 0x400;
lpNT[1] = g_NTMEM + NT * 0x400;
lpNT[2] = g_NTMEM + NT * 0x400;
lpNT[3] = g_NTMEM + NT * 0x400;

Where NT is what battletaods chooses via a write to 0x8000+ bit D4.

is that correct? if not can somebody explain me how real single screen works, cos what i understand by "all four cuadrants points to the same name table" is that what i wrote.

Thanks in advance.

by WedNESday on 2005-09-28 (#4978)

Exactly the same things happens on my emulator. When the toad drops before he gets to the ground the game just freezes. I think that it is to do with my sprite 0 hit detection as I am still getting an error in NEStress.

Maybe the game requires precise timing?

by tepples on 2005-09-28 (#4979)

Battletoads requires unbelievably precise timing.

by WedNESday on 2005-09-28 (#4980)

Since Battletoads is an AOROM (mapper 7) it is no wonder that it requires that much timing. Anes, is your emulator precise?

by Quietust on 2005-09-28 (#4990)

WedNESday wrote:
Since Battletoads is an AOROM (mapper 7) it is no wonder that it requires that much timing. Anes, is your emulator precise?

Correlation is not the same as causation - there are plenty of Mapper 7 games which do not use insane timing. The actual reason behind the timing insanity is that the game was written by Rare/Coin-It.

by Zepper on 2005-09-28 (#4999)

Firstly, you *should* write a debugger. I'm sure the hang occurs because of sprite #0 hits - there's no background pattern due to ppu scroll reset timing. YES, my emulator has a similar problem - the game works, but it hangs "randomly" on Impact Crater stage *due to* sprite #0 (infinity loop).

Secondly, it might be a CPU bug. Don't trust NEStress.

by Bregalad on 2005-09-28 (#5003)

Quietust wrote:
Correlation is not the same as causation - there are plenty of Mapper 7 games which do not use insane timing. The actual reason behind the timing insanity is that the game was written by Rare/Coin-It.

Scince Rare is basically a british software company, the game was originally written for the PAL format, so it's why it uploads to much tiles during VBLank, that is MUCH longer under a PAL screen, right ?
The PAL version of Battletoads probably doesn't use any tricky timings scince the VBlank is long enough to upload all the large array of graphics the game needs each frame, then the PPU can be constantly turned on, unlike the NTSC version.
Maybe if would be easier to first get the PAL version to work ?

About single screen miroring, I'm pretty much confused myself. Does that mirroring apply only while reading data, or for both read and write to the name table ? If it's both, then the nametable used for all 4 screens is determined by the single mirroring bit regardless of if the game write or reads it. In that case, it would probably change several times in a single VBlank while uploading status bar's tiles and playfield tiles.
Else, that would mean that write to PPU $2000-$23fff will write to nametable 1, and write to PPU $2400-$27fff will write to nametable 2. Then, when the screen is rendered, only the name table 1 or 2 is used in function of the 1-screen mirroring bit. That would make programmer's live easier, but it would need extra logic on the cartridge.
I don't know wich one of those is correct for a mapper 7 game. And what about a MMC1 game in single screen mode ?

by Disch on 2005-09-28 (#5004)

When a game is in single-screen mirroring mode... one and ONLY one nametable is accessable... the other is completely out of range until "swapped in" by changing one-screen modes (or changing to a different mirroring mode).

So a game will need to flip between nametables by changing the mirroring mode when writing tiles to $2007.. unless it only needs to write to one nametable.

Or as Bregalad put it... one screen mirroring applies to both reading/writing.

by mattmatteh on 2005-09-28 (#5013)

Secondly, it might be a CPU bug. Don't trust NEStress.

what is wrong with nestress. i cant get that to work yet but was going to use it. i can get some demos to display ok, but alot of games just show a grey screen, few black...

matt

by Anes on 2005-09-30 (#5063)

i did the following in my emulator and surpricely battletaodas passed the "sprite 0 hit" detection. What i did was to decrece the amount of scanlines in vblank (a thing that i dont understand cos its supposed that there are 20 scanlines of vblank).
i have a question when a rom has the type xxx (U).nes that is mean that si NTSC?
Where can i find a doc about this "nomenclature"?

by tepples on 2005-09-30 (#5066)

(J) = Japan, NTSC
(U) = North America, NTSC
(E) = Europe, PAL

Full list of GoodCodes

by Zepper on 2005-10-01 (#5080)

Well, you have a sprite #0 test, but it's nothing more than a sprite #0 test over a canonical background pattern. You should pay attention about a complex image - if the PPU scroll registers are reset in a wrong time, sprite #0 will fail out (no background pattern at that time).

by Disch on 2005-10-01 (#5082)

Anes wrote:
What i did was to decrece the amount of scanlines in vblank (a thing that i dont understand cos its supposed that there are 20 scanlines of vblank).

That's what we call a "hack". In that you're doing something else wrong to cancel out the thing that's wrong... rather than fixing what is initially wrong. ;P

Er... so yeah... there ARE 20 scanlines of VBlank. This isn't the way to fix your problem... and will potentially break other games besides Battletoads.

by WedNESday on 2005-10-01 (#5086)

Since a real NES can run all games using the same engine, a good emulator will do also. Leave the number of VBlank scanlines at 20 as this is correct. Making your emulator custom for certain games is what very old (and therefore crappy emulators used to do). Never introduce hacks for games, if it doesn't work then go back and find out why, as this is considered good programming practice.

by blargg on 2005-10-01 (#5104)

WedNESday, I imagine your enthusiasm for supporting the hardware exactly might wane when you find out all the intricate details. I've been testing the PPU's VBL flag recently and it's quite intricate (yes, the simple behavior of being set and cleared automatically).

I don't think there's anything wrong with an emulator running a limited set of games, as long as it's not being claimed to be a full NES emulator or that it emulates those games correctly. Some reasons for writing an emulator have little to do with general accuracy. There's an odd elitism I've seen here recently regarding the "correct" way to experiment with NES emulation. Obviously there is only one correct NES emulator (one that performs exactly as the hardware does), but that's not the only possible goal. This elitist attitude takes the fun out of writing an emulator and discussing it here.

by WedNESday on 2005-10-01 (#5105)

I never meant to be mean or anything...

I think the that there are 2 bottom lines when it comes down to emulation. 1. You write the emulator for fun or 2. You write the emulator for serious accuracy. I think that 1 wins hands down every time.

by blargg on 2005-10-01 (#5108)

I certainly agree that a claim of accuracy at the very least requires a pixel-accurate PPU rendering, not scanline-based. Maybe the criticism of inaccuracy is based on Nesticle and the common belief that it's the standard in accuracy.

But regarding goal 1 (fun), one needs a reasonable amount of accuracy for an emulator to be fun. When I first wrote my emulator it rendered the whole screen at once, so the status bar at the top scrolled with the screen. It was somewhat fun, but not near as much as when I improved it to scanline accuracy. There are so few games (that I know of) that require more than scanline accuracy that it's not worth it in terms of fun. Limiting accuracy to scanlines makes rendering simple to code and very fast (I can run 11 emulators tiled on screen at 60 fps on my 400 MHz Mac). Because of this, I think aiming for "mere" scanline accuracy isn't a reason for criticism.

by tepples on 2005-10-01 (#5109)

Can you make your scanline emulator emulate part-of-a-scanline? If so, it'd be easy to bring it up to pixel accuracy. Start by simply running the CPU ahead of the PPU and then having the PPU catch up to the CPU on every CPU$2xxx write. See which games screw up under that.

by blargg on 2005-10-02 (#5118)

Quote:
Can you make your scanline emulator emulate part-of-a-scanline?

Yes, I remembered this after I posted. Most of the time rendering covers multiple scanlines, which can be optimized using a scanline-granularity renderer (which actually renders n scanlines at a time, where n >= 1). When there's a partial scanline, then things need to be done pixel-by-pixel (for that scanline only). I guess the main barrier to this is the complexity and small benefit it brings. If there were more NES demos that relied on these things, it might be more encouraging for an emulator author to go all the way.