Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Intel
Date: Sun, 4 Aug 2024 03:31:33 -0700
Organization: A noiseless patient Spider
Lines: 115
Message-ID: <v8nla5$bnh$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>
 <v8neus$3vgl0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 04 Aug 2024 12:31:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="568bca9e299cae539fb168ca390b4582";
	logging-data="12017"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180ejhS8bXJiuB4C06iyEOS"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:BmeD4D4L+IEv0yDFMoemcBg2RJQ=
Content-Language: en-US
In-Reply-To: <v8neus$3vgl0$1@dont-email.me>
Bytes: 6255

On 8/4/2024 1:43 AM, piglet wrote:
> 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.

The fact that there were a bajillion clocks per bus cycle was
delightful!  Contrast that with things like the 6502/68xx; you
had to resort to one-shots to get "edges" where you wanted them!
The lack of a "refresh counter" meant more devices on the PCB.

"Great?"  Meh... :>

It was (like many other devices in that era) "different".  E.g.,
I/O was more like a "fly by" operation supported by some DMACs
instead of an explicit LOAD/STORE to "I/O space".

I really liked having a shitload of registers available; the idea of
having to keep going back to memory to reacquire a datum that I had
IN MY HANDS a few opcode fetches earlier always annoyed me (even
disguising this as a "workspace" did little to remove the foul taste).

I also miss support for BCD operations (nice when you are dealing
with physical display decoders, etc.).  But, that was true of many CPUs.

Mnemonics were kind of wonky -- largely a consequence of all the
oddities in the programming model (SEX, PHI, GLO, NLBR, etc.)

Today's "programmers" would probably be confused by the variety available,
back then.  I think they assume more "generic" programming models.
Expecting them to understand the architecture of the processor to make
sense of the instruction set ("the reason why things are done THIS way...")
seems like a stretch.

Imagine dealing with an 8x300 ("Where's the CALL instruction???")!