At 09:08 PM 05-01-99 -0800, Sam Ismail wrote:
>That's interesting. I must've missed the news about the 51st and 52nd
>states being added to the Union :)
A common mistake made by a number of us non-US assimilated citizens :-)
Confusion with the number of weeks in the year me thinks....
Huw Davies | e-mail: Huw.Davies(a)latrobe.edu.au
Information Technology Services | Phone: +61 3 9479 1550 Fax: +61 3 9479 1999
La Trobe University | "If God had wanted soccer played in the
Melbourne Australia 3083 | air, the sky would be painted green"
>I couldn't find a picture of it on Megan's web page, but I'm fairly sure
>that this was the hand-held "terminal" provided by Digital to FS
>personnel to allow them to use the diagnostic serial port on RA disks. I
>remember our FS guy having one, we used it for about 10 minutes before I
>connected our GIGI up - so much easier to use...
There's no picture yet because there aren't any pictures yet for
anything... I've taken some (including the IXO terminal) but have
not yet 1) developed them, 2) scanned them in, and 3) included the
image code in the document. Maybe I should put this as one of my
listed projects...
I've been busy making room for my newest haul... the pdp-8s.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
> Any addresses to get more info?
All I saw was a post Slashdot.org, which had a link to a C|Net article
saying basically that Hayes is liquidating its assets and closed yesterday.
There is also a little stock ticker that says: "Hayes: N/A" :)
I'm heavily involved with Y2K issues, and there are going to be plenty of real problems, and not all of them will be on January 1.
There was a story in todays Wall St. Journal about an aluminum smelter that shut down because it couldn't handle the leap year in 1996 ! It did half a million dollars worth of damage.
We have discovered access control systems (doors with electronic locks and swipe cards or keypads to gain entry) that have y2K problems -- they know the date, because they know which shifts and days of the week people work, and only allow access while a person is actually "on duty". When they get confused or detect any problem, they go to an "all-open" state, to prevent the possibility of locking someone up in a fire situation. Which is fine, but some of these systems are installed in hospitals (including mental hospitals) and prisons.
We thought our printers didn't care about dates, but low and behold, we found a bank passbook printer that DID care about dates, and it malfunctioned when fed a y2k date. Admittedly only a cosmetic problem, but a problem none the less.
The FDA has found seven medical devices that have malfunctioned in 1999 (already). Seems that "99" in the year field had a special meaning (we've found this in a LOT of systems). At first these looked like cosmetic problems only, the date is not functionally used, but is printed on a printer. Until it became clear that such printouts could cause a physician to conclude that a patient's blood pressure was going up instead of down. Or that his EKG was getting better instead of worse.
According to a recent SEC filing by AT&T, the company acknowledges that they cannot guarantee that they will complete their y2k work in time, and they will not guarantee that some of the possibly unfixed issues will not cause service interruptions, possibly extended.
The truth is, I can't tell you if any of the "nightmare" scenarios will happen or not, and y2k might indeed seem to have been hype if none of them do. Further, anyone who makes a prediction is doing nothing but guessing. But be aware that over half a TRILLION dollars will have been spent on this, so I can assure you that whatever happens on 1/1/99 (or later, in particular at the end of February of 1999), IT WAS NOT HYPE.
Barry Watzman
PS - and while we are spending the money to at least attempt to address it, bear in mind that Europe is WAY behind, and Asia Pacific has been too busy trying to survive to have even looked ahead to recognize that the end of the century is coming.
turns out the reason for the post error on my 5155 was because the head was
sticking and couldnt do the initial seek, thus causing the 601 post. tony was
right! i didnt bother with greasing it and swapped out an identical floppy
drive from an extra pcjr. anyone want a pcjr unit for the price of shipping?
david
The 11 year cycle is the sunspot cycle, any ham radio guy knows of it.
communications on the various bands are affected.
and, i have read that is is possible for "cosmic rays" to affect electronics.
apparently, its one of those 1 in a billion billion type of things. i was
doing
some research on memory and came across it. again, just not very likely.
kelly
In a message dated 1/5/99 3:15:27 PM Pacific Standard Time,
ard(a)p850ug1.demon.co.uk writes:
> I have heard them all! This is going to have even less of an effect that
> any software problems!
>
> >
> > >>>
> > Every 11 years the sun sends storms of cosmic rays which disrupt all
sorts
>
> Cosmic rays are coming all the time.
>
> > of electrical devices. The last was in 1989, and they are due again in
> > 2000. 1978 was also a year effected by mega cosmic rays and was
> > coincidentally the first year of Expansion Interface manufacture. Could
> > the rays have been the source of the EIs poor performance? I have a 1978
> EI
>
> Even if cosmic rays did have a major effect on computers (and AFAIK they
> don't) then the date of manufacture wouldn't make any difference. What
> would matter is the cosmic ray flux _now_.
>
>And PLEASE turn off the Microtrash HTML nonsense, it's rude to send HTML
>to a mailing list. Rememeber there are a lot of people that don't read
>your messages because they are being sent in HTML. A lot/most people,
>especially on this mailing list, are using software that doesn't cope
>with HTML.
Hear-Hear...
Keep in mind that this is 'classiccmp' -- we're probably also using
classic software... (and that includes unix, due to its age)
:-)
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
<<Brainstorming mode on:>
<Is IDE geared in any way to the MS-DOS filesystem?
No. It's a device level interconnect similar to SCSI or other busses.
In practice it's a 16bit data bus, several control lines and a few address
bits. It was a result of putting the early PCbus MFM(or rll) card in the
MFM hard disk to make it a single unit. The WD1003 MFM ISA16 (PC) bus
card is a very similar interface when viewed from the ISA16(PC AT and
later 386/486 sytems) bus. What IDE did was allowed the PC to offload one
board (Disk controller) onto the disk drive (IDE= Integral drive
electronics) and created a simple disk interface connector/cable that
was cheaper than SCSI but offered many similar features of SCSI interfaced
disks sans the greater cost.
The drive and it's IDE interface is a series of registers for parameters
and data transfer and it cares less what operating system is in effect.
About the only difficulty is interfacing the 16bit wide(for data, 8bit for
commands) bus to whatever the local CPU/BUS is in use. that logic is nearly
the reverse of the 99/4a 16bit->8bit for the PEB. One could do a kluge
and not use the high order bits as they are data only. However that means
the default 512byte sector size would only hold 256bytes of data (with large
drives dirt cheap this is not so bad!). I personally don't like that but
it'd work.
The interface is basically a series of registers that set up the transfer
with data like command, head, sector, cylinder and number of sectors
(transfer length). The interface does not have to keep up with the
physical media as even the smallest ones have a 32k (up to 512k) cache
ram on board so that if can feed data fast (or slow) as the host desires
it. Most of the 60-100meg and later drives (quantum is known for it)
have a LRU cache so that the drive can try to anticipate the next likely
sector to transfer to avoid rotational latentcy. While the drives are
hyped and speced for fast transfer rateds to their host system there is
no requirement to use that speed as there is no lower limit. Because of
the cache a polled interface is easy to do and there are no requirements
for critical fast loops to avoid loosing data.
I happen to use IDE with FreeBSD(on PC hardware) and also a Z80 CP/m system.
Both are about as unDOS as they can get.
DSR level issues are things like are there logical limits to how big a
TI99/4a file system can be. Also how does one write a DSR that uses any
one of several hundred differnt IDE drives of differnt sizes and
configurations? IE: 20mb as 4 heads 615 cylinders of 17 sectors or 306
cylinders and 8 heads? PCs (CP/M and others) have the idea of a bios that
translates differnt physical devices to look like one logical interface.
Sadly most DSRs were not written that way. Having a differnt DSR for a WD
240mb and a shugart 340mb would be a real problem. Also the older drives
are dumber and cannot tell the system what they are (configuration), the
later (mostly over 200mb) drives added that functionality. So there would
also have to be configuration tools and some amount of NVram(EEPROM) on the
board to allow for whatever drive was available from the older 40mb up to
the current 19gb drives. I'd point out that the drives in the 80-400mb
range seem to be more inconsistant than the larger ones. Also drives over
512mb have additional fuctionality so that they can be addressed as block
instead of cylinder, head, sector. So the driver (DSR)
has to be a bit smart so that it know what class of IDE drive and what
capabilities are available. That's a real tall order! So that is why I
say the physical interface is trivial compared to the DSR. It can be done
as many of the same problem occur with SCSI but the DSR will have a lot of
differences at the lower levels of code. Judging from the SCSI dificulties
reported here that wasn't easy either.
Allison
<The story on cosmic rays affecting memory is well-known. It was proposed
<as the reason why one of the early 4Kbit (I think) chips had a very high
<error rate. It was later found (I think) that the real reason was alpha
<particles from the radioactive decay of something in the (ceramic?)
<package of the chip.
it originated with the transiston from 16k Drams to 64kdrams as the feature
size was small enough that an Alpha particle hitting a sense line or other
die level feature could offset the charge on the capacitor(storage element).
Also different refresh schemes, better logic, faster parts
and fewer interconnects all contributed to this soft error rate going
down rather than up. The source of the particale was the gold eutectic
bond used to hold the die to the lead frame or the lide for the brazed
lid cases. The solution was a overcoat of particle absorbing material on
the die. Since there there has been a many fold(or greater) geometry
shrink to get the current megabyte parts and we do not have the forcasted
problem, though the potential exists. It's not to say the problem wasn't
real but win95 crashes(on its own) more often than the probability
of a actual soft error in practice.
Allison
