test-drb April 1999

test-drb@ccmp.vtda.org

170 participants
1190 discussions

by guerney＠uq.net.au

Richard, My latest e-mail to you has repeatedly bounced as "Sorry, no mailbox here by that name". If you are out there with a new address and want to continue discussing disks for the CPT 8525 then please contact me privately. Phil

26 years

Moving REALLY BIG IRON...

by mbg＠world.std.com

Recently I posted about some KS10s which were becoming available. I mentioned that I needed to mount a team to try to save them. Well, that part has been a success, and the move is currently set for two saturdays from now, pending acceptence from the current owners of the -10s. Per the current plans: This week I hope to be in attendence when the machines are turned off for the last time in their current home. After that I will being the process of staging the hardware for the move. This involves locking the heads on the disks, raising the leveling feet, removing cables and separating the cabinets. I'm not going to attempt to do it all... Carl Friend (of RCS/RI) and I will finish the pre-staging on friday the 23rd. On saturday the 24th, the team will assemble and simply roll all the stuff down to the loading dock and onto the truck were it will be secured for the move. I will be getting one of the machines. RCS/RI will be getting one, and the third is going to another group in Rhode Island. A couple of RP06s will go with each one. I will, of course, take pictures to document this major move. I also hope to do a write-up in a format similar to the one I did for the move of my more recent acquisitions (http://world.std.com/~mbg/move_report.html) I just wanted to assure everyone that they indeed were going to find homes and weren't going to end up at the crusher or in a landfill. 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 | +--------------------------------+-------------------------------------+

26 years

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

by edick＠idcomm.com

In all the time I was involved in the microcomputer industry, I never saw a single Commodore ad that wasn't printed in a trade publication of some sort. Most of those that I saw were German, though some I saw were in French or Italian, but I couldn't read them. That by itself indicates there wasn't much doing with them. I once read that they had a digital watch switch patent that made them more dough than all their computer-related activities combined. I didn't find that hard to believe. The way in which the Apple computer "won" the schools over was to donate a significant number to each school system with whom they thought they could do some business. Once they were on the Apple path, they were too short-sighted to see it would ultimately lead to much higher costs. For a number of years I served as a member of various committees at the middle school my sons attended. The impression I got was that there were darned few teachers and school administrators smart enough or experienced enough to realize that the "cheap" deal they were getting on their computers were all based on pricing when the products were newly entered in the market, and at maximal cost. Later on, they'd be paying double or triple what they could on the local economy. Dick -----Original Message----- From: Cameron Kaiser <ckaiser(a)oa.ptloma.edu> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Sunday, April 11, 1999 5:59 PM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) >::I don't think Commodore was a factor in this aspect of the process. The >::Commodore machines weren't "accessible" enough, in that there was no really >::convenient way to install the additional hardware people wanted, so nobody >::(well, almost) built it. > >I disagree very strongly with that statement (in a nice way :-). Apples >definitely had a nice selection of hardware add-ons, but there were also >C64 80-column cards (Batteries Included made some), hard drives (first the >Lt. Kernal, then the CMD series), RAM expansions (first the Commodore REUs >and then BBGRAM, RAMLink, geoRAM), modems (first Commodore VICMODEMS and >1600 series, then HesModem, Mighty Mo, etc.), printer interfaces (Cardco, >Xetec; even some Centronics ones) and accelerators (TurboMaster, Flash-8 >and SuperCPU). Many compared quite favourably with the Apple's assortment. >Moreover, the Commodore hardware has always been superbly documented -- >witness the Programmer's Reference Guides on all the major 8-bit Commodores >and even the minor ones like the 264 series (Plus/4, etc.). Granted, this >translated more into better designed software rather than expanded hardware, >but the 64 definitely had its fair share. > >::They couldn't afford a market clash with the Apple. They had a safe market >::in Europe, which didn't seem to suffer as badly from the video-toy-looking >::Apple as their U.S. market did. By the time all the goodies were installed, >::the Apple became a formidable presence to be reckoned with by nearly any >::computer maker. The Apples were unduly costly, but they exhibited an >::unprecedented breadth of applications with more variety of plug-in >::peripherals than even an S-100 box offered. > >But they didn't market-clash with the Apple except possibly in the education >market, which Apple soundly won (depending on whom you talk to, this is >either attributed to Apple's aggressiveness or Commodore's passivity). Apple >may have been trying for the home market at one stage, but they never made >any offerings that could be explicitly marked "home computer". The Apple IIs >were more business computers that happened to play some games, while (PETs >excepted) Commodore made home computers that happened to run some business >applications, IMHO. I've always perceived them operating in just about >separate worlds precisely *because* of the Apple's inclination towards >hardware expansion and the 64's towards software expansion (see the 64 demo >scene for an example of this), which breeds quick market separation because >any emergent applications will be totally differently focused. > >-- >-------------------------- personal page: http://calvin.ptloma.edu/~spectre/ -- >Cameron Kaiser Database Programmer/Administrative Computing >Point Loma Nazarene University Fax: +1 619 849 2581 >ckaiser(a)ptloma.edu Phone: +1 619 849 2539 >-- A dean is to faculty as a hydrant is to a dog. -- Alfred Kahn --------------

