John,

Let's look a bit at the numbers.

A) At a 14400 bit rate (8,N,1) and assuming a streaming mode of operation, bytes are arriving ever 694 us.

B)The 28c256 can accept bursts of 64 bytes but then you must delay a maximum of 10 ms.

C)If you allocate a buffer of 64 bytes to implement a page buffer this buffer fills every 44ms.

Now if you implement two buffers each 64 bytes deep, you can now fill one buffer from the serial line while writing out the other to the E2ROM (alternating buffers so that the one just filled becomes the one you write from and "vice versa".

These buffers do "eat up" a lot of RAM but 128 is a nice size if you can spare the top of IRAM (80H to FFH) for these buffers.

If you write 64 bytes to the E2ROM something like (@12 MHz std '51):

page_loop:
mov a,@r0
movx @dptr,a
inc r0
inc dptr
djnz r7,page_loop
~
it takes a little better than a half a ms. to write a 64 byte page to the E2ROM.

So if you have two buffers, one filling while the other is being written to the e2rom your "timing only" technique will work.
In fact your buffer filling logic can be that timing logic.

Now two methods are provided for knowing when the device is ready for more data (1) the last byte written will read back in complimented form until the device is ready or (2) upon succesive reads D6 will toggle 1 to 0,0 to 1, while the part is busy and finally stablize (to it's original value) when the device is ready for more.

Why use the polling mode? Because the E2ROM is generally faster than max spec. (if you pick the right vendor much faster than 10ms).

Again you buffer filling logic can easily incorporate the polling mode.

regards,
p