Up two levels (Moto index)
Back to Home
|
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 |
|
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 DB-25M) 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 DB-25 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:Back to DOS and RSS:
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.
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...
>HT600 RSS RVN4005G >Version B02.03.02 Dec 16, 1997 > >Release notes: >Previous symptoms: >Version R02.03.01 would not communicate with radios from a 166 MHz Pentium. > >Diagnostics revealed that a hardcoded software loop to accomplish a cable >delay was too short for a 166 MHz Pentium. This Beta version implements >a delay that is not machine speed dependent.
A "hardcoded software loop to accomplish a cable delay" !! Well, they
admitted to writing a timing loop finally. But a "cable delay"??? Who
are they trying to fool?? The total amount of delay created by a copper
cable between a computer and a RIB added to the delay inherent inside
the RIB added to the delay caused by the cable from the RIB to the radio
is measured in nanoseconds (a thousandth of a millionth of a second).
A proper statement would have been that they needed to delay long enough
to synchronize the RSS with the radios internal processor and firmware.
But this release note was one of the first admissions to writing timing
loops and an announcement of the timer chip based serial driver.
>This version (B02.03.02) has been tested successfully on the following >machines: > >486 100 MHz >Pentium 200 MHz >Pentium 60 MHz >Pentium 150 MHz >386 25 MHz > >Reminder: this RSS will only work in a machine that has been booted up >in DOS mode. Running this RSS in a DOS shell under Windows 95 is not >supported.
The October or November 2001 version (the last one, as far as I know) of the HT600 RSS has been used on a P3-800 with no problems.
As a third example, here is a excerpt from an article by Mike Blenderman K7IC on the Syntor X‑9000 radios:
> For totally reliable Syntor X9000 RSS operation, a 286 or 386 > computer no faster then 8 MHz is recommended. Most of the time, a 386 > at 20 MHz is OK, sometimes a 486 SX 20 MHz with BIOS caching disabled > will work, but NEVER WITH TOTAL RELIABILITY. Disabling the computer's > BIOS caching is a technique for slowing the computer down that may > help, unless the computer is just too fast to begin with. It is > simple, the faster the computer the less reliable the RSS becomes. > > Marginally too fast computer induced failures are characterized by it > mostly working, but failing to do certain functions (the type of > failures vary, see next paragraph). Faster computers can give false > "SERIAL BUS FAILURE" or other messages. If you really pump up the > computer speed (i.e. 333 MHz PII) it will not even run at all. The > older the conventional RSS version is, the more sensitive it is to the > computer's speed (i.e. some very early versions of the RSS will not > even run on a 386 at 20 MHz). > > One type of computer speed related problem was experienced with a > 386SX at 40 MHz. It programmed the Syntor X9000 radio, control head, > DTMF option, VRS and Siren/PA just fine and had always worked with > other models of Motorola radios. However, a Syntor X9000 MDC1200 > board would program and then fail to verify. The MDC1200 board was > suspected of being bad until a slower computer was tried and then it > programmed and verified correctly. The entire variety of speed related > failures would be impossible to identify and the point of this > paragraph is to make clear that just because things appear to be > working with a faster than recommended computer, it is no guarantee it > is working reliably. > > A service shop should stick with an 8 MHz computer or slower for the > Syntor X9000 radios. This way they will know that any programming > failures are not their computers fault and will not waste time trouble > shooting the radio's hardware because of incorrect error reports > caused by a slightly too fast computer. Some computers let you select > the computer speed in the BIOS (an 8 MHz / 20 MHz selectable > speed 386 machine is ideal, if you ever have a programming failure at > 20 MHz just try it again at 8 MHz).
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 nowThis 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".
> completely initialized upon startup. This prevents interference from
> prior applications when communicating with Radio via the RIB."
The same release note says:
> "This version has been updated to interface more reliably with theThis 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.
> Radio on faster 386/486 machines. This version has Radio Bus Timing
> controlled by the PC Timer IC, and Relaxed Bus Timing parameters."
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 DE-9 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 DE-9M and a DB-25F (i.e. a printer port connector) with the DB-25 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: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 DB-25 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....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.
- Connect the printer to the computer,
- power up the printer and the computer and let it boot DOS to a screen showing some text and a C:\ prompt,
- Tap the "Print Screen" key once.
If your printer absolutely will not work under DOS then you can do one of three things:
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).
- Reboot computer into MS/DOS mode.
- Load RSS, read from radio, edit codeplug as needed, write to radio.
- Save codeplug into archive file.
- Reboot computer into Windows.
- Open RSS in a DOS window.
- Get codeplug from archive file.
- Select "Print Codeplug Data" and choose desired option (mode summary, radio-wide, etc).
- Click off of the DOS window and onto the desktop. The DOSPRN application window will come up, allowing anything sent to the DOS LPT1 port to be printed through Windows.
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):
- Tweak the existing channel count in the model number entry that matches the radio.
- 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:
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.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
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.Apparently that particular version of the HT1000 RSS has the timing loop problem fixes in place, but not the FIFO fix.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.
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:
