help - 11/34 console problem -- first LA output
Dwight K. Elvey
dwight at ca2h0430.amd.com
Tue Nov 8 11:41:21 CST 2005
>From: "Allison" <ajp166 at bellatlantic.net>
>>Subject: Re: help - 11/34 console problem -- first LA output
>> From: "Chuck Guzis" <cclist at sydex.com>
>> Date: Mon, 07 Nov 2005 20:18:21 -0800
>> To: cctalk at classiccmp.org
>>On 11/7/2005 at 9:31 PM Allison wrote:
>>>Well save for wrap around. The stack on 8008 is strictly address and
>>>as already said 14bits (the 8008 only addresses 16k!!) and 8 levels deep.
>>>It was a challenge programming it to figure out where you came from and
>>>also not blow the stack. Still it beat the design we had before it as
>>>that was around 220 pcs of TTL sequential logic.
>Well my 8008 experience predates DEC and the TTL horror was pre 8008!
>I'll say it this way. The 8008 was a ground breaking micro. From a
>programmers perspective it wasn't too bad but from a hardware designers
>and debug perspective it was nasty. It was enough to be a micro but as
>feature free as one can get. However for the time it was pushing the
>limit for integration at around 5000 transistors in Pmos.
>The number of chips with limited internal stacks would amaze you. The
>8048/9 series is a fairly well known one, TMS1000 4 bitters, NEC uCOM4
>4 bitters, NEC uCOM75 series, National COPs and even the PIC all come
>to mind. And in every one them if you exceed the stack something falls
>off the bottom. Stack red zone hardware is truly a big machine thing.
I thought I might add that many current day DSP chips also
have internal stacks. Of course the Forth chip, the NC4000
used external stacks but had 3 busses to handle them so that
one could have all being active at one time. Two were stacks
and one was for instruction/data.
The 2100 family DSP by ADI has a limited internal stack as well
but it seems like I remember it would generate an interrupt if
Most tools for these have a method of indicating if the code
your running has a combination of main flow and interrupts
that would cause an overflow. Although, it doesn't seen so,
the worst case is predictable.
>>I always wondered why a carry or borrow from the stack pointer couldn't
>>have at least generated a branch to some known location. It may not have
>>exactly told you where your code went bonkers, but it'd be better than
>>letting the program run wild! How many micros used a local stack? The
>>Natoinal PACE is the only other one that comes to mind, but at least it had
>>a "stack about to overflow" interrupt and a way to access the stack
>>Were you a Datapoint employee?
>NEC and DEC but never Datapoint.
More information about the cctalk