test-drb October 2010

test-drb@ccmp.vtda.org

175 participants
274 discussions

by roger.holmes＠microspot.co.uk

> 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 for a 5 tape deck mag tape machine with card reader, card punch, line printer, one drum and 2000 (decimal) words of core. Sorry for rambling and thanks for all who commented on my 41 years of programming experience. > >> 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? > > That the PDP-11 influenced the VAX there can be no doubt about. > The the PDP-11 influenced the 68K seems very probable when looking at > the architectures, but that is guessing on our part. > > William Donzelli<wdonzelli at gmail.com> write: >>>> 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. > > Well, the fact that DEC explicitly stated that the VAX would be like the > PDP-11, but extended to 32 bits seems like an obvious statement that the > PDP-11 influenced the VAX. Not to mention the fact that they used the > same peripherial buses, and at VMS V1, most of the applications were > just the RSX programs moved straight over. Oh, and don't forget the > compatibility mode in the VAX, which made it execute PDP-11 code. :-) > > As for the 68K, we are making more of a guess, but it seems like a > fairly educated guess that the 68K was inspired by the PDP-11 (although Agreed. > I'd say the 68K is way inferior to the PDP-11...) If you say so, I never used a PDP-11. > > Johnny

13 years, 7 months

Happy Birthday VAX 11/780

by bqt＠softjar.se

On 10/25/10 16:53, William Donzelli <wdonzelli at gmail.com> wrote: >> > Also, the sentence starting "The VAX instruction set well revered would later on influence" needs restructured. The paragraph after the bullet points has more of the same error. > You could say that the designers of the 68000 were influenced by the > PDP-11, but I do not think you could say the same thing about the VAX. > When the 68000 design was started, the VAX was still well under wraps. > I can see no reason why DEC would have let the Motorola guys see the > developing architecture. > > Anyway, in the mid/late 1970s, heavily microcoded very CISCy > architectures were pretty much the design route of choice. It was > everywhere. It is very difficult to pin down influences. 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. However, I also object to the discussion about "Virtual memory" as something new the VAX brought to the table. 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. 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. 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). Johnny

13 years, 7 months

Another interesting computer on ebay

by brianlanning＠gmail.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-…

13 years, 7 months

BYTE magazines to be scanned?

by tosteve＠yahoo.com

I have stacks of duplicate BYTE magazines. Would it be a sin to have them cut-up to be scanned, page-by-page? Nothing from the 70's, I would do 80's era only. Has anyone ever done this? They wouldn't be posted online, it would be for personal research only. I would certainly share the info with others if requested.

13 years, 7 months

Happy Birthday VAX 11/780

by bqt＠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. > 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? That the PDP-11 influenced the VAX there can be no doubt about. The the PDP-11 influenced the 68K seems very probable when looking at the architectures, but that is guessing on our part. William Donzelli<wdonzelli at gmail.com> write: >> > 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. Well, the fact that DEC explicitly stated that the VAX would be like the PDP-11, but extended to 32 bits seems like an obvious statement that the PDP-11 influenced the VAX. Not to mention the fact that they used the same peripherial buses, and at VMS V1, most of the applications were just the RSX programs moved straight over. Oh, and don't forget the compatibility mode in the VAX, which made it execute PDP-11 code. :-) As for the 68K, we are making more of a guess, but it seems like a fairly educated guess that the 68K was inspired by the PDP-11 (although I'd say the 68K is way inferior to the PDP-11...) Johnny

13 years, 7 months

A new podcast

by david＠classiccomputing.com

Hello everyone, I would like to announce a new podcast series that I have started, and I feel really good about it's potential. When you can, please consider giving a listen to the Retro Computing Roundtable - http://web.me.com/dgreelish/Classic_Computing_Podcasts/RCR/RCR.html I am currently working on its submission to iTunes. This show has Bill Degnan from M.A.R.C.H. & VCFe, Earl Evans from "The Retrobits Podcast" and Carrington Vanston from the "1MHz: The Apple ][ Podcast." The next show is scheduled in three weeks! Best, David Greelish, Computer Historian Classic Computing The Home of Computer History Nostalgia http://www.classiccomputing.com Classic Computing Blog Classic Computing Show video podcast "Stan Veit's History of the Personal Computer" audiobook podcast Retro Computing Roundtable podcast Historical Computer Society meeting - first Wednesday of each month. Classic Computing Expo 1.0 - planned for March 2011!

13 years, 7 months

Oldest original proper computer (stored program etc)

by roger.holmes＠microspot.co.uk

> From: "Tom Gardner" <thomas.gardner at sbcglobal.net> > > On Fri, 22 Oct 2010 11:03:10 +0200 (CEST) Christian Corti wrote: > > > >> Per definition, a magnetic drum is not random access. > >> A random access storage is defined by the fact that addressing > >> any arbitrary cell needs the same time. > > > That may be today's definition but if you check the literature of the 50's > and 60's I am sure u will find drums (along with Williams Tubes, etc) > categorized as random access devices. Even the first disk drive was the IBM > RAMAC 350 - as in Random Access Memory! I think IBM invented the term > Direct Access Storage in the 1960s to distinguish devices whose assess time > was short but variable; that is, in between core (random) and tape > (sequential). > > > > So the historical definition may have been . needs essentially the same > time. > In my ICT 1301 manuals it always uses the term Immediate Access Store (IAS) for the core store, in fact I don't think the word core is used except in the engineers maintenance manuals. My machine also has three drums for storing overlays and data as well as mag tape. The drums also have reserved bands (only writable with an engineers assistance) which hold Initial Orders, the machine's bootstrap, along with three half words which are directly wired into the machine which on pressing a button are forced into the three control registers which then load Initial Orders from drum. P.S. I expect it was an oversight but please don't include the whole digest in your messages.

