Pipelined 6502/z80 with cache and 16x clock multiplier

On Dec 25, 10:56=A0pm, D Yuniskis <not.going.to...@seen.com> wrote:

> Wasn't the 2A03 also a 6502 derivative?

Yes, but it hasn't been produced for a while :) NES was 6502, SNES was
65C816.

On Sat, 25 Dec 2010 14:51:38 -0800 (PST), "Paul A. Clayton"
<paaronclayton@gmail.com> wrote:

>On Dec 19, 11:12&#4294967295;pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid>
>wrote:
>[snip]
>> Perhaps, but I don't think that is the target market for 4 bit
>> processors. &#4294967295;ARAIR the bit market for 4 bit processors is in the really
>> low requirements consumer areas, such as remote controls for TV's etc.
>> and things like microwave ovens, clothes washers, etc. &#4294967295;As such, speed
>> isn't an issue, but low cost and perhaps low power (i.e. longer battery
>> life) is. &#4294967295;So the market you are talking about may very well exist, but
>> that doesn't mean it will replace the 4 bit market.
>
>Performance does seem to be unimportant.  Note also that low power
>can also exploit energy harvesting.  It is surprising to me, however,
>that a mask-configurable 8-bit or 4-bit processor is not implemented
>(or would dynamic selection be more appropriate/sufficiently power-
>efficient? or fuse-configurable?), given that the registers/ALU/etc.
>(or even the entire processor core) take up a small fraction of the
>chip area.  (At larger bit widths, providing a half-width double-
>threaded mode could be useful.)  It does seem unlikely to me that
>a 4-bit processor makes sense: I strongly suspect that the area
>savings relative to an 8-bit processor are not significant (when
>ROM, RAM and peripherals take up most of the die space) and it seems
>likely that memory accesses would consume a significant fraction of
>the power reducing the impact of a wider processor.  If the processor
>tends to be either fully active or fully off, then differences in
>leakage (static) power would not be significant either it seems.
>(For very simple processors, would wave pipelining and asynchronous
>methods be attractive?)

If performance is not an issue, why limit the selection between 4 bit
or 8 bit parallel CPUs ? On a serial (1-bit) hardware, the word length
can easily be extended to match the requirements of the application by
adding bits into (dynamic) shift registers functioning as
accumulators. 

On Sat, 25 Dec 2010 19:39:30 -0800 (PST), larwe <zwsdotcom@gmail.com>
wrote:

>On Dec 25, 9:45&#4294967295;pm, George Neuner <gneun...@comcast.net> wrote:
>
>> I have no idea whether 6502 compatible chips are in demand for any
>> purpose.
>> Even so, I wouldn't bother with the 6502, but rather I would implement
>> the 65816 (or the 65802 if you need 6502 pin compatibility). &#4294967295;The
>
>At least until a year or two ago, Sunplus had a range of chips that
>were 6502 core with some restrictions (IIRC no Y register and maybe a
>couple of other oddities). Winbond and a couple of others also use
>6502 or 65816 cores in their toy chips.

There are a number of second sources for 6502's, but they aren't all
the same chip ... several manufacturers (incompatibly) extended the
original instruction set to add unconditional branching and a variety
of bit manipulation instructions.  Some of the extended variants have
instruction sets that conflict with the official 65c02 instruction
set.

I hadn't heard about variants missing an index register ... that would
effectively cripple the chip regardless of which register was missing.
The "indexed indirect" (pointer table) address mode depends on X and
"indirect indexed" (pointer+offset) mode depends on Y.  You can work
around lacking either of these, but the code would be both larger and
slower.

AFAIK, Western Design Center is the only source for 65816.

>I guess it depends on whether
>you already have proprietary dev tools (for compiling proprietary
>languages, building audio projects, assembling LCD data, etc) that
>target 6502.

There are freely available native and cross development tools
targeting both the 6502 and 65816: C and Pascal compilers, Forths, and
a whole selection of assemblers and disassemblers.

Freely available from Apple are the APW 65816 assembler and C compiler
(you needs a //gs to run these) and the corresponding MPW 65816 cross
development tools for the Macintosh.   

There is a proprietary MPW Pascal compiler for the 65816 but, AFAIK,
it isn't available free.  TML Pascal (//gs) is available free.

George

On Dec 27, 9:35=A0pm, George Neuner <gneun...@comcast.net> wrote:

> AFAIK, Western Design Center is the only source for 65816.

As a matter of known fact, the "SNES on a chip" and other similar
devices from Sunplus (inter alia) have a 65C816 within. Of course,
that might be no more legally licensed than the SNES cartridge images
that are typically on the ROM array right next to the CPU ;)

Some of Winbond's more recentish chips also had a c816 core. Don't
recall the details, it has been a while since I cared about that
field.

> >you already have proprietary dev tools (for compiling proprietary
> >languages, building audio projects, assembling LCD data, etc) that
> >target 6502.
>
> There are freely available native and cross development tools
> targeting both the 6502 and 65816: C and Pascal compilers, Forths, and
> a whole selection of assemblers and disassemblers.

