Sega Saturn cp talk (Page 2 of 3)

thanks!

yes,
when console boots up saturn will drive laser to this area and do few readings and if it's a backup - will fail.
so this final protection, it's very likely to be somewhere there.
i'm now very sure it's actually this logo, like RPS and few other people said (years ago ). because it's in CAV, this area is unlike the rest of cd.
every track consists of the same amount of frames (tracks do not get longer, closer to outer edge)

Console: SS
Tracks=~1460
FPT=2058 (2058/98=21 sec.) <|Frames Per Track

Console: DC
Tracks=~1226
FPT=1078 (1078/98=11 sec.)

so on backup this logo will never show up. it washes along the tracks and becomes garbage.
so i guess it doesn't matter how you pad it - to get logo, whole data would have to be recreated anyway, based on cd geometry.
would that work? - i don't know, it's unlikely, original is very precise (as can be seen in microscope,
i don't belive anyone could do that without proper hardaware)
maybe offset affects this whole process as well - i'm not sure. if it does, ther's 6 possible ways to pass data to circ
(one is correct, on four other ring will shuffle, like in those images i posted earlier).
and probably contrast on recorded media is too low to see anythig, anyway.
and maybe protection is something else after all...

also what's strange, sector count per track seems very low, compared to what i estimated from empty area. but maybe i made a mistake there.

i only had one DC ring, from European ChuChu Rocket. and it looks to be 1sample off. so you must remove 4bytes from the start of data
to get correct logo. but likely it's also my fault could be a bad dump.

Vigi, could you, please, check your DC rings?

i've uploaded the program here that will do circ delay lines and output ring to ASCII.
http://www.mediafire.com/?4hm1xyvojy2

syntax is:
ring2ascii.bat s 2058 10 RING_data.raw >SSRing
ring2ascii.bat s 1078 10 RING_data.raw >DCRing

i'll try to write something to reconfigure this data depending on cd in next few days,
maybe something shows up, some blured franken-image...

also, maybe new burners could write this logo easy, if you could specify CAV mode and speed,
i think, that's pretty much all there is.

thank you very much, Vigi!

i used Notepad++
it should have monospace font set by default, i think
ther's option to zoom out, under 'View', so you can go all way
it's slow tho, but good for overview

also you can just hit F4 in FAR Manager

..it's stupid, i know, but less coding...

yeah, that's what we do

maybe it's not there, maybe CAV is used only because it's easier to write logo this way
but many people talked about it being logo.
so i want to be sure if we can not draw it - it's ok, but let's check and see.
in a few days we will know, i think

i recalculated sectors per track, and it looks pretty close to CLV. on Saturn logo takes ~3mm (height)
it's about 2..3 sectors per track difference @CLV from top / bottom of logo. for 1400 tracks it's not that bad, i guess.
i'll make circ encoder and i want to to try to draw some cubes and rays and such on cd firs
if it's possible, maybe logo is too.

edit:
oh, sonic's logo start at the same MSF, where ChuChu Rocket, when leading sectors are removed.
and my rocket dump was desynchronized in middle, so thanks. if i can draw those cubes i'll try dc 1st, because it's closer to centre - can do faster.

And why don't you expect it to boot?

thanks, p_star!

it would be too simple...
on those forums ther's at least two people, who knew how this ring is made: Bexster/RPS (i think it's same person) @cdfreaks and HI_Ricky @segaxtreme/assemblergames.
they would have figured it out, i guess.
only way i can now imagine this to pass is if saturn rotates cd at some speed and checks laser wave, e.g. time for how long ther's short/long waves from pit/land blocks assambling logo pattern. but if it does something more - it would not. and i think it does more. pinchy said his cds pass all checks except the last one. and he's very determined it's before ring, maybe it is gap, like you said, after all. like absence of efm in there.
but anyway i won't give up on this until i try 650mb cd with corrected MSF/subchannel, skipped sectors before ring and ring done in several possible ways (scaled/padded etc.)

here i've redone 1st of those programs:
http://www.mediafire.com/?6zwrdyuz9pt
it interleaves/deinterleaves binary data.

i hope to do rest soon.

track pitch is different: ~1600nm on 650; ~1480nm on 700mb cd.
so ther's more 'tracks' (spiral revolutions) on 700. this makes all data compressed.
if logo is made on the same number of tracks it would be more narrow,
positioned @the same LBA as on 650mb cd, physically, on the surface, it will end up closer to the center .
assuming that properties of this area are verified, and we strive to simulate them,
ther's too much uncertainty with 700mb imho.
saturn will read RWs after laser is adjusted. on factory settings they wouldn't even spin up.

it might, the thing is - i don't know , closer it is to original the better

honestly, i haven't noticed, but yeah, looks like ring.
it's d ~44 mm..~46 mm for 'inner buffer zone' and ~46 mm..~50 mm for lead in, i think.
but what makes this thin stripe, i don't know. maybe you can compare it with other pressed cds - pc, audio... (better older)?
i only have those few from saturn atm.