26 years

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

by edick＠idcomm.com

I don't think Commodore was a factor in this aspect of the process. The Commodore machines weren't "accessible" enough, in that there was no really convenient way to install the additional hardware people wanted, so nobody (well, almost) built it. They couldn't afford a market clash with the Apple. They had a safe market in Europe, which didn't seem to suffer as badly from the video-toy-looking Apple as their U.S. market did. By the time all the goodies were installed, the Apple became a formidable presence to be reckoned with by nearly any computer maker. The Apples were unduly costly, but they exhibited an unprecedented breadth of applications with more variety of plug-in peripherals than even an S-100 box offered. Dick -----Original Message----- From: Cameron Kaiser <ckaiser(a)oa.ptloma.edu> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Sunday, April 11, 1999 3:14 PM Subject: Re: stepping machanism of Apple Disk ][ drive (was Re: Heatkit 51/4 floppies) >::I agree with you there. The Zilog boys had the CP/M crowd to maintain the >::low-end of their development system market, so nobody could complain it was >::too expensive to develop. The MOS-Technology folks had merely to point at >::the Apple to accomplish the same thing. Meanwhile, Motorola was making a > >Commodore, too (well, they did own MOS Technology, after all). > >-- >-------------------------- personal page: http://calvin.ptloma.edu/~spectre/ -- >Cameron Kaiser Database Programmer/Administrative Computing >Point Loma Nazarene University Fax: +1 619 849 2581 >ckaiser(a)ptloma.edu Phone: +1 619 849 2539 >-- Ours is a world of nuclear giants and ethical infants. -- Gen. O. N. Bradley

26 years

VCF preview

by dastar＠ncal.verio.com

Here's a quick overview on the things currently in the works at VCF central: * Exhibitor guidelines for the VCF exhibit - this year we want YOU to bring the machines to exhibit at the VCF. What's in it for you? We'll be judging each entry on a number of criteria in multiple categories. The best in each category will be honored with 1st, 2nd and 3rd place ribbons, and each Best in Class will be eligible to compete for the coveted Best of Show award. Prizes will be awarded!! * A contest for web site owners to win free passes and other junk by referring the most visitors to the VCF web site. Don't have a web site? Make one! The top winners will have prominent links to their site placed in a prominent location of the VCF web site. Think of all the hits you could get! * Another round of the Nerd Trivia Challenge - the NTC was a big hit last year. This year there will be even more challenging questions. A pre-qualifying quiz will be posted to the VCF web site in the coming weeks. The top pre-qualifying entrants will compete on the first day of VCF, and the top three entrants will appear in the actual Nerd Trivia Challenge on Sunday, October 3rd. Last year, the prize for first place included among other cool things $50 and a Java ring. * Some great speakers are being lined up! The current line up will be posted to the web site shortly (its currently undergoing construction for VCF 3.0). And much more! Stay tuned. P.S. If you'd like to be added to the VCF mailing list to receive updates as they are announced, go over to http://www.vintage.org/vcf/maillist.htm now and fill out the form (the VCF does not share your information with anyone, nor do we spam you!) 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]

26 years

Commodore vs Apple [WAS: Re: stepping machanism of Apple Disk ][ drive

by edick＠idcomm.com

When I referred to middle schools, I meant the "thing" that's in place here in the Denver Public Schools in place of what was junior high school when I attended it (in the same building, by the way). Your observation supports my notion that schools got into the Apples because they'd been given quite a number of them for free. Apple probably couldn't get a big write-off for donating things to the Canadian schools. There's no reason why the Commodore machines couldn't have evolved into someting useful That keyboard on the early models might have been a deterrent for the schools, though, since the Denver schools really teach little more than typing with these computers at the middle school level.

26 years

Commodore vs Apple [WAS: Re: stepping machanism of Apple Disk ][ drive

by gregorym＠cadvision.com

This must have varied significantly with geography. In Ontario, Canada, where I grew up, Commodore was king, both at home and in schools. Most schools' first computers were PETs, either alone or in clusters, followed by C-64s. There were some Apples around, but they were much more expensive (even to schools) than Commodores. Proof of this was the strength of the Commodore (TPUG, Waterloo Basic) and Amiga communities in Ontario.

26 years

z80 timing... 6502 timing

by edick＠idcomm.com

Well, Allison, I now see why this discussion has led nowhere. We were addressing the same issue from different perspective. You were looking at 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 that the memory read access strobe, something on the order of /mreq + /rd (which should yield a more or less appropriate /memrd) is quite short and that the write strobe is probably a bit shorter. What I was doing by tying these strobes to the processor clock period (ticks, cycles, whatever you like) was finding a way in which the overall rate at which they occur could be discussed without getting into the gate-level strategy of building the strobes themselves. That is, after all, a matter of style, and quite 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 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 seen 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 . . . What it comes down to is that the non-M1 memory cycles of a typical 2 MHz 6502 take one clock tick, or 500 ns, while the actual memory read strobe can be as short as you like within the window during which valid addresses are available and ending when the Phase-2 clock falls. As you've pointed out, the M1 processor cycle, comprised of the opcode fetch (a shortened memory read) and the refresh cycle, (during which the instruction was decoded and the memory refresh strobe asserted concurrently with the 7-bit refresh counter), was a bit longer, one or two clock ticks, and more if wait states were inserted as they often were for M1 cycles. Nevertheless, commonly used instructions were MUCH faster on the 2 MHz 6502, than on the 4 MHz Z-80. Offsetting this, however, the Z-80 had lots of instructions which operated on internal registers, leaving memory idle. If you executed a direct jump, which on either processor meant "load the program counter with the following two bytes," The Z-80 required at least five, and perhaps six clock ticks to get to the first address fetch, which took, overall three clock ticks, followed by another three for the second byte. This would amount to 12 clock ticks if my reckoning is correct for the AMPRO Little Board, of which I also have a couple, and on that board, running a 4 MHz Z-80A, you will 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 conclude it is just about twice as fast for that type of instruction on a 2 MHz 6502. How long the memory strobes are doesn't affect the duration of the cycles at all. After looking a what seems like about a billion lines of code over the years since I saw my first one back in the very early '60's (CDC-6400) I've concluded that most code I've seen underutilizes the internal resources 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 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 a 6502. I'm comfortable with the reality that I'll probably never know for certain. Since neither processor is particularly important these days, not terribly important to me either. 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/M every chance I got due to the abundance of really decent tools and office automation software. 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: Monday, April 12, 1999 8:24 PM Subject: z80 timing... 6502 timing >from my ampro LB using calibrated logic analyser... > > Tc = 1/clock z80A 4mhz or 250ns (clock is symetric) > >address stable before Memreq/ ~80nS (occurs 0.5clocks earlier > than read or wr -delays) > WR/ width 210ns (roughly 1 clock -delays) > RD/ width (M1) 290us (roughly 1.5 clocks -delays > RD/ width (other) 390us (roughly two clocks -delays) > >So the longest memory use cycle is address setup+ RD/ or about 470us. >Even the rom chip select was active for less than 400ns and that includes >propagation delays. the 4mhz z80 wants memories with access times in the >250ns range. > >In terms of memory bandwidth used the z80 runs from a high of 80% on M1 >cycles (due to z80 providing memory refersh) to around less than 50% on >other read or write cycles. Refresh is not a required signal for operation >with static rams so the M1 memeory bandwidh can be less than 50%. This >set of statements is also inaccurate as it is worst case for some >instuctions. In those cases like ADD DE,HL that takes many cycles but the >only bus useage is during M1 so the average bandwidth can be very low. > >To get 750ns I need to slow the clock to about less than 2mhz or add the >time for m1 and refresh at 4mhz. In either case it's apples and oranges. > >The 6502 @2mhz would want 300ns memory. An aside to this is that the >6502 like many cpus use both edges of the clock to trigger functions via >a two phase internal clock so there are roughly 4 phase pulses per cycle >internally. the external timing of the 6502 looks simpler due to it's >use of signals and the synchronous nature of the machine. this is wny >external clock frequency is so meaningless. Instruction execution time >is the only measure. > >the 6502 memory useage is far higher as it is active for half the >processor cycle so it's roughly 50% in all cases. This makes hidden >refresh of Drams easier with the regular cycle timing but allows less >time to achieve it. If the refresh is done during the inactive portion >of the 6502 cycle then memory bandwidth nears 100% use. The exception >is if the memory is fast enough it can be done with post read refresh >(cas after ras). Static rams will run at ~50% of bus bandwidth. > >Allison >

26 years

ABS - or is it Pure BS

by chemif＠mbox.queen.it

At 16:02 05/04/99 -0700, many of you wrote: >Boy, we're way off topic here. Yes, I think we are OT, exept if this (anyway interesting) discussion started talking about the CPU that drives the ABS systems (that's BTW older than 10 years). Anyway here my impressions: >Secondly, ABS is for dry or wet roads. It actually increases stopping >distance in snow and gravel, because on those surfaces it is more >advantageous to lock up the wheels and pile up material in front of each >tire. This is very true, and that's why my AUDI 90 was equipped with a switch to disable the ABS on snow. I' ve made many trials with and w./out ABS on snow and found that the switch had a real meaning. >ABS - American Bull Shi... American? Was it a Bosch patent? The only page I found was on Mercedes: http://www.mercedes-benz.com/e/innovation/rd/forschung_nov96.htm > > wheel motion sensors, something like the big GE locomotives. Some > systems used notched brake drums. Yes, in italian "ruota fonica" that in english should be a "sound wheel" or similar: it' the same used inside many needle printer to determine the movement of the carriage. >So? If the car is stopped, the wheels aren't turning. If the brakes have >locked and the car is skidding all over the place, the wheels aren't >turning. What's the difference? >AFAIK, it looks for times when only some of the wheels are stopped (i.e. >it assumes that at least one wheel still has some grip on the road). If >all the wheels are skidding, then essentially ABS won't do a darn thing. I've asking myself the same thing. My thinking is that that the system start its action when it detects the wheel is stopping and it cuts the breaking pressure to this channel so the wheel starts again moving (even on ice an unbreaked wheel rolls), so, in general, it checks that "after cutting the breaking pressure to a stopped wheel, the same keep rolling or not" if yes the system wait for next locking situation, if no the system make some additional attemps on the channels then stops. I think that specially in recent versions the ABS is checking also different speed between wheels. This improvement was necessary to develop the ASR (Acceleration Skid Control) and the amazing ESP (Electronic Stability Program). >Having had decades of extensive driving during the long cold winters in >western Canada, Qebec and Ontario , I would consider myself a quite skilled >slippery road driver. The worst thing you can do when you go into a skid is >lock your brakes. The best is to turn into the skid and use your accellerator >and steering to bring it back under control. I would rather have any brake >action under my control and hope I can steer out of it without using them. I fully agree on the dangerous use of the brakes:I' ve tried to conduct narrow mountain curves with snow, finding wich solution would better work in case I found myself to enter the curve with a higher speed (at last with my front wheel drive car) So I' ve tryed different possibilities E.g. brakes, acceleration, clutch and brakes, a lower gear etc. I found that the best is "clutch and pray" In fact: brakes or clutch and brakes = front wheel skid + worse stability lower gear or acceleration = similarly to breaks you are forcing the wheels to an unnatural speed (different radius)=skid + worse stability clutch and pray = with clutch pressed every wheels automatically adapt to the speed forced by the radius with lateral grip as only job to make, (e.g. with no loose of grip caused by de- or accelerations) and the pray helps...stability :-> > ABS seems just damnright dangerous to me All the above was to be considered with ABS=off >, except perhaps for the complete novice who >would lock his brakes out of fear and >inexperience. No, it's like the usage of safety belts, it works better or worse according to different situations: personally I thank the inventor of ABS because (unfortunately) I had the chance to verify its effectiveness when (in motorway speeding at 160 km/h) I suddenly found a stopped car in the fast lane. The good driving procedures said that one should break down the speed as much as possible (no steering) and then try to avoid the obstacle by steering by its side like this -------------------------------- [=]---->--->-->->->>>\ [X] -------------------------------- -[=] -------------------------------- but at that speed it's very difficult to keep the car in a straight direction to guarantee the necessary speed/stability to make the vital last steering.The working of ABS helped me to decrease the speed with more efficacy and allowed the late steering (while breaking):the car that followed me (no ABS) could'nt do the same and crashed against the stopped car. Really it's not only question of driving skills. Riccardo Romagnoli <chemif(a)mbox.queen.it> I-47100 Forl?

26 years

Pink Screen of Death? (was: Re: Hallelujah!)

by roblwill＠usaor.net

It is also the default color (gray on Blue) for the old DOS WordPerfect versions. -- -Jason Willgruber (roblwill(a)usaor.net) ICQ#: 1730318 <http://members.tripod.com/general_1> -----Original Message----- From: George Currie <g(a)kurico.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Monday, April 12, 1999 3:30 PM Subject: Re: Pink Screen of Death? (was: Re: Hallelujah!) > Well, I don't know. However, MS Word/Windows and /Macintosh has a strange > option: to have large white letters on a blue background instead of black > on white. This has nothing to do with any color settings, and no other > colors can be used in a similar way. This may have classic reasons. Anyone > know? Don't know the exact reason but that was the default color combination of the DOS version of MS Word (and every day I use the current version, I long for the old one). George

26 years

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