test-drb

test-drb@ccmp.vtda.org

101090 discussions

DEC equipment available, UK (Cheltenham)

by fryers＠gmail.com

All, I have a DECStation 5000/240 and a couple of Storage Expansion boxes I would like to pass on to someone with more time and space than I have. The equipment is currently in Cheltenham, UK. I do a fair bit of driving around the country so I *may* be able to deliver. Thanks. Simon -- ------------------------------------------------------------------------ "Well, an engineer is not concerned with the truth; that is left to philosophers and theologians: the prime concern of an engineer is the utility of the final product." Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh

15 years, 8 months

Fwd: [comp.sys.dec] Two PDP-11/03s available

by legalize＠xmission.com

This message has been forwarded from Usenet. To reply to the original author, use the email address from the forwarded message. Date: Sat, 31 Jul 2010 13:49:19 -0500 Groups: comp.sys.dec From: Jim Haynes <jhaynes at alumni.uark.edu> Reply: jhaynes at alumni.uark.edu Org: University of Arkansas Alumni Subject: Two PDP-11/03s available Id: <kc2dnZs2T-Sy7cnRnZ2dnUVZ_oadnZ2d at earthlink.com> ======== Free if picked up in Northwest Arkansas. These came out of VAX-11/780 systems, so have the 11-03 in its little box and the floppy drive in its awkward mounting and the terminator and boot ROM is on a big VAX board. jhhaynes at earthlink dot net

15 years, 8 months

IRQs and such (was Re: Serial interfaces)

by bqt＠softjar.se

"Brian L. Stuart" <blstuart at bellsouth.net> wrote: >> > There was/is a definitive schema for in which order vectors >> > should be assigned, but it is more or less not used since >> > all the OSes that atleast I have tried actually probe what >> > vector each card uses, and use that vector instead of having >> > some fixed scheme. >> > All that is required is that no two devices use the same >> > vector, because that would be bad. > > This is coming from 25 year old memories, but I seem > to recall there being some that didn't. Back in college > we had an 11/34 that we ran RSTS, RT-11 and 6th edition > UNIX on. IIRC we had to follow the scheme exactly for > all three to work. For one system, I seem to remember > telling it the addresses and it found the vectors. On > another, we told it the vectors and it found the addresses. > On the third, we told it both. We found this out when > we didn't follow the scheme for a 3rd party serial card, > and any deviation would break one or the other. The scheme as such is never needed for any of them. You need to decide somehow on how you want to assign CSRs, and then you need to set those switches or jumpers accordingly on each card. When you build, generate, or set up the system, you need to tell the system exactly which devices you have, and at which CSRs. For some systems, there is a program that can autoprobe and tell you what you have, but you don't have to use that, and once the configuration is done, you don't have to do it again. When the system boots, it uses the information that has been configured into the system previously. So, following DECs scheme can help you, but it is not neccesary to follow it. And for all systems, the CSR *must* be told somehow. Either you can let some auto-detection system do it if you follow the DEC scheme, or you have some config that sets it up. As far as I know, in RT-11 you have a SYSGEN that collects this, and then builds the device drivers with that information. (I think it can do a scan of the system according to the DEC scheme if you want it to.) RSTS/E also use a SYSGEN phase if I remember correctly, but my memory is a bit vague. I've never used Unix 6th ed., but in 2.11BSD you have a config file, which tells both the CSR and the vector. 2.11BSD does not have a mechanism for autodetecting the vector, unless my memory fails me, In RSX, you give all this information in the SYSGEN phase, but you can get default values to be suggested from running the autoconfig program that exist. But having just the vector and not the CSR isn't going to allow you to detect the CSR. From the CSR you can trick out the vector (and for some controllers even program the vector), but the other way just isn't possible. 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

15 years, 8 months

I am looking for a power supply of PDP11/44 for donation or to BUY. URGENT

by curador＠museudocomputador.com.br

