[Coco] some results

Mon Nov 9 18:55:18 EST 2009

  My memory may be foggy but I seem to recall using Shell "unlink...  to remove a procedure when it isn't needed. 
  Also, Lothan is correct inasmuch as the individual procedures, if small enough to fit more than one in an 8K module can be merged, then this will save some workspace. I usually go through the list and try adding different combinations so I might find a way to mix them so that they will squeeze into 8192 bytes of workspace in that module. 

  If you have a RAM disk on your coco, you can put the stuff you need to call on there and it will speed things up.
  If data is eating your memory, use the RAM disk or the floppy for that. It doesn't take much ram to open a record in a data file.  B09 can zip right on through several records if you use direct access to each record. You can have many datafiles for categories or related things. Use the disk drive or ram drive to keep this active stuff.
  Don't forget to use a "Quit" method so the program can copy the data from the ram drive to the disk. Likewise, the program should load all the stuff into the ram drive upon startup.
  I've found that using a command line shell script to copy my files to the floppy is easy to forget to do.
   Leave nothing to chance!!

George
  From: Lothan 

  Have you tried merging runb, gfx2, and your code module into a single file? 
  If you load them separately, each separate module takes up full pages of RAM 
  (4K, 8K?) even if the module is say 100 bytes. Merging them can 
  significantly reduce the memory footprint required.

  --------------------------------------------------
  From: "Wayne Campbell" <asa.rand at yahoo.com>
  Sent: Monday, November 09, 2009 4:28 PM
  To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
  Subject: Re: [Coco] some results

  > I don't know what is going on with the mem command. I can specify some 
  > values between even 000s, but not always, and some values are not accepted 
  > at all. I decided to work around the memory problem and try to make the 
  > procedure smaller.
  >
  > First, I replaced all of the GFX2 statements with GOSUBs, and put one of 
  > each GFX2 statement in subroutines. This reduced the code size for fmato 
  > to <24000 (unpacked). It still wouldn't run, so I removed the sort and 
  > renumber routines from fmato and placed them in separate procedures. 
  > Having them all in the workspace at the same time just made the overall 
  > size of the procedures greater than fmato was by itself. I packed the sort 
  > and renum routines into separate module files and deleted them from the 
  > workspace.
  >
  > Then I added SHELL statements to load each when it was time to use it. 
  > fmato still wouldn't run, even though the memory size was reduced to 24k 
  > (or so). I packed fmato, and found I could reduce the workspace size to 
  > 23000. It worked! I ran fmato and it ran. It went through the instruction 
  > section, displayed the decode in overlays, and when it got to the first 
  > sort, it quit with a 43 error. Running mdir showed that the sort module 
  > was indeed loaded, but Basic09 couldn't "find" it.
  >
  > I unlinked it from memory and quit Basic09. I ran it from the command 
  > line, and 67 error. Apparently the original RunB still has a problem with 
  > it. There were still 3 routines to separate, the ones for creating a 
  > record when a new var ref, line ref or lit ref occurs. I did that. While 
  > they were all merged with fmato it ran (only in Basic09, and only after 
  > packing). It still errored when it got to the first sort routine.
  >
  > I packed the record routines separately and removed them from fmato's 
  > workspace and tried again. Now it errors when it tries to run the first 
  > record procedure. Again, mdir shows that the module was found and loaded 
  > into memory. I don't get it.
  >
  > I am going to try separating the instruction decode section. It is the 
  > single largest routine in the program. I have a multitude of counter 
  > variables, as I wanted to know exact data concerning the I-Code. Perhaps 
  > making it a separate procedure will fix the problem.
  >
  > Wayne
  >
  > Also, I'll be putting the newest version of fmato on sourceforge, since 
  > the one I put there yesterday is already obsolete.
  >
  >
  >
  >
  > ________________________________
  > From: Robert Gault <robert.gault at worldnet.att.net>
  > To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
  > Sent: Sun, November 8, 2009 8:35:52 PM
  > Subject: Re: [Coco] some results
  >
  > Wayne Campbell wrote:
  >>
  >> Trying to go down to 26000 reduces the memory to less than
  >> the needs of the procedures. I am finding that Basic09's memory
  >> command is broken. For example, I can type mem 32000 and it will
  >> increase or decrease to that amount. Likewise, I can do the same
  >> with 34000. But if I specify 33000, I get "What?"!
  >
  > There is a good chance you have some code mismatches between your Basic09 
  > and the OS-9 versions. On my system, I can smoothly ask for memory within 
  > Basic09 up to mem 32760 giving 32767. I get What? trying for 32770, or any 
  > number higher including 34000.
  >
  > --
  > Coco mailing list
  > Coco at maltedmedia.com
  > http://five.pairlist.net/mailman/listinfo/coco
  >
  >
  >
  >
  >
  > --
  > Coco mailing list
  > Coco at maltedmedia.com
  > http://five.pairlist.net/mailman/listinfo/coco
  > 

  --
  Coco mailing list
  Coco at maltedmedia.com
  http://five.pairlist.net/mailman/listinfo/coco