> From: Charles Anthony
> the missing piece of the rounding algorithim has been identified:
> Only round if the mantissa was shifted more then 71 bits.
Wow. I'm really impressed that they implemented that in hardware, back then!
Then again, they threw so many gates at the Multics CPU, I guess they figured
a few more wouldn't matter... ;-)
Noel
The Multics distribution includes ISOLTS, a surprisingly complete and
pedantic processor test program.
It is unhappy with our emulated floating point.
This should be the floating point used by the GE 6xx series and the
Honeywell DPS8 and 6000 series.
There is one particular failure that I am driven to seeking help for.
If the intricacies of mainframe floating point math h/w do not interest
you, time to delete this message and move on.
For add and subtract operations, the operand with the smaller has its
mantissa shifted right and the exponent incremented adjusted until the
exponents match.
>From the DPS8M assembly language manual:
"The mantissas are aligned by shifting the mantissa of the operand
having the algebraically smaller exponent to the right the number of
places equal to the absolute value of the difference in the two
exponents. Bits shifted beyond the bit position equivalent to AQ71 are
lost."
Sadly, ISOLTS complains about our implementation. It does helpfully provide
what it says are the correct answers. Examination of the answers reveals
the it is not the case that the shifted bits are lost; the shift mantissas
are rounded according to rules that I can't quite characterize.
ISOLTS runs many operands through the UFA (Unnormalized Floating Add)
instruction; the current state of my rounding algorithm passes the first 46
tests; fails on the 47th. Everytime I try a different approach, it fails on
an earlier test.
The best rule that I have is: if the shifted mantissa is all ones and at
least one of the bits shifted out was a one, the set the mantissa to 0.
Test #47 adds:
700000000000700000000000 E 31. to
202025452400000000000000 E 102.
ISOLTS expects
202025452377 777777777777 E 102.
and it gets:
202025452400000000000000 E 102.
The emulator should not have rounded in this case; but I cannot figure out
the rule.
I've abstracted the instruction out of the emulator and embedded it in a
standalone test harness that runs the 47 tests.
https://sourceforge.net/projects/dps8m/files/drop/Charles/ufa47.c
Any insights, suggestions for algorithms, reading material would be greatly
appreciated.
-- Charles
Thanks!
I've to dig it, since my RSX experience amounts to two hours.
The IND should have worked before, since there are a lot of user generated .CMD files.
We are now working on the RK8F controller and RK05 drive. The RK8F has
special M7104 and M7105 boards so it will work in the DW8E Omnibus-Posibus
chassis.
The MAINDEC-08-DHRKA RK8E Diskless Control Test showed that a data-break to
address 0000 worked, but did not work to address 7777. After about 4 hours
of debugging we found a dirty connection on an M7102 board in the DW8E
chassis. This prevented one of the CA signals from the RK8F from being
driven onto the Posibus MA.
The DHRKA diag now passes, so much of the RK8K and the DW8E are working.
We bought a new NiCd battery pack for the RK05 and new weather strip to
replace the blower to card cage, and plenum to disk pack seals. There is
also a power supply problem that shows up after the RK05 had been powered
on for 10 minutes that we need to fix.
We have a disk pack that came with the PDP-12, but we don't know if it has
LAPS-DIAL or OS/12 installed. Maybe we will solve that mystery in a few
weeks.
--
Michael Thompson
Lyle would love a scan of it!
Ed# _www.smecc.org_ (http://www.smecc.org)
In a message dated 3/26/2016 9:59:18 A.M. US Mountain Standard Time,
lbickley at bickleywest.com writes:
On Sat, 26 Mar 2016 12:50:02 -0400 (EDT)
jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
> Hey, all you PDP-8 people: there's a PDP-8/E-F-M OEM price list going
> on eBay, not very much:
>
> http://www.ebay.com/itm/272187153709
>
> I saw it go past once before, figured someone would notice and grab
> it, but I guess not...
>
> Noel
Thanks, I bought it :)
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
> Does anyone know of _any_ information about this series of cards?
> ... search as I can, I don't seem
OK, it turns out I needed to be looking for "BM873"; under that, it appears to
be fairly well documented (prints, TM, etc).
> Known variants are the -YA, -YB and -YJ.
Most of the later variants are for use on the 11/40 which is the front end of
a KL10; there's a PDP-10 document online (KL873.MEM) which lists them all in
some detail.
Does anyone have a -YB we can dump? (I have a -YA, and will dump that in a few
moments, here.)
Noel
Does anyone know of _any_ information about this series of cards? They are
quad cards which seem to use two chips of the same types as the M9301 uses
four, with 128 words of memory. They thus must fit between the M792 diode ROM
card, and the M9301, in timing terms. However, search as I can, I don't seem
to be able to find anything on them. Known variants are the -YA, -YB and -YJ.
Noel
Hi Guys
Does anybody have an 8/i or 8/L?. I need a close up pic
of the logo area to the top left of the panel.
In particular the address text under the logo.
The font looks like a made up one and I need to create it.
Thanks
Rod (Panelman) Smallwood
Hey, all you PDP-8 people: there's a PDP-8/E-F-M OEM price list going on eBay,
not very much:
http://www.ebay.com/itm/272187153709
I saw it go past once before, figured someone would notice and grab it, but I
guess not...
Noel