Thanks, Peter. I think I’m going to try the barcode reader you use if I can
get it on eBay cheaply, as it may be more reliable anyway.  Perhaps I have
to try loading the driver and program with REX temporarily disabled as an
experiment.  I suspect a conflict in memory and don’t otherwise know how to
resolve that.

Best wishes,

On Friday, March 2, 2018, Peter Noeth <> wrote:

> I don't have a REX in my M102, but I have been using the BCR to do
> "pantry" and "wine cellar" inventory. Both are in the basement, so are not
> readily accessible when one wants to know what is down there. I am not
> using the Radio Shack wand, but instead am using a UniTech
> MS120-NTCB00-SG "industrial strength" wand. It is "plug-in" compatible with
> the RS wand, and has a sapphire tip that doesn't abrade the barcode labels
> and keeps dust out of the wand. It also has better "dynamic range" so has
> no problems reading low contrast barcodes or ines in color. I am using the
> sample "Simple Inventory" program (with some modifications) that came with
> the RS Barcode Reader package. I read the "database" file into Excel
> and keep a printout in the kitchen. The program works well, and barcode
> reads are quite reliable once you get used to the swiping speed needed.
> As to your program conflicts, problem with many of the early computers
> with "operating systems" supplied by Microsoft, is the RAM driver concept
> is limited in practical use. Microsoft intended the RAM driver facility to
> patch a ROM driver that may have bugs or add additional planned system
> expansion (like the DVI, Bar Code Reader, TDD, Option ROM, etc.). Later
> third party developers who had a product that used their own RAM driver all
> seemed to locate them in the same address in memory (top of available RAM,
> the logical place to put it). This creates memory conflicts. Especially in
> computers using the Intel 8080/8085 processors that do not support
> "relative" addressing. Without relative addressing, the user cannot move a
> driver to a different starting address in memory without recompiling it
> first, and since the user does not get a copy of the source code, he is
> usually out of luck.
> There were a few attempts using programs that would read the code of the
> driver and attempt to find all of the JMP and CALL instructions and patch
> them directly to a new base starting address, but it was not always
> successful, as often times the driver would contain inline data bytes that
> would confuse the conversion program. These programs usually worked on
> computers using the Z80 processors, since it did support relative
> addressing.
> Regards,
> Peter
> ------------------------
> <snip>
> Message: 14
> Date: Fri, 2 Mar 2018 00:57:07 -0500
> From: Anthony Coghlan <>
> To: "" <>
> Subject: Re: [M100] Bar code reader with REX
> Message-ID:
>         <CANeSRQV93k+KSUfJam+A-LGikozpWwDUBcGgeT4u-uK2OgzR-A@mail.
> Content-Type: text/plain; charset="utf-8"
> Yes, that was the drive belt I used also if I recall, made by Russell
> Industries.  I can?t find my old purchase info from eBay, but it was about
> $9 at the time.  (I think Brian mentioned that price as well.)  It was so
> nice to see the drive come to life!
> Best wishes,
> Anthony
> All on the list:  any tips on reliably using the bar code reader?  Thanks.
> I?m threatening to inventory our pantry if I can get it working, though my
> wife doesn?t think that?s such a practical application...  :)
> <snip>

Reply via email to