Sure, but I was talking about internally-developed proprietary SDKs
for toy chips. These typically use a sort of macro language, and are
very primitive. They're developed to the bare minimum required to get
people to buy the chips, and in many cases they are the ONLY way to
write programs for the chips (short of writing completely from-scratch
asm, which loses you the libraries that make the chip possible to work
with while retaining your sanity).

The head guy from Winbond's toy chip division once said to us when we
were complaining about the crappy tools "I have three engineers on
these chips. I can have them work on tools, or on the next version of
the chip. What do you think I'm going to ask them to do?"

On 28/12/2010 03:35, George Neuner wrote:
> On Sat, 25 Dec 2010 19:39:30 -0800 (PST), larwe<zwsdotcom@gmail.com>
> wrote:
>
>> On Dec 25, 9:45 pm, George Neuner<gneun...@comcast.net>  wrote:
>>
>>> I have no idea whether 6502 compatible chips are in demand for any
>>> purpose.
>>> Even so, I wouldn't bother with the 6502, but rather I would implement
>>> the 65816 (or the 65802 if you need 6502 pin compatibility).  The
>>
>> At least until a year or two ago, Sunplus had a range of chips that
>> were 6502 core with some restrictions (IIRC no Y register and maybe a
>> couple of other oddities). Winbond and a couple of others also use
>> 6502 or 65816 cores in their toy chips.
>
> There are a number of second sources for 6502's, but they aren't all
> the same chip ... several manufacturers (incompatibly) extended the
> original instruction set to add unconditional branching and a variety
> of bit manipulation instructions.  Some of the extended variants have
> instruction sets that conflict with the official 65c02 instruction
> set.
>

I think Rockwell made an enhanced version of the 6502 for the later BBC 
micros (the BBC Master).

> I hadn't heard about variants missing an index register ... that would
> effectively cripple the chip regardless of which register was missing.
> The "indexed indirect" (pointer table) address mode depends on X and
> "indirect indexed" (pointer+offset) mode depends on Y.  You can work
> around lacking either of these, but the code would be both larger and
> slower.
>
> AFAIK, Western Design Center is the only source for 65816.
>
>> I guess it depends on whether
>> you already have proprietary dev tools (for compiling proprietary
>> languages, building audio projects, assembling LCD data, etc) that
>> target 6502.
>
> There are freely available native and cross development tools
> targeting both the 6502 and 65816: C and Pascal compilers, Forths, and
> a whole selection of assemblers and disassemblers.
>

There were a range of programming languages available for the BBC 
Masters, including Pascal, C, Forth and Logo, running native on the 
6502.  I don't remember whether the Pascal was a full compiler or used 
P-Code.  And Acorn's Basic was always viewed as one of the best Basic 
variants around, and had a built-in assembler.

Of course, native BBC Micro software is perhaps not the most useful 
starting point for cross development...

