On Sat, 2019-01-05 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
> Re: Microcode, which is a no-go for modern designs
I was a tech in the 90's when the original Pentium FDIV bug was
storming. The issue was confined to the integrated floating point
portion of the processor and was therefore rarely an issue as the vast
majority of software did not use the mathco portion of the chip. Only
a handful of applications and relative handful of users were affected.
This became Intel's position on the matter and they hoped the issue
would just die down to those handful whom they would provide new chips.
The issue did not die down and the bad press forced the decision to
replace ALL pentiums affected. Only a relative few were actually
replaced in the home and small business arena. A software patch was a
common solution to the problem. It masssaged input to the FDIV
instruction to produce a corrected result and worked pretty well as I
recall.
At the time of the storm, the Pentium was still pretty new and very
expensive. Most folks were getting along with AMD k5 and k6
processors. I WAS. I went from k6 to Celeron.
Best
Jeff
Thanks for all the replies! Based on the responses I got, this is the
specific request list that I just emailed him:
anything HP 1000 related is interesting. HP 2100, HP 21MX 2113 2117,
A-Series A400 A600 A700 A900 A990, etc.
are all 21MX/2100-series:
HP 12908A Writable Control Store Interface Kit (PCA 12908-60002) HP 12908B
Writable Control Store Interface Kit (PCA 12908-60006) HP 12908-60003 Jumper
Board Assembly HP 12908-60005 Backplane Jumper Assembly HP 12908-60008
Jumper Board Assembly
HP 12978A Writable Control Store (PCA 12978-60006) HP 12978-60006 Jumper
Cable Assembly
HP 02100-60018 Cable Assembly (need two!) HP 02100-60052 Connector Assembly
an HP HIL mouse (so not PS/2), preferably 3-button
HP apollo 735/125 power supply part # 0950-2081 (Astec). It comes from a
workstation, A2608A or A2841A
HP 9000, whether it's the /200, /300, /400, /700, or /800 series
The prices I see for this equipment online are stiff! May I assume (and yes,
I know what that spells) that you guys are looking for machines in the sub
$200 class, not $2000 like some sites have posted? Equipment from the
recycler is so much cheaper, but strictly as-is.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
On Wed, 9 Jan 2019 cctalk-request at classiccmp.org wrote:
> Message: 7
> Date: Tue, 08 Jan 2019 20:03:24 +0000 (WET)
> From: Peter Coghlan <cctalk at beyondthepale.ie>
> Subject: Bogus "account hacked" message
>
> About two hours ago, I received an email to the address I only use for
> cctech/cctalk.
>
> It claimed my email account had been hacked and threatened all sorts of
> dire consequences if I didn't deposit $1000 in bitcoins in some place within
> 48 hours.
[chop]
I enjoyed reading the discussion regarding these bogus emails.
I get a one or two per week. Some with no password, and some with a
password only used for one particular site with an email address only
created for that site. (and the site is no longer around more than
likely due to being hacked ... essentially the account I had there was a
throwaway).
Some of the phishers are getting "smarter" and dropping the "-suffix" I
used for the email (which also ends up getting to me ...)
Obviously the system(s) they send it to don't have a camera, don't have
any web browsing software installed, are text based (Linux and OpenVMS)
and I just laugh.
However, I do enjoy totally confusing the scammers. I have the extra
password configured for the SYSTEM account on my main VMS box. The script
kiddies have no idea what to do with a second password prompt (since you
don't get a User Authorization Failure until you enter both passwords,
good, bad, or indifferent).
34630 failures since last successful login
No intrusion records either, as they try once and move on. Long
passwords are looooong so I challenge them to guess. If they get in,
login DCL does checks and if you don't have the secret sauce ... *plonk*
I probably don't have to have extra password set, but I'm paranoid and do
it anyway.
I've also noticed folks at $work are starting to get these "give me
bitcoins because I saw your pr0n" messages as well. Those were some fun
discussions.
Fred
Apropos of nothing, I've been confuse for some time regarding maximum
clock rates for local bus.
My admittedly old information, which comes from the 3rd ed. of "High
Performance Computer Architecture", a course I audited, indicates a
maximum speed on the order of 1ghz for very very short trace lengths.
Late model computers boast multi-hundred to multi gigahertz fsb's. Am
I wrong in thinking this is an aggregate of several serial lines
running at 1 to 200mhz? No straight answer has presented on searches
online.
So here's the question. Is maximum fsb on standard, non-optical bus
still limited to a maximum of a couple of hundred megahertz, or did
something happen in the last decade or two that changed things
dramatically? I understand, at least think I do, that these
ridiculously high frequency claims would not survive capacitance issues
and RFI issues. When my brother claimed a 3.2ghz bus speed for his
machine I just told him that was wrong, impossible for practical
purposes, that it had to be an aggregate figure, a 'Pentium rating'
sort of number rather than the actual clock speed. I envision
switching bus tech akin to present networking, paralleled to sidestep
the limit while keeping pin and trace counts low.....? Something like
the PCIe 'lane' scheme in present use? This is surmise based on my own
experience.
When I was current, the way out of this limitation was fiber-optics for
the bus. This was used in supercomputing and allowed interconnects of
longer length at ridiculous speeds.
Thanks for allowing me to entertain this question. Though it is not
specifically a classic computer question, it does relate to development
and history.
Best,
Technoid Mutant (Jeff Worley)
> From: Bill Degnan
> I attempted to port the same version of unix to an rl02 disk pack and
> to run on an actual 11/40. I was able to get ir to boot up to the #
> prompt but my system does not have a working EIS card to proceed any
> further.
I"m incredibly surprised that you got to the prompt! First, the V6 RL
bootstrap uses ASH, part of EIS. And then the C compiler makes extensive use
of EIS instructions, so anything in C (the OS, 'init', 'sh', etc) may have EIS
instructions in it.
Noel
Guys,
Do any of you know where I could get hold of DG document(s) describing the
microcode of their Eclipse family. It was wide yellow manual with brown
plastic ring binding. It brings back happy but foggy memories.
"The Soul of the New Machine"(book) tells me that the instruction set was
built from the microcode by some genius overnight. Probably an urban myth!
Who knows.
Many thanks,
peter
> Few people (but most are right here) can recite PI to enough digits to
> reach the level of inaccuracy. And those who believe that PI is exactly
> 22/7 are unaffected by FDIV. (YES, some schools do still teach that!)
Why remember the digits, when a small program can provide them?
+0un qn"E20Un' 0Uh 0uv HK
Qn<j 0uq Qn*10/3Ui
Qi<\+2*10+(Qq*qi)Ua 0LK Qi*2-1Uj Qa/QjUq Qa-(Qq*Qj)-2\10I$ Qi-1ui>
Qq/10Ut Qh+Qt+48Uw Qw-58"E48Uw %v' Qv"N:Qv,1^T' QwUv Qq-(Qt*10)Uh>
:Qv,1^T
!Can you figure out what this macro does before running it? It was
written by Stan Rabinowitz with modifications by Mark Bramhall and
appeared as the Macro of the Month in the Nov. 1977 issue of the TECO
SIG newsletter, the "Moby Munger". For information on the TECO Special
Interest Group, write to Stan at P.O. Box 76, Maynard, Mass. 01754!
--Johnny
> I don't recall off the top of my head whether the location of that
> shared block of memory is in the per-process swappable kernel data
> (which is included in the process core dump).
So I checked, and the swappable per-process kernel data does in fact include
pre-computed contents for all the memory management registers, so we'll be
able to see (from the process core dump) where the code and data segments
were.
On another front, that error message ("Memory error") is produced when a
process gets a 'memory management trap' (trap to 0250). This could be caused
by any number of things (it's a pity we don't know the contents of SR0 when
the trap happened, that would tell us exactly what the cause was).
With working hardware+OS, it's usually the result of a bad pointer in the
program. In a tested program like 'ls', I don't think that's the case. It's
most likely caused by faulty memory, but it's also faintly possible that the
MMU has an issue.
I'll look at the process dump a little later today, and see if I see anything
of significance.
Noel
About two hours ago, I received an email to the address I only use for
cctech/cctalk.
It claimed my email account had been hacked and threatened all sorts of
dire consequences if I didn't deposit $1000 in bitcoins in some place within
48 hours.
I am 100% certain that the claims in the message are completely bogus and
none of the threats will be carried out.
It is likely that email addresses belonging to other list members are also
to be found wherever my email address was scraped from so I just wanted to
warn other list members about this scam in case they receive similar emails.
(I received the scam email directly, not via the cctech listserver).
Regards,
Peter Coghlan.
