Which ACI improvements do exist (and work) ?

macnoyd wrote:

"Are you going to share the details of your findings?  Schematic of your changes?"

Uncle Bernie answers:

You betcha !

Do you know which day is today ?

Great celebration, the 70th birthday of the Woz !

Maybe he would cherish an improvement to his 45 year old "firstborn" as a birthday gift ?

In any case, I love the Apple I for its limitations, and my mission is to make it reliable and eventually add a floppy disk controller based on the Woz Machine.

I intend to publish every aspect of this work and make it open source, like I did with my various mid-1980's products for the 8-bit Atari.  Much like the Apple I, they are still in production after all these decades, although only made in small batches by enthusiasts and not anymore by the original business, and none are verbatim clones.

But before I do publish my findings on the ACI and the improvements, I need to review which improvements are  already out there. It would be too embarassing to write up my stuff only to find out it already has been tried by others.

Hence, again, my humble request to the Apple I "gurus" lurking on this list to point me to what they know about the exisiting / published ACI improvements other than the one by Mike Willegal (larger input capacitor).

Any comment invited. If you have a comment you don't want to show to the public, use the Applefritter message system to contact me directly.

Bernie

P.S.: I also need to go back to the lab and find out whether the original ACI using the LM311 suffers from the same bug I did see in my Apple II ACI knockoff. My current hypothesis is that the 741 based circuit just did exacerbate the effect of the bug over the 311 based circuit just enough to completely render my "improved" ACI useless, which then nudged me to do a thorough  root cause analysis, which then led to finding the bug and a remedy.

The LM311 in the original ACI circuit, may add its own problematic effects. The LM311 is infamous for having nasty habits in certain circuits. For instance, parasitic oscillations that appear under certain output loading conditions even when hysteresis is present: there is a LM311 based LC meter circuit all over the web which exhibits this problem if the LC time constant is large (kHz-ish) and there is a certain output load and some other diffuse features in its surroundings. Otherwise this LC meter circuit is quite brilliant (minimum component count) and works well. So people build it, sell kits, or finished LC meters, and most users seem to be happy with it. I was unhappy with it and over my 40+ years in electronics had enough run-ins with the nasty LM311 that I learned to avoid it like the plague. The LM311 having so many bad habits (under some conditions) did not prevent it from becoming immensly popular and it still is being made in huge numbers by various manufacturers, after half a century. The LT1011 made by my ex-employer is a much better part that does not turn around to bite you without any prior warning signs. Alas, the customers for analog ICs seem to prefer the cheap "jellybean" types and don't cherish much better parts designed by great designers. To cite an old adage: "Eat more sh*t --- millions of flies can't be in error". This is how Microsoft got so immensly "successful" ... but enough of that for now. -B.E.

Mike Willegal wrote:

"Note that I have found that the older and much slower SCELBI audio tape interface is more reliable  and less sensitive to input volume than either of the Apple designs.  The SCELBI design uses FSK encoding instead of zero crossing, which accounts for the speed difference.  The SCELBI recieve circuit has AGC and filter stages, which I think accounts for at least some of it's ability to handle a bigger range of input volume levels.  If you want to experiment with changes that might make make performance better, you might consider adding an AGC  and filter stages to the input.  The downside of all this sophistication in the SCELBI tape interface, is that the hardware is significantly more complex."

Thanks for the comment, Mike. Of course I knew of your improvement, which I think most ACI builds nowadays do use. I am also quite aware of the SCELBI interface (and others, like Tarbell etc.) because I am ... just that old. At around the time the Woz built the Apple I, I was a teenager who designed and built his own 8080 based machine.  My cassette interface used pulse counts to discern 0's ad 1's such that a single dropped or added pulse would not have made any difference. It was very robust. But much slower than the ACI. No problem though as my machine had only 1KByte of RAM unlike the whopping 8KBytes found in the Apple I ;-)

But back to the ACI. As far as my modified ACI goes, I do not seek sophistication and filters and AGC and stuff because I think that the minimalistic approaches both in hardware and software used by Woz are sound. As always, minimum parts count and elegant, small software. I am quite amazed how well the ACI works after my fix, with no mods to the software at all, no AGC, no filtering, etc. If you would see the "wow" of that cheap cassette recorder on the oscilloscope you would never believe it could work as flawlessly as it does. Actually, Woz did a great design here. Except for that one bug.

The big open question is whether my current hypothesis is correct: the Apple II ACI circuit based on the 741 exacerbating the impact of the bug. Maybe the 741 based circuit did create the bug (although I believe the bug is real and must also be manifest in the 311 based circuit, but it could strike less frequently, so the 311 circuit does still work OK under certain conditions).

As I dislike the LM311 I have none in the house so at this time I can't investigate. But I did order a few LM311 a few days ago and expect them to arrive soon. Then I will change my ACI back to the '311 circuit (without the bug fix) and run the same diagnostics. This experiment will prove or disprove my hypothesis. I have a hunch that it may be that very bug that makes the '311 based ACI circuit so finicky and sensitive to volume settings and power supply, the latter possibly having an effect because of some quirks inherent in the LM311. I learned to avoid that part as it did cost me many pitfalls in the lab.  All of them can be avoided, of course, by doing it right and by paying attention to every detail. But comparators in general are temperamental to work with especially when used in hand-wired lab setups.  The frustrating experience goes like this: while bringing up the lab bench circuit to test your latest and greatest IC design, you need a comparator, so you grab a 311 and slap it in. Big mistake !  You will spend the next few hours beating the 311 into submission instead of doing  productive work. For low speed (i.e. audio) work an opamp has much more benign behaviour. But in case of the ACI, it seems the opamp exacerbated the effect of a latent bug and hence, brought said bug to light. And unlike cockroaches in the kitchen, that bug can't speed away into hiding when that light is turned on. In any case, a lot of fun for me to kill time doing (commercially) useless projects.  This, of course, is intentional ! I have sworn to never create anything anymore that even remotely has any chance to be  looted for profit. Read Atlas Shrugged if you want to find the reason why.

Bernie

Corey986 wrote:

"You may also have problems with an ACI if you are using the edge connector for expansion as that can mess with the unregulated -12V and add noise onto the lines.   

Finally, your choice in transformers can affect reliabiity.   If your out of spec to what is recommended in the manual you can have issues.  I was working on an original Apple-1 which used some radioshack transformers which had lower voltage outputs than the Triad or Stancor which caused all sorts of problems including a very unrelable ACI even with the input coupling capacitor updated."

Uncle Bernie answers:

