[Coco] UltiMusE SOURCE CODE to be released

[Roger Taylor]

>Roger, you understand the memory management tricks (a la Projector) about  as
>well as I do.  But I'd be glad to explain them to anyone seriously  working
>on them.  Just converting the C code to assembler, as described  above, would
>preserve the existing "soowie"* technology, by whihc one 
>subroutine  module can
>call another such module via the "mother ship".


I recall most of the conversations we had years ago about this 
subject.  Ume is more advanced than Projector-3's tricks, but I do know 
exactly what you are talking about.  Ofcourse, with 512k or more of RAM, 
most of which is just sitting there in Disk BASIC, you can put a lot of 
memory management tricks to use, much beyond what OS-9 Level II utilizes.

One good trick for overgrown programs is to separate all of your code into 
8k modules.  Make your main program as small as possible, within reason, 
and use the extra 64k space for your code modules and data modules.  You 
can switch data in and out the same way and do great things.  I like the 
idea of modules switching in other modules before calling a procedure in 
the other module.  You can really make a very large program run in a very 
small space.  Well, RAM, that is.  The modules do take up disk space.  :)

Projector-3 uses hard-origin modules that get loaded at 49152 and 57344 
like ROMs.  P-3 uses a lot of global variables (common to all modules of 
the program), but it also uses a lot of local data to each module to save 
memory and to also allow changes to be made to a module without having to 
rebuild the entire program.


-- 
Roger Taylor