Up one level (RSS page)
Up two levels (Moto index)
Back to Home
  An overview of the Motorola Radio Service Software (RSS), its history, problems and some solutions   Print this Page

Background Information Part II

Editors note: This article mentions DOS and windows extensively. To put things in context, there's a timeline, from earliest to latest, at the bottom of this page.

One of the contributors to these RSS and RIB writeups has friends and relatives that live in many places, including Chicago and in Indianapolis. Motorola Communications Division is based in Schaumburg, a suburb just outside of Chicago. One year in the mid 1980s he visited his midwest clan over Thanksgiving, and the return trip consisted of an Indianapolis to Chicago hop then a plane change for the Chicago to his home airport hop. The first hop went fine but the second hop was delayed due to problems with the aircrafts hydraulic system (the mechanics and the pilot both thought that having landing gear that worked would be nice...). He ended up sitting in Chicago's O'Hare airport waiting area for almost six hours. Two hours into the delay he finished his book, reached into his briefcase, pulled out an HT200 handheld, called a local friend on the Chicago 146.85 repeater and asked him to call his home and let them know he'd be delayed even longer (this was long before cellphones). The gentleman sitting next to him in the waiting room was interested in the radio and asked about it ‑ he'd never seen a six-frequency HT-200 (stock was two channels maximum) with eight switchable PL encode tones (max was one tone, and that required the long case) and a 16-button backlit touchtone pad (touchtone in any form wasn't available at all) ‑ and they started talking. In the course of the conversation the gentleman claimed that he worked for Moto Land Mobile Research and Development. They got to talking about radios, computer controlled communications, early PCs and S-100 CP/M computers. The gentleman was also interested in our contributors background and the fact that he knew Moto's mobile and handheld product line pretty well. One of the comments the gentleman made was that the design engineers "never get a chance to talk to the end users, or to the radio enthusiasts..." He likened the design process to "We get some specs and maybe a wish list of features, we design something, build a prototype, then throw the new baby over the wall into marketing and production. The designers get some feedback from marketing, less from production, and never, but never, hear anything back from the taxi drivers, ambulance drivers, firemen, school bus drivers, construction workers, the military, or the cops on the beat". During the next four hours of the departure delay the gentleman told a few tales about early synthesized Motorola radios... he sounded like he had been there for each one, and to this day our contributor wishes that he had tape recorded the converastion and asked him for a business card.

As the story he was told went, Moto's first PC-programmed radio to make it out of the lab was the 800 MHz Mostar ‑ a real dog of a radio (the fact that it was the first really shows). If you glue a sheet of ribbed rubber to the bottom they make pretty fair doorstops... and by the way, if you have a schematic (even a reverse-engineered one) of the Mostar programming / interface box (the "MIB") please let repeater-builder know ‑ the schematic never got out of Moto, not even in the official MIB manual.

As the story went the Mostar project manager and the project staff were all RF and what today would be called embedded processor engineers. After finishing the radio design they knew they were in way over their heads on the PC programming. All of the versions of MS-DOS / PC-DOS at that time had serious shortcomings in the serial port BIOS (which at that time was practically worthless as it wasn't interrupt-driven, nor did it have a buffer) and the serial drivers built into DOS (which wasn't much more than a handoff to the serial routine in the BIOS). As a result most software packages of the era bypassed everything and talked directly to the serial port hardware. Because of the poor DOS serial port driver, Moto elected to purchase a serial port driver package from a local software house which later folded, and all the people from it evaporated. Nobody on the Mostar project was knowledgeable enough to recognize bad MS-DOS programming methodology, and didn't catch the fact that the package had CPU-speed-based timing loops. On top of that Moto did not get the source code... this meant that they couldn't fix it (or have it fixed) when the faster computers became common.

One comment I have heard from several people (independently, and in different words) is that earliest RSS looked like some summer interns work-study project poorly pasted on top of a kitchen table programmers half-finished serial port driver... and it didn't get much better until the rewritten serial driver came out. The same people remarked that the evolution of the RSS suggested that Motos programmable radio designers and programmers were learning PC programming as they wrote (and rewrote) the RSS. It wasn't until Moto hired some real, professional programmers into the mobile radio group (and they rewrote the serial driver, among other things) that the RSS became reasonably robust and both serial port hardware and CPU-speed independent. Even then it was not unusual to see the disclaimer in the RSS documentation that "Proper RSS execution relies on 100% IBM-compatible PC hardware".

Windows 1.1 and 2.1 were more of a prequel of things to come than a useful product, but there were a few companies that saw the handwriting on the wall and started writing software for the Windows environment (like AutoCad, and Pagemaker). Windows 3.0 and 3.1 were actually useful, was used in business a lot and had a better serial port driver. Windows 3.11 added functional networking and you could actually talk to a file server, a network-connected printer, and to the Internet. When Windows 95 came out Moto saw the handwriting on the wall and the RSS that is specified to run under Windoes 95 and used the serial drivers built into it (for example, the MTS2000 / MCS2000 RSS). When Windows 98 came out the RSS that was in the pipeline was modified to interface to it, and this is why the XTS and XTL series RSS is listed as usable only on Windows 98 and later.

All of the Windows versions from 1.1 through 3.x, plus 95, 98 and ME simply ran as an application program on top of the DOS of the day, and the DOS was modified for each iteration of Windows: Win95, 98, and ME. Under those versions of Windows the applications could totally bypass the operating system peripheral drivers (and even the BIOS), and talk to the serial port hardware directly. Doing this also bypassed and negated any parameters that the user might set with the MODE command, in the BIOS setup screens, etc. Many programs of the DOS and early Windows era took advantage of the this ability to talk to the hardware because the early DOS serial port drivers were so buggy and all operating systems prior to NT (and it's derivatives) allowed the applications to do so. Not until Windows NT, 2000 and XP were applications actively prevented from talking directly to the hardware.

Another problem was that many programs that used a serial port initialized it to meet their own needs, used it, and then walked away from it. Properly written programs of that era that accessed a serial port first read the port status and configuration of it, stored it, and then initialized the port the way they wanted it. When they were finished with the port they restored the port status and configuration the way it was found and then exited. The old elementary school report card line "Plays well with others" comes to mind, but most RSS didn't... When RSS started up the init routine reached out and tweaked the important port settings to the way it wanted them, but not all. This lack of full initialization of the serial port led to the situation where sometimes the behavior of the RSS sometimes depended on which program had last used the port. This caused much head scratching and was why you would find a reminder note taped to the front of the RSS computer in many radio shops: "Don't Forget: hard reset or power cycle the computer between different RSS programs". And the front panel reset button was well used. Those that didn't have reset buttons had them added (the how-to was in the applications note for the Intel 8088/8086/80286 clock generator chip), or was relegated to the radio shop billing office or the payroll office.

Any RSS whose release note states that it will run under Windows NT, Windows 2000 or Windows XP and is run under one of those operating systems will have no problems programming older radios since those later OSes force all applications to go through the operating system to talk to peripherals ‑ sometimes referred to as the "Mother, may I?" protocol. Unfortunately there are a large number of RSSes that predate this proper behavior ‑ for example, the last release of Saber handheld RSS was in December of 1995, right about the time that the Moto RSS group began to figure out that they had a major problem with no easy answers. The oldest RSS is the most sensitive to CPU speed, and supposedly the earliest Saber RSS (and others of that time frame, like the R100 repeater) works only on 286s that have any BIOS-managed cache memory turned off.

Another problem with old RSS is the actual hardware serializer / de-serializer chip embedded in the PCs COM port. But first, a bit of history:
The earliest integrated serial chips were the Western Digital WD1402A that was first marketed around 1971. It was designed by Gordon Bell for the Digital Equipment PDP series of computers. This "Universal Asynchronous Receiver-Transmitter" chip (commonly called a UART, commonly pronounced "You-art") was a big advance over the previous serializing and de-serializing methods ‑ ones that took a dozen or so TTL chips and were limited to one data byte format (perhaps 8 bits, no parity, 1 stop bit time), and at one, or maybe two speeds/baud rates. For an example of a multichip implementation look of the schematic of the serial port cards made for the early Digital Equipment Corp. PDP series of minicomputers, or their Data General, General Automation or Computer Automation competition.

The UART, with all it's internal complexity and outward advantages, still handled one byte at a time between the CPU and the outside world and needed from one to six chips (sometimes called "glue logic") to let it talk to a microprocessor memory or I/O buss.
By the way, a dual UART, or DUART, combines two UARTs into a single chip package. The USART (universal synch/asynch receiver/transmitter) added synchronous data handling. But we are getting ahead of ourselves.

The next generation serial chip took the basic UART core and added the glue logic into the chip package itself. The resulting chips interfaced directly with the CPU chip I/O buss, and another enhancement added a data register between the UART logic and the outside world - this allowed a second byte to be brought in while delivering the first one to the CPU... if 10-bit or 11-bit characters (start bit, 8 data bits, an optional parity bit, and 1 stop bit) were being received the program had the start time plus the data bit times plus maybe the parity bit time of the second character to fetch the first one, but there were very few situations that used both 8 bits and parity... 95% of the time the requirements were either 8 data bits, no parity and 1 stop bit (abbreviated 8N1) or 7 data bits, even parity and 1 stop bit (7E1).

These directly interfacing chips were the Intel i8250 (second sourced by National Semiconductor as the NS8250, and also called the WD16450 by Western Digital) and were used in the original IBM PC, XT and early AT. Unfortunately a lot of the RSS was written to talk specifically to these specific chips since at the time that's all that there was and the serial chip manufacturers were pretty quiet about what was in the design pipeline (they understandably didn’t want to tip off the competition). The 8250/16450 chips were adequate with the serial speeds of 2400 baud or less, and CPU speeds of 4.77 MHz (or hot-rodded to 16 MHz).

The next two paragraphs assume a 7 bit data byte, even parity with 1 stop bit. The data stream could be at speeds ranging from 50 bits per second all the way up to 38,400 bits per second.

To send data the CPU would transfer a data byte to the chip, which would send the start bit (always a zero) then the data bits (5, 6, 7 or 8 of them), then the optional parity bit, then the stop bit(s) (which are always ones). The length of the stop bit could be programmed to be 1 data bit time, 1.5 or 2 data bit times (the option of 1.5 or 2 stop bits was for backwards compatibility with the old mechanical teleprinters, and most computer-to-computer data communications used 1 stop bit just to speed things up. Yes, the early serial chips maintained backwards compatibility with the machinery of the prior day).

The chip received serial data by watching the incoming data line, and when it dropped from a 1 to a 0 (the incoming start bit) it started an internal timer. It then sampled the data line in the middle of the each data bit and built the received data byte from those samples. After the 8th bit was received the chips internal hardware built a test parity bit from the first 7 bits and compared it to the 8th bit of the received data. If it matched it would set the status bit that signals that data was ready. If interrupts were enabled that would interrupt the processor. The amount of time the applications program had to retrieve a new byte from the UARTs received data stream could be as short as the duration of the start bit ‑ a pretty short time window at 19,200 characters per second (about 4 to 5 microseconds).

Remember that the older 8250/16450 chips interrupted on each and every data byte, and only offered a one-bit wide window to get the received data byte. This is very significant.

Modem technology advanced as fast as the PCs did, and sometimes faster. It wasn't long until the modem speeds were faster than the 8250 could handle. Later PC serial ports used the 8251 or 8251A (16550, 16551 or 16C552) which, while similar from the hardware designers point of view, did have some very significant differences to the programmer: they added a block data transfer mechanism into the serial chip hardware.

This mechanism is called a FIFO stack or FIFO buffer (standing for "First In, First Out", and pronounced "Fee-Fow"... "Fee" as in feeble, "Fo" as in "focus") and functions like an elastic memory... think of the single teller line at your local bank that feeds a single teller window (ignore the additional teller windows for the purposes of this example)  ‑ that's a single-threaded FIFO ‑ no matter how fast the people enter the queue, or at what rate (steady or in bursts/clusters) they are handled in sequence and at the rate that the receiving system (the teller) can process them. When the FIFO function is switched on it speeds up file transfers tremendously by reducing the number of data transfers required between the serial chip and the driver software. The hardware FIFO buffers can be as large as 1024 bytes, and as small as 8 bytes (the most common chip implementation is 16 bytes). The FIFO buffer in the chip has a programmable "trigger level" or "threshold point" that interrupts the host processor. If the trigger of the receiver FIFO buffer was set to 12 then the chip will capture the inbound data byte by byte until there are 12 bytes in the queue. Then it tells the application to get data from the FIFO buffer by generating one interrupt (the receiving application would have no idea there was data waiting until the interrupt happened, then it would get all 12 bytes when it handled the interrupt). The transfer of the 12 bytes would take place simultaneously with the reception of the 13th, 14th, 15th and 16th bytes, which would end up in the first 4 bytes in the FIFO hardware stack. Applications that can actually use the FIFO can be busy doing something else for up to 15 character time frames, and no characters will be lost. Windows NT and later operating systems like Windows 2000, XP, 7 and all versions of Linux have a smart driver that can handle byte-at-a-time and FIFO mode transparently - the user never has to worry about it.

Applications based on the earlier serial chips were written to handle byte-at-a-time transfers, when the FIFO-based chips came along they had to be rewritten to handle block transfers of data up to 16 bytes. Smart programmers implemented multiple 16-byte (or larger) buffers and had the interrupt handler move the data into them (using DMA), and then pass the full buffers to the application (really smart programmers asked the serial chips how big their FIFOs were, and used that number plus one as the buffer size). The interrupt handlers had until the FIFO filled (i.e. four character times in our 12 byte threshold example) to finish the block transfer. Most FIFO hardware implementations were fast enough that 13 or 14 byte thresholds (i.e. 2 or 3 bytes of headroom) were common.

The data transmission protocol built into RSS has no use for (actually has no concept of) FIFOs and only operates in the byte-at-a-time mode. The functionality of the RSS depends on a closely coupled interaction between itself and the radio's firmware. The RSS transfers small data blocks, sometimes only one byte at a time, and single bytes of signaling or status in each direction. As an example, the RSS could send a "Is there a radio out there?" message (which might only be one byte) and wait for a response, which itself might only be one byte. Once it started the codeplug upload it could send a N-byte block of data (which could be as large as 1 kilobyte) and its checksum, then wait for an "OK" or an "Oops, please resend" acknowledgement back (i.e. a handshaking or status message) before proceeding. The acknowledgement might be as small as one byte. This handshaking protocol depends on no FIFO in the way (or if there is one, to be switched off) so that the serial chip in the PC creates an interrupt for each and every byte of data. If the computer BIOS, the operating system or another application has previously switched the FIFO function on then the response / status message byte will be sitting in the FIFO buffer, and the RSS will never "see" the character because the interrupt is being suppressed until more characters arrive (up to the FIFO trigger threshold level). This behavior leads to "timeout" errors within the serial protocol; the RSS is waiting (until timeout occurs) for the status byte that will never be transferred as long as the FIFO mechanism is enabled... the FIFO is waiting for as many as 15 more bytes that will never arrive because the radio is waiting for a response...). The most common RSS symptom of the FIFO being switched on is repeated errors (usually timeout errors) while trying to handshake with the radio initially, or when trying a read or write (download or upload) of the codeplug into or out of the radio.

Another problem ‑ and the BIG one ‑ in the RSS is deeply embedded in the serial port driver: The actual time interval used by the timeout detection routine is generated within the RSS by simply executing complex time-wasting computer instructions (one popular method of the day was dividing one 16-bit real number (or even 32 bit) by another similar real number) a certain number of times. If a delay of ten milliseconds was needed, and a floating point division took 50 microseconds, then the software would simply do the same division 200 times, throwing away the result each time. The 386 chip had no hardware multiply-divide functions (on some motherboards you could plug in a 387 math co-processor chip into an empty socket to get that option), the 486 had the math co-processor built in. Most RSS used software based multiply and divide routines. Faster motherboards (i.e. faster CPU chips) execute these timing loops faster. If the motherboard has a CPU instruction cache that was left on then the timing loop is almost instantaneous because the processor never has to do any off-chip memory access.

No matter how it happened if the computer outran the radio and the timing loop finished before the radio responded then the RSS wrongly decided that the radio was not going to respond at all and displayed an error message. Later RSS versions had patches that checked for CPU speed (read the RSS manual and release notes for later versions of any RSS of that era) and adjusted the timing loops, but the loops were still there, and would still break if the machine was too fast (or if the CPU cache had been left on). The right way to do the time delays would have been to use the interval timer chip on the PC motherboard (which was there in the original IBM PC model 5150 in 1981 ‑ all they had to do was to read the data sheet on the chip) and tell it (for example) "let me know when N milliseconds have passed, and I'll wait until you do", but the original programmer of the serial port driver took the easy way out and used timing loops, and every end-user of the older RSS has been paying for that short-sighted programming shortcut ever since.

Remember that most of the older RSS was written in the days when computer vendors were selling 286s and cacheless 16 MHz to 25 MHz 386s to the average end-user, and a cache-equipped 50 MHz or 66 MHz 486 was the fastest thing on the planet and generally found only in the software development labs.

Speaking of 486s, the on-chip CPU cache memory can be switched off if necessary. Some motherboard BIOSes have it as a switchable option, many do not. If yours does not, here's a zip file containing CACHEOFF.COM, CACHEON.COM and a text info file. The CACHEON program probably won't be needed as the initialization routine in most computer BIOS turns the cache on during a power-up cycle or after a hard reset (i.e. the front panel reset button). The CACHEOFF program can be added to your autoexec.bat file if you need it. An alternate location is your STARTRSS batch file.

And to answer a common question, Moto has no reason to allocate modern-day programming resources to fix mostly-broken (by modern standards) RSS for radios that have been off the support list for 15 to 20 years and off the sales list for even longer. There is no money to be made doing so and Moto would much prefer you threw the old radios in the trash and bought new radios and the CPS needed for them.

Yes, some enterprising programmer could use a serial data line protocol monitor (several are freeware) and reverse engineer the entire RSS protocol for a specific radio series (like the Saber, the Spectra, the Maxtrac, the Genesis or the Jedi) and from that reverse engineer the RSS program and write a modern replacement (hopefully in open source so it could be compiled for Windows, Mac or Linux). Or in Java or Ruby so it could run on anything. Or someone could write a patch that when loaded would replace / overlay the broken serial port driver with a new one, or even replace it with system calls to the Windows serial driver (yes, that would completely eliminate the speed / timing concerns, plus it would allow the modified / patched RSS to run in a DOS window and to use USB and PCMCIA serial ports and any Windows-supported printer). On the other hand your contributor(s) certainly wouldn't want to be in the shoes of anyone that Moto decided had done any of that software work, no matter if that person actually had done it or not. Trust me, you don't want to be on the defensive from Motos legal department... they make the fictional "900-pound gorilla" (see the note below) look like a bug to be stepped on ‑ just look at the RSS license / legal agreement. But there are anonymous ways to get software out "into the wild".

A possible solution is VMware ‑ a program that was very popular in the Y2K era. It creates a "Virtual Machine" under Windows (there are also Linux versions) that can load and run a program under a very different environment ‑ it was developed to allow testing of operating systems and applications programs in the mid 1990s. I used it to do a little Y2K testing: you could have the host machine running the current date, with the virtual machine clock set to December 31, 1999 and then watch and trace what happened when it rolled over to January 1 2000. I did not have the opportunity to do any in depth work, but on the current versions supposedly you can set the VMware virtual machine environment to 286, 386 or 486 mode and control the apparent CPU speed. If true you could run the 286 12 MHz Saber or R100 RSS in a virtual machine on any modern hardware.
Microsoft also offers a free VM product, but I do not have any experience with it, nor do I know if the serial I/O implementation is flexible enough to run RSS.

Another possible answer is the "dosbox" utility for Linux, FreeBSD, XP/Vista/7 and Mac OSX. It can be found for free download at Sourceforge Supposedly "dosbox" can be configured as to the emulated hardware and speed. However it would need some way to deliver direct and total control (at the hardware level) of the COM port (the serial chip) to the RSS program. Both Linux and XP prevent this as a part of the foundation of the operating system (but there are workarounds).

None of the contributors to this web page have any experience with running RSS on anything except real hardware. Repeater-builder would be very happy to host any article on "dosbox", on virtual machines, or any other solution to the RSS/computer speed problem. And it can be anonymous or with credit, your choice.

Back to PC and RSS history:
Then there are the hardware Interrupt Request lines, commonly referred to as IRQs. Eight-bit machines such as the PC and XT have only 8 IRQs, and the 16 bit machines such as the ATs, 386s and 486s have 16 (but only 15 are available ‑ IRQ2 should not be used as it is the daisy-chain input for IRQ8 and up). Most systems use IRQ4 for both COM1 and COM3, and use IRQ3 for both COM2 and COM4 (on the premise that only 1 or 2 would be in use at any one time). This means that you need to watch out you don't use the IRQ that your RIB is using for your serial mouse as well!!! ie, if your mouse is using COM1, don't put your RIB on COM 3!
In short, limit yourself to COM1 and COM2, and plan on plugging your RIB into COM2 because it has a higher priority interrupt than COM1. Use COM1 for the serial mouse if you are using one (the mini-DIN mouse port on an AT, PS2 or later machine is a non-issue here as it uses IRQ12). Note that IRQs above 7 are only available on 286 and later machines. For the most versatile RSS computer you really want a 16-bit machine ‑ an 8 MHz or 12 MHz 286 AT if you can get one, or an early 386 if not. Make sure that it has an IDE disk drive (single wide data cable) ‑ you do NOT want an MFM one (one that is narrower than an IDE cable and a second very narrow one). If you get one with an MFM controller or drive then replace it with an an IDE controller and drive immediately. Replacement MFM drives are NOT available, and you need to switch to an IDE drive at your convenience before you are forced to.

Here are two photos of the MFM drive and cable connectors. The white plug on the right end of the disk drive is a standard 4-pin power connector. The flash hit just right to wash out the detail.


Another potential but easily avoided problem is that many motherboard manufacturers use custom ICs which contain the serial port(s), the parallel port (printer port), the interrupt (IRQ) prioritizer hardware, the Real-Time Clock chip, the keyboard controller and perhaps several more functions ‑ primarily to minimize chip count (allowing smaller main boards and lower-cost assembly), but also to conserve DC power.   Some of these specialized chips (which are very popular in laptop designs and small-form-factor desktop motherboard designs) aren't quite perfect in their emulation, such as powering up with the FIFO enabled (the original chips power up with FIFO disabled and the RSS is totally dependent on that behavior).   In fact, some early Radio Shack and Toshiba computers used serial I/O hardware that was so incompatible that NOTHING but their own software had any clue about how to talk to the outside world.   Some of the Olivetti-built AT&T 6100 and 6300 series had other timing quirks as well. Some of the more recent computers that have reduced chipsets have no UART chips at all and emulate them in BIOS routines (and therefore are totally useless with any DOS program that needs a hardware COM port (which is ALL of the RSS).

Make sure that you have a proper serial port ‑ one that has no FIFO and is recognized by the BIOS. The DOS command MSD can be used to see what DOS "sees" in your system hardware configuration. The original 1981 IBM PC had COM1 and COM2 at I/O addresses 03F8 and 02F8 (hexadecimal). The COM3 and COM4 ports did not appear until later, and there was no initial standard for them ‑ several manufacturers followed IBMs published tech manual chart which put them at 03E8 and 02E8 (hex addresses). IBM themselves had COM3 and COM4 at those addresses throughout the PC, XT and AT product lines but they moved them in in their PS/2 line (which broke a LOT of software)... they put COM3 at 3220 and COM4 at 3228 because of I/O address buss clashes between the serial ports, the floppy controller and the early VGA cards (no, they couldn't just fix the clashes, they took the easy way and just moved the hardware out of the way). Later RSS packages were modified to look for COM3 and COM4 at both 03E8 and 02E8 or 3220 and 3228), but you will probably, at some time, encounter an early one that does not... You really want to use COM2 for your RIB if you can ‑ it has a consistent and stable I/O address and the higher priority IRQ... and as such it will always work.

As to the FIFO, locating a functional 8250 based serial board these days will be almost impossible unless you get REAL lucky at a garage sale, a thrift shop, or at a swap meet... and then you will have only one, and on something as important as your RSS computer you really want a shelf spare. You can use any real serial port if you DISABLE the FIFO. And Moto gives you a perfectly good program to do so, and it was designed as part of the RSS system.

Here's a photo of one of the REAL "async cards" made by IBM in the 1980s. The top two connections in the jumper block in the upper right corner are open, the bottom two are shorted. That block is used to select IRQ 3 or IRQ 4, and you simply rotated it 180 degrees in the socket to change from one to the other. The other jumper block (behind the DB25M) selects the I/O address (03F8 or 02F8 hex) and likewise you flipped it 180 degrees to make the change. The upper 4 are open, the lower 4 are shorted. Note that to change from COM1 to COM2 or back you have to rotate both blocks.
Note the white silk screen ink above the ISA connector that says "ASYNC CARD" - the printer port card of the era looked similar except for the sex of the DB25 connector and the silk screen. I forget if it said parallel port, parallel card, printer card, or printer port.

IBM also made a combination serial and parallel (one of each) card where the serial port used a 16450 chip. Here's a photo.
Notice the white ink at the bottom of the board says "SERIAL / PARALLEL".

Some I/O card manufacturers shipped a utility program that disabled the FIFOs, for example, COMPAQ provided "COMFIFO.EXE" with some of their computers. In 1997 Moto's Radio Software Technology Center finally released a program called COMMCHEK.exe which reports the type of UART used on Communications Ports 1-4 (COM1-COM4), plus information on the FIFO state (on or off) if the UART chip is of the type that has a FIFO. It also allows you to among other things) switch the FIFOs on and off on a per-port basis. Note that COMMCHEK only reports on COM ports that the BIOS recognizes. I suggest that anyone that has a FIFO-equipped com port locate a copy of COMMCHEK and put a call to it into the AUTOEXEC.BAT file of the RSS computer to disable the FIFO on the port that the RIB is on. Or use the free FIFO.COM program from David Perrell mentioned below (under "Slowdown Programs").

COMMCHEK is covered in the Motorola "Service and Repair Notes" for October 1997 and March 1998: SRN-1201 and SRN-1201A.

Whatever utility you use, it's end purpose is to let you use a serial card with a later FIFO-based chip (like the 1655x series) with earlier software (like RSS), but some vendors I/O Card wrote their utility programs such that they affected both COM1 and COM2 together and hence trashed the driver for a serial mouse. If you need to use both the FIFO disable program and a serial mouse then you need to research the option switches for that program and use them to limit the effect to only the serial port that will be talking to the RIB. Or use a computer with a PS/2 series mouse port that uses it's own I/O address and IRQ12.

Some of the Motorola RSS packages included COMMCHEK as a Communications Port Test function in the Setup Computer menu ‑ if it is in the RSS you are using (perhaps under a different but similar name), run it before you go programming a radio. If the Comm Test passes, then you know that the computer should be running at an acceptable speed, the RIB works, and your cable connections are probably OK. But I'd still put COMMCHEK in the autoexec.bat file.

To summarize the FIFO situation in one sentence, if you have the FIFO stack in the COM port chip switched off, either by COMMCHEK or an equivalent, or don't have a FIFO in the first place, the problem is solved.

No Power Management !! If you are using a desktop or laptop PC that contains any form of Power Management (PM), you need to make sure that all of it is totally disabled ‑ you don't need any behind-the-scenes changes happening while you are uploading a code plug into a radio (like the hard drive spinning down, or the COM port getting powered off).

No matter how much people would like it to, USB WON'T WORK !! Note that all forms of USB are supported by a driver in the operating system, and more recently in the BIOS. DOS hasn't a clue about USB, and nobody is updating DOS any more (the last IBM PC DOS version was 6.something, and the last Microsoft MS-DOS was buried inside (and tweaked for) Windows ME). Therefore DOS-based RSS will NOT run on a USB-to-serial or USB-to-COM-adapter and barring some magic DOS driver appearing never will. And USB-based programming cables - labeled "universal" or otherwise - will NOT work with DOS-based RSS because that RSS talks directly to the serial chip.

Any motherboard new enough that the BIOS understands USB keyboards or USB mice will be too fast and won't work with any RSS that has timing loops in the serial routines. And as said above, some of the more recent motherboards that have reduced chipsets use routines in the BIOS to serialize and de-serialize the COM port data streams (and therefore won't be seen by any RSS).

That said, if you have a windows based programming computer that is running CPS and talking to a radio by way of a a USB-to-serial adapter and a RIB, or via a USB to radio cable (which has a USB to serial adapter inside it) then you need to be aware of two major glitches - and either one can ruin your entire day:
1) Each USB port can source up to 1/4 of an amp at 5 volts. Under some conditions Windows will put the USB port (and therefore the serial adapter) to sleep to save energy. You need to go into device manager, then on the "power management" tab and deselect the "Allow Windows to turn off this device..." option. This will keep the power on.
2) Check to see what COM port the system has assigned to the serial adapter. Go to Device manager, then click on "properties". For some reason many USB to serial adapters will sometimes chose to be a COM Port above 4. Unfortunately early versions of CPS only know about COM Ports 1 through 4.
Back to DOS and RSS:
Similarly, the little plug-in serial port cards that slide into the side of a laptop (PCMCIA or CARDBUSS) often require a software driver to be used with DOS... but there are a few that don't. Most DOS-based RSS programs talk directly to the serial hardware and bypass any operating system drivers, so in most cases these plug-in cards will not run with RSS. The only card that will work is one that shows up as a valid COM port in the BIOS listing. I know that they are out there, I've used a couple, but I don't know who made them. If you find one that works under RSS please let repeater-builder know so that the manufacturer and model can be added to this article.