Jose Carlos Valle curator of Computer Museum Brazil -- * Jos? Carlos Valle - * *S?MENTE PARA DOADORES:* Por favor, preencha o formulario e nos devolva. O recibo deixe junto com a doa??o. Temos v?rios postos em S?o Paulo, Rio de Janeiro etc. Encontre um posto perto de voce para entregar, se n?o, conseguir nos AVISE. via email: curador at museudocomputador.com.br Recolhemos s?mente as quartas feiras. Leia com aten??o o formul?rio. *PS: Assistam os links abaixo e divulguem para empresas, amigos/as. Aten??o: O Museu recolhe o lixo eletronico desde 1998. Quando ninguem pensava e manter o meio ambiente politicamente correto.* * OBS: O Museu do Computador ? uma ONG. * SIGA O MUSEU NO TWITTER: http://twitter.com/curadordomuseu Eventos do Museu assistam os videos http://www.orkut.com.br/Main#FavoriteVideos?uid=4556187644461453698&sm=add O Curador no Jornal Nacional. agosto 2009. Assista agora no link abaixo: http://www.youtube.com/watch?v=RJEIuMcYtzA O Curador no Antena Paulista: http://www.youtube.com/watch?v=wO_JFfNiGlE O atual Museu no SPTV maio 2010 http://video.globo.com/Videos/Player/Noticias/0,,GIM1268168-7823-MUSEU+DO+C… Museu na UOL: http://www.youtube.com/watch?v=_Yz0XtCox2g O Museu no Olhar Digital na Rede TV, maio 2010. http://www.youtube.com/watch?v=-yLggafyqkk NOVO LOCAL DO MUSEU DO COMPUTADOR. www.museudocomputador.com.br Rua dos andradas, 237 - Galeria Continental - lojas 507,508,509. CEP 1212-010 Telefone - (11) 4666-7545 - . Contato: Jos? Carlos Valle ? Curador E-mail: para agendamento e doa??o: curador at museudocomputador.com.br -

15 years, 8 months

Apple/Mac floppy questions

by brianlanning＠gmail.com

A couple questions... Are there any differences between the double density and high density auto inject floppy drives? That is, could I put a high density drive in an older classic mac and expect it to work? It would be nice to get a hold of three or so extra auto-inject floppy drives for some vintage macs. But they seem to be expensive and hard to find. I noticed that the external 3.5" floppy drives for the 2gs seem to be plentiful. Are they the same mechanism? brian

15 years, 8 months

retr0brite not so right?

by feedle＠feedle.net

I think people are kind-of forgetting something in this discussion: "value" is set by the people that are buying, and for every collectable there are probably different rules. We can look to the classic car collectors for guidance here. With some cars (say, like the Model T) there are still tons of old-stock parts out there, so for a Model T to have extraordinary value requires that it has all OEM parts. Contrast that to a Tucker, where even the OEM used weird parts on some cars given the prototype nature.. however, documentation is always key. An excellent contra-example is in cameras. You could have a pristeen in-the-box Polaroid camera and a barely working similar vintage TLR.. guess what's worth more? It isn't the Polaroid. The TLR likely still is a functional camera (film is available). Polaroid film by in large is not available. It is sensible to me that limited modification to maintain an operational state wouldn't affect the collectible value much, especially compared to "not working at all."

15 years, 8 months

Question on DG/Walkabout/One Sharp models

by bdamer＠digitalspace.com

Say does anyone on this list know if the Data General Walkabout was ever released to the public (ie used outside of DG corporation) and what year/month that would have been. The SX model was released but what year too? Also was the DG/One released in 1984 and what month then too? Lastly does anyone know when the Sharp MZ-200 was released? bruce

15 years, 8 months

IRQs and such (was Re: Serial interfaces)

by bqt＠update.uu.se

