11 Aug
2004
11 Aug
'04
1:54 p.m.
what is wrong with making things easier? If a small amount of effort could be put out to
make the image file have a more useful purpose then to ONLY be able to create media, why
not? Your view seems to be to make all the emulators tyhat are currently available not
work anymore because now they have to be modified to access an image file. My idea is to
not change all that, make the image file simple enough to extract data. I really believe
that to not do that simple thing will make the project less than what it could have been.
I am not proposing something that takes a lot of code, but rather let's us do things
simpler.
Maybe you need to define what an emulator is so I can understand why you think being able
to access data easily should not be done.
If you thought of an emulator is to BE the machine in absolutely all respects then yes who
ever is writing it needs to understand the file structure intimately and we need to add
even more to the specification to allow writing to an image file... If you are designing
an emulator to look like a front panel and run cp/m programs from you favorite stash, then
having to design a complicated file structure interface to an image file is not needed.
best regards, Steve Thatcher
From: "Dwight K. Elvey" <dwight.elvey(a)amd.com>
Sent: Aug 11, 2004 3:24 PM
To: cctalk(a)classiccmp.org
Subject: RE: Let's develop an open-source media archive standard
From: "Steve Thatcher"
<melamy(a)earthlink.net>
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.
No, this is to archive the disk, not to make life easy for emulators.
Again, you assume that the data is files. Also, anyone making such an
emulator will surely know how to find files ( if they exist ) in an
image of the disk. Most emulators include the BIOS and such. The
emulator that we have in the H8 group simply uses the BIOS code
and the boot code from the disk to find file ( as it should ). It
just needs raw data. The emulator I/O is just tracks and sectors,
not files.
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.
Like I said, the archive file can include sufficient information to extract
the data in any form that you'd like but it must as a minimum be able to
recreate the physical disk. It may take some human to actually make the
physical media generator but the data in the file should be sufficient
to do that. This is not an easy task and goes beyond simply finding files
in the raw data.
Dwight
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 ]
12 Aug
12 Aug
1:43 a.m.
On Wed, 2004-08-11 at 22:54, Steve Thatcher wrote:
what is wrong with making things easier? If a small
amount of effort
could be put out to make the image file have a more useful purpose
then to ONLY be able to create media, why not? Your view seems to be to
make all the emulators tyhat are currently available not work anymore
because now they have to be modified to access an image file. My
idea is to not change all that, make the image file simple enough to
extract data.
I'd strongly recommend doing exactly that. Keep the data seperate from
the metadata describing it. Mixing the two really detracts from the
human readability aspect for starters - browsing a file with nicely
formatted structured data peppered with streams of encoded media data
(whether hex pairs, base64 or whatever) would give me a headache :-)
Aside from that, as Steve says, if someone wants to access the media
data itself without worrying about the extra cruft in the archive, they
can.
We've all seen good specs die before simply because they wasn't enough
of an incentive to use them outside of their specialised area - as a
viable project this is much more likely to work if it's easy to adopt by
anyone who currently has tools to do a similar thing (or a subset
thereof)
cheers
J.
12:22 p.m.
On Thu, 12 Aug 2004, Jules Richardson wrote:
I'd strongly recommend doing exactly that. Keep
the data seperate from
the metadata describing it. Mixing the two really detracts from the
human readability aspect for starters - browsing a file with nicely
formatted structured data peppered with streams of encoded media data
(whether hex pairs, base64 or whatever) would give me a headache :-)
Are you really going to be spending much time rummaging through image
files, as a hobby or something?
--
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 ]
13 Aug
13 Aug
3:13 a.m.
On Thu, 2004-08-12 at 21:22, Vintage Computer Festival wrote:
On Thu, 12 Aug 2004, Jules Richardson wrote:
Nope, just thinking of the fact that this is designed to be as
human-readable as possible. Future archivists *are* likely to be
rummaging through archive files. Embedding encoded data within the
metadata information detracts from that quite severely, as well as
forcing the encoded data to be in a form such that it *can* be embedded
within whatever markup language is used.
On readability and flexibility grounds it seems sensible to move the
data outside of the metadata area (e.g. in Steve's example, outside of
the <archive></archive> tags). Note that doing that doesn't mean that
the data can't be defined using the same markup langauge used for the
metadata information; in fact in most scenarios this would likely still
be the case.
Apologies for the cc - I expect many of us interested in this will take
a few more hourse before they're subscribed to the new list.
cheers,
Jules
I'd strongly recommend doing exactly that.
Keep the data seperate from
the metadata describing it. Mixing the two really detracts from the
human readability aspect for starters - browsing a file with nicely
formatted structured data peppered with streams of encoded media data
(whether hex pairs, base64 or whatever) would give me a headache :-)
Are you really going to be spending much time rummaging through image
files, as a hobby or something?
12 Aug
12 Aug
8:25 a.m.
On Wed, 11 Aug 2004, Steve Thatcher wrote:
what is wrong with making things easier? If a small
amount of effort
could be put out to make the image file have a more useful purpose then
to ONLY be able to create media, why not? Your view seems to be to make
all the emulators tyhat are currently available not work anymore because
now they have to be modified to access an image file. My idea is to not
Steve,
All emulators for 8-bit machines today that I'm aware of use disk images.
Emulators like SIMH can read in individual files by, for instance, turning
the file into a virtual paper tape reader.
Your point, again, is taken, but so is Dwight's. I think it depends on
what emulators you spend most of your time playing with which defines your
outlook on this.
One problem I did think of after I sent my last message concerning this is
that if you do start including filesystems, people (probably emulator
writers in particular) will start to wonder why you didn't store the data
in binary. "Why," they ask, "do I have to convert the data from ASCII
when the file is fully capable of holding binary data?" Then you might
get some joker making unauthorized extensions to the spec with binary data
fields. Perhaps I'm getting carried away here, but I do see this as
potentially problematic.
If you thought of an emulator is to BE the machine in
absolutely all
respects then yes who ever is writing it needs to understand the file
structure intimately and we need to add even more to the specification
to allow writing to an image file...
Isn't the specification itself a "how to" for writing an image file?
Also, the image file we are discussing is *NOT*, again, intended to serve
the emulators. Emulator usage is a SECONDARY concern.
--
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 ]
7265
days inactive
7267
days old
4 comments
3 participants
participants (3)
-
julesrichardsonuk＠yahoo.co.uk -
melamy＠earthlink.net -
vcf＠siconic.com