Offload of H89 hard and soft sectored disks

[Engunir]

Does anyone have a direct and efficient way to copy files off H89 hard and soft sectored disks to current technology media? 

I have a couple H89s (mine and one that previously belonged to my folks), and I want to offload any useful files from the floppies before I wipe them and find new homes for the hardware and blank floppy media.  as I recall, the data is on Heath-DOS and CP/M compatible, 5.25", 10-sector, hard-sectored disks, and on soft-sectored, 5.25" and 8" floppies.

My preference is to copy them directly to another form of media (e.g., Windows compatible, NTFS floppy, CD, DVD, or USB stick); but if necessary, I can probably use a serial interface to transfer any ASCII files using terminal emulators; but I was looking for something faster and more efficient.

Thank-you,

Vern.

[Kenneth L. Owen]

Hi Vern,

 

I run a home network on a Linux backbone.  On my PC, I run WinXP and set it to run DOS apps prior to installing Service_Pack_3.  That allows me to still run DOS apps with all update to WinXP.

 

I run TELIX (DOS version) on the WinXP box and then run either MAPLE for HDOS or ZMP for CP/M and send the files to the PC which saves them on my server.

 

MAPLE uses X-modem protocol, ZMP uses uses Z-modem protocol and TELIX (or HyperTerm) does both.

 

The Heath modem programs, cabling and installation/operation documentation is part of the Z67-IDE system setup files on Norberto’s site:

 

            http://www.koyado.com/

 

-- ken

 

---

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1e0f9475-3c31-4160-ae29-2325a8beeb93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Garlanger]

For 5.25 inch disks I have a two different systems. A FC5025 USB floppy controller connected to a Linux machine to handle hard-sectored disks. For soft-sectored, I have a dos machine and use a free program to image them. Can't recall the name this instant. Both of these generate images of the disk, not individual files. To get the files, they would need to be extracted from the image.

Mark

Sent from my iPhone

--

[dwight]

If you have ASCII files, we don't have anything better than
using a serial interface and a terminal program. We have been saving
entire disk images but that has been through serial and is slower than
individual file. One would still have to split the files from the images.
If your machine had a printer port, it would be possible to do faster
transfers but parallel ports were rare on the H89s.
Someone would still have to write the code to use a compatible parallel
 port on the PC side.
Dwight
 

---

From: tx83...@bellsouth.net
To: se...@googlegroups.com
Subject: RE: [sebhc] Offload of H89 hard and soft sectored disks
Date: Sun, 1 Jun 2014 00:44:47 -0400

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/4760987073004AD9A9D82E848A7393CE%40kws1.

[Chris Elmquist]

On Sunday (06/01/2014 at 12:18AM -0500), Mark Garlanger wrote:
> For 5.25 inch disks I have a two different systems. A FC5025 USB floppy controller connected to a Linux machine to handle hard-sectored disks.

Cool. Obviously you guys got this to work with the Heath hard-sector
format. Is there any writeup on what needs to change with the DeviceSide
software to accomplish that?

Chris
--
Chris Elmquist

[Lee Hart]

Engunir wrote:
> *Does anyone have a _direct_ and efficient way to copy files off H89
> hard and soft sectored disks to current technology media?*

That's a timely question. I'm wondering about the same thing myself.

I have an H8 with H17 (hard-sector 5.25"), and a couple of H89s with H17
(hard-sector 5.25") and H37 (soft-sector 5.25") drives and controllers.
One H89 also has a CDR FDC-880 8" controller as well. So far, I have
kept them working with real floppy disks and drives.

I have Peter Shkabara's excellent CPC program to read/write/format PC
360k floppies. For a long time, I used it to transfer files to a PC that
also had a 360k floppy drive. But now, that PC has died; and I can't get
a 360k floppy drive to work on any newer PCs.

And one by one, my disks and drives are going bad. Oddly, the 8" drives
and media have been the most reliable, H17 next, and H37 is the least
reliable. Huge numbers of 3.5" floppies on my PCs have also turned into
garbage; so I don't see them as reliable long-term media, either.

So, I'm also trying to figure out "what's next..."

Some kind of serial link to a PC is an obvious choice. But given the
quality of modern PCs, I have my doubts that any of them will last as
long as my 30-year-old Heathkits have. I can imagine transferring all my
disks to a PC, and then the PC dies!

Make lots of backups, and keep buying new PCs as they wear out? But I
can do that with floppies as well.

I'm tending to think that some form of semiconductor "disk" might be the
better route; USB flash drive, CF card, etc. It could be interfaced
directly to the H8 or H89, so it's not dependent on a PC. The media
could also be read on a PC, for transfers or archival storage.

--
I view this year’s failure as next year’s opportunity. Failures are
not something to be avoided. You want them to happen as quickly as
you can, so you can make progress rapidly. -- Gordon Moore
--
Lee Hart's EV projects are at http://www.sunrise-ev.com/LeesEVs.htm

[John Toscano]

Has anyone ever tried to burn files to a CD-R, DVD-R, or BD-R? These are probably longer - lived than floppies, though likely not "good forever". Also have the advantage of much higher capacity than floppies and lower cost per gigabyte (blank media) than flash cards or drives... I mean, if you can get files to a PC, it will have the "smarts" to deal with optical media. It's not like we need to teach (program) an H8 or H89 to read/write an optical disc.

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.

To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538B9011.50800%40earthlink.net.

[Mark Garlanger]

I haven't written anything up, but the changes were very minor. I think the main thing, was that the clock bits could be shifted a bit between the header and data portions of the sector. So, when removing the clock bits, it has to handle both cases - whether or not the clock bits were shifted.

I had talked with Adam from DeviceSide, and was able to get permission to use some of the code to make a heathkit specific program. I wanted to make it much more robust (re-read sectors if checksum is wrong), and create in a new file format.  I'll try to get something written up and done this week.

Mark

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20140601155039.GJ24493%40n0jcf.net.

[Peter Shkabara]

There does not seem to be any truly reliable storage medium for long term storage. My own bet is on hard disk storage. I copy all my files to an external USB hard disk. Although all I am storing now is PC (NTFS) format files. My old Heath CP/M and HDOS archives are also stored in folders on these NTFS drives. If it is important, always store two copies.

Today's hard disks store so much that there should not be a problem saving all that you may have had on the old Heath machine on a single hard disk. I remember being excited having my 20MB HD attached to my H89 - everything was on that HUGE hard drive. Only problem I ran into is that my CDR RAMdisk was so much faster that I did all my work on it. Once I was preparing my term paper for grad school and forgot to save from RAMdisk to the HD. Ran to class, and when I got back I discovered that I had to do the paper once more from human memory!

I might mention that the CPC program was actually a collaboration of me and DR. Grant Gustafson. I was working on a PC reading program as an extension to my EMULATE program when I discovered that Grant had already done much of the work. I was working in Assembly and he had written in C. I would work on it and send him the ASM code. It would come back to me rewritten in C! We finally compromised. The main routines were in C, and the hardware interface stuff was done in ASM. This was because ASM was MUCH faster than C and the speed difference was noticeable. The PC formatting program was all mine written in ASM.

Peter Shkabara
kol...@gmail.com

[Jbensadon]

Peter, I agree with you, although I'm a little tempted to believe in Flash memory. 
When I first started playing with vintage electronics/computers, I saw how paper fades, plastic melts, photographs even discolor.  CD's die in 10-15 years.  Information is perishable and we must work to keep it alive.

My 2 cents worth.
Josh Bensadon

> From: kol...@gmail.com
> To: se...@googlegroups.com
> Subject: RE: [sebhc] Offload of H89 hard and soft sectored disks

> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/000c01cf7dea%242febde40%248fc39ac0%24%40gmail.com.

[John Frankle]

Peter,

Is your software online for public consumption?

With respect to long term storage, it would be interesting to get some
definitive data on the longevity of different technologies. I have certain
impressions, and please don't roast me if you disagree because they are only
impressions. Anything mechanical using magnetic media, such as hard disks,
floppy drives, tape storage is not going to last very long. Solid state
memory such as USB sticks and mass storage do not have a long history to
gauge their life, but it seems that USB sticks can only tolerate a certain
number of write operations before they fail. I am hearing more and more
cases of solid state mass storage failing prematurely. Write once CD ROMS
(and DVDs) seem to have a long life if they are properly stored: out of
sunlight and at moderate temperatures. I would say if you are interested in
saving important data, burn it to a CD or DVD and also upload it to one of
the backup services on the Internet.

Regards,

John Frankle

[Mark Garlanger]

On Sun, Jun 1, 2014 at 6:40 PM, John Frankle <jfra...@alum.mit.edu> wrote:

Peter,

Is your software online for public consumption?

Hi John,

   It's available on my site: http://heathkit.garlanger.com/companies/ANAPRO/
 

[John Frankle]

Further on long term storage: Saving the data is one thing, the other is to
access it at some future time. With rapid change in technology, the drives
and the computers that were instrumental in saving the data become obsolete
and disappear from the scene. I know of cases where people have magnetic
tape cartridges and no hardware to read them. Conclusion is that, it may not
be the longevity of the media that matters, but the longevity of the
technology. The strategy then is to keep moving the data as technology
advances so as to keep ahead of the obsolesence curve.

Regards,

John Frankle

> https://groups.google.com/d/msgid/sebhc/31DC68BE6D894C24AE7FEB47E75B4243%40420US.

[Dave McGuire]

On 06/01/2014 07:40 PM, John Frankle wrote:
> With respect to long term storage, it would be interesting to get some
> definitive data on the longevity of different technologies. I have
> certain impressions, and please don't roast me if you disagree because
> they are only impressions. Anything mechanical using magnetic media,
> such as hard disks, floppy drives, tape storage is not going to last
> very long. Solid state memory such as USB sticks and mass storage do not
> have a long history to gauge their life, but it seems that USB sticks
> can only tolerate a certain number of write operations before they fail.
> I am hearing more and more cases of solid state mass storage failing
> prematurely. Write once CD ROMS (and DVDs) seem to have a long life if
> they are properly stored: out of sunlight and at moderate temperatures.
> I would say if you are interested in saving important data, burn it to a
> CD or DVD and also upload it to one of the backup services on the Internet.

I'm sorry to say that both you and Peter are in for some
disappointment. This response is not a "roast"; this is intended to
help, as I have some experience in this area.

First, about hard disks...it would be enlightening to look up some
statistics on the error rates of modern drives. The numbers are not
good. Going back to sub-TB-class drives will give you a much greater
chance of actually reading data back once it's written. The
conventional wisdom that anything newer will somehow automatically be
more reliable does not apply here...but you can virtually guarantee that
anything newer will have been cheaper to manufacture, which is at odds
with the desire to actually get the data back.

Bear in mind the typical use case for
absolutely-friggin-gigantic-capacity hard drives, 1TB or larger. 99.9%
of these are used in two basic applications: desktop PCs for the
unwashed masses, and very large RAID arrays. In the former case, people
believe they "need" that much capacity because it is available for
purchase. Those few who actually scratch the surface of using that much
disk space generally do so with collections of movies and music, as
those, especially the former, are just about the only thing (again,
99.9%) that actually takes up any appreciable amount of space. If
there's a bit error in a movie, you'll hear a tiny "tick" in the audio
or get a tiny burst of visual static or color distortion in the video,
which will almost always go unnoticed and, fortunately, never really
hurts anything. Since most of those poor sods are running old
non-checksumming filesystems (NTFS comes to mind), they will never know
that part of their data has been lost.

Further, if some bits get corrupted that cause (say) Microsoft Word to
start misbehaving, that world is very well-trained to "just reinstall it".

In large disk arrays, data is checksummed and stored redundantly, so
any read errors are dealt with and every bit of data that is delivered
to the host is intact and correct. The integrity of the data is
verified at the bit level at every read, and in some filesystems, at
other times as well. These techniques are not employed by the typical
home PC user who just buys and trusts.

So, to summarize the above, big unreliable disks are nearly always
used in situations in which where the actual data being stored isn't all
that important, or they are used in redundant configurations which
compensate for their shortcomings. For those 0.1% of situations in
which EVERY BIT COUNTS, like preserving software for vintage computers,
those high bit error rates can be a disaster.

Anyone interested in seeing the real numbers, which are terrifying,
should go find the disk error rate study that Google did several years
ago. It is several years old now, but disk error rates have only
worsened since then...not improved.

So, on to flash memory. That situation is even worse. John, you
typed above "it seems that USB sticks can only tolerate a certain number
of write operations before they fail." This does not "seem" to happen;
it is known and documented. Flash memory cells have a write endurance
rating. The flash memory chips that I use in my commercial designs have
an endurance spec of, depending on the chips, anywhere between 100,000
and 1M writes. For desktop computer use, I have one-year-old 16GB flash
drives (consumer grade) which are already starting to have data
retention problems.

Older flash drives tend to last a lot longer. There is a direct
negative correlation between capacity and longevity. As capacities go
up, bit cells become smaller, and the charge they retain to
differentiate a '1' from a '0' becomes smaller, and leaks away more
quickly. The situation became far worse with the introduction of "MLC"
(Multi-Level Cell) flash chips. That uses multiple levels of electrical
charge to represent multiple data bits in a single bit cell, typically
four bits per cell. This means the differentiation in the amount of
electrical charge (in analog terms here...remember, there's really no
such thing as "digital circuitry" only analog circuitry specified and
described in digital terms) stored in the bit cell required to
differentiate between 00, 01, 10, and 11 is 1/4 of the margin required
to differentiate between 0 and 1. Write endurance ratings are
commensurately lower...well under 10,000 writes for consumer-grade flash
devices like thumb drives, and less than 1000 writes for cheap clones.
To further brighten your day, note that writing a single file can result
in dozens of actual device writes to directory areas, file allocation
tables, etc.

The moral of the story here is don't trust really ANY ultra-modern
storage technology for data that would be damaged by the loss of one or
more bytes. Either spend the money and physical space to store data
WELL, or make friends with someone who has...or make yourself
comfortable with the fact that you WILL lose data, you MAY NOT know
about it, and, statistically speaking, it's essentially impossible that
it hasn't ALREADY HAPPENED unbeknownst to you.

I myself use a redundant, end-to-end-checksummed filesystem spread
across eight 100%-duty-cycle-rated 1TB hard drives to store data that
cannot be replaced. Those drives are never powered off and are kept in
a controlled environment.

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

[Chris Elmquist]

Excellent writeup Dave. I wanted to share similar words and experience.
Thanks for doing it so excellently.

The flash problem gets even uglier as the densities continue to increase.
A couple years ago I was working with 45nm devices in the 4Gbit density
range. These require extreme amounts of ECC from the attached controller
because now they have a new problem called "read disturb". This is a
physics problem due to the tiny size of the cells and the fact that when
you read those tiny cells the current produced from the read operation
causes other cells nearby to flip their bits! So, now, not only do
you wear out the flash when you write it, you also mess it up when you
read it and you have to write it again to fix up what got corrupted,
further decreasing the available number of write cycles. Geesh.

Market forces (smart phones and tablets) are driving the densities of
flash up and up and to achieve that, they have to go to the smaller
geometries, thereby introducing these problems. Economics don't make
it cost effective to produce the older, lower density/larger geometry
stuff and so we get forced into using the only stuff you can afford or
find and it is by far less reliable.

Now when I build stuff with flash, I double or quadruple the flash size
in the design and then use that extra space as part of the wear-leveling
mechanism. I've also moved completely away from bare NAND flash and use
SD cards with their own wear leveling, ECC and data management mechanisms
on-board with a (relatively) standard interface on the outside.

For personal stuff, I too have moved to a NAS with 4TB of RAID and
consider the drives in each workstation, laptop, etc as volatile,
"loosable" storage. The only things that really exist are on the NAS.

And so to bring this back to vintage machines, my goal is to build network
interfaces for many of my favorite and active vintage machines that can
then access the network attached storage as one method if not _the_ method
of storage for those systems. Protocols like AoE are trivial to implement
on 8-bit, slow machines and so I think that is the direction I will go.

Over time, it's then an exercise in migrating all the images and files
on the NAS forward to whatever is the most workable and reliable storage
of the time.

I have no illusions that any media we use today will last more than maybe
5 yrs. In fact, I "use up" 1 TB hard drives at the rate of about one
per year now. I'm the poster child for Seagate's warranty replacement
program.

The only media I have that I trust, is paper tape. Even better if it's
mylar. I have tapes 40 yrs old that I can still read without an error.
But, 1TB on paper tape is, umm, kind of a big roll.

Chris

> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538C67B2.9060006%40neurotica.com.

> For more options, visit https://groups.google.com/d/optout.

--
Chris Elmquist

[John Toscano]

Time to break out the paper tape punch?  Just don't crumple the roll of punched tape! Actually, I can relate to this discussion on multiple levels. When I worked for a government agency, we backed up certain data onto tape and stored the tapes securely.  One day I asked the computer folks to scan through all the backup tapes and download certain data for me to analyze. They replied that although they had 10 years worth of data stored, they did not actually have a program to read the tapes! Can you believe that? Well, long story made short,  they built the program to read the tapes and recovered the archived data from about 85% of the tapes. OTOH, in my personal computer system, I've had my bacon saved once already by using a RAID5 array of 250Gb drives. When one drive died, all I had to do was slip in a new 250Gb drive and let the array rebuild itself. Meantime all my data were still available. Of course, I couldn't leave well enough alone and instead I put in 4 new 1Tb drives to quadruple the size of the array. Then one of the 1Tb drives died under warranty and the manufacturer didn't have any 1Tb drives to replace it with,  so they sent me a 2Tb drive. That didn't play so well with my RAID array so I bought a new 1Tb drive and put the warranty - replacement 2Tb drive in an external USB/ESATA case. Yes, storage devices are inherently unreliable. I remember reading somewhere about some special DVD disc's that were designed for reliable archiving storage...

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538C67B2.9060006%40neurotica.com.

[Douglas Miller]

You beat me to it... I was going to say magnetic core memory and mylar
"paper tape"...

40 years of "modern computing" and we still can't solve the backup
problem... it's like hanging on to the back end of a bullet train...

On 06/02/2014 09:04 AM, Chris Elmquist wrote:
> ...

[Bob Groh]

Thank you, gentleman, for a most interesting discussion!  And from folks who not only understand the nitty gritty science but also the practical, boots on the ground, stuff.

To go off the topic a bit, the data storage problem is a big problem and has been for quite sometime.  Back in the 90's, I was working as a design engineer in the Architectural and Engineering (A&E) field (i.e. we designed buildings, structures, etc - well, a guy has to make a living!!) and I was amazed to find that all of our records (e.g. old drawings, specifications, documents) were stored on microfilm. How antiquated, I thought!  And then I was wapped on the back of the head and explained the facts of life - nothing is permanent and, to make things worse, you can't even count on having a machine available to read the old records!  Duh! Microfilm was, at the time and maybe still is, the best compromise.

Indeed a complicated subject.  Again enjoying the discussion.

Bob Groh

Heathkit Engineering 1977 to 1981

Longtime Heathkit fan

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.

To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538C8677.4090905%40gmail.com.

[Engunir]

[Dave McGuire]

On 06/02/2014 10:07 AM, John Toscano wrote:
> I remember reading somewhere about
> some special DVD disc's that were designed for reliable archiving storage...

Yup, M-Disc. It's not yet known how long these will actually last.

I should add to my last (way too long) post a comment about tapes.
Magnetic tape is still, by a huge margin, the most reliable storage
mechanism out there. (it's also the most capacious, but that's not the
point here...tape has always been the king of capacity) Even going back
to very old tape technologies, I regularly read 9-track magtapes that
were written 30-40 years ago. Some have given me trouble (3M
"Blackwatch") but the vast majority do not.

And 8" floppies...I don't think I've ever tried to recover data from
one and failed. I have hundreds.

The key here is to, as Glenn mentioned, rotate through storage
mechanisms and "refresh" the archives. Of course one MUST keep
checksums of the data, or use a checksumming storage mechanism, or one
could just end up propagating bad data from archive mechanism to archive
mechanism.

[Gregg Chandler]

I solved the problem by transferring diskette/disk images from my H-89 via a program running on the H-89.  I catch and save the data on windows via HyperTerm.  I convert the transferred Intel-Hex images to binary.  I then launch my emulator, boot HDOS virtually, mount the disk images just uploaded/converted, and use PIP/COPY to copy the files directly from HDOS to a Windows folder.  From there, I can burn CD’s, or use whatever other archiving capabilities are available within Windows.

[Chris Elmquist]

On Monday (06/02/2014 at 12:28PM -0400), Dave McGuire wrote:
>
> I should add to my last (way too long) post a comment about tapes.
> Magnetic tape is still, by a huge margin, the most reliable storage
> mechanism out there. (it's also the most capacious, but that's not the
> point here...tape has always been the king of capacity) Even going back
> to very old tape technologies, I regularly read 9-track magtapes that
> were written 30-40 years ago. Some have given me trouble (3M
> "Blackwatch") but the vast majority do not.
>
> And 8" floppies...I don't think I've ever tried to recover data from
> one and failed. I have hundreds.

I think the key here is the bit density. Neither of those technologies
pushed the envelope of how many bits per inch or bits per sector you
could reliably record on the media. They did it conservatively for
reliability and it shows.

Modern stuff typically says to hell with reliability and seeks to maximize
density.

I have a steel 7-track tape from the Univac I, which I bet if we built
a reader, we could read it at the whopping 100 bpi (or maybe less) that
it was written.

It was a different mindset then-- it was write/read media... not just
write-only :-)

