Message-ID:	<004f01c0437d$1eed1200$11fea8c0@dell>
From:	"Ben A L Jemmett" <ben DOT jemmett AT ukonline DOT co DOT uk>
To:	<opendos AT delorie DOT com>
References:	<200010290356 DOT XAA22793 AT xellos DOT bignet DOT net> <39FBBB35 DOT C76A6C52 AT internet1 DOT net> <00be01c04204$c99dd380$6f1e0404 AT dbcooper> <010201c0425f$93b03960$11fea8c0 AT dell> <00c701c0436f$afef99c0$8b8a1004 AT dbcooper>
Subject:	Re:
Date:	Tue, 31 Oct 2000 20:57:01 -0000
Organization:	Jemmett Glover Software Development
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To:	opendos AT delorie DOT com

> I have an old 345MB Maxtor drive and they run fine. Although at the time I
> bought the drive, it was not advertised, but it does have LBA mode 1 or 2,
I
> forget which it has. ...
Hmm...  OK, just a thought.  My old drive knew sweet FA about anything
except plain old IDE - no block transfer modes, didn't need LBA (240Mb), no
Current Parameters support.  Probably nothing to do with it though.  BTW, I
don't think LBA has anything to do with transfer speed, just addressing.

> It may be a BIOS thing then, because both of these systems have 5x86-133
> which are basically 486 chips which are improved.
Since they're clean-room, if they've got the same problems as the Intel
devices it's needed for compatibility and so software should be coded around
it.  But since when has this industry ever gone in for consistency?  :)

> But why
> certain DOOM WADs work and others do not is a mystery to me. Since they
all
> use the same engine and memory management. Go Figure.
It might be the size of the WAD pushing the malloc() calls into a different
area of memory.  It might also be the size of the individual LMP files
requiring more data transfer, pushing something just far enough to drop out.

> > Of course, the Pentia have their own set of bugs - three nasty ones,
IIRC.
> > The classic FDIV, F0 0F (always good for security batch files), and
> > something else to do with PCI and losing data in some circumstances.
>
> There are probably updated BIOS to fix those problems. Also there may be
> built in problems in the chipset.
Well, the FDIV and F0 0F are problems with the chip itself, and can't be
fixed with BIOS upgrades et al.  They need new silicon, although later Linux
kernels detect the presence of both bugs and report any - I'm not sure what
it does with the information though.  (I don't know why, but I tried out e
100 f0 0f, g 100 in DEBUG once and sure enough, the machine locked solid).
The PCI bug was a chipset problem (the Northbridge chip had an interrupt
problem IIRC), and Intel sorted it out PDQ - it came a month or so after the
first 486.999999999999999744 problem).

Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)

- Raw text -