test-drb May 2007

test-drb@ccmp.vtda.org

235 participants
483 discussions

by bqt＠softjar.se

"Rod Smallwood" <RodSmallwood at mail.ediconsulting.co.uk> skrev: > Hi > > Well that's seems to define the 11/84. > How does this all apply to the 11/94 > (which is the real problem) Well, the UBA is the same, so the same PMI Unibus signals are originated at that end. No memory can exist in an 11/94 though, since all the memory are on board. However, the communication between the CPU and UBA is using the PMI protocol, still. However, the dealings with interrupts and so on must still be done in the same way as for the 11/84 as well. So I would say that the 11/94 behaves exactly like the 11/84. (Do anyone know if an 11/94 with 2 megs on board could use an external 2 megs?) 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

17 years, 1 month

PDP-11/84, PMI and Q-bus

by RodSmallwood＠mail.ediconsulting.co.uk

Hi Well that's seems to define the 11/84. How does this all apply to the 11/94 (which is the real problem) Rod -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] On Behalf Of Johnny Billquist Sent: 21 May 2007 21:41 To: On-Topic and Off-Topic Posts; Pete Turnbull Subject: PDP-11/84, PMI and Q-bus Okay, since this topic have become a subject of much discussion and some diverse opinions, I decided to really read the manuals to try to find the bottom of this all. My main source of information here have been the "KDJ11-B CPU Module Users's Guide". EK-KDJ1B-UG-001 Now, to start with the position of the CPU card in an 11/84. Chapter 7, section 7.2. Page 7-1: "7.2 PMI INTERFACE The PMI interface signals are defined as the PMI bus master signals, the PMI slave signals and the PMI Unibus adapter signals. These interface signals are assigned to the C and D rows of the backplane and are defined as the interconnect bus. The PMI interface signals on the C/D bus are normally assigned two pins to provide an interconnection between the slots. The KDJ11-B module is only assigned one pin and therefore its position in the backplane is critical. The LSI bus signals that are used with the PMI protocol use the A and B rows of the backplane defined as the LSI bus." Now, if Pete is correct in that the PMI bus on the 11/84 really goes to both pins on all slots, then it should be okay to place the CPU in any slot. I haven't tried that, but I might when I have the time. I suspect he's right since otherwise I would have expected the CPU to be in slot 3. But DEC could be doing some fancy wiring... :-) The fact that the placement is critical is obvious if we talk about Q-bus systems, and I suspect the comment is written from that point of view. As for wether Q-bus memory (or any other Q-bus peripherial) will work, I'll quote some signal descriptions. Chapter 7, page 7-4. Table 7-3 PMI Unibus Adapter Signals "Pin: CF1 Mnemonic: PUBSYS L PMI Unibus System In a Unibus system, PUBSYS L is asserted by the UBA to direct the KDJ11-B to follow PMI protocol for all data transfers, wether the PSSEL L is asserted or not. LSI-11 bus protocol is disabled for all PMI devices when PUBSYS L is asserted. In an LSI-11 system, PUBSYS L is always negated. If PSSEL L is negated, the KDJ11-B follows LSI-11 protocol and the PMI memory then responds to the LSI-11 protocol by the LSI DMA devices." Chapter 7, page 7-5. Table 7-4 LSI Bus Signals "Pin: AF2 Mnemonic: BRPLY L Reply During PMI cycles, BRPLY L is asserted by the KDJ11-B and the PMI slave to prevent the next bus master from gaining control of the bus too soon. In a Unibus system, BRPLY L is asserted by the UBA as a slave response during the PMI DATOB cycle and interrupt DATI cycle. *** NOTE *** The PMI memory slave modules in a Unibus system must have BRPLY L disabled at all times. Pin: AH2 Mnemonic: BDIN L Data Input The BDIN L signal is only used in PMI Unibus systems during interrupt grant cycles. The KDJ11-B asserts BDIN L after it gates the interrupt priority, BDAL bits <3:0>, onto the bus. The UBA then latches the interrupt priority data using the leading edge of BDIN L. Pin: AM2 Mnemonic: BIAKI L Interrupt Acknowledge In Pin: AN2 Mnemonic: BIAKO L Interrupt Acknowledge Out These signals are only used in PMI Unibus systems during the interrupt grant cycles. The KDJ11-B asserts the BIAKI L signal, and the UBDA acknowledges it by asserting one of the Unibus bus grant signals. Pin: BB1 Mnemonic: BPOK H Power OK This signal is only used in PMI Unibus systems for the Unibus power-up/power-down protocol. This signal is asserted and negated by the UBA in response to the Unibus AC LO signal. The assertion of AC LO may be prolonged by the Unibus devices or the PMI memory during power-up." I could go on describing more details on how these signals are used, since it's all described in the manual. Suffice to day that the KDJ11-B *knows* when it's in a Unibus system (i.e 11/84) and will not behave like a normal Qbus. First of all, it will always use PMI protocol to access memory, no matter what the memory might claim. Second, interrupt handling is done differently, since all interrupts are expected to be dealt with via the UBA. There are also schematics for different signals in the manual, and you can clearly find the PUBSYS L signal included in some decoder path as a way to force a specific behaviour independent of other signals that might exist. Now, can we now accept that it's not a Q-bus in the 11/84? :-) 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