Charlie Carothers <csquared3 at tx.rr.com> wrote: > Johnny Billquist wrote: >> > Older cards usually use DIP-switches, while modern cards usually are >> > programmed. (And as others mentioned, it could also be jumpers, which works the same way as dip-switches, but might take some soldering to reconnect... :-) ) >> > Remember that you don't need the interrupt vector to talk with the card >> > in polled mode, so you can talk with the card, and set up stuff before >> > you allow it to start generating interrupts... >> > >> > What you drift into, Ethan, is then the question of deciding what >> > interrupt vector to actually set on the card. This is also an >> > interesting topic. >> > >> > Very few devices have more than one reserved vector. That is, if we talk >> > of one vector as assigned to one card. Some cards had more than one >> > vector because of the nature of the card, such as a terminal interface >> > which actually use two vectors. One vector for receiving characters, and >> > one vector for transmitting characters. I can only remember one device >> > where more than one set of vectors were reserved, and I think it ran to >> > eight for that one. I'd have to look in a processor book to check the >> > actual name of that device, though. >> > >> > For all other devices, vectors are allocated from the "floating" vector >> > space, which is everything from 300(8) to 774(8). >> > Each vector takes two words, the the lowest two bits of a vector is >> > always 0, and are usually not even available on the switch pack, or >> > register where you program the vector. > I'm guessing/assuming a "word" is 16-bits, so a vector is 32-bits in > all. (Snipped from my original question is my admission that I know > absolutely nothing about DEC gear.) Yes. A word is 16 bits on a PDP-11. The device presents a 16-bit vector on the bus when the interrupt is acknowledged by the CPU. This 16-bit vector from the device is then used to read the interrupt vector table in memory, where each entry consist of two 16-bit words. One is the new PC to be used, and the other is the new PSW. So, when a device fields an interrupt, and it get's processed, the current PC and PSW (processor status word, which holds condition codes, current interrupt level, and some other stuff) gets pushed on the stack, and a new PC and PSW is loaded, and the processor continues from there. Already running in the interrupt handler from instruction one. The reverse is the RETI or RETN instructions, which pops a PC and PSW >from the stack and puts them in the processor registers again. >> > For a device like a terminal interface, the next bit was also reserved, >> > since it was used to differentiate between transmit and receive, so two >> > vectors were programmed with one switch pack. >> > >> > There was/is a definitive schema for in which order vectors should be >> > assigned, but it is more or less not used since all the OSes that >> > atleast I have tried actually probe what vector each card uses, and use >> > that vector instead of having some fixed scheme. > I'm guessing again that you stimulate the card in some fashion, the card > generates an interrupt, and you check to see which interrupt was > received. I suppose if the card has no such facility you just have to > know from a configuration file or something. Correct. You set up a "fake" PC/PSW pair for all vectors, with some variation, which makes it possible to see in that interrupt handler exactly which vector that we got the interrupt through, and then we can change that vector to point to the correct interrupt handler. And we get the card to generate the interrupt so that we can do the whole detection thing. >> > All that is required is that no two devices use the same vector, because >> > that would be bad. > I imagine that would be *very* bad. :-( Indeed. I guess that in theory you could have an interrupt handler that then tried to figure out which device was generating the interrupt, but that kindof defeats the whole idea of having each device present a interrupt vector. >>> >> In practice, there weren't as many kinds of interfaces for the Unibus >>> >> as there ended up being for the ISA bus, so it may sound like anarchy, >>> >> but it wasn't. I think in 20-ish years of the hey-day of the Unibus, >>> >> they only ever reassigned CSR addresses once or twice, but it was >>> >> extremely unlikely that you'd have a particular obscure peripheral >>> >> from 1970, literally, on the same bus as a stack of c. 1990 disk >>> >> controllers and Ethernet interfaces. Electrically, they would work >>> >> together, but logically, a user would have no need to use 20-year-old >>> >> devices. The only "old" device we ever used on our VAX-11/750 was an >>> >> LP11, an original line-printer interface. The rest of the cards in >>> >> our machine were manufactured 10-15 years later. Some of our devices, >>> >> then, had a DIP switch for CSR assignment, but not for vector >>> >> assignment. Something older, like a PDP-11/34, was probably a >>> >> different story. >> > >> > No, it's just the same for any PDP-11, just as for VAXen with Unibuses. >> > >> > You *must* use dip-switches for CSRs, or possibly accept that it is at a >> > fixed address, which is a very bad idea. > That does indeed seem like a very bad idea. That would limit us to only having one controller of that type, ever, on that bus. Not a limitation some would be happy with. >> > Vectors are either set with DIP switches, or programmed into the card at >> > initialization time. >> > >> > But vectors are the simple part of the Unibus. The fact that it's easy >> > to autodetect the vector makes it even simpler. All you need to make >> > sure is that you don't have a conflict, and your vector issues are done. >> > >> > The interesting part of the Unibus is actually the CSRs. As the I/O >> > address page is only 8K, and some devices use quite a few registers in >> > that area, this is a short resource, so you cannot in general make a >> > permanent allocation in the I/O page for all possible combination of >> > devices you might have. > I assume that is 8K bytes, so only 4K CSRs. But maybe they are not all > words, I dunno. For all I know, some are 32 bits... No, that is correct. Since the PDP-11 access things as 8 or 16 bits, you could in theory have 8K registers. But registers are normally 16 bits, or atleast addressed on even addresses, which limits it to 4K registers. No registers are actually 32 bits, although most devices have more than one register, and some controllers actually combine registers to manage quantities larger than 16 bits (such as physical addresses, which can be 18 bits, or 22 bits, depending on system and controller). >> > So DEC designed a scheme for automatically detecting and configuring >> > devices on the Unibus. (Plug and play long before the PC saw the light >> > of day.) This do, however, require you to change the CSR address of >> > devices way more often than you might think. >> > >> > The general idea runs like this. For most of the common devices, *one* >> > CSR address is reserved. So, for the first device, you know which >> > address to set it to. Any additional devices of that type goes into the >> > floating address space. >> > >> > Each device additionally have a priority, size and modulo number. This >> > is all on paper. For autoconfiguration to work, you then start with the >> > highest priority device, and starts assigning CSRs to the devices you >> > actually have of that type. When you are done, you go on to the next >> > device, and repeat the exercise. Repeat until you've run through the >> > whole list of device types, and by then you will have the CSR address of >> > all the devices you have in your machine. >> > Now, if you add one additional device of some type, it will probably >> > affect the CSR address of all devices you have which have a lower >> > priority, moving them in the floating address space. The same is true if >> > you remove some device from the machine, which were located in the >> > floating address space. >> > >> > More specifically the algorithm goes like this. >> > (In pseudo-code, all numbers octal) >> > >> > CSR=160010 >> > DEV_PRIO=1 >> > >> > while (! end_of_devices_you_have) >> > CSR = round_up(CSR, device_modulo(DEV_PRIO)) >> > for (number_of_devices(DEV_PRIO)) do >> > this_device_csr = CSR >> > CSR = round_up(CSR+device_size(DEV_PRIO), device_modulo(DEV_PRIO)) >> > next >> > CSR += 2 >> > next >> > >> > >> > Worth pointing out: >> > Floating address space starts at 160010, and goes up. Preallocated CSR >> > addresses are usually very high up in this space, and were allocated >> > downwards. They "end" up somewhere around 174xxx space or so. I'm sure >> > someone could locate the lowest pre-allocated CSR address that DEC >> > assigned by looking in some processor book. > Hmmm. I get about 6KB decimal in all. I can see where you could run > out if you have many cards. Just thinking about a typical UART has 8 > each and ISTR a floppy controller has about that many too. About 6KB is left after the "reserved" addresses are accounted for, yes. But no, the typical serial interface on a PDP-11 uses two registers for transmit, and two registers for receive, although they are 16 bits. One for data, and one for control. And actually, when we talk about serial ports, we should remember that usually you had cards that controlled maybe 8 or 16 ports, using just maybe eight registers. The floppy controllers depend, but for the 8" floppy, which is the most primitive (thus using the most registers), it's still only like six registers or so. The modern floppy controllers use only two registers. >> > Between each device type, one CSR address is reserved. This means that >> > when you scan for devices, you'll run through one type at a time, and >> > stop when you hit an address where there is nothing responding. You then >> > go on to the next type. >> > It's important to understand that the space after this non-existant >> > address do not need to be the same size as that of the actual devices >> > for that prio. That would be wasteful of address space. Once you hit the >> > non-existant address, you start scanning for the next device type, using >> > the modulo of that device type instead. So if you have one device type >> > which uses 20 registers, and you don't have any of that type, you'll >> > only waste one register, plus the modulo of the next device type. >> > >> > Once all the CSRs have been figured out, the DEC official scheme for >> > vector allocation was basically to just allocate all vectors, starting >> > at 300, for all the devices you have, packed together as closely as >> > possible. No need for unused spaces, or anything else here. >> > >> > But this is all about the scheme for actually deciding what to use. The >> > actual method of getting the card to know this info was switchpacks, or >> > for vectors, programming a register. >> > >> > Johnny >> > > That's a lot of info. I think I'll save a copy in my DEC subfolder for > later reference. Feel free to ask if there is anything more you wonder about... :-) Johnny

