>> Maximisation of processor throughput, and minimization of
>> microinstruction count, is at least half the purpose of microprogramming.
>
>Sure. And the microcode compilers I've written and used are much better
>at optimizing horizontal microcode than I have the time or patience to do
>by hand.
>
Your lack of time and patience is not equal to the claim you make regarding
the quality of optimisation possible.
William R. Buckley
Hello, all:
Does anyone have a copy of the AIM65 Assembler ROM and BASIC ROM that
they can shoot me? I read the User's Guide and these seem like interesting
programs to have :-).
Thanks!
[ Rich Cini/WUGNET
[ ClubWin!/CW7
[ MCP Windows 95/Windows Networking
[ Collector of "classic" computers
[ http://highgate.comm.sfu.ca/~rcini/classiccmp/
[ http://highgate.comm.sfu.ca/~rcini/pdp11/
<---------------------------- reply separator
>On an interesting note is the availability of "white" LEDs (actually R, G,
>and B leds all wired together in the same case).
*Most* of the white LED's currently on the market are GaN (blue) LED's that
illuminate a white-producing phosphor. The chromaticity indices of the
resulting light is markedly different than you get from mixing R,
G, and B. (Though this probably doesn't matter to anyone for this
particular application...)
> This leaves open the
>possibility of replacing lamps with white LEDs continuing to keep the 8/e
>in service as it was intended. (I also scavenge wheat lamps when I see 'em!
It requires some small modifications, most noticably some way of dealing
with the pre-heat current (usually done with a shunting resistor across
the LED, though I have also seen schemes where a Zener or lifting a leg
of the pre-heat resistor is done.)
--
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
While I agree fundamentally in that you really don't have to have graphic
output capabilities, to wit, I did without it for over 30 years of computer
use, I don't believe there's any reason to favor the terimnal over the
direct-mapped monochrome video display. It's nominally a 2000 character
window that has to be managed, and whether you do it with a terminal or with
a video board is strictly up to you. I personally believe that exploiting
the approach of the 6545 chip is still a pregnant way to address the problem
of slow video updates due to low (<24.576Mbit/sec) baud rate.
as for what you find difficult to get fixed . . . (a) who cares about fixing
a serial card? Another costs $3. (b) pre-vga monochrome cards and monitors
abound at the thrift stores. Keyboards do as well. (c) so long as hard disk
drives of the ST506 variety still abound in the thrift stores, the
controllers will too. I passed on an 'AT box a week ago, which had a VGA
card, a 200+ MB eide 3.5" 1/3-height hard disk, and much of the usual stuff
for $10. Had there been a decent keyboard, I might have gone for it, but
there'll be others next week.
I figure, if I can't replace it with something similar, then I'll replace it
with something more current.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Sunday, April 04, 1999 7:26 PM
Subject: Re: homemade computer for fun and experience...
>>
>> Again, I have to agree about the "waste-of-trees" nature of most
"technical"
>> documents these days. Nevertheless, I find it easier to understand the
>> result of a SPICE simulation when displayed graphically, e.g. with PROBE
as
>
>There are, agreed, times when a graphical output is essential. I'd hate
>it if my logic analyeser could _only_ give a list of the input states for
>each sample (although sometimes that's what I want). More often, though,
>I want a timing diagram.
>
>My handheld 'scope has an RS232 output that'll send the samples in
>memory. Seeing those as a list of values is not often useful. Plotting
>them is.
>
>However, the fact remains that often graphical output is _not_ essential.
>I can't think why it would be superior to text-only output for
>programming, for example. Or text processing - I do all my word processing
>using TeX on a text-only machine. WYSIWYG would add absolutely nothing.
>
>> I already stated that the "old" machines did the "old" and in many
instances
>> quite persistent tasks well, and still would, given a chance. People
have
>> learned, however, that it's not as beneficial to have OLD hardware as to
>> have new, not because of what it will do, but what it won't. I don't
mean
>> that it won't break. Any hardware can fail. It's a statistical reality.
>
>Although, to be fair, some of the older machines were rather
>over-engineered, and less likely to fail than modern PCs...
>
>> However, if you try to repair that old, fine, terminal you bought in the
>> '80's you'll find you can't get it fixed for less than the cost of a PC.
>
>_get_ it fixed? I fix things (anything) myself, and will continue to do
so...
>
>> If, however, you break your PC, there's really nothing you can't repair
or
>> replace for much less than the cost of the original.
>
>Oh yes? Where do I find an ST506 controller from, new, these days? Or if
>I am using a machine that uses such a drive and the controller fails, do
>I have to replace the drive _and_ restore from backups as well? That's
>hardly a good idea. Ditto for any video card that isn't VGA or higher, etc
>
>Fact is, swapping parts in PCs is easy, provided the PC is absolutely
>modern. If it's even one generation behind, you start having problems
>finding parts. Maintaining an old machine, where proper docs and spares
>are _still_ available is a lot easier.
>
>What if I am depending on some hardware feature of the old card (like the
>current loop interface on the IBM Async card. Ever tried getting one of
>those, or a clone?
>
>-tony
>
For those who are putting together single-density-capable systems
for use on a PC-clone (with Teledisk, 22Disk, and the like), they
may find these articles from comp.os.cpm several months ago useful
(or they may have additional data and/or contradicting data, which
will be useful to the rest of us.)
Enjoy! -Tim.
Single Density on a PC (was Re: 22Disk and CompatiCard)
Author: Amardeep S. Chana <asc1000(a)ibm.net>
Date: 1998/12/30
Forum: comp.os.cpm
Ken Ganshirt <ken.ganshirt(a)sk.sympatico.ca> wrote in article
<36899CB0.19AD9093(a)sk.sympatico.ca>...
>
> I must have a pretty decent floppy controller, because I can even read
> my original SS/SD Os-1 floppies, even though 22Disk warns that it might
> not work for that format. (For the technically curious, this is on a
> Dell 486/50 running Win 95 and the floppy drive is one of those deals
> that has both a 3.5 and 5.25 in a single half-height drive. It's the
> only system I have left with a 5.25" floppy drive.)
>
Ken,
I recently did a study to find out what will and what won't do single
density. Here are my findings so far:
Will support single density / FM:
NS PC87306 Super I/O
SMC FDC37C65
SMC FDC37C78
Most SMC Super I/O chips
Will NOT support single density / FM:
NS 8473
NS PC87332* Super I/O
NS PC97307* Super I/O
WD FDC37C65
Most (if not all) Intel parts
Any Winbond part
Any UMC part
Reportedly will do single density / FM but NOT verified:
NS 8477
Intel 82077AA
Goldstar Super I/O
The NS PC87306 is found in a lot of Dell and Compaq machines from the
486-50Mhz models to the Pentium-90 models. Most Super Micro Pentium
motherboards using the PCI HX chipset also used that super I/O.
*NOTE: It is important to verify the part number on the chip itself. Many
of these newer NS parts will identify themselves to software as PC87306,
but do NOT support single density.
Best regards,
Amardeep
_________________________________________________________________
Re: Single Density on a PC (was Re: 22Disk and CompatiCard)
Author: Amardeep S. Chana <asc1000(a)ibm.net>
Date: 1998/12/31
Forum: comp.os.cpm
Don Maslin <donm(a)cts.com> wrote in article
<915064276.933215(a)optional.cts.com>...
[snip]
>
> Amardeep, I fear that I must question your study. I believe that you
> are ascribing to some of the chips the shortcomings of the FDC
> manufacturer. For example, both the NS 8473 and the WD 37C65 will
> most assuredly support FM. I have DTK FDC cards with the 8473 and
> read Osborne 1 disks with them just prior to writing this. Likewise,
> I have the WD 37C65 in the WD FOX card and it will also read/write
> FM. On that basis, I must have reservations about some of your other
> determinations.
> - don
>
Hi Don,
I understand your reservations and can address every issue. I did not go
into enough detail in the first posting to fully support my assertions.
> : Will support single density / FM:
>
> : NS PC87306 Super I/O
> : SMC FDC37C65
> : SMC FDC37C78
> : Most SMC Super I/O chips
>
The above parts are completely stand alone with on board filters, write
precomp generators, and data separators. They should work with FM in any
board implementation, unless something specific is done to prevent it (not
likely). This is per the National and SMSC (new name for SMC
semiconductor) data sheets. I have tested the NS PC87306 and SMC FDC37C65
using Jeff Vavasour's Model 4 emulator and Tim Mann's xtrs 2.8 under Linux.
They both read and write FM with no problems.
> : Will NOT support single density / FM:
>
> : NS 8473
> : NS PC87332* Super I/O
> : NS PC97307* Super I/O
> : WD FDC37C65
> : Most (if not all) Intel parts
> : Any Winbond part
> : Any UMC part
>
The 1988 data sheet for the NS 8473 states on page 8-32, "While the
controller and data separator support both FM and MFM encoding, the filter
switch circuitry only supports the IBM standard MFM data rates. To provide
both FM and MFM filters external logic may be necessary."
Every 8473 board I have tried failed to write FM. However, it may be
possible to read FM on some boards if the external filters have a wide
enough Q.
The NS PC87332 & NS PC97307 are standalone and by design do not support FM
(verified on the National data sheets).
The only information I have on the WD FDC37C65 is the Always IN2000 card I
have with that chip cannot read or write FM. I suspect it is also
dependent on implementation.
I have new information on Intel...
Intel 8272 is a NEC 765 clone and therefore dependent on implementation
.
Intel 82077AA and 82077SL - data sheet clearly states these parts suppo
rt
FM.
Thanks to Pete Cervasio for testing and reporting that the 82077 does
indeed read and write FM.
Intel 82078 - data sheet clearly states these parts will NOT support FM
.
I haven't yet investigated the new Intel Super I/O chip which is replacing
the 82078.
The Winbond and UMC chips have never worked on any adapter or motherboard
I've ever encountered them on. No idea if its the chip or the
implementation.
> : Reportedly will do single density / FM but NOT verified:
>
> : NS 8477
> : Intel 82077AA
> : Goldstar Super I/O
>
The NS 8477 data sheet indicates that it does support FM (it is
functionally and pin for pin compatible with the Intel 82077). The
Goldstar Super I/O was reported to work with FM in a newsgroup posting I
read once but have never been able to confirm it.
Hope that clarifies things :)
Amardeep
--
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
>Bill Pechter <pechter(a)pechter.dyndns.org> wrote:
>> > ABS - American Bull Shi...
>> >
>> > I have noted one difficulty with ABS, and that is its failure to
operate on
>> > snow
>> > and ice. Since I live in Southern California, I do not get that much
snow
>> > but,
>> > in any quick application of my Mustang's breaks, on snow covered roads,
>> > they always seem to lock up. Well, the pumping action occurs but, at
each
>> > application of the pump, I notice wheel lock-up. There is no stopping.
>> >
>> > William R. Buckley
>>
>> Noted the same thing with my wife's Acura in New Jersey.
>> The bad news is (unlike the last two years) we usually get snow here.
>
>Hi
> I think people miss the point here. First, nothing short
>of retro rockets will slow you fast on snow and ice. The
>best rule here is "SLOW DOWN". Even rainy or dew slick
>roads reduce traction a lot. ABS' generally do much better
>on ice and snow than can be done manually. Yes, they generally
>lock and on lock but it is much better than complete lock
>as all but a trained expert would do under such conditions.
> I'm not all that great a fan of ABS but I think for anyone
>not trained in skid control, it will do better than most
>people would do. Skid training is something that has to
>be learned as an automatic reaction. It requires regular
>refreshing to keep the skill in tune. It can't be learned
>by reading a book, it must be experienced.
> ABS will not do magic, it will in most conditions give
>one a better chance than they would normally have. It won't
>make up for foolish drivers.
>IMHO
>Dwight
>
The detail here is that it occurs even with extremely
light pressing of the brake (sorry for the earlier misspelling)
peddle.
Sure, very slow travel is the best course, which I judiciously
demonstrate in my driving under such hazardous conditions.
I, too, wonder how the computer knows (obviously, it does
not) when lock is due to locking up as opposed to halted
motion.
William R. Buckley
>[I'd suggested that we take this discussion off the list. I'm continuing
>to reply here in this case only because I don't want people to get the
>incorrect idea that Godel's Incompleteness Theorem can be used to magically
>explain away any philosophical problem regarding computers.]
>
>> Is this use of the word "assembly" not yours? I, sir, am quoting you,
not
>> me!
>
>OK, that one was mine. It wasn't in the context you originally quoted, or
>even from the same message you quoted
>(<19990405060635.29296.qmail(a)brouhaha.com>). I had used it three
>hours earlier in the discussion
(<19990405030452.28640.qmail(a)brouhaha.com>).
>So perhaps you see why I didn't understand what you were complaining about.
>It is customary to include a brief quote of the actual context you are
>referring to.
>
The quote was passed down several layers of reply. I expect one to
remember one's own words. Your failure to do so does not provide any
obligation on my part.
>> That says nothing about the general case
>> that humans have superior intellectual capacity vis-a-vis the computer.
>
>In the general case, I've never claimed that they do. I've only claimed
that
>in a sufficiently limited problem domain with a time limit (i.e., the
solution
>value vs. time curve is a flat with a sharp drop to zero), a computer may
>reach a better solution than a human would. I also claim that this is true
>for other common solution value vs. time curves; if the solution is worth
$x
>today but only $x/2 tomorrow, the computer may produce a more valuable
>solution than would a human.
>
Time limits accepted but, that is not my concern. I am refering to an
ultimate issue, which is that humans have intelligence, computers
do not. Any high-speed moron has the opportunity to surpass a
considerate intellect. Witness the ability of Deep Blue to challenge
the best chess player. Yet, ultimately, a human can decide by means
not algorithmic.
>> What you have failed to address is that the human intellect is not
limited
>> by the capacity to algorithmatise a solution.
>[and later:]
>> Humans have the capacity to make judgements by means outside of those
>> mathematical and logical, hence the reference to Penrose.
>
>Sure. A human may proceed in a manner that is not based upon logical
>deduction or any (obvious) deterministic algorithm.
>
>It is yet to be proven that this human ability (as manifested in complex
>problem-solving) is not equivalent to a non-deterministic algorithm,
>or even to a sufficiently complex deterministic system. Penrose claims
>that quantum uncertaintly is necessary to intelligence. While he provides
>insufficient proof of this claim (really just anecdotal evidence), as an
>argument against machine intelligence it is a red herring, since it is
>not especially difficult to build a system that uses quantum uncertainty
>to influence nondeterministic algorithms.
>
This begs the question, for proof is necessarily mathematical (I, for one,
do not agree with Judicial notions of proof, such as a preponderance of
the evidence). That you hinge your argument upon the lack of a proof
of the means of some human ability simply points to flaws therein.
>> in particular, the notions of Godel: that within any axiomatic system, th
>> answers to some positable questions are indeterminable.
>
>You know, since you mentioned the book GEB, I thought you might have been
>trying to bring Godel's Incompleteness Theorem into the discussion. But
>since you didn't specifically state that, I wanted to give you the benefit
>of the doubt.
>
>The Incompleteness Theorum if very useful for certain lines of reasoning.
>And it might be relevant to the strong AI problem. But it has no relevance
>to the compiler problem we've been discussing.
>
It is relevant to the notion that humans must use methods not algorithmic.
>In the compilers "axiomatic system", it is not possible to even construct
>the kind of questions to which GIT refers.
>
>The compiler is not burdened with proving that it is correct, or that its
>own output is correct. At most we are asking it to select the more
efficient
>of several proposed solutions. This in some sense does involve a "proof",
>but the required proof is no of the validity of the axioms (i.e., the
>compiler algorithm), nor is it a proof that the "system" is
self-consistent.
>
>> For all the nit-picky details of the works of these masters, the points
they
>> make are far grander. The real value of their works is not kept solely
>> within the realm from which their conclusions emerge, but within which
>> such conclusions find additional value.
>
>If you know where to apply them. You can't just willy-nilly claim that
>GIT applies to any random problem.
>
This is one of the wonders of human intelligence: to make leaps of logic
and application.
>If you are going to maintain that GIT precludes compilers generating code
>as efficient as the best human-generated code, you'd best be prepared to
>present a logical argument as to why GIT applies. It's not a magic wand,
>and I'm not going to concede your point at the mere mention of it.
I am not applying GIT to the operation of compilers. Instead, I am applying
it to the operation of human intelligence. Whether you concede the point
makes no difference to me. My purpose is to refute your claims of the
superiority of software versus human intelligence, and that is all.
William R. Buckley
Hi Gang:
I went on a trip to one of the local electronic/scrap stores today, and
noted that they have about twenty CPU and other boards from some sort of
Tandem machine for sale. They're marked $10 each (that's about $6.50 US)
but one could probably haggle with success.
Is anyone on the list into Tandem? There hasn't been any discussion of
Tandem and their "non-stop" line (read as "full stop" for those with any
hands-on experience with the machines) on the list at all, in my
recollection.
I'm not into Tandem either, but if anyone's interested I can call the
store owner for further info this week.
Kevin
--
Kevin McQuiggin VE7ZD
mcquiggi(a)sfu.ca
Boy, we're way off topic here.
First off, most ABS will lock up if all four wheels slip. How's it to know
that you haven't stopped? No variety of braking is going to help you on
ice, only tires (e.g. Bridgestone Blizzak) help there.
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.
Kai
-----Original Message-----
From: Buck Savage [mailto:hhacker@home.com]
Sent: Monday, April 05, 1999 3:20 PM
To: Discussion re-collecting of classic computers
Subject: ABS - or is it Pure BS
>2) even if the ABS system fails it still works just like non-ABS brakes.
unless
>the vacuum (power assisted) system fails or the brake line is cut, or (very
>unlikely) the piston sticks open, the brakes will work just fine.
>
ABS - American Bull Shi...
I have noted one difficulty with ABS, and that is its failure to operate on
snow
and ice. Since I live in Southern California, I do not get that much snow
but,
in any quick application of my Mustang's breaks, on snow covered roads,
they always seem to lock up. Well, the pumping action occurs but, at each
application of the pump, I notice wheel lock-up. There is no stopping.
William R. Buckley
According to the jumper settings on the 5150, it appears that 4 floppy
drives can be connected to the computer. How is this possible? I'm
guessing 2 internal, and two external, but there's only one connector for an
external drive, so it would only allow 3 drives.
Or is there a special controller that has dual external ports?
Any suggestions?
ThAnX,
--
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
