News: 11 March 2016 - Forum Rules

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dshadoff

Pages: [1] 2
Newcomer's Board / Re: 5v CPLD 'Is it possible?' fun :)
« on: January 23, 2022, 04:17:03 pm »
Yes, this should be fast enough to do address decodes, but the question is - do you have enough I/Os, and is there enough logic space to accomplish what you want ?

For greater speed, greater capacity, and greater number of IOs, you would likely need to switch to a different family of chip, which would almost certainly be 3.3V, and need level-conversion.  It's not the end of the world, just an inconvenience to add more chips.

You might want to try a printed circuit board design for anything more complex than that - they are very reasonably-priced when you order from China (but there's a short learning curve to get going on PCB design).

ROM Hacking Discussion / Re: 25th Anniversary - calling all oldtimers
« on: January 23, 2022, 11:49:59 am »
This timeline seems to be NES-centric, and the thread is probably targeted at NES enthusiasts (sometimes conversation on this board seems to ignore the existence of non-Nintendo consoles).

I was reverse-engineering the PC Engine in the 90s, and I would generally say that 1996 was the breakout year on that console for gathering sufficient data to make an emulator.  After we got decent emulation, efforts didn't generally get aimed at ROM hacks though - rather, they went toward development tools (slowly, I'll admit).

So I'm not sure if I belong to the group you are addressing, but I guess I do fit the category of 'old timer'.

Newcomer's Board / Re: PCE Translation
« on: January 13, 2022, 09:13:27 pm »
PC Engine CD data tracks are MODE1/2048 bytes, and the console uses them basically in the same way as a ROM which can be loaded in chunks.

No file system.

If you are using downloaded images, chances are you will find the data tracks ripped as MODE1/2352, which means the ECC data would be part of the extract; this needs to be separated.  If you try to make a direct adjustment to the actual program portion, the ECC will become invalid (unless it is recomputed).

So, step 1 is to get the data track into 2048 byte per sector format first.

Most games have 2 data tracks - one as track 2 (primary), and one at the end of the disc (duplicate).  If you are looking at a game which has several data tracks, I would recommend avoiding that as an initial project.

I thought the next one was released on PC-FX...

Newcomer's Board / Re: Translator services?
« on: December 14, 2021, 09:33:04 pm »
Best approach would be to find somebody who has a script and a means to reinsert already.  Best shot is somebody trying to do it all themselves, but finding the translation work too much.

You really should consider how big a script you want to work on for a first project though, and what things might be off-limits for you.

Gaming Discussion / Re: Paprium
« on: November 05, 2021, 05:09:12 pm »
Strange, from what i saw in the comments ppl dont seem to be complaining. Luckly the game was funded.  :)

Yeah, seems like different people (and a different funding site).  There are people who never got their game from the last funding (I know one, but I am not one).  I think people in general want to support new development, but from what I've read this is not something you fund, and then receive as per the original schedule.  So, people tend not to want to support a second time... but apparently there are always new people.

Gaming Discussion / Re: Paprium
« on: October 25, 2021, 03:37:30 pm »
There seems to be a lot of controversy on this game.  I can't speak from experience as I didn't order the last crowdfunding... but a lot of people tell me that they weren't happy with the overall handling of the project (and some apparently don't have theirs yet).

I am, though I've spoken with 4lorn on the topic.
The text is in sprites, which are compressed data.
There isn't enough space - either on screen, or in video memory - for a translation like yours.

Also, there are a couple of differences between that and my understanding (for example, "Aneki" seems to refer to the kidnapped Doctor character from the intro)...

In any case, although it's a small amount of text, it will be quite a bit of effort to make it fit and do the technical side/insertion.

Have you tried burning it back to physical media and running from a real machine ?

This de-syncing is a problem with almost all emulators and CD cores - they rarely attempt to recreate the original device's head-seek time and throughput limitations.  Sometimes this re-implementation appears to be an improvement (removing spots where original hardware struggled to keep up), and sometimes it causes failures and de-synchronizations.

filler, please make the request over here as well:

It can't hurt to ask in two places.

