From melamy@earthlink.net Thu Aug 12 06:11:18 2004
From: melamy@earthlink.net
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 06:11:18 +0000
Message-ID:
<20568369.1092309078565.JavaMail.root@grover.psp.pas.earthlink.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0958180684161092182=="
--===============0958180684161092182==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
here is a "crude" example of what I was talking about.=20
try:
a place to put whatever relevant information is needed about the format or=
achive
or your favorite poem or joke
Tandy Model 100
Ian Blindly
5.25" floppy
MFM? RLL? something ...
35
1
18
8
456789ABCDEF...
1234567890A...
890ABCDEF01245...
456789ABCDEF...
456789ABCDEF...
1234567890A...
890ABCDEF01245...
456789ABCDEF...
456789ABCDEF...
1234567890A...
890ABCDEF01245...
456789ABCDEF...
please don't get hung up on names, etc, The basic structure is what I have be=
en=20
talking about. A utility can go into the archive file, find a ,
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 me=
mory
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 req=
uires
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
--===============0958180684161092182==--
From julesrichardsonuk@yahoo.co.uk Thu Aug 12 06:50:47 2004
From: julesrichardsonuk@yahoo.co.uk
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 06:50:47 +0000
Message-ID: <1092311446.10829.52.camel@weka.localdomain>
In-Reply-To:
<20568369.1092309078565.JavaMail.root@grover.psp.pas.earthlink.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1992206018996863280=="
--===============1992206018996863280==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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):
... as before ...
... as before ...
....
....
.. 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
--===============1992206018996863280==--
From hans.franke@siemens.com Thu Aug 12 08:30:07 2004
From: "Hans.Franke@siemens.com"
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 08:30:07 +0000
Message-ID: <411B8CFF.25713.F1FA7AD@localhost>
In-Reply-To: <1092311446.10829.52.camel@weka.localdomain>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6688574196652972520=="
--===============6688574196652972520==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Am 12 Aug 2004 11:50 meinte Jules Richardson:
> On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote:
> > here is a "crude" example of what I was talking about.=20
> > [snip]
>=20
> That looks good.
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 :)
> 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:
HDR2U020480204841 =
00
or just point to the data
HDR2U020480204841=
00
which of course may even be in another file:
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).=20
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/
--===============6688574196652972520==--
From jbmcb@hotmail.com Thu Aug 12 09:04:16 2004
From: jbmcb@hotmail.com
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 09:04:16 +0000
Message-ID:
In-Reply-To:
<20568369.1092309078565.JavaMail.root@grover.psp.pas.earthlink.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3459135022079648533=="
--===============3459135022079648533==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
How about breaking up the sections a bit, like HTML sections?
Putting card-catalog information up top in it's own section would speed
indexing and searches. Like this:
a place to put whatever relevant information is needed about the format or
achive
or your favorite poem or joke
Pete Smith
ROM Dumper V4.12
02004-02-02
Omega Race
Midway
Commodore
VIC-20
ROM
Game Cartridge
....
....etc
----- Original Message -----
From: "Steve Thatcher"
To:
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:
>
>
>
> a place to put whatever relevant information is needed about the format
or achive
> or your favorite poem or joke
>
> Tandy Model 100
> Ian Blindly
>
> 5.25" floppy
>
> MFM? RLL? something ...
> 35
> 1
> 18
> 8
>
>
>
>
>
>
>
>
>
> 456789ABCDEF...
> 1234567890A...
> 890ABCDEF01245...
> 456789ABCDEF...
>
>
>
> 456789ABCDEF...
> 1234567890A...
> 890ABCDEF01245...
> 456789ABCDEF...
>
>
>
> 456789ABCDEF...
> 1234567890A...
> 890ABCDEF01245...
> 456789ABCDEF...
>
>
>
>
> 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 ,
> 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
>
>
--===============3459135022079648533==--
From vcf@siconic.com Thu Aug 12 16:33:59 2004
From: vcf@siconic.com
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 16:33:59 +0000
Message-ID:
In-Reply-To: <1092311446.10829.52.camel@weka.localdomain>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2779762973298717478=="
--===============2779762973298717478==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
On Thu, 12 Aug 2004, Jules Richardson wrote:
> 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 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 ]
--===============2779762973298717478==--
From vcf@siconic.com Thu Aug 12 16:55:24 2004
From: vcf@siconic.com
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 16:55:24 +0000
Message-ID:
In-Reply-To: <411B8CFF.25713.F1FA7AD@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4830571807772985487=="
--===============4830571807772985487==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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 ]
--===============4830571807772985487==--
From vcf@siconic.com Thu Aug 12 17:00:12 2004
From: vcf@siconic.com
To: test-drb@ccmp.vtda.org
Subject: archive file format exmaple
Date: Thu, 12 Aug 2004 17:00:12 +0000
Message-ID:
In-Reply-To:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5330895590952477323=="
--===============5330895590952477323==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
On Thu, 12 Aug 2004, Jason McBrien wrote:
> How about breaking up the sections a bit, like HTML 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 ]
--===============5330895590952477323==--