>It's the bench-top console for the M7341 microprocessor. The
>KC341-A was the rack-mount console.
Thanks...
>One would presume, then, that you've got a couple M7341's in your
>archives, too :-).
I believe I had one board at some point, but I haven't see it yet...
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 |
+--------------------------------+-------------------------------------+
<How is this AGC level derived, and how is it compared to the signal?
It is the rectifed output of the dectector circuit and and it's not
compared.
Allison
<Could anyone tell me how a radio detects signals vs. static? There is a
<little gauge on my radio that moves depending on the amount of noise vs.
<signal. I would guess that the digitally tuned radios that skip over the
<frequencies that are pure static work in the same way. What is this way?
Static is inchoherent radio signals (random). generally they are far
weaker so the selection is done on signal strength or in the case of FM
modulated systems reduction in received noise. Actually it's fairly
simple.
Allison
<Please forgive my interloping, here, but my SHUGART and Siemens SD 8" drive
<are spec'd for 6 ms step rate, and the double-headed types for 3 ms. It's
<really best (mechanically) to step these babies as fast as they will go, an
<it's quieter too.
Be specific on the model as the sa800s and 850s would never do 3ms! Though
the later ones did step faster. The problem with 8" drives are that there
were some that were doing their best at 10-12mS and a few like CDCs 3ms
was the norm. Most fell in around 6mS.
ALSO, the PC controller uses the 765 chip (or it's core) generally and
that chip can truncate the first step pulse by 1/2mS (8/5"). So the
fastest recommended step rate programming (srthut in SPECIFY command)
is 4mS. I believe it was never fixed.
Allison
<I bought mine new as a kit in '83, as part of the first production run.
<They didn't have HDD support then, and since I made and sold an adapter
<daughterboard to interface to Z-80 processor sockets, one of several, I wa
<not concerned about that. The board always worked reliably and, aside fro
<the occasional need to read a standard diskette, the system was pretty
<complete.
Mine is only slightly later, has the 5380 scsi chip.
<Well, the drive attached to my two boards, i.e. the hard drive, is an ST-50
<that was lying about some fifteen years ago when I happened to need a drive
The sequence of disks over the years for the HDD side:
xybec and st506 bought new in 82(late). Still have both.
Adaptec, and Quantum D540 (31mb) much faster.
the adaptec died and the xybec was in with a st251 for a while
then the fujitsu 3.5" scsi drive.
<>supported. The host interface was very similar in concept and nearly
<>in execution as IDE.
<
<
<The history included in the IDE spec clearly indicates that it was patterne
<after the 1003-WAH board (of PC/AT fame), which is the PC-bound eqivalent o
<the 1002. It uses the same IC's, hence the same command structure and bit
Here we go again... I DIDN'T SAY IT WAS IDE. I said it was similar in
respect that it was a bus level interface for a controller and predates
IDE. I do know that the wd1003 was what the IDE base design was patterned
after.
<definitions. I'm inclined to try hooking an IDE drive up in place of the
<1000-05 board and ST-506 drive just to see what it does. I'd imagine they
<emulated it faithfully.
<On Thu, 15 Apr 1999, Allison J Parent wrote:
<>Simple dont use word, it's virus prone.
<
<What if someone needs it for their job?
<
<--Max Eskin (max82(a)surfree.com)
Well as someone that's running 35 clients and 3servers all microspooge
I can say it's really keep me busy and a virus is really a major
headache. As a result for me it is the job. I'd rather be running VMS.
Allison
I thought it would (mmaybe) be helpful to point out that WD made several
similarly designated controllers during the period when the
8"-drive-compatible models were available. The WD 1000 series members which
used the 8X300 microcontroller used a different command set or register
organization, which was, IIRC inverted in some sense, i.e. either the
register order was the inverse of the one on the LSI version, or the
commands were the complement of the ones the LSI version (designated
1000-05, 1000-08, the latter of which I doubt was ever shipped) As several
folks have indicated some of these controllers had both the 50-pin connector
for the 8-inch drives' data cable, and the 34-pin connector for the 5-1/4"
drives' data cable.
What's not entirely obvious with the LSI controllers' jumper layout,
characterized in the documents only as a means for disconnecting biasing
voltages from the PLL circuitry during calibration, is that if one removes
the shorting plugs from some models, again depending on the version, a
jumper then will suffice to bypass the PLL circuitry, thereby allowing the
use of the clock already available from those drives which provide it on the
data connector. If this clock is fed to the circuitry downstream from the
PLL, the controller needs no further modification aside from changing the 4x
crystal, shipped at 20 MHz, to one at 17.36 MHz, which is 4x the standard
rate for 8" drives. That means that an oscillator and a single jumper is
all that's necessary to convert some of these boards from 5.25" to 8".
Persons wishing to use 8" HDD's should BE CAREFUL with the negative bias
supply. Just like some 8" FDD's, some of these drives have on-board
regulators for the negative supply, hence will only work if they're fed a
nominally -12 V dc source (actually anything greater than -8 vdc and not
damaging to the circuitry will be ok) since there's an on-board regulator.
A bypass jumper is usually provided, as some
drives will be used with supplies designed for drives without the on-board
regulator, therefore demanding -5V dc.
If this bias supply is not correct, either due to the lack of compatible
supply and regulator, or because -5 is being fed to the regulator, the drive
will not work. If -12 is fed to the drives which have no regulator, the
head interface circuits and probably the data conditioning circuits will be
damaged. BE CAREFUL!
I didn't learn about this over a beer after work, or by reading an article
in a magazine . . . 'nuff said???
Dick
Dick
-----Original Message-----
From: Don Maslin <donm(a)cts.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 16, 1999 4:14 PM
Subject: Re: Will The Grand Master Of Disk Controllers step foreward?
>On 16 Apr 1999, Eric Smith wrote:
>
>> > Specifically the WD-1000-5 disk controller. These are the ones that
>> [...]
>> > If you are intimately familiar with this legendary interface, I would
>> > like to hear from you. I need to figure out how to modify it for 8"
>> > harddrives.
>>
>> Regrettably I no longer have the manual or schematics for these, so a lot
>> of this is from memory.
>>
>> The WD1000-5 was the WD1000 repackaged on an 8" * 5.75" board, to match
the
>> form factor of 5.25" drives.
>>
>> The original WD1000 and WD1001 had both 34 and 50 pin drive control
>> connectors. I'm guessing that the WD1000-5 left the 50 pin connector
out.
>> However, you only need to scramble the pins appropriately, as the actual
>> signals are the same. All odd pins are ground on both connectors; the
others
>> should map thusly:
>>
>> 34-pin 50-pin signal
>>
>> 2 2 *RWC reduced write current
>> 4 4 *HS2 head select 2
>> 6 40 *WG write gate
>> 8 8 *SC seek complete
>> 10 42 *TK0 track 0
>> 12 44 *WF write fault
>> 14 14 *HS0 head select 0
>> 16 NC
>> 18 18 *HS1 head select 1
>> 20 20 *IDX index
>> 22 22 *RDY ready
>> 24 36 *STEP
>> 26 26 *DS1 drive select 1
>> 28 28 *DS2 drive select 2
>> 30 30 *DS3 drive select 3
>> 32 32 *DS4 drive select 4
>> 34 34 *DIR step direction (in when asserted)
>>
>> The radial data connectors are the same for both drive sizes.
>>
>> The bigger problem is that 8-inch drives used a data rate of 4.34 Mbps
rather
>> than 5 Mbps. I seem to recall that the WD1000 had a jumper setting for
this.
>> If they removed the 50-pin drive control connector, they probably also
removed
>> the jumper and supporting circuitry.
>>
>> > Also, does anyone have docs for the Quantum Q-2040 8"
>> > Winchester? I dunno what kind of power to feed it (24v sounds correct,
>> > but I seem to recall it used 110vac also!), and so on.
>>
>> No data here, but almost certainly not 110 VAC. Probably 24V AC and 5V
DC.
>
>Sorry Eric, but the spin motor is identical to the ones used in the
>Shugart SA80n series - 120 VAC 60Hz 1.6 Amp. The rest of the power
>requirements come in through a 6-pin connector, also identical to the
>Shugart, so I would assume +5 VDC, -5 VDC (maybe), and 24 VDC. Probably
>to the same pinout as the Shugart.
>
>> You *might* be able to get a Q2040 to run at 5 Mbps, but I've never
>> personally seen it done.
>
>I have a hazy recollection of running one on a latter day HDC to view data
>contents, but the details elude me now.
> - don
>
>
NOW YOU"VE DONE IT!!! I actually went down into the "pit" and found a
relevant data book. In this case it's the 1981 Zilog Data Book. The
portion of the first chapter, which deals with the CPU, has timing diagrams
on pages 18-20, dealing with the opcode fetch (M1)cycle, memory cycles, and
I/O cycles. The latter two types show both a read and a write cycle. From
the timing diagrams and text it is clear that unless one is concerned with
the minutiae of how the external resources are accessed, the only things
which need to be accounted for in evaluating the execution time of a series
of instructions is how many T-states or clock ticks are required for each
cycle type. Without wait states, an M1 CYCLE is ALWAYS 4 clock ticks long,
a memory read or write CYCLE is 3 clock ticks long, and an I/O read or write
CYCLE is 4 clock ticks.
It would be beneficial if we kept this discussion restricted to the two
processors at hand, i.e. the Z80 and (if you like) the MOSTEK and NEC
"equivalents" which at least claimed to exhibit the same timing
characteristics, and the NMOS 6502's in their various speed grades as were
available in 1980 more or less. There's no question that this doesn't
include the Z8 or the Z180 or the Z280 or any other part, nor does it apply
directly to the various other parts which later inherited the 'Z' or some of
the genuine Z80 characteristics. There's no doubt the Zilog folks, clever
as they were, figured out ways in which to improve their products in later
generations.
I thought I pretty well covered why it's not relevant how long the bird dips
his beak into the memory, so long as you remain mindful of how often,
maximally, it can do so. Your statement indicates an awareness of this, but
both your statement and your asserted conclusions suggest you've confused
the memory access cycle length for the memory cycle rate or frequency. For
purposes of clarity I've postulated that there are two parts to every cycle.
There are other ways of looking at this, but . . . There's the setup phase
and the "active" (for want of a better term) phase. The Z80 active phase
cannot be detected externally in the case of instructions which don't access
external resources. On a 6502 the active phase is defined by the
positive-going (high) portion of the Phase-2 clock. On the Z-80 an active
phase can be detected only when it involves external resources. I'd really
appreciate you referring me to a page in a data book current at the time
which makes any suggestion at all that the Z80 requires any fewer than 3
t-states to execute a non-M1-memory cycle. Even in an LDIR, where there are
NO opcode fetches at all once the process begins, each and every memory
access takes a minimum of three clock ticks or "t-states." This is true
whether the processor is clocked at its maximum or at a much slower rate.
This tells us that executing an absolute jump takes the duration of the
instruction fetch which means the opcode plus the two byte target address.
The diagram clearly shows four normal t-states plus the requisite wait-state
commonly inserted in M1 cycles, so, (a) we now have it straight from the
horse's mouth that the cycle with the one wait state, as your Ampro Little
Board undoubtedly allowed you to observe with your calibrated logic
analyzer, the M1 cycle takes a total of 5 t-states in this, the customary
implementation, and the two subsequent fetch cycles take three t-states
each.
So, the absolute jump takes minimally 4+3+3 clock ticks and, as typically
implemented, 5+3+3 (=11) clock ticks, not 12 as I estimated, to fetch the
entire instruction. The next cycle will ostensibly be an M1 cycle at the
16-bit address fetched as part of the absolute jump instruction. At the
very familiar 4 MHz, this is 2.75 microseconds. On the 6502, an opcode
fetch takes 1 clock tick. A fetch from memory takes 1 clock tick, and a
write to memory takes 1 clock tick. Consequently an absolute jump takes
three clock ticks. At 2 MHz, this is 1.5 microseconds.
You're right, the 6502 takes two clock ticks to execute any of the
"single-cycle" instructons. However, due to the designers' clever use of
simple pipelining, it executes two of them in three clock ticks and three of
them in four, as the execution of each wholly internal "single-cycle"
operation is overlapped with the next opcode fetch, so if you want to argue,
it takes only one, with the exception of the fact the first one takes two.
Its opcode was fetched during the last cycle of the previous instruction,
though, unless it was reached via jump, branch, call or interrupt. What
this means is that when you have a succession of ALU operations, e.g, a
sequence of shifts, the Z80 should win, right? . . . as it takes only five
clock ticks each (with the requisite wait-state) to fetch and execute four
successive left shifts, or 20 clock ticks which equals 5 microseconds. On
the 6502, because of the pipelining, it takes 5 clock ticks, which, in the
case of the 2 MHz processor, is 2.5 microseconds.
Please take a look at the additional comments I've embedded in the quoted
email below.
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: Tuesday, April 13, 1999 7:39 PM
Subject: Re: z80 timing... 6502 timing
><the relatively short memory access strobe, while I was talking about the
><frequency at which they occur, as defined in the spec. I agree completely
>
>Yes so? Often the z80 is moving 16bits, with 8bit wide memory it's going
>to take several cycles. If it were a z280 that would be even more biased
>as it uses fewer "ticks" per cycle and the bus is 16bits wide. Counting
>ticks or whatever as I've repeatedly stated meaningless save for
>discussions of how memory is used and not who is faster.
>
>An aside at this point, the z280 runs different cycle timing as @4mhz would
>be the base z80 of the same speed and the z380 (in z80 native mode) beats
>that as the cycles have been shortend again.
This is irrelevant to the comparison between the processors in the title.
><personal. The fact remains, that the memory CYCLE is three clock ticks
><long, as defined in the spec (though I haven't looked at it in 15 years or
>
>It is not and Like I said the spec is infront of me as I type. Worst case
>its 2. But that in itself is again meaningless.
please, Please, PLEASE take another look. Remember it's the CYCLE length,
not the access strobe width that's relevant to this discussion.
><so since I haven't yet unearthed my Zilog or Mostek data books) and if you
><look at the pictures you saw with your logic analyzer, you should have see
><two read pulses of whatever lenght they were, spaced at very nearly 750 ns
><each time you saw the execution of an absolute jump, or any other
><instruction which consists of an opcode followed by a 16-bit address. The
><same is true of writes. They take one memory cycle, which is three clock
><ticks long, for each byte, although the memory write strobe is a mite
><shorter than the read strobe, IIRC, which I might not, but . . .
>
>Your memory is faulty. and that 750ns bumber is still meaningless. they
>only number for comparative purposes is the amount of time it takes to do
>an absolute jump. For Z80 @4mhz that will be 2.5us. It will require
>memory in the 250ns range to do it.
I've frequently demonstrated, of late, that my formerly steel-trap-mind has
moved significantly in the direction of the polyethylene colander. However,
I did still remembered the details I pointed out yesterday, with the
exception that I thought the minimal number of T-states in the M1 cycle was
five rather than four. . . but I did remember on which pages the diagrams
were printed.
><were inserted as they often were for M1 cycles. Nevertheless, commonly
use
><instructions were MUCH faster on the 2 MHz 6502, than on the 4 MHz Z-80.
>
>A 2mhz 6502 executes a 1byte (say INX) instuction in 2 machine cycles and
>that takes 1uS.
Yes, but it executes two of them in three machine cycles, and three in four,
etc. due to the pipelining which allows overlapped execution and opcode
fetch.
>A 4mhz INC B (any register) takes 4 z80 clocks at 4mhz... damm if that
>doesn't happen to be 1uS! Where is the speed difference?
Yes, but if you execute two of them, it takes 8, and if you execute three it
takes 12. That's 3 microseconds. Now, a 2 MHz 6502 takes only 2
microseconds to increment a register twice.
>According to my book a 6502 absolute jump takes 3-5 cycles and in the 5
>cycle case its 2.5 us.
Not quite . . . the 5 tick jump is an indirect jump, opcode 0x6C. An
absolute jump, opcode=0x4C takes only and exactly three clock ticks.
><probably measure three microseconds for those twelve clock ticks (T-states
><which is EXACTLY how long a 1 MHz 6502 takes to do that. Hence, I conclud
>
>Exactly my point. The 6502 is not faster, it only marches to a different
drummer.
Yes, but if you had carefully read the quoted statement from my previous
email, you'd have noticed I referenced it to a 1 MHz processor, not a 2 MHz
one as was used in the comparison. So you see, for the sake of this
comparison, the drummer is beating twice as quickly.
><I've concluded that most code I've seen underutilizes the internal
resource
><and overutilizes the external ones. Code like that favors processors with
><more time-efficient use of the external resources. Hence, my assertion
that
><there's reason to believe the 6502 at 2 MHz could outrun the 4 MHz Z-80 in
><more or less typical code and in a more or less typical hardware
>
>No again. It can match the z80 and in some cases it's better or worse.
>
Well, I'd be very pleased to see a block of code written to accomplish any
useful (or otherwise definable) task in less time on a 4 MHz Z-80 than it
would take a 2 MHz 6502 to achieve the same end. I'm not saying I can write
better code than you, nor am I even saying it can't be done. I've never
seen it, though. It's virtually impossible to do this against a 1 MHz 6502,
and you're allowing me to continue the comparison between a 4MHz Z-80A and a
2 MHz 6502A, right? The immediately following statement which you quoted
>from my previous email states my view on this. I'd still be interested, if
only as point of curiosity.
>
><environment. Code written to make better than average utilization of the
><internals of a Z-80 might fare better against equally well-written code on
><6502. I'm comfortable with the reality that I'll probably never know for
><certain. Since neither processor is particularly important these days, no
><terribly important to me either.
>
>Agreed well written code is essential for either to do useful work.
>
><None of this is really worth getting all excited about because, by the way
><in spite of its "better" performance, (by my assessment) the 6502 didn't
><accomplish more useful work on MY behalf, because I used a Z-80 running
CP/
><every chance I got due to the abundance of really decent tools and office
><automation software.
>
>Therein lies the key. A good system is not always defined by it's
>hardware. Systems are a combination of practical hardware and functional
>software. This account for why despite their flaws the TRS80, Apple II,
>Z80 CPM based as well as others florished. Most people didn't program
>8080z806502ti990018028085680980886800065815 they ran basic or a word
>processor. the run on of part numbers was deliberate as to most people
>the cpu used was just a number.
>
Quite so, and I'd still be waiting today to get my old 6502 to run WordStar
under CP/M . . .
>
>Allison
>
>
>>Generally the gauge is a reading of the AGC (automatic gain control)
>>level being applied by the radio's IF. There are many other ways to derive
>>this signal, but this is the most common one.
>How is this AGC level derived, and how is it compared to the signal?
Nothing fancy - the AGC circuit is typically just a simple rectifier followed
by a RC time constant. The resulting level goes to your meter and is fed
back into the IF at a point where changing a bias affects the gain. If
there's a "skip over static" function in a digital tuner, it's typically
done by comparing the AGC level with a fixed voltage (possibly settable
with a pot somewhere.)
There are fancier methods of detecting the presence of a signal if you
know something specific about that signal. For instance, if you know that
it's a FM stereo broadcast, you can look for the FM subcarrier.
--
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
<Well, that's not very far from what I wrote, is it? I was just pointing
<out that although Allison seemed to imply that a 6 or 8MHz Z80 was much
<faster than a 4MHz(? I haven't got the original message any more) 6502, I
<believe that to be far from the case.
I was pointing out that is the processor was running fast enough even a
dog can look good. ;) Obviously using a 8mhz z80 as the standard your
comparison CPU had better be of similar generational speed or it may fail
the test. the inverse is with a 33mhz z185 I know I can blow the 65c02
out of the water unless someone has at least a 25-30mhz 6502!
Allison
Guys:
I suspect there is one among us who can rightfully bear this title;
if so, I need his guidance, wisdom, and council. I have some questions
regarding some obscure MFM disk interfaces made by Western DIgital.
Specifically the WD-1000-5 disk controller. These are the ones that
pre-dated the HDC's they made for the ISA bus; they were frequently
found on CP/M and MP/M machines that were equipped with fixed disk drives
(some of the TeleVideo machines come to mind).
If you are intimately familiar with this legendary interface, I would
like to hear from you. I need to figure out how to modify it for 8"
harddrives. Also, does anyone have docs for the Quantum Q-2040 8"
Winchester? I dunno what kind of power to feed it (24v sounds correct,
but I seem to recall it used 110vac also!), and so on.
Thanks.
Jeff
___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]
Please forgive my interloping, here, but my SHUGART and Siemens SD 8" drives
are spec'd for 6 ms step rate, and the double-headed types for 3 ms. It's
really best (mechanically) to step these babies as fast as they will go, and
it's quieter too.
Dick
-----Original Message-----
From: Don Maslin <donm(a)cts.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, April 15, 1999 9:41 PM
Subject: Re: 8" drive on a pc controller
>On Thu, 15 Apr 1999, Bill Sudbrink wrote:
>
>> > > Shouldn't you gentlemen be considering, instead of which format, at
>> what
>> > > kind of DRIVE is involved?
>> >
>> > Excellent point, as I have been using a Mitsubishi that I set at 6ms.
>>
>> Ah!
>>
>> Shugart and Seimens drives, requiring 15ms.
>
>More usual is 10ms.
> - don
>
>
>
> "Kar" is derivated from the Oldhighgerman word of chara/kara with
> an meaning of grief/mourning - so the Karwoche is the week of
> mourning for Christ / the mourning period. While this word is
> no longer in use in German (and no derivate, AFAIK), it is still
> present in English as 'care' (Didn't I already mention that English
> preserved a lot mor ol German words than German itself ? So learning
> English is kind of learning old German.)
>
> I hope this wil end your life long search for the meaning of Kar.
Many thanks.
Perhaps one day I'll learn Anglo-saxon. This is apparently rather like learning
German...
> P.S.: Now solve the riddle of Ostern/Eastern.
Oh no, now I'm getting even further off topic! Historically, Christianity has
had a habit of placing Christian festivals next to pagan ones so as to help
subsume them. A classic example is the winter solstice, which has had Christmas
(Weihnachten) dumped on it. But the name of the North European solstice
festival, Yule, has survived in many languages' names for Christmas.
In the case of the Pascha, the date was based on the Passover - the Jewish
festival at the spring equinox. This put in close to pagan equinoctial
festivals, and the pagan name, Easter/Ostern, has survived in English and
German. The usual explanation is that it derives from the name of a pagan
goddess, Aostre.
Good enough?
Philip.
Can anyone tell me what a
KC341-B
Microprocessor series Monitor/Control panel
is? (Other than the obvious).
It is a DEC item -- it appears to have the standard switches
for a computer front panel, but for a 14-bit wide machine...
I found two of them in my archives, still packed in their
boxes. One has a cable which connects to it and which ends
in a paddle board for plugging into a DEC backplane. I also
have a print set for it...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry(a)zk3.dec.com |
| Unix Support Engineering Group | (home): mbg(a)world.std.com |
| Compaq Computer Corporation | |
| 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 |
+--------------------------------+-------------------------------------+
>Can anyone tell me what a
>
> KC341-B
> Microprocessor series Monitor/Control panel
>
>is? (Other than the obvious).
It's the bench-top console for the M7341 microprocessor. The
KC341-A was the rack-mount console.
>It is a DEC item -- it appears to have the standard switches
>for a computer front panel, but for a 14-bit wide machine...
>I found two of them in my archives, still packed in their
>boxes.
One would presume, then, that you've got a couple M7341's in your
archives, too :-).
--
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
>> attitude is part of a larger problem. Personally, I do not like to damage
>> anything, but once in a while, I like to have some fun. If I didn't do
>
> You know, I like to have fun as well. But my fun consists of taking a
> pile of parts 'beyond economic repair' and getting them working again. Or
> taking a few bits of scrap metal and learning to machine them. Or
> designing Yet Another Useless Interface. In other words creating something.
Hear, hear!
> I really don't understand this love of breaking things.
Nor do I, even though I occasionally experience it. But I try to suppress my
love of braking things on the rare occasions when it does appear, because
creating things is so much more fun.
Philip.
No, I have no personal conflict with an Apple employee. The problem to
which I refer was all to common back in the '70's. Perhaps it was because
of the way in which the various program vendors wrote their software, but
I'd bet it's because they weren't left much choice. The detail to which I
refer is the absence of a message like the infamous IBM-PC's ". . . Abort,
Retry, Fail . . ." message. Once the Apple encountered a read error of some
type, it seemed that it couldn't recover without a restart. I don't know
the details, but I saw it every day that I was in the same room with an
Apple that was not idle. It seemed that the only way to avoid this type of
problem was to avoid the Apple, so, with one notable exception, that was
what I did. These things are based on perceptions, though, not necessarily
a sound and rigorous evaluation of the facts.
I once worked in a room with over a dozen MAC's though, and was the only one
with both a MAC and a PC/AT. We constantly had "trouble" with the MAC's
while I continued to chug along with my PC/AT running DOS. My work was
always ahead of schedule if I could stick to the PC. Now, when I ran the
MAC, e.g. using EXCEL, or McDRAW, which provided functions not so readily
available to the PC, I didn't have as much trouble as some of the more
common programs used by the others, e.g. WORD or MacWrite. I did my writing
in WordStar which I knew quite well, having used it since pre-release 0.7
(WordMaster). I imagine that quite a bit of the trouble was due to the
newness of the network scheme used to share the two laser printers. I'd
point out almost daily, that my PC/AT with a laser printer and a substantial
hard disk, plus a COLOR display, which none of the MAC's there had, cost
less than one of these MAC's alone.
The bias I held against Apple products was based on the perception that lots
of features and performance were sacrificed in favor of the rather lame
color display, which I then felt was useful for games and other forms of
entertainment, which I felt were out of place in the office.
Dick
-----Original Message-----
From: Sellam Ismail <dastar(a)ncal.verio.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 09, 1999 3:19 AM
Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4
floppies)
>On Thu, 8 Apr 1999, Richard Erlacher wrote:
>
>> My contempt for Apple begins and ends with their total disregard for the
>> value of your data. If you wrote to their floppies, especially if your
>> computer was in the "front room" of a business, exposed to whatever dust
was
>> carried in by customers and wind, etc, from the parking lot, (I had a
client
>> years ago, whose mail-order business was operated with the "help" of an
>> Apple-II with two controllers and three drives in just such a location.)
>> you'd frequently observe the computer locking up because it had come to a
>> bit it couldn't read. The reason was probably contamination of media or
>> drives, but the only recovery was the reset. Your data, meanwhile, and
>> perhaps your customer calling long distance, were gone by now. They
>> designed the MAC with no memory parity assuming that you'd not mind if
your
>> data was corrupted without your knowledge, and though the disk handling
was
>> a bit more mature than the Apple-II "I give up . . . and die" it wasn't
much
>> better.
>
>This sounds like poorly written software to me. The only time I've ever
>had my Apple ][ lock up because some data couldn't be read from the disk
>was because the software told the Apple to lock up. I think your bias is
>totally unfounded, or at least founded upon a predisposition to hating the
>Apple ][ for some odd reason. Did an Apple employee fart near you or spit
>on your car at some point in your life or something?
>
>Sellam Alternate e-mail:
dastar(a)siconic.com
>---------------------------------------------------------------------------
---
>Don't rub the lamp if you don't want the genie to come out.
>
> Coming in 1999: Vintage Computer Festival 3.0
> See http://www.vintage.org/vcf for details!
> [Last web site update: 04/03/99]
>
On 12 Apr 99 at 21:36, Mike Ford wrote:
> I have been thinking about and looking for a list like this one, except
> instead of hardware collecting, it would be about collecting software. I
> haven't found any existing list, so I am getting motivated to start a list
> on one of the various services that will host a list for free (free free
> ideally, but I don't have a problem with an ad supported list server
> either). I have a fair amount of feedback that such a list would be
> desirable, so other than a charter which I am still thinking on, two basic
> questions need answering in the next few days so I can get going.
It's a while since anyone last posted the charter for this list, but
I'm sure that it doesn't discourage discussion of >10year software. I
though Classiccmp was about the entire "classic computing experience"
not just the hardware nitty gritty anyway?
Phil
**************************************************************
Phil Beesley -- Computer Officer -- Distributed Systems Suppport
University of Leicester
Tel (0)116 252-2231
E-Mail pb14(a)le.ac.uk
What it amounts to is soldering the "front" of the SIMM to one edge of the
pins and soldering the reverse side to the other. if the edge of the SIMM
is appropriately close to the pin-strip, it makes a very solid connection,
with the loading stresses well distributed.
It doesn't stagger anything. These screw-machine single-pin sockets come in
plastic strips which keep them aligned. The way I accomplish this sort of
thing is plug them into a board which fits their barrel and proceed to
solder the connections, end pins first, on each side of the SIMM until the
job is finished. It's a lot of work, and not always worth it. I once
soldered 4 4MB SIMMs into this arrangement, only to learn that the
motherboard I was using wouldn't deal with the 4 MB parts. . . . too bad .
. .
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 16, 1999 9:41 AM
Subject: Re: 30 pin simms, not so hard to find.
>At 09:23 AM 4/16/1999 -0600, you wrote:
>>BTW, it's important that they be soldered on both sides. That's what
makes
>>the job difficult.
>
>How in the world do you do that? Wouldn't they become staggered?
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
--- Richard Erlacher <edick(a)idcomm.com> wrote:
> Actually, there was a DIPP package for many of the DRAMs. It was a
> single-in-line-looking version of the DIP, except that all the pins were on
> one side and they were staggered in their alignment.
I have several classic machines that use them, the Amiga 3000 included.
> These were most often referred to as ZIP's, though I don't know why.
Zigzag Inline Package
> The package was somewhat popular for about 5 years, after which it fell
> into disuse.
They were more fragile than DIP DRAMs (I've broken several pins off over
the years), but they did provide much better RAM density over DIPs. If
you wanted 4Mb of RAM with 256K parts or 16Mb of RAM with 1Mb parts, the
board space for DIPs was enormous.
What really killed ZIPs wasn't just the fragile nature of the pins, it was
the rise of SIPPs then SIMMs, once the custom sockets became available. You
get ZIP-like memory density with very few customer-acccessible interconnects
to go wrong.
I have a pile of 1Mx1 ZIPs that I don't need (I got a bag of mixed chips
and pulled all the 256Kx4's for my A3000). Does anyone out there need
some 70 or 80ns 1Mx1 ZIPs? I also have a few *massive* ZIPs that I think
are video memory of some kind. I'll have to look up the part number.
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
BTW, it's important that they be soldered on both sides. That's what makes
the job difficult.
Dick
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 16, 1999 9:13 AM
Subject: Re: 30 pin simms, not so hard to find.
>You can solder a SIMM to a 30-pin row of screw-machine socket pins (not
>easy, but it works) and end up with connections much superior to what you
>normally get with SIPPs. They will not bend as easily and you'll have much
>less trouble with the beasties than with normal SIPPs, especially the ones
>which have once had a bent pin, because those continue to want to bend.
>
>Dick
>-----Original Message-----
>From: Arfon Gryffydd <arfonrg(a)texas.net>
>To: Discussion re-collecting of classic computers
><classiccmp(a)u.washington.edu>
>Date: Friday, April 16, 1999 6:57 AM
>Subject: Re: 30 pin simms, not so hard to find.
>
>
>>
>>>>Have you got any 1Mb DIPPs??
>>>
>>>I have seen SIPPs, but have none of either. What exactly is a DIPP?
>>
>>A DIPP is another name for SIPP by morons (Like myself) who momentarily
>>forgot that SIPP was the correct name.
>>
>>Anyone have any small 1Mb SIPPs?
>>
>>----------------------------------------
>> Tired of Micro$oft???
>>
>> Move up to a REAL OS...
>>######__ __ ____ __ __ _ __ #
>>#####/ / / / / __ | / / / / | |/ /##
>>####/ / / / / / / / / / / / | /###
>>###/ /__ / / / / / / / /_/ / / |####
>>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
>># ######
>> ("LINUX" for those of you
>> without fixed-width fonts)
>>----------------------------------------
>>Be a Slacker! http://www.slackware.com
>>
>>Slackware Mailing List:
>>http://www.digitalslackers.net/linux/list.html
>
>
> Actually, there was a DIPP package for many of the DRAMs. It was a
> single-in-line-looking version of the DIP, except that all the pins were on
> one side and they were staggered in their alignment. These were most often
> referred to as ZIP's, though I don't know why. The package was somewhat
> popular for about 5 years, after which it fell into disuse.
>
> Dick
ZIP == ZigZag Inline Package
Actually, there was a DIPP package for many of the DRAMs. It was a
single-in-line-looking version of the DIP, except that all the pins were on
one side and they were staggered in their alignment. These were most often
referred to as ZIP's, though I don't know why. The package was somewhat
popular for about 5 years, after which it fell into disuse.
Dick
-----Original Message-----
From: Geoff Roberts <geoffrob(a)stmarks.pp.catholic.edu.au>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 16, 1999 8:53 AM
Subject: Re: 30 pin simms, not so hard to find.
>
>----- Original Message -----
>From: Arfon Gryffydd <arfonrg(a)texas.net>
>To: Discussion re-collecting of classic computers
><classiccmp(a)u.washington.edu>
>Sent: Friday, April 16, 1999 10:19 PM
>Subject: Re: 30 pin simms, not so hard to find.
>
>
>>
>> >>Have you got any 1Mb DIPPs??
>> >
>> >I have seen SIPPs, but have none of either. What exactly is a DIPP?
>>
>> A DIPP is another name for SIPP by morons (Like myself) who momentarily
>> forgot that SIPP was the correct name.
>>
>> Anyone have any small 1Mb SIPPs?
>
>Yes I have quite a few ex 386SX-20 Diskless workstations circa 1993.
>Er small? Was there more than one size.
>These are the same size as the equivalent simm, and can be converted to
same
>by CAREFULLY removing the pins and the solder. (Not easy, but I have done
>it and made it work on occasion - though only when desperate it's a real
>PITA)
>
>Cheers
>
>Geoff Roberts
>
>
Oddly enough, though it hasn't been my stock-in-trade for about 15 years, I
still have the manual for the original WD-1000 controller. I may, in fact,
even have one of the boards around somewhere. I certainly have a couple of
the ones used in the TVI TS-806-20's I have sitting in the driveway (under
4" of snow, at the moment).
Dick
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 16, 1999 9:07 AM
Subject: Re: Will The Grand Master Of Disk Controllers step foreward?
>
>-----Original Message-----
>From: Eric Smith <eric(a)brouhaha.com>
>To: Discussion re-collecting of classic computers
><classiccmp(a)u.washington.edu>
>Date: Friday, April 16, 1999 1:45 AM
>Subject: Re: Will The Grand Master Of Disk Controllers step foreward?
>
>
>>> Specifically the WD-1000-5 disk controller. These are the ones that
>>[...]
>>> If you are intimately familiar with this legendary interface, I would
>>> like to hear from you. I need to figure out how to modify it for 8"
>>> harddrives.
>>
>>Regrettably I no longer have the manual or schematics for these, so a lot
>>of this is from memory.
>>
>>The WD1000-5 was the WD1000 repackaged on an 8" * 5.75" board, to match
the
>>form factor of 5.25" drives.
>
>
>There's more to the difference than that. For one thing, the WD1000 series
>used the WD1100 chipset and an 8X300 microcontroller to run the whole
thing,
>while the WD1000-05 and -08, as well as the later models, used the WD1010
>chip along with other combinations of the 40-pin support chipset of which
>WD1014, which was, in at least one incarnation, an 8041.
>
>>The original WD1000 and WD1001 had both 34 and 50 pin drive control
>>connectors. I'm guessing that the WD1000-5 left the 50 pin connector out.
>>However, you only need to scramble the pins appropriately, as the actual
>>signals are the same. All odd pins are ground on both connectors; the
>others
>>should map thusly:
>>
>> 34-pin 50-pin signal
>>
>> 2 2 *RWC reduced write current
>> 4 4 *HS2 head select 2
>> 6 40 *WG write gate
>> 8 8 *SC seek complete
>> 10 42 *TK0 track 0
>> 12 44 *WF write fault
>> 14 14 *HS0 head select 0
>> 16 NC
>> 18 18 *HS1 head select 1
>> 20 20 *IDX index
>> 22 22 *RDY ready
>> 24 36 *STEP
>> 26 26 *DS1 drive select 1
>> 28 28 *DS2 drive select 2
>> 30 30 *DS3 drive select 3
>> 32 32 *DS4 drive select 4
>> 34 34 *DIR step direction (in when asserted)
>
>
>This should look pretty much like 8" floppy disks. An early controller I
>built used an FDC chip to drive these control signals, as the 8"
Winchesters
>had the same maximal step rate back then as the 8" double-headed FDD's.
>That's overkill, and the FDC expects to see things from the data stream
>which close the loop, and it won't see them. Open-loop, e.g. simple
>head-positioning command operation is possible, at least to see if the
>drive's mechanical functions are working. An enterprising approach would
be
>to operate the drive with a pair of small single-chippers one fairly slow
>one to handle the head positioning, and the other a fairly quick one to
>modulate the data, e.g. with ERLL code as was used in the PERSTOR
>controllers.
>
>>The radial data connectors are the same for both drive sizes.
>
>
>Yes except that some drives extracted clock locally and sent it on the data
>cable as well. For that reason, it would be advisable to stick with the
>4.34 MHz data rate. Keep in mind, also, that while the wide cable is
driven
>with open collectors, the data cable is intended to be driven with
>differential drivers/receivers of the MC3486/87 or 26LS31/32 type.
>
>>The bigger problem is that 8-inch drives used a data rate of 4.34 Mbps
>rather
>>than 5 Mbps. I seem to recall that the WD1000 had a jumper setting for
>this.
>>If they removed the 50-pin drive control connector, they probably also
>removed
>>the jumper and supporting circuitry.
>
>
>Western Digital was somewhat confused about how they should number their
>controller models back in those days, and the scheme got muddled, but as I
>recall, and I have some controllers to prove it, the data rate was fixed on
>the board at the factory, in some cases, particularly the larger WD1000
>boards with the WD1100 chips + 8X300 on board, had a discrete VCO as
opposed
>to the 74S124 or the LS624 they later used. These VCO's had to be tuned
>quite carefully and a procedure was included in the instruction manual.
>There were jumpers for accomplishing this tuning operation on nearly every
>type of board in this entire family, but one needed both a crystal and a
>retuned VCO for the PLL, not to mention changing the passive components in
>the integrator (LPF) of the clock extraction circuitry. The process of
>setting the VCO center frequency was not terribly difficult, but one had to
>know which jumpers to remove at which stage of the operation because there
>were inputs to the circuit which had to be active and other which had to be
>passive at different stages of the operation.
>
>>> Also, does anyone have docs for the Quantum Q-2040 8"
>>> Winchester? I dunno what kind of power to feed it (24v sounds correct,
>>> but I seem to recall it used 110vac also!), and so on.
>>
>>No data here, but almost certainly not 110 VAC. Probably 24V AC and 5V
DC.
>
>
>The power connections are precisely what is used with an 8" FDD, including
a
>110 VAC supply for the spindle motor. Don't forget that some 8" drives had
>to be fed a negative 5V supply while others could swallow either -12 Vdc
>or -5, depending on a jumper because they had on-board regulation. You
have
>to look for the regulator and ensure it has the jumper which bypassed it in
>the correct position.
>
>>You *might* be able to get a Q2040 to run at 5 Mbps, but I've never
>personally seen it done.
>
>We, meaning my people and I, tried this several times and never got it to
>work reliably with Shugart drives. They did some signal processing on the
>data, and included clock on the cable, so you might be able to skip the VCO
>retuning if you can find the "right" place to inject this conditioned clock
>in the data/clock recovery circuit. I'd be surprised to find the Quantum
>drives did things much differently, as they had to be compatible with the
>Shugarts, and some controllers, e.g. Intel's, relied on the drives or other
>external circuitry to extract clock.
>
You can solder a SIMM to a 30-pin row of screw-machine socket pins (not
easy, but it works) and end up with connections much superior to what you
normally get with SIPPs. They will not bend as easily and you'll have much
less trouble with the beasties than with normal SIPPs, espacially the ones
which have once had a bent pin, because those continue to want to bend.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Friday, April 16, 1999 6:57 AM
Subject: Re: 30 pin simms, not so hard to find.
>
>>>Have you got any 1Mb DIPPs??
>>
>>I have seen SIPPs, but have none of either. What exactly is a DIPP?
>
>A DIPP is another name for SIPP by morons (Like myself) who momentarily
>forgot that SIPP was the correct name.
>
>Anyone have any small 1Mb SIPPs?
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html