> The key here is to, as Glenn mentioned, rotate through storage
> mechanisms and "refresh" the archives. Of course one MUST keep
> checksums of the data, or use a checksumming storage mechanism, or one
> could just end up propagating bad data from archive mechanism to archive
> mechanism.

Exactly. It's maintanance but I think it goes along with the hobby-- not
a lot different than changing the oil in your motorcycle or painting your
boat.

cje
--
Chris Elmquist

[Lee Hart]

Dave McGuire wrote:
> I'm sorry to say that both you and Peter are in for some

> disappointment... you can virtually guarantee that

> anything newer will have been cheaper to manufacture, which is at odds
> with the desire to actually get the data back.

I worked at Eastman Kodak from 1973-1980. As an EE, we were always
fighting with MechE and ChemE over electronics vs. film. We lost.
"Electronics is temporary, but film is forever", they said.

Anyway, Kodak came out with their disk camera. They wanted to store
pictures on it. We used it to store data. We used a laser to write data
tracks, just like a CD. Develop the film, and you had a cheap
high-capacity ROM. Even our prototypes held more than any floppy disk of
the time. The film disks only cost $0.25, and the hardware to read them
was simpler than a floppy disk drive. Sell 'em to the burgeoning
personal computer market to distribute software! But management thought
it was a stupid idea, and wouldn't fund a product.

But they were right about one thing. Film *is* archival storage. We have
100-year-old examples to prove it. You would want to use error
correcting codes so a scratch or bit of lint wouldn't lose data, but
it's straightforward to add that to the coding.

The other archival possibility is paper. It can last thousands of years.
More than once, I've resurrected an old program from a printed listing.
But I've had to do it by hand. As far as I know, there is no good
automated low-error-rate way to convert a printed listing into software.

[Chris Elmquist]

On Monday (06/02/2014 at 12:02PM -0500), Lee Hart wrote:
>
> The other archival possibility is paper. It can last thousands of
> years. More than once, I've resurrected an old program from a
> printed listing. But I've had to do it by hand. As far as I know,
> there is no good automated low-error-rate way to convert a printed
> listing into software.

There is but it matters how it was originally printed. Dot-matrix
printout, not much of a chance. But if it was printed on a band-printer,
using an OCR font, pretty high likelihood you can scan it and convert it
today.

CDC did huge amounts of research into OCR in the mid-70's. All of their
system documentation, internal datasheets and other documents were all
printed in an OCR font (OCR A, I think) and as long as the document
hasn't physically degraded (water, rips, crumpled up) you can scan
those babies right in.

The modern approach might be to print it as a bar- or QR-code so that you
can add additional checksumming and then file them in an actual folder :-)

Chris
--
Chris Elmquist

[Lee Hart]

Dave McGuire wrote:
> Magnetic tape is still, by a huge margin, the most reliable storage
> mechanism out there.

But is it still available, especially for machines like our Heath
computers? It seems like there were some that interfaced via a serial port.

> And 8" floppies...I don't think I've ever tried to recover data from
> one and failed. I have hundreds.

Same here. I have a CDR FD-880H soft sector controller and a pair of 8"
drives on one of my H89s. It's been very reliable. I also have an IMSAI
with ancient Shugart 8" floppies, also still working fine. So, maybe the
answer is to get 8" floppies on all my vintage machines? Unfortunately,
Heath's H47 was a POS. :-(


--
I do not waste my life in friction when it could be turned into
momentum. -- Frances Willard

[Dave McGuire]

On 06/02/2014 01:47 PM, Lee Hart wrote:
>> Magnetic tape is still, by a huge margin, the most reliable storage
>> mechanism out there.
>
> But is it still available,

Good heavens. Of course.

> especially for machines like our Heath computers?

Good heavens. Of course NOT. ;) Modern tape drives interface via FC
and SAS. Just running an FC or SAS protocol stack requires more
horsepower than these machines have available.

However, we're talking about modern storage media for storing old
data, not connecting modern storage devices to old computers.

But if you're talking about OLD magnetic tape, as opposed to modern
tape...even 9-track magtapes are still being made, but they cost a
fortune new. I, however, have well over a thousand reels of it here,
and will send some to anyone who asks, for the cost of shipping.

> It seems like there were some that interfaced via a serial port.

