Okie Dokey Smokey, any ideas? (Burning EEPROMS)

[Tursi]

You might just be moving too fast... at least it's hard to follow the posts in this thread.

 

Slow down, take your time.... there's no magic involved, but there IS some uncertainty. You can never be sure that a burn is perfect until you read it back and verify it. Here's some background information that may help.

 

An erased EPROM has every address set to 0xFF -- erasing an EPROM actually charges up the gates and sets every bit to 1. Programming an EPROM drains the charge from the relevant bits, turning it into a 0. Thus, you can always turn a 1 into a 0, but to turn a 0 back into a 1 requires an erase process.

 

The way that the charge is drained is by applying a high voltage to the bit, which breaks down the insulator which is protecting the charge, and allows it to drain off. This usually takes multiple pulses, which the programmer software is meant to handle for you. The exact timing and required voltage is different for every type of chip.

 

Make sure your hardware setup is correct. If it's a USB powered device, it may work fine for smaller parts and for parts that can program on 12v, but you may need a power supply for other parts. There's no way to know in advance, except maybe experience. If you have a power supply, you probably want to use it until you've learned whether you need to.

 

On the software side, the first thing you need to do is select the right chip and right MANUFACTURER of that chip in the device selection. If you can't find an exact match, you can try a different manufacturer of the same chip. It might work, or it might take a few tries to program, just be aware.

 

Next you need to load your data - you are loading BINARY data and you need to use the offset of 0, until you know better that should always be the case. I think you figured that out already. Using 0xFF as the fill value is the best, because locations that are programmed as 0xFF don't need any write time - it's faster and causes less wear if you're going to keep reusing the chip. If you erase with 0x00 then every location you aren't using still needs to be fully written to all zeros.

 

Now install the chip into the programmer -- and make sure it is aligned correctly. Most programmers have more pins than most of the chips you'll be programming. With my Chinese programmer, the docs weren't good enough for me to be sure, so once I got it right I used a sharpie to mark the actual programmer. Also make sure pin 1 is in the right direction.

 

Do a blank check - you always want to do this. If it's not blank, either you have it installed incorrectly, or it's not blank. Check the mounting, make sure the pins are not corroded and making poor contact, and replace it if needed.

 

If all looks good, hit program and let it finish.

 

If it doesn't automatically verify, then you need to verify. You can't ever guarantee a write. If the write failed, all is not necessarily lost. Usually the programmer will tell you what byte was read and what was expected. If it's just a case where some bits didn't make it to 0 (ie: it wanted to see 0x55 but saw a 0x5F, you can see two bits didn't get drained)... then you can just hit program again. A '1' can always become a '0', and sometimes it just takes two program cycles. If it went too far (ie: a bit became '0' that should have been '1'), then it could be a fluke, it could be bad connection or misaligned chip, or it could be a bad chip. All you can do is erase that chip and try again later (assuming it's installed right). Mark it so you know if it's continuously bad.

 

If it verifies good, you should be done!!

 

HTH.

[Omega-TI]

I'm not sure if my cheap socket is part of the problem, so I purchased a better one that was recommended to me. I doubt my new one could have possibly gone bad after so few insertions and extractions, but I'll be needing it 'down the road' anyway.

 

It would be nice to have more than two images to test with though. We still need that 'sticky thread' idea for images.

[+Schmitzi]

At least, I´ve heard about this problems....

 

here´s some info what I am going to buy:

 

 

PLCC32 to DIP32 PLCC 1.27Pitch IC Socket Program Programmer Programming Adapter

http://www.ebay.de/itm/251065943194

 

Features
High quality and durable
Tested before shipping
Easy to use
Package PLCC32
Pitch: 1.27mm
Socket PN
IC51-0324-453
Pin Header Dimensions
Pitch: 100mil (2.54mm)
Width: 600mil (1.52cm)

 

 

 

RMSAAED

[+Lee Stewart]

I'm not sure if my cheap socket is part of the problem, so I purchased a better one that was recommended to me. I doubt my new one could have possibly gone bad after so few insertions and extractions, but I'll be needing 'down the road' anyway.

 

