search

IVBeatz / genplus-gx

Automatically exported from code.google.com/p/genplus-gx
Other
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by vaguerant on 15 Oct 2012 at 3:45

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ekeeke31@gmail.com on 15 Oct 2012 at 7:15

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ekeeke31@gmail.com on 15 Oct 2012 at 7:38

GoogleCodeExporter commented 9 years ago 
OK, thanks for taking the time to explain the issue.

Original comment by vaguerant on 15 Oct 2012 at 7:40

GoogleCodeExporter commented 9 years ago 
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.

Original comment by iceknigh...@gmail.com on 16 Oct 2012 at 10:56

Attachments:

GoogleCodeExporter commented 9 years ago 
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 ?

Original comment by ekeeke31@gmail.com on 16 Oct 2012 at 11:12

GoogleCodeExporter commented 9 years ago 
Issue 290 has been merged into this issue.

Original comment by ekeeke31@gmail.com on 19 Oct 2012 at 6:42

GoogleCodeExporter commented 9 years ago 
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 ?

Original comment by 0vet...@gmail.com on 8 Dec 2013 at 7:41

GoogleCodeExporter commented 9 years ago 
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.

Original comment by 0vet...@gmail.com on 8 Dec 2013 at 9:15

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

Original comment by 0vet...@gmail.com on 8 Dec 2013 at 10:13

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ekeeke31@gmail.com on 9 Dec 2013 at 12:14

GoogleCodeExporter commented 9 years ago 
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)

Original comment by 0vet...@gmail.com on 16 Dec 2013 at 1:09

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ekeeke31@gmail.com on 16 Dec 2013 at 1:45

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ekeeke31@gmail.com on 16 Dec 2013 at 1:52

GoogleCodeExporter commented 9 years ago 
bug fixed in r848

Original comment by ekeeke31@gmail.com on 17 Dec 2013 at 4:09