ACI output flip-flop question

... the ACI works with "toggle" information only, so the starting state of the flipflop is irrelevant.

During readback from tape the software counts cycles between changes on the port (which is a trick circuit using the tristate drivers of the PROMS, one 74LS125 saved, cool Woz trick !)

Depending on how many CPU cycles this takes, a "0" or "1" bit is discerned.

The actual timing is the same as in the APPLE II so all the information about the tape format can be found elsewhere.

The only difference is that the APPLE II attaches a checksum byte (EOR checksum) to the end of each record.

The Apple-1 has no such checksum as it can't be done in 256 bytes of firmware.

My "extended format" PROMs for the ACI which come with my kits add the checksum so these recordings can be read on Apple II and unmodified Apple-1 ACI. Full forward and backward compatibility.

This proves that the APPLE II inherited all "genes" of the Apple-1 cassette interface. It's essentially the same thing and much the same code, except they had more ROM space available and could add the checksum byte.

The TAPE IN channel in the APPLE II uses a 741 opamp in lieu of the LM311 comparator used in the ACI but after investigating both circuits I'm not so sure which one is better. IMHO most of the issues with the ACI might come from the pollution of the unregulated "-12V" power supply line feeding the LM311. If this is disconnected and the LM311 pin #4 is tied to its pin #1, the ACI still works (even in "replicas" having no negative power supply rail) and I got the impression that read back might be marginally better with that  mod but it never works great with real cassette recorders. With AIFF or WAF files played from a media player it works fine if played loud enough. All this assumes Mike Willegal's mod (100nF input coupling capacitor in lieu of 10nF) is applied. There is not much else that can be done to improve readback reliability.

Actually, even the Start bit polarity never matters for the Apple-1 or Apple II. All the firmware looks for is toggles, or polarity flips, and how much time transpires between the flips.

As for your suspicion if half a start bit works worse than the full start bit, it does not matter. If only one half bit in the whole stream is wrong, the read process will get derailed (and turn into the proverbial train wreck).  The Apple-1 will not tell you about the train wreck, but the Apple II will. With my extended format PROMs the Apple-1 also supports a checksum and so it will also warn you - unless it runs out of bits in the record, then it will just hang. Even 512 bytes were not enough to put in a "timeout" function. This limitation came about because I did not want to touch Woz' code in any way so my "extended format" PROMs will also work in unmodified ACI cards. Furthermore, modifying Woz' code would be regarded as desecration by many purists. And since the top levels of the Woz' code are no subroutines, I had to squander a lot of my added 256 bytes of code space just to recast them into subroutines. In the end there was no room for the CRC check and the timeout (the EOR checksum is there). I could do CRC and timeout if I had the whole 512 bytes for myself and could write everything from scratch. But 256 bytes more only get you so far ... the deficiencies in the original ACI code are not incompetence but it's simply impossible to do more than Woz did in his original 256 bytes. His code is super tight and even the parser has a nasty feature: you have to enter four hex digits for all addresses or you get in trouble. As my added functions also use Woz' parser as is the same "feature" is in my PROMs. Sigh ! I still wonder how some early pioneers did a BASIC in just about 1 kByte.

If you want to experiment, send me a PM and I'll give you the PROM image so you can experiment. I normally sell it only with the PROM set in my kits and as far as I know only two people in the world actually did the mod and use it. Still, better than to leave the 2nd page in these PROMs empty. The irony is the greedy IC brokers want much more $$$ for 256x4 PROMs than for 512x4 PROMs. Pay more, get less. At the moment only macintosh_nik from Russia can sell Apple-1 PROM sets (using 256x4 PROMs) for a good price, because he uses Soviet era 256x4 PROMs (which work fine in the Apple-1). Which I would also use for cost reasons if my Data I/O could program them, but it does not like "Communist" PROMs ;-) It's a cold war era American made programmer, see ! This is really a nasty situation because the IC brokers got crazy and want moon prices for all parts now. I refuse to buy parts at usurious prices as a matter of principles. Shall these greedy usurers sit on their overpriced parts until their ICs crumble to dust ! We Apple-1 aficionados are the only buyers for the Apple-1 specific parts and when we boycott those usurers we will win ! So don't buy any parts at usurious prices ! Boycott them ! There are alternatives ! Uncle Bernie will show you these alternatives !

