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
