Skip to content

In-Circuit EEPROM Programming the AT28C64

January 26, 2016

The AT28C64 has a substantially similar pinout to the 27C256 I’ve replaced with it. To use it in the Z80 Membership Card I made a socket adapter that re-routes pin 27 to pin 1. Pin 27 is A14 for the 27C256 but it’s write-enable(/WE) for the 28C64. Pin 1 is tied to +V in Lee’s ZMC CPU board and it’s N/C for the 28C64 so that covered the ground perfectly. I can program the 28C64 in a separate circuit and put it into the ZMC CPU card knowing that /WE will be held high which is inactive.

I’ve had the idea that I could reprogram the 28C64 without taking it out of the circuit if I hooked up the /WE and wrote some careful code. Hooking up the /WE is easy enough: the A14 trace going to pin 27 is under the chip but easy to identify and it doesn’t go anywhere else.  /WE is available at pin 27 of the RAM chip right next to the eeprom.

The code part is tricky. You can write to the 28C64 like any memory chip BUT after each write, the chip goes into a write cycle and won’t respond to reads for about 10ms. My proof of concept write routine looks like the following:

volatile unsigned char __at(0x1F00) romloc;	//unused rom location

void main(){
	unsigned int i;
	unsigned char romsave=romloc;
	printf("timein %d, romloc contains %x\n",millis(),romsave);
	__asm di __endasm;
	romloc=0xAA;
	for (i=1;i<10000;i++){
	}
	__asm ei __endasm;
	printf("timeout %d,romloc contains %x\n",millis(),romloc);
	while(1);

The routine disables interrupts, changes an unused rom location, and spins 10,000 times through a loop before reenabling interrupts and checking the location.

The first time i tried it i forgot the disable/enable part so the whole thing went byebye when the millisecond interrupt occurred and the Z80 tried to read from the ROM. That, in a nutshell, is the fly in the ointment: if some faulty code tries to write to an address in the ROM, it will not only succeed but it will take the eeprom offline for 10ms – no good will come of that! The eeprom has a software data protection feature where you write a specific sequence of data/addresses to lock it. That would prevent the overwrite but the ROM would still go offline for 10ms after a write attempt. I guess I could live with that but it would be better to have a jumper or something to disable /WE before the eeprom saw it.

I’ve modified the CPU board to connect /WE but I’ll probably leave the eeprom in its adapter socket so i don’t have to worry about overwriting. I had a quick shot at putting the software data protection into the ghetto programmer but you have to do the writes within 150us and my current code is too slow loading shift registers etc. I had it in the older sanguino-based version where I had more direct i/o pins.

I’ve learned a couple of things doing this: I could speed up programming substantially by using the AT28C64’s page mode – even my ghetto programmer could write 32 bytes at a time.  Also, it’s crazy to be rewriting the whole eeprom each time – i could work up some kind of patch control.

 

Advertisements

From → Olduino/Z

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: