as Sellam had suggested, the data size we represent the information in is not that important. I would encode binary data as hex to keep everything ascii. Data size would expand, but the data would also be compressable so things could be kept in ZIP files of whatever choice a person would want to for their archiving purposes.
XML has become a storage format choice for a lot of different commercial packages. My knowledge is more based on the windows world, but I would doubt that other computer software houses are avoiding XML. Sun/Java certainly embraces it.
I don't quite understand why representing binary as hex would affect the ability to have command line utilitities. Certainly more cpu cycles are needed for conversion and image file size is larger, but we need a readable format and I would think that cpu cycles is not as much of a concern or file size. A utility to create a disk would only have to run through the conversion once to buffer a representation of the floppy disk (unless we are talking about a hard drive image of course). The file size to re-create a floppy disk is only going to be 2 to 3meg at the most (if thinking about a 1.2meg floppy with fortmatting info).
The only difference I see in the sections that were described is that the first one encompasses the format info and the data. My description had the first one as being a big block that contained the two other sections as well as length and CRC info to verify data consistency. Adding author, etc to the big block would make perfect sense.
As for GCR, that would have been covered under etc... I am not familiar with GCR, but I would guess that it has to deal at least with physical tracks and heads. In this case, a track would consist of whatever the format needed plus the data blocks required for the track.
best regards, Steve Thatcher
-----Original Message-----
From: Jules Richardson <julesrichardsonuk(a)yahoo.co.uk>
Sent: Aug 11, 2004 8:08 AM
To: "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, 2004-08-11 at 10:50, Steve Thatcher wrote:
> Hi all, after reading all this morning's posts, I thought I would throw out some thoughts.
>
> XML as a readable format is a great idea.
I haven't done any serious playing with XML in the last couple of years,
but back when I did, my experience was that XML is not a good format for
mixing human-readable and binary data within the XML structure itself.
To make matters worse, the XML spec (at least at the time) did not
define whether it was possible to pass several XML documents down the
same data stream (or, as we'd likely need for this, XML documents mixed
with raw binary). Typically, parsers of the day expected to take control
of the data stream and expected it to contain one XML document only -
often closing the stream themselves afterwards.
I did end up writing my own parser in a couple of KB of code which was a
little more flexible in data stream handling (so XML's certainly not a
heavyweight format, and could likely be handled on pretty much any
machine), but it would be nice to make use of off-the-shelf parsers for
platforms that have them where possible.
As you've also said, my initial thought for a data format was to keep
human-readable config seperate from binary data. The human-readable
config would contain a table of lengths/offsets for the binary data
giving the actual definition. This does have the advantage that if the
binary data happens to be a linear sequence of blocks (sectors in the
case of a disk image) then the raw image can easily be extracted if
needs be (say, to allow conversion to a different format)
Personally, I'm not a fan of mixing binary data in with the
human-readable parts because then there are issues of character escaping
as well as the structure detracting from the readability. And if encoded
binary data is used instead (say, hexadecimal representation) then
there's still an issue of readability, plus the archive ends up bloated
and extra CPU cycles are needed to decode data. Neither of those two
approaches lend themselves to simply being able to use common
command-line utilities to extract the data, either. I'm prefectly
willing to be convinced, though :)
> I looked at the CAPS format and in part that would be okay. I would like
> to throw in an idea of whatever we create as a standard actually have
> three sections to it.
So, first section is all the 'fuzzy' data (author, date, version info,
description etc.), second section describes the layout of the binary
data (offsets, surfaces, etc.), and the third section is the raw binary
data itself? If so, I'm certainly happy with that :-)
One aside - what's the natural way of defining data on a GCR floppy? Do
heads/sectors/tracks still make sense as an addressing mode, but it's
just that the number of sectors per track varies according to the track
number? Or isn't it that simple?
cheers
Jules
I'm looking for ROMs (or ROM images would be better) for a TQK50
controller. The ROMs I want are 23-330E5 and 23-331E5. Can anyone
help?
--
Pete Peter Turnbull
Network Manager
University of York
would you rather have one format that allows for easy data access and re-creation of media or only be able to re-create media and have a difficult interface in EVERY emulator that needs to access the data? From a usage standpoint, I think putting the burden on the emulators is not a reasonable approach. There are a variety of emulators available do not have to deal with track sector access of information. One uses an import command to bring ms-dos files in for example. To have to write an outside utility that has to know what the image file type is, know the physical layout of the disk, know how the OS accesses files on the disk just to retrieve file data is not a good idea. leave the OS access to the real platform or emulators that want to deal with actual tracks and sectors.
best regards, Steve Thatcher
-----Original Message-----
From: "Dwight K. Elvey" <dwight.elvey(a)amd.com>
Sent: Aug 11, 2004 3:05 PM
To: cctalk(a)classiccmp.org
Subject: Re: Let's develop an open-source media archive standard
>From: spc(a)conman.org
>
>It was thus said that the Great Vintage Computer Festival once stated:
>>
>> HOWEVER, this makes it very difficult to use the imagefile on an emulator.
>> To use the floppy disk example again, if the emulator wants Track 14
>> Sector 8 (or Block 417) but it has not been explicitly laid out in the
>> imagefile because it was originally zeroes, then the emulator, if poorly
>> designed, may crap out.
>
> Are you trying to create an archive format, or a format that is to be used
>by emulators? I say skip the emulators and concentrate on archival
>purposes. An emulator can then use the archive format to create a disk
>image in whatever internal format it requires.
>
> Don't complicate the problem.
I agree. We only need to provide a format that could be converted
for a specific emulator, not necessarily one that can be conveniently
read by an emulator.
Dwight
>
> -spc (And don't try to become everything for everybody ... )
>
>
>
>
> -----Original Message-----
> From: cctalk-bounces(a)classiccmp.org
> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Jules Richardson
> Sent: 02 August 2004 23:10
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: rarest computers. was: RE: Xerox Alto
> Restoration + Emulation
>
>
> On Mon, 2004-08-02 at 19:56, Vintage Computer Festival wrote:
> > On Mon, 2 Aug 2004, Jules Richardson wrote:
> > > Apple /// (possibly lots worldwide; there don't seem to be many
> > > people this side of the pond who have seen one though)
> >
> > Very common.
>
> I figured they might be - just not in this part of the world, it seems
> :-) Wonder how many were actually sold in the UK...
At least 3 - you've got 1, I've got 2 and I bet Tony's got one
somewhere...
What might be uncommon these days is a *working* /// :)
Cheers
w
Hi
I suspect that most metal cased N*'s were destined to be used
in rack mount applications.
Dwight
>From: "Marvin Johnston" <marvin(a)rain.org>
>
>Actually, it would be nice to have pictures of all three Northstar
>chassis styles. Right now, mine are all buried and I won't get a chance
>to get near them for another month or so. But I'll keep my eyes open for
>one of the beige ones now :).
>
>Adrian Graham wrote:
>>
>> > On Wed, 4 Aug 2004, Marvin Johnston wrote:
>> >
>> > > Someone mentioned some time ago a metal case instead of the
>> > standard
>> > > case for the Northstar Horizon. Can anyone confirm if they
>> > did put out
>> > > a computer in a metal case, and if so, (wishful thinking) how many
>> > > they might have produced? I have one here in a powder blue
>> > metal case
>>
>> There's at least one of the metal cased ones in 'storage' at Bletchley
>> Park - IMSAI blue with an (I assume) aluminium front, 2 vertical floppy
>> drives etc. Got a pic somewhere if anyone's interested, I can't attach
>> it to this mail 'cos the list software will bin it.
>
>From: "melamy(a)earthlink.net" <melamy(a)earthlink.net>
>
---snip---
>
>The image file that you are discussing is only good as a "how to" to write
>arbitrary data to arbitrary media. It is only good for creating a final
>media image because the format being contemplated (mixing data into the
>physical spec) will preclude the file from standing on its own.
No, that is not true. The description of the physical data in the archive
should be sufficient to recover the system side data. I can state
this because the system side data is just a subset of the physical
data.
I recommend that the archive should include enough information to
translate from the physical to the system but for archiving purposes,
that is not absolutely necessary. It is not that hard to describe as
part of the header what FM looks like. Still, if we restrict all archived
information to include this, some unknown formats may not be archived
because the person with the data doesn't know that format. It is
better to capture the data first.
It may also be that the only way that person has to capture the
data is the output of a controller chip. The archiving should allow
this as well ( more in the format the Steve would like it all to
be in ). This file could later be combined with the more physical
information when that was available, just as a archive file that
originally had only physical information could be appended with the
data as seen by the system.
What this means is that some of the archived files may not be directly
useable by Steve and his tools without some more in depth knowledge
about the encoding use. It doesn't make it impossible to use, just
difficult.
Dwight
>I was
>proposing identifying data blocks as files if that is what they were. The
>data blocks would have been sequential and trivial to retrieve. That is
>hardly what I would call defining a file system as part of the image file.
>
>best regards, Steve Thatcher
>
>From: "Roger Merchberger" <zmerch(a)30below.com>
>
>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
>> > 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 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?
Hi
I don't see this as being an issue. Once one knew how to
decode the information for such applications that wanted to
extract the data, one could import information into the
image. It would of course require some knowledge of the
data structures used by that system. It would have to know
how to resolve things like logical interleaving and allocating
space by the allocation methods.
>
>>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.
I don't see this as an issue. Once one has the archive file in hand,
using it as a method to import external data is surely a valid application.
The concept of read-only is just an OS flag that can be overwritten.
Surely, someone doing this would rename the file or otherwise indicate
that it has change. There is nothing anyone can do to restrict such
actions. Why specify something that can not be enforced? We can recommend
action. We can recommend that there be a field that indicated any change
in the data of an archive and if that change is an overwrite of data
or an enhancement of the data.
Dwight
>
>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.
>
>
the emails I received seem to be out of order...
I believe what you are saying does satisfy the requirement that I have been
proposing. There are different levels of physical to data mapping. I can
see target platform code running that creates an image file and might
actually send the XML directly out a serial port in zmodem for example. It
could send it out as files or strictly embedded data. My point has been to
make the file blocks available if the target has them just so the data can
be extracted easily.
best regards, Steve
Original Message:
-----------------
From: Vintage Computer Festival vcf(a)siconic.com
Date: Thu, 12 Aug 2004 09:39:18 -0700 (PDT)
To: cctalk(a)classiccmp.org
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Steve Thatcher wrote:
> I am not assuming anything about the data. The usual use is to have
> files... in the case of a paper tape emulator system used for CNC, the
> disk structure may not resemble a normal file structure. It still
> contains one or more blocks of data. you can apply whatever name to that
> you want to. The boot sector on a cp/m 8" disk doesn't have a name, but
> it is a block of data that is separate from everything else. Personally,
> I would want to be able to "read" the boot sector and potentially even
> write it back to an image file. It really doesn't make a difference
> whether you access track 0 and sector 1 or a data block inside the image
> file that contains the boot code.
I see what you're saying now. I suppose another potential format that can
be incorporated into the spec is a file-based format, where blocks or
"files" are represented inside the archive. I can see this being useful
for two purposes:
1) Imaging the filesystem from a medium (as opposed to the medium itself)
2) Incorporating code along the lines of what Dwight has been suggesting
that knows how to do special processing of the image it is contained in.
The code can be extracted and poked into memory using a very simple
algorithm that possibly can be described in comments in the image file.
I did suggest that the spec be able to image filesystems in a previous
message. I think this comes close enough to what you are describing. It
can be modified to also be able to indicate "blocks of data". These
blocks could be given an identifier--a name, number, whatever; it doesn't
matter, as long as it's an ASCII-representable string--and then extracted
>from the image file as needed.
Does this satisfy you, Steve? :)
--
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
]
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
All,
Just to let you know I followed up to Lyle's message, and
went to see those guys (with Lyle) to see what is there.
I am going in there tomorrow morning, and will save the
systems from the oven. Basically, we have:
- MicroVAX 3600 with RA82 (my new baby ;-)
- extra rack filled with 6 pcs RA92
- Cipher magtape unit, frontloader (not in rack)
- two VAX 4000(-500A) systems
- a stack of BA42 storage expanders with various drives
- a stack of MicroVAX 3100 -M38 and -M76 systems
- two what seem to be DECsystem 5500 systems
- one more VAX 3600
.. and some little things. If you have an interest in any
of this (cept the 3600- tis mine!) please contact me off-list
so we can work something out.
Warning: RA92 dont ship well. This means that it will probably
be pickup only, sorry.
--f
Just obtained an M4 Data tape drive, model 9914 (800/1600/3200/6250)... just pulled from working service...desktop enclosure... $50 bucks :)
I believe it's Differential, not single ended. I haven't kept up with PC technology (hooking this to a PC). Is this older Differential the same as LVD? I believe it had a centronics 50 pin connector labeled "differential". I'm wondering what SCSI card I can use with this... Adaptec 2940?
Jay
