----------
> From: Richard Erlacher <richard(a)idcomm.com>
> To: classiccmp(a)classiccmp.org
> Subject: Re: Defining Disk Image Dump Standard
> Date: Tuesday, May 30, 2000 08:28 PM
>
> If you put floppy diskettes on the shelf and wait 20 years, you'll see
> what's left of your archive.
This weekend I backed up a set of factory-original Apple II CP/M disks for
MicroPro applications (Wordstar, Mailmerge, Spellstar, Datastar,
Reportstar, Calcstar, etc). The disks were dated 1979-1982 and there were
no errors reading them. I copied them twice: once to another floppy, and
once to the Apple II disk archive format (ShrinkIt) on my hard drive.
Twenty years is not too long if you use single-sided single density
diskettes that cost $10 each (in 1980 dollars!).
I don't trust today's ten-cent double-sided high-density diskettes for any
long term storage.
Paul R. Santa-Maria
Ann Arbor, Michigan USA
paulrsm(a)ameritech.net
>On Sun, May 28, 2000 at 10:38:55PM +0000, Mark wrote:
>>The Catweasel disk controller hardware (available as an ISA card for PCs) is
>>capable of similar things. However due to its developer (stupidly IMO)
>>refusing to release details on how to program it directly, this would be of
>>no use; you're stuck with the provided drivers which are apparently pretty
>>poor.
>I thought he had changed his mind about this? When I first talked to him
>he seemed pretty paranoid, but I think he eventually realized that there's
>not a big enough market for there to be even a point in stealing his idea
>and competing with him (although, I sure hope he's done a PCI version by
>the time ISA slots disappear entirely). I certainly remember that he
>softened his position about this, but I don't know if that turned into a
>manual. Then again, the CW/ISA board comes with no manual anyway!
>Anyway I sorted out a lot of the Catweasel/ISA details, from disassembly and
>the few sources that were available when I was doing it, it might be enough
>to write a driver (I've gotten stuck with my own work on RX01 and RX23 style
>drivers, I can read data enough of the time to think I'm really close but it
>works less than half the time).
>Here's what I've worked out on the I/O ports (default base is 320h):
Oh, i might try some of this info I have a catweasel, sitting in my amiga
thoug. I would love to find a way to access the wierd 1mb format of the
old cbm 8250 drive.
Regards Jacob Dahl Pind
When people receive complete systems (with software, manuals, etc.) do you
make any attempt to document the state of the system when you received it?
For example, do you record what programs were on the hard drive, what
peripherals were included, what the system was used for (either what you
were told, or could infer), etc?
It seems to me that increasingly, social historians and museums are more
interested in _how_ an artifact was used than in the thing itself. But
often , especially when I receive multiple examples of the same system, I
mix and match parts and programs to suit myself, and lose track of which
disk drive came with which CPU, which software was originally installed on
each, etc. Information is obviously being lost here.
I'd be interested to know what other list members are doing, and how
important you think the information being lost is.
Regards,
Mark Gregory
On May 31, Jason McBrien wrote:
> Cheapo bonanza! Grabbed a TRS-80 Model 100 Portable, in the deluxe hard case
> with tape drive and accoustic coupler modem for $5! Works like a charm.
> Snagged a Network General "The Sniffer" Protocol
> Analyzer, looks to be a modified Compaq Portable II, can't find any info on
> the sniffer program though (NAI bought out Network General, and doesn't take
> kindly to supporting older apps) Also grabbed a stripped RS/6000 320H for
> $1, a few odd cables, and a loaded Sun SPARCStation 10 for $25 (It was in
> with the SPARC 1's, so someone must have missed the 0, I know I did :) Good
> luck hunting!
Whoa! I'll triple your money on that SS10! ;)
-Dave McGuire
>If you're serious about creating an archive. It needs to be permanent, so
>it's essentially requisite that the media be write-once. I'd say you're
>better off with an OTP EPROM. Hardware to create them is dirt-simple to
>create, eraseable/rewritable equivalents are readily available, and even if
>the OTP's (very inexpensive, by the way) become scarce, there will still be
>rewritables available which can be write protected by removing the VPP or
>program pin. Use those and you'll have a real archive. What's more, there
>are no mechanical components, nothing to rust, become misaligned, or wear
>out.
Your kidding? Right? Eproms, have a finite random failure rate and while
better
in some ways over time you still run the risk of total failure due to:
Environment, humidity increases failure rate.
Temperature
Time
Electrical stress.
This does not include ESD and circuit mishandling. it still assumes
compatable technology (try reading a ECL prom using TTL).
Add to this the great number of devices needed to contain said archive
your risking the boat in exactly the same way as CDrom or on shorter
time spans magnetic media.
All of this is seperate from the format that will assure recovery of the
data.
Myself I'd rather risk even floppies with their known weakness and use
redundant recording and added error detection/correction. Even when
applied to CDroms this is more viable.
Most of all it matters not what you do, what you do it on! It does matter
that sufficient data on what was done is available along with the archive
to reconstruct not only the data but the systems that archived it (or can
recover it!!!). Books work because they can be preserved and copied
if they start to decompose and we teach the languges needed to read
them.
Reminds me of an old theological arguement of how many angles can
dance on the head of a pin. Untill we have music, a pin and angles
it's simply an exercise with a meaningless outcome to all but the faithful.
Allison
> > What I'm saying is that the way is *should* work is:
> >
> > pointer fault on attempt to execute faulted pointer to
> DLL routine
> > segment fault on attempt to execute code in unmapped
> DLL routine's
> > segment
> > page fault on attempt to execute code in unmapped DLL
> routine's page
> >
> > And in a really proper OS you'd also get a page fault if
> the page map
> > containing the PageMapTableEntries weren't currently mapped in (and
> > yes you can page out page maps).
> >
> > And before you point out that segments went away from Win32 let
> > me say that too is another fatal flaw with the Windows family of
> > OS's.
>
> Is it just me -- or does this sound like Multics segments?
Dang- busted again. :-)
-doug q
<< On Thu, 25 May 2000, Mark Gregory wrote:
> On the whole, your reply seemed remarkably snotty and unhelpful, and didn't
R. D. Davis replied:
< Sorry it appeared that way; it was posted only out of concern for the
< preservation of older computers. >>
Good grief, man, give us a break! If that note was posted "only out of
concern" then why did it include this bit of condescension???:
< Don't you mean an I/O card with a short circuit somewhere? If you
< don't know what a short circuit is, just ask, or experiment... e.g.,
< if, for example, you touch the conductors connected to the hot and
< ground connectors of a mains socket, and a fuse blows or a circuit
< breaker trips, you'll find that you've learned a lot about short
< circuits and saving classic computers. ;-)
Anyone who reads this list on even a semi-regular basis knows that Mr. Rigdon
is well aware of what a short is. Why the put-down? Do you think that you
are conducting a high-school electric shop class and talking to a bunch of
eighth-graders? Personally, I have never received anything from Joe Rigdon
except help when I needed it, which is more than I can say of you.
Actually, I'm glad that you blatantly displayed your arrogance in your post
to this list. Now everyone has a better idea of who they're dealing with
when they see a note signed "R. D. Davis."
Glen Goodwin
0/0
"In the case of the 1771 and 179x series it's possible to build a really neat
circuit I've seen but never tried to match, which uses the /TEST pin on the
FDC to cause the device to put out its pulses much faster, allowing them to
be accumulated externally in a counter, which, drives a DAC which drives a
VCO, which drives the counter as it downcounts the number of steps, thereby
slewing the head assembly. This could lead to an interesting but lengthy
discussion.
"
Sounds like an ideal candidate for reimplementation in a single chip
microcontroller.
>> No, they are not the same. the latter will do DD and the 1773 was single
>> density.
>> The 1773 was used on TRS80, Icom, and other early systems that were
>> softsector.
>
>
>I can assure you that a 1773 is capable of double density operation.
I shuffled the 1771 with 1773. Oops, it's easy to do with WD numbering.
Allison
>However, I've just thought of a better example : I once saw a card for an
>Apple ][ containing a 1771 and associated components (and probably a
>ROM). It linked to an external box containing 2 8" drives. The official
>purpose was to allow an Apple with a Z80 Softcard to read standard SSSD
>CP/M disks. But I am _sure_ it could have been used from Apple DOS given
>the right software.
>
>Which means the archive format would have to allow for :
>
>Apple ][, 16 sector 5.25" GCR-encoded disk
>and
>Apple ][, 26 sector, 8", FM encoded disk.
>
>It may be a _very_ unusual format, but a proposed archive format should
>be able to handle _anything_. In any case, I would think that 256
>sub-formats for each machine would be plenty, which means this adds _1
>byte_ to the archive size. Not really a problem IMHO.
You also forget the trackstar apple][ board for PCxt systems that could use
the
DOS disks for storage via the PC hardware never minding it's direct
interface.
To make it work in the end you need some basic documentation and a rosetta
stone to assure the results are valid. IE: what are you looking for, how to
get it,
and did you get that?
My solution for myself... use the newest media the system can support or I
can easily transfer bulk to. 3.5" floppies are OK. Then figure out what
I'm saving.
300 copies of CP/Ms PIP for V2.2 are pointless as are ASM, and all the other
common stuff. Also how many copies of worstar for ADM3 do I need?
Reducing
this is easier on physical storage too. Also using a system that can handle
multiple
formats or a common one via simple changes to reduce the possible medias
used
to one helps. In the end it's easy to work backward to say 8" CPM SSSD with
an
CCS bios if you have a system image, the CCS unique utilities, CPM std
utilities,
track layout and of couse a system that can write it all on a suitable
floppy. this
avoids the need to have a real CCS bootable disk as you can make as many as
you need. Then again if you have a CCS system with a monitor rom you could
down
load the peices and use itself to write to disk as native.
For example much of my archive is on AMPROLB. It is very copyable
Z80 design and as is can format/accept/boot/copy a large number of
formats: Both 5.25" and 3.5". My S100 system can bridge the 8" 5.25
and 3.5" rift making a very large number of formats possible in short order.
Both system even can read/write dos compatable disks (if it's on the WC
cdrom it's auto archived). So softsector is covered {with exceptions like
Intel M2fm and RX02 mixed}.
Hardsector and vendor unique at the extreme are more difficult, those
include:
NorthStar* (all)
Apple
TRS80
Heath
DEC RX02
Intel MDS230 series DD controller
and others as they did things that were very specific or unique to them and
most
common hardware is unable to reproduce it. this is where the challenge
lies.
Allison