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

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 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 longer 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 (at the time our contributors personal vehicle was a 1971 Ford Falcon station wagon that had been upgraded from a straight six and drum brakes to a V8 and disk brakes, equipped with six NMO antennas and Motracs on 6m, 2m and 450 MHz, and was in the middle of the conversion process on a high band Motran to 220 Mhz. One of the comments the gentleman made was that the 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.

Supposedly 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 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. Becasue 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 professional programmers into the mobile radio group (and they rewrote the serial driver) 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, and was used in business a lot and had a better serial port driver. When Windows 95 came out Moto saw the handwriting on the wall and the RSS that is specified to run under Win95 used the serial drivers built into it (for example, the MTS / 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 only usable on Window 98 and later.

All of the Windows versions from 1.1 through 3.x, 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: 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 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 app note for the Intel clock generator chip), or relegated to the 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 serializer / de-serializer chip embedded in the PCs COM port. The earliest integrated serial chips were simple-minded ones that accepted a data byte from the CPU, then on command sent 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, and the whole stream could be at speeds ranging from 50 bits per second all the way up to 38,400 bits per second. 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 compatibilty with the machinery of the day. 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. Also 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).

The next generation serial chip took the UART core and added the glue logic into the chip package itself. The resulting chips interfaced directly with the CPU chip I/O buss, plus it allowed a second byte to be brought in while delivering the first one to the CPU... if 12-bit characters (start bit, 8 data bits, a parity bit, and 2 stop bits) were being recieved the program had the start time plus 8 bit times plus 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... most were 8 data bits and no parity or 7 data bits plus the parity bit). These directly interfacing chips were the Intel i8250 (second sourced by National Semiconductor as the NS8250, and also called the WD16450 by Western Digital). Unfortunately a lot of the RSS was written to talk specifically to these chips ‑ at the time since that's all that there was and the serial chip manuafturers were pretty quiet about what was in the design pipeline. 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 significant.

Later PC serial ports used the 8251 or 8251A (16550, 16551 or 16C552) which, while similar from the hardware designers point of view, does 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 implementation is 16 bytes). Each FIFO buffer has a "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 the 12th byte is queued up. Then it tells the application to get data from the FIFO buffer by generating one interrupt (the receiving application 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 of the FIFO stack.

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 interupt 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 14 byte thresholds (i.e. 2 bytes of headroom) were common.

The RSS protocol 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 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 an 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 happend 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 much of the older RSS was written in the days when computer vendors were selling cacheless 16MHz to 25MHz 386s to the average end-user, and a cache-equipped 50Mhz or 66MHz 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, some 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 initialzation 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 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 12mhz Saber or R100 RSS in a virtual machine on any modern hardware.

Another possible answer is the "dosbox" utility for Linux. Supposedly it can be configured as to emulated hardware and speed.

None of your contributors have any experience with running RSS on any of the above. Repeater-builder would be very happy to host an article on "dosbox" or on virtual machines, anonymous or otherwise.

