Support for loading bin/cue audio CDs (for Flux/Mega-CD BIOS)

[Former user]

Original issue 287 created by vaguerant on 2012-10-15T03:45:43.000Z:

I saw in the readme that genplus-gx supported running Flux with Mega-CD hardware and was interested in trying it out, but after ripping a couple of audio CDs to bin/cue, I wasn't able to load them alongside Flux. The ROM itself loaded fine and went through the intro animation, but after returning to the emulator menu to "insert" a disc, the emulated system simply blackscreens on resume.

The emulator itself doesn't crash, and the menu can be returned to, different games loaded, etc. It seems to simply be a matter of audio CDs not being supported.

Obviously, genplus-gx is not intended as a CD player and it's highly impractical anyway since discs need to be backed up before they can be used, so I fully understand if this is simply outside the scope of the project, just thought it might be worth noting now that CDDA is supported for games.

[Former user]

Comment # 1 originally posted by ekeeke31 on 2012-10-15T07:15:38.000Z:

Well, it *should* in theory be working, just that i didn't go through the hassle of dumping my audio cd to test it.

The thing is, disc swap requires that the game (or program) send an "OpenTray" command so the emulator can detect virtual disc tray is opened and do not load the CD image as usual (i.e resetting the virtual system).
- in Flux, this can be achieved by pressing B anytime in the visualisation screen, load the disc image through emulator menu, return to game then press B again to make the game close the tray and start detecting the disc.
- in Wonder Library, you need to press C when the red disc icon starts blinking then C again after you loaded the disc image.

Note that system still reset when you do that, it might be because the BIOS did not send the "Open Tray" command, you might want to try with another bios. I should also probably make the wii disc led glowing when the virtual disc tray is opened, that could be useful to know when you are supposed to load another disc. If the system does not reset but that still does not work ( i.e CD is not detected) well then we are out of luck.

Another possibility is to use an undocumented feature of the emulator to make it automatically loads an associated CD image when a ROM that is known to support CD hardware is being loaded. You will have to rename either your .bin file to xxxx.iso where xxxx is the filename of the ROM, without extension (Flux for example). I implemented this initially for a certain game that uses the CD hardware but only use the CD data track, not audio track, so .iso came logically, but since the emulator does not care about extension when loading a CD image and is perfectly able to detect BIN images, changing its extension should not matter. Just make sure .cue file is named the same as the ROM and CD bin files (xxxx.cue) so it can also be automatically loaded when the .bin is loaded.

[Former user]

Comment # 2 originally posted by ekeeke31 on 2012-10-15T07:38:02.000Z:

hmm, forget about that, it won't work because audio CD does not have any data track so won't be recognized as valid Sega CD image.

the emulator expects the first track to be a data track and getting around that just to be able to load any cd would be far too much work ( basically rewrite the whole CD Drive emulation from scratch), for very little benefits.

[Former user]

Comment # 3 originally posted by vaguerant on 2012-10-15T07:40:01.000Z:

OK, thanks for taking the time to explain the issue.

[Former user]

Comment # 4 originally posted by iceknightmail on 2012-10-16T10:56:13.000Z:

That's a shame... and it also rules out the possibility of CD+G support, which I was going to suggest. Oh well.

What I don't understand is why the emu also fails to load NeoGeo CD rips when the tray is open, when those also have a first track with data. If you try loading the CUE, it says "Loading 2098 bytes", then resets and goes to a black screen (as if it had loaded a ROM instead), and when you load the IMG it says "File is too large".

Not that I need to load Neo Geo CD images in an unrelated emulator, but just in case it could be relevant.

[Former user]

Comment # 5 originally posted by ekeeke31 on 2012-10-16T11:12:48.000Z:

You like to try weird thing, don't you ?
The reason is obviously that neocd images are not valid sega cd images.

Emulator expects a valid sega cd id string at the start of cd image file, if it doesn't find one, it assumes the file isn't a cd image and therefore a ROM. This is used to detect between iso and bin images, because, by experience, file extension is not reliable, but also to distinguish .bin ROM files from CD image files.

Implementing support for any kind of CD including audio CD or CD-G is off course possible but what is the point of spending countless hours of coding when it's gonna be used maybe one time (to try it) by two people then never used anymore when you realize it's not really fun or practical. What's next ? Karaoke module with Wii microphone ?