17 years, 1 month

NEC 7220's

by chrism3667＠yahoo.com

Has anyone come upon a source of preferably NOS 7220's? ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097

17 years, 1 month

Original PC Needs Rescue

by yakowenk＠yahoo.com

Hey, all, I've got mail from somebody with an original IBM PC from the first batch to be sold by IBM to its own employees. Apparently they selected employees >from a list by lottery to determine what order to deliver them, this was in the middle of the list, delivered in October 1982. (Isn't that a little late for first batch? Was the production rate not up to demand at first?) Anyway, there are several pieces: system unit, keyboard, monitor, etc.; mostly (or all?) in original cartons with docs & software & such, some still in shrink wrap. There is also some amount of PS/1 stuff, available together with the PC stuff or separately, depending on who wants what, the order in which responses arrive, and the phase of the moon. This stuff is all in Colorado, but the owner is willing to pay shipping (presumably assuming domestic!) so the location doesn't much matter. I'll collect responses and forward them in a batch, and the owner will decide who to contact and so on. Cheers, Bill. ____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

17 years, 1 month

FOG DOS discs

by aek＠bitsavers.org

> I wonder if there is > some sort of soaking that could be done to loosen the floppy from its > jacket The floppies were in VERY bad condition. Years of mosture, black mold on the labels, softening and general destruction of the oxide and binder including mold on the disk itself. Since there are thousands of discs to go through, the data may appear on later backups. I also have personally had problems with nasal infections >from working with contaminated material like this in the past, so I made the decision to discard them.

17 years, 1 month

PDP-11/84, PMI and Q-bus

by bqt＠softjar.se

Okay, since this topic have become a subject of much discussion and some diverse opinions, I decided to really read the manuals to try to find the bottom of this all. My main source of information here have been the "KDJ11-B CPU Module Users's Guide". EK-KDJ1B-UG-001 Now, to start with the position of the CPU card in an 11/84. Chapter 7, section 7.2. Page 7-1: "7.2 PMI INTERFACE The PMI interface signals are defined as the PMI bus master signals, the PMI slave signals and the PMI Unibus adapter signals. These interface signals are assigned to the C and D rows of the backplane and are defined as the interconnect bus. The PMI interface signals on the C/D bus are normally assigned two pins to provide an interconnection between the slots. The KDJ11-B module is only assigned one pin and therefore its position in the backplane is critical. The LSI bus signals that are used with the PMI protocol use the A and B rows of the backplane defined as the LSI bus." Now, if Pete is correct in that the PMI bus on the 11/84 really goes to both pins on all slots, then it should be okay to place the CPU in any slot. I haven't tried that, but I might when I have the time. I suspect he's right since otherwise I would have expected the CPU to be in slot 3. But DEC could be doing some fancy wiring... :-) The fact that the placement is critical is obvious if we talk about Q-bus systems, and I suspect the comment is written from that point of view. As for wether Q-bus memory (or any other Q-bus peripherial) will work, I'll quote some signal descriptions. Chapter 7, page 7-4. Table 7-3 PMI Unibus Adapter Signals "Pin: CF1 Mnemonic: PUBSYS L PMI Unibus System In a Unibus system, PUBSYS L is asserted by the UBA to direct the KDJ11-B to follow PMI protocol for all data transfers, wether the PSSEL L is asserted or not. LSI-11 bus protocol is disabled for all PMI devices when PUBSYS L is asserted. In an LSI-11 system, PUBSYS L is always negated. If PSSEL L is negated, the KDJ11-B follows LSI-11 protocol and the PMI memory then responds to the LSI-11 protocol by the LSI DMA devices." Chapter 7, page 7-5. Table 7-4 LSI Bus Signals "Pin: AF2 Mnemonic: BRPLY L Reply During PMI cycles, BRPLY L is asserted by the KDJ11-B and the PMI slave to prevent the next bus master from gaining control of the bus too soon. In a Unibus system, BRPLY L is asserted by the UBA as a slave response during the PMI DATOB cycle and interrupt DATI cycle. *** NOTE *** The PMI memory slave modules in a Unibus system must have BRPLY L disabled at all times. Pin: AH2 Mnemonic: BDIN L Data Input The BDIN L signal is only used in PMI Unibus systems during interrupt grant cycles. The KDJ11-B asserts BDIN L after it gates the interrupt priority, BDAL bits <3:0>, onto the bus. The UBA then latches the interrupt priority data using the leading edge of BDIN L. Pin: AM2 Mnemonic: BIAKI L Interrupt Acknowledge In Pin: AN2 Mnemonic: BIAKO L Interrupt Acknowledge Out These signals are only used in PMI Unibus systems during the interrupt grant cycles. The KDJ11-B asserts the BIAKI L signal, and the UBDA acknowledges it by asserting one of the Unibus bus grant signals. Pin: BB1 Mnemonic: BPOK H Power OK This signal is only used in PMI Unibus systems for the Unibus power-up/power-down protocol. This signal is asserted and negated by the UBA in response to the Unibus AC LO signal. The assertion of AC LO may be prolonged by the Unibus devices or the PMI memory during power-up." I could go on describing more details on how these signals are used, since it's all described in the manual. Suffice to day that the KDJ11-B *knows* when it's in a Unibus system (i.e 11/84) and will not behave like a normal Qbus. First of all, it will always use PMI protocol to access memory, no matter what the memory might claim. Second, interrupt handling is done differently, since all interrupts are expected to be dealt with via the UBA. There are also schematics for different signals in the manual, and you can clearly find the PUBSYS L signal included in some decoder path as a way to force a specific behaviour independent of other signals that might exist. Now, can we now accept that it's not a Q-bus in the 11/84? :-) 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

