> Regarding Als idea of reading the disk backward - It would be a fairly
> simply matter to make up a version of ImageDisk which reads from the
> inside out.
> Why would reading from inside to outside (track 80 to track 0) help?
I have observed there is a higher rate of failure reading inside tracks.
If there is binder shed, it may help to start on the tracks that are more
difficult to read first (before the head starts to clog).
The bit about non-sequential track reading comes
mostly from trying to recover partially crashed 2315 media. You don't want
the ceramic of the flying head within 1/2" of the bad spot for very
long, or it will clog up and crash.
By moving the head on the floppy you knock the accumulating crud across
the surface of the disc as you seek, rather than having it pile up on the
leading edge of the head. Not great, but carving grooves in the floppy is
worse.
Sridhar Ayengar asks:
Well, I've seen how much dust a car air filter lets through, and I won't
use one on my car anymore. 8-/
Do the heads on older drives hover closer or farther from the data
surface than on newer drives?
Peace... Sridhar
Billy wrote:
All of the early cartridge drives used HEPA filters with no problems.
Provided you changed them when required by maintenance schedules.
Current drives still use a paper type filter but it is inside the drive and
not replaceable. Some of the higher speed drives (10-14K RPM) may have two
internal filters and a third over the pressure equalization hole.
Older drive heads of the ST412 era were in the 40-70 micro inch range. New
drives with Dynamic Flying Height ability are in the 1-3 micro inch range.
They also deliberately touch the media during the initial calibration
cycles. This is usually only once per head during the life of the drive.
There is no harm from this touch.
Billy
> I worked extensively in Dap16 in the 70's and still
> have a working H316 at home plus plenty of spares.
What software do you have for it? There are a few people
that have been looking for the disc operating system for
a while now
Jules Richardson wrote:
> I think I'd mentioned this privately to Chuck the other week, but I'm not sure
> if "playing back" raw data to a drive will even work, given that there will be
> slight differences in drive RPM between drives: a track buffered on a "slow"
> drive would run past the end of track on a "fast" drive by a few bits.
Besides that, there's the fact that the copy would have twice as much
peak shift and jitter as the original, and be unreadable or barely readable.
> It
> makes me wonder if the only way to do a 100% reliable write is to interpret
> the data that you're writing, lay down a format (which is guaranteed not to
> overflow available space), then lay down the actual data.
Right. And you also need to verify the CRCs, and reread any sectors that
failed, in case of dropout.
-- Adam
Hi guys,
I've just dug my not-even-a-tenth-finished floppy disc raw-reader out of
the cupboard, the plan being to finish it off. Problem is, I'm not seeing any
signals coming out of the floppy drive - all the outputs are stuck high.
What I've got is:
- All odd numbered pins on the IDC34 tied to ground
- All I/O lines from the floppy raised to +5V via two 4k7 resistor packs
- /MOTORA and /DS0 wired together, and grounded via a switch
- A Sony MPF520E floppy drive, HP badged, jumpered for automatic density
selection and DS0 (drive 0)
I can step the head in and out fine, and the motor seems to be spinning (the
drive's activity light is on at least). What I can't get is any form of output
>from the drive - even /INDEX is stuck floating high (FWICT it should pulse
once for every revolution of the disc, i.e. about once per half-second or so).
Am I violating some timing parameter or basic rule here? I honestly can't see
any reason why the drive would seek fine, but not return any data or index pulses.
Thanks.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.
> I am in the process of reading a couple of papers[1] on the effects of
> humidity on magnetic recording tape
There is a patent Ampex got on tape baking. Don't have my copy handy.
Dig around in the classiccmp archives, this has been discussed about
a year ago. The failure mode is reversable by removing the H2O in the
binder with heat/humidity reduction. For tape, I have been using a
heated dehydration chamber (modified 'dry box') 50degr C, <10% humidity
for about 24 hours.
The trick with tape is to have a LOT of air moving to get into the reels.
On 1/2" tape this is normally enough to prevent enough binder shed from
clogging the heads for a single pass over the tape w/o retries. You DO NOT
want the tape to stop! If it does, the built up binder will deposit itself
on the surface of the tape in a vertical stripe. If you are lucky and that
happens, it will occur in an inter-block gap, if not, you've just created
a permanent failure (you can't clean it from the surface of the tape).
There are some other tricks, like using magnetorestrictive transducers and
low tape pressures, but that requires extensive modifications to the tape
transport.
I just received a question from a fellow interested in the pricing of core memory:
"How much did this memory cost per bit, byte, or word? I am doing a
historical storyboard on the HP2100A used as the data processing system for
the HP5930A mass spectrometer and I would like to get some hard data on costs
of core memory."
Would someone (likely candidates: Jay, Bob :) ) have period price info for a
core memory module for the HP2100A?
I will pass on responses as well as suggest that he may wish to temporarily
join the list to ask other questions about the HP2100A.
I will also pass on the email addresses of responders (please indicate if you
don't wish me to do so) should he prefer to address questions directly to those
more knowledgeable about the HP2100 than I.
Hey All,
On 10/04/07, Philip Pemberton <classiccmp at philpem.me.uk> wrote:
> Al Kossow wrote:
> > The failure mode I've seen is oxide/binder coming off, clogging the head
> > and
> > carving little concentric rings in the media :-(
>
> If it's a case of the binder absorbing moisture and losing grip, it might be
> an idea to try baking the discs for a bit to dry out the binder. The only
> problem is, if you get the disc too hot (the words 'Curie temperature' spring
> to mind) then the data's toast...
I am in the process of reading a couple of papers[1] on the effects of
humidity on magnetic recording tape - primarily tape that has a
ployester urethane binder. Turns out that the problem is the binder
undergoing hydrolysis. The process is reversable but seems to take a
while - several weeks at least in low humidity conditions.
[...]
[1]
Kinetics of the humid aging of magnetic recording tape
Bertram, H.; Cuddihy, E.
Magnetics, IEEE Transactions on
Volume 18, Issue 5, Date: Sep 1982, Pages: 993 - 999
Aging of magnetic recording tape
Cuddihy, E.
Magnetics, IEEE Transactions on
Volume 16, Issue 4, Date: Jul 1980, Pages: 558 - 568
Simon
--
------------------------------------------------------------------------
"Well, an engineer is not concerned with the truth; that is left to
philosophers and theologians: the prime concern of an engineer is
the utility of the final product."
Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
Ok, here's a nice one...
I've got a SCSI drive that was working fine in a test system the other day. I
came to plug it in to a system today via a known-working external SCSI box,
and when I hit the power the drive didn't spin up and sat there with the LED
constantly on.
"Uh oh" I thought. So I turned off the power, unplugged the drive cable, and
turned power on again - the drive span up fine.
That's a bit worrying, I figure, so I plug the drive cable back in, but unplug
it at the system end: I figure some fault with the system's SCSI bus is
upsetting the drive. Turn on the power to the cabinet and... constant LED, no
drive fault.
Must be the cabinet's terminator, right? Wrong - with the power applied and
the cable plugged in, but no terminator, I still get the constant LED and no
spin-up. With just power applied and no terminator or cable, the drive spins
up fine.
So... that's just a cable fault left - must be a short between a couple of
pins (however unlikely this seems). Wrong again - try a different known-good
cable, and the behaviour's the same: no spin up with a cable plugged in.
After a bit of experimenting, the drive will spin up fine with either no cable
or a cable of a few inches plugged into it. With a cable of a foot (or more),
it refuses to spin up and just sits there with the LED on permanently.
Remember there's nothing funky at the other end of these cables - they're just
stock 50-way IDC cable with 50-pin IDC connectors at either end.
The fault is consistently reproducible - drive orientation makes no
difference, power to the drive is good, cable-waggling has no effect. If I
turn on power with a cable plugged in, *then* unplug it, the drive will
suddenly spin up.
So... huh!? It's as though something's gone bad on the drive and it's using
the SCSI cable like and antenna and picking up interference which is confusing
the heck out of it. But then why it does the same when it *does* have
something at the other end of the cable, I don't know.
David, I couldn't reply to you. Your mail server for some reason don't
want anything to do with me, so I'm posting this here instead.
===============
Yes, I've seen the discussion.
My view is basically that it's not impossible at all. Just a question of
actually write the thing. Memory wise it will be just fine.
Large V5 games will probably require too much memory, but I think almost
all Infocom games will be fine. They have much more modest requirements.
Inform games both require lots of memory, and are extremely inefficient,
on a level that makes you not want to play them because of speed issues
anyway.
As someone noted in cctalk, a few issues to deal with is about the fact
that the z-machine is oriented towards 8-bit based architectures, so you
will get some extra work, and inefficiencies because of that. Not much
to do about it, except to live with it. It's nothing strange, just extra
code.
Any z-machine on a small computer needs to implement a virtual memory
scheme. I did that for ZEMU, and the same goes for one on the PDP-8. But
that's easy. You just have a paging scheme with an LRU algorithm. The
easiest there is. I stole the design from Frotz, I think, and then
improved some on it, and adopted it to my needs.
Also, I used Frotz as a debugging tool when I wrote Zemu. It helps to
have a working Z-machine around, which you can tinker with and add
printouts to, to compare with what is happening in your implementation.
Well, like I said. I don't see any real problems, except it will take
some work. ZEMU took me probably a couple of months atleast, in the end.
And then Megan did the work to port it to RT-11.
For the PDP-8 I would think that you'd want atleast 16K, by the way. I
think that the z-machine will need around 8K, and then you need atleast
4K for the dynamic memory, which would leave 4K for the game code. More
is always better, though. Larger games will need more dynamic memory,
but one 4K field for the game code is plenty enough. In ZEMU I think I
normally only use 10 pages of 512 bytes each for game code, but I can
play any game with just one page, and it gets slower, but not unbearably so.
The things that are tricky is really timers and screen handling. A lot
of code in ZEMU is to deal with this stuff. But you really don't need to
bother with either. Especially not if you're focused on V3 games.
Another big item in ZEMU is to deal with all different versions of the
z-machine. By focusing on just V3, that would become much simpler.
Actually, I think it's both realistic, and probably wise to focus on
just V3. It will be much less code if you ignore other versions, most
Infocom games will run just fine, and you can skip timers, and have a
simple screen handling. Memory requirements will not be bad.
I mean, basically, the z-machine consists of executing instructions,
which aren't that difficult. And then you need the memory handler and
the screen handler. A few instructions are very complicated, but that's
just a very few, like the parse instruction which converts an input line
into tokens.
And then you need to deal with the 8 vs 12 bit issues, and decide on how
to layout the virtual memory in the physical.
Johnny
David Griffith skrev:
> On the cctalk list, there's a thread on how to get a Z-Machine running on
> a pdp8. Since you did this on a pdp11, I thought you might have some
> insight on this tricky goal.
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
