Video issues

There have been several threads on Applefritter on how to debug the video section, the trick is to find them ;-)

They all work by pulling an IC in the video data path and then "inject" a low or high signal in a pin of the now empty socket.

The "tool" to do this is a wire with a microhook at one end (to connect to GND - low - or VCC -  high, +5V). The prevent possible damage from slipping / wrong connection, use a serial 220 Ohm (or so) resistor on the other end of the wire which also serves as the "probe tip" and the "handle" to grab it.

Start at the end of the video data path, testing the 74166 shift register. To access its inputs, pull the 2513 character generator from its socket.

Now you can access the relevant 74166 inputs, and by observing what happens on the screen you can check the 74166. You would get thin vertical stripes depending on which input is touched to a "low" logic level.  Open TTL inputs count as logic "high".

Once you know the 74166 works, replace the 2513 and pull the 2519. Now, inject your test signal at the 2519 output pins, but as these have pull down resistors to -12V, you need to inject a logic "high" - connect the microhook to +5V. Same would apply to inject signals at the output of an empty 1404/2504 shift register socket ... these have pulldowns to -5V.

With this method you can check which signal in the video pipeline disappears where. And this points to the bad IC (the culprit).

Note that all too many 2519N of Y1977 and Y1978 date codes are bad and if they fail they typically show a screen full of '@'.

About 1/3 of those I had failed in burn-in. I later found a lot of 2519B with a Y1976 date code (yeah !) which were much better, less than 1% failure rate. So my conjecture is that somewhere in Y1977 there may have been a problem in the Signetics wafer fab which was not fully resolved, and sodium ion contamination (i.e. from human sweat soaked skin flakes shedded by the operators) is the most likely culprit. The sneaky feature of sodium ion contamination is that these ICs having "mobile ions" may initially work, and pass wafer sort and end test, and then fail in the field, after a few hours or days of operation. Back in the 1970s this was a huuuge issue in the semiconductor industry wordwide, affecting all MOS processes. Intel was a pioneer to analyze the root cause and this led to the famous "bunny suit people".

The 1404/2504 are the next common offender, but in this case, you would see properly formed characters, but the wrong ones.

Using one of my Apple-1 IC kits with 100% tested and burned-in ICs can save builders these troubles, provided that the solder job is done well, and use of good IC sockets (the "vintage" flat profile TI sockets seen in the original are NOT reliable, they were unreliable even when new, 50 years ago, and they did not improve over time sitting in some warehouse shelf for decades).

Alas, my Apple-1 IC kits are sold out, and the burn-in rigs were dismantled when my IC stock ran out years ago. But a few of the "critical" ICs were rediscovered recently, in a very small quantity, so I can still make a kit occasionally, using one of my regular Apple-1 builds as a burn-in platform. (Send a PM if you want such a kit, but sorry, no shipping to the EU due to their recent, fascistic, evil customs office crackdown on non-RoHS electronic components, even when sent as a private parcel from hobbyist to hobbist).

- Uncle Bernie

In post #3, 'kalinchuk' wrote:

" I'm using AM2804 instead of 2504 - maybe that's the issue? "

Uncle Bernie comments:

Most of my IC kits came with AM2804, and these never caused any problem, also, very few failed in burn-in. Very good quality as usual for AMD !

