[Coco] EEPROM replacement for 27C256

Dave Philipsen dave at davebiz.com
Mon Jun 29 14:04:28 EDT 2015


Yes, I think that's right. Another benefit of the 29c256 is that it appears to be available with faster access times. 

Dave Philipsen

> On Jun 29, 2015, at 7:19 AM, John B <trymyz at gmail.com> wrote:
> 
> Great information.  As for the EEPROM vs Flash, my understanding is the
> CoCo3 will still read the information the same way, the main difference is
> how its programmed.  I will be using TL866 so I should be ok.  Let me know
> if I am off base.
> 
> John
> 
>> On Sun, Jun 28, 2015 at 7:33 PM, Dave Philipsen <dave at davebiz.com> wrote:
>> 
>> Good point.  A couple of reasons for uniformity might be for ease of
>> programming with standardized programmers and for certain internal
>> page/block write operations operations that may require certain address
>> lines to be assigned correctly.  Also, the 28C256 polls the D7 line to
>> verify when a programming operation has finished although that could be
>> taken care of through software.
>> 
>> As far as the 29C256 is concerned, according to the strictest sense of
>> nomencalture  it is not an EEPROM but a FLASH.  I don't think you can write
>> single bytes with the 29C256 like you can with the 28C256.  But the 29C256
>> might be just the ticket for you if you understand the way it works.
>> 
>> Dave Philipsen
>> 
>>>> On 6/28/2015 12:55 PM, Gene Heskett wrote:
>>> 
>>> Another piece of trivia folks.
>>> 
>>> As long as the data buss is the same width AND on the same series of
>>> pins, it doesn't matter one bit if data pin d0 is connected to the data
>>> line on the board named d0. Ditto for d1-d7 (or d15 for 16 bit wide
>>> chips) Because any sucn accidental or on purpose scrambling simplifies
>>> the board layout, scrambling of the data written, it will be unscrambled
>>> by the same "re-arrangement" on the subsequent read.  You will get back
>>> the same data you wrote in any event.
>>> 
>>> Exactly the same situation exists for the address lines, the operative
>>> again is that the same group of pins are being used.  The a0 thru a15
>>> (or a23, a31 in the case of wider chips) can be fed to the chip in any
>>> sequence.
>>> 
>>> As long as those conditions are met, it will work as expected.
>>> 
>>> I can think of a flash eprom that would need exact matching because they
>>> often have to erase and rewrite a whole 4k block to change one bit.  The
>>> cocosdc might, probably is subject to that exception, but Darren can
>>> correct me.
>>> 
>>> On Sun, Jun 28, 2015 at 12:17 AM, Dave Philipsen <dave at davebiz.com>
>>> wrote:
>>> 
>>>> There is a 28C256 that is as probably as close as you'll get in
>>>>> terms of pinout.  It won't be an exact drop-in replacement, though,
>>>>> as the A14 pin changes position and you'll have to come up with a
>>>>> write enable as, obviously, the 27C256 which is a primarily
>>>>> read-only device does not have. I have a 28C256 floating around here
>>>>> somewhere that I used in a custom circuit I built one time but I've
>>>>> never tried to wire it up to a CoCo3. One thing for sure, you'd have
>>>>> to make sure that any changes written to the EEPROM contain no
>>>>> undesirable code that could cause the CoCo to become unbootable.
>>>>> Otherwise you'd have to pull the 28C256 and re-program it out of
>>>>> circuit.
>>>>> 
>>>>> Dave Philipsen
>>>>> 
>>>>>> On 6/25/2015 2:43 PM, John B wrote:
>>>>>> 
>>>>>> Does anyone know of a suitable EEPROM replacement for the 27C256
>>>>>> found in the CoCo3?
>>>>> --
>>>>> Coco mailing list
>>>>> Coco at maltedmedia.com
>>>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>> Cheers, Gene Heskett
>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco


More information about the Coco mailing list