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 3
Re: "Is Japanese hard to learn?" depends on your definitions of "Japanese", "hard", and "learn"...

If by "Japanese", you mean:
- If you want to be able to have light conversation, answer waiters at restaurants, and find bathrooms... it won't take years of a huge amount of effort.
- Reading and writing, with a full set of jouyou kanji, and a N1 vocabulary, this will probably take years.
- However, if you are also talking about the historical pre-genbun-icchi texts which are handwritten and represent the kanbun style of writing... good luck.  That's hard for Japanese people.

If by "hard" you mean:
a) More than a one-year entry-level course is needed to speak with your doctor or read legal texts, then it is hard
b) learning just from a textbook can't get you to communicate, then it still probably is
c) having casual conversations with friends can't be learned even while living in Japan... well then it isn't that hard

If by "learn" you mean:
a) being able to break down a sentence into its constituent parts, then it's not so hard
b) being able to construct complex sentences without a thought after a one-year course, then it is fairly hard
c) understanding the historical and geographic influences which brought modern Japanese to its current point, including regional accents and slang terms across generations, then it's pretty hard, because that's a big subject.

Learning any language goes through various stages where fluency and depth of knowledge are separate goals, each of which is difficult to achieve, but achieving both together is very hard.

Japanese makes it more difficult (for an English speaker) because there is less vocabulary overlap (must be re-learned), a reverse-sequence grammar, and cultural references which must be learned from basically nil.  Starting from Chinese, there is a.. say.. 30-50% head start though, because of shared kanji/vocabulary, and some shared literary/historical references.

But basically, if you plan to learn a language from zero, it all depends on how far you plan to go, but plan on counting in years before you aren't consciously thinking about how to construct your sentence.  (I know a few native English speakers who aren't as good at English as they would like to be in Japanese...)
Of course, motivation/desire, and time/effort applied to the task will help reduce this, but actual interactive contact with speakers of the language will be necessary.

Gaming Discussion / Re: News with NES2PCE?
« on: May 08, 2022, 04:19:28 pm »
I can only imagine the author was significantly demotivated to continue making them when, probably not surprisingly, his hacks were used to make bootleg physical copies (especially after being converted to CD).

That's exactly the case. That, and I believe there were also people trying to make minor changes and take credit for the entire works.

I think he's a member of this board, by the way - but I don't know what name he registered here with (he's had various handles over the years).

EDIT:  found him... he hasn't logged on in a few years.;u=426

Newcomer's Board / Re: PC-Engine/Turbografx-CD CD Image Hacking Help
« on: April 23, 2022, 11:55:21 am »
If I am going to burn a CD-R for playing in the actual PC-Engine console, do I need to do anything else besides simply burning the image to make it work?

Since the PC Engine uses a non-standard format for CDROMs, some burning software may react oddly to the audio/data/audio format - I use ImgBurn, which works great.

The other thing is that some games refer to CDDA music by time signature (rather than just track number), so if you're planning on replacing any game music files, the new file has to match the old file down to the exact frame count (1 frame = 1/75 second).  Incorrect timings have been known to cause game freezes or misaligned music in the past, even when improperly extracted from the original disc - but with TurboRip, all of the file sizes will be correct.

Newcomer's Board / Re: PC-Engine/Turbografx-CD CD Image Hacking Help
« on: April 23, 2022, 10:10:10 am »
Looks like you are using Redump rips, which are 2352 bytes per sector.

This is fine for audio (always 2352 bytes), and for Playstation games which natively use MODE1/2352, but not for the data tracks of anything made prior - for those, you will need MODE1/2048 sectors.

For this, you will need to:
- extract the data track(s) as MODE1/2048
- make whatever changes are necessary
- re-master, as the other 304 bytes are ECC data, which is calculated from the 2048 base

Note 1:
If you have a way of mounting the CD image (Daemon Tools used to be able to do this, but I'm not sure if it does anymore), you should be able to re-rip into individual file more easily using TurboRip which can be found here:

Note 2:
'Remastering' doesn't have to mean writing a CD-R... any program that interprets the .cue file should be able to do whatever is needed for this - for example, Mednafen runs game with a cue file reference.

Newcomer's Board / Re: Change music on Sega CD game?
« on: March 31, 2022, 10:25:27 am »
I'm pretty sure that Sega CD used redbook audio.  (as track 2 and onward, to conform to orange book)

Also, in cases like this where the audio tracks are ripped as bin, they are just binary rips - which are effectively WAV files, but without the headers that make them WAV files.

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.


Pages: [1] 2 3