Closed GoogleCodeExporter closed 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
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
OK, thanks for taking the time to explain the issue.
Original comment by vaguerant
on 15 Oct 2012 at 7:40
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:
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
Issue 290 has been merged into this issue.
Original comment by ekeeke31@gmail.com
on 19 Oct 2012 at 6:42
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
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
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
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
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
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
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
bug fixed in r848
Original comment by ekeeke31@gmail.com
on 17 Dec 2013 at 4:09
I changed my mind and took some time to implement not only Audio CD but also
CD+G support in r957.
1) For CD+G, you need a .sub file with same basename as loaded CD image file in
same directory.
=> tested fine with Rock Paintings - CD G Sampler and WonderMega Collection
2) For games with Audio CD support (Mode 1), you need a .cue file with same
basename as loaded ROM file in same directory. It also works without .cue file
if the emulator found OGG or WAV files with same basename as loaded ROM file
and track number appended (for example, xxxx-01.ogg, xxxx-02.ogg, etc)
=> tested fine with Flux, Chilly Wiily's Mode1 CD Player, Sonic 1 Redbook hack
and Rock 'n Roll Racing hack
Original comment by ekeeke31@gmail.com
on 31 May 2015 at 6:25
Original issue reported on code.google.com by
vaguerant
on 15 Oct 2012 at 3:45