Messages

[PCE/TG-16|CD/SGX Discussion / Re: Third party TG16 pad, has anyone tried it?]

I wish somebody would make a good wireless aftermarket adapter for the PCE/Turbo.
Something like the Gamecube wireless, or the 8BitDo Retro Receivers...

[Localizations, Games, Apps, Docs / Is there a Wiki ?]

I was taking a brief look at a few games over the weekend, in order to do a quick 'reconnaissance' pass for translation viability.

It struck me that there is some interesting information which can be collected in only about 10 minutes, which could be shared in case other people would like to look into translations or other hacks.

I could create a thread and keep updating the head entry, but with the number of games for this system, it would become untenable pretty quickly; is there a wiki which could be setup for this ?  (I don't think it quite matches the spirit of the Cutting Room Floor's intent: https://tcrf.net/Category:TurboGrafx-CD_games ).

For example, off the top of my head, I took another look at Snatcher.
- This would be a tough game, requiring not just a programmer, translator, and likely sound mixer, but also a pixel artist due to the text which is encoded as graphics.
- Entire opening cinema is graphics, although a fair bit of text (cast/developers' names) is printed in a PC Engine Kanji-rendered font.
- Text is stored compressed and decompressed into a buffer
- game text calls the system font to generate 12x12 kanji.

(I would find a better way to organize this raw data however)

Dave

[Localizations, Games, Apps, Docs / Re: System Card Font Fix]

We were able to get the ZIP file put up:

https://www.pcengine-fx.com/downloads/syscard_font.zip


The ZIP file includes:
- IPS file
- test_kanji utility - source code and compiled ISO
- Description of how it was done
- all of the relevant character definitions (as 1-bit BMP files).

This is all you will need in order to put your own font in (well, you'll still need a font....).


Here's a quick overview of how I did this... a little more detail is in the HOWTO in the zip file.

Viewing the Characters:

First, I needed to see how the characters appeared, and what SJIS codes they corresponded with.
testkanji.c (and .iso) are the product of this (see ZIP file).
- The direction keys adjust the SJIS code used for the first character in the matrix.
- The 'II' key prints a matrix of SJIS characters starting with this code. 16 characters across, and 8 rows down.
- The 'I' key toggles the flag between 12x12 and 16x16 font display
- The 'SELECT' key will page forward (0x80 kanji) for convenience

If you review the whole set, you'll notice that many codes appear multiple times - they aren't really duplicated in the ROM; these are just artifacts of the calculations in the decode routine. So we'll only have to replace one copy.


Finding Where the Codes Are Stored in the ROM:

Using the 'testkanji' program, I set a breakpoint for $E060 (the EX_GETFONT function), and traced it through.  It turns out that the characters aren't stored in a compressed format, and actually take up a significant portion of the ROM. Also, for the ones I was interested in, both Japanese and American System 3 ROMs had stored those characters at the same locations, for both 12x12 and 16x16 sizes.


Extracting the Existing Fonts:

I used FEIDIAN (a PHP program which tries to be a universal font extractor/implantor... and it seems pretty good).

All of the relevant FEIDIAN commands are listed in the HOWTO file int he ZIP.


Modifying Fonts:

Honestly, I didn't attempt to repair the existing fonts; I just replaced them with another set of fonts I found here, after making minor adjustments:
www.pvv.org/~roarl/nethack/nethack.html

I used a program called Pixelformer, and output a BMP after setting the colorspace to Monochrome.
Then, I reversed the process, using FEIDIAN again.

Note: To do the same, take the appropriate command above, switch '-r' to '-i', and swap the sequence of the ROM and BMP names.

The command sequence for a ROM with header would be:
php feidian.php -i 12,12,26,2,0x30A4C insert_alphabet12.bmp syscard3.pce
php feidian.php -i 16,16,26,2,0x110C0 insert_alphabet16.bmp syscard3.pce
php feidian.php -i 12,12,10,1,0x30998 insert_num12.bmp syscard3.pce
php feidian.php -i 16,16,10,1,0x10F80 insert_num16.bmp syscard3.pce
php feidian.php -i 12,12,2,1,0x30290 insert_quest12.bmp syscard3.pce
php feidian.php -i 16,16,2,1,0x10300 insert_quest16.bmp syscard3.pce

The ZIP file includes the IPS file for "Version 3.0" Super System cards; this expects a headered ROM, but should work equally well on both Japanese and American versions, as the font information is stored at the same location in both.

Hopefully this is helpful to everybody.

Dave

[Localizations, Games, Apps, Docs / Re: Translation patch – POST 4 – Extracting the script]

We were able to get the full ZIP file put up (this includes the SQLite3 database).

pcengine-fx.com/downloads/extract.zip

[Localizations, Games, Apps, Docs / Re: System Card Font Fix]

Or do you mean that the English fonts in the system cards suck (regardless of region), but it's only less annoying when most of the text are in Japanese?

I think for whatever reasons, the English font in Japanese system card 3.0 is a bit different from those in 1.x as well (don't know when it was changed, either from v1 -> v2, or v2 -> v3), as the screenshots in game manuals of non-super CD games usually show letters that are a bit different from playing the game with system 3.0.
Edit: If Wikipedia is to be trusted, the 12x12 and 16x16 fonts were changed in Super System Card(i.e. since v3) to add more symbols and enhance readibility. Maybe for unknown reasons the western system card v3 still uses the old fonts?

I should have been more clear with the scope of my change - I only changed:
1) Upper and lower-case letters from A-Z
2) Numbers from 0-9
3) The '?' and '!' punctuation marks

...And the American cards contain all the same font information as their corresponding Japanese cards (to the best of my knowledge).


System Card 3.0 probably does have more symbols, but that wasn't the focus of my studies.
If I can get the ZIP file uploaded to the board, there is a utility in there to browse the characters sets.

I just checked what you mentioned about the updated font, and it appears that they did make a couple of changes:

System Card 1.0 -> 2.0:
- replace the 12x12 numeric characters with a slightly larger, less-bold font (but this doesn't exactly match the rest of the Western characters anymore)

System Card 2.x -> 3.0
- replace at least the 12x12 uppercase alphabetic characters with new ones.

It seems that the old ones might have been too 'blocky', so they may have thought that they were making them prettier - but the replacements don't use the same baseline, so capitals sit lower than lowercase characters (which is jarring).  This would have been obvious if they had written a sentence in English, so I can't accept that it enhances readability.

[Localizations, Games, Apps, Docs / System Card Font Fix]

I should have done this 25 years ago.  Anyway, a long time ago, as soon as I was able...

I was playing a lot of games lately, and I was revolted by the font used by several of the American releases, as a substitute for the Japanese font.

The 8x8 fonts are usually good, but the built-in 12x12 and 16x16 fonts shatter the psyche with problems such as:
- lack of descenders
- mismatched characters within the font
- misaligned baselines
- etc.

Even fan translations avoid the built-in fonts because they're unacceptable.

So I finally took it upon myself to ameliorate these problems.
(I'm not claiming that they're all solved... but anyway, they're better than before).

I have included screenshots of an early screen on the American release of Exile (before and after); this should give a clear indication of whether this patch is for you.

I'll submit it to Romhacking.net tomorrow, and if I can get NightWolve to upload the ZIP file, I'll provide a more detailed explanation of how I did it in this thread.

[PCE/TG-16|CD/SGX Discussion / Re: Games that were first on the PC Engine and ported to SNES/SFC or genesis]

Cosmic Fantasy: Bōken Shōnen Yū (1990)
Cosmic Fantasy 2 (1991)

Ported to Sega CD:
Cosmic Fantasy Stories (1992, Sega CD)

[Localizations, Games, Apps, Docs / Re: Translation patch – POST 4 – Extracting the script]

Sorry, forgot the unicode.txt file which holds the translation between SJIS <-> Unicode.

[PC-FX Discussion / Re: Can a PICO PSU replace a stock PC FX power supply 100V to 240V conversion]

I see the source of confusion.  As you're converting 240V mains power downward to 100V in order to power the PC-FX, the term 'step-down' is more appropriate.

In any case, I haven't heard of anybody doing a power supply replacement on these units - whether to replace a faulty one, or to do as you suggest and swap for a different supply voltage.  Although I know several people (most on this board) who own one, I don't know if anybody has even opened theirs up...

If you go ahead with this replacement, I'm sure that people here would like to hear about it.

Dave

[Localizations, Games, Apps, Docs / Re: Translation patch – POST 4 – Extracting the script]

Attached is the C code.

Sorry, but I can't upload the database due to file type/size restrictions on this board.  (It could be compressed into a 495KB ZIP file though).

[Localizations, Games, Apps, Docs / Translation patch – POST 4 – Extracting the script]

Up to this point, we have discussed how to find the text and modify the print routine to accept and print Western script... so now we can move on to the script itself.

We have seen how the script is basically 2-byte SJIS interspersed with some control codes which govern some behaviors. Thanks to the print function disassembly, we have been able to understand the purpose of most of them, but they don't all need to be completely understood.

The key value which will be most important to understand initially are:

• Message terminator
• Carriage return/newline
• Clear text box
• Wait for a key
• Delay

For the Dead of the Brain project, I started out learning about these before even performing a disassembly, by finding the first-displayed string on disc and observing the behaviour of the print function when token payloads were modified.  A 'light' disassembly gave me most of the remainder, but I never truly understood the meaning of codes $04 and $06 until the more complete disassembly this past summer. This point will make more sense when you see the extractor program later.


Finding the Structure

Of course it isn't enough just to know the individual codes; we need to understand a little more about how these messages are arranged and stored: by looking at the area around the first message in a hex editor, we can see that there are many such messages stored one after another, separated by terminator codes ($01 or $00 on this games, but generally $01 – other games may vary).

If that was all the structure we needed to be concerned with, we'd just grab the text block from start to finish, translate the messages one by one, and lay them back into the ISO in the same sequence.  But since English (or French in this case) messages are not likely to be the identical length as the Japanese texts, the individual messages would shift around a bit in the block.

But that would overlook the fact that the game needs to know where these messages are, in order to print them, and there are many different ways that the game can make such references.  Primarily, these are: sequential reference, pointer blocks, and meta-script.

For sequential reference, the print function would take a request for "message 15", and find the start of message 15 by reading all of the characters from the start of message 1, counting 14 end-of-message tokens before actually printing.  This is really too much to hope for, in a game like this one.  It's not impossible though: this type of reference can happen in games where the list is short and the phrases are also short.  Some games using compression may also do it this way – decompressing a text block into a decompression buffer, and reading through it until they find the right message.

Pointer blocks are exactly what they sound like.  In this type of game, each message is referenced by a pointer somewhere, and these pointers happen to be grouped together for easy lookups.  So, "message 15" would be found by finding the 15 pointer in the block –> block start + 28 bytes (since each pointer is 2 bytes, and pointer #1 is actually at offset 0).

Meta-scripts are more complicated; they usually still have a pointer reference to the message, but it could be interspersed with references to graphics, decision trees, and so on.  This is probably a subject for another series of posts.

Finding out which type of referencing is sometimes easy (and sometimes not).  But in this case, it wasn't so hard.  Once you identify the beginning of your message in memory, use the debugger to find out where in memory a pointer to it exists.  The hard part is actually determining the start of the message, because it isn't always the first displayable character (there are often control codes before that).  A little trick is to find the first character in the next message, right after the end of message control code, and search for a pointer to that message instead.

Another way of finding it out by expanding the scope of the disassembly.  Starting from 'print one character, based on SJIS value', we have gone outward to 'print one message, based on start location', but it's not much more effort to go one step further to 'print any message, based on message number'.

As it turns out, the text for Dead of the Brain is stored in quite a neat and uniform manner:

• An overall block starts at the beginning of a sector, which is loaded into the beginning of a memory bank.
• The first thing in this block is a list of pointers into this memory, indicating the start of messages
• Immediately following the list of pointers is the first message.
• Pointers aren't required to point to sequential messages; likewise, more than one pointer can point to one message.  But if you get all the pointers, and all the messages, you should be OK.

And each block of text is stored in the same way, into the same area in memory.  Since this game is a digital comic, we also have a simpler time of it; we only need to worry about the main print area on screen:

• no selection boxes
• no status screens
• no 'in city' versus 'in fight' screen differences, and so on

Role-playing games often have these, and since they are often implemented by different members of the programming team, they can have separate print functions and support separate encodings (not just SJIS).

Also, a digital comic is generally more straightforward than an RPG because there are also no separate lists of weapons, beasts, characters, etc.

These complications aren't really so difficult, but are generally separate from the main text so they can feel like a brand new set of similar work.


Gotta Catch 'Em All

However, we still need to find all of the blocks.  You might imagine writing a heuristic algorithm to locate all of the locations which contain SJIS-character set characters, but you'd get a lot of false positives.  You could write one to search for the main character's name, but you'd certainly miss some text blocks.  Or you could do it manually.

I'll confess: I paged through the entire ISO file for Dead of the Brain, trying to 'eyeball' what looked like text.  Actually, this isn't so bad a technique on smaller files (i.e. HuCard-sized) which contain clearly-encoded text, but most people wouldn't have the patience to page through the 20MB ISO file that I did, let alone some of the 500MB ones that are out there for other games.  And even though I carefully searched, I can't guarantee that I didn't miss any text blocks. That's why I was intent on keeping the kanji print ability in the print function.


The Extract Program's Overall Structure

So, the overall structure of the extract program is basically loops within loops as follows:

• Sequence through a list of blocks
• For each block, extract all pointers into an array
• Sequence through the block of message text, extracting all messages and verifying the following:
• For each message, is there at least one pointer which points to it ?
• Do all pointers point to the start of messages in the block as we know it ?
• For each message, we also need to make it readable for the translation, so we will substitute a human-readable 'token' for any control codes.  For example, we will embed "<CR>" instead of the unprintable, unreadable $03 code.
• In this case, we also want to keep the original message sizes (to validate that our translation doesn't blow our limited memory), and all the original locations and pointers...

And we'll need to find a way to keep all this together, allowing for a script to be edited cleanly.


How Should the Script be Stored ?

From what I have seen, most of the game translations are extracted into text files (which also include information on where each message came from, etc.) and given to translators.  But not too many people talk about what happens after that.  As I mentioned previously, I have had experiences where a translator has changed/removed the intricate formatting of such a file (so that it can no longer be machine-inserted), or where a translator can't deal with SJIS files, requiring Unicode.  I've also had trouble when a script contained more than a dozen blocks, and the translator wasn't able to keep them organized.

But NightWolve had another approach which looked like it might solve some of those problems: he extracted everything into a Microsoft Access database, in Unicode, and was able to deal with scripts of arbitrary complexity by building a programming infrastructure around those elements. For RPGs, he was able to categorize which city/level text occurred in, to keep track of who spoke a given line (in order to keep their phrasing/accent consistent), and so on.  He created a local web application to allow the editor to update the text, and even had hooks into multiple machine translation engines for translator support.  And all of this about 15 years ago.

But unfortunately, it wasn't a perfect solution.  First, the programmer had to get a copy of Access XP, and use the Access tools (which I could use, but were a clunky back then in my opinion).  The Access database engine had various bugs and problems which required intervention to recover from, and Windows XP required various specific KB updates to be applied in order to get the web app to work.  While the database file was a convenient way to get all the updates packaged up at once, there were synchronization challenges if the code needed to be updated (because MS Access code lives inside the database).  And of course, over the ensuing years, each operating system update brought new compatibility challenges, as well as each new version of Access itself.

So when I revived the project this past summer, I wanted to migrate the data to technologies that demanded less support from me.  And in truth, Dead of the Brain doesn't need all the bells and whistles that a role-playing game might benefit from, so I decided to also prune anything in the data model I wasn't using, and add a few fields which might come in handy for me on this particular game.

Given my set of requirements:

• Free or low-cost technology
• All of the data stored in one file; separated from code
• Database-type format with multiple tables holding different structures
• Usable by language(s) which don't need frequent updates

...there was really only one viable choice, and that was SQLite.

I did end up spending some money on some software to convert the old Access database data into SQLite format, and I think that money was well-spent.

Since I had already extracted the data previously (and re-integrated target-language scripts for substantial amounts), I wanted to double-check that everything was OK.  I re-wrote the extractor in 'C' language for a few reasons:

• to familiarize myself with SQLite's systems,
• to check that the conversion software didn't corrupt anything in the process, and
• to verify that my original extract didn't miss anything or garble text.

I quite like the flexibility of SQLite; It holds BLOBs without complaint (original bytecode extract from the ISO), and does strings and numbers without forcing you to state the precision up front.  Since it's basically a fully-functional relational database, it's easily extensible too.  I took the liberty of changing the structure when it already held data:

• new columns to hold hexadecimal data in text format (because decimal information is not so meaningful when using a hex editor),
• triggers to log updates to a history table
• a new table to hold the pointers which need to be updated.

Once I got the structure pinned down, I went ahead with the re-extract, and I found a few surprises – but thankfully, none of them were related to the technologies involved.  As a matter of fact, they were all related to the original game authors doing unexpected things (I guess I was subconsciously expecting their code to be bug free, but I won't do that again...).

• While investigating a block of text which seemed wrong, I realized that the first pointer in the block was actually not a meaningful pointer for some reason, and as a result I had missed out on about 60 messages of real data the first time around. I set a disable flag on the bad data (rows with no stringnum; not_message =2).  The new strings were appended to the end of the data (stringnum 1857-1952), but since this is a relational database, physical location is virtually meaningless.
• I noticed that several messages which had no pointers pointing at them (where not_message = 1).  Some of them didn't contain the introductory control codes, but the text looked like it might have been connected to the preceding sentence.... Yet others looked like complete messages which are overlooked in the script.  So this may be a set of bugs in the editing process (or they may legitimately have been edited out of the script).  I wonder whether the unreferenced sentence is important to the plot (and is thus a bug).
• There were also a few pointers which pointed to the middle of one long message (see the 'comments' column); in this case, the authors probably intended to break up the string into smaller pieces, but forgot to add the string termination codes.  Again, I wonder whether the same portions of the string show up repetitively (and are thus bugs).

I became comfortable with the extract only because I went though each block and verified it.
That is to say, I did the following for each block of the script:

• Uncommented ONLY the element in the block array corresponding to the block I was working on,
• Set the START_STRING define to the appropriate starting string number for the block
• Set the UPDATE define to zero (output log info; don't update the database)
• Executed the program and examined the output...
• Once satisfied, I went back to set the UPDATE define to 1 (update the database) and ran it again

If you look at the code, you'll understand what I mean.

I've attached the code and the database extract (although I removed the translation messages).
Please peruse as you like, and discuss in the thread below.

There are several very good SQLite editors out there which don't require the user to be SQL-literate (like 'schema browser' on TOAD or PL/SQL developer, for anybody who has used those....).  The one I have been using for various browse and query operations is  "SQLiteStudio".

If you would like to compile the 'C' code, please grab the "SQLite Amalgamation" from here (you only need the 'sqlite3.c' file and the two '.h' files from the zipfile):
https://www.sqlite.org/download.html

I'll take a break before posting more on this; although I have the inserter ready, the edit and test phase is starting, so there are probably a few more things I'll learn during that process.

Return: Part I

[PC-FX Discussion / Re: Can a PICO PSU replace a stock PC FX power supply 100V to 240V conversion]

Not sure what you mean by "I am tired of using a step up converter for my PC FX in my set up".

A stock PC-FX expects wall power to be 100V as it is in Japan.
What voltage is in your area, and what voltage are you converting it to ?

I only ask because the way the question is worded, it sounds like you may not be using an original power supply in the first place.

Dave

[Console Repair/Mod Center / Re: SuperGrafx corrupted video - PCE works fine]

For one thing, the SuperGrafx has an extra video processor and memory.

If the SuperGrafx games play OK but with corrupted graphics, I would suspect that the video chip itself is working, but somehow the memory is the problem (second choice is the video processor).  Maybe check the traces to and from the video memory chips...

[Console Repair/Mod Center / Re: Cat + PC Engine Duo = Bad]

Well, if the CD doesn't start spinning, you aren't seeing a laser-alignment problem (although I can't guarantee that you don't also have one).
I have seen some old systems fail to spin up, but I don't know enough about the electronics to know whether it could be explained by old/dead capacitors (probably could...).

[Localizations, Games, Apps, Docs / Re: Translation patch – POST 3 – Print Function Modification]

And these are the patch-related files (added TXT file suffix to them to get past the board filter).

[Localizations, Games, Apps, Docs / Re: Translation patch – POST 3 – Print Function Modification]

It looks like ZIP files are not allowed on this board (in fact, most file types are not).
So I'll try to upload things as possible.
The print function disassembly files were changed to .TXT, and attached to the top post in this thread.

This post should contain the FONT-related files... but doesn't contain all of them.

In order to post, I had to change the BAT file to a TXT file, and I am unable to change the BIN file to anything usable... you'll just need to create it for yourself by running the BAT file with FEIDIAN against the BMP file.

[Localizations, Games, Apps, Docs / Translation patch – POST 3 – Print Function Modification]

We left off with a commented disassembly of the print function, and some questions about how one would implement a modification for western languages.

Some hints from the disassembly and knowledge of the machine's hardware:

• This print function is capable of printing both 16x16 and 12x12, as the 'kanji size' flag to the EX_GETFNT routine is not a constant, derived from PRINTFLAGS third-least-significant bit
• Similarly, the horizontal spacing is set by a flag within the PRINTFLAGS token's payload byte's most-significant 4 bits (shifted right of course)
• The 'normal' tiling/character layout on this machine would easily support 8x8 or 8x16 printing, which is ideal for latin-type letters

Tinkering around, we can modify the PRINTFLAGS (token=07) payload byte to adjust the amount of offset per character. I found that 'PRINTFLAGS=0x' (16 pix wide; 0 pix offset) worked well, and 'PRINTFLAGS=4x' (12 pix wide; 4 pix offset) also worked fine, but if I went one step further to 'PRINTFLAGS=8x' (8 pix wide), it didn't print well. Most other values also fail. So effectively, we realize that the appearance of being a very flexible print routine is only skin deep: since the original authors only believed that those two values were going to be needed, those appear to be the only values tested.  After digging into the print function, we realize that the sizes are hardcoded at various spots, so the design itself is deceptive.  This sort of thing happens a lot in "other peoples' code"; take nothing at face value, and take nothing for granted.


Previous Attempt at print function modification on Dead of the Brain

First, I need to give a bunch of credit to Tomaitheous (aka Bonknuts, aka Rich), who put a lot of effort into locating the print function, some initial disassembly, and working on a print function modification with very lofty goals. His goal was to create the first variable-width font (VWF) modification on the PC Engine, with a narrow font which could fit a lot of information into the box (compensating for the fact that English - and even more so French - uses more characters than Japanese to express the same thought). He also planned to use compression to squeeze it all into the small available space.

Without his effort I probably wouldn't have proceeded on the script extract. He accomplished a lot when the tools weren't really around to do much debugging.  Unfortunately, the initial text insertion revealed bugs in the print function, and while we worked together to try to identify and resolve these, ultimately we each became busy with jobs/life and progress stopped. One possible contributing factor is that the original print function has some weird quirks about tile allocation which I noticed during my own disassembly/patch efforts this past summer, (and I still don't completely understand some of the design decisions the original author made).


My Philosophy

When creating a print function modification, you can do it one of two ways:

• Replace the entire print function with one of your own making. In this case, you bear the risk that some external function makes an unexpected jump into the print function for its own undocumented purposes, expecting a certain output... which your replacement code likely won't replicate.  Games of this generation were all still written in assembler which promotes such bad behaviour; the next generation of consoles used higher-level languages which reduced these sorts of shenanigans.
• Or, you can perform the minimum possible change to the original function, which should preserve even obscure, hidden functionality.

...I'm not sure which approach the original print modification took, but it was ambitious. It may indeed have started as "minimum possible", but it likely ended up replacing existing code to some extent.

While I continue to have a great amount of respect for what Rich attempted (and EsperKnight later also looked into), I personally prefer to start with the "minimum possible" approach:

• I want the original kanji to remain printable -> in case I failed to locate all of the script for some reason, play-testing should still print the text as a clue to finding/fixing it.
• I want to work within the limits of the existing print function to extend functionality to include a simple 8x12 or 8x16 latin character print function which snaps into the same touchpoints the existing print function does.
• Once the "minimalist" function is working, I may consider the variable-width font as a 'stretch goal' in case I still wanted to get fancy once everything was working.  But I would certainly hold on to the 'cruder', working version as a fallback.  Keep in mind that any added complexity brings added risk, and I prefer to start my project with as little risk as possible (projects are full of surprises as it is).

...So this is exactly what I did exactly did this past summer: I implemented a much simpler print function modification, touching as little of the existing print function as possible, and retaining the ability to print kanji.

I have attached all of my code here, including a repost of the print function disassembly, now including patch points for illustration purposes.


-> See printfunc_disasm.zip for files printfunc-disassembly.asm and printfunc-disassembly-ramuse.asm


What exactly do you mean by "PATCH POINT" ?

Of course, all the code resides at fixed locations in memory, and we want to add some code. As I mentioned before, we could replace the whole function... but that could have complications. So, we locate the exact step where we need to intervene and replace it with a 'jump' to our own code block. The 'jump' instruction takes up space, obliterating one or two operations which were previously there, so we also need to transplant those instructions in our routine, whether we execute new code, or 'short-circuit' back out to the original code.

Note:  those instructions might set flags which are examined later, so we will need to keep that in mind and tread carefully in order to preserve such flags.


Steps

First, I felt I had to understand the existing print function completely. I already had some disassembly notes from long ago, but they were actually only about 40% of what I wanted. Worse, I hadn't taken the time back then to completely document the print function's RAM usage – maybe I thought I could remember it... well, I couldn't.  Document the print function – your notes will be needed later (at some point).

Once I had the disassembly, there were a few key touchpoints:

• When the print character is read, the original function check for special characters below $20, which clear the screen, end messages, and so on. Otherwise, it assumes that all text is going to be double-byte SJIS (first byte is a value above $80).  This is PATCH POINT #1; it needs to realize that there are valid values between $20 and $80.
• The new print function should re-use as much as possible of the existing 'tile allocate', and 'print' functionality (primarily 'shift'-'mix'-'display' steps).
• I needed to be clear about how to adjust the print function, since the new font was narrower; boundary adjustments (crossing the limits of am 8x8 tile) are different. Since the new font is narrower than the kanji font, it's simpler than if the new font were wider.
• I needed a font to display. I decided on an 8x12 font for a couple of reasons: a) 12 pixels is enough to provide for adequate descenders ('g', 'j', 'p', 'q', and 'y' which dip below the line on which everything else rests), and matches the 12x12 kanji height.  b) free space to store the font was limited, but there was enough to store a 12-pixel font without needing to compress it.
• I needed to be sure that there was room available to fit it. Based on the data on disc, there was an apparent empty area at about $DA50, until $DFFF (the end of the sector, also the end of the bank).  So I put it there, at $DA60. I also needed a couple of scratchpad values, but I couldn't rely on random areas in the $2000 segment, so I just used the adjacent memory (since it runs from RAM anyway), at $DA5C.

The print function modification simply adds the following functionality:

• Check whether the next character is between $20 and $80. If not, do whatever the function would have done if not patched. Otherwise, go to the special print function.
• For latin characters, use the same 16x16 graphic buffer that the EX_GETFNT function uses, but put our own graphic data inside.
• Return control back to the print function, but leave a flag set, so that the pixel-adjustment (for 12- or 16-, and now 8-pixel characters) can adjust their pointers properly to get ready for the next character's starting point.

A word about creating the font data:

You could put this together as a series of byte-definitions in assembler, but a graphic is easier to edit, review, and so on.  I have included a 1-bit BMP (careful, it's a relatively rare format; lots of editors try to bulk it out to more bit depth).  I used a free editor I found online called 'Pixelformer' which preserved bit-depth.

Based on the fact that the inserted script will be French, the font will need to include accented characters which aren't part of the standard ASCII set.  On the other hand, we aren't using all of the standard ASCII characters, so several of them have been replaced with accented characters.

Once the font is visually OK, the BMP can be converted into a binary file, which can then be inserted.  For this, I used a program called 'FEIDIAN' to do the bit conversion.


-> See font.zip for files DotBNewFont-8x12.bmp, NewFont8x12.bin, and GetFontBIN.bat which contains the FEIDIAN command-line parameters needed.  FEIDIAN is available separately on GitLab


Putting the print function modification together:

The best way to make even the simplest piece of assembler code is to use the assembler.  Of course, it can be done by hand (I've done it many times), and you may convince yourself that it's small enough... but sooner or later you'll miscalculate an offset, or you'll need to insert a line and need to adjust everything.

However, the PCEAS assembler only outputs to a new file; it doesn't directly patch an existing one.  So I had to write another program ('filepatch') to patch the base ISO file based on the PCEAS output (i.e. copy blocks of bytes from one file into the other file at a given location).  It's parameterized to allow entry of: {target file, target offset, patch file, patch offset, patch length}.
Then I wrote a shell script to sequentially patch each of the necessary blocks to be patched this way (it's a UNIX batch file, but should be trivial to switch to a Windows BAT file).


-> See dotb_printpatch.zip for files DotB1_patch_2018.asm, DotB1_patch_2018.lst, filepatch.c, and patch_dotb (shell script)


I think this provides a fair overview of what's needed in the patch, and I really hope that the comments in the code provide enough specific detail to give a programmer not just an overview of a print function modification, but a concrete example to learn from.

Please reply to this thread with any questions, follow-ups, comments, etc.


Next post:  Extracting the script

Continued: Part IV

[Localizations, Games, Apps, Docs / Translation patch – POST 2 – Isolating Text & Print Function]

I'm putting together a few articles on the subject of translation patch creation; I'm hoping that the forum-post format (thread per major subject) will allow a lively supplemental discussion to follow each post and explore a little deeper into areas in which people are interested. In the event that an initial post on a topic is too large, I'll try to break it into sections and post consecutively to the same thread.

Part of the process of selecting a game is determining how difficult the technical portion will be.

HuCard games generally use the 8x8 tiles available in hardware – but can define their own custom character sets, often making it difficult to search for text (due to the custom encoding). I'm not going to focus on this type of game today, but I will mention that the best place to start is to locate the definition of the character set (held in VRAM), so the encoding can be determined. This would be done with Mednafen in the same way as any character graphics would be found/isolated, and worked back to the source location.

Today's focus, however, is on locating the print function and script from CDROM games (or at least trying to).

Before We Start

• You should have a working version of Mednafen (any version in the past few years should be adequate).
• Also, have a digital copy of a CDROM game you wish to locate text on (RPGs or digital comics are likely to be better examples). Make sure that your digital copy is ISO/WAV. That is to say, the CUE file should refer to the data track(s) as "MODE1/2048".

Note that I will be using hexadecimal a lot in this post; since the 6502 convention is to prefix values with the dollar sign and capitalize the letters, I will try to ensure that this is done for addresses and values that the processor uses (i.e. '$F8'). For offsets into the ISO file, I generally use the 'C' convention of the prefix '0x', often with lowercase alphabetic characters ('0xffff'). And for a string of bytes, I hope that just using the pattern of repeating 2 digits+space is adequate.  It'll make sense... (I hope).


Where to Start ?

Like any sufficiently difficult puzzle, the key is to start at the most basic/simple/already familiar part, working outwards and solving the unknown at the edge of what it already known.

In this case, the key is the kanji graphics – NEC had the foresight to put a substantial kanji character set into the System Card, so that game developers wouldn't have to create their own character set definitions for the huge set of kanji in the Japanese language (effort which is better spent on other graphics). In order to make use of it, the game needs to make a system card call with a 2-byte SJIS value, getting the graphics data back in a buffer. This in turn means that the text to be printed is either stored directly in SJIS, or in a source format from which SJIS can be created easily.

The EX_GETFNT Call

The EX_GETFNT function is at location $E060, and the system card functions always expect parameters to be passed via the zero-page location between $F8 and $FF (or in registers).

For EX_GETFNT, the parameters are passed as follows:
$F8/$F9 = Kanji code – note: this processor is little-endian, so $F8 holds the least-significant byte (LSB), and $F9 holds the most significant (MSB)
$FA/$FB = destination address for the graphics (32-byte buffer)
$FF = transfer mode ($00 for 16x16 size; $01 for 12x12 size)


Mednafen's Debugger

If you've never used Mednafen's debugger before, it's indispensible for this kind of work. You should get accustomed to the debugging functions and features.

• Start up your game, and the CDROM "Press Start" screen comes up.
• Press 'ALT-D' to enter the debugger. Multicoloured information will appear, moving quite quickly. (Don't worry, you don't need to make sense of it yet.)
• Press 'g', and a popup box will appear with the heading 'Disassembly Address'... back up over the existing address, and enter 'E060' (the EX_GETFNT address mentioned above)
• A long list of 'JMP <address>' statements should appear in the disassembly list, with the 'E060' line highlighted. Press the spacebar to set a breakpoint, and a '#' will appear at that address.
• Press 'ALT-D' again to make the debug screen disappear; now start the game. As soon as the EX_GETFNT function is called, the debug screen will appear again (and the game will stop executing)... if the game starts printing text without stopping, chances are that you've chosen a rare game which doesn't use the built-in font. Or, perhaps the game has stored some title-screen graphics as graphic data, and the game isn't actually trying to print anything yet... advance the game a little bit to confirm.

OK, The Debugger Returned... Now What ?

So now, the debugger appeared again, and the game stopped. The disassembly list shows the jump table, just like the last time you left it, with the E060 line highlighted. You might ask yourself... "now what ?"

Get your deerstalker cap out of the closet... the game is afoot !

I've attached a screenshot of this exact moment while playing Dead of the Brain 1:



If you look closely, you'll see that I've also put a few red rectangles around some key information:

The patchwork square(ish) block of coloured numbers is zero page memory, which you will frequently consult while debugging; I put boxes around each of the parameters which EX_GETFNT uses... so:
$F8/$F9 -> shows us that the SJIS character is $8352 (remember, LSB is stored first)
$FA/$FB -> show us that the graphics buffer is at $3529
$FF -> shows us that the 12x12 version of the character is being requested

I placed another box in a list area – this is a traceback queue, which tells us where the processor has been before it came here. If you hit 'g' then put 'C778' in as the address, Mednafen will display a disassembly of the most recently-executed section of the game's print function.


Suggested Clue Gathering

A short list of things I usually do next is as follows (but other people may have a different approach):

• Note the location of the print function tidbit ($C778), as this will be the part of the print function from which the disassembly will start. This disassembly is needed in order to gain an understanding of how the function works internally (and the basis of how to patch it). Much of the traceback queue will be parts of the print function; try to understand its scope.
• Write down a sequence of actual bytes from the routine (several bytes before and including the call to $E060). Later, search the ISO file to find the origin sector(s) of this program; usually it just needs a few bytes in order to find it definitively (although sometimes the same code may appear more than once, because it is repeated in different overlays, or implemented several times related to different parts of the game).
• While the disassembly is still open, hit 'R' (run), and there should be a brief advancement in the game (about 1/60 of a second), before the next call to EX_GETFNT. Note down this SJIS value as well (on Dead of the Brain 1, this is $815B). And get one more SJIS value... (DotB1 = $838B). Using these values, search through the ISO to locate this group of bytes to find the string. Hopefully, the first few characters are more unique than the name of the main character (which may show up hundreds of times).

If all of this works out, you are well on your way... but if it doesn't, here are a few possibilities:

• If EX_GETFNT is never called, you'll need to find a completely different way to get at the text and the print function.
• If EX_GETFNT is called, but you can't find your SJIS on the disc (the above example would search for the following sequence of bytes in hexadecimal: 83 52 81 5B 83 8B), make sure that you haven't transposed them... the script itself is MSB first (such as in a byte stream), but as a 2-byte value used by the processor, it's LSB first. Could be confusing the first time you see it.
  
  • If you still can't find it, the text could be stored in a different format – either as compressed blocks, or using a token system, or some other format. Or it may have some control characters interspersed... If it's not easy to locate the first string, that game may not make a good candidate for a first translation... (unless you were already using assembly in the 8-bit era, and enjoy a good challenge).
    
• If EX_GENTFNT is called, but you can't locate the print function on disc based on the bytes you grabbed from the disassembly, check again – you may have transcribed something improperly (it's happened to me). It's not very likely that the code itself would be compressed or self-modifying.

Next Steps (Still Early Days)

Next, you could continue in either of two places – the script, or the print function.

For the script:

You may want to make a small adjustment in the script (within the ISO, where you found it):

• Change a Kanji character into – for example – SJIS 'A' (hex 8260), just to prove to yourself that you actually found it. (Run the game again to see the effect)
• Then, try changing it into couple of ASCII characters, just to see whether the print function can currently support regular ASCII (rare, but worth a try).

In order to really understand the script organization, though, you'll need to understand some more about the tokens, and the overall complexity of the strings. For that, you'll need at least some of the print function to be disassembled and understood.

For the print function:

Use a disassembler, and read the code in order to distil meaning from it.
...I know, easier said than done - but as I mentioned at the beginning of the post, start with things that are obvious, and comment them until you reach the edge of what is obvious. Including the scratchpad RAM usage. And a 100% understanding isn't always needed in order to get what you need.

So, this will start with the part leading up to the call to EX_GETFNT; if you trace back enough, you'll find the loop where it fetches the string's characters, and checks token values. At some point, as you try to understand what the original programmer was doing, you may reach a dead end... at that point, look for other familiar things, such as accesses to the VRAM (another 'fixed truth' of the machine are the VDC hardware addresses), and look at how they manipulate data and so on.

It's not a trivial piece of work, so you will need patience and an inquisitive nature to accomplish this. Chances are, you will at some point find something that looks like a bug. Maybe it is a bug, but the programmer 'fixed' it with a countervailing bug elsewhere. Or the programmer had a strange way of viewing the problem and implemented the solution in a completely counter-intuitive and inefficient way. Ah, the joys of examining somebody else's code...

Reverse-engineering somebody else's program without source code is not easy (it's often difficult even with source code!), but – thinking of it as a puzzle – it can be incredibly satisfying to solve.

I'm going to repeat this, because I don't think I can stress it enough – while understanding the print function, I found the most important thing was determining what scratchpad memory was being used for, so whatever you do, don't skip documenting that.

Hopefully, you will eventually come up with something like the files I am posting here – but it will take some time. Mednafen's single step function ('S' in the debugger) is also helpful, and so is setting other breakpoints to go over the boring parts. With a debugging emulator, we now have the luxury of seeing what values are reasonable (by viewing them 'live'), where branches actually take us, and so on. Much easier than just using a paper disassembly.


Notes (follow-up on my 'clue gathering' suggestions above):

• Based on where the call to EX_GETFNT takes place, the print function is anchored at 0x15f9e in the ISO file (corresponding to $C79E in memory)
• It turns out that the first few characters of the first message in DotB1 aren't unique enough, being the main character's name (I mentioned this could happen). The actual location would be found at 0x70f8f7, if you took enough characters from that message to get a unique string. This corresponds with the in-memory address $40F7, which coincidentally is an address you can see in the screenshot above, in the list of zero page values, at <$72/<$73.

Attached are my commented disassemblies of the print function, for your perusal:

printfunc-disassembly-ramuse.asm
printfunc-disassembly.asm


To Study/Consider in Advance of the Next Post

• Take a look at the disassembly of the print function -- in particular, the main print loop
• Think about where/how you might patch this print function in order to get western characters.  (Note: Like most surgeries, I always find that being minimally-invasive is a good policy to prevent failure.)
• If you have the ISO of this game, study the block of text in the ISO file, and see if you can identify any patterns/structure behind the strings, which may need to be preserved/updated on extract/re-insert

Next post: the print function patch

Continued: Part III

[Localizations, Games, Apps, Docs / Translation Patch – POST 1 – High-level Overview]

So you want to create a translation patch, and you'd like to know how somebody does such a thing ?

I'll be putting together a few articles on the subject; I'm hoping that the forum-post format (thread per major subject) will allow a lively supplemental discussion to follow each post and explore a little deeper into areas in which people are interested. In the event that an initial post on a topic is too large, I'll try to break it into sections and post consecutively to the same thread.

Today, I'll just give an overview...forgive me if today's post seems too short on details (even though it's a pretty big post); the next post will provide plenty of details.

If you're thinking of doing a translation patch, you'll need to consider all the following:

• Choosing a game to translate
• Somebody to do the translation
• Somebody to do the technical work
• Since these two roles are rarely performed by the same person, you'll need to have a few things in common:
• A method of communication
• Keeping track of versions, and ensuring the back-and-forth remains cohesive (i.e. version control/management)

Before you even start, you should know that translations are marathons, not sprints. For a CD-ROM scale game, be prepared that months or even years may elapse between the start of the project and when you're ready to release.


The Game:

Choosing the game is all about trade-offs... the factors are basically:

• Desirability of the game
  
  • Is anybody (especially yourself) going to actually play it ?
  • Are you going to get sick of it during play-test ?
• Complexity – which can mean:
  
  • Size of the script
  • Complexity of the language in use (technical terms ? poetry ? jokes ?)
  • Whether the script is easily identified, and/or stored in compressed format, etc.
• Whether there is enough space... and by this, I mean two things:
  
  • Whether English will fit comfortably on the screen. For example, it's easier to fit "FIGHT" (or similar word) into a choice box if the original Japanese is "たたかう", rather than "戦う". Again, English takes more characters to do the same job, but each character may be narrower.
  • Whether there appears to be space (i.e. in memory) to reinsert the script into the game itself. The more compressed it is, the more difficult it could be. Raw ASCII English (1-byte per character) and raw SJIS Japanese (2-bytes per character) are going to be relatively similar in size, because of the density of the languages themselves (note that French/Spanish may require more space to convey the same thoughts). If the Japanese stores kana as 1-byte, or if there is an efficient compression for the Japanese, you will need to worry about whether there is extra unused space available in memory (and/or on disk). Hopefully, you won't have to create a compression mechanism for a game which isn't currently stored as compressed text.

By the above standards, HuCards are probably going to be simpler projects than CDROMs...but you may not enjoy HuCards as much as CDROMs. On the other hand, CDROMs tend to use the System Card routines for printing kanji, so it may be technically easier to find the print function and the script on a CDROM game, because they are less likely to use compression or a non-standard character set than a HuCard game.

My example will be a CDROM game, so I'll show some techniques which are specific to that format.


The Programmer

The programmer doesn't need to know much Japanese, but it definitely helps. They should be able to recognize hiragana, katakana, and kanji on sight. An important factor is whether they can identify whether a word (or sentence/phrase) is complete, or whether some other odd encoding is in place. When I first looked at Emerald Dragon, I located partial words in the data track, but couldn't figure out why entire sentences couldn't be found...until I realized that there was compression involved.

The programmer should be familiar with the memory-mapping model of the PC Engine, assembly language, and 8-bit programming in general.

This shouldn't need to be mentioned, but the programmer should also be comfortable with hexadecimal, since they will be looking at hexadecimal listings in order to figure out where pointers are and where they point to, what the special codes mean, and so on.

The programmer will need to find and/or write various tools, because a lot of this work is so specialized that there aren't many tools flexible enough to do what you need them to.

Of course, it may be the case that more than one programmer exists on the project, but that would be distinctly rare. Such a team would be better-equipped to suffer the loss of team members, but communication and division of responsibilities would need to be considered.

Special notes to the programmer(s):
Even games which appear to play without issues will possess bugs which you may uncover. Games with apparent bugs – even rare ones – should be treated as poison.

You will likely find oddities when you are doing your text extract program; because of this, you will likely spend time cross-checking mis-referenced and unreferenced text, trying to infer why these issues exist. As a result, don't expect your extract program(s) to simply run one pass, and be complete. In the text extract post, I'll provide examples with some conclusions I have drawn.


The Translator

The translator needs to be able to deal with the fact that there are special characters in the script which will need to remain, because they are there for a purpose:

• Change text color
• Wait for a key
• Speed up/slow down text
• Short form for a character's or item's name
• Switch between hiragana/katakana
• Etc.

The translator will ideally be able to write well (i.e. literary, not just literate) in the target language, to be succinct where needed in order to make the text fit, and to maintain the correct "voice" for particular characters (i.e. a Southern accent on a character should remain consistent throughout the game). As such, the translator will in most cases need to manage which lines are being uttered by which characters, and what 'persona' those characters will project.


A brief note on choosing team members

Of course, skill is important, but first and foremost, they should be both patient and committed to the project. As I mentioned, any such project is a long-term project, and there will definitely be interruptions (i.e. "life"). Everybody must be in it for the same reasons, and persistent if a project is going to succeed.


Assets to translate

There's almost certainly going to be more material requiring translation than it first seems. Also, there's a difference between making a patch "good enough to make a game playable", and making a full translated version (this is another decision to be made, and team members should be in agreement).

Here is a list of necessary assets, and a list of easy-to-overlook ones:

• Text – the script of the game which includes the narrative and the dialogue
• Choice boxes (fight/run/status/etc.) – These are generally stored separately from the text, and are often stored in kana rather than kanji
• Lists – you can consider these 'pronouns', as they are often in separate lists in order to save space. These may include items, magic spells, bestiary, potential fight outcomes (i.e. 'took a hit'/'missed'/'gained a level'), etc.
• Scenery graphics which include signs/graffiti/etc.

Things which may not be top-of-mind include (leaving any of these out may make the translation seem less enjoyable – and sometimes even less playable):

• Title screen graphics
• Ending credits (could be text, and/or BG graphics and/or sprite graphics)
• Incidental "text stored as graphics" (think 1960's Batman – "BAM !", "POW !" balloons). These graphics (often sprites) become more common in later games for the PC Engine (1993/1994 and onward)
• Voices stored in ADPCM during normal gameplay (which often – but not universally - have accompanying text).
• Narrative/dialogue in cinema scenes which normally doesn't have accompanying text; these could be stored as ADPCM or redbook audio. For any speech which doesn't have accompanying text, you'll need to consider whether (a) It's good enough to have a written translation in a textfile, (b) you want to dub a version, or (c) you believe that it's technically possible and even easier to subtitle any graphics (note: this last choice is not likely)

A few hints:

• Text is easier to manage than graphics (which often needs an artist to modify).
• Graphics is easier to deal with than audio. Audio doesn't just require a translated script, but also performers, sound mixing expertise, and... if you're a perfectionist, some additional programming skills to alter the pace of the lip movement. Or conversely, performers who can match lip movement. But anybody who has ever watched a dubbed live-action movie knows that this just can't be expected in a dub.

Programming Tools Needed

As I mentioned before, you may end up writing your own tools. I prefer to use off-the-shelf software where possible, but it isn't always possible...

You will need:

• Hex editor which is capable of displaying SJIS. Even the best choices here have issues, like when the first byte of a 2-byte SJIS character occurs at the end of a line – so you can't clearly see the character.
  
  • Personally, I use a really old copy of Ultraedit that I bought 10 or 15 years ago, on a Windows 7 virtual machine, using Applocale to set the locale to Japan. Windows 10 doesn't seem to like Applocale, so if you use this tool, you will have to change the whole machine's locale to Japan (which probably isn't as bad as you think).
• Debugging emulator which is capable of properly playing the game.
  
  • These days, Mednafen is pretty much ideal for this; it was really hard to get anything done before this. For the truly ambitious, you can also modify the source code to add your own features.
• Programming tools, including an IDE. This is really more about what you're comfortable using. Keep in mind that Microsoft tools get refreshed every 3 years or so, and they pretty much always require some investment in updating your code in order to continue using their 'new, improved' tools. This can really creep up on you if you don't refresh your computer often – and suddenly you find yourself stuck with a huge amount of work modifying your code if you're 2 (or more) major versions behind.
  
  • I personally use Eclipse/CDT because I am comfortable with 'C' and like the IDE. It's also free and quite functional.
• Graphics browsers and extractors, for graphic assets
  
  • There was once a program called TMOD2 which I had written PC Engine sprite and background plugins for, but the program won't run on modern Windows systems. You may be able to find other graphics browsers which can view tile formats, but I am currently not aware of any which can view sprites or accepts plugins for your own code for sprite viewing.
  • There are graphics extractors, but they can be esoteric... I am using FEIDIAN for my current project.
• If you are planning to extract/re-implant ADPCM, I wrote a couple of tools for the Emerald Dragon project. But I have also heard that a program called 'SOX' is just as good (or perhaps better). I won't be able to provide any good advice on recording or mixing audio in general though – I'll leave that to somebody with more expertise than myself.

You'll also need to consider file formats for extract of the script, listing pointers, disk locations, etc.
...Well, this is one of those things where you're going to have to think about what works best for you, and it will probably depend on the script itself.

I originally started doing this by extracting each text block to a separate textfile, storing it in the original SJIS format, but I found some problems doing it this way, such as:

• Not everybody can view SJIS easily anymore – it's gone out of favor since about 10 years ago, being replaced with UTF-8.
• When the script was extracted as multiple files, it generally turned out to be a large number (> 60). These rapidly became unmanageable between translator and programmer.
• While the extracted text files were strictly formatted with line separators, special codes, etc., more than one of my translator counterparts had difficulty maintaining that strict formatting, leaving a lot of work to clean up those files for reinsertion.

In the 'extract' post of this series, I'll show a different way that I decided to use on my current project.


Keeping Things in Sync

Of course, communication is the most important aspect here – the programmer and translator need to be on the same wavelength, and the tools need to built to support the workflow.

But there's still the problem of keeping track of where you are in the overall project, and being able to start up again after a gap in the schedule. For this, you'll need a couple more things:

• Comments in the code, and notes files, detailing what you have completed, what is pending, and some challenges faced/how you overcame them. Human memory isn't perfect (as I can attest to).
• You should keep "snapshot" backups of your work, at point in time which are meaningful (i.e. "finished first pass of city #1 'Ergot' text and bestiary").
  
  • Rather than keep a series of ZIP files with dates in them, it's a better idea to get used to a version control system as used by programmers. Git seems to be the current popular version, but others include Subversion, CVS, SCCS and RCS. Don't forget to clearly comment every commit, and keep a TODO list.
  • If you use Git, it is pretty easy to keep all of the files (programs, scripts, assets) in sync between more team members, so if you are thinking about a larger project with people who can work together, this is probably the way to go.

So, the above summarizes the basic 'first principles' in terms of starting and managing the project.

Of course, when we talk about Project Management, talk inevitably turns to the things which PMs are expected to manage:

• expectations
• scope
• budgets
• dependencies
• delivery dates
• quality

Since we're talking about something which would be made available for free, expectations are directly related to any advertising which the team may have done, and budgets are effectively zero (or whatever you are willing to contribute from your own pocket). So... not much to manage there.

Scope and quality are determined by the participants (see above, assets to translate, and 'are you going to get sick of it during play-test ?')

...Which leaves us with dependencies and delivery dates. These are determined by the availability of the participants, and the overall size of the project.

• The technical part can vary so much that it boggles the mind
• Play-testing is going to be related to the number of bugs, the size of the script, and how long the game usually takes to play. A digital comic, while it may have a similar (or even larger) script compared to an RPG, is almost certainly going to be faster to play test, because there is very little complexity - it's all about adjusting text and formatting, not about actually progressing in the game in order to see the line of script.
• Translation of the script, however, seems to be the one component which should be possible to estimate. Of course, one 2500-line script can be a lot harder than another 2500-line script, but I wish I could give some sort of loose guess as to the size of the effort - if only to help people realize which projects are achievable with the resources they have. Maybe we can see some discussion on this point below.

I hope I have given you some things to think about in this introduction. Please provide feedback, comments, questions and discussion of this post as replies to this thread, below.

Upcoming topic: isolating the main print function and text

Continued: Part II

[PCE/TG-16|CD/SGX Discussion / Re: Does anybody already have an UperGrafx UGX-02 ? (memory card compatibility)]

I know that one thing on everybody's mind with a product like this, is its compatibility (are there any problems with specific games ?)

So as a follow-up, I've been working on a compatibility spreadsheet with the developer; he was using it for people to provide feedback to him on issues, but there wasn't a whole lot of positive feedback being provided for the public.

So, I've been playing games for several weeks to get to a point where the "compatibility rate" can actually be expressed.

It's all in a spreadsheet here:
https://docs.google.com/spreadsheets/d/1EIKgENXwRR7JhZSaE76bVxHXJoCKdr8AGf44t82TEu4/edit#gid=0

Basically, every CDROM game was played for at least 5 minutes (usually more than 10, and many to completion), to see whether there are any large issues (i.e. which would prevent the user from completing the game), or small issues (mostly annoyances like random noise or even a de-sync between voice and movement on screen).

Out of a total of 471 games distributed on CDROM media:
- 12 have issues large enough that they can't be completed by a player
- 13 have annoyances somewhere (most of these annoyances are in the video cut-scenes rather than the game itself)
- 4 have slight imperfections (i.e. issue somewhere between "I didn't notice it" and "infrequent annoyance")

...And this is with the October firmware; I know that there are at least 2 more fixes pending the next release.

Many of these are simply lip-synch issues (about half of the "minor" and all of the "slight imperfections"), and most of the others are common to more than one game, so I expect that these will be fixed in relatively big jumps.

Dave

[PCE/TG-16|CD/SGX Discussion / Re: What Turbo game are you currently playing?]

I wasn't sure what you were talking about, so I looked it up - there was a "walkthrough" insert in one of the magazines back in the day... the walkthrough wasn't so thorough, but it had a pic of that scene.  It's perhaps an overstatement to say she wasn't wearing any pants... her white shirt covered the same area in the same way as if she had been wearing them.  This is probably why nobody talks about it - it's really hard to notice.

I'm pretty sure that the patch left it as it was in the American release (red hotpants).

[PCE/TG-16|CD/SGX Discussion / Re: What Turbo game are you currently playing?]

For Cosmic Fantasy, they also undid the censorship on graphics. I think all it was, was Babette flipping the bird to the computer, but I wasn't sure whether the shower scene was also affected. They said difficulty and gold had been adjusted, but to be honest, I didn't notice.  (Of course, I hadn't played it in like 15 or 20 years).

For Exile 1 and Exile 2, it was all about difficulty. I was able to beat Exile 1 back in the day, but I was frustrated by the final boss sequence in Exile 2 back then (something about a staircase... this was about 20 years ago).

Over the years, this difficulty level became famous (because it was effectively untested and a mistake), and I've been dying to try out a patch which corrects that.

Here's a link to the post where all of the changes are described:
romhacking.net/forum/index.php?topic=23436.0

Like you, I felt that they expressed their feelings a little more emotionally and more specifically at a person/entity (Working Designs) than would have been optimal.

Dave

[Console Repair/Mod Center / Re: Need help with repairing a PC Engine GT]

If these tantalum capacitors are better how come no seem to be using them? Or are they just that much more expensive?

Yes they are more expensive - but not enough to make your eyes water (or at least weren't the last time I looked at prices).
Probably worth it if you fear doing another replacement in another 5-10 years.

Sorry, I don't know about the grey or white blob you see...

[PCE/TG-16|CD/SGX Discussion / Re: What Turbo game are you currently playing?]

I've been testing out the UperGrafx digital video/CDROM replacement device for compatibility lately, so I've been playing a lot of games, after a long absence from playing anything...

For American games,
- Just finishing up a run through Cosmic Fantasy 2 again (this time, with the "Un-Worked Designs" patch)
- Next up will be Exile/Exile 2 - again with the unworked designs patches to return difficulty to the original - maybe this time I'll be able to complete Exile 2 !

Now that I have several years of Japanese study under my belt, I also tried to work through a bunch of Japanese games... I understood more of the digital comics than I expected (as in, close to 100% without looking up many words), but RPGs are still a mental challenge.  Just finished these in the past 2-3 weeks:
- Pastel Lime (very short and kind of dumb)
- Gunbuster 1 & 2 (though I loved the anime, these games were not nearly as good as I expected)
- Fushigi no Umi no Nadia (overall I liked this)
- Urusei Yatsura (nicely done, but a little long)

Currently working on:
- Galaxy Fraulein Yuna (not so bad - great graphics and voicing, but slightly tedious because the story is a bit on the juvenile side)
- Sailor Moon (a little childish, but OK I guess - based on the very first season though)
- Tenchi Muyo (pretty true to the original, with great graphics and seems to be a fair bit of content)

Actually, for some reason, I had always imagined digital comics as being trivially short - only about 1 hour in length.  But in fact, the majority of them are probably between 6 and 10 hours long.  I'm surprised how much graphics and speech they were able to pack in.

[Console Repair/Mod Center / Re: Need help with repairing a PC Engine GT]

Has anybody here done a recap using tantalum capacitors (instead of the oil-based ones) ?
Theoretically, they should have a better lifetime - and if/when they do fail, they wouldn't leak anything out causing other issues on the board...

[PCE/TG-16|CD/SGX Discussion / Re: Does anybody already have an UperGrafx UGX-02 ? (memory card compatibility)]

Primarily for playing...  But what I'll be playing probably has a 'development' side to it - first, CDROM games that have been translated, likely followed by translations I'm working on.

[PCE/TG-16|CD/SGX Discussion / Re: Does anybody already have an UperGrafx UGX-02 ? (memory card compatibility)]

Update in case anybody is interested...

I received it, and had a few pleasant surprises.

- a simple DVI-to-HDMI cable (I got from Amazon) was all I needed to enjoy on my existing 4K monitor.  It automatically chose a dot-multiplication mode for 1280x720, so it was still pixel-locked (no filter-based scaling).  The DVI output also carries a sound signal (not sure, but I think it's stereo too), so the separate audio out is optional.

- The 'stutter' I had seen on early videos (seemed to be a visible stall, perhaps of 2 frames, about once every 5 seconds or so), due to the difference in VSYNC frequencies between NTSC composite and HDMI (59.85 versus 60.00 Hz), has been significantly improved.  I was only able to notice it when I was actively searching for it.  There is even a 59.85Hz choice on the firmware setup screen (which I haven't tried, but may eliminate it altogether).

- SD cards (at least some types) are supported; not just MMC cards as the website suggests.  I've used a 16GB SDHC so far, and will try a 64GB SDXC next.

- CD's loaded much faster than I expected, and compatibility was good - although not perfect, there are frequent firmware updates to improve usability and compatibility.  Firmware updates seem to come out roughly monthly.


The output looks great, and is more playable than an emulator - no lag, and no shearing.

I haven't tried the following functions yet, but they should exist based on the Japanese website:
- snapshot (screenshot) grab
- USB connectivity to upload/download backup RAM and snapshots
- USB download of HuCard image 'rips'
- USB upload of limited HuCard games - I'm not clear on the details, but it seems that there is 512KB RAM, and 256KB of ROM in which to store images.  256KB is small, but good enough to hold a system card image; the RAM-based area may be usable for development... I'll look in to this.

Unfortunately, the website's English content is only about 30% of the Japanese, so there is still a big gap... which I will try to help translate, as I get further into using this product.

Dave

[Localizations, Games, Apps, Docs / Re: Dead of the Brain I & II]

Happy to report David Shadoff made some progress on the Dead of the Brain I & II English fan translation project!

To clarify, I don't have an English script - this project will be French (at least for now).

Dave

[PCE/TG-16|CD/SGX Discussion / Does anybody already have an UperGrafx UGX-02 ? (memory card compatibility)]

I've been following the progress on these devices, and based on what I recently saw in Akihabara, plus the system firmware updates posted on twitter, I decided to order one.

If you have one, could you help me understand the memory card compatibility ?

The website indicates (in Japanese) that it supports MMC-compatible cards, but I can't seem to find any MMC cards over 4GB (including MMCPlus).  However, the webiste indicates that they've verified with 64GB cards (which is backed up by the large number of disc images on a card, mentioned/pictured in tweets).

So I'm not sure if some variant of SDCard is also supported...or whether they just have secret sources of large cards.

...Just want to make sure that I get the right kind of card(s).

Dave

[PC-FX Discussion / Re: Market research paper about NEC losing Japanese PC market]

I agree with some of your points, but ultimately disagree with several.

Through the first half of the 1980's, Japanese and American "hobbyist" computer culture was relatively analogous... but Japan was basically doing what they often do: take a look around the world, take what's good, put their own twist on it, and let the culture evolve around it.  This is why NEC computers were similar to, but not 100% compatible with, MS-DOS machines.  As I recall, they changed two crucial BIOS calls to create the differences.  Note that the innovations with computers were minor at best.

What happened next was a huge cultural difference:  American adoption occurred in two places: the business, and to a lesser degree, the home.  (The internet came several years later).

Business saw the opportunity of streamlining many tedious processes, in order to make their businesses more profitable.  This was necessary, as Japanese competition was rendering many businesses unprofitable.  Also, corporate changes made it easier to reduce or repurpose staff in the event of streamlined processes.  Japan didn't actively investigate any of this for several reasons: 1) Japan loves paper.  It is only now, 25 years later, that they are actually looking to reduce paper and rubber stamp usage. 2) Japan doesn't tend to like change, and didn't feel that reducing costs was a necessary step until after the bubble burst in the early-to-mid 90's. So no investment. And Japan was afraid that reducing effort was not going to make their overall businesses profitable, as surplus workers would still need to be paid (at that time).

Meanwhile, back in America, the most common uses of computers after Windows arrived were word processing - as a result of which managers lost their secretarial support (but this would not have gone well in Japan, land of paper), email - which may have been treated similarly in both locations, and spreadsheets - not sure about the impact in Japan, but I still feel a delay would have taken place, because internal company policies change slowly.

In the home, many people in America saw that computers would be the future, and bought them "for their children", but didn't really know what to do with them until the internet came. So they became game machines.  But Japanese people never considered that such an investment in themselves was necessary; if it was necessary, the company would certainly train them.  And besides that, homes really didn't have a lot of extra space for such a monstrous machine (back in the 90's, computers were all tower-sized with CRT monitors).

Once the internet came, Americans were keen to communicate with other people (though primarily in English), but Japan had "VANs" which were Japanese-specific, and served similar purposes.  I get the feeling that most people in Japan didn't see the purpose of getting on the internet at first... to communicate with foreigners... in English... it would have been a mere curiosity and limited to small group of people.  Not to mention, ,this was about the time that the economic bubble burst in Japan.  So Japan was about 5 years late to this party.  And since Japan is still (even now) primarily a cash-based economy, e-commerce was not trusted so quickly, and many people still didn't even have credit cards while Amazon was already thriving elsewhere in the world.

In short, the familiarity with computers in America is what caused people to think in terms of "digitize everything", which didn't really occur to Japanese people. Which is why Americans wanted everything to be connectable, but Japanese people didn't really think that way (at first). Oh sure, some did - the programmers - but not the retail market.  And perhaps Japanese electronics firms were forced by management to actively remove such functionality from early designs "for market considerations".  We will probably never know.

And I'm sure that Microsoft's belief that "everybody loves to fiddle with drivers and reboot several times before success" was not met with appreciation in Japan.  The "do it yourself" mentality that was a requirement for early computing... pretty much doesn't exist in Japan.

Dave

[Feature/News Archive / Re: The Retro "PC Engine Offline Catalog" Returns Online!]

I was just thinking about using it as the repository for the games database, on the assumption that it wasn't as small as it turns out to be.  I hadn't even considered the possibility that the data was actually embedded in the page download.  That's actually pretty cool (though some artifacts like images must be stored on a server I expect).

I wasn't thinking about changing your existing translation software system... although if it were to be recreated today, I think SQLite might be a better choice, especially as the M$ tools lose compatibility before translation projects can be completed, and open software tends to have a better track record for backward-compatibility (and/or effort required to update).

The problem I had with export is:
- UTF-16 can include embedded '\0' characters which cause a lot of problems with anything not limited to UTF-16.
- other export methods such as CSV would struggle, as there are embedded carriage returns and commas within the text data, which cause imports to have trouble discerning end-of-column and end-of-row.

...So, it was either this or something else custom, and I felt that paying some money would be better than expending a bunch of effort.

Also, as I started to look at UTF-8, it overcomes the embedded-'\0' issue at the cost of multi-length characters, and this was probably going to solve some string-management issues in the first place.  Also, I realized that it's the same encoding as 16-bit Unicode (at its core)...  So a simple transformation after all.

I'm still playing around, but I feel I can make better progress on reinsertion efforts now (though I won't re-implement an editor in the event that edits are required).  Perhaps SQLiteStudio would be sufficient for those.

As soon as I have some easter egg text to play with, I'll PM you a sample.

[Feature/News Archive / Re: The Retro "PC Engine Offline Catalog" Returns Online!]

Have you looked at SQLite ?  Self-contained database file, accessible from multiple many languages and with the ability for multi-table schema.

I started looking at this recently in order to move the data from Access in order to restart work on a translation project... I purchased a program which does a good job of moving data from Access to SQLite - but since it targets UTF-8, I needed to brush up on the various Unicode encodings.  (SQLite doesn't seem to have any such restrictions; just the migration program).

Meanwhile, I'll take your response as a "yes", and see what I can do to do a few sample Easter egg translations.

[Feature/News Archive / Re: The Retro "PC Engine Offline Catalog" Returns Online!]

Cool stuff !
This is pretty much what I had been aiming for with PCECP (which, sadly, is offline now).

How easy is it to add stuff to this ?

I have a slightly perverse desire to try to translate some of the "easter egg/cheat" information from places like the Hyper Catalog extract that Chris Covell pulled some time ago:

https://www.chrismcovell.com/texts/PCE_Catalogue-Lines.html

Dave

[PCE/TG-16|CD/SGX Discussion / Re: Son Son II - in western magazines]

Hey, "oriental" is a bad word now? That's new to me.

I never know this either. Does this mean many brand names, such as certain hotel names, are offensive now?

I had never heard this either.
I am aware that many people prefer the word "Asian" nowadays, but that term is inclusive of the peoples of the Indian subcontinent as well (so as a descriptive term, the word is far more vague).

[PCE/TG-16|CD/SGX Discussion / Re: Necromancer Resurrected! No, not our esteemed moderator, the game!!]

The irony is not lost on me.

Necromancer = one who communicates with the dead, and may summon them or bring them back from the dead.

...like this game release.

[Buy/Sell/Trade / Re: PCE Super Griffin For sale]

I have one of these which I would be interested in selling in late January (will be too busy until then).

875Euros is a lot of dough - what would be more reasonable (i.e. quick sale) ?

[Buy/Sell/Trade / FS: PC Engine Odd/Rare Hardware]

I'm cleaning up some space in my house, and I have the following for sale (from Canada).
(Please note that shipping can be expensive if destination is outside of North America.)

I'm not looking for foolish ebay pricing, so please PM me with offers.


1) AV Booster (stereo w/composite video).
Tested and working.
Comes in original box, although the box is beat up.


2) Backup Booster II  PI-AD8.  This is a memory unit, not an A/V unit.
In original box.  Never used (original plastic bags unopened), so I did not open it to test.
Box shows minor wear.


3) Cordless multitap set  PI-PD11
New in box (so untested).
Box is in good condition except for one corner where it sustained a bump.


4) Jamiko PC Boy (PC Engine clone machine, modeled after Shuttle)
In original box, in very good condition.
Mostly tested (*).  This machine is made for 50Hz PAL video; I was able to view a flipping screen on my 60Hz NTSC monitor with actual play action, but I do not have a compatible monitor to test output quality.  The screen was flipping because this is built for 50Hz output, and the game also ran visibly slower.  I did not test the included AC adapter, built for 220V 2-prong outlets.


-Dave

[Buy/Sell/Trade / Re: WTB PC Engine LT $1,800 bounty]

Please ban this guy if he says "bounty" again.

I'm sure he just used it because it's "the quicker picker-upper"

[PCE/TG-16|CD/SGX Discussion / Re: 2nd revision of PCE Juuouki Altered Beast [+Found!]]

I'm very interested in comparing the binary differences between the two versions.  I'll bet they are pretty tiny.

I suspect the original issue was either:
a) direct call into the system card to a function which was either undocumented, changed its implementation, or moved to a different location
b) a return value from a function which was assumed to be zero (but would have needed to be forced to zero on a later version)
c) a timing or interrupt-related issue

So, basically, I expect that the issue would be hard to find, but once identified, easily fixed.

[PCE/TG-16|CD/SGX Discussion / Re: Cdrom ode up for preorder]

Doh !
I've been away from the system too long...

[PCE/TG-16|CD/SGX Discussion / Re: Cdrom ode up for preorder]

OK, I see what you mean.

So then it creates a full frame 'buffer' based on the raster scan (although digital values), with its own color table based on bus sniffing (i.e. writes to $080x), and outputs them according to a whole separate timing cycle from the PCE's.  If true, R-Type will still have the flashing sprites when there are 17 on a scanline.

I had never supposed that it "looked into the VDC" however; I believed that it was implementing its own emulated version of the VDC based on more bus snooping (i.e. writes to $0400).  This is also possible, but a bit more work (though maybe not as much as it seems).  Maybe a future device (from him or somebody else) could go one step further and implement the 6280 and 6270, at a clock appropriate for HD.

[PCE/TG-16|CD/SGX Discussion / Re: Cdrom ode up for preorder]

It's important to note a few points about what this is, what it isn't, and why the creator states that he wanted to make such a thing in the first place - because most of this information isn't available in English.

I don't actually have an opinion about this machine because I've never seen one in real life.  This information may change - or reinforce - your current opinion.

Video section:

He said that he wanted to make the PC Engine compatible with newer, digital TVs, because he was worried that CRTs are becoming rarer, and wanted them to continue on.  While this statement may seem to be an exaggeration of today's environment, it will be true in the long term.

Because there is a small but real difference in the scan rate between NTSC and HD (ie. 29.997Hz versus 60Hz), there are some technical compromises which were unavoidable (at least, without changing the clock generator crystal inside the PC Engine).

Because of the frame rate difference, I would assume that there would be a hesitation (apparent frame 'skip') once every several seconds.  I had read about this, and that it was 'reduced', but it's not clear to me how much remains.

The term 'scaler' is an oversimplification.  The image is created in an internal frame buffer and output from there (not a line buffer).  My understanding (although I could be wrong) is that this image is built entirely by bus snooping, including background and sprite, and reconstructing the digital values... not based on scanline output from the PC Engine.  Watching R-Type for sprite flickering would prove this (or disprove).

So in other words, it's hardware emulation.  This has good points and bad points (as we all know).
Good points include:
- may get rid of sprite flicker
- SuperGrafx support can in theory be added (although I don't think that it is)

Bad points:
- may not be 100% accurate
- occasional frame jerk

It would be nice to have this matched with an emulated PC Engine with a tweaked clock rate so that the skipped frames don't occur.


CDROM section:

This is clearly emulation, and he currently has something like 75% compatibility.  This is better than early software emulation efforts (back in the '90's), but not quite where we would all like it to be.

On the other hand, he has modified things he felt were drawbacks.  Because of the way PC Engine software was created, these modifications may reveal latent bugs in the original code which wouldn't show on original hardware, but may show when one small variation is introduced.  Thus, these 'improvements' may reduce overall compatibility.

- Seek time reduced to basically nothing
- data read speed accelerated
- Based on the Youtube videos, I believe that ADPCM playback noise (high-frequency artifacting) has been reduced

And it's the first no-moving-part CDROM hardware replacement available.

On the one hand, I am very impressed at the technical work invested in this product, and how far it has come.  I am of course disappointed that the price is high, but no matter what the price, only a limited number of people would ever buy such a thing, so it's a choice of "high price" versus "not worth anybody's time to invest in its creation".  Given this choice, I would prefer for the device to exist.

...But I'll probably wait for the next iteration before pulling out my wallet.

[PCE/TG-16|CD/SGX Discussion / Off the Wall... released !?!]

I just tripped over this, and thought that people here would be interested.

http://www.smspower.org/forums/16747-OffTheWallForGameGearAndPCEngine

[Localizations, Games, Apps, Docs / Re: Anearth Fantasy Stories - Translation Development Blog]

1) What IDE/language are you using ?  Eclipse ?  Microsoft's IDE ?  JAVA ?  C ?

The custom toolset is comprised of a PCE-VDC-data-to-PNG converter, and PNG-to-PCE-VDC-data converter, and the script-extractor-compiler-inserter. These are all command-line programs so that they can easily be used in batch files.

They're written in C/C++, because I'm so familiar with it, and it's easy to knock up quick programs.

They could be written in C#, Python, or anything else that can memory-map and modify existing binary files.

I'm using Visual Studio 2010 Professional, because the debugger is excellent, and it's the last version before Microsoft screwed-up the IDE.

Although I actually prefer to edit the source code in a separate and more-powerful text editor. That's just personal preference.

But most of my time is either spent at a command-line in TCC/LE, or MSYS2 if I need some Unix tool like hexdump/grep/diff.

I tend to prefer using batch files for building and testing things (unless I'm debugging the extraction/insertion tools).

I'm using grafx2 to make all of the graphics changes, because it's quick and simple, and I don't need all of the extra features that something like ProMotion brings to the table.

This is really similar to what I use, actually - although I'm a bit more UNIXy (Eclipse IDE for C/C++, bash or ksh instead of BAT, gvim for editing, etc.).  I also write in C, because it's easy to write things quickly.

Would you be interested in sharing your PCE-VDC-data-to PNG converters ?

I wrote something similar to create ASCII art files for a Bazaru de Gozaru project - where almost all of the text is stored in graphics - but I'd like to pass along all of my work for somebody else to continue on, and nobody wants to touch ASCII art.  Sounds like your way would be easier for normal humans than my way.

(I'd be happy to convert all my extraction/insertion scripts to aid whoever wants to take it on - it would be mostly adjusting graphics...)

3) For the SJIS, are you displaying in a different codepage ?  Or are you converting to Unicode and back ?

Well, Windows is just in the standard US-English mode.

The scripts are extracted as SJIS, and not Unicode, because it's easier to compile them in SJIS format in order to verify that they produce identical data to the original script chunks.

That's the only way that I can be sure that I understand the complete structure of the script language, and will be able to change the scripts without breaking the game.

It's easy to edit the script files in any text editor that supports SJIS ... like Notepad++

Thanks for that... I've generally seen the following format, in non-compressed data:
[array of pointers to blocks]

block1:
[array of pointers to text strings]

text string1:
A bunch of text, with a few interesting control codes to pause, wait for keypress, change color, switch character set, and so on - but intermingled with the text itself...followed by a terminator, which is usually a 0x00 or sometimes 0xFF.

Occasionally, you'll find that "block1" is not an array of pointers, but rather the start of the first string, and the strings are read sequentially.

Finding a way to express the meaning of those interspersed codes - while still making it intelligible to the translator/editor, and keeping it parseable for reinsertion - was always challenging.

It's the last aspect that probably killed EsperKnight's ability to make any real headway with the script extraction, because until you understand that, you're just looking at fragments of Japanese text that make little sense.

I got the same feeling, looking at his work on Tengai Makyo - Ziria.  He was able to find text quickly, but had more difficulty trying to figure out a larger organizational structure of those blocks.[/quote]

[Localizations, Games, Apps, Docs / Re: Anearth Fantasy Stories - Translation Development Blog]

This is fantastic news !

As we are talking about the technical side of these patches, I was wondering whether you could describe your development setup (and workflow if possible).

1) What IDE/language are you using ?  Eclipse ?  Microsoft's IDE ?  JAVA ?  C ?
2) What emulator are you using ?  Is it one where you execute the TOC, or do you use a CD emulator like Daemon Tools ?
3) For the SJIS, are you displaying in a different codepage ?  Or are you converting to Unicode and back ?

I'm pretty sure that I'm not the only one who's interested.

Dave

[Localizations, Games, Apps, Docs / Re: Xanadu II Translation Development Blog]

BTW ... it was interesting to see that person on the NeoGaf forum wax lyrical on some of the PCE RPGs, including Emerald Dragon, and "Angel's Poem".

I had absolutely no idea that that was the English translation of "Tenshi No Uta"!

Actually, I've always thought of it as "(The) Song(s) of (the) Angel(s)" - "Uta" could mean poem or song, depending on context.  I don't know which is more correct in this particular case (because I haven't played enough of the game), but I personally would associate angles with music rather than poetry...

[Localizations, Games, Apps, Docs / Re: Xanadu II Translation Development Blog]

It's that it looks like you've got a bug in there. 

From what I'm seeing in your code, it looks like the only difference between the YsIV compression and Emerald Dragon compression, is that minimum offset/distance for a match has changed from "-1" to "-18".

The thing is ... as far as I can see ... you haven't actually stopped check_match() from returning matches that are closer than -18 away.

If so, when you're inserting more of the scripts, that's going to blow-up on you at some point, .

As I recall, this was just the difference in how the algorithm worked - same algorithm as Ys IV, but with a different offset.  0x12 also sounds familiar.  It's a circular buffer, so doing an "overflow" into the back end of the buffer should also be valid, in the extremely remote chance that a match is actually found.

But the best proof of not blowing up is to encode and decode and verify that the strings match 100%.  As I recall, we also did that.

...I just hope that my memory isn't playing tricks on me as I grow older.  And you might indeed have found a bug, but it likely wouldn't yield a measurably different compression rate (just the chance of garble as you mention)

Anyway, if we didn't encode/decode/validate back then, it's easy enough to do now.

Just sayin' ... this 30th Anniversary Year would be a great time to release the translation.    

Yes it would.
NightWolve, have you decided to start taking another look at digging into this ?

-Dave

[PCE/TG-16|CD/SGX Discussion / Re: PC Engine Creator Memories]

The other possibility is that there were a few games being developed around that time, which planned to use the entire BRAM because they wanted to save that much memory.

In a case like that, there is no particular reason for the programmers to use convention by saving the save game as a normal savegame - it could just be a binary blob.  Then your "file at a time" tool would break.  But dealing with the whole bank at once... works.


...And if I were designing it, I would probably have done the "file at a time" deal, until I got to testing it, and then realized that multiple savegames for the same game, need some work... probably as a whole interactive session on how to tell them apart.  And I'd probably panic a bit.  I may even revert to the "bank at once" under those circumstances.

[PCE/TG-16|CD/SGX Discussion / Re: PC Engine Creator Memories]

I think you guys may be forgetting an important use case:

Copying an individual Bomberman backup file into a larger pot (total: 8KB) is, as everybody has mentioned, not rocket science.  However, keep in mind that the total storage was still only 8KB.

The alternate method only helps if:
1) you have a lot of games (true only for a limited number of gamers at the time), or when used with certain BRAM-consuming games which started to come out at that time.
2) You don't need to keep multiple copies of the same game.  If you want do that, then you need to have some way of keeping those separate, which needs more space, and some differentiator (note: no clock in the PC Engine, so date/time won't cut it).

Now, why would anybody need mulitple savegames for the same game ?  Perhaps they are in the same family, and can only deal with one console.  And little brother overwriting big brother's perfect score would be traumatic.

That's probably the real reason for the banks.  Each kid gets their own slot.

[PCE/TG-16|CD/SGX Discussion / Re: Hideo Kojima and Oji Hiroi interview]

I'm curious what Japanese word they used for hoodlum ("GTA is a simulation of being a hoodlum.")

Yankii ?  Furyou ?  Yakuza ?  Chinpira ?