This doesn't help with the relocation, but instead of a ccr-81 couldn't you make an mp3 of UPC and load it from anything convenient that can play back the audio (phone, mp3 player, reel to reel ;)?
fg On Fri, Apr 2, 2021, 9:29 PM Greg Swallow <[email protected]> wrote: > 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: > > 1. 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. > 2. 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) > 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 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 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 on a floppy with 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 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 <>< > > >
