filling remaining array elements with fixed value

Er no. If the filesystem can't be read then the file can't be read. Consider whether you will be able to interpret the contents of a perfectly preserved file foo.xah

Reply to
Tom Gardner
Loading thread data ...

If you are talking about the Mill, then yes it's in Maynard.

Did you ever climb the clock tower ?

Some memories for you in case you did:

formatting link

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

No, but it's been through a incompatible language revision.

(Which is probably a sign of language maturity. :-))

Don't forget as well that a decade ago Perl was very popular and now it's a legacy language.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

Yes the smiley was because I thought the concept amusing, but at the same time I am serious about it being perfectly feasible.

I expect it will be OK, I can and do still run *DOS* compilers under dosemu or dosbox on modern system. There is still active development I believe for the "vintage games" market I think. And software is a lot more important today, there will be that much more incentive to have a virtualization solution for todays niche applications IMO. Even if x86 binaries cannot be run directly under the emulator of the day, I would bet it would need no more than one more "level" of virtualization to do so.

Yes but then *you* might have to do the maintaining, porting some open source simulator to newer architectures. I can't do that, but I can make sure I can still compile my old stuff when I move to a new system, and make a virtual machine using available tools if I can't.

--

John Devereux
Reply to
John Devereux

"Mill" is probably an appropriate name for the place -- it sat

*on* the water (probably a waterwheel somewhere), was built from large wooden beams, etc.

No, can't even recall there *being* one. It was a long trek from Cambridge out past 128 (25 miles?). By the time I could get my car, drive there, park and find my way into the "basement" (it felt like I was headed *down* to the junk room), more than an hour would have passed. The same for the return trip.

In between, lots of fun crawling through Gayloards full of PCB's, power supplies, "flip chips", core planes, etc. Then, trying to get all the goodies back out to the car. And, having to get them

*out* of the car when I got back to Cambridge...

Of course, this had to happen in the middle of a *weekday* (when they were open for business) which meant finding time in my class schedule to accommodate the trip.

And, eventually, making time to dig through all the goodies and figure out what the hell I had acquired! :>

Cool! Had I known something like that was there, I undoubtedly would have availed myself of the opportunity. (sigh)

Reply to
Don Y

Was it an RP07?

At my Alma Mater there was an RP07 disk crash that was so violent they evacuated the campus because they thought it was a bomb that went off. It was situated right next to a beam bearing of the

9 floors of the administrative building, and there was ample resonance in the 8 floors above it.

It thrashed the immediate surroindings quite well too, the DEC20 was saved by the same beam, being behind it.

Evidently the RP07 has the head arms in a different configuration relative to the spinning platters, different from 99% of all other drives out there, so it had a failure mode where the heads just dug into the platters (instead of gently skirting them), thereby making a ripple to all the other heads doing the same, and stopping the pack instantly. Or, rather, transferring the 3600 rpm volume of a 20 kg package to the disk drive itself, in a matter of milliseconds, making it trash wildly about in the computer room.

The DEC20 it was attached to did not crash, the disk was not hold swap or PS:, but several processes hung for a while before dying.

I was editing in emacs at the time, and was connected to a directory at the rp07. It hung for a few minutes, and then recovered. (I was logged on from the other end of campus).

I was able to save the document before being evacuated.

-- mrr

Reply to
Morten Reistad

That's the same class of device we're discussing. *Literally* the size of a washing machine (USA) probably weighing upwards of several *hundred* pounds! It supported a *removable* "disk cartridge" that consisted of *multiple* (9 or 10?) 14 inch diameter platters all revolving on the same spindle.

I.e., the same thing that you find in a "modern" disc drive but significantly larger (because the heads couldn't be made as small as current technology).

[hint: a 14 inch platter has some significant weight to it as it has to be *rigid* across those entire 14 inches lest it wobble/wiggle and hit the head assembly that *slides* between the platters. I don't recall how much the "pack" weighed but installing/removing one wasn't something you did "casually" -- they were heavy!]

To keep the total access time low, the platters want to rotate very quickly as a request can arrive at any relative angular position of the platters wrt the *desired* angular position.

Concurrently, a "comb" of heads have to move in or out to the correct cylinder. Simple when the distances involved are an inch or two *and* the mechanism being moved is insubstantial.

But, when the head assembly has some mass to it and you want to be able to drive it in/out "at will", there's a lot more kinetic energy involved.

The relative velocity at the periphery of the platters -- contrasted to the "stationary" head assembly -- invites some interesting conflicts! :>

Wow! The crashes I've seen (after the fact) "simply" beat the hell out of the drive itself. Like some imaginary beast was trapped inside and started beating on the enclosure FROM THE INSIDE with an *axe*. Think of the _Forbidden Planet_ scene in which the "Monster (from the id)" is trying to pound its way through the Krell metal shield around Morbious' home...

["Um, why didn't the monster 'materialize' *inside* the house?? Seems silly to have to walk *to* the house when you it could just as easily have come into existence anywhere on the planet!"]

Usually, the head assembly gets "violently relocated". I've heard claims of platters shattering (which would have to be REALLY impressive) but never saw anything like that.

Somehow, I suspect your document wasn't very high on their priorities, at the time!

Reply to
Don Y

We are mixing up levels here. There are files (such as code for the product, and other files within the virtual machine) on a filesystem, and that filesystem is on an virtual machine image file, which is on the host's filesystem. All the files need to be readable at all levels to get access to the data.

A point I made a few posts up was that it was best to store the virtual machine disk image as a single straight file containing the filesystem, rather than a disk container format specific to the virtual machine system (such as a ".vdi" disk for VirtualBox). Such container formats are usually more efficient - but there is the possibility that future emulation software will not support the older formats.

Reply to
David Brown

I have used one with capacitive sensing.

Guess what happens to the feed reel ?

It continues to rotate, spiting tape all around the room ahead of the reader :-).

The nice thing about paper tape that you don't necessary need a reader to find out what is on the tape. I once was quite fluent with the ASCII character table, so reading the paper tape visually was not that hard, although slower than the TTY.

Reply to
upsidedown

The RP07 was non-removable (Winchester style) drive with a replaceable HDA (Head Disk Assembly). The rotating platters might have been a few kilograms, the whole HDA perhaps 20 kg and the whole drive much more than that. If the platters really stopped in a millisecond i.e. 1/16 of a rotation, transferring the angular momentum to the HDA, which no doubt broke loose from the drive starting to rotate.

Apparently there were no people in the room, since there would have been injuries.

Computing was dangerous in the past with shrapnels from failing disks, deep scars due to fast paper tapes, crushed limbs due to heavy equipment, electrocution from anode and mains voltages etc.

Reply to
upsidedown

Well yes, I'd have thought that too. But I /don't/ remember it happening, and I /do/ remember wondering at the time how they avoided it.

Remember the "correctors"? A perspex block with eight holes, plus a rod inserted through the holes and paper to punch an extra hole in the paper.

All holes punched was interpreted as "ignore this mistake" in the characterset. Or was that just with 5 channel papertape?

Reply to
Tom Gardner

In the Facit 5000 / 1000 characters/s reader there was a feed reel with a buffer bar keeping a loop in the tape. The buffer bar operated the feed reel brake when the loop got too large.

IIRC, the still faster (2000 cps) Danish Regnecentralen reader used buffer loops and reel servos like open-reel mag tapes.

--

Tauno Voipio 

>> The nice thing about paper tape that you don't necessary need a reader 
>> to find out what is on the tape. I once was quite fluent with the 
>> ASCII character table, so reading the paper tape visually was not that 
>> hard, although slower than the TTY. 
> 
> Remember the "correctors"? A perspex block with eight holes, plus 
> a rod inserted through the holes and paper to punch an extra hole 
> in the paper. 
> 
> All holes punched was interpreted as "ignore this mistake" in 
> the characterset. Or was that just with 5 channel papertape? 
> 
>
Reply to
Tauno Voipio

On our DDP-516 system the paper tape was mainly used for the OS loading and a parity error would cause an immediate stop of the tape, causing a lot of hassle. To recover, just try to reload tape.

In systems that actually used paper tapes for data entry, there would have been frequent need to stop the tape at a specific location., so handling of the feed reel might have been quite important.

It was definitively available on 8 channel paper tapes, since the RSX-11 terminal driver contained a mode to ignore the 377 (octal) punches.

Reply to
upsidedown

Having worked at DEC facilities in UK, seeing 14inch platters that have had head crashes is quite spectacular considering how smooth they start. Remembers an RM03 multiple platter drive and main drive that estimated to stsrt head crash at 11pm, by 8:30am it was stopped as was continually trying to find good blocks to log errors. When taken apart instead of smooth flat brown surface it was pitted and shiny aluminimum.

Yes it was brown as in those days the magnetic coating was brown, unlike the shiny disks now adays.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate
Reply to
Paul

.....

Hmm remembers days of similar RP06 (with removable packs), one system operator move the same pack between 3 drives, before somebody stopped him from putting the mangled disk pack to crash another drive.

They were floor standing washing machines, 3 phase supply AFAICR.

Seen one be pushed too far on lorry tail lift and gravity unloaded them. Nice big crunch...

Remember recall on a tape drive (type that was top half of full 19in rack) because hinge pins were too short. Field Service open drive for maintenance and drive topples to ground. You do not try and catch something with that size of solid aluminium casting base, large motors and vacuum pumps on the back.

Mind you the Heathrow warehous had habit of not unloading the systems from planes correctly and end up with system on tarmac.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate
Reply to
Paul

These 14" disk packs (such as RP05/RP06) disk are really heavy, In practice you have to lift into the top of the "washing machine" single handed and screw it to the spindle. Our main operator, a tiny lady (must be 80+ today) had some real problem moving around with these heavy 14" disk packs, so by gentlemen's agreement all the disk changes were rescheduled to the evening shift.

One case in which I know the reason of the head crash:

A 14" pack was moved from a site in the opposite side of the town in winter times. The car did not warm much in that time and when the disk pack was moved into the computer room with high humidity, some water droplets were accumulated on the disk surfaces, and when inserted into the disk drive _screeek_ occurred :-(.

After that, the rule was to move the disk pack into the office environment of the target building, then wait a few hours, before moving the warmed up disk pack into the 50 % RH of the computer room.

Reply to
upsidedown

Not just. That's an ASCII DEL character.

Mel.

Reply to
Mel Wilson

DEL is 0x7f. Was the 8th bit set due to parity ?

(I also thought it was a special "rubout" character in which _all_ bits were punched regardless of the number of columns in use on the tape or the code set in use.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

8 track tape often used even parity in text, so DEL and rubout were the same.

On 5 channel tape all holes was letter shift, where extra ones were ignored, so it could be used as rubout.

--

-Tauno Voipio
Reply to
Tauno Voipio

There were, of course, multiple incompatible 5 channel encodings. My first machine code program, in which I unknowingly reinvented the concept of a simple FSM, converted between two of them (the teleprinter we had at school and the Elliott teleprinter/computer we used at the local Tech College)

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.