Castlevania II (Simon's Quest) - Multilingual enhancement

Started by Bisqwit, December 19, 2012, 01:38:36 PM

Previous topic - Next topic

keropi

holy cr*p! this project evolved so much! I was waiting for new donor cards but now I've changed my mind about mmc1, will use a new MMC3 TKROM for save support, good thing I got one too! Awesome work Bisqwit !!!
Will burn and make the cart now, hope I don't have to desolder the eproms soon to try a new awesome update!  ;D
I will be using this donor btw: http://bootgod.dyndns.org:7777/profile.php?id=3991

Bisqwit

Use sockets for the chips to avoid having to solder and desolder :-)

keropi

I did try that in the previous cart that turned out to be problematic, the problem is that with sockets you can't put the pcb in a shell and the height is too much so it goes in an angle when inserted in the famicom slot...

Bisqwit

Quote from: keropi on January 23, 2013, 05:54:06 AMI did try that in the previous cart that turned out to be problematic, the problem is that with sockets you can't put the pcb in a shell and the height is too much so it goes in an angle when inserted in the famicom slot...
Ok.
If you wish to burn the image soon and don't want to replace it quickly, I suggest you go with version 2.1.1 than 2.2.0.
Version 2.2.0 is more likely to have regression errors than 2.1.1 did, due to some fundamental changes required to add the VRAM support.

keropi

Quote from: Bisqwit on January 23, 2013, 06:59:49 AM
Ok.
If you wish to burn the image soon and don't want to replace it quickly, I suggest you go with version 2.1.1 than 2.2.0.
Version 2.2.0 is more likely to have regression errors than 2.1.1 did, due to some fundamental changes required to add the VRAM support.

thanks for the tip!  ;D I might end up doing the socket thing temporarily , with your awesome advancements it's either sockets or wait for a final version  ;D

kwik

Thanks for this amazing work ! Really impressive.

I've tested version NTSC 2.2.0 on MMC1, it jams Nestopia when you navigate on the map, after pressing Select.

Bisqwit

Quote from: kwik on January 23, 2013, 03:49:33 PMI've tested version NTSC 2.2.0 on MMC1, it jams Nestopia when you navigate on the map, after pressing Select.

You are right. This bug is attributed to the build-process which did not use different filenames for different versions for the OAM tables. I will have fixed this in release 2.2.1. In the meantime, version 2.1.1 is available in the vending machine.

EDIT: Version 2.2.1 released. It fixes the aforementioned problem, as well as VRAM mapping for MMC1 and PAL. A crashing bug in a certain dialog bit was also fixed, present since version 1.2.3. In addition, I finetuned some font characters and fixed a typo in a certain dialog piece.

KillerBob

I had to register just in order to thank you for this awesome re-translation patch, Bisqwit. Thank you so much for doing this! Didn't think there was enough love for this old game to ever see this happen. It's a flawed game and haven't aged that well but some of the things they tried with this title back then was ahead of its time. I have a lot of nostalgia attached to it and can still remember the days of anticipation before its original release, very happy to see this done. :) An underrated gem...
Quote from: Triupulent on January 09, 2013, 12:56:09 PM
I've read online that a direct translation of "Dracula II: Noroi no Fuiin" is  "Dracula 2: The Accursed Seal". That kind of sounds cooler than "Simon's Quest". Could that be used as the name of the hack, and the game? The title screen could be changed to reflect this.
Ironically, Castlevania II: Dracula's Curse would IMO been a perfect title whereas something like The Legend of Castlevania or Castlevania Legend would've been more fitting names for Castlevania III, I actually think Castlevania is a brilliant localization name for the series, especially fitting for the first game. But it's a little odd and interesting they went with the international name of the series for the in-game map in the Japanese original of Dracula's Curse (Akumajou Densetsu).

Vanya

Quote from: KillerBob on January 26, 2013, 02:58:34 AMIronically, Castlevania II: Dracula's Curse would IMO been a perfect title whereas something like The Legend of Castlevania or Castlevania Legend would've been more fitting names for Castlevania III, I actually think Castlevania is a brilliant localization name for the series, especially fitting for the first game. But it's a little odd and interesting they went with the international name of the series for the in-game map in the Japanese original of Dracula's Curse (Akumajou Densetsu).

