There's a change to the keynote plans for VCF East.
Ted Nelson is unable to attend due to a family issue. He sends his
regrets, and said he'll try to make it up to us another time.
Wes Clark will take Ted's place on Saturday morning at the show.
We are looking for other speakers and/or entertainment for the Saturday
dinner (when Wes was scheduled to speak).
Details are frequently updated at http://www.vintage.org/2015/east.
- Evan
So here is the octal print routine in the M9312 console boot prom for the '34:
; print an octal number followed by one <SP>
;
; R0 = register value to print
; R1 = return address
; R2 = temp char
; R3 = temp addr
prtoct: mov #<'0/bit1>,r2 ; ascii 0 right 1b
sec ; shift a 1 into R0 lsb as done bit
1$: rol r0 ; msb out of R0
rolb r2 ; into lsb of R2
mov pc,r3 ; ret addr
br txchar ; print char in R2
mov #<BL*bit8>+200+<'0/bit3>,r2 ; ascii SP upper, ascii 0 right 3b lower
2$: asl r0 ; msb out of R0
beq 3$ ; when R0 has gone to zero we are done
rolb r2 ; into lsb of R2
bcs 2$ ; loop once more if flagbit was set
br 1$ ; go get last bit and print char
3$: swab r2 ; move the SP from upper byte to lower
mov pc,r3 ; ret addr
br txchar ; print the space char in R2
retR1: cmp (r1)+,(r1)+ ; bump return address ptr R1 by +4
jmp -2(r1) ; return to (R1)-2
So I would speculate either 'rol' or 'rolb' are always rotating in a 0 bit instead of the
c-bit, or possibly the c-bit is stuck at zero.
-----Original Message-----
>From: Jacob Ritorto <jacob.ritorto at gmail.com>
>Sent: Jan 29, 2015 7:08 PM
>To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>Subject: Re: strange number corruption on pdp11/34
>
>So, pardon the large post, but here's the real comparison between my
>'mysterious zero bug' KD11E-A cpu board M8266, and my good one: First is
>the bad. Note that even at power on, I have to halt and restart the
>console emulator at 165200. Look at the registers, all blanked to zeroes
>and missing digits, too. It did manage to boot xxdp, but when I tried to
>enter the correct address and vector to ZRLG??, it actually told me I was
>wrong and couldn't even run the test on the device that way. Then I just
>accepted the default (which was presented as zeroes) and it did run. Two
>passes. Blinking lights and audible head movement. I let it run for two
>passes, but it presented even that as zero passes and spit a bunch of
>zeroes in the results. Just for kicks, I then booted (and very promptly
>crashed) RSX. It crash-dumped, giving a whole lot of zeroes. Next post
>will be same test with the good KD11E-A; stay tuned..
>
>thx
>jake
>
>
>?@
>000000 000 00000 000000
>@
>0 000 00000 00000
>@
>0 000 00000 00000
>@
>0 000 00000 00000
>@
>0 000 00000 00000
>@
>0 000 00000 00000
>@DL?
>
>
>BOOTING UP XXDP-XM EXTENDED MONITOR
>
>
>XXDP-XM EXTENDED MONITOR - XXDP V2.5
>REVISION: F0
>BOOTED FROM DL0
>124KW OF MEMORY
>UNIBUS SYSTEM
>
>RESTART ADDRESS: 152000
>TYPE "H" FOR HELP !
>
>.R ?RLG??
>NRLGA0.BIC
>
>DRSSM-G2
>CNRLG-A-0
>CNRLG TESTS CONTROLLER FUNCTIONS, INTERFACE LOGIC, REGISTER OPERATION
>UNIT IS RL01,RL02
>RSTRT ADR 000000
>DR>START
>
>CHANGE HW (L) ? Y
>
># UNITS (D) ? 1
>
>UNIT 0
>RL11=1, RLV11=2, RLV12=3 (O) 0 ? 1
>BUS ADDRESS (O) 0 ? 174400
>
># TOO LARGE
>BUS ADDRESS (O) 0 ? 174400
>
># TOO LARGE
>BUS ADDRESS (O) 0 ?
>VECTOR (O) 0 ? 160
>
># TOO LARGE
>VECTOR (O) 0 ?
>
>TOO MANY VALUES INPUT
>VECTOR (O) 0 ?
>DRIVE (O) 0 ?
>DRIVE TYPE = RL01 (L) Y ? N
>BR LEVEL (O) 0 ? 5
>
>CHANGE SW (L) ? N
>
>NXT TST MAY ZERO LD UNIT. DOIT ANYWAY?Y
>
>
> ILL INTER 000
> PC 000000 PS 000000
>DR>START
>
>CHANGE HW (L) ? Y
>
># UNITS (D) ?
>
>NO DEFAULT
># UNITS (D) ? 1
>
>UNIT 0
>RL11=1, RLV11=2, RLV12=3 (O) 0 ? 1
>BUS ADDRESS (O) 0 ?
>VECTOR (O) 0 ?
>DRIVE (O) 0 ?
>DRIVE TYPE = RL01 (L) Y ? N
>BR LEVEL (O) 0 ?
>
>CHANGE SW (L) ? N
>
>NXT TST MAY ZERO LD UNIT. DOIT ANYWAY?Y
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG EOP 0
> 0 TOTAL ERRS
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG DVC FTL ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000
>BAD SEEK-TEST OF DIFFENCE WORD
>CONTROLLER: 000000 DRIVE: 0
>BEFORE COMMAND: CS: 000000 BA: 000000 DA: 000000 MP: 000000
>TIME OF ERROR: CS: 000000 BA: 000000 DA: 000000 MP: 000000?
>LAST: 000000 PRES: 000000 EXP'D: 000000
>
>CNRLG EOP 0
> 0 TOTAL ERRS
>^C
>DR>^C^C
>DR>
>XIT^U
>EXIT
>?@
>000000 000 00000 000000
>@
>0 000 00000 00000
>@
>0 000 00000 00000
>@
>0 000 00000 00000
>@DL?
> DEVICE DD000: NOT IN CONFIGURATION
>DEVICE DD100: NOT IN CONFIGURATION
>DEVICE DY002: NOT IN CONFIGURATION
>DEVICE DY102: NOT IN CONFIGURATION
>DEVICE NI002: NOT IN CONFIGURATION
>
> RSX-11M V4.1 BL35 124.K MAPPED
>
>SYSTEM CRASH AT LOCATION 000000
>
>REGISTERS
>
> R0=000000 R1=000000 R2=000000 R3=000000
>
> R4=000000 R5=000000 SP=000000 PS=000000
>
>SYSTEM STACK DUMP
>
> LOCATION CONTENTS
>
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
> 000000 000000
>
>
>CRASH -- CONT WITH SCRATCH MEDIA ON DY0
>
>On Thu, Jan 29, 2015 at 9:30 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
>wrote:
>
>> ok, now with my 'good' 11/34 board set (not the set with the mysterious
>> zero bug) installed, I re-ran xxdp against the rl02. I'm getting proper
>> prompts with the address and vectors supplied with non-zero numbers as
>> defaults. I just hit return like I had been doing with the 'zero-bug' cpu
>> boards and this time, the tests run, the drive blinks wildly like before,
>> and I get real results with real numbers filled in. I think this pretty
>> conclusively proves that there's something really weird (mysterious zero
>> bug) going on with my other board set.
>>
>> On Thu, Jan 29, 2015 at 7:15 PM, Johnny Billquist <bqt at update.uu.se>
>> wrote:
>>
>>> On 2015-01-29 20:14, Pete Turnbull wrote:
>>>
>>>> On 29/01/2015 18:32, Jacob Ritorto wrote:
>>>>
>>>>> Johnny, you're insisting that I put in the real numbers for address
>>>>> and csr
>>>>> for testing the drive (for instance). I'm going to do that next, here.
>>>>> But are you understanding that some of us think that the reason it
>>>>> prompts
>>>>> a zero default is that it's a manifestation of the zero bug and that the
>>>>> real value *is* actually safe but hidden in memory? Did you see the
>>>>> RSX-11M crash dump I posted in the other thread?
>>>>>
>>>>
>>>> I didn't see a crash dump, but did you see what I posted yesterday?
>>>>
>>>
>>> I haven't seen any crash dumps either.
>>>
>>> The default in XXDP for CSRs is very often zero, and I'm pretty sure it
>>>> is so in the RL02 diagnostics (I've ont checked the listing for that
>>>> particular one, but I did look at some others that were more readily to
>>>> hand). So when it asked you for input and you just hit "return", you
>>>> really did tell it zero. Applying the principle of Occam's Razor, and
>>>> assuming the simplest solution is the correct one, you got a lot of
>>>> zeros back because it was accessing memory instead of the controller you
>>>> wanted.
>>>>
>>>> It's hard to believe you have a CPU fault that consistently prints
>>>> numbers as zeros yet happily boots three different OSs. Still, I'll
>>>> change the tune if you re-run XXDP with sensible inputs.
>>>>
>>>
>>> Totally agree with that one.
>>>
>>>
>>> Johnny
>>>
>>> --
>>> 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
>>>
>>
>>
So, I'm in the process of trying to read those old MIT V6 Unix dump tapes
(with a really big hand from Chuck, who did all the ugly work of actually
reading the bits off the tapes, for which he has my undying gratitude!), and
although I'm still trying to figure out what the format is, I did manage to
retrieve, more or less, a copy of the assembler startup/support file (m47.s; a
hacked version of m45.s), and it reveals that we were using an Able ENABLE
card to take our 11/45 out to more than 256KB.
I found a copy of brochure which very briefly describes/shows it here:
http://archive.org/stream/bitsavers_ablebrochuuctSummary_2920347/Able_Compu…
and although the picture didn't ring any bells for me, that must be it.
It looks like it has a UNIBUS connector (which I take it is 'UNIBUS out'), and
also some kind of 'over-the-back' connector which I assume is the bus to the
memory, which sounds (from a brief mention I found somewhere else) like it was
standard Extended UNIBUS memory in a separate backplane. (Although I could be
wrong; maybe the ENABLE plugged into the EUB backplane, and the UNIBUS
connector is 'UNIBUS in' from the CPU?)
I was unable to locate any real documentation for it online (maybe my
Google-fu just isn't strong enough), but if someone has any, or can point me
at any, I'd be grateful.
Any if anyone actually has one, in the flesh, that would be Really Cool!
Noel
At 07:34 PM 1/27/2015, Jacob Ritorto wrote:
>Johnny, I just took the defaults,
>BUS ADDRESS (O) 0 ?
What Johnny said. The prompt says "(O)", not "(0)" - the letter O for
Octal. The zero after that isn't a default, it simply means that the
value hasn't been set.
There is no default. Or at least no sane one. Zero in this case means
that it's writing to memory address zero for CSR. The diagnostic should
reject that, but diagnostics are notoriously user unfriendly.
-Rick
For those of you who are Spacewar! buffs and you haven't seen Norbert
Landsteiner's work, you are missing something big.
Norbert has what I believe to be the best simulation of original PDP-1
Spacewar! code running on a Model 30 display. And he doesn't just have
one version Spacewar! - but several original versions.
In addition, Norbert analyzed the original Spacewar! code line-by-line
and created an incredible set of writeups on Spacewar! internals.
As Norbert created his writeups, he sent them to me. I read them over,
and forwarded them to the entire PDP-1 Team at the Computer History
Museum. That Team includes Steve Russell (principal author of
Spacewar!) and Peter Samson (Spacewar! star field, etc.).
Additionally, I met with both Steve and Peter and we reviewed
several of Norbert's writeups together in some detail - and found only a
few minor corrections/comments to pass back to Norbert.
Here are links to Norbert's work:
Simulation
----------
http://www.masswerk.at/spacewar/
Writeups (Inside Spacewar!)
---------------------------
http://www.masswerk.at/spacewar/inside/
Cheers,
Lyle
--
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
> From: Roe Peterson
> How is it that googling
> XXDP manual
> XXDP documentation
> XXDP memory test
> Doesn't point at this?
Because Googling, useful as it is, is inferior to humans^H^H^H intelligences
actually sorting things out, and organizing them in a structured manner. (The
way Yahoo worked when it very first started...)
Now, if we had a wiki.... :-)
Noel
> From: Jacob Ritorto
> I just need quite a lot of hand holding because I'm still way too green
> with this stuff.
Hey, that's what this list is for, right? ;-)
> put in the real numbers for address and csr for testing the drive ...
> I'm going to do that next, here. ... the reason it prompts a zero
> default is that it's a manifestation of the zero bug and that the real
> value *is* actually safe but hidden in memory?
One other thing you could do that would be interesting: re-run the exact
same test, but with the good cards in the machine, and see if you still
get 0's printed, or if this time the correct numbers show up.
Of course, that won't definitely prove that the right numbers are actually
being used inside (in the case where it prints 0's), but it would certainly be
suggestive.
Noel
>Alexandre Souza wrote:
> ----- Original Message ----- From: "Mark J. Blair" <nf6x at nf6x.net>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Sent: Tuesday, January 27, 2015 3:04 PM
> Subject: Destructive Imaging of DECTAPE II Media
>
> [Snip]
>
> What do you folks think about this silliness?
It has been over 2 years since I last used my TU58 tape drive,
but it was still working then with (of course USABLE) TU58
tapes, although a good percentage were no longer in that
category. If it seems reasonable, I can try to see if the TU58
tape drive will still function correctly.
If the TU58 tapes which need to be recovered can still be
read by a TU58 drive, then I could undertake to recover
those ones. Note that I am in Toronto, so postage would
be MUCH more than within the US.
Unfortunately, there is no visual difference between tapes
which can still be read and those which have errors that
can't be recovered. But if the tape can't even be moved
or the drive belt is broken, either of those problems would
prevent a standard DEC TU58 drive from being able to
recover any data from the tape.
Jerome Fine
> From: Johnny Billquist
> I searched around a bit more today.
> I did find a couple of brochures on bitsavers that mentions it.
Err, you didn't need Google for that - the first post in this thread
mentioned it... :-)
>> Standard Extended UNIBUS (a la 11/24 and 11/44), I think.
> "Standard" is a strong word here. :-)
Well, 'standard' in the sense that more than one DEC machine used it, and one
could buy third-party memory cards that conformed to it.
> The Megabox .. As far as I know, it is not a Unibus at all. And it
> still could not be a Unibus, for the same reason I mentioned above.
I _suspect_ that internally it has a backplane which supported EUB, and the
memory plugged into that; whether that was a custom backplane, or what, I
don't know. (I'd have to check the wire-lists on, say, a DD11-D to see if
those pins are bussed together - I have this vague memory that they are.)
And yes, _iff_ the cable to it is a standard UNIBUS cable (I don't know what
kind of cable they used), that would only support the 18-bit address space -
which would imply that the ENABLE card was in the Megabox.
>> (And I can show you the code... :-) The original MMU was retained; the
>> ENABLE included only a second set of PARS (full 16-bit wide), which
>> were the ones normally used while the system was running; the PDRs in
>> the CPU continued to be used as the _only_ PDRs in the system.
> That would imply you could not address more than 256K from the CPU. Not
> likely...
Dude, I PERSONALLY WROTE THE CODE TO USE THE ENABLE. And I have the source,
here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/conf/m47.s
You are correct, the CPU cannot _directly_ address more than 256KB. However,
the ENABLE board _can_; mapping registers in the ENABLE (32 of them, each
handling an 8KB section of incoming UNIBUS address space, from the CPU) allow
that UNIBUS address space to be mapped, in 8KB blocks, anywhere in the 22-bit
memory space.
You will find it all laid out most ably in this old post by Mike Muuss
(peace, Mike):
http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.12_u…
It looks like I used a slightly different layout of the address space on the
UNIBUS from the CPU to the ENABLE from the one he describes (the code in
m47.s seems to use:
KI0-7
KD0-6
UI0-7
UD0-7
KD7 I/O page
with the KI underneath the KD, unlike his; KD7 has to be at the top so that
the CPU can get to the registers in the ENABLE), but other than that the
details are identical. (Note that they only differ in how the registers were
_used_, not in terms of what the hardware's capabilities were.)
>> The style of usage was to, using the CPU's PARs, statically map Kernel
>> D space to one quadrant of UNIBUS address space, Kernel I to a second,
>> User D to a third, and User I to the fourth.
> The 11/34 do not have D-space...
I was talking about on the /45.
>> The PARs on the ENABLE card (which controlled which part of real
>> memory various addresses on the first UNIBUS got mapped to) were the
>> ones the operating system adjusted as the system was running.
> Sorry, this is simply not how it worked.
Repeat previous comment about how I personally wrote the code to use it.
Just for you, I have groveled around in the dump I'm working on retrieving,
and found seg.h, which is the header file which contains the #defines for the
mapping registers in Unix V6. Here it is:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/h/seg.h
If you look at it, you will see that UISA[0] has been modified to be
"0163736". That's how we did the ENABLE - we just changed those definitions,
and recompiled all the system modules that touched the mapping registers, so
that that code now talked to the 16-bit PARs on the ENABLE, and not the
12-bit ones in the KT (which were set once at system startup time to provide
the static mapping - see m47.s - and then never changed again).
> Like I said, I actually used an 11/34 with the ENable/34 and the
> separate memory box for a few years. It really looked and behaved
> identically to an 11/24. Ie, full 16-bit PARs, still no split I/D space.
Yes, no split I/D because it was totally external to the CPU, it could only
take the UNIBUS addresses the CPU generated and map them around.
>> I'm kind of hazy on exactly how this was all wired up: there are the
>> fingers on the card (which I think _might_ be the EUB used for the
>> memory bus), the UNIBUS edge connector on the ENABLE card, and that
>> over-the-back connector on the ENABLE card.
> An 11/34 do not have any EUB slots.
I was assuming that the ENABLE used an EUB to talk to its memory. (See
diagram further up the original post.)
> (You should see Updates storage rooms...)
Even better would be being allowed to poke around in there... :-)
> I was running RSX-11M and RSX-11M-PLUS on our 11/34, and no
> modifications to the kernel was needed.
There must have been some changes somewhere, since as you can see from the
code above, the ENABLE had PARs in non-standard locations (0163700-0163776).
Anyway, if you could find the documentation that would be super-wonderful,
because I am _really_ curious to know exactly how the thing interfaced to the
incoming UNIBUS, outgoing UNIBUS, memory, and cache.
Noel
On 25 January 2015 at 00:04, John Foust <jfoust at threedee.com> wrote:
> I haven't ever played with official Sugru, but how does it differ
> from ordinary relatively inexpensive Shoe Goo? Is Sugru like
> slightly dried-out Shoe Goo? I find that a tube of Shoe Goo
> dries out a bit after a few years and becomes a more easily worked
> substance.
I've never heard of this Shoe Goo stuff before, so I can't comment on
a direct comparison.
I've used a differently-branded Sugru alternative, though. It's not an
adhesive and it's not sticky. It's like Plasticine or other modelling
clay -- a smooth, non-tacky, very viscous colloidal gel, which can be
moulded and shaped. It only adheres to things by virtue of being
moulded onto and around them; if you need to, say, stick it to a flat
surface, you'd have to glue it on.
But when it sets, it goes hard - like a hard rubber. You can make a
small mark with a fingernail but this will eventually smooth out. It's
no more pliable than a piece of truck tyre when cured.
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)
