• From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

1. Physical level.
- Saturn CDs are modified 74min/650MB media.
- roughly in LBA range 297000..297700 there is featureless transition area separating ring from user data.
it's estimated to be about 34 spiral revolutions (for reference - there is no actual spiral there),
but being variable it can also be twice as wide.
- ring itself lasts up until LBA ~328300, spanning approx. 1460 revolutions
it is pressed in such a way that all revolutions in this area contain the same amount of data - parameter is element length,
in contrast to an ordinary CD, where element length is fixed and so data capacity increases a little with every next revolution:
74min: ~36 additional channel bits per revolution
80min: ~34 ...
90min: ~30 ...
99min: ~27 ...
- rings do differ (even though a little) from CD to CD because of variable area width and logical level differences.
2. Logical level.
- 283649 is defined as last sector for user data, so both: featureless area and ring always end up outside TOC
assuming Lead-Out lasts for 6750 sectors, ther still would be sectors left inbetween user data and featureless area
those sectors are filled the same way Lead-Out is - audio silence in main channel, sub-channel continue as Lead-Out
so one can say that Lead-Out lasts up until transition area.
- ring's main channel data, when unscrambled, reveals Sub-Header: 00 00 28 00 and EDC set to 0
Sub-Header Submode byte 28h translates into:
00101000b -> Data = 1, Form = 1 (Form2)
- when left scrambled, main channel user data form patterns consisting of A8h and 59h bytes.
those bytes yield somewhat opposite pit/land sequences:
59h producing long continuous runs, A8h - frequent changes
- when interleaved those patterns form visible inscription: 59h being background and A8h data,
with each revolution taking up exactly 21 sector.
each sector consist from 98 channel frames and ther's 588 channel bits in each frame,
thus on physical level ther's always 21*98*588=1210104 channel bits in this area per revolution.
- main channel ring data is always the same - it can start or cut out little sooner or later but relevant data itself is the same -
those differences that occur do not affect inscription, it's rather an leading/trailing background-only buffer zone.
- ring's sub-channel data is still continuation of Lead-Out with alternating P-Channel, Control set to 0 as for Audio,
TNO set to AAh and MIN, SEC and FRAC referring to Lead-Out's star, so it's slightly different for every CD.
- sub-channel's offset from main channel in ring area would often coincide with that in user data area
but sometimes it would not.
3. Misc notes.
- would ring be recorded on an ordinary CD, padded out by amount of sectors indicated in MSF (~297700),
it would end up then in area with approx. following initial (constantly increasing) channel bit capacity:
74min: 1246019
80min: 1217269
90min: 1160548
99min: 1119495
following approx. sector ranges would be mapped to area with channel bit capacity closest to that of the ring (1210104):
74min: 276463..276485 - it's user data area.
80min: 293255..293277 - range between user data and transition area - Lead-Out.
90min: 331628..331650 - unused sectors - slightly after ring
99min: 364785..364807 - unused sectors - well over 74min CD capacity
would it be padded to position at about the same radius as original,
channel bits per revolution towards the end of ring would reach then approx. following value: 1304069
- to pass System ID check and proceed for ring,
it's sufficient to have Mode1 track with identifier '*EGA *EGASATURN ' at user data offset 0 in one of first 15 sectors.
- to disable further ring checks after 1st pass (a la System Disc),
it's enough to have additionaly an valid Maker ID field and Product Number filled with special identifier '*EGASYSTEM'

* = S
grayed out are unverified hypothetical values
----------------------------------------------------------------------------------------------------------------------
original topic:

if you've read thread on cdfreaks
i have a theory, that most likely i won't be able to verify (so i thought maybe somebody can?)
and i can't register on their forum
is it ok to post it here?

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Registered: 2006-12-24
  • Posts: 3,847

Dreamcast discs have similar rings, Vigi knows better about them smile

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

I do? yikes no, I don't hmm

Are they similar to PSX?

themabus, what do you make of this? - http://forum.redump.org/viewtopic.php?id=3349
xenogears' dumps in the last post should be identical to the other 2, right? or can it be a mastering difference again

  • Registered: 2006-12-24
  • Posts: 3,847

Vigi wrote:

Are they similar to PSX?

PSX doesn't have any rings wink And, IIRC, you've dumped those DC rings and examined the Saturn ones.

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