17 years, 1 month

CiTOH terminals (was Re: Well, now I've gone and done it... Dragged home more big(ish) iron...)

by RodSmallwood＠mail.ediconsulting.co.uk

Hi I have just remembered how the later version keyboards worked. It was still a counter sytem but the values where fully decoded. It worked on a matrix system. Each key on the keyboard sat across the junction of one of the matrix points. The columns, say 16. Would be the output of a 4 in 16 out decoder and the rows were the inputs of a say 16 in four out encoder. Stopping the clock by pressing a key gave you an 8 bit keycode. Serialize in the usual way. Finally dedicated chips appeared. But same old matrix system. Rod Smallwood -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] On Behalf Of Ethan Dicks Sent: 22 May 2007 13:58 To: General Discussion: On-Topic and Off-Topic Posts Subject: CiTOH terminals (was Re: Well,now I've gone and done it... Dragged home more big(ish) iron...) On 5/22/07, Mr Ian Primus <ian_primus at yahoo.com> wrote: > > > The 101 is the model shaped and colored much like a VT100. The > > keyboard looks similar... but its protocol is _not_ compatible with > > the VT100. > > Good thing I didn't buy the one on eBay a couple months ago. There was > a 101 there, and cheap too, but it had no keyboard. I may haev a few CiTOH terminals to drag to VCFmw if there's any interest. Closer to the event, I'll inventory what I have and see if I kept any spare keyboards "just in case", if anyone out there already has a terminal, but can't figure out why their VT100 keyboard doesn't work with it. I remember back in the day, since we had dozens of CiTOH and DEC terminals, looking over the available schematics for both and not being able to figure out how the keyboard works. I think it was a matter of inadequate/fuzzy docs more than anything else. Does anyone know of a good printset to pore over to see the nuts-and-bolts of a VT100-era keyboard? ISTR the crux of it was a 6402-type UART squeezing out the keystrokes at some slow baud rate, but I can't recall any essential details right now. I'm just curious if it's possible to swap a crystal or make a simple, switched change to allow one keyboard to work across both vendor's product lines. We used to have lots of dead keyboard when there was one or two terminals on everyone's desk. Since the company was shrinking at that stage, we never bothered fixing them - we just pulled one off a vacant desk and kept working. The number of working keyboards never shrank below the steadily decreasing size of the staff, so economically, it made sense. I think I only saved working keyboards in that set of 4 van loads, but it's entirely possible I picked up one or two dead ones. Right now, I have to search the pile for a VT100 keyboard to get my DECmate I back up and running so I can press it into service as an RX01/RX02 image archiver and finally whittle down my cartons of floppies. -ethan

17 years, 1 month

Well, now I've gone and done it... Dragged home more big(ish) iron...

by ian_primus＠yahoo.com

Eh... another in a series of things _not_ to put into a Chevy Venture, this time featuring... A Vax 11/750 and a Vax 6210. Fortunately, this isn't going to be as bad to remove >from the van as those CDC drives were. I just need to talk some friends into helping me. But, I do want to try and get this 750 running soon. The TU58 has a bad roller (suprise, suprise) so I'll have to get some of that tubing I saw mentioned in the archives. But, I have no cartridges, so it does me little good to fix it... Any source of boot images for this critter so I can boot it with a tu58 simulator on a PC? Also, what do I really need in order to boot and install an OS, say, NetBSD? At the moment, I have no disks (anyone have a Unibus SMD controller?), or for that matter, a working, compatible tape drive (no pertec controller...). I assume that the machine needs to boot initally from TU58 every time, and then after that, it can bootstrap from disk or tape. I found the 11/750 FAQ, but it doesn't have a section for "I dragged home a big heavy Vax, now what?". Thanks! -Ian

17 years, 1 month

Norsk Data for pickup in the Netherlands

by dr.emiel＠xs4all.nl

I'm getting a bit short on space. So for who wants it, a have a Norsk Data ND-110 compact including manuals an software (Sintran) with a Tandberg terminal. It's only for pickup or DIY-shipment I'm not packing or posting this one. Gr. Rik contact me at : dr.emiel at xs4all dot nl

17 years, 1 month

digest mode

by ygehrich＠yahoo.com

I followed the FAQ to set to digest mode and it does not work. I then changed the destination to list at classiccmp.org and that does not work how do I change to digest mode

17 years, 1 month

← Newer
1
...
15
16
17
18
19
20
21
...
49
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 May 2007