Kurt, Would work for sure, but I'm trying to get three M100 to do scanning and only have two with REX. Am using 3 M100 that have only a Y2K ROM and 32K RAM. The TPDD2 is a way to reload -- in case of crash, while at the job location. I can clear UPC.CO easy enough and CLEAR 256, MAXRAM should do the trick to remove FLOPPY. Then I can load UPC.CO with the app from RAM. A couple of extra steps to clear FLOPPY and reload, but the TPDD2 is still a lot easier than lugging around a CCR-81.
God Bless, GregS <>< Apr 2, 2021 5:39:41 PM Kurt McCullum <[email protected]>: > Use TS-DOS in ROM and you won't have a memory conflict. > > Kurt > > On Fri, Apr 2, 2021, at 4:44 PM, Greg Swallow wrote: >> Peter, >> >> Yeah, I was hoping, but UPC.CO does trample on top of FLOPPY. Even with any >> efforts to re-locate it to another segment of memory. Should've took to >> heart a clue in the TPDD2 manual noting FLOPPY is not for use/compatible >> with the DVI. >> >> God Bless, >> >> GregS <>< >> >> >> Apr 2, 2021 4:32:45 PM Peter Noeth <[email protected]>: >> >>> Greg, >>> >>> Memory conflicts have always been a problem in earlier computers with TSR >>> (Terminate and Stay Resident) drivers. It wasn't until the "Microsoft >>> Windows" era that methods of more sophisticated Memory Management were >>> created that alleviate much of this. >>> >>> Problems for this class of Operating System are: - * >>> No real Memory Management. Software designers figured that reserving some space from the Top of Memory would be a safe place to put their TSR code, as normal programs and data grow from a lower point in memory towards the top. - * >>> The 80C85 does not have a Jump Relative command. So all program jumps must be absolute. This prevents these TSR programs from being moved in memory to another location without being re-assembled to operate from a different range in memory. >>> The only way to make the two TSR drivers/programs play together is to >>> have the source of one of them, and re-assemble; or to disassemble one of >>> them to create a source file, that could be edited and re-assembled. There >>> are people on this list with the tools that could do this, but I am not >>> going to volunteer anyone. >>> >>> Regards, >>> >>> Peter >>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Thu, 1 Apr 2021 22:34:41 +0000 (UTC) >>>> From: Greg Swallow <[email protected]> >>>> To: [email protected] >>>> Subject: [M100] TPDD2 (FLOPPY) vs Barcode Wand (UPC.CO[http://UPC.CO]) >>>> Message-ID: <[email protected]> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> All, >>>> >>>> Working on the proof-of-concept for using barcode at work again. Changes >>>> in management had forced a pause. New super/lead likes the idea even more >>>> than previous. >>>> >>>> Am trying to use TPDD2 to store BASIC and barcode softwars for 3 M100. >>>> Trying to figure relocating barcode module UPC.CO[http://UPC.CO] to work >>>> with FLOPPY. Since the TPPD2 file manager is somewhat different in TOP, >>>> END, and EXEC addresses to identify all FLOPPY segments, I thought maybe >>>> someone could help with getting them to work together. And, avoid too much >>>> trial-and-error. >>>> >>>> Normally (without FLOPPY) UPC.CO[http://UPC.CO] is loaded after a CLEAR >>>> 110, 61784 statement. This will cause an AO error (I think it was) with >>>> FLOPPY loaded. I have been able to get UPC.CO[http://UPC.CO] on a floppy >>>> with READBC.BA[http://READBC.BA] and my code. I am hoping something like >>>> CLEAR 110, MAXRAM will set a proper loading point and avoid loading on top >>>> of any part of FLOPPY. The TOP of UPC.CO[http://UPC.CO] should then be at >>>> MAXRAM+4 with END and EXEC adjusted and savable with new numbers. At least >>>> I hope so and I am understanding it. >>>> >>>> Please. Any advise or wisdom, even a smack on back of my head, is welcome. >>>> >>>> God Bless, >>>> >>>> GregS <>< >>>> >