I've had similar thoughts in the past and totally agree especially when one considers that CV2 is actually about a specific curse where as CV3 never mentions a curse of any sort and was the first attempt by Konami to create an origin story for CV.

kwik

I've tested today the 2.2.2 patch on a MMC1 SKROM Cart.

The game plays fine, but the SRAM feature don't work, it gives me a black screen when I press "Load Game" in the menu.

When I try to save, the game freezes very often.

I also noticed that the backup slots are marked "damaged" instead of "void".

Any idea of the problem ?
Someone tested it on real hardware ?

Edit : Just tested with MMC3 TKROM cart, same problem.

Bisqwit

The text "damaged" is given when the SRAM contents in that slot (256 bytes each) are neither valid data nor blank (fully 00000000b or fully 11111111b).
There is currently no way to blank a slot, but if you save over a damaged slot, the damaged data will be replaced with valid data.

Unfortunately I have no way of testing the game on a real cartridge currently -- batterybacked / SRAM-equipped or not.
I have also done my best to ensure that no matter what kind of garbage there is in the SRAM, the game won't crash trying to read it. It is theoretically possible that it still does (if there is an oversight in the code), but I have not been able to produce such a situation.

EDIT: I managed to reproduce a predictable crash situation. There was a vulnerability in which the range checker allowed writing into random memory locations, including the stack.
There was also another error related to the dialog_ext bug that was fixed in version 2.2.1.
I have released version 2.2.3 addressing these two problems.
Note that this release does not fix any random crashes. It only fixes predictable crashes.

Thank you for reporting the problems!

kwik

Thank you! I will test this new version as soon as possible.

I will refer here the result.

February 04, 2013, 05:32:53 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

I tested version 2.2.3 on a MMC1 cart.
Unfortunately, the game often crashes when I try to save the game, and also when I select "load game".

I replaced damaged data with valid data, but no improvement.
However, the game plays perfectly.

Bisqwit

