Topics

[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 / 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.

[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

[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 / 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

[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

[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

[Buy/Sell/Trade / PCE Magazines (duplicates) - free for pickup in the Toronto area]

I have a fairly large number of excess PCE magazines - roughly 2 "Banker's Boxes" (16"x13"x10") full.  This includes an assortment of Gekkan PC Engine, Dengeki PC Engine, PC Engine Fan, and Marukatsu PC Engine.

These are duplicates that I acquired through buying lots/batches of magazines, in order to get a few that I didn't already have.

These are quite heavy, so I won't be shipping them - but if anybody in the Toronto area wants them, they are free for pickup.  I might even drop them off if you're near somewhere I frequently travel.

Rough estimates are about 60 lbs. each box, and roughly 1 lb. per magazine, so over 100 assorted issues in total.

PM me if you're interested.

-Dave

[Buy/Sell/Trade / PCE/Turbo VHS tapes - free if you pay postage]

I'm trying to clean up a bit.

I'm not going to watch these again, so I thought I'd give them to somebody who wants them more than I do.

7 VHS tapes, including:
- Lords of Thunder (US)
- Den Den no (Kabuki) Den (JP)
- Valis 3 (JP)
- PC Engine Perfect Video (JP)
- Tengai Makyo Ziria Anime (2 tapes - JP)

(no subtitles)

Shipping from the Toronto area will vary by location and service level... rough estimates are:

At roughly 2.5kg, the cheapest shipping would be about $20US to the NorthEast part of the USA; about double that to Europe.  Better service (such as tracking) would increase the price.

First positive response can have it.  Please respond first to the thread with approximate location (so that others will know when it's gone).  I will PM with shipping options; paypal for payment.  I should be able to ship on Tuesday or Wednesday.

-Dave

[PCE/TG-16|CD/SGX Discussion / Daigirin]

Back in the late '90's in Japan, there used to be a quarterly book published, called "Daigirin", which listed all of the games in catalog format, and included some additional hint/trick information for most of the games.

When I say it "listed all of the games", I mean "for (basically) all of the systems available" at that time.  In 1997, the book was basically a telephone book (remember those?) format, listing over 11,000 games across 13 systems.

Soon afterward, I didn't see these books anymore - I think the last one in this series was sometime in 1999.


So the other day, I was doing a search on Yahoo auctions to find the latest version that I could, and found that they released one in autumn 2011 as a sort of "anniversary" or "revival" of sorts.  This monster covers over 23,600 games across 26 different consoles - over double the previous one, published 12 years earlier (as advertised on the cover).

Better yet, it added coverage for a few more games than the 1997 issue, in other words after "end of life" for the PC Engine system:  from 656 games covered in 1997, up to 668.  And from 1799 hints & tricks in 1997, up to 1863.

...And it comes with a CDROM.

Sadly, nothing is perfect:
- the selling price on the book is over 8000yen on average (compared with 1000 yen for 1997/98 versions)
- The CDROM application does not have a separately-accessible database (it is all compiled into a 80MB monolithic executable file), and doesn't support cut-and-paste of the return data.  That must have been done deliberately, because I think it takes effort to prevent that.   


...While I'm not going to do a game-for-game comparison of the lists of games, I'll mention here if there are any interesting/notable games (or cheats!) in the new version.

Also, it would be interesting to see if the data could be extracted from inside the process' execution space, since it's good information.

[Buy/Sell/Trade / Japanese PCE Magazines for sale OR TRADE - UPDATED]

I've been collecting PC Engine magazines for quite a long time now (including Marukatsu PC Engine, Gekkan PC Engine, PC Engine Fan, and Dengeki PC Engine), and I have a lot of extra issues that I'm looking to sell (somewhere between 100 and 130 of these extra issues).  Just to put it into perspective, these magazines published 280 issues collectively (though some of my duplicates are actually triplicates).

Some are in pretty rough condition, but lots are pristine.
Pretty much all of them have been separated from their pack-in inserts, but if I can figure out what belongs with what (and if I have an extra one of the inserts to spare), I'd match 'em up and throw it in.


I'll be much happier if you could send me any of the following (no missing pages - fair condition or better would be appreciated):

I am completely missing these:
Marukatsu PC Engine 1989-01, 1990-07
PC Engine Fan 1989-01, 1989-07, 1990-02

I need a replacement copy of these, because my copy is missing one or more pages:
Marukatsu PC Engine 1989-05, 1990-05, 1990-10
PC Engine Fan 1991-12
Gekkan PC Engine 1990-01

...But if you don't have any of the above available for trade, money is always good.

Unfortunately, since I'm in Canada (Toronto area more specifically), shipping of individual copies could be pretty expensive... especially to people outside North America.  Shipping will be the responsibility of the recipient (for a sale; I'll cover both sides shipping for a trade), but I will help to find the best available means.


Note that the poor condition magazines are only being offered because of their severe age and rarity; otherwise I would probably throw them out.
I just thought that somebody might be interested in them, even in poor shape.
I will accept any offers on those; I'll even consider throwing them in for free if somebody buys others.

I am flexible on prices, especially if somebody is gong to pick up several magazines.  If I receive conflicting offers, I may favor the larger of the two offers if it saves me packing trouble, but otherwise the first offer will prevail.

Please note that I am not a professional used-magazine grader.  All of these magazines are used, and also old; do not expect anything to be in "mint" or "unused" condition.  In my descriptions, I am mostly looking for visible defects which could interfere with the enjoyment of the magazines.  This is (for better or worse) more information than you're likely to find anywhere else.  The information I provide here is done on a "best efforts" basis; I do not warrant the magazines in any way.


I have the following available:

Batch 1 - Marukatsu PC Engine:

1989 (a very rare year)
$40 - June - good condition with Susano wo Densetsu pack-in (OK condition - some creases on edge with fold)
*** - June - poor condition, but no missing pages (cover torn and falling off)
*** - July - torn cover but no missing pages, plus Tengai Makyo Ziria (part 1) pack-in (which is in good condition)
*** - August - poor condition (missing cover and 2 additional front/rear pages), plus Tengai Makyo Ziria (part 2) pack-in (good condition)
$35 - September - minor scuffs and cover creases
$35 - November - no obvious complaints

1990
*** - February - missing cover, corner tears, plus Ys 1-2 (part 4) pack-in (OK condition - minor creasing on edge with fold)
$25 - August - OK condition - some minor folding on a couple of the innermost pages
$30 - September - good condition, plus Image Fight pack-in (good condition), and Valkyrie no Densetsu (vol 1) pack-in (OK condition)

1991
$20 - January - good condition
$20 - March - good condition (minor fold on front cover)
$20 - April - good condition
*** - September - missing cover, but remainder of magazine is in OK condition
$20 - November - OK condition - some minor scuffs on back cover
$15 - December - missing center (removable) section, pages 83-98, but otherwise OK condition


1992
$15 - January - missing center (removable) section, pages 89-104, but otherwise OK condition
$20 - March - minor wear around the staples
$20 - May - minor wear around the staples
$25 - June - good condition
$30 - July - minor scuff on front cover, plus F1 Circus Special pack-in (good condition)
$30 - August - minor split at bottom of binding edge, plus Lodoss no Tousenki Fan Book pack-in
*** - October - split cover, but otherwise OK
$20 - November - wear around the staples
$20 - December - good condition

1993
*** - January - missing cover
$20 - January - cover has been repaired along the spine, with tape; otherwise OK condition.  Plus Eiyuu Densetsu II pack-in
$20 - February - crease in corner, but good
$20 - February - very minor crease on front cover; good
$25 - March - good, plus "Urawaza Hatsu Densho" (easter egg collection) pack-in
$15 - March - partially split cover
$25 - April - good, plus Fuun Kabuki Den pack-in (OK), plus Sotsugyou Graduation packin (good)
$20 - April - good
$15 - July - cover has been repaired along the spine, with tape; otherwise OK condition.
*** - September - missing cover, plus Langrisser pack-in
*** - October - missing cover
*** - November - cover separated from magazine, and split
$10 - December - staple wear, and some tearing on cover

1994
*** - January - staple wear, plus some inner pages loose
$25 - February - good, plus Emerald Dragon pack-in
$20 - February - good
$20 - March - good

[Localizations, Games, Apps, Docs / HuVideo]

I finally got a chance to look into some really cool information that tomaitheous had put together previously on the subject of HuVideo.
http://pastebin.com/raw.php?i=EejMA7jF

I was thinking that since the data is uncompressed, it'd be possible to hardsub the cinemas.
I got as far as identifying all of the HuVideos; the next steps were going to be:
- extract the ADPCM for each video for somebody to translate into English
- identify whether any palette sets are relatively consistent across entire videos, in order to imprint the hardsubs into the frame, using existing palette entries

So I thought I'd share the initial information below, since I found it.
Note that Gulliver Boy has over 30 minutes of HuVideo in it (!)


Gulliver Boy:

filesize = 436518912
Found video at  A801000, 2319 frames (231 seconds)
Found video at  C330000, 394 frames (39 seconds)
Found video at  C7D0000, 466 frames (46 seconds)
Found video at  CD48000, 95 frames (9 seconds)
Found video at  CE67000, 276 frames (27 seconds)
Found video at  D1A5000, 152 frames (15 seconds)
Found video at  D36F000, 495 frames (49 seconds)
Found video at  D93E000, 201 frames (20 seconds)
Found video at  DB9B000, 1019 frames (101 seconds)
Found video at  E78E000, 1412 frames (141 seconds)
Found video at  F81C000, 509 frames (50 seconds)
Found video at  FE15000, 162 frames (16 seconds)
Found video at  FFFD000, 558 frames (55 seconds)
Found video at 10689000, 192 frames (19 seconds)
Found video at 108CB000, 128 frames (12 seconds)
Found video at 10A4D000, 155 frames (15 seconds)
Found video at 10C20000, 180 frames (18 seconds)
Found video at 10E3E000, 514 frames (51 seconds)
Found video at 11446000, 143 frames (14 seconds)
Found video at 115F5000, 364 frames (36 seconds)
Found video at 11A3B000, 233 frames (23 seconds)
Found video at 11CF8000, 237 frames (23 seconds)
Found video at 11FC1000, 214 frames (21 seconds)
Found video at 12245000, 868 frames (86 seconds)
Found video at 12C73000, 265 frames (26 seconds)
Found video at 12F90000, 617 frames (61 seconds)
Found video at 136CD000, 136 frames (13 seconds)
Found video at 13867000, 277 frames (27 seconds)
Found video at 13BA8000, 236 frames (23 seconds)
Found video at 13E6E000, 702 frames (70 seconds)
Found video at 146AA000, 349 frames (34 seconds)
Found video at 14AC3000, 467 frames (46 seconds)
Found video at 1503E000, 1439 frames (143 seconds)
Found video at 1611D000, 943 frames (94 seconds)
Found video at 16C2C000, 992 frames (99 seconds)
Found video at 177CE000, 216 frames (21 seconds)
Found video at 17A58000, 240 frames (24 seconds)
Found video at 17D9D000, 240 frames (24 seconds)
ending...  Total HuVideo = 18405 frames (1840 seconds), in 38 videos


Yuna HuVideo:

filesize = 404658176
Found video at  B83F000, 710 frames (71 seconds)
Found video at 17933800, 710 frames (71 seconds)
ending...  Total HuVideo = 1420 frames (142 seconds), in 2 videos



Yuna 2 - Eien no Princess:

filesize = 202635264
Found video at  B83F000, 710 frames (71 seconds)
ending...  Total HuVideo = 710 frames (71 seconds), in 1 videos