On Mon, 20 Aug 2012 16:35:16 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:
>... [65816/65802] also postdated the 8080/Z80/6800/6502 (which were
>variously introduced in 1974-1976) by a decade (the 65816 first
>shipped in 1984). Nor was it particularly successful, certainly not
>by comparison to the above four devices, or the more contemporary 68K
>and 8086 families.
That's true, but the 6502 was popular. The 65802 was pin compatible
but much nicer to work with if the code needed 16-bit operations in
any significant number.
George
Reply by ●August 24, 20122012-08-24
On Friday, August 24, 2012 11:25:40 AM UTC-7, (unknown) wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
>
> > The above are all available as single-chip solutions (on-chip SRAM and
>
> > flash). If you want to use external flash and SDRAM (e.g. to run
>
> > Linux), then I'd go with:
>
> >
>
> > * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)
>
>
>
> If you just need the memory, at least ST, TI and Fujitsu have Cortex-M3s
>
> with external memory buses and built-in SDRAM/flash memory controllers.
Also NXP.
Reply by ●August 24, 20122012-08-24
Grant Edwards <invalid@invalid.invalid> wrote:
> The above are all available as single-chip solutions (on-chip SRAM and
> flash). If you want to use external flash and SDRAM (e.g. to run
> Linux), then I'd go with:
>
> * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)
If you just need the memory, at least ST, TI and Fujitsu have Cortex-M3s
with external memory buses and built-in SDRAM/flash memory controllers.
-a
Reply by Robert Wessel●August 20, 20122012-08-20
On Mon, 20 Aug 2012 16:14:38 -0400, George Neuner
<gneuner2@comcast.net> wrote:
>On Fri, 17 Aug 2012 13:13:35 -0500, Robert Wessel
><robertwessel2@yahoo.com> wrote:
>
>>On the 6502, OTOH, neither the stack pointer*, or either of the index
>>registers, X and Y, were 16 bit. But 6502 had a few very useful
>>zero-page indirect addressing modes, which allowed using most of the
>>first 256 bytes of memory as a collection of 16-bit index registers.
>>
>>*The 8-bit stack pointer was possibly the single biggest annoyance on
>>the 6502. Or maybe the lack of a zero-page indirect addressing mode
>>that *didn't* also use X or Y�
>
>Yes. But the 65802 and 65816 did have a full complement of 16-bit
>registers and operations. The 802 was pin compatible with the 6502.
>
>The 802 is no longer available, but the 816 comes in 2 flavors: MPU or
>SoC. IMO, the MPU version is overpriced, but the SoC version is
>pretty reasonable for what it does.
While true, it also postdated the 8080/Z80/6800/6502 (which were
variously introduced in 1974-1976) by a decade (the 65816 first
shipped in 1984). Nor was it particularly successful, certainly not
by comparison to the above four devices, or the more contemporary 68K
and 8086 families.
Reply by George Neuner●August 20, 20122012-08-20
On Fri, 17 Aug 2012 13:13:35 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:
>On the 6502, OTOH, neither the stack pointer*, or either of the index
>registers, X and Y, were 16 bit. But 6502 had a few very useful
>zero-page indirect addressing modes, which allowed using most of the
>first 256 bytes of memory as a collection of 16-bit index registers.
>
>*The 8-bit stack pointer was possibly the single biggest annoyance on
>the 6502. Or maybe the lack of a zero-page indirect addressing mode
>that *didn't* also use X or Y…
Yes. But the 65802 and 65816 did have a full complement of 16-bit
registers and operations. The 802 was pin compatible with the 6502.
The 802 is no longer available, but the 816 comes in 2 flavors: MPU or
SoC. IMO, the MPU version is overpriced, but the SoC version is
pretty reasonable for what it does.
George
Reply by dp●August 17, 20122012-08-17
On Aug 17, 9:13�pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> ...
> The 6800 had a couple of 16-bit registers (the stack pointer and index
> register, plus, of course the PC), and you do some limited operations
> on X (load, store, compare, increment, decrement).
And TSX/TXS... whoever has written lots of SWI handlers will
remember those well (including the +1/-1 ...). They lived on the HC11,
probably on the 12 (whatever they call that today) to this day.
The 6809 was a huge step forward but did not make it into the future,
it came too late (although I learned the trade mostly on it), the 68k
came out and changed the game entirely.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●August 17, 20122012-08-17
On Thursday, August 16, 2012 11:57:44 PM UTC+12, Andre wrote:
> Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
>
> one that support the whole series but more certainly the mid-range
>
> including the AT89C55WD ??
Do you have a dusty drawer full of AT89C55WD ?
If you want low cost, easy to use, the new Atmel AT89LP series are supported by Atmel web programmers.
Or, look at SiLabs C8051F5xx series tool sticks, programming AND Debug for around $20-$30.
Or the Zilog Z51F series, you can get going for ~$29, again programming AND debug.
The parts above are all wide Supply, which is rather harder to find in 32 bit variants.
-jg
Reply by Robert Wessel●August 17, 20122012-08-17
On Fri, 17 Aug 2012 13:17:16 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:
>On 2012-08-17, Mark Borgerson <mborgerson@comcast.net> wrote:
>
>> I've only looked briefly at the AVR, but I've done a dozen designs with
>> various MSP430 variants.
>
>The main annoyance in the AVR is that it's strictly an 8-bit CPU. It
>can't really do any 16-bit operations. That would be fine if it had
>an 8 bit address space, but it's got two different 16-bit address
>spaces. So, if you need to do anything at all with pointers (and C is
>designed to use pointers quite a bit) the AVR falls down badly
>compared to the MSP430 -- which has sixteen 16-bit registers, a single
>16-bit address space, and a very elegent, orthogonal instructions set
>(rather reminiscent of the PDP-11) where any register can be used as a
>pointer, accumulator, index, whatever.
>
>The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
>registers and a couple 16-bit operations specifically to deal with the
>pointer issue. Unfortuantely, the AVR failed to learn from them and
>is missing those features -- and it hurts.
The 6800 had a couple of 16-bit registers (the stack pointer and index
register, plus, of course the PC), and you do some limited operations
on X (load, store, compare, increment, decrement).
On the 6502, OTOH, neither the stack pointer*, or either of the index
registers, X and Y, were 16 bit. But 6502 had a few very useful
zero-page indirect addressing modes, which allowed using most of the
first 256 bytes of memory as a collection of 16-bit index registers.
*The 8-bit stack pointer was possibly the single biggest annoyance on
the 6502. Or maybe the lack of a zero-page indirect addressing mode
that *didn't* also use X or Y�
Reply by Mel Wilson●August 17, 20122012-08-17
David Brown wrote:
> "But it would have benefited enormously from > a forth pointer register,"
Not you, too! :)
> On 17/08/2012 15:17, Grant Edwards wrote:
[ ... ]
>> The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
>> registers and a couple 16-bit operations specifically to deal with the
>> pointer issue. Unfortuantely, the AVR failed to learn from them and
>> is missing those features -- and it hurts.
>
> Strictly speaking, the AVR also has 16-bit registers (X, Y and Z) made
> from pairs of 8-bit registers, and it has a few 16-bit operations (such
> as addiw, subiw and movw). But it would have benefited enormously from
> a forth pointer register, better addressing modes with these registers,
> and a few extra instructions (such as 16-bit atomic moves between the SP
> and a pointer register).
Grant Edwards was more dramatic than I would have been, but the 8-bit roots
show in all the doubled-up instructions below. A lot of potential pointer
problems go away because gcc has inlined the heck out of the code, and much
of the parameter passing has vanished (less obvious here than in other
snippets, I guess):
unsigned char led, i, w;
int mask, val, pwm;
// randomize time to next interrupt ..
for (i=0, w=0; i < (127/32); i++) // randomly pick a number
[31/32 .. 1+1/32) scaled into 8 bits
w = w * 2 + random_bit();
a2: 33 0f add r19, r19
unsigned short lfsr = 0xACE1u;
static int random_bit ()
{
// taps: 16 14 13 11; characteristic polynomial: x^16 + x^14 +
x^13 + x^11 + 1
lfsr = (lfsr >> 1) ^ (-(lfsr & 1u) & 0xB400u);
a4: ca 01 movw r24, r20
a6: 96 95 lsr r25
a8: 87 95 ror r24
aa: 44 27 eor r20, r20
ac: 55 27 eor r21, r21
ae: 46 1b sub r20, r22
b0: 57 0b sbc r21, r23
b2: 40 70 andi r20, 0x00 ; 0
b4: 54 7b andi r21, 0xB4 ; 180
b6: 48 27 eor r20, r24
b8: 59 27 eor r21, r25
unsigned char led, i, w;
int mask, val, pwm;
// randomize time to next interrupt ..
for (i=0, w=0; i < (127/32); i++) // randomly pick a number
[31/32 .. 1+1/32) scaled into 8 bits
w = w * 2 + random_bit();
ba: ba 01 movw r22, r20
bc: 61 70 andi r22, 0x01 ; 1
be: 70 70 andi r23, 0x00 ; 0
c0: 36 0f add r19, r22
Reply by David Brown●August 17, 20122012-08-17
On 17/08/2012 15:17, Grant Edwards wrote:
> On 2012-08-17, Mark Borgerson <mborgerson@comcast.net> wrote:
>
>> I've only looked briefly at the AVR, but I've done a dozen designs with
>> various MSP430 variants.
>
> The main annoyance in the AVR is that it's strictly an 8-bit CPU. It
> can't really do any 16-bit operations. That would be fine if it had
> an 8 bit address space, but it's got two different 16-bit address
> spaces. So, if you need to do anything at all with pointers (and C is
> designed to use pointers quite a bit) the AVR falls down badly
> compared to the MSP430 -- which has sixteen 16-bit registers, a single
> 16-bit address space, and a very elegent, orthogonal instructions set
> (rather reminiscent of the PDP-11) where any register can be used as a
> pointer, accumulator, index, whatever.
>
> The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
> registers and a couple 16-bit operations specifically to deal with the
> pointer issue. Unfortuantely, the AVR failed to learn from them and
> is missing those features -- and it hurts.
Strictly speaking, the AVR also has 16-bit registers (X, Y and Z) made
from pairs of 8-bit registers, and it has a few 16-bit operations (such
as addiw, subiw and movw). But it would have benefited enormously from
a forth pointer register, better addressing modes with these registers,
and a few extra instructions (such as 16-bit atomic moves between the SP
and a pointer register).
>
>>> The above are all available as single-chip solutions (on-chip SRAM and
>>> flash). If you want to use external flash and SDRAM (e.g. to run
>>> Linux), then I'd go with:
>>>
>>> * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)
>>
>> Yup. 160K RAM hardly gets you started on an OS which wants lots of
>> buffers for ethernet stacks, file system, video and USB drivers.
>
> I should add that there are a _few_ (very few) Cortex-M parts that
> have external busses and include SDRAM controllers (NXP has one
> family), so it is possible to do large-memory stuff with Cortex-M.
Some Freescale Kinetis (Cortex-M4) parts have external memory buses, IIRC.
> But, it's far more common to move up to the Cortex-A or the slightly
> older ARM9 families if you need memory measured in MB rather than KB.
>
>> Beagleboards and their kin are good place to start here. I worked in
>> that area for half a year----but I'm really happier down in the
>> Cortex and MSP430 environment.
>