In short, if the serial port does not show up in the BIOS summary screen during boot time (i.e. just before the OS loads) as COM1 or COM2, then the port probably won't work with earlier DOS-based RSS. Later RSS programs know about COM3 and COM4. Likewise the printer port has to show up as LPT1, LPT2 or LPT3. And you may have to turn the BIOS summary screen on in a BIOS setting - hitting "Del" during boot is the most common way to access the BIOS but I've seen Ctrl-Alt-Insert, F2, F10, F12, Alt-S and other key strokes used to access the BIOS configuration screen(s) during boot. Compaqs were famous for the F10 key, and it was only active for a second or so during the boot process - the blinking square cursor showed up at the left margin, then hop to the right margin for a second or two, then hop back to the left margin. The F10 key was only active while the blinking cursor was on the right margin.

In summary...

I'm repeating myself here, and doing it on purpose: Always run your DOS RSS in pure DOS ‑ and this does NOT mean in ANY emulated machines, including a DOS window in ANY version of Windows!! Many operating systems, including Windows, implements the multiprogramming environment by giving each applications program a "slice" of time. Picture a impulse-type rotary sprinkler (Rain-Bird is one brand) configured to do a continuous circle (i.e. no limit triggers that reverse the direction)... the sprinkler shoots a burst of water, rotates to the next position, shoots a burst of water, rotates to the next position, and does it continuously. The OS (Linux, Windows, etc.) time allocation routine (sometimes called a dispatcher) does just that ‑ it gives a burst of CPU time (called a "slice" in the software design books) to each of several system overhead routines, like the printer spooler, the mouse handler, the keyboard handler, the video handler, etc. then a slice to each user program in turn. If the handler or the user program is done before it's time slice is up it does a special return instruction to return control to the dispatcher, if not, a timer interrupt returns control. The dispatcher then selects the next program to get a slice of time.
One term for the is technique is "round robin time slicing". All it takes to cause a disaster is to have the OS dispatcher routine switch away from the RSS to something else at the wrong moment... like during an upload to the radio...

