Page 8 of 8

Re: Questions on writing a new Mega CD emulator

Posted: Sat May 25, 2019 6:59 am
by Sik
Chilly Willy wrote:
Fri May 24, 2019 3:00 pm
I think the primary benefit of an open BIOS for the CD would be to help facilitate CD replacements. The CD drives on these systems are now so old that they're not very good, even when "new". The replacement I got for my CDX is barely any better than the old drive. An open BIOS would allow replacing the drive with something entirely different that still worked at the BIOS level, since I don't know of anything commercial for the CD that bypasses the BIOS. That would allow for competing CD replacements since very few people are up to replacing the CD at the hardware level.
I'd have agreed with you before this thread… but it seems the important CDD commands are exactly the same on all models, so it'd be easier to tackle any such mods at the CDD level (which as a side effect means no need to replace the whole firmware on such a mod). Not like those mods are trivial anyway, having to get rid of a significant part of the hardware.

But yeah, emulators and clones made from scratch (i.e. full reimplementations) would be the biggest ones to benefit from a free BIOS.

Re: Questions on writing a new Mega CD emulator

Posted: Sat May 25, 2019 1:27 pm
by byuu
A reproduction BIOS doesn't need a full audio CD(+G) player interface. It doesn't even truly need a memory save interface (although that would help.) It just needs to run games. Emulators can make per-game backup RAM files. Or for Shining Force CD, backup RAM cart files per-game.

All we really need is the initial boot sequence, followed by whatever BIOS calls that officially released games make. That in itself would be very valuable. From there, add all the features one likes.

I'm sure there are hardware clones of the LC8951 that are still obtainable, so we might as well target that protocol.

The value to emudevs is not needing two codepaths: one HLE, one ... somewhat less HLE (since we don't have CDD firmware dumped.) The homebrew BIOS file lets Sega CD games work out of the box on emulators with nothing but a CD-ROM drive or game image.

Re: Questions on writing a new Mega CD emulator

Posted: Sun Jun 02, 2019 6:32 am
by byuu
I added CDC DMA emulation, but Popful Mail still hangs after the Sega logo (the one after pressing start with the sound effect.)
Both the main CPU and sub CPU are waiting on the other's messages, so a deadlock. Don't suppose anyone else ran into this issue with their emulators?

Also, why does CDD command 3 (seek and play) set the status to playing even while seeking, but CDD command 4 (seek and pause) sets the status to seeking, and then to pause once the seek is completed? Seems counter-intuitive?


This seems a bit strange: ... dd.c#L1917

cdd.latency is checked for null before setting the new latency. So if you wrote a pathlogical program that kept seeking to the start and end of the disc rapidly, the value would keep growing way above the limit.

I imagine this should be removed, and a cdd.latency=max(11,cdd.latency) line should be added after the latency calculation. And it should be there for the SeekPause command as well.

Re: Questions on writing a new Mega CD emulator

Posted: Sun Jun 02, 2019 12:41 pm
by Eke
I already told you (I think at least) but when this was
written, there were barely any documentation about CDD and it was implemented to be mostly optimized while still working fine with all existing BIOS / game software.
CDD emulation code is therefore definitively not accurate to how the real micro-controller and CD mechanism worked and you shouldn't really use it that much as a reference or spend too much time trying to find flaws in this code as I am mostly already aware of all of them. I plan to rewrite it someday now that reference sourcecode surfaced but I have no idea when this will be done as this is not high priority to me and my available free time for coding is barely null these last years (don't make kids, emudevs ;-) )

As for your questions, yes, I am sure status is set to 'seeking' when 0x3 (play/read) command is sent until the needed sector is reached, it's just it was easier to handle it this way in emulator and still worked fine with BIOS (also keep in mind that latency thing was only added later to deal with some specific game issues but initially that command was handled without any delay). The latency check was added to detect the initial spinning latency and I agree it could have been handled better (by using drive status instead) but again it was simpler this way and worked fine with existing software. To be completeley accurate, drive mechanism latency should be emulated for all kind of commands (not just play or seek) and CDD status response timings should be measured on real hardware or copied from official CD drive emulation software.

Re: Questions on writing a new Mega CD emulator

Posted: Mon Jun 03, 2019 2:56 am
by byuu
Sorry, I thought it might be helpful to mention things in case you wanted to work on it again.

I understand, I'll stop giving you grief about it.

Thank you again for your code. Buggy or not, it works, and that's the most important bit. It would have taken me ten times as long if I had to reverse engineer all of this from those documents alone, and likely would have been impossible for me without either.

If you ever get back to the Sega CD, I'd be happy to work with you, but no rush and no obligation. Thanks again! ^-^

Re: Questions on writing a new Mega CD emulator

Posted: Mon Jun 03, 2019 6:30 pm
by Eke
You are welcome. Gens and Picodrive sourcecode were also quite helpful to me when I was trying to figure some of these things or clarify some stuff so I am glad this can be helpful to others in return. That's also why I always try to comment the code as much as possible and indicate stuff that were needed to fix specific games but I guess I could have indicated better when something is not 100% hardware exact or a deliberate optimization/shortcut :oops:

Re: Questions on writing a new Mega CD emulator

Posted: Tue Jun 04, 2019 9:52 am
by byuu
Just for overkill, I thought it'd be fun to support the LC7883KM.
I understand that I'm emulating a DAC when both the input and outputs from the emulation are digital, but this is just for fun.

