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.
<
