I'm using assembly.
Welcome, it's always nice to see someone willing to program in asm!
How can one signal to emulators that the game binary is a CD game?
Generally you tell them to load/run a .CUE file instead of a .PCE/.SGX HuCARD image.
A .CUE file is a text file that describes a CD track layout, including the names the other files on your computer that contain the data for each of those tracks (whether the tracks are CD audio data or CD-ROM data).
The data in the tracks can be either the raw CD standard-compliant bitstream with includes all the additional error-correction information, or it can be just a number of 2048-byte binary sectors for the CD-ROM tracks, and a set of .WAV files for the CD-AUDIO tracks.
The CD-ROM tracks have no filesystem, that luxury didn't happen until many years later.
In the case of the PC Engine, the System Card reads the first 2 sectors of the first CD-ROM track on the disc, and if they contain the appropriate signature data that it's looking for, then it uses the information in second sector to tell it what data sectors to load from the CD, where to put them in memory, and what address to jump to to start executing the game program.
I've notice that CD games have different binary formats, why?
Well, technically they don't ... it's always an image of a CD.
But there have been many different ways of representing the contents of a CD that have been used over the years, and emulators often have to support a number of different conventions because there was no universal standard when people started to rip the contents of CD discs onto their computers.
The easiest convention to use for developing homebrew is the .CUE/.BIN/.WAV format.
Where in the HuC6280 address space do a CD game starts in? I mean, what is the process of the game code in the CD to 'take over'?
As mentioned above, this is determined by the game's boot sectors.
Have you found Hudson's official System Card documentation yet? The boot process is described in there.
Most developers really don't get too deep into that stuff because we have tools to take care of that stuff and make life easier.
What toolchain are you currently using for you PC Engine experiments?
Coming from the NES and SNES, I could see you using CA65 or WLA-DX ... but those really aren't the best tools for PC Engine coding (IMHO).
The TurboGrafx-16 CD hardware consists of the following:
- 64K general purpose RAM for the CD software to use
What exactly does this mean? 64K to decompress tiles, etc?
It means that you have 64KBytes of CPU accessible memory available for your program and data.
If you need different code/data, then you have to load it from your game's CD-ROM track.
There aren't many sane reasons to develop for the original System Card these days, you're going to get much nicer results if you develop for the Super System Card which bumps up the RAM to 256KBytes.
Can one access this RAM without the System Card? If so, how?
It's just RAM in banks $80..$87 (or banks $68..$87 for the Super System Card).
(I tried setting the address with $1808/$1809 and then writing to $180A, but the RAM did not changed)
Regarding ADPCM, is this a completely different system from the base PC-Engine's PSG sound system?
Yes, it's a completely different system from the PSG, with its own 64KBytes of memory.
Those registers that you're playing with are for reading/writing that ADPCM memory from the main CPU. It's quite slow.
Early PC Engine CD games with the 64KByte RAM limit sometimes stored extra graphics/code in the ADPCM memory because that was (sometimes) faster than seeking to find the data on the CD-ROM.
- 2K battery backed RAM for save game data and high scores
Is this 2k for all games? How does one know the amount of RAM available for your game, and at which location?
2KBytes shared for all games. There is a storage convention that you use for allocating and using "files" within that 2KBytes. You normally use the System Card functions to do the reading/writing if you're developing a CD game.
Is it possible for a HuCard game to run the CD hardware without the need of a System Card?
Perfectly possible, just rarely done because it makes little sense for game development.
If you're developing a HuCARD game then you're generally doing it because you want it to run on PC Engine hardware that doesn't have a CD drive.
If you're developing a CD game, then there's no reason to include the horrific expense of including a HuCARD as well, it doesn't get you any benefits.
Recent Posts
They can be either a bespoke/unique port or imagined.