Page 2 of 6

Re: Sega Saturn cp talk

Posted: Fri Jul 11, 2008 3:16 pm
by Jackal
ok.. I suppose 100b is always better than 001b and no real data is lost (only random errors).. so I'll do several 100b sub dumps, and clean those as much as possible

Re: Sega Saturn cp talk

Posted: Fri Jul 11, 2008 3:49 pm
by themabus
ok Image
i've rereaded all discussion yesterday, and i think pinchy said something about subcode acting strange
tho maybe it was somewhere in wip posts and later he could have changed his mind

what i wanted to post on cdfreaks, i got some images from microscope on wednesday
but i'll post them tomorrow, i'm falling apart now Image

Re: Sega Saturn cp talk

Posted: Fri Jul 11, 2008 6:43 pm
by Jackal
Here are the mk2 ring img and sub.. maybe I can still squeeze more sectors out of the cd, but it's gonna be tough...

http://www.speedyshare.com/843465866.html

Here are my first observations:

- Main channel data appears to start @ 297700 (maybe your discs do to if you go back more?)
- I managed to extract 30326 sectors of main channel so far, subchannel a bit less.
- CDReader is good for extracting multiple sectors at once, but it's unable to extract some of the first and some of the last sectors of the area. The D8 command seems more suitable, so maybe Truong can mod cdtoimg so it can extract sector ranges.
- Use px_d8 to read more sectors at the start and at the end (you can append them to the cdreader image using hex editor)
- px_d8 has more trouble reading sectors with subchannels enabled, for example: I can read sector 297700 without subchannels but not with.
- subchannels only contained read errors, no actual protection data (did several 100b extractions at different speeds and it only left me with some random errors at the end).

I'll try installing a different drive tomorrow to get some of the missing subchannels sectors and then construct an image with the unreadable sectors and ring area etc added (hopefully I can make it a burnable image so that someone with a saturn console can try to boot it).

It's possible that the saturns reads this data (at least the main channel), but I don't think it does it right from the first to the last sector, and possibly it only reads the user data.. so as long as the 595959 bytes are present in that range on the CD there's a chance it might work?

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 2:55 am
by themabus
great, Vigi.
i'd like to try, but i can not now. maybe i can fetch cd or two from home later.

i've checked my rings, and ranges above are slightly incorrect - it's what i entered when ripped them, and took note.
but actual data often cuts off sooner and then follow $00 sectors.
i'm not sure was it because drive could not read any more or they were in fact smaller.
tho, i think they were smaller, because otherwise subcode would have been messed up, it's not.

so a brief summary on rings we have so far:
Mortal Kombat II [EUROPE]
297694..328019
Myst [UNK] (from pinchy)
297685..328341
T-7612G [JAPAN] (+subcodes that i had)
298646..328349
T-1505G [JAPAN]
298581..328249
T-15009G [JAPAN]
298649..328124 (followed by zeroes)
T-15025G [JAPAN]
298989..328124 (followed by zeroes)
T-20301G [JAPAN]
298758..328124 (followed by zeroes)
Sega World Wide Soccer '97 [not JAPAN] (from FamilyGuy)
301274..328350 (the range, where data aligned on sector boundaries starts and ends,
but it goes wrong in middle somewhere again (~sector 301511).
this is very strange. probably a 'bad dump')

all rings, except for SWWS'97, when realigned and zero sectors removed, match.
It's possible that the saturns reads this data (at least the main channel), but I don't think it does it right from the first to the last sector, and possibly it only reads the user data.. so as long as the 595959 bytes are present in that range on the CD there's a chance it might work?
i think, it's also pinchy said something similar.
it will not boot, tho. it's that final test that do not pass.
but maybe we can gather more info, like how this image is formed, and what exactly is checked in failed test, and maybe in the end we figure out something.

for example image does not appear on writed cd... why doesn't it? as i understand, ther's 5 possible ways for data to enter circ, when written to cd (i could register on cdfreaks with different username and asked for confirmation on this). so if you burn ring on cd, bytes from sectors would realign in one of those patterns and not neccessarry form writing. but i've tested all those patterns on 650Mb cd-rw (i think i did, i've padded ring data by +1 sample x5 times, maybe it's stupid, actually). i also did tried to check for what i thought would be the best aligments if data would enter circ with step of one byte instead of sample - the pattern that would form most consecutive $a8 (somewhat simulated circ delay lines in software, but this probably was very stupid thing to do), still nothing visible formed on surface. it could be because of much worse refraction of cd-rw, but on the other hand, if you stich togeather sequences of let's say 50mb of $59 / 50 of $a8 and so on, until full size of cd - those rings become clearly visible. but maybe this all just is stupid, and i don't understand how cds work at all... Image