If the crash cannot be reproduced in Nintendulator or FCEUX, I don't know how to fix the problem.
(I would add Nestopia, but Nestopia doesn't have a disassembler/tracer.)

keropi

hopefully my new eproms will arrive soon so I can test on a mmc3 saver cart... I only have SLROM mmc1 carts with no sram ...

Bisqwit

I have confirmed two predictable crashes: One on PAL map screen, and one on SRAM screen given garbage SRAM data (found in randomized tests).
I have released version 2.2.4, and later 2.2.4.1, addressing these problems.

All sprite-0-hit wait loops (those are found on the credits screen, on SRAM screen and on the map screen) are now equipped with a timeout counter to ensure that the game won't crash even if a sprite-0 hit is missed for whatever reason.

kwik

A report on the new 2.2.4 version: it works!  :thumbsup:

No crashes or freezes on SRAM screen, on my MMC1 SKROM cart.
Once again, congratulations to all this work. This is really impressive !

Bisqwit

That's nice to hear!

By the way, in case someone is interested, here is the save data format:

; First: sixteen 4-bit bytes raw password (for compatibility with matrixz's SRAM hack).
;   Followed by checksum (16-bit)
;      If 0, record ends here. (For compatibility, again.)
;   Followed by records:
;      header (16-bit), and data (1-n bytes)
;      header is: nnnnnaaa aaaaaaaa
;        n = number of bytes-1 (0-31, coding for 1-32 bytes)
;        a = RAM address ($000-$7FF. Further restrictions to acceptable addresses apply; for example you can't write into stack.)
;      header word $0000 = end of records. (There's no way to write 1 byte at $00.)
;   For up to 192 bytes. (Current size, as of version 2.2.9: 105 bytes). Aligned into 256 bytes.
;   Blank slot = begins with 16 bytes of $00 or 16 bytes of $FF.

The checksum is formed from data bytes and headers using a mixture of CRC-16 and simple checksumming. If the calculation yields 16-bit zero, 1 is subtracted from it.
The raw password includes its own integrity check.

This design is chosen with forward-compatibility in mind. If there arises a need / desire to save new bits of game state, any patch version can still load such saves.

Save slot #x (begins from 0) occupies the SRAM address $xx00-$xxBF. The bytes $xxC0-$xxFF are reserved for future expansion for other purposes (such as achievements).
The SRAM size detection also permits putting the game on a homebrew cartridge that only has 2 kilobytes of SRAM instead of the full 8. If you have 2 kB of SRAM, you have 8 slots. If you have 4 kB of SRAM, you have 16 slots. If you have 8 kB of SRAM, you have 32 slots. If you have patch version < 2.2.5, you have 7 slots.
You can use this knowledge to avoid writing into areas of SRAM that you want to protect, e.g. if you they contain data from other games.

Bytes in SRAM addresses $07E0-$07E2 are used in a read-write test for verifying whether SRAM exists in the first place, and whether it can be reliably accessed. If the game detects that SRAM is faulty, all SRAM entry routes will produce the buzzer sound effect and not enter the SRAM screen. In addition, $07F0-$07F2, $17E0-$17E2 and $1FE0-$1FE2 are used for SRAM size detection. The game strives to restore these bytes to their original values after the test.
You can use the cheat code 67E0:01 to simulate a cartridge that has no SRAM.

There is still a certain shortcoming: Valid SRAM slots are identified by extracting data from them, and bailing out on the first sign of error. Sometimes, the first sign of error is that the checksum fails, and by that moment, all kinds of RAM addresses have already been clobbered. In random tests I found a SRAM configuration that, when exists, and you enter the SRAM screen while in town Jova, when you exit the screen, you are suddenly in battle with Dracula -- in middle of town of Jova -- without having loaded a save.
The obvious way to inhibit this would be to first verify the SRAM checksum and then extract data, but that would be slower and laggier. I will have to see what to do about that.
EDIT: In that thought, I released version 2.2.5 which should fix the less-than hypothetical problem I explained above, in addition to a few other problems. It also does another minor but obvious SRAM-related change related to the above explanation.

EDIT: The http://bisqwit.iki.fi/cv2fin/ page now automatically switches language of the page when you switch the language of the patch.

kwik

I noticed that saving in Belasco Marsh makes a damaged save. Is it normal ?

In addition, I discovered a strange thing : if I open the map in Belasco Marsh and stay in without activity, the game freezes after one minute, like this :



This phenomenon does not occur if I do the same thing in Town Of Jova, for example.
This is on real cart (MMC1), and unfortunately, I have not been able to reproduce this bug on emulator.

Bisqwit

Quote from: kwik on February 08, 2013, 02:11:42 PMI noticed that saving in Belasco Marsh makes a damaged save. Is it normal ?

It is not. I have confirmed your report on FCEUX. I will investigate it. Thank you for the report.
EDIT: I discovered the cause. Your save is fine. But there is an error in the validity checker.


Quoteif I open the map <...> the game freezes after one minute

I have received other reports like this, as well. These reports were the cause for releases 2.2.4 and 2.2.4.1.
I have no idea why it happens. The map screen should be robust against NMI re-entrancy. In addition, it should be robust against uninvited PRG ROM page switches caused by NMI re-entrancy. In addition, the game uses sprite-0-hit there; it should now also be robust against failing to meet a sprite-0-hit for whatever unknown reason.
But I am investigating it.
EDIT: It seems to happen when an NMI occurs during mapper reprogramming. Which is a problem I have already invested number of hours trying to mitigate. CURSED BE MMC1 and its non-atomic reprogramming.
EDIT: Discovered the root cause. At some point, I had accidentally changed the part that resets MMC1 to be activated only on NROM (i.e. never), mistaking MMC1 mapper number which is 1, for 0. I have released version 2.2.6 addressing all the aforementioned problems.

kwik

I confirm that everything is fine in 2.2.6 version, on MMC1 cart.
That's great !
I think I will do my definitive cart with that.