Really?? That's odd, unless it was a cassette or something. Nearly
all tape drives transfer data a lot faster than an (async) serial port
can typically handle.

>> And 8" floppies...I don't think I've ever tried to recover data from
>> one and failed. I have hundreds.
>
> Same here. I have a CDR FD-880H soft sector controller and a pair of 8"
> drives on one of my H89s. It's been very reliable. I also have an IMSAI
> with ancient Shugart 8" floppies, also still working fine. So, maybe the
> answer is to get 8" floppies on all my vintage machines? Unfortunately,
> Heath's H47 was a POS. :-(

That sucks. :-( The sensible thing to do would seem to be to transfer
the data to modern hardware, but not consumer-grade crap hardware, and
to store it using cryptographically-checksummed storage mechanisms.

[Peter Shkabara]

Would storing data on an external NTFS drive but first saving it to a ZIP or Z7 container provide the necessary data correction code to preserve integrity of data?

Peter Shkabara
kol...@gmail.com

-----Original Message-----

[Mark Garlanger]

Not sure on 7z, but zip only provides detection, not correction for errors. So at least you would know an error occurred. For correction, the best thing I've found is http://en.wikipedia.org/wiki/Parchive

I've used the par2 program before, but it looks like they are now up to par3. It's amazing how it can correct errors. Everything is broken up into blocks, and then you add how ever many correct blocks that you want. If ANY block is bad/missing, ANY correct block is able to repair it.

Mark

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/000601cf7e93%24cd9f5fa0%2468de1ee0%24%40gmail.com.

[Chris Elmquist]

On Monday (06/02/2014 at 11:52AM -0700), Peter Shkabara wrote:
> Would storing data on an external NTFS drive but first saving it to a ZIP or Z7 container provide the necessary data correction code to preserve integrity of data?

I think you need to be a little mindful of compression. If the wrapper
format (ie, ZIP, Z7, .tgz, .gz, etc) compresses the data and then the
media takes a hit in the middle of that, the ability to recover the
uncompressed data is pretty slim, since the compression algorithm likely
depends on previous data and now some of it missing.

The more safe approach is to store it uncompressed and then perform CRC,
checksum, etc over that uncompressed data. You later use the checksum
to determine whether the data has become corrupt and if it has, you can
likely still recover most of it and only have smaller holes to fill with
some other recovery technique.

The ability to loose everything due to a small media failure is much
greater with compressed data stored on that media.

Chris

> -----Original Message-----
> From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf Of Dave McGuire
> Sent: Monday, June 02, 2014 11:47 AM
> To: se...@googlegroups.com
> Subject: Re: long-term data storage, was Re: [sebhc] Offload of H89 hard and soft sectored disks
>
>
> That sucks. :-( The sensible thing to do would seem to be to transfer the data to modern hardware, but not consumer-grade crap hardware, and to store it using cryptographically-checksummed storage mechanisms.
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
>

> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/000601cf7e93%24cd9f5fa0%2468de1ee0%24%40gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--
Chris Elmquist

[Gary Crowell]

CDR FD-880H    Cool, I had long forgotten the name of that.  That is the controller that I used on an adapter board in my H8.  Worked great.

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538CC6B7.4020105%40neurotica.com.

For more options, visit https://groups.google.com/d/optout.

--

----------------------------------------------
Gary A. Crowell Sr., P.E., CID+

Linkedin  Elance  KE7FIZ  Things RocketryCNC

[Lee Hart]

Dave McGuire wrote:
> Modern tape drives interface via FC and SAS. Just running an FC or
> SAS protocol stack requires more horsepower than these machines
> have available.
>
> However, we're talking about modern storage media for storing old
> data, not connecting modern storage devices to old computers.

Well, *I'm* thinking about ways to have mass storage on old computers. :-)

>> It seems like there were some that interfaced via a serial port.

> Really? That's odd, unless it was a cassette or something. Nearly

> all tape drives transfer data a lot faster than an (async) serial port
> can typically handle.

I used a Texas Instruments "Silent 700" terminal that had two digital
cassette drives. These weren't consumer audio cassettes; they were
special data cassettes. It interfaced via a serial port, and was used to
read/write programs and data.

Then, I had an MFE digital tape drive on an early PC. If I remember
correctly, the tape cartridge was called a DC-100? It had both serial
and parallel interfaces. Yes it was slow; but the software provided
backed up the 10Mb hard drive as a background task, while you were doing
other things.

I'm sure you wouldn't want to back up gigabytes of data this way; but
for H8 and H89, we're only talking about megabytes.

> The sensible thing to do would seem to be to transfer the data to
> modern hardware, but not consumer-grade crap hardware, and to store
> it using cryptographically-checksummed storage mechanisms.

Since many of us are having (or going to have) backup problems, can you
provide details on how to do this?

[Engunir]

Wow!  In spite of the minor deviations from the baseline discussion topic, the responses have been helpful.  Thank-you for the feedback.

As soon as I can get one or both of the H89s on the bench, I'll begin looking more closely into the suggestions you have provided, and pick the specific approach to use for the various files I need to archive. 

Personally, I'm not as concerned by the media retention issue (covered as a slight deviation within this thread), as I learned that lesson many years ago.  For me, once I get the H-DOS and CP/M files transferred into almost any current medium, the worst part of the job is over.  I already have a redundant (NAS) RAID fileserver in place, with an appropriate back-up and off-site archival methodology.

Thanks again for the responses; I may popup a bit later as I implement the suggestions provided and run into follow-up questions.

Regards,

<<< vern >>>

With respect to: On Saturday, May 31, 2014 8:59:50 PM UTC-7, Engunir wrote:

Does anyone have a direct and efficient way to copy files off H89 hard and soft sectored disks to current technology media? 

 

[Dan Emrick]

 Hi, Vern,

Please do pop-up and let us know how you are doing and what works best for you.  Lots of people here provide and receive very useful information in the group.  It's posts like yours that help keep things going and keep them interesting.

Dan

PS:  Sometimes deviations are what we do best.

[Lee Hart]

Engunir wrote:
> Personally, I'm not as concerned by the /media retention issue/...

>I already have a redundant (NAS) RAID fileserver in place, with an
> appropriate back-up and off-site archival methodology.

Then you're well ahead of the pack! I must say that 99% of the people I
know never back *anything* up. If their computer dies or they lose their
cellphone, they've lost *all* the data on it. But no matter; they create
virtually nothing themselves. All their music, videos, books, games,
programs, etc. were created by someone else. So they buy a new computer
or phone, and download it all over again.

[Lee Hart]

I bought one of Noberto's H89 serial-USB boards. My intention is to use
its USB port with a thumb drive to save/transfer data from my floppies
to a PC. I don't yet know if this will turn out. The way Murphy works,
the floppy with the software needed to talk to the USB drive will be the
one that dies!

A question: RAID uses multiple hard drives to improve reliability. Would
the same technique work with USB thumb drives? Does someone make a
'carrier' for multiple USB drives, and software to redundantly spread
the data between them? So if one fails, it can be replaced and the data
is restored from the others?

[Jack Rubin]

Here you go:

http://www.wired.com/2009/05/five-disk-floppy-raid-4mb-of-blistering-fast-storage/

> -----Original Message-----
> From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf

> Of Lee Hart
> Sent: Monday, June 02, 2014 7:11 PM
> To: se...@googlegroups.com

> --
> You received this message because you are subscribed to the Google Groups
> "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sebhc/538D1296.60607%40earthlink.net.

> For more options, visit https://groups.google.com/d/optout.
>
> -----

> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3955/7611 - Release Date: 06/02/14

[Dave McGuire]

On 06/02/2014 08:11 PM, Lee Hart wrote:
> A question: RAID uses multiple hard drives to improve reliability. Would
> the same technique work with USB thumb drives? Does someone make a
> 'carrier' for multiple USB drives,

Yes, they're called "hubs", Lee. ;) *poke*

> and software to redundantly spread
> the data between them? So if one fails, it can be replaced and the data
> is restored from the others?

ZFS, in particular, has been demonstrated on USB thumb drives. It
implements this functionality.

[Dave McGuire]

On 06/02/2014 07:53 PM, Lee Hart wrote:
> Then you're well ahead of the pack! I must say that 99% of the people I
> know never back *anything* up. If their computer dies or they lose their
> cellphone, they've lost *all* the data on it. But no matter; they create
> virtually nothing themselves. All their music, videos, books, games,
> programs, etc. were created by someone else. So they buy a new computer
> or phone, and download it all over again.

That seems to be most people, yes. It's really quite ridiculous.

Me: "You know, you really should back up your data."
Them: "Sigh, I know, I KNOW!"
...
...
Them: "OH SHIT! I just lost all of my pictures! Can you help?"
Me: "How are your backups?"
...

[Chris Elmquist]

Them: Backups?
Me: oh geez, look at the time. I've got to go shampoo the cat.

--
Chris Elmquist

[Dave McGuire]

On 06/02/2014 09:03 PM, Chris Elmquist wrote:
>>> Then you're well ahead of the pack! I must say that 99% of the people I
>>> know never back *anything* up. If their computer dies or they lose their
>>> cellphone, they've lost *all* the data on it. But no matter; they create
>>> virtually nothing themselves. All their music, videos, books, games,
>>> programs, etc. were created by someone else. So they buy a new computer
>>> or phone, and download it all over again.
>>
>> That seems to be most people, yes. It's really quite ridiculous.
>>
>> Me: "You know, you really should back up your data."
>> Them: "Sigh, I know, I KNOW!"
>> ...
>> ...
>> Them: "OH SHIT! I just lost all of my pictures! Can you help?"
>> Me: "How are your backups?"
>> ...
>
> Them: Backups?
> Me: oh geez, look at the time. I've got to go shampoo the cat.

ROFL!!

[Jbensadon]

Reminds me of an instance where I got in trouble with a customer.
I took to liking the phrase "It's not *if* your drive crashes, but a matter of *when*".
After training a customer to use a card access application, I would complete training by showing them how to back up the database.  To drive my point, I would say that phrase.  One customer complained to my boss that I was saying that their *new* system would crash and lose all it's data.  I now choose my words more carefully to match the level of understanding by the customer and believe it's not a matter of *if* you meet ridiculous people but a matter of *when*.

Josh Bensadon

> Date: Mon, 2 Jun 2014 21:05:14 -0400
> From: mcg...@neurotica.com
> To: se...@googlegroups.com
> Subject: Re: [sebhc] Re: Offload of H89 hard and soft sectored disks

> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538D1F4A.9060001%40neurotica.com.

[Dave McGuire]

On 06/02/2014 04:52 PM, Lee Hart wrote:
>> Modern tape drives interface via FC and SAS. Just running an FC or
>> SAS protocol stack requires more horsepower than these machines
>> have available.
>>
>> However, we're talking about modern storage media for storing old
>> data, not connecting modern storage devices to old computers.
>
> Well, *I'm* thinking about ways to have mass storage on old computers. :-)

Well good! Let's run with that, then. :-)

> I used a Texas Instruments "Silent 700" terminal that had two digital
> cassette drives. These weren't consumer audio cassettes; they were
> special data cassettes. It interfaced via a serial port, and was used to
> read/write programs and data.

The Silent 700 interfaces via a serial port, but I'll bet the tape
drives inside it don't. ;)

The Coleco Adam also has digital cassette drives. I think there were
others that used Philips-style audio cassettes physically, but used
digital modulation schemes and/or tapes of different coercivities.

> Then, I had an MFE digital tape drive on an early PC. If I remember
> correctly, the tape cartridge was called a DC-100? It had both serial
> and parallel interfaces. Yes it was slow; but the software provided
> backed up the 10Mb hard drive as a background task, while you were doing
> other things.

Yeah. I like the background backup idea, but those were never real
contenders in the real magnetic tape world. "Floppy tape" systems also
"functioned", technically, meaning one could occasionally make them work
and sometimes even get data back, even within the same day...barely.
There were a number of cheap tape systems in the early PC world, once
hard drives appeared. Those products didn't last very long.

The world of tape was, at the time, still solidly dominated by huge
and (by then) VERY VERY FAST 9-track drives. Some higher-end QIC
subsystems appeared, with ISA-bus interfaces. Those were solid and fast
(except when compared to 9-track), but way too expensive for most people.

I am fighting with DC-100 cartridges right now, trying to recover
calibration constants for high-end RF calibration kits. I am using tape
drive belts from donor tapes and crap like that. Very frustrating.
DC-100 was great at the time, but they sadly didn't stand the test of time.

> I'm sure you wouldn't want to back up gigabytes of data this way; but
> for H8 and H89, we're only talking about megabytes.

Yes, absolutely. I'm sure those technologies would be a much better
match for our eight-bitters than the hard-disk-sporting PCs, ATs by that
time, that they were marketed toward. With less data to store, and
slower buses to carry the data, a "floppy tape" subsystem (say) would
probably have been fantastic on something like an H-8.

Thinking about it further, it would be near-trivial to implement a
SCSI host adapter for something like an H-8. Software would be a
tougher prospect, but putting even an old-fashioned 8-bit 10MHz SCSI
host adapter in one would, since SCSI will fall back to the old speeds
and widths, give one access to some middle-aged tape standards like DLT.
DLT drives and media are small, cheap, readily available, and
practically indestructible. I am willing to bet that a single 40GB tape
cartridge would hold all software ever written for the H-8 and H-89.
Possibly all CP/M software, too...though maybe that'd take two tapes.

But the software to drive it would be interesting. Perhaps something
like tar could be written for CP/M and/or HDOS, with small buffers etc etc.

That would actually be a viable project, I think.

>> The sensible thing to do would seem to be to transfer the data to
>> modern hardware, but not consumer-grade crap hardware, and to store
>> it using cryptographically-checksummed storage mechanisms.
>
> Since many of us are having (or going to have) backup problems, can you
> provide details on how to do this?

I am certainly willing to help, but this pretty off-topic. Well
actually I guess data preservation really isn't off-topic at all, but is
pretty central to what we do. Ah whatever. Here's some random advice.

There are many ways to go about it. A good start is simple common
sense. It should be obvious, and probably is to most people here, but
the concept is lost on too many people so it bears mentioning: Don't buy
cheap consumer crap hardware. If one is ordering a 3.5" hard drive
TODAY and it's more capacious than, say, 1TB and costs less than about
$70.00, it is probably cheap consumer crap. Personally I recommend WD
"Red" series drives. I have 18 of them running here 24/7, some are
approaching two years old, and have had no problems. These are
NAS-rated drives, built to be run 24/7 (most consumer hard drives are
built to be powered on about 20% of the time), and built to be RELIABLE
rather than just "MORE MORE MORE MORE GIGGGGIDDIE-BYTES" for people to
buy whether they actually need the space or not.

Next...Spinning drives up and down causes a great deal of wear and
tear. Buy them, install them, and LEAVE THEM RUNNING. They consume
practically no power and produce practically no heat...some people will
be cheap (ahem, sorry, "frugal") about this, but it is to their own
eventual detriment. If it's worth saving, it's worth spending eight
bucks a month to save.

Next, find a good checksummed filesystem and find a comfortable way to
use it. Windows users are probably out of luck here (but then that's
pretty much the case by default); I don't know of any way to do
something like this directly on a Windows box. But...ZFS (from
Sun/Oracle) is the most advanced filesystem I've seen in 35 years of
computing, and was ported to Linux and FreeBSD (accessible) from Solaris
(production-grade). That is the one I recommend, though there are
others. If you (or anyone) wants to explore this, I can help. There
are other ways to accomplish the goal, but this is the best way I've
found, and it's the only one I can really assist with.

There's a really easy and cheap way to take advantage of this type of
technology. There are "canned" NAS packages, for free of course, that
you download as a disk image and install on most any well-configured PC
that essentially turns it into a NAS. Many (most) of these use ZFS for
the actual storage, and provide a very easy interface (usually
web-based) to manage it. THAT is a good solution. FreeNAS comes to
mind, but there are others. Get or buy a decently-configured PC (RAM is
the most important thing), put some quality drives in it, put it in the
spare bedroom with an UPS, and use it as a repository. Don't bother
putting a monitor on it; you'll never sit at the console of this
machine. That's what desktop and laptop PCs are for, not servers. This
machine will turn into a NAS, and it will outlive your other PCs.
Laptops, other desktops, etc can then also access those shared
filesystems, which are stored in a secure and resilient way on a machine
that doesn't "also" get used for games/movies/videos/viruses/etc.
Again, cheap people will balk at this suggestion, and they are
ironically the people who tend to whine the loudest when they lose data. ;)

"The Cloud": Bullshit. All of this "Cloud" crap being touted by suits
everywhere is a set of technologies and capabilities that the real data
processing world has had for thirty years. There is nothing new here,
except for the people buying into it. The rest of us are just shaking
our heads as we watch the carnage. Why? Well, apart from the
hopefully-obvious problem of storing private data on other peoples'
servers...There are no charities here; the companies providing such
services do so today because it is profitable to do so today. The
moment it stops being profitable, those servers will be powered off and
the data deleted without a second thought. It has happened before!

I'm about done for the day; this ought to be enough food for thought.

[Chris Osborn]

I've had too many drives fail at the same time when running RAID5, so now I have my 4 drives split between a RAID1 partition and a RAID5 partition. All of my critical stuff like the server's OS, the configs, the mail spool, my source code, netboot root filesystems, etc. live on the RAID1 partition. Non-critical things that I could recover from other media, like scanned manuals, DVDs I've ripped, music, live on the RAID5. If I lose that stuff it's not that important and I can get it back, even if it's the hard way.

I also run daily backups to a secondary server which copies all the stuff on the RAID1 partition (plus data from several other servers). It doesn't touch the stuff on the RAID5 because it's not critical. Every night it runs an incremental backup to tape, and once a month I do a full backup of everything on the mirror server to tape. After the full backup is completed the previous month's set is taken home so there is never more than a month old backup off-site in case of catastrophe.

Of course I came up with this system by learning the hard way. :-/

It's been a while since I've had to do a full restore from tape. Most of the time I can restore from the mirror on the backup server. But the tapes do still get read from time to time because individual files need to be recovered, and it's also important to make sure the tape backups are actually working.

On Jun 2, 2014, at 7:07 AM, John Toscano <jptosca...@gmail.com> wrote:

Time to break out the paper tape punch?  Just don't crumple the roll of punched tape! Actually, I can relate to this discussion on multiple levels. When I worked for a government agency, we backed up certain data onto tape and stored the tapes securely.  One day I asked the computer folks to scan through all the backup tapes and download certain data for me to analyze. They replied that although they had 10 years worth of data stored, they did not actually have a program to read the tapes! Can you believe that? Well, long story made short,  they built the program to read the tapes and recovered the archived data from about 85% of the tapes. OTOH, in my personal computer system, I've had my bacon saved once already by using a RAID5 array of 250Gb drives. When one drive died, all I had to do was slip in a new 250Gb drive and let the array rebuild itself. Meantime all my data were still available. Of course, I couldn't leave well enough alone and instead I put in 4 new 1Tb drives to quadruple the size of the array. Then one of the 1Tb drives died under warranty and the manufacturer didn't have any 1Tb drives to replace it with,  so they sent me a 2Tb drive. That didn't play so well with my RAID array so I bought a new 1Tb drive and put the warranty - replacement 2Tb drive in an external USB/ESATA case. Yes, storage devices are inherently unreliable. I remember reading somewhere about some special DVD disc's that were designed for reliable archiving storage...

[Dan Emrick]

I'm not as deep into the physical properties of storage media as others, so I appreciate that's being shared here.  I will admit to falling away from a good backup discipline occasionally - and paying the price in time and aggravation.

What I'm really writing to say here is that Dave's comment about using a good PC for NAS is sound.  I've had a good experience with on even though I didn't go out and buy new hardware. 

Someone gave me an old Dell P4 that was being tossed.  I blew out the dust and did a general maintenance routine, added memory and a couple of large drives.  I probably should switch to something like FreeNAS, but on a whim I loaded a version of Linux w/o all the GUI stuff, set it in a corner and have almost forgotten it.  It serves four partitions of storage to the other computers on my home network and has run untouched for nearly three years.  An occasional re-boot if I don't get the generator running soon enough during power failures, but that's all.  My own mini-cloud - but under my control!

Dan

[John Frankle]

Interesting discussion all the way around. 

 

Most, if not all the stratagies discussed, talk about local storage: RAIDS, etc. . I guess nobody has experienced a housefire, or a severe lightening storm, or hurricane Sandy, or a power outage lasting weeks. Sorry to be a voice of doom, but these things do happen. Possibly statistically more significant than media failure. I wouldn't rule out the Cloud too quickly.

 

Paper tape storage????: Time to get that ASR33 Teletype out of the basement.

 

Regards,

 

John Frankle

[Dave McGuire]

On 06/03/2014 08:44 AM, John Frankle wrote:
> Most, if not all the stratagies discussed, talk about local storage:
> RAIDS, etc. . I guess nobody has experienced a housefire, or a severe
> lightening storm, or hurricane Sandy, or a power outage lasting weeks.
> Sorry to be a voice of doom, but these things do
> happen.

Yes, absolutely. Off-site backups are a great idea regardless of your
local storage mechanism. At the very least, get a USB- or
FireWire-connected hard drive, do periodic snapshots to it, and store it
at a friend's house, at work, or in a safe deposit box.

> Possibly statistically more significant than media failure.

Hoooboy no, not even close. It' significant, but nowhere near as
significant as media failure.

> I wouldn't rule out the Cloud too quickly.

I would. There is absolutely NOTHING about it that's a good idea.

> Paper tape storage????: Time to get that ASR33 Teletype out of the basement.

KA-CHUNK KA-CHUNK KA-CHUNK :-)

