Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Don't panic.


devel / comp.arch / Re: Could we build a better 6502?

SubjectAuthor
* Could we build a better 6502?Thomas Koenig
+* Re: Could we build a better 6502?Quadibloc
|+* Re: Could we build a better 6502?John Levine
||+* Re: Could we build a better 6502?MitchAlsup
|||`* Re: Could we build a better 6502?aph
||| `* Re: Could we build a better 6502?Anton Ertl
|||  `* Re: Could we build a better 6502?MitchAlsup
|||   +- Re: Could we build a better 6502?Thomas Koenig
|||   +- Re: Could we build a better 6502?Anton Ertl
|||   `* Re: Could we build a better 6502?Quadibloc
|||    `* Re: Could we build a better 6502?Thomas Koenig
|||     +* Re: Could we build a better 6502?Brian G. Lucas
|||     |`* Re: Could we build a better 6502?Quadibloc
|||     | +- Re: Could we build a better 6502?Brian G. Lucas
|||     | `- Re: Could we build a better 6502?Anton Ertl
|||     +* Re: Could we build a better 6502?Stephen Fuld
|||     |+- Re: Could we build a better 6502?Terje Mathisen
|||     |`* Re: Could we build a better 6502?pec...@gmail.com
|||     | +* Re: Could we build a better 6502?MitchAlsup
|||     | |+* Re: Could we build a better 6502?pec...@gmail.com
|||     | ||`* Re: Could we build a better 6502?Stephen Fuld
|||     | || `- Re: Could we build a better 6502?pec...@gmail.com
|||     | |`* Re: Could we build a better 6502?Timothy McCaffrey
|||     | | +- Re: Could we build a better 6502?Michael Barry
|||     | | `* Re: Could we build a better 6502?Thomas Koenig
|||     | |  `* Re: Could we build a better 6502?Timothy McCaffrey
|||     | |   +* Re: Could we build a better 6502?pec...@gmail.com
|||     | |   |`* Re: Could we build a better 6502?Michael Barry
|||     | |   | `- Re: Could we build a better 6502?Thomas Koenig
|||     | |   `* Re: Could we build a better 6502?chris
|||     | |    `* Re: Could we build a better 6502?pec...@gmail.com
|||     | |     +* Re: Could we build a better 6502?MitchAlsup
|||     | |     |`- Re: Could we build a better 6502?Thomas Koenig
|||     | |     `* Re: Could we build a better 6502?chris
|||     | |      `* Re: Could we build a better 6502?George Neuner
|||     | |       `* Re: Could we build a better 6502?chris
|||     | |        +* Re: Could we build a better 6502?MitchAlsup
|||     | |        |`* Re: Could we build a better 6502?Thomas Koenig
|||     | |        | +- Re: Could we build a better 6502?Bernd Linsel
|||     | |        | `* Re: Could we build a better 6502?David Brown
|||     | |        |  `* Re: Could we build a better 6502?chris
|||     | |        |   `* Re: Could we build a better 6502?David Brown
|||     | |        |    `* Re: Could we build a better 6502?Terje Mathisen
|||     | |        |     `* Re: Could we build a better 6502?Thomas Koenig
|||     | |        |      `- Re: Could we build a better 6502?Terje Mathisen
|||     | |        `* Re: Could we build a better 6502?Al Grant
|||     | |         `- Re: Could we build a better 6502?chris
|||     | `* Re: Could we build a better 6502?Thomas Koenig
|||     |  +- Re: Could we build a better 6502?MitchAlsup
|||     |  +- Re: Could we build a better 6502?pec...@gmail.com
|||     |  +* Re: Could we build a better 6502?Thomas Koenig
|||     |  |+* Re: Could we build a better 6502?Stefan Monnier
|||     |  ||`* Re: Could we build a better 6502?Ivan Godard
|||     |  || `* Re: Could we build a better 6502?Stefan Monnier
|||     |  ||  `* Re: Could we build a better 6502?John Dallman
|||     |  ||   +- Re: Could we build a better 6502?Stefan Monnier
|||     |  ||   +* Re: Could we build a better 6502?pec...@gmail.com
|||     |  ||   |`- Re: Could we build a better 6502?Ivan Godard
|||     |  ||   `- Re: Could we build a better 6502?Stephen Fuld
|||     |  |`* Re: Could we build a better 6502?pec...@gmail.com
|||     |  | `* Re: Could we build a better 6502?Thomas Koenig
|||     |  |  `- Re: Could we build a better 6502?pec...@gmail.com
|||     |  `* Re: Could we build a better 6502?Thomas Koenig
|||     |   +* Re: Could we build a better 6502?Anton Ertl
|||     |   |+* Re: Could we build a better 6502?Thomas Koenig
|||     |   ||`* Re: Could we build a better 6502?pec...@gmail.com
|||     |   || `- Re: Could we build a better 6502?MitchAlsup
|||     |   |`* Re: Could we build a better 6502?David Schultz
|||     |   | +* Re: Could we build a better 6502?Anton Ertl
|||     |   | |`- Re: Could we build a better 6502?David Schultz
|||     |   | `* Re: Could we build a better 6502?MitchAlsup
|||     |   |  `* Re: Could we build a better 6502?pec...@gmail.com
|||     |   |   `- Re: Could we build a better 6502?MitchAlsup
|||     |   `- Re: Could we build a better 6502?MitchAlsup
|||     `* Re: Could we build a better 6502?Anton Ertl
|||      `* Re: Could we build a better 6502?Thomas Koenig
|||       `* Re: Could we build a better 6502?MitchAlsup
|||        +* Re: Could we build a better 6502?Marcus
|||        |+* Re: Could we build a better 6502?MitchAlsup
|||        ||`* Re: Could we build a better 6502?Thomas Koenig
|||        || `- Re: Could we build a better 6502?Anton Ertl
|||        |`- Re: Could we build a better 6502?Thomas Koenig
|||        `- Re: Could we build a better 6502?Thomas Koenig
||+* Re: Could we build a better 6502?Quadibloc
|||`- Re: Could we build a better PDP-8, was 6502?John Levine
||`- Re: Could we build a better 6502?Tim Rentsch
|`* Re: Could we build a better 6502?Quadibloc
| +* Re: Could we build a better 6502?Thomas Koenig
| |`* Re: Could we build a better 6502?Anton Ertl
| | `* Re: Could we build a better 6502?David Schultz
| |  `* Re: Could we build a better 6502?Brett
| |   `* Re: Could we build a better 6502?David Schultz
| |    `* Re: Could we build a better 6502?Brett
| |     `* Re: Could we build a better 6502?David Schultz
| |      `* Re: Could we build a better 6502?Brett
| |       `- Re: Could we build a better 6502?David Schultz
| +* Re: Could we build a better 6502?Stefan Monnier
| |`* Re: Could we build a better 6502?Thomas Koenig
| | +* Re: Could we build a better 6502?Stefan Monnier
| | |+* Re: Could we build a better 6502?MitchAlsup
| | ||`- Re: Could we build a better 6502?pec...@gmail.com
| | |`* Re: Could we build a better 6502?pec...@gmail.com
| | +- Re: Could we build a better 6502?MitchAlsup
| | `* Re: Could we build a better 6502?pec...@gmail.com
| `- Re: Could we build a better 6502?MitchAlsup
+* Re: Could we build a better 6502?Marcus
+* Re: Could we build a better 6502?MitchAlsup
+* Re: Could we build a better 6502?EricP
+* Re: Could we build a better 6502?Guillaume
+- Re: Could we build a better 6502?EricP
+* Re: Could we build a better 6502?Timothy McCaffrey
+- Re: Could we build a better 6502?JimBrakefield
+* Re: Could we build a better 6502?Anssi Saari
+* Re: Could we build a better 6502?John Dallman
+* Re: Could we build a better 6502?Anton Ertl
+* Re: Could we build a better 6502?Michael Barry
+* Re: Could we build a better 6502?pec...@gmail.com
+* Re: Could we build a better 6502?Bernd Linsel
+- Re: Could we build a better 6502?clamky
+* Re: Could we build a better 6502?Quadibloc
`- Re: Could we build a better 6502?Quadibloc

Pages:12345678910111213
Re: Could we build a better 6502?

