>IIRC in an 11/34, the power connectors are at the A-end of the backplane.
Come to think of it, I think you're right... confirmed by the fact
that the grant cards go in the D slot, which is the fourth from the
back of the chassis...
>It wouldn't be hard to make up the harness. It does have 2 connectors on
>the PSU end (15 way for power and 6 way for LTC/ACLO/DCLO). The VT11 does
>use LTC IIRC to sync the display to the mains and reduce flicker.
I guess I could make a harness if I can't find the one which already
has one... I'd like to have the printset so I can make the cable lengths
correct, and so I have the part numbers for the connectors...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
On Mar 30, 17:01, Megan wrote:
> Subject: Re: PDP-11/34A rebuild project Was: Re: Post-move diary
>
> >I believe you can put an MUD or SPC card in slot 5 if you don't have the
> >cache. I can't remember what happens if you don't have the FPU - either
> >slot 3 is also an SPC slot (I think that's the case) or you move
> >everything left one slot (Which I think is not the case).
Slot 3 is SPC; you *must* put the two main CPU cards in the rightmost two
slots.
> First step will be to remove everything from the backplane and
> vacuum it out...
When you've removed all the disintegrated
foam-that-used-to-be-front-panel-filter, you might want to replace it with
something less prone to aging. I found the synthetic fibrous filter
material sold for cooker hoods (over-the-stove extractor fans) works very
well, and you can tear it into half thickness for lighter duty.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
>I believe you can put an MUD or SPC card in slot 5 if you don't have the
>cache. I can't remember what happens if you don't have the FPU - either
>slot 3 is also an SPC slot (I think that's the case) or you move
>everything left one slot (Which I think is not the case).
I just realized that one of the connectors I did find was one which
appeared to connect over-the-top with two boards. The other one I
found has three connectors, and the spacing between 1 and 2 is
different from that between 2 and 3... I presume it is because 1 and
2 connect to the CPU and FPU in slots 2 and 3, and the third needs
extra space to connect to the Cache in slot 5...
I may just have what I need to get that working...
First step will be to remove everything from the backplane and
vacuum it out...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
On Mar 30, 14:14, Fred Cisin (XenoSoft) wrote:
> Subject: #029 variants (was: IBM 557 Alphabetic Interpreter??
> In addition to the rare "Interpreter punch", there was also a quite a bit
> less rare variant, the "Verifier". It would READ a card as the operator
> typed. If the card and keyboard didn't match, (IIRC after a couple of
> tries) it would put a notch in the top of the card at the point of
> discrepancy. If everything matched, it would put a notch in the side of
> the card, as testimony to it having been checked.
Yes, we had a few of those -- almost all reserved for "specialist
operators".
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
I have an Epson HX-20 with an EPROM programmer built on. See it at
"http://www.intellistar.net\~rigdonj\hx20.jpg". Does anyone know anything
about this? The case for the EPROM programmer is made of the same material
and is the same color as the Epson case and has the name "Motorola" cast
into it. It's held on with a steel bracket underneath. Someone went to a
lot of trouble to make this. There's also a ribbon cable (?) cconnector in
the top corner. Any idea what it was used for? There are also "Motorola"
marked EPROMs in the socket sin teh bottom of the HX-20. Any idea what
this machine was used for? The batteries in it are dead and I haven't had
time to get it working yet.
Joe
Obviously there has been a fair amount of 11/34a traffic today
what with the descriptions of the cache/fpu and CPU boards and
interconnects.
Armed with this info, I searched the documentation I got in the
haul and found an 11/34a printset. I also did find 1) the
FP11 floating point, 2) the cache, and 3) the two over-the-board
connectors which would allow me to connect them to the CPU.
First step was cleaning the BA box. I removed all backplanes with
the exception of the primary DD11-PK backplane. The other backplanes
were the VT11 without a power harness, and an RH11 backplane.
I removed all the boards from the primary backplane (noting where
they went). I then vacuumed the backplane, removing all sorts of
dust and particulate matter, including what appeared to be
degraded foam padding, which fell apart if I tried to pick it up.
With the backplane as clean as I could make it, I checked the
wiring harness and the backplane pins, sighting along the rows and
columns looking for any bent pins. Fortunately I didn't find any.
So the next step was to apply some power. The power controller in
the bottom of the rack did not have a normal 115vac plug on it, so
I plugged the BA box into the unswitched side of the power controller
I have in the bottom of my 11/10. I tried the front panel switch...
nothing... Whoops, forgot the circuit breakers in the back of the
BA box. I switched those on, turned the front panel switch and I
got DC OK light, and the power supply fans ran (I'd forgotten how
noisy they are with the skins off the box).
Power off... next step was adding the boards to the backplane,
one at a time. With each board, I lengthened the amount of time
I left the unit on doing the smoke test... (checking for any
whisps of the magic smoke which makes electrical things work :-)
I finally had the CPU (two boards), memory (MS11-LD, 128kw, 256kb)
the programmers console interface, a serial line, the boot board
and a bus terminator in the backplane. With power applied, I
finally had the programmer's console displaying something. But
when I tried to do stuff, the bus appeared hung. I turned the
machine off and thought about it... 'oh yeah, I forgot the
bus grant cards"...
With bus grant cards in, it powered up just fine and I entered a
few simple code fragments (actually single instructions) just to
see if it would work.
First test was a simple branch to self:
1000/777
started it, and it ran.
Next, a memory clearing routine...
0/15740
15740/0
R0/160000
start at 0, it ran briefly and halted with 000002 in the display.
Just as expected... memory was clear...
At this point I got a little daring and moved boards around so
that I could install the FPU, the cache, and the FPU and cache
in successive attempts. Unfortunately it didn't work with any
of those two boards in it, so I restored it to the working
configuration.
Slot 1 - 11/34a data paths (ABCDEF)
Slot 2 - 11/34a control module (ABCDEF)
Slot 3 - boot board (EF), KY11LB console interface (ABCD)
Slot 4 - DL11-W (ABCD)
Slots 5-9 bus grant cards (D)
Slot 9 - Bus terminator (EF)
I then checked the address for the console interface, hoping that
the serial line unit (DL11-W) that I put in it was actually at
the console address, and it appears it was.
I then checked the amount of memory and found 124kw (248kb) as
expected.
So, bottom line is that the first day of real work was quite
successful. Next step will be to find the cable I need to attach
a terminal to see what sort of boot code is available. Then
I'll have to try putting the RUX50 in it, attach that to an
RX50 in a leprechaun box, use one of my qbus machines to build
an RT-11 bootable RX50, and actually try to boot this thing.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
<It was always somewhat of a nuissance dealing with the Z-80 because of the
<way it presented its interrupt acknowledge, which was a combined I/O and M
<cycle, as long as the I/O cycle, but with M1. That meant, in my case, tha
All instuction fetch cycles were short, INTA cycle had an extry cycle added
for interrupt resolution in the supporting chips.
To get around the short M1 cucles I'd use a tiny bit of logit to stutter
the clock to the chip (slip a cycle) for M1 only. This results it running
generally faster and still using slower memory.
<This same protocol made it unwise to try to use memory mapped I/O, since th
<cycle length of an I/O cycle differed from that of a memory cycle.
I used to do it all the time and like I posted earlier the NS* disk system
used MM-IO very effectively.
Allison
<I said 'ROM' because on a number of machines, it was just a few TTL chips
<that gated C3, lobyte, hibyte onto the data bus on the first 3 fetches
<after reset.
Most used a mux and jumpers to fake a 3byte rom with the first byte
hardwired as C3h (jmp in 8080/8085/z80) and it was jammed on the bus for
boot and only then. another approach was to on power up map rom to loc 000
and also F800h and then disable the mapping after the code was running up
high. Plenty of tricks to fake that.
Allison
Anyone have a spare IBM 4869 floppy drive? Power supply died in mine.
I'm also looking for an external floppy from a TRS-80 (w/PS). Doesn't need
to have a drive.
--
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
<I guess it's fortunate there was only one DMA process going on at the time
<else it might have been real sticky figuring out what had been overwritten
<already.. If you were doing a read in order to do a write, using DMA, you
<might actually get tangled up. Fortunately that showed up while the vendo
<was debugging his code, so I didn't have to deal with that.
Multiple DMA streams are doable too though hard to apply usefully.
<That's quite so. Fortunately one wasn't required to load data at the
<granule size, but rather at the sector size, so you could get by with a rea
<of a 1K sector. Of course you had to read it before you could write it, s
<you had to wait for the next revolution of the disk. All this went by so
<fast, and, since I didn't run big databases requiring sorts to and from
<disk, I didn't perceive much delay, as it only takes a few revolutions to
<load up a program. So each drive had six logical drives on it.
I have. Running a pair of drives and using ramdisk and my own smartdisk
system. That was the speed order as well, the smartdisk system was fasest
as it hard its own CPU and DMA channel to processor ram using hidden cycle
stealing plus caching to 4x physical track size. That and a 6MHz z80 and
dust flew.
<This all sounds like it could be fun if, for example, you're running it al
<on classic and unmodified hardware. I'm not sure I'd want to try to earn m
<living that way, though.
it's more fun on current hardware like 33mhz Z180s and it's still in use
in odd pockets here and there. I don't (never did) make a living off it.
Allison
Please see comments imbedded below.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 11:59 AM
Subject: Re: Computer busses....
>>You've hit most of the important signals. One I'd add, however, is a data
>>bus disable, and perhaps an address bus disable as well. This would allow
a
>>front panel or other bus mastering device to steal cycles under certain
>>circumstances.
>
>Why wouldn't BUS REQUEST work?
>
It would only work if BUS REQUEST were not a request for negotiation. If
you do have a bus negotiation handshake, then it might not work simply to
asser BUS REQUEST because you may want to "jam" data in to certain locations
while the processor is doing most of the work. CPU places addresses on the
bus, you, by means of your front panel, want to put different data there.
You float his data bus, and drive it yourself while he creates the strobes
in his normal timing. Likewise, you might want to redirect his data flow,
hence you float his address bus, driving it yourself, while the CPU
generates normally timed transaction control signals. It's an obscure point
but I've seen it done for whatever reason on several occasions.
>
>>What would you do with the HALT signal, and how would you implement it?
>
>WAIT sould act as a "pause and hold the bus in it's current condition"
>signal. Halt should mean "Stop what you are doing, release the control of
>the bus and wait until the HALT signal is removed". IMHO
>
Now this one seems like it could be accomplished with the BUS REQUEST
signal. I suppose it's arguable, but if you want control of the bus, and
want the processor to more or less disconnect himself from it, it would
require a signal to each processor/master on the bus. If the FP wants to
control the bus, it doesn't have to HALT the processor does it? It just
needs to seize the bus. Whether that stops the processor(s) would depend on
what's on the CPU card. It depends, of course, on whether you have multiple
master candidates on the bus. If not, it's moot, but if so, then you might
not want to halt them, but merely seize the bus for a moment.
>
>>There's some debate about how one should signal the beginning of a new bus
>>cycle. This should be at the earliest moment at which addresses are
stabile.
>
>I guess the RD/WR signals should be seperate and only applied AFTER all
>signals on the bus are stable.
>
As I mentioned before, it's quite critical to the operation of the bus, how
you time the WRITE signal. Many processors following the MOTOROLA model,
i.e. with a regular 2-phase clock, with one clock per bus cycle, tell you
when the cycle begins by asserting the "E" clock in the MOT case. If R/W is
true at the beginning, it's a read cycle, else R/W must be low, meaning it's
a write. Most of the older processors of this sort assert the WRITE state,
i.e. R/W LOW quite some time before the E clock (or phase 2) becomes true.
Nevertheless, the data is only held valid for a minimal time after the
falling edge of E, hence some steps have to be taken to hold the data for
some time after end of E so that the data will persist beyond the rising
edge of the nWR signal. On a 6800 or 6502, this is quite straightforward.
The CPU is fed a single phase clock, sometimes called phase 0. It produces
(in the case of the 6502) a pair of non-overlapping complementary clocks,
phase 1 and phase 2. The 6800 required you use a clock generator to produce
those and feed them to the CPU. You could still gate them with R/W to
create nRd and nWr signals, but the results were slightly different.
More recent processors don't give you the two clocks, so you don't have as
many options. Some give you both an address strobe and a data strobe, from
which you can derive appropriately timed nRD and nWR strobes. These often
are needlessly short, however, leaving valuable bus bandwidth unused.
I think a less conservative though still correct approach would be to limit
your statement to signals other than data. Most peripherals require only
that the data be stabile on the trailing edge of the write command. It's
likewise with memories, so I think that's a safe approach. There are
exceptions, though, but I hope they're dead forever.
Dick
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
By all means if you can get a shot at it do it, get them all.
I would be interested in a complete set of each:)
Francois
>Having said that, I did see a good amount of Model 100s and their
>accessories (disk drives, manuals) and a couple of other Tandy things
>(cassette recorders). Is any of this especially rare? Some machines might
>be model 102s, since I saw the 102 tecnical manual. It would be a fair
>amount of effort to get everything; I might be able to convince the surplus
>people to make the Tandy stuff their own lot, but I'm not optimistic about
>that.
>
>-- Derek
>
You've hit most of the important signals. One I'd add, however, is a data
bus disable, and perhaps an address bus disable as well. This would allow a
front panel or other bus mastering device to steal cycles under certain
circumstances.
What would you do with the HALT signal, and how would you implement it?
There's some debate about how one should signal the beginning of a new bus
cycle. This should be at the earliest moment at which addresses are
stabile.
If you have separate strobes for memory and I/O, then either of them could
do it, or if you generate separate strobes for read and write, that could
work as well. The question comes up, however, of how to generate the write
strobe, which is often shorter than the read signal from the processor, if
there is a separate read strobe at all. On a read, it's generally desirable
to time the read strobe so the strobe at the processor goes away, signalling
that the data has been sampled, before the memory or I/O device is disabled,
making the data go away. Likewise, it's desirable to make the write strobe
during processor write cycle go away before its data becomes invalid at the
target. What's more, some peripherals don't like having data change once a
write cycle begins, so it's necessary to have valid data before signalling a
write. This is complicated by the fact that some processors initiate a
write cycle before the data is valid, while others do not. Many schemes for
generating these signals end up making the processor operate relatively
slowly with respect to the memory bandwidth in order to satisfy these
conditions. Circuits which latch the data or otherwise fiddle with the
cycle length in order to avoid slowing the processor down will increase the
parts count and complicate the timing, while those that accomplish this fit
by using faster memories and peripherals will cost more due to the higher
and not as effectively used bus bandwidth.
If you'll start with the model you've suggested, consider the types of
devices you anticipate attaching to the bus, and decide how each can be
accomodated, you'll eventually settle on a good approach.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 9:49 AM
Subject: Computer busses....
>Anyone have any idea what was/is the best bus design?
>
>I'm thinking a stripped down Z-bus (without the M1 signal and etc). What
>else should be on a bus besides:
>
>ADDRESS
>DATA
>RD/WR
>MEM/IO
>BUS REQ
>BUS ACK
>INT
>INT ACK
>WAIT
>HALT
>RESET
>CLOCK
>
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
It was always somewhat of a nuissance dealing with the Z-80 because of the
way it presented its interrupt acknowledge, which was a combined I/O and M1
cycle, as long as the I/O cycle, but with M1. That meant, in my case, that
I had to insert a wait state in the M1 cycle in order to avoid having to use
much faster RAM, since the M1 signal appeared before either the IORQ or the
MEMRQ signals. By either synchronizing the resulting signal with the clock,
thereby eliminating the glitch, or by waiting for either of these two
steering signals, the resulting cycle was too short. By that I mean that it
was almost an entire clock period shorter than the normal M1 cycle would
have been, had I been able to ignore the IACK protocol in the Z-80
peripheral devices. I was stuck with them as a result of decisions already
made. <sigh>
This same protocol made it unwise to try to use memory mapped I/O, since the
cycle length of an I/O cycle differed from that of a memory cycle.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 2:20 PM
Subject: Re: Rebirth of IMSAI
>> >One of the problems with the S100 bus is that it is _very_ dependant on
>> >the 8080 signals. Even using a Z80 is a bit of work - things like PINTE
>> >(which indicates if interrupts are enabled) and SSTACK (address lines
>> >contain the value of the stack pointer) don't exist as external signals
>> >on the Z80.
>> >
>> Of course if you wire your own Z-80, you can ignore most of the weird
>> signals if you are using static ram. Just use a memory write signal for
>> writes, and another to gate read data onto the buss.
>
>True, until you find you have some strange (commercial) card that depends
>on one of these signals for some strange reason. I know that many
>commercial Z80 CPU boards did have extra logic at least for PINTE.
>
>> There is nothing in the Z-80, etc. to prevent you from using memory
mapped
>
>-tony
>
Hi,
today was a good day at Amvets on Brighton Ave. in Allston/Brighton, MA. I
picked up 6 books on old computers, all of which are available is someone
wants them:
Minicomputer Systems: Organization, Programming, and Applications (PDP-11)
This book is a russian translation of the above title, includes
very in-depth explanation of PDP-11 (now I need one)
CODASYL: Data Description Language Committee
Ditto. Could someone tell me what CODASYL is, though? This book is
far too boring for me to figure it out myself...
Minicomputers in Data Processing and Simulation
In English for a change, has in-depth explanation of computers
and their components (including PDP-8, -11, HP and Varian
machines)
Fortran 77
In Russian
Advanced Programming Techniques: A second course in programming using
Fortran
In Russian
Assembly Language Programming
In Russian, for a Russian mini or mainframe (EC-EVM)
Here is what is still at the store:
Osborne-1 with modem in perfect physical condition
DEC Letterwriter 100 in perfect physical condition
Advanced-looking book: Digital Signal Processing
Lots of modern Borland and Microsoft programmer's manuals
--Max Eskin (max82(a)surfree.com)
Please see comments imbedded below.
regards,
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 5:36 PM
Subject: Re: Rebirth of IMSAI
>>
>> Thanks for posting this information. It might be useful, in addition, at
>> least to me, to have to correspondence with the S-100 bus pins so they
can
>> be cross-referenced to the '696 standard signal names. I do hve the 8080
>> data in house, but nothing tying it to the S-100 bus pinout or timing.
>
>Isn't this already on-line somewhere? If not, I could type in the pin
>descriptions for the Altair 8800b bus that I happen to have here. I have
>a very useful book called 'The S100 Handbook' that contains things like
>the S100 pinout, schematics for a dozen common cards (including Altair
>and Imsai CPU/frontpanel/memory), etc. But I'd rather not duplicate the
>work if I don't have to.
>
>>
>> Actually, it might be as correct to say that 8088 signal names are more
or
>> less like "all the other" microcomputers in the non-Motorola camp. with
the
>> 8085 and z-80, it became obvious that the large number of strange signals
>> generated by the 8080 didn't even help the Intel folks with the task of
>> interfacing the processor to memory and peripheral devices. The simple
>
>One of the problems with the S100 bus is that it is _very_ dependant on
>the 8080 signals. Even using a Z80 is a bit of work - things like PINTE
>(which indicates if interrupts are enabled) and SSTACK (address lines
>contain the value of the stack pointer) don't exist as external signals
>on the Z80.
What's more, those signals are really of little use. They could be, but it
was too much trouble to use them when they were available, so the fact they
aren't is of no concern.
>> a transfer of data to or from the processor. Additionally, it's nice to
>> know whether the read or write is between the processor and memory or
I/O.
>> With the MOT class of processor, you have an address strobe to tell you a
>> cycle's begun, and you have to decode the address to determine whether
it's
>
>Actually, I prefer the Motorola / PDP11 idea of having memory and I/O in
>the same address space. It means you can use the same instructions and
>addressing modes to access either.
>
>If the total address space is large enough, you don't need all of it for
>memory, so you can assign (say) 1/256th of the entire address space for
>I/O. So you use something like an 8-input NAND to decode the top 8
>address lines. One TTL chip. Not a lot of work IMHO.
Yes, this was a common approach, and one which we used with bus-based memory
mapped I/O on the 6502 and 6809, etc. With a small address space, though,
is was common to have the PROM live above the I/O page because the reset
vector lived there anyway. With the I/O mapped processors, where the ROM
was expected to live at the bottom of addressable memory, tricks had to be
used to make the rom at the bottom go away and be replaced with I/O handlers
at the top. Intel finally figured that out with the 8086 family, but with
IBM's implementation, it became a pain. There it might have been more
practical to put all the ROM at the bottom, with each adapter having a
pointer at its beginning to indicate where it ended.
>[Incidentally, can people please trim the messages they are replying to.
>It's not necessary IMHO to include a complete copy at the end of your
reply]
>
>-tony
Hello, I'm cleaning out the basement making room for some new stuff... I
have an IBM PC/36 (aka Baby 36) Model 5364 with floppy drive and one hard
drive (I can get the other drive but it needs to be wiped first). Removed
>from operation, still works, needs controller card for console machine.
Uses twin-axe terminals. I cleaned it out when I got it (took 5 minutes
for the dust to clear from the air in my workroom!)
Anybody interested in it? If not, I'd be interested in finding an OS for
it and the controller card to put it back in service.
Kevin
--------------------------------------------------------------------------------
After sifting through the overwritten remaining blocks of Luke's
home directory, Luke and PDP-1 sped away from /u/lars, across the surface
of the Winchester riding Luke's flying read/write head. PDP-1 had Luke stop
at the edge of the cylinder overlooking /usr/spool/uucp.
"Unix-to-Unix Copy Program;" said PDP-1. "You will never find a
more wretched hive of bugs and flamers. We must be cautious."
-- DECWARS
____________________________________________________________________
| Kevin Stewart | "I am a secret |
| KC8BLL ----------| Wrapped in a mystery -Milford High School |
| a2k(a)one.net | Wrapped in an enigma Drama Tech Dept. |
|jlennon(a)nether.net| And drizzled in some tasty chocolate stuff.|
--------------------------------------------------------------------
I have 4 Tandy printer cables to sell, individually or as a lot.
1) 12 ft heavy guage Tandy card edge female to Centronics 36 male $10
plus ship
2) 6 ft heavy guage Tandy card edge female to Centronics 36 male $7.50
plus ship
3) 6 ft flat ribbon Tandy card edge female to Centronics 36 male $5.00
plus ship
4) 6 ft ribbon Tandy header to Centronics 36 male, Tandy number 2x-1409
for PORTABLES, in package $7.50 plus ship
ALL ABOVE for $30.00 but will ship FREE.
Shipping will most likely fall into the $3.20 priority category for
USPS. USA and APO/FPO only. Contact me by direct email
> Lawrence Walker <lwalker(a)mail.interlog.com> wrote:
>
> Sounds like Doug has a head-startt in collecting Canadian-made computers
> what with the Hyperion and the AES. Now to get an ICON and a MCM 70. I
> have a couple of clone types. A Tryllium 286 and another, a MAX , a 386
> with
> dreadfull physical attributes, looks like an oversized XT, but nice
> internal
> architecture, OEMed by a Quebec company whose name escapes me at the
> moment.
>
Would that Quebec company be Ogivar?
Arlen
> --
> Arlen Michaels amichael(a)nortelnetworks.com
>
On Mar 30, 8:34, Fred Cisin (XenoSoft) wrote:
> Subject: Re: IBM 557 Alphabetic Interpreter??
> #026 and #029 keypunches, nor the punch outputs of most computers, did
> NOT print anything on the card.
We had lots of 026 and 029 punches at Edinburgh University when I was
there, and they all *did* print on the top edge. I wish I still had some
of those cards; alas I only have a few empty steel boxes. Come to that, I
wish I had one of the punches :-)
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
>Great choice to start with! (Uhh, actually, I'm trying to get my own
>11/34A running and this will open up our list colleagues' assistance for
>benefit of both of us ;-)
Thanks... I'm sure it will...
>The 11/34A CPU backplane (slots 1-9) has to be a DD11-PK.
The backplane does appear to be the correct one...
>Does the ID label on the outside, right side panel of the system box say
>1134A xx or is it BA11 xx?
I'll have to check...
>Can't help with the VT11. Sorry. Sounds quite cool though.
It is... when I was in college (the first time around), I used to
write programs for it under RT-11... I wrote a program for an ME
grad student which displayed a four-bar linkage problem, allowing
the student to examine the results of various lengths of the legs
by actually moving them in real-time with the light pen...
Another program I did graphed trajectories of objects given initial
angle and velocity... it properly did clipping at the top of the
screen if the graph went that far, and did automatic scaling...
Finally, I developed a program which allowed design of logic
circuits using the light pen to first drag parts from a library
along the edge of the screen out to the breadboard field, then
wired them, then could supply a clock and test what the circuit
did...
>Should have three cables connecting to the console panel: a two-wire
>shielded cable going to the M9312 (P/N: 70-11413-3F), a four-wire twisted
>cable going to the H765 PSU (P/N: 70-11992-0-0) and a 20 cond. flat cable
>(P/N: 70-12214-2D) which goes to the M7859 Programmer's Console module.
It looks like it has the right cables, but I'll have to check when I
get home... Thanks for the info...
>The FPU is M8267. (The FP11-A option)
Turns out I have one in the box of parts... (see my list at the bottom
of this post).
>Cache board # M8268 (the KK11-A option)
Found it too in the same box...
>Important to find the over-the-top jumper boards which go between the
>various modules and possibly dependent upon whether you have the FPU in
>or out. I'm assuming you got a box with a rat's nest of cables and misc
>parts. If so, dig for small PC boards with dual-row, 0.1" center
>connectors. Part numbers on white paper labels are H8821 with dual 40-pin
>connectors and (hopefully for addition of your planed FP option) the
>H8822 with three 40-pin conns.
I did find some familiar connectors for such things... I'll have to
check them out when I get home and see if they are what I need...
>If you do not have the 11/34A printsets and KK11-A Cache tech manual
>please get back to me and I'll give you more P/N's and some details on
>what goes where based on my system and 11/34A printsets. This can get
>confusing with just simple, brief statements.
Not for someone who has seen the stuff before... I'm not a guru with
it, but I recognize what you're talking about...
>I have not found an FP11-A tech manual and printset and Cache printset as
>of yet (hint-hint anybody! :)
I still have a box of printsets to go through as well... it may just
have that in there... we may both luck out...
>Two other important cables to root around for in the box, which go
>between the M8266 and M7859, are two 10-conductor flat cables P/N
>70-11411-1D. When the M8367 FPU board is plugged-in, they run between the
>M8267 and the M7859 (this is where the docs are *real* handy) and a
>over-the-top board connects the M8266 and M8267.
More to checkout when I get home...
>The board lineup in my machine is as follows (going from slot #1 to the
>left) and the first five must be adhered to:
>
>#1 M8266, 11/34A Control Module (KD11-EA)
>#2 M8265, 11/34A Data Path Module (KD11-EA)
These two are in the machine...
>#3 M8267, 11/34A Floating Point Processor
Not yet, but soon...
>#4 M9312 (slot A-B), Bootstrap/Terminator;
M9301, but I have an M9312...
>#4 M7859 (slot C-D-E-F), Programmer's Console I/F (KY11-LB)
It's in there...
>#5 M8268, 11/34A Cache (1kbyte) (KK11-A)
Not yet...
>The following can now be any MUD module . . .
>#6 M7891-BC, 64KW MOS memory
>#7 M7762, RL01/2 controller (RL11)
>#8 G727A, buss grant jumper
>#9 M9202, backplane jumper to next backplane . . .
Haven't found the RL11 controller yet... I do have the bus grant
jumpers, and a terminator in the main backplane. The VT11
backplane wasn't even connected... but then again, it doesn't
have a power harness...
>For you Megan, the first three slots shall be M8266, M8265 and M8267 with
>the H8821 over-the-top jumper between the 8265 and 8267. So, the H8821 is
>the hot item to find to get your FPU lit up.
I don't think I saw the over-the-top connector in the machine, but I
think I saw one in the random parts box...
>Incidentally, my system box has several of the module numbers printed on
>the slot number label strip going across the top of the backside of the
>slot cage. Yours may if it is indeed an 11/34A box instead of a generic
>BA11-K.
Yep, it has that strip...
>Oh, I am salivating at the RUX50 controller! :) Can you clone that
>module?
Sorry... :-)
Okay... here is the list of what I have found (so far) in my collection
of UNIBUS related parts...
DD11-CK 4 slot hex backplane
DD11-DK 9 slot hex backplane
DD11-B 4 slot hex backplane (comm backplane?)
G109C part of memory option... don't know which yet
G114 (with H217C and G235)
G231 part of memory option... don't know which yet
G235 (with H217C and G114)
G651 (with H221A)
H114 (with G114 and G235)
2 H214 8 Kw 16-bit stack used in MM11-L
H215 8 Kw 18-bit stack (parity) used in MM11-LP
H221A 8 Kw 18-bit stack (plugs into G651)
4 M3105 DHU11 - 16-line async mux
3 M5904 RH11 Massbus controll transceiver
2 M5922 RM03 transceiver port A
2 M5923 RM03 transceiver port B
M7013 ???
M7014 ???
M7093 FP11-F 11/44 Floating point module
M7097 KK11-B 11/44 4 KWord cache module
2 M7228 KW11-P Programmable real-time clock
2 M7260 KD11-B 11/05,10 Data paths
2 M7261 KD11-B 11/05,10 Control logic
M7341 ???
M7521 DELUA
M7522 RUX50
3 M7547 TUK50
M7684 RK05 control sequencer
M7685 RK05?
M7686 RK05?
2 M7792 DEUNA port module (1/2)
2 M7793 DEUNA link module (2/2)
3 M7800 DL11
M7819 DZ11-A 8-line async mux
3 M7856 DL11-W SLU and real-time clock
M7859 KY11-LB 11/34a programmers console interface
M7860 DR11-C parallel I/O
3 M7891 MS11 (I don't know which variants yet)
M7892 TU60 Cassette interface
M7893 DRS11
M7895 DSS11
M8203 (with M8207) DMP11
M8206 (with M8207) DMC11
M8207 (one with M8203, one with M8206)
DMC11/DMP11/DMR11?
M8256 RX211 RX02 floppy disk interface
M8265 KD11-EA 11/34a data paths module
M8266 KD11-EA 11/34a control module
M8267 FP11-A 11/34a floating point processor
M8268 KK11-A 11/34 cache module
M8293 16K UNIBUS timing
2 M8398 DMZ32 24-line async interface
M873 BM873 bootstrap/loader
4 M9202 UNIBUS backplane jumper
M9312 Boot/terminator
M9970
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
At 09:41 PM 3/29/99 -0800, you wrote:
>On Mon, 29 Mar 1999, John Lawson wrote:
>
>> Do you actually *own* this, or just know where one is? Tres Cool!
>
>I might very soon. Its a huge beast! Too adorable to ignore.
Verily, it is a huge *beast*, and though adorable it should be ignored, IMHO.
Unless it is in perfect working condition, you probably will not be able to
restore it to working condition, especially if their is any appreciable wear
and tear on the print unit or the giant cams that are inside. The 557 was a
very unusual machine in the IBM tabulating line. I worked summers at
college for IBM field engineering during the 60's and the 557 was notorius
for needing constant maintenance. IBM kept incredibly detailed records of
every maintenance action on a piece of punched card equipment, since
practically all of them were rented at the time. The 557 was the hanger
queen of all tab equipment, consistantly the most maintenance intensive of
tab card machines. Open the covers and you will see why. There are two
giant cams, about 3' across driving the internals. It takes so much
mechanical energy to drive the print wheels, that the wheel cage is actually
skewed inside the frame, so that if all the print wheels are printing the
same character, they don't all fire at once. I have heard of field
engineers taking off the covers of a 557 for the first time, thinking that
the whole machine was trashed because the print wheel cage was torqued in
relation to the machine frame. When the machine runs it feels like a
washing machine out of balance and hops around the floor.
-- Dean
Okay, since it has been a long time since I last did anything with a real
pdp-8, and since I did pdp-11s for some 20+ years, I decided to start with
what I knew... so I started examining the pdp-11/34a I got in the recent
move.
Turns out that the system box has the cpu backplane, one DD11-DK (9 slot
backplane for taking 'small peripheral controller' (SPC) boards), and
one VT11 backplane.
Unfortunately, there is no power harness on the backplane, no boards in
the backplane, and no cable to attach the boards to the VR14 that I did
get.
I think I may have a VT11 backplane with power harness and boards
somewhere in my 'warehouse' (a couple of closets).
The machine has the programmers console, but no memory.
In one of the boxes I got in the move, I got a couple of MS11-LB memory
boards, so I'll use one of them. I think I also got an FPU, but I'll need
to see if I got prints for the 11/34a to see where it goes and how it gets
connected (if it does). I don't have a cache board, so I'll be looking
for one of those.
I think I have an RL11 somewhere... but I'll need an RL drive. I may,
for the time-being, take one of the RL01s from the -8 system racks. I
also have an RUX50 controller and some RX50 disks, so I may try to get
that working... I might be able to boot the XXDP+ RX50 kit that I have
and do some system diagnostics.
That's it for now...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
Hi All,
Today I salvaged a very odd looking DEC box, and I have no idea what it
is. It is in a black metal case, with vents at the top, the external ports
look like those of a VT-100, it has Video in, Video Out, Comm, 20ma
Current Loop, and keyboard. The model number is stamped 70-17562-01, but
the Serial number is stamped N/A.
Does anyone know what this is? I suspect it is some kind of terminal, but
I'm not sure.
Cheers
Karl
------------------------------------------------------------------------------
Karl Maftoum
Computer Engineering student at the University of Canberra, Australia
Email: k.maftoum(a)student.canberra.edu.au
<One of the problems with the S100 bus is that it is _very_ dependant on
<the 8080 signals. Even using a Z80 is a bit of work - things like PINTE
<(which indicates if interrupts are enabled) and SSTACK (address lines
Neithrr of which had much application.
<Actually, I prefer the Motorola / PDP11 idea of having memory and I/O in
<the same address space. It means you can use the same instructions and
<addressing modes to access either.
nothing about z80, 8085 or 8088 stops one from doing that. The Northstar*
floppy controller was memory mapped for exactly that reason.
Allison
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, 30 March 1999 6:43
Subject: Re: Decwriter II
>The paper out logic is pretty simple. The output of the switches goes
>through a little RC circuit to the input of a 7474 d-type (unfortunately
>which chip this is depends on the board version - it's E5b on an M7723
>and E34b on an M7728). The output of that ff is the ready line.
marvin was kind enough to post similar data. Looking at that area this
afternoon.
>It appears that the switch is closed when the printer is out of paper. So
>my first test would be to find the 100 Ohm resistor between the D-input
>of that chip (pin 12) and pin BB on the keyboard connector. Unsolder it.
>This disconnects all the switches. Does it work now?
No.
>I don't, alas, have the schematic of the chassis. But it appears from a
>general wiring diagram that the paper out switch is in parallel with the
>cover interlock switch. Have you checked that one?
Yes. the switches are not implicated. I disconnected the whole switch
assembly, still no go. Stuck output on the chip I'll bet, the fact it was
intermittent for a while makes a logic chip failure even more likely. (I
don't think I mentioned that earlier)
Thanks for your help......
Cheer
Geoff Roberts
Hi,
I have some DEC cables that I peicked up. Does anyone know what they're
for?
Marked "BC-022D-10" also "82351-000" DB-25F on both ends estimate 10
foot long
Marked "BC22D-50" also "71065" DB-25F on both ends, estimate 50 foot long
Marked "BC22D-25" also "71065" DB-25F on both ends, estimate 25 foot
long,NIB
Thanks,
Joe
Thanks for posting this information. It might be useful, in addition, at
least to me, to have to correspondence with the S-100 bus pins so they can
be cross-referenced to the '696 standard signal names. I do hve the 8080
data in house, but nothing tying it to the S-100 bus pinout or timing.
Actually, it might be as correct to say that 8088 signal names are more or
less like "all the other" microcomputers in the non-Motorola camp. with the
8085 and z-80, it became obvious that the large number of strange signals
generated by the 8080 didn't even help the Intel folks with the task of
interfacing the processor to memory and peripheral devices. The simple
interface used by the 8085 and Z-80, which had to be painstakingly created
>from an 8080, lives on, in the ISA and other bus architectures. What it's
come down to over the last 20 years is that you need a pair of signals, i.e.
nRD and nWR to tell you (1) that something's going on, and (2) whether it's
a transfer of data to or from the processor. Additionally, it's nice to
know whether the read or write is between the processor and memory or I/O.
With the MOT class of processor, you have an address strobe to tell you a
cycle's begun, and you have to decode the address to determine whether it's
I/O space or memory that's the target. In either case, you need only one
level of logic to create the necessary strobes, and none of it is clocked
logic, so no nonessential time loss is generated.
One of the reasons the S-100 required such fast memory for its relatively
slow processors was that you had to operate relatively complex timing
structures to create proper timing. That's a reason the standard, in my
considered opinion, killed the S-100 rather than perpetuating it. Intel
figured this stuff out a decade earlier with its Multibus-I. That used a
very ISA-like set of bus handshakes. Because the '696 standards committee
couldn't take the hint from the rest of the world and simply pick WHICH
write signal to use and WHICH read signal to use and that they couldn't
figure out that the system didn't need to have data valid at the beginning
of a write cycle, but only a short while before the end, and that data had
to be held for a time after the end of a cycle, simply was a dreadful shame.
That's what happens when folks meet with no intention of compromising. The
result of course, was the chaos that results when surplus vendors e.g.
CompuPro/Godbout (cited here because they were BIG, not because they were
BAD) design their boards considering only what's out in the dozen 55-gal
drums full of TTL parts in the warehouse as opposed to how the functions can
be implemented BEST.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 2:18 PM
Subject: Re: Rebirth of IMSAI
>>
>> GAWD! The 8080 data sheet! I wonder if my archives go back that far . .
.
>
>
>I know I still have the 8080 data sheet (actually a NatSemi version of
>it). I found it the other day when looking for the SC/MP data (which I
>also found...)
>
>> Soooo . . . the signals were named the same also, eh? pSYNC, /pWR,
sMEMR,
>> etc???
>
>I have the Imsai 8080 CPU board schematics here.
>
>Here are the signals (modulo buffering/inverting):
>
>reset/ -> 8224 clock generator reset
>Prdy, Xrdy logically ORed and fed to 8224 rdyin
>PINT/ -> 8080 INT
>HOLD/ latched by D-type (clocked from phi2), -> 8080 Hold
>POC <- 8224 reset output
>Phi1 <- levelshifted 8224 phi1 output
>SSW DIS/ -> logic -> data buffer enable pins
>Phi2 <- 8224 phi2ttl output
>Cloc <- gate-delayed version of phi2
>Data, address lines <- 8080
>Pwait, Pwr/, Pdbin, Pinte, Phlda, Psync <- 8080
>CCDSBL -> enable line on buffers for last list of signals.
>Addr disbl/ ditto for address buffers
>DO Disbl/ ditto for data out buffers
>RUN, SS -> logic -> data buffer control
>SINTA, SWO, SSTACK, SHLTA, SOUT, SM1, SINP, SMEMR <- 8212 latch on CPU
>data lines, clocked by STSTB from 8224.
>STAT DISBL -> enable of buffers for those lines.
>
>That#'s basically it. The S100 bus is very similar to the raw 8080 lines
>(like 8-bit ISA is pretty much 8088 signals).
>
>-tony
>
At 09:27 PM 3/29/99 -0800, Sellam wrote:
>Same difference. [110 baud vs 110 bps ]
Bzzzt! And thanks for playing. Actually this would be a reasonably good
trivia question. The term 'baud' is used to indicate signalling states, the
term 'bits' is used to represent transmitted data. The ASR-33 transmits 110
signaling states (bauds) per second, out of every 11 one is a start bit,
eight are data bits, and two are stop bits, thus the number of bits per
second is actually 8/11 * 110 or 80 bits per second. When you use 8 bits to
represent a character this is 10 characters per second.
--Chuck
Today I went to see a couple of the people that I meet at yesterday's
hamfest. One of them used to service XEROX computers. He told me that he
threw out three rooms full of old XEROX computers less than a year ago. :-(
He gave me part of the stuff that he had left, I have to take a Truck
(note capital) back to get the rest (estimated at two cubic yards but no
complete machines). So far I've found lots of docs and 8" flopppy disks
for the 820 and 16/8. The 16/8 looks pretty interesting, it ran CPM,
CPM-86 and MS-DOS. Does anyone have one of these? What's your opinion of
them?
He has a floppy disk drive control box to manual operate 3.5", 5.25" and
8" drives during alignment. Anyone have an idea of what one of these is
worth with the alignment disks and manuals?
Alos found a Lisa mouse to go with the Lisa that I got yesterday.
Joe
I have been offered a "Vector Graphic B" and would like to find some more
information about it. I have found they did a 1 and 1+ from the Haddock
book and I have seen reference to an "MZ" on the comprehensive computer
catalogue. Where there other machines in their range? The "B" apparently
runs the p-system was this common for these machines or did they run any
other systems? I would like to talk to any other collectors out there who
have one of these machines so I can work out just what I will be getting.
Many Thanks
--
Kevan
Collector of old computers: http://www.heydon.org/kevan/collection/
OK, this is totally off topic, but if you haven't heard the weekends news
I'd recommend checking out the following URL:
http://www.zdnet.com/zdnn/special/melissavirus.html
Normally I discount these as hoaxes, but this isn't. Thankfully I'm one of
the 'Dinosaurs' at work that refuses to give up an antique RS/6000 for a
nice shiny new NT box, so I'm still on UNIX e-mail.
The problem in a nutshell, don't open any messages in a Microsoft E-Mail
program with the following title "Important Message From: {persons name}".
Zane
| Zane H. Healy | UNIX Systems Adminstrator |
| healyzh(a)aracnet.com (primary) | Linux Enthusiast |
| healyzh(a)holonet.net (alternate) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| and Zane's Computer Museum. |
| http://www.dragonfire.net/~healyzh/ |
Anyone know where I'd find a circuit diagram for a Decwriter II?
Preferably in South Australia.
I have one that thinks it's permanantly out of paper.
(No, it doesn't seem to be a microswitch)
I suspect it's just a stuck logic state in a 74xx ttl chip, but a circuit
will make it a lot easier to find.....
Alternatively, if this is a common fault, anyone know which chip is
implicated?
Cheers
Geoff Roberts
Computer Systems Manager
Saint Mark's College
Port Pirie, South Australia.
Email: geoffrob(a)stmarks.pp.catholic.edu.au
ICQ #: 1970476
Phone: 61-8-8633-8834
Mobile: 61-411-623-978
Fax: 61-8-8633-0104
At 08:37 PM 3/29/99 -0800, Sellam wrote:
>
>Does anyone know what the function of an IBM 557 Alphabetic Interpreter
>is/was?
... and yes, if you had not guessed... I still have a manual on how to
program these things!
(now, if I could just remember that trick that we used to teach a 402
tabulator how to multiply... B^} )
-jim
---
jimw(a)agora.rdrop.com
The Computer Garage - http://www.rdrop.com/~jimw
Computer Garage Fax - (503) 646-0174
Another interesting thing I noticed this evening is that the color scheme
of the PDP-8/f is subtley different than the scheme of the 8/m. The Rust
colored handles are the same but the brown ones are more yellow. Megan's
got a picture of the green one that was the 'lab' 8. How many were there?
--Chuck
(who thought he had extra 8 switches but finds he has mostly extra 8/m
switches)
At 21:27 29-03-1999 -0800, you wrote:
>On Mon, 29 Mar 1999, Bruce Lane wrote:
>
>> Actually, ASR-33's ran at 110 Baud rather than BPS.
>
>Same difference.
>
>(you were just joking though, I'm sure)
No I was not, and it's not necessarily the same (contrary to popular belief).
From 'Data Transmission, Second Edition' by Tugal and Tugal (McGraw-Hill,
1989), Pages 133-134:
"...The transmission rate is generally expressed in Baud (Bd). Although in
most systems it is equivalent to bits per second (b/s), the baud
transmission rate must not be confused with the information rate, bits per
second, the rate at which actual data are transmitted. One baud signal may
carry one or more bits of the data..."
The book goes on to detail some specific examples. In essence, in a case
where QAM (Quadrature Amplitude Modulation) is used between a pair of 9600
b/s modems, every discrete change in the signal represents four bits.
9600/4 = 2400, so the actual 'baud' rate of such a signal is 2400, even
though the bits/second is 9600.
They give another example specifically related to the transmission of
ASCII code where the baud rate is representative of the total number of
bits in a single character (11 in their example, made up of 8 data, 1
start, and two stop bits).
Anyway, it makes a good read. The book itself may be a bit dated, but the
principles don't change.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bruce Lane, Owner and head honcho, Blue Feather Technologies
http://www.bluefeathertech.com
Amateur Radio:(WD6EOS) E-mail: kyrrin(a)bluefeathertech.com
SysOp: The Dragon's Cave (Fido 1:343/272, 253-639-9905)
"Our science can only describe an object, event, or living thing in our own
human terms. It cannot, in any way, define any of them..."
At 09:48 PM 3/29/99 -0800, Sellam wrote:
>On Mon, 29 Mar 1999, James Willing wrote:
>> At 08:37 PM 3/29/99 -0800, Sellam wrote:
>> >
>> >Does anyone know what the function of an IBM 557 Alphabetic Interpreter
>> >is/was?
>>
>> ... and yes, if you had not guessed... I still have a manual on how to
>> program these things!
>
>Cool. I especially liked the patch panel. I'd love to learn how to
>program the thing.
OOH!!! I see a program for VCF III coming on! "Progamming IBM Unit Record
Equipment"! You will have to find a couple of more pieces tho...
We'll need a keypunch, a sorter would be nice, (I have both of those, but
they are a bit hard to move that far), a reproducer would probably be
excessive, but a tabulator or calculator would be just keen! (WARNING -
IBM had a REAL interesting definition of "calculator") A collator might be
fun too...
>> (now, if I could just remember that trick that we used to teach a 402
>> tabulator how to multiply... B^} )
>
>Are you implying these things had some general purpose computing
>attributes?
Yes... (BTW: brain fart - it was a 403 that we taught how to multiply)
The Tabulators could do addition, subtraction, and summary functions (basic
accounting machines) controlled by the programming on the plug board.
The Calculators could also do multiply, divide, and logical functions.
Again, controleld by plug boards and the cards...
Any which way... watch out what you ask for! I can probably still teach
someone how to program these things! B^}
(Damn, I'm starting to feel old!)
-jim
---
jimw(a)agora.rdrop.com
The Computer Garage - http://www.rdrop.com/~jimw
Computer Garage Fax - (503) 646-0174
><I have no idea, however, how you block and deblock I/O with 1K blocks when
><you have only 1k in your sector buffer. I suppose I could go back and loo
>
>You copy the sector to the 1k ram area and then copy out the desired
>sector. the real trick is keeping track of whats in ram and if it has
>to be written back.
I guess it's fortunate there was only one DMA process going on at the time,
else it might have been real sticky figuring out what had been overwritten
already.. If you were doing a read in order to do a write, using DMA, you
might actually get tangled up. Fortunately that showed up while the vendor
was debugging his code, so I didn't have to deal with that.
><at the software, but the stuff I had at my disposal at the time seemed to
><work best with a big hard disk requiring the largest available granules
><(allocation blocks) and since the logical drives were limited to 8MB and
>
>the largest allocation blocks are due to the need to store in ram on a bit
>per allocation block basis, a bit for every allocation block on the disk.
>for something like a 8mb disk using 4k blcks that would be 256 bytes!
That's quite so. Fortunately one wasn't required to load data at the
granule size, but rather at the sector size, so you could get by with a read
of a 1K sector. Of course you had to read it before you could write it, so
you had to wait for the next revolution of the disk. All this went by so
fast, and, since I didn't run big databases requiring sorts to and from
disk, I didn't perceive much delay, as it only takes a few revolutions to
load up a program. So each drive had six logical drives on it.
><since CP/M was pretty much a thing of the past, I didn't see any point in
><wasting time and resources fine-tuning it. I used it because I had a few
><already-paid for cross assemblers and other tools for CP/M. Once a decent
><version of the PC-DOS became available, I was sure to make the switch. O
><course I didn't realize how long that would be. Nonetheless, once I had a
><PC with a '186 processor, I could run the CPM emulator to use my tools and
><the more modern hardware to do my work, and the CPM became a relic.
>
>Shame. I still use it. And I'm still finding ways to tune it for even
>more performance. It was the active full time OS amd machine until
>89 when I went pdp-11. After that it was the part time on line system.
>
>Current project is to add heirarchal directories (not the ZCPR user thing).
>it turns out to be doable though the bdos will have to be altered.
This all sounds like it could be fun if, for example, you're running it all
on classic and unmodified hardware. I'm not sure I'd want to try to earn my
living that way, though.
>Allison
>
Sellam Ismail <dastar(a)ncal.verio.com> wrote:
> Does anyone know what the function of an IBM 557 Alphabetic Interpreter
> is/was?
Yeah, it "interprets" punched cards, meaning it reads the punches and
prints human-readable characters, probably across the 12-edge.
"Alphabetic" probably means "can do letters too" (in addition to
0-9).
I vaguely remember one that used to sit in the University
of Maryland College Park Computer Science Center dispatch room,
as I recall it would print sixty-mumble characters across the
the 12-edge and put the next eleventy-so off to the right
about where the 12-punches would be.
-Frank McConnell
Hi everybody-
First off my e-mail address changed. I used to be rws(a)ais.net, now it's
rws(a)enteract.com.
Second, at the LAMARSfest yesterday at Grayslake IL (which was pretty
poor- a few expensive C=64's, lots of expensive PC clones, and not much
else), I got an Oneac ON! computer. (Actually somebody was holding a
"weird CP/M computer" for me there.) It's a black box about a foot square
by 3" tall, with no on/off switch, a huge capacitor inside across the
rectified mains to keep the switcher running for a while in case of power
failure, and serial console I/O. It has a ONFILE (basically a RAMdisk) of
2 MB, in 4256 DRAMs. A 5 1/4" DSQD floppy is permanently connected by
ribbon cable. It appears from the somewhat sketchy manual that it runs
ZCPR. Upon plugging it in and waiting 30 seconds, hitting CR gets a nice
main menu with choices of a (decent) monitor, initialize the ONFILE, run
Z-system, and a few other things. I can't get it to load from disk to
init the ONFILE yet but I didn't try very hard yet.
Has anyone even heard of this thing? It looks pretty neat. I hope I can
get it running.
Richard Schauer
rws(a)enteract.com
At 08:37 PM 3/29/99 -0800, you wrote:
>
>Does anyone know what the function of an IBM 557 Alphabetic Interpreter
>is/was?
>
>Looks like a punch card sorter of some sort.
Not quite... The 557 interpreter reads and prints the content of a card
back onto the card, in a format of up to 60 print columns and on one of 25
selectable horizontal positions.
Thie was a more advanced model that the previous 548 and 552 models, and
had more available options. Some of these included:
(quoted from "IBM Machine Operation and Wiring - 2nd edition")
* Repetitive print for printing on detail cards the information read from
an X or NX master
* Proof checking of interpreting and other functions
* A second print entry that will permit one control panel to handle two
lines or two jobs
* A pre-sensing (control-X reading) station for use in selecting alphabetic
information and also for use in the repetitive-print operation
* Large type wheels and check protection (for printing checks)
Up to four selective stackers
So, why? Did you find one???
-jim
---
jimw(a)agora.rdrop.com
The Computer Garage - http://www.rdrop.com/~jimw
Computer Garage Fax - (503) 646-0174
<I have no idea, however, how you block and deblock I/O with 1K blocks when
<you have only 1k in your sector buffer. I suppose I could go back and loo
You copy the sector to the 1k ram area and then copy out the desired
sector. the real trick is keeping track of whats in ram and if it has
to be written back.
<at the software, but the stuff I had at my disposal at the time seemed to
<work best with a big hard disk requiring the largest available granules
<(allocation blocks) and since the logical drives were limited to 8MB and
the largest allocation blocks are due to the need to store in ram on a bit
per allocation block basis, a bit for every allocation block on the disk.
for something like a 8mb disk using 4k blcks that would be 256 bytes!
<since CP/M was pretty much a thing of the past, I didn't see any point in
<wasting time and resources fine-tuning it. I used it because I had a few
<already-paid for cross assemblers and other tools for CP/M. Once a decent
<version of the PC-DOS became available, I was sure to make the switch. O
<course I didn't realize how long that would be. Nonetheless, once I had a
<PC with a '186 processor, I could run the CPM emulator to use my tools and
<the more modern hardware to do my work, and the CPM became a relic.
Shame. I still use it. And I'm still finding ways to tune it for even
more performance. It was the active full time OS amd machine until
89 when I went pdp-11. After that it was the part time on line system.
Current project is to add heirarchal directories (not the ZCPR user thing).
it turns out to be doable though the bdos will have to be altered.
Allison
<Teletype, so I'm pretty sure the Elf code is correct. I'm using 110
<bits per second, no parity, 8 data bits, one low (logic 0) start bit,
<and one high (logic 1) stop bit. It seems to like the data
TWO stop bits, tty did two. 8n2
<characters; I get consistent hex values for each character I send to the
<Elf, but they seem to usually be either shifted left or right by one
<bit, or they have the high bit set when it shouldn't be. It feels like
It may be the one stop bit missing or there are too many transistions going
on die to contact bounce (dirty commutator and poor signal conditioning on
the other end).
TTy reading 8 level tape is a continious stream of start, lsb...msb,stop
stop and repeat. the COSMAC in this case is just sitting there playing
catch. If the timing loop is off on the RX end you get garbage.
Allison
>Today I salvaged a very odd looking DEC box, and I have no idea what it
>is. It is in a black metal case, with vents at the top, the external
>ports look like those of a VT-100, it has Video in, Video Out, Comm, 20ma
>Current Loop, and keyboard. The model number is stamped 70-17562-01, but
>the Serial number is stamped N/A.
>
>Does anyone know what this is? I suspect it is some kind of terminal, but
>I'm not sure.
I think it is the VT100 portion of a VSV11... the output of the VT100
in that box could be fed through a signal cable to the VSV11, and thus
displayed...
(If you otherwise have no need for it, I have a VSV11 without that part).
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
Yes. That is the "toaster" that is a VT100 logic board and power supply to
provide 'normal' text and video sync on green with a VS11 graphics board
set. I have a few here along with the VS11 boards and docs. If you don't
have the VS11and cab kit you can use the video out and go straight into a
VR241 green.
Dan
-----Original Message-----
From: Karl Maftoum <karlm(a)blitzen.canberra.edu.au>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 11:03 PM
Subject: Strange DEC box
>
>Hi All,
>
>Today I salvaged a very odd looking DEC box, and I have no idea what it
>is. It is in a black metal case, with vents at the top, the external ports
>look like those of a VT-100, it has Video in, Video Out, Comm, 20ma
>Current Loop, and keyboard. The model number is stamped 70-17562-01, but
>the Serial number is stamped N/A.
>
>Does anyone know what this is? I suspect it is some kind of terminal, but
>I'm not sure.
>
>Cheers
>Karl
>
>
>---------------------------------------------------------------------------
---
>
>Karl Maftoum
>Computer Engineering student at the University of Canberra, Australia
>
>Email: k.maftoum(a)student.canberra.edu.au
>
I have to defer to your more recent experience. Aside from the occasional
job requiring my portable development station, I seldom used CP/M after 1984
or so. I did have a farily flexible prom programmer with which I could
program parts not yet supported on my PC-based programmer, but in the span
between '81 and '84, I had other concerns.
I have no idea, however, how you block and deblock I/O with 1K blocks when
you have only 1k in your sector buffer. I suppose I could go back and look
at the software, but the stuff I had at my disposal at the time seemed to
work best with a big hard disk requiring the largest available granules
(allocation blocks) and since the logical drives were limited to 8MB and
since CP/M was pretty much a thing of the past, I didn't see any point in
wasting time and resources fine-tuning it. I used it because I had a few
already-paid for cross assemblers and other tools for CP/M. Once a decent
version of the PC-DOS became available, I was sure to make the switch. Of
course I didn't realize how long that would be. Nonetheless, once I had a
PC with a '186 processor, I could run the CPM emulator to use my tools and
the more modern hardware to do my work, and the CPM became a relic.
It had performed fairly well and competitively with the PC up to the point
at which I got an XT clone which used a '186 at 16 MHz. Together with a
couple of fairly fast drives it outperformed CP/M on the Z-80 even when it
was emulating CP/M.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 8:01 PM
Subject: Re: followup: Rinky dink hamfest
><I agree that the ramdisk improved performance. It was just the
><implementations that made the system so fragile once ramdisk was in place.
>
>I have a kaypro with a 2048k ramdisk, it screams and would beat any kaypro
<snip>
>Allison
>
Hi,
I just picked up an i860 box, which has System V on it ... and I don't
know the root password. If I interrupt the boot cycle at the start,
I get a prompt of "?". If I say "boot", it boots System V and puts me
at a login prompt. Is there a way to get logged on as root without
knowing the root password?
thanks,
Stan Sieler
sieler(a)allegro.com
>Just how much does one of these (*#^@&* things weigh? I had to move mine
>today to get a monitor box for a 21" monitor that was sitting behind it.
>After moving the DECwriter the monitor which was about 80 pounds seemed
>downright lite!
>
I know they are under 140 lbs. I FedX P1 shipped one for a customer. (it
had to be under 150 to go P1 and not the freight group) Also 2 of them on a
pallet with a heavy box over them was 270 lbs IIRC. They are just
cumbersome.
Dan
<I agree that the ramdisk improved performance. It was just the
<implementations that made the system so fragile once ramdisk was in place.
I have a kaypro with a 2048k ramdisk, it screams and would beat any kaypro
hard disk. I also have a 512k Mdrive on s100 and it's plenty big
enough and fast. Fragile, neither.
<The virtual disk features with which I had contact were pretty memory
<hungry, in that they required a fair sized buffer in order to allow speedy
<caching of data from the drive from which it was being loaded. They
There were some ugly implmentations. The first one I did was in late '80
and was pretty tight. No banking and it left 56k(to the base of the BDOS)
for transient programs.
<or that it provide a buffer in lower memory so that the higher memory coul
<be switched in and out. This became quite taxing in terms of hardware
<resources and memory bandwidth.
I never ran out of either.
<You're certainly right about the observations you made of the effect of
<various floppy disk handling factors, e.g. sector skew, on performance.
<Since you're probably referring to SSSD floppies, which were not only the
<smallest but also the slowest, I can see why you might favor such a scheme
By late 82 I was running a 4 z80/6MHz multiprocessor system using CP/M2.2
as the core OS with a task manager added. I've done most all of it at one
time or another. I took advantage that statistically the data bus was
actually unused between 40-60% of the time! Z80 T1 and T2 states offer
very litle in the way of actual transfer activity other than preperation.
<The software overhead was burdensome only because it had to reserve quite
<bit of memory in order to block and deblock on a track-by track basis.
<That's why we didn't use ramdisk. One could manage disk I/O almost
<transparently when the disk was spinning at 3600 instead of 360 rpm.
Well to deblock you only needed a chunk the size of disk sector and
typically that was 256 or 512 bytes, trivial space. The code to do it is
under 512bytes. Giving up 1k for a huge increase in performance is worth
it.
Usually I would bump that host buffer up to at least the same size as the
allocation block size, as that meant you could cache a whole allocation
block. That usualy being either 2k or 4k. For that I would bank in a
small amount of ram in lowmem just for that and generally that was based
on the common size chips (2k or 8k x8 rams). later I would do a full MMU
for even more space for track buffers. the code to do basic deblock will
do any size with ease.
The latentcy even at 3600 rpm is low but that assumes DMA direct to ram.
most controllers had a small (usually 1-2 sectors) sized buffer and would
read to buffer and transfer from there.. added delays. Also those
controllers could be driven harder than the usual supplied drivers did
for far greater peformance. The bios often used the least efficient means
to move the selected 128 bytes to the target address. Considering how
often that was done it's a big hit. The average systems did not utilize
the possible performance of the z80 even at 4mhz. When 6 and 8mhz parts
started to show up they were often idling in loops waiting for something
to happen. Spooling printer and keyboard/modem interrupts were often not
done. So the user often never saw type ahead or any semblence of
concurrency. All of which were possible.
If there is a point, CP/M prevented nothing performance wise and usually
anything it did offer was not used (it can signal when to flush the cache).
Think like forground/background were easily done and there were a few print
spoolers that really worked.
Allison
>For one thing, I want to ask what a few of these items are. For one
>thing, what are the three identical units on the rightmost rack? Also,
>what is the tall unit right above the green PDP in the middle rack? Also,
>what is the top unit in the short blue rack?
If you check my home_systems web page, in the recent_acquisitions
section, I have the items listed.
To answer the question, in the first rack are 3 RL01s, 1 RX01, a
pdp-8/a and a pdp-8/e. In the second rack are TU56, 2 Diablo
(RK05 equivalents) and a lab-8/e (the section above the blue/green
8/e panel is the I/O area for data acquisition). The third rack
contains a laboratory peripheral system (LPS) which is a UNIBUS
option...
>Next question: Is there anything you can do with these that my DECMate
>can't do (besides peripherals that the DECMate doesn't have)
I will be able to copy data between multiple formats -- RK05, RL01,
DECtape, RX01. I'll be able to breadboard stuff that could be
connected to the lab-8/e... something not pictured is a display
scope on which the lab-8/e could display stuff by driving beam X and Y
and beam intensity.
>Last question: What did you use to make this picture?
Powershot 350 digital camera, downloaded to my PC, gamma-edited,
uploaded to the web page along with updates to the home_systems.html
page to point to the new picture...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
bill_r(a)inetnebr.com (Bill Richman) wrote:
> Teletype, so I'm pretty sure the Elf code is correct. I'm using 110
> bits per second, no parity, 8 data bits, one low (logic 0) start bit,
> and one high (logic 1) stop bit. It seems to like the data
I'm thinking that when you get down to 110 bps it is more usual to
use two stop bits (or one that's twice as long as a data bit).
-Frank McConnell
...Would Mr. Bill Pechter please respond, either to the list or to me,
with a valid E-mail address?
I cannot make either of the two I have work. I've got
pechter(a)pechter.ddns.org and pechter(a)ddns.org. Both bounce with timeout
messages.
Thank you. We now return to your normal programming.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bruce Lane, Owner and head honcho, Blue Feather Technologies
http://www.bluefeathertech.com
Amateur Radio:(WD6EOS) E-mail: kyrrin(a)bluefeathertech.com
SysOp: The Dragon's Cave (Fido 1:343/272, 253-639-9905)
"Our science can only describe an object, event, or living thing in our own
human terms. It cannot, in any way, define any of them..."
I agree that the ramdisk improved performance. It was just the
implementations that made the system so fragile once ramdisk was in place.
The usefulness of the ramdisk was limited by its size, and, since I had hard
disks back then anyway, the speed of which was nearly infinite as compared
with the floppies, it didn't improve things very much.
The virtual disk features with which I had contact were pretty memory
hungry, in that they required a fair sized buffer in order to allow speedy
caching of data from the drive from which it was being loaded. They
typically used a mini-bank switching arrangement on the order of what EMS
used in PC's at one time, which required your system be compatible with it
or that it provide a buffer in lower memory so that the higher memory could
be switched in and out. This became quite taxing in terms of hardware
resources and memory bandwidth.
Ramdisk didn't become interesting until I could copy a whole diskette to it.
Since that was much more easily accomplished with hard disk, I didn't devote
too much time to it.
You're certainly right about the observations you made of the effect of
various floppy disk handling factors, e.g. sector skew, on performance.
Since you're probably referring to SSSD floppies, which were not only the
smallest but also the slowest, I can see why you might favor such a scheme.
I seldom used SSSD except for interchange of data. Buffering a whole track
in memory while reading the next meant a fair amount of memory since the
same buffer was used hard disks and floppies. A hard disk track had between
32 256-byte sectors, and 10 1K sectors. With the Lark drive (SMD) it was a
bit more, but I don't remember the details. The sectors were odd-sized.
The software overhead was burdensome only because it had to reserve quite a
bit of memory in order to block and deblock on a track-by track basis.
That's why we didn't use ramdisk. One could manage disk I/O almost
transparently when the disk was spinning at 3600 instead of 360 rpm.
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 5:33 PM
Subject: Re: followup: Rinky dink hamfest
><I would mention that I had 128K in each of my Systems Group systems and
><never used it under CP/M. MP/M had a mechanism for cashing in on extra
><memory, but it was awkward at best under CP/M 2.2.
><
><Needless to say, the use of a RAMdisk would speed things up, but unless
><there was an extensive amount of software for managing it, and that took u
><too much TPA, even a RAMdisk didn't help much.
>
>Way off. Caching disks for CP/M-any (especally 2.2) is a huge performance
>boost. CPM suffers from waiting on the disk and often the difference
>between a slow system and a fast one is how the disks were handled. Having
>run ram disks, caches, caching controllers I have studied where the
>bottlenecks are and the most common is the CPU spinning in PIO or worse
>waiting for the sector to come around to do PIO.
>
>the software over head for caching is small. once you go over 128 byte
>sector size yo need a host buffer to deblock it... you can read a whole
>track in and deblock that. Free cache.
>
>Allison
>
Ok folks here is the deal...
Tony has his hand full with an impending move and work. I'm going to pickup
a truck (toyota) load of the stuff. I have first dibs on vax and Qbus
but will gladly share excess (there will be plenty!).
If it doesn't fit in the truck I will not be getting it.
If it can't easily be shipped UPS dont ask me to ship it.
I will ship stuff IF... It's under 30lb and fits in reasonable cardboard
boxes. I do not have a shipping dock or service so if I ship it, people
will pay for packing, and UPS. Just being upfront.
<If you can proxy any of it for people on the list, feel free. We just want
<to be rid of it before we move.
<
<According to Joan there is:
<1 11/03 Processor Boards
<1 11/23PLUS CPUs
<5 11/23 CPUs W/KTF11A
<2 32KWORD 16-bit MOS RAM
<2 SLU PLUS RTC Option (DL11-W)
<3 LSI-11/2 CPUs
<2 HD Parallel Line Units
<1 RX-01 Floppy Cont (U)
<1 16KWORD 18-bit RAM (U)
<1 M7809 ???? Who knows what this is?
<1 RL-01/02 Drive Controller (U)
<1 RD-51/52 & RX-50 Control Module
<3 DR11-C
<5 M8047 (16KWORD RAM, 2 ASYNCH SLU ROMS)
<1 4 SLU Interface
<2 16-Bit PLU
<1 11/34A CPU (3 boards)
<1 11/34A Programming Console
<1 Unibus Terminator & Bootstrap ROMs
<Assorted parity and terminator boards
<
<Computer Designs and Applications:
<1 MSP-3/A Memory Board
<
<MDB:
<1 MDZ-11
<1 MDL-11
<1 DRV-11c clone
<1 Q-Bus Terminator
<
<Paritech:
<2 VRG-Q (Color video card?)
<2 VCH-Q (mono video card?)
<
<Matrox:
<1 MDC-512-HS (U) (Mono video card)
<
<USDC:
<1 Some sort of controller card (HD? FD?) (U)
<
<Andromeda Systems:
<2 UDC-11X
<
<Analog Devices:
<4 D/A Board (DAS1150)
<
<Plessy:
<3 703521-001
<1 703680-100B
<1 703695-100E
<
<Charles River Data Systems:
<2 FC202
<
<National Instruments:
<1 179055-01 Rev G
<
<Chrislin:
<6 Memory Cards
<
<Intel:
<1 05-0848-012 (memory?)
<1 05-0787-002 (Unibus Memory?)
<
<Heath:
<3 WHA-11-5 (serial I/O?)
<2 H-11-2 (parallel I/O?)
<2 WHA-11-16 (16Kx16 Memory)
<
<Unknown:
<1 64k Memory???
<1 2010-60 (U)??
<
<MOSTEK:
<1 8001-H-00 (U)
<
<Yale EDL:
<3 Custom XYZ Plotter Controller (U)
<
<1 11/34A Enclosure W/Good PS
<1 DEC RL-01 W/25 Disk Packs (not an accurate count) W/unknown data
<1 Charles River DS 2xRX-01 Enclosure
<1 Chrislin??? RX-02 & 10MB HD and Enclosure
<1 Chrislin HD W/Enclosure
<1 Plessy?? 10/20MB Hard Drive W/Enclosure
<1 Bag-o-Cables for above stuff
<Full docs for almost everything (including RT-11 manuals)
<About 150 or so 8" disks
<
<
<Must pick it all up from us in Lawrence, MA before 4/6/1999 or I'm afraid
<we'll have to dump it all in the dumpster.
<
<Allison, take what you want off of here and forward the rest to the list.
<Its all first come first served, no holding of anything, no money, no
<trades, no shipping. If you want it, you come get it, if someone else
<already got it, then oh well.
<
Ok Megan, I'm officially Jealous.....
Nice Gear! (Especially the RK05 drives I've been looking for)... Congrats!
Jay West
-----Original Message-----
From: Steve Robertson <steverob(a)hotoffice.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 10:15 AM
Subject: RE: Picture of my latest haul
>
>>
>> For a quick route to the picture...
>>
>> http://world.std.com/~mbg/move_step00.jpg
>>
>> Megan Gentry
>> Former RT-11 Developer
>
>
>Very nice!!!
>
>Steve Robertson -<steverob(a)hotoffice.com>
>
>
-----Original Message-----
From: Marvin <marvin(a)rain.org>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, 30 March 1999 4:00
Subject: Re: Decwriter II
>It looks like the Paper Out signal goes into J3-6 of the keyboard assy. and
>goes into the main logic board on J2-AA/BB; the main board test point is
>TPZ17. It looks to be lo true judging by the pullup resistors.
Looks right, IIRC, the microswitch is tied to ground.
>it goes into E37 pin 12 (7474) and comes out on pin 9 as MPC8 Ready H.
Ok, that's what I needed to know, I'll have a play in that area, I think we
have a stuck
output here.
>test point is TPV20. I might add that the logic board I am looking at is
the
>M7728. I can scan in that portion of the schematic if you need it.
Ok, thanks, that would be great. I'll don't recall offhand the main board
id, I'll have a look later today.
Kindest Regards
Geoff Roberts
Periodically I swing by Surplus Property here. It's very disappointing;
there hasn't been anything exciting in a few years. Also, the University
gets first dibs at surplussed things; whatever survives is auctioned off in
big lots. So whatever interesting things ARE there tend to either disappear
again or be sold with a pallet of uninteresting things.
Having said that, I did see a good amount of Model 100s and their
accessories (disk drives, manuals) and a couple of other Tandy things
(cassette recorders). Is any of this especially rare? Some machines might
be model 102s, since I saw the 102 tecnical manual. It would be a fair
amount of effort to get everything; I might be able to convince the surplus
people to make the Tandy stuff their own lot, but I'm not optimistic about
that.
-- Derek
please see comments imbedded below.
regards,
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 5:30 PM
Subject: Re: Rebirth of IMSAI
><signals? I guess it's no wonder people liked the 8085, with its silly
muxed
><data/address bus better than the 8080 . . .
>
>The 8085 had different control signals, didn't require 3 voltages, a clock
>chip, a bus control chip, was faster and allowed better memory timing.
Yes, but, moreover, it had two signals to tell you when to read and when to
write, and it had two signals telling you whether your target was memory or
I/O. The fact that it had those essentially useless (for this environment)
multi-level interrupts internally, or that it had the bizzarre (for the
time) serial I/O on chip, was relatively uninteresting in light of the
benefits of fewer power supplies, faster operation, internal clock
generation, less critical timing, and lower parts count.
><Soooo . . . the signals were named the same also, eh? pSYNC, /pWR, sMEMR,
><etc???
>
>Follow them back to the 8080. it should answer themselves. Also the 8080
>muxed status on the data bus at the early part of the cycle so the control
>signals reflect the raw 8080 status and control for the most part.
Unfortunately, all my 8080's appear on Multibus-I cards. I've NEVER owned
an S-100 8080 CPU. In fact, it wasn't until there were some single-board
computer boards on the S-100, e.g. SD Sales' SBC-100 that I even considered
using S-100 for anything.
>That's why board with 8085 and Z80 had all sorts of screwy logic to take
>their mostly decoded controls and encode them.
I certainly agree on that one! Half the logic on most of my later CPU cards
was dedicted to making the processor create the 8080-compatible signals
required for the bus. It takes less logic to implement a floppy controller,
two serial ports, a parallel port or two, and a full compliment of DRAM on
an S-100 board than it takes to make the a Z-80 or 8085 appear to the bus to
be an 8080.
>Allison
>
<be cross-referenced to the '696 standard signal names. I do hve the 8080
<data in house, but nothing tying it to the S-100 bus pinout or timing.
Someone must have the imsai or altair cpu board schematic on the net.
If not get Bursky's The s100 Bus Handbook.
<One of the reasons the S-100 required such fast memory for its relatively
<slow processors was that you had to operate relatively complex timing
<structures to create proper timing. That's a reason the standard, in my
<considered opinion, killed the S-100 rather than perpetuating it. Intel
No. The 8080 had short timing thats all. Then the later z80s wer faster
and wanted fast (relatively) memory. Bus speed was never a problem and was
good for 10mhz if terminated.
<result of course, was the chaos that results when surplus vendors e.g.
<CompuPro/Godbout (cited here because they were BIG, not because they were
Compupro was one of the closest to 696 early on!
I say this as I likely have more operational and in use S100 hardware than
most.
Allison
<For one thing, I want to ask what a few of these items are. For one thing,
<what are the three identical units on the rightmost rack? Also, what is
<the tall unit right above the green PDP in the middle rack? Also, what is
<the top unit in the short blue rack?
I'll leave this for Megan to map.
<Next question: Is there anything you can do with these that my DECMate
<can't do (besides peripherals that the DECMate doesn't have)
Not much other than the difference in expansion capability. However for
much of the PDP-8 software the 8E is the "standard" for many devices in
the IO realm. One thing does stand out... you can load core with a
program, power off and years later power up and execute that program.
Allison
<I would mention that I had 128K in each of my Systems Group systems and
<never used it under CP/M. MP/M had a mechanism for cashing in on extra
<memory, but it was awkward at best under CP/M 2.2.
<
<Needless to say, the use of a RAMdisk would speed things up, but unless
<there was an extensive amount of software for managing it, and that took u
<too much TPA, even a RAMdisk didn't help much.
Way off. Caching disks for CP/M-any (especally 2.2) is a huge performance
boost. CPM suffers from waiting on the disk and often the difference
between a slow system and a fast one is how the disks were handled. Having
run ram disks, caches, caching controllers I have studied where the
bottlenecks are and the most common is the CPU spinning in PIO or worse
waiting for the sector to come around to do PIO.
the software over head for caching is small. once you go over 128 byte
sector size yo need a host buffer to deblock it... you can read a whole
track in and deblock that. Free cache.
Allison
<>The problem in a nutshell, don't open any messages in a Microsoft E-Mail
<>program with the following title "Important Message From: {persons name}"
<
<The solution in a nutshell... run Linux, or some other more reasonable
<OS...
Actually it's the problem of word and email tightly meshed. Add to the
mix a programming language (VB macros) and you've got an open door to an
otherwise insecure system.
I run win3.1 and don't have Word so I have no problem. Though another OS
or better yet another processor would kill the bug straight out.
Allison
<signals? I guess it's no wonder people liked the 8085, with its silly muxe
<address bus better than the 8080 . . .
The 8085 had different control signals, didn't require 3 voltages, a clock
chip, a bus control chip, was faster and allowed better memory timing.
<Soooo . . . the signals were named the same also, eh? pSYNC, /pWR, sMEMR,
<etc???
Follow them back to them 8080 it should answer themselves. Also the 8080
muxed status on the data bus at the early part of the cycle so the control
signals reflect the raw 8080 status and control for the most part.
That's why board with 8085 and Z80 had all sorts of screwy logic to take
their mostly decoded controls and encode them.
Allison
If you have to align an 8"drive, the alignment diskette is pretty essential,
i.e. you can't really do well without it. The 5.25" diskettes are about as
easy to manage with software and one of the "digital alignment diskettes" if
you can get them.
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 6:46 PM
Subject: followup: Rinky dink hamfest
> Today I went to see a couple of the people that I meet at yesterday's
>hamfest. One of them used to service XEROX computers. He told me that he
>threw out three rooms full of old XEROX computers less than a year ago. :-(
> He gave me part of the stuff that he had left, I have to take a Truck
>(note capital) back to get the rest (estimated at two cubic yards but no
>complete machines). So far I've found lots of docs and 8" flopppy disks
>for the 820 and 16/8. The 16/8 looks pretty interesting, it ran CPM,
>CPM-86 and MS-DOS. Does anyone have one of these? What's your opinion of
>them?
>
> He has a floppy disk drive control box to manual operate 3.5", 5.25" and
>8" drives during alignment. Anyone have an idea of what one of these is
>worth with the alignment disks and manuals?
>
> Alos found a Lisa mouse to go with the Lisa that I got yesterday.
>
> Joe
>
Pretty snazzy looking stuff! If you get bored with the TU-56, I'd love to
take it off your hands!! :-)
-- Tony
>> For a quick route to the picture...
>>
>> http://world.std.com/~mbg/move_step00.jpg
>>
>> Megan Gentry
>> Former RT-11 Developer
Can now be found on my home_systems web page... just go to my
home page, follow the link to retrocomputing, then to home
systems...
I've got the pictures all loaded, I just have to start doing the
writeup...
For a quick route to the picture...
http://world.std.com/~mbg/move_step00.jpg
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
I have a Sage IV computer out on loan to a company that is using it on
their production line. It turns out that they need to use it for longer
than expected which means that they are concerned about Y2K problems with
the hardware. (They need for another year possibly)
I offered to ask around so if there is anybody out there with a Sage IV I
would like to talk to them. They are investigating too but any data I can
get would be most welcome.
Thanks
--
Kevan
Collector of old computers: http://www.heydon.org/kevan/collection/
I don't know why I posted the previous empty reply . . . it's hell getting
old . . . <sigh>
I would mention that I had 128K in each of my Systems Group systems and
never used it under CP/M. MP/M had a mechanism for cashing in on extra
memory, but it was awkward at best under CP/M 2.2.
Needless to say, the use of a RAMdisk would speed things up, but unless
there was an extensive amount of software for managing it, and that took up
too much TPA, even a RAMdisk didn't help much.
Dick
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 11:07 AM
Subject: Re: followup: Rinky dink hamfest
>
>-----Original Message-----
>From: Joe <rigdonj(a)intellistar.net>
>To: Discussion re-collecting of classic computers
><classiccmp(a)u.washington.edu>
>Date: Monday, March 29, 1999 8:26 AM
>Subject: Re: followup: Rinky dink hamfest
>
>
>>At 08:40 AM 3/29/99 -0500, you wrote:
>>>Joe, CP/M-80 is 2.2,
>>
>> I looked throgh the XEROX manuals last night. There's a separate manual
>>for 2.2, CPM-80 and CPM 86 and MS-DOS 2. 2.2 is the oldest in this bunch.
>>
>>> and real computers don't need more than 64K...
>>
>> Yeah I know but 128K is nice to have.
>>>
>>>The 820, at least the later ones, used big 984K discs. I hardly ever ran
<snip>
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 8:26 AM
Subject: Re: followup: Rinky dink hamfest
>At 08:40 AM 3/29/99 -0500, you wrote:
>>Joe, CP/M-80 is 2.2,
>
> I looked throgh the XEROX manuals last night. There's a separate manual
>for 2.2, CPM-80 and CPM 86 and MS-DOS 2. 2.2 is the oldest in this bunch.
>
>> and real computers don't need more than 64K...
>
> Yeah I know but 128K is nice to have.
>>
>>The 820, at least the later ones, used big 984K discs. I hardly ever ran
>>out of space. There was an 8 meg rigid drive available too, but I neever
>>filled that up either. WordStar on the 820 just grinds along, and works
>>very satisfyingly.
>
> I got new manaul and 8" disk with WS 3.3. Also D-Base II and some other
>stuff.
>
>> At least 3 word processing packages were avialable
>>plus business graphics, multiplan, quite a few programming languages.
>>XWP wasn't so great, apparently a primitive WordStar, WordStar was superb
>>if cryptic, and there was another nice one, a bit glitzy and modern for
>>my taste, but put WordPerfect to shame, but hey, even a blank screen does
>>that. Don Maislin may remember the name, he likes that particular
>>programme. Ran very well on 5-1/4 inch drives.
>>
>>There was a memory expansion available for the 16/8, but I've never seen
it.
>>The DEM-II is interesting because the card rack is very like the NEC
APC-II.
>>
>>Incidentally, Hyperion's DOS 1.25 runs circles around the Xerox DOS 2.0.
>
> Do you know where I can find a copy of that? Do you still have any of
>your XEROXs? I think I have the CPU portion of an 820-II here but no
>drives (or the controller/daughter board) and no keyboard. The drives and
>keyboard should be a problem but the controller is.
>
> Joe
>>
>>On Mon, 29 Mar 1999, Joe wrote:
>>
>>> Merle,
>>>
>>> At 10:24 PM 3/28/99 -0500, Merle wrote:
>>> >The 16/8 is an interesting machine. It came in 2 versions, the
earliest
>>> >with 8" Shugart drives, a later with a DEM-II expansion case housing
>>> >5-1/4 inch drives. The CP/M-86 is not bad, but the MS-DOS is...well
>>> >MS-DOS.
>>>
>>> Not surprising considering it's only ver 2.0 . At least that's what I
>>> got in this load.
>>>
>>> > Incredibly primitive compared to CP/M 2.2.
>>>
>>> I don't know that much about CPM but this machine only has CPM-80 and
>>> CPM-86. How do they compare to CP/M 2.2?
>>>
>>> One problem is that
>>> >many were shipped with 128K memory. With the dinky drives, the
machines
>>> >are disappointing. The old 8" 820-II is a far better and more usable
>>> >machine.
>>>
>>> Better than the 16/8? I thought it was newer. How much memory did
the
>>> 820-II have?
>>>
>>> Thanks for the info.
>>> Joe
>>>
>>> >
>>> >On Sun, 28 Mar 1999, Joe wrote:
>>> >
>>> >> Today I went to see a couple of the people that I meet at
yesterday's
>>> >> hamfest. One of them used to service XEROX computers. He told me
>that he
>>> >> threw out three rooms full of old XEROX computers less than a year
>ago. :-(
>>> >> He gave me part of the stuff that he had left, I have to take a
Truck
>>> >> (note capital) back to get the rest (estimated at two cubic yards but
no
>>> >> complete machines). So far I've found lots of docs and 8" flopppy
disks
>>> >> for the 820 and 16/8. The 16/8 looks pretty interesting, it ran CPM,
>>> >> CPM-86 and MS-DOS. Does anyone have one of these? What's your
>opinion of
>>> >> them?
>>> >>
>>> >> He has a floppy disk drive control box to manual operate 3.5",
>5.25" and
>>> >> 8" drives during alignment. Anyone have an idea of what one of these
is
>>> >> worth with the alignment disks and manuals?
>>> >>
>>> >> Alos found a Lisa mouse to go with the Lisa that I got yesterday.
>>> >>
>>> >> Joe
>>> >>
>>> >>
>>> >
>>> >M. K. Peirce
>>> >Rhode Island Computer Museum, Inc.
>>> >215 Shady Lea Road,
>>> >North Kingstown, RI 02852
>>> >
>>> >"Casta est qui nemo rogavit."
>>> >
>>> > - Ovid
>>> >
>>> >
>>>
>>>
>>
>>M. K. Peirce
>>Rhode Island Computer Museum, Inc.
>>215 Shady Lea Road,
>>North Kingstown, RI 02852
>>
>>"Casta est qui nemo rogavit."
>>
>> - Ovid
>>
>>
>
GAWD! The 8080 data sheet! I wonder if my archives go back that far . . .
I know the signals are modeled after the 8080, but are they all 8080
signals? I guess it's no wonder people liked the 8085, with its silly muxed
address bus better than the 8080 . . .
Soooo . . . the signals were named the same also, eh? pSYNC, /pWR, sMEMR,
etc???
Is there a web site which has details on the 8080=>'696 standard decision
tree?
Dick
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 8:12 PM
Subject: Re: Rebirth of IMSAI
><I've been after the original spec's for the IMSAI pre-1977 bus timing, etc
><in case anyone has that data in shareable form.
>
>Read the 8080 data sheet for the part running a 2mhz clock... the rest is
>obvious to the point of painful.
>
><I've found the schematic for my IMSAI PIO-6 board but only half the manual
><fortunately with the schematic, of the PIO-4. I don't seem to have any bu
><timing informtion, though.
>
>Thre wasn't any bus timing info published. The S100 bus was based on
>the raw 8080 timing. All the bus was is the buffered 8080 signals plus a
>few handy ones. A quick look at the processor board is everything.
>
>Allison
>
This appears to me to be an intermittent trace on the main board's video
addressing logic I'd look in the counter chains. Careful examination of the
boad may enable you to find it.
Dick
-----Original Message-----
From: Doug Spence <ds_spenc(a)alcor.concordia.ca>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 4:18 AM
Subject: Messed up Apple (clone) video
>
>Hi,
>
>Along with a dead 4116 (which I recently replaced with a hacked 4164),
>my Microcom II+ (Apple II+ clone) has a video problem which has kept me
>from using it for the past few years.
>
>Usually when it's cold, the display is a complete mess. As it warms up,
>the image becomes clear but in four parts. Each quarter (corner) of the
>screen is a mini-image of what should be displayed on the whole screen.
>Out of each group of four pixels of what would be displayed normally, each
>will be displayed in a different quadrant of the screen.
>
>After about 10 minutes, the screen becomes normal, with occasional "zaps"
>and returns to the quartered screen image.
>
>Just about everything in the II+ is TTL, so it's probably just a matter of
>knowing which piece of TTL to replace. Does anyone know?
>
>I'm looking at the schematics (for a _real_ Apple II) now, but I have no
>idea how to locate the problem because there are several lines leading to
>the video output, and the problem chip may be farther back into the
>curcuitry and not connected directly to the output.
>
>I know that some of you are fairly expert with Apple hardware.
>
>I want to get the Microcom II+ working because it's the only machine I've
>got that's capable of using my Z80 Softcard or my SMC-II Light Pen.
>Neither will work in my Apple //e.
>
>Besides, it also has a better keyboard than the //e, once it's been worked
>in to cure the 'bounce'.
>
>
>(As an addition note on the machine's history:
>The machine was repaired at the Microcom store in early 1987, and it came
>back with a loose, drifty keyboard. I found out the reason was that the
>keyboard's curcuit board had been cracked and the keyboard only works if
>it's not screwed in too tightly. I'll get around to looking at that after
>the video is fixed. It's just one corner that's folded a bit, but there
>are traces on there! The keyboard tends to report the wrong characters
>when it's screwed in properly.)
>
>--
>Doug Spence
>ds_spenc(a)alcor.concordia.ca
>http://alcor.concordia.ca/~ds_spenc/
>
<In return for her help, she took the pdp-8/f (smaller unit than the
<pdp-8/e), a core stack from the -8/e, and a second serial line card.
<
<I believe she is pleased... I know I am...
You bet! I've wanted a physically small 8 to hack with for years.
This was lots of fun saving some really unique interesting machines.
Now to go through the bring up for a machine that may have been sitting for
too long. Any thoughts out there on the 8F power supply? I plan to pull
all the cards and load it so I don't cook anything.
<I took pictures and hope to document the procedure at some point
<in the future...
This was a fun move and Megan made it easier to do it by being persistant
and finding a good rental truck vendor with a liftgate. Nice truck!
Everything moved and none broken. A handy item to have are the nylon web
straps. They are handy to keep stuff on slides from sliding and also made
securing the racks to the walls of the truck. Other things were plenty of
rope and a good pair of movers dollies.
Allison
>Who was the nut who mounted the CPU units near your ankles? Looks like
>you're suposed to lie on your belly in order to read the displays and
>toggle the switches!
Well, the lowest of the machines (the pdp-8/e and pdp-8/f) were
actually not even configured for operation... they were simply
stuck in the racks, taking up space. The 8/f now has a home with
Allison, so there is empty space in the 11/34 rack... which I will
probably fill with an RL01 (or RL02 if I can find one).
The pdp-8/a, which doesn't have any blinkenlights, was the actual
operating machine for the person who owned it before... its
backplane can handle a hex board, which was required for the RL8
controller, apparently.
The 8/e is currently out of the rack as I figure out what I'm going
to do next...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
As single-card-single-box CP/M systems went, these were about as good as any
you could get back in the lat '70's-early '80's. They were well equipped
with documentation and human support. There was a users' group which
supported them as well.
Dick
-----Original Message-----
From: Kevan Heydon <kevan(a)heydon.org>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, March 29, 1999 6:41 AM
Subject: Superbrains in the UK.
>
>I have a lead on a couple of Superbrains available here in the UK. I am
>not interested but if anybody else is then I can pass on the details.
>
>--
>Kevan
>
>Collector of old computers: http://www.heydon.org/kevan/collection/
>
>
>
> For a quick route to the picture...
>
> http://world.std.com/~mbg/move_step00.jpg
>
> Megan Gentry
> Former RT-11 Developer
Very nice!!!
Steve Robertson -<steverob(a)hotoffice.com>
On Monday, March 29, 1999 12:17 AM, Don Maslin [SMTP:donm@cts.com] wrote:
> On Sun, 28 Mar 1999, Richard Erlacher wrote:
>
> > If you have to align an 8"drive, the alignment diskette is pretty essential,
> > i.e. you can't really do well without it. The 5.25" diskettes are about as
> > easy to manage with software and one of the "digital alignment diskettes" if
> > you can get them.
>
> I am pretty sure that they are still available from:
>
> Accurite Technologues, Inc.
> 231 Charcot Avenue
> San Jose CA 95131-1107
>
> - don
Looks like the disks are still available.
http://www.accurite.com/Products.html
Steve Robertson - <steverob(a)hotoffice.com>
I have a lead on a couple of Superbrains available here in the UK. I am
not interested but if anybody else is then I can pass on the details.
--
Kevan
Collector of old computers: http://www.heydon.org/kevan/collection/
As usual, contact the person in the post, not me... I don't have anything
to do with the machines...
- - - - -
Rainbow and DECMate fans:
Please feel free to cross-post in full to any and all interested LISTSERVS and
groups:
The Press of Atlantic City NJ is about to begin unloading its supply of
well-maintained (and heavily used) DEC Rainbows, and possibly other equipment
as well, including one or more PDP-11/84s(? the last -11 built, the
half-height equivalent of the PDP-11/70) with lots of heavy-duty port
equipment, etc.
The monitors, keyboards, and I believe power supplies, chasis components and
disk drives are identical to those used on the DECMates and some parts seem
identical to components of the earlier VT 1XX and 2XX terminals.
Final negotiations between newsroom/pressroom management, MIS and corporate
are now underway. It appears the situation will be 12 will go immediately upon
paperwork approval, with another three dozen or so, operating, plus parts, to
follow.
Tentative price for working machines with 2 floppies, no HD, a random
monochrome monitor (green, white or amber) and random keyboard (many with
special labels on keys for the editing system) and varying amounts of
memoryis $25, +packing and shipping, or $25 for direct pickup in
Pleasantville, NJ (southern NJ, about 12 miles inland from Atlantic City)
We (them of us who have used the machines and kept them alive) would prefer
seeing them used or put on display or put to use repairing DECMates rather
than scrapped.
The price for the -11s and/or their components have not been set, but they are
due to be out of service by December.
Software is a question - I believe the machines can be released with MS-DOS
3.10, but licenses for the newsroom and classified advertising systems would
probably have to be negotiated separately. While the Rainbows have passed my
personal Y2K basic complience tests (they keep running and reporting the right
date) I have not done any file creation or editing tests. MS-DOS 3.10 is NOT
supposed to be Y2K complient.
The newsroom software (I forget the vendor) and PDP-11 software in use is
reportedly NOT Y2K complient, and you wouldn't want to try to run a newspaper
off one of these systems anyway unless you're still using Linotypes.
Please post any offers to tips(a)pressplus.com and note in the first line of the
body of the message Attention: David M. Razler. I'll pass them on to the folks
doing the selling and arranging the shipping.
PLEASE - Do not respond to originating address of this message.
dmr
David M. Razler
david.razler(a)worldnet.att.net
http://www.the-dock.com/club100.html
is a good place to find info and software for the Model T (100 and the
likes). ther is also a very active mailing list where one can gather a lot
of information about the Model T (even though it seems like the Y2K is a big
issue these days) you can subscribe from the link above.
I'm not sure what a complete set is, a nice system would include the disk
drive (there were various models) a memory extension and any eripheral that
could be available.
Apparently the Model T has still a large base of users.
Francois
>Isn't there some really active Model 100 mailing list or newsgroup even?
-----Original Message-----
From: Lawrence LeMay <lemay(a)cs.umn.edu>
>Well, There were model 100, then 102, then 200. I doubt that anything
>came with it out of the box except a manual of some sort.
>
there was also a model 80
- Mike: dogas(a)leading.net
you go girls.
;)
Mike: dogas(a)leading.net
-----Original Message-----
From: Megan <mbg(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 7:00 PM
Subject: The move is accomplished!
>
>It's finally been done... after many weeks of talking about it and
>not having it happen, Allison and I drove up to New Hampshire this
>morning and drove back with a couple of tall (H960, 6') racks with
>the following:
>
> pdp-8/a
> pdp-8/e
> pdp-8/f
> lab-8/e
> pdp-11/34a
> vr14
> lps
> DECwriterII
> 3 RL01s
> 1 RX01
> 3 Diablo RK05-work-similar
> TU56 DECtape dual drive
>
>Funny thing... the pdp-8/e was originally Allison's... she had given
>it several years ago to the guy from whom I got all of the above...
>In return for her help, she took the pdp-8/f (smaller unit than the
>pdp-8/e), a core stack from the -8/e, and a second serial line card.
>
>I believe she is pleased... I know I am...
>
>I took pictures and hope to document the procedure at some point
>in the future...
>
>Now to get them all wired back up and tested out...
>
> Megan Gentry
> Former RT-11 Developer
>
>+--------------------------------+-------------------------------------+
>| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
>| Unix Support Engineering Group | (home): mbg!world.std.com |
>| Compaq Computer Corporation | addresses need '@' in place of '!' |
>| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
>| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
>| (603) 884 1055 | required." - mbg |
>+--------------------------------+-------------------------------------+
>
>p.s. YIPPEE!!
>
>
>Now to go through the bring up for a machine that may have been sitting
>for too long. Any thoughts out there on the 8F power supply? I plan to
>pull all the cards and load it so I don't cook anything.
Didn't a post come through here just earlier today about someone
offering a pdp-8/f power supply for $30?
>This was a fun move and Megan made it easier to do it by being persistant
>and finding a good rental truck vendor with a liftgate. Nice truck!
>Everything moved and none broken. A handy item to have are the nylon web
>straps. They are handy to keep stuff on slides from sliding and also made
>securing the racks to the walls of the truck. Other things were plenty
>of rope and a good pair of movers dollies.
I'm going to document all that we used... since I'm taking chemistry,
it may just end up looking like a lab report... (abstract, apparatus
used, procedures, actual write-up)...
At this point I'd like to heartilly recommend Budget Rentals. They
do have lift-gate trucks... the one I got was 15' with 7' inside
vertical dimension. The truck is 11' total height, it handled really
well, and the 90 mile move was about $65 itself. Unfortunately, since
the budget place wasn't open today, I had to rent yesterday, for two
days, so the total price will be higher.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
I recently rented a Budget cargo van one-way from Seattle to Los
Angeles, and filled it with about 1.5 kilopounds of DEC Stuff.
I drove straight thru all one day. The van was comfortable,
handled well, got great gas mileage, with a handy cruise control.
1139 miles in 18 hrs.... but all-in-all a nice trip.
It was $269 plus the petrol... so if you're contemplating a
Rescue Mission, you might try your local Budget place.
And, I'm not a Budget employee, nor do I play one on Television!
Cheers
John
On Sun, 21 Mar 1999, Lawrence Walker <lwalker(a)mail.interlog.com> wrote:
> Would stand to reason AES would be a Canadian company. Dorsey now heads
> Voice and Data Systems. A major player in packet technology. Sounds like a
>
> minor version of Corel's Cowpland. Yes Virginia ,Canada does have a
> computer
> aristochracy.
>
Here in Ottawa, old AES boxes used to turn up fairly often. But I don't
recall if they were the 7100 model that Doug described. I think the
Canadian government must have used hundreds of the things for word
processing, and they used to show up in junk stores and even the occasional
garage sale. Haven't seen one for a while, Doug, but I will keep my eyes
open for boot disks or anything else AES, just in case. Also, if you need a
blank hard-sectored floppy to test-feed your uncooperative new house-guest,
send me your address and I'll pop one in the snail-mail.
--
Arlen Michaels amichael(a)nortelnetworks.com
>The problem in a nutshell, don't open any messages in a Microsoft E-Mail
>program with the following title "Important Message From: {persons name}".
The solution in a nutshell... run Linux, or some other more reasonable
OS...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
I don't know how much a couple of hundred bucks is worth to you. You can
use an operational S-100 computer running CP/M, or even an 820 to run the
drive for alignement. Though I've had an alignment tool for many years, I
usually use a computer. It's the alignment diskettes that are scarce.
If you have a digital alignment diskette, made by Dysan, among others, and
the software to run one, it makes alignment easy. If you need to read a
5-1/4" floppy, a drive you can buy today won't help you much. I keep a half
dozen of the old DS minifloppies around.
regards,
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 9:14 PM
Subject: Re: Drive alignment tool, diskettes
>At 07:08 PM 3/28/99 -0700, you wrote:
>>If you have to align an 8"drive, the alignment diskette is pretty
essential,
>>i.e. you can't really do well without it.
>
> Yes I know, I used to repair and alignment drives. What I wanted to
>know is what the whole setup is worth and weather I should buy it. He
>wants a couple of hundred bucks for it. He said it cost ~$3500 new.
>
> The 5.25" diskettes are about as
>>easy to manage with software and one of the "digital alignment diskettes"
if
>>you can get them.
>
> I doubt 5.25" drives are worth reapiring, even if you could get the
parts.
>
> Joe
>>
>>Dick
>>
>>-----Original Message-----
>>From: Joe <rigdonj(a)intellistar.net>
>>To: Discussion re-collecting of classic computers
>><classiccmp(a)u.washington.edu>
>>Date: Sunday, March 28, 1999 6:46 PM
>>Subject: followup: Rinky dink hamfest
>>
>>
>>> Today I went to see a couple of the people that I meet at yesterday's
>>>hamfest. One of them used to service XEROX computers. He told me that he
>>>threw out three rooms full of old XEROX computers less than a year ago.
:-(
>>> He gave me part of the stuff that he had left, I have to take a Truck
>>>(note capital) back to get the rest (estimated at two cubic yards but no
>>>complete machines). So far I've found lots of docs and 8" flopppy disks
>>>for the 820 and 16/8. The 16/8 looks pretty interesting, it ran CPM,
>>>CPM-86 and MS-DOS. Does anyone have one of these? What's your opinion
of
>>>them?
>>>
>>> He has a floppy disk drive control box to manual operate 3.5", 5.25"
and
>>>8" drives during alignment. Anyone have an idea of what one of these is
>>>worth with the alignment disks and manuals?
>>>
>>> Alos found a Lisa mouse to go with the Lisa that I got yesterday.
>>>
>>> Joe
>>>
>>
>>
>
<>for too long. Any thoughts out there on the 8F power supply? I plan to
<>pull all the cards and load it so I don't cook anything.
<
<Didn't a post come through here just earlier today about someone
<offering a pdp-8/f power supply for $30?
I don't know this one is bad, only that I have to test it well before
subjecting boards to it. Even if it were bad I'd repair it, that part of
the fun.
Allison
-----Original Message-----
From: Allison J Parent <allisonp(a)world.std.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Monday, 29 March 1999 11:56
Subject: Re: The move is accomplished!
><I took pictures and hope to document the procedure at some point
><in the future...
Be interested to see them...
>Everything moved and none broken
Good catch / nice work ladies.
I have to move a 6410/6240/HSC70/RA9x/TA79 Cluster in a couple of weeks.
I hope it goes as well for me. (But it probably won't).
Cheers
Geoff Roberts
Computer Systems Manager
Saint Mark's College
Port Pirie, South Australia.
Email: geoffrob(a)stmarks.pp.catholic.edu.au
ICQ #: 1970476
Phone: 61-8-8633-8834
Mobile: 61-411-623-978
Fax: 61-8-8633-0104
<The Xerox 820 is one I really liked for a while. It only supported
<single-sided single density drives, but had on-board terminal-style video
They were quite popular as when Zerox got out of cpm those were cheap and
common.
Other really nice boards were the amproLB and the SB180. the SB180 was
1985 design and offered the 64180 (z180) that had a MMU and a bit more
speed.
Allison
<I've been after the original spec's for the IMSAI pre-1977 bus timing, etc
<in case anyone has that data in shareable form.
Read the 8080 data sheet for the part running a 2mhz clock... the rest is
obvious to the point of painful.
<I've found the schematic for my IMSAI PIO-6 board but only half the manual
<fortunately with the schematic, of the PIO-4. I don't seem to have any bu
<timing informtion, though.
Thre wasn't any bus timing info published. The S100 bus was based on
the raw 8080 timing. All the bus was is the buffered 8080 signals plus a
few handy ones. A quick look at the processor board is everything.
Allison
At 07:56 AM 3/28/99 -0800, you wrote:
>
>Might this be a chassis for a TI9900 system, Allison?
Yeap, I think it is. I found "TM 990/520" marked on the MB. Guess I'll
leave it alone for the time being. Anybody need it? I have to get some of
this stuff out of here and I don't really have the room to keep it.
>
>If so, I'd leave it in tact as bait for the cards that go with it.
>Otherwise, if you modify it you'll attract S-100 cards with the edge
>connectors cut off. :(
Not if I move the MB over and modify the card cage.
Joe
Nope, the 99/4 was never intended to fill any niche other than the
home/video-game market. The 990 series was a "business minicomputer" while
the 9900 was a microcomputer development environment. It's kind-of like
comparing a 747 with a bicycle. Each has its place, of course.
Dick
-----Original Message-----
From: Max Eskin <max82(a)surfree.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 10:44 AM
Subject: Re: Just another Rinky-Dink Florida hamfest
>On Sun, 28 Mar 1999, Richard Erlacher wrote:
>>Yes, that's probably a chassis for a 9900 system. I once marveled at the
>>similarity to S-100 when it was shown to me in a TI sales office when I
was
>>considering using TI's 9940 single-chip microcontroller in a product.
>
>Is this thing in any way related to the TI-99/4A expansion box?
>
>--Max Eskin (max82(a)surfree.com)
>
I bet you're going to be disappointed in the TI chassis, Joe. TI made (back
in the '70's) a line of their microcomputers which used a connector and a
card form-factor like the S-100, sort-of, but which wasn't S-100. One easy
way to tell the difference, I believe is that the TI system, which I never
inspected, hence can't say for certain, used a global power supply rather
than the s-100's on-card local regulation. Their power and other supply
leads were in different places, too.
Let me know if I'm wrong, Joe, as I hope you're getting something you can
use, but something tells me . . .
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, March 27, 1999 12:51 PM
Subject: Just another Rinky-Dink Florida hamfest
> Went to another one this morning. Didn't find much except three Lisas
>(two Lisa 2s and one Lisa 2/10), two HP 715/50s, two Zorbas and a *NICE*
>S-100 chassis made by TI. I managed to get the L 2/10 and the Zorbas.
>Pictures and questions to follow.
>
> Joe
>
> PS the HPs are still available if anyone wants them.
>
The Xerox 820 is one I really liked for a while. It only supported
single-sided single density drives, but had on-board terminal-style video
circuitry (24 lines of 80 characters) and used a BIOS which could be banked
in and out, which I don't know for certain even banked in the entire BIOS.
I once concluded that it only banked in the parts it needed at the time,
thereby leaving a larger TPA. I'm probably wrong about this, but I don know
the hardware was present to allow this.
With the addition of a little daughterboard from Denver Business Systems,
which replaced the 1771 FDC on the board, the device was double-density
capable once the BIOS was patched.
I even made and sold a daugherboard which replaced the CPU in order to
interface WD1000-05 and 1002-05 boards (bridge controllers) by Western
Digital. Both this board (the 820) and the TVI 80x seemed to be pretty
solid boards for CP/M.
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 6:46 PM
Subject: followup: Rinky dink hamfest
> Today I went to see a couple of the people that I meet at yesterday's
>hamfest. One of them used to service XEROX computers. He told me that he
>threw out three rooms full of old XEROX computers less than a year ago. :-(
> He gave me part of the stuff that he had left, I have to take a Truck
>(note capital) back to get the rest (estimated at two cubic yards but no
>complete machines). So far I've found lots of docs and 8" flopppy disks
>for the 820 and 16/8. The 16/8 looks pretty interesting, it ran CPM,
>CPM-86 and MS-DOS. Does anyone have one of these? What's your opinion of
>them?
>
> He has a floppy disk drive control box to manual operate 3.5", 5.25" and
>8" drives during alignment. Anyone have an idea of what one of these is
>worth with the alignment disks and manuals?
>
> Alos found a Lisa mouse to go with the Lisa that I got yesterday.
>
> Joe
>
I've thrown out LOTS of 8" drives. I have a few packaged and, in some
cases, powered single as well as double sided drives if anyone is willing to
pay the freight.
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 6:46 PM
Subject: Re: Hard-sectored 5.25" disks
>At 06:34 AM 3/28/99 -0500, Doug wrote:
>
>
>>Maybe next month I'll drag home something with an 8" drive. :)
>>
>
> Doug, how far are you from British Columbia? I know where there's a
>Tektronix 4051 AND a 4052 up for sale. Both can use optional 8" drives, I
>think they have drives but I'm not sure. I'm in Florida, so it's a mite too
>far for me to go get.
>
> Joe
>
Speaking of the rebirth of IMSAI . . .
Has anyone seen anything new on their web page? I've been following a few
of the items and have seen no changes since the 20th or so.
I'm not sure of the market for a hot pentium system packaged behind an Imsai
trademark and front panel. I'd much rather see them pick up the support
thread for the already existing Imsai-branded hardware and publish the
existing doc's on their web site. I'm sure there is a market for between 50
and 500 of each of several boards, and, if he already has the rights and the
artwork, reproducing the originals. If he ( Todd Fischer ) made them,
perhaps to order, and perhaps with a dry-film solder mask and high-quality
bright-white silk screened legends, with some jumper definitions as are on
many no-longer-current PC ISA add-ons, to distinguish between the old boards
and the new as well as to minimize the support requirements, I don't think
he'd lose his shirt.
I've been after the original spec's for the IMSAI pre-1977 bus timing, etc,
in case anyone has that data in shareable form.
I've found the schematic for my IMSAI PIO-6 board but only half the manual,
fortunately with the schematic, of the PIO-4. I don't seem to have any bus
timing informtion, though.
Any help with this would be appreciated.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, March 28, 1999 2:25 PM
Subject: Re: Rebirth of IMSAI
>> As the purchaser of mostly Thrift-Store Classics (i.e. incomplete, dirty,
>> sometimes broken machines for $10 and less) I really don't know what was
>> being displayed in the showroom. I remember the cool 3D wireframe stuff
>> on the Northstar Advantage, the Juggler and Boing! demos on the Amiga,
the
>> aforementioned Christmas Demo, and that's about it.
>
>
>There was a (tape) program for the TRS-80 model 1 called (IIRC) Micro
>Marquee. It let you type in a message and it would display it on large
>characters built from the graphics blocks (something like about 12
>characters/line, 3 lines/screen), scrolling up the screen.
>
>There was a default built-in message which seemed to be advertising for
>the machine. Something like 'Hello, I'm the new TRS-80 computer that
>you've heard so much about...' I've always assumed that was a shop demo
>program.
>
>There was a demo program for the PERQ. It showed some very fast graphics
>(windows moving over the screen, lines being drawn, etc). AFAIK, they
>_were_ being created in real-time - it wasn't just a set of full-screen
>bitmaps. Don't think you could call it a 'store demo', though.
>
>-tony
>