[John Frankle]

Dave,

You may laugh, but at one time that was music to my ears. Brings back
memories.

Regards,

John Frankle

----- Original Message -----
From: "Dave McGuire" <mcg...@neurotica.com>
To: <se...@googlegroups.com>
Sent: Tuesday, June 03, 2014 8:53 AM
Subject: Re: long-term data storage, was Re: [sebhc] Offload of H89 hard and
soft sectored disks

> --
> You received this message because you are subscribed to the Google Groups
> "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sebhc/538DC52F.3000404%40neurotica.com.

[Douglas Miller]

Fascinating discussions. I must admit I also have apprehension about the
Cloud, especially for these purposes.

something to note, especially for relatively static data 9i.e.
archives), that simply making a copy of your data is effectively like a
mirrored RAID volume - you have two (or more) copies of your data on
different spindles. I'm just pointing out that RAID may be overkill if
your data is not highly dynamic. The biggest benefits, arguably, for
RAID are for things like online transaction processing databases where
your data is constantly changing and you need to be protected
up-to-the-second. My main point is that if you make frequent
synchronizations of your data to separate spindles, preferably in
separate locations, you are as well protected as with RAID - possibly
better depending on location dispersal (all RAID mirrors tend to be in
the same enclosure and thus susceptible to localized disasters).

Also, I am worried about vaulting a winchester hard drive, as I seem to
recall horror stories about froze-up drives after sitting for long
periods. Anyone concur? I am thinking constantly spinning data is best,
promptly replacing and re-synching drives that go bad. Sort of like Mr.
Scott in the transporter loop...

[Dave McGuire]

Hey, I'd never laugh at that. I love my ASR-33!

-Dave

[Dave McGuire]

On 06/03/2014 09:05 AM, Douglas Miller wrote:
> something to note, especially for relatively static data 9i.e.
> archives), that simply making a copy of your data is effectively like a
> mirrored RAID volume - you have two (or more) copies of your data on
> different spindles. I'm just pointing out that RAID may be overkill if
> your data is not highly dynamic. The biggest benefits, arguably, for
> RAID are for things like online transaction processing databases where
> your data is constantly changing and you need to be protected
> up-to-the-second. My main point is that if you make frequent
> synchronizations of your data to separate spindles, preferably in
> separate locations, you are as well protected as with RAID - possibly
> better depending on location dispersal (all RAID mirrors tend to be in
> the same enclosure and thus susceptible to localized disasters).

Oh be careful here; there's more going on behind the scenes of a RAID
system than simply copying data back and forth between drives. A modern
RAID system does checksums at the block level, and can detect block
corruption and recover/reconstruct data from distributed copies. Simply
snapshotting drives back and forth is a very easy way to propagate
unseen data corruption, possibly overwriting good copies with bad.

RAID is more than just mirroring, man!

> Also, I am worried about vaulting a winchester hard drive, as I seem to
> recall horror stories about froze-up drives after sitting for long
> periods. Anyone concur? I am thinking constantly spinning data is best,
> promptly replacing and re-synching drives that go bad. Sort of like Mr.
> Scott in the transporter loop...

Ahh, I remember that episode. :)

Yes, cheap drives do succumb to that. But in this case, while nobody
mentioned any specific timetable, I'd say monthly is a good idea for
most applications, and that's plenty frequent enough to keep drives'
bearings and such in good shape.

[Douglas Miller]

