This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Attention: wAMMA

Attention: wAMMA
by on (#30794)
http://pouet.net/prod.php?which=31326

I tried commenting in that thread, but every time I tried to register I got "WTF ERROR" and it didn't tell me what the error was.

I know visy stops by here every once in a while. Hopefully he'll see this. I don't know how else to get in touch with him.


Anyway... I tried that demo in my emu after someone reported it was messing up. Assuming you tried this on a real system, I figured it was a bug in my emu. So I traced what was happening and found several errors that were not due to my emu.

1) you don't turn off the PPU before letting it warm up (you may not technically have to -- but you probably should.)
2) you don't back up your registers on NMI
3) you enable NMIs during VBlank, without first clearing the VBlank flag (this triggers an immediate NMI)


2 and 3 cause the monochrome bit to flip on in my emu, because an NMI is triggering right before the write to $2001. Here's a truncated trace log:

Code:
A8C6:A9   LDA  #$88                  00 07 10 [..I..]  FF --   9,186 -- <0000,0000>
A8C8:8D   STA  $2000      [2000=00]  88 07 10 [N.I..]  FF --   9,192 -- <0000,0000>
A8CB:A9   LDA  #$1E                  88 07 10 [N.I..]  FF --   9,205 -- <0000,0000>
*** NMI ***
CE8B:AD   LDA  $2002      [2002=82]  1E 07 10 [..I..]  FC --   9,234 -- <0000,0000>
...
893C:BD   LDA  $0300,X    [0300=3C]  03 00 00 [..I..]  F8 -- 166,274 -- <0000,0000>
893F:4A   LSR  A                     3C 00 00 [..I..]  F8 -- 166,287 -- <0000,0000>
8940:4A   LSR  A                     1E 00 00 [..I..]  F8 -- 166,294 -- <0000,0000>
8941:1D   ORA  $0394,X    [0394=10]  0F 00 00 [..I..]  F8 -- 166,300 -- <0000,0000>
8944:BC   LDY  $8AD1,X    [8AD1=00]  1F 00 00 [..I..]  F8 -- 166,313 -- <0000,0000>
...
CF59:40   RTI                        1F FF 00 [..I..]  FC -- 167,154 -- <0000,0000>
A8CD:8D   STA  $2001      [2001=01]  1F FF 00 [..I..]  FF -- 167,173 -- <0000,0000>


The $2000 write is occuring when the VBlank flag is high, which immediately triggers an NMI (after the LDA). The NMI then changes A to $1F, and when you RTI... $1F, instead of the desired $1E, is being written to $2001, causing monochrome mode.

this can be solved by any one of the following:

1) clearing the VBlank flag by reading $2002 before you write to $2000

2) backing up A on NMI entry, and restoring it on exit

3) not writing to $2000 until the very end of your prep code (just before the infinite loop)


If you are testing this on a PowerPAK, it is likely interfereing with the startup time (ie: your code is being jumped to at a different time in the frame than it would be if you were on a normal cartridge -- meaning it's possible/likely that the glitch that is happening on my emu would happen if your ROM was on a normal cart).

However, if you are testing this on a straight cart with no additional software/BIOS running, please let me know so I can adjust the powerup time in my emulator.

Thank you.


PS - please don't give your .txt files an .nfo extension.


To anyone else: If you know how to contact visy or anyone else on the wAMMA team, please direct them here for me. Thanks.

by on (#30797)
Quote:
2) you don't back up your registers on NMI


Does that mean that I should do an IRQ-style backup of all 6502 registers, pushing them to stack?

Quote:
3) you enable NMIs during VBlank, without first clearing the VBlank flag (this triggers an immediate NMI)


This is probably just some bit toggled when it's not supposed to be, ah, the miracles of democode...

Quote:
Anyway... I tried that demo in my emu after someone reported it was messing up. Assuming you tried this on a real system, I figured it was a bug in my emu. So I traced what was happening and found several errors that were not due to my emu


Surprise that there's some bugs there :) This demo was coded very quickly a few days before the party, and even during the party I was hacking the code during the first night to make it work.

Thanks for pointing out the issues, though.