It would be nice to have more than two images to test with though. We still need that 'sticky thread' idea for images.

 

 

Though the bank order may need to be inverted, you can use the binary in the ZIP file under “Classic99 & Real Iron” in fbForth—TI Forth with File-based Block I/O . I believe that is the version you have in your fbForth 2.0 cartridge. I will probably post build #3 sometime before the Faire, i.e., within the next couple of weeks. It must load starting in bank 0, i.e., burn with starting address = 0000. I mentioned that the bank order may need to be inverted because I believe the board you are using uses non-inverted latching. In that case, you will need to invert the bank order in the BIN file. I can do that for you, but it's easy enough to do. Just use a hex editor to copy each of the four 8KiB chunks to another file in reverse order. @Ksarul will tell us for sure about the latching.

 

...lee

[Omega-TI]

Thanks Lee,

That is a little... at the moment.

 

I've only been able to make one successful burn and that was for a single image... until I can figure out what my problem is with inconsistent burns, I'm afraid I'm a ways away from multiple images and banks, let alone inverting!

[+Schmitzi]

...yes, we need an inverting-Thread

 

 

 

 

RMSAAED

[TheMole]

Thanks Lee,

That is a little... at the moment.

 

I've only been able to make one successful burn and that was for a single image... until I can figure out what my problem is with inconsistent burns, I'm afraid I'm a ways away from multiple images and banks, let alone inverting!

 

I definitely get that it can be a bit daunting, but the ROM-only images are actually fairly straightforward, you only have two types (inverted and non-inverted) and a bunch of different sizes (multiples of 8k). You can write any ROM-only image in exactly the same way, once you've verified the type, and it's really easy (although a bit cumbersome) to manually convert any ROM image from one type to another.

 

For the Ubergrom board you have, you will always need a non-inverted (also called '378' style) image. For the older and smaller boards, you need the inverted (or '379' style) images.

 

