It is currently Thu Dec 14, 2017 12:10 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 33 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Wed Jul 13, 2005 4:20 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Thanks.

To 'fix' Stars SE, change 0x58 at offset 0x17 to 0x78.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 13, 2005 7:41 am 
Offline

Joined: Fri Nov 12, 2004 5:02 am
Posts: 40
Sonic 3D Blast 6 doesn't work with $4017 set to 0 on power-up, presumably because it's a hacked dump. Other than that, no other game seem to cause any trouble when default-enabling frame IRQ's.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 11:59 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
I'm having a bit of trouble getting Ironsword (W&W2) and Cobra Triangle to run with frame IRQs enabled on boot.
At boot, after 1 frame, the frame IRQ line is set, then it writes 0 to the frame sequencer, and one frame later, it writes 0x80 to it. It never acknowledges the frame IRQ.

Ironsword locks up at the titlescreen. That happens because it does a PLP that sets the status register to 0. The frame IRQ is finally let through, and it gets stuck in an RTI/frame IRQ loop.

Cobra Triangle locks up in-game, I don't know yet what it does, but the boot-sequence is quite the same as in Ironsword, so I guess I'm doing something wrong at boot, but I have no clues.

Image
"Better watch it bro, for I wield legendary imaginary IRONSWOR!"


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 12:12 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Frame IRQs ONLY occur in the 4-step frame counter sequence (i.e. when you write $00 to $4017); they do NOT occur during the 5-step sequence ($80 -> $4017).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 12:56 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Yes, the frame IRQ happened when 0x4017 was 0 (1 frame after powerup).

The IRQ line stays hot until it's acknowledged, right ? eg.:
- pending frame irq and pending mapper irq
- acknowledge mapper irq
- don't acknowledge frame irq
- rti
- pending frame irq again

(loop)

