- Any clues what's causing those black lines in the score?
image removed
- Plus, this occurs with Time Lord:
image removed
- Any help? Thanks!
EDIT: Well, TimeLord requires those dummy reads, since 2002:80 is "required" on startup.
EDIT2: Fixed Ian Bell's tank demo. Still pending TimeLord problem.
Time Lord looks like IRQ trouble. Specifically, APU Frame IRQs are tripping when they shouldn't be. The screenshot you showed looks like exactly what happens when APU Frame IRQs trip.
Time Lord uses DMC IRQs for the status bar, but never actually disables APU Frame IRQs. Instead, it switches to 5-step mode some time after start up. It may require dummy reads to be emulated, as I don't think it explicitly acknowledges APU Frame IRQs ever.
EDIT2: Found the problem. On powerup, 4017h=00h. If I set it to C0h, the game works fine. Suggestions, please? ^_^;;
___________________________________________________
- Dummy reads are emulated. If I press reset, everything's fine.
EDIT: yes, there's an error in the APU IRQ timing reset (test rom). Heh, it wasn't supposed to do, but anyway... :S
- Recap: by default (?), 4017h=00 on power up. This way, a frame IRQ is requested & remains pending until 4015h is read or 4017h AND 40h is true.
- There's a bug in my emulator, or very close to it. The game Time Lord reads 4015h twice too early, clearing the pending frame IRQ, but writting 80h into 4017h (switching into mode 1, 5 steps), keeping the pending frame IRQ, which is triggered right after a CLI. So, the IRQs are tripping during the game, messing up the scorebar.
- Any suggestions, please?
Fx3 wrote:
- Recap: by default (?), 4017h=00 on power up. This way, a frame IRQ is requested & remains pending until 4015h is read or 4017h AND 40h is true.
- There's a bug in my emulator, or very close to it. The game Time Lord reads 4015h twice too early, clearing the pending frame IRQ, but writting 80h into 4017h (switching into mode 1, 5 steps), keeping the pending frame IRQ, which is triggered right after a CLI. So, the IRQs are tripping during the game, messing up the scorebar.
- Any suggestions, please?
Check if
Strobe is bound to the same
IRQ as the timer for
VBlank.
I think there may be a similar issue in emulating the
"Prince Of Persia : Sands of Time" game for Playstation2 and the upcoming Wii VirtualConsole re-release of the GCN (GameCube) version.
jargon wrote:
I think there may be a similar issue in emulating the "Prince Of Persia : Sands of Time" game for Playstation2 and the upcoming Wii VirtualConsole re-release of the GCN (GameCube) version.
Screenshots please.
tepples wrote:
jargon wrote:
I think there may be a similar issue in emulating the "Prince Of Persia : Sands of Time" game for Playstation2 and the upcoming Wii VirtualConsole re-release of the GCN (GameCube) version.
Screenshots please.
I said
"may be", not
"is."
jargon wrote:
Check if Strobe is bound to the same IRQ as the timer for VBlank.
- I didn't get what you mean.
Fx3 wrote:
jargon wrote:
Check if Strobe is bound to the same IRQ as the timer for VBlank.
- I didn't get what you mean.
See if the controller is supposed to resynchronize at a specific line after vertical retrace begins after VBlank occurs instead, due to missing something you were supposed to emulate but didn't.
Time themed games often have uber controller sync issues.
Fx3: Don't listen to jargon. He's spouting nonsense. I don't know why he thinks Prince Of Persia has anything to do with this... or why the game is set up a certain way just because it has "Time" in the title. The controller has nothing to do with this.
I looked at Time Lord again and it looks like you're right... it doesn't acknowledge frame IRQs with even a dummy read!
Game looks like it's doing the following:
1) LDA $4015
2) STA $4000,X (where X=$15) -- results in dummy read of $4015, followed by a write to $4015
3) STA $4017 (where A=$80) -- changes to 5 step mode, but does not disable frame IRQs
4) STA $4015 -- no dummy read (still doesn't do anything to stop IRQs)
I figure there's approximately 210 cycles between the STA $4000,X (last frame IRQ acknowledge) and the STA $4017 (mode change). If the Frame IRQ happens in this window, you'll have a problem.
Only thing I can think of that might help would be to adjust your startup time. IIRC, on powerup, you should start emulation some time shortly after the start of rendering (I forget exactly where -- been so long).
All I can say is try to keep shifting around your startup time until the game starts working. You shouldn't have to shift much more than 200 cycles in either direction.
I thought Strobe initialization accounted for that missing amount of cycles? Am I wrong?
jargon wrote:
I thought Strobe initialization accounted for that missing amount of cycles? Am I wrong?
yes =P
Time Lord appears to be just zeroing all the APU regs during that time.
Actually -- change that number to 723 cycles instead of 210 -- just remembered that it's writing to $4014 which is sucking up CPU cycles as well.
It worked. The PPU starts near the dummy scanline (20 lines relative to the VBlank).
Fx3 wrote:
It worked. The PPU starts near the dummy scanline (20 lines relative to the VBlank).
Yay, good job, Fx3.
Knew it had to be something initialization related.
Reviving this thread because I'm having the same issue with Time Lord. Nintendulator also gets this game wrong.
Edit: Yep, should start at Prerender, not vblank time. Nintendulator starts at Vblank time, so the game dies. This is what happens when you copy Nintendulator's methods: you get Nintendulator's bugs