help - 11/34 console problem -- first LA output

Dwight K. Elvey dwight at
Tue Nov 8 11:41:21 CST 2005

>From: "Allison" <ajp166 at>
>>Subject: Re: help - 11/34 console problem -- first LA output
>>   From: "Chuck Guzis" <cclist at>
>>   Date: Mon, 07 Nov 2005 20:18:21 -0800
>>     To: cctalk at
>>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
it overflowed.
 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 mailing list