PCEAdvance CD-ROM support - howto required

[patters]

Does anyone here remember how the CD-ROM support in PCEAdvance is meant to work?

The readme information is not clear enough, and there's no additional readme info for the dedicated EZ-Flash III nor Supercard versions with Super CD-ROM support.
I've tried in vain to dig up stuff from PocketHeaven in the Web Archive but, frustratingly, no relevant threads are archived. There's even a thread 'How to attach and play CD-Rom games for Idiots (FAQ)' visible in the PCEAdvance subforum, but not cached (last thread here).

The issue is that the guide says to concatenate the ISO with the emulator and Super CD-ROM BIOS 3.00. But how would that work - these ISOs are hundreds of megabytes. There's even a worked example in CDfiles/MakeCF2.bat that shows each and every audio track being concatenated to the .gba file. An EZ-Flash IV card can only load a 16MB ROM from PSRAM, and a 32MB one from NOR so I can't see that this would ever be workable. It can't stream the ROM data from the SD filesystem if it's in a .gba file.

I have tried ripping only the data track which usually seems to be track 02 (typically about 15-20MB), but these disc images are normally one Cue file and a Bin file for each track. I used bchunk on macOS to convert from Bin/Cue to ISO (editing the cue sheet so it only lists the one track I'm interested in) but that doesn't seem to work. I'm sure I could get the hang of this if I could find just a single worked example...

There's some suggestion that the EZ-Flash version ought to be able to browse the ISOs from the SD card here, but that sounds more like DLDI style media access that wasn't really a thing until the Nintendo DS:
http://www.racketboy.com/forum/viewtopic.php?p=1107125#p1107082

Should the EZ-Flash version be able to browse the SD card like that? Without a dedicated readme it's impossible to tell. When I boot the CD-ROM BIOS 3.00 rom I get a CD Player-like interface with 16 audio tracks reported, seemingly regardless of whatever I try. Should I even see that if the ISO is correctly added?

This is about all I can find: http://www.racketboy.com/forum/viewtopic.php?t=27197
A guy with the same problem, but no solution.

Someone must remember...

 

[patters]

I get a CD Player-like interface with 16 audio tracks reported, seemingly regardless of whatever I try.

Ok, looking at the source code I see that it includes MusicCD.tcd. Comparing that binary data against the spec in CDfiles/TGCD_Format.txt I see that it is in fact the mystery 16 track audio CD which the BIOS displays when the ISO data has not been recognised.

CDROM_readme.txt states that the .tcd file isn't required, but perhaps this is wrong. Some other header spec documents for other Flubba emulators contain errors (e.g. wrong identifier listed) so this isn't impossible. My experiences would suggest that perhaps the emulator is searching the .gba file for .tcd data and if it finds none it will default to using MusicCD.tcd. Maybe this is preventing my tests from working.

 

[FAST6191]

Never went there myself.

The EZTeam did release an SDK for the EZ3, which would have included NAND access (most would be 1Gbit but there was 2 and 4, possibly also 8 but I am not sure I have never seen anybody with one)
https://web.archive.org/web/20071012062303/http://ezflash.sosuke.com/files/sdkv1.1.zip has the EZ3 SDK if you are really bored. Possibly more relevant would also be https://github.com/ez-flash as they released source code to the EZ3 manager and GBA side code.
https://web.archive.org/web/*/http://ezflash.sosuke.com/files/* has a load of good stuff it seems as well.

I am not aware of similar for the EZ4, nor anybody ever doing anything for that. Similarly I was not aware of supercard getting a version doing anything with the PCE CD, though it would have been theoretically possible. In both cases I am not sure there is enough code to do anything here, give or take what you might backport from lick's RAM API on the DS. The EZFlash team also noted around here somewhere during the earlier days of the Omega/Omega DE that such things might not be possible either as some did express interest in a RAM/storage boost, will have to find the thread.

https://web.archive.org/web/20071011033614/http://www.ndsretro.com/gbadown.html for the sake of more links, in this case should have some stuff on PCE advance. For older stuff then https://web.archive.org/web/20050118011414/http://hem.passagen.se/flubba/gba.html

There was a vanishingly small amount of DLDI homebrew for the GBA (proof of concept pocket nes and save dumper on http://www.chishm.com/ being about the sum total, though I think we saw another thing since).

FluBBa is still around, been doing some nice DS arcade emulators in recent times. https://gbatemp.net/threads/made-a-couple-of-arcade-emus-for-ds.585097/ so you might have some luck asking there, though it is probably still going to be a throwaway mode for a flash cart 15 years ago.

 

[patters]

Thanks for that. My thought was that perhaps the PSRAM (presuming the RAM is mainly what PCEAdvance uses) may work the same on EZ3 as on the EZ4. I seem to recall that QuakeDS used the EZ RAM and IIRC it wasn't fussy about the specific model.

I'm away for the weekend, but I enjoy picking at this kind of problem so I'll try my best before contacting Flubba directly.

I remember trying PCEAdvance back in the day and it really was nowhere near as good as version 7.5 ended up. It's really amazing how close 7.5 came to being full speed. So frustrating that the GBA is just a bit too slow of a system.

As for Flubba, I noticed he's ported this back to GBA:
https://github.com/FluBBaOfWard/SwanGBA

I'll be trying to compile that soon, though I suspect that it will be slow.

 

[FAST6191]

I played with it too, though never the CD aspects. Several 16 bit era games had some really nice versions made for it (bomberman sequels probably being what most would start with there if we ignore the castlevania mob) and as SNES was more proof of concept and megadrive non existent then it was between that and any official ports for games of such a vintage.

I don't think it is RAM boost as much as storage that is the concern (with things measured in gbit of storage you could get stuff done), though the RAM may or may not be used for certain things as part of it (I imagine it is going to be something of a split window/page affair).

Also as quake ds was mentioned then list of things that made use of the extra RAM for the curious there
https://wiki.gbatemp.net/wiki/3_in_1_Expansion_Pack_for_EZ-Flash_V#Third-Party

 

[patters]

I got it working in the end. I figured out the spec for the .tcd files by examining one of the pre-made ones and comparing it to the CD-ROM image. The LBA values can all be discovered by opening the image in Imgburn and examining the Image Information view. They just need converting into hex using a calculator app in programmer mode.

I think my confusion stemmed from how best to extract the data tracks from the CD image. Some bin/cue images have each track as a separate file and some are a single bin file. I had tried a few options, like using the bin file directly, or converting to iso - but I think I had either made separate mistakes, or extracted incorrectly. On Windows, the easiest method is to use IsoBuster and extract the desired track to 'ISO user data'. This converts from raw mode 1 2352 bytes per sector to 2048 bytes - stripping out the CD-ROM error correction data. You can also do this on macOS or Linux using bchunk. Even this is somewhat difficult though. You need to duplicate the cue sheet and delete all the tracks apart from the one you want to extract, then save. Then run:

bchunk track.bin edited.cue extract.iso

If you put the cue first it doesn't work, but it doesn't tell you why.

I found that the various PCEAdvance readme info is indeed accurate. Most games do indeed work without a .tcd file - they're only needed if the iso has more than track 02 and the last track (usually a duplicate of track 02) as data tracks.

Another detail that's not completely clear is that for most games you only include the iso of that track 02 data. The example game with a provided .bat file which is appending many separate tracks is an oddity, and I think they're likely to all be quite small files (I haven't confirmed this yet). It's attaching every odd numbered track, not all tracks as I had mistakenly suggested in an earlier post.

Regular CD-ROM titles work fine, but unfortunately it does seem that the EZ3 build of PCEAdvance will not identify the PSRAM of the EZ4 carts, so no Super CD-ROM titles (with their additional RAM requirements) function on EZ4. Inspecting the source code I can see that file cart.s contains comments that it is enabling and testing the EZ3 PSRAM - confirming my earlier guess that it's only using this additional RAM from the supported carts, not streaming CD-ROM data from storage. I will start a new thread to ask EZ Team if they can see what would need tweaking to get it working in EZ4, once I have uploaded the source to GitHub where it will be a bit easier to link to. For some reason EZ Team published the source for EZ3 and Omega products, but not EZ4, so I doubt even Flubba would be able to support EZ4 without some documentation at least.
EDIT - posted request for EZ4 PSRAM help here

Following on from this tinkering, I have done a ground-up rewrite of the basic Python2 compile scripts which Kuwanger wrote long ago for the EZ4 exit-hacked emulator collection. There wasn't one for PCEAdvance so I had to do some detective work with the Windows builder. My new scripts are Python3 and can work equally well for creating multi-rom compilations (via dragging and dropping files into a command line) and for looping through a folder of ROMs to build separate .gba files for each game. Importantly I have made the PCEAdvance builder able to build .pce ROMs and .iso files equally well.

I will release these cross-platform build tools soon, which saves people from having to create a Windows XP VM just to try out these emulators for GBA.

 

[pinbi7]

@FluBBa still lurks around these parts, maybe he can help out
point you in the right direction

 

[FAST6191]

Found a copy of Lick's RAM API (should do for supercard of the day, m3, g6, opera browser and EZ4, though might not do for all original flavours*). It is for the DS but backporting should be easy enough as if anything the DS' GBA slot access is more limited than what is available in GBA mode. I also imagine the EZ4 stuff is going to be quite similar to the EZ3 stuff (some of the EZ4 stuff in code and hardware being EZ3 with the NAND swapped out for SD and real time clock dropped)

*more the 256Mbit of EZ4 lite deluxe than the limited stuff of the EZ4 lite compact.

 

[FluBBa]

If I had unlimited time to code emulators maybe I would look into supporting EZ4 as well, running PC-Engine CD rom games on the GBA was always going to just be a proof of concept. Using a hacked DSi is soo easy today so that is my main target now, though it is quite easy to back port to GBA when everything is written for DevkitARM.

 

[patters]

Hi FluBBa,

Diminishing returns I know That's why I didn't pester you directly. I had hoped that adding EZ4 compatibility might be some really simple tweak that might be obvious to the eye of the EZ-Team guys if they glance at that source code I linked to.

Anyhow, I have published my Python 3 builder scripts for many of your emulators:
https://github.com/patters-syno/gba-emu-compilation-builders

 

[patters]

I have now realised why I had so much trouble with getting CD-ROM support working at all. The original win32 builder which ships with PCEAdvance actually breaks the CD-ROM support by padding the end of the compilation with 0xFF bytes. But the CD-ROM iso data must start directly after the last ROM. I think if this builder correctly incremented the ROM size in its header than the padding would be acceptable, but it doesn't, so it isn't, and the CD BIOS will always drop to the CD Player screen with the built-in TCD of a 16 track audio CD. This caused all my confusion. When I eventually got it working, it was only with my own Python 3 builder.

 

[hippy dave]

Good job figuring it out!

 

[patters]

Just discovered that you can get all the LBA values for each disc (for making a TCD, which is not normally necessary) directly from https://www.necstasy.net/uk/

You can see that the values for Rayxanber II are consistent with the screenshot from Imgburn which I posted earlier in this thread.

It's probably fairly irrelevant since of all the CD titles I have tried, I think only one needs a TCD - Macross 2036 so that data track 17 can be added. For all the others, simply dumping track 2 as User Data (.iso) using ISOBuster is fine. It's a useful resource for determining which specific type of system is required per title though.