> Freely available from Apple are the APW 65816 assembler and C compiler
> (you needs a //gs to run these) and the corresponding MPW 65816 cross
> development tools for the Macintosh.
>
> There is a proprietary MPW Pascal compiler for the 65816 but, AFAIK,
> it isn't available free.  TML Pascal (//gs) is available free.
>
> George

In article <ien6lu$8n9$1@speranza.aioe.org>,
D Yuniskis  <not.going.to.be@seen.com> wrote:
>Hi Brett,

>Or anything else that uses timing loops or implicitly
>counts on execution speed wrt peripheral interfaces, etc.
>(e.g., some devices have internal synchronizers which
>won't run faster just because the processor wants to
>run faster -- "recovery times").
>
>> But lets ignore that for the moment, Apple made some work arounds
>> for the Apple2GS, so that can be fixed.
>>
>> Step 2 would be to add a boot loader to set the cache modes up
>> correctly for your memory spaces, so everything is not write through.
>> That will get you another ~2x speedup.
>>
>> One should be able to do at least a 16x local clock multiplier,
>> especially if the base clock is a pathetic 2 MHz.
>> That will get you another ~8x speedup.
>>
>> The end result will be a ~quarter of the speed of the native OpenRISC
>> opcodes, due to being register starved, but close enough not to matter?
>> Compatibility is important.
>>
>> The end result would still be pad limited and tiny, and made at a
>> still obsolete if newer fab.
>>
>> Is there a market for a 6502 era CPU that ran ~10x faster at
>> ~10% more cost?
>
>The military, IIRC, still uses 6502's in some weapon systems (?)

I have written some code for sampler chips that contain 
dual 6502s at opposite clocks. AFAIK they are still used in
sonars because they now have such a low price and small
footprint; pulling in 14 bit a/d samples, compress them
to 8 and shift them out as a bit stream. 

I don't think these will benefit from faster speeds. Perhaps
a 2x or 4x speedup, but they perform such a lowly task
that more oomph is wasted on them.

>> I think I just described the AVR8 family of CPUs, so the answer
>> would be yes...
>
>Rabbit tried this approach with the Z80.  But, decided to make
>something that wasn't 100% compatible with the original Z80.
>At least the Z180 devices didn't suffer this fate.

I keep thinking what could be done if a classic machine
like a PDP11 or a PDP10 was made with a modern process, no
microcode in core instructions, and we substiute L2 cache
for main memory, and ram for disk. And hyperchannel for
I/O. 

How high could we have driven the clock for such a system?

NO classic memory accesses. Just L1/L2 cache systems, and
a FAST "disk". 

-- mrr

Hi Morten,

On 12/29/2010 3:11 PM, Morten Reistad wrote:
> In article<ien6lu$8n9$1@speranza.aioe.org>,
> D Yuniskis<not.going.to.be@seen.com>  wrote:
>>> Is there a market for a 6502 era CPU that ran ~10x faster at
>>> ~10% more cost?
>>
>> The military, IIRC, still uses 6502's in some weapon systems (?)
>
> I have written some code for sampler chips that contain
> dual 6502s at opposite clocks. AFAIK they are still used in
> sonars because they now have such a low price and small
> footprint; pulling in 14 bit a/d samples, compress them
> to 8 and shift them out as a bit stream.
>
> I don't think these will benefit from faster speeds. Perhaps
> a 2x or 4x speedup, but they perform such a lowly task
> that more oomph is wasted on them.

Actually, this might be a good sort of use!  E.g.,
I often throw two or three "extra" MCU's into a
design in place of an FPGA+software (in the "main"
CPU).  With more MIPS, you could address a wider
range of "subsystems".

But, you need rigidly defined, small-ish algorithms
to avoid having to lose any economies that the small/fast
CPU gives you (since you want the memory complement to
be entirely in the MCU).  E.g., I like using MCUs
for sound subsystems -- tasks that are easy to
offload from the main CPU (very little interaction
and very terse data formats) that can also be coded
in very small memory footprints.

>>> I think I just described the AVR8 family of CPUs, so the answer
>>> would be yes...
>>
>> Rabbit tried this approach with the Z80.  But, decided to make
>> something that wasn't 100% compatible with the original Z80.
>> At least the Z180 devices didn't suffer this fate.
>
> I keep thinking what could be done if a classic machine
> like a PDP11 or a PDP10 was made with a modern process, no
> microcode in core instructions, and we substiute L2 cache
> for main memory, and ram for disk. And hyperchannel for
> I/O.
>
> How high could we have driven the clock for such a system?

While the 10 and 11 were "pigs" in their day, I think they
would be considered "lightweight" when compared to i64
devices today.  I.e., why couldn't you clock them just as fast?
And, assuming you resist the temptation to add all the
cruft that is now part of ISA offerings, you could probably
get great performance from them

VAX SOC!  :>

> NO classic memory accesses. Just L1/L2 cache systems, and
> a FAST "disk".

Morten Reistad wrote:
> I keep thinking what could be done if a classic machine
> like a PDP11 or a PDP10 was made with a modern process, no
> microcode in core instructions, and we substiute L2 cache
> for main memory, and ram for disk. And hyperchannel for
> I/O.

Afair, both of them had memory indirect addressing?
>
> How high could we have driven the clock for such a system?

Given that you'll need some form of microcode statemachine to handle 
complicated addressing modes, the rest should be relatively easy.
>
> NO classic memory accesses. Just L1/L2 cache systems, and
> a FAST "disk".

1-2 GHz with ~1 ipc?

Terje

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

On Mon, 27 Dec 2010 19:53:45 -0800 (PST), larwe <zwsdotcom@gmail.com>
wrote:

>On Dec 27, 9:35&#4294967295;pm, George Neuner <gneun...@comcast.net> wrote:
>
>> AFAIK, Western Design Center is the only source for 65816.
>
>As a matter of known fact, the "SNES on a chip" and other similar
>devices from Sunplus (inter alia) have a 65C816 within. Of course,
>that might be no more legally licensed than the SNES cartridge images
>that are typically on the ROM array right next to the CPU ;)
>
>Some of Winbond's more recentish chips also had a c816 core. Don't
>recall the details, it has been a while since I cared about that
>field.

I don't doubt they exist ... WDC does license an embeddable 65816
core.  But a core based product does not count as a "second source".
GTE and Sanyo used to make 65816s as second sources for WDC ... but
they no longer do so.  AFAIK, WDC currently is the only source to get
an actual 65816 chip.

George

Morten Reistad <first@last.name> wrote:

>I keep thinking what could be done if a classic machine
>like a PDP11 or a PDP10 was made with a modern process, no
>microcode in core instructions, and we substiute L2 cache
>for main memory, and ram for disk. And hyperchannel for
>I/O. 
>
>How high could we have driven the clock for such a system?
>
>NO classic memory accesses. Just L1/L2 cache systems, and
>a FAST "disk". 

It would be very fast on old applications and operating systems, but
not so much on newer ones.