Writing 0x80 to 0x4017 won't acknowledge the pending IRQ (0x4017.6 does that).


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2005 4:24 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Hap is correct. The only way (I've found) to clear the frame IRQ flag is to read $4015 or write to $4017 with bit 6 set (i.e. $40 or $c0). Writing $00 and $80 to $4017 never clears the flag.

Darn it, I'm almost done with a first round of APU test ROMs, and this is one of the things it checks. I'm going to have to break the frame sequencer tests into two releases since I've got a great set ready (the complexity due to the delay when changing modes is really overwhelming me).

What are you initializing the NES RAM to on power-up? Perhaps you're using 0 and the plp is getting that. I recently re-ran the test and got the same result: RAM filled with $ff (except four bytes in zero-page that have different values).


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 3:26 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
RAM set to 0 or 0xff has no effect on it (I have it set to 0xff).

I saw wrong, my debugger is kind of confusing: the PLP gets 0x90, not 0 (the 0x90 is from a PHA a few instructions earlier, stupid game bug I guess). I'm almost certain the clearing of the 'I' flag is correct behaviour, and I've got a bug somewhere related to IRQ handling.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 9:49 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Problem solved. On powerup, I started at the dummy scanline right after vblank. Starting at vblank instead, fixed this frame IRQ bug.

Something I thought of while searching for the cause of this bug:
If an IRQ is pending, and you do a CLI, or PLP or RTI that clears the 'I' flag, does the IRQ happen after this instruction, or after the next one ?

Doing it the 2nd-method-way fixes Stars SE.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 10:40 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
If the IRQ line is already asserted and cli is executed, the next instruction is executed before taking the IRQ. I just ran the following:

Code:
     lda   #1
     cli
     lda   #2
     lda   #3
     sei
irq: jsr print_a ; prints 2


EDIT: plp behaves the same as cli, but rti does not execute the next instruction:

Code:
      ; addr and $00 pushed on stack
      lda   #1
      rti
      lda   #2
addr: lda   #3
      lda   #4
      sei
irq:  jsr   print_a ; prints 1


This means that if you don't clear the source in an IRQ handler and it keeps getting called, the interrupted code won't get executed at all, rather than one instruction between each IRQ invocation.

EDIT: ...except in the curious case of cli sei, where the IRQ is acknowledged but the I flag is set in the saved status:

Code:
     ; IRQ already asserted
     cli
     sei
     ; IRQ occurs here
forever:
     jmp forever

irq: rti   ; executed only once


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 2:03 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Interesting. But too bad for Stars SE:

(pending frame IRQ)
...
CLI
LDA Immediate 0x07
something1
something2
something3
irq: RTI

this translates as:
CLI
LDA..
RTI, RTI, RTI, RTI, etc.

while this would fix Stars SE:
CLI
LDA..
RTI
something1
RTI
something2
RTI, etc.

(Yeah, I know, kind of dumb to use Stars SE as a test case, it might not have been tested on a real NES)


*edit*
Days of Thunder (U), had what I thought to be a feature where the dashboard shaked vertically when the engine was revved high. That doesn't happen anymore after implementing this irq flag 'edge trigger' behaviour. Other glitches still happen though, like 2 displaced scanlines on the textbox at the gameover screen.

(the screenshaking problem in Ys III is still there)

*edit2*
Days of Thunder (U) behaves the same as before after fixing a bug, so ignore the comment about it above.
It might be important to know that whenever Ys III does a shake, a pending IRQ, caused by a CLI, is always involved.


Last edited by hap on Mon Aug 01, 2005 10:48 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 2:13 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
hap wrote:
Problem solved. On powerup, I started at the dummy scanline right after vblank. Starting at vblank instead, fixed this frame IRQ bug.


As I kinda suspected, this broke some other games (ppu statusregister being 0x80 on boot). Could it be something undocumented is happening ? Like the pending frame IRQ fading away somehow.

If it's not too much work, can it be tested?:
- set interrupt flag
- wait 2 frames, so the apu frame irq flag gets set
- write 0x80 to the framesequencer
- wait a few seconds (in w&w2 the interrupt flag is cleared after about 3 seconds, in cobra triangle when you start the game)
- clear interrupt flag
- frame irq happens ?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 5:12 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Things like you suggest to test are the exact thing I'm looking for since they might uncover new details of operation.

I ran the test you suggested and don't find evidence of the frame IRQ flag "fading":

Code:
reset:
      sei
     
      lda   #$00        ; mode 0, frame irq enabled
      sta   $4017
     
      lda   #34         ; 34 msec (a little over 2 frames)
      jsr   delay_msec
     
      lda   #$80        ; mode 0, frame irq unaffected
      sta   $4017
     
      ldx   #30         ; 3.0 seconds
:     lda   #100
      jsr   delay_msec
      dex
      bne   -
     
      cli
      jmp   forever     ; would print nothing if no irq
     
irq:  lda   $4015
      jsr   debug_byte  ; prints $40


Since you mentioned VBL and NMI, I ran some other tests on their power-up and reset timing.

At power-up, the VBL flag ($2002.7) was set on each of several test runs. On reset, the VBL flag was usually clear. It was next set and readable by the CPU 27386 clocks later (sometimes one clock earlier).

Code:
reset:
      lda   $2002       ; 4 clear VBL flag
      ldy   #60         ; 27379 delay
      lda   #90         
      jsr   delay_ya2
      lda   $2002       ; 4 read $2002 at 27386
      and   #$80
      jsr   debug_byte  ; consistently prints $80


When timing the first NMI, I found that writing $80 to $2002 was ignored until 29659 clocks after reset (though usually just 29658):

Code:
reset:
      ldy   #32         ; 29654 delay
      lda   #184       
      jsr   delay_ya5
      lda   #$80        ; 2 enable nmi
      sta   $2000       ; 4 write at 29659
                        ; any earlier is somtimes ignored


The first NMI occurs by 57168 (sometimes one clock earlier) after reset (I wasn't getting a consistent result after power-up and don't have the energy to run any more tests right now):

Code:
reset:
      ldy   #32         ; 29654 delay
      lda   #184       
      jsr   delay_ya5
      lda   #$80        ; 2 enable nmi
      sta   $2000       ; 4 write at 29659
     
      ldy   #182        ; 27503 delay
      lda   #29         
      jsr   delay_ya4
     
      lda   #1          ; 2
      lda   #2          ; 2
                        ; NMI occurs here...
      lda   #3          ; 2
                        ; ...or here
      lda   #4          ; 2
     
nmi:  jsr   debug_byte  ; prints 2 or 3


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 01, 2005 7:21 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Quote:
At power-up, the VBL flag ($2002.7) was set on each of several test runs. On reset, the VBL flag was usually clear. It was next set and readable by the CPU 27386 clocks later (sometimes one clock earlier).


This fixes Ironsword/Cobra Triangle, while not causing extra problems (eg. Downtown Special, that Japanese Samurai version of River City Ransom, had screenshaking problems when booting in vblank). 27386, that means at boot it's out of vblank, what about the other 0x2002 bits then ?

Quote:
When timing the first NMI, I found that writing $80 to $2002 was ignored until 29659 clocks after reset (though usually just 29658):


Are early writes to other PPU register(bits) also ignored ?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 01, 2005 11:01 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Times are in clocks since reset or power-up. For example, the following code executed at reset writes $00 to $2000 at time 5:

lda #$00
sta $2000

Writes to $2006 before 29658 were ignored (sometimes only before 1911 clocks after power-up).

Writes to $2007 were not ignored just after reset (I haven't run a test to figure out what the $2006 address is set to on power-up).

The address in $2006 was unchanged after reset.

Writes to $2003 and $2004 were not ignored just after reset.

Reads of $2007 before 29657 put $00 into the internal buffer; at that time and after reads worked normally.

I'll have to run more tests another time (2.5 hours of testing seems to be my limit).


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2005 10:44 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
blargg wrote:
Reads of $2007 before 29657 put $00 into the internal buffer; at that time and after reads worked normally.

Kamen Rider Club (J) doesn't like that (locks up).

I've not encountered any problems yet with the NMI delay, or with 0x2002.7 being set at boot.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] 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