Quote:
If you are testing this on a PowerPAK, it is likely interfereing with the startup time (ie: your code is being jumped to at a different time in the frame than it would be if you were on a normal cartridge -- meaning it's possible/likely that the glitch that is happening on my emu would happen if your ROM was on a normal cart).


I'm actually testing on a FunkyFlashCart, which I think is a "normal" cart.

Quote:
PS - please don't give your .txt files an .nfo extension.


Sorry, this is sort of a demoscene standard on how to name your infofiles... :)

by on (#30799)
Don't mind the NFO comment; he's new to demoscene stuff. ;)

by on (#30806)
visy wrote:
Does that mean that I should do an IRQ-style backup of all 6502 registers, pushing them to stack?


Normally I would recommend it... but since your program is just an infinite loop outside of the NMI routine, it makes sense that you're not doing that. While this would be a solution in this case, I don't think it's the best solution. I think clearing the VBlank flag is probably the way to go:

Code:
LDA #$88
BIT $2002  ; clear VBl
STA $2000  ; okay to raise NMI flag now
LDA #$1E
STA $2001
; ...etc



Quote:
I'm actually testing on a FunkyFlashCart, which I think is a "normal" cart.


This is good to know. It suggests the powerup timing in my emu is off. Looks like I'll have to pull it forward 10 or so scanlines.

In that event... nothing is really wrong with the demo -- it's just getting lucky that the timing is working out. I still would recommend fixing that issue though -- in case you ever need to change the powerup code or something... or in case the powerup time varies on different systems or something.

Quote:
Sorry, this is sort of a demoscene standard on how to name your infofiles... :)


Heh... alright. Seems weird to me, but whatev.

Thanks for replying. And good work on the demos.

by on (#30807)
It's a European production, I suppose it's been tested on a PAL NES. Try booting it in PAL mode, Disch, it works fine here on my emu (and not with NTSC).

by on (#30808)
I was testing it in PAL mode ;P

Anyway I pushed my PAL powerup time back to 20 scanlines before the end of VBlank and the demo works in my emu now.

hap: Where in the frame does your emu start on hard reset?

by on (#30810)
Based on guesswork and getting sensitive games like Cobra Triangle and Ironsword running, I start at the pre-render scanline, then do nothing for 262.9 scanlines, then boot. So, in the case of PAL, 20.9 scanlines after vblank start.

by on (#30817)
I don't know what the NES hardware does, but I can share ideas:

1. "Warm" time. Does it run CPU code? When the warm time is over, there's no concrete proof it's really over. I read speculations only. So, my personal answer for this question is no latency.

2. Mapper 7 games. Empirical theory shows that it doesn't matter too. For Cobra Triangle (and a few others), I must emulate the RESET interruption much like an IRQ or NMI (7 cycles) with the VBlank flag set, or else it hangs. No matter where in the frame the emulation starts. Someone wrote about the VBlank being set OR cleaned during resets, though nothing special else.

3. Known games. Well, I remember of Konami's Gradius (arcade) having a waiting time before the game launches. Anyway, it's software waiting for 1 minute. I don't know the reasons for such time, but CPU code is running and a image is being displayed. I don't know either about more than a CPU inside the arcade, though this example can be valid for now.

by on (#30851)
Fx3 wrote:
3. Known games. Well, I remember of Konami's Gradius (arcade) having a waiting time before the game launches. Anyway, it's software waiting for 1 minute.


Isn't that just the Bubble Memory version of Gradius? (Memory which needs to warm up.)

by on (#30886)
No, the Vs. version of Gradius does have an unusually long boot-up time. The first ~8 seconds are spent in a loop, doing nothing but reading $4017 over and over again. After that, it checks the ROMs, displays "GRADIUS ROM 1 OK ROM 2 OK," and then goes to the title screen. I think the initial delay is there to give the monitor a chance to warm up, so you can see the results of the ROM check.

Strangely enough, you can even force the cartridge version to perform a ROM check by holding A+B and pressing Reset, though this one skips the initial delay, and then says "KONAMI ONE GRADIUS ONE" (PRG and CHR, respectively). Modifying either part of the ROM will change its respective status to "TEN" (or "OUT" in the Vs. version). Kinda weird...