<2021Jul28.114605@mips.complang.tuwien.ac.at>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19277&group=comp.arch#19277

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Wed, 28 Jul 2021 09:46:05 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 34
Message-ID: <2021Jul28.114605@mips.complang.tuwien.ac.at>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad>
Injection-Info: reader02.eternal-september.org; posting-host="8b18bbfdfdd9080e119a794836100169";
logging-data="13041"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18BPAS1VHKdudaRYLLKpa6M"
Cancel-Lock: sha1:h7+W5E0EQK0cOjbygroctTGVsso=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 28 Jul 2021 09:46 UTC

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>>
>> The 8008 fits an 8x14bits stack in its 3500 (PMOS) transistors, and
>> has a more complex architecture. And it probably was static rather
>> than dynamic RAM, because AFAIK there is no way to refresh it by
>> storing it to memory at regular intervals.
>
>8008 (circa 1972) and 8080 (circa 1974) were both dynamic internally.

Now I remember that the 6502 was dynamic, too, and the 65C02 was
static.

However, it was never really clear to me what this "dynamic" means,
other than having a lower limit on the clock rate.

Does it mean that these dynamic CPUs used DRAM for their registers?
If so, how were they refreshed?

>8008 required an externally generated 2 phase non overlapping
>pulsed clock with some rather strict timing requirements.
>Cycle time of each phase had minimum of 2 us, max of 3 us
>taking 2 clock cycles for 1 machine state cycle.
>First cycle, phase 1 is the precharge to internal memory and buses,
>phase 2 is read, second cycle phase 1 is precharge, phase 2 is write.

This sounds like each bit would require more transistors than the two
that Bernd Paysan assumed for the b16 variant (and for which he
suggested software refresh).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Could we build a better 6502?

<2021Jul28.173320@mips.complang.tuwien.ac.at>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19283&group=comp.arch#19283

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Wed, 28 Jul 2021 15:33:20 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 42
Message-ID: <2021Jul28.173320@mips.complang.tuwien.ac.at>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at>
Injection-Info: reader02.eternal-september.org; posting-host="8b18bbfdfdd9080e119a794836100169";
logging-data="28270"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9L9ZlKDNwP1+rApxtREYH"
Cancel-Lock: sha1:W84yzF327ZT0JLBpmfmap1Snd3g=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 28 Jul 2021 15:33 UTC

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Bernd Paysan <bernd@net2o.de> writes:
>>Am Sat, 24 Jul 2021 10:22:08 GMT schrieb Anton Ertl:
>>> https://bernd-paysan.de/b16-presentation.pdf
....
>Today I lean more towards having a 16-bit ALU and letting the software
>synthesize 16-bit memory accesses out of 8-bit accesses, to avoid the
>need for a sequencer. Maybe I will revert that again when I think
>more about how to deal with immediate arguments.

For immediate arguments one could take a transputer-like approach (or
RISC-like, but the transputer seems more relevant given that we are
discussing a stack machine):

Immediates are synthesized on the top of return stack (that works out
better for conditional branches that deal with data on the top of the
data stack): Have an instruction that has a 7-bit immediate field and
pushes it sign-extended on the return stack; have another instruction
that has a 6-bit immediate field, shifts the top of return stack to
the left by 6 bits and puts the immediate field in the bottom 6 bits.

This means that in many cases we can have an immediate operand and the
instruction consuming the operand in the same number of bytes as the
6502. It leaves 64 encodings for other instructions, which should be
ample (the 6502 has 56).

It also means that I have now departed from the c18/b16 way of
encoding more than one instruction per word, and having immediate
arguments in extra words. I think that way would require more
transistors than just treating each byte as one instruction.

Concerning the need for multi-cycle instructions (and thus a
sequencer; but that could be cheap to implement), at least load and
store instructions need to be multi-cycle (one cycle for loading the
instruction, and at least one for loading or storing the data). And
given that multi-cycle instructions are needed anyway, having a
two-byte load and two-byte store may add few transistors.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Could we build a better 6502?

<2XmMI.80414$VU3.55543@fx46.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19297&group=comp.arch#19297

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at>
In-Reply-To: <2021Jul28.114605@mips.complang.tuwien.ac.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 56
Message-ID: <2XmMI.80414$VU3.55543@fx46.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Thu, 29 Jul 2021 00:50:06 UTC
Date: Wed, 28 Jul 2021 20:49:53 -0400
X-Received-Bytes: 3462
 by: EricP - Thu, 29 Jul 2021 00:49 UTC

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>>> The 8008 fits an 8x14bits stack in its 3500 (PMOS) transistors, and
>>> has a more complex architecture. And it probably was static rather
>>> than dynamic RAM, because AFAIK there is no way to refresh it by
>>> storing it to memory at regular intervals.
>> 8008 (circa 1972) and 8080 (circa 1974) were both dynamic internally.
>
> Now I remember that the 6502 was dynamic, too, and the 65C02 was
> static.
>
> However, it was never really clear to me what this "dynamic" means,
> other than having a lower limit on the clock rate.
>
> Does it mean that these dynamic CPUs used DRAM for their registers?
> If so, how were they refreshed?

I don't know of any reason that any device would have a a minimum clock
rate unless its' internal state required a dynamic refresh to retain.
However the storage cells may not be identical to an actual DRAM,
i.e. not a single capacitor.

The only reason I can think of, and I don't think this applies here,
that a device might be static logic internally and not require periodic
refresh but still has a minimum clock, is if the some of the substrate
voltages are generated internally by charge pumps driven by the clock.
If the clock stops then the charge bleeds off, the voltages disappear,
and the logic looses its state.

The 4004 is pMOS and the manual explicitly says the register file
is dynamic ram. The internal functional diagram has a refresh counter
muxed into the register file.

The 8008 is pMOS and has the same timing as 4004 and the functional
diagram has the same refresh counter attached to the register file.

The 8080 is nMOS and has similar clocking to 4004 and 8008.
The manual does not show a refresh counter on the internal functional
diagram but it does state that it is a "a dynamic device" that requires
a clock for refresh and timing control.

>> 8008 required an externally generated 2 phase non overlapping
>> pulsed clock with some rather strict timing requirements.
>> Cycle time of each phase had minimum of 2 us, max of 3 us
>> taking 2 clock cycles for 1 machine state cycle.
>> First cycle, phase 1 is the precharge to internal memory and buses,
>> phase 2 is read, second cycle phase 1 is precharge, phase 2 is write.
>
> This sounds like each bit would require more transistors than the two
> that Bernd Paysan assumed for the b16 variant (and for which he
> suggested software refresh).
>
> - anton

Re: Could we build a better 6502?

<2021Jul29.120600@mips.complang.tuwien.ac.at>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19302&group=comp.arch#19302

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Thu, 29 Jul 2021 10:06:00 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 34
Message-ID: <2021Jul29.120600@mips.complang.tuwien.ac.at>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad>
Injection-Info: reader02.eternal-september.org; posting-host="ee4420149de74c857bd1c499e94a7eec";
logging-data="15124"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0ouQF5JOGOmjpuwQXM0ii"
Cancel-Lock: sha1:Ubq+4oZ/xvwMMTDXzzZEmxnDGNU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 29 Jul 2021 10:06 UTC

EricP <ThatWouldBeTelling@thevillage.com> writes:
>The 4004 is pMOS and the manual explicitly says the register file
>is dynamic ram. The internal functional diagram has a refresh counter
>muxed into the register file.
>
>The 8008 is pMOS and has the same timing as 4004 and the functional
>diagram has the same refresh counter attached to the register file.

My current understanding from this description is that the counter
counts through the various registers, and at some point during
instruction execution one register is read and written back.

Looking at the 6502 microarchitecture as described in
https://i.imgur.com/BkZ9o.png, with its individual registers on 4 or
so buses, and the way it is clocked, at first it seemed unplausible to
me that it could do automatic refreshing of DRAM registers.

But thinking about it, it's not that outlandish: When loading the next
instruction, the SB and DB buses are unused and can be used for
reading from one of the registers that can keep data for a long time
without being necessarily updated (in all bits): A, X, Y, S, P; and
the control logic can produce the right signals to do it. I don't see
anything like a refresh counter for counting through these registers,
but then not all of the signals from the timing generation logic are
clear to me, nor the control flip-flops; so the refresh counter might
hide in there.

It's interesting that despite the hardware limitations none of these
architectures fell back on software assist for refresh.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Could we build a better 6502?

<53472dc3-71ec-41cb-bc63-ff563708def1n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19309&group=comp.arch#19309

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:29cf:: with SMTP id s15mr6665211qkp.363.1627582933158; Thu, 29 Jul 2021 11:22:13 -0700 (PDT)
X-Received: by 2002:aca:3094:: with SMTP id w142mr3942864oiw.37.1627582932885; Thu, 29 Jul 2021 11:22:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 29 Jul 2021 11:22:12 -0700 (PDT)
In-Reply-To: <2XmMI.80414$VU3.55543@fx46.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4d78:fd0f:f097:e375; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4d78:fd0f:f097:e375
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <53472dc3-71ec-41cb-bc63-ff563708def1n@googlegroups.com>
Subject: Re: Could we build a better 6502?
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Thu, 29 Jul 2021 18:22:13 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 58
 by: MitchAlsup - Thu, 29 Jul 2021 18:22 UTC

On Wednesday, July 28, 2021 at 7:50:08 PM UTC-5, EricP wrote:
> Anton Ertl wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >> Anton Ertl wrote:
> >>> The 8008 fits an 8x14bits stack in its 3500 (PMOS) transistors, and
> >>> has a more complex architecture. And it probably was static rather
> >>> than dynamic RAM, because AFAIK there is no way to refresh it by
> >>> storing it to memory at regular intervals.
> >> 8008 (circa 1972) and 8080 (circa 1974) were both dynamic internally.
> >
> > Now I remember that the 6502 was dynamic, too, and the 65C02 was
> > static.
> >
> > However, it was never really clear to me what this "dynamic" means,
> > other than having a lower limit on the clock rate.
> >
> > Does it mean that these dynamic CPUs used DRAM for their registers?
> > If so, how were they refreshed?
<
> I don't know of any reason that any device would have a a minimum clock
> rate unless its' internal state required a dynamic refresh to retain.
> However the storage cells may not be identical to an actual DRAM,
> i.e. not a single capacitor.
<
Mc 68020 had a minimum clock rate. There were latches between stages
that were a capacitor followed by an inverter driving the next stage, (also
there were pairs of capacitors driving a sense amplifier driving true-comp
to the next stage.)
>
> The only reason I can think of, and I don't think this applies here,
> that a device might be static logic internally and not require periodic
> refresh but still has a minimum clock, is if the some of the substrate
> voltages are generated internally by charge pumps driven by the clock.
> If the clock stops then the charge bleeds off, the voltages disappear,
> and the logic looses its state.
>
> The 4004 is pMOS and the manual explicitly says the register file
> is dynamic ram. The internal functional diagram has a refresh counter
> muxed into the register file.
>
> The 8008 is pMOS and has the same timing as 4004 and the functional
> diagram has the same refresh counter attached to the register file.
>
> The 8080 is nMOS and has similar clocking to 4004 and 8008.
> The manual does not show a refresh counter on the internal functional
> diagram but it does state that it is a "a dynamic device" that requires
> a clock for refresh and timing control.
> >> 8008 required an externally generated 2 phase non overlapping
> >> pulsed clock with some rather strict timing requirements.
> >> Cycle time of each phase had minimum of 2 us, max of 3 us
> >> taking 2 clock cycles for 1 machine state cycle.
> >> First cycle, phase 1 is the precharge to internal memory and buses,
> >> phase 2 is read, second cycle phase 1 is precharge, phase 2 is write.
> >
> > This sounds like each bit would require more transistors than the two
> > that Bernd Paysan assumed for the b16 variant (and for which he
> > suggested software refresh).
> >
> > - anton

Re: Could we build a better 6502?

<CYCMI.17516$6j.14191@fx04.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19316&group=comp.arch#19316

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad> <2021Jul29.120600@mips.complang.tuwien.ac.at>
In-Reply-To: <2021Jul29.120600@mips.complang.tuwien.ac.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 66
Message-ID: <CYCMI.17516$6j.14191@fx04.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Thu, 29 Jul 2021 19:04:02 UTC
Date: Thu, 29 Jul 2021 14:48:41 -0400
X-Received-Bytes: 4075
 by: EricP - Thu, 29 Jul 2021 18:48 UTC

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> The 4004 is pMOS and the manual explicitly says the register file
>> is dynamic ram. The internal functional diagram has a refresh counter
>> muxed into the register file.
>>
>> The 8008 is pMOS and has the same timing as 4004 and the functional
>> diagram has the same refresh counter attached to the register file.
>
> My current understanding from this description is that the counter
> counts through the various registers, and at some point during
> instruction execution one register is read and written back.
>
> Looking at the 6502 microarchitecture as described in
> https://i.imgur.com/BkZ9o.png, with its individual registers on 4 or
> so buses, and the way it is clocked, at first it seemed unplausible to
> me that it could do automatic refreshing of DRAM registers.
>
> But thinking about it, it's not that outlandish: When loading the next
> instruction, the SB and DB buses are unused and can be used for
> reading from one of the registers that can keep data for a long time
> without being necessarily updated (in all bits): A, X, Y, S, P; and
> the control logic can produce the right signals to do it. I don't see
> anything like a refresh counter for counting through these registers,
> but then not all of the signals from the timing generation logic are
> clear to me, nor the control flip-flops; so the refresh counter might
> hide in there.
>
> It's interesting that despite the hardware limitations none of these
> architectures fell back on software assist for refresh.
>
> - anton

The wikipedia article on 6501/6502 is an interesting read.
https://en.wikipedia.org/wiki/MOS_Technology_6501

The 650x designers left Motorola after designing the nMOS 6800.
6800 nMOS required 3 voltages -5V, (gnd), +5V, +12V.
One of 6800 features was the on-chip voltage inverter for generating -5V,
and the voltage doubler for +12V invented and patented by John Buchanan
(the charge pumps I referred to earlier.)

Patent 3942047 MOS DC Voltage booster circuit, Buchanan, 1974
https://patents.google.com/patent/US3942047A/en?oq=3942047

On 8080 these voltages were externally supplied from DC-to-DC converters,
which are expensive, inefficient, and get quite hot.

Buchanan was left Motorola for MOS Technologies with the others
and designed the 650x's voltage generators.

6501 was pin compatible with 6800 and had the same 2 clocks phase
(phase 2 was just the compliment of phase 1 so its not clear why
6800 did that - maybe current draw for volt generators).
At any rate, the 6502 used just a single 5V clock.

So I'm guessing that 6800 and 650x used static latches for their registers,
the phi-1 and phi-2 clocks referred to on the JPG are generated internally
from clock edge-triggered, self-timed circuits to precharge the bus,
and the minimum clock was for the voltage generators as I suggested.

The nMOS 8080 had no such on-chip voltage generators so I have no idea
why it has a minimum clock of 0.5 MHz.

Re: Could we build a better 6502?

<sduu97$su0$1@newsreader4.netcologne.de>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19317&group=comp.arch#19317

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-c228-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Thu, 29 Jul 2021 19:07:19 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <sduu97$su0$1@newsreader4.netcologne.de>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me>
<2021Jul25.174327@mips.complang.tuwien.ac.at>
<tsALI.23489$uj5.7828@fx03.iad>
<2021Jul28.114605@mips.complang.tuwien.ac.at>
<2XmMI.80414$VU3.55543@fx46.iad>
<2021Jul29.120600@mips.complang.tuwien.ac.at>
<CYCMI.17516$6j.14191@fx04.iad>
Injection-Date: Thu, 29 Jul 2021 19:07:19 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-c228-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:c228:0:7285:c2ff:fe6c:992d";
logging-data="29632"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Thu, 29 Jul 2021 19:07 UTC

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

> So I'm guessing that 6800 and 650x used static latches for their registers,

https://downloads.reactivemicro.com/Electronics/CPU/6502%20Schematic.pdf
has the schematics, if you can read them, you could look it up :-)

Re: Could we build a better 6502?

<BOmdnWwzHNXGiJ78nZ2dnUU7-aXNnZ2d@earthlink.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19323&group=comp.arch#19323

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 15:53:46 -0500
Subject: Re: Could we build a better 6502?
Newsgroups: comp.arch
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad> <2021Jul29.120600@mips.complang.tuwien.ac.at> <CYCMI.17516$6j.14191@fx04.iad>
From: david.sc...@earthlink.net (David Schultz)
Date: Thu, 29 Jul 2021 15:53:46 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CYCMI.17516$6j.14191@fx04.iad>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <BOmdnWwzHNXGiJ78nZ2dnUU7-aXNnZ2d@earthlink.com>
Lines: 13
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 108.194.109.128
X-Trace: sv3-XApTKHIsD0jSJTmv7Y2O+yuKh4ylkHghOxioWhVJaAoEGdin/MQqVfA9ettZPIMVaOTl7N+1bZel3TE!FIeinZSPRoM14+isV6Aeskxxa45lWYUcdXG/dC9L7TCrhcsFTpwlVwD0dQoi6MFBXzvuHi8KuZHp!wMmDNw+Bp2+qiEFEltyhxUyDvxvxd9DgWw==
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 1902
 by: David Schultz - Thu, 29 Jul 2021 20:53 UTC

On 7/29/21 1:48 PM, EricP wrote:
> 6501 was pin compatible with 6800 and had the same 2 clocks phase
> (phase 2 was just the compliment of phase 1 so its not clear why
> 6800 did that - maybe current draw for volt generators).
> At any rate, the 6502 used just a single 5V clock.

The MC6800 clocks were required to be nonoverlapping. Usually supplied
by a MC6875.

--
http://davesrocketworks.com
David Schultz

Re: Could we build a better 6502?

<2021Jul30.104638@mips.complang.tuwien.ac.at>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19344&group=comp.arch#19344

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 08:46:38 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 40
Message-ID: <2021Jul30.104638@mips.complang.tuwien.ac.at>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad> <2021Jul29.120600@mips.complang.tuwien.ac.at> <CYCMI.17516$6j.14191@fx04.iad>
Injection-Info: reader02.eternal-september.org; posting-host="f375a9bee4d8b8b6e84aaa12c2f4c78d";
logging-data="2512"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/N+cTr9X/K4Ta99HnwFFOF"
Cancel-Lock: sha1:hsoEiM353bqsTUlDkx+XgU69vNU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Fri, 30 Jul 2021 08:46 UTC

EricP <ThatWouldBeTelling@thevillage.com> writes:
>The wikipedia article on 6501/6502 is an interesting read.
>https://en.wikipedia.org/wiki/MOS_Technology_6501
>
>The 650x designers left Motorola after designing the nMOS 6800.
>6800 nMOS required 3 voltages -5V, (gnd), +5V, +12V.
>One of 6800 features was the on-chip voltage inverter for generating -5V,
>and the voltage doubler for +12V invented and patented by John Buchanan
>(the charge pumps I referred to earlier.)
>
>Patent 3942047 MOS DC Voltage booster circuit, Buchanan, 1974
>https://patents.google.com/patent/US3942047A/en?oq=3942047
....
>So I'm guessing that 6800 and 650x used static latches for their registers,
>the phi-1 and phi-2 clocks referred to on the JPG are generated internally
>from clock edge-triggered, self-timed circuits to precharge the bus,
>and the minimum clock was for the voltage generators as I suggested.

According to the article you linked above, the 6501/6502 used
depletion-load NMOS:

|depletion-load NMOS is a form of digital logic family that uses only a
|single power supply voltage, unlike earlier nMOS (n-type metal-oxide
|semiconductor) logic families that needed more than one different
|power supply voltage.

<https://en.wikipedia.org/wiki/Depletion-load_NMOS>

So the 6501/6502 do not need such voltage generators.

>The nMOS 8080 had no such on-chip voltage generators so I have no idea
>why it has a minimum clock of 0.5 MHz.

Your earlier theory that Intel used DRAM for registers is plausible
given that they already had experience with that.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Could we build a better 6502?

<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19353&group=comp.arch#19353

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:204c:: with SMTP id d12mr3111647qka.417.1627662164776;
Fri, 30 Jul 2021 09:22:44 -0700 (PDT)
X-Received: by 2002:a9d:4e0a:: with SMTP id p10mr2569268otf.329.1627662164655;
Fri, 30 Jul 2021 09:22:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Fri, 30 Jul 2021 09:22:44 -0700 (PDT)
In-Reply-To: <cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:f39c:db00:89b5:84a0:9b9e:3bf5;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:f39c:db00:89b5:84a0:9b9e:3bf5
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com> <7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com> <2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
Subject: Re: Could we build a better 6502?
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Fri, 30 Jul 2021 16:22:44 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Fri, 30 Jul 2021 16:22 UTC

On Tuesday, July 27, 2021 at 4:56:42 PM UTC-6, MitchAlsup wrote:

> The utility of reinventing this wheel in today's world and market is so close
> to zero it nears exponent underflow.

Oh, that may be, but I never thought that this was what the OP's question
was about.
The original 6502 was a masterpiece of economical design.
Could it be bettered by a designer today?
I would suspect:
- not by much, because it was done so well;
- but it is not the case that modern designers have forgotten how to design
circuits efficiently. They still want to pack *more* on each die, even if that
more is 11 cores instead of 10, and those cores are GBOoO.

John Savard

Re: Could we build a better 6502?

<se1a22$eqc$1@newsreader4.netcologne.de>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19354&group=comp.arch#19354

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2a0a-a544-189e-0-7911-95fa-4162-c525.ipv6dyn.netcologne.de!not-for-mail
From: bl1-remo...@gmx.com (Bernd Linsel)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 18:40:34 +0200
Organization: news.netcologne.de
Distribution: world
Message-ID: <se1a22$eqc$1@newsreader4.netcologne.de>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me>
<2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad>
<2021Jul28.114605@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Jul 2021 16:40:34 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2a0a-a544-189e-0-7911-95fa-4162-c525.ipv6dyn.netcologne.de:2a0a:a544:189e:0:7911:95fa:4162:c525";
logging-data="15180"; mail-complaints-to="abuse@netcologne.de"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
In-Reply-To: <2021Jul28.114605@mips.complang.tuwien.ac.at>
 by: Bernd Linsel - Fri, 30 Jul 2021 16:40 UTC

On 28.07.2021 11:46, Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>
> Now I remember that the 6502 was dynamic, too, and the 65C02 was
> static.
>
> However, it was never really clear to me what this "dynamic" means,
> other than having a lower limit on the clock rate.
>
> Does it mean that these dynamic CPUs used DRAM for their registers?
> If so, how were they refreshed?
>
>
> This sounds like each bit would require more transistors than the two
> that Bernd Paysan assumed for the b16 variant (and for which he
> suggested software refresh).
>
> - anton
>

See https://en.wikipedia.org/wiki/Dynamic_logic_(digital_electronics) .

However, the distinction made in this article is not clear enough, as
there is as well clocked static logic.

To put it short, signals in dynamic logic circuits are always "in
flight" and only buffered by (small) capacitors between the gates, thus
the need for a minimal clock rate specification (roughly 5 tau of the
buffers), while static logic has latches between functional blocks that
keep the signals up as long as Vcc is applied, so that even if the clock
is stopped, the circuit state is held.

Besides, the maximum clock rate for dynamic logic may also be
constrained to a substantial lower clock rate than resulting from
switching times, because the capacitors can only be charged/discharged
with rates depending on gate fan-out.

On the other hand, the clock rate for static logic is restrained by the
additional latch switching times.

In summary, dynamic logic needs less silicon and less energy (if
designed correctly), but static logic is less dependent on clock phase
and stability, and has the advantage of a wide frequency range.

Today's big chips usually incorporate a mixture of both.

--
Regards,
Bernd

Re: Could we build a better 6502?

<fdf5b0eb-edef-4909-9f42-b20d2aa075d0n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19357&group=comp.arch#19357

  copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:41d2:: with SMTP id o18mr3441580qtm.10.1627668221509;
Fri, 30 Jul 2021 11:03:41 -0700 (PDT)
X-Received: by 2002:a9d:5c8b:: with SMTP id a11mr3073610oti.206.1627668221235;
Fri, 30 Jul 2021 11:03:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Fri, 30 Jul 2021 11:03:41 -0700 (PDT)
In-Reply-To: <se1a22$eqc$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:918b:713a:6df:fda7;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:918b:713a:6df:fda7
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at>
<sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at>
<tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <se1a22$eqc$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fdf5b0eb-edef-4909-9f42-b20d2aa075d0n@googlegroups.com>
Subject: Re: Could we build a better 6502?
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Fri, 30 Jul 2021 18:03:41 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 67
 by: MitchAlsup - Fri, 30 Jul 2021 18:03 UTC

On Friday, July 30, 2021 at 11:40:36 AM UTC-5, Bernd Linsel wrote:
> On 28.07.2021 11:46, Anton Ertl wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >
> > Now I remember that the 6502 was dynamic, too, and the 65C02 was
> > static.
> >
> > However, it was never really clear to me what this "dynamic" means,
> > other than having a lower limit on the clock rate.
> >
> > Does it mean that these dynamic CPUs used DRAM for their registers?
> > If so, how were they refreshed?
> >
> >
> > This sounds like each bit would require more transistors than the two
> > that Bernd Paysan assumed for the b16 variant (and for which he
> > suggested software refresh).
> >
> > - anton
> >
> See https://en.wikipedia.org/wiki/Dynamic_logic_(digital_electronics) .
>
> However, the distinction made in this article is not clear enough, as
> there is as well clocked static logic.
>
> To put it short, signals in dynamic logic circuits are always "in
> flight" and only buffered by (small) capacitors between the gates, thus
<
During the precharge time period, the signals are not "in flight" they are
solidly driven in one direction (usually high). It is only in the evaluation
period that the signals can be pulled low and then float until the precharge
period comes back around.
<
> the need for a minimal clock rate specification (roughly 5 tau of the
> buffers), while static logic has latches between functional blocks that
> keep the signals up as long as Vcc is applied, so that even if the clock
> is stopped, the circuit state is held.
>
> Besides, the maximum clock rate for dynamic logic may also be
> constrained to a substantial lower clock rate than resulting from
> switching times, because the capacitors can only be charged/discharged
> with rates depending on gate fan-out.
<
Some circuits such as integer adders are actually faster and lower power
in static implementations than in dynamic implementations.
>
> On the other hand, the clock rate for static logic is restrained by the
> additional latch switching times.
>
> In summary, dynamic logic needs less silicon and less energy (if
> designed correctly), but static logic is less dependent on clock phase
> and stability, and has the advantage of a wide frequency range.
>
> Today's big chips usually incorporate a mixture of both.
<
Mostly, the dynamic parts are hidden from designers inside macros that
the designer is not allowed to even look at. So, while there are dynamic
parts to modern chips, 99% of the designers work in purely static design
capacities. SRAM macros have internal dynamic components (bit lines
sense amplifiers,...) but the interface given to the designers using said
macro smells distinctly static (except that some libraries mandate that
the read out from the sense amplifiers are latched (or floped) before
used==seen by other signals. Very few things "on the data path" are
dynamic these days, essentially nothing in the control path is dynamic.
>
> --
> Regards,
> Bernd

Re: Could we build a better 6502?

<se1hvt$li9$1@newsreader4.netcologne.de>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19358&group=comp.arch#19358

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-c228-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 18:55:57 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <se1hvt$li9$1@newsreader4.netcologne.de>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com>
<7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com>
<2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
Injection-Date: Fri, 30 Jul 2021 18:55:57 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-c228-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:c228:0:7285:c2ff:fe6c:992d";
logging-data="22089"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Fri, 30 Jul 2021 18:55 UTC

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Tuesday, July 27, 2021 at 4:56:42 PM UTC-6, MitchAlsup wrote:
>
>> The utility of reinventing this wheel in today's world and market is so close
>> to zero it nears exponent underflow.
>
> Oh, that may be, but I never thought that this was what the OP's question
> was about.
> The original 6502 was a masterpiece of economical design.
> Could it be bettered by a designer today?
> I would suspect:
> - not by much, because it was done so well;
> - but it is not the case that modern designers have forgotten how to design
> circuits efficiently. They still want to pack *more* on each die, even if that
> more is 11 cores instead of 10, and those cores are GBOoO.

If you take the basic concept of a 6502 (single-byte instructions,
heavy on sequencing, but not as heavy as the Z80) I think they
were pretty close to optimum on the cost/performance curve.

To expand a little on a previous post, I still think that a
proto-RISC design could have been superior. A design with

- All 16 bit instructions only
- Load/store architecture
- 16 registers of 16 bits each
- Eight bit opcode, eight bit data
- Possibility of 16-bit immediates for all arithmetic
operations, load and store for the address
- Format: op Ra, Ra or op Ra, #immediate (4 bits)

can probably be made to fit on a 6502-sized die using the
technology of the day.

Of course, such a design would be screaming to have a 16-bit
data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
NMI, Clock. Would that be enough?

Re: Could we build a better 6502?

<6gYMI.19189$_fgb.14201@fx01.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19359&group=comp.arch#19359

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!npeer.as286.net!npeer-ng0.as286.net!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx01.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad> <2021Jul29.120600@mips.complang.tuwien.ac.at> <CYCMI.17516$6j.14191@fx04.iad> <sduu97$su0$1@newsreader4.netcologne.de>
In-Reply-To: <sduu97$su0$1@newsreader4.netcologne.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 21
Message-ID: <6gYMI.19189$_fgb.14201@fx01.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Fri, 30 Jul 2021 19:18:26 UTC
Date: Fri, 30 Jul 2021 15:18:01 -0400
X-Received-Bytes: 1939
 by: EricP - Fri, 30 Jul 2021 19:18 UTC

Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>
>> So I'm guessing that 6800 and 650x used static latches for their registers,
>
> https://downloads.reactivemicro.com/Electronics/CPU/6502%20Schematic.pdf
> has the schematics, if you can read them, you could look it up :-)

Thanks.

At the top right, latches for stack pointer, X and Y -
two inverters back to back, with the 2 pass gates cp2 and x6 being a mux,
and pass gate x7 output onto the bus.
To set the latch, put the data on the bus, set cp2=0 and x6=1.
Then x6=0 and cp2=1 to hold that value.

Since cp2 is clock pulse 2, it goes 0 every 1/2 cycle which leaves
its inverter gate input floating. I was taught to never do this.
Anyway, that might be a source of the minimum clock - if cp2 is
missing the gate charge bleeds off and loses its feedback state.

Re: Could we build a better 6502?

<2FYMI.97718$sI4.11275@fx40.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19360&group=comp.arch#19360

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx40.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <2021Jul24.122208@mips.complang.tuwien.ac.at> <sdi8ds$ngf$1@dont-email.me> <2021Jul25.174327@mips.complang.tuwien.ac.at> <tsALI.23489$uj5.7828@fx03.iad> <2021Jul28.114605@mips.complang.tuwien.ac.at> <2XmMI.80414$VU3.55543@fx46.iad> <2021Jul29.120600@mips.complang.tuwien.ac.at> <CYCMI.17516$6j.14191@fx04.iad> <2021Jul30.104638@mips.complang.tuwien.ac.at>
In-Reply-To: <2021Jul30.104638@mips.complang.tuwien.ac.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 38
Message-ID: <2FYMI.97718$sI4.11275@fx40.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Fri, 30 Jul 2021 19:45:02 UTC
Date: Fri, 30 Jul 2021 15:44:52 -0400
X-Received-Bytes: 2448
 by: EricP - Fri, 30 Jul 2021 19:44 UTC

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> The wikipedia article on 6501/6502 is an interesting read.
>> https://en.wikipedia.org/wiki/MOS_Technology_6501
>>
>> The 650x designers left Motorola after designing the nMOS 6800.
>> 6800 nMOS required 3 voltages -5V, (gnd), +5V, +12V.
>> One of 6800 features was the on-chip voltage inverter for generating -5V,
>> and the voltage doubler for +12V invented and patented by John Buchanan
>> (the charge pumps I referred to earlier.)
>
> According to the article you linked above, the 6501/6502 used
> depletion-load NMOS:
>
> |depletion-load NMOS is a form of digital logic family that uses only a
> |single power supply voltage, unlike earlier nMOS (n-type metal-oxide
> |semiconductor) logic families that needed more than one different
> |power supply voltage.
>
> <https://en.wikipedia.org/wiki/Depletion-load_NMOS>
>
> So the 6501/6502 do not need such voltage generators.

Oops, right. Sorry about that. I was multitasking too much with
the 6800 article and mixed them up.

Never mind.

>> The nMOS 8080 had no such on-chip voltage generators so I have no idea
>> why it has a minimum clock of 0.5 MHz.
>
> Your earlier theory that Intel used DRAM for registers is plausible
> given that they already had experience with that.
>
> - anton

Re: Could we build a better 6502?

<se1lcg$56m$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19361&group=comp.arch#19361

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bage...@gmail.com (Brian G. Lucas)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 14:53:52 -0500
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <se1lcg$56m$1@dont-email.me>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com>
<7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com>
<2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Jul 2021 19:53:52 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="da08f7f83e8c0f8e8ce489aa0275b5fb";
logging-data="5334"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+iqDMX1zCSU4XPzpb7ngov"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:S5HejKzsxZVEQ4dFdKN/IZyQfao=
In-Reply-To: <se1hvt$li9$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: Brian G. Lucas - Fri, 30 Jul 2021 19:53 UTC

On 7/30/21 1:55 PM, Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> On Tuesday, July 27, 2021 at 4:56:42 PM UTC-6, MitchAlsup wrote:
>>
>>> The utility of reinventing this wheel in today's world and market is so close
>>> to zero it nears exponent underflow.
>>
>> Oh, that may be, but I never thought that this was what the OP's question
>> was about.
>> The original 6502 was a masterpiece of economical design.
>> Could it be bettered by a designer today?
>> I would suspect:
>> - not by much, because it was done so well;
>> - but it is not the case that modern designers have forgotten how to design
>> circuits efficiently. They still want to pack *more* on each die, even if that
>> more is 11 cores instead of 10, and those cores are GBOoO.
>
> If you take the basic concept of a 6502 (single-byte instructions,
> heavy on sequencing, but not as heavy as the Z80) I think they
> were pretty close to optimum on the cost/performance curve.
>
> To expand a little on a previous post, I still think that a
> proto-RISC design could have been superior. A design with
>
> - All 16 bit instructions only
> - Load/store architecture
> - 16 registers of 16 bits each
> - Eight bit opcode, eight bit data
> - Possibility of 16-bit immediates for all arithmetic
> operations, load and store for the address
> - Format: op Ra, Ra or op Ra, #immediate (4 bits)
>

I think you just described the Motorola MCore except for 16-bit immediates.

> can probably be made to fit on a 6502-sized die using the
> technology of the day.
>
> Of course, such a design would be screaming to have a 16-bit
> data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
> NMI, Clock. Would that be enough?
>

Re: Could we build a better 6502?

<3780694d-b2f5-41ae-9288-3e8a0f906d20n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19364&group=comp.arch#19364

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:a5a:: with SMTP id j26mr4583175qka.42.1627684603260;
Fri, 30 Jul 2021 15:36:43 -0700 (PDT)
X-Received: by 2002:a9d:5c8b:: with SMTP id a11mr3953700oti.206.1627684603044;
Fri, 30 Jul 2021 15:36:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Fri, 30 Jul 2021 15:36:42 -0700 (PDT)
In-Reply-To: <se1lcg$56m$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:f39c:db00:58f6:d409:7e3d:cef;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:f39c:db00:58f6:d409:7e3d:cef
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com> <7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com> <2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com> <868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de> <se1lcg$56m$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3780694d-b2f5-41ae-9288-3e8a0f906d20n@googlegroups.com>
Subject: Re: Could we build a better 6502?
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Fri, 30 Jul 2021 22:36:43 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Fri, 30 Jul 2021 22:36 UTC

On Friday, July 30, 2021 at 1:53:54 PM UTC-6, Brian G. Lucas wrote:
> On 7/30/21 1:55 PM, Thomas Koenig wrote:

> > To expand a little on a previous post, I still think that a
> > proto-RISC design could have been superior. A design with

> > - All 16 bit instructions only
> > - Load/store architecture
> > - 16 registers of 16 bits each
> > - Eight bit opcode, eight bit data
> > - Possibility of 16-bit immediates for all arithmetic
> > operations, load and store for the address
> > - Format: op Ra, Ra or op Ra, #immediate (4 bits)

> I think you just described the Motorola MCore except for 16-bit immediates.

If somebody designed a bare-bones 16-bit processor that fit on
an 8-bit sized die, what prevented it from becoming an amazing success
that made people forget all about the 6502, the 8080, and even the 6800?

Oh. Introduced in late 1997. Unfortunately, it was a little late to the party;
and so in real life, the TI 9900 was the only minimalist 16-bit chip that
tried to hasten the transition from 8-bit to 16-bit.

John Savard

Re: Could we build a better 6502?

<865ywr5r4x.fsf@linuxsc.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19366&group=comp.arch#19366

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 16:16:46 -0700
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <865ywr5r4x.fsf@linuxsc.com>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com> <sdhkr7$15vg$1@gal.iecc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="a262f327f7790ef595b5f779a3ef228e";
logging-data="14936"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QyfHYoG2SOOKkFXqKBzh6P+RUBc1ulZs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:sq0JsUN721YXH+8CbMPE4ZjUZB0=
sha1:7Xv9ROa5Dd7XkcjC6heitthvFXU=
 by: Tim Rentsch - Fri, 30 Jul 2021 23:16 UTC

John Levine <johnl@taugh.com> writes:

> According to Quadibloc <jsavard@ecn.ab.ca>:
>
>> On Friday, July 23, 2021 at 4:59:30 AM UTC-6, Thomas Koenig wrote:
>>
>>> Another direction for retro-architectures... I've been looking
>>> at the 6502 a bit, and it really is quite an interesting design.
>>> Squeezing the functionality of a CPU into ~3500 transistors (plus
>>> ~1000 transistors used as resistors) was quite an achievement.
>>
>> Indeed.
>>
>> However, even the 6502, let alone the 6800 or the 8080, seemed
>> to me to have very complicated instruction sets compared to the
>> PDP-8.
>
> The original PDP-8 had only 1409 transisors, each one in a separate can,
> so it's not surprising. The first computer I programmed was a PDP-8 and
> it was a fantastically well-done tradeoff between extreme simplicity and
> usability.

Amusing data point: the LGP-30 had 19 flip-flops.

Re: Could we build a better 6502?

<se25g8$5i2$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19372&group=comp.arch#19372

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: bage...@gmail.com (Brian G. Lucas)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 19:28:56 -0500
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <se25g8$5i2$1@dont-email.me>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com>
<7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com>
<2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de> <se1lcg$56m$1@dont-email.me>
<3780694d-b2f5-41ae-9288-3e8a0f906d20n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 31 Jul 2021 00:28:56 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b5a1314b712229ee16bd880838836f9d";
logging-data="5698"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BuPNnMmZkDb2DfQ64ayeJ"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:Mh7AedlZq+LMfi0ShK1OnnwZWhw=
In-Reply-To: <3780694d-b2f5-41ae-9288-3e8a0f906d20n@googlegroups.com>
Content-Language: en-US
 by: Brian G. Lucas - Sat, 31 Jul 2021 00:28 UTC

On 7/30/21 5:36 PM, Quadibloc wrote:
> On Friday, July 30, 2021 at 1:53:54 PM UTC-6, Brian G. Lucas wrote:
>> On 7/30/21 1:55 PM, Thomas Koenig wrote:
>
>>> To expand a little on a previous post, I still think that a
>>> proto-RISC design could have been superior. A design with
>
>>> - All 16 bit instructions only
>>> - Load/store architecture
>>> - 16 registers of 16 bits each
>>> - Eight bit opcode, eight bit data
>>> - Possibility of 16-bit immediates for all arithmetic
>>> operations, load and store for the address
>>> - Format: op Ra, Ra or op Ra, #immediate (4 bits)
>
>> I think you just described the Motorola MCore except for 16-bit immediates.
>
> If somebody designed a bare-bones 16-bit processor that fit on
> an 8-bit sized die, what prevented it from becoming an amazing success
> that made people forget all about the 6502, the 8080, and even the 6800?
>
> Oh. Introduced in late 1997. Unfortunately, it was a little late to the party;
> and so in real life, the TI 9900 was the only minimalist 16-bit chip that
> tried to hasten the transition from 8-bit to 16-bit.
>
The MCore is a 32-bit processor with 16-bit instructions.

> John Savard
>

Re: Could we build a better 6502?

<se2o7s$uis$1@dont-email.me>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19383&group=comp.arch#19383

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Fri, 30 Jul 2021 22:48:44 -0700
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <se2o7s$uis$1@dont-email.me>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com>
<7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com>
<2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 31 Jul 2021 05:48:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ce907f427114b4735e9d2695fbd44a5a";
logging-data="31324"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18dgEEwJXc6YVN1jHO600xBWf8hFNrxRsQ="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
Cancel-Lock: sha1:gn/S6yrfwLIOAcvg6p/nrjiPh3U=
In-Reply-To: <se1hvt$li9$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: Stephen Fuld - Sat, 31 Jul 2021 05:48 UTC

On 7/30/2021 11:55 AM, Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> On Tuesday, July 27, 2021 at 4:56:42 PM UTC-6, MitchAlsup wrote:
>>
>>> The utility of reinventing this wheel in today's world and market is so close
>>> to zero it nears exponent underflow.
>>
>> Oh, that may be, but I never thought that this was what the OP's question
>> was about.
>> The original 6502 was a masterpiece of economical design.
>> Could it be bettered by a designer today?
>> I would suspect:
>> - not by much, because it was done so well;
>> - but it is not the case that modern designers have forgotten how to design
>> circuits efficiently. They still want to pack *more* on each die, even if that
>> more is 11 cores instead of 10, and those cores are GBOoO.
>
> If you take the basic concept of a 6502 (single-byte instructions,
> heavy on sequencing, but not as heavy as the Z80) I think they
> were pretty close to optimum on the cost/performance curve.
>
> To expand a little on a previous post, I still think that a
> proto-RISC design could have been superior. A design with
>
> - All 16 bit instructions only
> - Load/store architecture
> - 16 registers of 16 bits each
> - Eight bit opcode, eight bit data
> - Possibility of 16-bit immediates for all arithmetic
> operations, load and store for the address
> - Format: op Ra, Ra or op Ra, #immediate (4 bits)
>
> can probably be made to fit on a 6502-sized die using the
> technology of the day.
>
> Of course, such a design would be screaming to have a 16-bit
> data bus.

Yes. With only an 8 bit bus, every instruction will require two memory
reads to fetch the instruction, which will substantially hurt
performance. 8088 anyone? :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Could we build a better 6502?

<2021Jul31.103941@mips.complang.tuwien.ac.at>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19387&group=comp.arch#19387

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Sat, 31 Jul 2021 08:39:41 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 19
Message-ID: <2021Jul31.103941@mips.complang.tuwien.ac.at>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <sdhkr7$15vg$1@gal.iecc.com> <7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com> <g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com> <2021Jul27.194213@mips.complang.tuwien.ac.at> <cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com> <868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com> <se1hvt$li9$1@newsreader4.netcologne.de> <se1lcg$56m$1@dont-email.me> <3780694d-b2f5-41ae-9288-3e8a0f906d20n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="209b39387a3e4cc93ab51b7fa259e14c";
logging-data="9130"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+oeDLIHTMP3LTThIufjtl6"
Cancel-Lock: sha1:nMlV7stBD3GXFbGVeqC5yduSBEA=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 31 Jul 2021 08:39 UTC

Quadibloc <jsavard@ecn.ab.ca> writes:
>If somebody designed a bare-bones 16-bit processor that fit on
>an 8-bit sized die, what prevented it from becoming an amazing success
>that made people forget all about the 6502, the 8080, and even the 6800?
>
>Oh. Introduced in late 1997. Unfortunately, it was a little late to the party;
>and so in real life, the TI 9900 was the only minimalist 16-bit chip that
>tried to hasten the transition from 8-bit to 16-bit.

There are all the Nova-like microprocessors (National Semiconductor
IPC-16A/520 PACE, microNOVA mN601, Fairchild 9440), but from what I
read, they tended to be not particularly fast, more expensive than the
6502 (6502: $25, mn601: $95 in lots of 100, 9440: $395 in lots of
100), and not marketed as aggressively as the 6502.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Could we build a better 6502?

<2021Jul31.110456@mips.complang.tuwien.ac.at>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19396&group=comp.arch#19396

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Sat, 31 Jul 2021 09:04:56 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 63
Distribution: world
Message-ID: <2021Jul31.110456@mips.complang.tuwien.ac.at>
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com> <sdhkr7$15vg$1@gal.iecc.com> <7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com> <g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com> <2021Jul27.194213@mips.complang.tuwien.ac.at> <cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com> <868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com> <se1hvt$li9$1@newsreader4.netcologne.de>
Injection-Info: reader02.eternal-september.org; posting-host="209b39387a3e4cc93ab51b7fa259e14c";
logging-data="22067"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FukSFgja3nzAnibRQ5B4+"
Cancel-Lock: sha1:H5LC3Eq1E2Yu9xbff37Xv0xebGU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 31 Jul 2021 09:04 UTC

Thomas Koenig <tkoenig@netcologne.de> writes:
>If you take the basic concept of a 6502 (single-byte instructions,
>heavy on sequencing, but not as heavy as the Z80) I think they
>were pretty close to optimum on the cost/performance curve.

What makes you think so? Admittedly, we have not seen anything
guaranteed to be better, but then it's expensive (maybe a person-year)
and commercially pointless to design a CPU with 1975 technology today.

>To expand a little on a previous post, I still think that a
>proto-RISC design could have been superior. A design with
>
>- All 16 bit instructions only
>- Load/store architecture
>- 16 registers of 16 bits each
>- Eight bit opcode, eight bit data
>- Possibility of 16-bit immediates for all arithmetic
> operations, load and store for the address
>- Format: op Ra, Ra or op Ra, #immediate (4 bits)
>
>can probably be made to fit on a 6502-sized die using the
>technology of the day.

I see lots of things that make it more expensive:

16-bit ALU
16 registers of 16 bits (in addition to PC and status? or are they included?)
Bernd Paysan's suggestion of using DRAM for registers might help here.
longer instruction buffer (especially with the 16-bit immediates)

What might make it cheaper:

Depending on the instruction set: A simpler decoder with fewer cycles
to generate signals for (although 6502 was ingenious in minimizing the
microcode for its instruction set). Looking at the 6502 die shot
description in
<https://en.wikipedia.org/wiki/MOS_Technology_6502#Technical_description>,
apparently half of the 6502 was dedicated to control (microcode PLA
and random), so there is substantial room for improvement here.

>Of course, such a design would be screaming to have a 16-bit
>data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
>NMI, Clock. Would that be enough?

The 6502 has an extra VSS pin, 3 N.C. (not connected?) pins, a sync
pin, an S0 pin and two clock-out pins in addition. Not sure what the
sync and S0 pins are good for, but if you can do without all these
pins, a 16-bit data bus would be technically possible.

But the result does not fit your original requirements, and in 1975
would have been a commercial failure. Remember that for the 1981 IBM
PC, IBM chose the 8088 over the 8086, because a system with a 16-bit
data bus is significantly more expensive than one with an 8-bit data
bus.

If we stick with an 8-bit data bus as you originally required, your
16-bit instructions may be suboptimal. I also thought about something
RISC-like, but this aspect steered me to something b16-like.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Could we build a better 6502?

<se3fb4$t22$1@newsreader4.netcologne.de>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19401&group=comp.arch#19401

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-c228-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Sat, 31 Jul 2021 12:23:00 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <se3fb4$t22$1@newsreader4.netcologne.de>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com>
<7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com>
<2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de>
<2021Jul31.110456@mips.complang.tuwien.ac.at>
Injection-Date: Sat, 31 Jul 2021 12:23:00 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-c228-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:c228:0:7285:c2ff:fe6c:992d";
logging-data="29762"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sat, 31 Jul 2021 12:23 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>If you take the basic concept of a 6502 (single-byte instructions,
>>heavy on sequencing, but not as heavy as the Z80) I think they
>>were pretty close to optimum on the cost/performance curve.
>
> What makes you think so? Admittedly, we have not seen anything
> guaranteed to be better, but then it's expensive (maybe a person-year)
> and commercially pointless to design a CPU with 1975 technology today.
>
>>To expand a little on a previous post, I still think that a
>>proto-RISC design could have been superior. A design with
>>
>>- All 16 bit instructions only
>>- Load/store architecture
>>- 16 registers of 16 bits each
>>- Eight bit opcode, eight bit data
>>- Possibility of 16-bit immediates for all arithmetic
>> operations, load and store for the address
>>- Format: op Ra, Ra or op Ra, #immediate (4 bits)
>>
>>can probably be made to fit on a 6502-sized die using the
>>technology of the day.
>
> I see lots of things that make it more expensive:
>
> 16-bit ALU

The ALU should perform:

- ADD, SUB, ADDC, SUBC
- OR, AND, NOT, XOR
- ROL, ROR, ASL

The most expensive part is the adder (used as adder subtractor
of course). A 16-bit ripple-carry adder (have to leave _some_
room for improvement) including the xor is about 500 transistors

Shift instructions are just wiring. AND, OR and NOT are cheap, for
XOR, the XOR from the adder/subtractor can be re-used.

The processor should probably be set up so that the ALU also
does branch calculations.

So, ~ 700-800 transistors for the ALU including the multiplexers.

> 16 registers of 16 bits (in addition to PC and status? or are they included?)

16 registers of 16 bits is 256 bits, four transistors each (like they
did on the actual 6502), with multiplexers, lets's say 1200 transistors.

2000 so far.

> Bernd Paysan's suggestion of using DRAM for registers might help here.
> longer instruction buffer (especially with the 16-bit immediates)
>
> What might make it cheaper:
>
> Depending on the instruction set: A simpler decoder with fewer cycles
> to generate signals for (although 6502 was ingenious in minimizing the
> microcode for its instruction set). Looking at the 6502 die shot
> description in
><https://en.wikipedia.org/wiki/MOS_Technology_6502#Technical_description>,
> apparently half of the 6502 was dedicated to control (microcode PLA
> and random), so there is substantial room for improvement here.

That was the point I was trying to get across. A proto-RISC 16-bit
processor could get by without much of the sequencing and control
logic on the 6502. Let's say the additional logic is implemented
in 1500 transistors (not unreasonable), and we're up to 3500.

>>Of course, such a design would be screaming to have a 16-bit
>>data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
>>NMI, Clock. Would that be enough?
>
> The 6502 has an extra VSS pin, 3 N.C. (not connected?) pins, a sync
> pin, an S0 pin and two clock-out pins in addition. Not sure what the
> sync and S0 pins are good for, but if you can do without all these
> pins, a 16-bit data bus would be technically possible.

> But the result does not fit your original requirements, and in 1975
> would have been a commercial failure. Remember that for the 1981 IBM
> PC, IBM chose the 8088 over the 8086, because a system with a 16-bit
> data bus is significantly more expensive than one with an 8-bit data
> bus.

You're right, this could be a significant bottleneck, but maybe still
better than a 6502.

Re: Could we build a better 6502?

<se3jqf$1rjq$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19408&group=comp.arch#19408

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!aoTW/Fm1++YcllHDt9jnUQ.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Could we build a better 6502?
Date: Sat, 31 Jul 2021 15:39:26 +0200
Organization: Aioe.org NNTP Server
Message-ID: <se3jqf$1rjq$1@gioia.aioe.org>
References: <sde7eg$hgb$1@newsreader4.netcologne.de>
<be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com>
<7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com>
<2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com>
<868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de> <se2o7s$uis$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="61050"; posting-host="aoTW/Fm1++YcllHDt9jnUQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sat, 31 Jul 2021 13:39 UTC

Stephen Fuld wrote:
> On 7/30/2021 11:55 AM, Thomas Koenig wrote:
>> Of course, such a design would be screaming to have a 16-bit
>> data bus.
>
> Yes.  With only an 8 bit bus, every instruction will require two memory
> reads to fetch the instruction, which will substantially hurt
> performance.  8088 anyone?  :-(

The only good thing about 8088 was the fact that you could statically
calculate the number of cycles a given code construct would use, i.e.
"number of bytes touched/read/written by code or data" multiplied by 4.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Could we build a better 6502?

<7340146b-e800-4e48-85a0-ac1783696022n@googlegroups.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=19417&group=comp.arch#19417

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:858:: with SMTP id 85mr7851080qki.70.1627750106780;
Sat, 31 Jul 2021 09:48:26 -0700 (PDT)
X-Received: by 2002:aca:c78d:: with SMTP id x135mr5544651oif.30.1627750106582;
Sat, 31 Jul 2021 09:48:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 31 Jul 2021 09:48:26 -0700 (PDT)
In-Reply-To: <se3fb4$t22$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:288a:67f4:917d:3e7a;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:288a:67f4:917d:3e7a
References: <sde7eg$hgb$1@newsreader4.netcologne.de> <be7f8928-ee11-422e-b11e-f89d3ad39782n@googlegroups.com>
<sdhkr7$15vg$1@gal.iecc.com> <7ba1c011-0d7a-40f3-b690-a729134ac9ecn@googlegroups.com>
<g6Odnbe33KUHVWL9nZ2dnUU78U_NnZ2d@supernews.com> <2021Jul27.194213@mips.complang.tuwien.ac.at>
<cee262df-cecf-4111-a213-6341934e564dn@googlegroups.com> <868dc60e-0882-44af-a545-c875f59553f3n@googlegroups.com>
<se1hvt$li9$1@newsreader4.netcologne.de> <2021Jul31.110456@mips.complang.tuwien.ac.at>
<se3fb4$t22$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7340146b-e800-4e48-85a0-ac1783696022n@googlegroups.com>
Subject: Re: Could we build a better 6502?
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sat, 31 Jul 2021 16:48:26 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Sat, 31 Jul 2021 16:48 UTC

On Saturday, July 31, 2021 at 7:23:02 AM UTC-5, Thomas Koenig wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >>If you take the basic concept of a 6502 (single-byte instructions,
> >>heavy on sequencing, but not as heavy as the Z80) I think they
> >>were pretty close to optimum on the cost/performance curve.
> >
> > What makes you think so? Admittedly, we have not seen anything
> > guaranteed to be better, but then it's expensive (maybe a person-year)
> > and commercially pointless to design a CPU with 1975 technology today.
> >
> >>To expand a little on a previous post, I still think that a
> >>proto-RISC design could have been superior. A design with
> >>
> >>- All 16 bit instructions only
> >>- Load/store architecture
> >>- 16 registers of 16 bits each
> >>- Eight bit opcode, eight bit data
> >>- Possibility of 16-bit immediates for all arithmetic
> >> operations, load and store for the address
> >>- Format: op Ra, Ra or op Ra, #immediate (4 bits)
> >>
> >>can probably be made to fit on a 6502-sized die using the
> >>technology of the day.
> >
> > I see lots of things that make it more expensive:
> >
> > 16-bit ALU
> The ALU should perform:
>
> - ADD, SUB, ADDC, SUBC
> - OR, AND, NOT, XOR
> - ROL, ROR, ASL
>
> The most expensive part is the adder (used as adder subtractor
> of course). A 16-bit ripple-carry adder (have to leave _some_
> room for improvement) including the xor is about 500 transistors
>
> Shift instructions are just wiring. AND, OR and NOT are cheap, for
> XOR, the XOR from the adder/subtractor can be re-used.
<
Shift instructions require multiplexers.
>
> The processor should probably be set up so that the ALU also
> does branch calculations.
>
> So, ~ 700-800 transistors for the ALU including the multiplexers.
> > 16 registers of 16 bits (in addition to PC and status? or are they included?)
> 16 registers of 16 bits is 256 bits, four transistors each (like they
> did on the actual 6502), with multiplexers, lets's say 1200 transistors.
<
The 4 transistors make up the storage unit, but you have not added the
read (mux) or write ports, so the count is a bit higher.
>
> 2000 so far.
> > Bernd Paysan's suggestion of using DRAM for registers might help here.
> > longer instruction buffer (especially with the 16-bit immediates)
> >
> > What might make it cheaper:
> >
> > Depending on the instruction set: A simpler decoder with fewer cycles
> > to generate signals for (although 6502 was ingenious in minimizing the
> > microcode for its instruction set). Looking at the 6502 die shot
> > description in
> ><https://en.wikipedia.org/wiki/MOS_Technology_6502#Technical_description>,
> > apparently half of the 6502 was dedicated to control (microcode PLA
> > and random), so there is substantial room for improvement here.
<
Like Mc 88100, 6502 used a single NOR plane as microcode.
<
> That was the point I was trying to get across. A proto-RISC 16-bit
> processor could get by without much of the sequencing and control
> logic on the 6502. Let's say the additional logic is implemented
> in 1500 transistors (not unreasonable), and we're up to 3500.
> >>Of course, such a design would be screaming to have a 16-bit
> >>data bus. Power, Ground, Memory ready, IRQ, Reset, Read/Write,
> >>NMI, Clock. Would that be enough?
> >
> > The 6502 has an extra VSS pin, 3 N.C. (not connected?) pins, a sync
> > pin, an S0 pin and two clock-out pins in addition. Not sure what the
> > sync and S0 pins are good for, but if you can do without all these
> > pins, a 16-bit data bus would be technically possible.
>
> > But the result does not fit your original requirements, and in 1975
> > would have been a commercial failure. Remember that for the 1981 IBM
> > PC, IBM chose the 8088 over the 8086, because a system with a 16-bit
> > data bus is significantly more expensive than one with an 8-bit data
> > bus.
> You're right, this could be a significant bottleneck, but maybe still
> better than a 6502.

Pages:12345678910111213
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor