Hi all, I'm having a clearout with a pending house move. All these bits
are in Southampton, UK. I'd prefer them to go quickly as one lot but
will consider any and all requests. No guarantee that all this works,
but most of it I've used some time in the past! Please contact me off
list if you're interested.
Sun SS20 doesn't boot. Comes with a pair of Ross 150MHz CPU's and lots
of memory that I never got around to installing.
Sun ultra2. Has solaris 8 installed and works fine. 4GB disk, 200MHz CPU.
Box of sun sbus cards - GX, network, SCSI, etc.
Sun type 5 keyboard and 2 mice.
2 SGI Octanes. Single and dual R10K with SI gfx. Possibly a dual R12K if
you can convince me to get rid of it :-)
Iiyama 19" FST CRT monitor with VGA & 5*BNC connectors. Really, really
nice picture but a few scratches to the glass.
Selection of I-BUS PCI & ISA passive backplanes, including a 20 slot ISA
monster! Most of these are PICMG (think that's it?) mixed ISA/PCI.
DDS1 drive
DDS2 drive
4 SCSI CD-ROMs
2 HP ProCurve 10/100 switches
"Jeta" power supply. pulled from some system it comes with a basic
hand-drawn pinout and does 5V at 80A, 12V at 6A & 12V at 10A
Selection of small (<=9GB) SCSI drives. Mix of 50, 68 & 80 pin.
Right, that's the boring stuff... More interesting is 3 crates from my
rescued Whitecross WX9020 system. I'm keeping this as a working system
with system controller and processing crates but getting rid of the 3
storage crates. Each is a 19" 6U unit and includes 4 disk "modules" (one
of them is missing a module). Each module has 2 disks, each disk is 4GB
and has it's own controller card. Each card has an Inmos T425
transputer, NCR SCSI controller and 16MB of ECC RAM. On the back of each
crate are power boards to take the 48V system power to 5V and ??. The
other cards in the crate I'll keep as spares for the rest of the system
since they're of little use on their own. You could build a 22
transputer network with the disk controller cards - just apply power and
patch in to the links. I've put some pics on Flickr
(http://www.flickr.com/photos/17208732 at N00/sets/72157604779715870/) so
you can get an idea of what I'm talking about :-)
There's probably more to come. Probably some peecee rubbish too!
Cheers,
James
Well,
Some nice items I picked up today:
2 rack config with 1 PDP-11/35 (10" box) & 2x RK05
2x spare PDP-11/35 (10" box)
3x spare RK05
20 RK05 packs
6 Unused RK05 packs
small stack of system documentation
11/23+
No pics, I forgot to take the camera with me.
Ed
I have just about managed to get DECWindows up. All bar one thing.
After logging in as a user in the DECWindows dialog box I get this error
message.
"No license is active for this product" The DW-MOTIF license is loaded
and active.
So what is it referring to to? Answers please
Rod Smallwood
I have a new bounty out for the following items:
1. netDrives Brujo CD/MP3 player
2. AudioReQuest ARQ-1 MP3/CD Player
I'm offering $200 for each unit. They must be working and with original
firmware.
Please contact me directly if you have either of these.
Thanks!
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
Our user group and museum here in NJ -- the Mid-Atlantic Retro Computing
Hobbyists (MARCH) -- owns a Straight-8 as of yesterday morning.
This one is the desktop version (vs. the rack-mount version). Of course,
"desktop" is relative -- it weighs about 250 pounds.
It sat in someone's barn for a few decades, so it was VERY dirty ... but we
put some effort into cleaning off the top layer. Inside we found mouse
nest! But no mouse, whether furry or electronic.
One of the two translucent plastic sides is broken. We plan to fix it, or
rebuild it, or find a suitable replacement.
We also picked up an ASR-33 and a plotter with the PDP-8.
Gotta love transistors, core memory, and flip-chips.
Best of all, we have the story that goes along with the computer -- see
www.resistors.org -- here's an excerpt from the group alumni wiki:
>>>> DEC donated a PDP-8 (original series with 4,096 12-bit words of core
memory), and a model 33 ASR Teletype to the group. We went to Maynard, Mass.
and picked these up from 'the mill' (the original headquarters building) and
brought it back to the barn in someone's VW bus. The computer was mounted on
a pallet with 4 handles so it could be carried like a sedan chair <<<<
So, that's another good reason to come to VCF East 5.0, Sept. 13-14 ....
you'll get to see our desktop Straight-8 with the original accessories (and
manuals and paper tapes, etc.)
- Evan
>
>Subject: Re: 8251 troubles
> From: Brent Hilpert <hilpert at cs.ubc.ca>
> Date: Tue, 29 Apr 2008 00:50:50 -0800
> To: General at priv-edtnaa04.telusplanet.net,
> "Discussion at priv-edtnaa04.telusplanet.net":On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
>
>
>
>Allison wrote:
>>
>> >
>> >Subject: Re: 8251 troubles
>> > From: Brent Hilpert <hilpert at cs.ubc.ca>
>> > Date: Mon, 28 Apr 2008 13:22:08 -0800
>> > To: General at priv-edtnaa03.telusplanet.net,
>> > "Discussion at priv-edtnaa03.telusplanet.net":On-Topic and Off-Topic Posts
>> > <cctalk at classiccmp.org>
>> >
>> >dwight elvey wrote:
>> >>
>> >> Hi
>> >> The routines SETUP and COUT are ROM routines.
>> >> SETUP passes the first byte to the clock generator and the
>> >> remaining to the command port of the 8251. The command/status
>> >> port is 1 while the data is 0.
>> >> COUT sends text to a video board.
>> >> The second COUT never seems to get executed?? I give plenty
>> >> of time between characters because I send then manually.
>> >> The board can do interrupt driven serial but that didn't seem to
>> >> work so I went for the simpler polling method.
>> >>
>> >> DI
>> >> CALL SETUP
>> >> ; .DB $01F ; 9600
>> >> ; .DB $01D ; 4800
>> >> .DB $01B ; 2400
>> >> ; .DB $019 ; 1200
>> >> .DB $0AA ; SYNC
>> >> .DB $0AA ; SYNC
>> >> .DB $040 ; RESET
>> >> .DB $0CE ; 2STOP, NO PARITY, 8BIT , X16
>> >> .DB $010 ; CLEAR ERRORS
>> >> .DB 0
>> >>
>> >> MVI A,$027 ; RTD, DTR AND REC-EN TX-EN
>> >> OUT 1
>> >>
>> >> CALL TIN
>> >>
>> >> CALL COUT ; This works
>> >>
>> >> CALL TIN
>> >>
>> >> CALL COUT ; never gets here
>> >> ......................................
>> >>
>> >> TIN:
>> >> IN 1
>> >> ANI 2
>> >> JZ TIN
>> >> IN 0
>> >> RET
>> >
>> >I have the datasheet for the 8251A but not the 8251 here, so just some guesses:
>>
>> They are the same except for timing and some quirks/bugs.
>
>Well, in general, differential quirks/bugs can go a long way to being a problem.
>There's a fair set of differences listed in the A datasheet.
I know, I was product engineer for NEC when 8251AC was released.
>
>> > - perhaps the 8251 (as opposed to the A) requires the receiver to be re-enabled
>> > (not a full reset) after receipt of each character (an 'explicit ack') (?).
>>
>> Not required.
>
>OK.
>
>
>> > - .. check the error flags to see if a framing error is occurring?
>>
>> You don't have to but it's an idea.
>>
>> > - .. try sending a stream of (best random) characters at full rate,
>> > as opposed to just 2 manually? This might get around some framing
>> > inconsistency or such to at least see if a subsequent character can be received.
>>
>> ??why.
>
>8251A doc says device is picky about seeing the STOP bit.
>Suppose for example, there is an inconsistency between the framing being sent
>and the rcvr cfg, returns first character ok but sends dev into error state,
>and error state does something to subsequent characters returned.
>In general, it might help tease out an otherwise consistent consequence of some
>unexpected behaviour.
It is a bit picky bit then that would creat a framing error and it will still
recieve the next byte. The only "error state" is that the framing flag is
set and if you didn't check it on a byte by bye basis you have no clue what
byte caused it, it continues to recieve (async). Generally the device is
very stupid.
>> > - (may be inconsequential, but in the init sequence the two sync characters
>> > are not preceded by a mode byte (perhaps SETUP does this internally?))
>>
>> Thats required only for SYNC mode not async.
>
>As Dwight has explained they are there for a reliable init, even for async
>mode. I was noticing that it's different than what is suggested for init in the
>A doc, which is to write 3 nuls to the command register followed by a reset
command.
You do that for any 8251 on reset as a matter of course as you may not know
the prior state and you always get to a initial command state. I always
do it but I find for async unless you have a flakey hardware reset it's
not usually required thing for async.
Like I said I use it a lot as I have a potload of them (both A and non A)
>from multiple vendors. I laso have many system that thats the primary
serial IO. NS* horizon, NS* advantage, SBC880 and the companion 5 port
serial card, Vt180 used 4 of them and I have load of them as well. I
do use and program the part still. For Bisync its a disaster, for simple
async the bugs are not near as annoying. I've seen far more problems with
things like toasted 148x drivers/recievers (and DEC 963x) and one end
as 8n1 with the companion system as 7p1!
Other ways to break the part include no baud clock when programming,
chip clock not at least 4.5x the baud clock. There are a few others.
Allison
VCF Midwest happened, and a good time as had (by all?) I've posted a
few pics and various commentary at the 'blog here:
http://silent700.blogspot.com/
Today's post has link to a Flickr set with many more pics, and a short
video. Many thanks to Pat and all others involved in making VCF-MW
happen again this year!
-j
--
silent700.blogspot.com
Retrocomputing and collecting in the Chicago area:
http://chiclassiccomp.org
> Date: Sat, 26 Apr 2008 23:15:41 -0500
> From: Jim Leonard
> I disagree somewhat, if only to present the evidence of the PCjr. Now
> *that* was clearly meant as a home computer (cartridge slots, wireless
> keyboard, small and light, built-in composite video)
I use the introduction of the Peanut as proof that IBM was still
suffering from the shock of having customers flock to buy the PC. As
they discovered, even the unwashed public had its limits as to what
could be passed off as an IBM product. Or maybe it was just the
result of a drunken bet. You forgot the complete lack of DMA and,
shall we say, "anemic" interrupt handling facility?
How about the 1990's IBM "multimedia" computer system? Use it as a
phone answering machine, fax machine, CD player, etc. The only
problem being that you have to leave it on all the time. Toshiba
made a similar blunder at about the same time with its Infinia
machines--only to abandon the desktop business altogether.
Cheers,
Chuck
This brings seeral questions about the hardware.
What is the state of CTS/ (clear to send active low) if the state of
the input is false it will never send. It effectively disables the
transmitter and can be used for hardware handshake.
Also the command instruction must have bits 0 and 2 set to enable Tx
and RX repectively. Typical command byte would be 35H or 37H.
Allison
>
>Subject: 8251 troubles
> From: dwight elvey <dkelvey at hotmail.com>
> Date: Sun, 27 Apr 2008 08:23:09 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>
>Hi
> I've got a funny problem with a 8251.
> I've been writing 8080 code and seem to have a strange
>problem.
> I initialize the chip in async mode. I have a light box on the
>serial wire. It is initialized to both send and recieve.
> I send one character to the 8251 and it passes it to the software
>on the 8080 side. I display it on the 8080 side.
> I then send another character to the 8251. Nothing happens.
>It won't receive until I reset it.
> None of the status lights change. I can see the data light flicker.
> It could be a bad part but it just doesn't seem that it would
>work once and then fail to work for the second character.
> It just doesn't make sense.
> Is there something I'm missing about the 8251.
>Dwight
>
>_________________________________________________________________
>Spell a grand slam in this game where word skill meets World Series. Get in the game.
>http://club.live.com/word_slugger.aspx?icid=word_slugger_wlhm_admod_april08
Dear Jason,
Are you really looking for sony floppy drive model#MP-F52W-00D ,
Please be informed that I do have 2 unit of the above item.
Kindly advise?
Warmest Regards,
Desmond Lwe/29.04.08
I am looking for a Sony floppy drive Model# MP-F52W-00D. Do you have any
information on how I could obtain one? Please reply to both e-mail addresses
in this message.
Thank you,
Jason
Hello,
You wouldn't by chance still have those tu58-k tapes still available? I'm just taking a shot at it. Any response would be appreciated.
Regards, Jim
For nearly five years I have had some pages on my website
regarding the MicroProfessor MPF-1. These pages included
binary images from the ROMs and redrawn schematics along
with other technical information. This was done with the
understanding that I had a tacit agreement from Flite
Electronics to so do having discussed these pages with a
representative of Flite.
Now I have received what can only be described as a thinly
veiled threat from one of the directors of Flite demanding
certain actions on my part but not, strangely, the removal
of any of the disputed information.
What I would like is some help on what I can freely publish
without having to worry about any action from Flite.
As Flite and I are both in the UK this at least does not
include the problems of crossing any legal borders.
And, just in case any Flite directors read this list, when
you prefix the question "Indeed, I am being very polite and
conciliatory?" with the threat of "?causation and damages?
through your public domain exposure of our copyright
material for so long." then no, you are not.
Lee.
>
>Subject: RE: 8251 troubles
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Mon, 28 Apr 2008 11:22:58 -0700
> To: cctalk at classiccmp.org
>
>> Date: Sun, 27 Apr 2008 15:41:49 -0400
>> From: Allison
>
>> I have both in quantity. Generally it's the quirks of the
>> "improved part"that are annoying but for simple Async serial IO
>> they are identical enough.
>
>It could be that simple polled-mode async I/O works well enough, but
>when I was trying to get a bisync package working with the 8251, I
>wanted to chew my own arm off. Among the issues (other than the
>occasional device "hang") that I had was the lack of double-buffering
>and the indeterminate control logic (it was possible to disable the
>transmitter in the middle of a character). The 8251A was *much*
>better in that respect.
>
For async its ok bisync, you gotta be crazy. While the A helped
bisync it broke the CTS/ CTS to inactive during a TX meant the
character would be resent! The Fix was for both A and non A
is a gate to interlock the external CTS/ with TXE.
>In any case, Dwight has the NEC part which renders the topic moot.
Not really as it had the exact same bugs.
>
>I found at the time that the Signetics 2651 was a far better chip for
>most utility purposes than the 8251, having the benefit of an
>internal baud-rate generator for async operation.
It was better.
Allison
>Cheers,
>Chuck
> Date: Sun, 27 Apr 2008 15:41:49 -0400
> From: Allison
> I have both in quantity. Generally it's the quirks of the
> "improved part"that are annoying but for simple Async serial IO
> they are identical enough.
It could be that simple polled-mode async I/O works well enough, but
when I was trying to get a bisync package working with the 8251, I
wanted to chew my own arm off. Among the issues (other than the
occasional device "hang") that I had was the lack of double-buffering
and the indeterminate control logic (it was possible to disable the
transmitter in the middle of a character). The 8251A was *much*
better in that respect.
In any case, Dwight has the NEC part which renders the topic moot.
I found at the time that the Signetics 2651 was a far better chip for
most utility purposes than the 8251, having the benefit of an
internal baud-rate generator for async operation.
Cheers,
Chuck
I was wondering if anyone out there has a VT52 they'd be willing to part
with... As most of you are aware, I have oodles of goodies to trade.
--
David Griffith
dgriffi at cs.csubak.edu
>> This was done with the understanding that I had a tacit
>> agreement from Flite Electronics to so do having
>> discussed these pages with a representative of Flite.
> Do you have any of this in writing (or email)?
I may have. This was nearly five years ago and I'm hoping
that the emails from Flite are among those I have archived.
> The information seems to be gone (or I'm looking in the
> wrong place).
As it was the easiest option it has gone for now at least.
>> What I would like is some help on what I can freely publish
>> without having to worry about any action from Flite.
> Presumably nothing of theirs.
That's what I need to sort out. Can I post a redrawn schematic?
How about board pinouts, or system descriptions?
> uk.legal might be the place to start.
It may indeed, thank you.
Lee.
I'm doing a bit of spring cleaning so I have a Sharp Hayac 2900 with disc's
and manual looking for a new home.
I like to trade it for HP stuff (printers HP-1000 interface or computers
calculators )
I also have a MicroVax II for trade (this a BA23) with cpu 2Mb memory and
disc and TK-50 controllers but no disc or tape drive.
If you don't have any of this well maybe we can work someting else out.
I live in the Netherlands.
Rik
>
>Subject: RE: 8251 troubles
> From: dwight elvey <dkelvey at hotmail.com>
> Date: Sun, 27 Apr 2008 18:02:19 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>
>
>
>
>> From: cclist at sydex.com
>
>> Date: Sun, 27 Apr 2008 08:23:09 -0700
>> From: dwight elvey
>>
>> I'm going to assume that you have an 8251A, not an 8251. If the
>> latter, either sell it to a collector or have it bronzed and made
>> into a tieclasp. There are substantial differences between the -A
>> and non-A parts, all annoying.
>
>Hi Chuck
> The chip is a NEC 8251C.
NEC part number are D8251C for intel 8251 and D8251AC for intel 8251A
and the nec part have the same bugs for compatability (really!).
>>
>> Glancing at your code, I'm a bit puzzled by the final initialization
>> byte of 0x10. Why isn't this, say, 0x37? Why would you disable the
>> receiver? 8251A commands are bit-inclusive; that is, ALL bits in the
>> command register are interpreted independently of one another. Thus,
>> 0x10 sent to the command register doesn't just reset the error flags,
>> it also disables the transmitter and receiver and drops DTR and RTS.
>
> I'd originally done a 37 but looking at some example code,
>I thought I'd try separating out that bit. No change in results.
>The data sheet seems to indicate that the flags will not effect
>or stop operation.
Be very careful with soft reset as that means sending the whole command
string again and most users of 8251 reset the this many times (up to 3)
then write commands and read the data input a few times to clear it.
>
>>
>> The implication is that since the command register's write-only, you
>> have to remember the last command you sent if you want to reset the
>> error flag. One of the minor annoyances of a few early Intel
>> peripherals.
>>
>> Anent that last one--make certain that your handshake lines
>> (RTS/CTS/DTR) are set to the proper levels--an inactive CTS will
>> prevent the 8251A from transmitting.
>
> At least at the port, there is no change. There could be something
>at the chip. Since I've not even gotten to the sending serial, yet, CTS
>isn't yet an issue.
First assure your self that the RS232 input device 1488/1489 arent
cooked and data is reaching RXD pin and there is clock and baud
clock of the correct rates.
Some 8080 code known to work.
INIT: ;...
LXI H,$7A37 USART 7 BITS, NO PARITY, HIGH-SPEED
CALL SETURT INITIALIZE 8251
;...
*
* INITIALIZES 8251 USART TO VALUE PASSED IN H-L
*
SETURT:
MVI A,3 VALUE TO RESET UART
OUT UCTL MAKE SURE.
OUT UCTL UART IS RESET
MVI A,$77 VALUE TO ENTER COMMAND MODE
OUT UCTL ENTER COMMAND MODE
MOV A,H GET HIGH BYTE OF NEW COMMAND WORD
OUT UCTL WRITE TO CONTROL PORT
MOV A,L GET LOW BYTE OF NEW COMMAND WORD
OUT UCTL WRITE TO CONTROL PORT
RET
Allison
Date: Sun, 27 Apr 2008 08:23:09 -0700
From: dwight elvey <dkelvey at hotmail.com>
I'm going to assume that you have an 8251A, not an 8251. If the
latter, either sell it to a collector or have it bronzed and made
into a tieclasp. There are substantial differences between the -A
and non-A parts, all annoying.
Glancing at your code, I'm a bit puzzled by the final initialization
byte of 0x10. Why isn't this, say, 0x37? Why would you disable the
receiver? 8251A commands are bit-inclusive; that is, ALL bits in the
command register are interpreted independently of one another. Thus,
0x10 sent to the command register doesn't just reset the error flags,
it also disables the transmitter and receiver and drops DTR and RTS.
The implication is that since the command register's write-only, you
have to remember the last command you sent if you want to reset the
error flag. One of the minor annoyances of a few early Intel
peripherals.
Anent that last one--make certain that your handshake lines
(RTS/CTS/DTR) are set to the proper levels--an inactive CTS will
prevent the 8251A from transmitting.
Hope this helps,
Chuck
> Date: Thu, 24 Apr 2008 22:25:49 -0500
> From: Jim Leonard
> Wow, I can't see it being useful at launch with 16K -- the DOS 1.0 took up
> about 11K if memory serves, and command.com 5K all by itself... I guess
> that left 1.5K to run BASIC.COM and that was all she wrote...
But with the 5150, the diskette drive (160K format) was optional.
All you really needed was a CGA card to get going. You had BASIC in
ROM and a cassette tape interface. The CGA card could be hooked to a
modulator and make pretty pictures on your TV. IIRC, that's one of
the configurations described in the IBM literature.
As another poster has mentioned, it really did seem like the target
was the Apple II and TI 99/4 type of market, rather than the higher-
end "office" machines like the Morrow or Eagle. I almost bought a
NEC APC after I first saw a 5150, thinking that I'd completely
misunderstood IBM's marketing objectives.
Those "pick your poison" expansion slots are what saved that box,
which succeeded, sometimes it seems, in spit of IBM's worst efforts.
Maybe someone remembers that the US 120v 60Hz models were availble
quite a bit before the 220v 50Hz models were--and IBM charged a
premium for the 220v models. I remember going to the local sales
office on Arques and trying to place an order for a dozen of the 220v
models. "Not available yet" was the answer. So, says I, "How about
buying some US models and running them at 120v 50Hz via a
transformer?" "That would void the warranty" was the response.
Apparently IBM also refused to support US systems sent overseas to
50Hz land. It was very strange.
We bought a bunch of US 5150s and shipped them anyway. They ran fine
on 50Hz.
Cheers,
Chuck
>
>Subject: RE: 8251 troubles
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Sun, 27 Apr 2008 11:12:06 -0700
> To: cctalk at classiccmp.org
>
>Date: Sun, 27 Apr 2008 08:23:09 -0700
>From: dwight elvey <dkelvey at hotmail.com>
>
>I'm going to assume that you have an 8251A, not an 8251. If the
>latter, either sell it to a collector or have it bronzed and made
>into a tieclasp. There are substantial differences between the -A
>and non-A parts, all annoying.
I have both in quantity. Generally it's the quirks of the
"improved part"that are annoying but for simple Async serial IO
they are identical enough.
>The implication is that since the command register's write-only, you
>have to remember the last command you sent if you want to reset the
>error flag. One of the minor annoyances of a few early Intel
>peripherals.
Yep, helps to have a table of set up variables.
>Anent that last one--make certain that your handshake lines
>(RTS/CTS/DTR) are set to the proper levels--an inactive CTS will
>prevent the 8251A from transmitting.
Yep,
Allison
Date: Sat, 26 Apr 2008 20:58:36 +0100 (BST)
From: Tony Duell
> Another silly thing is that refresh was controlled by a DMA channel. I'm
> sure it saved a couple chips, but it meant that errant, or
>
> And, indeed, using the 8237 DMA chip with a paging register (and not even
> doing that as elegantly as the FTS-88 did, which at least had one paging
> register per DMA channel) rather than using the 8089 'I/O processor'.
The 5150 has 4 page registers, one for each DMA channel (an LS670 4x4
RAM). Of course that limits one to doing DMA inside of 64K physical
blocks, but that's not too awful. The DMA-driven RAM refresh earned
some writers beer money as they could write articles on how to alter
the refresh rate to squeeze a bit more performance out of the basic
box. On the PC-AT, the big design flaw in the DMA circuitry to me
was the omission of handshaking for DMA memory-to-memory transfers.
It would have made the memory above 1024K much more useful on the
system without having to switch into protected mode.
The "use DMA for refresh" wasn't an awful compromise. At least the
video adapters had their own private memory and didn't load the
system down refreshing out of system RAM (i.e., IBM didn't use an
8275 CRTC, thankfully). Given that the 5150 used 16K DRAMs on the
planar, the Intel memory controller would have been the 8202, a
miserable piece of silicon. It would also have made upgrading to
64K DRAMs a bit more of a chore (requires an 8203).
The 8089 was pretty much of a dead-end product; limited to 20 bits of
addressability, expensive, with only 2 DMA channels. I never did
figure out why Intel introduced it. Our Intel sales engineer didn't
even want to talk about it.
I only vaguely remember the tamper-proof stuff on the 5150 PSU since
I dug into it only a few days after I had the system. Reversed the
fan--again, it was incredible that the case interior was kept at
negative pressure. Suck all sorts of crud in through the floppy
slots. I added a filter over the fan port on the case.
I was still doing the same thing 20+ years later. In an odd twist of
events, I also like to replace the cheap Chinese DC fans with nice
Japanese AC line-powered fans. I've never had one of the latter
develop fan noise--they're just better built.
Cheers,
Chuck
Date: Fri, 25 Apr 2008 22:18:59 +0100 (BST)
From: (Tony Duell)
> I was refering to critical timing between the hardware control lines. For
> example I've used an interface (not QIC anything) where one device
> asserted a signal, then the other device had to acknowldedge within a
> certian (short) time (1us or so), otherwise there would be ig problems.
The best known example of this in spades is the Pertec tape
interface. "Here's the data, catch it!" type of interface. On read,
there's a strobe asserted when data's ready, but no handshake or
other means of throttling the flow. Same for the write side--a "data
accepted" sort of signal, but the data must have been presented on
the host side. Lost data conditions aren't diagnosed, unless the
host decides to incorporate logic to do it (i.e. detect strobe before
data accepted/ready). Given that there's no standard on tape block
length, most Pertec controllers have a bunch of RAM or at least a
good-sized FIFO to deal with the condition that the host may not be
able to keep up with events. Data errors are detected by the drive,
but presented during the course of a transfer, so again, the
controller must be there to latch them when they occur.
IIRC, QIC-02 uses handshaking; QIC-36 does not.
> The QIC36 ISA card I have in my junk box appaers to be essentially a
> QIC-02 host interfaxce and a QIC-02-to QIC36 bridge on the same PCB. I
> keep it because the ASICs on the board are the same as those on a separate
> QIC-02 to QIC36 bridge that I sometimes use with my PERQ, and thus the ISA
> card is a source of spares...
The QIC-36 ISA cards I have are Wangteks--they use an 8085 and a fair
number of house-labeled ICs to do their dirty work. They're
integrated units, though I suspect there's a fair amount of shared
logic with the Wangtek QIC-36-to-02 controller, as it also uses an
8085 and has some of the same house-labeled packages on it.
My QIC-02 cards are by Alliance Technology; nothing to write home
about--just some LSTTL logic and maybe a PAL for address decoding.
About what you'd expect--and apparently clones of the Wangtek PC-02.
Cheers,
Chuck
