11 Aug
2004
11 Aug
'04
12:47 p.m.
I realize that the idea is to create a format to make re-creation of media possible for a
variety of platforms. We can certainly do that and have its only function be to maintain
a physical data format. My added idea is that the data and the formatting be separated so
that a simple utility on a non-target platform could extract data from the image file.
If we create a physical description only and do not abstract the data then any emulator
must understand the OS file structure in order to retrieve any internal file
representation. My idea would make the file re-creation simple in that the xml image file
would be parsed for the actual file data that an emulator would need. This makes the
emulator easier.
To retrieve a file from the physical layout that it at the end of this message, the
emulator must know the actual disk format that is used on the target system (the one the
image file was made for). I have seen cp/m systems where the actual physical sectors were
sequential on disk and the OS file sector was actually virtual to increase speed. Not my
idea of the way to do it. It is much easier to make the physical sectors slewed so that a
physical sector is a file sector. These are the types of issues you will have to overcome
if an emulator must totally understand each and every file system for a cp/m version for
example.
Sellam, let me know if you would like to discuss this via telephone so I can convery the
idea that I am proposing.
best regards, Steve Thatcher
-----Original Message-----
From: Vintage Computer Festival <vcf(a)siconic.com>
Sent: Aug 11, 2004 3:00 PM
To: Steve Thatcher <melamy(a)earthlink.net>et>,
"General Discussion: On-Topic and Off-Topic Posts"
<cctalk(a)classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Steve Thatcher wrote:
I agree with Sellam on the point about using it both
for media
re-creation and emulation. The trouble with the approach below of just
using raw data on a track sector basis is that now you have created a
file that can only be used with an emulator that understands the
physical format and OS access for the computer system you are emulating.
That is the point, really. What we are attempting to do is describe as
faithfully as possible a physical media with logical data in a purely
logical form. The goal would be that the physical media could be
re-created from the imagefile if need be. The parameters of the physcial
media are specified so that this can be possible.
My earlier point of separating the data and the format
information
allows a single file (that would not be much bigger that the one
described below) to contain multiple platform specific files that can be
"read" by a simple utility that does not require any knowledge of the OS
or the platform.
I'm not quite understanding you here. Or maybe I am. An image in the
format shown below could be read by any emulator. Making sense of the
data with respect to that emulator is a different issue altogether, but it
does make it possible for, say, a Northstar Horizon emulator to load up an
Apple ][ disk image and then try to access it.
Anyway, I don't think I am quite getting the point you are trying to make.
<MEDIA TYPE=FLOPPY SIZE=5.25 SIDES=1 DENSITY=SINGLE
FORMAT=GCR TRACKS=35
SECTORS=16 SECTORSIZE=256>
<VOLUME>Apple ][ System Disk</VOLUME>
</MEDIA>
<DATA>
<TRACK 0><SECTOR 0>
HERE WOULD BE THE ASCII HEX DATA FOR TRACK 0, SECTOR 0
</SECTOR></TRACK>
...
<TRACK 34><SECTOR 15>
HERE WOULD BE THE ASCII HEX DATA FOR TRACK 34, SECTOR 15
</SECTOR></TRACK>
</DATA>
--
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 ]
11 Aug
11 Aug
4:07 p.m.
On Wed, 11 Aug 2004, Steve Thatcher wrote:
I realize that the idea is to create a format to make
re-creation of
media possible for a variety of platforms. We can certainly do that and
have its only function be to maintain a physical data format. My added
idea is that the data and the formatting be separated so that a simple
utility on a non-target platform could extract data from the image file.
This can be done anyway. Parsing the tags should not be too difficult.
And unless someone can come up with an elegant way of doing it, what
you're proposing will require two sets of data in the imagefile: one in
the structured format and one in an unstructured format. I suppose tags
could be added to specify this is the case so that "lazy" programs don't
have to go through all the trouble of parsing the structured data.
If we create a physical description only and do not
abstract the data
then any emulator must understand the OS file structure in order to
retrieve any internal file representation. My idea would make the file
re-creation simple in that the xml image file would be parsed for the
actual file data that an emulator would need. This makes the emulator
easier.
You're describing an imagefile that contains a filesystem image, rather
than, say, a disk image. This can be accomodated in the spec, but it's a
different type of image than what we've been discussing.
Remember, I envision the spec being able to handle:
1) A filesystem image (as you describe)
2) An image in "logical" format (i.e. blocks structured in tracks and
sectors for a floppy, or cards for a punch card deck)
3) An image in "raw" format (a bit stream, or the actual punched holes
from a punch card deck)
And there's actually a:
2.5) Magnetic media at a level below the "logical" format (decoded tracks
and sectors) but above a bit-stream, which would be the raw sectors on a
disk or tape including address headers, data headers, prologue/epilogue
bytes, sync bytes, etc.
To retrieve a file from the physical layout that it at
the end of this
message, the emulator must know the actual disk format that is used on
the target system (the one the image file was made for). I have seen
Right. If you choose to store an image in the raw disk format.
cp/m systems where the actual physical sectors were
sequential on disk
and the OS file sector was actually virtual to increase speed. Not my
idea of the way to do it. It is much easier to make the physical sectors
slewed so that a physical sector is a file sector. These are the types
of issues you will have to overcome if an emulator must totally
understand each and every file system for a cp/m version for example.
It's up to emulator writers to read the spec and adapt to it. We'll make
the spec as flexible as possible, but first and foremost, the spec is
intended to archive images of data media, and not to serve as a universal
emulator image format (though it should be able to be used as such).
Sellam, let me know if you would like to discuss this
via telephone so I
can convery the idea that I am proposing.
I think I understand what you're saying. Let me know if I still don't get
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 ]
4:42 p.m.
Rumor has it that Vintage Computer Festival may have mentioned these words:
On Wed, 11 Aug 2004, Steve Thatcher wrote:
> If we create a physical description only and do not abstract the data
> then any emulator must understand the OS file structure in order to
> retrieve any internal file representation.
I don't wanna sound like a doofus, but:
So?
My idea would make the file
It could be accommodated, but why should it when it would be easier for
someone to build a converter into an emulator image file?
This spec (as far as I understand it) is going to be read-only anyway -
this is for archiving after all. What happens when the emulator tries to
rewrite the disk image (say, from saving a modified file)? What will happen
to the original archive?
re-creation simple in that the xml image file
would be parsed for the
actual file data that an emulator would need. This makes the emulator
easier.
You're describing an imagefile that contains a filesystem image, rather
than, say, a disk image. This can be accomodated in the spec, but it's a
different type of image than what we've been discussing. It's up to emulator writers to read the spec and
adapt to it.
Bam. That hit the thumbnail right on the head. ;-)
We'll make
the spec as flexible as possible, but first and foremost, the spec is
intended to archive images of data media, and not to serve as a universal
emulator image format (though it should be able to be used as such).
I'd like to add that IMHO it should be "read-only" so the emulator
doesn't
destroy the archive when it rewrites certain sectors and/or files.
At least that's my take on the deal...
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
Recycling is good, right??? Randomization is better!!!
If at first you don't succeed, nuclear warhead
disarmament should *not* be your first career choice.
12 Aug
12 Aug
5:06 a.m.
Am 11 Aug 2004 14:47 meinte Steve Thatcher:
I realize that the idea is to create a format to make
re-creation
of media possible for a variety of platforms. We can certainly do
that and have its only function be to maintain a physical data
format. My added idea is that the data and the formatting be
separated so that a simple utility on a non-target platform could
extract data from the image file.
Well, physical format and data is not always seperable. In some
circumstances the physical format is part of the onformation an
application needs, and differs form media to media (e.g. copy
protection schemes)
If we create a physical description only and do not
abstract
the data then any emulator must understand the OS file
structure in order to retrieve any internal file representation.
My idea would make the file re-creation simple in that the xml
image file would be parsed for the actual file data that an
emulator would need. This makes the emulator easier.
But what if the emulator needs the physical format information?
To retrieve a file from the physical layout that it at
the end
of this message, the emulator must know the actual disk format
that is used on the target system (the one the image file was
made for). I have seen cp/m systems where the actual physical
sectors were sequential on disk and the OS file sector was
actually virtual to increase speed. Not my idea of the way to
do it. It is much easier to make the physical sectors slewed
so that a physical sector is a file sector. These are the types
of issues you will have to overcome if an emulator must totally
understand each and every file system for a cp/m version for
example.
At least within a CP/M system it usualy doesn't matter at all
how the files are stored on a disk. Except for some odd apps
who tried to implement system specific copy protection schemes,
all and every CP/M app accesses files just via BDOS which already
hides the real disk strukture.
Gruss
H.
--
VCF Europa 6.0 am 30.April und 01.Mai 2005 in Muenchen
http://www.vcfe.org/
7266
days inactive
7267
days old
3 comments
4 participants
participants (4)
-
Hans.Franke＠siemens.com -
melamy＠earthlink.net -
vcf＠siconic.com -
zmerch＠30below.com