3DO disc structure
Bernd Ohm
Hi,
is there any information about the format (structure)
of the 3DO CD-ROM discs ?
I had a look into some sectors of the disc, which
came with the PANASONIC drive FZ 10. One could read
something like "i am a duck" and so on....
I got the drive for my CD+Gs and not to play game
with it, so it's only curiousity.
until then, BEN
Al Amaloo
b...@ws1.iffr.ing.tu-bs.de (Bernd Ohm) wrote:
Here's all the information I have on the subject. There's a web page
(English) in Japan at:
http://www.keisei.tsukuba.ac.jp/~kashima/games/3do_dir-e.html
that has more information, including programs that will allow a PC with a
SCSI CD-ROM to read 3DO discs. However, if you wish to view 3DO graphics
files, etc, it's much easier with a Mac (through DeBabelizer plug-ins).
BTW, I've seen that "i am a duck" come up on a few different discs.
Perhaps someone that used to work at 3DO can clue us in on the joke.
Have fun...
[The 3DO CD format is] actually a proprietary format called Opera - a
truly interesting CD format developed by Dave Platt at 3DO. [...] What
this means is unless you look at the disc at a low lovel (i.e., direct
SCSI commands to your drive) you're not going to get very far.(1)
It's a hierarchical filesystem format, with some goodies added such as the
ability to include multiple copies of a file or directory in various
locations on the CD (the filesystem picks the closest one during each
read, and automatically switches to alternative copies if a scratch or
fingerprint leaves one copy unreadable).(2)
I wrote a program for my Amiga that allows me to examine the 3DO CD-ROMs
on a sector by sector basis. I've got enough of an understanding of their
file system to poke around into directories and to look at files. I tried
Escape From Monster Manor and I found the maps (or floorplans) for each of
the levels. They're in ASCII format and of course show you the locations
of all the nasties, the piece of the talisman and the exit.
There's directories called Drivers, Daemons, Devices. Folios, Kernel,
Graphics and more. I see OS type programs such as ALLOCATE, CERTIFY,
BANGON, DELETE, DISMOUNT, GDBUG and more. Amiga owners will also
recognize romtags. I've been reading the script files which are
equivalent to the Amiga’s Startup-Sequence or the PC’s autoexec.bat and I
see all kinds of interesting stuff, like a "killprintf" command. I can
see that a program called "LaunchMe" gets called at startup. In EFMM,
this looks to be the actual game code. And... I see strings in it like
"You are in LAYTEST mode. PAUSE button advances level", "Unknown Option",
"Can't prepage for El Kabong", "HEY! How'd you get in here? SECURITY!!"
as well as debug messages about not being able to open/allocate/find
resources.
The guys there have a real sense of humor. The unused sectors are filled
with this pattern: "iamduck". There's even a file named
"LaurieProbstMadeMeUseThis"(3)
A while back I wrote a program that would examine a 3DO disk sector by
sector. I figured out enough of their file system to be able to extract
files and examine them. While looking at the 3DO sampler disk, I came
across an interesting discovery. One of the files seemed to be compiled
with a debug option. This inserted structure, symbol and header
information for use by the debugger. There's a wealth of 3DO operating
system internals there. For instance, sector zero on the disk is a disk
label. Here's what the "Escape from Monster Manor" label looks like in
binary:
000000: 015A5A5A 5A5A0100 00000000 00000000 00000000
000014: 00000000 00000000 00000000 00000000 00000000
000028: 43442D52 4F4D0000 00000000 00000000 00000000
00003C: 00000000 00000000 00000000 176E0E09 00000800
000050: 00038400 12B9969F 00000003 00000800 00000006
000064: 0000004D 0000A407 0001D3E5 0001D3E8 00022DEF
000078: 0002A509 000338C2 00000000
Now, here's the same info using the structure info found in the debug
file:
DiscLabel
dl_RecordType 01
dl_VolumeSyncBytes 5A5A5A 5A5A "ZZZZZ"
dl_VolumeStructureVersion 0100
dl_VolumeFlags 00000000
dl_VolumeCommentary 00000000 00000000 00000000 00000000
00000000 00000000 00000000
dl_VolumeIdentifier 43442D52 4F4D0000 00000000 00000000
00000000
00000000 00000000 00000000 "CD-ROM"
dl_VolumeUniqueIdentifier 176E0E09
dl_VolumeBlockSize 00000800 /* 2048 byte sectors */
dl_VolumeBlockCount 00038400 /* 471859200 bytes on
CD-ROM */
dl_RootUniqueIdentifier 12B9969F
dl_RootDirectoryBlockCount 00000003 /* root block length in
sectors */
dl_RootDirectoryBlockSize 00000800
dl_RootDirectoryLastAvatarIndex 00000006
dl_RootDirectoryAvatarList 0000004D 0000A407 0001D3E5 0001D3E8
00022DEF
0002A509 000338C2
The AvatarList is cool. They spread identical copies of the data all over
the disk so the OS can seek to the closest copy of the data to avoid long
seeks on the CD-ROM.
If we go next to one of the RootDirectoryAvatarList entries, we find the
root of the directory structure. As we see above, it's 3 sectors long.
Here's just the beginning of sector 0000004D:
Root sector
0000: 00000001 FFFFFFFF 00000000 000007BC ................
0010: 00000014 00000002 3977524C 20202020 ........9wRL
0020: 00000800 000000A9 00000001 00000001 ................
0030: 00000000 41707053 74617274 75700000 ....AppStartup..
0040: 00000000 00000000 00000000 00000000 ................
0050: 00000000 00000000 000338DA 00000007 ..........8.....
And decoded we see:
DirectoryHeader
dh_NextBlock 00000001
dh_PrevBlock FFFFFFFF
dh_Flags 00000000
dh_FirstFreeByte 000007BC
dh_FirstEntryOffset 00000014
DirectoryRecord
dir_Flags 00000002 /* 7 for directories, Cxxxxxxx
*/
dir_UniqueIdentifier 3977524C /* for last entry
*/
dir_Type 20202020 " "
dir_BlockSize 00000800
dir_ByteCount 000000A9
dir_BlockCount 00000001
dir_Burst 00000001
dir_Gap 00000000
dir_FileName AppStartup
dir_LastAvatarIndex 00000000
dir_AvatarList 000338DA
I've seen types of "*dir", "font", "cel ", "dsp ", "C6 ", "*lbl" and
others. Now, if we go to sector 000338DA, we find the AppStartup file
which is:
#
# This is the application startup script
#
# This script should contain your aliases
#
# After this script is run, the system will start $boot/Launchme
#
sleep 5
#
Armed with this info, it shouldn't take too long for others to start
looking around to see what's there. Now, for data structures, here's a
very few of what's in there...
Task Node Semaphore MsgPort
t_ThreadTask n_Next sem_bit
mp_Signal
t_ResourceTable n_Prev sem_Owner mp_Msgs
t_ResourceCnt n_SubsysType sem_NestCnt
mp_UserData
t_WaitBits n_Type sem_TaskWaitingList
mp_Reserved
t_SigBits n_Priority SemaphoreP
t_AllocatedSigs n_Flags
t_StackBase n_Size
t_StackSize n_Name
t_regs NodeP
t_sp
t_lk Message Screen
t_pc msg_ReplyPort scr_ScreenGroupPtr
t_psr msg_Result scr_VDLPtr
t_Userpsr msg_DataPtr scr_VDLItem
t_ssp msg_DataSize scr_VDLType
t_Usersp msg_MsgPort scr_BitmapCount
t_Userlk msg_DataPtrSize scr_BitmapList
t_Reserved msg_SigItem scr_SharedList
t_SuperStackSize scr_TempBitmap
t_SuperStackBase MacFileInfo
t_ObsoleteMemProtectBits mfi_Length
t_FreeMemoryLists mfi_Info
t_FolioData mfi_NumEntries
t_FolioContext MacDisk
t_ElapsedTime MacDirectoryEntry mdi_RawDeviceRequest
t_MaxTicks mde_Info mdi_CurrentPathName
t_MaxUSecs mde_Name mdi_DirectoryEntry
t_PageTable
t_ssl
t_UserStackList
t_Flags
TaskP
[...]
There are many many others such as:
Folio, NamelessNode, ItemNode, MemHdr, MemList, IOBuf, IOReq, Timer,
Device, Driver, DeviceStatus, HighLevelDisk, OptimizedDisk, LinkedMemDisk,
FileSystem, OpenFile, BufferedFile, FileIOReq, IoCacheEntry, Stream,
VDLEntry, FontEntry, ScreenGroup, Bitmap, vdl_ScreenPtr, Point, Rect,
GrafCon, Font, FontChar, GrafFolio, MathFolio, JuggleeClass, NoteTracker,
ScoreChannel, ScoreContext, SoundFileBuffer, SoundFilePlayer, AnimStruct,
EventBrokerHeader, EventFrame, MouseEventData, GunEventData,
KeyboardEventData, ListenerList, PodData, PodDescription, FaderBlock,
MIDIFileParser, MIDIEvent, and more and more.
Also, some of the functions I saw are:
AddScreenGroup, ChangeInitialDirectory, DSPGetMaxTicks, EnableHAVG,
FillRect, GetAnimCel, HandleMouse, InitShellGame, KillEventUtility,
LoadInstrument, KillEventUtility, MapCel, NumControlPads,
OpenGraphicsFolio, PathAction, ResetScreenColors, SetFGPen, Triangle,
UnifyAnimation, VRAMTableSearch, WaitIO.
There's many many more of course.
The debug option also inserted the paths to include files ala:
sunshine:SWMC_Library_Files:bezpath
sunshine:SWMC_Library_Files:animstruct
sunshine:SWMC_Library_Files:anim8
sunshine:3DO:Interfaces:1p01C5:Includes:Utils3DO
sunshine:3DO:Interfaces:1p01C5:Includes:Parse3DO
sunshine:3DO:Interfaces:1p01C5:Includes:Init3DO
[...]
Oh yeah, all of the disks that I've looked at have a file named
"signatures". They're all 0x52000 bytes long and they're not identical.
[...](4)
I've found out a little more about the "signature" files. The number of
non-zero entries in the file is the same as the number of used blocks on
the disc. Maybe this is a CRC or some other code used for error
checking.(5)
(1) rec.games.video.3do, agri...@blue.weeg.uiowa.edu (A. Grignon), 18 Jan
1995 00:58:33 -0600
(2) rec.games.video.3do, dpl...@3do.com (Dave Platt), Fri, 20 Jan 1995
00:56:46 GMT
(3) rec.games.video.3do, f40...@fsd.com (D.J. James), Tue, 6 Dec 1994
12:36:12 GMT
(4) rec.games.video.3do, dja...@fsd.com (D.J. James) , Fri, 30 Dec 1994
14:59:18 GMT
(5) rec.games.video.3do, dja...@fsd.com (D.J. James), Sat, 31 Dec 1994
19:33:29 GMT
_______________________________________________________________________
Al Amaloo - The Mining Company: Video Game Strategies Guide
vgstrateg...@miningco.com
http://vgstrategies.miningco.com
Dave Platt
In article <3386d85b...@news.zippo.com>,
Al Amaloo <vgstrateg...@miningco.com> wrote:
>BTW, I've seen that "i am a duck" come up on a few different discs.
>Perhaps someone that used to work at 3DO can clue us in on the joke.
That's my doing. The "iamaduck" pattern is used to initialize all
blocks on the CD which do not contain actual data. It's a personal,
historical homage to my roots.
The first "real" operating system I got my teeth into was a system
called UTS - "Universal Timeshare System". It was a combined batch-
processing and online/interactive OS which ran on the Xerox Sigma
series of mainframes, back in the 1970s. My college had one, and I
had the chance to study it quite closely when I worked for the
Computer Operations division as an operator and as a system programmer
during my last couple of years there.
The UTS (and successor CP-V) operating systems had a very flexible
filesystem (including some features that I haven't seen built-in any
OS I've used since). As with most modern operating systems, the
filesystem code had a fair bit of consistency checking built in - it
could detect corrupted directories, file descriptors, etc. "on the
fly" and prevent further damage to the filesystem data by blocking off
updates to damaged files.
The OS would return an error code to the program using a damaged file,
and would also write a snapshot of the inconsistency information into
an in-memory table for later analysis. In most cases, the system
would recover from the inconsistency... but in really _severe_ cases
of inconsistency, the system would screech (Unix equivalent ==
"panic"), dump all of memory to disk, reboot, and then run an analysis
process.
The in-memory inconsistency log table was preinitialized at boot time
to a recognizable pattern. This made it easy to locate it when
looking at a memory dump - an experience system programmer could tell
at a glance whether there had been any inconsistencies logged, just by
the size of the pattern display in the hex/ASCII dump.
The initialization pattern for the table was the string "IAMADUCK".
When I needed a disk initialization pattern for Opera, I decided to
use that one, as a way of memorializing an OS from which I had learned
so much.
The meta-issue, of course, is "Why did the UTS programmer use
'IAMADUCK' to initialize the 75table?".
I have no idea.
>The AvatarList is cool. They spread identical copies of the data all over
>the disk so the OS can seek to the closest copy of the data to avoid long
>seeks on the CD-ROM.
#grin#. I'm rather proud of this - as far as I know, the Opera
filesystem is the first one to incorporate this sort of application-
transparent redundancy feature.
We took it a step or two further in the later releases of the
Portfolio operating system. As well as having one or more avatars per
file, the disc can also incorporate a "Catapult" file. This file
contains exactly those blocks which are read during the system's
booting process and game startup, in precisely the right order...
they're extracted out of the files' and directories' avatars and
interwoven with a table-of-contents to create the Catapult file. The
selection and interweaving is performed by a mostly-automatic process
when the disc is being pre-mastered. This means that a game program
can open and read literally dozens of different files during game
startup (and can even be reading blocks from two or more files at
once)... and the data's all available from the CD drive as necessary,
with very few head-seeks being required.
This "Catapult" enhancement is part of the reason why the
later-generation 3DO games boot so much more quickly that the
first-generation ones. There were a bunch of other improvements made
in the boot process, as well.
>I've found out a little more about the "signature" files. The number of
>non-zero entries in the file is the same as the number of used blocks on
>the disc. Maybe this is a CRC or some other code used for error
>checking.(5)
Yes, you could say that ;-}
--
Dave Platt Speaker-to-kernels
dpl...@navio.com Navio Communications, Inc.
Visit the Jade Warrior home page: http://iq.navio.com/jade-warrior/
Bill Baker
In article <3386d85b...@news.zippo.com>,
vgstrateg...@miningco.com wrote:
> The guys there have a real sense of humor.
^^^^
"had"
> The unused sectors are filled
> with this pattern: "iamduck". There's even a file named
> "LaurieProbstMadeMeUseThis"(3)
I bet you that file contains a superfluous bit of 3DO trademarking.
Oh well, we had high quality stickers, didn't we? Our brochures were
always printed on heavy bond glossy stock. You can thank Laurie Probst for
that.
I wish I could remember the million-dollar logo story in its entirety.
Suffice it to say that she was yet another management cog burning up a lot
of IPO capital by expanding her little bit of company turf.
The real story to Laurie Probst is her last name. What major 3DO investor
was controlled by someone named Probst?
Al Amaloo
w...@well.com (Bill Baker) wrote:
>In article <3386d85b...@news.zippo.com>,
>vgstrateg...@miningco.com wrote:
>
>> The guys there have a real sense of humor.
> ^^^^
> "had"
>
>> The unused sectors are filled
>> with this pattern: "iamduck". There's even a file named
>> "LaurieProbstMadeMeUseThis"(3)
>
>I bet you that file contains a superfluous bit of 3DO trademarking.
>
>Oh well, we had high quality stickers, didn't we? Our brochures were
>always printed on heavy bond glossy stock. You can thank Laurie Probst for
>that.
>
>I wish I could remember the million-dollar logo story in its entirety.
>Suffice it to say that she was yet another management cog burning up a lot
>of IPO capital by expanding her little bit of company turf.
>
>The real story to Laurie Probst is her last name. What major 3DO investor
>was controlled by someone named Probst?
(Al reveals his answer card)
"Who is Larry Probst (President/CEO Electronic Arts)?"
Did I win final Jeopardy?
Dave Platt
In article <wab-ya02408000R...@208.131.56.3>,
Bill Baker <w...@well.com> wrote:
>> The guys there have a real sense of humor.
> ^^^^
> "had"
Oh, we still do. We just aren't there any more.
Joel Lingenfelter
>Yes, you could say that ;-}
He found the copy protection eh? ...
Nice work, and thanks for your very informative post.
Joel
| Joel Lingenfelter
-=+=-
| Do not conform any longer to the pattern of this world, but be
| transformed by the renewing of your mind. - Romans 12:2a
chuitin
Interesting. Is there any ways to read the CD Sound tracks?
Regards,
CT Yen.
MR_NoBody
Dave Platt wrote:
>
> In article <wab-ya02408000R...@208.131.56.3>,
> Bill Baker <w...@well.com> wrote:
>
> > "had"
>
> Oh, we still do. We just aren't there any more.
>
> --
> Dave Platt Speaker-to-kernels
> dpl...@navio.com Navio Communications, Inc.
> Visit the Jade Warrior home page: http://iq.navio.com/jade-warrior/
First up, nice thread Al Alamoo (What a unusual name, what country are
your parents from).
Sorry, getting off topic.
Speaker-to-kernels (Dave Platt), I bet you had some real cool
programming
knowledge about 3DO, care to share some of strange bugs that popped up,
or some info on great routines you were involved in.
Just Curious!
Neil Stratton
MR_NoBody wrote:
>
> Dave Platt wrote:
> >
> > In article <wab-ya02408000R...@208.131.56.3>,
> > Bill Baker <w...@well.com> wrote:
> >
> > > "had"
> >
> > Oh, we still do. We just aren't there any more.
> >
> > --
> > Dave Platt Speaker-to-kernels
> > dpl...@navio.com Navio Communications, Inc.
> > Visit the Jade Warrior home page: http://iq.navio.com/jade-warrior/
>
> First up, nice thread Al Alamoo (What a unusual name, what country are
> your parents from).
>
> Sorry, getting off topic.
>
> Speaker-to-kernels (Dave Platt), I bet you had some real cool
> programming
> knowledge about 3DO, care to share some of strange bugs that popped up,
> or some info on great routines you were involved in.
>
> Just Curious!
how do you access the memory manager for the fz-1.
one bug is in a game called strall it locks up on one level .
Al Amaloo
Neil Stratton <ne...@nfld.com> wrote:
>how do you access the memory manager for the fz-1.
The FZ-1 doesn't have the Memory Manager in ROM. Try finding one of the
3DO Interactive Samplers (volumes two and later). They have the manager
on their menus. You can also try finding a game that allows access to the
manager. Wing Commander III comes to mind... I'm sure there's a few more.
_______________________________________________________________________
Al Amaloo - Video Game Strategies Guide at The Mining Company
Cheat codes, hints, and FAQs for over 3,400 games - Updated daily
PC, PlayStation, Nintendo 64, Saturn, and other home systems...
http://vgstrategies.miningco.com