blargg wrote:So you have sprite DMA taking 513/514 cycles, depending on whether the $4014 write is on an even or odd cycle?
blargg wrote:Have you tried having DMA take two cycles if the write cycle occurs one cycle before DMA?, or something like that?
Yes that's what my logic does but I'm still tracing through to see why it doesn't do that on the write cycle.
blargg wrote:I have no way of running the multi-test ROMs, as my devcart only has 32K PRG. ... It's possible that a multi-test won't pass on a NES. If you pass the singles, you're good, period.
That's good to hear but it'd be even better to see the results of the "all-in-one" on a real NES! Perhaps I'll remove the "all-in-one"'s from my test ROM status
blargg wrote:Before releasing I test all the singles by loading them and powering the NES off then back on, to be sure they are solid. Maybe we can find someone to verify my multi-tests with a PowerPak whenever I need to release them.
I need to get me one of them PowerPak's.
blargg wrote:I'll have to add a specific test for this, since as far as I know none of the APU counters count up; the only time the period for a timer is examined is when it's being reloaded, not every time it's clocked. It's good at least one caught this.
The only time I examine the period is when I am checking to see if I need to emit a clock (and hence reload the counter). Not sure why count-up/count-down made a difference yet, but I'll keep thinking on it.
blargg wrote:BTW, your screenshots would be less imposing if you just took it of the NES screen and nothing more. BTW, it looks like your NES window is stretched vertically by about 5 or 6 pixels, judging by the frequency of stretched characters.
Yes, essial put in some logic to stretch the emulation window that doesn't quite work right at minimal. I haven't bothered to figure that part out yet. I was kind of hoping someone with more OpenGL knowledge than myself could step in and help get it right. 8) [/url]