Questions on writing a new Mega CD emulator

Ask anything your want about Mega/SegaCD programming.

Moderator: Mask of Destiny

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on writing a new Mega CD emulator

Post by Near » Fri May 03, 2019 6:16 am

I don't want to promise the world here, but ... if I can get the Mega CD supported, and I can get all of the requisite information and content to emulate the Mega LD, then I'm all for supporting that as well. I was very happy to learn you were working on preserving those games. I've looked all over Akihabara for them and the only thing I ever found was a LaserActive Mega CD PAC unit.

(I also found a Linguaphone Education Gear, but it wasn't for sale, just to show off.)

As for the Mega CD, I'll take absolutely any information I can get, thank you.
This is my first attempt at CD emulation, and it indeed looks like a really deep rabbit hole.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: Questions on writing a new Mega CD emulator

Post by Eke » Fri May 03, 2019 6:47 am

Wow, this is very interesting piece of information, thank you Nemesis !
I just had a look at segaemu.asm file and it indeed seems to be direct emulation of CDD hardware (maybe more ?), including CDCK/HOCK communication protocol with gate-array, handling of commands, status responses, TOC extraction from SUBQ stream (coming from CD-DSP or simulated ?), etc... very useful to confirm what was already reverse-engineered and fill the missing gaps.

The command codes list matches the one in JVC X'Eye technical manual with two exceptions: it lacks 0xE (pitch control/sound mode) which seems to be X'Eye specific and adds 0xA (Track Skip) which I more or less figured through BIOS analysis (named it "Track Jump" in my code) but didn't really knew why it was sometime sent before SEEK or PLAY command.

The status codes list also lacks one from JVC documentation (0xF - Test Mode) which might be specific and adds 0xD ("Disc In" ?) which I haven't looked yet in provided code (I guess it's a temporary code when a disc is detected, before switching to "read TOC" status)
I should mention, I also know of two people who have a bunch of official docs, containing lots of technical bulletins that have never been scanned/released publicly before.
Yes, in particular, there seems to be a more recent hardware manual but only a few scanned pages are available publicly (https://www.megadrive.org/elbarto/megac ... are%20New/)
I remember there was an user on assemblergames boards that was planning on scanning unpublished stuff (not sure if he had this particular manual though) but the thread has never been updated...
Last edited by Eke on Fri May 03, 2019 8:12 am, edited 1 time in total.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Questions on writing a new Mega CD emulator

Post by Stef » Fri May 03, 2019 8:08 am

Indeed very interesting package Nemesis !
Extracted from equates.asm :

Code: Select all

;drive command nibbles

CMD_NOP			EQU				$0				;nop command
CMD_STOP		EQU				$1				;stop motor
CMD_REPORTREQ	EQU				$2				;change report type
CMD_READ		EQU				$3				;read ROM data
CMD_SEEK		EQU				$4				;seek to a given location
CMD_PAUSE		EQU				$6				;pause the drive
CMD_PLAY		EQU				$7				;start playing from current location
CMD_FWD			EQU				$8				;forward skip and playback
CMD_RVS			EQU				$9				;reverse skip and playback
CMD_TRACKSKIP	EQU				$A				;start track skipping
CMD_TRACKCUE	EQU				$B				;track cueing
CMD_DOORCLOSE	EQU				$C				;close the door
CMD_DOOROPEN	EQU				$D				;open the door

;drive status nibbles

STATUS_STOP		EQU				$0				;disc is set, motor not in operation
STATUS_PLAY		EQU				$1				;data or audio playback in progress
STATUS_SEEK		EQU				$2				;seek operation by read or seek command
STATUS_SCAN		EQU				$3				;skipping to a specific track
STATUS_PAUSE		EQU				$4				;paused at designated track or frame
STATUS_DOOROPEN	EQU				$5				;the door mechanism is open
STATUS_SUMERROR	EQU				$6				;a checksum error occurred during communication
STATUS_COMMANDERROR	EQU			$7				;an invalid command has arrived
STATUS_FUNCTIONERROR	EQU			$8				;some sort of error occurred during command execution
STATUS_TOCREAD	EQU				$9				;TOC is being read at the moment
STATUS_TRACKING	EQU				$A				;currently skipping tracks
STATUS_NODISC	EQU				$B				;door is closed, but cannot focus on disc
STATUS_DISCEND	EQU				$C				;paused in the leadout
STATUS_DISCIN		EQU				$D				;paused in the leadin
STATUS_TRAYMOVING	EQU			$E				;the disc door mechanism is in operation

;drive request format nibbles

RF_A			EQU				$0				;request absolute time
RF_R			EQU				$1				;request relative time
RF_T			EQU				$2				;request track info
RF_TOCO			EQU				$3				;request disc completion time
RF_TOCT			EQU				$4				;request start/end tracks on disc
RF_TOCN			EQU				$5				;request start time of track N
RF_E			EQU				$6				;Error information requested
RF_SUBCERROR		EQU				$E				;had subcode error
RF_NOTREADY		EQU				$F				;not ready to comply with command at the moment

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: Questions on writing a new Mega CD emulator

Post by Eke » Fri May 03, 2019 8:44 am

There are a few interesting defines iib that file, to improve CDD emulation accuracy.

Code: Select all

;;various timeout values

IRQTIMEOUT		EQU		2		;number of ms before HSCK required after IRQ
HSCKTIMEOUT		EQU		3		;number of ms to complete status/command sequence
H2ITIMEOUT		EQU		3		;number of ms to wait for handshake from the IBM
SCANPLAYTIME	EQU		10		;while scanning, play at least this many blocks before seeking again

;constants relating to emulation

TOCTVERSION		EQU		0	;version number to report to a TOCT request

ADJUSTBLOCKBACK	EQU		4	;number of blocks to subtract from seek request to guarantee that the requested block is seen

FWDOFFSETLOW	EQU		100		;low word of number of blocks to skip while in forward scan mode
FWDOFFSETHIGH	EQU		0	;high word of number of blocks to skip while in forward scan mode

RVSOFFSETLOW	EQU		140		;low word of number of blocks to skip while in reverse scan mode
RVSOFFSETHIGH	EQU		0		;high word of number of blocks to skip while in reverse scan mode

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on writing a new Mega CD emulator

Post by Near » Fri May 03, 2019 12:31 pm

Okay, here's my implementation of the graphics ASIC without look up tables.
Many thanks to the Genesis Plus GX code for this.

I feel like there's ways to simplify it more ...

First thought was store a mapMask of 0xffffff when stamp.repeat=0, save the conditional and mask on load from vector table + increment by xstep/ystep, but that messes up the "outside the stamp map" conditional test.

Second thought is that the pixel lookup code is messy.

I wanted something like output = read(index << 8 | xpixel + ypixel * 8), but the way 8x8 tiles are laid out in memory is a royal pain.

I end up with:

Code: Select all

        uint6 pixel = uint3(xpixel) + uint3(ypixel) * 8;
        xpixel = xpixel >> 3 & stampMask;
        ypixel = ypixel >> 3 & stampMask;
        uint4 cell = ypixel + xpixel * (1 + stampMask);
        output = read(index << 8 | cell << 6 | pixel);
Which I *could* compact more, eg uint4 cell = (ypixel>>3&stampMask) + (xpixel>>3&stampMask)*(1+stampMask), but ... it's not like it's a contest to get it into a minimal number of lines ...

Still, it feels like between the >>3&stampMask, the *(1+stampMask), and the cell<<6 ... that we should be able to do this in less operations.
For instance, if xpixel and ypixel were <<6'ed already, the cell<<6 wouldn't be necessary, so maybe {xpixel,ypixel}<<3&fancierStampMask. And then maybe having a different shift amount for the xpixel to skip the *(1+stampMask).

Doing the flip/roll with ~pixel means that we can't pre-mask by stampMask. We could instead say pixel^=mask, but that seems like it'd be worse than just masking off the sixth bit later on.

Well anyway, enough code golf for now.

Full code if anyone were interested:

Code: Select all

auto MCD::GPU::step(uint clocks) -> void {
  if(!active) return;

  counter += clocks;
  while(counter >= period) {
    counter -= period;
    render(image.address, image.hdots);
    image.address += 8;
    if(!--image.vdots) {
      active = 0;
      irq.raise();
    }
  }
}

auto MCD::GPU::read(uint19 address) -> uint4 {
  uint lo = 12 - ((address & 3) << 2), hi = lo + 3;
  return mcd.wram[address >> 2].bits(lo, hi);
}

auto MCD::GPU::write(uint19 address, uint4 data) -> void {
  uint lo = 12 - ((address & 3) << 2), hi = lo + 3;
  mcd.wram[address >> 2].bits(lo, hi) = data;
}

auto MCD::GPU::render(uint19 address, uint9 width) -> void {
   uint8 stampShift = 11 + 4 + stamp.tile.size;
   uint8 mapShift   = (4 << stamp.map.size) - stamp.tile.size;

   uint2 stampMask  = !stamp.tile.size ? 1 : 3;
  uint23 mapMask    = !stamp.map.size ? 0x07ffff : 0x7fffff;

  uint24 x = mcd.wram[vector.address++] << 8;  //13.3 -> 13.11
  uint24 y = mcd.wram[vector.address++] << 8;  //13.3 -> 13.11

   int16 xstep = mcd.wram[vector.address++];
   int16 ystep = mcd.wram[vector.address++];

  while(width--) {
    if(stamp.repeat) {
      x &= mapMask;
      y &= mapMask;
    }

    uint4 output;
    if(bool outside = (x | y) & ~mapMask; !outside) {
      auto xstamp = x >> stampShift;
      auto ystamp = y >> stampShift << mapShift;

      auto data  = mcd.wram[stamp.map.address + xstamp + ystamp];
      auto index = uint10(data >>  0);
      auto lroll =  uint1(data >> 13);  //0 = 0 degrees; 1 =  90 degrees
      auto hroll =  uint1(data >> 14);  //0 = 0 degrees; 1 = 180 degrees
      auto hflip =  uint1(data >> 15);

      if(index) {  //stamp index 0 is not rendered
        auto xpixel = uint6(x >> 11);
        auto ypixel = uint6(y >> 11);

        if(hflip) { xpixel = ~xpixel; }
        if(hroll) { xpixel = ~xpixel; ypixel = ~ypixel; }
        if(lroll) { auto tpixel = xpixel; xpixel = ~ypixel; ypixel = tpixel; }

        uint6 pixel = uint3(xpixel) + uint3(ypixel) * 8;
        xpixel = xpixel >> 3 & stampMask;
        ypixel = ypixel >> 3 & stampMask;
        uint4 cell = ypixel + xpixel * (1 + stampMask);
        output = read(index << 8 | cell << 6 | pixel);
      }
    }

    uint4 input = read(address);
    switch(mcd.io.wramPriority) {
    case 0: output = output; break;
    case 1: output = input ? input : output; break;
    case 2: output = output ? output : input; break;
    case 3: output = input; break;
    }
    write(address, output);
    if(!(++address & 7)) address += (image.vcells + 1 << 6) - 8;

    x += xstep;
    y += ystep;
  }
}

auto MCD::GPU::start() -> void {
  if(mcd.io.wramMode) return;  //must be in 2mbit WRAM mode

  active = 1;
  period = 4 * 5 * image.hdots;
  counter = 0;

  image.address = (image.base << 1) + image.offset;
  vector.address = vector.base >> 1;
  stamp.map.address = stamp.map.base >> 1;
  if(stamp.map.size == 0 && stamp.tile.size == 0) stamp.map.address &= 0x1ff00;  // A9-A17
  if(stamp.map.size == 0 && stamp.tile.size == 1) stamp.map.address &= 0x1ffc0;  // A5-A17
  if(stamp.map.size == 1 && stamp.tile.size == 0) stamp.map.address &= 0x10000;  //    A17
  if(stamp.map.size == 1 && stamp.tile.size == 1) stamp.map.address &= 0x1c000;  //A15-A17
}
...

And here's my attempt at emulating the read latency for word RAM:

Code: Select all

auto MCD::external_read(uint1 upper, uint1 lower, uint22 address, uint16 data) -> uint16 {
  address.bits(18,20) = 0;  //mirrors
  if(address >= 0x200000 && address <= 0x23ffff) {
    if(io.wramMode == 0) {
    //if(io.wramSwitch == 1) return data;
      address = (uint18)address;
    } else {
      address = (uint17)address << 1 | io.wramSelect == 0;
    }
    //VDP DMA from Mega CD word RAM to VDP VRAM responds with a one-access delay
    //note: it is believed that the first transfer is the CPU prefetch, which isn't emulated here
    //games manually correct the first word transferred after VDP DMAs from word RAM
    data = io.wramLatch;
    io.wramLatch = wram[address >> 1];
    if(vdp.dma.active()) return data;
    return io.wramLatch;  //non-DMA accesses respond with the requested data correctly
  }
 ...
}

Code: Select all

auto VDP::DMA::load() -> void {
  cpu.wait |= Wait::VDP_DMA;

  io.active = 1;
  auto data = cpu.read(1, 1, io.mode.bit(0) << 23 | io.source << 1);
  vdp.writeDataPort(data);
  io.active = 0;

  io.source.bits(0,15)++;
  if(--io.length == 0) {
    vdp.io.command.bit(5) = 0;
    cpu.wait &=~ Wait::VDP_DMA;
  }
}
I need to come up with a clean way to signal to any emulated component in the system when a DMA completes, so that I can flush the io.wramBuffer to an invalid value (eg 65537), so that I can then return the open bus input data from the external bus read. Maybe something like vdp.dma.completing() to indicate the last read from a DMA transfer would work.

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on writing a new Mega CD emulator

Post by Near » Fri May 03, 2019 4:45 pm

Could someone with a working Sega CD emulator please share a CDC + CDD command log for booting a game from the BIOS? Just up to the game running its own loaded code would be perfect.

What I see right now is:
CDC: 0xF RESET
CDC: 0xF RESET
CDC: 0x1 IFCTRL
CDC: 0x8,0x9 WA
CDC: 0xC,0xD PT
CDD: 0x0 NOP
CDD: 0x1 STOP
CDD: 0x2 0x4 GetDiscFirstAndLastTracks
CDD: 0x2 0x3 GetDiscTimeInMMSSFF
CDD: 0x0 NoOperation <repeats forever>

The BIOS hangs here at "checking disc".

For the CDD status[0] nibble, I'm returning 0x0 STOP.
For the CDD 0x2 (0x3,0x4) commands I am returning some basic false information: track start=1, track end=1, track length=01:00:00.

I was expecting the CDD to try and do a 0x3 READ command to get the TOC or something.

Speaking of, where exactly is the TOC? If my reading up on CD formats is correct, is this part of the ~150-sector lead-in, repeated throughout it, and something that needs to be recreated from the CUE file? (well, not that we'd have to create the exact bits on the disc, just return the correct information from the 0x2 REPORT commands.)

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Re: Questions on writing a new Mega CD emulator

Post by TascoDLX » Fri May 03, 2019 8:23 pm

Timecode is relative to start of the mandatory data track pre-gap, which also factors into the total time, I believe. So, track 1 start will be 00:02:00, and all subsequent tracks are offset accordingly (+2 seconds).

You are correct that TOC is stored in q-channel within the lead-in. Pretty sure the cd ripper programs that extract subchannel data don't even include this, but that info is stored in the cue file to be recreated.
Last edited by TascoDLX on Sat May 04, 2019 12:30 am, edited 1 time in total.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: Questions on writing a new Mega CD emulator

Post by Nemesis » Fri May 03, 2019 10:25 pm

Speaking of, where exactly is the TOC? If my reading up on CD formats is correct, is this part of the ~150-sector lead-in, repeated throughout it, and something that needs to be recreated from the CUE file? (well, not that we'd have to create the exact bits on the disc, just return the correct information from the 0x2 REPORT commands.)
Every CD image format sucks. This is something you'll learn soon enough. For each "session" on a CD, of which there is only one for MegaCD/LD games, you have a single unbroken spiral of data. In its raw, native format, this consists of 98 frames per sector, with 588 encoded bits per frame, resulting in 57624 bits (7203 bytes) per sector. Something that stores the CD data in this format is the only image format that can truly claim to be a full representation of all the data on the session. If you did this, you'd only need a single file, and no external cue file or anything like that to add context to it. No CD image format exists that stores the data in this way. That said, you'd only need to go to this length if you wanted to be able to accurately store a CD image with all C1/C2 errors intact. The next level down from this that I consider "valid" is to store data with the frames decoded and PQ error correction already performed, but with mode 1 sectors still scrambled and ECC/EDC correction not yet applied, and the subchannel data retained. All that you've done here is to decode the frames, perform C1/C2 error correction, and unpack the contained data in its raw form. This results in 2448 bytes per sector, composed of 2352 bytes of user data and 96 bytes of subchannel data. You'd want all the data, from the start of the lead-in to the end of the lead-out. Nothing can do this either. While there are a few formats that can store the 2448 bytes per sector, absolutely no CD image formats support storing the true lead-in at all. A few support the pre-gap, which is sometimes incorrectly called the lead-in, but it's not, as it comes after the lead-in but before the start of the first track. The lead-in is where the TOC is stored, encoded in the subchannel data. If image formats supported this, there'd be no need for a separate cue file or the like, but there's no way to read that data in its raw form on a PC CDROM drive, which all image formats have been designed down to, so there's no way to store it in common formats. For the MegaLD, I've ripped the true, raw TOC data. This is just subcode data like any other, but for the lead-in sectors. A bigger problem is scrambling though. On the real disk, as per the redbook standard, "mode 1" sectors are stored in a "scrambled" format. Most PC drives perform descrambling automatically, so basically all CD image formats assume descrambling has already been done. On the MegaCD, you can actually take full control of descrambling and do it when you want to, so knowing whether a sector has been descrambled or not is important. The only CD image format I've found for the PC that even supports storing mode 1 sectors in their original, scrambled form is the clonecd image format with a flag in the ccd file, but most programs that use ccd images don't support this flag.

Long story short, you're in for a bit of pain when it comes to CD image formats. Every one of them has its own limitations and sucky issues, and you're going to need hacks around every individual format you add support for to correct assumptions made, and restore missing data. Most CD images won't have any subcode data at all for example (IE, your common bin/cue rips), and you've got to expect all of them store sectors already descrambled. You'll need to therefore be able to regenerate subcode data, and perform scrambling on the input data where appropriate, so you can then descramble it later if required. I'd strongly advise you ignore the abomination that is iso+mp3 though, and never support it. Make the user find at least a halfway decent image file to start with.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Questions on writing a new Mega CD emulator

Post by Sik » Fri May 03, 2019 11:17 pm

I'm gonna laugh if we end up redumping every single CD from scratch using a Mega CD/LD simply because it's capable of dumping all that.
Nemesis wrote:
Fri May 03, 2019 10:25 pm
I'd strongly advise you ignore the abomination that is iso+mp3 though, and never support it. Make the user find at least a halfway decent image file to start with.
Sites have already started to ditch even CUE/BIN in favor of exclusively using CCD at this point. Became a pain when all I wanted to do was to extract a CD audio track from Game no Kanzume vol 1 :​| (since I had no way to mount it directly either and no Mega CD emulator seems to support it yet so I couldn't even check if I was looking at the correct volume)
Sik is pronounced as "seek", not as "sick".

F1ReB4LL
Interested
Posts: 15
Joined: Thu Apr 24, 2008 6:46 pm
Contact:

Re: Questions on writing a new Mega CD emulator

Post by F1ReB4LL » Fri May 03, 2019 11:55 pm

Nemesis wrote:
Fri May 03, 2019 10:25 pm
The next level down from this that I consider "valid" is to store data with the frames decoded and PQ error correction already performed, but with mode 1 sectors still scrambled and ECC/EDC correction not yet applied, and the subchannel data retained. All that you've done here is to decode the frames, perform C1/C2 error correction, and unpack the contained data in its raw form. This results in 2448 bytes per sector, composed of 2352 bytes of user data and 96 bytes of subchannel data. You'd want all the data, from the start of the lead-in to the end of the lead-out. Nothing can do this either.
Plextors allow to read the lead-in area (with certain nuances) and any drive with the overreading into lead-out capability also allows to read the lead-out area, so, technically, it is possible to read all the data. Saturn and DC protection rings are also readable. The only problem is that it's hard to get consistency on the 'borderland' sectors, the ones that are very close to the end of lead-out or to the protection rings are only readable once per xx attempts. Also, the drives with more powerful lasers can sometimes get a few more of those sectors compared to the ones with less powerful heads.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: Questions on writing a new Mega CD emulator

Post by Nemesis » Fri May 03, 2019 11:59 pm

I'm gonna laugh if we end up redumping every single CD from scratch using a Mega CD/LD simply because it's capable of dumping all that.
It's probably going to happen actually. The work that's been done with the Domesday Duplicator (https://www.domesday86.com/?page_id=978) I expect will probably precipitate some serious work on re-imaging CDs that have been done up till now. They've recently got working CD demodulation and decoding from the raw RF signal from the laser pickup. That allows you to capture those 7203 bytes per sector rips I talked about, which is really the only complete, true preservation format for CD image data. The catch is, a disk will never rip with the same data twice. You can rip the same CD five times on the same drive and you'll get back differences each time. That's because there's a lot of inherent error in both the reading and the mastering process for CDs. The purpose of all those extra bits is to add error correction to allow the inevitable glitches to be error corrected. That makes it hard to verify rips. It is still possible to fix this though. If you can get three or more rips of each disk (preferably more like five or six), you can reconcile these errors and cancel them out, to get a true image of the disk as it really is, apart from surface damage or smudges on the disk surface that are interfering that is. If you can get three or more cleaned up rips like this from disks that have been pressed from the same master, you can then cancel out mastering errors from the individual presses too, building an accurate image of the original master, which will itself contain errors, but those are true errors from the factory, so in a preservation format like that you should preserve them.

Although I can't get a rip like that from the MegaLD hardware, I've done some of this error correction stuff already, as subcode data has no additional error correction, so you always get errors in that. I rip subcode data a dozen times or more to correct the errors, then merge and reconcile between multiple disks where I have them. Sites that work on preserving accurate images will need to change to base themselves around multiple submissions, with a goal to get three or more cleaned rips from different sources, in order to build a single cleaned master CD image. With how active some of these communities are, I expect that kind of thing will be happening in a few years time.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: Questions on writing a new Mega CD emulator

Post by Nemesis » Sat May 04, 2019 12:05 am

F1ReB4LL wrote:
Fri May 03, 2019 11:55 pm
Nemesis wrote:
Fri May 03, 2019 10:25 pm
The next level down from this that I consider "valid" is to store data with the frames decoded and PQ error correction already performed, but with mode 1 sectors still scrambled and ECC/EDC correction not yet applied, and the subchannel data retained. All that you've done here is to decode the frames, perform C1/C2 error correction, and unpack the contained data in its raw form. This results in 2448 bytes per sector, composed of 2352 bytes of user data and 96 bytes of subchannel data. You'd want all the data, from the start of the lead-in to the end of the lead-out. Nothing can do this either.
Plextors allow to read the lead-in area (with certain nuances) and any drive with the overreading into lead-out capability also allows to read the lead-out area, so, technically, it is possible to read all the data. Saturn and DC protection rings are also readable. The only problem is that it's hard to get consistency on the 'borderland' sectors, the ones that are very close to the end of lead-out or to the protection rings are only readable once per xx attempts. Also, the drives with more powerful lasers can sometimes get a few more of those sectors compared to the ones with less powerful heads.
Actually, from what I've seen, the purported reading of the "lead-in" area on Plextors is just the "pre-gap", not the true lead-in. That term is usually mis-used by both users and software in the PC space. There's no way to instruct a PC drive to seek to the lead-in area, just the pre-gap. You can read into the lead-out on a lot of drives though.

The Saturn protection ring can't really be "read" in the traditional sense, as the key on that protection mechanism isn't a data issue, it's a geometric one. Normally data is written to the CD surface in a smooth spiral. For the Saturn copy protection, they "wobbled" the laser as it cut the track. The low-level CD hardware on the Saturn is still able to follow this spiral, but it reports the tracking error information as it goes, and the copy protection requires to "see" this wobble occur in order for the protection to pass. Getting a full data rip wouldn't help with that, you need geometric information to go with it. You'd need some geometric info for multi-session CDs for full preservation too, to report the physical location of the sessions on the physical CD surface, but tracking the wobble is next level above that.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: Questions on writing a new Mega CD emulator

Post by Nemesis » Sat May 04, 2019 12:08 am

I'll add that you're right though, the lead-in and lead-out areas "degenerate" towards the edges, as the laser power level drops from the writing process. For the MegaLD images, I'm reconstructing the full data to the edges from the known data before it starts fading.

Near
Very interested
Posts: 109
Joined: Thu Feb 28, 2008 4:45 pm

Re: Questions on writing a new Mega CD emulator

Post by Near » Sat May 04, 2019 5:49 am

You are correct that TOC is stored in q-channel within the lead-in. Pretty sure the cd ripper programs that extract subchannel data don't even include this, but that info is stored in the cue file to be recreated.
So then as I presume the Mega CD BIOS expects to be able to read the raw TOC data, it would be nice to be able to recreate it, even if presently we have to HLE the CDD that reports on what it says. I don't know the format, though.
The only CD image format I've found for the PC that even supports storing mode 1 sectors in their original, scrambled form is the clonecd image format with a flag in the ccd file, but most programs that use ccd images don't support this flag.
Well, you know me (probably, anyway.) I've already dealt with this and the unacceptable way Famicom Disk Images are currently stored, I'll handle this the same way.

I'll support a new image format that contains all data: lead-in, pregap, postgap, lead-out, subchannel data, etc in scrambled form.

Understandably we can't yet (or possibly ever) create images in this format, but like with FDS, I can write code that "imports" a Mega CD image from a variety of lossier formats by trying to parse cue sheets, rescramble data, etc. I'll store data at 2448-bytes/sector. The raw channel frames is kind of pushing it.

I get that the data won't be guaranteed to be accurate when it's not truly ripped from the original CD, but in this way, I can *support* a proper rip in the event that it ever becomes possible now, and the emulation core only has to implement one format instead of 30 formats.

Conversely, people are going to lose it when they find out higan expects them to import entire CDs to play their games. But I think it's too complex to have the emulation core have to support every image format on the planet and to generate the data dynamically.

It sounds like you know what you're doing, so if I can get the Mega CD emulated, I'll defer to your advice on a Laserdisc image format to support.
I'd strongly advise you ignore the abomination that is iso+mp3 though, and never support it.
I have zero plans to support lossy audio formats, no worries.
I'm gonna laugh if we end up redumping every single CD from scratch using a Mega CD/LD simply because it's capable of dumping all that.
That's gonna get real expensive, real quick with the high and rapid failure rate of Sega CD hardware.

Nonetheless, I'm here in Akihabara for another two years so if folks want, I can start buying up all the Japan-market Mega CD games I can get my hands on. It's already very hard to find the games here, though. Usually only ~10-20 games per shop and almost all of them are the same exact ones (HKB, Sangokushi, etc.)
There's no way to instruct a PC drive to seek to the lead-in area, just the pre-gap. You can read into the lead-out on a lot of drives though.
If nothing can read it, is the TOC binary format encoded in the lead-in Q-channel even known at this point? ._.

...

As to the wobble, yeah I have no idea how one would preserve that. I kind of feel like we should give in at that point and just store whatever data can be extracted from the wobble sections as a separate file. Or worst case, just fake it out in the emulation of the BIOS / drive controller emulation. It's just getting to be too much to try and encode the physical properties of the disc spiral.

A raw channel frame CD is already bordering on 2.1 to 2.5 gigabytes of information.

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Re: Questions on writing a new Mega CD emulator

Post by TascoDLX » Sat May 04, 2019 6:32 am

byuu wrote:
Sat May 04, 2019 5:49 am
If nothing can read it, is the TOC binary format encoded in the lead-in Q-channel even known at this point? ._.
http://www.13thmonkey.org/documentation ... c3r10g.pdf
see pdf page 63

Post Reply