test-drb April 1999

test-drb@ccmp.vtda.org

170 participants
1190 discussions

by allisonp＠world.std.com

<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

26 years, 1 month

Will The Grand Master Of Disk Controllers step foreward?

by edick＠idcomm.com

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 > >

26 years, 1 month

z80 timing... 6502 timing

by edick＠idcomm.com

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 > >

26 years, 1 month

Signal detection

by CLASSICCMP＠trailing-edge.com

>>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

26 years, 1 month

stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies)

by allisonp＠world.std.com

<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

26 years, 1 month

Will The Grand Master Of Disk Controllers step foreward?

by jeff.kaneko＠juno.com

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]

26 years, 1 month

8" drive on a pc controller

by edick＠idcomm.com

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 > > >

26 years, 1 month

OT: Religious Festivals (was:Re: Fwd: H8 Enthusiasts)

by Philip.Belben＠pgen.com

> "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.

26 years, 1 month

Another item to identify

by gentry＠zk3.dec.com

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 | +--------------------------------+-------------------------------------+

26 years, 1 month

Another item to identify

by CLASSICCMP＠trailing-edge.com

>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

26 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb April 1999