tests could be done to fill the entire screen memory with 1's and then scroll around or specifically write to those bad regions to see what happens.

I'm not trusting markings from eBay chips. Not any more. Although this ones look legit. I've read a couple of the microcode ROMs and they check fine after 3 or so months.



I wasn't too keen on the microcode thing either. Yes pixels did change from light to dark (rarely so). See attached, when scrolling the screen with something in it, some dark lines also appear. More on this below.



I made two scrolling subroutines, one that filled the last row with 0s (blank) and the other one with ones (light). I fount that no errors were made when filling the last row with ones. Screen just turned blue, and no dark lines appeared.

----------------------
I tried re-locating the video card on a different address, but it made no difference. Now it is on it's original address.

So here is what I found. Turns out that my LCD, which is connected directly to the data bus, doesn't fully leave its bus in high impedance when inactive, but has some pull-ups always active. This may explain why turning 0s into 1s is more common than turning 1s into 0s.

Also, the data bus is going from the CPU to the memory card and video card, and from the memory card to the LCD, by a not so short ribbon cable, as can be seen on the photo I posted earlier.
Removing the LCD and the ribbon does make mistakes less frequent, even running at the intended 5 V. So I'm doing away with the LCD. It makes no sense to use it having the video card. I've read advice on not running CPU's buses off the board. Even if this is a "slow" computer, and the CPU is three boards already, it may make a difference.

Adding some more ground wires between the CPU and the memory card seems to eliminate errors completely. It seems that the couple ground wires in the IDE cable, pus the power cables on the back are not enough. So I think I'm just going to add some copper tape to the IDE cable and have it connect the grounds of both bays. Shortening the IDE cable is out of question (I've tried...).

All this makes making a SBC with some 65C816's I've got around even more appealing...
Juan

Sounds like a classic case of ground bounce, possibly combined with a mild instance of signal reflection and/or crosstalk. The result is that the write strobe gets briefly activated when it shouldn't be, and that sends whatever happens to be on the data bus at that moment to wherever happens to be on the address bus at that moment.

Indeed. And there is some crosstalk for sure. Running tens of wires close together on a tight space doesn't help much. Signals look reasonably clean on the scope, but there's always the ocasional spike and such. I've also caught a "runt pulse" on the data lines, but happens when no one is actually driving the bus, and adding pull down resistors kills it.
Juan

Pulling the bus up to Vcc may produce better results. Such so-called active termination is used on parallel SCSI buses to dampen reflections on cables that may be several meters in length.

Series resistance is another method that works on uni-directional lines. You'd have to know the characteristic impedance of the line in order to select the proper resistance.

Reflection dampening via Schottky diodes is another possibility, although I've not given that method any testing in my POC units.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Many years ago, while building the M02 TTL CPU, IIRC I had used Fairchild 27C512 EPROMs for the microcode.

The EPROM programmer had asked me about the manufacturer of the EPROMs,
but somehow I had clicked a different manufacturer by accident...
resulting in a different programming algorithm.

After some hours of operation, some of the Bytes in the EPROMs had "flipped".

It would make sense to verify, if the data in the EPROMs is not corrupted _now_.

;---

On the other hand:
No glitches at 4.3V supply, plenty of glitches at >5V.

From the datasheets, propagation delay of 74HC\74HCT chips depends on the supply voltage.
So it also could indicate a timing problem somewhere.

Maybe it would make sense to replace the TTL CPU with a real 6502 chip,
just to see if the problem originates from the CPU or from the peripherals (CRT controller).

;---


This asks for thicker ground wires.

Voltage drop due to "wire resistance versus current" is an interesting topic.
That story, where somebody had tied the 12V fridge in his camper van to the car battery by resorting to bell wire,
and somehow it didn't work.

Termination: try something like 330 or 470 Ohms to +1.3V, but I'm not sure if this really helps.
BTW: LA6500 is a nice and rugged power opamp,
but I'm not sure about the minimum input\output voltage when VEE is tied to GND.

wouldn't a 65C02 be better for testing? due to the much lower power consumption and ability to run it at very slow speeds...

Hmm... right.

First try a 65C02,

Then a 65C02 plus something like a >5W cement resistor between GND and VCC,
for drawing the same current from the power supply like with the TTL CPU.

//Just to see if the problem might be caused by the wiring between the CPU and the power supply...

I was hoping not to get into transmission line stuff just yet... oh well. We'll see. At any rate, I don't think line impedance is constant by any means on any of my lines.



I checked them yesterday. Data is consistent with what I programmed 3 months ago.




That may explain the voltage dependence. I'll take some measurements with the scope to see if timing of the R/W line and such is affected and what not.

The CRT controller seems to have nothing to do with it, I've taken it out and errors persist (I wrote a small program to check)

I don't have any 6502s at hand but what I do have are 65C816s, which is nice as in my design I actually implemented a "Valid address" pin to help with LCD interfacing. Turns out I didn't really need it, but the keyboard interface does use it, so better keep it going.

I'd have to make a new card or wire it up on a breadboard. Also I'd have to take a look at bus timings, especially as the 65C816 outputs its highest address bits on its data bus, that may have to be taken into account.



