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, Anthony On Friday, March 2, 2018, Peter Noeth <petern0...@gmail.com> 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 <coghl...@gmail.com> > To: "m...@bitchin100.com" <m...@bitchin100.com> > Subject: Re: [M100] Bar code reader with REX > Message-ID: > <CANeSRQV93k+KSUfJam+A-LGikozpWwDUBcGgeT4u-uK2OgzR-A@mail. > gmail.com> > 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> > > >
