| View previous topic :: View next topic |
| Author |
Message |
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
 Posted: Tue Jun 27, 2006 2:41 am Post subject: ISO-9660 PC Engine CD format |
 |
|
Today I made my first(the first?) ISO-9660 PCE hybrid CD. I say hybrid because the game points to the second track after the logo and boot code loads. It's very much possible to make a SEGA CD format style CD for the PCE CD system. Matter of fact, the method I used is pretty much what the SEGA CD format does.
Here brief explination-
The ISO9660 standard is the CDFS format. The first 16 sectors are ingored by the CDFS system ( read reserved). The MAC HSF CDs and other operating systems use these sectors as well. Other known practice is the "ElTorito" boot CD that Windos XP and other bootable PC CDs use, which in turn uses these first 16 sectors.
The PCE boot sequence is in the first two sectors of the data track so it easily fits into the first 16 sectors. I made a CDFS ISO with Nero which contained the track2.iso file. I then edited the CDFS ISO and added the PCE boot sectors. I then located the offset(in sectors) to the track2.iso file and added the additional sectors to the control variables located in the beginning of the second sector. The test game ofcourse was Spriggan mark 2 - inwhich I changed both the read data sector offset( byte 2 - relative to 0) and the graphic logo screen sector offset( byte $10) to the difference of the ISO file from the original position. The boot code for the game is coded to read data track 2, so it doesn't load anything else from track 1 after the boot sequence.
I also added a text file called "z_readme.txt" to the CDFS iso and was readable as a text file in explorer. I had to add the "z" to force it to come after the "spriggan.iso" so my sector point wouldn't be off. This isn't a big deal as I could have just recalculated the sector address for the "spriggan.iso" file.
You could design a game from the ground up to use nothing but the iso9660 track 1 and have the graphic, sound, and text as files in the CDFS format or provided additional material for the gamer, i.e. behind the scenes, art work, etc.
Rich
_________________
www.pcedev.net |
|
| Back to top |
|
 |