edit:
got my saturn now, tried swapping and it can be done so, that only outer part from the original cd is read.
whatever there is @center, it doesn't matter.

my pc died today...
it was having problems for about last half month.
would not start often and when it did, was going on defaults only - cmos would hang on save.
the week i didn't wrote 15..24 i was replacing cpu, i thought it was l2 cache, but it didn't help.
so finaly today it's stone cold. even bios doesn't beep.
and i can't afford repair or a new one now.

so i won't be able to do anything for a while.
i'm sorry i couldn't finish those programs.

i was writing simulation on pc. the ray, when you supply wrong parameters form curve what's essentially archimedean spiral.
so i thought that would be interesting to experiment with it on pc screen, rather than reburn cds all the time.

to form a ray - it's not hard. all you need is to take start / end radius, track pitch and channel bit size as variables
(width of ray optionally - it's better to start with at least one sector wide and decrease it gradually, as it gets straighter)
and calc rings with incremental circumference from 2*Pi*r. that's what i did, but maybe ther's a better way.

when parameters of given cd are determined you can draw whatever you like in this model, (or realign data / pad / add headers...)
and then run it through deinterleave routine to form an image,
thogh it will always be distorted by some amount, i guess, because it's an approximation after all
and because of the nature how cds work.

i never tested those images on saturn, myself... i sincerely hope somebody will.

hello, RPS! i'm very glad you're here
actually every tidbit of information would be welcome

but so, to be more specific:
basically as i understand this ring with copyright/logo essentially is an area recorded in CAV.
so, how i see it, on ordinary CLV CD pit/land length (T) would stay fixed (with insignificant deviations)
and hence every revolution, from center to outside, would increase in data capacity (by ~35 channel bits).
in CAV on the other hand T is variable that changes so all revolutions hold same amount of data
and pit/land length increases in direction from center to outside.
is this what you meant when you referred to an area with no EFM?
or was it perhaps this transition area (empty zone on microscope image) from ordinary data to ring?
this is what i'm most puzzled about.
also from my understanding, to simulate this CAV layout one would need to keep spindle motor @fixed RPM
(or RPS i can't stop to think your nick actually being a tongue in cheek like humor, excue me if i'm wrong)
maybe you have performed such experiments before?
i'm currently reading book on cd circuits but it's probably years until i get there.
so the plan is to hack drive and get this ring on CD-R in CAV. and in case of positive result proceed further
from there. this ability to recreate ring at will would allow necessary flexibility for experimentation
and improving method and making it more user friendly and possibly simplify it to level
where drive hacking would not be required at all.
other possible outcome - ring recreated in CAV would not work. then i guess nothing would.
but we would have done all we could, at least.

as i understand you have a lot of experience with hardware hacking, maybe you are interested in this yourself?
but if not, could you, please, point in direction, where to look to get it done eg. from firmware, circuit?...

ther's an easy way to tell CAV/CLV data aligment apart by measuring time it takes for optics to position from one sector to another.
i guess this is about what Alcohol does with DPM on. maybe it could be used to get characteristics of spiral from CD-Rs
but probably it's too rough. i haven't got much time to test it myself and i'll be away for about 2 weeks, so i've included sources too:
http://www.mediafire.com/?0joblmsqvl1

for example Dreamcast GD-ROM: (didn't know much about it but being described as CAV on wiki, i thought it's curious)

1st area - regular CLV

linear decrease in delay is clearly visible here (jump @7000, it's drive dropping speed)
this happens, because same amount of sectors in CLV take more revolutions at the center and less towards the outside of CD,
so less mechanical movement is involved to skip same distance (measured in sectors) as radius increases.

2nd area - logo

for CAV it's constant.

3rd area - high density

here change of delay is a lot less obvious than in 1st area, but still present.

it's possible to keep one of sectors fixed instead of distance, so now revolutions become visible:
@the beginning of  3rd area

towards the end

from last two images it's apparent, that sectors per track in this area aren't nowhere close to being constant.
so even though pitch or T is modified, essentially it's CLV.

edit:
fixed download link

Do you have them? I've read on segaxtreme, that KD01 and KD02 won't work on a non-dev console.

there appears to be another value: '*EGAVIEWER' for Photo CDs
though maybe just syntax is alike

edit:
identifier '*EGASYSTEM' is also present in DC System Disc replacing CRC16 & Device Information

edit:
boot process roughly:
- check for 1st instance of '*EGA *EGASATURN ' identifier at user data offset 0 in first 15 sectors
- if present check ring
- if pass carry on with Security Code, Area Code verification
...

minimum to disable further ring checks (like SD does) appears to be pass on 1st two checks
and additionaly properly filled Maker ID & Product Number fields
all the rest can be blank dat - 0x00

also i've tried to replace identifiers with various strings that would yield same CRCs for most common models
and few other things and they wouldn't pass so i'd guess they're actually byte compared for exact match