actually both Intel and Motorola use a checksum which is just the negative value of the summation of all bytes. A CRC check actually was used in zmodem for example and it is a mathematical value derived from a polynomial function (do a search for CRC onm the web). There are CRC code snippets for creation of this type of data.
I know a three section approach that I was proposing is more complicated, but from a code standpoint allows total freedom of data access without having to create a target media let alone have the computer system to then read the media just to get at the data that was on a floppy disk. The beauty is that if you need to create a Northstar system diskette then you can, but if all you need is a copy of the dump.asm program then you can get that also without having to go any further than the file you started with.
best regards, Steve Thatcher
-----Original Message-----
From: "Cini, Richard" <RCini(a)congressfinancial.com>
Sent: Aug 11, 2004 7:37 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
Dave:
I tend to forget about the Motorola format (call me an Intel snob).
The 16mb would be enough for many systems, and I would hope that 4gb would
be enough, at least for now, to represent the largest of the media types we
want to represent.
Rich
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of David V. Corbin
Sent: Wednesday, August 11, 2004 10:34 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: Let's develop an open-source media archive standard
You might want to consider Motorola rather than Intel.
The only reason I suggest this is the motorola format alread has a (semi)
extensible record type description [the second char of each line].
S2 and S3 are already defined for 16MB and 4GB memory spaces...
A (non-standard) record type "could" be used for media format, etc...
Just my 16.3875 milli-EUR comment...
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Cini, Richard
>>> Sent: Wednesday, August 11, 2004 10:02 AM
>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>> Subject: RE: Let's develop an open-source media archive standard
>>>
>>> I haven't read the entire thread on this but I did read
>>> Steve Thatcher's idea and it describes about where I was
>>> coming out on this myself.
>>>
>>> I might have missed what the ultimate use of this archive
>>> would be. Will the archive be used to (1) re-generate
>>> original media; (2) operate with emualtors; (3) both?
>>>
>>> To ensure integrity of the data I would propose recording
>>> the data in the Intel Hex format -- it's text-based and has
>>> built-in CRC. Now, we'd have to modify the standard format
>>> a bit to accommodate a larger address space and to add some
>>> sort of standardized header (a "Hardware Descriptor"). This
>>> data would be used by the de-archiver to interpret the
>>> stream of data read from the data area (the "Hex Block").
>>>
>>> I agree that a multi-layer approach offers the best
>>> combination of platform neutrality and portability. I don't
>>> really know if we need two or three layers as Steve
>>> described to describe the file in a standard fashion. Using
>>> an Intel Hex-like format would increase the "de-archiving"
>>> time, but in my view it's a fair trade-off. De-archiving
>>> software could translate the platform-neutral file into
>>> another format better suited for use in emulators.
>>>
>>> I think that we should start compiling a list of the
>>> various media we want represented and how that media is
>>> organized natively. I don't mean "well, it has blocks and
>>> sectors" either. We should examine the exact format down to
>>> the actual numbers (i.e., "2048 blocks of 256-bytes
>>> recorded twice"). Seeing how the various data stores are
>>> organized should bring some clarity to how we should represent it.
>>>
>>> Just my $0.02.
>>>
>>> Rich
>>>
to clarify my comment about using zip, this was suggested as a way for a person to reduce the size of their archive for their own purposes. I was not proposing that data be compressed with zip for the actual archive file.
The only assumption I made for data continuity was that the data needed to be ascii and to have some error detection ability to let the person accessing the data have an idea of validity.
Keeping an image file in an error checked ascii file in a purely sequential form seems to me to not rely on any technology or special information other than accessing a pure data file from some type of computer system. As someone else suggested, ascii text could even be contained in archive files to explain how to get teh data back. My thought of having the data accessible as well as the formatting information would allow a single transmission of a group of files to be sent with information contained within to either get just the data or be able to actually create media copies.
best regards, Steve Thatcher
-----Original Message-----
From: Doc Shipley <doc(a)mdrconsult.com>
Sent: Aug 11, 2004 10:20 AM
To: General(a)mdrconsult.com, Discussion@mdrconsult.com@null,
On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>, null@null
Subject: Re: Let's develop an open-source media archive standard
Jules Richardson wrote:
> On Wed, 2004-08-11 at 13:13, Steve Thatcher wrote:
>
>
>> 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.
>
>
> "could be kept" in zip files, yes - but then that's no use in 50 years
> time if someone stumbles across a compressed file and has no idea how to
> decompress it in order to read it and see what it is :-)
There's going to have to be _some_ assumption of continuity or this
project is hopeless. It's my opinion that short-term or long-term,
anyone who wants or needs access to the data** will have some historical
understanding of the computing environment contemporary to that data.
Provisions for changing technology and loss of continuity are good,
but we still need to draw the line at some point, especially concerning
"external" archival of the archived data, i.e. zipped arcives and
storage media. To go to an extreme example, even printed ASCII on paper
or mylar isn't reliable. Paper may be just as archaic as hieroglyphics
when the data is wanted.
We have to depend on ongoing maintenance of these archives. If they
are not periodically migrated to current media, and if the
attached/imbedded documentation is not augmented to account for social
and technical "loss of memory", future retrieval will be difficult, if
not impossible, no matter what we do now.
Doc
** Technically speaking. We can't provide for, say a non-technical
attorney who wants recorded files as evidence. That example will end up
in the hands of someone like us.
I forgot to answer one part of the original post. If you need someone to act
as the consolidator of the media data, I can do that.
-----Original Message-----
From: cctalk-bounces(a)classiccmp.org
[mailto:cctalk-bounces@classiccmp.org]On Behalf Of Vintage Computer
Festival
Sent: Wednesday, August 11, 2004 1:56 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Let's develop an open-source media archive standard
On Wed, 11 Aug 2004, Cini, Richard wrote:
> I might have missed what the ultimate use of this archive would be. Will
the
> archive be used to (1) re-generate original media; (2) operate with
> emualtors; (3) both?
Both. Emulators will certainly be able to make use of the archive by
having parsers built-in that can translate the archive data into
something the emulator can use. So instead of point the emulator to a
binary disk image, you would point it to an archive file and it would
translate the file back into tracks/sectors, or punch cards, or whatever.
> To ensure integrity of the data I would propose recording the data in the
> Intel Hex format -- it's text-based and has built-in CRC. Now, we'd have
to
> modify the standard format a bit to accommodate a larger address space and
> to add some sort of standardized header (a "Hardware Descriptor"). This
data
> would be used by the de-archiver to interpret the stream of data read from
> the data area (the "Hex Block").
I think you're thinking of this in terms of a large binary file encoded as
ASCII hex. If so, this is not what's being proposed. What is being
discussed is a format which actually describes the physical medium. For
example, on floppy:
<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>
> I think that we should start compiling a list of the various media we want
> represented and how that media is organized natively. I don't mean "well,
it
> has blocks and sectors" either. We should examine the exact format down to
> the actual numbers (i.e., "2048 blocks of 256-bytes recorded twice").
Seeing
> how the various data stores are organized should bring some clarity to how
> we should represent it.
I agree. This would be useful. Does someone want to volunteer to do
this?
--
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
]
my concept of splitting the data and the formatting information relies on the data blocks being the correct size for whatever media you are creating. In other words, you could see 128, 256, 512, and 1024 "sectors" for floppies. Each data block is assigned a number (virtual or real) that is then used to put the data in the correct physical location on whatever media it was supposed to be put in. The addressing of the hex formats in less important that the ability to have a block size of the required length. A paper tape data block would be whatever arbitrary length the tape was a be sequential. Same goes for a cassette tapel recording that might have been converted to mp3 for storage.
best regards, Steve Thatcher
-----Original Message-----
From: "David V. Corbin" <dvcorbin(a)optonline.net>
Sent: Aug 11, 2004 8:46 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
S1 = 16 bit address in each record..
S2 = 24 bit address in each record..
S3 = 32 bit address in each record..
Hence the maximum sizes.....
>>> -----Original Message-----
>>> From: cctalk-bounces(a)classiccmp.org
>>> [mailto:cctalk-bounces@classiccmp.org] On Behalf Of Jules Richardson
>>> Sent: Wednesday, August 11, 2004 10:52 AM
>>> To: 'General Discussion: On-Topic and Off-Topic Posts'
>>> Subject: RE: Let's develop an open-source media archive standard
>>>
>>> On Wed, 2004-08-11 at 14:37, Cini, Richard wrote:
>>> > Dave:
>>> >
>>> > I tend to forget about the Motorola format (call me an
>>> Intel snob).
>>> > The 16mb would be enough for many systems, and I would
>>> hope that 4gb
>>> > would be enough, at least for now, to represent the
>>> largest of the
>>> > media types we want to represent.
>>>
>>> I don't know about 4GB, but I'd really like to archive hard
>>> disk images in the 20-30MB range using the same format if
>>> possible...
>>>
>>> cheers
>>>
>>> Jules
>>>
>>>
>>>
On Aug 9 2004, 21:58, trash3(a)splab.cas.neu.edu wrote:
> I have three boards. Two of them are Rev. K3. One of the boards has
PROMS
> on it, and no readable version, but the second has the 330-E5 and the
> 331-E5.
Thanks, Joe. I've got images now.
For those who may be interested, I've added a few more images to my DEC
ROM collection, including those. In an effort to make it slightly more
user-friendly, I've also added a 00ReadMe file and one called
"ROMlist", which lists ROM numbers I know, with the modules they belong
to, and some (occasionally cryptic) notes.
The whole lot is at http://www.dunnington.u-net.com/public/DECROMs/
Further contributions welcome :-)
Did anyone sort out a repository for the small PROMs used in Unibus
bootstraps and the like? I know Henk has a nice (if you don't mind
Javascript) list of the common ones, but I don't know if dumps are
around anywhere.
--
Pete Peter Turnbull
Network Manager
University of York
Hello,
My name is Rick Fama from Delta Computer Group. We are in need of the SSP diskettes for a IBM 5362.
Any idea of where I can obtain these?
Thanks
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. There is plenty of software available on most platforms to deal with this format.
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.
The first would be a data description and subsequent data (i.e. Data Container contains Data Items). Block size, number of blocks, and block data...
The second would be a physical format description that would tell how the data description data is actually stored on whatever media is being targeted (Format Container contains Format Items). Device type (sequential, random), track, sector, virtual sector, head, bad sectors, etc would be needed and then a mapping from each Data Item to each Format Item.
The third would simply be a "image file" that would simply be a sequential block of data with length and CRC that contained the Data Container and Format Container.
This type of arrangement would give us a single file to send around that not only allowed for the recreation of the physical format, but also allowed for direct file access (read only of course). I suppose one could think of it as a smart library file that not only contained one or more files, but also gave physical re-creation information.
best regards, Steve Thatcher
-----Original Message-----
From: Vintage Computer Festival <vcf(a)siconic.com>
Sent: Aug 10, 2004 7:04 PM
To: Classic Computers Mailing List <cctalk(a)classiccmp.org>
Subject: Let's develop an open-source media archive standard
Ok, instead of all the unproductive bickering over semantics (most of
which is illogical...come on, admit it) I'd rather we actually discuss
developing further an open-source, public domain, free (in every sense of
the word) standard for archiving data media of all types (magentic, paper,
or otherwise).
This is basically going to be a continuation of what we've already
discussed on the list, and what Hans and I have discussed in private.
First, let's start with the goals.
The format should be:
1) Well Documented (with such documentation actively preserved in all four
corners of the globe and beyond)
2) Not constrained to any particular hardware
3) Be inclusive of all physical (and logical?) manner of recording media
4) Be implementable on even the simplest architectures (because the
original media source will in many cases have to be read on the hardware
it is connected to)
5) Open source, public domain, etc. (although a copyright may be held if
it makes sense to do so)
6) Adaptable, expandable, revisable (for future extensions)
7) Text-based and storable in commonly accessible character formats (i.e.
a suitable subset of Unicode, i.e. ASCII)
8) Allow for the representation of media in either logical or physical
(raw bit stream) formats
This is a good start. Someone please continue adding to the definition.
I will establish a special session at the next VCF (November 6-7) where
we can commence a committee for formalizing this standard and getting it
recognized internationally in all the various relevant groups (i.e. ANSI
or ISO/IEC).
--
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 ]
*********************************************************************************
Before acting on this e-mail or opening any attachment you are advised to
read Metronet Rail BCV Limited's disclaimer at the end of this e-mail.
*********************************************************************************
Hi lee
I found this discussion thread recently and would be interested in the
Matrox Graphic cards - have you still got?
Best Regards
Trevor Wright
Recently rescued ..
HP 9000/300 - 68010 CPU, 1MB RAM + video (so it says)
HP 9153A - 2 of, floppy + HD (probably 10MB)
HP 35731A - 12" 512x400 monochrome monitor (some burn)
HP 46021A - keyboard
HP 46083A - HP-HIL rotary control
HP 46084A - HP-HIL ID module
One of the 9153A drives is alleged to contain the software
to dribe a gas chromatograph (written in PASCAL) the other
is alleged to contain the PASCAL compiller environment.
Not tested as yet. Also ..
MEM/340 - 4MB multibus II(?) memory card
And bought recently ..
Heurikon M220 - 5 of, VME, 68020/68881, 4MB DRAM, SCSI, 2 x SERIAL
Matrox MMG640 - 2 of, VME, graphics, ??
I need info for the Matrox and Heurikon boards, and possibly ROM
images, and I could use a VME backplane or two (or other VME cards
such as ethernet) so the HP stuff and the multibus card are available
for swap/sale. I can probably deliver/collect within the UK.
Cheers
Lee.
*********************************************************************************
Any opinions expressed in this e-mail are those of the individual and
not necessarily the company. This e-mail and any files transmitted with
it are confidential and solely for the use of the intended recipient.
It may contain material protected by attorney-client privilege.
If you are not the intended recipient or the person responsible for
delivering to the intended recipient, be advised that you have
received this e-mail in error and that any use is strictly prohibited.
If you have received this e-mail in error please notify the sender or
Metronet Rail BCV Limited's service desk on 0870 458 3862 and then delete
this message.
Unencrypted e-mail is intrinsically insecure and Metronet Rail BCV Limited does
not accept responsibility for any changes made to this e-mail or attachments
during its transmission. If you are unsure of the authenticity of this e-mail
then please contact the sender.
Virus Disclaimer:
Every effort has been made to ensure that this e-mail is virus free.
However Metronet Rail BCV Limited does not accept any liability in respect to
an undetected virus and recommends that the recipient(s) use an up to date
virus scanner.
Metronet Rail BCV Limited
Registered Office: Templar House, 81-87 High Holborn, London WC1V 6NU.
Company Number: 3923496
**********************************************************************************
Hello,
I recently got an Alphaserver 2000 4/200 and I want to run OpenVMS on
it. I have signed up for the Hobbyist program but I do not have the
money to purchase the media. If someone has a set that I can borrow or
get a copy of I would be very grateful.
Thanks,
Eric Moody
Hi
There is a format that has been used with the H8/89
hard sectored disk called SVD. I like it in some ways but not
in others.
Things I like:
It is in a human readable format
Sectors are separated by white space and/or comments
comments can be added
Things I don't like:
Format is octal ( I prefer hexadecimal )
Header contains various bit of information that are not decoded
in a human readable form( still encoded as octal values ).
I use a straight binary image file to transfer disk images to
my H8's and H89. Converting the SVD format to one that I can use
is trivial.
The issue of reading the actual file from an image and placing
that into a file is another issue. Each disk system uses a
different directory structure and allocation method. How this
could be simply encoded into the image files is more than I'd like to
think about unless one would just settle for a textual description
in the comment space.
As an example, the H8/89 hard sectored disk have a volume number
encoded in the header field ( that isn't part of the data ). The
directory and allocation tables are pointed to by specific locations
on track 0. They are not at specific locations.
Other issues that might be a problem are things like the actual encoding
methods used. Not all data is in nice 8 bit chunks ( my Nicolet does
20 bit chunks ). Inter leaving is usually not a great issue since
it often only effects speed but it might be important.
Dwight
>From: "Paul Koning" <pkoning(a)equallogic.com>
>
>>>>>> "Vintage" == Vintage Computer Festival <vcf(a)siconic.com> writes:
>
> Vintage> Ok, instead of all the unproductive bickering over semantics
> Vintage> (most of which is illogical...come on, admit it) I'd rather
> Vintage> we actually discuss developing further an open-source,
> Vintage> public domain, free (in every sense of the word) standard
> Vintage> for archiving data media of all types (magentic, paper, or
> Vintage> otherwise).
>
> Vintage> This is basically going to be a continuation of what we've
> Vintage> already discussed on the list, and what Hans and I have
> Vintage> discussed in private.
>
> Vintage> First, let's start with the goals.
>
>When you say "archiving" what span of time do you mean? A year? A
>decade? A century? Longer?
>
>You will get completely different answers depending on how you answer
>that question.
>
>(See also www.longnow.org)
>
> paul
>
>