Back to PC and RSS history:
Then there are the hardware interrupt lines. Eight-bit machines such as the PC and XT have only 8, and the 16 bit machines such as the ATs, 386s and 486s have 16 (but only 15 are available ‑ IRQ2 is unusable except in very rare cases). 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 Comm. Ports would be in use at one time). 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 PS2 mouse port uses IRQ12 and 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 8MHz or 12MHz 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 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 many more functions ‑ primarily to minimize chip count (allowing smaller main boards and lower-cost assembly), but also to conserve power.   Some of these specialized chips (which are very popular in laptop designs and small 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 6300 series had timing quirks as well.

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. 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 (they couldn't just fix the clashes, they just moved the hardware out of the way). Later RSS packages were modified to understand COM3 and COM4 at both 3E8 and 2E8 or 3220 and 3228), but you will probably, at some time, encounter am 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 later real serial port if you DISABLE the FIFO. And Moto gives you a perfectly good program to do so.

Here's a photo of the REAL "async card" 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 (3F8 or 2F8 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.

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 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 locate a copy of COMMCHEK and put a call to it into the AUTOEXEC.BAT file of the RSS computer to disable the COM2 FIFO.

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 softare (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 later Motorola RSS packages contain 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.

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 adapter, and never will. And USB-based programming cables will NOT work with DOS-based RSS. Any motherboard new enough that the BIOS understands USB keyboards or USB mice will be too fast and won't work either.

Similarly, the plug-in PCMCIA or CARDBUSS card (the little cards that slide into the side of a laptop) serial ports 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 as COM1 or COM2. 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 DOS-based RSS. Likewise the printer port has to show up as LPT1, LPT2 or LPT3.

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 a DOS window in ANY version of Windows!! Windows implements it's multiprogram environment by giving each 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 stops to reverse direction)... it 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 Windows (any Windows) CPU 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 (and a timer interrupt returns control to the dispatcher which selects the next program to get a slice of time). If the handler is done before it's time slice it up it does a special return instruction to the dispatcher... One term for the is technique is "round robin time slicing". All it takes is the Windows dispatcher routine switching away from the RSS to something else at the wrong moment... like during an upload to the radio...

Another problem is that Windows NT, 2000, XP, and now Vista 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 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 sreen mode disabled the time-slicing routine and gave that one program 100% of the CPU until you switched back to windowed mode. Windows versions after 98 did not offer the full-screen, time-slice disabled mode.

It took long enough, but it finally percolated to the top in Motos 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, hardware or software handshaking, 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.

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 there 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 (everything prior to Windows NT) were all DOS applications that used the underlying DOS as little more than an I/O 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 PS/2 would not work on on other brands of computers ‑ PC hardware and Windows standards were in constant change, so for anything I/O dependent (i.e. 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 by any decent TV repair shop (assuming the tube is good). A large hard disk is not needed, and in fact is wasted as DOS can't handle a drive partition over 2gb. 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 (the limit in DOS 3.3 and earlier) a 200meg drive still occupied ALL of the drive letters (DOS 3.31D and later allowed for 32mb drive volumes, meaning that a 200mb 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 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. Those 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 orignal PC and XT). The boards that use separate crystals for the video and the CPU can have the CPU crystal changed by a toggle or rotary switch ‑ it's an easy way to switch 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 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: connect the printer to the computer, power up the printer and the computer and let it boot DOS to a screen showing a bunch of text and a C:\ prompt, then 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 loated 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 locates 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 decode 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 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 talkes first will have the printer until it is done.

If your printer will not work under DOS then you can do one of two 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 comnputer 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).   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. Run your RSS under DOS to do the download and upload to the radio, and 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.

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 MDF has a checksum contained in it, and the "parent" RSS program verifies that the checksum is corrent before it uses the MDF file. This means that any patching of the MDF (like to enable amateur 900 MHz frequencies, 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 a checksum, that's hard-coded in the parent EXE file. If they don't match, you get all sorts of errors and "File not found" messages.

Another situation that causes stange error messages is when someone burns a CD of the RSS directory on copmputer #1 and then restores it to computer #2. Somewhere in the middle the "read only" flag gets set. The RSS opens many files in read-write mode and panics if they are read-only. Again, you will get all sorts of errors and "File not found" messages.
The cure for the read-write is to use the DOS command ATTRIB to fix it.

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 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 elses programing setup (that does not have the tweaked MDF that has the increased channel count in your radios model number) you loose all the added channels until you get back to the computer with the treaked 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 per second) 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 serial port driver timing loops.   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 and they have no 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 2ghz 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 2 gig machine then it's the answer to a lot of prayers.

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 are running DOS on a Windows box you MAY discover that you have no C: drive. 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 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, with it in it boots DOS.

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 an 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.   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 Borland's Turbo Pascal package.   So we can safely say that some RSS was probably written using Borland Turbo Pascal for DOS.

* 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

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 Repeater-Builder.

This web page, this web site, the information presented in and on it's 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.