On Tue, Mar 17, 2015 at 4:22 PM, Pontus Pihlgren <pontus at update.uu.se>
wrote:
> On Tue, Mar 17, 2015 at 04:08:26PM -0400, Ethan Dicks wrote:
> >
> >... How many 11/70s are in the hands of folks like us?
>
> Quite a few I would think. We have no less then three at the club. And
> of the top of my head there are at least three more owners on this list.
>
> Given how many of the more rare machines people have, I'd venture that
> there are at least 25, if not more, 11/70 machines in private hands.
>
> /P
>
So, I've never thought of the 11/70 as being "that rare", but "at least 25"
still sounds to me as being fairly uncommon as PDP-11's go?
How (relatively) common are the remaining early 11's these days? With some
lumping, and ignoring the F11/J11-based ones, in these categories: 20/15;
10/05; 40/35; 45; 50; 55; 60; 70; 34/04; 44? The last two I'm thinking are
still quite common; really no idea about the others ... although the number
of remaining 11/60's seems to be in the bare-handful category. 50's and
55's might be similarly low?
-----
paul
> From: Paul Koning
> if the CPU generates an address in the range 17000000 to 17577777, it
> lands on the Unibus and is then mapped by the Unibus map.
Umm, I think you meant "to 17 757 777", no? (Too many 7's - I find it helpful
to break them up into groups of 3, the way DEC does, to prevent that kind of
confustion.)
> More precisely, it works that way for 11/44 and 11/70 - but not for the
> J-11. That's a difference not documented in the PDP-11 Architecture
> handbook model differences table
But, but, but... the J-11 doesn't _have_ a UNIBUS map! Well, the 11/84 and
11/94 do, but not other J-11 machines. (And the Architecture Handbook table
does not have separate columns for the 11/73, 11/84, etc.) So an 11/73 can't
have a reference in the range 17 000 000 to 17 757 777 go out the UNIBUS -
there isn't one! :-)
So what happens if one does a reference to something in the range 17 000 000
to 17 757 777 on the 11/84? The 11/84 _does_ support having memory on the
UNIBUS (up to 248KB), _but_ how it appears depends on how much there is. (See
section 3.13.2, EK-1184-TM-PR2.) There's a special register to configure it
(the 'KTJ11-B Memory Configuration Register', KMCR), which includes _how
much_ UNIBUS memory there is.
If there is _no_ UNIBUS memory, then PMI memory appears (to the CPU) at 0 up,
and the UNIBUS Map is enabled. References to 17 000 000 to 17 757 777 go to
PMI memory ("PMI memory, as seen by the CPU, resides in contiguous locations
>from 0 up to as high as 17 757 777"), and presumably if there is no PMI
memory there, they fail, they don't even go out the UNIBUS to see if anyone's
home.
If there is _no_ PMI memory, then _UNIBUS_ memory appears (to the CPU) at 0
up, and the UNIBUS Map is _disabled_. (And I assume references to the range
01 000 000 to 17 757 777 just immediately fail.)
If, on the other hand, there is a _mix_ of PMI and UNIBUS memory, things get
really wierd. UNIBUS memory does not appear at 0, _or_ at 17 000 000 up to 17
577 777; instead, that memory appears to the CPU (depending on how much there
is) from 17 757 777 _downwards_ to (17 600 000-UNIBUS_memory_size); UNIBUS
memory apparently has to be assigned UNIBUS addresses from 757 777 _down_
("[UNIBUS] DMA Address XXX XXX accesses the same UNIBUS Memory location
accessed by CPU addresses 17 XXX XXX").
(Which is slightly odd because in the case where there is no PMI memory, the
UNIBUS memory needs to be assigned UNIBUS addresses from 0 up, which is quite
different from how to assign UNIBUS addresses to that memory in the 'mixed'
case. But never mind... :-)
The UNIBUS map will not respond to UNIBUS cycles in the address range
assigned to the UNIBUS memory.
And, to look at the original point, I would _guess_ that references to
locations in the range 17 000 000 to 17 757 777, but below the configured
UNIBUS memory, again don't go out the UNIBUS, but try and perform a PMI
cycle, which may or may not fail.
Basically, it seems like DEC was determined not to waste any address space on
the J-11/UNIBUS machines. Either it's configured as UNIBUS memory, or it's
PMI.
The KTJ11-B can also be configured to operate in 18-bit mode, with a mix of
PMI and UNIBUS memory, but I will leave the ugly details unless someone is
particularly interested in them! :-)
Noel
> From: Michael Holley
> The French standard is SECAM, which stands for "System Essentially
> Contrary to American Method"
The French! Don't get me started on the French!
(If there any French people on here, don't worry, you're all forgiven, because
of CYCLADES! For everyone who doesn't know what CYCLADES is: Google it!! These
bits are coming to you via its descendant! :-)
Question: Why is the ATM cell payload 48 bytes?
Clue #1: Multiply 1/c by the largest diameter of France.
Clue #2: What is a camel?
Noel
> From: John Wilson
> I used battery-backed SRAM in the Unibus RAM card I prototyped a while
> back (and just recently got working and have been finishing the XMOS
> firmware for).
UNIBUS RAM cards? Neato-keeno!! When will they be available, and how do I
order some? :-)
BTW, what's an 'XMOS'? Google didn't enlighten me...
> From: Ethan Dicks
> As much as I would like one (or two), what's the actual market for such
> a thing?
Oh, probably almost as large as all the other custom UNIBUS/PDP-11 cards
people are building these days... :-)
> I'd rather have a faster machine while I'm using it.
Somehow, I'm thinking that if it's speed we're after, a hardware PDP-11 isn't
where I'd turn... :-)
Noel
> From: Johnny Billquist
> But this is still way too little to actually know for sure how things
> works.
Even if you don't have the documentation, it's possible that the ENABLE at
Update can answer some questions for us. Does Update still have their ENABLE?
Is it still plugged into a machine, or has it been pulled (and is now sitting
on a shelf somewhere, perhaps)? If the latter, are there any pictures of it
in the machine?
Thanks!
Noel
By now, many have seen the 2100A on ebay (item # 141602578927). Those are
truly wonderful machines and a great example of HP engineering at the time.
IMHO, the best (usability) front panel of any machine I've ever touched. It
looks to be in good shape and from what little I can tell from the pictures
it looks to be complete (foggy memory makes me think there was an A9 card as
well, but don't recall for sure, probably optional). Only downside is it has
8K (give HP-IPL/OS a try), no terminal board, and no disc controller; the
only thing missing that is really essential is the terminal board (either
12531 {HS TERMINAL} or 12966 {BACI} is what it needs). I suspect it will go
for "substantially" more than the current bid ($290). Note that by and
large, I/O boards for the 1000 series (21MX M/E/F) are compatible with it.
The auction states there is no key, I have a whole box full of keys for the
2100 if someone here gets it. I have several 2100's, plus a couple spare
machines, so I have no dog in that hunt. Hope someone gives it a great home.
Whoever gets it - there is a chance I have a spare set of rails for it, not
sure.
Also of note is the 7970E tape drive (ebay item # 141603907013). I can't
really tell from the pictures, but careful inspection of them makes me
wonder if there isn't some corrosion present. Of particular concern is the
condition of the capstan surface. It may be completely fine, but the grainy
picture raises that question. On the bright side, the seller says the load
button produces the expected results which is a fair sign of some amount of
life. Bidders should be aware that the electrical interface for this drive
is "HP Only", not a common standard. I asked the seller to get a picture
inside the unit, particularly so I could see the date code and options
placard but didn't get a response. At the least it would be nice to know
what speed the drive is and more importantly if it is a "slave only" unit
(requiring a master). Lastly, can't tell from the pictures, but I'm guessing
it does not include the oddball HP mounting bracket. It is unlikely you'd be
able to mount this thing in a rack at all without that bracket. If someone
here gets this unit, contact me off-list as I did actually get one extra
bracket manufactured in the recent order that is unspoken for. I was going
to bid on this unit because if it arrived and was in poor condition - it
would be a complete spare board set for my other two units. However, the
bidding has already gone above what I was willing to pay for a spare
boardset J Again, hope someone gives this a good home!
Best,
J
On Mon, 16 Mar 2015, John Foust wrote:
> I'm trying to understand at a low level how some early computers
> and game consoles generated a non-standard form of NTSC.
>
> The Wikipedia http://en.wikipedia.org/wiki/Low-definition_television says:
>
> "Older video game consoles and home computers generated a nonstandard NTSC
> or PAL signal which sent a single field type which prevented fields from
> interlacing. This is equivalent to 240p and 288p respectively, and was
> used due to requiring less resources and producing a progressive
> and stable signal."
[...]
This has absolutely *nothing* to do with NTSC or PAL (or SECAM or
whatever). NTSC etc. are colour encoding standards and don't describe in
any way how a image signal is generated (fields, syncs, timing). They only
describe how to put colour information into the signal.
Christian
> From: John Wilson
> I think Guy's MEM11 is going to be way cooler. ... I'll be doing a new
> rev one of these months ... and then I'll certainly make them
> available, but not seriously expecting anyone to order one. Guy's MEM11
> is nicer!
Yeah, but for some machines I wouldn't mind having pure memory boards.
> it plugs into the A/B positions of a MUD/SPC slot, which makes it
> useless on an 11/20 which doesn't have those (right? unless you add a
> BA11K?)
I haven't checked, but I suspect there might be a way to power like a DD11-C
through some sort of conversion plug, but I'm not up on 11/20 power (would
have to read the H720 manual, which I'm too lazy to do).
> Naturally I've gotten way sidetracked writing that firmware ...
> Totally out of hand.
Hah, what else is life for? :-)
> it sounds (from the MS11P manual) as if the 11/24 and 11/44 extended
> Unibus would be easy to support as an option (seems like the four extra
> address bits on AN1, AP1, BE1, and BE2 are all that's new
I'm pretty sure. If you look at the MS11-M prints (FMPS #742, pg. 4), they
have a jumper called 'UNIBUS/Extended UNIBUS' and basically all it does is
disable listening to those 4 extra bus address lines. (It also affects CSR
stuff, but not the basic memory operation, other than disabling the 4 extra
address lines.)
I've got some MS11-P cards (which are now really cheap, compared to real
UNIBUS MOS memory) here, and I'm planning on hacking them so they are UNIBUS
cards, via a similar hack. (I'm not going to use MS11-M cards because they
use some wierd voltage that's only easily available in the 11/44; the
MS11-P's use +5V only.)
Noel
> From: John Wilson
> But for 18-bit machines, emulating the Enable thingy might be fun for a
> tiny handful of people, which is always enough to justify months of
> work in my book.
D'accord! :-)
> But thinking about how it must work hurts my head.
OK, let me give you my best understanding/recollection of how it works.
The UNIBUS from the CPU is pretty much only used as a CPU<->ENABLE bus. The
CPU does reads/writes (which all go to the ENABLE) on it, and interrupts from
devices come in on it, but that's all. (I don't think the CPU did NPR
arbitration any more.)
The CPU's internal PARs are used to distribute various chunks of CPU address
space across that UNIBUS' address space. Most code set up that mapping
statically at startup, and afterwards played only with the PARs in the ENABLE
(which could map chunks of the UNIBUS space to the 22-bit address space) from
then on. With a total of 256KB of UNIBUS address space, that means it will
hold a full-sized Kernel I+D, and a full-sized User I+D. There is therefore no
Supervisor (I or D), _unless_ you skimp on one of the other 4, or dynamically
re-allocate the address space in the CPU<->ENABLE UNIBUS (e.g. when switching
>from User to Super).
The Enable had two (maybe three) other bus connections: one was a device
UNIBUS in/out (for all DMA, and possibly other, devices), one was the 22-bit
address memory bus, and the potential third was the bus to the optional cache.
(Except I think maybe the latter two were combined into one; see below.) In
theory you could put non-DMA devices on the CPU<->ENABLE UNIBUS, but I don't
know if anyone did.
The second UNIBUS had a UNIBUS map on the end of it inside the ENABLE,
through which all incoming DMA cycles were fed to the 22-bit memory. So, NPR
cycles on it acted just like those on the 11/70's UNIBUS (they even used the
same register locations/etc, so programming-wise an 11 with the ENABLE looked
just like an 11/70, as far as the UNIBUS went).
There are code/.h files which give all the register locations, bits in the
CSR, etc so it should be possible to build a replica (so that existing code
for it still works).
If you look at a picture of an ENABLE (there's one in the Product Summary),
it's a hex card which has i) the normal edge connector, ii) a pair of DuPont
headers (which are, I'm pretty sure, the cache connector), and iii) a UNIBUS
connector stuck on the top edge of the card. I think one UNIBUS came in the
edge fingers (but I could be wrong, that's just a guess); the other clearly
used the one of the top of the card.
I don't know if it plugged into a 'normal' Extended UNIBUS system unit, or if
it was a special backplane that Able supplied. I suspect the latter, because
one way or another, that backplane had to have normal UNIBUS on either the
input or output A/B slots, and I can't see how that would work with EUB
memory cards plugged into that backplane. But maybe I'm missing something?
(This is why I'd really like to have the documentation - to see how it was
hooked up. How it worked, I can tell from looking at the software.)
It's possible the cache connector doubled as the memory bus; all memory cycles
would have been sent out that connector to the optional cache card, and if it
hit, cycle done; if not, it went out (over the backplane?) to the EUB
memory. So maybe if there was no cache, there was a different 'null' card
there with a connector for the ribbon cable, and minimal circuitry, to connect
up to the EUB - but that's a pure guess. Another possibility is that only the
cache used the DuPont connectors, and memory cycles went out other 'fingers'
on the edge connectors. (Grr! Wish we had installation instructions!!)
It would really help to know if the ENABLE needed a special backplane. Maybe
someone can look at the one at Update, and see what kind of backplane it's
plugged into? That could also tell us whether the UNIBUS connector on the back
edge was the 'in' or 'out' UNIBUS. (And of course they should make sure their
card looks like the one in the Product Summary brochure!)
> It's emulating Unibus memory at the same time that it's emulating the
> Unibus map -- i.e. CPU accesses (which should be relocated through the
> onboard PARs) are coming over the same bus as DMA (which should be
> relocated using the Unibus Map).
Nope. Two separate UNIBI.
> Does it need to tap into each model of CPU somehow (like how a
> Microverter gets at MMR3)?
AFAIK, it doesn't connect up to the CPU at all.
> And what if there's a cache, like the KK11A, that doesn't know about
> the outboard PARs?
Good question! Probably you should pitch the KK11A, and use Able's optional
cache for the ENABLE. Or flush the KK11A whenever you change the mapping
(does the KK11A have a register to do that)?
The one thing I'm still confused about is that I'm pretty sure that on our
11/45, with the ENABLE and its cache, running 'mips' produced 3. But could it
really get that much speed out of the UNIBUS? I had thought that somehow the
one we had plugged into the FastBus on the 11/45, but maybe my memory is
(somehow) playing tricks on me?
Noel
