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
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 |
+--------------------------------+-------------------------------------+
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 --------------
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
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]
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.
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.
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
>
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?
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