I have a few PC Engine Super CD-ROM games, and they have an unconventional mixed mode layout: Track 1 is an Audio track (a warning to not play this disc in a CD Player), Track 2 is a data track, then there are a audio tracks (actual audio, not binary data masking as such), and then there's a second data track at the end.

For example, the Japanese PC-Engine CD Game Snatcher:

Snatcher PCE CD Example

Neither data track seems to have a known file system (e.g., ISO 9660), so I wonder if there was a standard file system, or if every game/vendor did their own thing, and why they use two data tracks instead of the more common 1 Data + 0-98 Audio tracks of later CD-based game consoles. I know that the PCE CD-ROM Drive could be used as a CD-ROM drive on a special model of the PC-88, so I wonder if the PC-Engine CD Format has any roots/commonalities on the PC-88, but I don't know much about NECs line of PCs.

Google was not overly helpful since my search queries resulted in dump formats for emulators (iso, bin/cue, chd etc.) and I couldn't find much about the actual format of real PCE/TGX CDs.

Looking at the track in a Hex Editor shows clear-text strings of authorship information, so this definitely looks like something unique to the PCE/TGX CD-ROM Format, and it does look like a standard format, not a "every game developer has to build their own CD-ROM routines":

Track 2 in a Hex Editor, Part 1

Track 2 in a Hex Editor, Part 2

Is there documentation for the format?

  • The beginning of the track (offset 0) could give some hint about the actual format, so please include the hexdump of this, too. If you can, copy&paste as code (indent 4 spaces). Or link to an upload of the complete track somewhere.
    – dirkt
    Aug 13 at 5:15

2 Answers 2


I managed to find what looks like the original Developer Documentation of the toolchain, which was hugely helpful to piece the puzzle together.

To answer my own question: Yes, there was a standard, though it looked very different from later CD-ROM formats and more like a magnetic tape format, and it's pretty much all manually managed.

The CD-ROM² unit came with a System Card (*1), which provided BIOS functions to interact with the CD. All games that were made using the system card (*2) and official tool chain follow a similar structure. There are different versions, but the differences don't matter here (*3).

On the final CD, there is a Header ("IPL") to load and run the initial executable, but there is NO central directory - a game would literally hardcode sector addresses into its code and say "Read X bytes from Sector Y into RAM Address Z", and the toolchain would be used to lay out that structure. (*5) Technically, you can lay out the CD however you want apart from that IPL header, but it seems that all official games followed the structure created by the official toolchain.

The Hu7 dev kit came with a 620 MB Hard Drive (*6), and the idea was to declare "I have a file named test.bin that's at most 8 blocks long", which would reserve 8 Blocks * 2048 Bytes = 16384 Bytes for a file, and then the developer could later update the actual content of the file. If the actual file is less than 16384 Bytes, it would be filled with 0x00. If the actual file is more... well, tough. You'd either have to reserve a new file at the end, or backup the entire hard drive to tape and restore only the used files as a kind of manual defrag process.

When you're done with the layout and ready to write game code, the INFGET.EXE in the toolchain would create an Assembly file (they call it an "equ file" because it's all just definitions like TESTBIN_LW EQU $0001) that contained the actual sector offsets of each file. Audio Tracks were also handled through this, though they used different commands.

BIOS functions like CD_READ/CD_SEEK/CD_EXEC take three arguments, REC H, REC M, and REC L, which could be fed from those definitions (TESTBIN_LW would contain the REC M and REC L bytes, while TESTBIN_HI would contain the REC H byte).

So the "block reservation" strategy made sense because you have a chicken/egg problem: How can you compile your application with all the hardcoded offsets if you don't know yet how big the resulting executable is and where it's located? You did that by reserving the space/location beforehand - it's all completely laid out by hand, and then the actual content is filled in later.

There is no need for the data track to be Track 2 - it can be Track 1, which some homebrew games do (*7). The System Card BIOS will seek to the first data track and read the IPL header from there. But I assume it made so much more sense to have Track 1 be the "Warning: Do not play in a CD Player" audio track (*8), and because the official toolchain/documentation does that, all official games do that.

The BIOS supports a second data track (the CD_BASE function supports two offsets), though I don't know if there was an official intended use-case for the second data track.