About the software to make AIFF files for Apple-1, Apple II, and extended format ACIs, I've already written it, it's called "Uncle Bernie's ACIace", but I struggled a long time with finding the right volume defaults and there were many mysterious reports about it failing on some older iPods. So I took the tags out and increased the volume. Reports of my beta testers told me it now works with the iPods which failed before. But the jury is still out if the tags which I put back just a few days ago do not cause some other problems. I already noticed that the Windows media player stutters when it plays my files. I avoid using  Windows because I think the newer versions are junk - XP was OK as far as Windows goes but obviously Microsoft has replaced the magicians who gave us XP with a bunch of idiots. So I prefer Linux just to see the same kind of rot and bloatware there.  Every new release is more obese and needs longer to boot. But at least the media player of Linux mint plays my AIFF files without a hitch. I don't know it's just my own programming incompetence why the Windows media player chokes on my AIFF files or not. Ironically, if I first run Jimi Hendrix "All along the Watchtower" through Windows media player it sounds OK and afterwards it even plays my own AIFF files without problem, and the Apple-1 can read them. So, maybe there is self conscious AI involved in the Windows Media Player which refuses to work unless you give it some candy first. These are the days I want to go back to DOS on a 80486. Good enough to play DOOM and HERETIC. Oh, and DUKE NUKEM. I don't need to talk to a computer using a mechanical rodent which eats away the cartilage in the joints of the fingers, like a rat chews on baby toes.

All these troubles with modern media players and iPods and other "Pods" kept me from finishing this work now for almost half a year. The synthesis section seems to work (other than the Windows Media Player issue) but the analysis section is still rudimentary (reads AIFF and WAV and turns them into binary files). Since I'm a one man show and have too many open projects I'm not making good progress anywhere. And I don't want to publish unfinished and unpolished junk. I leave publishing crappy software to the usual suspects with the big names.

Comments invited ! (Maybe somebody ahs an idea what is wrong with Windows Media Player / of Windows 7)

The change to .1uF from .01uF actually isn't mine, it was done by Apple when they moved to the Apple II. This change alone makes the Apple II much more reliable than the Apple 1.  I don't think the other changes make that much of a difference, but they probably help a bit.

During the Brain Board project, I ported the Apple 1 monitor and cassette driver to the Apple 2 and anyone with a Brain Board is able to read and write Apple 1 tapes on the Apple II with the Brain Board software.  I did tweak timing just a hair as clock speeds of the two systems differ slightly.

Most of you probably know this, but when reading Apple 1 tapes, a common practice is to compare the last two bytes of the load with what was supposed to load, and if they are correct, you probably have a good load.  In practice, this is probably about as reliable as having an actual checksum.

When I worked on the SCELBI, an earlier 8008 based system, I was impressed by two things about the cassette interface. 

 1) how much more reliable the SCELBI is, when compared to  Apple's cassette interface

2) how much slower the SCELBI tape interface is.  It is glacially slow. 

After so many years of futzing with the Apple cassette interface, it always amazed me how, on the SCELBI, after 5 minutes of reading a tape that you would almost always have a perfectly loaded program.  The SCELBI uses a FSK mechanism so it wasn't near so sensitive to noise.  It also had some front end hardware to automatically adjust input gain level so it isn't near so sensitive to tape deck output level.

Was the cost of the extra hardware and slower speed of the SCELBI cassette interface worth it to increase the reliability?  What do you think?

regards,

Mike Willegal

In post #6, Mike Willegal asked:

"Was the cost of the extra hardware and slower speed of the SCELBI cassette interface worth it to increase the reliability?"  

"What do you think ?"

Uncle Bernie's opinion and tales from the past (Warning: long read):

I don't know the SCELBI cassette interface but I remember very well the KIM-1, and the SYM-1, and the AIM-65, and all these cassette interfaces were painfully slow but did work very well. I friend of mine (which I envied for his machines which included a real ASR-33 Teletype his dad, who worked in the computer business, was able to get for a song). Since I could not afford a KIM, I designed my own 8080 based KIM substitute which had much the same specs: 1K ROM (I used a 2708 EPROM, KIM had ~2K ROM), 1K RAM (2 x 2114), a 6 digit seven segment display, and a hex keyboard. An uncle who worked in the telecom industry could get me a 8080 and a 2708 for free out of their junk bin as they already had moved on the the 2716 and the 8085 (which were +5V only). My cassette interface also did work very reliably despite it did use even less components than the ACI, and it was faster than the KIM's, but slower than the ACI. I did use no LM311 or such, just a TTL gate configured as a linear amplifier.

To fully appreciate the pros and cons, here is the relevant technical background what makes all the difference:

The KIM (and many other contemporary microcomputers) used, as Mike correctly stated, FSK, or "Frequency Shift Keying". One tone (several cycles long) would be a "0" and another tone (again several cycles long) would be a "1".  One example how this works is the ancient "Kansas City" Standard, see:

https://en.wikipedia.org/wiki/Kansas_City_standard

The overall thing works much like a 300 baud modem of the time which sent data over the telephone network. Phone lines of the time had poor bandwidth and a lot of interference (crosstalk from other lines, voice, dial tones or dial pulses spitting into the channel, etc.). So the system is made robust against all that by making the signal very redundant (this is the reason for the tones being "several cycles long").

The real magic happens in the receiving circuit: it uses a PLL, or "phase locked loop". Proper configuration of the loop filter makes it very robust against random glitches, noise, or speed variations (the latter being no issue on phone lines, but tape speeds will vary).

In the KIM-1, a LM565 PLL IC was used. It is configured such that its built in VCO (voltage controlled oscillator) tracks the input tone coming in from the tape. All what is left is to filter the VCO control voltage (to clean it up) and to compare it against a fixed threshold voltage (the LM565 makes one at its pin #6). This adds another IC, a comparator, like the LM311 known from the ACI.

I do not want to show you the math behind a PLL (it's nasty differential equations in the phase domain) but I give you a little model:

Imagine an old farm tractor with an engine having a huge flywheel. All you can control is the throttle (the VCO control voltage). You can manipulate the throttle to increase or decrease the RPM of the flywheel (change the VCO frequency) but the change in RPM is not instantaneous. The whole system has inertia. But eventually you could adjust the throttle such that the flywheel spins with a higher or lower frequency of your choosing (RPM is the same thing as frequency). Whether the frequency is high or low you can see on the throttle setting. As easy as that. A real PLL goes further: if you put a mark on the flywheel and bring another tractor close to it with a similar mark on his flywheel, the man at the throttle (the PLL) would adjust the throttle such that his flywheel runs exactly at the same RPM as the flywheel on the other tractor, AND the marks would align to be on the same spot all the time: when the mark on one flywheel is in the highest position of the circle, the mark on the second flywheel would be there, too. Both engines  would run in perfect synchrony. In the electrical grid, the "flywheels" are the turbines and generators turning in the power plant. All these must be perfectly synchronized all over all power plants in the grid. Modern semiconductor based power converters make it easier, but for a plain old style power grid, PLL techniques are used. If you fly small propeller driven twin engine aircraft, there is an electronic gadget called a "synchrophaser" to make the propellers spin at the same RPM and the same phase. This avoids nasty beat frequencies which are not only a nuisance, but also torture the crew and the passengers. 

This perfect synchrony is called "phase lock". But for FSK decoding, acquiring phase lock is not even needed.

It should be obvious that such a PLL based system:

a) is slow to respond to changes in frequency

b) has built-in inertia

c) is not easily thrown off by any disturbance (i.e. occasional misfire of the engine = dropouts or glitches on the tape signal)

So by adding these features via a PLL, which costs money, you get a much more robust, but slower, tape signal receiver system.