ok, i'm posting here, thanks smile
Vigi, i think one cd could be the same, other probably isn't
i've posted details in that other topic

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

Ok.. I'm dumping my one and only saturn disc (Mortal Kombat II) with audio trap disc..

do you have any information on the location of the ring?

My disc has readable sectors up to sector ~297000 (666 mb).. but I'm using ddump to skip past the unreadable ones (hope some will be readable after).. and there's no data except zeroes between the end of the game data and the unreadable sectors, so maybe it reached the end of the disc and I'm wasting my time hmm

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

sector range, it's a bit different for every game i tried (not many about 5)
i only have Japanese cds
but i think the sectors you'd get will be always the same.
we could compare crc afterwards.
i dumped with CD Tool, because it does dump subcode
and subcode on ring  so far was always with same offset as on data track.
so it's interesting imo, because it means each ring is different on pit level
and they were most likely generated at the same time when data tracks,
on the same machine (not pre-pressed).

T-15025G
Readable (uncorrected sectors):
Data: 000000..297034 Subcode: 00 02 00..66 02 34
Ring: 298990..330743 Subcode: 66 28 40..73 31 68

T-1505G
Readable (uncorrected sectors):
Data: 000000..297000 Subcode: 00 02 00..66 02 00
Ring: 298583..328251 Subcode: 66 23 08..72 58 51

T-20301G
Readable (uncorrected sectors):
Data: 000000..296994 Subcode: 00 02 00..66 01 69
Ring: 298759..330743 Subcode: 66 25 34..73 31 68

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

oh those unreadable sectors are ok, it's an empty space.
it's possible to wait for very long until reader skips this zone, or just try to hit ring entering range.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

I managed to rip the main channel data, from sector 297704, 30199 sectors long, but the subchannels are giving me problems.. I want to be sure that they don't contain any protection bits, but I can't get them cleaned 100% with cdgtool..  there are always some differences left in the crc bytes.. I already tried 100b and 001b, compared them, etc, but think we'll need a tool that rereads every sector a couple times, like psxt001z --libcryptdrv does...

Have you examined your subs for any possible protection data?

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

no i think i haven't. i havent  thoroughly for sure.
all i can find now on hdd is x4 subs from T-15025G, one sub for T-1505G and one for T-20301G
and ther's two more rings (T-15009G and T-7612G) without subcodes at all

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

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

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

ok smile
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 smile

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

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?

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

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

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 sad ).

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

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 smile

this is how data loolks x800, near the edge of datatrack. (tracks go verticaly at slight angle)
http://img509.imageshack.us/img509/220/datax800gsrj4.jpg

transition area from data to ring x800
http://img515.imageshack.us/img515/8807/transitionx800gsuc7.jpg

background x800
http://img510.imageshack.us/img510/2984/backgroundx800gstv1.jpg

block, that form letter pattern x800 (it's out of focus and looks like toning in plastic, but no - it isn't)
http://img300.imageshack.us/img300/1732/patternx800gsgo8.jpg

upper right corner of the same block x2000
http://img184.imageshack.us/img184/9079/patternx2000gskx5.jpg

zoom in x4000
http://img16.imageshack.us/img16/309/patternx4000gs.jpg

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

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)

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? smile it's probably enought with about x600.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

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 lol)
- 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: http://redump.org/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:  http://redump.org/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?)

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

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?

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

i looked up by MSF smile 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 sad
but i'll try to get my 650 cd-rws, maybe something shows up

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

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 cool

  • Registered: 2006-12-24
  • Posts: 3,847

themabus wrote:

tho i won't be able to test it - console is away and it's unmoded Japanese anyways sad

Guess, it must be unmodded in this case.

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

the thing is, i have saturn only for about half of the year and never tried to rund non Japanese CDs,
but i think you're right. probably it would act different from copy.

Vigi, ok, i'll check you'r sector.
i tried to burn your image yesterday as an audio cd on 650mb rw, so that ther's no need for scrambling.
but nothing is visible, not even change from erroneous zone with $55s to ring. i guess contrast is too low, after all. sad
edit:
oh, ok i did
yes, those bytes, i think they are from previous sector. it's not different from how rest cd is made and so we get
sector with some offset, instead of requested one. but from your cd it looks different, form data track.
it's 222 in db, but here difference is several sectors, i'll have to check my cd's on this again.
so meanwhile i've uploaded you'r MK2 image (from yesterday) here:
http://www.mediafire.com/?81ynydnbmd1



