[Translation][Art][NES] Hokkaido Rensa Satsujin: Okhotsk ni Kiyu

Started by Pluvius, October 05, 2018, 04:58:18 AM

Previous topic - Next topic

Pluvius

I have reached a point where I am reasonably confident that I can deliver a high-quality translation hack of the Famicom version of Hokkaido Rensa Satsujin, the sequel to Portopia Renzoku Satsujin Jiken and the second of the Yuji Horii Mysteries.  The main help that I need is a competent translation of the script, which is linked below.

https://www.dropbox.com/s/x4i2rcia869cblv/hokkaidoscript.zip?dl=0

I am nearly certain that this is the entire script for the game aside from a few incidental things related to starting the game.  As you can see, it is quite large, so I do not expect a quick response to this request.  As I feel that this game actually merits the effort, I'm also asking for help with converting any artwork from Japanese into English.  There are a few examples of this, most notably the title screen and a couple of in-game title cards.

If there is any doubt about my part in this, allow me to say that I've already reinserted the Japanese script into an expanded ROM without making use of the dictionary and embedded pointer subroutines that allowed the programmers to compress the text sufficiently, and have converted the pointers to 24-bit.  Preliminary testing suggests that this worked without any major hiccups (the one bug I ran into I am now aware of what caused it, and fixing it will be easy particularly once I have a translation and can use the dakuten and katakana subroutines for more coding space).

Virgilmaro

Hey!

I was wondering if your still looking for some help with translating this game.
I've never worked on a translation project like this, but I'm interested in using my Japanese ability to contribute to some project so that I  can improve my ability while simultaneously learning how translation projects like this work.

I had a cursory look at the script and I know it would be a challenge for me as it has some regional dialect usage in it (obviously Hokkaido), but I just wanted to throw my offer out there in case you can use me.

Looking forward to your PM so that i can know about where you are in the translation.


Pluvius

Translation is now underway, but the Japanese art will still need to be modified.  I will have more details than I've already mentioned above when the translation is inserted and playtesting is underway.

koitsu

#3
Wanted to find out the status of this project.

I've been working on this game myself since September 2018 and have about 60KBytes of reverse-engineering notes on critical 6502 code portions.  Haven't done any text/script analysis yet, just REing out how all the graphical routines, RLE format (which is unique), etc. work.  I also wrote some Python and Go programs to do the RLE decoding (I lost the Go version, but still have the Python version.  It simply outputs lots of .db statements intended for an assembler/reassembly.)

First Q: by "24-bit pointers" what are you referring to exactly?  Multiple reasons why I ask:

This game uses MMC1 (but keep reading), so I want to assume by "24-bit" you mean something like PRG bank number as a 4/6/8-bit value, followed by 16-bit offset, or some variation thereof?  Or by 24-bit are you referring to something the script dumping/reinsertion tool uses to reference data?  Part of my question is fuelled by my current lack of familiarity with how all the game text is stored/referenced in the game (haven't gotten to that part yet, but not a big deal to figure out, just takes time).

This game is very densely packed -- there's only about 46 bytes of free space in it, and only about 2KBytes of duplicated data (Bank $08 $21C00-21FFF == Bank $0A $29C00-29FFF (1KB) and Bank $09 $27C00-27FFF == Bank $0D $37C00-37FFF (1KB)).  The 16-byte "OHOTSUKU NI KIYU" game title string added at the top of each PRG bank is not enough to really help with romhacking efforts.

Also highly relevant: this game is very special due to when it came out (1984).  It's the only game to ever use the SMROM PCB revision, which includes an early-release MMC1 revision that has not been reverse-engineered reliably.  It's the one revision of MMC1 that is completely undocumented on the nesdev wiki.  There is behavioural variance between MMC1 revisions (ex. 1A vs. 1B vs. 1C), but this game appears to use a pre-1A revision.  Given the rarity of this game / collectors never willing to give up their cartridges for someone skilled enough to do decapping + analysis, we have to rely on pure software-based reverse engineering to determine if there is any behavioural differences and hope for the best.  So far, the bank switching code in the game (routines at $FEF4, $FF85, and $FEEC for bank $0E specifically) looks to be like other MMC1 games, but I haven't delved deeply enough to see if there's bus conflicts.

Relevant to THAT point: ROM expansion for this game in English would very likely require extending it to 512KB, which would require switching to the SUROM PCB type.  Here's the rub: SUROM would require use of NES 2.0 headers, which would limit playability to emulators/devices with NES 2.0 header support, else the emulator/device would need a PRG checksum to ensure the game got loaded in with the proper board type.  I am not particularly big on NES 2.0 headers because of long-standing compatibility problems all over the place, so I try hard to keep to things that can work with the original 16-byte NES header ("iNES header") and/or rely on emulator/device databases.

What I came up with was converting the game to UxROM (mapper 2), so probably UOROM.  This retains classic NES header compatibility (no need for NES 2.0), allowing things to work on emulators/devices without issue.  This is because emulators/devices all treat the bank switch register in UxROM as effectively a 7-bit value, so 7*16KB = 2MByte PRG capacity total.  Likewise, UxROM has $8000-BFFF swappable and $C000-FFFF fixed, just like MMC1.  And both have 8KB CHR-RAM by default.  Finally, neither mapper are subject to bus conflicts (though early UxROM chips from Nintendo WERE subject to them, nothing made today would be).

That all sounds good except for one use case: turning the romhack into an actual cartridge.  That becomes a problem, because there's no actual UxROM PCB revision that has ever supported more than 256KB PRG... except for one: UNROM 512 (mapper 30) which supports up to 512KB PRG.  This chip is still actively made/available, which is great.  Bus conflicts aren't a problem unless you go with the non-flashable version of the PCB (not recommended).  4-screen PCB version would not be needed/wouldn't work anyway.  Total cost per-PCB (with all chips included) would be around US$12/board, which falls into "reasonable cost" for people who wanted to make actual cartridges of such a romhack.

Second Q: what script dumper / inserter software did you use, and what version?  Just a .zip file of a .txt with no other details is not helpful (honest).  Atlas for example varies in behaviour per version, so this information is important.

Finally: if you wanted to share notes/etc., I'd be happy to put up what I have on GitHub or Google Drive or the like, including the RLE decoder.  I do more on the 6502 side and RE side than the translation side, as I can't read Japanese, but I have access to plenty of people who do Japanese (including one American who speaks fluent Japanese and lives in Hokkaido + whose wife and family is from Hokkaido.  I mention this because of Hokkaido dialect inflections in the script.)

Thanks for your work on this!
Making life hard for others since 1977.

Pluvius

Work has been stalled for the past few years since (as is common with projects like this) my translator disappeared after completing about half of the script.

By "24-bit pointers," I mean that I literally converted the 16-bit pointers that the game uses into 24-bit pointers.  The game stores all of its text in a big 64kb (4 bank) block which takes up the entire address range for the 16-bit pointers.  I had to add an extra byte and change the text and bankswitching routines to recognize that change so I could expand the text into more banks.  I've never seen any issues with bus conflicts, but I can't guarantee that my hack would work on real hardware.  I'm not at all interested in getting the hack to work on a real cartridge, though something like a PowerPak would be nice.

It's not true that a 512kb MMC1 ROM requires NES 2.0 headers.  Every modern emulator that I know of assumes that the ROM is SUROM if the PRG-ROM is 512kb (https://www.nesdev.org/wiki/MMC1#iNES_Mapper_001).  The only problem occurs when CHR-ROM = 128kb, which is not an issue for this game.

I used abcde 0.0.2 to dump and insert the script.  Insertion was fairly straightforward, but dumping required me to use my rudimentary knowledge of Perl to modify the program so as to make the embedded pointers completely transparent.

Incidentally, I have also written a fairly crude codec for the RLE-encoded graphics.  I have quite a few extracted bits of untranslated graphics here but I'm not sure how useful the format would be for an artist (I found out about a better method for extracting the pattern information later).  I also modified the game to use SRAM rather than passwords (something which purists might not like, but was honestly a lot less tedious than changing the password system to Roman characters would've been).

I'm not really comfortable with sharing any high-level code since I'm not a programmer by trade and I just write that stuff so that it works rather than worrying about how usable or safe it would be for the general public.  As for assembly code, I do all of that by hand (which you could probably tell if you analyzed any of my previous hacks).  Not good, I know, but since I'm not doing big-ass total conversion hacks or anything, I haven't yet run into anything that has encouraged me to learn how to be more systematic.  Here is the latest version of the patch, for what it's worth.

Here's a video of the beginning of the hacked game for anyone who doesn't want to use the patch:

https://www.dropbox.com/s/exd3ckbyt2we8de/hokkaido.mp4?dl=0

Lazermutt4

I would be willing to help with editing the graphics.

To show what I can do, WIP mockup for the main title screen.

This is from yesterday, so I did my own spin on the phrasing.
ISSUES:
The crack effects aren't done, mostly because the phrasing of the title is still up in the air.
"Hokkaido Serial Murders" would need 4 extra tiles, but what you see is about the thinnest I can legibly make it.
The tiles above & below the ー (JP elongation dash) are empty and can't be edited. (9 tiles)

But, here's two that should work: the two signs with pricetags.
 