The added components (over the ACI) are: 1 x NE565 PLL IC, 4 x diodes, 1 x trim pot, 6 capacitors, 2...3 resistors.

Except for the IC and the trim pot, all penny items. (The KIM-1 used much more expensive quality capacitors than needed ... obviously digital designers who did not really know what they were doing with that PLL, the circuit is copied out of the NE565 datasheet).

Can it be done without a PLL ? Yes, the 6502 is fast enough to emulate a PLL in software, so you could build a FSK decoder in software.

But there is even a simpler way. My own 8080 based computer used a pulse count method. I don't remember all of it, but it was something like 2 pulses followed by a pause would be a "0" and 5 pulses followed by a pause would be a "1". Super easy to code and very robust against the occasional pulse being missing or being added by a glitch.

Since both the Apple-1 and the Apple II have completely software based encoding or decoding of the tape signals, and there are no filters of any kind involved, all these techniques could be implemented in software and then enter a tournament to find out which one offers the best compromise between robustness and speed (you can't be robust and fastest at the same time).

Like so often with my drivel it got much longer than planned, sorry. But I wanted to show you the background and the options.

And based on the above I can boldly make this statement:

It's not so much how much money you want to invest into the hardware for a more (or less) sophisticated tape recorder based mass storage system, it's more about how much brains you have and can invest into sophisticated software algorithms to do the same thing as the more elaborate hardware would do.

The last thing we need to consider (to be fair) is how much does the memory cost to hold and run these sophisticated algorithms. We could make the point that back in the year 1975, memory was very expensive and so costs for sophisticated firmware in (P)ROM was prohibitive and the LM565 PLL solution most likely was cheaper. Maybe you could make a very slow but robust and still small enough firmware solution which loads a 2nd stage loader from tape into RAM, and this one would be the sophisticated, faster, and still robust tape decoder software. These solutions were going by the name "Turbo-Tape" or similar and these were quite popular with home computers in the 1980s for those less wealthy kids whose family could not afford a floppy disk station. The Brits with their Sinclair ZX and Spectrum were prime candidates for that.

But with only 256 bytes of PROM as Woz had in the ACI ? No way. 

Comments invited (maybe I've inspired somebody to experiment and start writing some better tape I/O software for the Apple-1).

- Uncle Bernie

In post #8, nippur72 wrote:

"In my experience the "pulse count method" for FSK performs worse than PLL or other specific methods".

Uncle Bernie answers:

Do not confuse the pulse encoding method I used with FSK. All the pulses I used had the same width and distance, so it's the same tone.

Such a group of pulses would be terminated by a much longer space with no signal (I think it was more than 2.5 times the regular pulse period, but I'm not sure, would need to inspect the 8080 code).

I agree that a FSK decoder based on mark and space filters has a better performance than typical PLL solutions. Acoustic modems used such filters. But you can't make good analog filters with cheap components. This is why none (as far as I know) of the hobbyist computers of the 1970s used that approach. For a modem costing as much as that microcomputer the expense of the high quality components for the filters is feasible.

I think that back in the 1970s, a lot of development money has been sunk into the whole "cassette recorder as a mass storage device" engineering rathole.

Regardless how much money you put in, you never get the desired fast and reliable mass storage system out.

It seems they finally gave up and designed custom cassette recorders where the write and read circuits were specifically designed for the signals in question. The Atari 410 had a stereo head, so it could play back the data signal on one channel and a voice / music signal on the other channel. Commodore also had their own, custom datasette recorder. Tandy / Radio Shack TRS-80 used a cassette recorder which looked much like a standard model out of their catalog, but I dimly seem to remember they claimed the one in the TRS-80 system was "specially adapted" to the system.

It would be really interesting to experiment with modern modulation systems like QAM on ancient cassette recorders to see how far we could get. But this, of course, is yet another engineering rathole, and with no commercial benefit anymore.

The SCELBI used HW filters in the FSK detection circuit - as stated before,  in my experience works very well.

regards,

Mike Willegal