Another problem is that all versions of Windows NT, 2000, XP, Vista and now Windows 7 takes away control of all the peripherals from all of the applications. The OS reserves ALL peripherals to itself, and puts a wall between the applications and the outside world. The application no longer can just reach out to the COM port ‑ it has to request the use each time ‑ sometimes called the "Mother, may I?" technique. RSS has no concept of "Mother, may I?", it expects completely unfettered access to the COM port. When it sends out the "is there a radio out there" inquiry and Mother blocks the access to the COM port it gets either no response or something it does not recognize. Either way it times out and assumes that there is no radio out there.

Note that there are some RSS programs that were specifically designed to tolerate Windows 3.1, 3.11 or 95 and say so in the book and the release notes that ship with the package. Those earlier versions of Windows (up to NT) did not have the "Input/Output Mother" in the way, and the release notes for those RSS programs specify that they must run in full screen mode (as opposed to in a window) as full screen mode disabled the time-slicing routine and gave that one program 100% of the CPU until you switched back to windowed mode. All Windows versions after 98SE did not offer the full-screen, time-slice disabled mode.

It took long enough, but it finally percolated to the top in the Motorola Mobile Radio Software group that their RSS was so poorly written that it was at the point of being deemed almost unusable. They were forced to realize that they had painted themselves into a corner and didn't have any windows to escape through.   About 1994-1995 the programming process and the professional programmers caught up with the faster machines and a lot of the computer speed problems in the RSS were cured.

