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
>