This are exactly the arguments why I wanted to avoid the original '311 based ACI circuit in the first place. IMHO if any ACI is so sensitive and finicky with the power supply then something must be wrong with it. The problem with any comparator is that they combine high gain with high speed and no internal frequency compensation which is a recipe for inviting disaster in any feedback circuit. You need to pay attention to every detail in the surrounding circuits and in the physical construction to beat these beasts into submission. The venerable LM311 due to its kinks / quirks adds some further possible pitfalls.  On the other hand, I found the '741 based ACI circuit of the Apple II behaves very benign and has none of the temperamental tendencies often seen with comparator based circuits. For instance, in the '741 circuit there are no influences of the negative power supply as long as it exceeds a reasonable value. -5V on the 741's V- supply (pin #4) certainly is good enough. The circuit ceases to work at -2.6V there, so there is plenty of margin left.  There are also opamps which might work in the ACI even when their V- supply is at 0V (GND). I will investigate this option at a later time. This would be great for Apple I replicas lacking a negative power supply.

This said, I would not want to go back to the '311 based ACI circuit even if it works OK under certain circumstances. The '741 based ACI circuit is much less temperamental and much more robust. Alas, it just did expose a latent bug. But this bug can be fixed easily. Still, as I did mention above, as soon as I have the '311 in my mailbox I will proceed to try proving whether the bug also is manifest in the '311 based ACI circuit or not. I wouldn't be surprised if a lot of the finicky behaviour of the '311 based circuit would go away after the bug fix is applied. At the moment however all this is just conjecture.

If my conjecture happens to be valid, however, this would mean the problems with the ACI are just another case of a "feature" (synonym for any "bug"  when used by the  marketing department) that has a completely different root cause than people think but manifests rarely enough so nobody cares enough to dig down to root cause. The consequence being "cargo cult" like magical behavior patterns of some users seeking best results by turning volume knobs or trying to find the "magic" cassette player that "works", or, in case of the rest of the Apple I main board, find the "magical" DRAM brands, types and date codes that work better than others. All these futile (but sometimes alleviating) efforts to solve a problem by applying magical thinking (like an Amzon tribe's witch doctor) in lieu of proper root cause analysis using a well equipped lab.

(Of course I write all this anecdotal drivel such that the casual reader can learn from my mistakes ;-)

Bernie

I got the LM311 end of this week and proceeded to rip out all the improvements I did to my ACI.

This unfortunately can't be avoided as I do only have one PCB.

This sucks.

With two ACI PCBs a could compare the two circuits without hours of desoldering and resoldering components.

Here are the preliminary results on the original ACI circuit:

1. The LM311 based original ACI circuit works - - - somewhat.

2. I can load BASIC from a notebook soundfile with no problems.

3. Trying to load BASIC from the same crappy cassette recorder that worked fine with the '741 based circuit always failed, with all possible volume settings and all reasonable negative supply voltages.

These results show that my LM311 based circuit was slapped together correctly. Same problems seen as with all other "normal" ACI circuits.

My diagnostics were run (briefly) and the bug did not manifest itself, unlike with the 741 based circuit, where it manifested itself.

The conclusion so far from my experimental work is that the 741 based ACI circuit from the Apple II indeed is much more robust and can work very well (even with real cassette recorders) but in the Apple 1 ACI subsystem provokes a latent bug to manifest itself, which must be exterminated with some further changes to kill it dead. This vulnerability allowing the bug to rise its ugly head is only present in the Apple 1. It cannot happen in the Apple 2.

Further experiments are necessary to see if the bug  ever strikes with the 311  based original Apple 1 ACI circuit.  I'd guess from my experience with this type of bug that it should happen with the LM311, too, but significantly  less often than with the 741. Maybe it never happens, though. Which would surprise me bigly.

Even with the 741 it is a rare event so catching it with the 311 is tedious and time-consuming. But it is interesting experimental lab work which is perfect for me to kill time. Much more welcome than cleaning the house ...

Some of you may have seen this thread:

https://www.applefritter.com/content/which-aci-improvements-do-exist-and-work

in which I wrote about my work towards improving the notorious ACI. Alas, there never was enough interest / feedback from the worldwide Apple-1 user community to justify any more investment of my precious RQLT into that project, so it was shelved and I never made a new PCB layout of the improved hardware, which would not have been optimum anyways as the improvement work was not complete. I did have an improved playback circuit I stole from the Apple-II (with some adaptions required for the Apple-1 environment) which IMHO did noticeably improve the tape read operations. I also had written some new firmware (512 bytes, yet another little hardware mod required as the standard ACI circuit only supports 256 bytes of firmware PROM) which provided full Apple-II compatibility (adding the checksum byte) and some more useful features. But at the point I shelved it I still had no solution to make that LED work.

The LED on the ACI obviously was meant to give an indication for proper volume setting during tape read operations. But this is just a conjecture because it never worked for me. One cassette recorder would light it when the volume was cranked up to maximum, but then the tape read would fail due to the noise being amplified too much. Another cassette recorder never lit it regardless of volume setting, but lit it when using rewind / fast forward. Any playback of WAV or AIFF audio files from a computer succeeded after the correct volume setting was found by a lot of fiddling, and the loaded software worked, but it never lit the LED. I do not have the original cassette recorder recommended in the ACI manual so I can't tell if the LED indicator works with it, and yields the correct volume setting. Unless somebody proves to me that this is so, I must regard this LED circuit in the ACI to be the biggest POS in the whole sea of Apple-1 quirkyness. You see, there is no properly set DC operating point in it, and taking its input signal from the TAPE IN plug is completely nonsensical ... you don't want to know if the input is moving, you want to know if the output of the comparator is moving. Because just a tad more volume over the point where this happens is the volume setting which gives the best tape read reliability. And you want a LED volume indicator circuit which gives you that capability. But back in August 2020 I did not get around to find an improvement for that circuit. I was quite happy that my 741 opamp based readback circuit did work and I already has spent waaaaay to much time to get there. Lack of a reliable LED volume indicator contributed. But I did not need that as long as I had the oscilloscope near the computer and could look at the output of the comparator to adjust the volume. So I did not really feel the pain from that awfully botched LED circuit and could ignore it.

Fast forward in time until last week. I wanted to try out some software on WAV and AIFF files. The oscilloscope was not at the computer and used elsewhere in an ongoing experiment and I was too lazy to disconnect it and move it downstairs. Big mistake ! The volume setting issue nearly drove me nuts ! (This time I used the original LM311 based ACI card). So I finally felt the pain that may be caused by that nonfunctional LED indicator and decided to go to the lab and fix it once and for all. And here is the fix. But be warned, it is not perfect despite it works OK:

As I did mention above, the key to make that LED volume indicator work is to make it look at the output of the comparator, and to hook it up in such a way that when the comparator output moves, it will light up the LED. LED shall not light up if the comparator output either is static "L" or "H". This implies we need to add a small capacitor to keep the DC away from the LED amplifier (the two transistors in Darlington configuration). Alas, I found out that any capacitance large enough to give more than a faint glow, if attached to the comparator output, will already impair its signal quality. So another amplifier / buffer stage must be added. Alas, all gates in the ACI are used. Except for the second D-FlipFlop in the 74LS74. So I pressed that into service as a buffer amplifier. The final circuit is like this:

A1_ACI_mod3.JPG

It works OK but as it is a quick hack that cost me only an hour of my precious RQLT, it is not fully characterized and worked out for all component tolerances. One issue you may run into is transistors with a beta / Hfe too low. Because of the Darlington configuration, the betas multiply which makes this circuit very sensitive to beta variations. If, for instance, beta is 100, total current gain is 100 x 100 = 10000. Which is not really great if you want to make the LED light up from the feeble current pumped into the amplifier input via the capacitor. If you happen to have transistors with a beta of 300 each, total current gain is 300 x 300 = 90000, or nine times of the previous case ! In this case, a 120pF coupling capacitor is enough to light up the LED well. So, if you have a LED too dim, you have to experiment with increasing the coupling capacitor and / or the base pulldown resistor (which is the 4.7 MegaOhm resistor in the above circuit that replaces the 100K resistor of the original ACI). I had some lower beta transistors in the second ACI and had to increase the coupling capacitor to 1 nF to get a nicely lit LED.  The D-FF output would not be happy with that load if it would need to drive anything in addition to this coupling capacitor. But as this is its only job, we are fine.

To use this new and improved volume indicator LED, place the tape on the header tone and put the recorder into playback mode (you do not need to start the ACI firmware). Then slowly increase the volume setting until the LED lights up. Just a tad more that that setting is the optimum one.

Comments invited ! If I get enough feedback I will add some photos of the mod. Be aware that the one leg of the resistor that must be grounded has traces both on the top and the bottom side of the PCB to the TAPEIN signal, so you need to cut it near the pad of the resistor on both sides. Do not solder near bus finger "A" but follow the trace up until it disappears in a via, and use that via to solder in the wire that connects to U2 / Pin #11.

Enjoy ! (And don't forget to tell me if you want the photos)

Hi -

here are the photos I have right now. Maybe they are good enough. I never invested in a professional photo studio or a good camera so there is no good lighting and no good background and the autofocus sucks. This is not that I don't know how to do professional grade photos ... 30 years ago I used the equipment of my GF of the time (she had divorced a professional photographer who later became quite famous) and got some really great photos out. A few of them were so excellent I was able to sell then for good money to a tour operator which used them in their catalogs for years (Seychelles, the jewel of the Indian Ocean). But unless you can make lots of money with your photos you never get the investment back.

OK, so here is the component side of the modified board:

A1_ACI_mod2.JPG

The red arrow points to the trace that needs to be cut to isolate the one leg of the 100K resistor which will be replaced by the 4.7 MEGohm one. I advise that before doing the cut, remove the 100K resistor and desolder one leg of the 3K resistor to be able to lift that resistor up so it is safely away from the work site when the cutting tools are in action. It is very easy to damage components when you slip with these tools, so better get them out of the danger zone.

This is the solder side of the modified ACI board:

A1_ACI_mod1.jpg

You can see where to make the second cut to isolate the one leg (as before) and how to route the wires around. I use insulated copper wire the kind used to wind transformers and the insulation is conveniently removed by the soldering iron when pre-tinning the ends. This works with most polyurethane based insulations. Buy be aware that the process makes isocyanate fumes, although in minute amounts. I have a solder vapor remover in my lab which sits near the solder work and sucks away the fumes and neutralizes them in some charcoal insert, so I don't need to worry. But if you don't have such equipment, don't inhale the fumes ... unless you are a smoker, then it doesn't matter anymore anyways.

The "A" is at the via where you can solder the wire in to tap the signal from bus finger "A".

Tell me how it works for you. Sorry that the photos are such a mess.  I did not clean the PCBs yet from flux because it's still work-in-progress and I had to take them outside which explains the glare. Inside the house the lights were too bad to be able to get any useful photo. It used to be easier. Maybe something on the camera starts to fail. It is 22 years old.

I also have a comment to post #12: I can confirm the TAPE OUT signal issue. It has been my experience that with some cassette recorders I tried, the TAPE OUT signal level from both Apple-1 and Apple-II was too weak to get good recordings, and the remedy with modifying the voltage divider is sound and it works. The irony here is that it seems to be the "noise" from the digital logic which is the main culprit, and not lack of sensitivity in the cassette recorder. I had to modify the Apple-II to get a higher TAPE OUT level but I did not need to modify the ACI card for that, as long as I don't try to use the super cheap "dictaphone" style recorder which is my "worst case example". This one would need more signal in any case.

As for the TAPE IN amplifier, I have found (as seen in the above thread) that the Apple-II circuit using the 741 opamp works much better for me than the original ACI circuit with the LM311. And this is where I stopped my investigation. I now have two ACI cards, one with the original LM311 circuit and one with the 741 mod. The irony here is that in my LSTTL based Apple-1 the original LM311 card just works fine, once the volume is properly adjusted.

This gives us another clue that the problem with the original ACI is  not the LM311 based circuit by itself. In the lab, on the test bench, and powered from laboratory power supplies, even the original ACI card works perfectly fine and I can't pinpoint any measureable problems regardless how I set the signal generator.  I even tried added noise to the signal but could not make the LM311 circuit misbehave (unless the noise exceeded the hysteresis, which, of course, is expected). So most likely, it is a PSRR or CMRR problem which manifests itself when the ACI card is plugged into the "supply from hell" (the ringing and noisy Apple-1 motherboard). But as I need to prioritize what I do with my precious RQLT, I never had the time to get to the bottom of it. And since without knowing the root cause I don't have any proof that my 741 mod to the ACI is not overkill. Which greatly discourages making a PCB layout for that mod. Because the effort for that may be wasted. It could be that a less involved mod to the LM311 circuit exists which brings enough remedy to be a perfectly viable solution. This would mean much less mods to the PCB and staying closer to the original "looks".  Which for me, would be the preferred solution, if such a solution could be found.

The observation of AppleMicha in post #12 above gives us a further clue that such a  solution may exist. But I don't have the time nor the motivation to further pursue the improved ACI project, as I now have one hand-wired modified ACI using the 741 which works fine in all my Apple-1, and the original LM311 based ACI which works in my LSTTL based build (it does have Mike Willegals input capacitor mod, though). Had there been much more resonance from the worldwide Apple-1 crowd for the proposed "improved ACI" the situation would be different, of course. But without enough resonance / demand / encouragement, I can't justify to expend more of my precious RQLT on this topic, even more so now, a year later, with my Apple-1 floppy disk controller getting closer to the finish line. So the improved volume LED circuit is all what I've got for you, but I think it's fair enough to at least have published this small but helpful mod which came out of my work on the improved ACI. The improved firmware I wrote for it will never be published, like my APPLE-1 DIAGNOSTIC PROM SET. Not enough takers, sorry.

Hi AppleMicha -

thanks for you post #15, it is certainly helpful for the Apple-1 crowd to understand what is going on and why the original ACI does not work all too well.

It all boils down to  what electronics professionals call "signal to noise" or SNR. Depending on the circuit you have, the signal must be larger than the noise to allow for proper recovery of the signal. The more primitive the circuit and the signal modulation /encoding is, the better the SNR must be. There are some signal processing techniques where you can actually "fish" out a signal from below the noise floor, so-called "lock-in amplifiers" being one example. But what we have in the ACI is the most primitive encoding and modulation method possible. So we need a really good SNR to get good enough reliability.

What most hobbyists (and some professionals) don't understand is that the "noise" part may not only come along with the "signal" out of the "channel" (the transmission medium) but it also may come from parasitic effects coupling unwanted crap into the receiver circuit. And so far all evidence we have at hand points to this being the most likely root cause of the issues with the ACI. Alas, proper diagnosis and a real proof of exactly how this happens and what the parasitic signal path really is requires a lot of lab work and a lot of time. This is why most people (hobbyists and professionals alike) tend to slap some filter capacitors in (or do some other small mods) and if this brings remedy, it's adopted to be "the solution". Which, alas, may be sub-optimum, or not a good solution at all.

Time is money (especially when the bonus payments of your local psychopath aka "manager" depend on being in or below budget) and so they call it "done". But this is not how you get stellar products which are ... perfect and very satisfying for both the customer and the maker !

There were very few famous companies out there which consistently designed and made stellar products. Names like Hewlett Packard, Tektronix (for instruments) or Burr-Brown and Linear Technology (for ICs) come into mind. But all these once famous and highly regarded companies share a common fate: once the founders were gone and the hired managers took over,  rot and decline set in and crappy products were made and sold which never should have existed at all. In some cases the company ran out of money (or was too small to defend itself against hostile takeover) and then was bought by a much larger corporation, which, by definition, always has internal rot and lousy products, and a management / mindset which spoils and ruins everything. So in the end, all the stellar reputation built over many decades is quickly ruined by the new owners / new management. This is how stellar companies rise and fall. The most sad example properly being Hewlett Packard. Carly Fiorina "managed" to destroy  in a few years what the founders had built in more than 60 years.

I have always resisted pressure from management to cut corners and make crappy designs.  So most of my projects were over budget and / or late. But once they went into production, they were always trouble free, had consistently good yields, and never came back to haunt me. So I could fully focus on new projects. Those colleagues who gave in to pressure from moronic managers only concerned with their bonuses had a different fate ... their products more often than not had yield issues or - even worse - field failures requiring mask revisions after the release. Or they were quirky and the customers hated these ICs, so they never became "stellar" products. This is what happens when designers listen to moronic / greedy managers. (Not all managers are bad like that, though. But most are. The "Dilbert" comic strips are popular for a reason.)

My policy to never compromise the quality of my work extends even into the hobby realm, so this is another reason why I rather abandon some project that is not yet perfected and would take too much time to get it up to my standards. Some projects are simply not worth doing (or completing). Alas, you can't always tell which project is worthwhile to do at the beginning. At the beginning, all projects look rewarding, otherwise you would not start them in the first place. But once, down the road, you come to a point where any further progress would take unjustifyable amount of effort, time and money, you better stop and put it on the back burner. Or right into the trash can. Depending what it is.

If you really want to continue working on the ACI where I stopped, try a resistor and zener diode combination in the negative power supply of the LM311. The zener I used in the 741 circuit was 5.6V but as long as the power supplies are in a range where the circuit would work, any zener voltage would do, but keep in mind that the power dissipation on each component and calculate it before putting them into the ACI. I have a hunch that, together with your supply filter capacitor right at the LM311, this might be a good solution. But I don't have the time nor the motivation to try.

I also did not look into the option to do away with the negative power supply and run the LM311 from a positive power supply to ground only.

This is all the hints I have for you. The 741 circuit can be found in the Apple-II manual. But if you can make the LM311 circuit work well enough, then we don't need the 741 solution.

Any thoughts ?

The Apple Cassette Interface (ACI) has been notorious for being unreliable since it appeared in 1976. Numerous attempts have been made by various individuals to improve it. Mike Willegal suggested the increase of the input capacitance, which helps a lot. I have substituted the whole LM311 based tape read circuit with the 741 based circuit from the Apple-II and have seen dramatic improvements: for the first time I was actually able to read back the tapes I had written on the same cassette recorder.

More recently I have improved the LED volume indicator circuit (which almost never works in its original form). All this you can see in the above posts in this thread.

But the adventure continues !

Here is what happened: I wrote some software for Linux which would allow me to make synthetic AIFF audio files from my Apple-1 binaries so I could post these audio files on Applefritter. Beats typing, does it ?

Everything appeared to work fine and I can make such AIFF files which can be read back into a real Apple-1. Ironically, I never had any read errors with these AIFF files even when using an unmodified ACI card (the only exception being Mike Willegal's input capacitor mod). So even the LM311 circuit is not all that bad. It works ! At least it does work with synthetic AIFF files. This is quite in line with the findings of other Apple-1 owners using MP3 or AIFF files.

But in hindsight this should have risen some eyebrows !

The reason is that any cassette recorder in reasonably good shape (that is, no sloppy / deteriorated rubber drive belts and no gummy capstan drive wheel) should have enough audio fidelity to give the same, reliable playback of cassette tape recordings. It just should work. Period. Which it does not. See the contradiction ? Although a sound card in a modern PC will undoubtely produce a cleaner signal than any cassette recorder, the latter, if using a quality tape, should not distort the signal so badly it would then cause tape read troubles. Of course, super cheap and super crappy cassette recorders might do that. But any decent one won't. People were listening to music with them ! And enjoyed it ! These cassette recordings were not that bad ! And compared to music, the Apple-1 tape signals are not that demanding. So something else must be going on, right ? But nobody did investigate that. At least I did not find any reports on any such investigation. Here is how I stumbled upon yet another suspected quirk of the ACI:

After I had my AIFF synthesizer up and running, I thought it would be nice to have the reverse process, too, being able to capture audio from the Apple-1 TAPE OUT port and then run it through my software to extract the binary data. This was mainly driven by not having a means to efficiently get data out of the Apple-1 as easily as getting data in. So I coded the necessary routines and tested them with my synthetic AIFF files, and I got the same bytes out as I did put in. Victory ! But when I tested the same process with a real capture (made with AUDACITY) from a real ACI, nothing worked ! Despite my demodulation / decoding algorithm is quite sophisticated and should be able to handle all sorts of less-than-perfect signals. A lot of my know-how coming from the design of TVtext ICs went into it (TVtext was quite popular in the last century, and the signal rode on the TV lines invisible on the CRT). Every signal recovery trick known to me is in this code. And the captured signal broke it nevertheless ! Very suspicious, isn't it ?

So I went back to AUDACITY and dialed up the gain and zoomed into the captured audio. And there was the culprit:

ACI_glitch.JPG

You can see that from time to time, there are glitches in the signal (red arrows added to point to them) which should not be there. It seems to occur every 8 bits, hinting at some timing bug in ACI firmware related to the byte write loop.

So I started to count cycles in Woz' code. And found some small inaccuracies, but nothing which could provoke such a glitch. It's not a matter of small cycle count deviations from ideal worth half a dozen CPU cycles or so. Whatever causes these glitches is much, much worse. So I got doubts about my ability to count cycles and to read code. And decided to finally go through the ordeal to fix the X11 library issue on my 64 bit Linux computers, so I could again compile my own Apple-1 emulator, which I had lost earlier this year to a hard disk of a 20 year old Linux machine dying (I of course keep regular backups of the code I write, but, alas, only the source code). I just did not need that emulator badly enough to justify the expenditure of my valuable RQLT to fix issues with 64-bit Linux distributions not setting up the X11 libraries correctly (a known problem, and all the well meant remedies suggested on the web did not work for me). Finally, after I had fixed it by hand, which took me a whole afternoon, I could compile my own Apple-1 emulator again and run it. And this is the result from its ACI emulation for the ACI timing (the first number is the CPU cycles between TAPE OUT toggles in the emulation):

ACI_stats.JPG

So there are no timing / cycle counting bugs in Woz' ACI firmware, only minor and inevitable deviations from the ideal case, none of them more than 12 CPU cycles, which is irrelevant for the audio recording and could not possibly cause the observed glitches.

So the most likely reason for these glitches is yet another hardware bug. It looks as if the 74LS74 D-flipflop in the ACI driving the TAPE OUT toggles somewhere around the byte boundary without the firmware commanding it to do so. Now, if you look carefully at the glitches, you can see that they don't persist long enough to produce a full amplitude swing in the signal. So how that glitch manifests itself in the recording would depend on the bandwidth of the cassette recorder and the characteristics of the tape. But in any case, it's no good to have such glitches in any case. It may contribute to the notorious unreliability of the ACI --- and maybe this is the final missing piece in the puzzle !

Before I continue to spend further time on getting to the root cause of these glitches (and hopefully find a remedy) I'd like to ask you - yes ! I mean YOU !!! - to try that experiment yourself: use the ACI to write a few bytes (I used the command 600.607W with 600 to 607 filled with some data, so only 8 bytes were written) and record the TAPE OUT signal using your notebook, PC or smart phone.

For PCs, the AUDACITY software is free and available for both Windows and Linux. It's super simple to use as it has the same virtual "play, record, stop, rewind" bottons as a real cassette recorder has. After you ended the recording with STOP, you can use the slider to get to the end of the header tone and then zoom in by repeatedly clicking on the "+ magnifier" symbol.

If you see glitches, please make a screenshot and report them here in this thread. If you don't see any glitches, report that, too (but no screenshot is needed in this case).

I have seen the glitches with both of my ACI cards and in three different Apple-1 builds (but I did not want to interrupt my burn-in rigs). One of the builds I tried is the LSTTL version which has the glitches, too, despite it has cleaner signals on the 44-pin edge connector than the standard TTL version and it also has the real PHI2 of the 6502 pin #39 there, which I did to make my Floppy Disk Controller work better.

Alas, I could not yet set up more elaborate instrumentation yet because I did forget that my logic analyzer is disassembled for repairs (since a year). And with the oscilloscope I could not nail it down because the trigger conditions to actually see the glitch among the legit flipflop toggle commands given by the firmware are too complex. Only a logic analyzer can do that and even there it is quite tricky to program (you need to exclude triggering on the LDY $C000,X instruction in the firmware at address $C1EA).

Alas, before I can get there, I need to repair the logic analyzer and put it together again, with I did loathe and avoid for a year now. It's a problem with the rubber membrane keyboard which stopped working after 25 years. I foolishly bought a second logic analyzer of the same type off Ebay for $50 or so but it also had the same problem. There exists some magic potion / paint containing silver to "fix" those rubber keys but it's very tedious and messy. Uncle Bernie's tip: never buy instruments with rubber keys ! Another trap brought to you by moronic managers, bean counters, and Idiocracy. Such cheap crappy rubber keyboards have absolutely no justification to be in an instrument that did cost five figures back in the day !

So at the moment I'm stuck and have to rely on your inputs on whether your ACI also shows the glitches. If it's not just rare but manifests itself often enough, your feedback could greatly motivate me to put my logic analyzer together again and get to the root cause of it.

Comments invited ! 

natas666 wrote:

Instead of trying to cure a broken design it might be better to port a proven good design from the Apple II to the Apple I.

Softwarewise this is already partly done with the Wozanium Pack.

 

Uncle Bernie answers:

natas666, you seem to misunderstand the mission statement of this thread (and my mission in terms of the Apple-1 in general). My mission is to address all the quirks of the Apple-1 and fix them, such that in the end it will be a sound design that works robustly and is fun to use (and not frustrating at times as it is now).

This mission was initially driven by my desire to sell off my vast overstock of Apple-1 ICs without creating an angry mob of frustrated builders who would want to lynch me (or at least tar and feather me) because their Apple-1 builds don't work all to well or don't work at all. I want happy builders who succeed, and this is why I do the burn-in and testing of all the IC kits I sell, and why I had to fix the DRAM reliability issue first. Then I proceeded to fix the notorius ACI. And yes, if you have read the above thread, I found that the 741 based circuit of the Apple-II works better. But as long as there are glitches in the TAPE OUT signal, the ACI can't be considered "fixed".

Please also try to understand my philosophy when I propose fixes / mods / add-ons to the Apple-1: I try to design and develop them in such a way that they stay as faithful to Woz' original design as possible but still fix the bugs. I also try to use period correct electronic components only. It would have been all too easy to just disable the notoriously unreliable on-board DRAM and plug in a daugther card with a modern 64Kx8 SRAM chip. Which even could have a small button cell to make it nonvolatile. But all these ICs did not exist back in 1975-1978 (the time period I consider to be "period correct"). So I don't want to use any IC that came on the market later. Of course I am not dogmatic about this arbitrarily drawn cut off date, but somewhere a line must be drawn. Otherwise you could replace the whole Apple-1 with a single small FPGA in the smallest BGA package you can find, put it on a thumbnail sized PCB, and call it done ! This is *not*  what most vintage computer enthusiasts would want !

The TAPE OUT glitch issue is a very interesting discovery because there are strong clues that its root cause also may affect other peripherals. For instance, when I load RWTS software for my prototype floppy disk controller seen here:

https://www.applefritter.com/content/uncle-bernies-woz-machine-based-apple-1-floppy-disk-controller

... into the Apple-1 by using the auto-type feature of my keyboard emulator seen here:

https://www.applefritter.com/content/apple-1-keyboard-emulator-cable-plans

... then the floppy disk spindle motor suddenly turns on halfway through the load. Which means that something toggles the 74LS259 soft switch in an erratic way ... which happens to "live" in the same 4K address block as the ACI.

This effect is not random. It always happens. And it aways happens at about the same RAM address (as far as I can tell by human observation ... the Wozmon is not too fast to see that). It does not happen when I actually run the RWTS (which happily reads and writes sectors all over the floppy disk and checks for errors for days with no fault).

This said, I think it is really worth to investigate this ACI glitch effect further and to get to the bottom of it (the "root cause"). Which I think does NOT reside on the ACI daughter card itself, but most likely is yet another  quirk on the Apple-1 motherboard. But before I expend all the irreplaceable RQLT which would be needed to set up all the instrumentation to hunt that bug down using a logic analyzer, I would like to get some feedback from other Apple-1 owners whether they can see the same glitch in their machines or not.

So I hereby renew my call for other Apple-1 owners having an ACI card to investigate and post the results here in this thread ! You do not need any expensive measurement equipment like an oscilloscope or a logic analyzer, you just need some PC with a sound card (you certainly have) and some audio capture software like AUDACITY, which you can download for free from the web !

Comments invited !  

... in other ACI cards. It could be it's just in my own two ACI cards which are heavily modified due to ongoing work on improving the ACI. This is why I asked other Apple-1 builders to see if their ACI cards also have these glitches. I don't want to go on a wild goose chase nor do I want to undo all the mods on my own ACI cards. Which may be too risky and the reason for the glitch.

So if you have an unmodifed ACI card, and can download AUDACITY, or can send me a MP3 or any other audio file  with a recording you have made, regardless of data contents, please send it to me.

I really want to get to the bottom of this glitch issue (if it's not just me). 

... for sending me this file you recorded. I examined it with AUDACITY and there are no such glitches in it. Also, a converted it to AIFF and fed it into my software and the decoding process to binary worked just fine ! (Despite your recording was done at a volume level too high so there was clipping).

Anyway, this proves that the root cause of the glitches I saw in my ACI cards must have been caused by my most recent mods I put in (an upgrade to 512 Bytes of PROM space, for extra commands, which make the ACI Apple-II compatible and much more !) The irony is that this new software works fine as long as it runs in RAM, even with the modified ACI cards having the extended PROM space mod. This is how I have tested and debugged it.  When running from RAM, it produces good recordings with no glitches. If it runs in the 512 byte PROM, it has the glitches. And if it were a software bug, my ExactA1 Apple-1 emulator would catch it. It has a complete ACI emulation built in which checks the emulated TAPE OUT pulses to have the correct timing. And this check is proven to work because if I deliberately reduce a timing constant in the PROM firmware after loading it into the emulator, and do a tape write operation, the check is triggered and duly reports a timing error. So whatever causes this glitch can't be a fault in my new ACI software. It works perfectly fine in the emulator and when running in RAM on a real Apple-1. But what is even worse, the original ACI firmware written by Woz also produces these glitches on the modifed ACI card - despite my add-on functions are not even running.  To me this is completely mind boggling and despite I pondered quite a while over possible root causes, it eludes me and I have no clue. This is the sort of self-made problem (changing a proven third party design that works) which can make you wonder about your mental sanity. Reluctance to undo the changes contributes. Of course I know the iron rule that if some change is made causing things to go wrong, the first action to take is to undo the change and see if the problem goes away. This even applies to flying airplanes. But in this particular case I was so confident the small, trivial change would work perfectly (the ACI memory decoding circuit is simple) that I did modify both of my ACIs in one session and then painstakingly cleaned them from flux residue because I considered them to be "finished". What an illusion !  I really "finished" them good, and broke them. They don't work anymore and now have the glitches. But before I got a confirmation that the normal ACI does not have the glitches, I did not want to undo all the last mods, lose the time invested in the mods, and contaminate the PCBs again with nasty flux residue, just to need to clean them again which is a tedious process.

But after AppleMicha's audio file confirmed that the glitches must have come from my mod, I undid the mod (removing two wires and closing a PCB trace cut) and then the glitches were gone. Alas, now the PROM space is back to 256 Bytes and I can't run my extra page anymore.

Another example where the attempt to preserve invested work = time and being lazy  in the end did cause much more waste of time. I should have followed the iron rule to undo the last change before taking my troubles to this thread. But it's a nice example on how not following the rules of lab work leads to a waste of time.

The actual failure mechanism (root cause of the glitches) is not yet known. I fully understand the address decoder logic of the ACI and the little change I made to get 512 bytes of PROM space looks innocent enough. In 40 years of working with the 6502 I never have seen something like that before. It's not a random effect caused by poor signal integrity, and there can't be a timing issue with the addresses crumbling away before PHI2 ends (verified by oscilloscope measurements). I see no reason why the TAPE OUT port works fine with the PROM space mod when the same software runs in RAM but when running in the PROM it makes glitches, at the end of each byte, in a reliable way, all the time. After all it's the same instruction which toggles the TAPE OUT flipflop, and other than the relocation to RAM, it's the same code. Weird !

But I promise to get to the bottom of it and I will find the elusive root cause and post my findings here in this thread !

This is the motivation for all of this: I do need a functional 512 Bytes ACI mod to be able to release my new ACI PROMs to the worldwide Apple-1 user community. Imagine you could read and write the same recordings on both the Apple-1 and the Apple-II while staying backwards compatible with unmodifed ACIs. This is a very cool feature and I hope it will be of great benefit to the Apple-1 world. Imagine you could develop software on an Apple-II and then save it to tape on the Apple-II and then load it into the Apple-1 and have the checksum feature of the Apple-II. You could record existing software on the Apple-1 (using the modified ACI) and then read it on the Apple-II for  editing / disassembly / modifications etc. I intend to use it to test my RWTS routines currently under development on the Apple-1 also on the Apple-II to check for their compatibility with DOS3.3 and with the original Disk-II controller card. All this requires a convenient "bridge" between the Apple-1 and the Apple-II. Which would be the upgrade of the ACI to my new 512 Bytes of ACI firmware. It looked so deceptively simple to do until the glitch problem reared its ugly head. But I promise - I will get to the root cause and fix it. Stay tuned !

Comments invited (perhaps you have a hint which mechanism could cause the glitches). 

Your Uncle Bernie has finally found out how he shot himself in the foot (figuratively of course) with that botched first attempt to do a 512 Bytes firmware upgrade of the ACI card. I do now fully understand the exact mechanism how the glitches are generated. And it is so mind boggling and obscure that I decided to turn it into another one of Uncle Bernie's infamous riddles !

And this one is for 6502 experts only ! Dim light bulbs please stop reading any further ! They would just waste their time and never understand what is going on !

Here is the riddle and the rules (and the reward):

- You read posts #17 and #23 above to learn the facts about the glitches and how they    manifest under which conditions. It is very important to pay attention to the details !

- You turn on your brain and explain how exactly the failure mechanism which causes the    glitches works.

- If you don't have any clue, stay silent in shame.

- If you do have a clue and think you understand the failure mechanism, write it up and send    your writeup as an 'Applefritter' message to me (you just need to click on my handle "Uncle Bernie" of this post and then choose "send message") --- but, PLEASE, don't post your theory here in this thread. This would be a foul and all my rewards will be forfeit ! Nobody would get anything ! Don't be such a spoil-sport !

- The rewards: the first three responders who send me a private message with the correct   description of the exact mechanism how the glitch comes into existence due to my (innocent) 512 Byte mod to the ACI, will get a PROM set for the ACI with my extended firmware, free of charge, regardless where you live in the world !

Do we have a deal ? This is a great opportunity for you to become a beta tester and no, the corrected version of my mod does not have the glitch anymore. What is even better, I will feature the three winners here in this thread to be smarter than me. Because I fell - foolishly - into that trap that was set back in the year 1975.

To be fair, I will give you a full disclosure of the harmless looking circuit mod which caused the glitch:

PDRM1623.JPG

The changes to the original ACI circuit are in red color: what I did is to disconnect address line A9 from the ACI memory decoder and to use it as an address line input to the larger 512 Byte PROM (a Signetics 82S131). This enables a second firmware page at address $C300-$C3FF in which my extended ACI firmware resides. The first page in address range $C100-$C1FF is still the original ACI code written by Woz in 1976, which I did not want to modify as it is perfect (as much as the 256 bytes allow).

My "extension" code just adds a few features and the Apple-II compatibility. If you plug these new PROMs into a standard ACI, you just get the same thing as before. But if you implement the small circuit mod as shown in the above circuit diagram, you enable the 2nd page in the PROM, and if you then do the C300R command you can start it and get the additional features. And you will also get the glitch ... even when running the unmodified code written by Woz using the C100R command ! The exact failure mechanism causing the glitch really is insidious and it is somewhat mind boggling. To explain it, you need to understand how the ACI hardware and software works. But keep in mind the cause of the glitch is not a software bug ! As long as the same ACI software runs in RAM, there is no glitch, even if the ACI circuit is modified as seen in the above circuit diagram.

 The original ACI schematic and the listing of the original ACI firmware as written by Woz you can find in the "aci-v0.18.pdf" file on Mike Willegal's website (www.willegal.net) under "Vintage Computers", then go to the Apple-1 ACI page, and said pdf is in the link at the end of that page. Armed with this information, you should be able to explain the exact mechanism causing the glitch. Note that Mike Willegal also mentions a nasty bug (or compromise due to lack of code space) in the ACI firmware, but this has nothing to do with the glitch. This bug can easily be neutralized if you always enter all addresses as four hex digits when in the ACI firmware command line, and all is good !

If you can explain the glitch mechanism, then you qualify as a 6502 wizard !

If you can't explain it, you are at least as dumb as I am. Possibly even dumber, as I did find it myself, but alas, after wasting way too much of my time !

But this is no medal you want to compete for.

Comments invited !

natas666 wrote:

The mirror C000-C0FF is uses as IO.

I guess you did not have that in mind.

As the way this is done is a bit bizar, as the Output of the OP-Amp is logicaly combined with the Adresslines including A9.

Like this predefined ROM positions are read that are not equal.

I think your extension is breaking that while switching.

Well, you are close but did not follow the rules I have set forth in my post above.

Of course I knew *exactly* how the ACI works even before I made the mod. And the mod does work perfectly without glitches as long as the firmware runs in RAM. The glitches appear when the same 512 bytes of firmware are relocated to $C100-$C1FF and $C300-$C3ff and run from the PROMs in the modified ACI. Note that I could not use $C200-$C2ff because this is a mirror of $C000-$C0ff where the I/O resides. So the "A8" address line of the PROMs on their pin #14 was connected to CPU A9, as seen in the above circuit diagram. But this does not explain why the glitches appear when the same code runs in the PROMs and do not appear when the same code runs in the RAM.

Despite of  your violation of the rules, I will grant mercy and keep the rewards for solving the riddle open until next Sunday. Then I will disclose the solution. If any reader wants to compete in the Riddle and win the free PROM set, do not respond in this thread but send me a private Applefritter message. These are the rules ! Any further violation will forfeit my rewards !

Hi -

here is the promised solution of the riddle. There were no entries so nobody was interested in winning a free PROM set with the extended ACI functions.

Or maybe nobody dared to try find the answer to avoid embarrassment ? --- this is the reason why I had made the responses (to be sent by private message to me) non public.

Or maybe all the 6502 gurus have died out ?

Or no gurus read my posts ?

Anyways, here is the solution (danger: long read !):

After you know it, it's so trivial and simple and straightforward you would say it's child's play and obvious.Except that it is not.

Here is what happens:

1. The ACI generates the TAPE OUT signal by toggling a D-Flipflop in the 74LS74. The toggle happens when any address in the range $C000-$C0FF is accessed by either a read or a write cycle. So the actual I/O feature is controlled by the addresses only. This is a typical Woz trick which allows for reduced TTL count and efficient coding. In contrast, in any canonical 6502 I/O scheme, such as suggested by all  the application notes by MOS Technology, Synertek and others, any change in any I/O port requires to be a write cycle. This means one signal more to decode (the R/!W signal of the 6502) and hence, needs more gates. It also needs more code, to load the desired output port state in a register to write it to the port in the next instruction. This load costs additional 2 bytes. So if you allow the address only, combined with PHI2, to set an output port to a desired state, you can save something like two gates and two bytes of code. I first saw this technique in Woz' work. In the Apple-II it is called "soft switches".

I always thought it's a stupid trick against the common lore and against established engineering practices. Until I started to design my Disk-1 controller for the Apple-1 based on the Woz machine some 42 years later and wrote the RWTS for it (still work under progress). Then I saw in its full glory how powerful this trick is. You can do everything in less CPU cycles and you can read and write data while changing the mode of the Woz machine in the same single instruction ! In his Disk-II controller which almost nobody fully understands how it really works, Woz even did exploit the odd so-called "phantom read" of the 6502 STA abs,X instruction to change the mode of the Woz machine from "SHIFT" to "LOAD", just before the following write cycle, so it will grab the next disk nibble byte off the data bus just at the right time ! This is the handwriting of a true genius. Thinking outside the box ! This kind of inventiveness may lead to surprising results that blow the competition - who follows the common lore - out of the water. Alas, down the road, and more often than not, there are unintended consequences of such trickery. Apple had to pay a lot of money to develop the "Integrated Woz Machine", or "IWM", when they started to use the 65C02 processor which had the "phantom read" bug fixed. But with the gazillons Apple had made with the Disk-II system being so cheap to manufacture thanks to Woz' innovative tricks, they could afford it.

2. When I wanted to expand the PROM space of the ACI from 256 bytes to 512 bytes, I took the most obvious route and cut the A9 line from the address decoder circuit to use it on the PROM. A9 was the first address line being available for that purpose, so why not use it ? Note that A8 can't be used to expand the PROM space because it discerns between the ACI PROM (A8 = 1) and the ACI I/O (A8 = 0) pages. The outcome of this little and harmless looking mod is that the 2nd page of the 512 byte PROMs appears at addresses $C300-$C3FF. Everything else used in the unmodified ACI is still there: the I/O page at $C000-$C0FF and the page with Woz' original ACI firmware-in-PROM at addresses $C100-$C1FF. Everything the same as before as far as Woz' original ACI is concerned. From the standpoint of Woz' firmware, nothing has changed. It can't know about the added 2nd page. Or so I thought. Big mistake ! If you have any brain at all you can easily see that the I/O page of $C000-$C0FF, after the mod, also appears at $C200-$C2FF. I knew that, of course. But I did not think of anything evil. As no instruction in the firmware ever accesses that page. Or so I thought, after using the force and reading the source.

3. Now how come that the glitch appears when the same software is running in the extended PROM but does not manifest itself when running in RAM - the only difference being the relocation ? How come that the glitch appears after every 8th bit ? Any real 6502 wizard / guru could explain that by knowing the above facts and inspecting the ACI firmware code. The original ACI code written by Woz back in 1976. So the glitch is latent and only gets activated by the A9 mod. But the code accesses the I/O page only once in all the write routines. This is the LDY FLIP,X instruction at address $C1EA. And it it easy to verify that this instruction does not produce the glitch. So what does produce it ? No 6502 wizards anywhere ? Are they all but extinct ? Died from old age ? Hello, anyone out there ?

4. Here is the relevation. Let me enlighten you ! Look at the one subroutine that is called after a byte has been written. It's name is INCADDR and it begins at address $C1F1. Inspect it closely. There is no access to the I/O page in it. Agree ? But this function toggles the 74LS74 flipflop and this causes the glitch. So how come ? Can you explain the mechanism ? No 6502 wizards anywhere ? But I repeat myself.

5. May I guide your attention to the RTS instruction at the end of this subroutine. I was able to prove that this is the instruction which makes the glitch. But it is not supposed to do it. So how come ?

6. Real 6502 wizards / gurus know the answer. They always knew it. Even I knew it, 40+ years ago. But I forgot. And so I wasted one week of my life hunting down the root cause of that glitch. It trivially easy. The 6502, after fetching an instruction opcode, always fetches the next byte, at the next address, while it ponders what to do with that opcode (yes, it is that slow and stupid). The RTS instruction is no exception from that rule. After the RTS opcode ($60) at address $C1FF has been fetched, the 6502 proceeds to fetch the next byte at the next address, which is $C200, in the next CPU cycle. Because after my neutralisation of A9 in the ACI memory decoder, this now is a mirror of the $C000-$C0FF. And the 74LS74 toggles. Which produces the glitch. It is so simple a 7 year old kid could understand the mechanism. At this age - called the "age of reason" in some religious circles - I already did read pulp SciFi stories in dime novels for adults I snatched from my dad's living room drawer. My classmates still did read Dr. Seuss and the Grimm brothers. But I was immersed in fusion reactors, hyperspace engines, ray guns, robots with 'positronic' brains which to me appeared to be smarter than the human protagonist(s), 'paratronic' shield generators and strange worlds full of weird alien life forms. The age of reason ! (Sigh !) But I think that these pulp SciFi stories had a great influence on my life and career, as electronics often were the "magic" ingredient of most of these fantasy machines.

So, now, the story of the glitch is told. After I found out the root cause, I ruefully reconnected the A9 address line to the ACI address decoding logic, just as Woz had designed it, and the glitch was gone. But my 2nd PROM page also was gone. So I cut the A10 address line from the decoder and used that 'new' line to select the 2nd page of the 512 byte PROMs. And all was good. The glitch did not rise its ugly head again. And the 2nd page was activated. Alas, it now was at addresses $C500-$C5FF, and not at $C300-$C3FF anymore. Which ruined the #4 PROM as one damn nibble had changed from 3 to 5, due to the required relocation of the code.

You may now ask yourself how I found out. Most engineers would have used a logic analyzer. But I was too lazy to repair the mine and put it together again. So  made my own "logic analyzer" out of a single piece of wire. Yes. A single piece of wire !

You read correctly. This single piece of wire connects the clock input of the 74LS74 of the ACI to the NMI interrupt line on the bus. I also wrote a short interrupt handler (a dozen bytes or so) which pulls the return address of the stack and displays it in hex, using the PRBYTE routine of the Wozmon, and then jumps back into the Wozmon. With this makeshift logic analyzer, I was able to see where the glitch came from. There is a little bit of wizard knowledge involved, though. Because you need to know how long it takes for the 6502 to actually acknowledge the NMI after the NMI line was pulled low. All the datasheets of the 6502 I know of avoid the topic of interrupt latency like the plague. But if you have the transistor level circuit diagram of the 6502, you can trace the NMI signal and find the delay (in CPU cycles). Armed with this information, I was able to identify that nasty RTS as being the culprit.

Wow, that was a long story. But I felt I just had to tell it with all gory details for posterity. How a seemingly harmless mod can cause so much trouble in a 6502 system. The trap has been set in the year 1975, when the 6502 was designed, and they sped it up by "always fetching the next byte", and in 1976, when Woz decided to use his "address only control" trick for his output ports. And 45 years later, nearly half a century later, I fell into that trap.

I don't feel too smart about all of this. But advanced age always is a credible excuse for any such stupidity. I've probably forgotten more details about electronics that most current electronics professionals will ever know in their whole career. I even used to know tubes, such as Triodes and Pentodes ! And DTL ! And TTL ! And PMOS ! And NMOS ! --- all technologies of the past, and all extinct and almost forgotten now. They went the way of the dinosaur. All the cute circuit tricks for these dino parts now gone and forgotten ! What a waste !

But for me, it was a good run riding the wave of the rise and fall of the microprocessor. With "fall" I mean the prices, of course: Nowadays they are so ridicolously cheap that hardly any of their manufacturers makes a good profit with them. So all we can do now for fun is to scavenge the fallout from the "golden era" of the 8-bit microprocessor. Apple-1 is part of this. To make my point clear, and show what I mean, just look at the amount of US$ you have to pay for one single Signetics 2519. And compare how much Raspberry Pi you can buy for the same amount of money.

And you can't run Linux on the 2519. (See my point about the prices !)

Comments invited !