But be aware that *NONE* of the usual 1kx1 dynamic shift registers works in an Apple-1 based on 74LSxxx ICs. The only exception I found was MM1404 made by National Semiconductors, these work fine in my "LSTTL" only Apple-1 example. The MM1404 however had a disastrous failure rate of more then 50% right out of the tube. Very few failed in burn-in, though. (Just as a sidenote, a LSTTL Apple-1 draws about 1A from the +5V rail, while  a TTL once draws about 1.5 A. So it's barely worth doing.)

I think you should pull these AM2804 and then "tickle" their outputs in the sockets. You should get a very consistent pattern of the same characters on the screen, depending on the 6 bit binary code you produce by injecting logic 1's.

But it also seems, from your description, that your Apple-1 may have a thermal error. Cold spray sparingly applied to individual ICs in the video section can greatly help with that. Note that some thermal errors are bad solder joints, or bad socket contacts, and not necessarily a bad IC.

Also beware of the DS0025. Most you can buy are Chinese counterfeits, which is possible only because the "footprint" of the original DS0025 was adopted by lots of so-called "MOS Gate Drivers" which are ubiquitous. Alas, these MOS Gate Drivers are made in CMOS technologies and these switch too fiercly for the weak Apple-1 power and ground grid (a layout issue). This can be mitigated by adding 75 Ohm...100 Ohm series resistors on the two output pins driving PHI3 and PHI4.

I would not try to buy yet another IC set (costly), instead, try to find out which IC causes the problem.

- Uncle Bernie

In post #5, 'kalinchuk' wrote:

" Regarding the cold spraying, I don't think any of those ICs are hot to the touch. "

Uncle Bernie comments:

You have a misconception about the use of cold spray. It is not meant to cool ICs because they are running hot. It is meant to reveal the location of thermal errors / faults. Most semiconductors have drastic changes in their electrical performance, i.e. propagation delays or logic thresholds of digital logic, when they warm up above room temperature. This may lead to system failure. The typical symptom is that the circuit runs fine just after power up, and once it warms up, failures start to manifest. Now, by squirting a small amount of cold spray on suspect ICs you can reverse this and the circuit will work properly again, until the bad IC warms up again, which may take a 10 seconds or a minute or so, depending on how much power it consumes. This is a nearly bulletproof way to find thermal errors. Back in  the day, every TV repairman was toting a bottle of cold spray to hunt for bad transistors and bad ICs.

C13 (the 74175) if pulled shuts down all clocks in the system, so of course most of the spikes are gone. The Apple-1 has very poor VCC and GND trace layout (typical for the early 1970s, this layout mistake was common, and I suspect that it was based on the availability of these self adhesive trace spools, the wider ones were rare, so the layouters who glued them to the mylar foil tended to make the VCC/GND traces too narrow. Frankly, I committed the same "crime" against innocent electrons when I glued my own layouts back then. Because PCB layouters would typically work with 2:1 reduction so everything was twice as large on the layout as as on the final PCB, and it looked good on the mylar, and turned out narrow and weak on the PCB.)

A 1.2V spike on GND can definitely wreak havoc and flip flipflops erratically. 

I'd recommend you to pull the DS0025 and wire its empty socket pins 5 and 7 to +5V, (you may also plug in resistors to make this connection) so the PHI3 and PHI4 clock phases are deasserted, and nothing bad can happen. You still should be able to get characters and manipulate them if you pull the 2519, too. If the weird behavior of your build is gone after that, I'd suspect the "DS0025" is a counterfeit.

This is based on my experience with various non-DS0025, such as Chinese counterfeits based on modern CMOS "MOS Gate Drivers" and with the DS0026. The DS0026 is a slightly faster version of the DS0025 and it caused erratic behaviour in my first Apple-1 build (I had no DS0025 at the time). The modern CMOS "MOS Gate Drivers" the Chinese counterfeiters relabel as DS0025 will cause the Apple-1 to completely go nuts.

The DS0026 will work in the Apple-1 when my "Reliability Mods" are applied - these have been documented here on Applefritter. Essentially, adding more power supply bypass capacitors.

CMOS "MOS Gate Drivers" in the DS0025 socket will hit the Apple-1 too harshly and even the "Reliability Mods" will not help.

Yet another issue with these CMOS "MOS Gate Drivers" is that some lack the pull down resistors on their inputs. You can measure the suspect "DS0025" input pins #2 and #4 to the -12V rail (pin #3) and in a real DS0025 there should be a resistor there of nominal 250 Ohms (allow for +/-50% tolerance). If that resistor is not there, you have a counterfeit DS0025. If it is there but much larger (nominal 10 kOhms) you have a DS0026.

In case you happen to have a counterfeit IC lacking these resistors, you can put in 1k Ohm pulldowns, I did use 0805 form factor SMD resistors which fit just between the solder blobs on the PCB solder side. But you will also need series resistor of ~75 Ohms at the outputs of these fierce CMOS drivers, otherwise they also crash the system by hammering it too badly. Alas, not all CMOS "MOS Gate Drivers" are specified for the 17V supply voltage they "see" in the Apple-1. But most are specified for 12V in automotive environments and they won't blow up at 17V (although the manufacturer does not guarantee them for this form of abuse).

So far for the suspicion it might be a counterfeit DS0025. If you can measure and find the 250 Ohm resistor on its inputs, it's probably genuine. Then the problem must be rooted elsewhere. It could be a bad TTL, too. But with none of the many, many IC kits I made I ever saw the peculiar behavior you describe.

- Uncle Bernie 

In post #8, 'kalinchuck' wrote:

" After pulling out the 7427 and setting DS0025 pins 5 and 7 to HIGH, I got a screen of flashing @ symbols. It seems like progress ..."

Uncle Bernie comments:

What the removal of the DS0025 does (yours seems genuine, no known CMOS based "MOS Gate Driver" has 250 Ohm pulldowns in the inputs)  is that the 1404 shift registers making the video memory are disabled (they get no clocks PHI3, PHI4 anymore, but these must be hooked to +5V to prevent damage to the 1404/2504/2804).

So what you should see on the screen is these flashing '@' but watch out, it must be  40 characters per line and 24 such lines, no more, no less ! And this should stay so even after warm up. No extra characters appearing, no instability (no screen jumps, no line wiggling, no characters getting deformed ...)

If so, you made some progress because now you know the whole video timing / counter chain works properly. What is left as possible culprits for erratic behaviour is the scrolling logic and the cursor state machine (the seperate small schematic in region A-B 1-3 of the "Terminal Section" sheet).

If there is any problem with any of that, then weird things can happen on screen once the video memory is functional (DS0025 inserted): characters may appear outside of the regular 40x24 character field and the picture may "jump" or scroll erratically. The latter is due to some logic which tries to 'eliminate' bogus cursors outside the regular 40x24 field. So  any issue with the cursor source (C11b and part of C13) or the cursor state machine itself can lead to wild behaviour.

You may try to put the DS0025 back (don't forget to remove the PHI3, PHI4 hookups to +5V) and pull shift register C11b (sits below the DS0025 in the same socket) and then see what happens:

- after power up after a longer pause (1 minute or so) you should get a _@_@_@_@_ pattern with the '@' blinking. The long pause is meant to "clear" residual charges from the shift registers. Note that the occasional different character may appear even after a prolonged power off period. These are the (few) exceptions of shift register cells which "wake up" at the other state. No concern here unless that bit is stuck forever.

- activating the CLR SCREEN switch should blank the screen, and you should see a faint dot pattern in the background, one tiny dot per character position. This is known crosstalk due to poor layout. But it helps to see issues with the video timing. There should be four such dots per line outside the regular 24 lines, the rightmost (last) dot aligned with all the other last dots on the regular lines. These four extra dots per line are the locations (in time) where the DRAM refresh cycles happen.

- releasing the CLR SCREEN switch should produce all '@', blinking, in the regular 40x24 character field, the outside of which must stay blank (except for the faint crosstalk dots mentioned above).

If you get there, you could put C11b back and then focus on which possible TTL in the cursor state machine may be the culprit. Try grounding pin #4 of the 74174@C7 first. It is floating and might pick up erratic signals. This is one reason why in my "Tips & Tricks" pdf for Apple-1 builders I recommend to do the tests with all ICs inserted. The partial test with only the "terminal section" IC sockets populated (as suggested in Mike Willegals Apple-1 building instructions) did cause more erratic behaviour and confusion for many builders than it was worth in terms of "protecting" ICs for the "CPU Section" from damage, which is my conjecture why Mike recommended this method.

But if the very first power up is done with all IC sockets empty and if all regulated voltages are measured and verified to be in spec, there is no such danger for any ICs to get damaged.

- Uncle Bernie

In post #11, 'kalinchuk' wrote:

" .... then connect the scope ground to the ground plane (near the heat sink) and the other end to pin 7 of 7410, this is what the signal looks like (blue) on the scope ..."

Uncle Bernie comments:

This way to measure noise on power or ground rails is meaningless. Also, the Apple-1 has no "ground plane". You can only have a "ground plane" when a whole layer of the PCB is devoted to be that "plane", and you can't do this with a dense digital circuit on a two layer PCB.

The sad truth is that all these thin long VCC and GND traces are inductors of substantial, noticable inductance, and with TTLs turning currents off and on in about  one to two nanoseconds (rise and fall time, not to be confused with propagation delays) these inductors essentially behave as open circuits. Which means the supply voltages seen by the TTLs at their VCC pins will collapse, and the GND will bounce up. Everything moves and bounces. There is no "solid ground" anywhere on this motherboard. So don't try to do such oscilloscope measurements . . . they are meaningless.

The power supply bypass capacitors sprinkled all over the PCB will provide local power and ground to the adjacent ICs and mitigate the bouncing.

This is why these digital circuits work at all.

Where it gets dubious is when one signal coming from one IC in the PCB goes to another IC far away and the "grounds" do not agree. This can lead to lots of problems if a bouncing ground kicks a signal across the logic threshold of the receiving IC. If it is a clock, weird things can happen.

But I don't think this is causing the issues you see, assuming:

a) you have used good bypass capacitors of reasonable performance

b) you have used Standard TTL (74xxx) and not some faster logic families such as HC, HCT, A, F, ACT, FCT etc.