also from image with data block x2000, i'm now almost sure it's sync up there. i belive, little lower,
it's 4 parity bytes, then 12 bytes forming block, 4 parity again...
but ther's no sync formed arrays on data track, so i guess they've manipulated with speed/pit lenght @ring.
i guess it means trying to get visible logo, it's useless - it's not going to happen.
but i think it should be possible to get ring with software, so we would know at least it's properties
and maybe we could synthesize it later on (if sector content does not matter, maybe it's possible?).
...but i'm not even sure, it's logo, that matters, i think that's what RPS said. and he said it's not possible to reproduce
but it's at least interesting to understand 'how?'.

also i got those saturn CDs and will try to check ranges again on d8.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

Vigi, you were right about offset difference on sega logo.
from 6 cds i've checked 4 offsets match with datatrack offset but 2 doesn't.

i've checked ranges and all those rings do end there (4 at the same place, @LBA 328124), right on sector boundary.
then follow some zero sectors, while subchannel is still readable, but soon it runs out.

those zones with background $59 @the start and the end of ring,
i think, they work like a buffer. some cd's have them smaller, some larger - it doe's not matter.

about your Mortak Kombat image: i think, most likely, it does not matter about how sectors are alignet.
laser would seek 297700 (66:11:25) in subchannel and correct itself to locate right sector.
also i think, this change, it does not affect logo pattern (since unit is sector). so, it could be both ways.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • Jackal
  • Moderator (Retired)
  • Online
  • Registered: 2006-12-23
  • Posts: 4,132

With offset difference you mean that MK2 has +222 before ring and +150 (180-30) after?

Anyway, I was thinking.. maybe there are actually some readable sectors inside the ring? is there any way we could check this accurately? (ddump resets the drive after every sector read, I'm not sure if this makes any difference or if other tools do this as well?)

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

i call that logo zone 'ring' smile
i mean when you check that zone for offset, like you do on data tracks, this offset, it sometimes differ from the rest of cd.
like in your Mortal Kombat. it's +222 for data - ok, but i think it should be higher, for ring, because that sector, you uploaded,
it's MSF:66:11:19 (297694), so difference with requested sector 66:11:25 (297700) is 6 sectors and 180 samples
(those preceding 1st sector with header in your dump), but maybe i'm wrong here

about data in this area, i don't think there is any. on microscope photo it's empty, so there cant be full (round) 'track'.
i've found boundaries of this transition zone between data->logo with Truman's 'cdreader' on the same cd, i did microscope readings.
it's exactly 1350 wide. from photos i'd guess it's about 31~32 tracks in there, so 1350/31=~43 sectors per track.
so there is no 43 continuous sectors in there.
when i looked for zone boundaries earlier today, it's quite hard to get there. if you go from e.g. 300000 to 320000
and data ends @328000, laser can often skip past data and will loose track. and it's thousands of sectors.
so i don't think laser would be able to find anything there. though maybe there could be some pattern, that's not read as data at all.
so that would mean Saturn is way different, but on PC i think it's impossible to verify. i think Cdrwin did reading for very long, until
it get past this area, but i would not trust, if it returns anything. probably junk.
it would show on microscope tho smile

also i've run logo sectors data through circ delay lines simulation, and looked for a best contrast by statistics.
(and it's a bit strange actually, it wasn't per sample unit)
i did this before, but now i realigned data in tracks, looking for patterns.
and this is what i got:
http://img183.imageshack.us/img183/1319/segasaturnring1zc6.jpg
http://img244.imageshack.us/img244/301/segasaturnring2rk2.jpg
http://img141.imageshack.us/img141/6532/segasaturnring3gd8.jpg
http://img296.imageshack.us/img296/4370/segasaturnring4yn9.jpg
it's first and last characters of each sentance, later those patterns run onto eachother and become unreadable.
i guess - maybe my circ is wrong. or could be holographic image is made this way? - i would not know.

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website

  • From: Macondo
  • Registered: 2007-08-21
  • Posts: 966

http://img244.imageshack.us/img244/4453/segasaturnringokzp1.jpg
there was an error in circ
i'll post logo details tomorrow

ECMa130 @20091225 :: friidump 0.5.3 :: PSXstuff :: SaturnPrograms :: MyStupidPrograms2 :: MyStupidPrograms

themabus's Website