Let's develop an open-source media archive standard

From: Steve Thatcher <melamy_at_earthlink.net>
Date: Wed Aug 11 17:54:33 2004

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_at_amd.com>
Sent: Aug 11, 2004 3:24 PM
To: cctalk_at_classiccmp.org
Subject: RE: Let's develop an open-source media archive standard

>From: "Steve Thatcher" <melamy_at_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.

>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_at_siconic.com>
>Sent: Aug 11, 2004 3:00 PM
>To: Steve Thatcher <melamy_at_earthlink.net>,
> "General Discussion: On-Topic and Off-Topic Posts"
>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.
>> <VOLUME>Apple ][ System Disk</VOLUME>
>> </MEDIA>
>> <DATA>
>> <TRACK 0><SECTOR 0>
>> ...
>> <TRACK 34><SECTOR 15>
>> </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 ]
Received on Wed Aug 11 2004 - 17:54:33 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:36:34 BST