Dave is right, of course. I was talking about using (winchester)
harddrives and not FLASH, which I think would be adequate at detecting
errors. Of course, having the extra error checking/correcting built into
the RAID is nice. Just saying that there are trade offs, and so manually
checksumming (MD5, SHA1, etc) and doing whole file/tarball
synchronization may be simpler/easier/cheaper than maintaining a RAID
and could provide the off-site benefits (or at least avoid the
single-enclosure risk). Ultimately it's about having multiple copies and
being able to tell which one is uncorrupted. Again, talking the
(more-)static data case of archival. In case anyone out there is
overwhelmed by the idea of purchasing, setting up, and administering a
RAID (it's not as hard as I make it sound), they should keep in mind
that there are alternatives that can protect their data reasonably well.
I think everyone here is saying "do something, anything is better than
nothing". It's not limited to "RAID or nothing at all". Again, I've got
nothing against RAID and even have a NAS RAID box setup - but even I
don't rely solely on that to protect my data - I have several copies on
different spindles in different enclosures. Now if I could only remember
where they all are...

I have never seen a modern harddisk controller pass bad data undetected,
but it is certainly theoretically possible. I did find out recently that
some laptop harddrives have gone to 4096 byte sectors (from the typical
512) which puts a great deal more pressure on error detection and
correction.

Nothing lasts forever...

[John Toscano]

Here's another thing to consider. It is called BTSync. It is derived from BitTorrent. You could set up a PC in one location with a big RAID array and set up to share that drive via BTSync from anywhere with an Internet connection. This is like a private "cloud" that you have full control over (and privacy also). If (and only if) you desire, you can share the BTSync drive with others and they will create a local copy on one of their drives. Any changes made by any of the sharers are automatically synced so all drives have identical data. I use this to share some files among 4 friends scattered around Minnesota and myself both when I am in MN (4 months of the year) and in TX (8 months of the year). All 5 drives in 5 locations would need to die in order for the BTSync share to fail. Given the relatively small volume of HDOS/CPM  software we want to preserve, maybe we should set up such a share and give the key to interested people on this list. Each of us could share what we have, and everyone on the share list would automatically get a copy.  And there would be copies in many locations so local disasters would  not harm the archive as a whole. The more people who share, the faster it becomes. If, for example, your hard drive goes belly up, put in a new one, re - install BTSync if needed, and your empty drive will get re - filled from all the online sharing drives.

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+unsubscribe@googlegroups.com.

To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538DD154.3050701%40gmail.com.

[Douglas Miller]

I'm assuming those 4 months in MN are Dec-Mar right? ;-) While I've enjoyed being in TX I must admit I prefer all 12 months in MN!

To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538DD154.3050701%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAD9POuaqfJVJP%2B7COpiTODRq7tOyOkF421pVjCNVdSjspZVp5w%40mail.gmail.com.

[Chris Elmquist]

On Tuesday (06/03/2014 at 09:06AM -0400), Dave McGuire wrote:
>
> Hey, I'd never laugh at that. I love my ASR-33!

And I love mine! (plural)...

--
Chris Elmquist

[John Toscano]

Ha, ha. I'm still suffering the sequelae of a torn rotator cuff from falling down while trying to blow snow out of my driveway! No, it's June-September in MN for me, now that I'm retired from 33 years at the Minneapolis VA Hospital and University of Minnesota College of Pharmacy. My daughter, son-in-law, and 2 grandchildren live in San Antonio year-around, and we get to live with them for the other 8 months. With any luck, I will never see snow or -20°F again!  ;^)

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538DD84C.9040706%40gmail.com.

[Chris Elmquist]

And there's others of us in MN that can't wait for -20F, tons of snow
and hope we never see +80F :-)

Back to the backup topic though, if we consider just the problem of
backing up and archiving H8/H89 software, I think you can pretty well
cover all of it ever written with a 32GB flash stick for $9.99 can't you?
Get a couple of those and make multiple copies and then file it away,
on-site and off.

I use this model for customer development projects-- archiving each
one to a seperate flash drive (or in some cases hard drive) and don't
try to keep all the everything online all the time.

I think we'll also see SSDs getting larger and cheaper and then they
may become practical for use as removable storage when connected
via USB or equiv. Right now, the overlap there is at about 128GB, with
the 128GB flash stick being far cheaper (and much slower) than the
128GB SSD. But even then, the 128GB SSD is about $70...

cje

> > <https://groups.google.com/d/msgid/sebhc/CAD9POuaqfJVJP%2B7COpiTODRq7tOyOkF421pVjCNVdSjspZVp5w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .

> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "SEBHC" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sebhc+un...@googlegroups.com.
> > To post to this group, send email to se...@googlegroups.com.
> > To view this discussion on the web visit

> > https://groups.google.com/d/msgid/sebhc/538DD84C.9040706%40gmail.com
> > <https://groups.google.com/d/msgid/sebhc/538DD84C.9040706%40gmail.com?utm_medium=email&utm_source=footer>
> > .

> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAD9POuacrves%2BReCC%3DYf0Zo3jOuGGfP-y4a4m-ztD-KyBv%2Bg_g%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--

Chris Elmquist

[Douglas Miller]

That would have been my approach at the beginning of this discussion. I
was naively assuming FLASH was static, but now I am hearing that there
can be bit-rot in FLASH memory as it sits on the shelf. Since it is
based on maintaining a charge in each cell, that is worrying. Sounds to
me like write-once optical media might be good, but then there's concern
about environmental affects on the plastic. After hearing all the gloom
and doom, I'm not sure how to go. I was thinking maybe using multiple
different kinds of media and periodically copying to fresh media? Of
course, you have to be able to detect if one copy got corrupted
(rotted), too. Perhaps the process needs to be based on keeping the data
moving, in some respect. Don't just put it in a vault and expect to be
able to read it 20 years from now...

I think we're arriving at a general-purpose archive process... Now if we
can only find a way to archive the archive process...

[Dave McGuire]

On 06/03/2014 10:17 AM, Chris Elmquist wrote:
> On Tuesday (06/03/2014 at 09:06AM -0400), Dave McGuire wrote:
>>
>> Hey, I'd never laugh at that. I love my ASR-33!
>
> And I love mine! (plural)...

Lucky bastard! Only one here. :-(

[Chris Elmquist]

On Tuesday (06/03/2014 at 11:02AM -0400), Dave McGuire wrote:
> On 06/03/2014 10:17 AM, Chris Elmquist wrote:
> > On Tuesday (06/03/2014 at 09:06AM -0400), Dave McGuire wrote:
> >>
> >> Hey, I'd never laugh at that. I love my ASR-33!
> >
> > And I love mine! (plural)...
>
> Lucky bastard! Only one here. :-(

Ya. I have three and two model 28 too.

Talk about maintainance... :-)

--
Chris Elmquist

[Chris Elmquist]

Yes. That's true. I guess we also have to decide if we need this
stuff to persist longer than ourselves or is the goal just to keep
it alive as long as we are?

http://en.wikipedia.org/wiki/Flash_memory

Archival or long-term storage

It is unclear how long flash memory will persist under archival
conditions—i.e., benign temperature and humidity with infrequent
access with or without prophylactic rewrite. Anecdotal evidence
suggests that the technology is reasonably robust on the scale
of years.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/538DDFAE.3080700%40gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--

Chris Elmquist

[Dave McGuire]

I bet!

[Glenn Roberts]

that's really the question Chris.  as long as there are people like us, with energy and interest we'll keep the software 'alive' in whatever the media of the day is.

when we're gone, who knows.  it is quite possible that the only remnants of this stuff that will be around (and usable) 100 years from now is what's on paper.  paper, ironically, is extremely persistent, so lock those source code listings in your favorite time capsule!

- Glenn

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20140603152125.GH24493%40n0jcf.net.

[steve shumaker]

sigh... wish i could score one....



there's a 28 for sale on C/L in PA right now if anyone is interested.

Steve

[Dave McGuire]

Oooh, where in PA, do you recall?

[steve shumaker]

stand by let me find it again


steve

[steve shumaker]

ehhh bit rot again
unit was in NY (Buffalo) and as of just now, it's been deleted. sorry.

Steve

[Dave McGuire]

Ah ok, no worries. Thanks for checking!

[Chris Elmquist]

I actually have greater fear of things in "The Cloud" disappearing while
I still need them. I make heavy use of documentation, schematics,
service manuals and similar that I find out on the net for all the old
gear I have here. But I always make a local copy of every one as I
pull it down because, as Dave mentioned, those web sites, servers and
services can disappear in a heartbeat when someone decides they are no
longer interesting (in monetary terms).

All of this goes on my NAS which I hope to keep running for 3 to 5 years
and then I'll need to migrate the stuff to the next interesting local
storage technology. This is my second NAS-- the first lasted just
about 5 yrs after which the power supply failed, not the disks :-)

So, I guess I kind of think of it all like a traveler with a backpack.
All my souvenirs are in that backpack and I just keep hefting it along
as I go. Hopefully I don't forget it on a train (I have a story about
corporate ID theft that goes with that comment) and hopefully nobody rips
it off and the bottom doesn't rot out of it while I am still traveling.

cje

> > https://groups.google.com/d/msgid/sebhc/538DDFAE.3080700%40gmail.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > Chris Elmquist
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "SEBHC" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sebhc+un...@googlegroups.com.
> > To post to this group, send email to se...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/sebhc/20140603152125.GH24493%40n0jcf.net

> > .
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CACkv5mB%3D5-fXxSBrwWbpDxGsL4XC3O8XqsTPgk7RSMRdGpo1%3DA%40mail.gmail.com.

[Jack Rubin]

Only problem with that metaphor is that the backpack becomes a steamer trunk and the traveler becomes weaker.
Just a thought to brighten up your day -

Jack

> -----Original Message-----
> From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf
> Of Chris Elmquist
> Sent: Tuesday, June 03, 2014 11:08 AM
> To: se...@googlegroups.com
> Subject: Re: long-term data storage, was Re: [sebhc] Offload of H89 hard and
> soft sectored disks
>

> >>>https://groups.google.com/d/msgid/sebhc/538DD84C.9040706%40gmai
> > > > >>>l.com
> > > > >>><
> > >
> https://groups.google.com/d/msgid/sebhc/538DD84C.9040706%40gmail.com
> > > ?utm_medium=email&utm_source=footer

> > > >
> > > > >>>.
> > > > >>>For more options, visit https://groups.google.com/d/optout.
> > > > >>>
> > > > >>--
> > > > >>You received this message because you are subscribed to the
> > > > >>Google
> > > Groups "SEBHC" group.
> > > > >>To unsubscribe from this group and stop receiving emails from
> > > > >>it, send
> > > an email to sebhc+un...@googlegroups.com.
> > > > >>To post to this group, send email to se...@googlegroups.com.
> > > > >>To view this discussion on the web visit
> > >

> https://groups.google.com/d/msgid/sebhc/CAD9POuacrves%2BReCC%3DYf0Z
> o

> > > 3jOuGGfP-y4a4m-ztD-KyBv%2Bg_g%40mail.gmail.com
> > > .
> > > > >>For more options, visit https://groups.google.com/d/optout.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > Groups "SEBHC" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> > > > send
> > > an email to sebhc+un...@googlegroups.com.
> > > > To post to this group, send email to se...@googlegroups.com.
> > > > To view this discussion on the web visit
> > >
> https://groups.google.com/d/msgid/sebhc/538DDFAE.3080700%40gmail.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > > --
> > > Chris Elmquist
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "SEBHC" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > > send an email to sebhc+un...@googlegroups.com.
> > > To post to this group, send email to se...@googlegroups.com.
> > > To view this discussion on the web visit
> > >
> https://groups.google.com/d/msgid/sebhc/20140603152125.GH24493%40n0j
> > > cf.net

> > > .
> > > For more options, visit https://groups.google.com/d/optout.
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "SEBHC" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email to sebhc+un...@googlegroups.com.
> > To post to this group, send email to se...@googlegroups.com.
> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/sebhc/CACkv5mB%3D5-
> fXxSBrwWbpDxGsL4XC3O8XqsTPgk7RSMRdGpo1%3DA%40mail.gmail.com.

> > For more options, visit https://groups.google.com/d/optout.
>
> --
> Chris Elmquist
>
> --
> You received this message because you are subscribed to the Google Groups
> "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sebhc/20140603160737.GK24493%40n0jcf
> .net.

[Chris Elmquist]

On Tuesday (06/03/2014 at 04:39PM +0000), Jack Rubin wrote:
> Only problem with that metaphor is that the backpack becomes a steamer trunk and the traveler becomes weaker.
> Just a thought to brighten up your day -

Ha. Ya. I guess I did forget to mention the part about getting a new
and bigger backpack before each trip :-)

cje

--
Chris Elmquist

[Jack Rubin]

Sort of off topic but if you want to watch your bits rot, here's a cool device from Jameco's new mailer -

http://www.jameco.com/Jameco/workshop/ProductNews/smallest-oscilloscope.html?sp_rid=MjAyMjI0MTY1NDkS1&sp_mid=9056719&spMailingID=9056719&spUserID=MjAyMjI0MTY1NDkS1&spJobID=283208922&spReportId=MjgzMjA4OTIyS0

> -----Original Message-----
> From: se...@googlegroups.com [mailto:se...@googlegroups.com] On Behalf
> Of Chris Elmquist
> Sent: Tuesday, June 03, 2014 11:47 AM
> To: se...@googlegroups.com
> Subject: Re: long-term data storage, was Re: [sebhc] Offload of H89 hard and
> soft sectored disks
>

> --
> You received this message because you are subscribed to the Google Groups
> "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sebhc/20140603164635.GL24493%40n0jcf

> .net.
> For more options, visit https://groups.google.com/d/optout.
>

> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4592 / Virus Database: 3955/7611 - Release Date: 06/02/14

[Dave McGuire]

On 06/03/2014 12:07 PM, Chris Elmquist wrote:
> I actually have greater fear of things in "The Cloud" disappearing while
> I still need them. I make heavy use of documentation, schematics,
> service manuals and similar that I find out on the net for all the old
> gear I have here. But I always make a local copy of every one as I
> pull it down because, as Dave mentioned, those web sites, servers and
> services can disappear in a heartbeat when someone decides they are no
> longer interesting (in monetary terms).
>
> All of this goes on my NAS which I hope to keep running for 3 to 5 years
> and then I'll need to migrate the stuff to the next interesting local
> storage technology. This is my second NAS-- the first lasted just
> about 5 yrs after which the power supply failed, not the disks :-)
>
> So, I guess I kind of think of it all like a traveler with a backpack.
> All my souvenirs are in that backpack and I just keep hefting it along
> as I go. Hopefully I don't forget it on a train (I have a story about
> corporate ID theft that goes with that comment) and hopefully nobody rips
> it off and the bottom doesn't rot out of it while I am still traveling.

The parallels between our professional lives continue to amaze me. :)

ra$ du -sh Books-Articles Documentation Datasheets AppNotes
41G Books-Articles
43G Documentation
1.9G Datasheets
265M AppNotes
ra$

[Chris Elmquist]

On Tuesday (06/03/2014 at 12:53PM -0400), Dave McGuire wrote:
> >
> > So, I guess I kind of think of it all like a traveler with a backpack.
> > All my souvenirs are in that backpack and I just keep hefting it along
> > as I go. Hopefully I don't forget it on a train (I have a story about
> > corporate ID theft that goes with that comment) and hopefully nobody rips
> > it off and the bottom doesn't rot out of it while I am still traveling.
>
> The parallels between our professional lives continue to amaze me. :)
>
> ra$ du -sh Books-Articles Documentation Datasheets AppNotes
> 41G Books-Articles
> 43G Documentation
> 1.9G Datasheets
> 265M AppNotes
> ra$

well, you're a little more organized than I am. Mine goes more like this,

13 % du -sh hp/ tektronix/ dec/ altair680/ altair8800/ heathkit/ wavetek/ ...
116M hp/
288M tektronix/
1.6G dec/
88M altair680/
1.8M altair8800/
675M heathkit/
33M wavetek/
254M cdp1802/
53M m6809/
322M teletype/
13M ti/
25M kim1/
23M swtpc6800/
...

and we didn't get anywhere near all the radio stuff :-)

--
Chris Elmquist

[steve shumaker]

I think I have you all beat:

E:\stuff
F:\old stuff


lol



Steve

[steve shumaker]

wow... an o-scope in your shirt pocket! that is cool.


steve

[Jbensadon]

So to combat bit rot, are there any good programs out there that read through all the files looking for errors, additions, changes, deletions?
I was planning on writing such a program that would act like a "data security guard", but there's just no time.

[Dave McGuire]

This sort of thing is really the job of the underlying filesystem..

[Lee Hart]

I use the old CRCK.COM program this way. It computes a CRCK-16 checksum
of every file, and can print the results, or save them to disk. They can
be compared to see if any undetected errors have slipped in.

Using it, I *know* there are cases where errors have crept into a file,
without CP/M catching it.

--
I do not waste my life in friction when it could be turned into
momentum. -- Frances Willard
--
Lee Hart's EV projects are at http://www.sunrise-ev.com/LeesEVs.htm

[Douglas Miller]

If anyone's asking my opinion, I would suggest you not do this on the
'89. If it were me, I'd be using something like the Linux utility
'md5sum' which can both generate and check the hashes on files. once you
put the hashes into a text file you can run a cron job to confirm that.
or you can manually invoke md5sum whenever you like. Of course, you have
to make sure your hashes don't get corrupted too. There is probably some
optimal scheme of storing hashes in one place and files in another, or
printing the hashes in a scan-able format on paper, or ...

with md5sum I'd typically:

md5sum files... >hashes

then to check:

md5sum -c hashes

I think there is also a SHA1 equivalent, if you're worried MD5 is not
discerning enough. Also, keep in mind there is a big different between
the ability of modern harddrives and filesystems to detect/correct disk
errors and that of the H89 - especially the H17 which used an 8-bit CRC
(if I recall correctly). The soft sector WDC controller chip did a
better job - as long as you did not use over-sized sectors.

[Dave McGuire]

Ahh, my "Documentation" directory is similarly divided by company. :)

> and we didn't get anywhere near all the radio stuff :-)

:-)

[George Farris]

I have used this before and it worked well.

http://dvdisaster.net/en/

I haven't done any definitive tests but it's better than just a single
DVD.

[Lee Hart]

Lee Hart wrote:
>> Well, *I'm* thinking about ways to have mass storage on old computers.
>> (I don't want my backup foundation built on the shifting sands of
>> here-today gone-tomorrow PC technology).

Dave McGuire wrote:
> Well good! Let's run with that, then. :-)
>
> "Floppy tape" systems functioned... barely...once hard drives appeared
> those products didn't last very long... The world of tape wasdominated
> by huge9-track drives. Some higher-end QIC subsystems appeared, with
> ISA-bus interfaces. Those were solid and fast (except when compared to
> 9-track), but way too expensive for most people... DC-100 was great at
> the time, but they sadly didn't stand the test of time.

Thanks for the info. I know lots of systems existed; but I don't know
how reliable they turned out to be.

Of course, the vast majority of people used whatever was the cheapest
system at the time. Thus the "bit rot" that so often plagues older systems.

So, I'm trying to figure out (with 20/20 hindsight) what kind of
reliable backup storage I *should* be using for my classic computers. Of
course I can modem all my files to a PC, and depend on its
cheapest-is-best technology. But that feels like just kicking the can
down the road. When I want that data back, I don't feel like there's any
guarantee I can *get* it back!

> Thinking about it further, it would be near-trivial to implement a
> SCSI host adapter for something like an H8.

Didn't Heath's H67 hard drive use the SASI interface, which is very
close to SCSI? The software already exists to run that. If a modern SCSI
drive can be interfaced in place of the old H67, that could be a viable
solution.

> DLT drives and media are small, cheap, readily available, and
> practically indestructible. I am willing to bet that a single 40GB tape
> cartridge would hold all software ever written for the H-8 and H-89.

Tell us more. I've never heard of it!

> But the software to drive it would be interesting. Perhaps something
> like tar could be written for CP/M and/or HDOS, with small buffers etc etc.
> That would actually be a viable project, I think.

I've only seen "tar" mentioned as the linux alternative to "zip" files.
Is that what you're referring to?

Is it *necessary* to compress files, when the media you're storing them
on is vastly bigger than necessary? I would think that when the purpose
is archiving, some format that spreads out the data reduntantly with
error correction is what would be used.

> Don't buy cheap consumer crap hardware... I recommend WD "Red" series drives.

Thanks! I don't know the difference between brands, and online reviews
are certainly no help (the blind advising the blind). EVERYTHING is made
in China, and there's often no way to tell the good from the bad at the
retail level.

> Next...Spinning drives up and down causes a great deal of wear and
> tear. Buy them, install them, and LEAVE THEM RUNNING.

That assumes you do continuous backups? I'm thinking more in terms of
spending days to backup most of my H8/89 software on some kind of media,
and then putting that media away in a safe place until I need it. It
seems like a hard drive running continuously will be less reliable than
one that is off except maybe for a few hours a month for updates.

> find a good checksummed filesystem and a comfortable way to use it.
> ZFS... was ported to Linux and FreeBSD (accessible) from Solaris
> (production-grade). That is the one I recommend...

Forgive my ignorance; but you're talking getting a version of linux that
uses ZFS to run on a Windows PC, and use that PC for a backup file
server? Use a serial port to transfer files between it and the H8/H89?
Keep in mind you're talking to someone who has never had networked
computers, and not been successful at using linux for anything.

> There are "canned" NAS packages, for free of course, that
> you download as a disk image and install on most any well-configured PC
> that essentially turns it into a NAS.

NAS = Networked Attached Storage? I had to google a bit to guess. The
NAS wiki seems to say it requires an ethernet or other high-speed
network to get data in/out. How would you do this with an H89?

Assuming you use an NAS with a network for other PCs: Are you using the
NAS *instead of* the PC's own hard drive for storing files and programs?
If so, what backs up the NAS when it fails? Or, is there some special
program that is saving backup copies of the PC's local hard drive on the
NAS, so the PC and the NAS back each other up?

[Douglas Miller]

I recall working with a backup device that used video tape (this is
before VHS and home video) to do backups. Can't recall the name, but it
might have been from Corvus (who also did hard disk systems). It
redundantly stored blocks of data in video frames with enough
checksumming to be able to choose a valid duplicate frame as needed.

But, at the risk of starting a barfight, my own point of view is that
eventually these glorious old machines (like ourselves) will become
unmaintainable and die. In my mind, the best way to preserve our
glorious experiences is through virtualization. To that end we would be
served to keep safe copies of all our files/programs/data on modern storage.

But one thing I've always wondered about is getting an '89 hooked up to
a modern computer through one of it's high speed communications links,
like a SASI (hard disk) port. I would think it's not too big a deal to
interface a SASI port to a PC parallel port. Then you'd need to write a
driver on the PC to proxy the disk commands from the '89 to your local
filesystems. The drive should be able to present anything the '89 needs
in the area of partition tables, etc.

One step further would be to write a driver for the '89 (I am a CP/Mer
and so think of CP/Net) to virtualize/network drives over the interface
to the PC. That might not seem like a big improvement, and maybe it
won't get us much, but I was thinking it could un-shackle us from the
SASI protocol and allow more simple function-shipping of file operations
over the interface - allowing the PC to store our actual files natively
instead of only raw disk images from the '89 (you could directly access
'89 files on your PC without running a disk image interpreter). Not sure
about HDOS, but CP/M was taking steps to get away from direct disk I/O
and push most things through the file interface, so many CP/M
applications would work in such a mode. I had played with a virtual
machine that does just that, pretends to be CP/M on a Z80 but uses the
native OS filesystem.

anyway, just in case there was nothing left to talk about...

[Lee Hart]

Douglas Miller wrote:
> ...In my mind, the best way to preserve our glorious experiences is

> through virtualization. To that end we would be served to keep safe
> copies of all our files/programs/data on modern storage.

This certainly works in the short term. Most of the people (who bother
to backup anything) probably do it with the inexpensive consumer-grade
hard drives, flash drives, etc. that they already have, or by putting it
out "somewhere" on the web. It's better than doing nothing!

> I've always wondered about is getting an '89 hooked up to

> a modern computer through one of its high speed communications links,

> like a SASI (hard disk) port. I would think it's not too big a deal to
> interface a SASI port to a PC parallel port.

It can certainly be done! I make a little retro-computer kit called the
"Membership Card". <http://www.sunrise-ev.com/MembershipCard.htm>. It
uses the RCA 1802 microprocessor and strictly 1970's technology. It has
a traditional old PC parallel port. The amount of hardware and software
it takes to implement it is trivial.

It plugs into a traditional old PC parallel port. You can transfer 8-bit
parallel data both ways, at high speed (like 100k bytes/second). The
software on the PC end is also trivial; I use a short QuickBASIC program.

Heath made a parallel port card for the H89 (the Z89-11). It was
basically the standard 3-port board, with one of the ports replaced by a
parallel port. An H89 with this card could also transfer data to/from a
PC at high speed with minimal software on both ends. *If* you have that
card, this is a fairly simple job.

> Then you'd need to write a driver on the PC to proxy the disk commands

> from the '89 to your local filesystems... write a driver for the '89

> to virtualize/network drives over the interface to the PC.

Once a hardware layer is in place (RS-232 serial, PC parallel, SCSI, or
whatever), then it becomes a software problem to use it to create this
kind of virtual disk interface. Writing such software is beyond me; but
there may be some here that could do it.

Heath supplied source for the BIOS, so there are examples of disk
drivers. Heath also had a SASA disk interface (the H67), so there are
examples of that code as well. The stumbling block is that few people
have that H67 interface board with the SASI port.

Maybe one of Noberto's boards can serve in place of the parallel or H67
board?

The problem so often is that a talented individual can use *his* skills
and *his* hardware to come up with a great solution... for his
special-case problem. But it is very difficult for others to follow in
his footsteps. It somehow never gets solved in the general-case. It
isn't fully documented, or the hardware he used isn't available, or the
reader just doesn't have the skill to do it.

So I think we're kind of stuck with the serial port, just because all
H8s and H89s had it.

I'm not sure what to do about software. Many use modem programs for
transfer. I have done it; and it works. But it's pretty tedious to
transfer more than a few files.