I wrote a few fairly large posts on another board, about the overall process of making a translation patch for PC Engine games.

You can find them here:
Post 1:
Post 2:
Post 3:
Post 4:

These are going to answer some of your questions, but are really only a starting point.  They are all posted in the "Homebrew Development" forum on the (currently) most active PC Engine-focused message board, which is focused on subjects like this one.  I'm sure there are many other posts there which you might find helpful too.

Any questions you have after that point are welcome there, and will likely find good answers.


ROM Hacking Discussion / Re: PC Engine Ripping voice clips and PSG music
« on: September 25, 2019, 10:28:07 pm »
Regarding decoding, is there a way to listen to the datatrack in its .iso form?

I'm not sure what you mean here...
When you say "in .iso form", are you talking about a track-by-track, or a full-disc image ?
In order to do anything, you would need to start with track files - most will be simple audio (CD audio tracks), but some will be data tracks (2048-byte MODE 1).  a full disc image will add all sorts of ECC error checks data which just confuse things.

Once you have a CUE/track extract, another more accurate way to find the locations of the ADPCM data, is to use the Mednafen debugger, and keep track of data loaded into ADPCM memory (and played); you would also need to keep track of which sectors are loaded from disc into memory too.

Many people might find this boring, tedious, or too much work - but it's the best way to have a full working knowledge of the system, and get accurate lists of memory locations where messages reside in the data track.

ROM Hacking Discussion / Re: PC Engine Ripping voice clips and PSG music
« on: September 24, 2019, 07:00:49 pm »
I wrote some ADPCM extraction/re-insertion utilities many years ago, and they have been used in a few places (Ys IV, Dracula X, etc.).

You can find them available for download here:
(If source code isn't included and you need it, let me know)

Note: each message is embedded in a data track, which will also have code, graphics, etc.; the utilities work based on the offset inside the track.  If you don't know the offset, you may be at a disadvantage.

There is a way to roughly locate the messages, and that is to decode the entire data track, and listen through the noise until something intelligible comes out.  When it does, you will know (a) the existence of the message, and (b) based on the time signature, the rough location within the data track.  This should easily work back to an offset, since ADPCM compresses the amplitudes, not the samples themselves - time offset within the track remains a fixed ratio to location offset within the track.


This is actually quite a big subject, so I'll go through at a high level at first.

First, as you pointed out, it's a nice system with a ton of great JAPANESE games. But unfortunately, its marketing in North America (including the library chosen for publication here) was overall disappointing, so that even today, it's considered a niche system.

Next, you will see (not just on this site) that in North America, NES and SNES - due to their popularity - drive the largest amount of discussion, which in turn leads to the largest developer community.  And game players. And people interested in doing translations.

You can see the disparity by searching the number of translation for these systems - Nintendo dwarfs TG-16 (or PC Engine, as I will call it from here on).

In order to have get a translation done, usually there is a technical person and a translator. And both of them need to have a lot of perseverance.  There are several strong technical people in the PC Engine community, but we suffer from a dearth of translators.  As you mentioned in your post, the Startling Odyssey II translation was completed without a translator.  (As an aside, this fact generated a storm of nasty comments on this board about whether it could even be considered a translation - which is why you won't find it here).

Now, as for the differences between HuCard and CDROM, the first and most important to consider is SIZE. A CDROM game generally has a much larger script to translate, which leads to commitment issues on the sides of both the translator and the technical person.

Of course, there are technical differences as well, but basically if you don't start a project, you won't need to worry about those.  I'll give you a high-level on those next.

First, the PC Engine CDROMs are not stored in an ISO-9660 format as some modern games are.  Their disc format predates even High Sierra, so NEC chose to just stick a large blob of data there.  Consider it a giant ROM, which is loaded in sections, so you still need to observe the same practises you would on a ROM - except you can't arbitrarily extend the ROM and be able to map the new area.  This is because a new ROM area can be mapped instantly (nanoseconds), but an extension of the data track on a PC Engine disc needs to consider seek time, which will basically be hundreds of milliseconds.

On the bright side, many CDROM games were written thinking, "I have so much space, I don't need compression", so the text can often be found easily (it is often stored in SJIS, because the CDROM system card contained fonts for this).  The double-byte encoding works to your advantage, as long as you switch to ASCII and alter the print routine to match.

I have written a little 'starter series' on PC Engine translation here:

...and as a follow-up, I even made the print function modification easier with this hack:

Hopefully, this helps explain a lot of the things you asked about.  Let me know if there are more questions on the subject.


Total Commander (Windows) and some of its many homages (for example, Krusader on Linux) have a "compare by content" selection under the "Files" menu item.  This package is a split-window file explorer made for fast navigation/copying/other file operations between one place and another.

The "Compare by content" item will do a line-by-line text diff for text-type files, or show binary differences for anything else.

You would select a file from each of the windows to effect the comparison.
It's particularly effective if you are comparing two directories (using "Synchronize Dirs"), and find that one of the files is 'different'; you can find out what changed.


Newcomer's Board / Re: How to go about tile editing for the PC-Engine?
« on: January 07, 2019, 01:46:56 am »
A watchpoint (also known in Mednafen as a watch address) is a breakpoint you can set, where the debugger halts execution when a specific part of memory (or I/O) is accessed, instead of just an execution address.  You can set Mednafen to stop as the VRAM is getting loaded from the cartridge.

Which brings us to the second point - if you just look at VRAM, you may not be able to get the desired result.  The VRAM is loaded from the cartridge (on some games, this happens multiple times because VRAM is often in short supply).  If you want Doraemon's head to appear differnetly, you need to alter the source data on the cartridge, not just the VRAM data.

But having found it in VRAM is a big step; from this, you can find the cartridge data by doing one of the following:
1) Set a watchpoint on the VRAM write to that location, examine the loop where it's being loaded, and determine the source location of the data.
- or -
2) Now that you have a dump of the data, see if you can search the source ROM for the same byte sequence.