15 years, 8 months

FPGA-Elf

by eric＠brouhaha.com

I finished my RetroChallenge entry with one day to spare. FPGA-Elf is the COSMAC Elf reimplemented using an FPGA with an 1802 soft core. Video of demo: http://www.youtube.com/watch?v=4IhDMDVBYio Blog entries: http://whats.all.this.brouhaha.com/category/computing/retrocomputing/retroc… RetroChallenge site: http://retrochallenge.net/ Thanks to Jim Donnelly, Richard Ottosen, and Jim Phillips for help assembling the front panel.

15 years, 8 months

N8VEM project with my son?

by tom.manos＠gmail.com

Hi, I'm about to embark on building a single board computer (an N8VEM) as a project with my 15yo son. My son is a typical gamer kid who spends most of his waking moments either in front of a computer playing WOW, or reading SF and fantasy. I'm trying to find something a bit more positive about technology for him to enjoy. The operative word is enjoy. Anyway, he's agreed to give it a shot, and I'm thinking through how to make this a great experience for him. I've got a fair amount of background (BSEE and MSCS), and understand the technology, at least theoretically, from bare silicon to flip flops, to computer block diagrams. I'm reasonably well versed in Z80 assembly language programming and the CP/M operating system, which is what the N8VEM runs. I've got the equipment (electronics soldering station, good DMM, logic probe, bench power supply, etc) and have access to an OScope if I need one. And I actually sort of remember how to use them :) My question for you folks is: At what level, and in what order should I try to teach some theory to my son? Should I do some background before we start soldering sockets and ICs to boards and wiring things up, or just jump right in to building? I've been thinking jump in and fill in the theory as I can as we go along. In the end we should have something that looks like an Altair with more modern HW: solid state drives, and maybe IDE, but still has a front panel and which runs traditional CP/M 2.2. I have lots of old software to run there, languages, editors, games, etc. Have any of you tried something like this with your children? Experiences and wisdom gratefully accepted! Cheers, Tom

15 years, 8 months

Jump to page:

2026

2025

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