Skip to main content

EEPROM Programmer Pt.2

I have decided to revisit my earlier plan of making an EEPROM programmer with as few I/O pins required as possible. I have decided to abandon that requirement in favor of making something functionally complete with a minimum of software development required.

I'm using an Arduino Mega as the programming controller, with the sole reason being the large amount of I/O pins available. Rather than reflashing the controller every time an EEPROM needs to be rewritten to hold a new program, I've implemented a method to send the desired program over a serial connection, and program the EEPROM in 128-byte chunks. This is done via the Xmodem protocol, which allows for a pause between packets to allow time for programming 128 bytes at a time, before requesting the next packet.

Due to the variant of EEPROM I have, a 12V level signal needs to be applied to the /OE pin in order to enable a full chip erase. This 12V line will be handled by an opto-coupler, and a momentary pushbutton acting as a 'dead man' switch in series. This is done to prevent accidental erasure for dumping of ROM data, or when programming a device that does not require 12V to erase, such as an NVRAM.

On the software side of things, I've written a function that can detect the size of the device by comparing the first 8 bytes of the device with addresses just past common boundaries (2^n). This technique is imperfect, giving a false reading for devices that are:
  • Erased or filled with a repeating pattern
  • Faulty such that an address line has failed
  • Or somehow contain the same 8-byte sequence as the first 8-bytes on one of these boundaries 
In the first condition, it would be favorable as this function is only used to determine how many packets to send via Xmodem, and you don't really need to send several KBs of the same data multiple times. For the second condition, I may include an option that allows you to perform a raw dump of all 64KB addresses that can be read by the controller, as an emergency measure. The third condition is so improbable (1 in 2^64) so as to be considered inconsequential.

Further on down the line I expect to be able to use the Zephyr computer to program EEPROMs, even for itself.

Comments

Post a Comment

Popular posts from this blog

HP-125 Floppy Drive Emulation

A 'back burner' project I have in mind is to repair an old HP-125 computer I picked up at a thrift shop quite a while ago. This computer has no onboard storage drives, instead coming paired with an HP-82901M floppy drive unit , which communicates over HPIB/GPIB/IEEE-488 (whatever you want to call it). These drives are either pure unobtanium, or are downright bankrupting, so I need to find a way to emulate it. My requirements are as follows: Standalone operation, not requiring another computer to emulate Low cost parts, or using mostly parts I have on hand (Optional) Multiple uses, I don't want this to be a one-trick pony While I've learned how the GPIB protocol works, I have no idea what the command set is that either the HP-125 and/or HP-82901M speaks. I've found mention of the HP-82901M using the Amigo command set, as introduced with the HP-300 "Amigo", on this page about emulating an Amigo-compatible drive with a modern PC . That project requir...
1 comment
Read more

Introduction

This blog is intended to showcase my electronics and computer projects, as well as educating about related concepts. I currently have an ongoing project consisting of an 8-bit computer I call Zephyr (because I'm bad at coming up with names). Details as follow: CPU: Zilog Z80 rated to 10MHz (Currently running at 625KHz) Memory: 8KB of ROM, 32KB of RAM with room for expansion I/O: Serial Currently it doesn't do anything since I need to create an EEPROM programmer, which I plan to make using shift registers and a controller of some variety. I also have plans to create another 8-bit computer project called CosNaut (Again, bad at names) using an RCA 1802 'COSMAC' CPU, though anything else is not set in stone. Will post updates as necessary.
Post a Comment
Read more

Disk Selection

So I've started work on the BIOS-ROM for the Z80-based Zephyr computer in preparation for use with BP-DOS, and I needed to decide between SCSI or IDE for a storage disk. The SCSI disk I have would be ideal on the hardware level, since both commands and data are 8-bit (with hardware generated/checked parity), plus it would make for a nice auditory experience being a full-height 5.25" disk. However, an issue arose when reading through the commands section of the SCSI standard, there are several different bus phases, and the flow path can be quite confusing at times. I'm sure given time it could be done, but I'm interested in getting the Zephyr computer running in a reasonable time frame. Instead, I have opted for using one or two IDE disks, for simplicity of the bus and command-set. Data transfers are done on 16-bit words, so a data read/write takes two input/output cycles from the CPU, and the ordering of which byte of the word will vary between reads and writes. On...
Post a Comment
Read more