so ok, i'll try to get some cds, and check those ranges. and i'll post those images from microscope later today (checking in matlab now, ther's much noise Image ).

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 7:32 am
by themabus
ok, about microscope data,
i've gave up on matlab... can't convert them to binary images -
ther's too much noise, or i suck @matlab, so i've cut out fragments and converted them to grayscale
>full images are here<
(they cover much larger scale and are uncompressed, so if you find this interesting,
please download this archive instead.)

so i've asked professor from local university, could i take a look at cd with optical microscope
that they have there (Nikon ECLIPSE L150)
and he said ok, and actually was very kind and did most himself, i only got to click mouse few times Image

this is how data loolks x800, near the edge of datatrack. (tracks go verticaly at slight angle)
Image

transition area from data to ring x800
Image

background x800
Image

block, that form letter pattern x800 (it's out of focus and looks like toning in plastic, but no - it isn't)
Image

upper right corner of the same block x2000
Image

zoom in x4000
Image

so it certainly does look like the transition area is empty.
background really is $59 (01011001 |EFM> 10000000000100)

Code: Select all

1000000000010010010000000000100100
___________---___-----------___---
-----------___---___________---___

11T        3T 3T 11T
if there is 11T-6T-11T in bg pattern - it's much more rare, but i could not find one.
(on these photos, i only was for about an hour at microscope so this is all i got)

logo really is made of $A8 (10101000 |EFM> 01001001001001)

Code: Select all

0100100100100100001001001001001000
_---___---___-----___---___---____
-___---___---_____---___---___----
 3T          5T
dsv looks unmanipulated, i think, because on one track same bit can be set with pit->land and
on the other with land->pit change (hece the chessboard look of background).
it's a good thing, i guess.
also i guess this means - every cd would form a bit different drawing - large elements would be the same,
but pit land sequences would be often inverted, because of unique subcode.
on 5th image (pattern x2000), in the upper right corner it does look like T11-T11 sync pattern. so it probably
sync bytes also form radial structures of their own, going across whole ring.
this precision, how one byte ends up atop another on neighboring tracks - this is what's scarry.
i'm not sure how it's happening on cd-r/rw.
it would be interesting to burn ring or just some sequences of $59 and $a8 and take a look on microscope -
how they align, it could be sega's machine manipulated lenght of pits/lands to achive this, but it's a guess.

also, probably it's all meaningless and the last check is not on photos at all. maybe it's something else?
but it's a guess again.
it's, because while taking photos there were actually some spots on plastic, that i thought were a dust but professor,
he was very sure, it isn't. he said it's inside plastic (could be toning). at those places pits looked slightly darker
and out of focuss.
they were round and uniform and about where logo goes (with size of around half of pattern forming block x800),
and i think there was none @segment, without log - wher's just background.
but it's most probably just a fault in production or aging effect. i've found very similar images here: [figure3]
http://www.andraste.org/discfault/discfault.htm
also RPS said something about area with no EFM, and hologram only being used for tracking. and it looks like
he was right about pre-ring, would it be toned plastic - it could probably work, i guess. but to be honest -
i don't quite understand what he said, and am probably missinterpreting.
so anyway, it would be very, very interesting if somebody could examine another cd and confir this true or false.

so if someone can get to microscope at university or lab, please try, ok? Image it's probably enought with about x600.

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 8:40 am
by Jackal
Here's a WIP image..

http://rapidshare.com/files/129135106/mk2.rar.html

mirror: http://www.megaupload.com/?d=JDVYNCDW

- The last sector I was able to read before the ring is sector 297143, so error sectors start at sector 297144.
- Ring is from 297144 - 297699 (possibly the real start is 297150, but there's no way to tell, except maybe a microscope Image)
- Unknown data seems to starts at sector 297700.. so far I managed to read it up to sector 328468, so the size of this unknown data is 30768 sectors.

What's missing:

- A fake TOC file that matches these sector ranges: https://redump.info/disc/2210/
- Subchannels (partial subs from the unknown data range are included in the archive, but since it doesn't contain any protection data I guess the same data is generated during burning, so it should be useless)

How it should be burned (in RAW DAO 96, using a tool that can burn illegal TOCs):

- Sectors 0 - 13536 should be the same as the dump:  https://redump.info/disc/2210/
- Sectors 13537 - 297143 should be audio (all zeroes)
- Sectors 297144 - 297699 should be data (burned as error sectors) or maybe it can be anything
- Sectors 297700 - 328468 should be data too I think (because there's a sync/header..)

It's pretty difficult to get an exact start and end position for the ring and the unknown data area because all drives give different results. But I guess it doesn't have to be 100% exact because the saturn drive propably won't be able to read the first and last sectors of it either.

What we need to find out:

- If the ring and the data after it are always the same amount of sectors and what the correct sizes are.
- If the location of the ring and the unknown data is always the same, or if it can be predicted in any way
- If this data is used for protection (if not, is there evidence of a wobble?)

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 8:54 am
by Jackal
Mortal Kombat II [EUROPE]
297694..328019
Looks like I made an error there? are you sure it starts @ 297694? that would mean that there the ring is 550 sectors long.. could you correct the image that I uploaded plz?

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 10:28 am
by themabus
i looked up by MSF Image it was 66:11:19 in your ring.
ok, i've corrected now image, so i removed some $55 sectors and 1st $59 because it was 66:11:18 this time,
so sector 297694 (66:11:19) is now at it's position, ok?
tho i won't be able to test it - console is away and it's unmoded Japanese anyways Image
but i'll try to get my 650 cd-rws, maybe something shows up

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 3:51 pm
by Jackal
Themabus, here's the first sector after the ring that I'm able to read (plextor reads it @ 297700, and there's no sector offset difference between trap disc > normal disc..) it has some extra bytes before the sync/header so I guess they should be included also?: http://www.speedyshare.com/936172809.html

But you say the MSF indicates that it's sector 297694.. that may be.. but I think this sector really is sector 297700 and it belongs @ offset 700190400?

The reason I 'predicted' the rest of the sector (including the sync/header) before these bytes is that I thought the drive cut off the rest of the sector and the bytes before the sync/header that you see in the file actually belong to a previous sector?

Would be nice if you could upload a fixed image Image

Re: Sega Saturn cp talk

Posted: Sat Jul 12, 2008 6:00 pm
by F1ReB4LL
themabus wrote:tho i won't be able to test it - console is away and it's unmoded Japanese anyways Image
Guess, it must be unmodded in this case.