> >
> >> 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