12 Aug
2004
12 Aug
'04
2:11 a.m.
here is a "crude" example of what I was talking about.
try:
<archive image file version="1.0">
<definitions>
a place to put whatever relevant information is needed about the format or achive
or your favorite poem or joke
</defintions>
<target system>Tandy Model 100</target system>
<author>Ian Blindly</author>
<media>
<format>5.25" floppy</format>
<default-sector-data value="$AA"/>
<encoding>MFM? RLL? something ... </encoding>
<tracks>35</tracks>
<heads>1</heads>
<sectors size="256">18</sectors>
<wordsize>8</wordsize>
</media>
<datamap>
<head physical="0">
<track physical="0">
<sector logical="1" physical="4" datablock="DB1"
dataitemid="SB1" />
<sector logical="2" physical="8" datablock="DB2"
dataitemid="SB1"/>
<sector logical="3" physical="12" fill="$00"
/>
<sector logical="4" physical="16" fill="$00"
/>
...
</track>
<track physical="1">
<sector logical="1" physical="4" fill="$FF"
/>
<sector logical="9" physical="12" datablock="DB3"
dataitemid="SB1"/>
</track>
<track physical="22" datablock="DB3"
dataitemid="SB2"
/>
</head>
</datamap>
<datablock id="DB1" type="boot">
<dataitem id="SB1" encoding="HEX"
crc="1234">456789ABCDEF...</dataitem>
<dataitem id="SB2" encoding="HEX"
crc="2341">1234567890A...</dataitem>
<dataitem id="SB3" encoding="HEX"
crc="3412">890ABCDEF01245...</dataitem>
<dataitem id="SB4" encoding="HEX"
crc="4123">456789ABCDEF...</dataitem>
</datablock>
<datablock id="DB2" type="OS">
<dataitem id="SB1" encoding="HEX"
crc="1234">456789ABCDEF...</dataitem>
<dataitem id="SB2" encoding="HEX"
crc="2341">1234567890A...</dataitem>
<dataitem id="SB3" encoding="HEX"
crc="3412">890ABCDEF01245...</dataitem>
<dataitem id="SB4" encoding="HEX"
crc="4123">456789ABCDEF...</dataitem>
</datablock>
<datablock id="DB3" type="file" name="DUMP.ASM">
<dataitem id="SB1" encoding="HEX"
crc="1234">456789ABCDEF...</dataitem>
<dataitem id="SB2" encoding="HEX"
crc="2341">1234567890A...</dataitem>
<dataitem id="SB3" encoding="HEX"
crc="3412">890ABCDEF01245...</dataitem>
<dataitem id="SB4" encoding="HEX"
crc="4123">456789ABCDEF...</dataitem>
</datablock>
</archive image file>
please don't get hung up on names, etc, The basic structure is what I have been
talking about. A utility can go into the archive file, find a <datablock>,
know what it is and extract it without having to know anything about the OS. Another
utility can read the media, datamap, and datablocks to re-create tracks in memory
to then write out to disk. There was earlier talk about years from now being able
to still re-create disks. I think that is a fine ambition, but that still requires
all the hardware and intimate OS knowledge to still be around. My idea was to at
least be able to extract the data without having to have ANY knowledge of the OS.
best regards, Steve Thatcher
12 Aug
12 Aug
2:50 a.m.
On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote:
here is a "crude" example of what I was
talking about.
[snip]
That looks good. How's about moving things like author into the
definitions section? I'm not sure that it belongs at the top level, but
more in the section containing archive info (description, creation date
etc.)
I'd suggest making certain fields mandatory in what you've called the
definitions section. People tend to be lazy, which means the temptation
is there to create an archive and not bother to include much of the
information, thinking that they'll know what it is a few years down the
line. We've all be caught out by that one! (author, date, description
are good candidates for mandatory fields; there'll be others too)
I'm not so sure about having the actual data within the archive element;
I'd rather have it afterwards. Data in your datamap section still points
to chunks of data, using whatever scheme is understood by the
storage/compression system used by the archive. But then the possibility
is there for using an encoding method that doesn't mix with XML data if
needs be. It also makes it easy to scan the archive section by eye as
it's not mixed up with huge chunks of encoded media data. Actually, you
could probably build collections of media archives (say for some common
platform) all within the same file that way, without breaking the format
- the data in the datamap section of the first archive section just
points to other archives within the same file. That's kinda neat.
eg. (simplifying a little for example purposes):
<archive image file version="1.0">
<definitions>
... as before ...
</defintions>
<media>
... as before ...
</media>
<datamap>
<head physical="0">
<track physical="0">
<sector logical="1" physical="4" id="DB1" />
<sector logical="2" physical="8" id="DB2" />
...
</track>
</head>
</datamap>
</archive>
<datablock id="DB1" type="boot">
....
</datablock>
<datablock id="DB2" type="boot">
....
</datablock>
.. that way anything following the archive section doesn't have to be
XML data even, providing the definition within the datamap section for
the encoding/compression scheme used by the archive can reach it. It
might be zipped data, other archive definitions, whatever.
cheers,
Jules
4:30 a.m.
Am 12 Aug 2004 11:50 meinte Jules Richardson:
On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote:
Well, in fact it reassembles quite much something I postet some
3 years or so ago on classiccomp (I repost the original definition
in a paralell message - that was the first draft, the actual is a
bit more advanced by now, but I don't have it here at work).
I have been working on that afterwards, but as usual, there where
way moe other things to do, so it faded away a bit. Maybe I should
get finaly my ass moving and post all the stuff on the Website that
I prepared for it some years ago :)
here is a "crude" example of what I was
talking about.
[snip]
That looks good. How's about moving things like author into the
definitions section?
I think such stuff (i.e. basicly everything that is not necersarry
for a narrow minded application which works only on one system
like a reader/writer for Apple DOS 3.3 on an Apple II) should be
optional.
I'm not so sure about having the actual data
within the archive element;
I'd rather have it afterwards.
I would prefer an aproach where both ways are possible, includeing
a third wich allows to put the data even into another file. In the
CCDD definition almost every element (except META) may be empty and
have a HREF attribute pointing to it's content:
A take header record could have it's data included:
<DATA SIZE="80" ENCODING="CHAR" FILLER="
">HDR2U020480204841 00</DATA>
or just point to the data
<DATA HREF="#DB1"/>
<DATA SIZE="80" ENCODING="CHAR" FILLER=" "
ID="DB1">HDR2U020480204841 00</DATA>
which of course may even be in another file:
<DATA HREF="http://cc-archive.org/~hans/mytapes/T43782.xml#DB1"/>
This linking structure was a side effekt from the main goal to define
a XML format, which is not only able to represent the information of
one storage media, but also a storage configuration. And for more
complex configurations it might be useful to have configuration and
media independently defined.
Some may say that configuration is not needed, but then again,
for some applications you have to have several media online
in a certain way, otherwise it won't work (e.g. a programm
disk in drive 1 and a data disk in drive 2).
Furthermore it simplifies the design (and handling) of emulators,
when one can mount a whole set of media in a specific configuration
ar once.
Gruss
H.
--
VCF Europa 6.0 am 30.April und 01.Mai 2005 in Muenchen
http://www.vcfe.org/
12:55 p.m.
On Thu, 12 Aug 2004, Hans Franke wrote:
I would prefer an aproach where both ways are
possible, includeing
a third wich allows to put the data even into another file. In the
CCDD definition almost every element (except META) may be empty and
have a HREF attribute pointing to it's content:
Nononononono (neineineineineineinein).
This would be BAD practice. While I would make the spec allow this, I
would *strongly* discourage it.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
12:33 p.m.
On Thu, 12 Aug 2004, Jules Richardson wrote:
On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote:
I think it's rather premature to be discussing implementation :(
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
here is a "crude" example of what I was
talking about.
[snip]
That looks good. How's about moving things like author into the
definitions section? I'm not sure that it belongs at the top level, but
more in the section containing archive info (description, creation date
etc.) 
5:04 a.m.
How about breaking up the sections a bit, like HTML <head><body> sections?
Putting card-catalog information up top in it's own section would speed
indexing and searches. Like this:
<archive image file version="1.0">
<catalog>
<definitions>
a place to put whatever relevant information is needed about the format or
achive
or your favorite poem or joke
</defintions>
<archiver>Pete Smith</archiver>
<method>ROM Dumper V4.12</method>
<recdate>02004-02-02</recdate>
<title>Omega Race</title>
<author>Midway</author>
<platform>
<mfg>Commodore</mfg>
<system>VIC-20</system>
</platform>
<archivetype>
<fmtcategory>ROM</fmtcategory>
<fmttype>Game Cartridge</fmttype>
</archivetype>
</catalog>
<format>
<default-sector-data value="$AA"/>
....
</format>
<data>
....etc
----- Original Message -----
From: "Steve Thatcher" <melamy(a)earthlink.net>
To: <cctalk(a)classiccmp.org>
Sent: Thursday, August 12, 2004 7:11 AM
Subject: archive file format exmaple
here is a "crude" example of what I was
talking about.
try:
<archive image file version="1.0">
<definitions>
a place to put whatever relevant information is needed about the format
or
achive
or your favorite poem or joke
</defintions>
<target system>Tandy Model 100</target system>
<author>Ian Blindly</author>
<media>
<format>5.25" floppy</format>
<default-sector-data value="$AA"/>
<encoding>MFM? RLL? something ... </encoding>
<tracks>35</tracks>
<heads>1</heads>
<sectors size="256">18</sectors>
<wordsize>8</wordsize>
</media>
<datamap>
<head physical="0">
<track physical="0">
<sector logical="1" physical="4" datablock="DB1"
dataitemid="SB1" />
<sector logical="2" physical="8" datablock="DB2"
dataitemid="SB1"/>
<sector logical="3" physical="12" fill="$00"
/>
<sector logical="4" physical="16" fill="$00"
/>
...
</track>
<track physical="1">
<sector logical="1" physical="4" fill="$FF"
/>
<sector logical="9" physical="12"
datablock="DB3"
dataitemid="SB1"/>
</track>
<track physical="22" datablock="DB3"
dataitemid="SB2"
/>
</head>
</datamap>
<datablock id="DB1" type="boot">
<dataitem id="SB1" encoding="HEX"
crc="1234">456789ABCDEF...</dataitem>
<dataitem id="SB2"
encoding="HEX" crc="2341">1234567890A...</dataitem>
<dataitem id="SB3" encoding="HEX"
crc="3412">890ABCDEF01245...</dataitem>
<dataitem id="SB4"
encoding="HEX"
crc="4123">456789ABCDEF...</dataitem>
</datablock>
<datablock id="DB2" type="OS">
<dataitem id="SB1" encoding="HEX"
crc="1234">456789ABCDEF...</dataitem>
<dataitem id="SB2"
encoding="HEX" crc="2341">1234567890A...</dataitem>
<dataitem id="SB3" encoding="HEX"
crc="3412">890ABCDEF01245...</dataitem>
<dataitem id="SB4"
encoding="HEX"
crc="4123">456789ABCDEF...</dataitem>
</datablock>
<datablock id="DB3" type="file" name="DUMP.ASM">
<dataitem id="SB1" encoding="HEX"
crc="1234">456789ABCDEF...</dataitem>
<dataitem id="SB2"
encoding="HEX" crc="2341">1234567890A...</dataitem>
<dataitem id="SB3" encoding="HEX"
crc="3412">890ABCDEF01245...</dataitem>
<dataitem id="SB4"
encoding="HEX"
crc="4123">456789ABCDEF...</dataitem>
</datablock>
</archive image file>
please don't get hung up on names, etc, The basic structure is what I have
been
talking about. A utility can go into the archive file,
find a <datablock>,
know what it is and extract it without having to know anything about the
OS.
Another
utility can read the media, datamap, and datablocks to
re-create tracks in
memory
to then write out to disk. There was earlier talk
about years from now
being able
to still re-create disks. I think that is a fine
ambition, but that still
requires
all the hardware and intimate OS knowledge to still be
around. My idea was
to at
least be able to extract the data without having to
have ANY knowledge of
the OS.
best regards, Steve Thatcher
1 p.m.
On Thu, 12 Aug 2004, Jason McBrien wrote:
How about breaking up the sections a bit, like HTML
<head><body> sections?
Putting card-catalog information up top in it's own section would speed
indexing and searches. Like this:
It's too early to discuss implementation.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
7266
days inactive
7266
days old
6 comments
5 participants
participants (5)
-
Hans.Franke＠siemens.com -
jbmcb＠hotmail.com -
julesrichardsonuk＠yahoo.co.uk -
melamy＠earthlink.net -
vcf＠siconic.com