Unfortunately the RSS version release process was so slow that features like adding FIFO shutoff instructions (or better yet, the whole new serial port driver) never made it into the RSS for the older radio series... frequently the RSS was updated only as long as the radios it programmed were on the currently active sales list. This means that older radios need older RSS which works only on older slower computers, and the older the RSS the more sensitive it is to the clock speed of the computer. The Maxtrac software release dated December 1995 reads:

> "Communications Port (COM1 ‑ COM2) IC (UART) is now
> completely initialized upon startup. This prevents interference from
> prior applications when communicating with Radio via the RIB."
This tells me that after 10 years they finally figured out that you can't assume that the FIFO is off, or that the port is set for 8 bits, the proper baud rate, the proper handshaking (hardware or software), and no parity. A lot of other software of the day set the serial port configuration the way it wanted, then didn't put the port back the way it was found when it was done. Hence the note that many radio shops had taped to the RSS computer: "Hard reset the computer between different RSS programs".

The same release note says:

> "This version has been updated to interface more reliably with the
> Radio on faster 386/486 machines. This version has Radio Bus Timing
> controlled by the PC Timer IC, and Relaxed Bus Timing parameters."
This tells me that they were forced into admitting they had timing problems and someone had finally figured out how to use the interval timer chip that had been soldered to the motherboard since the original PC was released in 1981, fourteen years earlier.