I have a program that creates virtual disk drives with an H89 serial
port (MOVE-IT). But no one else has it, and it is apparently unavailable
on the web; so it's a special-case solution. I can't even find a copy of
it that runs on a PC; so it's only good for transferring files between H89s.

[Dave McGuire]

On 06/04/2014 04:39 PM, Lee Hart wrote:
> Of course, the vast majority of people used whatever was the cheapest
> system at the time. Thus the "bit rot" that so often plagues older systems.

Individuals, yes, but not so much companies.

> So, I'm trying to figure out (with 20/20 hindsight) what kind of
> reliable backup storage I *should* be using for my classic computers. Of
> course I can modem all my files to a PC, and depend on its
> cheapest-is-best technology. But that feels like just kicking the can
> down the road. When I want that data back, I don't feel like there's any
> guarantee I can *get* it back!

This is a very real concern, yes.

>> Thinking about it further, it would be near-trivial to implement a
>> SCSI host adapter for something like an H8.
>
> Didn't Heath's H67 hard drive use the SASI interface, which is very
> close to SCSI? The software already exists to run that. If a modern SCSI
> drive can be interfaced in place of the old H67, that could be a viable
> solution.

First-generation SCSI is an evolution of SASI, but unfortunately there
isn't enough compatibility there to actually make anything work. :-(
More modern SCSI is very different, even at the electrical level.
Current SCSI implementations are even MORE different.

>> DLT drives and media are small, cheap, readily available, and
>> practically indestructible. I am willing to bet that a single 40GB tape
>> cartridge would hold all software ever written for the H-8 and H-89.
>
> Tell us more. I've never heard of it!

You've never heard of DLT? It was *the* mainstream tape technology
from the early 1990s up until a few years ago. It originally grew out
of the DEC TK50 design, 95MB on a cartridge back in 1984, and ended up
at the current iteration, DLT-S4, which puts 800GB on a cartridge.
(which still looks just like a TK50! :))

Middle-aged DLT drives, like the DLT-7000 for example, can be had in
the $20-30 range. The tapes are cheap and readily available. The
interface is F/W SCSI. They store 35GB on a tape, uncompressed. You
can enable data compression that, for otherwise-uncompressed data,
doubles the storage capacity to 70GB.

>> But the software to drive it would be interesting. Perhaps something
>> like tar could be written for CP/M and/or HDOS, with small buffers etc
>> etc.
>> That would actually be a viable project, I think.
>
> I've only seen "tar" mentioned as the linux alternative to "zip" files.
> Is that what you're referring to?

Tar is "Tape ARchiver". It is not a Linux alternative to zip files;
it predates them by many years. Tar was originally developed for
reading/writing data from/to tape drives, but you can create "tar files"
instead, and that's the vast majority of tar's use now. Tar does not
compress data; it combines one or more files into one file with some
metadata to facilitate later extraction. Then, separately, if desired,
you can compress the tar file. This is a lot more efficient than the
way the zip works.

Tar is the de-facto standard file archive format in the UNIX world.

> Is it *necessary* to compress files, when the media you're storing them
> on is vastly bigger than necessary? I would think that when the purpose
> is archiving, some format that spreads out the data reduntantly with
> error correction is what would be used.

It is definitely NOT necessary to compress data for storage,
especially when we're talking about comparatively tiny bits of data like
(say) everything ever written for CP/M. Mathematically, compressing
that data beforehand makes the hash/checksum algorithms less effective,
so it's safer to store it uncompressed, where longevity and reliability
are concerned.

>> Don't buy cheap consumer crap hardware... I recommend WD "Red" series
>> drives.
>
> Thanks! I don't know the difference between brands, and online reviews
> are certainly no help (the blind advising the blind). EVERYTHING is made
> in China, and there's often no way to tell the good from the bad at the
> retail level.

Well...I'm sure you're speaking figuratively, but most hard drives are
made in Thailand, and the WD Red series in particular is made in
Malaysia. ;)

>> Next...Spinning drives up and down causes a great deal of wear and
>> tear. Buy them, install them, and LEAVE THEM RUNNING.
>
> That assumes you do continuous backups? I'm thinking more in terms of
> spending days to backup most of my H8/89 software on some kind of media,
> and then putting that media away in a safe place until I need it.

Either approach works great.

> It
> seems like a hard drive running continuously will be less reliable than
> one that is off except maybe for a few hours a month for updates.

