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)
> From: Johnny Billquist
> However, the was one board that went into the CPU box, and then there
> was a cable or two out from that to a separate memory box that held the
> memory. So the memory cards themself was not in the CPU box
Right, that's a product called the Megabox; details I can find online about
it are thin, but it seems to include the Extended UNIBUS backplane the memory
sits on, and the memory cards. (Google 'ABLE Enable Megabox' and it'll pop up
a short Computerworld blurb about it.)
> The machines that had more than 256K of memory, and were Unibus based,
> and had the memory on the "unibus" actually had a special backplane for
> the memory cards, where otherwise unused signals were used to do the
> extra addressing bits.
Standard Extended UNIBUS (a la 11/24 and 11/44), I think.
> Which also means that all the memory cards had to sit in the same
> backplane as the CPU. They could not be put in any other Unibus
> backplane.
Anyway, no, the memory did not have to be in the same backplane as the CPU;
see the Megabox, where the memory was in that box.
However, a caveat: there is some possibility there was more than one version
of the ENABLE, in which case two seemingly contradictory statements about
'the' ENABLE might in fact both be correct. But until that's shown, let's
assume there's only one kind... :-)
The thing that I think did have to be on (in, actually - see below) the main
UNIBUS was the ENABLE card. I think the logical configuration was like this
(diagram semi-ripped off from Mike Muuss' email):
Processor ---------- ENABLE ------------------------ Term.
UNIBUS | | UNIBUS
| EUB |
| |
|_ 11/44 style |
memory |_ Devices (both DMA and
non-DMA)
I think all the devices - well, you could have put non-DMA devices on the
section between the CPU and the ENABLE - all DMA devices at least, had to be
on the second UNIBUS, because the ENABLE included a UNIBUS map, which was
separate from the PARs used for CPU accesses, so I think that's pretty
conclusive that the CPU and DMA devices did not share a UNIBUS.
> and you'll get a new MMU which implements all the bits in the PAR
> registers. ..
> So, it also implies that the original MMU have to be removed.
No. (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.
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. (You wanted to use Supervisor mode too?
Thhhppptttt!) Those mappings would be on the segment between the CPU and
ENABLE; once initially set up, those mappings (i.e. CPU PAR contents) were
never changed.
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.
> And that is where you put the new card in.
I don't think so.
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. Then there were 4 things that had to be connected up: the
CPU UNIBUS, the memory EUB, the device UNIBUS, and an optional cache memory
card ... but we have only three connectors. So whether the cache somehow hung
off the EUB, or directly from the ENABLE via a custom backplane, or what, I'm
not sure.
> I don't know anything about the 11/45 extension this way. Like I said,
> I only played with an 11/34 that had this.
Anything you could do on the /34 could of course also be done on the /45
(since the ENABLE did not involve any mods to the CPU, it just interfaced to
the UNIBUS).
Although I have this bit set that perhaps it - or, one variant of the ENABLE
(see comment above about more than one) - somehow used the fast memory slots
in the 11/45 backplane (originally designed for special high-speed solid
state memory) and that's how you got full advantage of the cache. (I have
this distinct memory of running 'mips' on our /45 after it was upgraded and
the result was '3'...) But probably something in my memory is flaky - it was
a long time ago.
> I probably should try to find the documentation for exact details here
> then. I might be able to track down the machine, but I haven't seen it
> in almost 20 years.
If you could track down the documentation, that would be really good.
The programming of the thing we can work out (in addition to my code for V6
Unix, there is code online for other versions of Unix which support it, e.g.
BSD2.9). It's the physical installation details which are murky...
Noel
> From: Jacob Ritorto
> but now that the problem has been isolated and removed, I'm inclined to
> just enjoy the pdp11 :)
I'd really recommend fixing at least one more board set - otherwise, when the
next failure happens, you'll have _no_ working board sets...
Noel
We're up to 25 exhibitors for VCF East so far:
http://www.vintage.org/2015/east/exhibit.php
We'll definitely exceed 30, as we did last year for East 9.1 (33).
How high will it go? 35? 37? Will we somehow squeeze in 40, which would
be the most of any VCF ever?
If you're thinking about exhibiting, then do not wait. Register now
while there is space.
