From: Fred deBros <fdebros(a)verizon.net>
>Is there an ISA card that has the IDE irq assignable to any IRQ?
Older ones did. IDE IRQs were 15 and 14.
>U guessed right: I'd like to stick a secondary ide drive (CDROM
>obviously) into a 486 that has only one ide (IRQ14)drive, but no plug
>for a secondary drive, and no, I cannot use the ide cable as it is a
>laptop, but yes, it has the bus connected to a dockstation. And yes I
yes you can. I've done it. one of my 486boxen has 3 CDroms and
a 500mb IDE disk. It serves as a CD server running Win95.
Some of the real early 486s the bios was a bit poor but most of the
better ones it's been no problem. FYI: for the CDrom you simply do
nothing at the bios level and it's the OS that has to find and install
the CDrom. If the cdrom is a standard the win95 drivers will do though
I've had a few oddballs that I had to use the driver supplied with
the drive.
Allison
Yeah, I saw those (at Active, right?); in fact here they were 5 for 10 cents. Bought
a couple packs myself but alas, I don't know of anything that uses them, not PETs
anyway; I think you're thinking of 2114s, 1Kx4.
There were 4 versions of the static RAM PETs: (6316 ROMs equivalent to 2316B)
320008: 6540 ROM, 6550 RAM & VRAM
320081: 6316 ROM, 6550 RAM & VRAM
320132: 6540 ROM, 2114 RAM & VRAM
320137: 6316 ROM, 2114 RAM & VRAM
The Dynamic RAM PETs used 2114/6114s for VRAM.
ROMS used include 2316/6316, 2332, 2364/6364.
RAMS used include 5298, 4108, 4116
Parallel disk drives used 2114s.
mike
----------Original Message-----------
>Date: Thu, 02 May 2002 21:19:24 -0400
>From: Arlen Michaels <arlen.michaels(a)sympatico.ca>
>Subject: Anyone need 2112 RAMs?
>I was surprised to find a local supplier clearing old stock of 2112 RAMs.
<snip>
>I believe this was the chip used in late-model Commodore PETs
<snip>
> From: Richard Erlacher <edick(a)idcomm.com>
> The problem is that the popular U.S. vendors expend entirely too much of
their
> resources on packaging, thinking, perahaps correctly, that it will help
sales,
> but they forget, oir perhaps not, that the individualized packaging will
make
> their systems difficult to upgrade over time, thereby making the
long-term
> usefulness of considerably less value.
Dick, I believe they do this deliberately, to inhibit upgrades and repairs.
I make a lot on upgrades and repairs of systems I originally built and
sold, but the big names only make money when they sell a machine, so
naturally they prefer that people replace their PCs instead of fixing them
or beefing them up.
When people come into my shop and I can get them to understand "total cost
of ownership," they buy from me every time.
Glen
0/0
Today I picked up a wire wrap card with some strange ICs. They're 16 pin dips with white ceramic bodies and gold lids and legs. They have the numbers 7552-1C and 7350 on them. I believe the 7350 is a date code. There are other ICs on the card and they're all date coded to 1973. There's also a note on the board that says that it was modified on 7/25/74.
There's also a trademark symbol on the ICs that looks like a black box with a lower case "i" showing through in gold. I don't think I've ever seen this trademark before, does anyone know what company it's for? Anyone know what the ICs might be?
Joe
Hans B Pufal wrote:
>Vintage Computer Festival wrote:
>> I need the pinouts of the card reader interface. Does anyone have this
>> information? Is the service manual available online (in some nook I
>> haven't looked into yet)?
>
>I found it on the web somewhere, I am putting a copy on line for you at
>www.aconit.org/hbp/m200ref.pdf it is about 21Mb. Give my upload a few
>minutes to complete.
>
The scan was from my site http://www.pdp8.net/query_docs/query.shtml
If anybody knows of an extra card weight around I need one for my M-200.
David Gesswein
http://www.pdp8.net/ -- Run an old computer with blinkenlights.
Greetings folks:
Bob Shannon has a PDP-11/34 rack system for me in Massachusetts sitting in
his garage. I can take care of having it shipped from any location that has
a loading dock, so the shipping isn't a problem as long as it is shipped
sometime within the next week or two at most. However, the shipper will want
it banded to a pallet and shrinkwrapped and Bob doesn't have the stuff to do
that, nor does he have a loading dock.
Is there anyone who might be able to assist getting the system banded to a
pallet and shrinkwrapped, and possibly to a loading dock that the shipper
will pick up from? Any thoughts or assistance is greatly appreciated.
Thanks!
Jay West
must be 10 years old... mebe not...
anyway my install disk has vanished, I have the whole rest
of the .2x10^2 disks (thats about 20 right(^: )
can anyone help me out?
ron.
Well, here is the pinout of the typical IBM external floppy
drive (5.25) & interface:
External Diskette Adapter
-----------------------,
unused 1 | Diskette Drive
unused 2 | ,-----------------------
unused 3 |----------------| 2 unused
unused 4 |----------------| 4 unused
| |----- alignment slot
unused 5 |----------------| 6 Drive Select 4
Index 6 |<---------------| 8 Index
Motor Enable C 7 |--------------->| 10 Drive Select 1 *
Drive Select D 8 |--------------->| 12 Drive Select 2 *
Drive Select C 9 |--------------->| 14 Drive Select 3 *
Motor Enable D 10 |--------------->| 16 Motor On *
Direction Select 11 |--------------->| 18 Direction Select
Step 12 |--------------->| 20 Step
Write Data 13 |--------------->| 22 Write Data
Write Gate 14 |--------------->| 24 Write Gate
Track 00 15 |<---------------| 26 Track 00
Write Protect 16 |<---------------| 28 Write Protect
Read Data 17 |<---------------| 30 Read Data
Head Select 18 |--------------->| 32 Head Select
unused 19 |----------------| 34 unused
-----------------------' `-----------------------
Bottom Row Sockets 20 - 37 of the DB37S Connector are Ground
Now, here is what Chris gave me earlier for the Type 9331 Model 011:
External Signal Cable Connector
Table 7-1. Pin Assignments for 37 Pin D Shell Cable
Signal Name Signal Pin Ground Pin
Reduced Write Current 2 20
Drive Select 0 8 26
Motor On (Head Load) 10 29
Direction Select 11 29
Step 12 30
Write Data 13 31
Write Gate 14 32
Side one Select 18 36
Ready 9 27
Index 6 24
Track 00 25 33
Write Project 26 34
Read Data 27 35
Diskette Change 19 37
Two Sided 7 25
8-Inch Drive Attached 5 23
5.25-Inch Drive Attached
They look pretty compatible...
Now, the next step would be OS support. I think I know how
to make it work for an older DOS machine, but what about
Windows?
Anyone else done this yet?
Regards,
-doug q
After hearing about them for quite a while I found them.
I picked up a few NABU computers and the adapters still in the box.
Also a VT180 with disks and manuals.
I though last weekend was good when I grabbed a Sparcstation SLC, ELC,
and a PSC-586VGA SBC for a buck each.
> On Fri, 26 Apr 2002, David Woyciesjes wrote:
>
> > Did someone say power cords??? I got a box of about 4 dozen if you need
any.
>
> Heh. I can get you about 4 dozen boxes of 'em....
I have finally figured out what the dealieo is with this... I've
got so many it's as if two or three came with every device. But
I was the one who unpacked almost everything at the office for
the last 6 years.
So what's happening is that they are reproducing. I think you're
safe with just two in a box, they're not bunnies, but when you put
three or more together, they gain some kind of sexual critical mass
and start reproducing.
Everything that's been given away had a power cord, and almost
nothing has been thrown away. So this has got to be the answer...
;)
>> I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive
>> Card" installed in it, with a big connector on the back of the SE. What is
>> the card for?
>
>'A big connector'??? What is it really? How many pins, how arranged. Is
>it, for example, a DC37 socket?
I was going to say I thought it was a 27 pin from memory, but a 37 pin D
shell sounds about right.
Apple bundled the card with a drive, but that drive might just be a
regular drive in an apple case.
How would I be able to determine that? (I don't mind opening mine to
check if it means the other guy can benifit from the info and assemble a
drive to use with their card)
-chris
<http://www.mythtech.net>
I wonder if this adflip.com site (the one that has the classic magazine
advertisements) isn't setup by one of those guys that sells old magazine
ad pages on eBay. It would make sense.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
* Old computing resources for business and academia at www.VintageTech.com *
Would this guy be a prankster or .....
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2022001381
Ed
--
The Wanderer | Politici zijn gore oplichters.
quapla(a)xs4all.nl | Europarlementariers: zakkenvullers
http://www.xs4all.nl/~quapla | en neuspeuteraars.
Unix Lives! M$ Windows is rommel! | Kilometerheffing : De overheid
'97 TL1000S | weet waar je bent geweest!
Richard Erlacher wrote:
> While the logical replacement has never been a problem, the rounded front
that
> fits the case is a virtually impossible thing to replace by the time the
drive
> needs replacment. They seem to require a rounded drawer front with no
bezel
> of the drive. Whereas the bezel can be removed easily enough, finding a
drive
> with that rounded front that fits, precisely, the slot in the plastic
> front-face of the box is a problem. The part number is seemingly never
> available more than 90 days after the computer is no longer an
off-the-shelf
> item.
I've seen very few HPs with this setup, but the Acer Aspire is famous for
it. Fortunately the Aspire has a couple of "normal" 5.25" bays so I just
leave the old drive in place and add a new one in an empty bay, or if I'm
lucky I have a drive yanked from a dead Aspire.
>
> No ATAPI CDROM has ever been a problem to replace under Windows 9X, to my
> experience.
Unless Win9X is hosed. Yesterday I worked on a Gateway P-III running Win
98, which wouldn't boot, but hung on the splash screen. Yanked the IDE
cable off of the CD-ROM drive and the system booted and all devices worked
perfectly. Tested the drive in another box; the drive was fine. Put
another drive in the Gateway -- no boot. Took CONFIG.SYS, AUTOEXEC.BAT,
WIN.INI and SYSTEM.INI out of the picture. No boot. Moved the drive from
master to slave. No boot. Replaced the IDE ribbon. No boot. Put the
drive on the same ribbon as the hdd, hdd as master, CD-ROM drive as slave.
No boot. Uninstalled and reinstalled the motherboard drivers. No boot.
Pulled the hdd, put in a new one, loaded Win98, and the system booted and
the CD-ROM drive worked. Put the original hdd back in -- no boot. Reset
the BIOS to default settings and made sure both IDE ports were turned on.
No boot. Verified that both ports were visible to Windows -- no boot.
Turned DMA off in Windows -- no boot. Ran a virus check and didn't find
anything.
Did I miss anything? (serious question). Finally I wiped and reloaded the
hdd and all was well. I've seen this five or six times in ten years. It's
something deep down in the Windows goo . . .
Apologies -- seriously OT.
Glen
0/0
> > We had 25 of the TS-803 at RETS, and I've been haggling
> > for the only one I know is left from the guy who has it,
> > so far, to no avail. I have manuals and lots of software
> > for it, including TELE-WRITE and TELE-DRAW. We had a
> > MouseSystems optical mouse on ours that worked with TELE-DRAW.
>
> Cool. I'm pretty sure the TS-806 and TS/TVI-800's were text-only, but if
> the text-mode software still is compatible, that'd be awesome.
Well, when you were running CP/M, these were text-only too.
But they had 640 x 240 graphics, with primitives in ROM that
sped things up quite a bit. DRI's GSX-80 came with the systems
to provide a standard layer for the graphics support. Then
DRI's CBASIC had language extensions for drawing lines and
such. But the overhead was high, translating from a real-number
world coordinate system to an integer normalized coordinate
system and then to the integer physical device coordinate system.
I bypassed all that using some assembly language interfaces I
wrote and went straight to ROM. The application we'd written
in CBASIC using its "native" graphics statements took 6 minutes
to finish drawing the screen (an image of a prototyping board).
The re-written version drew the same inage in six seconds on a
4MHz Z-80.
-dq
Does anyone have any spare Zenith Z-100 expansion cards? I'd particularly
like to get some more RAM, the USR internal modem, and an RTC board. Cash
or possible trade.
Thanks,
Glen
0/0
Ok guys, so there was a problem in the terminal settings. (Hey,
it's an IBM 3151(?) terminal, and mostly configures in Swahili)
Open firmware does, indeed, work on this system. Don't ask why
it didn't work earlier with the Wyse (which was set up properly,
I'm sure, since it's in use on the machine which I used to finally
get the IBM configured properly ;).
Anyway, it will now boot into Open Firmware, even without keyboard,
monitor, etc, attached. I'll attempt to install Darwin on the disk
sometime soon. It may work, but at the moment, it has less RAM and
less disk than they say is "required."
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
I have a friend who has a Sun i386 running SunOS 4 and is looking for
documents/webpages related to either of them. Especially for SunOS 4 manuals.
Anyone got any or can point me to information? Thanks!
Tarsi
210
> Date: Thu, 2 May 2002 21:23:26 -0500 (CDT)
> From: Doc <doc(a)mdrconsult.com>
> To: ClassicCmp List <classiccmp(a)classiccmp.org>
> Subject: RE: Tape dumping programs for Unix/Linux...
> In-Reply-To: <000501c1f245$6a304ca0$1aefffcc@Shadow>
>
> On Thu, 2 May 2002, Douglas H. Quebbeman wrote:
>
> > I just did a 'dd' of a bad QIC-80 tape; it read the entire tape
> > as a single file, and didn't bail out.
> >
> > I've not done that with magtape, but ISTR someone else here
> > saying that 'dd' does raw reads, bad blocks and all...
> >
> > My bad if not true.
>
> No bad, just an honest difference in perspective. I recently went
> through this with a set of VMS-based diagnostics tapes. AFAIK, the
> tapes are undamaged, but dd returns a valid read - of the first file on
> the tape - and stops. I'm not that familiar with non-"streaming"
> formats, so I just accept what is without knowing why....
> dd on a disk or raw filesystem ignores files. On a tape archive, even
> using the raw device as the if, dd reads files and stops at the end of
> the first record.
I think you have your terminology mixed here.
dd reads records and stops at the end of the first file.
carl
> > You wrote...
> > > I ran out of ports a few weeks ago so i am looking to buy a 4-5 port
> > > 10mbit or so ethernet hub or switch. Contact me off-list.
> >
> > 10mbit OR SO? Let's see, I think I have a few 7mbit units, and maybe a
few
> > 14mbit ones. Wait - I know - I have a 18mbit unit and a 8mbit model - so
if
> > you daisychain them... voila - 10mbit.
>
> "Well, our [hub] goes to 11 [Mbit]."
Yeah, but the synch has a tendancy to spontaneously combust...
;)
I think we have it solved.
I believe it could be a 1 Meg SRAM. Thanks for the info about IDT. The 16
pieces soldered on the top and bottom seem to have a solder pad pattern of 5
on the ends and 9 on the sides. Would this jibe with the 64KX8 configuration?
Sorry for the "glamour" look to the pictures, it was accidental. I use my
Sony 730 HI-8 videocamera hardwired to a framegrabber in the computer. I have
two adjustable clamp on lights, one incandescent with a magnifier and one
with a round fluorescent that I normally use for photography.
The round light gives fairly even lighting but it was busy so I used the
Incandescent. I was really surprised at the difference. Not only was it much
warmer but the contrast was way up. These are the only pictures I have shot
with that light.
There is only one label on top of one of SRAMs. No other labels except IDT
7M624 plated in gold on top of the ceramic. You should be able to see both in
the pictures.
Thanks for the help.
Paxton
Astoria, OR
> > > The emulator community is vigorously using a tape image container
> > > format known as TAP for precisely this purpose.
> > >
> > > Each record from tape is written to file prefixed *and* suffixed
> > > by a four-byte record length in little-endian format. A zero-
> > > length record is represented by a 4-byte value of zero; although
> > > intuition might call for 8-bytes (a prefix & suffix with nothing
> > > in between), this is not the case. The convention appears to come
> > > directly from FORTRAN 77's handling of unformatted sequential files.
> > >
> > > And EOF is represented by two consecutive zero-length records.
> >
> > Darn...sounds like a subset of what I use. I'd be interested
> > in knowing more about TAP (with an eye towards adopting use of it),
> > and would suggest some possibly missing features might be:
>
> Is there any more information on "TAP" other than the program that I
> find with Bob Supnik's simh stuff, namely "mtdump" that produces
> a "TAP" image given a list of files? It would be nice if someone else
> had already written the program that reads a real physical magtape and
> produces a "TAP" image.
Not really any more information that I know if other than what
you've seen here- it's a minimalist convention.
But I can recommend Eric Smith's tapecopy program as far as other
code to look at. It accompanies tapedump & t10backup in his package.
You should be able to find his package here:
http://www.36bit.org/dec/software/unix-util/
hth,
-dq
I was surprised to find a local supplier clearing old stock of 2112 RAMs.
This is an NMOS static RAM 256bit x 4. The chips are new, labelled SY2112-A
(Synertek I think) and they're supposedly 350 nS devices.
I believe this was the chip used in late-model Commodore PETs (after they
designed out the earlier 6550 chips); maybe someone wants to confirm this
for the list. I seem to recall the Heathkit micro trainer used a couple
too, but I could be mis-remembering.
Not as commonly needed as the 2102 or 2114 I know, but if anybody wants some
I could pick them up. They're 5 for a buck, plus whatever it costs to mail
them-- unless of course you want to offer me something extra for my trouble
:)
--
Arlen Michaels
arlen.michaels(a)sympatico.ca
I just came across a large number of loose 2102 chips in a junkbox, and
wondered if anyone has a schematic of a test circuit for these. I'm not
sure how many of them there are yet, but they all appear to be from the
same batch; AM9102BPC/P2102A-4 7632QD [32nd week, 1976]. An couple
interesting facts I dug up on these chips is that the AM9102 was AMD's
first RAM product, and it was first produced in quantity in 1975.
I'm thinking these chips might be a good source of ram for a 6800 based
homebrew system, especially since I already have the chips and lots of
wirewrap (and patience)...
-Toth
After a trip down to Asian Pearl, Al and I took a
trip down to the local recycle place. He spotted an
Apple 3.5 inch External drive, the 800k variety we
were discussing recently on the list. He wasn't
interested, so I snagged it, and it appears to be
working fine on the Mac IIci, although I wasn't
sure at first, as it took me a while to find any
800k disks.
Outside, I found an IBM Type 9331 011 8 inch external
floppy drive, a nice black enclosure with the IBM logo
in the oval badge set at 45 degrees, like the PS/2 line
logos were. The interface connector on the rear has 37
pins and so I'm hoping it's the same as the interface
on the old IBM floppy interfaces that had a 37-pin
external connector.
Anyone know what these drives were used with, and will
I luck out on the interface? It needs cleaning...
Also, an IDE removable harddrive carry case & two mounting
frames, so I can start carrying serious storage two & fro
the orifice, er, office.
No blinkenlights, although the poprietor indicated he'd
dumped a bunch of old stuff six months ago. Oh well, the
way he does this is he leaves a pallet out front for people
to stack stuff on. I'll start checking more often.
Anyway, total damage for the above: eight bucks; five for
the Apple drive, two for the IBM floppy, and 1 for the IDE
shuttles.
-dq
> I got a type 9331 model 011 with an AS/400 system... I
> think. When I get home, I'll look at it (and its //manual// :)
> again.
Excellent, and thanks in advance!
-dq
> From: "Stan Sieler" <sieler(a)allegro.com>
> To: cdl(a)proxima.ucsd.edu (Carl Lowenstein), classiccmp(a)classiccmp.org,
> classiccmp(a)classiccmp.org
> Date: Fri, 3 May 2002 12:10:42 -0700
> Subject: Re: Tape dumping programs for Unix/Linux...
> Priority: normal
> In-Reply-To: <200205030710.AA16219(a)proxima.ucsd.edu.UCSD.EDU>
>
> Re:
>
> > Look for a program named "copytape". It copies tapes including the
> > block structure, file marks, etc. Unlike dd(1) which only really
> > works if all blocks are the same size and there is only one file
> > on the tape. It can copy tape-drive to tape-drive or tape-drive to
> > disk file, and puts markers in the disk file to indicate the
> > structure of the data on the tape.
> >
>
> The versions I found do a fair job of copying a tape...but not
> a complete job (particularly for DDS and DLT tapes).
>
> Why?
>
> It doesn't know about "setmark".
>
> On a DDS (DAT) drive, you can have a data record (of variable length,
> not just multiples of 128 or 256 bytes, BTW), an EOF (end-of-file mark),
> a setmark, or an end-of-tape indicator.
OK. It _was_ written long before anything as smart as a DAT drive
had been devised.
Why do you stress "data record not just multiples of 128 or 256 bytes"?
Oh, this is qualified by "on a DDS drive". Certainly 7-track and 9-track
1/2" drives could have fairly arbitrary data records. I have seen
tapes with records as short as 14 bytes, and as long as 65535 bytes.
Also pre-DLT tapes (DEC TK50) with 1MB records, but only to be read
by a MicroVax not a PDP11.
> >From "man mt" on HP-UX (since at least 1992, so it fits the 10 year rule, too
> :)
> DDS format devices also support setmarks which are hierarchically
> superior to filemarks. A setmark is used to delineate a group (set)
> of files. Reading a setmark is also returned as a zero-length read.
> The two can be distinguished by unique bits in the mt_gstat field.
>
> (In fact, #$%^ HP took out the above text from the 10.20 "man mt" doc, leaving
> just a bare reminder that setmarks exist)
>
> Who uses setmarks? Backup software that wants to be able to locate
> files quickly.
>
> E.g., consider a modified tar/gtar that writes an EOF after every
> file, and a setmark after every 1000 files, and also writes s table
> of contents (list of files to be backed up) at the start of the tape.
> If the user says "restore file FOO", the software can read the table of
> contents and determine that FOO is file, say, 2349. It can then issue
> two "forward setmark" commands, and then 349 "forward EOF" (or "forward
> filemark" or "forward space file") commands to quickly get to the file.
>
> DDS drives can find a setmark very quickly, faster than they can find
> an EOF.
>
> So....any software trying to *accurately* duplicate a tape should
> record the fact a setmark was seen, as well as data record and EOFs
> and errors :)
As I recall, DDS tapes can also have two partitions, independently
writeable. So the tape index can be written onto the first partition
_after_ the data is written on the second partition. I don't know any
common software that takes advantage of this.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
Hi
One could throw together a simple socket and connector
circuit to put on a parallel printer port. Use a '273 to
increase the number of outputs and use one pin as the input.
The pins for the 2102 are 1,2,4,5,6,7,13,14,15 and 16 are
address lines. 3 is MWR\. 11 is data in and 12 is data out.
10 is +5 and 9 is ground.
You do need a bi-directional parallel port.
Check out : http://www.lvr.com/jansfaq.htm for ideas
on how to control the printer port of a PC ( I would
do it with Forth, myself but most others would use C
or something ). Write a March "C" and pause between passes
for a few seconds to check retention.
Dwight
>From: Tothwolf <tothwolf(a)concentric.net>
>
>I just came across a large number of loose 2102 chips in a junkbox, and
>wondered if anyone has a schematic of a test circuit for these. I'm not
>sure how many of them there are yet, but they all appear to be from the
>same batch; AM9102BPC/P2102A-4 7632QD [32nd week, 1976]. An couple
>interesting facts I dug up on these chips is that the AM9102 was AMD's
>first RAM product, and it was first produced in quantity in 1975.
>
>I'm thinking these chips might be a good source of ram for a 6800 based
>homebrew system, especially since I already have the chips and lots of
>wirewrap (and patience)...
>
>-Toth
>
>
A power supply for an RS/6000 397.
Peace... Sridhar
--
"How do you fight such a savage?"
"With heart, faith, and steel. There can be only one."
-MacLeod and Ramirez, "Highlander"
Anyone need a power supply for an RS/6000 380/390/390H/3AT/3BT/3CT?
Peace... Sridhar
--
"How do you fight such a savage?"
"With heart, faith, and steel. There can be only one."
-MacLeod and Ramirez, "Highlander"
I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive
Card" installed in it, with a big connector on the back of the SE. What is
the card for?
--
Owen Robertson
JP Hindin <jplist(a)globe.net.nz> wrote:
> I see le0 a lot, but I picked up ie0 from my Sun 4/470, which I'm using on
> the 386i. Is this an error on my part? Should I try and set up le0
> instead?
Maybe. ie is the driver for an Intel Ethernet chip/card (I have
vague recollections of the card being a Multibus card in a VME-to-
Multibus frame in a Sun 4/370). le is the driver for an AMD LANCE
chip. I can't remember what Ethernet hardware is in the 386i,
but a LANCE-based design would not be surprising.
Does your 386i boot at all? If so I would expect it to tell you at
boot time what devices the kernel is finding. If you can log in, the
dmesg command should replay those messages for you (if they're still
in the kernel's buffer).
-Frank McConnell
> From: "Stan Sieler" <sieler(a)allegro.com>
> To: "Douglas H. Quebbeman" <dquebbeman(a)acm.org>,
> "ClassicCmp List" <classiccmp(a)classiccmp.org>
> Date: Thu, 2 May 2002 12:06:37 -0700
> Subject: Re: Tape dumping programs for Unix/Linux...
> Cc: fmc(a)reanimators.org
> In-Reply-To: <000701c1f1e2$a795cd80$e401a8c0(a)tegjeff.com>
> Content-Transfer-Encoding: 7BIT
>
> Re:
>
> > The emulator community is vigorously using a tape image container
> > format known as TAP for precisely this purpose.
> >
> > Each record from tape is written to file prefixed *and* suffixed
> > by a four-byte record length in little-endian format. A zero-
> > length record is represented by a 4-byte value of zero; although
> > intuition might call for 8-bytes (a prefix & suffix with nothing
> > in between), this is not the case. The convention appears to come
> > directly from FORTRAN 77's handling of unformatted sequential files.
> >
> > And EOF is represented by two consecutive zero-length records.
>
> Darn...sounds like a subset of what I use. I'd be interested
> in knowing more about TAP (with an eye towards adopting use of it),
> and would suggest some possibly missing features might be:
Is there any more information on "TAP" other than the program that I
find with Bob Supnik's simh stuff, namely "mtdump" that produces
a "TAP" image given a list of files? It would be nice if someone else
had already written the program that reads a real physical magtape and
produces a "TAP" image.
carl
>The problem is that the popular U.S. vendors expend entirely too much of
>their
>resources on packaging, thinking, perahaps correctly, that it will help
>sales,
>but they forget, oir perhaps not, that the individualized packaging will make
>their systems difficult to upgrade over time, thereby making the long-term
>usefulness of considerably less value. Apple has taken this to the extreme,
>as only a vendor knowing he has a market segment to himself could do.
Most of the system manufacturers WANT to make it hard to upgrade the
system. They don't want you swapping parts to renew the life of your
machine... they want you to just buy a whole new machine every few years.
These upgrade impared designes are deliberate.
-chris
<http://www.mythtech.net>
>While the logical replacement has never been a problem, the rounded front
>that
>fits the case is a virtually impossible thing to replace by the time the
>drive
>needs replacment. They seem to require a rounded drawer front with no bezel
>of the drive. Whereas the bezel can be removed easily enough, finding a
>drive
>with that rounded front that fits, precisely, the slot in the plastic
>front-face of the box is a problem. The part number is seemingly never
>available more than 90 days after the computer is no longer an off-the-shelf
>item.
The last HP I had to do a CD swap on, I gave up finding a replacement
"HP" drive, and just found the same model Mitsumi drive, then swapped the
front bezel off the drawer. Of course, finding an 8x multi-year old
Mutsumi CD drive was a challenge in itself (I tried other Mitsumi's, but
on newer ones, and on every other CD drive I found, the drawer position
and or mounting clips had changed, so there was no way to align it or put
the old bezel on it).
One more reason I build my own PCs these days.
-chris
<http://www.mythtech.net>
> From: Raymond Moyers <rmoyers(a)nop.org>
> To: classiccmp(a)classiccmp.org
> Subject: Re: Tape dumping, bad blocks.
> Date: Fri, 3 May 2002 01:01:59 -0500
> In-Reply-To: <200205030508.BAA32513(a)conman.org>
>
>
> Funny, on the 9 track tape you dont confront this issue.
> 9 track tape is 8 bits + parity right ? so here a bad bit dont
> cause you to lose the ability to get the next byte and know
> that its a valid byte, a physical superiority it has over the
> serial streamers ?.
>
> Or am i assuming too much again.
I think you are assuming that there will never be a dropout over the
complete width of the tape. i.e. there will always be at least one
"1" bit passing the read head. Data clocking is essentially done
on the inclusive OR of all channels, so if they all drop out, you
have lost your place.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
Sorry for being a bit off-topic....
I ran out of ports a few weeks ago so i am looking to buy a 4-5 port 10mbit
or so ethernet hub or switch. Contact me off-list.
Thanks,
Torquil MacCorkle III
Lexington, Virginia
So I finally got this TSZ07 that I've been wanting for a while so I can
archive a mountain of magtape I have (including System III sources for
the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp
stuff off of tape, but it's tedious. What tools are people using for
tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
that essentially pulls everything off the tape until logical or physical
EOT. I'm looking for something similar - point it at the drive and
siphon it on down.
At present, because of cable reach, I am talking to the tape drive
through an Adaptec AHA1460 PCMCIA SCSI interface on a Dell Latitude LM
running RedHat 5.2. I can address the drive fine and dump files with
dd and cat. I'm looking for a bulk data slurper, source or RH RPM. I'm
willing to throw this beast on the SPARCstation 5, but I'd rather not
put it in that corner just yet. At the moment, the drive is several
dozen times larger than the computer controlling it.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
To Wit
(about dd blocking handling)
The original need for dd came with the 1/2" tapes used to
exchange data with other systems and boot and install Unix
on the PDP/11.
Those days are gone, but the 9-track format lives.
To access the venerable 9-track, 1/2" tape, dd is superior.
With modern SCSI tape devices, blocking and unblocking are no
longer a necessity, as the hardware reads and writes 512-byte data blocks.
( what i was familiar with )
However, the 9-track 1/2" tape format allows for variable length blocking
and can be impossible to read with the cp command.
The dd command allows for the exact specification of input and output block
sizes, [[and can even read variable length block sizes, by specifying an
input buffer size larger than any of the blocks on the tape.]]
(Stan was right on target here eh ?)
Short blocks are read, and dd happily copies those to the output file
without complaint, simply reporting on the number of complete and short
blocks encountered.
Murphy's Law was postulated long before digital computers,
but it seems it was specifically targeted for them.
When you need to read a floppy or tape, it is the only copy in the
universe and you have a deadline past due, that is when you will
have a bad spot on the magnetic media, and your data will be unreadable.
To the rescue comes dd, which can read all the good data around the bad
spot and continue after the error is encountered. Sometimes this is all that
is needed to recover the important data.
Example dd bs=265b conv=noerror if=/dev/st0 of=/tmp/bad.tape.image
Yup .. using cat to do the same thing, it gets the err signal and
drops, but dd can be told to ignore it
So in this case its clearly superior, and the *only* tool for 9 track tapes,
( due to the block handling )
So i stand before you better educated. thx to those that filled in the
missing bits
Raymond
> Date: Thu, 2 May 2002 02:01:33 -0700 (PDT)
> From: Ethan Dicks <erd_6502(a)yahoo.com>
> Subject: Tape dumping programs for Unix/Linux...
> To: classiccmp(a)classiccmp.org
> Sender: owner-classiccmp(a)classiccmp.org
> Reply-To: classiccmp(a)classiccmp.org
>
>
> So I finally got this TSZ07 that I've been wanting for a while so I can
> archive a mountain of magtape I have (including System III sources for
> the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp
> stuff off of tape, but it's tedious. What tools are people using for
> tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
> that essentially pulls everything off the tape until logical or physical
> EOT. I'm looking for something similar - point it at the drive and
> siphon it on down.
Look for a program named "copytape". It copies tapes including the
block structure, file marks, etc. Unlike dd(1) which only really
works if all blocks are the same size and there is only one file
on the tape. It can copy tape-drive to tape-drive or tape-drive to
disk file, and puts markers in the disk file to indicate the
structure of the data on the tape.
Copytape is a "classic" piece of software, its source file begins as follows:
/*
* COPYTAPE.C
*
* This program duplicates magnetic tapes, preserving the
* blocking structure and placement of tape marks.
*
* This program was updated at
*
* U.S. Army Artificial Intelligence Center
* HQDA (Attn: DACS-DMA)
* Pentagon
* Washington, DC 20310-0200
*
* Phone: (202) 694-6900
*
**************************************************
*
* THIS PROGRAM IS IN THE PUBLIC DOMAIN
*
**************************************************
*
* July 1986 David S. Hayes
* Made data file format human-readable.
It should be available at numerous FTP sites.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
> From: Raymond Moyers <rmoyers(a)nop.org>
> To: classiccmp(a)classiccmp.org
> Subject: Re: Tape dumping programs for Unix/Linux..
> Date: Thu, 2 May 2002 20:15:37 -0500
> In-Reply-To: <3CD16EDB.31791.1013160B@localhost>
>
> On Thursday 02 May 2002 18:52, you wrote:
>
> > Someone had copied a tape whose records were 16 KB long using software
> > that expected the records to be 8192 bytes longs ... and only asked
> > for 8192 bytes in each read() request.
>
> Now i really do find this interesting
>
> Lets scope out some examples to illustrate my focus.
>
> On a floppy or a hard disk as examples you have
> pad data inbetween its records these are usually
> all FF's constant stream on 1's in other words
> then an address mark like FE followed by the header data
> Head Sector Cylinder ,, then some more FF's then a start
> of data mark the block of data then the CRC .. then all
> else is ignored ,, be it artifacts from a prev write ( hub speed jitter )
> or whatever .. the controller is looking for its string of a minimum
> number of 1's then the FE and so it repeats all round the disk.
>
> During lowlevel formatting you are basically building an image
> of this track .. complete with the between sector filler of FFs
> amd dumping a whole track at once with the write track command.
>
> These devices are random access, but when you pull the image
> off the device using it as a streamer, you are not getting
> the filler bytes the address marks or the crc's your getting
> only the content of the sectors (soft physical records)
> back to back a raw spool off a unix device with a typical
> device driver gives you the data without the controler
> interested bits off the media.
>
> I would assume that any decent unix driver up to the minimal
> expectations of behavior should act the same, including
> that for a proper interface to a 9 track tape.
>
> If the record length is varible, then is not the record length
> in the block headder ? and should not the driver read
> that from the headder then xxx bits of data ?
No. You haven't been around tape drives long enough. The tapes
are not preformatted with block headers. They are written sequentially.
In general, a tape drive can only record forward and add data beyond
whatever has already been written.
> it would seem that any tape used as a random access
> block device, that ever had a record re written would
> have garbage (from a prev update of that record)
> in the block,
> just like on a floppy where this happens all the time,
> (jitter again) and the controller simply ignores looking
> for its resetting minimal number of FF's and the next
> address mark
Only some very special tapes with extra tracks for tape mark
information can be reliably used as random-access block devices.
The classic example is DECtape, 3/4 inch wide on 3 inch reels.
Pre-formatted into blocks of 129 12-bit words or other interesting
combinations.
> ( im ignoring the hard sector media with a hole for
> every sector, but it would still apply in this scope
> albeit a bit differently)
>
> Now .. excuse me, but ive been around this stuff
> for a long time, and i think ive got a really firm grasp
> of the minimal amount of things needed in place for
> any data-to-media, data-from-media scheme to work.
>
> So, do i have this right ?
No.
> That if i spooled off a 9 track tape, and assuming no
> non-recoverable media errors, that i would *not*
> get all of the data from all the records and without
> trailing garbage and the controler interested bits left out ?
Your tape-reading program might truncate all block lengths to
the length that it was "expecting". Or just quit after the
first file instead of reading all the files on the tape.
> Knowing the proper expected behavior of any unix
> driver i could name ... i find this rather ....
> well unexpected.
Nobody has said that Unix has well-designed tape drivers.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
From: Cameron Kaiser <spectre(a)stockholm.ptloma.edu>
>> If a formula for determining classic computer cool factor gets finalized,
>> I'd like to create a calculator script on the VCF website so that people
>> can enter their parameters and have their score automatically computed.
>>
>> We need a unit or label for this number.
>
>The neuron.
Feh! Too common, everyone has a few many don't use them.
First it should be dimensionless, those are weird enough. If not then
like DB (DeciBell) which will give it a log or exponential character though
I'd be interested in seeing other oddly shaped numbers.
A possible name? Calcula with a range of values from microcalcula
(watch calc or smaller) to Kilo or maybe megacalcula(Sage! or other beast).
Allison
> Here you are talking about a data tape with fields that make up records
> where the records are all the same size and the fields being varaible
> length inside the record but repeating in all the other records.
No, I am talking about a data tape with a physical structure that can
be interpreted as a sequence of physical records (each of which has a
length) and end-of-file (EOF) marks.
The physical records can be blocks of multiple logical records as well.
There are also inter-record gaps that separate the physical records
and EOFs from each other, and I suppose the information about how long
those are may be of interest to someone too, it just hasn't been of
interest to me yet and I certainly don't see an obvious way to get
that information using common hardware and software.
> But a tape like this, from the days when tapes was used as random
> access devices is not the format of a system archive tape is it ?
Just because tapes were used as random access devices, that doesn't
mean they were always used that way or were particularly good for it.
And a system archive tape didn't need to be structured for random
access.
So, take classic MPE :STORE format. I'm thinking that it defaults to
having a maximum on-tape block (physical tape record) length of 8192
bytes, but that's overrideable by the user and variable in any case.
A single-volume (single-reel) :STORE set has several parts:
(a) two files that could actually contain useful bits if this is
really a :SYSDUMP tape (each is followed by its own EOF, even if
not present); if this isn't a :SYSDUMP tape then there are
two consecutive EOFs at the start
(b) a :STORE label, which is a single 80-byte tape block followed
by an EOF
(c) a :STORE directory, which is written as blocks of up to the
maximum block length; each block contains a number of 24-byte logical
records which give the names of the files to be stored on this
volumeset; again, this is followed by an EOF (Note this presents the
order in which the files are stored on the volumeset)
(d) user files, each of which is written as one 256-byte block
containing a copy of the MPE file label followed by more blocks
of actual file data, and finished off with an EOF (Note I may be
forgetting some things about how user files are written to the
tape; in particular I can't remember how user labels are stored;
Stan may know more)
(e) a :STORE trailer label, which is another 80-byte tape block
followed by three EOFs
A multi-volume :STORE set makes for some additional complexity.
Volumes after the first don't have the two files and EOFs and just
start with the :STORE directory, plus once you get to multi-volume you
also need to deal with whether a file was split across volumes.
OK, maybe I could kinda sorta do this by cat'ing the tape files to
disk files and writing some code to kludge around the lost
physical-record boundaries. I'm not sure about the user files but
I have some ideas to try.
But frankly I'd rather have a container file format and tools to
collect and preserve the information. Then I can treat the container
file like a tape. If I can write some descriptive text in the
container file as well, that would be like sticking a label on the
tape to me.
> If it was me i would spool the whole raw image to disk, and work
> with it there ,, it can certainly be massaged into any format you
> like after that ...
That is what I want too. The problem is, the "raw image" includes
information other than the bytestream. If you use bytestream-oriented
tools like cat, you lose that other information.
-Frank McConnell
Hi,
don't know whether this is appropriate for this list, but I'll ask
anyway (it's over 10 years old).
I've got a machine which has a 4860 motherboard, this a combi
80486/80860 with EISA slots.
Overall it works fine, but there is a small problem enabling the
cache.
The battery is broken, so after turning off it loses it's BIOS and
EISA configuration. When this happens I can go into the BIOS and
setup everything, *enable the cache*, and boot from ide disk. Problem
is since the EISA configuration is still invalid, the SCSI controller
does not work.
After I setup the EISA configuration with the DOS CF.EXE utility, the
SCSI controller works, but the cache is disabled, and I cannot
re-enable it in the BIOS menu (menu item is disabled).
What can the problem be? Anyone experienced s/th similar?
regards,
chris
I'm looking for any documentation and software for the Definicon DSI-32
(NS32032 PC/XT coprocessor board). ... anything would be useful!
Thanks in Advance,
Bill Morgart
morgarws(a)Molbio.sbphrd.com
> -----Original Message-----
> From: Raymond Moyers [mailto:rmoyers@nop.org]
> If i might use the 1991 mips 3k sysVr4 unix thats on my old sony
> NeWS again as an example, its tar program cant write
> or read from a file. its only provided function is to/from
> the tape device to the file system,, how absurd !
Absurd? It is for making "tape archives..." :) On the other hand,
I'm sure there must be some way to make it work, though, if you
wanted an on-disk archive, I'm sure they would have expected you to
use ar. ;)
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");
'
In a message dated 5/3/02 2:22:42 AM Pacific Daylight Time,
tothwolf(a)concentric.net writes:
> http://members.aol.com/innfogra/idt624a1.jpg
>
> Based on looks alone, I'd guess it is some type of RAM. IIRC, IDT did make
> some RAM, but also made quite a few other special purpose chips.
>
> > http://members.aol.com/innfogra/idt624a2.jpg
>
> This link didn't work btw.
>
>
Fixed the broken link, thanks Toth.
The bottom is the same as the top, 8 more small gold caps. I remember
something about them being 1 Meg something or other. That something or other
is what I am trying to figure out of course.
I wonder if they could be an EEPROM like another smaller chip I have. That
one is listed on ebay at the moment as a SEEQ EEPROM. It uses a similar but
smaller IDT chip like this as a controller.
<A HREF="http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=1728103123">eBay item 1728103123 (Ends May-09-02 12:53:43 PDT ) - Unusual Gold SEEQ 1
Meg E</A>
Maybe these are a 1 Meg EEPROM based on 64K cores? Anyone got a book out
there?
Thanks for the help.
Paxton
Astoria, OR
>I picked up another Mac SE today, and it's got a "Macintosh SE PC Drive
>Card" installed in it, with a big connector on the back of the SE. What is
>the card for?
Apple made a PC compatible drive that worked with the SE and the Mac II.
It needed a special card to connect to the computer (why they couldn't
just use the already present Floppy port I have no idea). There was an SE
PDS slot card (the one you have), and a NuBus version for the Mac II.
They made this for the era before they were shipping the "SuperDrives"
that could read/write 1.44 disks, and PC format disks.
It ONLY works with the SE or the Mac II. I don't know if it will work
with the SE FDHD.
If you had the Mac II NuBus card, I would ask you for it, but I already
have the SE version.
-chris
<http://www.mythtech.net>