test-drb April 2007

test-drb@ccmp.vtda.org

257 participants
560 discussions

by aek＠bitsavers.org

> 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.

17 years, 9 months

How to Build a Clean Box

by Billy.Pettit＠wdc.com

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

17 years, 9 months

any Honeywell H316 experts out there?

by aek＠bitsavers.org

> 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

17 years, 9 months

Open-source floppy reader: the data separator/sync-er works!

by adamg＠pobox.com

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

17 years, 9 months

Floppy drive interfacing

by classiccmp＠philpem.me.uk

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.

17 years, 9 months

Humidity and Magnetic Media Was: Re: floppy media failure

by aek＠bitsavers.org

> 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.

17 years, 9 months

HP2100A core memory (period) prices

by hilpert＠cs.ubc.ca

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.

17 years, 9 months

Humidity and Magnetic Media Was: Re: floppy media failure

by fryers＠gmail.com

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

17 years, 9 months

The voodoo of SCSI...

by julesrichardsonuk＠yahoo.co.uk

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.

17 years, 9 months

ZEMU and the pdp8

by bqt＠softjar.se

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

17 years, 9 months

← Newer
1
...
41
42
43
44
45
46
47
...
56
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb April 2007