Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: piglet <erichpwagner@hotmail.com>
Newsgroups: sci.electronics.design
Subject: Re: Intel
Date: Sun, 4 Aug 2024 08:43:08 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <v8neus$3vgl0$1@dont-email.me>
References: <f61taj5diic94fobra7adhaero41mofm57@4ax.com>
 <qh7taj52516ohp92mt081mjg7t3fs65vt5@4ax.com>
 <v8macd$3lerk$1@dont-email.me>
 <v8mam1$3lk8k$1@dont-email.me>
 <v8mcia$3lpv9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 04 Aug 2024 10:43:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e42a7d6b6d93b85f2c94bf4d26b78ef8";
	logging-data="4178592"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+xHP/Ug5KJTAq8ddHQmex8"
User-Agent: NewsTap/5.5 (iPhone/iPod Touch)
Cancel-Lock: sha1:SiffDsQtMOVtiKUlbXgbjGwFy7Y=
	sha1:Kg8lvdWFCzoCgbG/TQj9a2EdFBU=
Bytes: 4633

Don Y <blockedofcourse@foo.invalid> wrote:
> 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... :<
> 
> 

Yes, the 1802 was great, the address bus was muxed high byte low bytes so
interfacing to DRAM was extremely easy.

-- 
piglet