Sega Saturn cp talk

[themabus]

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.

[themabus]

i finally rewrote those programs. i'm glad i could keep the promise but i'm very sorry it took me so long.

everything is combined in 2 exes: one for interleaving and the other one for recalculating CAV->CLV
http://www.mediafire.com/?nryjjzwv9yx
(please let me know it ther's any problems - still havent tested them much, but i think their fine.)

previously i've tried doing visualisation (on 486 dos machine in vesa ) but it's inaccurate.
either you see very small section of cd close or about 4% approximation. neither is very useful imho.
so instead i've changed algorithm for how spiral is broken into tracks from circles to smaller Archimedes' spirals.
this way parameters tie together much better and deviation on whole spiral length is only few bytes.
so generally no visualisation is required. to calculate arc length i use 1st formula given below,
but it's also possible to use 2nd, it's much smaller and very precise also - only differs by 1..2 bytes from 1st one.

1)
s(r₂) - s(r₁)
              _________                 _________
s = ½ r √1 + (r/a)² + ½ a ln (√1 + (r/a)² + r/a)

2)
s ≈ π (r₂² - r₁² ) / ε

ε = pitch

i've tested about 20 patterns on console (different scaling, sector headers on/off, different sector sizes by headers and so on),
with no results. they all act the same: check boot code, go to ring, return to center, return to ring, fail.
altrough they all were written to same 650mb rw @10x and subcode were not modified, i don't think it would change anything.
it's either just too rough or will not work at all because of different sector amount.

also what's interesting, to do more precise scaling, i've tried to clean up ring data by mapping everything to $59/$a8 patterns,
and it's not possible actually. the thing is - every character in copyright message, it's little different.  similar letters - they just look the same
but are not. so when you have eg. byte $ff right between $59 and $a8: ..$59 $59 $ff $a8 $a8.. you can not tell, should it be $59 or $a8.

OO     OO    OO      O?
OO     OO    OO      O?
OO     OO    OO      O?
OO     OO    OO      O?
OOOOOO    OOOOOO?

this adds yet more variables to the equation...
still i've uploaded it anyway here:
http://www.mediafire.com/?na6oybjaam8
(all non dual pattern bytes were mapped to $ff)

so i think only rational way to recreate this data would be by actually writting it in CAV with constant RPM.
but i don't know is this possible at all. i think it should be, by modding firmware or connecting to spindle motor controller probably.

i'll post on cdfreaks what we have, and will try to ask there. somebody should know.

edit:
i've changed one program a little today. and added brief tutorial.
so now it's very easy to output basic shapes and forms to cd. eg it's possible to draw something simple, like this even in notepad.

Code: Select all

..............0
.000000000000.0
.0..........0.0
.0.00000000.0.0
.0.0......0.0.0
.0.0.0000.0.0.0
.0.0.0....0.0.0
.0.0.000000.0.0
.0.0........0.0
.0.0000000000.0
.0............0
.00000000000000

and you just need to specify how many times to repeat pattern.
but still you need to know parameters of given CD - it's a huge drawback.

[themabus]

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?...

[themabus]

thank you very, very much, RPS!

after seeing your reply, to actually grasp what you said, i had to read through whole book i had.
though, i have to admit, i'm still not exactly sure about fully reflective area,
i think i do have basic understanding now of how this would work in regard of CAV area.
those signals, that could possibly be used for authentication, they can originate in these stages:
1.Focusing - but it's unlikely, i guess. there is no relief changes.
and would there be, they'd have to be distinguished from disc vibration.
2.Autotracking - could be used for reflective area. for CAV it's less feasible,
though a lot would depend on exact implementation.
3.High-Frequency Information Signal decoding - on this stage, when it's being transformed into binary signal,
certain frequency would directly depend on channel bit size, making CAV/CLV differentce unambiguous.
4.EFM demodulation - drive rotation speed is constantly corrected depending on subccode block frequency.
so again CAV/CLV difference manifests in a very blatant way.

so thank you again. though yet lacking confidence to experiment with a hardware,
(still have to read much more...) i do have a clear vision of what to do now

[themabus]

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

[themabus]

on system discs KD01 & KD02

so what matters is valid System ID record in System Area and particularly -
special identifier in it's Product Number field: *EGASYSTEM
everything else - does not.
it can be any track layout, any content - as long as it's valid for Saturn it will function.

Product Number field is where serial usually goes,
so it's possible to change it with hex editor to value mentioned above for any Saturn CD
and it will disable repeated ring checks after 1st validation - just like system disc does - even after reboot.

difference between KD01 and KD02 lies in Maker ID field
it's '*EGA ENTERPRISES' in 1st case - 1st party and '*EGA TP' in 2nd - 3rd party
this is not different from all normal CDs and this value is kept somewhere in memory after 1st validation,
so would you make system disc out of CD with serial T-????? (3rd party) it would function as KD02
system disc made from GS-????? CDs (1st party) would work like KD01
(except that game will still boot - actual system disc does nothing after execution of AIP - cease to function)
there appears to be no further distinction between manufacturers based on company code for 3rd party CDs
so one should work for all.

after System ID record ther's Security Code. it's like always and also Area Code group is unmodified.

and then ther's Application Initial Program for about 2 sectors, i'm not sure what it does
well it displays message on screen and appears to modify fonts, i think, but that's all i could figure
maybe it sets up some additional functions for system disc,
but it appears to play no role in boot process modification whatsoever.

so this special value for Product Number field is interesting.
maybe ther's others? maybe ther's one, that would bypass ring completely?
i'd guess it isn't stored directly for comparation but rather something like checksum would be used.
(as an example: Dreamcast has CRC16 calculated on Product Number+Version stored as an field of System ID)
so if one could figure where this validation takes place,
it should be possible then to determine whether there are any more such magic numbers.

* = S

[F1ReB4LL]

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

[themabus]

only images from UG.
they work but since ring can't be reproduced on CD-R as of yet, you'd need to do swap once - for the 1st time.
i have Japanese console though - i don't know about the others, maybe there is an difference.

[themabus]

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

[themabus]

i wrote summary in 1st post
/viewtopic.php?p=5304#p5304

maybe somebody feels like experimenting with 90 or 99 min CDs?
in a way, depending on which characteristics are evaluated,
they would replicate protection ring with less distortions than 74 or 80 min ones
e.g. 74min CD would gain ~52645 channel bits per 1460 revolutions, while 99min only ~39884 (25% less)
though i don't think Saturn would read 99 at all, maybe 90

i haven't tried any of those myself since there aren't such RWs