Several 100's of Apple-1 have been built and despite the signals generally look horrible on an oscilloscope, they work.

If you don't trust your bypass capacitors, you can always add more (see my "Reliability Mods" published here on Applefritter).

If you have low performance bypass capacitors this might bring remedy, but I think (from looking at your screen shots) you just have some bad TTL IC or some short or open or bad solder joint somewhere.

You can try to remove the 5V regulator and run the Apple-1 with a laboratory power supply at less than 5V. I have had some cases which did not work all too well at 5V, but worked fine at 4.5V or slightly below that. Mix and match of the TTLs helped to remedy these cases.

But make no mistake - when I produced my kits I used to change ICs row by row to "harvest" the burned-in ICs and get a new set in for the next  4 weeks of burn-in. After changing one row I powered up the Apple-1 to see if it still works. Often, it didn't work anymore, and despite I knew that only one (or more) ICs in the most recently changed row could be the culprit(s), there were some really mind boggling cases where even I could not easily find out which one would be the most likely candidate, based on the symptoms seen on the screen. In these cases I just decided to change all ICs in that row again. This was more efficient in terms of time invested than pondering over the schematics.

Your whole case shows how helpful a 100% tested and burned-in IC set can be for Apple-1 builders. But don't despair, I think if you look long enough and think and experiment a bit, you will eventually arrive at a functional Apple-1. But I don't think this "maverick" building approach based on unproven ICs saves any time or money. Even if you agree to take "minimum wage equivalents" (here in the USA typically $20/h, but be aware nobody can make a living from that) you might have "spent" less time = money buying a completely assembled and tested Apple-1 replica from one of the usual sources. (For me this is the "acid test" to check if some journey in electronics wonderland is worth it . . . imagine the "buy" alternative costs $ X and the "DIY" alternative costs Y hours. If Y times $20 is > X, then the "buy" makes more sense unless the learning experience is what is wanted. Of course, for the $20, you may substitute whatever you can earn per hour, after taxes,  in your bread job, but $20 is the absolute minimum).