Most of the time, with drives built for 24/7 use (which are the only
ones that aren't garbage) this is actually not the case. A lot more
wear and tear happens, especially on the heads, during spin-up and
spin-down, due to take off/landing.

>> find a good checksummed filesystem and a comfortable way to use it.
>> ZFS... was ported to Linux and FreeBSD (accessible) from Solaris
>> (production-grade). That is the one I recommend...
>
> Forgive my ignorance; but you're talking getting a version of linux that
> uses ZFS to run on a Windows PC,

Well, on a PC...Windows would be gone at that point.

> and use that PC for a backup file server?

Not necessarily as a backup file server, but as a file server in
general, yes.

> Use a serial port to transfer files between it and the H8/H89?

You'd transfer files to/from whatever computer you actually sit in
front of (which had better not be a *server*) the same way you do now.
You'd have a chunk of space on your file server mounted over the network
on your desktop machine, whatever OS that happens to be running.
Whatever software you're using to transfer to/from the H8/H89 cannot
tell that it was actually coming in via an Ethernet cable rather from a
locally-attached drive.

> Keep in mind you're talking to someone who has never had networked
> computers, and not been successful at using linux for anything.

Understood; I can help. But, if you've survived Windows with your
sanity intact, you've been through FAR greater fires. ;)

>> There are "canned" NAS packages, for free of course, that
>> you download as a disk image and install on most any well-configured PC
>> that essentially turns it into a NAS.
>
> NAS = Networked Attached Storage? I had to google a bit to guess.

Yes, I'm sorry.

> The
> NAS wiki seems to say it requires an ethernet or other high-speed
> network to get data in/out. How would you do this with an H89?
>
> Assuming you use an NAS with a network for other PCs: Are you using the
> NAS *instead of* the PC's own hard drive for storing files and programs?

Yes, exactly. A network file server serves disk storage to other
computers *on the network*. The same desktop machine that you currently
use would be the one to squirt data back & forth to the H89.

Essentially you'd have a folder on your desktop (or somewhere) that,
for all practical purposes, looks just like any other folder. But, when
you open it and see files, and open/edit/create/delete or otherwise
manipulate files, stuff happens on the network, and the actual bytes
making up those files reside on the file server. Applications
(including serial comm programs) do not see any difference.

Redundant, highly reliable storage is a lot more expensive per byte
than storage on a single consumer-grade disk drive in a consumer-grade
PC. So you don't want to store, say, that TV show that you downloaded
yesterday and only plan to watch once, on the file server. If your
desktop PC's drive fails and you lose THAT file, it's no big deal. But,
for instance, one of the few known copies of something like a PL/I
compiler for HDOS or whatever, that's important, you don't necessarily
know that you can re-obtain it at any time...The floppies you got it
from might have rotted away to dust, or everyone else who "has a copy of
it" may have stored it on a dime-store hard drive in a dime-store
PC...so those copies of the file, if they even exist, could be full of
holes and you'd never know it. So, you pick and choose what goes on
your expensive-but-very-reliable storage, and what doesn't. Use it, but
don't waste it.

> If so, what backs up the NAS when it fails?

Well, the first point is that it's far less prone to failure in the
first place. You won't be surfing the web or watching movies on the
file server, so it won't be subject those sorts of stresses. It is
treated as essentially a storage "appliance".

Next, it is built to be resilient in the face of an eventual
(inevitable) failure. Resiliency of that sort comes from things like
redundant disk storage, usually a form of RAID array, where a filesystem
is spread across multiple physical disk drives but appears to be a
single disk drive, but has enough redundant information interspersed
(transparently...users can't see this) within it such that no user data
is lost if one of the drives in the array fails.

> Or, is there some special
> program that is saving backup copies of the PC's local hard drive on the
> NAS, so the PC and the NAS back each other up?

That is another possible approach, yes. There's really a lot of
flexibility in the way you can do things; you can set up whatever sort
of arrangement works best for your usage patterns and
time/effort/space/money budget and data preservation requirements.

[Dave McGuire]

On 06/04/2014 06:04 PM, Lee Hart wrote:
> I have a program that creates virtual disk drives with an H89 serial
> port (MOVE-IT). But no one else has it, and it is apparently unavailable
> on the web; so it's a special-case solution. I can't even find a copy of
> it that runs on a PC; so it's only good for transferring files between
> H89s.

That sounds really, really familiar.

I'd think it'd be fairly trivial to sniff the protocol, document it,
and write an implementation for some other platform.

[Norberto Collado]

> Didn't Heath's H67 hard drive use the SASI interface, which is very
> close to SCSI? The software already exists to run that. If a modern SCSI
> drive can be interfaced in place of the old H67, that could be a viable
> solution.

> First-generation SCSI is an evolution of SASI, but unfortunately there
> isn't enough compatibility there to actually make anything work. :-(>
> More modern SCSI is very different, even at the electrical level.
> Current SCSI implementations are even MORE different.

 

Dave is correct and also HDOS does a negative testing to the H67 and expects certain behaviour that SCSI does not support. So nowhere to go. 

 

There is an IDE to SAS adapter and I tested one of them on the Z67-IDE controller with two SAS drives and it worked fine.

 

For backups, I'm using Glenn solution by using the USB flash device and also I use Dan solution via the FT245 controller as well. Once in the PC, then it goes to my back-up drive and then to a DVD R/W media.

 

These emails threads reminded me that I need to do a backup of my server which I have never done!!!

 

Norberto

[Kenneth L. Owen]

Hi All,

 

I don’t propose this as a ‘solution’ to the archiving issue, but rather as a presentation of one man’s attempt to do better than just pray.

 

I run a small network.  It is composed of three sub-nets:  my workshop net connected to the WIFI net connected to the top level net where Ethernet is interfaced and available to all machines.

 

I run servers on the two ends – a network share server running Linux hosting two shares formatted Ext-3 and shared to my Linux boxes via NFS and to my Windows boxes via Samba runs on the top end.  Another Linux server running BACKUP-PC runs on the other end and keeps full backups at ages 1 week, 1 month, 6 months and 1 year.  It performs nightly incremental backups of the shares.

 

If a share hosted on the server fails, I install a new drive and restore from the BACKUP-PC server.  If the BACKUP-PC Data Drive Fails, I install a new drive and manually run a full backup to restart the process.

 

The Operating System runs on one HD and is imaged to a different HD on the machine.  If the OS disk fails, I install a new disk and restore the image from the other HD.  The image is reworked at periodic intervals due to OS updates or significant application changes.  The images are also maintained on DVDs at a different location.

 

My Heaths communicate to a Linux or Windows machine via a modem program running on the Heath and another modem application on the networked machine which saves the files on one of my network shares.

 

For HDOS, I use MAPLE (or MAPLE340, a patched version of MAPLE that will use port 340Q instead of 330Q).  MAPLE will transfer files using X-modem at 4800 baud for a 2 MHz clocked machine or at 9600 baud if faster clock is used.  MAPLE only goes up to 9600 baud max as originally written.

 

X-modem will only send one file at a time and requires typing the filename to send on the source machine and the filename to save on the receiving machine.  It is tedious when sending many files.

 

For CP/M (and CP/M with ZCPR), I use ZMP as the modem program on the Heath.  ZMP can use port A (330Q) or port B (340Q).  It does about all modes up to and including Z-modem.  It will send at 4800 baud on a 2 MHz box, 9600 baud on a 4 MHz box and 19200 baud if running 8 MHz or higher.  It will allow sending files using wild cards, so all files in a user area can be sent as one operation.

 

On the receiving machine, the target directory (or du [drive;user]) must be set prior to sending.  Then the sending machine starts the transfer and the receiving machine will automatically receive to the designated directory – all done from the sending end after setting the destination directory on the receiving machine.

 

Both X-modem and Z-modem use checksums for transfer.  I believe MAPLE uses CRC16.  ZMP uses CRC32.  Both applications will re-transmit bad blocks until they get it right.

 

One of the files sent is a checksum file for all of the files in the group.  On HDOS, I use a patched version of CHECK.ABS to generate the checksum file.  On CP/M, I use CRC.COM.

 

For upload, the Heath sends the files to a networked computer which saves the files on a Linux server.  Once the files are safely uploaded, the CRC data is loaded into a database by filename and version.  The files are now copied into a directory structure based on OS, Application type, etc. and verified against the uploaded copy.

 

When I am ready to archive to CD or DVD, I generate a SHA1 sum file for the files to be written to the disk.  Now I am ready to make multiple copies and then verify them with the SHA1 sum to ensure integrity.  The disk creation date is recorded and date that the disk is to be re-recorded in the future.  The disks are stored in a CD/DVD case in an air conditioned environment at separate locations for safe keeping.

 

-- ken

 

[Jbensadon]

Hi guys,

I'm finishing up a project in the N8VEM group that might interest some here.
It's a replacement 8080A CPU board for the ALTAIR and/or IMSAI.  I am building a limited run of blank boards, if anyone is interested, the cost of a bare board will be $20ea.

Features are:

CPU: 8080A
UARTS: 2x 8250, RS-232
RAM: 2x 32K
ROM: 32K
I/O: 8 input, 8 output pins
SPI to SD Card interface & SD Card socket
ALTAIR & IMSAI Front Panel Connectors.

The ROM can be permanent or Shadow ROM, selectable in blocks of 8K.
The RAM can be on or off board, selectable in blocks of 8K
Where ROM is selected in a block it overlaps the RAM on reads, but writes go through to RAM.
The CPU can be deselected with jumpers and the board will work as RAM/ROM and I/O for another CPU on the S-100 bus.

Regards,
Josh Bensadon

[Jack Rubin]

You’ve probably already done this, but are there easy test points for checking/monitoring voltages without needing an extender card?

Jack

No virus found in this message.
Checked by AVG - www.avg.com

Version: 2014.0.4592 / Virus Database: 3955/7625 - Release Date: 06/05/14

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SNT145-W140F5369B6DA554D561C64BBB2D0%40phx.gbl.

[Chris Elmquist]

On Wednesday (06/04/2014 at 05:04PM -0500), Lee Hart wrote:
> people have that H67 interface board with the SASI port.
>
> Maybe one of Noberto's boards can serve in place of the parallel or
> H67 board?
>
> The problem so often is that a talented individual can use *his*
> skills and *his* hardware to come up with a great solution... for
> his special-case problem. But it is very difficult for others to
> follow in his footsteps. It somehow never gets solved in the
> general-case. It isn't fully documented, or the hardware he used
> isn't available, or the reader just doesn't have the skill to do it.
>
> So I think we're kind of stuck with the serial port, just because
> all H8s and H89s had it.

We have had the FT245 interface to H8 and H89 running for several years
with quite a number of folks on this list contributing to the effort.
This gives you a USB 2.0 interface between your PC and the Heath machine
and runs as fast as the Heath machine can drive it.

With the associated software, we can move files to and from the PC and
we can emulate a disk drive on the Heath machine from a file image on the
PC in real-time. I believe support is there for both HDOS and CP/M now.

--
Chris Elmquist

[Dave McGuire]

On 06/02/2014 10:20 AM, Chris Osborn wrote:
> I've had too many drives fail at the same time when running RAID5, so
> now I have my 4 drives split between a RAID1 partition and a RAID5
> partition.

This is one of the nuances of data storage system design. If you buy
a stack of brand-new drives from the same vendor at the same time,
they'll likely be from the same production run...and you'd be amazed at
the consistency of their lifetimes. A few years down the road a cluster
of them will fail within days of each other. I've seen this happen over
and over. If at all possible, mix and match drives from different
production runs...buy a few now, well in advance of construction of the
array, wait a month, buy a few more, etc.

> Of course I came up with this system by learning the hard way. :-/

:-(

> It's been a while since I've had to do a full restore from tape. Most of
> the time I can restore from the mirror on the backup server. But the
> tapes do still get read from time to time because individual files need
> to be recovered, and it's also important to make sure the tape backups
> are actually working.

An old friend of mine once said that if you don't test your backups,
you don't have backups...you have hopes.

All of this that we've been talking about may seem like a lot of work
to some, but if the data is worth preserving, it's worth taking these
sorts of steps to preserve. If it's not, then, well, just let it die.

[Gregg Chandler]

I did essentially what I believe you said. I virtualized my H-8 and its
HDOS file system, including the front panel. HDOS is probably easier to do
than CP/M in this regard. I translated HDOS file access into the host (in
my case Windows,) file access. I was able to mount Windows folders as a
virtual devices--up to eight of them at once. Individual files sizes grew
to a couple of megabytes apiece as well. The only thing that needed
patching, which I was too lazy to do, was the files sizes displayed in
directory listings exceeded the buffer space allocated by PIP. I had wanted
to interface to the network via ethernet, but was unsuccessful in convincing
anyone to create a board.

[Gregg Chandler]

My experience with the $20-$30 DLT tape drives off of ebay has not been
good. I believe the mechanical mechanisms were worn out. I purchased new
tapes, but found the drives themselves to be less than reliable.

[Gregg Chandler]

I agree that you must test your backups.

I was called in to consult on an IBM unix system once, where a company had
done everything I had ever recommended. Daily backups, Weekly Backups, and
Monthly backups rotated through a bank vault.

I had the sad task of informing them that when their expensive IBM
consultant had added a second drive to the system, and moved all of the
company data to the new drive, he had apparently not modified the backup
system. They had excellent backups of the OS, and none of their data.

I hadn't set any of it up, they were just paying me to hold their hand
through the restore process. Needless to say, they were in a bad situation.
Ontrack couldn't get their data back after they drove the drive there--not
trusting it to FedEx. One simple fire drill would have made all of this
clear.

[Dave McGuire]

The drives themselves are very reliable as long as they're not beat to
crap. The same goes for the tapes.

The trick with the drives is to purchase only ones that are sold as
being in good condition (so you can get a refund if they're not), and
ones with very good pictures. Look for lots of dust in the mechanism,
indicating not only lots of use, but infrequent care. Avoid those.

Tapes are easier...buy them from reputable sellers when they are
listed as having been "single-use backups". Many companies have a
policy that a tape cartridge must only be used once, then they either
destroy or surplus the tapes.

-Dave

[Norberto]

Can you provide an schematic? I do not know that much to do a design that can meet your request.

Sent from my Verizon Wireless 4G LTE DROID

Gregg Chandler <in...@esx.com> wrote:

It was my understanding that the Ethernet on the one board was more of a replacement for RS-232.. I apologize if I mis-understood.. My code requires an API more like Berkley sockets.. I looked at the ethernet interface of an Arduino, and it wasn’t sufficient to support my code base either—in particular, it did not support the select function.


On 6/5/14 3:33 PM, "Norberto" <norberto...@koyado.com> wrote:

About the Ethernet board I only have a similar board for the H8. I think we talk about this and my request was for someone to provide schematics. Also it was mentioned to buy off the shelf board with such capability and then interface to the H8/H89
Sent from my Verizon Wireless 4G LTE DROID

>> Of course, the vast majority of people used whatever was the cheapest
>> system at the time. Thus the "bit rot" that so often plagues older
>> systems.
>>

>> So, I'm trying to figure out (with 20/20 hindsight) what kind of
>> reliable backup storage I *should* be using for my classic computers.
>> Of course I can modem all my files to a PC, and depend on its
>> cheapest-is-best technology. But that feels like just kicking the can
>> down the road. When I want that data back, I don't feel like there's
>> any guarantee I can *get* it back!
>>

>>> Thinking about it further, it would be near-trivial to implement a
>>> SCSI host adapter for something like an H8.
>>
>> Didn't Heath's H67 hard drive use the SASI interface, which is very
>> close to SCSI? The software already exists to run that. If a modern
>> SCSI drive can be interfaced in place of the old H67, that could be a
>> viable solution.
>>

>>> DLT drives and media are small, cheap, readily available, and
>>> practically indestructible.  I am willing to bet that a single 40GB tape
>>> cartridge would hold all software ever written for the H-8 and H-89.
>>
>> Tell us more. I've never heard of it!
>>

>>> But the software to drive it would be interesting.  Perhaps something
>>> like tar could be written for CP/M and/or HDOS, with small buffers
>>> etc etc.
>>> That would actually be a viable project, I think.
>>
>> I've only seen "tar" mentioned as the linux alternative to "zip"
>> files. Is that what you're referring to?
>>

>> Is it *necessary* to compress files, when the media you're storing
>> them on is vastly bigger than necessary? I would think that when the
>> purpose is archiving, some format that spreads out the data
>> reduntantly with error correction is what would be used.
>>

>>> Don't buy cheap consumer crap hardware... I recommend WD "Red" series
>>> drives.
>>
>> Thanks! I don't know the difference between brands, and online reviews
>> are certainly no help (the blind advising the blind). EVERYTHING is
>> made in China, and there's often no way to tell the good from the bad
>> at the retail level.
>>

>>> Next...Spinning drives up and down causes a great deal of wear and
>>> tear. Buy them, install them, and LEAVE THEM RUNNING.
>>
>> That assumes you do continuous backups? I'm thinking more in terms of
>> spending days to backup most of my H8/89 software on some kind of
>> media, and then putting that media away in a safe place until I need

>> it. It seems like a hard drive running continuously will be less

>> reliable than one that is off except maybe for a few hours a month for
>> updates.
>>

>>> find a good checksummed filesystem and a comfortable way to use it.
>>> ZFS... was ported to Linux and FreeBSD (accessible) from Solaris
>>> (production-grade). That is the one I recommend...
>>
>> Forgive my ignorance; but you're talking getting a version of linux

>> that uses ZFS to run on a Windows PC, and use that PC for a backup
>> file server? Use a serial port to transfer files between it and the
>> H8/H89? Keep in mind you're talking to someone who has never had

>> networked computers, and not been successful at using linux for anything.
>>

>>> There are "canned" NAS packages, for free of course, that
>>> you download as a disk image and install on most any well-configured PC
>>> that essentially turns it into a NAS.
>>

>> NAS = Networked Attached Storage? I had to google a bit to guess. The

>> NAS wiki seems to say it requires an ethernet or other high-speed
>> network to get data in/out. How would you do this with an H89?
>>
>> Assuming you use an NAS with a network for other PCs: Are you using
>> the NAS *instead of* the PC's own hard drive for storing files and

>> programs? If so, what backs up the NAS when it fails? Or, is there

[Norberto Collado]

With a combination of parts from the Z67-IDE+ and the H8-Z67 controller you can do all 3. The hard part is the hardware interface to the Ethernet IC and the TCP stack on the microcontroller.

 

Norberto

-------- Original Message --------
Subject: Re: long-term data storage, was Re: [sebhc] Offload of H89 hard
and soft sectored disks

From: Chris Elmquist <chr...@pobox.com>
Date: Thu, June 05, 2014 4:00 pm
To: se...@googlegroups.com

I remember some of this discussion and I believe it fragmented into two
camps, with one wanting what amounts to a terminal server with an async
connection to a UART on the Heath machine and another camp that wants
to run the entire TCP stack on the Heath.

I think I'm in the middle.

I would propose an ethernet interface that is assisted by a modern
microcontroller to do the following things,

1) provide a parallel interface to the Heath system with command, status
and data ports that are byte wide, read/write interfaces.

2) provide a synchronous serial interface to the ethernet controller.
Most of the low-cost ethernet controllers appearing in Arduino and
PIC land use a SPI interface. This would be painfully slow to support
directly on a Heath H8 or H89.

3) Have a soft API where, depending on the firmware loaded, you can
choose to have the entire TCP stack on the microcontroller and have
terminal sessions supported across the host interface, or you can have
half the TCP stack and a sockets-like API to the microcontroller or,
what I want, a MAC layer protocol where I can put and get packets on
the ethernet that are not TCP protocol.

As much as I dislike PICs, they do have a nice interface called the PMP
(parallel master port) which takes care of #1 right out of the box.
There are then a zillion reference designs and example code in PIC-land
for hooking up the ethernet controller and code to make it go.

I'm pretty busy with a startup company these days but I'd sure be happy
to colaborate with folks that want to put something like this together.
It is applicable to lots of platforms and not just the Heath H8 or H89.

Chris

> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CFB654F2.DAD67%25info%40esx.com.

> For more options, visit https://groups.google.com/d/optout.

--
Chris Elmquist

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20140605230041.GJ10582%40n0jcf.net.

[Jbensadon]

Hi Jack,

I was thinking of adding test points, and LED's for the various supply voltages, but to bring them to the top is going to be a challenge... there just isn't any room to run more traces.  I would have to go down to .010 traces and start running two between the IC pins, which is something I don't like to do.  Let me try sending a picture of the board... you'll see how packed it is.

Cheers,
Josh

 

 

---

From: j...@ckrubin.us
To: se...@googlegroups.com
Subject: RE: [sebhc] RE: ALTAIR or IMSAI replacement CPU board
Date: Thu, 5 Jun 2014 15:13:27 +0000

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/d5af67babf754aa496bd63c929e5d7f6%40BLUPR05MB166.namprd05.prod.outlook.com.

[Jbensadon]

Oh, I should also mention that Rich Cini and Don Caprio are releasing their Mini Front Panel board, which is a copy of the IMSAI FP.
It would go with this CPU board very nicely.

---

From: j...@ckrubin.us
To: se...@googlegroups.com
Subject: RE: [sebhc] RE: ALTAIR or IMSAI replacement CPU board
Date: Thu, 5 Jun 2014 15:13:27 +0000

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/d5af67babf754aa496bd63c929e5d7f6%40BLUPR05MB166.namprd05.prod.outlook.com.