> On 5/30/2015 8:40 AM, Simon Clubley wrote:
>> On 2015-05-29, Don Y <firstname.lastname@example.org> wrote:
>>> On 5/29/2015 2:29 PM, Simon Clubley wrote:
>>>> On 2015-05-29, Don Y <email@example.com> wrote:
>>>>> The "normal" application was obviously too long to bit-switch in
>>>>> like this.
>>>>> A tiny bipolar ROM (I think 16x16 -- or maybe 32x16?) did the normal
>>>>> bootstrap... which loaded the image from a "data cassette" (the
>>>>> "Compact Cassette" format that was popular for music, at the time).
>>>>> Once loaded (into *core*), it was persistent, of course. So,
>>>>> power-ups just caused the code to start running immediately
>>>>> (cassette load
>>>>> was pretty slow).
>>>> Ok Don, you are now making me feel old - I've also done the load
>>>> from cassette routine. :-)
>>> From *data* cassettes? Or, from *audio* cassettes (Kansas City
>> Good point. :-) The Compact Cassettes in question were sold as audio
> I suspected. These were special data cassettes. IIRC, a clock track
> was prerecorded on the media. The tapes would go bad frequently.
I worked on a design once to pull data from a tape like this. It had a
clock track which was solely to control the tape movement and the data
was Manchester encoded. The company I worked for "inherited" the design
from someone (perhaps a government facility) who wanted it to be sold
commercially. The design wasn't bad, but they forgot a few things that
you just don't do in production like leave TTL inputs floating. It
would have very intermittent errors from a FF being reset randomly (open
reset input). That took a while to figure out.
I remember learning about CMOS being sensitive to static discharge. I
don't recall how I picked up a charge, but I zapped a board of mixed TTL
and CMOS. When I debugged it I found that nearly every CMOS chip was
zapped while the TTL was all good. This was *long* before anyone was
wearing wrist straps for static control.