> Don't know. Most times whenever someone asks about more EEPROM parts
> The response from Microchip has been along the lines of "too slow, not
> cost effective, no request from real (read thousands of units).

Hmm... I personally find this a little surprising; especially if MicroChip
could produce a product which could write its EEPROM under [perhaps limitted]
program control (e.g. code writes data value to be written to a pair of magic
registers, executes a computed goto to the desired spot, and 10ms later the
chip resets having written the word) I think there'd be a market for certain
types of upgradable consumer products.

> Does this have built in character/graphics drivers? If not then you'll
 probably
> need another PIC to act as the interface to it. One of my biggest problems.
> I have a Toshiba display from Timeline that I haven't gotten to work even
> with the built-in drivers. Japanese translated English isn't real conducive
> to easy understanding.

Hmm... I've been wanting to use one of those, and thinking of getting one
from TimeLine.  Have you tried just writing a hard-coded "hello world"?
[i.e. explicit code to toss the data onto the appropriate pins without any
real logic whatsoever]?

> And you still haven't dealt with a fundamental PIC flaw: the inaccessible
> stack. It's significant because interrupt based task switching is almost
> impossible to do because you can't change the stack for each task.
...
> Even if Microchip had mapped just the top of the hardware stack into memory
> there's a possibility of implementing a usable multitasking executive.Because
> the call stack can be easily implement using gotos and user stacks, A TOS
> mapping would create the ability to store the current return address and
> change it.  I mean it's only 2 lousy bytes that I believe each PIC has in
> its address space. A real bummer.

While it may seem discouraging that the PIC does not have a software-address-
ible stack, it's also understandable.  You need to realize that the PIC is
set up to support certain simultaneous data flows, and these flows are of
necessity not connected.  While the 17C42 did map the accumulator into memory
(rather a surprise) in general mapping things into memory is not so simple as
you might imagine.  Personally, the only way I could really imagine the PIC
allowing memory-mapped access to its stack would be to add a pair of registers
which could be PUSH'ed and POP'ed.  While this would be useful and somewhat
do what you want, it still wouldn't be perfect.  Alternatively, if the stack
pointer were addressible (even if the stack itself weren't) you could do some
multi-tasking that way.

> Another possibility in the Motorola family is the 683XX series. I don't know
> about pricing, but they have an extended 68020 core (called CPU-32), on board
> peripherals (serial, parallel, DMA, timers) and come in low power/ low voltage
> versions. I'm partial the 68340 and the 68332 is nice too.

Note: the 683xx CPU-32 core is NOT an extended 68020; rather, it is a varia-
tion on the 68010.  Important differences include:

[1] Limit of 16 bit data bus.
[2] No code cache.
[3] "Loop mode": if you execute a one-word instruction followed by a one-word
    branch back, I believe the instruction and the branch will only be fetched
    twice (and executed the appropriate number of times in turbo-mode).
[4] I believe not all of the 68020 addressing modes are supported, though some
    modes are added compared to the 68000.
[5] Some new interpolation instructions.