Edited .NES files uploaded here: https://www.mediafire.com/folder/le9je606xz4kz/okhotsk
(FYI: When saving them, YYCHR expanded the files to 4KB. is that gonna mess things up?)

koitsu

Making life hard for others since 1977.

Pluvius

Quote from: Lazermutt4 on August 14, 2022, 11:39:47 AM(FYI: When saving them, YYCHR expanded the files to 4KB. is that gonna mess things up?)

Not a problem, it's just padding.

Thanks a lot for your help.  Unfortunately, as I feared would probably happen, your artwork even when compressed takes up more space than the compressed Japanese artwork.  The best solution for this is probably to move all of the art to the expanded ROM area and repoint everything, modifying the graphics subroutine if necessary.  A pain in the ass, but it should be doable just like repointing all of the text was doable.

Again, I really appreciate your help.  It's too bad that it might not come to anything if I can't find another translator.

Bunkai

#8
Making a comment to check when i am at the computer. And to receive notifications if something new comes up :)

The script seems shorter than what I expected, I mean, my other projects except the Dandy one are huge so... This lead me to believe it has a point. I told you the other reason some time ago in the Discord.

PROs
It's in hiragana and has space separated words.
Seem linear (rpg and vn are non-linear and sometimes that and finding the scene is madness making)


CONs
It's in hiragana and sometimes that could lead to unclear homophones
it has some dialectal things, they might be obvious for a native but i haven't look carefully to say the same for a foreigner.


Anyways, Nice to see this project still has a chance.

EDIT:
What's the proper way to write the translation here? I see everything commented and i don't know where i should put the translation...  I did a little sample with the text translated to ask where it goes, I believe it should be the same but after the comments, however it was a better safe than sorry situation.

Spoiler
//GAME NAME:      Hokkaido Rensa Satsujin: Okhotsk ni Kiyu

//BLOCK #000 NAME:      Names
//Block Range: $28E5E - $28E90

//Suzuki[END]
//
//[END]
//
//Sato[END]
//
//[END]
//
//Yamada[END]
//
//[END]
//
//Tanaka[END]
//
//[END]
//
//Nakamura[END]
//
//Ito[END]
//
//[END]
//
//Morita[END]
//
//[END]
//
//Fujita[END]
//
//[END]
//
//Kimura[END]
//
//[END]
//
//Sawada[END]
//
//[END]
//
//
// current address: $28E90


//BLOCK #001 NAME:      First Block

//POINTER #0 @ $28012 - STRING #0 @ $28E5E
//HACKING NOTE: The list of names goes under this pointer.

//Suzuki[END]
//
//
// current address: $28E62


//POINTER #1 @ $28014 - STRING #1 @ $28E90

//[END]
//
//
// current address: $28E91


//POINTER #2 @ $28016 - STRING #2 @ $28E91

//[CLEAR][END]
//
//
// current address: $28E93


//POINTER #3 @ $28018 - STRING #3 @ $28E93

//[LINE]
//Boss:?[END]
//
//
// current address: $28E98


//POINTER #4 @ $2801A - STRING #4 @ $292F2

//Kuroki:[YOURNAME] inspector, right?[LINE]
//  How do you want the text speed[LINE]
//  to be?[END]
//
//
// current address: $29313


//POINTER #5 @ $2801C - STRING #5 @ $29313

//Kuroki:[YOURNAME] inspector, right?[LINE]
//  I was waiting your[LINE]
//  arrival.[LINE]
//  Now let's resume our inquiry!![LINE]
//  How do you want the text speed[LINE]
//  to be?[END]
//
//
// current address: $29318
[close]
Curiosity leads to knowledge,
be curious.

Pluvius

If you want to help on the translation side of things, you'll definitely want to see the current script.  Feel free to make revisions to the stuff that's already been translated.  The format shown there is the format I always use, but it's not hard for me to copy-paste and make edits to contributions.  Thanks for the help.

Pluvius

#10
This didn't require quite as much work as I thought.

https://www.dropbox.com/s/dnau83a9yi48edg/Hokkaidou%20Rensa%20Satsujin%20-%20Okhotsk%20ni%20Kiyu%20%28Eng%29-0.png?dl=0

The art subroutine also happens to use embedded pointers, and I was able to exploit that so I that I could move the translated artwork to the expanded area of the ROM while leaving the rest of it alone.  Not only is this a lot more convenient, but I don't think I could've fit all of the art along with the text anyway.

Now the hack is pretty much complete aside from what I need help with.  Incidentally, adding four tiles to the end of the set for the title screen should be no problem.  In addition, the first transition tileset (the one with the "to be continued" text) should be expandable as much as necessary.