Re: Analog Cell Phones]

> >
> >> The alarm industry still makes use of AMPS cell phone systems for > >> connectivity from their client=3Fs premises. In March 2006 an Alarm > >> Industry Communications Committee petitioned the FCC to extend the AMPS > >> =3Fsunset=3F date by two years to February 2010. They asserted that there > >> were more than a million analog alarm radios and they say that there > >> just isn=3Ft enough time to change all of them out by February 2008. > >> Never mind that they have already had several years to change their > >> equipment. One of my =3Fmottos=3F is: Lack of planning on your part does > >> not constitute an emergency on my part. > >> > >> > > > >The alarm industry seems to always be behind the power curve. Some of > >them still use dial pulse instead of DTMF for wireline dialing. > > > > It wasn't all that many years ago that the phone companies charged a > premium for DTMF dialing, which adds up over time. > > For an automated application, using DTMF may speed up your dialing by > a few seconds, which really dosen't matter in the end. > > I recall that one of the other arguments that the alarm industry used > was that the manufacturers had been very slow in making replacement > products available, and that replacement equipment was still in short > supply. In other words, they could not do upgrades because the equipment > was not available. > > >

One of the really interesting aspects of alarm systems it seems many of them use the Z80 CPU. I still remember some of the opcodes for that processor.

***** Moderator's Note *****

My first "real" computer was a Heath H89, which also had a Z-80 processor. IIRC, it had a nice "area move" capability that the 8080 didn't, allowing a programmer to move blocks of memory around with a single command instead of by calling a subrouting to iterate through the memory range.

I was running CP/M, and I had to modify it so that it would send EBCD code to an Anderson-Jacobson 841 printer, which I had bought at the M.I.T. surplus store: the machine was a Selectric typewriter, with solenoids on the bottom of the mechanism to allow the (RTL) electronics to drive it.

The AJ-841 used EBCD code, which is not the same as EBCDIC: it's a six-level code, which means that there are only 64 posible bit combinations, so it includes "shift" and "unshift" characters, just like Baudot. Using the shift/unshift combination gave 126 possible codes, which was enough for most use.

The Z-80's "area move" was really nice to have because I could cache a line of ASCII, move it to another memory area with a single opcode, and then put it through a translation table to get from ASCII to EBCD. In addition, I had to account for the current "shift" or "unshift" state of the mechanism, and insert appropriate codes to shift or unshift as needed. There was also a keyboard lock feature, but I didn't care about it because I only used the machine as a printer.

The weirdest thing about the AJ-841 was that the Selectric typeball was 90 degrees off from normal: if I changed the custom ball that came with it for a "civilian" ball from a regular selectric, I had to also change the ASCII > EBCD lookup table to account for the new ball having the "wrong" characters in the positions that the OEM ball used.

Since the AJ-841 had a built-in modem, I looked it up in the Tymnet compatibility list JFL, and was astonished to discover that Tymnet would support it: not only would Tymnet allow me to log on with the EBCD codes, but it would provide "on the fly" speed and code conversion when I was talking to an "ASCII" node, which meant that I could use it directly with Prodigy. Needless to say, that was before HTML and the web, when emails were _always_ text.

If I think about it for a while, I'll probably be able to remember the divisor that I had to load into the 8250 UART to get 134.5 baud output...

Ah, the good old days.

Bill Horne Temporary Moderator