> It includes a table which says which chip each bit in the memory is
> stored in
Oh, there's an entry (well, actually two) missing from the table, which is the
parity bits (2; byte parity); I'll work them out and add them. (I know, by
elimination, which two columns of chips are the parity bits; I just don't know
which is for the high byte, and which for the low.)
The flippping documentation doesn't say whether it's even or odd parity,
though! I'm assuming odd (which seems to be the usual: probably so that
totally failed memory - all 0's - generates an error), but now that I think
about it, it should be pretty easy to work out. I'll just store a '0' word,
and looking at either parity bit should give me whether it's using even/odd;
storing '-1' should confirm.
Then I can do byte writes to work out which chips the high/low parity bits
I'm assuming the DEC memory diagnostics (for people using them, not their own)
will call out parity failures, and high/low, so people will know which chips
Not exactly the same thing, but I've run several different versions of
NetBSD on both a real 3900 and on SIMH. I have not tried current, but I
have tried the 3 series, the 4 series and the 5 series - all seem to
work well. In this context, "well" is defined as (in order of decreasing
The ability to run colossal cave adventure (the 350 point version)
The ability to boot into multi-user
The ability to TELNET to remote hosts, e.g., oath.com
The ability to TELNET to local hosts
The ability to run "vi"
The ability to compile/link/run "hello.c"
I have not tried to recompile the kernel
I have not tried to compile other more obscure/exotic, but less useful
operating systems like emacs
The only problem I've come across is that the hash function on passwords is
VERY slow on the new versions of netbsd (> the 3 series).
So, a while back someone had a broken MSV11-Q QBUS memory card, and needed
info on them. I said I'd provide same, but then got distracted. Well, I
finally got to it, and it's been added to the CHW page for them:
It includes a table which says which chip each bit in the memory is stored
in (which is what one needs to fix one which is basically working, but has
some bad bits).
While working out that table, I ran into a hitch, which is a good part of why
it took so long. The hitch, when solved, revealed something mildly interesting.
The hitch was in my process for finding out which bit was stored in which chip.
I whipped up a simple loop to store a word with a single '1' bit, and the
rest 0's; I set that running, and used a 'scope probe on the DIn pins to find
out which column of chips held bit 0, etc. So far, so good. I then looked on the
-Wr pin, to find out which row of chips held which banks.
Not so good! There were pulses on -Wr for _all_ the banks, no matter which
address I tried to write to.
Eventually I worked out what was going on: when writing data, the MSV11-Q
sends a 'write' signal to _all_ the banks, and selects the one to _actually_
use by use of the RAS signal. I'm not certain why DEC did this, but since
there is no explicit 'read' signal on the DRAM chip, and likely the data
outputs from all the banks are wire-OR'd together, use of RAS to select the
desired bank works for read, and also for write.
Has anyone else seen this trick used anywhere else?
This is probably a long-shot, but does anyone have any advice for testing the End-of-Tape sensor on a QIC drive?
I've recently restored a Wangtek 5125ES (well, "restored" is a bit strong, I just replaced the capstan roller) and after about 5 tape passes, it completely lost its End-of-Tape sensor. I'm not entirely sure whether or not it's producing IR, pr of the sensors are dirty, or what.
web at loomcom.com
I am helping a guy with a dead IBM 3279 terminal
The PSU does not seem to work. But as usual it is impossible to find any
schematic online for IBM stuff. Just interconnection diagram and high level
Now the PSU circuit seems to be quite simple with just one IC in it. A chip
>From the look of mold I guess that the manufacturer is Texas Instruments.
At least it matches very well with other TI chips manufactured in the same
The rest is looking like a quite simple flyback mode PSU: A transformer
with air gaps, no output filter inductors and one single power transistor.
Is there a cross reference list available for IBM numbers to standard chips?
It shouldn't be that hard to figure from the how it connected, though,
since it is most likely a standard chip. It can be a TL494 or SG3524
I've successfully managed to get a simulated TOPS20 environment going with
networking. Now there's a new strange hitch: the behavior of make. Would
someone please look at this and tell me what I'm doing wrong?
For a simple Makefile, it works fine if I just type "make", but if I type
"make <target>", I get the commands sent to the command line, but no
responses. The display then stalls at the eighth source file. Strangely,
if I scroll up in the xterm, it gets dragged back down as if more stuff is
Just typing "make", I get this:
cc -c buffer.c -o buffer.rel
PANDA TOPS-20 Command processor 7.1(4453)-4
@cc -c buffer.c -o buffer.rel
... and so on until this:
cc -o dfrotz.exe buffer.rel err.rel fastme.rel files.rel getopt.rel
... more .rel files
and we're done. dfrotz.exe is in the current directory and it works.
Here's the strange behavior I can't explain:
cc -c buffer.c -o buffer.rel
?Unrecognized command - Does not match switch or keyword - "dumb"
cc -c err.c -o err.rel
cc -c fastme.c -o fastme.rel
cc -c files.c -o files.rel
cc -c getopt.c -o getopt.rel
cc -c hotkey.c -o hotkey.rel
cc -c input.c -o input.rel
cc -c main.c -o main.rel
The process stalls at this point, jerking back the terminal to the bottom
if I scroll up. Hitting ^C once or repeatedly doesn't seem to do
anything. Logging into the from a different terminal, I can see that no
.rel files were generated from this operation.
Typing "make foobar" results in this:
?MAKE: Don't know how to make foobar
perror() says: No such file or directory
Amusingly, "make love" returns this classic reply:
?MAKE: Don't know how to make love
perror() says: No such file or directory
Here's the Makefile:
CC = cc
NAME = frotz
C = .c
O = .rel
E = .exe
DFROTZ = d$(NAME)$(E)
OBJ = buffer$(O) err$(O) fastme$(O) files$(O) getopt$(O) hotkey$(O) \
input$(O) main$(O) math$(O) missin$(O) object$(O) \
proces$(O) quetza$(O) random$(O) redire$(O) screen$(O) \
sound$(O) stream$(O) table$(O) text$(O) variab$(O) \
dblorb$(O) dinit$(O) dinput$(O) doutpu$(O) dpic$(O)
$(CC) $(CFLAGS) -o $(DFROTZ) $(OBJ)
$(CC) $(CFLAGS) -c $< -o $@
.SUFFIXES: .exe .rel .c *.h
This whole thing can be found at https://gitlab.com/DavidGriffith/frotz/
in the tops20 branch.
dave at 661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing in e-mail?
I thought that I had sent a message to the list a few months ago showing the procedure to use the software DDCMP driver in RSTS V10.1. That's a standard feature, but undocumented and probably unsupported. It works well and interoperates with PyDECnet and with the DDCMP implementation in SIMH. Presumably it will talk to the software DDCMP in RSX, though I have not tried that.
Attached are the instructions and the program mentioned.
A small group of volunteers are working on restoring JOSS-II, the PDP-6
version, to a working state. We are typing in a program listing
provided by the RAND corporation. The listing is the supervisor, which
is a large part of the system. So far good news.
The bad news is that it's not a complete system. The Computer History
Museum seems to have additional program listings here:
But they have not been scanned. They archvists are willing to let us
see the collection, but no one of us lives near the museum. Is there
anyone interested in this kind of thing that are willing to help out?
I have paper copies of a few manuals I have no use for. Most of these
are single-sided photocopies made by others and sent to me for scanning
years ago. These are not originals. Almost all of them appear to be
available on bitsavers, but if you have a penchant for paper, this might
be your chance. Available by post (for whatever it costs to send them
plus the paypal fee) or by arrangement in Reading, UK.
MicroVAX Troubleshooting and Diagnostics. EK-O19AE-SG-005
MicroVAX Dual-Host Systems. EK-338AC-DH-003
VAX-11/780 Unibus Adaptor Technical Description. EK-DW780-TD.001
VAX-11/730 Diagnostic System User's Guide. EK-DS780-UG.002
VAX-11/780 Installation Manual. EK-SI780-IN-002
Translation Buffer Cache and SBI Control Technical Description.
VAX-11/780 Hardware User's Guide. EK-11780-UG-001
VAX-11/780 Console Interface Board Technical Description. EK-KC780-TD.001
FB780 Floating-Point Accelerator. EK-FP780-TD.001
MS780 Memory System Technical Description. EK-MS780-TD.001
* KA780 Centraler Processor Technical Description. EK-KA780-TD.001
* KA655 CPU System Maintenance. EK-306AA-MG.001
The last two (marked *) do not currently appear to be on bitsavers. They
do appear in my index of local files so I'll make them available to Al
Send emails off-list please.
antonio at acarlini.com
Hey all - We have had soft-launched it on our website calendar a few months
ago but I wanted to confirm that yes on October 16 - 18 2020 the first
annual "Kennett Classic" weekend is scheduled and a GO; venue booked and
implementation is under way.
The centerpiece of the weekend will be a contest between teams of vintage
computer hobbyists competing for the Kennett Classic Cup, an award to the
team with the best network of vintage hardware based on up-time and
connectivity. There will be a substantial prize awarded to the winning
team. We're really excited to share the details of this event, but stand
by for now. In addition to the on-site teams, we will open the contest to
any qualifying team worldwide. This is a first-of-its-kind world-wide
vintage computing networking event!
We're working on the registration pages now, and once they're live we'll
share all of the details. Think of the Kennett Classic Cup as a car rally
for vintage computers. We have many other activities planned for that
weekend, stay tuned.
We look forward to making this a huge success.
Kennett Square, PA