Over the weekend while moving another project out of long term storage, I
also unpacked the Hawley Mark II mouse for my SGI IRIS 1400 since I wanted
to see what it might take to repair its cord.
When I originally acquired the machine, the outer insulation of the
mouse's cord was just beginning to crumble at the ends, but 10+ years
later, it has now become extremely brittle and is completely flaking off
the cable. The cable they used for the mouse is very small diameter [my
mouse has the same cord as this one:
http://www.oldmouse.com/mouse/hawley/X063Xvanilla.shtml] and I don't think
I would be able to find a multiconductor cable that small to replace it.
The individual conductors are still tightly twisted together along with a
fiber wrapping of some sort. Since the inner conductors appear to still be
intact, I'm considering using heatshrink tubing to replace the outer
insulation, but I'm not sure if this would be the best approach or not.
In addition, the main ball doesn't turn very well and the rollers/contacts
inside the mouse also don't move. I've not yet disassembled it any further
than just lifting off the outer cover since I'm not sure of how involved
of a project this thing is going to become. [I was initially hoping it
would be a minor project to repair the cord but it's starting to look like
repairing this mouse may be pretty involved.]
Has anyone else rebuilt one of these mice, and if so are there any gotchas
I need to be watching out for?
I have some Emulex SD590 drives which require a controller like the
DEC KDA50-Q (M7164+M7165) or KDA50-QA.
I found a KDA50-Q controller on eBay, but also discovered that the
KDA50-Q has a rather bad (show-stopper) bug that was fixed in later
revisions, detailed here:
http://deathrow.vistech.net/~cvisors/DEC94MDS/kda50dol.txt
>From that description I understand I need either revision D1 or D2 of
the M7164 module. What should I be looking for on the board that would
indicate it has had the FCO applied? is it an option to re-program the
6 PROMs that appear to be involved?
Alternatively, if anyone has the two board set (M7164 and M7165 joined
with the 40-pin and 50-pin cables) along with the cab-kit up for sale
I would be interested in discussing further.
thanks.
Ps Thanks Jay for getting cctalk back online, well done!
Long shot here but does anyone have a control board (or two) for an 8"
internal Mitsubishi M2896-63-02U either from a dead drive or as spare parts
they may want to part with? Thanks.
-Ali
Standard CD carriers/trays for Sun type CD drives... I have 11 of
them... no physical damage although some have mild plastic yellowing.
All appear functional/usable.
Free for shipping from 95006 (Haven't tried but I suspect they will all
fit a small flat rate box if you want the lot).
Steve
Sending again since the rebuild of the list probably lost the first post
(apologies if this is duplicate).
Thanks
Rob
From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com]
Sent: 02 November 2014 18:29
To: General Discussion: On-Topic and Off-Topic Posts (cctalk at classiccmp.org)
Subject: Comparison of Desoldering Stations
I need to buy a desoldering station and in my price range it seems I have
the choice of two:
Duratool (sold under several other brands too) D00672:
http://cpc.farnell.com/duratool/d00672/desoldering-station-uk-eu-plug/dp/SD0
1384
Aoyue 474A++:
http://www.amazon.co.uk/AOYUE-Aoyue-474A-Desoldering-Station/dp/B00FDOP2DI/
Has anyone tried both of these to give me an idea which is the better buy?
Thanks
Rob
Thanks for getting the list going again.
Probably not a big deal, but the 'Sender' header now has quotes around the
string 'cctalk' and required a slight tweak to my procmail rules.
Steve
--
For quite some time I have been pursuing an effort to repair a PDP-11/04
system and make it running under CAPS-11. I have had it successfully boot
>from the TU60 tape drive. The plan is now to attach a contemporary console
terminal to it. I happen to have a LA30P which looks suitable and would
make it a nice looking system.
I have documented the effort here:
http://www.datormuseum.se/computers/digital-equipment-corporation/pdp-11-04
The LA30 is now working fine but the problem is that I don't have the M7910
or M791 card that make up the LC11 Unibus option as this terminal was once
upon a time connected to a PDP-8/E instead.
Is there anyone that have a M7910 or M791 card who wants to sell or trade
it for something?
During the restoration process of the LA30 I found that it is using quite
uncommon paper. I needs 9-7/8 inch (250 mm) wide paper. Is there a source
for this kind of paper somewhere else than in the USA?
If there is no M791 or M7910 available I have to either make my own M791 or
make a serial / parallel converter to go into the LA30P (I guess that no
one has the M7389 and M7731 boards that make it a LA30S, or?).
When looking for more information on the LC11, there were limited amount
available on the net. I did find the LC11 Decwriter System Manuel (pages
4-2 and 4-3 was missing which is quite annoying) but not the LC11 Decwriter
System Engineering Drawings. Anyone knows an online source for that one?
/Mattis
> From: Mark J. Blair
> Where is the modified Unibus used? ... I tried to cram in every bus I
> could find using the same physical form factor, but if MUD is an
> especially niche application then maybe it doesn't need to be in there.
> From: David Riley fraveydank at gmail.com
> Typical Unibus peripherals are quad-width; those that are hex-width are
> *generally* only in it for the additional power .. There are certainly
> exceptions, but I don't know what they are.
> If someone is trying to build Unibus memory, they'll probably be
> interested in the modified Unibus pins. Otherwise, it's somewhat
> unlikely.
I'm on the road, and away from my documentation, but I definitely would not
call MUD 'niche' - it's pretty much the standard hex-height UNIBUS spec in
all the later UNIBUS backplanes.
Here's what I can recall: in the beginning, there were what were called
'Small Peripheral Controller' (SPC) slots, which took quad-high cards in the
C-F connectors. Older, simpler interfaces (think DL11, RX01/2 controllers,
etc) were quad cards which went in the C-F connectors of an SPC slot. (More
complicated interfaces, like the RK11, RP11, DH11 etc were entire custom
backplanes/system units - 4 slot for the RK11, larger for the DH11, IIRC.)
I forget what was in the top two connectors (A-B) of the old SPC slots (e.g.
on the early DD11s - the name of the early 4-slot backplane units). Of
course, in the 1 and 4 slots, the A and B connectors had 'standard UNIBUS' so
one could plug in either a jumper module to the next backplane (earlier M920,
later M9202 - once they started dealing with lumped loads), or a UNIBUS cable
(the big flat white one) to another system unit.
So then hex cards started to become common (and basically all later UNIBUS
interface cards are hex cards - from early ones like the DZ11 and RL11, to
the latest ones like the UDA50, DELUA, etc). Around then, the MUD spec came
in: in a MUD slot, the bottom 4 connectors (C-F) are still SPC (so you can
plug any quad SPC board into the C-D connectors of a MUD slot), but the top
two connectors (A-B) are subtly different.
I _think_ many (most?) hex boards are MUD only, but I would have to check on
that.
When I get back, I will check and see what the A-B connectors in an old SPC
slot are - and if any hex UNIBUS cards use that, instead of MUD. (Of course,
any hex card that _only_ uses SPC pins can go in either kind. I don't know if
there are any hex cards are like that - or perhaps many are, I just don't
know off the top of my head.)
> From: David Riley
> Qbus shares Unibus' defined +5v and GND pins and adds a few more
> dedicated grounds ... I'm honestly a little surprised they didn't make
> the power pins a little more broadly compatible (or at least less
> likely to cause damage) in general
Well, I can kinda-sorta understand the UNIBUS and QBUS not being safe from
each other. It's sort of 'intuitively obvious' that one shouldn't plug a card
>from one into the other. (And remember, the QBUS started out as almost all
dual-high cards, except the LSI-11 CPU card, another differentiation.)
But the Q/Q and Q/CD thing is, to me, at least, different - one has to
know there are two kinds of QBUS, and not to plug cards for one into
the other (except the many cards that can go both ways).
But now that I think about it, I guess there are sorta two kinds of UNIBUS
too - MUD and non-MUD. And I think I even recall someone damaging a card by
plugging a non-MUD card into a MUD slot (or vice versa, I don't recall the
details any more).
Noel
I have completed scanning the 33 issues I was given of "Inside
Solaris," a monthly newsletter for admins of the Solaris operating
system. This is just a small slice of the total run, which went from
1995 to ??. My scans cover all of 1999 and 2000 as well as parts of
1998 and 2001:
https://archive.org/details/insidesolaris
Enjoy!
- jht
Hi all
>http://www.vintage-computer.com/vcforum/entry.php?315-Cloning-a-PAL-HAL-%28…
Interesting.
I've been doing something similar as an on-and-off project since 2011
(more off than on). Wrote some code to apply vectors on my Expro,
read the output, didn't know about Minilog (thanks, Chuck), wrote
some really clunky code to do something similar.
I'm working on the MAC PALs which is kind of redundant since I have
Jecel's work archived.
My thinking is that a PAL with 8 registers has at maximum 256 states.
Therefore I should be able to apply a vector, clock the PAL 256
times, and that would give me all the states. Repeat for the other
1023 or whatever vectors.
But I recently got back into brewing beer so there's not much
happening on the PAL reverse engineering front.
W
Hi!
I recently acquired a Racal-Milgo MSD III Modem Sharing Device.
Although I doesn't own any modem, I'd like to know how to use such a
device. Could someone point me to a manual or something? :)
I also may possibly acquire another MSD - or whatever it is, i briefly saw it.
[Bummer that I have no space, i'd take a cash machine , too!]
--
Ola Hughson
The early 20/24 pin PALs had a security fuse to prevent unauthorized
duplication. I worked at Data I/O, the device programmer company, in the
1980s and figured out a way to determine the contents. I did a few
experiments to prove the concept but never created a complete package.
PAL programmers like the Data I/O LogicPak could apply test vectors to a PAL
and check the output state of each pin. For a purely combinatorial device
like a PAL16H8 you just need to apply all possible inputs and read the
outputs. This will create a large truth table in inputs and outputs that can
be minimized with PLD software like ABEL.
Registered devices like PAL 16R8 require the bank of registers to cycle
through all starting points with all inputs. Most of these devices supported
pre-load, the programmer could force the internal registers to a known
state. You could force a desired register state and inputs then apply the
clock. These early registered PALs had a tri-state output buffer controlled
by a dedicated pin so you could always read the register output. Later parts
had the output buffer controlled by an internal logic function.
I am sure that by now someone has developed a high speed tester that applies
every combination of inputs then minimized the output to generate a
programming file.
I have copies of the early DOS based ABEL software; it runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
Michael Holley
> From: David Riley
> Looking at the PMI pins in the KDJ11-B manual, it looks like there are
> signal lines on the D2 pins for the memory. That's a +12v pin for Qbus.
What I just cannot fathom is why they used D2! PMI is only like 14 signals or
so (plus normal QBUS signals like BDALxx), and there are heck of a lot more
than 14 available pins on the CD that _do not_ conflict with the normal QBUS
power, etc. (You lose xS1 and xB2, but the rest all look OK, although if you
want to stay away from +5 you lose a few more.)
Someone must have a bad case of brain fade, is all I can think.... But I'm
still pretty incredulous that nobody else caught it before it was too late.
Maybe it was deliberate - they hoped to increase sales through people burning
boards out, plugging them into the wrong backplanes? (Tongue 3/4 in
cheek... :-)
Noel
Yeah - I've heard a couple of stories myself, but personally have never had
a problem with customs. I've come back from Canada a couple of times with
hardware (rescued a Burroughs B80 one time even - now that was a vanload!)
and they have never once even opened the side door of the van to get a
better look, they just peer in through the driver's window a bit. I have
gotten the "What do you want with this junk" bit though.
Granted, it's been several years since I have been to Canada, but, I'm not
terribly worried. All I can hope is that they do the same, or, when
checking, will notice that Sun hardware was made in the US to begin with.
-Ian
> From: David Riley
>> But not all quad cards have removable grant jumpers - e.g. the BDV11
>> doesn't. (Not sure why it even _has_ grant jumpers, given that one
>> would usually make it the last card, especially since it has pull-ups
>> - but I guess it's in case one doesn't.)
> You can install it without the terminators
??? You'd have to desolder the terminator resistor packs (or do etch cuts),
no? It doesn't have any jumper/switch to disable them. (The Sigma backplane
has terminators in plug-in resistor packs, which can be removed.)
> From: Mark J. Blair
> Well, it turns out that I haven't added the C-D rows to the table
> because I don't have any good documentation about them yet.
The CD pinout is given in the 1980 Microcomputer Interfaces Handbook under
the H9273-A entry (the H9276-A is the same; I forget where I found that one);
here it is:
+5 CA2, DA2
Gnd CC2, CT1, DC2, DT1
nCx2 - n+1Cx1 for x = B, D-S, U-V (last two high amperage traces)
nDx2 - n+1Dx1 for x = B, D-S, U-V
nCA1 - n+1CC1
nDA1 - n+1DC1
nCT2 - n+1DT2
Jumper W2 connects 1CK1 - 1CL1
Jumper W3 connects 1DK1 - 1DL1
The jumpers are for when plugging a quad LSI-11 (the original) in; it needs
those, apparently.
Noel
(sorry for abusing the list, but due to the very nature of the problem I currently cannot contact Mr. Mouse directly and his directions for this case explicitly call for me to "contact [him] through
some other channel".)
Hello Mouse,
when trying to contact you about the Sun-3/4 stuff you were offering FTGH, I got back the following:
> "mouse at rodents-montreal.org":
> SMTP error from remote server in greeting:
> host: MX-4.rodents-montreal.org:
> This relaying host's domain is blocked for spamming me. See
> ftp.rodents-montreal.org:/mouse/misc/one-strike.txt for more.
Unless you're keeping some sort of whitelist for addresses on otherwise blacklisted servers (but if you did so, I'd think you'd be mentioning that and a way to get on there in the document you're referring to), your approach strikes me as a bit over the top. After all you're blocking accounts (and the people behind them) that never were responsible for any spam you may have got, without even giving a procedure to get through that ban (like including some keyword or a random one-time key in the Subject line). I will be off the 'net until the beginning of next week, but I hope we can work out a solution to that afterwards.
So long,
Arno
From: Al Kossow <aek at bitsavers.org>
>
>You would obviously only talk to one device at a time. PC would be at
128.0.0.16 on a
>private un-routable interface (which is why it's 128.0.0.x).
>
128.0.0.0/24 isn't unroutable. It's allocated to a company called "Jump
Management SRL" out of Romania (and it's in the BGP tables). Unroutables
are 10/8, 172.16/12 & 192.168/16 (per RFC1918).
KJ
Hi,
I just finished my KIM Uno project. It is a handheld KIM-I clone based on a miniature Arduino.
Some hard/software extensions make the KIM-1 clone into a pretty effective
6502 programmable calculator, with non-volatile memory to keep code
stored.
(just to make sure: this is a non-profit hobby project)
It costs just $10 in parts. For the next few weeks, I'll send
PCBs/kits at cost price to anyone who is interested. The PCB
gerbers and firmware will remain on my web site if anyone would like to
create the gadget afterwards.
The idea was that I like coding in 6502, but I never have much reason to do it. Small calculator-style programs might be the answer... The other idea being I needed a replacement for my real KIM-1, which died sadly.
Also, some of the best KIM-1 software I could find is built in to extra
KIM-1 ROMs. I had a lot of fun digging them up. So Microchess is there, and some vintage programming tools like
Wozniak's 505-byte disassembler, etc.
Here is the site:
http://obsolescence.wix.com/obsolescence#!kim-uno-summary/c1uuh
Regards,
Oscar.
Hi,
I am looking for a terminator card (2-wide) IBM p/n 5863806 used in the IBM
3340 or 3350.
It is normally located in the 01A gate (position A2-A3) of the end of string
unit.
This card is missing in a IBM 3340 which I want to connect to an IBM
System/3 model 15D.
Remark: this is not the IBM channel bus/tag terminator card.
See: http://www.ibmsystem3.nl/downloads/IBM3340.jpg
This IBM 3340 is located at the DDHF near Copenhagen, Denmark:
http://datamuseum.dk/foreningen/dansk-datamuseum/
Who can help me ?
Some detailed pictures of the IBM components used on this card are also very
welcome.
Regards Henk
Okay, I don't think there's any realistic chance I'm going to want all
this old Sun stuff I've been hanging onto; indeed, there's a decent
chance I'm never going to want _any_ of it. What chance there is is
mostly in case I want to run some VMEbus hardware (for example, I think
I have a relatively good VME A->D board somewhere).
So I've got a bunch of 9U VME Sun stuff looking for a new home. This
is all in Ottawa (Ontario, Canada). I might be convinced to ship, but
I would much prefer pickup; I have neither materials to pack this stuff
properly nor even the knowledge to tell what materials I would need.
I have three 9U VME machines. They worked last time I turned them on,
but that was long enough ago that I hesitate to recommend depending on
anything being in working condition. (How long? At least a decade,
maybe two. They have been stored indoors - in human living quarters,
not garages or warehouses or the like - for that time.) I also have
some twenty-plus 9U VME boards which are not in cardcages.
All part numbers here are ten-finger copies and thus may contain typos.
If you suspect I've made a mistake, I can doublecheck.
Machine 1:
501-1206 -3/2xx CPU
non-Sun RAM (size unknown)
empty slot
501-1102 8M RAM with HW patch, component side
empty slot
501-1451 32M RAM with HW patch, foil side
501-1045 in 9U-to-6U adapter (internal SCSI)
501-1058 GB graphics buffer [*]
501-1055 GP graphics processor [*]
501-1170 internal SCSI, 501-1236 in 9U-to-6U adapter [*]
501-1116 cg3 framebuffer
blank slot cover
The three boards marked [*] have the top lever broken off. The two
boards marked "HW patch" suffered physical damage to a component; in
each case, I soldered in a replacement, which worked as far as I could
tell. But they do require that the slot adjacent to them be empty - as
configured above, the empty slot between them satisfies this criterion
for both boards at once. I haven't inspected those patches to see
whether they still look in good shape, but, unless etch runs have torn
loose or some such, at worst they should need a little soldering. The
"internal SCSI" boards have no connectors on their back panels; they
appear to be designed to plug ribbon cables onto for use inside the
machine.
Machine 2:
501-1206 -3/2xx CPU
blank slot cover
501-1102 8M RAM
501-1102 8M RAM
blank slot cover
501-1254 32M RAM
501-1217 SCSI, DD-50 back-panel connector
blank slot cover
empty slot
501-1116 cg3 framebuffer
empty slot
empty slot
Machine 3 is not accessible enough for me to give an inventory of its
cardcage; I am convalescing from minor surgery at the moment and am not
supposed to do significant physical exertion yet, so inventorying that
one will have to wait a week or two, unless I can find help moving the
things on top of it. Fuzzy memory says it's a Sun-4/470, but I'm also
not sure I didn't empty it out of boards before my last move, so the
boards from it could be in the list below.
The boards not currently in any cardcages:
501-1164 -3/xxx CPU
501-1217 SCSI, DD-50 back-panel connector
501-1153 AUI Ethernet
501-1134 -3/110 CPU
non-Sun RAM, size unknown
501-1153 AUI Ethernet
501-1153 AUI Ethernet
non-Sun RAM, size unknown
501-1132 4M RAM
501-1333 32M RAM
501-1333 32M RAM
501-1217 SCSI, DD-50 back-panel connector
501-1217 SCSI, DD-50 back-panel connector
501-1203 16-channel ALM
501-1539 IPI disk interface
501-1381 -4/470 CPU
There are also a handful more which need special remark.
There are two 501-1584s. This board looks like an AUI Ethernet, but
when I look up the 501-1584 number, it is apparently combination SCSI
and Ethernet; I don't know whether the SCSI functionality is
accessible.
There is a board whose tag says it's a 501-1165, but that number
appears to be a VME/Multibus adapter; the markings and connectors on
the back panel make this out to be an ALM board.
There is a non-Sun board from ILLIMITE INC, of Rochester NY; I don't
know what it's for, except that its back panel doesn't give any hints,
reducing the list of plausible candidates.
There are two boards which have lost their plastic tags. I also have
two torn-off plastic tags, which likely but not certainly are from
those boards; they say 501-1381 and 501-1217. One of the boards is
SCSI, a 501-1236 in an adapter to 3U; that is probably the 501-1217.
The other is a CPU board. The ROMs are marked 525-1103 through
525-1106; combined with the other plastic tag (501-1381) and a brief
look over the board, I think this is probably another -4/470 CPU board.
I will be watching both my mailbox and the list for replies, but, given
email's unreliability these days, I recommend not counting on it. If
you have trouble getting through by email and you care to bother, I
should be reachable at +1 613 482 0910. (That number goes through a
VoI system I'm the primary geek behind, which puts me in enough control
of its behaviour that I don't mind posting it here - it's temporary
anyway; I'll take it down in at most a few months.)
I also have enough of the small Allen-wrench screws Sun used to hold
these boards into their cardcages that I can supply them for any boards
that don't have them.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
On 01-10-14 01:21, Bill Sudbrink wrote:
> Dennis Boone wrote:
> At that point, I'll probably just switch to a linux box, a couple of USB
> hubs and a bunch of USB<>serial dongles. Somebody has probably already
> written a generic POSIX terminal server program... if not, I can hack one
> up myself.
>
Then do yourself a favour and stay away from the el cheapo pl2303
clones. they *seem* to just work fine, but they tend to have all kind of
fuzzy defects, not apparent but after a longer period of time. ft232
cost more, but are very reliable
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
Just clearing out some more stuff, Ive got 5 HP t5735 Thin Clients
They are Sempron 2100mhz with 1GB RAM, 1GB ATA Flash
The best part with these is you can replace the 1GB DOM with a hard
drive and have yourself a really quiet low power linux box. Or just
put a 16GB USB stick in the internal USB port and install linux. I
run a system to provide PPP access to my Commodore Amiga, and run my
VT420 off of the same system. They have a real serial port. So the
possibilities are endless with these. Faster then an RPI
It has 8 USB Ports 6 on the outside 2 on the inside
Im asking $50 each shipped for them. They come with AC Adapter. The
Debian image and XPe image for these is on HP's website if you so choose
to download it.
Just back from a visit to RE-PC in Tukwila.... Tucked back in a corner
is a large box of original IBM floppy disks (both 8 and 5.25) for AS-400
with some docs in 3ring binders. Looks to be apps although there are
some sealed pkgs as well.... they want $40 for the box but
occasionally dicker.
Is this stuff potentially significant?
Steve
> From: Antonio Carlini
>> Does anyone know of a list of quad QBUS cards that work (or do not
>> work) in Q/CD backplanes
> There are lots and lots of Q-bus cards so it would be quite a long list.
Indeed; hence the "or do not work" in my original message - I realized that
that list was likely more manageable.
(Although one possible bug with the 'does not work' list is that one could get
a false positive failure...)
> From: David Riley
> Conversely, cards designed for the CD interconnect (RLV11 board sets,
> PMI memory, PMI CPUs) should NEVER, EVER be plugged into a Q/Q
> backplane.
Off-topic somewhat, but I wonder why DEC put PMI signals, etc on power pins
(I assume that's what zaps a PMI/etc card plugged into a Q/Q slot). Surely
there are enough pins which are bus lines, etc, which one could use? Yes, the
machine probably wouldn't work if one plugged such a card into a Q/Q slot,
but you wouldn't zap boards...
>> CB2 is tied to DB2, and the two feed (through a jumper which is
>> normally removed) special power (-5V) for a particular kind of EPROM
> -5v is an optional rail on Qbus, anyway.
Actually, I think AB2/BB2 are 'normally' -12V - although not all power
supplies provide the -12 - e.g. the BA11-N only does +5V and +12V.
> In general, as long as there are removable grant jumpers for the CD
> lanes
But not all quad cards have removable grant jumpers - e.g. the BDV11 doesn't.
(Not sure why it even _has_ grant jumpers, given that one would usually make
it the last card, especially since it has pull-ups - but I guess it's in case
one doesn't.)
Noel
>Noel Chiappa wrote:
>Does anyone know of a list of quad QBUS cards that work (or do not work) in
>Q/CD backplanes (other than the board pairs specifically designed to go in a
>Q/CD backplane, of course)? I tried Google, but either there is no such list,
>or my Google-fu is pretty weak.
>
>For instance, I'm looking at a BDV11, and it has the usual grant jumpers on
>CM2-CN2 and CR2-CS2, but I don't think those will be a problem (provided there
>is no quad board immediately next to it). Similarly, CB2 is tied to DB2, and
>the two feed (through a jumper which is normally removed) special power (-5V)
>for a particular kind of EPROM; but again, I don't think this will be a
>problem (again, if blank neighbour slot).
>
>But I'd rather not have to go through that exercise for every quad card; it
>would be nice if there's a table which just says which ones are OK. (I did
>find mention, in the 1980 Interfaces Handbook, in the BA11-N entry, that
>MMV11-A modules will _not_ work in a Q/CD backplane, which _implies_ that
>all the rest are OK, but...)
>
I don't have a list, but there is at least one example of "do not work" for
the RL01 / RL02 Qbus controller which uses a 2 board set and supports
ONLY 18-bit. The M8013 / M8014 requires that BOTH boards be
(probably adjacent) in two quad Q / CD slots. Placing the boards into
a Q / Q backplane will release the magic smoke.
While not a good example, in a BA23 box, place the CPU board in the
first slot with the M8013 / M8014 in the second and third slots. The
non-PMI memory and the other boards will then occupy the other 5 slots.
PROBABLY (as mentioned in other posts), the Qbus PMI memory must
also be used in a Q / CD backplane AND in this case placed above the
CPU board, in this case an M8190. On the other hand, if the PMI memory
is placed below the CPU board (but still in a Q / CD slot), then the memory
will still function correctly, but NOT as PMI memory.
Contrary to what is stated elsewhere, the M8190 boards which support
the use of PMI memory work (as far as I understand - I have done so on
a VT103 which uses a Q / Q backplane) with either type of backplane,
although obviously with the Q / Q backplane, NEVER use PMI memory
in the first place.
Jerome Fine
Cisco 2600 with an 8-port sync/async serial card would make a nice
replacement and they're pretty easy on the wallet these days. You might
spend as much cabling it as you did for the unit when it's all said and
done? C2500s lingered on in this role for some time as well, though they're
quite a bit slower than the 2600. Or an old Portmaster, those things are
dirt cheap now.
It's always annoying when you get in a situation like this; I had a very
contemporary ATEN IPKVM at work that would get stuck in a reboot loop the
minute I plugged it into a specific VLAN full of traffic. Never could get
them to fix it...
Best,
Sean
On Tue, Sep 30, 2014 at 7:24 PM, Bill Sudbrink <wh.sudbrink at verizon.net>
wrote:
> Richard wrote:
> > Or maybe customize the WRT software installed on the router?
>
> Yes, I was thinking about that too. There's a guy called "Merlin"
> who customizes it. I have not exactly identified the offending
> traffic. I'm not sure what I would lose if various "subsystems"
> in the router were disabled.
>
> > Isn't WRT open source?
>
> Yes.
>
> Bill S.
>
>
> This new router seems to broadcast a number of packet types that the
> IP stack on the Annex was not designed to handle. The buffers
> containing these packets appear to be leaked and the memory loss
> eventually causes the Annex to hang hard. This happens about every
> 40 hours. A power cycle will bring it back. A bit of googling seems
> to indicate that I am running the latest official firmware (from
> 1995?). I can't seem to find any web discussion of the Annex more
> recent than 2004. I wondered whether anyone here might know of some
> trick or some small remaining community of users of the Annex. I
> know that it has something to do with traffic from the new router
> because if I isolate it on a subnet by itself it still runs fine with
> no memory loss.
Nortel discontinued the line about then, if memory serves. You might
try asking Doug Jones <dcjones at netdesc.com>. He was providing some
support for Annexen after Nortel quit.
Honestly, the easiest thing to do is probably to throw one of the small
board computers at being a packet filter, though.
What model do you have?
De
I still use annex terminal servers too, but haven't seen your problem, nor
do I know of solutions. Was buying them well into 2001. I think bay
networks bought out xylogics. maybe they have a newer firmware?
On Tue, Sep 30, 2014 at 4:53 PM, Bill Sudbrink <wh.sudbrink at verizon.net>
wrote:
> Hi all,
>
> I have the above mentioned device and have been using it
> for a number of years to access the console ports on several
> of my vintage computers. It also communicates with the
> serial ports on a couple of older UPSs that I still have in
> service. It has worked flawlessly up until a couple of
> months ago. At that time, I replaced my old primary router
> with a new one. This new router is an ASUS and runs an ASUS
> specific version of WRT. This new router seems to broadcast
> a number of packet types that the IP stack on the Annex was
> not designed to handle. The buffers containing these packets
> appear to be leaked and the memory loss eventually causes the
> Annex to hang hard. This happens about every 40 hours. A
> power cycle will bring it back. A bit of googling seems to
> indicate that I am running the latest official firmware (from
> 1995?). I can't seem to find any web discussion of the Annex
> more recent than 2004. I wondered whether anyone here might
> know of some trick or some small remaining community of users
> of the Annex. I know that it has something to do with traffic
> from the new router because if I isolate it on a subnet by
> itself it still runs fine with no memory loss.
>
> Thanks,
> Bill S.
>
>
On Tue, 30 Sep 2014, Bill Sudbrink wrote:
> Hi all,
>
> I have the above mentioned device and have been using it
> for a number of years to access the console ports on several
> of my vintage computers. It also communicates with the
> serial ports on a couple of older UPSs that I still have in
> service. It has worked flawlessly up until a couple of
> months ago. At that time, I replaced my old primary router
> with a new one. This new router is an ASUS and runs an ASUS
> specific version of WRT. This new router seems to broadcast
> a number of packet types that the IP stack on the Annex was
> not designed to handle. The buffers containing these packets
> appear to be leaked and the memory loss eventually causes the
> Annex to hang hard. This happens about every 40 hours. A
> power cycle will bring it back. A bit of googling seems to
> indicate that I am running the latest official firmware (from
> 1995?). I can't seem to find any web discussion of the Annex
> more recent than 2004. I wondered whether anyone here might
> know of some trick or some small remaining community of users
> of the Annex. I know that it has something to do with traffic
> from the new router because if I isolate it on a subnet by
> itself it still runs fine with no memory loss.
>
Oooooh. Annex! I have no familiarity with those, need to learn 'em for
my pet project.
> Thanks,
> Bill S.
>
>
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Hi all,
I have the above mentioned device and have been using it
for a number of years to access the console ports on several
of my vintage computers. It also communicates with the
serial ports on a couple of older UPSs that I still have in
service. It has worked flawlessly up until a couple of
months ago. At that time, I replaced my old primary router
with a new one. This new router is an ASUS and runs an ASUS
specific version of WRT. This new router seems to broadcast
a number of packet types that the IP stack on the Annex was
not designed to handle. The buffers containing these packets
appear to be leaked and the memory loss eventually causes the
Annex to hang hard. This happens about every 40 hours. A
power cycle will bring it back. A bit of googling seems to
indicate that I am running the latest official firmware (from
1995?). I can't seem to find any web discussion of the Annex
more recent than 2004. I wondered whether anyone here might
know of some trick or some small remaining community of users
of the Annex. I know that it has something to do with traffic
>from the new router because if I isolate it on a subnet by
itself it still runs fine with no memory loss.
Thanks,
Bill S.
Does anyone know of a list of quad QBUS cards that work (or do not work) in
Q/CD backplanes (other than the board pairs specifically designed to go in a
Q/CD backplane, of course)? I tried Google, but either there is no such list,
or my Google-fu is pretty weak.
For instance, I'm looking at a BDV11, and it has the usual grant jumpers on
CM2-CN2 and CR2-CS2, but I don't think those will be a problem (provided there
is no quad board immediately next to it). Similarly, CB2 is tied to DB2, and
the two feed (through a jumper which is normally removed) special power (-5V)
for a particular kind of EPROM; but again, I don't think this will be a
problem (again, if blank neighbour slot).
But I'd rather not have to go through that exercise for every quad card; it
would be nice if there's a table which just says which ones are OK. (I did
find mention, in the 1980 Interfaces Handbook, in the BA11-N entry, that
MMV11-A modules will _not_ work in a Q/CD backplane, which _implies_ that
all the rest are OK, but...)
Noel
The problem with the IBM1620 is that it has extra bits in the characters that can't be used to store data. This mean that implementing the "C" language in way which allows it to perform meaningful work possibly on existing data would be challenging. I can't see any point in implementing any language just to show it can be done...
Dave
G4UGM
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Eric Smith
Sent: 30 September 2014 08:51
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Who is the world's oldest working programmer?
On Mon, Sep 29, 2014 at 7:06 PM, Sean Conner <spc at conman.org> wrote:
> Going back to K&R ... um ... maybe? Perhaps? Can you address a
> single BCD digit? If not, it may make char * a bit hard to support ...
Actually, if you *can* address a single BCD digit, that will make C hard to support, because C requires that all data types have sizes of a multiple of the size of the character type, and the character type is required to have a range of at least -127 to +127 (for signed char) or 0 to 255 for unsigned char. It would seem that the easiest way to do that on a BCD machine would be to use groups of three digits (or
more) as a char, and have a lot of the possible machine values of those groups be illegal.
This is essentially the same reason that a compliant C on a PDP-10 would have to use 9, 12, 18, or 36 bit characters, and not directly support the normal PDP-10 native 6-bit and 7-bit characters.
> From: Sean Caron
> I'd at least grab the boards out of it, if you could.
I cringed when I read this! I find so many boards available for old PDP11's -
but without the cables, cabinet plates, etc which make them usable. E.g.
there's currently a seller on eBay who has an RK11 board set - but without the
custom backplane, they are useful only as spares for an existing RK11.
Grabbing the boards is better than recycling the whole works, I concede; but
such boards are effectively sentenced to being spares for an existing unit:
they will almost certainly never again function as a working unit.
So I think it is a desperate move to save only boards - one really ought to
try and save the rest if one possibly can. (I know, in this case that happened;
I was just commenting on the general concept.)
Noel
Thanks to everyone who responded. (And for the pointer to the BA11-N prints;
I had that print set, just hadn't look all the way through it! Although I still
hope a copy of the Tech Manual shows up some day.)
> From: Pete Turnbull
> For each BDAL line I used a suitable length of wire-wrap wire to run
> the length of the bus plus an allowance to wind once round each pin. I
> stripped somewhat over an inch of of insulation from the end, then used
> the stripper to separate the remaining insulation everywhere it would
> solder to a pin. Soldered one end, wind once round every succeeding
> pin, and soldered each.
Thanks for that tip - I had been planning on using separate lengths, but one
piece made a lot more sense. (Although I used wire from a 25-pair telephone
cable - I like working with that, it takes solder very easily, which not all
wire wrap wire will.)
Noel
Just wondering if anyone has (or can point me to) any technical information
about Mayflower's MFE 750 and MFE 751 8 inch floppy drives.
I have one of each of these drives, and am looking for information about the
configurations settings etc.
Regards, Malcolm.
> I have verified that the CD part of the backplane is identical in both
(the
> 1983-84 Microcomputer Interfaces Handbook, EB-23144-18, has pinouts for
> the CD
> part for both, and they are indeed identical). Alas, I cannot find
detailed
> data on the rest of the H9273-A: neither the BA11-N Technical Manual, nor
> the
> Print Set, is available online. (I found some old list email which
> indicates
> that someone named David Powell had a copy of the TM - does anyone know
> him?)
>
> Noel
>
Hi Noel, there are H9273/H9273A PCB layouts and wiring diagrams at pages
41-51 of the "PDP11/23 Field Maintenance Print Set". A Google search for
"MP00740_1123_schem_Oct81" will bring it up on Bitsavers.
Malcolm
Hi
I am a model railroader (in HO scale) and use a digital controller from
the 1980s. The controller is a Hornby UK, Zero 1. This device is based
around the TMS1000NLP and has been excellent value over 30 years. The
only small improvement I would like to make is to increase the number of
locomotive addresses to above the current limit of 16. (because of4-bit
chip).
The TMS1000 has a masked program (MP0186) and the ram can be dumped in 2
ways, by removing physically the top of the chip and photographing etc.
The second option is dumping code via the test mode, as mentioned in TI
literature.
I would like to be able to discuss with someone about instructions to
use the Test Mode etc. Also I would like to locate a list of the TI
TMS1000 programs MP**** (incl the MP0186 above)
Dave Caroline was good enough to direct me to this mailing list.
Thankyou
Charles Harris
NZ
Hi all --
The CPU in the 11/05 seems to be behaving nicely as far as I can tell,
now that the Microcode ROMs are no longer filled with bogus data. It
will run small programs I've toggled in without issue, and so I've moved
on to testing the memory.
Basic testing (via the simple address test listed here:
http://www.psych.usyd.edu.au/pdp-11/hints.html) reveals that most of the
8KW of core (H215) and controller is working pretty well, except for a
128 byte range between 012000(8) and 012200(8). Within this range, all
words read back as all zeros regardless of what is written.
Given the nature of the fault, I tend to think that this is not an
addressing problem or an issue with the core drivers -- if it was any of
these I'd expect the fault to repeat across the memory space in a
pattern, rather than being isolated to a single contiguous block of
memory. If that's true, then it seems that the core plane itself might
be at fault. Which doesn't surprise me, I'm actually surprised it works
at all -- when the /05 arrived the H215 core memory board was loose,
banging around inside the chassis.
Does my initial analysis seem reasonable? Anyone have any experience
debugging one of these and have any tips to share?
Thanks,
Josh
On Thu Jun 19 10:28:44 CDT 2014, Zane Healy <healyzh at aracnet.com> wrote:
>On Jun 19, 2014, at 8:14 AM, Glen Slick <glen.slick at gmail.com> wrote:
>
>> On Thu, Jun 19, 2014 at 7:53 AM, Zane Healy <healyzh at aracnet.com>
wrote:
>>>
>>> Yes, yes, and yes. I did this 15+ years ago, you're making me feel
old. :-(
>>>
>>> You need the following:
>>> 1. A high enough version of the EPROM
>>> 2. A PAL Fuse Map for burning a PAL that will allow the board to act as
a QDT controller (Disk and Tape)
>>> 3. A special cable that allows you to connect a Serial Terminal
>>> 4. Instructions on how to get into the hidden menu to configure the
board
>>>
>>> I should have #4, but I have no clue as to where it is. The person I
knew that had #2 lost that data in a fire years ago. I seem to recall
hearing about someone jury-rigging #3, I used the pr\
oper cable and bulkhead plate.
>>>
>>
>> If you burned your own PAL yourself and you didn't secure the PAL (or
>> does a PAL16L8 even have a security fuse?) then even if the known PAL
>> Fuse Map was lost I would assume that it could just be read back from
>> the PALs on the boards you have, along with dumping the firmware
>> EPROMs as well.
>>
>> -Glen
>
>The person that burned the PAL's is the person that had the fire.
>
>Zane
I have had some progress in this matter:
I got a reply to the letter I sent to folks at tdsys.com. The gentleman had
forwarded to the designer of the Viking series of adapter boards and to the
lady that was working with configuration of products. He had not yet go a
reply from them.
I also checked how the address decoding PAL is connected and I now
understand that it has two outputs, connected to another PAL chip and then
16 inputs. These 16 inputs are the 4 jumpers and also BDAL02-BDAL12 and
also the BBS7 signal. Looks quite reasonable being an address decoding
chip. I more or less presume that the reason for two outputs is that one is
for disk and one is for tape. I have to verify that by reverse engineer the
actual content of the PAL using a small arduino board.
You mention that there is a special way of accessing the configuration
menu. It make sense since when I examine the board more carefully I
discover a small serial EEPROM that might be used for storing the
configuration. It would be really interesting to get more info about how to
access this secret menu! Anyone else out there that knows about this?
I have the cab kit for it. It has a DB25 connector as well as a 50 pin male
IDC connector. But there is also pads for a 10 pin connector that seems to
be for the second serial port. What is the use for this second serial port?
The board has a Signetics SCN2681 DUART chip so it definitely has two
serial ports.
Regarding versions of the firmware. My firmware is 4.0 :
https://dl.dropboxusercontent.com/u/96935524/Datormusuem/Viking_Q_B_A4.0.bin
Zane, Pontus: What is your version?
Mattis Lind
> From: Jay West
> Ensure that if you ever no longer wish to keep the machine that it
> winds up in the hands of another collector
This all seems eminently reasonable, but I had one question/clarification,
about the above: what about museums?
In other collecting fields I am aware of (Asian art, old racing cars, steam
locomotives) there are a range of opinions about giving things to museums. (I
personally don't have any strong feelings / axes to grind either way on these
issues, merely raise them as I know there is debate on them in other field.)
One issue with museums is that a lot of their holdings are stored out of
sight, never to be seen by the ordinary public, and in that case, they might
as well be with a collector who can enjoy them, and show them.
The other issue (only with the cars and locos) is that some museums have a
strict 'conserve it exactly as it was' policy, and since these things were
intended to be _used_, an old race car/loco that's been 'stuffed and mounted
on a plinth' (as the phrase goes in loco preservation) is akin to a zoo full
of stuffed and mounted animals.
Yes, using them can cause them to wear out (although there are rare counter-
examples - John Harrison's sea-going clocks H1 through H3 are allowed to run,
as their bearings, etc are thought to have indefinite life-times - which is
not the case with H4, his first chronometer, which is displayed stopped), and
also, to get one running may require replacement of some parts (although one
can always save the old parts, for historical purposes).
Like I said, I can see both sides - just wondered what the feeling was about
this.
Noel
Hi all --
I have the opportunity to pick up a Ridge 32/330, which looks like a pretty
interesting 32-bit server/workstation from the mid-80s. It looks seriously
cool, but I'm a bit hesitant to jump on it since it's a pretty large
machine (well, relatively speaking...) that I haven't been able to find
much information about. I have a few *other* interesting machines that are
basically doorstops due to lack of media and documentation, I'm not sure I
need another to add to that category :).
What say you, O Internet Collective?
Thanks,
Josh
> From: David Riley
> I think most if not all Qbus backplanes were PCBs. But some of them
> (notably the H9270) are PCBs with wire-wrap posts for the connector
> terminals. Makes it very handy to, say, modify the H9270 for 22-bit,
> which I did .. with no problem.
This reminds me of something I'm looking into. I have a BA11-N (Q18/CD) which
I'd like to upgrade to BA11-S (Q22/CD). (Yes, yes, I know, the -S has a
oomphier power supply, which I won't have, but I'm not trying to run a lot of
power-hungry cards.)
I've tried finding an H9276-A backplane (Q22/CD) to go in it, to replace its
existing H9273-A (Q18/CD), but _every_ place I called which had one listed
reasonably cheap (<$100), and which claimed their internal stock database
(i.e. not just their lame, useless, Web-site) showed they had one... when they
checked the actual shelf, they did not in fact have any.
So now I'm thinking, maybe I'll just add the BDAL19-22 lines to the existing
H9273-A. It doesn't have wirewrap pins, but there's enough pin showing that I
can get two wires onto each pin, and solder them; does not look to be
difficult at all.
I have verified that the CD part of the backplane is identical in both (the
1983-84 Microcomputer Interfaces Handbook, EB-23144-18, has pinouts for the CD
part for both, and they are indeed identical). Alas, I cannot find detailed
data on the rest of the H9273-A: neither the BA11-N Technical Manual, nor the
Print Set, is available online. (I found some old list email which indicates
that someone named David Powell had a copy of the TM - does anyone know him?)
So, has anyone tried to upgrade an H9273-A to H9276-A, and are there any
pitfalls? From what I can see, there shouldn't be a problem, but I'd like
to be 100% sure before I start plugging cards into it...
Noel
It was recently pointed out to me that my DECwriter II (LA36) has
holes drilled on the bottom of the stand to accept pads or casters.
Does anyone know the measurement and thread size of those holes? I'm
willing to use DIY-store parts to make these beasts mobile. No
DEC-original parts needed.
The DECwriter III (LA120) also appears to have the same holes. Are
they the same size as the LA36's?
Worst case, they can go on furniture dollies, but I'd like to try
doing it "right" first.
TIA
- jht