13 years, 7 months

simh & hardware - pdp-11 psw in supervisor mode?

by brad＠heeltoe.com

I have a low-level pdp-11 question... I'm confused about writing to the PSW on cpu's which support user & supervisor mode. My read of the docs is that in user mode you should not be able to write the "mode" bits of the PSW. (or, perhaps more accurately, you should not be able to *clear* any mode bits from user space) I have a little diagnostic which doesn't work as I though it should under simh and I thought I'd ask what others think... Basically, simh allows code running in "user mode" to write the PSW even when (I claim) it should not. I have not tried this on a real 11/44 or 11/34 yet, but I can/will. Should simh allow this? In the test blow the "clr @#PSW" is successful when run on simh and I think it should basically be a nop... (which begs another question - should it be a nop? or a exception?) A side question might be "the psw is not protected from writes, except by using the mmu" - is this true on all models? or just some? The 11/40 manual implies that it *is* protected. But 11/73 docs seem to say the opposite and imply using the mmu. diagnostic follows: .TITLE test17 .ASECT PSW=177776 ;processor status word .=34 .word 200 .word 0007 .=200 mov #200, r5 ;we should be in kernel mode here rti .=500 clr @#PSW ;kernel mode mov #500,sp ;sp=500 in kernel mode mov #140000,@#PSW ;user mode mov #700,sp ;sp=700 in user mode trap 377 ;should move us to kernel mode nop clr @#PSW ;back to kernel mode nop halt

13 years, 7 months

H316 indirect jump instruction

by drb＠msu.edu

I'm writing a little program in H316 assembler, running it in simh (3.8-1). The usual idiom for returning from a subroutine seems to be an indirect jump through a pointer. But my indirect jump halts at the location where the pointer is stored. The code looks something like this: ... >from jst subr call the subroutine ... subr dac ** ... do some stuff jmp* subr The jst is supposed to drop the address of from+1 into location subr, and execution continues at subr+1. The indirect jmp (jmp*) should be the return, getting the target address >from location subr. There are even examples in some of the H316 docs showing this kind of thing. Best I can tell, the assembled code has all the correct bits set -- the indirect bit is the high order bit in the word, and is set, opcode looks correct, etc. The correct target address is indeed stored at subr by the jst. Obviously this isn't re-entrant, etc. Don't care about that at this point. What am I doing wrong? Thanks, De

13 years, 7 months

simh & hardware - pdp-11 psw in supervisor mode?

by bqt＠softjar.se

On 10/25/10 00:46, Brad Parker <brad at heeltoe.com> wrote: > I have a low-level pdp-11 question... > > I'm confused about writing to the PSW on cpu's which support user& > supervisor mode. My > read of the docs is that in user mode you should not be able to write > the "mode" bits of the PSW. > > (or, perhaps more accurately, you should not be able to*clear* any mode > bits from user space) > > I have a little diagnostic which doesn't work as I though it should > under simh and I thought I'd > ask what others think... > > Basically, simh allows code running in "user mode" to write the PSW even > when (I claim) it > should not. I have not tried this on a real 11/44 or 11/34 yet, but I > can/will. > > Should simh allow this? In the test blow the "clr @#PSW" is successful > when run > on simh and I think it should basically be a nop... > > (which begs another question - should it be a nop? or a exception?) > > A side question might be "the psw is not protected from writes, except > by using > the mmu" - is this true on all models? or just some? The 11/40 manual > implies > that it*is* protected. But 11/73 docs seem to say the opposite and > imply using the mmu. > > diagnostic follows: > > .TITLE test17 > .ASECT > PSW=177776 ;processor status word > .=34 > .word 200 > .word 0007 > .=200 > mov #200, r5 ;we should be in kernel mode here > rti > .=500 > clr @#PSW ;kernel mode > mov #500,sp ;sp=500 in kernel mode > mov #140000,@#PSW ;user mode > mov #700,sp ;sp=700 in user mode > trap 377 ;should move us to kernel mode > nop > clr @#PSW ;back to kernel mode > nop > halt > > The PSW, when regarded as a memory location, is not protected at all. How could it be? The PSW is protected, when we talk about the MFPS/MTPS instructions, as well as the RETI/RETN. For an operating system, you normally protect the whole I/O page from user access, since not only the PSW is in there, but all kind of stuff that you do not want user programs to get access to. Data in the I/O page follows the same rules as any other memory essentially. If you have write access to it, you can write to those locations. The underlying device responding to those writes have no idea what the PSW is, and cannot enforce any protection. The special case of the PSW itself is perhaps "odd" since it actually do know what the PSW is (obviously) but it still follows the same rules as all other devices. Johnny

13 years, 7 months

← Newer
1
...
8
9
10
11
12
13
14
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb October 2010