Another example: From the release notes sent out with a December 1996 version of a certain RSS:
(in the text below the "COM Bus" is the serial connection between the RIB and PC and the ALL CAPITALS emphasis is in the actual Moto text)

> "The PC-RIB radio communications timing has been changed to enhance
> the COM Bus operation over a wider range of CPU speeds and operating
> systems (DOS and Windows).
> This version contains two timers which are independent of CPU speed, and
> which do not conflict directly with the Windows multi-tasking timer when
> the RSS is used in Windows' FULL-SCREEN DOS MODE."

The reference to "Windows" in the above statement is referring the versions that were popular at the time of the writing - to Windows 3.0 / 3.1 / 3.11 and Windows 95. All 3.x and 9x Windows versions (in other words, everything prior to Windows NT) were all DOS applications that used the underlying DOS as little more than a loader that pulled the Windows program into memory and started it, then as an I/O and disk storage manager. Some of the problems of running Windows 3.x or 9x on top of DOS were hardware related. At that time frequently what worked well on a IBM AT or IBM PS/2 would not work on other brands of computers. PC hardware and Windows standards were in constant change, so for anything I/O dependent (including RSS) a pure DOS programming environment was the most stable way to go. And in Windows 3.0 / 3.1 / 3.11 the key combination of Alt-Enter was used to switch between Windows multi-program mode and full-screen single-program DOS mode.

If you need to run old RSS and stumble across a working or workable 286 or 386 computer, perhaps at a thrift store, a church rummage sale, or in the back of your packrat friends garage just grab it, and especially if it has an IDE disk controller, a VGA card or either an 8250-based or 16450-based serial board. A PS/2 mouse port would be nice as working serial mice are becoming pure unobtanium. You will need an ISA IDE hard disk controller in order to use a modern hard drive and a VGA video card to use a modern monitor (the chances of finding a working monochrome or CGA monitor (one with a DB9 plug on it) are lower than finding a working 286/386 box, however monitors can be fixed (assuming the tube is good). A large hard disk is not needed, and in fact is wasted as no DOS can handle a drive partition over 2 GB. All DOS prior to version 3.31D was limited to 8 megabytes per volume (per disk letter, i.e. C:\ or D:\). A 200 Mb hard drive was considered huge in that day, a 1 gigabyte drive was over US$1,200 dollars, and nobody knew what to do with that much storage on one drive. And at 8 megabytes per volume a 200 MB drive still occupied ALL of the drive letters (DOS 3.31D and later allowed for 32mb drive volumes, meaning that a 200 MB drive only occupied six to seven letters). There were many IDE cards made that plug into the ISA buss (i.e. a PC, XT or 286), but there were not many ISA VGA or ISA 8250 serial cards made. So if you find one, grab it ‑ you will need one sooner or later. By the way, Hewlett Packard made a big bunch of 8250 based dual port serial cards for their Vectra series of ISA machines in the mid-to-late 1980s with the wrong sex of DB-25... if you find an HP branded 8-bit ISA serial card in the surplus store with both a DB9M and a DB25F (i.e. a printer port connector) with the DB25 lableled "Serial" just GRAB IT and either use a male-to-male gender changer, or a male-to-male cable to compensate for the manufacturing production line oversight (it's not worth risking damaging the board ‑ it's a multilayer board ‑ to swap the connector for one of the correct sex).

If you find a stack of old 386 or 486 motherboards look for the ones with multiple crystals or multiple clock oscillator modules on them. The original IBM systems and the clones that had a single oscillator used a magic frequency that the video section needed and the "Turbo" switch selected different CPU divider ratios... (the video section magic frequency requirement was the reason for the weird 4.77 MHz CPU clock frequency of the original PC and XT - it was 4/3 the standard NTSC color burst frequency of 3.579545 MHz). The motherboards that used separate crystals or separate oscillator modules used one on 4.77 for the video and a separate one for the CPU – this allowed faster CPU processing. You can take one of those motherboards and add a toggle or rotary switch to change CPU speeds without affecting the video circuitry. The added switch can allow you to slow down a 50 MHz or 66 MHz 486 (much more common than a 386-20 or 386-25) down to 12 MHz or even 8 MHz.

The fastest 486 that I'd even think of using on most early RSS is a 20 MHz (but only if all the cache memory can be disabled), and a slower machine is actually preferred (I've been told that HT600 software can handle a 486-25, some older Saber handheld, STX handheld and R100 repeater RSS requires a 286, and that some early Spectra and System Saber RSS will not run on any 486). Those claims may have been exaggerated, but not having those radios, or seeing the release notes for that specific RSS it can't be verified by your editor.

As said above, if you limit yourself to the later radios and matching later RSS ‑ the versions that state that they can be used on NT or later operating systems ‑ and then run them on NT, 2000 or XP, then you will have zero problems. The only problem with that concept is that many of the radios out there were dropped off the sales list (and therefore the RSS update list) before speed-independent RSS was released.

