<What extra do you (as a software hacker) get from this chip that you
<wouldn't get from a software emulator of the Eniac running on (say) a PC?
A grade in an EE course where there is a required project to create a
system on a chip. In software 311 you do the emulator for the PC.
;)
Allison
In a message dated 5/29/99 6:28:09 PM Pacific Daylight Time,
pete(a)dunnington.u-net.com writes:
> Yes, but shipping to the UK would be too expensive :-)
Effective May 30th, 1999 the United States Postal Service changed it's
"Global Priority Flat Rate Envelope" service to $9 US for up to 4 pounds if
it will fit in a USPS 10"X12" Envelope.
This size package would take a couple of S100 cards wrapped in anti-stat &
bubble wrap.
This is a much cheaper international rate that the USPS is starting to
promote. Their web site is www,usps.com. The rate calculators work best. The
new international rate sheet is in Adobe pdf format and loads slowly (19
pages). The calculators are html but are not updated yet.
A 6"X8" envelope is $5, and, I think, up to 4 pounds. I have used the small
envelope to ship software to Hong Kong.
Hello, all:
Does anyone remember this Hayes novelty? I saw a pic in an old magazine
and thought what a neat idea -- a serial programmable clock in the same case
as a Hayes Modem.
If anyone comes across one of these, I'd be interested in it. Also, if
anyone has a manual for this, let me know. In the absence of an actual
clock, maybe I can hack one together with Stamp.
[ Rich Cini/WUGNET
[ ClubWin!/CW7
[ MCP Windows 95/Windows Networking
[ Collector of "classic" computers
[ http://highgate.comm.sfu.ca/~rcini/classiccmp/
[ http://highgate.comm.sfu.ca/~rcini/pdp11/
<---------------------------- reply separator
The place where you get the results of an ENIAC is, of course, in the
programming of this single-chip ENIAC emulator. Now, I too, would
like to have the real thing (how many were made?) but, I do not
expect my want to be fulfilled. Yet, via this chip, I may still afford
myself
the pleasure of programming an ENIAC. For the hardware tinkering
people on this list, I can understand their dissatisfaction. For those
of us who want to experience the software/user side of things, this
chip is not so much of a disappointment.
William R. Buckley
From: Christian Fandt <cfandt(a)netsync.net>
>Amen, Max. The only thing one would probably get out of that 'radio' would
>be a work-alike thing. Exactly the same for that ENIAC-on-a-chip.
>Work-alike, probably, but no where near the same as having either the real
>thing or a functional replica with tubes/relays/other fun parts.
>
>Regards, Chris, an old radio collector (or rather, collector of old radios
:)
Hi all,
Today I bought a SC/MP wirewrapped board. Does anyone know of a site with a
data sheet? My search came up with what is known as "SC/MP II", including a
description of a "MK14" project in Practical Electronics mag. In
particular, the chip on my board requires an unknown neg. voltage on pin
40, instead of +5 Volts on the later NMOS versions. The actual part No. is:
ISP-8A/500D
Thanks,
-Dave
<A last thought on this for you legal guys out there! Would'n it be
<sensible to design some kind of 'declaration of trust' regarding private
<content of equipment. So that the receivers can be held responsable for
No, you that declare you are repsonsable where you formally were not.
You then place yourself in a position of trust for the data. If your disk
cleaning efforts were not adaquate and someone read them and misused the
findings YOU ARE IN TROUBLE and the original owner can sue you for breech
of contract. Liability is then directed to you, and the original owner
then has limited libility, both the donator and thir clients can sue you
for cause. Don't go there unless you want to make it a business.
<any irrisponsable disclosure of private data. And also that the donator
<has signifies that he has (had) knowledge about the informational
<content of his donation. In serious cases a Judge may decide who has
<acted liable. But most of ours would live by such a contact and it may
<endorse reliable image about the restoration and preservation of classic
<hardware & software.
If it's important, maybe. Consider that no responseable source of
significant equipment would leave mission critical data or files behind
unless the equipment were inoperable. In that case you may wish to operate
as an agent to that donator... be careful as you are taking the role of
a contract engineer to them and if you fail to recover the data and loose
it or fail to remove it totally you may be in trouble. Again desireable
equipment may warrent.
I did some checking and here is my lawyer friends call:
You get a system with stuff on the disk.
They (donator) failed to perform due dilligence and due care in maintaining
confidence. IF and unless there is a provable agreement that data is fair
game. The however of this is while they may loose in a suit, everyone
would in the process so long as there is not malicious intent on the part
of the person that recieved the equipment. They (donator) would injure
themselves, their clients and it would cost to defend. In short you can
be sued, they would likely loose, it's costly to win on both sides and the
would not help anyone and would hut everyone.
Best bet is if you find crap on the disk and have not been asked or told,
delete it and forget it.
Allison
<Hi all,
<Today I bought a SC/MP wirewrapped board. Does anyone know of a site with
<data sheet? My search came up with what is known as "SC/MP II", including
<description of a "MK14" project in Practical Electronics mag. In
<particular, the chip on my board requires an unknown neg. voltage on pin
<40, instead of +5 Volts on the later NMOS versions. The actual part No. is
<ISP-8A/500D
That is the early Pmos part (SC/MP and not the II) and the voltage there
is -7v (Vgg). Never saw that particular schematic (Practical Elect.) there
was one in an early kiloboaud, byte or interface age you could look at for
more info.
I have a working example of the inexpensive board national sold with that
chip, 256bytes of ram and a monitor.
I'd doubt there is a site with a data sheet unless someone got permission
form National Semi to scan one.
Allison
<It uses about 175,000 transistors! Wow, what an increase, just think of a
<computer with 175,000 triodes, and compare that to an ENIAC (much less,
<the power required). Or some years later, one with 175,000 discrete
<transistors. Now that I remember, this was a thread some months ago... top
<speed, etc.
<-Dave
Your babbeling. The original use some 15000 tubes of single and dual types.
The interconnecting logic used many diodes. What is missed is the in many
of the tube (early transistor too) machines pulse transformers, diodes and
capacitors were used to interconnect logic elements. To perform the same
logical function of a tube FF on a CMOS FPGA/FPLA you will not less than
6-10 transistors due mostly to differeing interconnect schemes and tube
logic have load resistors where cmos having a complmentary transistor. The
difference showing in the power used (15KW VS ~1-2W).
The key is they are implementing archetecture not direct circutry.
Allison
<> There are various systems like this. The most common (in my limited
<> experience) being a JTAG boundary scan. Basically, some LSI devices have
<
<The system Tera uses is quite similar, except that it extends to the intera
<circuitry of the chip rather than just the boundary (pins) of the chip.
Look again. They are likely the same thing. Most boundary scan approaches
allow not the pin level output but a snapshot of the core logic to be
brought out as a serial bit stream on just a few pins. It is an
approximation of the PDP-8 style front pannel where most of the internal
working can be seen in lights and allow diagnosing say a stuck bit in the
ACC or core.
Allison
<>uPD414 is the equivalent of a 4027 DRAM (4096 x 1bits). What's a 2414?
<> Did you mean 2114, or 2147?
I was wrking for NEC when that part was current. I have an old catalog and
the MK4027 was the one I was trying to remember.
Allison
well . . . we all know what those are. This makes a great deal more sense!
Dick
-----Original Message-----
From: Don Maslin <donm(a)cts.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, May 29, 1999 9:55 PM
Subject: Re: Vintage S-100 cards
>On Sun, 30 May 1999, Pete Turnbull wrote:
>
>> On May 29, 16:28, Don Maslin wrote:
>> > Subject: Vintage S-100 cards
>
>________O/_______
> O\
>
>> uPD414 is the equivalent of a 4027 DRAM (4096 x 1bits). What's a 2414?
>> Did you mean 2114, or 2147?
>
>Bit of a slip twixt (thought) cup and (finger) tip. I think 2114 was the
>reference I intended.
>
> - don
>
>
Hi,
Today I bought what I thought were three 4MB 72-pin SIMMs. On closer
examination, they have *80* pins, and were made by Digital in 1991.
It says 5019144-01 A1P2 on the boards.
Some questions:
- what system would these have been used in?
- how much might they be worth?
- does anyone need any 4MB 80-pin SIMMs?
-- Mark
I am a radio collector. I know what you're saying. I have one of these
"Modern" radios - it's a Crosley Metro. While it would fool a non -
collector, since it looks like the original, a collector would know that the
tape deck doesn't belong there :)
What should be done, is that a "knobs and switches (and whatever else is
needed)" interface that hooks to the "modern" interface, with the chip in it
(or just put the chip in the other interface). While not being the
original, it'll still give the feel of the original. It'll use a LOT less
power, too :)
///--->>>
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
-----Original Message-----
From: Max Eskin <max82(a)surfree.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, May 29, 1999 1:48 PM
Subject: Re: ENIAC-on-a-Chip
>
>Maybe you don't see what I'm saying (and I don't know any reason for
>insults, either). Let's say you're a radio collector. You want a certain
>old radio, which you would never be able to own. Somebody gives you a
>modern radio with the same circuit layout but the old components have been
>replaced by modern ones. Such a radio could fit on a circuit board 2"
>sq. if done with surface mount. It works the same way. Would you take this
>radio, and say 'hell, if I want, I can add the old-fashioned knobs later'?
>I doubt it. Now, granted, this is the only kind of ENIAC anyone will ever
>be able to own, but I'm dubious about how similar the experience would be
>to running a real ENIAC.
>
> --Max Eskin (max82(a)surfree.com)
> http://scivault.hypermart.net: Ignorance is Impotence - Knowledge is
Power
>
>
Look what those wacky college students are up to now:
http://www.ee.upenn.edu/~jan/eniacproj.html
Sellam Alternate e-mail: dastar(a)siconic.com
------------------------------------------------------------------------------
Don't rub the lamp if you don't want the genie to come out.
Coming this October 2-3: Vintage Computer Festival 3.0!
See http://www.vintage.org/vcf for details!
[Last web site update: 04/03/99]
Sellam:
Comments like this are a bit condecending, lacking a kind
disposition to others. Your point is important but, you could
give it without so much venom.
William R. Buckley
If you're so indignant you can always build a "knobs and
>switches" interface to settle your neurosis.
>
>Sellam Alternate e-mail:
dastar(a)siconic.com
>---------------------------------------------------------------------------
---
On May 29, 16:28, Don Maslin wrote:
> Subject: Vintage S-100 cards
>
> I just acquired a number of vintage (circa 1977) S-100 cards. They are
> listed below:
>
> 3) Processor Technology 16k(?) RAM cards - one fully populated with
> NEC uPD414C chips, which I take to be a 2414 clone. The other
> two seem to have all of the glue chips, but no RAM. They are
> identified in silkscreen as ASSY NO.203000 and in etch as 16KRA.
uPD414 is the equivalent of a 4027 DRAM (4096 x 1bits). What's a 2414?
Did you mean 2114, or 2147?
> Anybody care? Anyone interested? Any offers?
Yes, but shipping to the UK would be too expensive :-)
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
At 10:37 PM 5/28/99 -0700, Sam wrote:
>
>Look what those wacky college students are up to now:
>
>http://www.ee.upenn.edu/~jan/eniacproj.html
>
It uses about 175,000 transistors! Wow, what an increase, just think of a
computer with 175,000 triodes, and compare that to an ENIAC (much less,
the power required). Or some years later, one with 175,000 discrete
transistors. Now that I remember, this was a thread some months ago... top
speed, etc.
-Dave
I have to admit, the 2414 is a strange number to me also. I looked up the
NEC DRAMs though, and the uPD414C would have been equivalent to a MOSTEK
MK4027. Remember, MOSTEK was the industry leader in DRAMs in the mid-'70's.
This number predates my NEC data, but uPD416C would have been the 16K
version.
Dick
-----Original Message-----
From: Pete Turnbull <pete(a)dunnington.u-net.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Saturday, May 29, 1999 7:27 PM
Subject: Re: Vintage S-100 cards
>On May 29, 16:28, Don Maslin wrote:
>> Subject: Vintage S-100 cards
>>
>> I just acquired a number of vintage (circa 1977) S-100 cards. They are
>> listed below:
>>
>> 3) Processor Technology 16k(?) RAM cards - one fully populated with
>> NEC uPD414C chips, which I take to be a 2414 clone. The other
>> two seem to have all of the glue chips, but no RAM. They are
>> identified in silkscreen as ASSY NO.203000 and in etch as 16KRA.
>
>uPD414 is the equivalent of a 4027 DRAM (4096 x 1bits). What's a 2414?
> Did you mean 2114, or 2147?
>
>> Anybody care? Anyone interested? Any offers?
>
>Yes, but shipping to the UK would be too expensive :-)
>
>--
>
>Pete Peter Turnbull
> Dept. of Computer Science
> University of York
A 2100S in good condition is a nice find. Is it just me or did the 2100/21MX
line of HP gear suddenly get popular with collectors in the past 6 months or
so? <grin>
You wrote...
>Some of these are pretty obvious about their functions,
>but does anybody have any idea what the "DUP REG" functions
>are?
There were two boards in the 2100/21MX line called DUP REG. They were the
8-bit duplex register PCA and the 16-bit duplex register PCA. They are
general purpose I/O interfaces. I know for sure that the 8-bit board was
used almost exclusively for paper tape readers or paper tape punches. I've
never seen the 16-bit board in use, so I'm not sure what it was used for.
>I'm speculating that the black section is the memory subsystem
>for the machine, and that the ID & DC boards have something
>to do with memory addressing, decoding, etc.
As I recall, you are correct in your speculation.
>That's all the info. I have right now. Doesn't look to
>me like there are any terminal I/O type interfaces in
>the box. I haven't had the nerve yet to power it up
>to see if it does anything. If any of ya'll have any info.
>about this machine, I'd appreciate a shout.
The 2100S gave you a choice of several different terminal interfaces. Most
common for general use was the 12531A, B, C, or D. Most common for
scientific use was the (IIRC) 12766 BACI. Also, the power supply in the
2100A/S was er.... not the best example of HP's usual over-engineering.
Check those voltages with dummy loads before you sacrifice some cards :)
I've got a fair amount of docs on the 2100A/S, but check out Jeff Moffat's
website, he has some decent manuals online.
Jay West
I just acquired a number of vintage (circa 1977) S-100 cards. They are
listed below:
3) Processor Technology 16k(?) RAM cards - one fully populated with
NEC uPD414C chips, which I take to be a 2414 clone. The other
two seem to have all of the glue chips, but no RAM. They are
identified in silkscreen as ASSY NO.203000 and in etch as 16KRA.
1) Polymorphic Systems 8k RAM card. It is fully populated with
2102 chips. It is a product of Interactive Products Corp.
1) Processor Technology Helios II Controller - presumably for an 8"
drive (two 50-pin headers). No LSI.
1) Processor Technology Formatter. Based on its 50-pin header and
the header's location, I infer that this card is part of a two
card set that is the Helios II listed above. Again, no LSI.
1) Percom Cassette/Terminal I/O card. Carries one each male and
female 10-pin connector. Also has an SMC COM2502 chip (40-pin).
There is a ~2x4" breadboard area on one end of the card.
Obviously, I have no way to know if these cards are functional.
However, they are clean and not beaten up.
Anybody care? Anyone interested? Any offers?
- don
<As an aside, there have been laser printer interfaces where the host
<computer gets to control the laser engine control signals directly,
<rather than talking to a 'formatter board' that turns
<text/graphics/postscript/whatever into a suitable bitmap for printing.
DEC LN03P (~1988), a video print engine. Used a bit map in the host
computer wuth serializer, there is still a small embedded micro to cotrol
the basinc mechanics. FYI: due to construction and process laser printers
have to keep the paper moving or the image will be a mess.
The most extreme was the LPS40 (DEC, 12/27/1997) that literally had a
BA23 microvax in the base to do, networking, distributed queue management,
Postscript to raster engine interpretation. It was then handed to a 4board
set (bimaps and display list to raster bitmap engine) and set serially to
the printengine. The printengine had 1 8085 to manage the system, 3 8749s
to manage the mechanics and a 78pg11 to handle the large capacity paper
input. All that was to print complex postscript pages at 40ppm. That
seems obscene but starting one piece of A4 paper every 1.5 second plus
between three and four peices in transit is not a trivial task. Then there
was the Xerox 9700 (120ppm) monster (10+running feet of laser printer.).
<Of course this is a slightly higher level than talking to the mechanics
<directly, since you have a signal to tell the printer to start a page
<rather than having to control the motor and clutches directly. But still,
<the host computer has to monitor the Beam Detect signal and send suitably
<timed pixels to the laser control input.
Beam detect is a sync signal and it's all done in hardware. You get a sync
and start DMAing data to a serializer at a preset clock rate. Not much
different than driving a tube.
<I've seen (and probably still have somewhere) plastic daisywheels with a
<metal pin for the '.' , just to make the last a little longer when used
<like this.
My first plotter was a modified daisy mech, no daisy and a pin brazed to the
solinoid. Good to 200 dpi or so.
Allison
<How big is the LPS40? Can the microvax be programmed ( :) )? BTW, do you
Roughly 30Dx 48Wx 38H.
The microvax was running a downloaded image that was the exec and postacript
interpreter. Programmable, very, as postscript has it roots in forth and
contains all of the same or similar primitives plus the printing
libraries.
<know if the Xerox machines use any kind of common computer? At school, we
Several different ones depending.
Allison
Hello,
Just a quick question; I have an old NEC 3x external SCSI CDROM, and
i'm in need of a CDROM for my VAXstation 3100. Assuming I found the
right cables, could that CDROM be used?
-paul
--
paul(a)paul.dragontear.org [a paradigm of a paramount failure]
>How big is the LPS40? Can the microvax be programmed ( :) )? BTW, do you
>know if the Xerox machines use any kind of common computer?
Many Xerox laserprinters use a J11-based (same CPU chip as PDP-11/73, 83,
84, 93, and 94) controller. Some have it on a Q-bus backplane, but
most J11-based Xerox engines that I've seen have their own custom bus.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Here's someone wanting to sell their PET 2001-32 (new style keyboard).
Please reply directly to the seller.
Reply-to: sharonklee(a)netzero.net
---------- Forwarded message ----------
Date: Sat, 22 May 1999 22:31:36 -0400
From: SLee <sharonklee(a)netzero.net>
Commodore Pet Personal computer with built in screen-- the tag on the back
says "Pet 20001-32" Come with a tape drive and a dual flopy disk drive.
Both are separate from the main unit but connected by cable. The tag on
the back of the dual floppy says "Commodore dual floppy 2040 serial number
407680"
excellent condition. protected with plastic cover
Both are in working condition
Cables are available.
Come with orginial manuals and pet magazine and game magazine
---
Sellam Alternate e-mail: dastar(a)verio.com
-------------------------------------------------------------------------------
Puttin' the smack down on the man!
Coming this October 2-3: Vintage Computer Festival 3.0!
See http://www.vintage.org/vcf for details
[Last web site update: 05/25/99]
> Two large chassis (size of old fridge) rolled into the salvage yard near
> me, labeled MassPar and one of them has 8 big, I think, MFM drives in it.
> Anybody know what this stuff is, or have interest in it? Its cheap, and
> looks intact and very good shape.
It's a massively parallel supercomputer containing thousands of four bit
processors. It's a SIMD model; i.e., the thousands of four bit processors
are all executing the same instruction simultaneously. MassPar was working
on special FORTRAN and C compilers to run the thing. It's controlled by
a Digital Ultrix workstation, either a Firefox or a DECstation 5000 depending
on its age.
Roger Ivie
ivie(a)cc.usu.edu
Yes, '81 was pretty late . . . CP/M-86 came out then, as did PC-DOS.
Within a few years, nobody wanted to be limited by the same systems they
coveted only a few years earlier. By '81, the Apple][ could be equipped
with a Z80 board, a "real" FDC (Sorrento Valley Associates ?) an 80x24
display, and a hard disk if you could afford it. I recently sold the
prototype of the original Apple HDC I made up in the spring of '81 together
with my first ST-506.
Those were the days . . . <sigh>
Today I can still run CP/M but at an effective clock rate of 83MHz on my
notebook . . . designing hardware involves thousands of lines of HDL, weeks
in front of a simulation, and when it's done, I can't even hook up an
instrument small and fast enough to inspect it because even our government
can't afford one. One has to design circuits with 25% overhead so they can
be inspected. Oh, well . . .
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: Thursday, May 27, 1999 8:54 PM
Subject: Re: Re[4]: Bringing up a CPM
><If you're writing your own, it might be well to keep in mind that the BIOS
><used in several late-generation CP/M systems used device drivers which
coul
>
>It was late generation in 1981! I started doing it then. CPM had a formal
>product called CP/M+ (CP/M3.0) to extend that idea.
>
><California Computer Systems (CCS) had a pretty nice boot process in which
><they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest
memor
><in which they claimed they could run. It wrote that to the boot blocks,
>
>Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
>you would run movcpm on to get the xxK version you wanted.
>
><then, under the control of that skeletal system, they loaded a "full-size"
><(you get to define that!) CP/M and transfer control to it. It's pretty
><solid and makes the preparation of a bootable disk a straightforward if no
><a quick process.
>
>Yes and they were doing it a long time back, Compupro too. Kaypro was one
>of the few "boxed" system that had the rom mapped to get a large TPA.
>
><IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
><mapped into the TPA during file transfers, or something on that order. If
>
>Classic.
>
><your machine can handle that, it saves on BIOS size, especially tables,
etc
><and, generally speaking, if the READ operations from the TPA are from
><temprorarily mapped-in PROMs, you can overwrite the TPA in the event you'r
><loading overlays, with complete impunity. That way your
blocking/deblockin
><buffer space can still reside in high memory.
>
>An IMSAI can neither handle that nor not handle that. The basic design
>had no rom! To do that you need a prom card with a little bit of hardware
>to map it with an IO port.
>
>The key here is to get a working system in whatever space... Why, it's the
>development platfrom for itself. Once you have it running and can poke and
>understand it the improvements will come.
>
>Allison
>
>
> -----Original Message-----
> From: Don Maslin [SMTP:donm@cts.com]
> Sent: Thursday, May 27, 1999 6:47 PM
> To: Discussion re-collecting of classic computers
> Subject: RE: What's a "computer console" selectric called?
>
> On Thu, 27 May 1999, Arlen Michaels wrote:
>
<snip>
> > Actually, the biggest challenge in interfacing this thing to a computer
> was
> > to sort out how to read one particular status signal from one of the
> > microswitch contacts in the print mechanism, so your computer could
> start
> > sending the next character at just the right moment before the
> mechanical
> > cycle completely finished. Else your software had to pause a few
>
> Didn't you also have to feed it EBCDIC instead of ASCII in order for it to
> 'understand' what you wanted printed?
>
> - don
>
<snip>
I don't think the Model 735 Selectric could even handle EBCDIC directly. I
seem to recall the electrical interface was defined as tilt-and-rotate
signal names. My Selectric terminal certainly didn't do any translation by
itself from character-codes to solenoid signals, at least not from ASCII. I
had to do translation myself before sending to the printer. One way would
have been with hardware between the computer and the Selectric, eg- using an
eprom to translate each ASCII code into the correct combination of Selectric
tilt-and-rotate signals. My lazier way was to simply put a look-up table in
my driver code, to intercept each ASCII character enroute to the printer and
translate it into the appropriate pattern of solenoid signals first.
Imagine if you had to drive a dot-matrix print head with raw pin-driver
signals instead of the printer hardware figuring it out for you : same kind
of problem.
Some vendors did indeed supply an interface that took ASCII from the
computer and sent the necessary tilt-and-rotate signals out to the
Selectric.
Arlen
--
Arlen Michaels amichael(a)nortelnetworks.com
Nortel Networks, Ottawa, Canada
I called them printing terminals. They had a keyboard, a printer and usually
a serial interface.
Besides IBM, Xerox had the 1610 Printing terminals based on the 630 printer
mechanism. There was one based on the NEC spinwriter printer. GTE had the
Termnet series of printing terminals (300 & 2120s) and of course the
venerableTI Omni 7XX series of thermal printing terminals.
If you find one of these I may have manuals.
Paxton
On May 28, 10:37, Arlen Michaels wrote:
> Subject: RE: What's a "computer console" selectric called?
> > From: Don Maslin [SMTP:donm@cts.com]
> > On Thu, 27 May 1999, Arlen Michaels wrote:
> > > Actually, the biggest challenge in interfacing this thing to a
computer
> > was
> > > to sort out how to read one particular status signal from one of the
> > > microswitch contacts in the print mechanism, so your computer could
> > start
> > > sending the next character at just the right moment before the
> > mechanical
> > > cycle completely finished. Else your software had to pause a few
> >
> > Didn't you also have to feed it EBCDIC instead of ASCII in order for it
to
> > 'understand' what you wanted printed?
> I don't think the Model 735 Selectric could even handle EBCDIC directly.
I
> seem to recall the electrical interface was defined as tilt-and-rotate
> signal names. My Selectric terminal certainly didn't do any translation
by
> itself from character-codes to solenoid signals, at least not from ASCII.
I
> had to do translation myself before sending to the printer. One way
would
> have been with hardware between the computer and the Selectric, eg- using
an
> eprom to translate each ASCII code into the correct combination of
Selectric
> tilt-and-rotate signals. My lazier way was to simply put a look-up table
in
> my driver code, to intercept each ASCII character enroute to the printer
and
> translate it into the appropriate pattern of solenoid signals first.
> Imagine if you had to drive a dot-matrix print head with raw pin-driver
> signals instead of the printer hardware figuring it out for you : same
kind
> of problem.
>
> Some vendors did indeed supply an interface that took ASCII from the
> computer and sent the necessary tilt-and-rotate signals out to the
> Selectric.
Coincidentally, last weekend I was going through old magazines from 1979,
and found a pair of articles by Roland Perry in Practical Computing (the UK
magazine, January/February 1979) describing a Selectric interface.
According to the articles, there were three types: BCD, correspondence, and
BCD-converted-to-correspondence. All of them use tilt-and-rotate codes,
which vary according to the golfball type (BCD or correspondence) and the
keyboards differ as do the golfballs. The interface was pretty simple (8
SSI TTL ICs, 14 driver transistors) but the contacts had to be re-wired to
suit the terminal version. The driver code used a lookup table to convert
ASCII to interface signals, sent 8-bit-parallel from an I/O port on an
8080, with two handshake lines.
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
Well after crossing my fingers I got 24 TK-52-K 1/2" tape cartridges in the
mail today. I've now got a reasonable amount of media for my TK70 to chew
on. These were DEC labelled tapes interestingly enough. They come with a
check box to indicate "296 MB" or "95 MB" and it appears that one can use
them in a TK50 as well? That would be pretty cool (not that I have a TK50,
but if I did it would be cool :-) A couple of questions of course ...
1) Can use in either drive? Restrictions?
2) Is it possible to write a TK50 bootable tape on a
TK70?
Also I signed up for DECUS so that I could get the OpenVMS media, but
haven't heard back from DECUS.org, (its been a week). Are these guys slow?
--Chuck
Hi,
I’ve got a rather small problem with my old PS/2 laptop. I don’t know which
power supply I have to use with it. Can somebody tell me (exactly) which
power supply I have to use (voltage, needed current,…). Can I use the 5-12 V
/250 W switching power supplies from PC’s? Is there any fuse or surge
protection built in the L40, protecting the motherboard from too high
voltage? I’ve tried it with an unstabilized 14 V transformator, and it
worked for a short time, then the thermo-fuse in the transformator switched
off. The L40 got two ways powering it, through the battery slot (three pins,
+, -, ?) and/or using the power supply adapter. Now I need to know which of
these two possibilites should I use when I have not got any batteries or
accus, and need an stationary power supply which has an clear, stabilized
voltage, which is the easier way?
These are the specs of the machine:
Machine: IBM PS/2 Model L40 SX
Proc.: i386DX @ 20 Mhz
RAM: 2 Mb(the two blue memory slots are still free)
HDD: 60 Mb
FDD: 3,5” 1.44 Mb
Mail all hints and/or advices to evilnet_genesis(a)yahoo.com or
evilnet_genesis(a)hotmail.com. If nobody can’t help me then please give me
some links or adresses, where I can find informations.
Thank you!
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
At 10:37 AM 5/28/99 -0500, you wrote:
> <snip>
>
>I don't think the Model 735 Selectric could even handle EBCDIC directly. I
>seem to recall the electrical interface was defined as tilt-and-rotate
>signal names. My Selectric terminal certainly didn't do any translation by
>itself from character-codes to solenoid signals, at least not from ASCII. I
>had to do translation myself before sending to the printer. One way would
>have been with hardware between the computer and the Selectric, eg- using an
>eprom to translate each ASCII code into the correct combination of Selectric
>tilt-and-rotate signals. My lazier way was to simply put a look-up table in
>my driver code, to intercept each ASCII character enroute to the printer and
>translate it into the appropriate pattern of solenoid signals first.
>Imagine if you had to drive a dot-matrix print head with raw pin-driver
>signals instead of the printer hardware figuring it out for you : same kind
>of problem.
In the CDC-3300 and 3500, most of the "logic" in the operator console, as I
remember from the prints, was related to driving the console typewriter.
The "API" for the typewriter was a BCD (6 bit) similar to the "native" code,
but included (in an enhanced mode of operation selected by a console button)
shift codes for selecting lower case/upper case and some extra type-ball
codes. Normally the printer ran in UPPER CASE only with a few BCD codes
stolen for carriage return, tab and backspace. No other functions
were available in the normal mode of operation.
I'd guess the logic for this took about 50 or so circuit modules (little
3x3 inch cards with a few transistors each - probably the equivalent to
a single TTL IC in functionality. I don't recall if there was a diode
rom, though.
As for ASCII, the 3300 didn't know nothing about ASCII. However, if you
had the BDP (Business Data Processor) as an option, you could do ASCII
string operations (including some arithmetic, if I recall.) e.g.
"strcpy" and "strcmp" were single instructions (after some setup code.)
But the BDP was a dog and crashed a lot. It was only used by the Cobol
compiler.
>
>Some vendors did indeed supply an interface that took ASCII from the
>computer and sent the necessary tilt-and-rotate signals out to the
>Selectric.
>
>Arlen
>--
>Arlen Michaels amichael(a)nortelnetworks.com
>Nortel Networks, Ottawa, Canada
Gary
Hi,
On 24 May 1999 Jason (the General) wrote:
> I just got two IBM Optical drives, complete with drivers, controllers,
> operator's manual, and service manual.
Nice. I have a 3363 drive myself, but no controller or docs. How big are the
manuals?
> -Are there updated drivers for these drives? The ones that cane with it run
> the driver as a DOS shell, which takes up a bunch of memory, and slows down
> the entire computer (also won't work with Windows).
There *are* a couple of 3363-related files on the IBM PC BBS, but I doubt they
are significantly better than the drivers you have already.
ftp://ftp.pc.ibm.com/pub/pccbbs/options/3363driv.exe
142869 11-14-90 3363 Optical Disk Drive Opt Dsk V.1.02D
ftp://ftp.pc.ibm.com/pub/pccbbs/dos_util/3363.zip
281665 05-24-90 Original 3363 opt dsk ver 3.3 & lower.
> - Does anyone have an ISA controller card for one of these drives? Both
That's just what I'm looking for to see whether my 3363 actually works. Please
let me know if you ever get hold of a spare.
> - Sometimes, when I put in a disk, and try to read it, I get a "General
> Failure" error. I take the disk out, put it back in, and it works. I think
> there was a discussion about this before. Do I just need to clean the
> disks?
It wouldn't hurt. The lens inside the drive may also be dirty/dusty. It's not
fun to disassemble the drive in order to expose the lens.
As for cleaning the disks, try this:
- wear plastic gloves to avoid getting oil from skin on disk surface
- breath on disk surface and wipe radially with a folded-up kitchen towel
- rotate the disk using finger through centre
- do the same for the other surface.
> -The drives that I have are 3363's, and the disks I have are 3363 200MB
> Single Sided cartridges (IBM). Can I use other types of Optical disks, or
> do I have to use the IBM 3363 ones?
No, as far as I know the 3363 uses proprietary disks, you can only use the IBM
ones. I bet the disks aren't available any more, though it wouldn't hurt to
ask IBM about this. If they are available, you can bet they'll be expensive.
> I've heard (I think it was on this list) that the 3363 is a WORM drive.
> However, it allows you to delete files, but you don't get any added space
> when the file is deleted (as if the file is still there). If the file is
> actually gone, where did the empty space go, and is there any way to get it
> back? Or is the file still there, and it being 'deleted' is it just an
> optical illusion (no pun intended)?
Basically, the file is just marked as deleted in the directory (which will
always be at the end of the written part of the disk). It is still physically
on the disk. Depending on how the driver software works, it may or may not be
possible to access previously-deleted files.
Once a disk is full, you can't write to it again. You can't reformat a disk.
(In its operation you can think of the 3363 as similar to a CD-R drive using a
UDF filesystem -- I think.)
-- Mark
>> a PC. Another technique I have used when I didn't have immediate access
>> to a wiping program (and *think* it is okay although not as good as
>> doing a wipedisk) is to overwrite the offending file with another
>> larger one, i.e. "copy [bigfile.ext] [offending file.ext]" and of
>> course, then deleting the
>
>This may not work. On RT11 (I think) it certainly won't work.
Right...
>What some OS's do is create the new file in a suitable (contiguous) free
>area on the disk and then mark the existing file as unused space. RT11
>does this because all files have to be contiguous on that OS.
Good explanation...
>Of course then the original (deleted) data is still on the disk.
Yep...
>Deleting files and then compressing an RT11 disk should be OK unless the
>files are at the end of the disk. Compressing and then creating a large
>file (large enough to overwrite the rest of the disk) should be safe.
Unfortunately not... the only way to guarantee it is if there are LOTS
of files on the disk, and the file deleted existed at a point in the
directory less than the total size of all the following files. Too much
to have to check before you are sure it is gone...
Teh creation of the large file simple creates a directory entry... the
actual disk surface defined by the new entry is not touched, so the
data could still be there, hidden inside the larger file. Now if you
did something to that file to overwrite it's contents, then it would
be gone.
It's been a while since I had to do this, and I had a program to do it
for me anyway... but on a stock RT-11, you might be able to mount the
file as a logical device, then FORMAT or INIT it, or do a COPY/DEV
to it...
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 |
+--------------------------------+-------------------------------------+
In my previous post I mentioned the 13037 handling 7900A drives. It does
not.
7900A drives use a 13210 controller.
7905/7906/7920 and I think 7925 use the 13037 controller.
The 13037A and 13037B are different mainly in the number of drives it will
support. The B model will support more (8 i think), the A only four as I
recall...
The 13037C will support HPIB drives like the 7906H as well as the 7906
"standard" variety.
Sorry for the boo boo.
Jay West
>> I think you're talking about RT-11, Allison, but I may be wrong because
>> the utility name you specify and the options you're talking about make
>> no sense under RT-11. Are you maybe talking about some other OS?
>>
>> Under RT-11, it's not PIP, it's DUP, and the option is /G:n.
>> The CCL equivalent is COPY/FILE/DEVICE/START:n.
>
>It is RT but brain fart on the app name it is dup.
Admittedly, under RT-11 trying to figure out whether DUP or PIP is performing
a particular COPY function is sometimes a bit fuzzy. (Let's see, COPY
can also invoke FILEX, too!)
>> Or, even easier, just do an FORMAT/VERIFY:ONLY. To be really thorough,
>> do a FORMAT/VERIFY:ONLY/PATT:7777 to write 12 different patterns over
>> the disk.
>
>Forgot that one. ;)
It's very useful for wiping media. Of course, with some common types
of media, FORMAT/VERIFY:ONLY doesn't wipe all the blocks: for example,
with RX01's and RX02's, it leaves track 0 untouched. DEC OS's don't
usually store data on track 0, but still... . And RL01's and RL02's
might end up with replacement blocks being untouched by the operation, too.
I know that the subject of this thread is how we never mess around with
confidential data, but as a tool for finding things that you might not
have otherwise thought of, Bob Schor's "SNOOP" program is quite effective
at finding files that used to be on a disk, even identifying entire
logical disks. It's on the RT SIG tape 11S113, available by anonymous
ftp from:
ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-11/rt/decus…
in "schor2.dsk". Bob Schor also has a program called "CLEAR" whose
only purpose is to blank out unused blocks on a RT-11 disk; this is in
"schor1.dsk".
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
This board is definitely dedicated for disk I/O. It supports 8" and 5.25"
floppy drives with a connector for each, and apparently two 5.25" hard disks
as well. It uses a WD 1010 chip as did most of the early PC HDC's. The
floppies are run with a WD 2797. I'd have concluded that this was NOT an
Intel board because of the non-Intel FDC, but the one board identifier I can
find says Intel.
I've got another '186-based board which uses a '286 as a processor and a
'186 as an I/O controller. This one has ethernet, serial I/O, lots of RAM,
with "secded" and about 200 IC's on one side plus about a thousand passives
and discretes on the other. It's from "Little Machines."
Dick
-----Original Message-----
From: Joe <rigdonj(a)intellistar.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, May 28, 1999 9:37 AM
Subject: Re: Multibus-I Users ??
>Dick,
>
> I don't have any catalogs that show the single board computers but I
>found something in the '85 Intel product guide. It lists an iSBC 186/03
>that has an 80186 and that they classify as both a CPU card and Mass
>Storage Controller. There is only a one line description for each so I
>don't know if it has 8042 or not. Here's the info that the CPU section
>gives: CPU = 80186, RAM = 0 to 64K EPROM or EEPROM = 0-512K, iSBX expansion
>connectors = 2, MultiMode Expansion = iSBC 341, Operating System Software =
>iRMX. Here's what the mass storage section says: No. of boards = 1,
>Interface Supported ="SCSI-single host environment (transfer rate 1.2
>Mbyte/sec asynchrous)", No. of drives supported = "single targer
>environment", S/W Support = RMX 86. There is also a chart showing the year
>of introduction and relatve performance. It was introduced in 1984 and it's
>performace is a 5.
>
> Joe
>
>At 07:30 AM 5/28/99 -0600, you wrote:
>>Are there any users of the old Multibus-I out there? I'm having
difficulty
>>identifying a board that is so "busy" that there was no room on which to
put
>>an identifier in the silkscreen. It's a FD/HD controller with a '186 and
an
>>8042 on it. Sound familiar?
>>
>>Dick
>>
>>-----Original Message-----
>>From: Richard Erlacher <edick(a)idcomm.com>
>>To: Discussion re-collecting of classic computers
>><classiccmp(a)u.washington.edu>
>>Date: Thursday, May 27, 1999 11:16 PM
>>Subject: Re: Re[4]: Bringing up a CPM
>>
>>
>>>Yes, '81 was pretty late . . . CP/M-86 came out then, as did PC-DOS.
>>>Within a few years, nobody wanted to be limited by the same systems they
>>>coveted only a few years earlier. By '81, the Apple][ could be equipped
>>>with a Z80 board, a "real" FDC (Sorrento Valley Associates ?) an 80x24
>>>display, and a hard disk if you could afford it. I recently sold the
>>>prototype of the original Apple HDC I made up in the spring of '81
together
>>>with my first ST-506.
>>>
>>>Those were the days . . . <sigh>
>>>
>>>Today I can still run CP/M but at an effective clock rate of 83MHz on my
>>>notebook . . . designing hardware involves thousands of lines of HDL,
weeks
>>>in front of a simulation, and when it's done, I can't even hook up an
>>>instrument small and fast enough to inspect it because even our
government
>>>can't afford one. One has to design circuits with 25% overhead so they
can
>>>be inspected. Oh, well . . .
>>>
>>>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: Thursday, May 27, 1999 8:54 PM
>>>Subject: Re: Re[4]: Bringing up a CPM
>>>
>>>
>>>><If you're writing your own, it might be well to keep in mind that the
>>BIOS
>>>><used in several late-generation CP/M systems used device drivers which
>>>coul
>>>>
>>>>It was late generation in 1981! I started doing it then. CPM had a
>>formal
>>>>product called CP/M+ (CP/M3.0) to extend that idea.
>>>>
>>>><California Computer Systems (CCS) had a pretty nice boot process in
which
>>>><they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest
>>>memor
>>>><in which they claimed they could run. It wrote that to the boot
blocks,
>>>>
>>>>Actualy it was 20k for cpm2.2, as it was distributed as a 20k system
that
>>>>you would run movcpm on to get the xxK version you wanted.
>>>>
>>>><then, under the control of that skeletal system, they loaded a
>>"full-size"
>>>><(you get to define that!) CP/M and transfer control to it. It's
pretty
>>>><solid and makes the preparation of a bootable disk a straightforward if
>>no
>>>><a quick process.
>>>>
>>>>Yes and they were doing it a long time back, Compupro too. Kaypro was
one
>>>>of the few "boxed" system that had the rom mapped to get a large TPA.
>>>>
>>>><IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
>>>><mapped into the TPA during file transfers, or something on that order.
>>If
>>>>
>>>>Classic.
>>>>
>>>><your machine can handle that, it saves on BIOS size, especially tables,
>>>etc
>>>><and, generally speaking, if the READ operations from the TPA are from
>>>><temprorarily mapped-in PROMs, you can overwrite the TPA in the event
>>you'r
>>>><loading overlays, with complete impunity. That way your
>>>blocking/deblockin
>>>><buffer space can still reside in high memory.
>>>>
>>>>An IMSAI can neither handle that nor not handle that. The basic design
>>>>had no rom! To do that you need a prom card with a little bit of
hardware
>>>>to map it with an IO port.
>>>>
>>>>The key here is to get a working system in whatever space... Why, it's
the
>>>>development platfrom for itself. Once you have it running and can poke
>>and
>>>>understand it the improvements will come.
>>>>
>>>>Allison
>>>>
>>>>
>>>
>>
>>
>
Two large chassis (size of old fridge) rolled into the salvage yard near
me, labeled MassPar and one of them has 8 big, I think, MFM drives in it.
Anybody know what this stuff is, or have interest in it? Its cheap, and
looks intact and very good shape.
Another MultiBus card that was found in the trash. It was made by
"MicroBar Systems Inc" and is marked "Master/Slave M24 I16 D16 V02NBV". It
has a small (~2 x 4") daughter board attached to it that says Intel and
contains a 82C55A-2. Most of the ICs seem to be dated 1985.
Joe
>> file as a logical device, then FORMAT or INIT it, or do a COPY/DEV
>> to it...
>
>Use PIP to do a absolute block addressed copy. I think it's :n or :I
>and your can then move known clear blocks to anywhere on the disk.
I think you're talking about RT-11, Allison, but I may be wrong because
the utility name you specify and the options you're talking about make
no sense under RT-11. Are you maybe talking about some other OS?
Under RT-11, it's not PIP, it's DUP, and the option is /G:n.
The CCL equivalent is COPY/FILE/DEVICE/START:n.
>If you have to do that alot under RT-11 make up a disk with files that
>contain nothingg (fresh disk) but use the entire surface and then image
>copy it.
Or, even easier, just do an FORMAT/VERIFY:ONLY. To be really thorough,
do a FORMAT/VERIFY:ONLY/PATT:7777 to write 12 different patterns over
the disk.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Are there any users of the old Multibus-I out there? I'm having difficulty
identifying a board that is so "busy" that there was no room on which to put
an identifier in the silkscreen. It's a FD/HD controller with a '186 and an
8042 on it. Sound familiar?
Dick
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 11:16 PM
Subject: Re: Re[4]: Bringing up a CPM
>Yes, '81 was pretty late . . . CP/M-86 came out then, as did PC-DOS.
>Within a few years, nobody wanted to be limited by the same systems they
>coveted only a few years earlier. By '81, the Apple][ could be equipped
>with a Z80 board, a "real" FDC (Sorrento Valley Associates ?) an 80x24
>display, and a hard disk if you could afford it. I recently sold the
>prototype of the original Apple HDC I made up in the spring of '81 together
>with my first ST-506.
>
>Those were the days . . . <sigh>
>
>Today I can still run CP/M but at an effective clock rate of 83MHz on my
>notebook . . . designing hardware involves thousands of lines of HDL, weeks
>in front of a simulation, and when it's done, I can't even hook up an
>instrument small and fast enough to inspect it because even our government
>can't afford one. One has to design circuits with 25% overhead so they can
>be inspected. Oh, well . . .
>
>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: Thursday, May 27, 1999 8:54 PM
>Subject: Re: Re[4]: Bringing up a CPM
>
>
>><If you're writing your own, it might be well to keep in mind that the
BIOS
>><used in several late-generation CP/M systems used device drivers which
>coul
>>
>>It was late generation in 1981! I started doing it then. CPM had a
formal
>>product called CP/M+ (CP/M3.0) to extend that idea.
>>
>><California Computer Systems (CCS) had a pretty nice boot process in which
>><they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest
>memor
>><in which they claimed they could run. It wrote that to the boot blocks,
>>
>>Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
>>you would run movcpm on to get the xxK version you wanted.
>>
>><then, under the control of that skeletal system, they loaded a
"full-size"
>><(you get to define that!) CP/M and transfer control to it. It's pretty
>><solid and makes the preparation of a bootable disk a straightforward if
no
>><a quick process.
>>
>>Yes and they were doing it a long time back, Compupro too. Kaypro was one
>>of the few "boxed" system that had the rom mapped to get a large TPA.
>>
>><IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
>><mapped into the TPA during file transfers, or something on that order.
If
>>
>>Classic.
>>
>><your machine can handle that, it saves on BIOS size, especially tables,
>etc
>><and, generally speaking, if the READ operations from the TPA are from
>><temprorarily mapped-in PROMs, you can overwrite the TPA in the event
you'r
>><loading overlays, with complete impunity. That way your
>blocking/deblockin
>><buffer space can still reside in high memory.
>>
>>An IMSAI can neither handle that nor not handle that. The basic design
>>had no rom! To do that you need a prom card with a little bit of hardware
>>to map it with an IO port.
>>
>>The key here is to get a working system in whatever space... Why, it's the
>>development platfrom for itself. Once you have it running and can poke
and
>>understand it the improvements will come.
>>
>>Allison
>>
>>
>
Hi Chuck,
Check the config file first, if your kernel looks for a DHV11 anyway ...
cheers,
emanuel
-----Original Message-----
From: Chuck McManis <cmcmanis(a)freegate.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 10:58 AM
Subject: "default" DHV11 CSR?
>Does anyone know the "default" CSR for the first DHV-11? (8x serial mux)
>I'm trying to get one recognized in my uVax III with NetBSD and it's not
>seeing it.
>--Chuck
>
>
>
I found this card in a pile of scrap boards. The IC on the top right corner
is broken. Can anyone tell me what it's supposed to be? It's marked U 16
and is a 16 pin SSI DIP. Does anyone have any docs for this card?
Joe
<I'm sure that lawyers are the worst because they know that if you did
<anything with the information or even made it public knowledge that you ha
<the information they would successfully sue you for everything you own.
It's a foolish practice. Running Norton's diskwipe is a good thing but at
least delete and better yet do a format.
They are at risk for malpractice for mishandeling possibly confifential
info. Their risk is much greater due to that confidence.
Generally, wipe them. If the disk has a possibly useful OS then clean it.
Whatever you do respect privacy!
I work as a MIS/Sysadmin, in short that means everything in the company
can or is seen by me. That also means I have a responsability to keep it
to myself where it is known.
Since I've been doing this for quite a while and often so I have usable
disks! MY standard thing is to let the former owners if known that I
will be trying to use the disk and if there is any data found it will be
destroyed or at their option copied if possible and returned to them.
More often than not the drive is LLF'd as the controller I'm using doesn't
like their format. If I plan to pass on the disks I will try to wipe
them first or at least make sure nothing grossly dangerous to the former
owner is on them. That is assuming I have hardware to do that.
Allison
Hello,
I recently acquired a VAXstation 3100 from a local pharmaceutical
company that was trashing it. Being a sucker for old computers, and
having always been intrigued by VMS, i've messed around with it.
I know incredibly little about VMS, and have never encountered it
before yesterday, but what I have been able to figure out is that it's
running VAX/VMS 5.4, it has 16Mb of RAM, (2) 212Mb hard drives, and an
RX23 disk drive. Does anyone have any references or links that would
be helpful in setting this thing up? Any information would be greatly
appreciated.
Thanks in advance.
-paul
--
paul(a)paul.dragontear.org [a paradigm of a paramount failure]
So... having found some time to have a look at these beasties, I find that
overall I'm still as puzzled as before.
And one of these cases where documentation can be TOO old... My one
vintage HP catalog predates these CPUs by a couple of years. The catalog
only lists the HP2116.
I wandered through the card cages in both machines (fairly diverse
configurations) and the designations look like this:
Machine 1 Front card cage Rear card cage
DCPC 13037 Intf
Memory Protect Grd True In/Out
M.E.M. Grd True In/Out
64k HSM 12747H Microcircuit
64k HSM 12747H BACI 12966A
64k HSM 12747H 7970 Mag Tape 2
64k HSM 12747H 7970 Mag Tape 1
64k HSM 12747H Line Printer
64k HSM 12747H Time Base Gen
Mem Contr 2102E F.E.M.
Main Logic? (under chassis)
Machine 2 Front card cage Rear card cage
DCPC Jumper
Memory Protect I/O Buffer
M.E.M. 8 Chan Mux
Standard Memories Bus I/O
(256k memory) 1
Standard Memories 2
(256k memory) Disc Intf 2
256kw 12749H Disc Intf 1
256kw 12749H 3
Mem Contr 2102E 4
BACI 12966H
12821A Disc Intf
Time Base Gen
F.E.M.
Main Logic? (under chassis)
(pictures are on the MiniComputers page at The Computer Garage)
Some of the cards are fairly obvious as to function, (memory, time base
gen, etc...) but some of the designations are a bit vague, and in any case
I still need to find docs on this critter and the cards.
The cards designated as 1,2,3, & 4 are all identical, and look like
multi-channel serial I/O cards. The only obvious designation are etched on
the card and read 5180-1953 and 668298. They are HP cards...
Any information on these critters would be greatly appreciated!
After the usual pre-launch checks, all of the (apparently) optional cards
were removed from the card cages and the units were powered up. Curiously,
they both act identically in that they seem to have some front panel
function, but the CPUs seem to be hung pretty hard.
No odd sounds or loss of magic smoke, so an initial suspicion is a
configuration error common to both units. The card cages only have
specific card notations on a couple of slots, so there is the obvious
question of proper card positioning. (no idea if the cages are a parallel
bus or not)
Help???
Thanks;
-jim
---
jimw(a)computergarage.org
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
<If you're writing your own, it might be well to keep in mind that the BIOS
<used in several late-generation CP/M systems used device drivers which coul
It was late generation in 1981! I started doing it then. CPM had a formal
product called CP/M+ (CP/M3.0) to extend that idea.
<California Computer Systems (CCS) had a pretty nice boot process in which
<they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest memor
<in which they claimed they could run. It wrote that to the boot blocks,
Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
you would run movcpm on to get the xxK version you wanted.
<then, under the control of that skeletal system, they loaded a "full-size"
<(you get to define that!) CP/M and transfer control to it. It's pretty
<solid and makes the preparation of a bootable disk a straightforward if no
<a quick process.
Yes and they were doing it a long time back, Compupro too. Kaypro was one
of the few "boxed" system that had the rom mapped to get a large TPA.
<IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
<mapped into the TPA during file transfers, or something on that order. If
Classic.
<your machine can handle that, it saves on BIOS size, especially tables, etc
<and, generally speaking, if the READ operations from the TPA are from
<temprorarily mapped-in PROMs, you can overwrite the TPA in the event you'r
<loading overlays, with complete impunity. That way your blocking/deblockin
<buffer space can still reside in high memory.
An IMSAI can neither handle that nor not handle that. The basic design
had no rom! To do that you need a prom card with a little bit of hardware
to map it with an IO port.
The key here is to get a working system in whatever space... Why, it's the
development platfrom for itself. Once you have it running and can poke and
understand it the improvements will come.
Allison
If you're writing your own, it might be well to keep in mind that the BIOS
used in several late-generation CP/M systems used device drivers which could
be swapped in and out of PROM. This seems like a decent idea in view of the
way in which some compilers handled their TPA usage. You could end up with
a pretty big BIOS if you make it any sort of fancy at all , and that could
mean you can't run some compiled programs.
California Computer Systems (CCS) had a pretty nice boot process in which
they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest memory
in which they claimed they could run. It wrote that to the boot blocks,
then, under the control of that skeletal system, they loaded a "full-size"
(you get to define that!) CP/M and transfer control to it. It's pretty
solid and makes the preparation of a bootable disk a straightforward if not
a quick process.
IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
mapped into the TPA during file transfers, or something on that order. If
your machine can handle that, it saves on BIOS size, especially tables, etc,
and, generally speaking, if the READ operations from the TPA are from
temprorarily mapped-in PROMs, you can overwrite the TPA in the event you're
loading overlays, with complete impunity. That way your blocking/deblocking
buffer space can still reside in high memory.
Just a thought . . .
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 3:25 PM
Subject: Re[4]: Bringing up a CPM
>allisonp(a)world.std.com wrote:
>> > I guess the issue is that the additional space is the BIOS and
>> > since I'll be replacing this with my own BIOS, and I write efficient
>> > code, I don't have to worry about it until I run out of space?
>> > Dwight
>> >
>> ???HUH??? Figure this if your running a SSSD 8" to be compatable with
>> media out there the system has two tracks to use for the CCP, BDOS and
>> bios. Thats 52 sectors!
>>
>> The first sector DOES NOT HAVE TO BE THE BOOT.
>
>Hi
> It does on my system unless I toggle in a loader or have
>EPROMs to do it. I'd like to not have any EPROMs if I don't
>need it. The controller automatically loads track 0 sector 1.
>I start executing at address zero and it boot loads the
>CPM system. The boot loader then jumps to the start of
>the CPM and it over writes info at address zero with what
>it requires there. As far as I know, I am following the examples
>for a non-MDS800 type system and following exactly what is
>shown on 6-14/6-15 of the CPM manual that I got from the
>unofficial site. The mapping shows that the first sector
>is a cold start loader and the CPM ( CCP ) part doesn't start until
>the second sector.
> It would seem that there was additional BOIS info loaded that
>didn't fit into the 51 sectors. It sounds like I can ignore
>this because I'll be replacing it anyway.
> Let me say, no EPROM's, boots from disk.
>Dwight
>