I'm not sure about tools to do the editing though.


A deficit of translators for games on this system is (at least for the past 10 years) the primary bottleneck.

Emerald Dragon's translation is incomplete.
Seiya Monogatari has been extracted but not translated.
Dead of the Brain will receive a French translation first, because there is no English translator for it.
..And there are various other projects with partial (and even complete) extracts but no translators.

So, if anybody here is a translator with a track record on large projects, and would like to work on a PC Engine translation, please let us know.


Newcomer's Board / Re: How to go about tile editing for the PC-Engine?
« on: January 04, 2019, 07:53:11 pm »

That was my plugin (but I didn't write TMOD2).
What game(s) are you looking at ?

Sometimes the tiles aren't so easy to see because the ROM-storage format isn't precisely the same as the VRAM format (I wouldn't call this compression exactly).  For example, if the sprite only uses 4 colors (i.e. 2 bits), but the video processor is set for 4 bits; the video load process would 'unpack' it.

(Note: Fighting Run is (AFAIK) the only game that uses native 2-bit sprite mode.)

You might want to search video memory for the sprite, once it has already loaded, then restart the game, but this time with a watchpoint on the VRAM write.


Personal Projects / Re: Tengai Makyou Zero translation project
« on: October 16, 2017, 12:31:56 am »
But before I concentrate on that, I need to concentrate on getting Zero out and Ziria translated.

Have you already received a fully-extracted script for Ziria ?

The "recipe" thing was an analogy.

Please feel free to interchange it with "fan anime mashup video", or "home remix version of a hit single", or "fan fiction", etc.
Essentially any derivative work created without permission of the original author.  Such works are generally created for the own personal enjoyment of the secondary author -- although others might enjoy them, and the original authors or copyright holders may perceive infringement.

My point was that although a thing may be "commercially valueless", it does not follow that the work has been "worthless", and further does not follow that it is therefore public domain, or that it must be mandatorily volunteered as community property.

I just wanted to keep this idea separate from the idea of whether infringement is taking place, or what perceived value that infringement might denote.  I noticed that some posters seemed to be implying that "infringement" should beget "mandatory publication", which is clearly not true.

Pages: [1] 2