I've seen a few possible explanations, and the one that makes most sense to me is for performance. By placing the second data track at the end, it's located more toward the outer edges of the actual CD. The 1X Speed CD-ROM drive was pretty slow, and data toward the outer edges reads a bit faster (better latency/lower seek times?), so it looks like it's good to place media assets there. That said, I haven't spend too much time looking at what's actually on there on the games that I own.

I found an alternative explanation that data would be duplicated on both tracks in case of scratches making stuff unreadable in one data track - but I couldn't substantiate that claim and I'm not seeing that duplication on the games I own, so I assume that's just a homebrew thing.

(*1) The card was built directly into some later systems like the Turbo Duo

(*2) There was at least one unlicensed CD Card, and the few games seem to have a different disc format. I don't care about this one.

(*3) Version 2.0 added CD+G support, Version 2.1 added some way to auto-detect disc changes. The Super CD-ROM² (3.0) (*4) and Arcade Card added more RAM. But the disc format stayed the same.

(*4) The Super CD-ROM² is not to be confused with the SuperGrafx, which was a different console, which didn't have a CD-ROM drive. Well, unless you add one yourself.

(*5) There is a differentiation between Audio Tracks and Data, and different BIOS functions. But even audio tracks have to be hardcoded with offsets in the application. Also, it's not really sector addresses: One would specify a base address using CD_BASE and then a record offset when calling CD_READ, and the BIOS itself would do the "CD_BASE + (Offset * 2048)" math. Also, even though the Hu7 SDK has tools to maintain a central directory on the development hard drive, it looks like the final CD doesn't even contain the original file names anymore - the central directory only exists as definitions in an Assembly file, compiled into the executable.

(*6) And also a 8mm Tape Drive, which could be used for backups but also as the final master - NEC wanted you to send them two tapes with your CD-ROM image so they could duplicate it. Ah, the era before CD-Rs or sending a hard drive with a binary fine were an option.

(*7) Nowadays, HuC and related tools like isolink seems to be the toolchain of choice, which doesn't strictly follow the same methods as the Hu7 dev kit tools do

(*8) Yellow Book compliance is definitely not a thing here, even though that standard came out in 1983. I think NEC made the right call here: CDs were still very new technology, the PC-Engine was one of the first systems that used Data CDs, so it's reasonable to assume that people would put the CDs into a regular CD Player.

  • 1
    The Super CD-ROM 2 drive was released in 1991 and was a 2x speed drive. These were usually CLV drives so the disc was spun slower when reading data from the outer edge, so data was transferred at constant rate no matter from where it is read. If there is proper specs for the device that says it was a CAV drive then outer edges would read faster.
    – Justme
    Aug 16 at 20:41
  • @Justme I've been mostly looking at the Japanese PC Engine system, which had its CD drive released in December 1988 and seems to have been a 1X drive (constant 150 kb/s speed) - not sure if the American TurboGrafx CD or later TurboDuo systems went to a 2X drive (like the Neo Geo CDZ). That said, most of the technical details I've found so far are e.g., on the Japanese Wikipedia, so still trying to piece stuff together. I wonder if the outer edges have better initial latency, rather than better throughput? Aug 16 at 20:52
  • 1
    OK, sorry I quoted a wrong drive then. However both 1X and 2X drives should still be CLV drives so that's unchanged.
    – Justme
    Aug 16 at 20:59

Take a look at the HuC compiler's ISOLINK, it can create an ISO file. https://raw.githubusercontent.com/uli/huc/master/doc/huc/overlays.txt

About the Yellow Book: "...this book did not define any format for organizing data on CD-ROMs into logical units such as files, which led to every CD-ROM maker creating its own format." Wikipedia

  • 1
    An ISO file as in "file that contains image/dump of CD data track contents regardless of whatever it may contain" or ISO file as in "image/dump which contains a standard ISO9660 file system"?
    – Justme
    Aug 15 at 19:27
  • 3
    Given that HuC is a toolchain for the PC Engine, it produces "something that will run on the PC Engine". However, the "What does isolink really do ?" section of that "Overlays FAQ" indicates that it's taking a more COFF/PE/ELF-esque approach and producing a bootloader+segments file, not an ISO9660 filesystem. (Sort of like how non-hybrid mac ISOs are HFS disk images with .iso extensions.) Thus, if there was a standard filesystem for the PC Engine, it may be implemented in the bootloader generated by the official platform devkit, not in the firmware. (Which would save on ROM costs.)
    – ssokolow
    Aug 16 at 0:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .