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.

Could we do better knowing what we know now?

"Better" could of course mean different things - more instructions
per cycle, possibility of higher frequency, higher code density,
easier programming (programming the 6502 was not easy, especially
on the C-64 where Commodore had used up almost all of the zero
page for its Basic - I hardly ever used the X register).

The boundary conditions were of course severe. 16 bit address
bus, combined program and data bus of 8 bit. At least memory
was rather fast and could be accessed once per cycle without
problems (and even with the possibility of another, interleaved
access for graphics). Plus, any more transistors were bound to
increase the size and decrease the yield, leading to much
higher cost and erosion of the competetive advantage that the
6502 and its derivatives had at the time.

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.

But interestingly enough, the 12-bit SDS 92 had an instruction set
that in many ways resembled those of the early 8-bit micros. (A
manual describing its instruction set is, of course, on Bitsavers.)

John Savard

On 2021-07-23 12:59, 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.

One of my favorite aspects of the 6502/6510 CPU was that the logic
was so "compressed" that they didn't even bother to define the
semantics for undefined opcodes, so people later discovered that
many of the undefined opcodes actually had a useful meaning (while
some were less useful).

This is a very nice document that gives a detailed description of
all of the "illegal" opcodes (or "unintended", as the author calls
them):

https://codebase64.org/lib/exe/fetch.php?media=base:nomoresecrets-nmos6510unintendedopcodes-20202412.pdf

>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).

I have a love-hate relationship with the 6502. It's the first machine
that I programmed assembler on (actually I mostly used a machine code
monitor in the beginning), and as you say it's remarkable in many ways.
Yet it's also horrible to code in many ways.

I have sometimes thought about various ways to do a "modern" 6502.

At one end of the spectrum you could try to make a binary compatible
machine that tries to go as far as possible with pipelining and
high clock speeds etc (it's an interesting problem since 6502 was
not designed for pipelining, and ugly things like self-modifying code
were very common - at least on the C=64).

At another end of the spectrum you could try to make a 6502:ish
ISA, but with easier to use addressing modes and registers etc. It
wouldn't be compatible, but it would be interesting to see if you
could design something with similar (low) complexity that's more
programmer friendly.

>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.
>

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> On 2021-07-23 12:59, 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.
>
> One of my favorite aspects of the 6502/6510 CPU was that the logic
> was so "compressed" that they didn't even bother to define the
> semantics for undefined opcodes, so people later discovered that
> many of the undefined opcodes actually had a useful meaning (while
> some were less useful).

That is a consequence of their logic - they generated the internal
CPU with a PLA with a lot of "don't care" values. You can see the
PLA on the top of the die shots on http://www.visual6502.org/ .
Apparently, this was quite popular in NMOS, less so in CMOS.

We could probably do better now because our PLA optimization
algorithms are better now than in 1974 (if they even used automated
methods for the design in that particular team, I see no mention
of it anywhere).

[...]

>> Could we do better knowing what we know now?
>>
>> "Better" could of course mean different things - more instructions
>> per cycle, possibility of higher frequency, higher code density,
>> easier programming (programming the 6502 was not easy, especially
>> on the C-64 where Commodore had used up almost all of the zero
>> page for its Basic - I hardly ever used the X register).
>
> I have a love-hate relationship with the 6502. It's the first machine
> that I programmed assembler on (actually I mostly used a machine code
> monitor in the beginning), and as you say it's remarkable in many ways.
> Yet it's also horrible to code in many ways.

That pretty much expresses my feelings, too.

> I have sometimes thought about various ways to do a "modern" 6502.
>
> At one end of the spectrum you could try to make a binary compatible
> machine that tries to go as far as possible with pipelining and
> high clock speeds etc (it's an interesting problem since 6502 was
> not designed for pipelining, and ugly things like self-modifying code
> were very common - at least on the C=64).

You would probably need to run this off 64 kbyte static RAM
(basically use a modern L1 cache as RAM), or you would have to
wait a relative eternity of what you can do today in a CPU.

> At another end of the spectrum you could try to make a 6502:ish
> ISA, but with easier to use addressing modes and registers etc. It
> wouldn't be compatible, but it would be interesting to see if you
> could design something with similar (low) complexity that's more
> programmer friendly.

That's what I was thinking of - what could they have built with
a similar transistor number at the time?

One severe problem for code density was 16-bit arithmetic. This was
so bad tat Steve Wozniak wrote what we would today call a "Soft CPU"
in 6502 assembler, the https://en.wikipedia.org/wiki/SWEET16 ,
a sixteen-register accumulator architecture. This has to be one
of the shortest CPU emulators in history, with around 300 bytes.

So... probably a load-store architecture to save complexity, and
lose the more complicated addressing modes. With an 8 bit machine,
you'd want 8 and 16 bit immediates for load and store, jump and
branch. Opcodes should be limited to single bytes. There are so
few bits in a byte that you cannot have many operations between
registers, so the accumulator architecture stays, but something
like the 8080 or Z80 register pairs could make sense.

You could still have special treatment of the zero page by allowing
load and store absolute with an immediate byte, or relative to
an 8-bit register.

Hm... this would probably look more like an 8080 than a 6502.

On Friday, July 23, 2021 at 5:59:30 AM UTC-5, 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.
>
> Could we do better knowing what we know now?
<
Yes, It was called the PDP-11.
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit.
<
The buss needs widened.
<
> At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

On Friday, July 23, 2021 at 9:21:04 AM UTC-6, MitchAlsup wrote:
> On Friday, July 23, 2021 at 5:59:30 AM UTC-5, 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.

> > Could we do better knowing what we know now?

> Yes, It was called the PDP-11.

The PDP-11 used even fewer transistors?

I could imagine the PDP-8 would, as it was *very* simple.

John Savard

Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>> On 2021-07-23 12:59, 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.
>> One of my favorite aspects of the 6502/6510 CPU was that the logic
>> was so "compressed" that they didn't even bother to define the
>> semantics for undefined opcodes, so people later discovered that
>> many of the undefined opcodes actually had a useful meaning (while
>> some were less useful).
>
> That is a consequence of their logic - they generated the internal
> CPU with a PLA with a lot of "don't care" values. You can see the
> PLA on the top of the die shots on http://www.visual6502.org/ .
> Apparently, this was quite popular in NMOS, less so in CMOS.

In nmos they could build equivalent to wired-OR logic with a
depletion mode pull-up (effectively a resistor pulling the wire high)
and a pull down for each input signal. Essentially each logic input
term to a large fan-in NAND (a, b, c, ...) cost just 1 transistor.

It wastes power, but it works.

Static CMOS doesn't have any equivalent to wire-OR so there is little
saving making static PLAs. Instead PLAs are built out of dynamic logic.
But I don't see them explicitly referenced in designs much
so I think the tricky dynamic aspect keeps designers away.
Also tools like Verilog don't generate PLAs.

> We could probably do better now because our PLA optimization
> algorithms are better now than in 1974 (if they even used automated
> methods for the design in that particular team, I see no mention
> of it anywhere).

IIRC 6502 used a PLA for the first part of the decoding and sequencing,
but also had gobs of random logic after it.

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.
>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

Also the whole processor would have been designed using brain power
on paper and pencil. There was no CAD development tools.

Then a prototype is wired up, probably using TTL on wire-wrap boards,
and debugged using oscilloscopes.

Then that logic is translated by hand to individual transistors,
again using pencil and paper.
And wire up a second prototype using individual transistors
and debugged using oscilloscopes.

Then the transistor level design is translated by hand to
giant colored-tape-on-clear-mylar sheets, about 6 ft by 6 ft.
One sheet for each mask layer.

Oh and you only have 2 layers of interconnect, one polysilicide
and one metal. Use them wisely.

These masks are then photo reduced to produce the reticle masks.

Then you can make your prototype IC and 8-12 weeks later
you can start testing it to try to figure out the mistakes
you made in any of the above.

Le 23/07/2021 à 12:59, Thomas Koenig a écrit :
> 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.
>
> Could we do better knowing what we know now?

If you mean with the same number of transistors, that would be very hard
to do really better.

I guess using a completely different architecture, based on a very
simple RISC instruction set, you might be able to do something a bit
more "powerful" with the same amount of logic, and being able to run at
much higher frequencies even on old processes. But using such a CPU with
simple dev tools as they were available at them time would be very
clunky. Only decent compilers can make efficient use of such simple RISC
architectures while not making the developers' life a hell. I guess.

On Friday, July 23, 2021 at 11:33:05 AM UTC-5, EricP wrote:
> Thomas Koenig wrote:
> > Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >> On 2021-07-23 12:59, 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.
> >> One of my favorite aspects of the 6502/6510 CPU was that the logic
> >> was so "compressed" that they didn't even bother to define the
> >> semantics for undefined opcodes, so people later discovered that
> >> many of the undefined opcodes actually had a useful meaning (while
> >> some were less useful).
> >
> > That is a consequence of their logic - they generated the internal
> > CPU with a PLA with a lot of "don't care" values. You can see the
> > PLA on the top of the die shots on http://www.visual6502.org/ .
> > Apparently, this was quite popular in NMOS, less so in CMOS.
> In nmos they could build equivalent to wired-OR logic with a
> depletion mode pull-up (effectively a resistor pulling the wire high)
> and a pull down for each input signal. Essentially each logic input
> term to a large fan-in NAND (a, b, c, ...) cost just 1 transistor.
>
> It wastes power, but it works.
>
> Static CMOS doesn't have any equivalent to wire-OR so there is little
> saving making static PLAs. Instead PLAs are built out of dynamic logic.
> But I don't see them explicitly referenced in designs much
> so I think the tricky dynamic aspect keeps designers away.
<
Err, no........
All of the 68K family (at least the ones before 040) used PLAs.
The 88Ks used a PLA--well, actually ½ a PLA; we used a single NOR
plane as the decoder in 88100.
Lots of other designs used PLAs or NOR planes because they were
DENSE--as dense as DRAMs with mask programmable bit patterns.
I bet most of the microprocessors, prior to the RISC revolution, used
PLAs (or NOR planes).
<
One of the clever things 68020 did was to place an XOR gate between
the two NOR planes of the PLA which vastly increases the kinds of
patterns one could decode !!
<
> Also tools like Verilog don't generate PLAs.
<
NO but microcode assemblers do !
<
> > We could probably do better now because our PLA optimization
> > algorithms are better now than in 1974 (if they even used automated
> > methods for the design in that particular team, I see no mention
> > of it anywhere).
> IIRC 6502 used a PLA for the first part of the decoding and sequencing,
> but also had gobs of random logic after it.

On Friday, July 23, 2021 at 11:58:56 AM UTC-5, EricP wrote:
> 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.
> >
> > Could we do better knowing what we know now?
> >
> > "Better" could of course mean different things - more instructions
> > per cycle, possibility of higher frequency, higher code density,
> > easier programming (programming the 6502 was not easy, especially
> > on the C-64 where Commodore had used up almost all of the zero
> > page for its Basic - I hardly ever used the X register).
> >
> > The boundary conditions were of course severe. 16 bit address
> > bus, combined program and data bus of 8 bit. At least memory
> > was rather fast and could be accessed once per cycle without
> > problems (and even with the possibility of another, interleaved
> > access for graphics). Plus, any more transistors were bound to
> > increase the size and decrease the yield, leading to much
> > higher cost and erosion of the competetive advantage that the
> > 6502 and its derivatives had at the time.
> Also the whole processor would have been designed using brain power
> on paper and pencil. There was no CAD development tools.
>
> Then a prototype is wired up, probably using TTL on wire-wrap boards,
> and debugged using oscilloscopes.
>
> Then that logic is translated by hand to individual transistors,
> again using pencil and paper.
<
> And wire up a second prototype using individual transistors
> and debugged using oscilloscopes.
>
> Then the transistor level design is translated by hand to
> giant colored-tape-on-clear-mylar sheets, about 6 ft by 6 ft.
> One sheet for each mask layer.
>
> Oh and you only have 2 layers of interconnect, one polysilicide
> and one metal. Use them wisely.
<
Silicide did not occur until 2µ and we are talking about the 5µ-3µ era.
But then again, logic speeds were not high enough that silicide bought
much gain (it was instrumental in getting 68020 to 33 MHz BTW)....
>
> These masks are then photo reduced to produce the reticle masks.
>
> Then you can make your prototype IC and 8-12 weeks later
> you can start testing it to try to figure out the mistakes
> you made in any of the above.
<
In the 1.5µ era we went from full layer tapeout, to prototype wafers
in 35 hours..........it was a rush job, and we had a FAB guy walk the
wafers between stations so there was not manufacturing latency
only the latency of each job step.

On Friday, July 23, 2021 at 12:16:39 PM UTC-5, Guillaume wrote:
> Le 23/07/2021 à 12:59, Thomas Koenig a écrit :
> > 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.
> >
> > Could we do better knowing what we know now?
<
> If you mean with the same number of transistors, that would be very hard
> to do really better.
<
It would be impossible today. 3× transistors is the minimum you could even
conceive of !!
<
Consider the select line driver on the 68020:: This is a logic block that
took a lightly loaded control signal, a clock, and drove a select line
across a 32-bit data path with 32 loads on this wire. Today we call these
and AND-clock. We built these with 3 transistors !! and one inversion.
I can't imagine you could build this with fewer than 12 transistors today
and 2 logic inversions.
>
> I guess using a completely different architecture, based on a very
> simple RISC instruction set, you might be able to do something a bit
> more "powerful" with the same amount of logic, and being able to run at
> much higher frequencies even on old processes. But using such a CPU with
> simple dev tools as they were available at them time would be very
> clunky. Only decent compilers can make efficient use of such simple RISC
> architectures while not making the developers' life a hell. I guess.
<
In other words--don't bother.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Friday, July 23, 2021 at 5:59:30 AM UTC-5, 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.
>>
>> Could we do better knowing what we know now?
><
> Yes, It was called the PDP-11.

The PDP-11 had considerably more transistors, looking at the die
shot of the https://en.wikipedia.org/wiki/DEC_T-11 vs. the die
shot at https://en.wikipedia.org/wiki/MOS_Technology_6502 will
tell you (or a look at https://en.wikipedia.org/wiki/DEC_J-11
from 1979).

Totally impossible to start the home computer revolution with
such a chip launched in 1975, whose main selling point was that
it undercut the more 6809 on price.

No 6502, no Apple I or II, no C-64.

>> "Better" could of course mean different things - more instructions
>> per cycle, possibility of higher frequency, higher code density,
>> easier programming (programming the 6502 was not easy, especially
>> on the C-64 where Commodore had used up almost all of the zero
>> page for its Basic - I hardly ever used the X register).
>>
>> The boundary conditions were of course severe. 16 bit address
>> bus, combined program and data bus of 8 bit.
><
> The buss needs widened.

And so they did, with their 16-bit chips. For the embedded market
in the mid-1970s that they originally developed the chip for,
this was out of the question.

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Thomas Koenig wrote:

> Static CMOS doesn't have any equivalent to wire-OR so there is little
> saving making static PLAs. Instead PLAs are built out of dynamic logic.
> But I don't see them explicitly referenced in designs much
> so I think the tricky dynamic aspect keeps designers away.
> Also tools like Verilog don't generate PLAs.

If you want to, it is quite possible to use Espresso (see
https://github.com/classabbyamp/espresso-logic to generate Verilog
or VHDL truth table (you may have to edit the formulas, but that
is easily doable by using a small sed script).

>
>> We could probably do better now because our PLA optimization
>> algorithms are better now than in 1974 (if they even used automated
>> methods for the design in that particular team, I see no mention
>> of it anywhere).
>
> IIRC 6502 used a PLA for the first part of the decoding and sequencing,
> but also had gobs of random logic after it.

Easily identifiable on the chip, yep :-)

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.
>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

The cpu's I worked with were the Motorola 6800, Intel 8080,
and CMOS RCA 1802. Electronics for 1802 was the
easiest to design with but it had a horrible ISA.

I had an paper-design hobby project a while back to design the best
ISA possible within the 1802's budget of 5500 CMOS transistors.
Gates have a maximum of 3 inputs, and there is 2 layers of interconnect.

My design had 2 accumulators, A and B, a Flag register,
8 16-bit address/data registers, a link register for Branch And Link,
a link register for interrupted IP, and a IP register.
In the Mark-I model A and B were 8 bits. In the Mark-II they were 16 bits.

Internally there was a 16 bit temp register for loading an immediate,
a Memory Address Register (MAR), ALU input registers,
and an 8-bit instruction register.

Instruction opcodes are 8 bits, with 1 or 2 bytes of immediate,
and can do 8 and a few 16 bit operations.
Two accumulators means operate opcodes are of the form A = A op B
eliminating register fields for most instructions.
The rest of the instructions have a single 3-bit register field.

The decoder was one 2:4 and two 3:8 decoders (remember, gates are
limited to 3 inputs so no 4:16 decoders) followed by random logic,
and the instruction sequencer a 16 state Johnson counter.
ALU performed standard operations but also did 16-bit
increment, decrement, and add.

There is a 16 bit bus running from the register file to MAR, ALU
and data bus interface, and a 16 bit result bus the runs back to
register file but also to MAR so a register can be read into MAR,
and incremented sent back to register file in 1 cycle.
16 bit adds took 2 cycles.

Bus timing had its own sequencer logic (just a few FF)
so to do a bus read or write one stuffed a value in the MAR and
pulsed the bus sequencer. That shut of the instruction sequencer
until the bus cycle finished and presented the data value on the
internal data bus, and re-enable the main sequencer.

Guillaume <message@bottle.org> schrieb:
> Le 23/07/2021 à 12:59, Thomas Koenig a écrit :
>> 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.
>>
>> Could we do better knowing what we know now?
>
> If you mean with the same number of transistors, that would be very hard
> to do really better.
>
> I guess using a completely different architecture, based on a very
> simple RISC instruction set, you might be able to do something a bit
> more "powerful" with the same amount of logic, and being able to run at
> much higher frequencies even on old processes.

The Nova paved the way for that, I think - it was very good on the
price / performance curve for its day.

I have not found a transistor count for the Nova, unfortunately, and
the schematics on Bitsavers give just codes for the ICs that they
built in that I am unable to deciper.

> But using such a CPU with
> simple dev tools as they were available at them time would be very
> clunky.

Ugh...

I have programmed the 6502 in assembler, it was a PITA. A few
more registers would have done wonders and would have saved me a
few torn-out hairs (but I had enough in those days).

The first time I browsed through handbook on the 68000, I thought
"This is not assembler, this is a high-level language!"

> Only decent compilers can make efficient use of such simple RISC
> architectures while not making the developers' life a hell. I guess.

Hardly a decent compiler around for the 6502 in those days, at
least I knew none. It was Basic or Assembler (or machine code
via a monitor, with a hard reset if you made a programming mistake).

On Friday, July 23, 2021 at 1:15:11 PM UTC-5, Thomas Koenig wrote:
> Guillaume <mes...@bottle.org> schrieb:
> > Le 23/07/2021 à 12:59, Thomas Koenig a écrit :
> >> 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.
> >>
> >> Could we do better knowing what we know now?
> >
> > If you mean with the same number of transistors, that would be very hard
> > to do really better.
> >
> > I guess using a completely different architecture, based on a very
> > simple RISC instruction set, you might be able to do something a bit
> > more "powerful" with the same amount of logic, and being able to run at
> > much higher frequencies even on old processes.
> The Nova paved the way for that, I think - it was very good on the
> price / performance curve for its day.
>
> I have not found a transistor count for the Nova, unfortunately, and
> the schematics on Bitsavers give just codes for the ICs that they
> built in that I am unable to deciper.
> > But using such a CPU with
> > simple dev tools as they were available at them time would be very
> > clunky.
> Ugh...
>
> I have programmed the 6502 in assembler, it was a PITA. A few
> more registers would have done wonders and would have saved me a
> few torn-out hairs (but I had enough in those days).
>
> The first time I browsed through handbook on the 68000, I thought
> "This is not assembler, this is a high-level language!"
<
And they took most of it from the PDP-11
<
> > Only decent compilers can make efficient use of such simple RISC
> > architectures while not making the developers' life a hell. I guess.
> Hardly a decent compiler around for the 6502 in those days, at
> least I knew none. It was Basic or Assembler (or machine code
> via a monitor, with a hard reset if you made a programming mistake).

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Friday, July 23, 2021 at 1:15:11 PM UTC-5, Thomas Koenig wrote:

>> The first time I browsed through handbook on the 68000, I thought
>> "This is not assembler, this is a high-level language!"
><
> And they took most of it from the PDP-11

Certainly a lot.

What mostly dazzeled me, though, was the sheer number and
witdth of registers.

For somebody who had only seen 6502 and Z-80 up to that point,
that was quite an experience.

Of course, there was also some frustration involved. I had done
some Mandelbrot calculations (who hadn't :) and sped things up by
a factor of 10 or more by using the floating point routines
in the C-64's BASIC interpreter.

A friend, who had one of the first Amigas, was _much_ faster
just using BASIC. I then gave up on 6502 assembler.

On Friday, July 23, 2021 at 6:59:30 AM UTC-4, 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.
>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

16 bit Stack pointer.

Some optimizations that found their way into follow on products (I think these are documented on the Wikipedia page).
IIRC, there was a sequencer optimization to one of the addressing modes that sped things up by ~15%.

16 bit X & Y would have been great, especially if they supported some 16 bit math.
Get rid of the (mostly) unused addressing modes.
Direct Page register like the 6809.

I really liked the ISA of the General Instruments CP1600, but I cannot find out what the transistor count was.
(Except for the stupid encoding which wasted 4 bits for every 16 bits of memory).

- Tim

On Friday, July 23, 2021 at 2:02:19 PM UTC-4, Thomas Koenig wrote:
> Totally impossible to start the home computer revolution with
> such a chip launched in 1975, whose main selling point was that
> it undercut the more 6809 on price.
>
I think you meant 6800 (or 8080), 6809 didn't show up to several years later
(with 3x the number of transistors).

- Tim

On Friday, July 23, 2021 at 5:59:30 AM UTC-5, 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.
>
> Could we do better knowing what we know now?
>
> "Better" could of course mean different things - more instructions
> per cycle, possibility of higher frequency, higher code density,
> easier programming (programming the 6502 was not easy, especially
> on the C-64 where Commodore had used up almost all of the zero
> page for its Basic - I hardly ever used the X register).
>
> The boundary conditions were of course severe. 16 bit address
> bus, combined program and data bus of 8 bit. At least memory
> was rather fast and could be accessed once per cycle without
> problems (and even with the possibility of another, interleaved
> access for graphics). Plus, any more transistors were bound to
> increase the size and decrease the yield, leading to much
> higher cost and erosion of the competetive advantage that the
> 6502 and its derivatives had at the time.

There are several open source attempts at 6502 with more 16-bit capabilities.
Only one that attempts 64-bit capability:
http://www.6502.org/users/andre/65k/index.html
It does not fare well in FPGA LUT counts, about a 4X to 8X increase over 6502 open source designs.
But then you are going from an 8-bit ALU to a 64-bit ALU. Perhaps a two clock
32-bit ALU would be best?

On Friday, July 23, 2021 at 2:15:11 PM UTC-4, Thomas Koenig wrote:

> Hardly a decent compiler around for the 6502 in those days, at
> least I knew none. It was Basic or Assembler (or machine code
> via a monitor, with a hard reset if you made a programming mistake).
The only one I knew of was UCSD Pascal, which used the P-System
interpreter.

- Tim

On Fri, 23 Jul 2021 18:15:09 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>I have programmed the 6502 in assembler, it was a PITA. A few
>more registers would have done wonders and would have saved me a
>few torn-out hairs (but I had enough in those days).

I also programmed 6502 in assembler. I didn't find it particularly
troublesome, but no doubt it depended on what you were trying to do.

>Hardly a decent compiler around for the 6502 in those days, at
>least I knew none. It was Basic or Assembler (or machine code
>via a monitor, with a hard reset if you made a programming mistake).

Manx, DeSmet, and Orca all had native 6502 C compilers. Orca also had
a native Pascal compiler.

UCSD and Apple both had pcode Pascal compilers. I never tried the
Apple compiler, but UCSD was pretty useless.

I used the Manx C compilers on Apple //e. There was both a native and
a bytecode compiler [their own, not based on UCSD pcode or Sweet16].
You could mix native and bytecode in the same program, and even write
in 'assembler' for the bytecode interpreter. Manx suported nested
code overlays, and could use the extra 16KB "language" card on the
Apple ][, and the extra 64KB available on the Apple //e and //c.

With careful coding, it was possible to pack a whole a lot of function
into a C program ... at least on the 128KB Apple //e or //c ... and
the resulting program could be made fast enough to use.

YMMV,
George

Thomas Koenig <tkoenig@netcologne.de> writes:

> 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.
>
> Could we do better knowing what we know now?

Wasn't it already done with the 65816 or perhaps more interestingly the
CSG4510? That was intended to go in the Commodore 65 which never
happened but lives on in the FPGA-based MEGA65 project. Information is a
little hard to find for the moment though but there's some documentation
from the MEGA65 project at
https://files.mega65.org/manuals-upload/mega65-chipset-reference.pdf

AFAIK, mostly the 4510 improved on the 6502 on speed, some instructions
executed faster and some new ones were introduced. I have no idea of the
transistor count.

In article <sde7eg$hgb$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> ... programming the 6502 was not easy, especially on the C-64
> where Commodore had used up almost all of the zero page for
> its Basic - I hardly ever used the X register.

It gets easier with practice. The style of assembler code that works well
is very different from normal Z80 or x86 styles. The 6502 is quite good
at running interpreters, but compiling HLLs for it is horrible. I had a
couple of years of employment writing CAD for 6502 in the mid-eighties,
and we implemented an interpreter for a virtual machine that did the
floating point.

The early ARMs were inspired by the 6502, but only in terms of being
simple and avoiding microcode.

John