burke_vern@mtblue.dec.com (WHY BE NORMAL?) (08/18/88)
I recently outfitted myself with a 128K CoCo III,2 floppy drives,
and OS9 level 2(version 02.00.01).I've been having some difficulty
getting some extra memory space.I noticed that when the shell is
linked at startup,19 extra command modules are also loaded into
RAM.I wanted to get rid of some of these because I don't use them
enough to justify the space.At this point, mfree showed 48K.
I used the level 1 save command to save just the shell module,
and put it in my cmds directory.Now everything boots alright and
the shell works alright,but I ended up losing memory instead
of gaining it.I only have 40K now.It seems like OS9 is still
assigning the memory that old shell command(shell+19 modules)
required.aaaarrrrrgggghhhhh!
Is there an easier way to get rid of some of these modules?
Where did the memory go?Help!
Vernjejones@mcrware.UUCP (James Jones) (08/18/88)
In article <8808172042.AA01032@decwrl.dec.com>, burke_vern@mtblue.dec.com (WHY BE NORMAL?) writes: > I recently outfitted myself with a 128K CoCo III,2 floppy drives, > and OS9 level 2(version 02.00.01).I've been having some difficulty > getting some extra memory space. ...followed by some, as SubGeniuses would say, puzzling evidence. It's not as puzzling, though, once you know about the GIME chip. The GIME chip does lots of stuff, and one of the things it does is memory mapping. I don't know the design tradeoffs involved, not having had anything to do with it, but it turns out that the GIME maps memory in units of 8 (count 'em 8) K. This is VERY large compared to other OS-9 Level Two systems, and it can eat memory up quickly if you're not careful. All those other modules that you pulled out of the stock "shell" file were there because it didn't hurt anything--the shell is only about 1.5K, so that leaves 6+K out of an 8K hunk that would otherwise be wasted. OS-9 can't map memory in units smaller than the hardware supports, so you didn't gain anything by putting only the shell in /dd/cmds/shell, and when you ran mfree, it had to be loaded instead of already being there when you loaded /dd/cmds/shell, so poof! another 8K gets allocated and you see 40K free instead of 48K free. I personally don't understand why the stock CoCo 3 is sold with 128K, because windows can eat memory pretty quickly. You should get more memory. James Jones
eaker@sunbelt.steinmetz (Charles E Eaker) (08/18/88)
In article <8808172042.AA01032@decwrl.dec.com> burke_vern@mtblue.dec.com (WHY BE NORMAL?) writes: > I recently outfitted myself with a 128K CoCo III,2 floppy drives, > and OS9 level 2(version 02.00.01).I've been having some difficulty > getting some extra memory space.I noticed that when the shell is > linked at startup,19 extra command modules are also loaded into > RAM.I wanted to get rid of some of these because I don't use them > enough to justify the space.At this point, mfree showed 48K. > I used the level 1 save command to save just the shell module, > and put it in my cmds directory.Now everything boots alright and > the shell works alright,but I ended up losing memory instead > of gaining it.I only have 40K now.It seems like OS9 is still > assigning the memory that old shell command(shell+19 modules) > required.aaaarrrrrgggghhhhh! > Is there an easier way to get rid of some of these modules? > Where did the memory go?Help! I doubt that the level 1 save command will work properly with level 2. I suspect that whatever module file it is creating is using up the extra 8K when it is loaded into memory. What I do know for sure is that getting rid of those extra modules will not save any memory. Level 2 allocates memory in 8K chunks because that's the granularity of the memory management hardware. For *each* process, it will allocate a minimum of 8K bytes for the process's variables, stack, etc. In addition, if the program module is not already in memory, it will allocate yet another 8K bytes (minimum) and load the module into it from disk. These two 8K chunks are then mapped into the CPU's address space whenever it is that process's turn to execute. Since the shell module is less than 8K bytes in length, the other commands are added to it since they are used a lot. Otherwise, each invocation of dir, for example, will result in 8K bytes being allocated for its variables, stack, direct page storage etc. (which happens no matter what), *AND* another 8K bytes for the code module if it is not already in memory. Since OS9 is supplied with the shell and dir residing in the same 8K chunk of memory, that same 8K chunk is mapped into the shell process's address space and in dir's address space. This is a very brief description which may leave you still scratching your head. Frank Hogg Laboratory sells a book that explains it reasonably well. It comes with listings (in assembler) of programs which will show how things are mapped when the programs are run. The moral of the story is that you can't do much with os9 in 128K. Get a 512K upgrade. Chuck Eaker General Electric | eaker@sungod.steinmetz.ge.com Corporate Research & Development | eaker@ge-crd.arpa P.O. Box 8, K-1 3C12 | eaker@steinmetz.uucp Schenectady, NY 12301 | 518-387-5964
pete@wlbr.EATON.COM (Pete Lyall) (08/19/88)
In article <8808172042.AA01032@decwrl.dec.com> burke_vern@mtblue.dec.com (WHY BE NORMAL?) writes: > I recently outfitted myself with a 128K CoCo III,2 floppy drives, > and OS9 level 2(version 02.00.01).I've been having some difficulty > getting some extra memory space.I noticed that when the shell is > linked at startup,19 extra command modules are also loaded into > RAM.I wanted to get rid of some of these because I don't use them > enough to justify the space.At this point, mfree showed 48K. > I used the level 1 save command to save just the shell module, > and put it in my cmds directory.Now everything boots alright and > the shell works alright,but I ended up losing memory instead > of gaining it.I only have 40K now.It seems like OS9 is still > assigning the memory that old shell command(shell+19 modules) > required.aaaarrrrrgggghhhhh! This is because of the way level II, and specifically the Tandy implementation of it, work. Memory is allocated in 'blocks' under LII, not in pages as in Level I. On most sane 6809/os9 systems, block size was 4K (or 2K) and the physical memory limitations (addressing lines + DAT) allowed for a meg of RAM. Under the Tandy scheme, you have a 512K ceiling (a limitation in the GIME chip), and your block size is 8K. That means no matter how little you load into it, you lose 8K at a whack (system memory excepted). The best idea here is to use each 8K block to its fullest potential - that is, FILL IT UP. That means merging several smaller modules together so that when one loads, they all load. The best bet here it to group frequently used utilities, or at least utilities that are related, together. This is what they did with 'Shell'. If you do an IDENT on the /dd/cmds/shell file, you'll see that they stuffed a lot of the frequently used file management tools into the file as well (DEL, LIST, etc.). Actually, because there's a 512 byte area that's reserved across the top of all address spaces, it's best to keep the merged modules at or below $1E00 in length. If you don't, you'll find that the merged modules cannot be loaded in the top block of a 64k adress space, and you'll effectively lose 8k. In summary - leave things as they are! You're not 'paying any extra' to have those additional tools in RAM - they'll actually cost you more to use if you split them up. Also, it's pretty widely know that os9/LII for the coco3 without 512k is awkward at best. Limp along if you have to, but set your sights on a 512k board. Hope this helps. Pete area at the top of each address space, you should only try to use $1E00 of it (instead of $2000). -- Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693 Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Internet: pete@wlbr.eaton.com UUCP: {scgvax,jplgodo,voder}!wlbr!pete
jonh@tekgen.BV.TEK.COM (Jon Howell) (08/19/88)
In article <8808172042.AA01032@decwrl.dec.com> burke_vern@mtblue.dec.com (WHY BE NORMAL?) writes: > I recently outfitted myself with a 128K CoCo III,2 floppy drives, > and OS9 level 2(version 02.00.01).I've been having some difficulty > getting some extra memory space.I noticed that when the shell is > linked at startup,19 extra command modules are also loaded into > RAM.I wanted to get rid of some of these because I don't use them > enough to justify the space.At this point, mfree showed 48K. > I used the level 1 save command to save just the shell module, > and put it in my cmds directory.Now everything boots alright and > the shell works alright,but I ended up losing memory instead > of gaining it.I only have 40K now.It seems like OS9 is still > assigning the memory that old shell command(shell+19 modules) > required.aaaarrrrrgggghhhhh! Exactly. The 19 commands are merged with the shell module and called "shell" on the disk. The CoCo3's MMU divides the 128K in your machine (or 512) into 8K blocks to be shuffled around. Every module loaded independently takes at least one block, and enough to fit it. Shell only takes some 6K (I think), so the other commands are added into the same load so that they fill in the other 2K. If each command is loaded independently, they'd each take 8K. [If you're a visual learner:] Block 1: [S----h----e----l----l......] Block 2: [Lu.........................] (Lu=Little Utility) Block 3: [Mu.........................] (Mu=Medium Utility) when broken up. Total=24K (or 160K if all 19 utils are loaded) But by packing them all into one block, it all takes only 8K. Little space is wasted: Block 1: [S----h----e----l----lLuMu..] Sooooo, don't bother breaking them up. As a matter of fact, ident the other utils you like to have loaded, and merge them together in groups which fit neatly into a multiple of 8K. (8192 bytes, not 8000..) Also, I save disk space on my boot disk for important programs by doing an mdir to find out which modules come with shell, then deleting the individual copies of those off of the disk. Hope it helps, Jon Howell -- ...!tektronix!tekgen!jonh (503) MAK-SEMA Jon Howell o o o o o o o o // // // _ _ _ _ . . . . ___ . _ -|--|--|--|--|--|--|--|- // // // / / \ / / \ |\/| |\ |\ | | |\ / /> /> /> /> /> /> /> /> // // // \_\_/ \_\_/ | | |"\ | \| _|_ |"\ \_ <Disclaimers never fit int
jonh@tekgen.BV.TEK.COM (Jon Howell) (08/22/88)
In article <11895@steinmetz.ge.com> eaker@sunbelt.UUCP (Charles E Eaker) writes: >I doubt that the level 1 save command will work properly with level 2. >I suspect that whatever module file it is creating is using up the >extra 8K when it is loaded into memory. Nope..SAVE works..But of course it is using up the extra 8K..that's the "minimum block phenomenon" we both explained. However, I realize the other blcok is un-accounted for. That's tricky...I just thought of why, tho: When the mfree was performed the first time, mfree was in the same block as shell. However, the second time, OS-9 had to load it from the floppy...using another 8K block! (gee, that was sleuthy! I oughta do one of those Q&A columns! I bet YOU didn't think of that! [can you tell I'm proud of my little accomplish- ment? :-]) Anyhow, my original advice and the explanations by I and the person who's accusation of the SAVE command I hacked up without looking for his/her name still stand. [Go ahead, make sense out of it! :-] Jon Howell -- ...!tektronix!tekgen!jonh (503) MAK-SEMA Jon Howell o o o o o o o o // // // _ _ _ _ . . . . ___ . _ -|--|--|--|--|--|--|--|- // // // / / \ / / \ |\/| |\ |\ | | |\ / /> /> /> /> /> /> /> /> // // // \_\_/ \_\_/ | | |"\ | \| _|_ |"\ \_ <Disclaimers never fit int
knudsen@ihlpl.ATT.COM (Knudsen) (08/23/88)
In article <726@mcrware.UUCP>, jejones@mcrware.UUCP (James Jones) writes: > I personally don't understand why the stock CoCo 3 is sold with 128K, because > windows can eat memory pretty quickly. You should get more memory. I used to feel the same way -- that the Shack should just solder in the 512K chips and sell the Coco 3 for maybe $50 more than the current units. However, since Reagan reminded us of Peral Harbor and drove RAM prices into orbit (compensating for NASA's impotence?), Radio Shack would be in a quandary today -- they'd have to hike Coco 3 prices by at least $100 to cover the cost of the chips (just as upgrade kit prices have shot up). That would make it harder to sell Coco 3s at all. Also, remember the Coco family is "modular" -- most buyers don't start off with a floppy drive or MPI, let alone OS9. The 128K runs all the new RomPak games just fine, and adds the much better graphics to BASIC. Also the competitors (Apple, Commodore, Atari 8-bit) are 128K too. I've heard some amazing figures about how most Cocos remain toys for kids to learn Basic and blast aliens on; some TINY percentage of Coco owners buy disks, MPIs, or RS232 Paks. Thus these "necessities" (to us) get discontinued or not properly supported. But along James' line of opinion, I wondered why Tandy kept pushing the old 16K Coco 2s for so long, instead of making them all 64K (64K chips are still dirt cheap). My best guess is they just didn't shut down the old 16K production line soon enough and got stuck with a big inventory. If RAM prices had kept falling, by now there probably would be a "native" 512K Coco 3. Actually, what I wish is that the GIME DAT had used all 8 bits to give us 16 blocks of 4K each, with an upper size limit of 1 Meg. Somehow the Coco 3 would seem a lot more powerful if advertised as a "Mega Coco."
bdw@rwing.UUCP (Brian Wright) (09/01/88)
I think that most of the problem revolves around the fact that Tandy is
not really competing effectively against Commodore or Atari. The CoCo 3
is the best route to go for a low cost multi-tasking machine. The Amiga
does have a multi-tasking kernal in it's OS, but it's a beast to use,
thanks to the lack of hardware memory management. The ST is just a
game machine, nothing more. But, Atari got started with video games,
they now have a machine that's more powerful than there other 400/800
6502 based game machines. The CoCo may be marketted by the Shack as
a game machine, but it's only one out of the 3 that allows for good
expansion at low cost, and you can take your CoCo to ANY Tandy outlet
for servicing.
--
--
Brian Wright
UUCP: {backbones}!uw-beaver!tikal!toybox!rwing!bdw
" "!camco!eskimo!bdw
"I'd buy that for a dollar!" --Robocop