On the other hand, some people actually enjoy to solve these electronic riddles and do it to gain "debugging" experience. Not bad either. But it may take a lot more time (and money) than initially expected to get to the desired result / "victory".

- Uncle Bernie

This is probably irrelevant to your problem, but just after turning on my Apple-1 reproduction with all ICs populated for the first time, I had an issue with the cursor not blinking, and other weird display issues. I troubleshot it down to a dead electrolytic capacitor next to the 555. On the oscilloscope the signal was oscillating at more than 200 KHz! In any case, I swapped the 555, no result. Then I removed the 555 and measured, in-circuit (safe as the 555 was removed) the 2 associated resistors and the capacitor, and found that the capacitor was absolutely dead. Replacing it fixed my issue.

Again I realize that this is probably not relevant to your case, but I thought I would share it anyway. I found it interesting that the non-working cursor signal was causing more trouble than just the cursor not blinking.

In post #15, 'kalinchuk' wrote:

" The weird thing is that, when I run the IC through a tester, it says that its okay. I'm not sure what to make of it."

" Now, when I clear the screen, I get one blinking @. Is that correct or is this still an issue ?"

In post #16, 'kalinchuk' wrote:

" After the reset, the screen displayed a list of random characters and then started srolling with what looks like gibberish. Any ideas what could be causing this ?"

Uncle Bernie comments:

A) Your IC "Tester": it's a cheap toy which may be OK to find really dead ICs or ones with a stuck-at-0 or stuck-at-1 input or output. Do not expect that it could find parametric errors. Testers who can do full tests are too expensive for hobbyists (a Teradyne "Eagle" costs > $1 Million).

B) If after a clear screen a single, blinking '@' is in the upper left corner of the character field, and everything else is blank, your "Terminal Section" does what it should do in this case. But the "Processor Section" did not send any characters to it - yet. This should happen after a RESET.

C) In your screenshot I recognize my "Diagnostics Page" which is running (most of my IC kits came with 512x4 PROMs, and the first 256 Byte page was the Wozmon, and the second 256 Byte page was the "Diagnostics Page" I wrote for builders using my IC kits (Wonder how you got it --- I'm only aware of a EPROM based PROM replacement plug-in which has my diagnostics page with my permission, and this card normally comes from Russia ... hmmmm, but no offense. I'm glad when my tools help Apple-1 builders).

D) The "gibberish" you see is a Terminal Section test which is supposed to fill the whole screen with a slanted field of all the characters the Apple-1 has. It also tests the DRAM memory. Your DRAM memory did not work at all, so you got these particular error messages.