The chip has pins for:
* SOC1,SOC2 -> clock rate (384f, 448f, 392f, 512f): seems to be fixed at one of these with no software control
* EMPH1,EMPH2 -> de-emphasis mode (off, 44.1khz, 32khz, 48khz): can be configured via serial transfer ($ff8034)
* D/N -> 1 = double-rate, 0 = normal-rate: can be configured via serial transfer ($ff8034) [called "spindle speed", but it's not really]
Also there's attenuation bits for a15-a4, but the manual says a4-a5 are ignored so it's only 10-bits

The normal rate mode performs 8x oversampling at 18-bit precision.
The double rate mode performs 4x oversampling at 18-bit precision.

The normal rate filtering is:
Input -> 43rd-order FIR (unknown purpose) -> 1st-order IIR (de-emphasis) -> 11th-order FIR (unknown purpose) -> 3rd-order FIR (attenuator) ->noise shaper (lower 6 bits) -> Output at 16-bit

The double rate filtering is:
Input -> 1st-order IIR (de-emphasis) -> 43rd-order FIR (unknown purpose) -> 3rd-order FIR (attenuator) -> noise shaper (lower 6 bit) -> Output at 16-bit

Each FIR filter doubles the input frequency rate. So the normal rate output is 44.1khz*8=352.8khz, the double rate output is 44.1khz*4=176.4khz.

The IIR filter for de-emphasis is is a high-shelf filter with a gain of -9.477, a slope of 0.5, and a cutoff frequency of 5uS (3.1KHz) + 15uS (10KHz).
I'm using a biquad filter (second-order, but oh well, I don't have a first-order high-shelf algorithm handy) with arithmetic mean, so (10000+3100)/2.0 cutoff.

I presume the Sega CD will feed this DAC 44.1khz audio no matter what, so setting the 48khz and 32khz de-emphasis modes are just going to adjust the output frequency parameter of the IIR filter, which will basically throw off the coefficient calculations and produce the wrong shelf, which is how I'm emulating it for now.

The manual states the attenuator adjustment is: -20 * log((attenuator & ~63) / 256) dB. I'm not sure how to model that, but (sample*attenuator)/0x4000 seems to produce adequate results, although it may be incorrect. I'm also not clear why one would design a 3rd-order FIR filter to do this attenuation ...? Since 0x4000 is the baseline value at reset, it means we can quadruple the input volume with an attenuation of 0xffff, which would probably be fine given the filters internally work at 18-bit. So if we are outputting in normalized floats, we can then do:
int18 output = (4*sample*attenuator)/16384; return output / 131072.0; //-1.0 to +1.0

The attenuator is adjusted by one for each sample period, persumably one input sample at 44.1khz, which also produces adequately sounding results.

The manual does not say anything about what the 43rd-order and 11th-order FIR filters are for, short of for doubling the sampling rates. Without knowledge of this, modeling this step seems pointless. (I know, this whole exercise is pointless, but its fun to support what we can!)

The noise shaper is used to boost the SNR of the output, but again, the algorithm used is unknown. I don't understand why it's 6-bit when the input at this point will be 18-bit. You'd end up with 12-bit of unmodified input. That can't be right.

Finally, the PDF recommends low-pass filters on the final outputs from the DAC, but I don't know if those are present in the Sega CD, or what their cutoffs would be (but I'd bet money they'd be first-order if they were even there.)

I imagine absolutely none of this aside from just the attenuator is ever going to produce any kind of audible difference in the Sega CD output, but oh well.


Obviously, the WonderMega and WonderMega M2 use different DACs with their own peculiarities, but I'm not as interested in them.

If anyone wants to take this absurd tangent any further, let me know, otherwise I think I'll stop with de-emphasis and the attenuator stepping (hopefully) correctly emulated, and the oversampling and noise shaping omitted.

Re: Questions on writing a new Mega CD emulator

Posted: Tue Jun 04, 2019 10:16 am
by TmEE co.(TM)
The big filters are for bandwidth limiting and are responsible for the characteristics of the passband ripple and whatever goes on in the stopband. This isn't really useful to model, especially since whatever plays the sound will do its own stuff like that, mangling whatever you did (and you need to use some high sample rate also to actually model these things which may not be available on all hardware).
(de)emphasis and attenuator are only things that matter.

Re: Questions on writing a new Mega CD emulator

Posted: Mon Jul 29, 2019 3:14 am
by Sik
I forgot on which of the threads we had discussed this but whatever.

I recall that we discussed that a handful of sectors from the lead-in are actually readable because they end up in the buffers — not enough to build an entire TOC, but a quirk nonetheless. Is it possible to try to peek at the buffers while it's in the "reading TOC" state though?

Re: Questions on writing a new Mega CD emulator

Posted: Sat Aug 10, 2019 1:49 pm
by Nemesis
Unfortunately the data is never passed on when it's in that mode. I'm on my phone and can't look things up properly, but IIRC whichever asic gets the raw data stream from the laser also exposes the TOC data, and it never passes the data on when it's doing TOC decoding. Only way I could get at that data in the MegaLD hardware was to hook the serial data stream with a logic analyzer and decode it in software. I believe the same situation exists on the normal MegaCD from memory.