Printing in RSS:
You will want a printer on your RSS computer to print summary sheets of the programming, and the DOS operating system and the DOS applications programs like RSS expects to see a parallel-port attached printer like an Epson FX, EX, LX or RX series of dot-matrix printers, or one of the equivalent Okidata, Star Micronics, IBM, Panasonic or similar printers (the early IBM dot matrix printers were Epsons in drag).   Laser printers and ink jet printers can be used as long as they will work under DOS (some won't), and in some it's annoying to have to force a page eject after each page.   Any printer that requires a memory-resident driver or an operating system driver to print will not work.

Here's a quick printer compatibility test:
  1. Connect the printer to the computer,
  2. power up the printer and the computer and let it boot DOS to a screen showing some text and a C:\ prompt,
  3. Tap the "Print Screen" key once.
Does the printer proceed to print a screen dump?   If not, then try Shift-Print-Screen, Ctrl-Print-Screen or Alt-Print-Screen.   If any one of them works then the printer will probably work under RSS.
The PC standard reserves three I/O addresses for parallel printers, the first of which is located on the Monochrome Video card.   If you have a color monitor then there are only two. You may find more than one female DB25 on the back of the computer, so you may have to try both / all of them (after you pop the cover off and make sure that one isn't a SCSI card).   DOS assigns the name LPT1 to the first port it finds during the boot process, LPT2 to the second, etc, but sometimes it gets confused.   You may have to try all three printer ports in the RSS to "find" the one that talks to your physical printer port.   And note that if you decide to share a printer between your RSS computer and another computer that you will have to use a printer port A-B switch, as you cannot share with USB or network....
EXCEPT: if you can find one of the HP, Epson or Canon ink-jets or laser printers that had both a USB port and a parallel port AND was DOS-compatible... then you could connect the USB port to your Windows (or Mac) computer and the parallel port to your RSS computer, and whichever computer talks first will have the printer until it is done.

If your printer absolutely will not work under DOS then you can do one of three things:

  1. Find an older printer ‑ PC-DOS / MS-DOS (and the applications including DOS-based RSS) expects a self-contained printer that takes in the single byte of data that represents the character and prints it.   For example, the byte with the hex value 41 is a letter "A".   To print an "A" the computer transfers a hex 41 byte to the printer and that's all it takes to do it.   On theother hand, most modern printers require device drivers that live in Windows or Linux.   These printers, for example, don't print a letter, they print the graphic shape of the letter ‑ and that requires a multi-byte stream that describes that particular characters shape (using data from the font file in the OS).   If you have a modern graphics compatible printer you will need to find yourself a "dumber" DOS compatible printer.   Most of these will be dot matrix technology.... however not all.   A daisy ‑ wheel printer works just fine as long as you can find the ribbons, and most HP Deskjets or a Laserjets power up in "dumb" mode, and works just fine with RSS as long as you force a page feed as needed.
  2. Find a MS-DOS or PC-DOS printer capture program. This is a program that you run with a filename as a parameter before you start the RSS. When you print something from the RSS it gets stored in the disk file, but RSS thinks that it was printed. When you are done with the RSS session you close the print file, copy it to a floppy disk and print it on another system.
  3. Run your RSS under DOS to do the download and upload to the radio, and as a last resort run it in a Windows DOS box ONLY to do the printing.   I repeat, DO NOT even think of trying to upload or download to the radio while running any DOS-based RSS under Windows or in an emulated machine under Linux.   Just leave the radio and/or the RIB powered off while Windows is running.   Yes, this is a valid option - you can use the old computer to do the radio programming, then copy the codeplugs to a floppy, then take that floppy over to any Windows box (even XP, Vista or Win7), bring up the RSS in a DOS window, load the codeplug from the floppy and print the frequency lists on the regular printer.

Other Ways to Print the Code Plug:

The following was suggested in an email by Frank Carlson, KDØSVO:

I had been wanting to use the "Print Codeplug Data" feature in the Motorola RSS for quite awhile, and finally found a solution (I don't have an old DOS-type printer). I thought I would share in case it can be helpful to others.

There's a Windows application that allows Windows printers to be used with DOS applications. It's available from www.dosprn.com/.

In my case, I am using it with a free PDF printer available from www.cutepdf.com/products/cutepdf/writer.asp.

Here are the steps I am using:

Note, I am not reading or writing to the radio when running the RSS in Windows, only retrieving and printing the codeplug data. Also be aware that not all RSS programs will even start up under a Windows environment (MSF5000, for example).

The printouts that are generated by the RSS are neatly organized and are an exact representation of what is in the radio. In my case, I was programming some Radius mobiles for another ham and wanted to give him an exact PDF printout of the mode configuration in each. This saves a lot of typing and spreadsheet formatting and eliminates possible errors as well.

Some comments on RSS internals:
The later RSS used a structure where all the radio information was contained in a Model Definition File - MDF for short. The RSS opens it on startup and many of the RSS programs run a checksum on the file (yes, some do and some don't). Those that do compare the calculated MDF checksum with a constant contained in RSS and if the checksum is not correct it panics. This means that any patching of the MDF (like to enable amateur 900 MHz frequencies, or to widen the low band RSS from 42-50 to 42-54, or to widen the UHF from 450-470 to 440-470, or to bump up the channel count for a specific model radio) must maintain the magic checksum number. It also means that you can't mix and match files from one version to another, like using a version 4 MDF in a version 1 RSS. Each MDF has some unique data in it, plus the checksum, and that checksum result is hard-coded in the parent EXE file. If they don't match, you get all sorts of errors (some are misleading in their wording) and "File not found" messages.

Another situation that causes strange error messages is when someone burns a CD of the RSS directory on computer #1 and then restores it to computer #2. Or uploads the resulting file to a web site somewhere. Somewhere in the middle the "read only" flag on each and every file gets set. The author(s) of the RSS wrote it in such a way that it opens many files in read-write mode where it really doesn't need to (the only time it actually writes to the disk is when it is saving a code plug or the program configuration) but since the program opens almost every RSS file as read-write the RSS panics if they are found set to read-only. And the error messages caused by the read-only flag are really misleading - the most common one is "File not found". The cure for the read-only flag being set is to use the DOS command ATTRIB to fix it. Use "ATTRIB /?" to learn how (or Google it), and don't forget the " /s" switch.

Another MDF concern... from an email received by repeater-builder:

Every ham wants to add more channels to a radio - the 8 channel GM300 needs to go to 16, the 2 channel HT600 needs to go to 6, the 16 channel Maxtrac needs to go to 24 or even 32, (or to 99 once he hears about the Ontario Hydro 99 channel special Maxtracs).

There are two ways to go about this, (assuming that the radio has enough RAM to hold the additional frequency / tone information):

  1. Tweak the existing channel count in the model number entry that matches the radio.
  2. Change the internal model number of the radio to a more capable model number, one that has the maximum number of channels. Then when the radio is read by the RSS the channel count of the new, more capable model number is in effect.

The second method is preferred, since when you go to change the channel info on someone else's programing setup (that does not have the tweaked MDF that has the increased channel count in your particular radio's model number) you lose all the added channels until you get back to the computer with the tweaked RSS. This has bitten a few people (and badly) when they go to change a PL tone on, for example, a 16 channel radio that started out life as an 8 channel one... the 16 channel code plug is sucked into the PC, the change is made, then the code plug is truncated to 8 channels and uploaded back into the radio.

Slowdown programs:
Earlier versions of MoSlo, and similar programs slow down your computer and claim to make it possible to run older programs on faster machines...   These programs were originally designed for early computer games and work by hooking into and intercepting the clock interrupt mentioned above and on every "tick" (16 or 18 per second, I forget which) wasting a chunk of time on each one.   To understand how they work, picture how you could walk to the corner store at your normal speed, and you could get there only half as fast by walking ten steps at normal speed, then pausing for the amount of time that ten steps would take, then taking another ten steps at normal speed, then pausing for the amount of time, over and over again.   Not quite the same as actually walking at 50 percent speed, is it?   You could adjust the numbers any way you wanted - to get a 66 percent slowdown by walking ten steps, then pausing for twenty steps.   Yes, MoSlo can get the RSS to run, but it doesn't completely solve the I/O timing issues ‑ getting it to actually read and write to the radio usually fails at some point (the slow-down software can't compensate for the UART read/write cycles) or the timing loops in the serial port driver.   A video game is one thing, and I could live with a hung copy of Space Invaders, but as far as I'm concerned, it's not worth the risk of a missed timer interrupt corrupting a codeplug upload into a customers radio and bricking it.   Some of my clients carry badges and guns, others work for three-letter and four-letter federal agencies… all of them have zero sense of humor.

David Perrell, the author of MoSlo found this web page and wrote:

Hello.

I'm the author of Mo'Slo, and I recently came upon a page on your website
when I googled the words 'MoSlo FIFO RSS'. The page, "A comprehensive
overview of the Motorola Radio Service Software (RSS), the Radio Interface
Box (RIB), their history, problems and some solutions" is immensely
informative.

All PC's use an 8253 programmable interval timer (PIT) or equivalent as the
system timer. In DOS it interrupts 18.2 times per second. The AT&T 6300 had 
a PIT, and there was no difference in system timing between the 6300 and the 
IBM PC. The 6300, however, had a real time clock (RTC) chip that maintained 
the time while the system was turned off. IIRC, a special DOS was needed to 
support the RTC. The IBM didn't get an RTC (except on add-in boards) until 
the PC-AT.

The latest versions of Mo'Slo aren't limited to the PIT interrupt interval
of 55ms, nor do they necessarily waste CPU cycles to slow the system. Mo'Slo
Deluxe can use the RTC, with intervals of 7ms, and the APIC timer, with
intervals of under 1ms. In both of these slowdown modes, the CPU is actually
halted, not wasting time in a loop, which results in less power consumption
and heat.

In addition to the smoother slowdown methods, Mo'Slo Deluxe (under US$25) has 
options to disable the CPU cache and the COM port FIFO buffer while slowdown 
is in effect. (I also wrote a standalone FIFO buffer program that can be
downloaded for free from http://moslo.info/utils.asp.)

The result of these enhancements has been positive feedback regarding use of
Mo'Slo Deluxe with RSS and PLC software. According to one user it worked for
STX, Syntor X 9000E, DGT9000, Maratrac, and Spectra on a Dell Latitude D630
Dual Core 2 GHz PC.

Anyway, I hope you don't mind that I've added a link your Motorola Equipment
page on my website. Thanks for maintaining such a valuable resource.

Best regards,
David Perrell
http://moslo.info
I've not had a copy of the recent MoSlo to play with, but if it will actually allow a X9000 to program on a modern day (fast) machine then it's the answer to a lot of prayers.

Another bit of info from yet another email...

A friend was trying to program an HT1000 with a relatively new laptop computer, booted to DOS from a thumb drive. The software would not communicate with the radio properly. If he kept trying to read the code plug, eventually it would get the job done. Writing the code plug made a mess of things but luckily didn't brick the radio. I figured the computer was enabling the FIFO in the serial port's UART during the BIOS startup sequence, and that was something RSS never figured on. Being the bullet-proof software that RSS is, it never disabled the FIFO, so the radio's data bytes get stuck in the UART's FIFO buffer and RSS failed reading and writing.

I pointed him at MoSlo, and he found this program, also written by David Perrell: http://moslo.info/fifo. It will report the status of the FIFO, and also let you turn it off (or on, probably).

He downloaded the program, put a line in his AUTOEXEC.BAT to disable the FIFO, and now the HT1000 RSS works perfectly.

Apparently that particular version of the HT1000 RSS has the timing loop problem fixes in place, but not the FIFO fix.

Another caution - if you do have a later version of RSS than runs on a fast computer, the most common method of running DOS on your speedy box instead of Windows is to boot a DOS floppy. Older versions of DOS run the FAT-16 file system, later versions support larger hard drives with FAT-32. Later versions of Windows dropped FAT entirely and use NTFS. If you boot DOS from a floppy drive on a Windows box you MAY discover that you have no hard drives once it's running. One workaround is to acquire an IDE interface Iomega ZIP drive (they come in 100 meg and 250meg versions, and in IDE, SCSI and USB) and set up your computer boot sequence for floppy and IDE or SCSI ZIP first, then the hard drive. Then load your DOS and RSS on the Zip drive. With the ZIP cartridge out the box boots Windows from the hard drive, with it in it boots DOS from the ZIP.

In closing, because Moto does not update the RSS of discontinued radios, those folks that need to run older RSS are forced to keep older computers running because of the poor programming practices in the RSS. And until there is a truly untraceable anonymous way to distribute software nobody is going risk the wrath of Moto legal by writing replacement software.

Lastly... A comment on a totally erroneous rumor: If you do a hexadecimal dump on some of the RSS executables you will find an embedded copyright notice from Borland Corporation.   No, Borland is not responsible for the RSS software problems as anyone can write junk software with timeout loops even with the best tools.   Borland only wrote the compiler that was used to generate some of the COM and EXE files. The legal environment is such that to protect themselves the Borland copyright notice is embedded in all of the generated executable files as extra nonexecutable code.   Borland has sold compilers and other software development tools for Pascal, C, Basic and other languates since the mid 1980s.   It would take analyzing the executables to determine which language the RSS was written in, and even then what good would that knowledge do you?   While you could, I really doubt that anyone is going to de-compile an old RSS program.   Note that some RSS displays a "Divide by zero" or a "Run Time Error 200" message if run on a too-fast computer, and the "Error 200" message is known to be produced from the runtime section of Borland's "Turbo Pascal" and "Turbo C" packages.   So we can safely say that some RSS was probably written using either Borland's Pascal or C compiler.


* Note to our overseas readers, or anybody else who does not get the joke: The "900 pound gorilla" reference above is a reference to two old (1960s / 1970s vintage) paired jokes in the USA...

Question: Where does a 600 pound gorilla sit?
Answer: Anywhere he darn well pleases!

Question: Where does a 900 pound gorilla sit?
Answer: He kicks the 600 pound gorilla out of the way.

In other words, there's always a bigger bully around somewhere.


Back to the top of the page
Up one level (RSS page)
Up two levels (Moto index)
Back to Home


Editors note: This article mentions DOS and windows extensively. To put things in context, here's a timeline, from earliest to latest:

April 1980
Tim Patterson, the designer of Microsoft's Z-80 SoftCard for the Apple II, begins 
writing QDOS (Quick and Dirty Operating System) for use with Seattle Computer 
Products' 8086-based computer. Even though it had been created in only two 
man-months of evenings, QDOS 0.1 works surprisingly well.

October 1980
Microsoft's Paul Allen contacts Seattle Computer Products' Tim Patterson, asking 
for the rights to sell SCP's QDOS to an unnamed client (IBM), but it will have 
to be renamed. Later on Tim Patterson goes to work for Microsoft.

December 1980
Seattle Computer Products renames QDOS to 86-DOS, releasing it as version 0.3.
Microsoft pays less than US$100,000 for non-exclusive rights to market 86-DOS 
and does so to other hardware manufacturers.

February 1981
MS-DOS runs for the first time on IBM's prototype microcomputer. The BIOS does 
not use or offer access to the timer chip. It can handle only 180K single sided 
5.25" floppies, and does not have subdirectories.

July 1981
Microsoft buys all rights to QDOS/86-DOS from Seattle Computer Products, and 
changes the name to MS-DOS. They license it to IBM for an undisclosed amount.

August 1981
IBM announces the IBM 5150 Personal Computer, featuring a 4.77 MHz Intel 
8088 processor, ships with 64KB RAM, 40KB ROM, one 5.25-inch floppy drive, 
and PC-DOS 1.0, for US$3000.

September 1981
Someone at Microsoft gets a very quiet tour of Xerox PARC (Palo Alto Research Center) 
and is shown an Alto workstation. It has a graphical user interface, overlapping 
windows and icons. It also has a Star Wars game where you "fly" a X-wing fighter 
(using the mouse) into a trench and try and drop a bomb down a tubular target. 
Microsoft begins development of the Interface Manager (subsequently renamed 
Microsoft Windows).
See the Wikipedia article on the Alto. 
Steve Jobs of Apple had been given a more visible tour in 1979 and promptly integrated 
a large number of Alto concepts into the Apple Lisa (whose technology was later rolled 
into the Macintosh). 

May 1982
DOS 1.1 is released with many bug fixes and adds 360k double sided floppies.

March 1983
MS-DOS 2.0 supports 10 MB hard drives, a hierarchical directory structure (i.e. a 
tree-structured file system), the EXE file format and installable device drivers. 
Mark Zbikowski is one of the developers of MS-DOS 2.0 and uses his initials at the 
front of the EXE files as a tag to indicate that it is not an executable COM file.

November 1983
Microsoft announces Windows 1.0, which included MS-DOS Executive, Calendar,
Cardfile, Notepad, Terminal, Calculator, Clock, Reversi, Control Panel, 
PIF (Program Information File) Editor, Print Spooler, Clipboard, RAMDrive, 
Windows Write, Windows Paint... and Wes Cherry's Solitaire. 

March 1984
August 1984 MS-DOS 3.0 supports for 1.2 MB floppy disks, and bigger (than 
10 MB) hard drives.

January 1986
Microsoft releases MS-DOS 3.2 which adds support for 3.5-inch 720 KB floppy 
disk drives.

Fall of 1987
Windows 2.0 is released, and adds icons and overlapping windows.

August 1987 
MS-DOS 3.3 is released, and until DOS 5 is the most popular version. Even after 
DOS 5 is released many people prefer 3.3 due to the smaller RAM footprint.

November 1987 
Compaq ships MS-DOS 3.31D with support for over 32mb drives. 
For many years this is the preferred version for many users.

June 1988
MS-DOS 4.0 adds the mouse port driver. There is an attempt at multi-programming,
but it falls flat on its face. It also has a much larger memory footprint and there
are a large number of applications that just won't run under it. The common hard 
drive at this time is 50 to 60 MB and bootleg copies of Compaq 3.31D are available. 
They are very popular since it runs just fine on any PC clone hardware and supports 
larger-than-32-meg drives.

November 1988
MS-DOS 4.01 is released as a bug-fix release. It includes an interrupt driven 
mouse driver since the port-scanned one in 4.0 frequently dropped mouse movements. 
There is no reduction in memory footprint or fixes for applications that work under 
3.3. and not under 4.0 

May 1990 
Windows 3.0, a complete rewrite, is released. Drops support of 8" floppies. 
It is very popular.

June 1991
Microsoft releases MS-DOS 5.0, a rewrite from scratch. It adds a full-screen 
editor, undelete and unformat utilities, and task swapping. 8 inch floppies 
are still suported.

October, 1992 
Windows for Workgroups 3.1 is released. It has a workable file sharing system, 
with sharable directories, and a Mail program.

March 1993
MS-DOS 6.0 Upgrade includes DoubleSpace disk compression. 8 inch floppy 
support is dropped.

November 1993 
Windows for Workgroups 3.11 is released, and since they finally fixed the network 
drivers it becomes the first really viable Windows network client.

January 1994 brings Windows NT 3.1 which is based on an entirely new operating
system kernel (OS/2 for IBM, under contract). One aspect is that it prevents 
applications programs from talking to peripherals.

February 1994
Microsoft releases MS-DOS 6.21, removing DoubleSpace disk compression.

June 1994
MS-DOS 6.22 brings back disk compression under the name DriveSpace.

September 1994
Windows NT 3.5, the first really useful version of NT. 

March 1995 
Windows NT 4.0 

April 1995
IBM releases PC DOS 7 but nobody really notices.

August 1995 
Windows 95 is a 32-bit system providing full pre-emptive multitasking, 
advanced file systems, threading, networking and more. Uses MS-DOS 7.0 
as a bootloader, but takes over from DOS completely after starting. 
The VER command says "Windows 95". It's obvious that DOS, as a product, 
is gone.

June of 1998 
Windows 98 is released. The tech support community jokes that "98" is 
the number of security vulnerabilities that MS has included at no 
extra charge. Some wags joke that it's 0x00000098 (i.e. 152 decimal)

November 1998 
NT 5.0 released as Windows 2000. It is the first consumer release of a 
professional grade operating sysytem. The tech support community jokes 
that "2000" is the number of bugs it was shipped with. Microsoft announces 
that they will fold the consumer and business products into one software 
development unit.

May 1999
Windows 98SE released, and basically rolls up several hundred bug fixes 
into one new release, and adds a few features that had been developed for 
Windows 2000.

Feb. 2000
Windows 2000 Professional is released.

Sep. 2000 
Windows ME (short for Millenium Edition) was introduced with many features 
from the Win2000 product crammed into it. Rumor has it that it is introduced 
to milk the existing 98 codebase for one more cashflow cycle while the next 
version of Windows 2000 is further developed. Insufficent integration and 
testing results in a very buggy product, and the tech support community jokes 
that ME is an abbreviation for "Massively Evil".
The refusal of major ISPs to support it makes it a very short-lived product, with many users switching from Win98SE to Win2000 and skipping ME entirely. Many computer vendors chose to ignore ME, instead offer your choice of 98SE or 2000. October 2001 Windows XP debuts. It is dubbed as "Xtra Problems" by the tech support community. Service Pack 1 comes out within 6 months, rolling up over 700 / changes / bug fixes / updates into one download. Over the next few years there are three service packs, and even after you apply SP3 there are over 100 security patches left to download. July 2005 Windows Vista is announced, and finally released almost 18 months later in January of 2007. Due to many problems discovered in the Beta and initial releases the tech support community dubs it "the Windows ME of the NT world". Very few corporate users adopt Vista, which appeared to be aimed mainly at the audience who had never used a computer before. So much was changed (including many printer drivers), and it didn't work on a lot of XP machines, that existing users just decided to wait for something better to come along. Ubuntu Linux is given a good hard look by many corporate IT departments. Microsoft made several massive sales pushes and marketing promos, but the users and uses they were depicting (kids, videos and photo albums) weren't the ones with money to buy computers (their parents, or corporate IT departments). The major computer manufacturers had been offering machines with Vista pre-installed, but so few purchased them that they were soon forced to offer a choice of Vista or Windows XP). There were reports that over ninety percent of the new system buyers chose XP. October 2009: Windows 7 is released, in several flavors. More familiar to users of Windows XP and the remaining corporate users who were still using Windows 2000. Once Service Pack 1 comes out, more of the existing user base will migrate to it (most corporate IT departments have had a policy since Windows 98 days that no new Microsoft operating system is ready for prime time until Service Pack 1 comes out).


This web page first posted 16-Mar-2004


Motorola® is a registered trademark of Motorola Inc.   CPS, HT600, MICOR, Mostar, MT1000, R100, Radio Service Software, RSS, Radio Interface box, RIB, Saber, SmartRIB, Spectra, STX, Syntor, Syntor X, Syntor X9000, Systems Saber and other terms used in this article are trademarks, service marks or copyrighted by Motorola Inc. and are used in this writeup and on this web site in a descriptive or educational use only, and no misuse or infringement is intended.

This article is an original work that was written by a Repeater-Builder staff member at the request of another Repeater-Builder staff member, and is © Copyright March 2004 and date of last update by the author, and is hosted at the Repeater-Builder web site.

This web page, this web site, the information presented in and on its pages and in these modifications and conversions is © Copyrighted 1995 and (date of last update) by Kevin Custer W3KKC and multiple originating authors. All Rights Reserved, including that of paper and web publication elsewhere.