> From: Richard <legalize at xmission.com>
> Roger Holmes <roger.holmes at microspot.co.uk> writes:
>
>> ither. The 29000 processor [...]
>
> 2900, not 29000. The 29xx is a bit-slice CPU design made up of a
> bunch of chips. The 29000 is a single chip CPU that came later.
Quite right. Brain parity error, but the difference is only a 0 :-)
IIRC we used six 4 bit slices and a controller chip in one of our machines called CHLL which was a two off special, one bench prototype and one flyable prototype. I got to modify some of the microcode for the bench machine and worked on the CHLL 'compactor' which was really a compiler but the idea was that the instruction set was a Compacted High Level Language so the compiler was very simple (it wasn't) and he machine would be very efficient (it wasn't). Trouble was someone got carried away and implemented much of Algol 60 instead of the Coral 66 they had been asked to do. I just cleaned it up and got it through its acceptance test with the minimum of work. I remember telling them I could fix a bug easily (by incrementing a field for a particular instruction as it went through the back end of the code generator) but that it was not the right place to fix it. I was told to fix it in the wrong place and I did so and they closed down the project. Apparently the flyable prototype was used at the Royal Aircraft Establishment at Farnborough - as a door stop!
At the time I had neither the experience nor the confidence to tell them they were wrong, I was just a year out of University, supposedly a trainee programmer working for a huge company (4000 staff at just the one site I worked and many other sites too) and its only looking back years later I realised fully what had gone on.
I snagged a copy of the first three volumes of this set from the company
library when they were thinning the stacks.
They were published by The People's Computer Company in 1980.
They are a really cool snapshot of the microcomputer stuff that was doing on
in the late '70s. Is there an online copy?
-chuck
On 2010-10-27 00:16, Roger Holmes<roger.holmes at microspot.co.uk> wrote:
>> > From: Johnny Billquist<bqt at softjar.se>
>> > On 10/26/10 04:20, Roger Holmes<roger.holmes at microspot.co.uk> wrote:
>> >
>>>>> >>>> From: Mr Ian Primus<ian_primus at yahoo.com>
>>>>> >>>> And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best:)
>>> >> I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
>> >
>> > What does "largest addressable unit of memory" means? I totally fail to
>> > understand that. Sounds like "the largest memory chip that can be
>> > utilized", but that can hardly be the meaning.
> Compare with another thing I was taught. A byte is the smallest addressable unit of memory. By this definition I have worked on machines with bytes sizes of 3, 8, 18, 24, 36 and (I think) 60. In most of the latter ones, a byte was also a word. I guess you exclude memory to memory block move instructions, then consider the instructions which can load and save data and find the one which acts on the largest number of bits. I think by this definition a 68000, a Z8000, and the Manchester Baby all had 32 bit words. The VAX may have had 32 bit of 64 bit words even if it had just a 32 bit data path. My ICT 1301 has 48 bits words and 48 bit bytes even though its mill was only 4 bits wide. The data path from core memory to the 'A' register was 50 bits in parallel (it had two parity bits), but the data path between registers was only 4 bits, or in one case two sets of 4 bits. It was a serial/parallel architecture which allowed the end user price to be kept just below 250,000 pounds
f!
> or a 5 tape deck mag tape machine with card reader, card punch, line printer, one drum and 2000 (decimal) words of core.
Hmm. Gotcha. But in that case, a VAX would be a 128 bit machine, since
the largest quantities it can operate on is 128 bits.
And a PDP-11 would, I guess, be a 32-bit machine, and a Z80 a 16-bit
machine.
Hmm, I do not think I agree with that definition.
> Sorry for rambling and thanks for all who commented on my 41 years of programming experience.
I think it's more convenient to look at what the "natural size" of the
registers are.
I say "natural", because for instance, on the Z80, you can combine
registers, but I would define that as not the natual size. So, HL is a
16-bit register, and you can do pretty much anything with the, but it's
actually the registers H and L combined together, and you can address
each register separately as well. And they are 8 bits.
And the PDP-11 have 16-bit registers, but some operations work on a
combination of two registers combined. Once again, not "natural". And
the same goes for the VAX (obviously).
On the PDP-10 the accumulaltors are 36 bits, but you have instructions
that can deal with bytes of any size between 1 and 36 bits. And they
automatically manage the manipulations on parts of accumulators. But
those smaller byte sizes aren't natural either, so it is 36 bits on that
machine. :-)
But it might have made more sense back in older days..?
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
Oh, yeah... One more thing...
> The VAX-11 (note that "-11" in the names of the first models!) added the
> use of demand-paged virtual memory (that is to say, disk-based storage) to
> the PDP-11, then expanded the instruction set into the new 32-bit word size.
The -11 in VAX-11 was placed there to indicate the inheritance to the
PDP-11, and the fact that it could execute PDP-11 code as well (even if
only in user mode).
The -11 moniker was dropped when PDP-11 compatibility was dropped.
(And for the person who raises his hand and asks about the VAX 86x0
machine, which do have PDP-11 compatibility, those machines were
internally referred to as VAX-11/79x, but marketing (or whoever) decided
that it would be cool to call them 8600 instead. I even once read a
rumor that 8600 was chosed as it was twice that of 4300, but I don't
know. But if you read DEC documentation on the 86x0 machine, you can
still find plenty of references to VAX-11/790.)
If you still doubt what I write, I suggest this source:
http://www.bitsavers.org/pdf/dec/vax/VAX_archHbkVol1_1977.pdf
which is the very first edition of the VAX-11/780 Architecture Handbook.
Read chapter 1.1, Introduction.
Second paragraph has this nice piece of text:
"The goals of the VAX architecture were to provide a significant
enhancement to the virtual addressing capability of the PDP-11 series
consistent with small code size, easy exploitation by higher-level
languages, and a high degree of compatibility with the PDP-11 series."
Now, if people could only read documentation, and learn to use terms the
correct way... ;-) :-D
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
On 2010-10-27 00:16, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>> > VAX stands for "Virtual Address eXtension", note the "extension".
> I always thought that VAX-11 meant it was a PDP11 that had the
> 'eXtension' of 'Virtual Addresses'.
You obviously need to pick up any PDP-11 processor handbook as well, and
check out the memory management chapter. DEC defined the PDP-11 as
having virtual addresses already from the first day the MMU was
available for the machine. :-)
>> > Extension normally means that you modify/extend something that already
>> > exists, in this case the virtual address. On a PDP-11, the virtual
>> > address is 16 bits, the VAX extended it to 32 bits, which is a huge
>> > improvement (and the biggest bottleneck of the PDP-11, as I'm sure all
>> > people know). The physical address on a PDP-11 is 22 bits, while the
>> > physical address on a VAX varies, but on the 11/780 I only think it was
>> > something like 24 bits.
> Hmmm. I was under the impression there was a difference between virtual
> memory/addresses and an MMU. Namely that the former impliled a larger
> logical address space than the physcial address space and that if a
> program tried to access a memory page that wasn't currently mapped to a
> physcial area of memory, the OS would be given the chance to load the
> approraite data from disk (or whatever) into RAM and map the page
> appropriately.
The size of the virtual address space compared to the physical is not
really relevant. After all, on a VAX, they are actually the same. The
physical address is defined as 32 bits, and the virtual address as well.
However, no VAX actually implemented a full 32 bit physical address
space, but there were many different max physical memory limits on
different machines.
A virtual address is "virtual". It's not real. It's a fake. :-)
The MMU is what does the translation between a virtual and a physical
address. Exactly how these two domains look like have less to do with
the definition. And exactly how the translation is done is also less
relevant. As long as you can present to several programs running on the
same machine, a memory space in which they think they are the only one
playing with the memory, and they have an "unlimited" (within the size
of the address space) access to that memory in a linear fashion, it
qualified as virtual memory. (What would you call it?)
> The 11/780 logica address space is larger than the physical one, the
> (memory managed) PDP11's is not.
Yes. So what? In which way would that make the virtual address in a
program running on a PDP-11 less virtual? After all, you are totally
shielded from how the actual physical memory layout, allocation,
translation or mapping is done. You are only playing within your virtual
memory space.
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
Hi, Rich. Thanks for broaching an interesting topic of which I'm rather
fond... :-)
On 2010-10-27 00:16, Rich Alderson<RichA at vulcan.com> wrote:
> From: Johnny Billquist
> Sent: Monday, October 25, 2010 9:08 AM
>
> 1.> The PDP-11 was in architectural ways more important than the VAX, if
> > nothing else than just because the VAX was basically just extending the
> > PDP-11.
>
> 2.> However, I also object to the discussion about "Virtual memory" as
> > something new the VAX brought to the table.
>
> 3.> Virtual memory worked just fine on a PDP-11 as well, thank you very
> > much, as it also worked fine on a bunch of other machines, and had been
> > doing for quite a while.
>
> 4.> VAX stands for "Virtual Address eXtension", note the "extension".
> > Extension normally means that you modify/extend something that already
> > exists, in this case the virtual address. On a PDP-11, the virtual
> > address is 16 bits, the VAX extended it to 32 bits, which is a huge
> > improvement (and the biggest bottleneck of the PDP-11, as I'm sure all
> > people know). The physical address on a PDP-11 is 22 bits, while the
> > physical address on a VAX varies, but on the 11/780 I only think it was
> > something like 24 bits.
>
> 5.> The VAX also introduced demand pageing, compared to the PDP-11, where
> > you normally didn't do that (and not all models could even possibly do
> > it), but demand pageing as such wasn't new either. DEC was already doing
> > it with the PDP-10 running TOPS-20 (and other companies had also done it).
>
> Addressing 1, 2, 4, and 5:
>
> The "Extension" in 'Virtual Address Extension" does not refer to extending
> the virtual address in the PDP-11, but rather to extending the PDP-11
> architecture with virtual addressing. The PDP-11's 16-bit address is real,
> not virtual in the usual definition; the use of memory management to select
> from within an 18- or 22-bit memory space does not make it virtual.
Sorry, but I'll have to totally disagree with you, and so does all the
processor handbooks for the PDP-11. :-)
Virtual addressing have nothing to do with demand paging, or even paging
(even though I know Wikipedia uses that very broken definition (or
atleast used to)).
A virtual address is... Well... Virtual. It does not match a physical
address. Instead it is an address into an imagined memory space, virtual
memory. This virtual memory space would appear as just your own in a
system. Another process in the same system have another virtual address
space, using the same virtual addresses you are, but you are not
actually referring to the same memory. It's virtual. :-)
A virtual address gets translated into a physical address by an MMU.
The "Virtual Adress eXtension" (aka. VAX) was a virtual address
extension to the PDP-11, nothing more.
The PDP-11 already have virtual addressing. Pick up any PDP-11 processor
handbook and read about it yourself. Or check
http://www.google.ch/url?sa=t&source=web&cd=2&ved=0CB4QFjAB&url=http%3A%2F%…
, for the (arguably) yucky PDP-11/40 online. Look at chapter 6 - Memory
Management.
On a PDP-11, an address can either be physical, in case the MMU is
turned off, or else virtual. The virtual address gets translated to a
physical address by the MMU, by using the page table and some simple adders.
In case you run on a PDP-11 with the MMU turned off, the 16-bit address
just gets extended to 18 (or 22) bits by using zeroes for the high bits
of the physical address. if the MMU is turned on, the virtual 16-bit
address is translated into a 18 or 22-bit physical address.
> The VAX-11 (note that "-11" in the names of the first models!) added the
> use of demand-paged virtual memory (that is to say, disk-based storage) to
> the PDP-11, then expanded the instruction set into the new 32-bit word size.
VMS added demand paged virtual memory. There is nothing preventing you
>from writing an OS on the VAX which don't use demand paging, just as
there is nothing preventing you from writing an OS for the PDP-11 which
would do demand paging (assuming you have a PDP-11 model with the
neccesary features implemented in the MMU, which not all have).
> Addressing 2 and 5:
>
> Burroughs introduced the B5000, the first computer with virtual memory
> (segmented rather than paged) in 1961; the British brought out the Atlas in
> 1962. Multics used both segmentation and paging on the GE-645, beginning
> in 1964. DEC provided a segmented memory model in the PDP-6 (1964) and
> PDP-10 (1967); BB&N created a pager for the PDP-10 and brought TENEX, with
> demand paging, to the world c. 1970. When DEC licensed TENEX and modified
> it for the KL-10 processor (born at the Stanford AI Lab as the SuperFoonly!),
> they added the working-set concept which had been discovered by (IIRC)
> Denning in his research on demand-paged memory systems, and christened the
> result "TOPS-20".
No additional comments. And you know the PDP-10 much better than I do. :-)
> Addressing 3:
>
> I don't believe that there was ever demand-paged virtual memory on the
> PDP-11, but I'm willing to be shown the error of my ways. Please point me
> at documentation for an operating system which did that.
Sorry, just as with you, I don't know of anyone who did that. But I can
tell you how you should do it, in case you'd be interested in actually
doing it. There is nothing in the hardware that prevents you.
The biggest reasons why noone did it are that:
1) The physical memory is much larger than the virtual memory on a
PDP-11, meaning that it's normally not a big problem to actually have
all virtual memory always paged in when a process is running. You will
never see working sets that are larger than what can be held in memory
at one time, thus one big reason for demand paged memory is lost.
2) The page size of the PDP-11 is 8K, which at the time was pretty big.
With that size, you actually only have eight pages for a process. Now,
why do demand paging, when you can at the most get 8 page misses before
everything is paged in? You might as well preload them, and skip the
whole demand paging mechanism.
3) Not all models of the PDP-11 MMUs support all the fancy stuff you
need. People weren't that interested in writing software that only
worked on some models (that did eventually happen in other ways anyway,
but only by slower evolution at a later stage).
So, no, I cannot point you to any system that implemented demand paging.
Maybe someone did it without us knowing about it. The fact still stands,
though. The PDP-11 allows you to do it. Is it then relevant if someone
actually did it or not?
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
> From: Eric Smith <eric at brouhaha.com>
>
>
>> You guys might like this one. I didn't realize AMD has been around that long.
>>
>> http://cgi.ebay.com/AMD-AM9080-INTEL-8080-CLONE-VINTAGE-COMPUTER-1978-RARE-…
>>
> What the item description doesn't say is that this is a development
> system for Am2900 series bitslice chips. The Am9080A (equivalent to
> Intel 8080A) is the only the host processor.
I will watch it with great interest. I have one too but mine also has a pair of 8 inch floppy drives attached in a separate cabinet. Never powered mine up either. The 29000 processor would have been in a unit under development not within this chassis. The unit contains emulated microprogram ROM. The 8080 loads microcode into the emulated ROM cards which were connected to the unit under development with ribbon cables.
Just picked up an nCUBE 2 from a list member, but I know almost nothing
about the machine (beyond wikipedia and my own examination of the machine
physically). I have the Sun 4/470 that front-ends it and, in theory, all
the software. But I've got no idea on how to actually _use_ it.
No one has donated nCUBE documentation to BitSavers, which pretty much
totally buggers me up. Is there anyone out there who is familiar with
these machines that, perhaps, could give me some pointers?
Muchas gracias all;
- JP
From: William Donzelli <wdonzelli at gmail.com>
>
>
>> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
>
> Big microcoded CISC was the dominant thinking in computer architecture
> at the time, so it is really hard to say that X influenced Y.
True
>
>> The engineers did not believe the Motorola design was practical and we worried about a large 64 pin chip in the environment of a military helicopter's avionics bay (G forces, vibration, expansion, cooling etc) and it was decided to go with the 48pin Zilog Z8001 instead.
>
> Why not use PGA or Flatpack?
For production the plan was for bare silicon mounted on hybrids but the silicon itself was large. Of course as production progressed die sizes would have been shrunk but not fast enough.
We also used up to 22 layer PCBs! IIRC, samples when they became available would have been DIPs, they were for the Z8001 for sure. We used our own Elliott 920ATC computers to load code into shared RAM before the microprocessor was released from reset. I also wrote a simulator (for the Z8001) for compiler, high level assembler and other utility software development.
Unfortunately working at a technical level on the leading edge does not pay very well in the UK. I was told I would not be able to progress to a higher grade without becoming a manager, so I left and became a major shareholder and director of a tiny company and have remained technical to this day. Somewhat to my surprise I found I can still out-program every other programmer we have ever employed despite now being 57 years old.
Date: Tue, 26 Oct 2010 10:28:12 +0100
From: Roger Holmes <roger.holmes at microspot.co.uk>
Subject: Re: What are these IBM 'thingys'
> From: Al Kossow <aek at bitsavers.org>
>
> On 10/25/10 7:26 PM, leaknoil wrote:
>> It looks to me like a punch card exactly fits in there and the contacts
>> are what read the holes in the card.
>
> nope
>
> cards are read with 12 brushes
Or 80 brushes, I think the holes in cards were made tall and narrow to make
reading them that way easier.
+++++++++++++++++++++++++++++++++++++++++++++
Exactly. In those electro-mechanical days cards were almost always read in
parallel, i.e. long edge first, because that's how those machines worked;
rotary selectors, type bars, sorter gates, etc., the timing of the entire
system was based on and ran in sync with the card moving through the various
digit positions 0 to 9 (and 11 & 12 for symbols and alpha).
Want to add two numbers? Take a rotary 10-position switch and connect it
mechanically through a solenoid-operated clutch so that as the card moves so
does the switch, each position corresponding to a vertical location on the
card. Starting with the switch in the 0 position, read the first card,
engage the clutch when it passes the 0 position and drop the clutch when a
brush makes contact through a hole in the card. Do the same with the second
card and the rotary switch will read the sum (with a few extra solenoids and
relays to handle carries).
Want to print it? Simple: you have a type bar with the digits in reverse
order, again synchronized to the rest of the machine. Start rotating the
switch and moving the type bar together and when the switch hits 0 fire the
type hammer.
Want to sort your invoices by client number? Take the card deck over to your
08x sorter, those machines you've all seen in old movies where the cards
move across and drop into different columns or pockets (usually flying out
and across the room for amusement - it wasn't funny when it really did
happen!). Rotate the column selector knob to the LSD column (it only had one
moveable brush) and press Start. As the card moves, it passes a set of
chutes each leading to one of those pockets and when the brush makes contact
through the hole the card is diverted to whichever chute it's under at that
exact moment. Go through all the cards, put the 10 piles back together in
sequence, repeat for each column up to the MSD and presto, they're sorted.
Ah, the good old days... I'd love to see some kind of emulation of these
systems...
When computers came along the whole paradigm shifted from parallel
processing to serial, and those card readers did indeed read the card from
left to right with only 12 brushes (more likely optical sensors) instead of
top to bottom with 80, although IIRC there were some combined serial and
parallel binary card formats.
Of course now we've seen the error of our ways and have returned to parallel
processing; a modern card reader would no doubt read cards top to bottom
again, with each column connected to its own CPU.
mike