[Former user]

Comment # 6 originally posted by ekeeke31 on 2012-10-19T18:42:30.000Z:

issue #290 has been merged into this issue.

[Former user]

Comment # 7 originally posted by 0vetal0 on 2013-12-08T19:41:35.000Z:

Is there any chance you change your mind and implement "mode1" support ?

I've tryed Rock'n'Roll Racing hack https://dl.dropboxusercontent.com/u/41545394/games/SegaCD/Rock_n%27_Roll_Racing_Hack_v15_alpha_r6.bin
with modifyed ROM header to "FLUX", and SegaCD image (Heart of Alien) named as game rom.
Emulator recognises rom as mode1-compatible, loads CD-image, but crashes after a short time.
Slave's M68K PC becomes 0xffffffff for some reason after reset and m68k_read_immediate_16(pc) made Access violation.
Is there any way to avoid this ?

[Former user]

Comment # 8 originally posted by 0vetal0 on 2013-12-08T21:15:38.000Z:

add:
"Sonic with Redbook audio" hack crashes emulator in the same way, but Chilly Willy's "Mode1 Player" works fine, except 1st track cant be played.

[Former user]

Comment # 9 originally posted by 0vetal0 on 2013-12-08T22:13:50.000Z:

oops, my bad, those hacks works only with Japanese BIOS.
but anyway, AppCrash must not happen ;)

[Former user]

Comment # 10 originally posted by ekeeke31 on 2013-12-09T00:14:24.000Z:

1) crash happens because slave CPU is trying to execute code from unmapped memory

see this line in scd_init function, scd.c:
s68k.memory_map[0xff].base = NULL;

crash could be avoided by setting the pointer address to some dummy buffer but the thing is, running code from this area will likely cause a crash on real hardware too since this is either PCM area, CD register area or unmapped area, causing either exception because of lack of valid 68k instructions, or simply lockup because of undecoded address.

2) having a PC value set to FFFFFF can be avoided by fixing bugs in the ROM hack, it means that PRG-RAM was not properly initialized with decompressed Bios when slave 68k was resetted so invalid PC value is fetched. The reason is probably the program assumes the compressed BIOS to be at some hard-coded location. Chilly Willy's program probably support various different BIOS...

3) adding support for Audio CD is a lot of work because my implementation expects the first track is a valid Mega CD data track and is built around that. All that need to be changed (cue file handling, cd track handling,...) should be located in cdd.c so feel free to submit a patch, I personally don't have the motivation to rewrite it for now.

[Former user]

Comment # 11 originally posted by 0vetal0 on 2013-12-16T13:09:49.000Z:

okay, I'll do it by myself, actually its implemented already but need more tests and a bit cleanup, I'll submit then it will be ready.

meanwhile real bugs:
scd.c, void scd_reset()
/* H-INT default vector */
*(uint16 *)(m68k.memory_map[0].base + 0x70) = 0x00FF;
*(uint16 *)(m68k.memory_map[0].base + 0x72) = 0xFFFF;

I have not idea what it for, but it destroy HINT vector in Main M68K space (scd boot rom or cartridge rom in mode1)

[Former user]

Comment # 12 originally posted by ekeeke31 on 2013-12-16T13:45:30.000Z:

It's not a bug, MAIN CPU level 4 interrupt vector is actually handled by Mega CD ASIC. Lowest 16-bit must be initialized by writing value to register $A12006. This is normally initialized by Boot ROM before enabling HINT.

[Former user]

Comment # 13 originally posted by ekeeke31 on 2013-12-16T13:52:28.000Z:

Hmm, actually disregard what I said, there is indeed a bug with the way this is handled when using Mode 1.

It should only affects Boot ROM and not cartridge ROM so the correct code is:

*(uint16 *)(m68k.memory_map[scd.cartridge.boot].base + 0x70) = 0x00FF;
*(uint16 *)(m68k.memory_map[scd.cartridge.boot+].base + 0x72) = 0xFFFF;

Also needs to be corrected in mem68k.c

Thanks for the notice.

[Former user]

Comment # 14 originally posted by ekeeke31 on 2013-12-17T16:09:56.000Z:

bug fixed in r848