I've just made a demo that show a Fire Emblem screenshot WITHOUT using the MMC4 auto-CHR switch features. It does all switching manually with very very fine tuned timings.
The goal was to test mid-scanline CHR bankswitching. Unfortunately, since under normal conditions, there is a 7-cycle jittering (which means up to 21 (NTSC) or 23 (PAL) pixel jittering), which means 3 tiles should be "shared" by both pattern tables, which is a lot.
However, after having a few headaches I found an idea to reduce the jittering and make it happen on only one dozen of pixels (2 tiles), and that for both PAL and NTSC. The idea is that when the sprite zero hit happens at a fixed place, the amount of cycles between when the flag is clear and where it's set is constant. Then it's possible to count the number of times we have to poll $2002 in order to get the sprite hit with an index register (altough the loop takes 9 cycles intead of 7). Then by using this count value, it either is fixed (useless) or oscillate between 2 adjascent values. By placing the sprite zero in a fine tuned way so that it oscillate between 2 values at about 50%-50% probatilty, I'm able to check which one it is and waste a different amount of cycles on each case, halving the jittering.
Here you are the code for that :
Unfortunatlely this is all theorical, I can't test it on real hardware, not even the PAL version because one of my EEPROMs I used to use on my CNROM devcard seems to stopped working
I have uploaded the demo here, both PAL and NTSC versions available, for both MMC1 and CNROM (sorry no CNROM NTSC version right now). Someone please test them for me (if possible different people test PAL and NTSC version) and tell me the results.
Emulator reults so far :
Latest Nintendulator : Works perfect
Latest Nestopia : Works perfect
Nintendulator 0.950 : PAL version has glitches on the left (switching too early)
Nestopia 1.09 : both versions have a flickering tile after the switch not at the same place tough
FCEUltra (all versions) : PAL version perfect, NTSC has two flickering tiles after the switch
VitruaNES : Givies all kinds of terrible messy graphics
Nesticle : All bankswitching is ignored
Rew : The screen doesn't even look like it's supposed to
So on this one I can really not rely on emulators, even Nestopia and Nintendulator revisions disagree between them
Probably because I rely one the exact $2002 poll number which makes most emulator breaks.
PS : Before anyone ask, no, I'm NOT preparing a Fire Emblem mapper hack, I was just experiencing midscanline CHR bankswitching
The goal was to test mid-scanline CHR bankswitching. Unfortunately, since under normal conditions, there is a 7-cycle jittering (which means up to 21 (NTSC) or 23 (PAL) pixel jittering), which means 3 tiles should be "shared" by both pattern tables, which is a lot.
However, after having a few headaches I found an idea to reduce the jittering and make it happen on only one dozen of pixels (2 tiles), and that for both PAL and NTSC. The idea is that when the sprite zero hit happens at a fixed place, the amount of cycles between when the flag is clear and where it's set is constant. Then it's possible to count the number of times we have to poll $2002 in order to get the sprite hit with an index register (altough the loop takes 9 cycles intead of 7). Then by using this count value, it either is fixed (useless) or oscillate between 2 adjascent values. By placing the sprite zero in a fine tuned way so that it oscillate between 2 values at about 50%-50% probatilty, I'm able to check which one it is and waste a different amount of cycles on each case, halving the jittering.
Here you are the code for that :
Code:
- bit $2002
bvs - ;Wait for the flag to be clear
ldx #$00
- bit $2002 ;Wait for the flag to be set, count itterations
inx
bvc -
cpx #Value ;You should check Nintendulator's debugger to get a reliable value here
bcs +
nop ;This wastes 3 more cycles x >= value, reducting the jittering
nop
+
bvs - ;Wait for the flag to be clear
ldx #$00
- bit $2002 ;Wait for the flag to be set, count itterations
inx
bvc -
cpx #Value ;You should check Nintendulator's debugger to get a reliable value here
bcs +
nop ;This wastes 3 more cycles x >= value, reducting the jittering
nop
+
Unfortunatlely this is all theorical, I can't test it on real hardware, not even the PAL version because one of my EEPROMs I used to use on my CNROM devcard seems to stopped working
I have uploaded the demo here, both PAL and NTSC versions available, for both MMC1 and CNROM (sorry no CNROM NTSC version right now). Someone please test them for me (if possible different people test PAL and NTSC version) and tell me the results.
Emulator reults so far :
Latest Nintendulator : Works perfect
Latest Nestopia : Works perfect
Nintendulator 0.950 : PAL version has glitches on the left (switching too early)
Nestopia 1.09 : both versions have a flickering tile after the switch not at the same place tough
FCEUltra (all versions) : PAL version perfect, NTSC has two flickering tiles after the switch
VitruaNES : Givies all kinds of terrible messy graphics
Nesticle : All bankswitching is ignored
Rew : The screen doesn't even look like it's supposed to
So on this one I can really not rely on emulators, even Nestopia and Nintendulator revisions disagree between them
Probably because I rely one the exact $2002 poll number which makes most emulator breaks.
PS : Before anyone ask, no, I'm NOT preparing a Fire Emblem mapper hack, I was just experiencing midscanline CHR bankswitching