14 May
2005
14 May
'05
4:24 p.m.
For any newbies to the group:
1. Don Maslin (San Diego, CA) collected what I
believe is the largest and most complete archive
of CP/M/S100 operating systems amongst us 'hobbyists'.
2. Don died 28 August 2004, leaving no plans
for his archive.
3. Because his widow Winnie was distressed with
the enquiries from those in our community regarding
Don's archive (of which she knew nothing), after
discussing this with her, with her heartfelt
appreciation and agreement, it having been read
to her before posting and sent to her in letter
form, as Don's friend and collaborator of some
15 years, I published the following statement
on ClassicCmp and comp.os.cpm on 22 September 2004:
*
"I have of course talked with his wife Winnie, and
she has asked that people interested in Don's software
archives and his hardware collection hold off on
contact until further notice through this list.
"Within a reasonable time I will locate his archives,
and I will personally guarantee that the archives will
be duplicated and copies deposited with people and
institutions which will honor the attitude that Don
put into this effort - one of love for old stuff and
and of service to the community.
"In time his hardware collection will also be made
available to the community.
"I ask you to consider Mrs. Maslin's position and not
attempt to intervene at this time."
(You can see the full text in the ng or ClassicCmp
archive.)
*
Many of you have enquired of me in private e-mail as
to the status, many have made generous offers of time,
energy, web hosting space, etc., and Winnie has been
left free of bother.
I NO LONGER BELIEVE THAT I CAN KEEP MY PERSONAL
GUARANTEE THAT THE ARCHIVES WILL BE SAVED. I MADE THAT
PROMISE IN GOOD FAITH, ON THE WORD OF WINNIE MASLIN.
My intent was to locate the base archive, gather the
materials not yet incorporated, make certain the
structure was fully documented and sensibly usable,
and
write it off to CD-ROM - to be distributed to computer
museums, universities, and to be hosted on web sites
so
that all could download the full archive, guaranteeing
that it would never be lost.
I seemed to be the logical one to do this - close by,
long association with Don, his project having come out
of the Dina-SIG which I founded, and a feeling for his
work habits.
I have talked with Winnie at least four times since
Don died, and with a member of the family who has
understanding of modern Windoze computers. I wrote an
'Appreciation' of Don for Sellam's last Vintage
Computer Fair (did you use it, Sellam? you never told
me), with a photo of Don and Winnie supplied by that
member of the family.
I HAVE GOTTEN NOWHERE.
The weekend following Thanksgiving was suggested by a
family member as good time to enter the garage and
find the archive and take first stock of Don's
'stuff'.
Winnie said no, she was too busy.
Sometime around Christmas was again suggested as a
good time, as a family member would be available to
move things so that my wheelchair could get to Don's
machine. Again, Winnie said no, she was too busy.
She told me that she would contact me after the
holidays, and that she still intended to have me do
the
job. When I had not heard from her at the end of
February, I called again.
She said she was angry with Don for never having told
her of the major intellectual work of the last 15
years
of his life, for having left no instructions. Of
course, she had no interest in his computer life and
he
would not have tried to explain this to her. She knew
that he sent and received disks - but never had the
interest to ask about them.
From Winnie's view, Don left her with a burden that
she
does not want to deal with.
In my last talk with her, I repeated my offer to
inventory the contents of the garage, remove the
contents to a storage facility of my own, do the
archival work, get rid of the junk machines, and sell
the valuable machines FOR HER ACCOUNT, ON MY OWN
NICKEL.
The sentences I recall most vividly from that
conversation are "you will just have to wait until I
decide. After all, what else can you do?" And, "I'll
have Debbie [a family member who uses computers in her
work life] call you sometime - but she's very busy."
Her manner with me was unsupportable; I made an
sgreement which kept her free from annoyance, and she
will not honor her part. It's been 8 months now, time
to keep her part of the agreement. No, she hasn't the
slightest idea what an operating system or what the
archive is and, despite extended explanations, will
not
learn or care. I believe she cannot understand that
any
adult could be interested in old computers.
I believe the day will come when she will simply call
a
trash man and have her garage cleared. I do NOT
believe
that she will honor her committment to me.
*
So - where do we go from here? I have done all I can.
I
have agonized over this statement, wanting to release
a
progress report, unable to do so when there was no
progress to report. But now, I have to do this.
As I see it, there are four likely possibilities.
1. The community decide to inundate her with letters
requesting her to allow me to do as I have said I
would
do.
2. A reputable member of the community (I would
suggest
Jay West) approach her and try to get her to see
reason
and work out some arrangement.
3. Allow Don's archive to go to the trash bin when she
finally decides to have her garage cleaned out.
4. Allow the sharks to go after her, trying to get
their hands on the stuff in Don's garage.
*
I AM NOT SUGGESTING ACTION AT THIS POINT. I AM
SUGGESTING A DISCUSSION WITHIN THIS GROUP (WHERE DON
SPENT MOST OF HIS ONLINE TIME), FOLLOWED BY A GROUP
DECISION TO BE IMPLEMENTED. (For that purpose, I will
be turning on individual messages instead of the
digest
form in which I read this group.)
I WOULD STILL SAY THAT, UNTIL CLASSICCMP HAS ACHIEVED
A
CONSENSUS OF THE BEST COURSE OF ACTION,
DO ***NOT*** CONTACT WINNIE MASLIN.
I will send a copy of this message to Winnie by post.
Vern Wright
vern4wright at yahoo.com
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
14 May
14 May
4:34 p.m.
Vern -
I appreciate all your efforts. Don and I traded floppies back
and forth several times in the 90's, and I know that I only ever
saw a tiny segment of all that he had archived. I wish I could offer
you good advice but I have seen large academic and corporate
archives disappear when a division is eliminated or folded into
another entity, and all efforts of those who were truly interested
came to naught. I hope, that because this is only a single person
who has to be convinced, that your work efforts do pay off. Good
luck!
Tim.
4:35 p.m.
Thank you for your sincere efforts. Apart from our desire to preserve
Don's disk collection and documents, I'm sure his wife is still dealing
with grief and associated connections to all of his "stuff" being around.
I am sure you can imagine that she may not be able to voice the feeling
that if all of his stuff goes, it makes more concrete his absence.
If there's any route to her slow reassurance and eventual willingness
to pass along these possessions to others, it might be through her kids or
other relatives. Did she have any? Are there other local or
close friends who might be able to lend her advice?
- John
4:52 p.m.
On Sat, 2005-05-14 at 13:24 -0700, Vernon Wright wrote:
2. A reputable member of the community (I would
suggest Jay West) approach her and try to get her to see
reason and work out some arrangement.
I'd suggest someone from a museum on that side of the pond - if approach
by an official non-profit entity doesn't get the point across that it's
the preservation of the archive that's important, then I doubt any
private collectors will.
It sounds like she doesn't want the trouble of dealing with it all, but
doesn't want anyone potentially making a profit out of it (fair enough).
Not that anyone would be making a profit, but it sounds like she has it
in her head that someone might. Approach by a museum might persuade her,
and be able to take over farming out of the preservation to appropriate
people... (and disposing of assets on her behalf where appropriate)
cheers
Jules
5:45 p.m.
Unfortunately, the San Diego Computer Museum (formerly the Computer Museum
of America) has its own problems right now -- they need a new home.
http://www.computer-museum.org/
Of course I can't speak for them. Vernon, maybe SDCM's David Weil can help.
Sellam -- can CHM help?
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Jules Richardson
Sent: Saturday, May 14, 2005 4:53 PM
To: cctalk at classiccmp.org
Subject: Re: The Don Maslin Software Archive
On Sat, 2005-05-14 at 13:24 -0700, Vernon Wright wrote:
2. A reputable member of the community (I would
suggest Jay West)
approach her and try to get her to see reason and work out some
arrangement.
I'd suggest someone from a museum on that side of the pond - if approach by
an official non-profit entity doesn't get the point across that it's the
preservation of the archive that's important, then I doubt any private
collectors will.
It sounds like she doesn't want the trouble of dealing with it all, but
doesn't want anyone potentially making a profit out of it (fair enough).
Not that anyone would be making a profit, but it sounds like she has it in
her head that someone might. Approach by a museum might persuade her, and be
able to take over farming out of the preservation to appropriate people...
(and disposing of assets on her behalf where appropriate)
cheers
Jules
6:23 p.m.
I had dealt with Don for years, sending him disks when I came accross them
and getting them from him when needed.
His archive is irreplaceable.
If it would help we can create a list of signatures (or at least email
addresses) of people that Don has helped in the past to show the
significance.
As far as Don's collection goes I personally believe the disks and disk
images I sent to Don were for the good of all but after the data is rescued
any monetary value is part of his estate. Don always advertized the archive
as the DynaSig archive not as Don's personal cash cow. Don put sweat and
effort in to help all and I for one am grateful, I hope his wife gets fair
market value for his computers.
It may be useful to start a new archive anyway, even if Don's archive is
rescued it could be handy to have more ready.
If people are interested maybe we can make a list of what we have to donate.
Right now I am already working with others to archive several systems.
Please remember archiving does not just mean the latest or best system but
as many versions as possible even if you only prefer one specific version.
Randy
www.s100-manuals.com
7:19 p.m.
Vernon Wright wrote:
For any newbies to the group:
1. Don Maslin (San Diego, CA) collected what I
believe is the largest and most complete archive
of CP/M/S100 operating systems amongst us 'hobbyists'.
It's beginning to sound like it might be easier to start a
new archive than try to recover this one.
Whatever is done, it should be easily distributed so a
similiar problem does not happen again. If one site
disappears, there should be several others ready to
continue.
Make all the images available over the internet, with
instructions on how to create "physical" versions,
as well as the software necessary to create them (source
code preferred).
Some of the disks would need special hardware to
recreate, but that could be documented with the
image, along with a list of anyone who has the
necessary equipment and would be willing to
recreate it for them.
Set it up so that it is easy for anyone to supply such
image files.
Maybe at some point, Don's library could be merged
back in.
7:51 p.m.
New subject: Creating a new CP/M archive was Re: The Don Maslin Software Archive
From: "Kevin Handy" <kth at srv.net>
Sent: Saturday, May 14, 2005 6:19 PM
Vernon Wright wrote:
Some disk formats are completely incompatible with standard PC hardware
(such as Altair hard sectored disks).
Some disk formats are incompatible with some PC hardware, most PC's do not
support FM - Single Density, some systems used formats that were specific to
WD controllers and not compatible to the NEC (and NEC clones) used by PC's.
For formats compatible with PC controllers there is a utility called
teledisk that is commonly used to backup/restore. Anadisk is another tool
that can extract the data.
For other formats there are a variety of methods including:
Catweasel - handles anything.
SVD - Semi-Virtual Diskette (http://www.rothfus.com/SVD/) that emulates a
standard drive and requires a working classic computer to create the image.
Serial port transfer of disk image - Dave Dunfield has one for NorthStar and
one for Cromemco (http://www.parse.com/~ddunfield/museum/)
There are plenty of other methods, the problem is finding/building the right
hardware.
If anyone has disks that they would like to donate I'd be happy to help by
either walking you through creation of the disk image or for most formats
you can send me a disk and I can create a disk image.
Randy
www.s100-manuals.com
For any newbies to the group:
1. Don Maslin (San Diego, CA) collected what I believe is the largest and
most complete archive of CP/M/S100 operating systems amongst us
'hobbyists'.
It's beginning to sound like it might be easier to start a
new archive than try to recover this one.
Whatever is done, it should be easily distributed so a
similiar problem does not happen again. If one site
disappears, there should be several others ready to
continue.
Make all the images available over the internet, with
instructions on how to create "physical" versions,
as well as the software necessary to create them (source
code preferred).
Some of the disks would need special hardware to
recreate, but that could be documented with the
image, along with a list of anyone who has the
necessary equipment and would be willing to
recreate it for them.
Set it up so that it is easy for anyone to supply such
image files.
Maybe at some point, Don's library could be merged
back in. 
15 May
15 May
4:40 p.m.
New subject: Creating a new CP/M archive was Re: The Don Maslin Software Archive
Some disk formats are completely incompatible with
standard PC hardware
(such as Altair hard sectored disks).
Yes, but provided the file format is docuemnted, there's always a
possibility womebody can make the special hardware, or use the target
machine to write the disk (with the data sent, say, over an RS232 link).
Some disk formats are incompatible with some PC hardware, most PC's do not
support FM - Single Density, some systems used formats that were specific to
WD controllers and not compatible to the NEC (and NEC clones) used by PC's.
For formats compatible with PC controllers there is a utility called
teledisk that is commonly used to backup/restore. Anadisk is another tool
that can extract the data.
I would strongly discourage the use of Teledisk for this. The file format
is proprietary, and although there have been some attempts to
reverse-engineer it, AFAIK the full details aren't know (particularly of
Teledisk compressed files). If you use Teledisk, you _have_ to use an
MS-DOS PC to re-write the data to a physical disk (and a PC with the
appropriate type of floppy drive), you _have_ to get Teledisk (last time
I checked, it wasn't free, it was shareware, but you could no longer
register it...). etc. If your PC can't write FM formats, then you're
stuck (even if you've got 100 machines that _can_ write such formats, and
which can get data from a PC disk or similar).
Any such archive must be made as accessible as possible, and that means
using documented file formats. To be honest, I'd rather have to write my
own software than do battle with a proprietary PC program.
-tony
16 May
16 May
4:33 p.m.
New subject: Disk archival
Tony Duell wrote:
I would strongly discourage the use of Teledisk for
this. The file format
is proprietary, and although there have been some attempts to
reverse-engineer it, AFAIK the full details aren't know (particularly of
Teledisk compressed files).
F-prot has been able to scan inside teledisk images for over a decade. One of
the authors graciously let me look at the source a while ago and the
compression is nothing more than LHA (ie the free lharc source by yoshi). I
might still have the source somewhere, but it's buried in email archives going
back a decade. If someone needs it to do something useful, let me know
off-list and I can try to dig it up. (It would give me an excuse to finally
organize and index my email archives!)
If you use Teledisk, you _have_ to use an
MS-DOS PC to re-write the data to a physical disk (and a PC with the
appropriate type of floppy drive), you _have_ to get Teledisk (last time
I checked, it wasn't free, it was shareware, but you could no longer
register it...). etc. If your PC can't write FM formats, then you're
stuck (even if you've got 100 machines that _can_ write such formats, and
which can get data from a PC disk or similar).
The problem with various methods of archiving diskettes is that they are all
proprietary methods with drawbacks:
Disk2FDI: works with any disk, requires dual-drive PC or special cable, file
format is bitstream and extremely complicated to work with
Central Point Option Board: works with FM/MFM/GCR disks, requires special hardware
Catweasel: works with any disk, requires special hardware, no mature software
exists specifically for archiving, no mature/stable file format
Teledisk: works with MFM disks only, file format not published, limited
CopyIIPC+Snatchit: works with MFM disks only, requires old PC, file format not
understood
Nobody has tackled this to any great capacity. Disk2FDI is the best option
right now since the file format is well described, but at the same time the
files produced by Disk2FDI are nothing more than bitstreams that are nearly
impossible to work with without knowledge of the controller hardware. (In
fact, the only application other than Disk2FDI that works with FDI images is
WinUAE, since it emulates the disk controller at all levels.)
When I started archiving my 5.25" software in the 1990s, much of it
copy-protected, I settled on the Central Point Option Board. This was for
several reasons: I knew I would always have 8088-80386 hardware to use with
the board; I only had MFM/FM/GCR disks to archive (ie no
hard-sectored/proprietary/goofy formats); the file format is a hybrid of raw
(gap length, header info) and cooked (actual sector DATA stored as bytes) which
was the most useful to me (without any knowledge of the archive file, I can do
"strings filename.img" and read plaintext data. Whenever I saw an option board
for sale @ $20 or less (usually not on ebay), I would pick it up as a spare. I
have 5 "spares" now :-)
Any such archive must be made as accessible as
possible, and that means
using documented file formats. To be honest, I'd rather have to write my
own software than do battle with a proprietary PC program.
But then *your* program would be proprietary :-)
What is needed, and has been attempted and mostly failed by several different
people, is this:
- A standard method of describing not only what is stored on a diskette, but
HOW and WHY (to make sense of all the gap/header/sync/etc. bits)
- A common way of getting that information off the disk, which will probably
require interfaces to PCs or MACs because the original hardware may not be able
to provide every single flux off the disk
- Well written "disk controller emulation" utility programs to translate the
archived stream of bits into useful data, the highest priority being the
ability to extract individual files
As you can imagine, everyone has their own idea on how to do this. Not
surprisingly, the people who have had the most headway with projects like this
have been software pirates (reformed, grown-up, 9-to-5 job software pirates)
who -- though they mean well -- have a very limited vision of what archival is.
(Meaning, if you can read the files, and run the program, it's good to them.
Who knows what kind of alterations had to be made to get to that point, but
they don't care. I personally WANT copy-protection to remain intact, etc. I
want exact copies.)
Until some common standard is defined and widely accepted and applies equally
to every type of diskette-based magetic medium, I'll just keep on doing what
I'm doing that works for me, and I'll contribute my work to the global standard
if/when it exists. Just because there isn't a standard doesn't mean I should
hold off archiving.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
5:55 p.m.
New subject: Disk archival
On Mon, 16 May 2005, Jim Leonard wrote:
What is needed, and has been attempted and mostly
failed by several different
people, is this:
- A standard method of describing not only what is stored on a diskette, but
HOW and WHY (to make sense of all the gap/header/sync/etc. bits)
- A common way of getting that information off the disk, which will probably
require interfaces to PCs or MACs because the original hardware may not be able
to provide every single flux off the disk
- Well written "disk controller emulation" utility programs to translate the
archived stream of bits into useful data, the highest priority being the
ability to extract individual files
http://www.futurekeep.org
Until some common standard is defined and widely
accepted and applies
equally to every type of diskette-based magetic medium, I'll just keep
on doing what I'm doing that works for me, and I'll contribute my work
to the global standard if/when it exists. Just because there isn't a
standard doesn't mean I should hold off archiving.
The FutureKeep project will solve all these issues. Now, if only someone
can solve the issue of adding another couple hours to the day ;)
--
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 ]
6:07 p.m.
New subject: Disk archival
Vintage Computer Festival wrote:
What I hinted at, but did not explicitly say, is that actually coming up with
such a standard is such a herculean effort that I doubt I will see it happen in
my lifetime :-)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
6:35 p.m.
New subject: Disk archival
On Mon, 16 May 2005, Jim Leonard wrote:
Vintage Computer Festival wrote:
What I hinted at, but did not explicitly say, is that actually coming up
with such a standard is such a herculean effort that I doubt I will see
it happen in my lifetime :-)
Ok, just you wait and see ;)
--
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 ]
7:01 p.m.
New subject: Disk archival
----- Original Message -----
From: "Vintage Computer Festival" <vcf at siconic.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Monday, May 16, 2005 6:35 PM
Subject: Re: Disk archival
On Mon, 16 May 2005, Jim Leonard wrote:
Festival
Why can't a group just incorporate the images that are already made by
machine specific groups? There is a huge scene for Atari, Commodore, Timex,
Amiga, Tandy, etc that has already made images of just about every
commercial and PD disk for their platform. Asking a group that already has
everything dumped to use special tools to redump them for some other group
is a waste of their time. I think it would be better just to document what
each group does now, archive those images, and then create some software
that can recreate any of the images back to disk as needed.
Vintage Computer Festival wrote:
What I hinted at, but did not explicitly say, is that actually coming up
with such a standard is such a herculean effort that I doubt I will see
it happen in my lifetime :-)
Ok, just you wait and see ;)
--
Sellam Ismail Vintage Computer
7:11 p.m.
New subject: Disk archival
On Mon, 16 May 2005, Teo Zenios wrote:
Why can't a group just incorporate the images that
are already made by
machine specific groups? There is a huge scene for Atari, Commodore, Timex,
Amiga, Tandy, etc that has already made images of just about every
commercial and PD disk for their platform. Asking a group that already has
everything dumped to use special tools to redump them for some other group
is a waste of their time. I think it would be better just to document what
each group does now, archive those images, and then create some software
that can recreate any of the images back to disk as needed.
Because not all (if any) groups have dumped to images of any manner of
archival standard. All we have today is a mish-mash of miscellaneous
images not dumped in a manner that preserves as much information
(metadata) of the original media as possible.
This is the problem that FutureKeep aims to resolve. Existing images will
be able to be converted to the FutureKeep standard, but they will lack
essential metadata. Once FutureKeep exists, it is hoped that any new
images made will be done in that universal standard. It is also hoped
that volunteers will go back and re-image all possible software in the
FutureKeep file format.
--
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 ]
17 May
17 May
12:20 a.m.
New subject: Disk archival
Vintage Computer Festival wrote:
This is the problem that FutureKeep aims to resolve.
Existing images will
be able to be converted to the FutureKeep standard, but they will lack
essential metadata. Once FutureKeep exists, it is hoped that any new
images made will be done in that universal standard. It is also hoped
that volunteers will go back and re-image all possible software in the
FutureKeep file format.
No offense to anyone who may be part of the project, but that's a pipe dream.
I think a better goal is to create conversion utilities that perform
cross-conversion to/from FutureKeep format, as that is much more realistic.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
12:58 a.m.
New subject: Disk archival
From: "Jim Leonard" <trixter at oldskool.org>
Sent: Monday, May 16, 2005 11:20 PM
Vintage Computer Festival wrote:
I looked at FutureKeep, as far as I can tell there is no FutureKeep format.
There are a variety of real formats but no FutureKeep format.
I'd like to archive media in one standard format with metadata but until
anyone every developes a standard I'll stck to what is real even if it means
using different formats for different systems.
Randy
www.s100-manuals.com
This is the problem that FutureKeep aims to
resolve. Existing images
will
be able to be converted to the FutureKeep standard, but they will lack
essential metadata. Once FutureKeep exists, it is hoped that any new
images made will be done in that universal standard. It is also hoped
that volunteers will go back and re-image all possible software in the
FutureKeep file format.
No offense to anyone who may be part of the project, but that's a pipe
dream. I think a better goal is to create conversion utilities that
perform cross-conversion to/from FutureKeep format, as that is much more
realistic.
--
Jim Leonard (trixter at oldskool.org)
http://www.oldskool.org/
Want to help an ambitious games project?
http://www.mobygames.com/
Or check out some trippy MindCandy at
http://www.mindcandydvd.com/
10:19 a.m.
New subject: Disk archival
On Mon, 16 May 2005, Jim Leonard wrote:
Vintage Computer Festival wrote:
What part? At any rate, my answer is "Not at all."
This is the problem that FutureKeep aims to
resolve. Existing images will
be able to be converted to the FutureKeep standard, but they will lack
essential metadata. Once FutureKeep exists, it is hoped that any new
images made will be done in that universal standard. It is also hoped
that volunteers will go back and re-image all possible software in the
FutureKeep file format.
No offense to anyone who may be part of the project, but that's a pipe dream. I think a better goal is to create conversion
utilities that perform
cross-conversion to/from FutureKeep format, as that is much more realistic.
That will also be done, but I would prefer to re-do images that don't have
sufficient metadata.
--
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 ]
3:40 p.m.
New subject: Disk archival techniques
On Mon, 16 May 2005, Jim Leonard wrote:
No offense to anyone who may be part of the project,
but that's a pipe dream.
I think a better goal is to create conversion utilities that perform
cross-conversion to/from FutureKeep format, as that is much more realistic.
I completely agree. Lessons from the past are simple to grok.
There is no complex data standard and certainly no media that has
survived long enough to be considered permanent.
My bias is towards the simple; at least then when it's
incompatible you have less raw data, and less-ambiguous work (you
hope).
The more the payload data is encumbered with organization,
formatting, compression, interpretation, etc the harder it is.
There's no universal approach, but if we're talking about mainly
floppies, a simple sector dump (note 1) with a hand-written
description of the organization would probably suffice.
An example:
* a byte stream copy (note 1) of the diskette image, say 256256
8-bit-bytes long. Even printed on paper. Who knows what OCR will
be like in 20 years?
* A scrap of paper upon which is written:
"Copied from a Shugart 801, 8", single-sided, soft-sectored,
WD1771 FM format. CP/M-80. 128 byte sectors, 26 spt, 77
tracks."
Dumb. Simple. Repeatable. Portable as anything will be after 1, 5,
10, 20 years.
NOTE 1: you can either rely on a byte today being a byte tomorrow,
or define a mapping that is unambiguous, such as a description of
the local file system's byte ordering, or use a text
representation of the numbers (disk as a string) with a Rosetta
Stone for ASCII, or define as decimal, etc.
Cruder is better. A representation of the diskette contents
consisting of:
0: 0
1: 255
2: 47
...
256253: 229
256253: 229
256255: 229
with the prose description above is more than enough to simply
recreate the diskette, whatever that means.
4:07 p.m.
New subject: Disk archival techniques
From: "Tom Jennings" <tomj at wps.com>
Sent: Tuesday, May 17, 2005 2:40 PM
On Mon, 16 May 2005, Jim Leonard wrote:
One big problem with staight dumps of data is that often the media is not
homogenous.
Cromemco requires that the first track of the floppy disk be written in FM
but the other tracks can be MFM.
NorthStar allows complete mixture of FM & MFM on a single disk.
Jade requires the first track of bootable disks be MFM but the rest can be
FM.
Commodore 1541 has different number of sectors for different tracks.
Some meta information is needed but as stated simply good written info may
be enough.
I like and prefer media images as straight data dumps but I want the
formatting information of the original media somewhere. I even want data
No offense to anyone who may be part of the
project, but that's a pipe
dream. I think a better goal is to create conversion utilities that
perform cross-conversion to/from FutureKeep format, as that is much more
realistic.
I completely agree. Lessons from the past are simple to grok.
There is no complex data standard and certainly no media that has
survived long enough to be considered permanent.
My bias is towards the simple; at least then when it's
incompatible you have less raw data, and less-ambiguous work (you
hope).
The more the payload data is encumbered with organization,
formatting, compression, interpretation, etc the harder it is.
There's no universal approach, but if we're talking about mainly
floppies, a simple sector dump (note 1) with a hand-written
description of the organization would probably suffice.
An example:
* a byte stream copy (note 1) of the diskette image, say 256256
8-bit-bytes long. Even printed on paper. Who knows what OCR will
be like in 20 years?
* A scrap of paper upon which is written:
"Copied from a Shugart 801, 8", single-sided, soft-sectored,
WD1771 FM format. CP/M-80. 128 byte sectors, 26 spt, 77
tracks."
Dumb. Simple. Repeatable. Portable as anything will be after 1, 5,
10, 20 years.
NOTE 1: you can either rely on a byte today being a byte tomorrow,
or define a mapping that is unambiguous, such as a description of
the local file system's byte ordering, or use a text
representation of the numbers (disk as a string) with a Rosetta
Stone for ASCII, or define as decimal, etc.
Cruder is better. A representation of the diskette contents
consisting of:
0: 0
1: 255
2: 47
...
256253: 229
256253: 229
256255: 229
with the prose description above is more than enough to simply
recreate the diskette, whatever that means. from media that is incomplete or has errors, also
documented.
In the past I've done cut and paste reconstruction of data from damaged
originals.
As for corrupted media bit dumps (including formatting bits not normally
saved in data dumps) can be a godsend, it may be possible to reconstruct
corrupted data streams by bit shifting.
Randy
www.s100-manuals.com
4:48 p.m.
New subject: VT220
Hello. I am playing with one VT220 plugged to the serial port of one Pentium
4 laptop. I have Cygwin installed, with Init and getty started, and the
serial port defined with VT200 and 9600 bauds, and I want to open one
session under Cygwin from the VT220. Of course something happens under
Cygwin, because every "enter" opens a new login in the ps list under Cygwin.
But nothing appears in the VT220 screen...
With this previous explain, the question for gurus is: Would I need one DEC
cable to plug the VT220 (by the way, 25 pin interface) in the Laptop Serial
`port (9 pin port) ? Or can I use a normal serial cable ?
Thanks and Regards
Sergio
4:51 p.m.
New subject: VT220
On Tue, 2005-05-17 at 22:48 +0200, SP wrote:
Hello. I am playing with one VT220 plugged to the
serial port of one Pentium
4 laptop. I have Cygwin installed, with Init and getty started, and the
serial port defined with VT200 and 9600 bauds, and I want to open one
session under Cygwin from the VT220. Of course something happens under
Cygwin, because every "enter" opens a new login in the ps list under Cygwin.
But nothing appears in the VT220 screen...
With this previous explain, the question for gurus is: Would I need one DEC
cable to plug the VT220 (by the way, 25 pin interface) in the Laptop Serial
`port (9 pin port) ? Or can I use a normal serial cable ?
Normal serial cable will work -- but you'll need a null modem in between
there.
Brian
4:54 p.m.
New subject: VT220
>>>> "SP" == SP <spedraja at
ono.com> writes:
SP> Hello. I am playing with one VT220 plugged to the serial port of
SP> one Pentium 4 laptop. I have Cygwin installed, with Init and
SP> getty started, and the serial port defined with VT200 and 9600
SP> bauds, and I want to open one session under Cygwin from the
SP> VT220. Of course something happens under Cygwin, because every
SP> "enter" opens a new login in the ps list under Cygwin. But
SP> nothing appears in the VT220 screen...
SP> With this previous explain, the question for gurus is: Would I
SP> need one DEC cable to plug the VT220 (by the way, 25 pin
SP> interface) in the Laptop Serial `port (9 pin port) ? Or can I use
SP> a normal serial cable ?
A plain old 25 to 9 Null Modem cable should work. It sounds like you
have that, because you see something happening at the host end.
There may be a flow control mismatch. If your PC serial port is set
up to use RTS/CTS flow control, that would account for no output
showing up. I forgot if the VT220 supports that flavor of flow
control. Look through the Setup. If not, change the PC settings to
"no flow control" (or better yet, XON/XOFF, if that's available).
paul
5:21 p.m.
New subject: VT220
On Tue, 2005-05-17 at 22:48 +0200, SP wrote:
Hello. I am playing with one VT220 plugged to the
serial port of one Pentium
4 laptop. I have Cygwin installed, with Init and getty started, and the
serial port defined with VT200 and 9600 bauds, and I want to open one
session under Cygwin from the VT220. Of course something happens under
Cygwin, because every "enter" opens a new login in the ps list under Cygwin.
But nothing appears in the VT220 screen...
Possible terminal emulation problem?
Are you saying that you see 'login' itself in the ps each time enter is
pressed? That'd seem more like a getty misconfiguration to me; makes it
sound like login's getting hung up somewhere before the user's
environment is set up.
Never used cygwin before, but is there anything meaningful in the system
logfiles?
You are seeing *something* on the VT220 aren't you? (login prompt or
whatever)
cheers
Jules
18 May
18 May
11:43 a.m.
New subject: VT220
SP wrote:
Hello. I am playing with one VT220 plugged to the
serial port of one Pentium
4 laptop. I have Cygwin installed, with Init and getty started, and the
serial port defined with VT200 and 9600 bauds, and I want to open one
session under Cygwin from the VT220. Of course something happens under
Cygwin, because every "enter" opens a new login in the ps list under Cygwin.
But nothing appears in the VT220 screen...
With this previous explain, the question for gurus is: Would I need one DEC
cable to plug the VT220 (by the way, 25 pin interface) in the Laptop Serial
`port (9 pin port) ? Or can I use a normal serial cable ?
Login will usually respond to any kind of garbage sent through
the serial port. Ok if everything is already set up, but useless
for real debuging.
Make sure you are NOT using a DEC 9-pin to 25-pin cable when
plugging into the PC. DEC's 9-pin layout is different than IBM's.
Do you need a null modem? I've had PCs with opposite "polaritry"
before. Those cheap RS232 testers available from RadioShack (and
others) are useful here (i.e. a block with two DB25's and a lot of leds);
if both 2-3 light up, cabling is probably ok and you don't need to
add a null modem; if only one does then you probably need one;
if none light, you have another problem.
Test that the terminal works. Tie pins 2 and 3 together (on the VT220's
25-pin connector) to make a loopback connector (paper clips often
come in handy here), and try typing on its keyboard. It should echo.
If you don't get echo, then the line drivers are blown.
Also double check baud rates and bit-sizes (Try 8bit-no parity-one stop
bit).
Another thing to try is to write a program that sends a continuous stream
of characters to the serial port. Make sure it doesn't hang while outputing
(indicates it's a flow control problem). Then you can play with the VT220
settings without needing login working properly.
Or you can use kermit (or another terminal program) from the PC. Type
on the VT220 keyboard, and you should see what you typed on the PC.
Also vice versa. you can see if characters are flowing on one direction
or the other properly that way. If you get garbled characters, you have
[baud-rate, char width, stop bit, cabling, etc] problems.
Try slower speeds (300 baud). Could be a time-base problem in one or
the other devices. Slower speeds may not be as badly affected.
17 May
17 May
5:04 p.m.
New subject: Disk archival techniques
On Tue, 2005-05-17 at 15:07 -0500, Randy McLaughlin wrote:
I like and prefer media images as straight data dumps
but I want the
formatting information of the original media somewhere. I even want data
from media that is incomplete or has errors, also documented.
Yep, me too. From when we were bashing around ideas about this though a
few months back it seems that's a minority viewpoint; most people want
data embedded in the metadata.
For hard drive images I zero-pad any bad data but also include metadata
in a seperate file - including disk geometry, which blocks are bad,
resulting dump checksum, timestamp etc. along with anything else that
might be particularly useful. For floppy images things would be
significantly more complex though (due to factors as mentioned - variant
sectors/track, different encoding for different tracks etc.)
The idea behind futurekeep though was to make the metadata highly
structured and in a similar vein to HTML in that clients could handle as
much of the data as needed (eg. someone not dealing with variable bit
rate images wouldn't need a decoder that could handle them). Ideally
it'd be human-readable too (after a fashion) - e.g. XML - so that the
data could be reconstructed into a disk image "by hand" even if some
whizzy util to do it wasn't present. (understanding it at a file level
is obviously outside the scope)
That doesn't seem *too* much to ask; basic metadata can be created for
existing images without a lot of hassle *if desired*. To me such a
format's more useful for future image creation though, particularly in
the case of less-common systems; the popular machines are likely to be
covered by their own archive formats already and the following large
enough that lack of data is not (yet) a problem. Rather than messing
around with proprietary image formats for those, or formats that aren't
particularly descriptive, it'd be nice to start from day 1 using
something that allows us to capture all the useful stuff that goes along
with the raw data.
cheers
Jules
6:06 p.m.
New subject: Disk archival techniques
As coincidence would have it, I work at Indiana University's Digital
Library Program and there was a lecture on archiving audio which hits
many of the same issues that have come up here. The conclusions that
they came up with for the project included:
* There's no such thing as an eternal media: the data must be
transportable to the latest generation of storage
* Metadata should be bundled with the content
* Act like you get one chance to read the media :(
While this is a different context, the principle is basically the same.
I've got a pile of TK50 tapes I'm backing up using the SIMH tape format,
so this is relevant to that process as well.
I think the optimum format for doing this isn't a single file, but a
collection of files bundled into a single package. Someone mentioned
tar, I think, and zip would work just as well. The container could
contain these components:
* content metadata - info from the disk's label/sleeve, etc
* media metadata - the type of media this came from
* archivist metadata - who did it, methods used, notes, etc
* badblock information - 0 blocks which are actually bad.
* content - a bytestream of the data
I don't think there's any real need to document the physical properties
of the media for EVERY disk archived -- there should probably be a
repository of 'standard' media types (1541's different-sectors-per-track
info, FM vs MFM per track information, etc) plus overrides in the media
metadata (uses fat-tracks, is 40 track vs 35, etc).
Emulators could use the content part of the file as-is and collectors
would have enough information to recreate the original media. It would
also allow for cataloging fairly easily.
Brian
On Tue, 2005-05-17 at 21:04 +0000, Jules Richardson wrote:
On Tue, 2005-05-17 at 15:07 -0500, Randy McLaughlin
wrote:
I like and prefer media images as straight data
dumps but I want the
formatting information of the original media somewhere. I even want data
from media that is incomplete or has errors, also documented.
Yep, me too. From when we were bashing around ideas about this though a
few months back it seems that's a minority viewpoint; most people want
data embedded in the metadata.
For hard drive images I zero-pad any bad data but also include metadata
in a seperate file - including disk geometry, which blocks are bad,
resulting dump checksum, timestamp etc. along with anything else that
might be particularly useful. For floppy images things would be
significantly more complex though (due to factors as mentioned - variant
sectors/track, different encoding for different tracks etc.)
The idea behind futurekeep though was to make the metadata highly
structured and in a similar vein to HTML in that clients could handle as
much of the data as needed (eg. someone not dealing with variable bit
rate images wouldn't need a decoder that could handle them). Ideally
it'd be human-readable too (after a fashion) - e.g. XML - so that the
data could be reconstructed into a disk image "by hand" even if some
whizzy util to do it wasn't present. (understanding it at a file level
is obviously outside the scope)
That doesn't seem *too* much to ask; basic metadata can be created for
existing images without a lot of hassle *if desired*. To me such a
format's more useful for future image creation though, particularly in
the case of less-common systems; the popular machines are likely to be
covered by their own archive formats already and the following large
enough that lack of data is not (yet) a problem. Rather than messing
around with proprietary image formats for those, or formats that aren't
particularly descriptive, it'd be nice to start from day 1 using
something that allows us to capture all the useful stuff that goes along
with the raw data.
cheers
Jules
6:30 p.m.
New subject: Disk archival techniques
From: "Brian Wheeler" <bdwheele at indiana.edu>
Sent: Tuesday, May 17, 2005 5:06 PM
As coincidence would have it, I work at Indiana
University's Digital
Library Program and there was a lecture on archiving audio which hits
many of the same issues that have come up here. The conclusions that
they came up with for the project included:
* There's no such thing as an eternal media: the data must be
transportable to the latest generation of storage
* Metadata should be bundled with the content
* Act like you get one chance to read the media :(
While this is a different context, the principle is basically the same.
I've got a pile of TK50 tapes I'm backing up using the SIMH tape format,
so this is relevant to that process as well.
I think the optimum format for doing this isn't a single file, but a
collection of files bundled into a single package. Someone mentioned
tar, I think, and zip would work just as well. The container could
contain these components:
* content metadata - info from the disk's label/sleeve, etc
* media metadata - the type of media this came from
* archivist metadata - who did it, methods used, notes, etc
* badblock information - 0 blocks which are actually bad.
* content - a bytestream of the data
I don't think there's any real need to document the physical properties
of the media for EVERY disk archived -- there should probably be a
repository of 'standard' media types (1541's different-sectors-per-track
info, FM vs MFM per track information, etc) plus overrides in the media
metadata (uses fat-tracks, is 40 track vs 35, etc).
Emulators could use the content part of the file as-is and collectors
would have enough information to recreate the original media. It would
also allow for cataloging fairly easily.
Brian
<snip>
I disagree on a few points:
Today we know what the 1541 structure is, we need enough detail to explain
it to future users.
The differences between FM and MFM are not as simple as a binary decision.
RX02 is one example of mixed formatting, even with FM & MFM each
implimentation can be fairly unique (hard vs. soft sectored, sector size,
flux density, etc).
Most of the exact details can be understood by using current knowledge but
maybe not 50 years from now when someone is trying to understand it.
One thing can be that for a given format part of the overall archive should
include technical details:
That is to say one example would be a site like asimov should include
technical information on the apple disk interface as well as an explaination
of how the dsk images are created and restored. It isn't necessary to
include the details with every dsk file but withing the general archive.
In the 1940's how many people were able to build a radio reciever with what
they found in the battle field (razor blade, safety pin, knife, wire,
headset), how many could today? The same applies to computer technology.
Randy
www.s100-manuals.com
18 May
18 May
9:13 a.m.
New subject: Disk archival techniques
On Tue, 2005-05-17 at 17:30 -0500, Randy McLaughlin wrote:
From: "Brian Wheeler" <bdwheele at
indiana.edu>
Sent: Tuesday, May 17, 2005 5:06 PM
As coincidence would have it, I work at Indiana
University's Digital
Library Program and there was a lecture on archiving audio which hits
many of the same issues that have come up here. The conclusions that
they came up with for the project included:
* There's no such thing as an eternal media: the data must be
transportable to the latest generation of storage
* Metadata should be bundled with the content
* Act like you get one chance to read the media :(
While this is a different context, the principle is basically the same.
I've got a pile of TK50 tapes I'm backing up using the SIMH tape format,
so this is relevant to that process as well.
I think the optimum format for doing this isn't a single file, but a
collection of files bundled into a single package. Someone mentioned
tar, I think, and zip would work just as well. The container could
contain these components:
* content metadata - info from the disk's label/sleeve, etc
* media metadata - the type of media this came from
* archivist metadata - who did it, methods used, notes, etc
* badblock information - 0 blocks which are actually bad.
* content - a bytestream of the data
I don't think there's any real need to document the physical properties
of the media for EVERY disk archived -- there should probably be a
repository of 'standard' media types (1541's different-sectors-per-track
info, FM vs MFM per track information, etc) plus overrides in the media
metadata (uses fat-tracks, is 40 track vs 35, etc).
Emulators could use the content part of the file as-is and collectors
would have enough information to recreate the original media. It would
also allow for cataloging fairly easily.
Brian
<snip>
I disagree on a few points:
Today we know what the 1541 structure is, we need enough detail to explain
it to future users. The differences between FM and MFM are not as simple
as a binary decision.
RX02 is one example of mixed formatting, even with FM & MFM each
implimentation can be fairly unique (hard vs. soft sectored, sector size,
flux density, etc).
I guess what I was getting at is there should be a library of standard
types which fully define the format. 1541's look the same 99% of the
time unless half-tracks, fat tracks, or another copy protection scheme
was used. So if there's a library that fully defines what a 1541 _is_,
there's no reason to have that exact definition copied for each disk
archived. Not that it really takes up that much space, but it does make
it more tedious -- do you want to enter the track/sector geometry for
every disk you copy?
Most of the exact details can be understood by using
current knowledge but
maybe not 50 years from now when someone is trying to understand it.
True, but I suppose that's why we're discussing it now :)
One thing can be that for a given format part of the
overall archive should
include technical details:
That is to say one example would be a site like asimov should include
technical information on the apple disk interface as well as an explaination
of how the dsk images are created and restored. It isn't necessary to
include the details with every dsk file but withing the general archive.
Agreed. If there's an archive with the 'bundling software' which
handles the meta data, there should be a library of definitions there
that can be copied to each user's archive as needed.
Brian
10 a.m.
New subject: Disk archival techniques
On Wed, 2005-05-18 at 08:13 -0500, Brian Wheeler wrote:
I guess what I was getting at is there should be a
library of standard
types which fully define the format. 1541's look the same 99% of the
time unless half-tracks, fat tracks, or another copy protection scheme
was used. So if there's a library that fully defines what a 1541 _is_,
there's no reason to have that exact definition copied for each disk
archived. Not that it really takes up that much space, but it does make
it more tedious -- do you want to enter the track/sector geometry for
every disk you copy?
Ahh, OK - not a problem at image creation time, *providing* that the
image format includes all the data needed to recreate that disk
*without* the repository. In 30 years time, there's no guarantee that
the repository will be in the same format, or easy to get hold of etc.
so there's a danger that an image will be junk if all it has in it is a
label saying that the source disk was in "Fred's own disk layout"
format.
But yep, a repository could make the UI of any creation tools cleaner -
but it's a seperate project from the image format itself I think...
Personally I think it's achievable, providing we stick to worrying about
floppies at the moment. Tapes, hard drives, ROM images etc. can come
later - doubtless they'd share some field names, but the structure is
sufficiently* different that it's too much to take on in a first cut.
*OK, gut feeling it that it's not *that* different and floppy images are
actually the most complex of the lot. But as someone else has said, it's
too easy to get bogged down when trying to come up with a "do
everything" solution. I can't see that it matters if there ends up being
seperate futurekeep formats for different classes of media.
cheers
Jules
10:12 a.m.
New subject: Disk archival techniques
On Wed, 2005-05-18 at 14:00 +0000, Jules Richardson wrote:
On Wed, 2005-05-18 at 08:13 -0500, Brian Wheeler
wrote:
Good point. Yeah, the formatting information should probably be
included with every image, but a disk format repository solves alot of
the tedium.
I guess what I was getting at is there should be
a library of standard
types which fully define the format. 1541's look the same 99% of the
time unless half-tracks, fat tracks, or another copy protection scheme
was used. So if there's a library that fully defines what a 1541 _is_,
there's no reason to have that exact definition copied for each disk
archived. Not that it really takes up that much space, but it does make
it more tedious -- do you want to enter the track/sector geometry for
every disk you copy?
Ahh, OK - not a problem at image creation time, *providing* that the
image format includes all the data needed to recreate that disk
*without* the repository. In 30 years time, there's no guarantee that
the repository will be in the same format, or easy to get hold of etc.
so there's a danger that an image will be junk if all it has in it is a
label saying that the source disk was in "Fred's own disk layout"
format.
But yep, a repository could make the UI of any
creation tools cleaner -
but it's a seperate project from the image format itself I think...
Yes.
Personally I think it's achievable, providing we
stick to worrying about
floppies at the moment. Tapes, hard drives, ROM images etc. can come
later - doubtless they'd share some field names, but the structure is
sufficiently* different that it's too much to take on in a first cut.
Tapes are an issue since they're really not a stream of bytes -- there
are tape marks and gaps. The simh virtual tape format seems to be
fairly complete in that respect:
http://simh.trailing-edge.com/docs/simh_magtape.pdf
Brian
*OK, gut feeling it that it's not *that* different
and floppy images are
actually the most complex of the lot. But as someone else has said, it's
too easy to get bogged down when trying to come up with a "do
everything" solution. I can't see that it matters if there ends up being
seperate futurekeep formats for different classes of media.
cheers
Jules
1:29 p.m.
New subject: Disk archival techniques
From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
Sent: Wednesday, May 18, 2005 9:00 AM
On Wed, 2005-05-18 at 08:13 -0500, Brian Wheeler
wrote:
<snip>
Personally I think it's achievable, providing we
stick to worrying about
floppies at the moment. Tapes, hard drives, ROM images etc. can come
later - doubtless they'd share some field names, but the structure is
sufficiently* different that it's too much to take on in a first cut.
<snip>
cheers
Jules
For ROM images just a binary (or hex) file is sufficient since there is no
formatting involved.
The only information needed would be a description of what the heck it is.
If we were smart (a long stretch) we could store it as Intel hex preceded by
text descriptions (including a short description of the Intel hex format).
If the ROM is > 64K then a different hex format can be used.
ROMs and card image formats are simple enough that no great thought should
be wasted on them.
Papertapes generally come in two flavors: Text or binary, please note hex
tapes are text files. The leading and trailing nulls should be stripped but
the data should be kept the same i.e hex tapes should stay hex and not
converted to binary. I have seen people store hex data as binary which
strips load address data plus with Intel hex it is possible to load
different segments which gets lost when converted to binary.
Randy
www.s100-manuals.com
1:51 p.m.
New subject: Disk archival techniques
At 12:29 PM 5/18/2005, Randy McLaughlin wrote:
For ROM images just a binary (or hex) file is
sufficient since there is no formatting involved.
The only information needed would be a description of what the heck it is.
I kind of like the idea of the metadata being a quick scan of
the label of the ROM or the label of the floppy.
Does FutureKeep's format allow for metadata composed of a picture of
the object or a picture of the label?
- John
4:29 p.m.
New subject: Disk archival techniques
On Wed, 18 May 2005, John Foust wrote:
At 12:29 PM 5/18/2005, Randy McLaughlin wrote:
That's a new one.
--
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 ]
For ROM images just a binary (or hex) file is
sufficient since there is no formatting involved.
The only information needed would be a description of what the heck it is.
I kind of like the idea of the metadata being a quick scan of
the label of the ROM or the label of the floppy.
Does FutureKeep's format allow for metadata composed of a picture of
the object or a picture of the label?
8:06 p.m.
New subject: Disk archival techniques
I kind of like the idea of the metadata being a quick
scan of
the label of the ROM or the label of the floppy.
The problem with this is that it's impossible to seach for automatically
(e.g. if you're looking for an AMUX16.3 PROM for a PERQ 2 or something),
(and it's impossible for me to view it :-)).
There's no reason why a scan of the label can't be included as well, but
as much plain text description should be given too.
-tony
2:48 p.m.
New subject: Disk archival techniques
On Wed, 2005-05-18 at 12:29 -0500, Randy McLaughlin wrote:
From: "Jules Richardson"
<julesrichardsonuk at yahoo.co.uk>
Sent: Wednesday, May 18, 2005 9:00 AM
;)
Description's one thing, date would be another, plus checksum info I
suppose. Plus for these kinds of things it probably makes sense to store
the name of the person who created the image, and the tool they used to
do so (can be handy to have the latter for times when a release of a
tool is found to be broken)
Plus one ROM archive might be intended to be spread across several
physical chips in some way. I've certainly got ROM images saved from 32-
bit machines where four physical 8-bit chips are accessed in parallel.
For the native machine they're accessed that way; for browsing in a hex
editor or maybe use with an emulator, it'd be handy to have them as a
linear sequence of bytes. Maybe for that reason some essence of the data
organisation also needs to be captured in the image archive...
This is just off the top of my head; there may be other things, or
some/all of these might be wrong. But it does seem to suggest that there
might be more useful stuff to capture in a ROM image file than just a
chunk of raw data and a freeform description...
On Wed, 2005-05-18 at 08:13 -0500, Brian Wheeler
wrote:
<snip>
Personally I think it's achievable, providing
we stick to worrying about
floppies at the moment. Tapes, hard drives, ROM images etc. can come
later - doubtless they'd share some field names, but the structure is
sufficiently* different that it's too much to take on in a first cut.
<snip>
cheers
Jules
For ROM images just a binary (or hex) file is sufficient since there is no
formatting involved.
The only information needed would be a description of what the heck it is.
If we were smart (a long stretch) Papertapes generally come in two flavors: Text or
binary, please note hex
tapes are text files. The leading and trailing nulls should be stripped but
the data should be kept the same i.e hex tapes should stay hex and not
converted to binary. I have seen people store hex data as binary which
strips load address data plus with Intel hex it is possible to load
different segments which gets lost when converted to binary.
Sure - I'm no expert at all on tapes! Possibly there are other things
that'd be usefully captured in a suite of image formats one day - PAL
chips maybe, or even documentation scans. It's not reinventing the wheel
if it actually adds useful stuff over and above what's currently
available of course :-)
cheers
Jules
3:21 p.m.
New subject: Disk archival techniques
From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
Sent: Wednesday, May 18, 2005 1:48 PM
Multi-part ROM's can be backed up as either the whole or as pieces as long
as it is documented. The tools used to extract the data doesn't sound
important to me.
On many early boards bipolar PROM were used as PAL's. All programmable
devices data should be backed up when possible.
Using one manufacturer as an example - Cromemco used bipolar PROMs and made
their own numbers - 749XX. This makes it confusing but easy to spot when
seen. They would use the chips on multiple boards keeping the same
programming by chipnumber i.e. 74901 could be used on a floppy controller or
memory card and still be interchangeable (I just made up an example but I've
seen common 749XX across different types of cards).
Randy
www.s100-manuals.com
On Wed, 2005-05-18 at 12:29 -0500, Randy McLaughlin
wrote:
> From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
> Sent: Wednesday, May 18, 2005 9:00 AM
<snip>
For ROM images
just a binary (or hex) file is sufficient since there is
no
formatting involved.
The only information needed would be a description of what the heck it
is.
If we were smart (a long stretch)
;)
Description's one thing, date would be another, plus checksum info I
suppose. Plus for these kinds of things it probably makes sense to store
the name of the person who created the image, and the tool they used to
do so (can be handy to have the latter for times when a release of a
tool is found to be broken)
Plus one ROM archive might be intended to be spread across several
physical chips in some way. I've certainly got ROM images saved from 32-
bit machines where four physical 8-bit chips are accessed in parallel.
For the native machine they're accessed that way; for browsing in a hex
editor or maybe use with an emulator, it'd be handy to have them as a
linear sequence of bytes. Maybe for that reason some essence of the data
organisation also needs to be captured in the image archive...
This is just off the top of my head; there may be other things, or
some/all of these might be wrong. But it does seem to suggest that there
might be more useful stuff to capture in a ROM image file than just a
chunk of raw data and a freeform description...
Papertapes generally come in two flavors: Text
or binary, please note
hex
tapes are text files. The leading and trailing nulls should be stripped
but
the data should be kept the same i.e hex tapes should stay hex and not
converted to binary. I have seen people store hex data as binary which
strips load address data plus with Intel hex it is possible to load
different segments which gets lost when converted to binary.
Sure - I'm no expert at all on tapes! Possibly there are other things
that'd be usefully captured in a suite of image formats one day - PAL
chips maybe, or even documentation scans. It's not reinventing the wheel
if it actually adds useful stuff over and above what's currently
available of course :-)
cheers
Jules
8:12 p.m.
New subject: Disk archival techniques
Plus one ROM archive might be intended to be spread
across several
physical chips in some way. I've certainly got ROM images saved from 32-
bit machines where four physical 8-bit chips are accessed in parallel.
For the native machine they're accessed that way; for browsing in a hex
editor or maybe use with an emulator, it'd be handy to have them as a
linear sequence of bytes. Maybe for that reason some essence of the data
organisation also needs to be captured in the image archive...
This, IMHO, is a non-problem. Unlike a floppy disk, where there is
information other than the user data in the sectors, and where losing
things like the inter-sector gap size _is_ a loss of information, you get
the same infromation whether your ROM dump is 16K 32 bit words as the
processor would read them, or 4 off 16K byte files, dumped from each
EPROM.
Even with my limited programming skills I can write a program to convert
one into the other (and, if necessary scramble the order of address and
data pins if they were not connected in the obvious order). Said programs
may not been neat or efficient, but they only generally get run once, so
it doesn't really matter.
Of coruse it's _essential_ to record just what each file consists of, and
if possible to explain how it corresponds to the real hardware. I am
particularly bad about doing the latter, since I tend to assume it's
obvious from the schematics, which I am likely to have anyway.
-tony
17 May
17 May
6:34 p.m.
New subject: Disk archival techniques
On Tue, 2005-05-17 at 17:06 -0500, Brian Wheeler wrote:
As coincidence would have it, I work at Indiana
University's Digital
Library Program and there was a lecture on archiving audio which hits
many of the same issues that have come up here. The conclusions that
they came up with for the project included:
* There's no such thing as an eternal media: the data must be
transportable to the latest generation of storage
Yep, it's recognised the need to periodically refresh data onto whatever
the current favourite media type is. The nice thing about a structured
and essentially human-readable metadata format is that there's a good
chance that it can be transferred as-is to a new type of media without
any reprocessing.
* Metadata should be bundled with the content
Just to clarify; do you mean bundled alongside content or interspersed
with? (From the rest of your message I believe you mean the former,
which happens to be my view too...)
* Act like you get one chance to read the media :(
Yep. Although sometimes multiple reads of media and a combination of the
resulting data can actually improve the ability to reconstruct it :)
I think the optimum format for doing this isn't a
single file, but a
collection of files bundled into a single package. Someone mentioned
tar, I think, and zip would work just as well.
The only danger there is that the two become separated over time, but in
my mind it's an acceptable risk. It's sort of like a librarian losing a
few volumes from a set of encyclopedia I suppose - something that you'd
have to be really careless to do.
I don't think there's any real need to
document the physical properties
of the media for EVERY disk archived -- there should probably be a
repository of 'standard' media types (1541's different-sectors-per-track
info, FM vs MFM per track information, etc) plus overrides in the media
metadata (uses fat-tracks, is 40 track vs 35, etc).
Now risk of seperation there might well be a problem if there's a single
copy of some metatdata for more than one disk image. I'd say that each
'bundle' forming a disk image (raw data + metadata) needs to totally
describe that disk...
cheers
Jules
7:37 p.m.
New subject: Disk archival techniques
On Tue, 17 May 2005, Jules Richardson wrote:
I have in the past and still completely disagree with this. If the image
is structured, including the metadata is naturally obvious and
unobstrusive to the data stream. Having separate metadata invites future
error.
Correct, and the descriptive metadata to describe the attributes of a
particular medium would take up less than 1K characters, in most cases FAR
less.
--
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 ]
I think the
optimum format for doing this isn't a single file, but a
collection of files bundled into a single package. Someone mentioned
tar, I think, and zip would work just as well.
The only danger there is that the two become separated over time, but in
my mind it's an acceptable risk. It's sort of like a librarian losing a
few volumes from a set of encyclopedia I suppose - something that you'd
have to be really careless to do. I don't
think there's any real need to document the physical properties
of the media for EVERY disk archived -- there should probably be a
repository of 'standard' media types (1541's different-sectors-per-track
info, FM vs MFM per track information, etc) plus overrides in the media
metadata (uses fat-tracks, is 40 track vs 35, etc).
Now risk of seperation there might well be a problem if there's a single
copy of some metatdata for more than one disk image. I'd say that each
'bundle' forming a disk image (raw data + metadata) needs to totally
describe that disk...
18 May
18 May
9:18 a.m.
New subject: Disk archival techniques
On Tue, 2005-05-17 at 22:34 +0000, Jules Richardson wrote:
True. During this lecture they were talking about recording the
stop/starts required to get the actual audio into the system.
Apparently there's some standard for doing that for audio. There were
several horror stories as well.
Yeah, but if the package is treated as a separate archival unit, then
the risk of separation should be fairly low. As to other's comments
about zip vs tar, I only suggested zip because it is more common today.
Just don't use ar or cpio! :)
Well, the on-disk-structure metadata is the only one that would benefit
On Tue, 2005-05-17 at 17:06 -0500, Brian Wheeler
wrote:
Bundled alongside so the 'raw' data (metadata or content) can be
manipulated with standard tools.
As coincidence would have it, I work at Indiana
University's Digital
Library Program and there was a lecture on archiving audio which hits
many of the same issues that have come up here. The conclusions that
they came up with for the project included:
* There's no such thing as an eternal media: the data must be
transportable to the latest generation of storage
Yep, it's recognised the need to periodically refresh data onto whatever
the current favourite media type is. The nice thing about a structured
and essentially human-readable metadata format is that there's a good
chance that it can be transferred as-is to a new type of media without
any reprocessing.
* Metadata should be bundled with the content
Just to clarify; do you mean bundled alongside content or interspersed
with? (From the rest of your message I believe you mean the former,
which happens to be my view too...)
* Act like
you get one chance to read the media :(
Yep. Although sometimes multiple reads of media and a combination of the
resulting data can actually improve the ability to reconstruct it :)
I think the
optimum format for doing this isn't a single file, but a
collection of files bundled into a single package. Someone mentioned
tar, I think, and zip would work just as well.
The only danger there is that the two become separated over time, but in
my mind it's an acceptable risk. It's sort of like a librarian losing a
few volumes from a set of encyclopedia I suppose - something that you'd
have to be really careless to do.
I don't
think there's any real need to document the physical properties
of the media for EVERY disk archived -- there should probably be a
repository of 'standard' media types (1541's different-sectors-per-track
info, FM vs MFM per track information, etc) plus overrides in the media
metadata (uses fat-tracks, is 40 track vs 35, etc).
Now risk of seperation there might well be a problem if there's a single
copy of some metatdata for more than one disk image. I'd say that each
'bundle' forming a disk image (raw data + metadata) needs to totally
describe that disk...
from having a separate repository of definitions. I
don't see any
reason to not allow the data to be fully defined if the archivist
feels
the desire to do so, but a list of standard types (as well as a copy of
the full definitions stored somewhere) would take some of the tedium out
of it.
Brian
17 May
17 May
6:22 p.m.
New subject: Disk archival techniques
On Tue, 17 May 2005, Jules Richardson wrote:
On Tue, 2005-05-17 at 15:07 -0500, Randy McLaughlin
wrote:
Sorry to quote the entire message, but mostly what Jules said is my
response.
I just don't want to engage in a discussion and explain/defend the
FutureKeep concept until we've progressed a bit farther with it. I've
been so tied up with finishing other outstanding projects over the past
several months that FutureKeep has effectively stalled, though I'm gearing
up on it again.
I think once people see the draft proposal of FutureKeep all fleshed out,
which takes into account the ephemeral nature of digital media in general,
and which incorporates philosophies which will hopefully ensure that image
archives stay around for a long time, they will see the value of it and
not only support but actively use it.
We have some very smart people working on it. Once we get rolling again
we'll want more involved. I suspect things will start to heat up again in
a couple more weeks, and I will post an announcement here (and of course
on the FK mailing list) once things start to roll.
--
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 ]
I like and prefer media images as straight data
dumps but I want the
formatting information of the original media somewhere. I even want data
from media that is incomplete or has errors, also documented.
Yep, me too. From when we were bashing around ideas about this though a
few months back it seems that's a minority viewpoint; most people want
data embedded in the metadata.
For hard drive images I zero-pad any bad data but also include metadata
in a seperate file - including disk geometry, which blocks are bad,
resulting dump checksum, timestamp etc. along with anything else that
might be particularly useful. For floppy images things would be
significantly more complex though (due to factors as mentioned - variant
sectors/track, different encoding for different tracks etc.)
The idea behind futurekeep though was to make the metadata highly
structured and in a similar vein to HTML in that clients could handle as
much of the data as needed (eg. someone not dealing with variable bit
rate images wouldn't need a decoder that could handle them). Ideally
it'd be human-readable too (after a fashion) - e.g. XML - so that the
data could be reconstructed into a disk image "by hand" even if some
whizzy util to do it wasn't present. (understanding it at a file level
is obviously outside the scope)
That doesn't seem *too* much to ask; basic metadata can be created for
existing images without a lot of hassle *if desired*. To me such a
format's more useful for future image creation though, particularly in
the case of less-common systems; the popular machines are likely to be
covered by their own archive formats already and the following large
enough that lack of data is not (yet) a problem. Rather than messing
around with proprietary image formats for those, or formats that aren't
particularly descriptive, it'd be nice to start from day 1 using
something that allows us to capture all the useful stuff that goes along
with the raw data. 
6:57 p.m.
New subject: FutureKeep Info (Was: Disk archival techniques
Rumor has it that Vintage Computer Festival may have mentioned these words:
We have some very smart people working on it.
And so am I, so anyone else who shows up, don't worry - you won't look like
the Village Idiot. I fill that slot nicely. ;-)
Once we get rolling again
we'll want more involved. I suspect things will start to heat up again in
a couple more weeks, and I will post an announcement here (and of course
on the FK mailing list) once things start to roll.
Which, of course, is still up and running -- but rather quiet nowadays. As
a reminder, to subscribe, send an empty email to:
ccarchive-subscribe at list.30below.com
and reply to the confirmation message. It's just that simple!
Archives are here:
http://ccarchive.30below.com/
There's even a handy "Subscribe" link *right thar on the page!* Now Just
how handy is that????? A bargain at half the price! Call now and you get
this free set of Ginzu Knives! (OK, not really.)
Sellam: Should I change the listname to futurekeep instead of ccarchive?
Oh, and now that VCF-MW is late July, I *might* be able to attend. Don't
wanna make any promises yet, but the wife might go for it.
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers
zmerch at 30below.com
What do you do when Life gives you lemons,
and you don't *like* lemonade?????????????
18 May
18 May
4:28 p.m.
New subject: Master archive was Re: Disk archival techniques
On my site I've been working to archive everything I can on certain systems,
as many others have done.
Right now one of my many projects is the Cromemco series of computers.
After consideration on this one project I've come to believe the following:
All of the chips used in the computers need to have their datasheets
archived. Many chips are now rare and documentation even more so.
All of the manuals need to be archived, for all versions.
All of the programmable info needs to be archived: PROMs to disks with
everything in between including PAL's etc.
For different systems there is a huge overlap:
Most chips used on a Cromemco are also used in an Apple ][.
For CP/M based systems much of the documentation and software is common
between systems.
What is needed is a way to link common parts between archives and not end up
with the 404 error.
I propose cross support:
If you have a website like Jim's SOL-20 site that uses 2102's and you have
the datasheet don't post it on your site, send it to Al at bitsavers and
link to it. Keep a personal copy of all the needed datasheets on your
personal system just in case bitsavers ever disappears.
Is this heresy?
Randy
www.s100-manuals.com
17 May
17 May
6:03 p.m.
New subject: Disk archival techniques
On Tue, 17 May 2005, Tom Jennings wrote:
An example:
* a byte stream copy (note 1) of the diskette image, say 256256
8-bit-bytes long. Even printed on paper. Who knows what OCR will
be like in 20 years?
* A scrap of paper upon which is written:
"Copied from a Shugart 801, 8", single-sided, soft-sectored,
WD1771 FM format. CP/M-80. 128 byte sectors, 26 spt, 77
tracks."
Dumb. Simple. Repeatable. Portable as anything will be after 1, 5,
10, 20 years.
Until you die and your SO doesn't want to let others have access to your
archive.
--
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 ]
6:09 p.m.
New subject: Disk archival techniques
Tom Jennings wrote:
* a byte stream copy (note 1) of the diskette image,
say 256256
8-bit-bytes long. Even printed on paper. Who knows what OCR will
be like in 20 years?
* A scrap of paper upon which is written:
"Copied from a Shugart 801, 8", single-sided, soft-sectored,
WD1771 FM format. CP/M-80. 128 byte sectors, 26 spt, 77
tracks."
This only works if the data is consistently laid out over the entire disk. Mac
disks store less sectors on the inside tracks and more on the outer ones so the
scrap of paper would have to be longer. For personal computers of the 1980s,
copy-protection would not work with this method since it's all over the map
without consistency.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
5:03 a.m.
New subject: Disk archival
On Mon, 16 May 2005, Jim Leonard wrote:
Teledisk: works with MFM disks only, file format not
published, limited
Well, that's not true at all.
1.
TeleDisk works fine with FM *and* MFM disks, even with mixed coding,
sector sizes and densities (IBM System/34 format, track 0 side 0 FM 26
sect., 128 bytes/sect., additional directory tracks MFM 26 sect., 256
bytes/sect., data tracks e.g. 8 sect.,1024 bytes/sect.), supports normal
and deleted address marks, will read bad sectors anyway, stores sector ID
fields as read (important for CBM 1581 disks with swapped head IDs) and so
on. TeleDisk archives and restores everything your combination of FDC and
FDD can do. For example I have a Multi I/O controller card with an FDC
that supports 128 bytes/sect. MFM. This makes it possible to archive
Robotron A5120 UDOS diskettes.
2.
The file format has been reverse-engineered some time ago. See
http://www.fpns.net/willy/wteledsk.htm for more information (it's not my
site!).
Christian
1:05 p.m.
New subject: Disk archival
What version are YOU running? My shareware version from the early 1990s
clearly can't do all that you describe.
Christian Corti wrote:
On Mon, 16 May 2005, Jim Leonard wrote:
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
Teledisk: works with MFM disks only, file format
not published, limited
Well, that's not true at all.
1.
TeleDisk works fine with FM *and* MFM disks, even with mixed coding,
sector sizes and densities (IBM System/34 format, track 0 side 0 FM 26
sect., 128 bytes/sect., additional directory tracks MFM 26 sect., 256
bytes/sect., data tracks e.g. 8 sect.,1024 bytes/sect.), supports normal
and deleted address marks, will read bad sectors anyway, stores sector
ID fields as read (important for CBM 1581 disks with swapped head IDs)
and so on. TeleDisk archives and restores everything your combination of
FDC and FDD can do. For example I have a Multi I/O controller card with
an FDC that supports 128 bytes/sect. MFM. This makes it possible to
archive Robotron A5120 UDOS diskettes.
2.
The file format has been reverse-engineered some time ago. See
http://www.fpns.net/willy/wteledsk.htm for more information (it's not my
site!).
Christian
1:31 p.m.
New subject: Disk archival
From: "Jim Leonard" <trixter at oldskool.org>
Sent: Tuesday, May 17, 2005 12:05 PM
What version are YOU running? My shareware version
from the early 1990s
clearly can't do all that you describe.
Christian Corti wrote:
The problem is in the hardware don't blame teledisk for poor PC hardware. I
keep a Compaq 575e (P100) just because it handles FM.
Randy
www.s100-manuals.com
On Mon, 16 May 2005, Jim Leonard wrote:
--
Jim Leonard (trixter at oldskool.org)
http://www.oldskool.org/
Want to help an ambitious games project?
http://www.mobygames.com/
Or check out some trippy MindCandy at
http://www.mindcandydvd.com/ Teledisk: works with MFM disks only, file format
not published, limited
Well, that's not true at all.
1.
TeleDisk works fine with FM *and* MFM disks, even with mixed coding,
sector sizes and densities (IBM System/34 format, track 0 side 0 FM 26
sect., 128 bytes/sect., additional directory tracks MFM 26 sect., 256
bytes/sect., data tracks e.g. 8 sect.,1024 bytes/sect.), supports normal
and deleted address marks, will read bad sectors anyway, stores sector ID
fields as read (important for CBM 1581 disks with swapped head IDs) and
so on. TeleDisk archives and restores everything your combination of FDC
and FDD can do. For example I have a Multi I/O controller card with an
FDC that supports 128 bytes/sect. MFM. This makes it possible to archive
Robotron A5120 UDOS diskettes.
2.
The file format has been reverse-engineered some time ago. See
http://www.fpns.net/willy/wteledsk.htm for more information (it's not my
site!).
Christian
14 May
14 May
9:17 p.m.
On Sat, 14 May 2005, Vernon Wright wrote:
I AM NOT SUGGESTING ACTION AT THIS POINT. I AM
SUGGESTING A DISCUSSION WITHIN THIS GROUP (WHERE DON
SPENT MOST OF HIS ONLINE TIME), FOLLOWED BY A GROUP
DECISION TO BE IMPLEMENTED. (For that purpose, I will
be turning on individual messages instead of the
digest
form in which I read this group.)
It's cause for serious personal reflection -- are you a
packrat (as Don apparently was) or a collector?
Packrat syndrome is serious, the cliche is a house filled with
bundled newspapers and magazines stacked to the ceiling, that
falls on the elderly 'rat, killing them, etc.
This actually happened to the owner of the house some friends of
mine bought. The guy have one million (1e6) antique railroad items
(as inventoried by the club he belonged to post-death).
It's not very funny; he was in ill health, lived alone, told no
one what he had, etc, some thing happened to him as he was
arriving home [he got hurt in some way I cannot recall], stumbled
in his house, piles fell on him, his family found him a few days
later but he died from his injuries.
This is essentially what Don did. I know someone else with
packratitis. I suspect it's rampant in this list.
Make a goddamn will or just an informal letter, give a copy to
your spousal unit/family/friends/enemies, post it on your website,
whatever.
10:44 p.m.
On Sun, 15 May 2005 shoppa_classiccmp at trailing-edge.com wrote:
On the heels of my foolish posting (see accompanying apology) this
sounds a bit off, but here goes:
But don't archivists make their archives available? Clearly, Don's
is not. If Don had been loosely operating an informal library,
then his family would have at least a faint handle on what to do
with it.
My attempt at a point earlier was that he was packratting, making
a big pile of stuff with no real plans for the future. This
appears to be fact.
We've all gone to estate sales of people who did this very thing.
It's a great way to morbidly pick up deals from distraught
families but it's not a way to "archive". This is what I meant as
a lesson to us all.
By all accounts Don was a great guy, friendly and helpful. I just
find it frustrating that this packratting is exalted, and could
have been so easily headed off. That's all.
are you a
packrat (as Don apparently was) or a collector?
Don was neither. He was a true archivist, in this case working
for the CP/M community.
16 May
16 May
6:29 a.m.
But don't archivists make their archives
available? Clearly, Don's
is not.
Well, he did while he was alive - he helped me and hundreds of others
out many times.
But the issue of what happens to a personal archive when it's not
explicitly written out in a legal will is hard. You and I may think
we know what Don would've wanted, but I look back at my pestering him
to make off-site backups in the 90's and maybe the issue isn't so
clear-cut. He was always polite in his replies to my pestering, and
the answer was always "no" to any mass duplication of the archive. Now
I have to find the old E-mails and see if I can extract what reason
there was.
Tim.
7:13 a.m.
On Sun, 2005-05-15 at 19:44 -0700, Tom Jennings wrote:
On Sun, 15 May 2005 shoppa_classiccmp at
trailing-edge.com wrote:
On the heels of my foolish posting (see accompanying apology) this
sounds a bit off, but here goes:
But don't archivists make their archives available? Clearly, Don's
is not.
I'm not sure about making it physically available, but at least to do it
electronically costs money that might not be available. Plus of course
making disk images / rom images / scanning docs all eats up a lot of
time.
Regarding physical archives, most of us are probably quite approachable
I'd imagine - distance being a problem there. It sounds like Don was at
least organising and rescuing stuff that otherwise might have gone to
landfill; it's just a shame instructions weren't apparently left as to
what to do with everything after he'd gone.
cheers
Jules
are you a
packrat (as Don apparently was) or a collector?
Don was neither. He was a true archivist, in this case working
for the CP/M community.
10:15 a.m.
On Sun, 15 May 2005, Tom Jennings wrote:
On Sun, 15 May 2005 shoppa_classiccmp at
trailing-edge.com wrote:
On the heels of my foolish posting (see accompanying apology) this
sounds a bit off, but here goes:
But don't archivists make their archives available? Clearly, Don's
is not. If Don had been loosely operating an informal library,
then his family would have at least a faint handle on what to do
with it.
Don was operating as an informal library. However, when I spoke to his
wife last year not too long after Don passed away, she explained to me
that she was completely unaware of what he was doing.
are you a
packrat (as Don apparently was) or a collector?
Don was neither. He was a true archivist, in this case working
for the CP/M community. My attempt at a point earlier was that he was
packratting, making a big
pile of stuff with no real plans for the future. This appears to be
fact.
The only thing Don didn't do was plan for an "unplanned departure". As
far as we know, he never got around to writing a will for his computer
collection. But Don was definitely not a packrat. He was an archivist of
system disks and actively collected and catalogued them. It remains to be
seen how universal his catalog was but hopefully we'll get a chance to
find out.
--
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 ]
10:30 a.m.
Vintage Computer Festival wrote:
...
It remains to be
seen how universal his catalog was but hopefully we'll get a chance to
find out.
Here is a list of the various system disks he had images for:
http://www.gaby.de/sysdisk.htm
2:49 p.m.
Jim Battle wrote:
Here is a list of the various system disks he had
images for:
http://www.gaby.de/sysdisk.htm
*If* that is a complete list (I didn't count, maybe 500
system disks?), how hard would it be to replicate?
We could all sign up with what we have (via a webpage,
a bit of PHP and MySQL) and then offer to make copies
on an as needed basis. For the first request for System-X,
everyone registered as having System-X is emailed asking
for a copy. Someone offers to supply the copy and uploads
it. It is then available for others (and future requests
are fufilled automatically without bothering anyone).
Throw in a mechanism to indicate whether a copy did or
did not work for you, and you have the makings of a
feedback system.
Once a replacement for teledisk is found, existing
stuff could be converted. Perhaps it might be best
to allow for multiple image formats for the same
data. Given the small size of old system images,
storage space is hardly going to be a problem.
Antonio
--
---------------
Antonio Carlini arcarlini at iee.org
17 May
17 May
12:18 p.m.
Another item that should be added to the archive would be
the various ROMs/PROMs/etc for numerous classic systems.
In addition to helping rebuild old systems, they would also
be useful for creating emulators.
15 May
15 May
11:18 a.m.
On Sat, 14 May 2005 18:17:26 -0700 (PDT)
Tom Jennings <tomj at wps.com> wrote:
On Sat, 14 May 2005, Vernon Wright wrote:
I guess I'm trying to figure out what your 'packrat vs. collector'
comment at the front has to do with the rest of your comment. Is there
some higher, more-esteemed thing called a 'collector' that is superior
to a packrat? I agree that organized and managed collections are
better. I just don't know where to draw the line without coming off
like we're labeling (self-labeling) ourselves with some sort of clinical
disorder and/or stepping up onto a pedestal.
I AM NOT SUGGESTING ACTION AT THIS POINT. I AM
SUGGESTING A DISCUSSION WITHIN THIS GROUP (WHERE DON
SPENT MOST OF HIS ONLINE TIME), FOLLOWED BY A GROUP
DECISION TO BE IMPLEMENTED. (For that purpose, I will
be turning on individual messages instead of the
digest
form in which I read this group.)
It's cause for serious personal reflection -- are you a
packrat (as Don apparently was) or a collector?
Packrat syndrome is serious, the cliche is a house filled with
bundled newspapers and magazines stacked to the ceiling, that
falls on the elderly 'rat, killing them, etc.
This actually happened to the owner of the house some friends of
mine bought. The guy have one million (1e6) antique railroad items
(as inventoried by the club he belonged to post-death).
It's not very funny; he was in ill health, lived alone, told no
one what he had, etc, some thing happened to him as he was
arriving home [he got hurt in some way I cannot recall], stumbled
in his house, piles fell on him, his family found him a few days
later but he died from his injuries.
This is essentially what Don did. I know someone else with
packratitis. I suspect it's rampant in this list.
Make a goddamn will or just an informal letter, give a copy to
your spousal unit/family/friends/enemies, post it on your website,
whatever.
5:55 p.m.
On Sun, 15 May 2005, Scott Stevens wrote:
I guess I'm trying to figure out what your
'packrat vs. collector'
comment at the front has to do with the rest of your comment. Is there
some higher, more-esteemed thing called a 'collector' that is superior
to a packrat? I agree that organized and managed collections are
better. I just don't know where to draw the line without coming off
like we're labeling (self-labeling) ourselves with some sort of clinical
disorder and/or stepping up onto a pedestal.
A collector collects. A packrat accumulates.
--
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 ]
9:22 p.m.
On Sun, 15 May 2005 14:55:00 -0700 (PDT)
Vintage Computer Festival <vcf at siconic.com> wrote:
On Sun, 15 May 2005, Scott Stevens wrote:
Collect and accumulate are synonyms.
I guess I'm trying to figure out what your
'packrat vs. collector'
comment at the front has to do with the rest of your comment. Is
there some higher, more-esteemed thing called a 'collector' that is
superior to a packrat? I agree that organized and managed
collections are better. I just don't know where to draw the line
without coming off like we're labeling (self-labeling) ourselves
with some sort of clinical disorder and/or stepping up onto a
pedestal.
A collector collects. A packrat accumulates.
9:27 p.m.
>>> Collect and accumulate are synonyms.
Uhhhh.... Wrong.
Collect means to explicity "gather".
Accumulate means to passively not dispose of.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Scott Stevens
Sent: Sunday, May 15, 2005 9:23 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The Don Maslin Software Archive
On Sun, 15 May 2005 14:55:00 -0700 (PDT) Vintage Computer Festival
<vcf at siconic.com> wrote:
On Sun, 15 May 2005, Scott Stevens wrote:
Collect and accumulate are synonyms.
I guess I'm trying to figure out what your
'packrat vs. collector'
comment at the front has to do with the rest of your comment. Is
there some higher, more-esteemed thing called a 'collector' that is
superior to a packrat? I agree that organized and managed
collections are better. I just don't know where to draw the line
without coming off like we're labeling (self-labeling) ourselves
with some sort of clinical disorder and/or stepping up onto a
pedestal.
A collector collects. A packrat accumulates.
10:39 p.m.
So what do you call a person who accumulates collections? ;-)
Curt
Computer Collector Newsletter wrote:
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005
>>>Collect and accumulate are synonyms.
>>>
>>>
Uhhhh.... Wrong.
Collect means to explicity "gather".
Accumulate means to passively not dispose of.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Scott Stevens
Sent: Sunday, May 15, 2005 9:23 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The Don Maslin Software Archive
On Sun, 15 May 2005 14:55:00 -0700 (PDT) Vintage Computer Festival
<vcf at siconic.com> wrote:
On Sun, 15 May 2005, Scott Stevens wrote:
Collect and accumulate are synonyms.
I guess I'm trying to figure out what your
'packrat vs. collector'
comment at the front has to do with the rest of your comment. Is
there some higher, more-esteemed thing called a 'collector' that is
superior to a packrat? I agree that organized and managed
collections are better. I just don't know where to draw the line
without coming off like we're labeling (self-labeling) ourselves
with some sort of clinical disorder and/or stepping up onto a
pedestal.
A collector collects. A packrat accumulates.
16 May
16 May
9:42 a.m.
Good response Jay :-)
Curt
Jay West wrote:
Curt wrote...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 5/13/2005
So what do you call a person who accumulates
collections? ;-)
Rich, and simultaneously very... very... very tired.
Jay
15 May
15 May
9:38 p.m.
Vintage Computer Festival <vcf at siconic.com>
wrote:
> A collector collects. A packrat accumulates.
On Sun, 15 May 2005, Scott Stevens wrote:
Collect and accumulate are synonyms.
When I closed my office, I kept everything that I collect,
and gave away a metric butttload of stuff that I had accumulated.
10:16 p.m.
On Sun, 15 May 2005 18:38:02 -0700 (PDT)
Fred Cisin <cisin at xenosoft.com> wrote:
And if you hadn't accumulated it to give away to other people more
interested, it would have all ended up in the dumpster at the point just
before when you supposedly 'packratted' it.
Sometimes one gets the idea here that if you don't mount each item on a
piece of walnut with a brass plaque labeling it, you're just piling up
junk.
Lord, how I wish I had kept ('packratted' to use that dirty word) some
of the computer-related things in the past I've had that I apparently
wasn't "collecting" back at that point in time.
There are people with some of the attitudes expressed here in
Numismatics, too. Coin 'collectors' who view it as a genteel pastime.
Lord knows they'll turn up their nose at that sack of mixed, circulated
foreign coins I'm excited to find at a table at a show. I just love
figuring out where each and every one of them comes from and the history
of that place when they were minted and circulated among the people. I
leave it to the 'gentlemen collectors' to fuss and fluster about the
'patina' on the particular specimens in the narrow series of coins they
specialize in. Who's the better 'collector'? I guess it's decided by
the 'professionals' who collect the fees and pay the custodians who
install the velvet ropes at the shows. Whatever.
Vintage
Computer Festival <vcf at siconic.com> wrote:
> A collector collects. A packrat accumulates.
On Sun, 15 May 2005, Scott Stevens wrote:
Collect and accumulate are synonyms.
When I closed my office, I kept everything that I collect,
and gave away a metric butttload of stuff that I had accumulated.
16 May
16 May
3:06 p.m.
On Sun, 15 May 2005, Scott Stevens wrote:
And if you hadn't accumulated it to give away to
other people more
interested, it would have all ended up in the dumpster at the point just
before when you supposedly 'packratted' it.
Sometimes one gets the idea here that if you don't mount each item on a
piece of walnut with a brass plaque labeling it, you're just piling up
junk.
Lord, how I wish I had kept ('packratted' to use that dirty word) some
of the computer-related things in the past I've had that I apparently
wasn't "collecting" back at that point in time.
What you, I, Don, or anyone does with their pile of stuff is none
of anyone's business. Really -- altruistic archiving or selfish
hoarding, if you obtained it in a legal manner it's no one's
business, period... though of course we're allowed our own
opinions of you/me :-)
The only larger point I mean to make is: whatever you're doing, do
it on purpose. I'm not a collector by any means; I don't think
collecting is a higher calling. Archiving, like Al Kossow does, is
a demonstrable positive value to the culture at large; few of us
actually do that, it's work. Collecting one each of the
motorcycles on the cover of 1971's CYCLE WORLD for no reason than
personal satisfaction (or obsession) is fine (I know someone who
did this). It's all fine, personal and NOMDB(1).
But gathering together a large number of rare, desirable items
(however subjective) into one place without a will or letter of
intent is not "archiving". In fact it's the opposite -- items were
taken out of circulation probably permanently.
Actions matter, intent ain't shit the next day.
Someone else can have the last word.
(1) None Of My Damn Business.
11:02 a.m.
New subject: Pathology or hobby?
At 08:17 PM 5/14/2005, Tom Jennings wrote:
It's cause for serious personal reflection -- are
you a packrat
or a collector? Packrat syndrome is serious, the cliche is a
house filled with bundled newspapers and magazines stacked to
the ceiling, that falls on the elderly 'rat, killing them, etc.
I know someone else with packrat-itis. I suspect it's rampant
in this list.
I'm confident it's rampant on this list. Sellam said "A collector
collects. A packrat accumulates." There's plenty of room for
semantics here. So where's the fine line between collecting
whatever you can get your hands on, and packrat-ism? It's slippery
slope, starting with one of something, then more for spare parts.
For some, the only upper bound is available space.
I could write a book on it. Many other people have. There are
many motivations, many potential causes and behaviors and beliefs
that perpetuate it. I'm all for a libertarian view of life that
lets people live in their parent's basement and collect old
computers, but on the other hand there's also room for advice
about what makes life worth living, and how an excess of possessions
can overwhelm your life. There is a cost to collecting / accumulating,
even if the computers are free.
- John
2:36 p.m.
New subject: Pathology or hobby?
----- Original Message -----
From: "John Foust" <jfoust at threedee.com>
To: <cctalk at classiccmp.org>
Sent: Monday, May 16, 2005 11:02 AM
Subject: Pathology or hobby?
At 08:17 PM 5/14/2005, Tom Jennings wrote:
In my view a collector looks for specific machines and parts to complete his
collection and does not have many multiples of duplicates. A packrat will
take anything in that is offered to him working or not, even if he has no
space for it.
It's cause for serious personal reflection --
are you a packrat
or a collector? Packrat syndrome is serious, the cliche is a
house filled with bundled newspapers and magazines stacked to
the ceiling, that falls on the elderly 'rat, killing them, etc.
I know someone else with packrat-itis. I suspect it's rampant
in this list.
I'm confident it's rampant on this list. Sellam said "A collector
collects. A packrat accumulates." There's plenty of room for
semantics here. So where's the fine line between collecting
whatever you can get your hands on, and packrat-ism? It's slippery
slope, starting with one of something, then more for spare parts.
For some, the only upper bound is available space.
I could write a book on it. Many other people have. There are
many motivations, many potential causes and behaviors and beliefs
that perpetuate it. I'm all for a libertarian view of life that
lets people live in their parent's basement and collect old
computers, but on the other hand there's also room for advice
about what makes life worth living, and how an excess of possessions
can overwhelm your life. There is a cost to collecting / accumulating,
even if the computers are free.
- John
4:46 p.m.
New subject: Pathology or hobby?
Teo Zenios wrote:
In my view a collector looks for specific machines and
parts to complete his
collection and does not have many multiples of duplicates. A packrat will
take anything in that is offered to him working or not, even if he has no
space for it.
I agree with this definition. As the son of a packrat, and a quasi-packrat
myself, I can tell you about my father: He is a coin collector, and our
basement, tables, ping-pong table, etc. were (and still are) covered up with
numismatics newspapers and various research materials. Although I am guessing,
I am fairly certain that he holds onto all these materials because he fears he
will not have access to information when he needs it -- someday -- when writing
an article for some publication.
I inherited this from him; whether or not it was passed down genetically or
socially I cannot confirm :-) Case in point: I have always wanted to write
essays ("put up web pages" in today's world) on various 1980's personal
computer topics, such as copy-protection methods or generating sound and music.
Along those lines, there was a time when I was bidding on sound cards every
other week because "that could be the last one I will ever find and if I miss
it I won't ever be able to write an article on it". Of course, time passes,
and I find myself with no time to write said articles/essays, and I have a
metric buttload of sound cards taking up space.
So am I hoarding or collecting? In the area of sound cards, probably a little
of both, as I plan to sell/give away the cards I am not interested in after I
write my articles. In the case of Central Point Option Boards, I definitely am
hoarding them because my own archives are in that format and I will always need
an Option Board to decode them properly. In the area of early computer game
software, I am most definitely a collector, as I have all my titles arranged
neatly on shelves, presented and displayed, and easily accessible.
So you can be a mixture of all the above :) but the main point, for me, is that
a collector presents and displays his collection, and keeps it accessible...
whereas a packrat hoardes, doesn't always know what he has, and can't get to
everything in his possession.
(BTW, John, very nice wording on your thoughts on the subject.)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Want to help an ambitious games project? http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
17 May
17 May
4:50 a.m.
New subject: Pathology or hobby?
On Mon, 16 May 2005 22:46:11 +0200, Jim Leonard <trixter at oldskool.org>
wrote:
...
So you can be a mixture of all the above :) but the main point, for me,
is that a collector presents and displays his collection, and keeps it
accessible... whereas a packrat hoardes, doesn't always know what he
has, and can't get to everything in his possession.
This are good points. I am a packrat myself, without having any
inheritance to blame it on.
I have a small collection of old cameras, all of which can (or at least
could, if I made film to fit them) be used.
I have a large collection of books, a private library that I use and enjoy.
I have a basement full of computer parts and sundry electronics which I
grabbed because they were available, with some dim future plan to do
something with.
I also have a number of personal computers of differing vintages ut to the
newest, which I use and keep working past their normal lifespan. I think
that is actually the important part - museum people say that the critical
time when things are lost to posterity is just after they are no longer
new and fashionable, but before they are old and interesting. I think my
1978 Iwatsu oscilloscope fits in that group - I still use it, but not very
much, and it is old-fashioned and all analogue.
However, I do not think most collectors are presenting their collections.
They will often display it, but only privately.
And even if a collection is open to the public, it is not necessarily a
museum. A museum also works systematically on preservation and research,
and publishes results.
Then we have the archive and the library. They are much akin.
A library collects what many desire temporary access to, either for
research, self-education or pleasure. Libraries are accessible to the
public or a defined subset of the public. If the subset is the owner and
possibly some close friends, it is a private library.
An archive collects everything within its scope, usually only one copy,
sometimes one for strict preservation and one for use by researchers.
Archives are usually only accessible to what the archive sees as
researchers. That, of course, may range from an auditor who wants to check
on a receipt from 1992 in a company archive to a scolar looking for the
first mention of freemasons in the archives of the Vatican Library. It is
unlikely that the same person would be granted access to both
archives<vbg>.
The main property af an archive as well as of a museum is continuity. They
must exist independent of their curator, and need a way to ensure that.
They should probably be legally made into some form of self-owning entity.
Different countries will have different rules and options for that, but it
will often give the collector a tax break as well as saving his family
lots of trouble in case he should succumb to an unexpected illness or
accident.
--
-bv
7:29 p.m.
New subject: Pathology or hobby?
This are good points. I am a packrat myself, without
having any
inheritance to blame it on.
I suspect I'm mostly a packrat too, although I do try to share
information, and I've made smoe provision for the collection to go to
good homes if I get burried 'face down, 9 edge first'
I have a small collection of old cameras, all of which can (or at least
could, if I made film to fit them) be used.
Ah, I have a large collection of old cameras, some working, others in
need of repair, which of course I do myself (what, you didn't think I
just fixed computers, did you?). One of my aims is to actually understand
the Voightlander Ultramatic well enough to repair and align it (this is
one of the most complicated mechanical cameras ever...)
I have a large collection of books, a private library
that I use and enjoy.
I've yet to meet a hacker who doesn't have books piled up everywher...
I have a basement full of computer parts and sundry
electronics which I
grabbed because they were available, with some dim future plan to do
something with.
Ditto, only no basement, if you see what I mean. Electronic parts, tools,
test gear, etc piled everywhere...
I also have a number of personal computers of differing vintages ut to the
newest, which I use and keep working past their normal lifespan. I think
I uspected this PC/AT definitely qualifies there...
-tony
7005
days inactive
7010
days old
74 comments
24 participants
participants (24)
-
a.carlini＠ntlworld.com -
ard＠p850ug1.demon.co.uk -
bdwheele＠indiana.edu -
bv＠norbionics.com -
cc＠corti-net.de -
cctalk＠randy482.com -
chenmel＠earthlink.net -
cisin＠xenosoft.com -
curt＠atarimuseum.com -
frustum＠pacbell.net -
jfoust＠threedee.com -
julesrichardsonuk＠yahoo.co.uk -
jwest＠classiccmp.org -
kth＠srv.net -
news＠computercollector.com -
pkoning＠equallogic.com -
shoppa_classiccmp＠trailing-edge.com -
spedraja＠ono.com -
teoz＠neo.rr.com -
tomj＠wps.com -
trixter＠oldskool.org -
vcf＠siconic.com -
vern4wright＠yahoo.com -
zmerch＠30below.com