Re: Intel

On 8/3/2024 3:24 PM, TTman wrote:

On 03/08/2024 23:18, Don Y wrote:

On 8/3/2024 2:18 PM, Joe Gwinn wrote:

And hung onto the Intel '86 architecture a tad too tightly, for far
too long.

>
Intel's folly was abandoning their more diverse offerings and focusing
solely on the x86.  Yeah, they tinkered with SA and Xscale but deluded
themselves into thinking that the "PC" would roll on, forever.  They
completely missed out on the larger embedded market in favor of more pricey
PC "CPUs".
>
OTOH, many of the original "big names" made similarly narrow-minded
decisions.
>
Remember SC/MP?  2650?  2A03?  8x300?  1802?  T11/F11?  9900?
Z280/Z800/Z8000/Z80000?  16032?  RGP?  29K?
>
What's truly amusing is how GI managed to survive and, to some extent,
thrive -- despite their dog of a "CPU"!
>
Sad that we have so few "choices", now.  And, such brain damaged I/Os!

>
My fave was the NSC800...I usd it in the first (?) all cmos hand held terminal...

The 1802 predated it as the first CMOS *CPU* (no idea as to first
"CMOS hand held terminal")

and the Z80 could do io mapped DRAM, albeit slowly but it worked as a printer buffer!

Z80 clocks were slow enough that you could squeeze the refresh
cycle into each M1 and a few "muxilpeckers" gave you a DRAM
controller -- at normal bus speed.  A bit clumsier on other
processors.
I put a bank of "by 1" DRAM into a device and allowed each "bit lane"
to be stuffed with either 16Kx1 or 64Kx1 devices.  So, you had 16Kx8
of DRAM with some combination of 0-8 additional bit-widths of DRAM
above that (obviously accessed via a subroutine that would
piece together *bytes* from sequential *bits* in each bit lane)
[I used it as a data store so access time wasn't important]
The 64K I/O space was a huge win as it let you move "stuff"
out of the main *memory* address decoder.  I would cringe when
working on (e.g.) motogorilla hardware and had to more fully
decode addresses in order not to "waste" the single address
space on something as silly as an output latch.
[It was common for Z80/68xx comparisons to be made and rules
of thumb equating their equivalent performance (in some
application niche.  God, I hate the load/store architecture!]
The 68K's bus timing was a significant annoyance as it made
NUMA multiprocessor systems costly to design.  I managed to
design a custom processor that had exactly (on paper) the
same bus timing as the 68010 -- so I could just treat it
as yet another 68K as far as the arbiter was concerned!
[Try sharing a bus between two heterogeneous processors
and you will appreciate the beauty, there!]
The original 32K had an interesting approach with EXTERNAL
coprocessors (FPU, MMU) which others assumed had to be
internal.
[And the 99K was even wonkier with their "workspaces"!]
Now, hardware is boring vanilla.  But, thankfully, the types
of capabilities that are now affordable in OTS devices means
one can move all of that creativity into software, instead!
Eventually, folks will learn to accept them as the new norm...
Heck, it only took a few decades for multitasking to become
the norm... :<