Char Problem

5 posts / 0 new
Last post
Offline
Last seen: 5 months 3 weeks ago
Joined: Nov 16 2021 - 23:47
Posts: 7
Char Problem

Hello All,

So I built my apple i, all was fine, I had run Uncle B's test program a number of times and all seemed fine. However I got a little excited and connected in both the ACI card and a PS/2 converter for the keybaord. When I booted back up I am only getting @'s, P's and 0's (I think the number not the letter).  My guess is that the lower half of the byte is some how getting messed up but currently unable to find the problem. I will shortly provide some pictures but in the mean time:

All Voultages appear fine and no issues.

I have removed the lower half of the computer (the computer section) and it still produces the same issue (as seen from the flashing load screen).

I have swapped out all of the repeat chips on the board to check that none had gone. 

While I dont totally discount a bad joint, I have checked checked and checked again all joints and also the board was working a number of times before even after being moved around a little. 

I have checked and blown air over the whole board a number of times in case something fell on the board and shorted two parts. 

 

Anyone had this problem and not talked about it? - I went back quite far in the forum for any monitor / char issues and couldnt find anything like this. 

 

Offline
Last seen: 5 months 3 weeks ago
Joined: Nov 16 2021 - 23:47
Posts: 7
CF93FDDA-456F-4CC4-B2A0
Offline
Last seen: 5 months 3 weeks ago
Joined: Nov 16 2021 - 23:47
Posts: 7
trim.909DE7B8-D528-49C0-A5C6
Offline
Last seen: 22 hours 48 min ago
Joined: Apr 1 2020 - 16:46
Posts: 806
A few rules about bringing Apple-1 to life ...

The problems described by "Acorn" are hard to diagnose without screen shots and a few more details - such as whether the CLR SCREEN works and the RESET works. Here are some rules I found helpful:

 

1. Disregard the contents of the power up screen entierly. It is a myth that it must contain certain patterns after power up. It's just a dirt effect caused by the empty dynamic shift registers which happen to have two interleaved banks of 512 bits inside, and one bank is inverted. So, typically, you will get the "@_@_@_@_...." pattern after power up but this depends on many things, like wait time without power, speed of power ramps, random counter wakeup in the Apple-1, etc. I've seen cases where the pattern would appear and then scroll upwards until it's partially gone. If the wait time without power is too short, remnants of the previous screen contents can be seen, but they may be displaced. I know exactly how this happens. There are extra circuits in the Apple-1 which try to "scroll away" cursors in the "forbidden" region of the cursor memory. But these do not work in the same way during each power up.

 

2. After power up, always press and hold CLR SCREEN and observe the screen. It should go totally blank. Any remaining char means a bad IC in the terminal section data path 74157 - 2519 - 2513 - 74166. Of course, a few other gates here and there could also be the culprit. Watch for the faint dot pattern  in the background. One faint dot at each possible character position, but four of the vertical dot rows extend upwards and downwards from the usual character field. If you see this pattern (which is a parasitic effect due to crosstalk) you know that all the timing in the Apple-1 is OK, and there is no fault in the counter chains.

 

3. Upon release of the CLR SCREEN, a blinking '@' cursor must appear in the leftmost upper corner. If it does not appear, the TTLs in the cursor state machine (lower right corner of the schematic) are the usual suspects.

 

4. Press and release RESET. The Wozmon must give ONE '\' prompt and the cursor must drop to the next line. If multiple '\' appear then you have a DRAM problem. Or no keyboard connected.

 

This is the recommended Apple-1 start up procedure. Many builders get spooked by the unpredictable behaviour of the power up screen and panic and start to swap ICs. This is NO GOOD !

 