To convert from one to the other (doesn't matter from which to which) all you need to do is open the file in a hex editor (many free hex editors can easily be found on the internet), count the number of 8k blocks in the file (this is just the file size in kilobytes divided by eight ) and for each 8k block (aka bank) cut the last 8192 bytes (or 8 * 1024 = 8k bytes) from the end of the file and append it to another (initially blank, newly created) file. Once the first file is empty, the second file will be the inverted version of the first.

 

Admittedly, inverting the Alex Kidd image (which is 64 banks large) like this would a royal pain in the ass, but I believe all larger images will already be in non-inverted format since only the non-inverted boards support the larger sizes. I believe turboForth is 4 or 8 banks, so it's definitely more manageable.

 

Now, none of that explains why you needed to try 20 times before you had a successful burn with an image that was already in the right format, which is an entirely different story where I'm afraid I can't be of much help...

Edited October 14, 2015 by TheMole

[+InsaneMultitasker]

 

Though the bank order may need to be inverted, you can use the binary in the ZIP file under “Classic99 & Real Iron” in fbForth—TI Forth with File-based Block I/O . I believe that is the version you have in your fbForth 2.0 cartridge. I will probably post build #3 sometime before the Faire, i.e., within the next couple of weeks. It must load starting in bank 0, i.e., burn with starting address = 0000. I mentioned that the bank order may need to be inverted because I believe the board you are using uses non-inverted latching. In that case, you will need to invert the bank order in the BIN file. I can do that for you, but it's easy enough to do. Just use a hex editor to copy each of the four 8KiB chunks to another file in reverse order. @Ksarul will tell us for sure about the latching.

 

...lee

 

Back when Gazoo was playing with the various images, I wrote a small Geneve-only program for him that read the image, inverted the banks, and wrote the new image to disk. A small Java or C utility to do the same might be helpful, if someone has the time to create it.

[Omega-TI]

I'm beginning to wonder if I have a bad gate in the programmer. I've filled the buffer with FF's after 6 or 7 erase pulse cycles and can get it to program correctly 1/4 of the time. When I use the same erase procedure and try a write an image, I get errors... but not always in the same place.

[RickyDean]

 

Back when Gazoo was playing with the various images, I wrote a small Geneve-only program for him that read the image, inverted the banks, and wrote the new image to disk. A small Java or C utility to do the same might be helpful, if someone has the time to create it.

Once I wrap my head around the principles here, I can probably write a C# program to do it.

[Asmusr]

 

Back when Gazoo was playing with the various images, I wrote a small Geneve-only program for him that read the image, inverted the banks, and wrote the new image to disk. A small Java or C utility to do the same might be helpful, if someone has the time to create it.

 

This is a Java program I wrote a while ago.

 

 

 

import javax.swing.*;
import javax.swing.filechooser.FileNameExtensionFilter;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.Stack;

/**
 * Created with IntelliJ IDEA.
 * User: Rasmus
 * Date: 04-04-14
 * Time: 17:45
 */
public class Main {

    public static void main(String[] args) {
        JFileChooser fileChooser = new JFileChooser();
        fileChooser.setFileFilter(new FileNameExtensionFilter("ROM Images", "bin", "rom", "c", "d"));
        if (fileChooser.showOpenDialog(null) == JFileChooser.APPROVE_OPTION) {
            File file = fileChooser.getSelectedFile();
            try {
                FileInputStream fileInputStream = new FileInputStream(file);
                Stack<byte[]> banks = new Stack<byte[]>();
                boolean done = false;
                while (!done) {
                    byte[] bank = new byte[8192];
                    int bytesRead = fileInputStream.read(bank);
                    if (bytesRead == 8192) {
                        banks.push(bank);
                    }
                    else if (bytesRead == -1) {
                        done = true;
                    }
                    else {
                        throw new Exception("File size must be a multiple of 8192 bytes.");
                    }
                }
                if (banks.size() > 1) {
                    fileInputStream.close();
                    if (fileChooser.showSaveDialog(null) == JFileChooser.APPROVE_OPTION) {
                        file = fileChooser.getSelectedFile();
                        FileOutputStream fileOutputStream = new FileOutputStream(file);
                        while (!banks.empty()) {
                            byte[] bank = banks.pop();
                            fileOutputStream.write(bank);
                        }
                        fileOutputStream.close();
                    }
                }
                else if (banks.size() == 1) {
                    throw new Exception("Only one bank found - cannot invert.");
                }
                else {
                    throw new Exception("File is empty - cannot invert.");
                }
            } catch (Exception e) {
                e.printStackTrace();
                JOptionPane.showMessageDialog(null, e.getMessage(), "Error", JOptionPane.ERROR_MESSAGE);
            }
        }
    }
}

 

 

bankinvert.zip

[RickyDean]

 

This is a Java program I wrote a while ago.

 

 

 

import javax.swing.*;
import javax.swing.filechooser.FileNameExtensionFilter;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.Stack;

/**
 * Created with IntelliJ IDEA.
 * User: Rasmus
 * Date: 04-04-14
 * Time: 17:45
 */
public class Main {

    public static void main(String[] args) {
        JFileChooser fileChooser = new JFileChooser();
        fileChooser.setFileFilter(new FileNameExtensionFilter("ROM Images", "bin", "rom", "c", "d"));
        if (fileChooser.showOpenDialog(null) == JFileChooser.APPROVE_OPTION) {
            File file = fileChooser.getSelectedFile();
            try {
                FileInputStream fileInputStream = new FileInputStream(file);
                Stack<byte[]> banks = new Stack<byte[]>();
                boolean done = false;
                while (!done) {
                    byte[] bank = new byte[8192];
                    int bytesRead = fileInputStream.read(bank);
                    if (bytesRead == 8192) {
                        banks.push(bank);
                    }
                    else if (bytesRead == -1) {
                        done = true;
                    }
                    else {
                        throw new Exception("File size must be a multiple of 8192 bytes.");
                    }
                }
                if (banks.size() > 1) {
                    fileInputStream.close();
                    if (fileChooser.showSaveDialog(null) == JFileChooser.APPROVE_OPTION) {
                        file = fileChooser.getSelectedFile();
                        FileOutputStream fileOutputStream = new FileOutputStream(file);
                        while (!banks.empty()) {
                            byte[] bank = banks.pop();
                            fileOutputStream.write(bank);
                        }
                        fileOutputStream.close();
                    }
                }
                else if (banks.size() == 1) {
                    throw new Exception("Only one bank found - cannot invert.");
                }
                else {
                    throw new Exception("File is empty - cannot invert.");
                }
            } catch (Exception e) {
                e.printStackTrace();
                JOptionPane.showMessageDialog(null, e.getMessage(), "Error", JOptionPane.ERROR_MESSAGE);
            }
        }
    }
}

 

 

Looks good, better than what I probably would have done in C#.

[Asmusr]

If anyone has chips to burn, why not burn a hat?

hat8.bin

[Omega-TI]

This burner is weird, after sitting for about 6-8 hours I was able to burn another image on the first attempt. It's a pretty easy and straight forward procedure. I cannot figure out what it's issue is. Anyway, here is #2!

 

Lot's of goodies on here Tursi! I even managed to get 48,000+ in Defender.

 

 

 

Soooooo, anybody got any other "Killer Image" I need?

[+acadiel]

:-)

[Shift838]

i really think there should be a folder on our FTP that someone can submit binary images to for all of us to snag. I could put one in my folder, but everyone would have to send me the binaries to upload.

 

I am fine with doing that, this way we can have a one stop shop for cartridge images for the 512k, UberGrom, etc. carts..

 

Thoughts?

[Tursi]

I'm beginning to wonder if I have a bad gate in the programmer. I've filled the buffer with FF's after 6 or 7 erase pulse cycles and can get it to program correctly 1/4 of the time. When I use the same erase procedure and try a write an image, I get errors... but not always in the same place.

 

I would ask again about your power supply. My programmer is unreliable on some EPROMs without external power, but works fine on others with just the USB. Do you have external power on yours?

 

I'd also ask, what do you mean by "erase pulse cycles"? Are you programming EPROMs (with the little window on the top)? If so, these can only be erased by exposure to strong ultraviolet light.

[+Ksarul]

The eprom burner is erasing the 49F040 flash chips as the first step of the burn cycle. A problem several people have encountered in the past with these is that the 49F040 chips do NOT like to be programmed in a cheap socket. They fail much more often than not--and once moved to the high quality sockets Omega and Schmitzi linked to, the same chips that were giving problems worked flawlessly.

 

That said, it is also highly possible that you have a very unstable power supply Omega. I say that because it seems to work nicely when it has been off for a while, and that the longer you have it on, the flakier it gets. Check all of the connections between the power supply and the eprom burner--and the cabling to the PC as well.

[Omega-TI]

While I'm still waiting for my good quality socket to arrive, I'm using the solution in the video below... hey, it works!

I'm getting 100% results now.

 

https://www.youtube.com/watch?v=UzuzRKVP4wE

[RickyDean]

While I'm still waiting for my good quality socket to arrive, I'm using the solution in the video below... hey, it works!

I'm getting 100% results now.

 

https://www.youtube.com/watch?v=UzuzRKVP4wE

I see why it is helping as you are making sure there is good contact, but why not use some emery cloth or very fine sandpaper to accomplish the same thing doing it on a flat surface. That way your fingers are more protected and less likely to damage the item you are working on. Don't mean to be critical, but I am a 10 year machinist and 30 yr mechanic as part of my experience and safety(especially to newcomers into the tech field, such as kids) should be stressed to every one. But glad it worked for you.

[Omega-TI]

.., but why not use some emery cloth or very fine sandpaper to accomplish the same thing doing it on a flat surface.

 

You're right, that WOULD be a better way to do it, but the Dremel was right there next to me and already and setup. I didn't feel like driving into town, so I just made do with what was on-hand.