Re: Intel

Liste des GroupesRevenir à se design 
Sujet : Re: Intel
De : invalid (at) *nospam* invalid.invalid (Edward Rawde)
Groupes : sci.electronics.design
Date : 04. Aug 2024, 19:27:48
Autres entêtes
Organisation : BWH Usenet Archive (https://usenet.blueworldhosting.com)
Message-ID : <v8oh75$24jb$1@nnrp.usenet.blueworldhosting.com>
References : 1 2 3 4 5 6
User-Agent : Microsoft Outlook Express 6.00.2900.5931
"piglet" <erichpwagner@hotmail.com> wrote in message news:v8neus$3vgl0$1@dont-email.me...
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.

I never used the 1802 but it did look like a nice architecture to me at the time.
Is that the one which stored the return address in the first two addresses of a subroutine or am I thinking of something else?

>
--
piglet



Date Sujet#  Auteur
3 Aug 24 * Intel43John Larkin
3 Aug 24 `* Re: Intel42Joe Gwinn
3 Aug 24  +* Re: Intel30John Larkin
3 Aug 24  i+* Re: Intel4Phil Hobbs
4 Aug 24  ii`* Re: Intel3Gerhard Hoffmann
4 Aug 24  ii `* Re: Intel2Dimiter_Popoff
5 Aug 24  ii  `- Re: Intel1Don Y
5 Aug 24  i`* Re: Intel25John Larkin
5 Aug 24  i `* Re: Intel24John Larkin
6 Aug 24  i  +* Re: Intel21Jan Panteltje
6 Aug 24  i  i+* Re: Intel17Bill Sloman
6 Aug 24  i  ii`* Re: Intel16Jan Panteltje
6 Aug 24  i  ii +* Re: Intel3John Larkin
7 Aug 24  i  ii i+- Re: Intel1Jan Panteltje
17 Aug 24  i  ii i`- Re: Intel1Bill Sloman
7 Aug 24  i  ii `* Re: Intel12Bill Sloman
7 Aug 24  i  ii  `* Re: Intel11Jan Panteltje
7 Aug 24  i  ii   `* Re: Intel10Bill Sloman
7 Aug 24  i  ii    `* Re: Intel9Jan Panteltje
7 Aug 24  i  ii     `* Re: Intel8Bill Sloman
7 Aug 24  i  ii      `* Re: Intel7Jan Panteltje
8 Aug 24  i  ii       `* Re: Intel6Bill Sloman
8 Aug 24  i  ii        `* Re: Intel5Jan Panteltje
10 Aug 24  i  ii         `* Re: Intel4Bill Sloman
12 Aug 24  i  ii          `* Re: Intel3brian
12 Aug 24  i  ii           `* Re: Intel2John Larkin
12 Aug 24  i  ii            `- Re: Intel1Phil Hobbs
6 Aug 24  i  i`* Re: Intel3John Larkin
7 Aug 24  i  i +- Re: Intel1Bill Sloman
7 Aug 24  i  i `- Re: Intel1Jan Panteltje
6 Aug 24  i  `* Re: Intel2bitrex
6 Aug 24  i   `- Re: Intel1John Larkin
4 Aug 24  `* Re: Intel11Don Y
4 Aug 24   `* Re: Intel10TTman
4 Aug 24    +* Re: Intel3John Larkin
4 Aug 24    i`* Re: Intel2Joe Gwinn
4 Aug 24    i `- Re: Intel1John Larkin
4 Aug 24    `* Re: Intel6Don Y
4 Aug 24     `* Re: Intel5piglet
4 Aug 24      +- Re: Intel1Don Y
4 Aug 24      `* Re: Intel3Edward Rawde
4 Aug 24       +- Re: Intel1John Larkin
4 Aug 24       `- Re: Intel1Don Y

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal