News: 11 March 2016 - Forum Rules

Author Topic: Extract artworks from PC-Engine CD image?  (Read 2908 times)

MisterXen

  • Jr. Member
  • **
  • Posts: 3
    • View Profile
Extract artworks from PC-Engine CD image?
« on: June 02, 2017, 07:39:44 pm »
Greetings everyone! I am interested in ripping backgrounds/sprites from PC-Engine CD-Rom games. I am aware of method like this but wanted to know if more direct approaches are available. Take the game Dracula X as an example, with guidance from this post I was able to separate the image file into 20 sound files and 2 data tracks. The sound files played alright but I have no idea how to unpack the data tracks :( . I suppose no general tools exist for this kind of tasks (correct me if I am wrong) so hex hacking is a necessity, I have some experience in C/Python but are completely new to this scene, and I'd be glad if some one can point me to some tutorial/resources for beginners :)

Also just out of curiosity, why is the size of ripped tracks much smaller than the original image? ISO of Dracula X is about 500M but ripped tracks are only like 64M :o

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7183
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: Extract artworks from PC-Engine CD image?
« Reply #1 on: June 02, 2017, 10:08:12 pm »
Ripped audio tracks have probably been compressed to MP3 or something.
"My watch says 30 chickens" Google, 2018

MisterXen

  • Jr. Member
  • **
  • Posts: 3
    • View Profile
Re: Extract artworks from PC-Engine CD image?
« Reply #2 on: June 02, 2017, 10:29:13 pm »
Ripped audio tracks have probably been compressed to MP3 or something.
This :thumbsup:, should have noticed all ripped music files are 80kbps Ogg

elmer

  • Full Member
  • ***
  • Posts: 122
    • View Profile
Re: Extract artworks from PC-Engine CD image?
« Reply #3 on: June 03, 2017, 11:24:35 am »
You've got two issues here ... (1) getting a good rip with the data and audio tracks separated, (2) getting the graphics out of the data track.

***********************

For ripping a PCE CD, you can use something like these on Windows ...

NightWolve's TurboRIP & TOCFixer
http://www.ysutopia.net/index.php?ind=downloads&op=section_view&idev=3

They contain a database of every PC Engine CD game, and can help to create a known-good rip.


If you've already got a rip as two files, a .cue and a .bin/.iso, then you can use "bchunk" to split it into data and audio tracks.

The problem is that most Windows builds of bchunk have a bug in their calculation of the sector lengths when splitting up the .bin/.iso into the separate .iso and .wav files.

I found/fixed this when building bchunk for use with my Zeroigar and Legend of Xanadu translations.

Here's the patch to fix the bchunk 1.2.0 source, and also to allow it to compile on Windows with mingw-w64 & msys2 ...

Code: [Select]
diff -Naur bchunk-1.2.0/bchunk.c bchunk-1.2.0-msys2/bchunk.c
--- bchunk-1.2.0/bchunk.c 2004-06-29 21:42:34.000000000 +0100
+++ bchunk-1.2.0-msys2/bchunk.c 2015-07-02 17:35:51.323496400 +0100
@@ -58,7 +58,11 @@
  */
 
 #include <inttypes.h>
-#include <netinet/in.h>
+#ifdef _WIN32
+ #include <winsock2.h>
+#else
+ #include <netinet/in.h>
+#endif
 
 #define bswap_16(x) \
      ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8))
@@ -279,7 +283,7 @@
 
  printf("%2d: %s ", track->num, fname);
 
- if (!(f = fopen(fname, "w"))) {
+ if (!(f = fopen(fname, "wb"))) {
  fprintf(stderr, " Could not fopen track file: %s\n", strerror(errno));
  exit(4);
  }
@@ -289,7 +293,7 @@
  exit(4);
  }
 
- reallen = (track->stopsect - track->startsect + 1) * track->bsize;
+ reallen = (track->stopsect - track->startsect) * track->bsize;
  if (verbose) {
  printf("\n mmc sectors %ld->%ld (%ld)", track->startsect, track->stopsect, track->stopsect - track->startsect + 1);
  printf("\n mmc bytes %ld->%ld (%ld)", track->start, track->stop, track->stop - track->start + 1);
@@ -332,7 +336,7 @@
  sz = track->start;
  sect = track->startsect;
  fl = 0;
- while ((sect <= track->stopsect) && (fread(buf, SECTLEN, 1, bf) > 0)) {
+ while ((sect < track->stopsect) && (fread(buf, SECTLEN, 1, bf) > 0)) {
  if (track->audio) {
  if (swabaudio) {
  /* swap low and high bytes */
@@ -399,7 +403,7 @@
 
  parse_args(argc, argv);
 
- if (!((binf = fopen(binfile, "r")))) {
+ if (!((binf = fopen(binfile, "rb")))) {
  fprintf(stderr, "Could not open BIN %s: %s\n", binfile, strerror(errno));
  return 2;
  }
diff -Naur bchunk-1.2.0/Makefile bchunk-1.2.0-msys2/Makefile
--- bchunk-1.2.0/Makefile 2001-08-02 13:51:40.000000000 +0100
+++ bchunk-1.2.0-msys2/Makefile 2015-04-04 12:38:34.870112100 +0100
@@ -33,7 +33,7 @@
 BITS = bchunk.o
 
 bchunk: $(BITS)
- $(LD) $(LDFLAGS) -o bchunk $(BITS)
+ $(LD) $(LDFLAGS) -o bchunk $(BITS) -lwsock32
 
 bchunk.o: bchunk.c


You can find a prebuilt Windows copy of the fixed bchunk in my Zeroigar translation patch that's on this site.


***********************

Good luck on the next part, you'll need it!

There is no standard format for the data in the data track. There is no filesystem in there, unless the developers created a custom one for themselves, and even if they did ... you have no idea what it is.

You've already found that old thread. Read tomaitheous's post again ...

http://www.romhacking.net/forum/index.php?topic=17351.msg254052#msg254052

To find the graphics of most games, you'll have to hack the game itself to figure out the compression format ... and then you'll still have to figure out where the graphics data is stored in the decompressed data.

None of this is for the faint-of-heart.

Honestly ... for most things, you'll probably find it easier to run the game in an emulator like Mednafen, and then dump the contents of VRAM and main RAM when you see something that you want to extract.

MisterXen

  • Jr. Member
  • **
  • Posts: 3
    • View Profile
Re: Extract artworks from PC-Engine CD image?
« Reply #4 on: June 04, 2017, 03:36:12 am »
You've got two issues here ... (1) getting a good rip with the data and audio tracks separated, (2) getting the graphics out of the data track.

***********************

For ripping a PCE CD, you can use something like these on Windows ...

NightWolve's TurboRIP & TOCFixer
http://www.ysutopia.net/index.php?ind=downloads&op=section_view&idev=3

They contain a database of every PC Engine CD game, and can help to create a known-good rip.


If you've already got a rip as two files, a .cue and a .bin/.iso, then you can use "bchunk" to split it into data and audio tracks.

The problem is that most Windows builds of bchunk have a bug in their calculation of the sector lengths when splitting up the .bin/.iso into the separate .iso and .wav files.

I found/fixed this when building bchunk for use with my Zeroigar and Legend of Xanadu translations.

Here's the patch to fix the bchunk 1.2.0 source, and also to allow it to compile on Windows with mingw-w64 & msys2 ...

Code: [Select]
diff -Naur bchunk-1.2.0/bchunk.c bchunk-1.2.0-msys2/bchunk.c
--- bchunk-1.2.0/bchunk.c 2004-06-29 21:42:34.000000000 +0100
+++ bchunk-1.2.0-msys2/bchunk.c 2015-07-02 17:35:51.323496400 +0100
@@ -58,7 +58,11 @@
  */
 
 #include <inttypes.h>
-#include <netinet/in.h>
+#ifdef _WIN32
+ #include <winsock2.h>
+#else
+ #include <netinet/in.h>
+#endif
 
 #define bswap_16(x) \
      ((((x) >> 8) & 0xff) | (((x) & 0xff) << 8))
@@ -279,7 +283,7 @@
 
  printf("%2d: %s ", track->num, fname);
 
- if (!(f = fopen(fname, "w"))) {
+ if (!(f = fopen(fname, "wb"))) {
  fprintf(stderr, " Could not fopen track file: %s\n", strerror(errno));
  exit(4);
  }
@@ -289,7 +293,7 @@
  exit(4);
  }
 
- reallen = (track->stopsect - track->startsect + 1) * track->bsize;
+ reallen = (track->stopsect - track->startsect) * track->bsize;
  if (verbose) {
  printf("\n mmc sectors %ld->%ld (%ld)", track->startsect, track->stopsect, track->stopsect - track->startsect + 1);
  printf("\n mmc bytes %ld->%ld (%ld)", track->start, track->stop, track->stop - track->start + 1);
@@ -332,7 +336,7 @@
  sz = track->start;
  sect = track->startsect;
  fl = 0;
- while ((sect <= track->stopsect) && (fread(buf, SECTLEN, 1, bf) > 0)) {
+ while ((sect < track->stopsect) && (fread(buf, SECTLEN, 1, bf) > 0)) {
  if (track->audio) {
  if (swabaudio) {
  /* swap low and high bytes */
@@ -399,7 +403,7 @@
 
  parse_args(argc, argv);
 
- if (!((binf = fopen(binfile, "r")))) {
+ if (!((binf = fopen(binfile, "rb")))) {
  fprintf(stderr, "Could not open BIN %s: %s\n", binfile, strerror(errno));
  return 2;
  }
diff -Naur bchunk-1.2.0/Makefile bchunk-1.2.0-msys2/Makefile
--- bchunk-1.2.0/Makefile 2001-08-02 13:51:40.000000000 +0100
+++ bchunk-1.2.0-msys2/Makefile 2015-04-04 12:38:34.870112100 +0100
@@ -33,7 +33,7 @@
 BITS = bchunk.o
 
 bchunk: $(BITS)
- $(LD) $(LDFLAGS) -o bchunk $(BITS)
+ $(LD) $(LDFLAGS) -o bchunk $(BITS) -lwsock32
 
 bchunk.o: bchunk.c


You can find a prebuilt Windows copy of the fixed bchunk in my Zeroigar translation patch that's on this site.


***********************

Good luck on the next part, you'll need it!

There is no standard format for the data in the data track. There is no filesystem in there, unless the developers created a custom one for themselves, and even if they did ... you have no idea what it is.

You've already found that old thread. Read tomaitheous's post again ...

http://www.romhacking.net/forum/index.php?topic=17351.msg254052#msg254052

To find the graphics of most games, you'll have to hack the game itself to figure out the compression format ... and then you'll still have to figure out where the graphics data is stored in the decompressed data.

None of this is for the faint-of-heart.

Honestly ... for most things, you'll probably find it easier to run the game in an emulator like Mednafen, and then dump the contents of VRAM and main RAM when you see something that you want to extract.

Thanks for your reply. For track splitting, the tool I am using is "bincuesplit" by Francisco Munoz, is this an outdated tool? I do notice that it doesn't work with all games. On the other hand I will definitely look into "bchunk".

For hacking, I understand it's not for beginner and way beyond my level :(, but can you point me to some resources for beginner so I may pick it up someday? Is basic ASM a good start?

As for VRAM dumping, I can use Mednafen to examine and dump the memory but I have no idea how to tell which is which and extract relevant data :-[. According to the Mednafen documentation 0000-7FFF are for VRAM so is this 32KB the only part I need to concern? Now for an example, when a sprite is changing color on screen I notice there is a particular part in memory changing in same frequency, since it's so short I suppose it's the palette (encoding in RGB565?), but then I don't know how to proceed...

elmer

  • Full Member
  • ***
  • Posts: 122
    • View Profile
Re: Extract artworks from PC-Engine CD image?
« Reply #5 on: June 05, 2017, 09:06:11 pm »
Thanks for your reply. For track splitting, the tool I am using is "bincuesplit" by Francisco Munoz, is this an outdated tool?

I've never heard of bincuesplit, and can find no mention of it online.

bchunk is included in pretty-much-every linux distribution ... and I know that it has worked on my PC Engine games.


Quote
For hacking, I understand it's not for beginner and way beyond my level :(, but can you point me to some resources for beginner so I may pick it up someday? Is basic ASM a good start?

There is nothing wrong with being a beginner, we all were at some point. The question is one of how and where you start learning.

Personally, I recommend that you learn to program in assembly first ... that's the best way (IMHO) to get a handle on how games were put together back then, and give you the grounding in hardware that you'll need to be able to deconstruct games and extract graphics or data from them.

I generally recommend the original Gameboy as an excellent starting point. It's got all of the basics, and it's a simple design to work with.

Once you've got your head around one CPU in assembly language, it's pretty easy to switch to another CPU.

I imagine that other people would have different recommendations.


Quote
As for VRAM dumping, I can use Mednafen to examine and dump the memory but I have no idea how to tell which is which and extract relevant data :-[. According to the Mednafen documentation 0000-7FFF are for VRAM so is this 32KB the only part I need to concern? Now for an example, when a sprite is changing color on screen I notice there is a particular part in memory changing in same frequency, since it's so short I suppose it's the palette (encoding in RGB565?), but then I don't know how to proceed...

PCE VRAM is 32K words ... so 64K bytes. Honestly, I'm very sorry to be blunt, but I don't have the time to teach you the basics of how these old machines work.

Have you found the Archaic Pixels website yet? http://www.archaicpixels.com/Main_Page

The PC Engine is a very clean and logical piece of hardware ... but until you know the basics of these old machines, it is unlikely to make much sense.

If you join the forums at pcenginefx.com, there are people there who may be able to help you.