Castlevania II (Simon's Quest) - Multilingual enhancement

[keropi]

those audio or gfx artifacts that are discussed here only affect the map screen right?

edit: just saw the 1.30 release, I will try it tomorrow since I don't have my soldering equipment at home atm , are both CHR and PGR data modified? or can I get away with just re-flashing the PGR rom?

edit2: on nestopia I can see now severe artifacts on the map screen (mmc3) , seems some tiles are misplaced

WOW! 1.31 is up! 

[Bregalad]

I managed to get the DMC-aware delay code right, but there's still some jitter of 12 cycles or so at some point. It doesn't help that the bank switching itself takes 76 cycles on VRC6, 72 cycles on MMC1 and 96 cycles on MMC3. The h-blank just isn't long enough to hide the whole switch, especially if there is a rocking of even 8 cycles back & forth

Put the MMC1 in 8kb CHR mode, and the whole switch happen in a single cycle. Only the last of the MMC1 register writes actually takes effect. 12 cycles of jittering is no problem you can hide it in hblank. Problem solved. I don't see why you would need MMC3 or VRC6, but if you use those, you'd want to forget about cycle counting completely and use their respective IRQ features so that you can get no visual artifact and no sound artifacts.

[Bisqwit]

are both CHR and PGR data modified? or can I get away with just re-flashing the PGR rom?

Both 1.3.0 and 1.3.1 change both.
I moved the map screen a bit up, trying to relieve as many scanlines worth of work from the bottom as possible.

edit2: on nestopia I can see now severe artifacts on the map screen (mmc3) , seems some tiles are misplaced

There was such a problem at one point. In 1.3.1. none of the variants seem to produce that error.

Put the MMC1 in 8kb CHR mode, and the whole switch happen in a single cycle. Only the last of the MMC1 register writes actually takes effect.

Ah, I didn't realize that only the last write is significant. Then it is no problem for timing. It is still a serious problem for the NMI-during mapper-reprogramming situation.

Technically I could mitigate the lag by doing some of the work during the scanline wait loops, but due to ROM organization problems (the rendering loop has to fit in the common bank, which has quite little room), I haven't been able to do that.

I don't see why you would need MMC3 or VRC6

I offered MMC3 option, because it is one of the most common chips that has the necessary features for this game.
And VRC6 is the one that has a very fast PRG switch (there are several PRG switches each frame) and that has atomic mapper writes (no separate command & data writes that can be intervened with), making it the recommended option.
Yes, could use their IRQ features, but that would require some significant rewrites that I am not prepared for.

[Bregalad]

Mmh, so the only remaining problem is the lagging problem.
I think we must find a solution to it so it would make that version of the game perfect.

You should try to disable the music or disable sprites, and see if it still lags (in both cases).

If it stops lagging with both hacks (I mean not both at the same time, but both separately) then you should optimize your sprite routine somehow to be faster.

If it still lag in either case then you'll have no choice other than dramatically reduce the number of sprites or to shut the music off on the map.

In all cases, mapping all 64 sprites is slow on the NES. Even if you only update their X position, it's still a lot of work for poor little 6502 at 1.79 MHz to handle. So if you reduce it to less sprite it could perhaps get faster.

[Bisqwit]

I could make the sprite update code slightly faster, if I updated only the X coordinate instead of the X and the Y coordinate.
Y coordinate updates are needed in order to hide sprites.
Now, to hide a sprite, which manner is recommended?
A) Put it in coordinate 255. 1 pixel of garbage will be seen in the right of the screen.
B) Put it in coordinate 0, and enable the 8-pixel margin in the left of the screen. 8 pixels of blank will be shown in the left of the screen.
X) Put it vertically outside the screen. This is what I did previously.

[Bregalad]

X) is the best, but if it is too slow you could try A) or B) or even better, just use less sprites.

[keropi]

Don't know if it's a stupid idea or not, but wouldn't making the map 1 screen only (without scrolling) help?

[Bisqwit]

Don't know if it's a stupid idea or not, but wouldn't making the map 1 screen only (without scrolling) help?

But I like a large map! :-)

EDIT: Release 1.3.2 is out. Lag is almost gone now. I split the sprite updates across two frames, and in general do them only when needed.
Sprites are now hidden for 8 leftmost pixels, background is still visible.
Found also a bug in my emulator in the process: the edge clearing bits in $2001 really are supposed to affect the left edge only; not the right and the left.

[Vanya]

Fantastic work on this. I'm looking forward to playing CV2 again for the first time in a decade.
I was wondering, though. Since there's a VRC6 version of the patch, does that mean that one could upgrade the game's music to the standard of Akumajou Densetsu?

This really is the coming close to being the ultimate version of CV2. The only thing it needs is candles & a larger and more challenging selection of bosses.

[Bisqwit]

Thank you.

I was wondering, though. Since there's a VRC6 version of the patch, does that mean that one could upgrade the game's music to the standard of Akumajou Densetsu?

One could, if one could make heads or tails about the music engine. It seems like a lengthy effort.
(And, of course, if one could compose something worthwhile for the VRC6.)

This really is the coming close to being the ultimate version of CV2. The only thing it needs is candles & a larger and more challenging selection of bosses.

Haha don't give me ideas! :-)
No, seriously one thing I am considering is adding myself as an NPC in a particular location in the game. Just need to figure out the map data format first. If optomon could help...

[Bregalad]

I just tried the last version, the map itself works wonders as there is no glitch in the sound nor graphics, I really congratulate you for this.

However, when the map is supposed to scroll only the sprites scrolls, and the BG remains static. It probably needs yet another little update... and it'll be perfect.

[odditude]

Fantastic work on this. I'm looking forward to playing CV2 again for the first time in a decade.

seconded. i'd been feeling the urge to begin with, but this? yeah, i'm excited to try it out this weekend!

[keropi]

I just tried the last version, the map itself works wonders as there is no glitch in the sound nor graphics, I really congratulate you for this.

However, when the map is supposed to scroll only the sprites scrolls, and the BG remains static. It probably needs yet another little update... and it'll be perfect.

hmmm and I was thinking my mmc3 pcb developed a fault... I have triple-checked my connections and triple-verified my eproms, I get this result on my famicom:



The map is garbled and static and the sprites move. The rest of the game is fine but there is a chance after you exit the map the game graphics become garbled too... sprites are OK but tiles are replaced with others.

[Bisqwit]

However, when the map is supposed to scroll only the sprites scrolls, and the BG remains static.

...What.

You are right. It happens on the vending machine version, and not in my local dev version. Which files did I forget to update? I have to check. Sorry about that.
keropi, your circuit is not to blame; it was my installation that was broken.

1.3.4 released addressing this problem alone; verified to be ok.

I think you got the calculations quite right, but for NTSC I get the preriods 72 and 54 from here : http://wiki.nesdev.com/w/index.php/APU_DMC. I don't know why you substracted them with 1. (not saying it's incorrect).
For PAL it will be 66 and 50 respectively.
I don't know if you got this working, but if you did it's really great. Keep in mind most emus will be inaccurate and will not simulate the DMC stealing cycles to the CPU. Only Nestopia and Nintendulator might emulate this correctly. I'm even pretty sure they only emulate NTSC correctly and have off-timings for PAL. I can always test whatever with my powerpak, as I have both a NTSC and PAL console, if this can be handy.

Testing on PAL console, that would be great.
I'm not sure why I subtracted the 1, either. I did it because my emulator does that. :-) If it turns out to be incorrect in the end, I will have to fix it.
Most emulators that I have tested do the DMC cycle stealing at a constant 4 cycles. I think Nestopia attempts varying amounts depending on what action the DMC interrupts.

[keropi]

time to test 
both prg/chr were updated this time or only prg?

[Bregalad]

I have not yet tested on hardware but apparently with the 1.3.4 version there is a garbage sprite on the top of the screen after you close the map. Fixing that would be great.

Also you said the lag is almost gone. This means it's not completely gone ? If you have the room in ROM, do more unrolling of the loop that does your sprite, that should do the trick.

[keropi]

yes, I see this on Nestopia, on both upper left+right corners... and I was about to burn eproms 

[Bisqwit]

Also you said the lag is almost gone. This means it's not completely gone ? If you have the room in ROM, do more unrolling of the loop that does your sprite, that should do the trick.

It is not completely gone, yes. If you put fceux on turbo and flail the cursor wildly around on the map, you get a lag frame once every second or two.
Unrolling the loop to the full extent allowed by ROM space does not seem to help.

Both chr/prg were updated in 1.3.4. 1.3.5 (when I figure out the remaining bits of lag and that odd sprite) is expected to update only prg, unless I update the map crosshair also.

EDIT: Could someone contribute a nice 16x16, 4-color (3+transparency) skeleton pointing hand icon for use as the map crosshair?
I tried a larger crosshair as requested by someone, but somehow this doesn't fit in the game's style.

[keropi]

allright! I have left it testing for ~40mins now and there is no gfx corruption except the 2 artifacts on the top... 

damn, I get random wrong tiles after ~50mins... maybe there is something wrong with my cart ... I need to power cycle to get rid of them, a reset does not help... if there was a bug somewhere then the reset would clear it , right?

[Bisqwit]

damn, I get random wrong tiles after ~50mins... maybe there is something wrong with my cart ... I need to power cycle to get rid of them, a reset does not help... if there was a bug somewhere then the reset would clear it , right?

Yes, a reset should clear errors.

At least I am in the understanding that a reset signal is also carried over to the MMC3 chip. I will verify though whether there are settings I somehow fail to reset.