**********
Topic 5         Fri Nov 08, 1985
SKRASNA                      (Forwarded) 
Sub: c-128 RAM

This is a question pertaining to how
the c-128 uses it's memory in the
c-128 mode
26 message(s) total
**********
----------
Category 14,  Topic 5
Message 1         Fri Nov 08, 1985
SKRASNA                      (Forwarded) 

I read somewhere that the c-128
splits it's RAM into two parts
when in basic. One part (half ) 
is used for progarm text and
the other part is used for strings
, arrays, and variables.

Does this mean that you are limited
to only half the RAM for text an
the other half for strings, arrays,
and variables. Does this mean I can
store lets say 90k of data in an 
array or in data statements?
Also does this affect ml programs
at all.
And also when I upgrade to 512 RAM 
will that get split to?

P.S. By the way Deb you really know
your bytes. You seem to know quite
a bit about this stuff. I guess thats
why GEnie got you huh?
They are lucky!

---------
Category 14,  Topic 5
Message 3         Fri Nov 08, 1985
DEB                          (Forwarded) 

((blush!))
   The C-128 uses BANK commands to fllip the memory configurations around
and give you all sorts of extra room.
  
   ((similar to the way the old B-128 did it))
  
   When running under native 7.0 BASIC, you have _ALL_ the room it tells
you for just your BASIC program!  (like about 64K)  All the variables and
strings and arrays are stored in BANK 1, a completely separate storage
area, where you have about 64K for just that, also.
 
   So...just the opposite is happening, you are actually being given MUCH
more room to program and operate in BASIC.
 
   This is all handled invisibly by the BASIC O/S.   Nobody much knows what
will happen when the 512 K expansion arrives, but there are EXTRA slots in
the memory management unit for banking extra RAM.  I'm sure that any add-on
memory will use the same procedures.
  
    Yes, the MMU (memory management unit) *does* affect M/L.  There are
seveeral registers and places you must specifically TELL where/how and what
bank to look in so that they will work.  A plain old SYS from BASIC just
is not directly transportable from the 64 to the 128.
  
    This bank switching is similar to how the 64 is laid out with the RAM
under the ROM where the BASIC interpreter and KERNAL are.  Its just on a
much much greater scale and with much much more room in the 128.
  
    I'm trying to get a special little tutorial edited up about handling these
different banks, it was a small little Conference lesson to several of us
asking questions by Joe O'Hara of Micro Technics Solutions...they have been
C-128 developers for months now.  I will post it as soon as I get it done.
  
    We REALLY need to see some comprehensive reference materials being 
published soon!!!!!
  
    KO---did that answer the questions?
     *deb!*
----------
Category 14,  Topic 5
Message 4         Fri Nov 08, 1985
SKRASNA                      (Forwarded) 

That really answers my question. 
Thanks!
I guess this way there really is no
garbage collection. Is that correct?
looking foward to the info on how to
switch banks etc...   Thanks!
----------
Category 14,  Topic 5
Message 5         Fri Nov 08, 1985
DEB                          (Forwarded) 

Correct, there seems to be none of the lengthy BASIC Garbage collections
we all came to know and love in the 64 ... but I don't *think* it has anything
to do with *where* the strings are stored, since the string storage in
BANK(1) is still dynamic, I think they just used a _decent_ garbage
collection routine.  Remember, the old PET and CBM Business Machines series
did not have garbage collection troubles, either, in 4.0 BASIC.
 
I have done some limited testing of string arrays, you know, the kind of
stuff that made the 64 pause for 5 minutes????   There is no noticeable
garbage collection!!!  In fact, I see _worse_ pauses for it in BLITZED programs
than I have in BASIC 7.0.
   *deb!*
----------
Category 14,  Topic 5
Message 6         Sat Nov 09, 1985
SKRASNA                      (Forwarded) 

Thanks for all this info Deb. I'm really glad about the abscense of the old
garbage collection routines.
I'm writing an album collection data base for my 1000 albums and let me tell
you that no garbage collection (or fast routuines anyway) really make a solid 
difference.
To drift off the topic for a sec. Can you relieve some of the garbage collection
in the 64 by assigning then to nulls (i.e.  n$="")?

----------
Category 14,  Topic 5
Message 7         Sat Nov 09, 1985
DEB                          (Forwarded) 

There have been several articles written on the C-64 garbage collection.
About the BEST thing you can do is to force SMALL garbage collections 
periodically, with something like:
     T = FRE(0)
  
 As you know, the garbage becomes much worse as you work with individual
string input and huge string arrays.
 
 BLITZ! still pauses momentarily for garbage collections, but it just looks
like a tiny little pause, and is no problem at all.
 
 Of course, in M/L there is no problem with garbage collection.....((grin))
----------
Category 14,  Topic 5
Message 8         Wed Nov 27, 1985
DEB                          (Forwarded) 

Now in the C-128 Software Library, an edited transcript of an impromptu
Conference class with Joe O'Hara about machine language, managing memory,
storing in bank (1) and other good stuff!  Enjoy!  Sorry it took me so long
to get it edited and uploaded.  ((blush!))
  
 *deb!*
----------
Category 14,  Topic 5
Message 9         Mon Jan 27, 1986
PRESS24 [Softronics]         (Forwarded) 

Ah! Must break out an XModem program
and dump the file about flirting with
banks...
 
I have Commodore's Tech Notes on the
128, and inserted was a supposedly
"easy to use" what-bit-does-what
to the MMU, for instance, to configure
the machine to show kernal and I/O
in bank 1 (for ML programs and such).
I never did get it to work as predicted,
and find it somewhat frustrating that
hopping from bank to bank isn't as
easy as they would like you to believe
it is. Does anyone have a simple
solution? I hate to give up wonderful
basic program space for ML...

Steve Lewis
----------
Category 14,  Topic 5
Message 10        Wed Jan 29, 1986
DEB [*Sysop* DEB]            (Forwarded) 

Believe that most of what you need to know, Steve, is in that file in the
library.  I'm already beta testing 2 C-128 terminals which use the banking
capabilities for their buffers.
  
   *deb!*
P.S.  Oh, the text files in the Library don't *HAVE* to be downloaded via
XMODEM, they can also be LISTed into a capture buffer
----------
Category 14,  Topic 5
Message 11        Sat Feb 01, 1986
PRESS24 [Softronics]         (Forwarded) 

I have downloaded the file and examined it and find it to be of some
help. It doesn't delve into the MMU like what I am looking for,
unfortunately.

It does, however, contain some tidbits that go unmentioned in the
tech notes.

Anybody know of any tech notes on the 1541 and 1571?

-Steve Lewis
----------
Category 14,  Topic 5
Message 12        Sun Feb 02, 1986
DEB [*Sysop* DEB]            (Forwarded) 

INSIDE the 1541, from ABACUS....and the 1571 book is due soon.
   deb!