[Coco] 512K AND Beyond??? How FAR Beyond???

Bill Pierce ooogalapasooo at aol.com
Wed Dec 27 11:09:41 EST 2017


Robert, Jim and anyone else, OS9 did NOT use memory above 2 meg. The only software I know of using this is the ramdisk in the NitrOS9 repository specifically written for Paul Barton's 8 meg board and it accesses the memory directly and not through OS9's memory manager. Of course, there's Robert's test programs as well.
The DAT tables required for anything above 2 meg are too large for system memory and something would have to be modified/changed before NitrOS9 can "legally" use memory above 2 meg.

That being said, the memory above 2 meg CAN be used with special programming... as data space, graphics memory storage, etc, but the program itself would have to keep tabs on what memory is being used and what memory is free (above 2 meg). A good example of this is Dave Philipsen's BMP display demo for the Coco3FPGA which loads 20+ 640x450, 256 color BMP files into memory the runs a slideshow. The Coco3FPGA DOES have some memory and graphics functions that a Coco3 does not, but it would still work on a Coco3with standard Coco3 res screens (with a little modification to the software)... and store about 40-50 (maybe more, too lazy to do the math) 640x192 graphics screen!!

https://youtu.be/WlcjJLiOQbQ

and while playing a wav file!!

https://youtu.be/G8a9-6R7wh0

And yes, this was done in NitrOS9 on the Coco3FPGA @25mhz!!

Also, to clear something up... I keep seeing that the 1-2 meg is "just" used for ramdisks... Yes and no. This is only true IF that's what you assign it to.
The 1-2 meg upgrades are used in NitrOS9 as REGULAR mappable memory. In other words, if you're running programs, you have more memory for more programs. More graphics pages and windows can be assigned. More/larger get/put buffers can be used and much more. This is all transparent to the user, no special commands needed... NitrOS9 just has more memory. The 64k workspace limit still applies, but you can have even have more 64k workspaces. It "Just Works".

A good example of this would be Ultimuse3. It is originally configured to a 256k score buffer. With the change of a single variable, it can use up to 1.5 meg (system and program use the rest) for the score buffer. I may make this change on the next release :-)

Another example is my MShell project. The MShell File Manager reads 2 complete directories into memory. On large HD directories or PC directories (yes, MShell will read/copy directly from your PC HD using DW4), you could read massive directory into memory. MShell dynamically allocates the memory for the huge buffers using get/put buffers and will utilize the 1-2 meg upgrades (all done "legally"). MShell also forks various modules as it runs. With more memory, MShell easily handles the forking of subs along with massive data buffers for program use (not to mention other programs running in other windows) and it's all transparent to the user. MShell doesn't do anything special to use this memory, it works with 512k or above. All the heavy lifting in the memory management is done transparently by NitrOS9.

To say "it's not used" or "who would need it?" is just saying "You never had it!". I've been running my real Coco3 with 1 meg and VCC with 2 meg for years and when I go back to 512k, I get frustrated when I run out of memory for extra processes, windows, or graphics.

The Coco3 memory upgrades above 512k fall in that category of "You don't know you need it until you've had it and then have to do without it"
I'm lost on a 512k machine these days.

 

 

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page

E-Mail: ooogalapasooo at aol.com

 




More information about the Coco mailing list