Great emu (The DOS version works great in WinXP with Win95 compatibility). I was wondering if hugo has a debug mode where it can a) log what commands it's executing b) show font table c) notify when text is used/loaded d) provide byte locations for all previous actions(when working with a 2048 extracted ISO file)?????? I know, i'm probably asking for too much... but i'm trying to work on translating Legend of Xanadu, unfortuately, i can't find any decompiler for PCE CDROM data tracks, nor can i locate where any TEXT begins within the data track... I'm told i can replace JAP text with same length ENG text, but would have to decompile for increasing ENG length text....
Any info on rom hacking with/without hugo would much be appreciated (ie. hack tools). I'm trying to take shortcuts by not having to learn PCE programming, but it's not looking good, hehe....
That might be a difficult one to start with, since the text may (or may not) be stored compressed on the CDROM.
Most uncompressed text on PC Engine platform is stored as SJIS, which is like an extended version of ASCII.
First you should extract the data track as a MODE1/2048 byte-per-sector file onto your harddisk. There may be many data tracks, but most have one or two. In the case of two data tracks, they are usually the same (one is there in case the other fails), especially if they are track #2 and the last track.
Then use a SJIS-compatible viewer to search for Japanese text. Or you can get a utility like NJWIN (http://www.njstar.com) to display SJIS from 'normal' Windows applications.
Be aware: many CDROM games can have very large data files, and they can be pretty tedious to walk through. You might be better off starting with a game with less text for your first attempt.
I've since been able to extract > 240 or so characters after i found a text location in the beginning of the game. The Hiragana/Katakana single byte codes have all been dumped & matched up to windows unicode/s-jis (i'm using windows' japanese ime support).
I pretty much knew from emails with David Michel that most PCE CDs use uncompressed text, & looks like Legend of Xanadu is no exception.. Although, it's good to know that last data track is useless, cause even he couldn't figure out its purpose & it seemed it was never used.
What really ruins my plans are that most hiragana&katakana were using 1 byte characters..... I was hoping they were 2 byte s-jis so that i could replace each one with 2 english characters, thus allow more precious space for more eng text.... Now, it's the reverse, the English alphabet is in s-jis, so i'd have to use 2bytes to replace every 1byte of hiragana&katakana.......
Anyhow, script dumping & CG translation will be underway faster that i thought, but i'm wondering if the text space problem will be an impediment that will result in abandoning the project... hehe... I will have to try & move the sprite data of the the english alphabet in place of the hiragana&katakana, but i have a feeling the font table is compressed(i can't find it using any sprite viewer)...
I guess the only hope is for a PCE data track decompiler that could separate code, data, graphics, etc.... Obviously the counterpart to reassemble everyback...
Notes:
The first couple of sectors (say, 6 KB) are boot code, and contain text about the authors of the CDROM system card. Don't confuse the text here with actual game text.
The Kanji font is actually contained in the system card. They have 2 fonts: 12x12 and 16x16 for this, and special ROM calls to print kanji (sub-functions of GRP_BIOS call).
I don't know whether there would be a problem with using normal ASCII characters - the 1-byte versions (instead of the special SJIS 'wide' versions of roman alphabet which are 2-bytes).
hi,
well, about all those features (which were once thought when attempting to translate a cd game, indeed)
a) logging all commands ? you mean in asm ? It can be easily done but extremely slow (I mean _extremely_ :)
As for CD command (such as reading or playing music), it if doable if you really want to ..
b) About font, well, there isn't a really font table. Rather patterns, for both sprites and tiles (which are the most common way of displaying text) but the whole kanji font tables don't fit in vram at a moment, and there's surely a dynamic placement of them. If you want them, the best place is certainly the .iso itself, without executing it. I don't remember well but we may have identified the banks were it was located (in the cd system card)
c) Notify when text is used ... hmm what I could do is :
you put marks in the .hcd, explaining what sectors interest you. (it's similar to the patching system in .hcd) and when this sector is loaded in the emu, you're warned in some way ...
d) backtracing of data is quite hard. first, it wasn't thought like this when coding all of this, and then you can have auto generated code or moves inside the ram, messing tracks.. I don't think this is doable ...
for the rest, I also think you can use ascii where you've found jap text, but don't mix it up with the credits/copyright right at the beginning (in the first 2kB of the cooked iso) btw, if my memory serves, you don't have to alter the font as the 127 lower ascii chracters are part of sjis encoding and have a pattern in the game...
Keep up the good work... i'll see how it goes, i'm trying to find a good 16x16 Tile/Sprite Viewer to find those damn fonts... Unfortunately, everything in the range from 00h - 7Eh + 99h - FFh produces hiragana/katakata, control codes etc. The english alphabet is only found with 16-bit S-JIS encoding(8260=A...8279=Z, etc), so if i could move the bytes of those tiles(english alpha tiles) to the locations where the 1 byte hiragana/katakana are found, then i can use Ascii(one byte for english characters).... I didn't expect this complication going into the project, but oh well....
After that, i gotta figure out a few more of what the various 1 byte control codes do... Right now, i can pause text display, force a messagebox window to close, change text to 8 different colors, new line, cursor restart, etc. A few of them cause crashing in hugo when placed in strings, just cause i haven't
figured out the purpose/correct usage.
I haven't learned pointer stuff, so that might be a problem later on... If anything, it's a learning experience...
