Msg: 2200 *Conference*
03-31-92 09:38:56
From: LEX JENKINS
To : RICK LOPES
Subj: WARM.BA
Hi, Rick, As promised, I've enclosed an ASCII version of modified WARM.BA, which I use to load CR/CR.CO, DO2BA.CO and PACKER.CO. There are several advantages to loading .CO files this way: 1. Speed. Using the "parent" .BA programs to load the .CO programs that you actually use is slow, because each data line is POKEd one at a time - this can take up to a minute! But WARM.BA assigns non-conflicting top addresses, so loading the .CO file takes only a couple of seconds. 2. Economy. Once you've assigned addresses in WARM.BA for the .CO files, you can usually get rid of the "parent" .BA program, saving a lot of RAM space. For example, the "parent" program for PACKER.BA is 11K! But PACKER.CO is only 2.7K. Ditto for DO2BA and CR/CR (2K for the .BA files, vs. .5K for the .CO files, for each program). (A significant exception to this is SORT.CO, which requires SORT.BA to assign its address and load it. Not a big deal, since both programs are only about 200 bytes.) 3. Avoid cold starts caused by .CO clashes. WARM.BA does this two ways: First, it assigns non-conflicting addresses to the .CO files you load via WARM.BA; Second, when you RUN WARM.BA and press F8 to exit back to the menu, it "cleans up" after itself, resetting MAXRAM and MAXFILES to free up memory and avoid clashes with programs you don't load via WARM.BA This particular version of WARM.BA has one insiginificant "bug", if you can call it that (it causes no problems): Ideally, when you exit a .CO program loaded via WARM.BA, you should be returned to WARM.BA, rather than the menu. This feature works fine with DO2BA.CO, but not CR/CR.CO or PACKER.CO. Not a big deal, and I really haven't had time to work on fixing this. Clear as mud, huh? If you get a chance to bring it up at Club meeting maybe another member can explain this better than I have, and perhaps offer a solution to the "bug" I mentioned! <Lex> *Enclosed File: warm