This is what I'm going to do first, try to improve the grounding between both "bays". I recently added some decently sized wires carrying power and ground to both bays from the power supply. Voltage drop to any point in the computer is now in the single digit mV. This doesn't imply that ground distribution is adequate, of course.

Regarding termination, I have the processor's buses running to both the memory card and the CRT controller. Should I terminate them on both cards or just one? Seems to me that on the memory card (the first one) should be sufficient. Having terminations on both may load the buss excessively. Errors on the CRT controller don't matter much, any glitch would result on artifacts on the screen, but the program would not notice, and they would get corrected when scrolling for example.

Juan

Rather than parallel termination (which loads the bus very heavily), I think series termination might be a better choice. But am I correct in assuming you're using relatively slow chips like HC and HCT series, for example, not AC/ACT? If so, the fairly slow rise & fall times make it questionable whether there's any need to worry about termination at all.

I suspect the comparatively high output impedance of HC/HCT chips means parallel termination is out of the question anyway, as the loading would be excessive. Series termination avoids that, but HC/HCT's output impedance is probably already higher than the ribbon cable's impedance, in which case adding series resistance would worsen rather than improve the match. There's room for experimentation, though.

But instead I'd follow up on what you said about reduced errors with extra ground conductors. Can I suggest you review the assignments on the ribbon cable? Rather than adding more conductors, you might succeed simply by shuffling one or two of the assignments. The best assignments are those that're immediately adjacent to a ground or +5 conductor. Ideally those preferred locations should be occupied by sensitive signals such as the Clock.

I know swapping assignments is non-trivial, but only a small minority would be affected. To me that seems better than adding copper foil, but of course you know the details better than I do.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yes, I'm using HC and HCT . I'll have to do some reading on termination types and its implications. I can add series termination at a latter stage. My construction technique, with sockets and connectors soldered to pin headers on the underside makes it easy to add resistors in between.

I've added the copper foil as can be seen below. Its just a test, I can peel it off anytime. Adding it does make "scrolling errors" disappear.
The IDE cable follows the pinout of a 6502. I've just realized that I have some unused pins: of the 3 NC, I'm using one for the "Valid address", and SO is free too as I'm not implementing it. These are reasonably close to the clock pins, and the R/W line. So I will be wiring those to ground. They won't be side to side, but one conductor apart. R/W line is already right next to VCC.

----

There was other error that became more frequent, the Interrupt disable flag would just remain 1 after exiting the ISR. Probing with the logic analyzer, I found that it changed when it shouldn't. Probing the flag prevented this from happening (My logic analyzer has an input impedance of 100K), but probing it with the scope didn't make a difference. I added thicker power and ground wires to the backplane and problem solved. I also had a couple unused pins on the CPU bus, and I connected one of them to ground too. This way cards have ground connections on both sides.[These two unused pins were reserved should I need to implement the b flag, which is not there, I don't know if I will need it any time soon. Should be able to do it with the remaining one.].

Later, I added a thick ground wire on the perimeter of each of the CPU cards. Not sure if id actually does something, but it doesn't hurt.

Next (and hopefully last) issue is that it randomly resets itself, but only when typing on the keyboard. I thought it was a software issue, but after some measurements I now think it's a hardware thing. Needs further investigation.

Juan

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That link redirects me to this thread. I think you meant this one viewtopic.php?f=4&t=5865&p=76205#p76205.
I'll do some reading on the subject. There are no "intentional" transmission lines in my design. I'll take some scope screenshots of the signals I'm observing.



There is a grid of power and ground wires on each card as well. It's wired with regular wire-wrapping wire, and can be seen on the photo above. I just added that thicker wire on top to see if it helped, maybe the LEDs were causing some voltage drop on GND. It did make a difference on the power rails on the backplane. Voltage drop may be more of an issue there.
Juan

Some updates:
A couple measurements with the logic analyzer confirm that reset happens either after an RTS or an RTI, so its due to errors getting the return address back from the stack. Here are some scope screenshots of the signals that I'm observing. Using the probe's ground lead or the low-inductance-ground-springy-thing (scope probe accessory) makes little difference.

As it can be seen, address lines do have a shorter rise time and that causes ringing and what not. Data lines are better behaved, which is curious, as data lines are driven by a 74HC245, which is supposed to have greater driving capability than the 74HC377 that drives address lines. I don't know if this directly influences errors on reads/writes, but it may very well be.

Using Schottky diode termination seems to work. I don't have enough diodes for all lines, some more are on the way. But maybe I could just add some series resistors on the address lines (CPU side) so together with the bus capacitance they slow down those edges. I've solved crosstalk on slow signals with fast edges that way before.

EDIT: Clarification.

Juan

On the '245 (unlike the '377) the rise/fall time of the outputs will to some extent depend on the rise/fall time of the inputs -- perhaps they, too, are fairly slow. And is the capacitive loading on the 377 comparable to that on the 245?

I'm not sure what you're referring to when you mention the "ground springy thing." Is that the copper foil you applied to the ribbon cable?

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html