But as we know from your post #17, your Apple-1 works now !

Congratulations ! You have proven that with persistence, even "Maverick" Apple-1 builds can succeed !

Every Apple-1 being built successfully is an improvement to this world, although only a very small one. There are only about 1000 people from 8-9 billion people living on the planet who care about Apple-1. This small "fan scene", BTW, also is the reason why making Apple-1 kits (or IC kits) is not really a viable commercial business. It can only be a hobby.

- Uncle Bernie

In post #19, "kalinchuk" asked:

" How is the diagnostic triggered ?"

Uncle Bernie answers:

It's not "triggered". It is "selected", at least with 512x4 PROMs, by bending off both pins#14 of these PROMs at an approximately 30 degree angle, so if they are plugged into the sockets, they make no contact, and as it's TTL, float high, which selects the upper page with the diagnostics.

When the Apple-1 works as expected, including the DRAM, the pins are bent back to select the WOZmon. Never to be bent again ... do it too often and they might break off.

All this is outlined in my "Tips & Tricks" pdf I wrote for builders of my kits.

The "Russian" version is an EPROM PCB which plugs into the A1, A2 sockets, replaces the hard to find bipolar PROMs, and the EPROM has many 256 Byte pages which can be selected by a hex switch or DIL switch. I think the PCB originally was designed and / or made by "Macintosh_nik" who is a member of this forum, but I'm not sure if he originated this PCB or modified it from some other source. It also could be available from other sources. Frankly, I don't care who makes my 'diagnostics page' available to Apple-1 builders, the only important issue is that it is available - otherwise all too many builders will get stuck with Apple-1 builds which  almost  do work but not quite right.

There are many other ways to test an Apple-1, there is a memory test by Mike Willegal available on his website, and a test for the "terminal section" is in the Apple-1 manual that came with the originals. However, with these solutions you have a chicken-and-egg problem because both require an Apple-1 able to run WOZmon, accept keyboard entries, and run programs from DRAM. Now, what if the DRAM is bad . . . so WOZmon will crash ?

I wrote my diagnostics such that they don't need any DRAM to run, and this helps a lot to dodge the chicken-and-egg problem. Of course, for the DRAM test, it needs two fully functional DRAM locations in the zero page, but whenever these are changed by the program, it immediately checks them afterwards to be right. The memory test algorithm I used is one of the best (same as was used during production test of the DRAM manufacturers). It would, of course, by its inner workings, also detect a corrupted pointer in the zero page, without specifically testing the pointer, but this could lead to confusing error messages showing another address other than the pointer location in the zero page. The whole topic is not as trivial as it seems.

Hope this helps. I know that at least one "Maverick" builder who sourced his A1, A2 location PROMs from some Ebay seller got only the diagnostics page and not the WOZmon. The seller had mixed something up . . . not  my  fault ! But IMHO putting just the diagnostics page into 256x4 PROMs is a terrible waste and borders on crime, because these PROM blanks are very rare and should be used only for making WOZmon and ACI firmware. We simple can't waste them on one time use contents like diagnostics. This is why I never sold the special 'diagnostics only' PROM set I once wrote, which even had a machine language monitor that did not need any functional DRAM to work. It's the same issue as with rare special tools for working on machine like a car, they are used once in a lifetime, and then are useless (unless the same rare fault pops up again). But when I found out that 512x4 PROM blanks are more abundant (and cheaper, too) than 256x4 PROM blanks, then of course I could put the diagnostics page into the otherwise unused 2nd page of these PROMs. My solution for 100% use of the the 512x4 ACI PROMs was to add the 'extended format' page (the original ACI firmware as written by Woz was only 256 bytes long).Alas, now, 4 years later, the world is running out of all suitable PROM blanks for the Apple-1, both the 256x4 and 512x4 are incredibly hard to find now, and typically command moon prices, so we can't squander any.

Hope this clarifies the mystery contents of some PROMs.

- Uncle Bernie

kalinchuk wrote:

I think you make a lot of sense. These PROMs are not erasible and easy to screw up. I did see quite a few of the empty PROMs on eBay. I guess they're still around. I would get some if I had a way to program them but seeing how expensive some of these programmers are, I'd rather pay someone a few bucks to program it for me.

FWIW I have built the EPROM replacement board by P-LAB which plugs into the PROM sockets. See this part of one of my blog posts. It's very convenient. I might yet get actual PROMs at some point.

IMG_1593.jpg

The author's memory test of the respected Uncle Bernie is simply indispensable for the so-called "independent" Apple-1 assemblers. But now with the depletion of stocks for the famous kits everyone has become "independent".