Ok so I've been banging my head against this issue now for hours and I've decided to post something here while I continue to bang my head against it, so hopefully someone can ease my pain.

I got an AT 28c256 EEPROM for my first build and I'm working on programming it using an arduino mega. The reason I chose the mega was I did not have shift registers laying around and programming it parallel would greatly reduce the thought needed for hooking it up, also, I happened to have a mega on my desk.

I've got A0-A13 hooked up to pins 2-15 and A14 tied to VCC (I'm only using 16K of this eeprom on the machine, so a14 doesn't matter).

I've got D0-D3 tied to 16-19, D4 on 30 and D5 on 31 and D6-D7 on 22 and 23 (pins 20 and 21 were acting up, I figured maybe because they were for i2c serial, although that makes no sense, I know that they weren't correctly reading or writing though).

OE is 24
WE is 25
CE is 26

I will state, when I first hooked this up I made a pretty stupid mistake and hooked D6 and D7 to VCC directly (they're beside 22 and 23) and OE and WE were probably tied to the D6 and D7 places on the arduino. Also, I had CE tied to ground originally but moved it when I took a closer look at the timing diagram on the data sheet.

The problem I'm having is I can write to a byte, and read it back just fine, but after 5-10 seconds the byte starts losing bits, until it's completely zeroed out.

The process I have for writing is this:

Write OE HIGH (just to make sure)
delay 10 micro seconds
Write A0-A13 lines
Write CE LOW
delay 2 microseconds
Write WE low
Write D0-D7
delay 2 microseconds
Write WE HIGH
delay 1 microsecond
Write CE HIGH

and for read:

Write A0-A13
Write CE LOW
delay 1 microsecond
Write OE LOW
delay 10 microseconds
read data pins and shift into byte result
Write OE and CE HIGH at the same time

some of the timing values are a bit arbitrary, as I've been playing around with them trying to get it to work, I've gone up into the millisecond range on everything trying to figure this out. Also, when I got the chip, I think most values were initialized to 0, I've read that they're supposed to be initialized to FF.


Do I have a bad chip? Or is there something else going on. I've ordered 4 more chips but I'd like to get this taken care of so when the last parts for the computer get here I can have it ready with a NOP generator programmed in.

As a quick aside, I took a scope to OE and WE earlier and they seem to be performing as expected, what is unexpected, is I just took a multimeter to a random data line (D4 I think) and made the program delay 100 seconds during a read to keep the pins high, but this pin never shows high. I also notice, in console when I have it do a set of 500 reads of the same byte, when the multimeter is measuring this bit, it shows as 0 in the read, but when it's not, it shows as 1. Maybe I'm drawing too much power for what this arduino can handle?

My first thought: are you definitely reading the chip, and not just the bus? Can you write two different values and read back the first one?

Most likely a very close review of the timing diagram will help, and a close audit of your code to be sure you're doing as you intended. And re-check the wiring and pinouts, of course!

Ok, some good news, I'm certain it's not the chip and it's either my setup or my programming, I slapped my 32k SRAM chip in there and it has the *exact* same issue.

How in the world is it dropping bits randomly?

So-far, you've designed and built an 65816 board from scratch, never having made anything like it in the past.

You're now writing your own assembler. (In Java, to make it cross platform - admirable)

You're now making your own eeprom programmer.

This is fantastic, really, well done!

However, I do think that at some point, it might be a good idea to stop, think and maybe make life easier for yourself and buy or use something with a proven track record.

as65 (from the cc65 suite) is a good assembler that runs under MS Windows and Linux. It's very well established, works well and I've used it for some time now.

I use a Genius G540 programmer that also works well and was relatively inexpensive.

Others will be using other assemblers and programmers - we all have our favourites and very few have written/build their own, but I'd really suggest you establish a good base-point first. Get something you know will work, something that will give you a bit of a boost to get started then use it to test and build your own.

Good luck...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Sorry didn't notice you when I posted. By reading the chip and not the bus, what exactly do you mean, When I write 2 different values, the value that comes out immediately after is the second value, but it steadily loses bits over a couple seconds.

As for the timing and pinouts, I'm certain at this point the pinout is correct, as I meticulously checked it. Timing, I'm not sure on, which is why I posted my ordering here, it seems to coincide with what the sheet says though.

Thanks, I appreciate that. The reason I'm building everything is for the experience of doing so. The assembler comes naturally, I'm a programmer by trade and I've done similar work before, so I might as well lend my skills to the community, and if it turns out to be garbage, I'll at least learn more about the ins and outs of assembly along the way, and learn some valuable lessons about assemblers themselves.

I fully intend on using a trusted assembler if my assembler fails to assemble code reliably, or if I have issues with it in any way. As far as an eeprom programmer, the ones I saw were pretty expensive, and it seemed like a no brainer to build one with an arduino, since all it is is pushing bits in and out of the chip, I plan on building a shield for it too (although I know it already exists) just for the fun of it.

Ultimately all of this is for the fun of it, and the experience, (and the computer running pacman will be my anniversary gift to my fiance (who now knows about the project, since I couldn't hide it any longer))

So, to get back on topic here, this happens on both the SRAM chip and EEPROM chip now, (which work very similarly, except for the speed at which they run). I should mention this is on a breadboard, with big loopy wires since it's all I have, but I'm not running this very fast at all.

so after reading over this my code isn't quite as robust yet but seems to be functionally the same, this leads me to believe the issue lies in the hardware setup. It could be that certain pins on the arduino are misbehaving, or it could be that the wire setup is total trash. I think I'm going to switch to using only the bottom bar of pins off the mega, and see where that gets me here, I just can't think of how in the world it would be losing bits, WE would have to be toggling, and I didn't see it toggling on my scope (other than when it's supposed to)

I've switched to using only the bottom bar, just like the one in that project I linked in my last post. It has the exact same issue, so at this point I'm starting to think software, I even swapped out some long cables for shorter ones.

Anyone have any other ideas before I dive into code?

I have now set up LEDs on the data bus and on OE, WE, and CE, The databus does exactly what I thought it would do, which is to blip on for the first few reads then lose state. OE, WE, and CE all appear to be working correctly.

Huh, now this is interesting, doing subsequent manual reads to the bytes is no longer zeroeing the entire byte, only parts of it....maybe I'm sampling reads too soon.

EDIT: no, I know this isn't the case because I've added a delay before sampling of 10 seconds before so I could see if it was a time based issue or number of reads issue.

Ok, I'm about to chalk this up to be at least partially bad behavior of the arduino.

During setup, it writes FF to 0x10. It does this 20 times so I can watch the LEDs strobe and make sure it's correct. Presently, a write takes about a second with all the delays I've added in.

I then read 0x10 50 times in setup, each read takes about a second, and I output the result to Serial.

Setup works great, it shows 255 (decimal) as the result for all 50 reads

If I read 0x10 immediately after setup, I get 0

If I write FF to 0x10 and *then* read 0x10, I get FF, all day long, no issue, so it's at least partially fixed.

Something in between it exiting setup and entering the loop is causing it to lose state, but what?

EDIT: I'm an idiot, I was writing to decimal 10 in setup. Reading 0x0A gives me the value set in setup, so it works now, but why does it suddenly work?
I have a theory that the resistors after the LEDs are acting as bus terminators, and helping with signal quality, am I crazy?

Now, reducing delays is starting to cause problems again, but by reducing them one by one, I believe I've cornered the actual issue (on read). It appears it needs substantial time before the arduino is allowed to sample, this may be because it's now driving an LED load on each data line, maybe an extra capacitor will help it when it has to do such a heavy switch? I've got a bunch laying around that were spares from building the computer, so I might as well throw a few more on. Read doesn't necessarily need to be that fast since this is mostly for burning the EEPROMs, but I've set the delay up to 50ms and it still reads incorrectly sometimes, although the LEDs verify that the state coming out of the EEPROM is correct.

EDIT: The extra capacitors seemed to do the trick, I also moved the one that was already on there around a bit to be closer to the VCC pin. Now I may be able to reduce the delays to more reasonable levels

EDIT2: would you look at that, already brought the delay down to 10ms and it's still solid as a rock, goes to show how important proper decoupling capacitance is

EDIT3: (trying to keep from making tons of new posts as I make these micro comments here) It seems getting to full speed read may still be impossible. 100 micro seconds still proves to be unreliable to read the correct value, I'll probably end up around 500 microseconds if I had to guess, but that's still over 3 orders of magnitude slower than what this chip is rated for (150ns). This appears to be entirely signal quality though, and so I urge anyone reading this in the future to really work on their layout and make sure they have decoupling capacitors, so you don't get spooky issues like mine.

I'm not going to /thread quite yet, I'll keep reporting back here as I learn more on this issue, and what the limits appear to be for running on a messy breadboard like this. A shield would no doubt go much faster, and possibly be able to hit max speed.

If you don't have the right timings of the control signals you could see this sort of thing.

Perhaps you could share a diagram of the timing you're aiming for? (Do you have a way to see if you are getting the timing that you're aiming for?)