Here is a golden rule from flying aircraft (I'm a private pilot so I should know): if you change the configuration of the machine, do changes step by step and keep the hand on the contol lever or switch until you see the reaction of the airplane to the last change in configuration. If something unexpected happens, immediately bring back that control lever or switch to the position it had before the change. And never change something unless absolutely necessary. This golden rule was worked often for me. Otherwise I couldn't write this. Don't laugh - I'm serious. The much more qualified airline pilots of flight AF447 from Rio de Janeiro to Paris, which crashed into the Atlantic on 1st June 2009, killed themselves and everyone aboard by disregarding these rules. And the same rules apply to change of configuration of any other machine, including Apple-1:

 

5. Change one thing at a time. Like adding an ACI card.

 

6. If it doesn't work anymore, undo that one change and see if you get back to where you were before.

 

7. If it comes back to life, as before, fine, the one thing you changed is the culprit. If it does not come back to life, something broke. Like a zapped IC. But also consider that during the manipulations, some ICs may have decided to climb out of their sockets, especially if you used the unreliable "original" IC sockets I warn about.

 

Finally, builders of my kits can always invoke the diagnostics page in the A1, A2 PROMs. It's done for the first start up to see if the build is OK, by slightly bending away the pin #14 of both PROMs so they don't touch the contacts in the sockets anymore (~25...30 degrees is enough). Then the usual CLR SCREEN and RESET and the diagnostics will run. They will allow you to detect all possible errors in the machine except for the keyboard port. But once the diagnostics run and produce the desired slanted character set pattern - and no DRAM errors - you can configure it back to the Wozmon and test the keyboard port using it ... you can type anything in Wozmon. A nice feature !

 

However, one word of warning: never use the pin #14 pin bending trick to activate the diagnostics page a second time. The pin might break off if bent too often. Instead, inspect the solder side of the motherboard below the A1 PROM location. You can see one sole long trace between the pin rows of A1. From this long trace, a small stub goes to pin #14. Cut that small stub out. This isolates both pins #14 on the two PROMs and activates the diagnostics. To get back to the Wozmon, solder a small wire from that isolated pin #14 to pin #8 (GND). Any time you need to reactivate the diagnostics, just lift off one end of the wire.

 

But never, ever, start to swap ICs without need. This has to be done with some reason, if a suspect has been identified. Randomly swapping ICs can make matters worse ... can you go back to the original configuration ? Not all ICs of the same type can be interchanged all the time. The semiconductor processes of back in the day were far from being as clean and precise as they are today, and so the apparently "same" 74xx IC - even with the same date code - may be faster or slower or its driving capability may be stronger or weaker, on some of its outputs, and its noise immunity on some of its inputs may be different. There is a reason why in my kits all the ICs come on ESD strips in the sequence they should go into the sockets. When composing these kits I see it all the time that one IC, say, a 7400, refuses to work in one position but would work in another position. I swap them to find out which is the culprit. But then I discard the culprit - it goes to my ever growing "graveyard" of bad ICs. So this "Zombie" can't cause trouble again. But I can't test all combinations and permutations of all similar ICs in the machine. So it it works, it works. Anyone starting to swap ICs should keep a list of swaps to be able to reverse it and get back to the original configuration. The sole exception are DRAMs - swap them as you like. This is because the diagnostics will tell you if you made matters worse. The error messages pinpoint the offender(s), always. For all the other ICs in the machine there is no such tool to pinpoint the bad ones automatically ... it requires a lot of experience and understanding of how the circuit works to find the culprit in a useful amount of time. Randomly swapping ICs hoping for a magical remedy is "cargo cult" class religious belief in the supernatural. It is not how we get our Apple-1 running.

 

And a final word about the perils of the infamous keyboard connector: whatever you plug in there, location B4, you plug into the connector from hell. I myself have blown up the printer ports of two of my beloved Aero 4/33 subnotebooks, now only one intact one left, using my keyboard emulator cable. I have blown up three keyboard encoders from various real keyboards. And except for one case (plugging in the cable turned 180 degrees) I even don't know what I did wrong. It seems it has something to do with the +12V and -12V supply voltages being present on that socket and they were placed in a stupid way so it's easy to blow things up when cables are foolishly put in backwards. Or when the power is turned on. I think back in the day they never bothered about  FMEA analysis ... which includes what the user could do wrong. The numbers of keyboards being killed by the Apple-1 is legion. I hear the whining and complaining of "my" builders all the time, grieving about the keyboards they killed. But so far I have no real remedy. I've thought about making a set of little PCBs for keyboard cables which would prevent the worst (even when plugged in turned 180 degrees or offset by one pin) but I don't see a market for those. It's not that I need to make money, but I don't want to waste my RQLT on projects which find 2 or 3 takers / users. The same happened to the interlock circuit for the transformers. I even have bought some suitable relays to make a dozen of them. But the PCB never was designed. So many things to do, so little time ...

- Uncle Bernie

 

Offline
Last seen: 22 hours 48 min ago
Joined: Apr 1 2020 - 16:46
Posts: 806
Finally - a video of the symptoms !

I've seen the video in post #3 and I have seen this failure mode before. Sorry I was too busy writing my previous post to notice earlier. I see you have activated the diagnostics page. Good. The processor section works. The counter chain also works. But something blew up / was damaged. Alas, I have to head out now to run some errands and bring my car to an oil change. I've sent you a PM on how to proceed. I'll be back in a few hours.

 

- Uncle Bernie

Log in or register to post comments