Micro programmed 6502-like CPU

[MichaelM]

And to reinforce Dr Jefyll's point:

Dr Jefyll wrote:

Boosting the setting to 6V isn't a solution.

If you inadvertently decide to use heavier wires and forget to adjust your power supply, then you'll run the risk of applying an over-voltage condition to your TTL parts; many of which may have a 5.5V operating maximum.

You also need to think about how much resistance your supply leads have given the voltage drop you measured. Also consider the effect that the resistance and the inductance of those wires will have on the power bus on your boards.

[JuanGg]

There are few things I feel confident about on this project, and power distribution is definitely not one of them. There is not much that can be done regarding power and ground "nets" on each card without mayor surgery. But on the power supply side definitely.
I was planning on putting a 5 V regulator on each "bay", fed from a higher voltage coming from my power supply or a power adapter.
I was postponing it, waiting for a connector, but I think I should get it done sooner than later. Maybe even separate power supplies/dedicated wiring for the video card and the PS/2 keyboard which is power hungry as well.
I also have a 100 uF capacitor across the rails on each card, that should help a bit too.
The leads I'm using at the moment are "not the best" lets put it that way, I'll try to get/make some proper ones soon.
Thanks everyone. I hope this makes a difference.
Juan

[Dr Jefyll]

JuanGg wrote:

The leads I'm using at the moment are "not the best" lets put it that way, I'll try to get/make some proper ones soon.

Do you have more of the same material -- the wire leads, I mean? You could make a significant improvement just by adding more conductors in parallel with what's already there. Make them double or even triple, cutting the resistance by one-half or two-thirds. Sometimes a "quick and dirty" fix is quite acceptable. This could be a temporary measure until you acquire some proper, heavy-gauge wire.

I would hesitate to split the load in two, powered by two separate, local regulators, because your computer could suffer damage if ever the two regulator output voltages differ... as could momentarily happen during powerup, for example, or as the result of a mishap involving an accidental short on one of your boards.

Let me remind you that any short between your 5V logic and the higher voltage at the regulator input will tend to be extremely serious. I've seen various mishaps over the years, and usually they're harmless... but only when they involve just one supply voltage. The risk of damage is MUCH higher if there's another, higher voltage involved. That's why I prefer that the regulator be located somewhere remote, rather than being part of my project.

In light of the above I think your present setup has a lot to be said for it. Just upgrade those leads!

-- Jeff

[JuanGg]

I hadn't thought about the two regulators conflicting. Maybe not now, but in the future I would like to add some sort of dedicated power supply to it, in a separate board, so I can get it out of the lab and such. I would't trust my power supplies much more than a dedicated regulator anyway. I'm using a switch mode lab power supply (noise is aceptable), but using a linear one instead does not change anything.

The leads I was using have a resistance of 2 ohms. I guess they put in the least amount of copper they could get away with.
I've replaced those by the heaviest gauge wire I've got around, connecting both "bays" together and straight to the power supply. Voltage drop is now in the single digit mV to any point in the computer. That makes me feel better, but the problem persists. Same behaviour, errors when reading or writing to RAM. Those get reduced and even disappear when the supply is dropped to 4.3 V or so. I just can't figure out why, if anything, lowering the supply would decrease the noise margin and make matters worse.

Also, I'm observing some more strange behaviour, like random resets ($FF opcode triggers reset on my CPU, so if it fetches instructions from a blank address, it resets itself) and that interrupts get disabled after typing for a while, so it does not react to key presses until reset. All of this could be explained by RAM reading-writing errors.

I really don't know how to go about this one. It could be a loose connection somewhere but wiggling all the cards doesn't make a difference, and it wouldn't explain the voltage-dependence...
Juan

[BigEd]

You mentioned caps at the board level - do you also have bypass caps at the chip level?

[JuanGg]

BigEd wrote:

You mentioned caps at the board level - do you also have bypass caps at the chip level?

I do. One 100 nF cap across the power pins of every IC. See photos earlier in the thread.
Juan

[BigEd]

(Thanks!)

[JuanGg]

I like my threads with photographs. So here is one of the current setup just for the sake of it. Notice the wires joining the two cards and then going to the power supply. I did cut the shortest section of an IDE cable to join the two cards, I could even try to shorten it further by opening it up and re-assembling. But it doesn't seem the cause for the RAM mistakes.
Juan

[JuanGg]

I took all the boards out and reseated all the ics, which made no difference. Running the thing at 4.4 V makes it work flawlessly, and raising VCC to 5.2 V or so makes it behave even more randomly. Also, when running it at 4.4 V, if I remove the power connection to the CPU (still powered by the IDE cable) errors appear again. So it may have to do with power distribution, or that can be a separate issue.
So I don't know if I should wrap the whole thing in copper tape, or just run it at 4.4 V and be done with it.

But the voltage dependence makes me think that maybe the RAM or EEPROMs are failing somehow (they are all eBay specials, clearly used and some even weren't erased.) I don't know. RAM tests fine on my programmer, and EEPROMS were programmed without problems.
Juan

[Dr Jefyll]

JuanGg wrote:

When scrolling (it does so upon pressing the enter key just for testing), some lines, dots and other creatures appear primarily (but not only) at the bottom of the screen and make their way up.

So, primarily at the bottom of the screen. That might be a clue. Or not...

And in the photo you posted it seems the "creatures" sometimes appear in place of the space character but never (or rarely?) in place of other characters such as alphabetic and numeric. Is that a fairly reliable pattern? That, too, could be a clue.

Thanks for posting the photo, by the way! It's nice to look over your shoulder and see what you're up to.

-- Jeff

[JuanGg]

Dr Jefyll wrote:

So, primarily at the bottom of the screen. That might be a clue. Or not...

And in the photo you posted it seems the "creatures" sometimes appear in place of the space character but never (or rarely?) in place of other characters such as alphabetic and numeric. Is that a fairly reliable pattern? That, too, could be a clue.

First thing I thought when I saw it was that I had forgotten the # sign and it was reading from a random address or something. But that wasn't the case, and I've tried copying a single line and it happens too.

This lines appear when scrolling. Before taking the photo above, I scrolled the screen several times and then typed in the text. So lines on those addresses were overwritten. But when scrolling after typing text, those lines do appear on top of characters. As it is a bitmapped display, the computer doesn't care about what's on the screen when scrolling. Also note that when something appears at the screen does't imply that it has been correctly written to system RAM, only to the video RAM (although both should contain the same data).

Pattern is somehow consistent, lines appear on the bottom, with the ocasional dot. Also this lines appear less frequently on any place on the screen and sometimes even disappear before reaching the top. So lines are full byte errors (they do match up with the "grid") and dots single bit errors. The fact that they are more frequent towards the bottom makes me think about some combination of addresses causing trouble or something similar. Also, higher address means more 1s, more lines to pull high and more ground return current. That may have something to do with it. Zero page addresses seem to be doing fine for example. But addresses are setup several cycles before reading or writing takes place.

Here is my memory map just in case:

$0000-$7FFF System RAM, with $7000-$7FFF mirrored in video RAM
$8000-$BFFF IO/Unused
$C000-$FFFF ROM

I'll have to try to get some scope traces of the precise moment mistakes occur. We'll see. Thanks.
Juan

[GARTHWILSON]

JuanGg wrote:

But the voltage dependence makes me think that maybe the RAM or EEPROMs are failing somehow (they are all eBay specials, clearly used and some even weren't erased.) I don't know. RAM tests fine on my programmer, and EEPROMS were programmed without problems.

When I started with PIC microcontrollers, I think the 16F84 might have been the only flash-based one, and the rest were all EPROM-based.  For production-worthy programming, programmers were supposed to program at 5V, then go back and check the whole thing at a higher voltage and a lower voltage, to verify good program margin and good erase margin, to avoid the problems you seem to have run into.  I don't remember if it was the higher or lower voltage that's to verify good erase margin.  Are you sure you've gotten them adequately erased before programming?  I have a Datarase II UV eraser.  Its manual says it erases EPROMs in something like six minutes (I don't remember for sure, and it would take some time and effort to find it); but you're supposed to try it and see how many minutes it seems to take to get your EPROMs to show all FF's (ie, the erased state), and then double that time.  I have to go to 20 minutes, even brand new.

[JuanGg]

GARTHWILSON wrote:

Are you sure you've gotten them adequately erased before programming? .

I am using EEPROMS (at28c64 to be precise), luckily no need to erase them with UV. My programmer does check them after writing. Possible mistakes would occur on the microcode ROMs inside the CPU, if it read instructions incorrectly from the program ROM it would do more strange stuff. But if some control signal changes when it feels like, that's another story. I may take them out and check their contents or test them under different power supplies. They could have been zapped by ESD and partially damaged. I don't know.
Juan

[GARTHWILSON]

JuanGg wrote:

GARTHWILSON wrote:

Are you sure you've gotten them adequately erased before programming?

I am using EEPROMS (at28c64 to be precise), luckily no need to erase them with UV. My programmer does check them after writing.

All programmers check after writing.  In the case of the PICs, you write each word, then read it back, at 5V; but when you're done, you check it all again at a lower voltage, and yet again at a higher voltage.  But if you're using EEPROMs, it might be a different story.  Wikipedia says:

Quote:

During rewrites, the gate oxide in the floating-gate transistors gradually accumulates trapped electrons.  The electric field of the trapped electrons adds to the electrons in the floating gate, lowering the window between threshold voltages for zeros vs ones.  After sufficient number of rewrite cycles, the difference becomes too small to be recognizable, the cell is stuck in programmed state, and endurance failure occurs.  The manufacturers usually specify the maximum number of rewrites being 1 million or more.

If you got used ones on eBay however, they might be from yesteryear when the endurance was a few orders of magnitude less.  One might be able to tell from the date codes, but even then, the Chinese have been harvesting ICs from used boards, cleaning them up, and re-marking them.

[Dr Jefyll]

JuanGg wrote:

Possible mistakes would occur on the microcode ROMs inside the CPU, if it read instructions incorrectly from the program ROM it would do more strange stuff.

It's normal during troubleshooting to have several theories under consideration, and it's best to keep an open mind for new theories, don't be hasty to rule out old ones, and NEVER focus on one theory to the exclusion of all others.

That said, I wonder if we can (cautiously) give more attention to the apparent data dependence. In the photo it seems all the erroneous pixels have changed from dark to light -- I see no cases of a pixel changing from light to dark. (Yes I realize light pixels are comparatively rare to begin with, but even so...) Also there are the patterns mentioned in my previous post. These don't disprove the "bad microcode" theory, but they do weaken the case, I'd say.

-- Jeff