Charles MacDonald
Member
Joined: 07 Dec 2005
Posts: 35
|
| Posted: Tue Jun 27, 2006 5:01 am Post subject: |
|
|
This is ingenious. So you have a CD with data tracks for 1 and 2; where track 2 contains the regular PCE boot code? Considering track 1 is always used for the warning in PCE games, it won't be missed. 
I like the idea of making a hybrid disc. Then you could share audio tracks and maybe resources (have a third data track of common graphics, tables, etc.) for the Sega CD program in track 1 or the PCE program in track 2 to use.
Having a real filesystem for PCE CD games is a fantastic idea too; I think the Games Express CD titles did this, but they had a hacked System Card and your idea requires no modifications. |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Tue Jun 27, 2006 6:38 am Post subject: |
|
|
| Quote: | | So you have a CD with data tracks for 1 and 2; where track 2 contains the regular PCE boot code? |
Actually, track 1 contains the PCE boot code(first two sectors) as well. The PCE bios never gets to read the PCE boot sectors from track 2, but the game reads from this track as its hardcoded. I think Dave Shadoff had a doc referring to this as "inf.h" file containing all the pointers( and tracks?).
From all the tests I've done it seems the PCE (BIOS?) system looks for the first data track in the TOC then checks for the copyright code/sector( both?) - if no check code then the BIOS stops and displays the "load cd error" message and doesn't continue checking the rest of the data tracks for a valid check code.
The strange thing is that a lot of PCE games repeat the first data track(2) as the last CD track, but they're identical. If you remove all data tracks from the iso except the last one, the system will load game boot sequence from the last track, but will halt as it will try to read data from track 2. A compatibility fix for some systems that couldn't identify the second data track?
| Quote: | | for the Sega CD program in track 1 or the PCE program in track 2 to use |
That's an interesting idea, but it might require the "hidden track" trick as the Sega CD has its check code in the first two sectors as well(I think).
-Rich
EDIT: It worked! I have Lords of Thunder for Sega CD and Spriggan Mark 2 for SCD on the same disc and they boot in both systems. Apparently the Sega CD reads from index 00 of track 1 while the PCE ignores index 00 and starts reading from index 01 of track 1. The two systems tested it on were the US Sega 2 + CD and a SGX+SCD2 unit.
_________________
www.pcedev.net |
|
| Back to top |
|
|
Rockman
Regular
Joined: 23 Jun 2004
Posts: 155
|
| Posted: Wed Jun 28, 2006 7:58 am Post subject: |
|
|
| I did something similar. I ripped bomberman from the 3-in-1 CD and wrote a small bootloader that coppied the rom into the syscard ram and ran the game. On the PC side my disc was bootable (win98 dos mode) and loaded up the old dos Magic Engine and played the exact same rom image. |
|
| Back to top |
|
|
David Shadoff
Regular
Joined: 10 May 2002
Posts: 83
Location: Toronto, Ontario, Canada
|
| Posted: Wed Jun 28, 2006 11:39 pm Post subject: COOL |
|
|
NICE !
I had never thought about this approach. I like it a lot.
I had created a 'sort of' hybrid CD at one time (oh, about 8 years ago...), with the PCE data track in session 1, and the ISO track in session 2. As I recall, session 1 track 1 needed to be audio too. The PC Engine can only read session 1, so it was great for the real machine, but PC's got a bit confused when emulating.
Actually, I was only able to get this to work on one writer, and not consistently, so I eventually gave up. My original idea was to do this so that the source code could be distributed on the same disc as the game itself, for the real hardcore developers among us. That, and because it's cool.
The textfile that you're referring to, with the description of the various bytes in the first 2 sectors, was actually not originally from me. Somebody else from the turbo-list (sorry, can't remember who) found it embedded in the data track of a comercial game - I think it was Golden Axe - and we speculated that it was a remnant of an actual developer's kit that got published accidentally.
There were other hidden fragments of code too (and Chris Covell also discovered lots of cool "hidden" graphics), but this was probably the most useful piece of accidentally-discovered information. |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Thu Jun 29, 2006 3:33 am Post subject: Re: COOL |
|
|
| David Shadoff wrote: | | There were other hidden fragments of code too (and Chris Covell also discovered lots of cool "hidden" graphics), but this was probably the most useful piece of accidentally-discovered information. |
That's hilarious!
| Code: |
db 'PC Engine CD-ROM SYSTEM',0 ;(ID string)
db 'Copyright HUDSON SOFT / NEC Home Electronics,Ltd.',0
if VISUAL_TEST
db 'VISUAL TEST ' ;program name (16 bytes)
db ' ' ; (6 bytes)
elseif FINAL_ZONE
db 'FINAL ZONE II ' ;program name (16 bytes)
db ' ' ; (6 bytes)
elseif GOLDEN_AXE
db 'GOLDEN AXE ' ;program name (16 bytes)
db ' ' ; (6 bytes)
endif
|
It'd be pretty cool to have the boot code(_boot.bin) read the FAT and look for the _startup.bin file load it as well as mapped all other files sector addresses into ram for futute loading, i.e. graphics, sound, mapped, stages(overlays).
Shape Shifter appears to be in some sort of PC format( BM format? )
| Code: | ULTRA1.BIN O ( \
ULTRA2.VRM T \
ULTRA2.BIN X \ ".
N2PANT.BIN " \ \ N2SHARK.BIN " ` \ N2STONE.BIN d \ *
N2DRAG.BIN " h \
2 N2ULTRA.BIN l \ 4
L2PANT.BIN " p \
L2SHARK.BIN " t \ L2STONE.BIN x \ 0
L2DRAG.BIN " | \
2 L2ULTRA.BIN \ 6
C2PANT.BIN " \ C2SHARK.BIN " \ C2STONE.BIN \ 4
C2DRAG.BIN " \
2" C2ULTRA.BIN \ :
P2PANT.BIN " \ P2SHARK.BIN " \ " P2STONE.BIN \ 6
P2DRAG.BIN " \
2& P2ULTRA.BIN [ / DSEG.BIN \
ENDING.BIN ; \4 HAPPY.BIN \4 HAPPY.M00 Ԁ \4 HAPPY.FNT \6" SAD.M00 Ӏ \6 SAD.FNT \96 DARK.M00 \90 DARK.FNT \
: RING.M00 \
8 RING.FNT & \
STORY.M00 * \
STORY.FNT D \
* DEATH.M00 H \
$ DEATH.FNT c \ & ADPCM.BIN 1 \
STCITY.LEV | \
STCITY.PRG \
STCITY.VRM 1Z \
4 TREES.LEV \ 3, TREES.PRG \
4 TREES.VRM , \
6
DRIDER.LEV t \ /
DRIDER.PRG \
8
DRIDER.VRM " # \
: COCOONL.LEV " \ |
| Quote: | | I did something similar. I ripped bomberman from the 3-in-1 CD and wrote a small bootloader that coppied the rom into the syscard ram and ran the game. On the PC side my disc was bootable (win98 dos mode) and loaded up the old dos Magic Engine and played the exact same rom image. |
So the first track/iso had a CDFS file system in it as well as the PCE boot data/copyright check?
edit: This is hilarious too!
Shapeshifter-
| Code: | LoMNoMNO Look in your own code you wanker ! #
.
.
.
T.H.C Productions 1992 |
_________________
www.pcedev.net |
|
| Back to top |
|
|
Keranu
Elder
Joined: 05 Aug 2002
Posts: 669
Location: Neo Geo Land
|
| Posted: Thu Jun 29, 2006 8:59 am Post subject: |
|
|
Hahaha, that's so awesome! Please update me on any other secret messages like that too  .
_________________
LaZer Dorks |
|
| Back to top |
|
|
cdoty
Member
Joined: 02 Feb 2005
Posts: 73
Location: Houston, TX
|
| Posted: Thu Jul 06, 2006 8:42 pm Post subject: Hmm. |
|
|
*removed duplicate post*
_________________
Visit RasterSoft on facebook or visit the website.
Last edited by cdoty on Thu Jul 06, 2006 8:45 pm; edited 1 time in total |
|
| Back to top |
|
|
cdoty
Member
Joined: 02 Feb 2005
Posts: 73
Location: Houston, TX
|
| Posted: Thu Jul 06, 2006 8:43 pm Post subject: Hmm. |
|
|
This sounds like a very interesting discovery. I'm trying to do the same for a SegaCD/TG-16CD version of Frog Feast.
I'm starting out with something simple. I took the iso for the HuC program testcd (http://www.zeograd.com/download_presentation.php?lang=en&id=118), and inserted 0x800 bytes of data at location 0x1000 (moved the boot code from sector 2 to 3). I changed location 0x0802 from 0x02 to 0x03. Locations 0x10 contains 0.
This doesn't work, am I missing something?
_________________
Visit RasterSoft on facebook or visit the website. |
|
| Back to top |
|
|
Tomaitheous
Elder
Joined: 27 Sep 2005
Posts: 306
Location: Tucson
|
| Posted: Fri Jul 07, 2006 2:23 am Post subject: Re: Hmm. |
|
|
| cdoty wrote: | This sounds like a very interesting discovery. I'm trying to do the same for a SegaCD/TG-16CD version of Frog Feast.
I'm starting out with something simple. I took the iso for the HuC program testcd (http://www.zeograd.com/download_presentation.php?lang=en&id=118), and inserted 0x800 bytes of data at location 0x1000 (moved the boot code from sector 2 to 3). I changed location 0x0802 from 0x02 to 0x03. Locations 0x10 contains 0.
This doesn't work, am I missing something? |
Let me see if I understand you correctly, you're trying to make a Sega CD/TG-16 CD hybrid CD correct? So that if put in a Sega CD, the SEGA CD system will load and execute them game and if the same CD it put into a TG/PCE CD system, it will load the TG/PCE game?
1st - Take the total number of bytes of the Sega CD iso and divide by 2048 to get the total number of frames in the ISO. Then divide the number of frames by 75 to get the total number of seconds the iso is in length. You probably won't have more than 60 seconds, but if so then convert the seconds into minutes, etc. Now, if after the conversion you have any frames left over, i.e. 00:47:13 - (Minutes:Seconds:Frames), then pad the iso with sectors(2048bytes) containing zero's until your total length has no left over frames, i.e. rounding the iso to the next second.
2nd - Take the Sega CD iso (padded iso if modified) and append the TG-16 iso, so you have as one large iso.
3rd - Now you need to create a listing in the cue-sheet like this.
| Code: |
FILE "combined.iso" BINARY
TRACK 01 MODE1/2048
INDEX 00 00:00:00
INDEX 01 00:48:00
|
INDEX 01 needs to be the calculated hours:minutes:seconds of the Sega CD iso (the padded one if modified). The reason why is the PCE system card bios ignores anything in the in the pregap(i.e. INDEX 00) and reads the first sector relative to INDEX 01, but the Sega CD does not and reads from the first sector of the track relative to INDEX 00.
The PCE bios can book a CD from track 1 - shape shifter does this. Matter of fact the PCE bios can boot a CD with the data track being the last track - or any track for that matter. It searchs the TOC for the first data track and compares the first sector to the copyright string in the system card bios( last 2k)., if the first data track fails the check, the system halts.
This 'Hidden track' trick is a totally legal format by REDBOOK and YELLOWBOOK standards. Quite a few audio CD's put hidden tracks in the pre-gap of the first track because there is no limit on the maximum pre-gap size of the first track and most/all CD players start play an audio track from INDEX 01 if selected a track. The only way to listen to the song in the pre-gap is to manually rewind the CD into the pregap. Early PC-CD games used this technique as a copy-protection because most ripping software ignored the pregap of the first track.
If the PCE game layout is set to load from track 2, then do the above mentioned and also put the original PCE iso as track 2. That way the PCE bios will still load the boot code from the first track, but the boot code switches to track 2 to continue the load process. Just make sure the Sega CD doesn't try to play audio from track 2.
Problems that may arise - Some(read: most) PCE games start playing the audio from the absolute sector address of the CD instead of the track number ( Y IV is an exception, I've been told). If you coded the game yourself, this should be an easy fix to recalculate the new audio sector addresses, but if not then you'll have to pad the end of the first data track or locate the cd_audio_play bios function calls and change the absolute addresses.
If you're trying to make just a 'PCE/ISO9660' hybrid cd, then that's a litte different. Let me take a look at the link you provided and I'll post back with some detailed instructions.
OK... here is the problem.
| Code: | 470 00:40F2 loadprog:
471 00:40F2 AD 01 C0 lda ovlentry+1 ; current overlay (as written by ISOLINK)
472 00:40F5 C9 01 cmp #1 ; is it initial overlay ?
473 00:80F7 lbne _init_go ; if not initial overlay, somebody else already
474 ; loaded us completely; do not try to load remainder
475 ; (ie. executing CDROM error overlay)
476
477 00:40FC 64 FC stz <_cl ; initial boot doesn't load complete program;
478 00:40FE 64 FD stz <_ch ; prepare to load remainder
479 00:4100 A9 0A lda #10 ; 10th sector (0-1 are boot;
480 ; 2-9 are this library...)
|
The PCE/hybrid CD loads the HuC boot program just fine with the ISO9660 adjustments. HuC boot program assumes all sector are relative to sector 0x00, but this is incorrect because the file.iso is offset by X number of sectors. In all the images I made, the offset was 0x15 if the file.iso was the first file. Since the program code is not in sector 0x0A but in 0x1F(0x0A+0x15), the boot program will load garbage and crash. I located the string "64 fc 64 fd a9 0a" and replaced 0x0A with 0x1F and.. viola! The program now loads and runs correctly.
Here are the setups I did to get the "PCE/ISO9660" iso file.
1) I renamed the testcd.iso to _boot.iso so it would be placed before all the other files. I used Nero to make a CDROM project with the file _boot.iso, and a few other files.
a) I used the "image recorder" instead of my real burner to make an ISO file of the CDROM project.
2) I opened the new iso file with ultraedit32(hex-editor) and replaced (not added) the first two sectors of the new ISO with the original first two sectors of _boot.iso.
b) I added 0x15 the third byte of the second sector, 0x02+0x15=0x17. I did a search for "64 fc 64 fd a9 0a" and added 0x15 to "0A" as well.
3) And finally, I created a cue-sheet with the track entry
| Code: | FILE "pce_hybrid_cd_alt.iso" BINARY
TRACK 01 MODE1/2048
INDEX 01 00:00:00 |
Note: Do not use a "2:00" second pregap for the first track. The recording software adds one by default. Otherwise you'll get a "4:00" pregap and windows won't read the CD as ISO9660.
Here is a modified example - http://pcedev.net/HuC/huc_test_cd.zip.
-Rich
_________________
www.pcedev.net |
|
| Back to top |
|
|
NightWolve
Elder
Joined: 19 Apr 2002
Posts: 304
Location: Chicago, IL, USA
|
| Posted: Sat Jul 22, 2006 10:53 pm Post subject: Re: COOL |
|
|
| David Shadoff wrote: |
I had created a 'sort of' hybrid CD at one time (oh, about 8 years ago...), with the PCE data track in session 1, and the ISO track in session 2. As I recall, session 1 track 1 needed to be audio too. The PC Engine can only read session 1, so it was great for the real machine, but PC's got a bit confused when emulating.
Actually, I was only able to get this to work on one writer, and not consistently, so I eventually gave up. My original idea was to do this so that the source code could be distributed on the same disc as the game itself, for the real hardcore developers among us. That, and because it's cool.
|
That's pretty cool Dave. That's how CD-EXTRA music audio discs are set up. First session has all the audio tracks and old players will only recognize that, and the 2nd session has the data track which PCs will recognize if your drive has multi-session support of course.
Anyway, Tomaitheous, that is pretty interesting what you're toying with. Interestingly, I learned about the track "indexes" just recently myself btw. In an effort to continue TurboRip's advancement, I began researching this INDEX issue quite a bit with the spare time I found the last couple of weeks. It turns out that the subchannel Q data is what allows for their detection, so no longer will I have PREGAP 03:00 or PREGAP 02:00 hardcoded anymore to create a CUE file upon ripping a disc. That'll make TurboRip more compatible with other game discs that use INDEX 00, 01, 02, etc.
I thought I'd share the full deal on "INDEX" partitions within a track as some might be interested. Basically, you can have 99 tracks and each track itself can have 99 INDEX partitions. INDEX 00 is the Pre-gap, INDEX 01 is what's recorded in the disc's table-of-contents so that's why a Pre-gap would be ignored if we're talking a data track. INDEX 01 is unfortunately the only data recorded on the TOC as I mentioned, so to detect other indexes, you must plan out reading sectors in the most efficient manner. After examining the data structure of how subchannel Q data is returned, I believe the plan is to read the first 300 sectors and the last 300 sectors of each track. If you read INDEX 01 for the start and end computed addresses of the current track you're analyzing, there are none to worry about. In the case of a PC-Engine/TG-16 disc, you'll find that the last 300 sectors will not read as belonging to track 1, but to track 2 and INDEX will be 00, so then you must act accordingly. Discs with INDEX partitions greater than two are rare, but apparently they do exist according to CDRWIN.
It should work out pretty well in the end. TurboRip will have an extra "Subcode analysis" phase and take slightly longer before beginning the ripping process, but it'll be a small price to pay. Well worth it - this Pre-gap/Index stuff really was troubling me. I didn't know whether or not CDRWIN/CloneCD etc. were assuming the industry recommended gap sizes (2 or 3 seconds) or actually detecting this partitioning from the disc itself. It turns out it was the latter. There are 96 bytes of subchannel data before the regularly available 2352 bytes of the sector. It is in those 96 bytes where burners record this index partitioning nonsense.
I swear though, the more I learn about the CD format, the more I appreciate the DVD format and all its simplicity. They eliminated all the bullshit and just basically have one sector type, 2048 bytes in size, one 4 byte CRC32, and that's it! No multi-session nonsense, no partitioning by tracks, indexes, and no ~10 different or whatnot sector types.
_________________
Translation Projects: Xak 3, Ys 4, Ys 1&2 Complete
Boycott XSEED Games! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
