I'm not an expert, so I hope that someone will correct any errors and
clarify things that I don't make clear. This has gotten to be a lot
longer than I had expected, but now that I've tried to explain it, I've
noticed that it doesn't seem quite as simple as I thought it was.
First off, as to how much memory the 48 series calculators can address:
The Saturn processor uses 20 bit addresses, thus can recognize 1048576
(1 Meg of) distinct addresses. But addressing is by the nibble (4 bits
or a half byte), so that's 1 "Meganibble" (is that a word?), so 512
KiloBytes. 256KB is used for ROM, leaving 256KB for RAM. Well, 256KB of
RAM that can be addressed "easily", that is.
Perhaps it's too bad they didn't develop a Saturn+ with larger addresses
when they developed the 48SX or the 48GX, but that would have been a
major project, and developing a new RPL with larger addresses would be
another major project, so I suppose that it wouldn't have been feasible.
When they developed the Saturn, who would've guessed at any desire for
more addresses in a hand-held calculator!?
I'll refer to built-in RAM together with any merged RAM from expansion
cards as "system RAM", which is used for storing global variables, the
stack, and "working memory". Note that the operating system reserves
some RAM for its own use, so the amount reported as available by the MEM
command will be somewhat lower, even immediately after clearing the
memory.
"Ports" are used for libraries and "back-up objects", that is, objects
that can't be modified (at least not while they're stored in ports);
although they can, of course, be stored or purged. "Port 0" comes out of
the same pool of memory as the system RAM, sort of a "virtual port". All
other ports are on expansion cards. When a card is "free", it's a port
(or ports, in the case of the 48GX); when it's "merged", its memory is
pooled with system RAM/port 0. Ports (other than port 0) are restricted
to 128KB each.
The 48SX has 32KB of RAM built-in. Up to two RAM cards of either 32KB or
128KB each can be added, and each can be either free or merged. That
means that 288KB can be used as system RAM! The 48SX manages this by
"covering" a portion of ROM with RAM as needed; I think of it as bank
switching. The card in slot 1 is port 1 if free, or system RAM/port 0 if
merged. The card in slot 2 is port 2 if free, or system RAM/port 0 if
merged.
ROM cards can be added instead of RAM cards. ROM cards can never be
merged; they're forever free. RAM cards can (if "free") be mechanically
switched to write-protected, in which case they effectively become ROM
cards. Write-protecting a merged card is a bad thing to do.
The "low-cost" follow-up to the 48SX is the 48S. Basically, it's the
same except without the slots for the expansion cards, and of course,
the price.
One company, TDS, marketed 256KB and 512KB cards for the 48SX; these are
multi-bank cards. The general idea is that instead of using 2 or 4 128KB
cards and physically switching them, you use 2 or 4 128KB banks on a
single card, and use software to switch them. But the requirements for
switching cards (except turning the calculator off and on) still apply
when switching banks. A special library that came with the card allows
the user to switch which bank is in use. The card can be merged, but to
do a bank-switch, it has to be free. A bank-switch forces a warmstart so
that the operating system can find out what's in the bank. Also note
that the bank in use (if free) has the port number of whichever slot
it's in. So while these cards do offer additional storage space, using
it isn't all that easy.
When HP released the 48GX, it looked to me as if they borrowed an idea
from TDS, but instead of the user having to make sure that the card is
"free" and telling a library to switch to a different bank, the 48GX
doesn't allow a card in slot 2 to be merged in the first place, treats
each bank of a multi-bank card in slot 2 as a separate port, and doesn't
need a warmstart every time that it looks at a different bank.
The 48GX has 128KB of RAM built in. Slot 1 can accept either a 32KB or
128KB card which can be either free or merged, and behaves the same as
slot 1 in the 48SX. Slot 2 can take these and larger cards, but can't be
merged, so the 48GX can have, at most, 256KB of system RAM, a bit less
than is possible on the 48SX. The 48GX can have up to 32 ports: port 0
(from the 128KB built-in), port 1 (up to 128KB in slot 1), and ports 2
through 31 (128KB each in slot 2). So it *can* have up to 4MB of RAM,
just not all on one card. The maximum of 30 ports of 128KB each comes
out to 3840KB available in slot 2.
That slot 2 can have at most 30 ports would seem to be the reason why
the Klotz 4MB cards have a mechanical switch to select between 2 pairs
of 128KB banks to be used as ports 30 and 31.
Whether this restriction to 30 ports on the card in slot 2 was an
oversight or intentional on HP's part, I don't know. As far as I know,
1MB was the largest card that HP ever marketed for the 48GX, so
being able to access only 3840KB of a 4096KB card was never a problem with
"Genuine HP" cards.
HP marketed 32KB, 128KB, and 1MB cards. Various other companies have
marketed 128KB, 256KB, 512KB, 1MB, 2MB, and 4MB cards.
The 48G is the "low-cost" version released together with the 48GX. Like
the 48SX and 48S, it came with 32KB of RAM built-in, and like the 48S,
doesn't have any slots for expansion cards.
The 48G+ was, I believe, ACO's very first "new product". It came with
128KB RAM built in, so the "+" means 4 times as much RAM as the 48G, as
much as the 48GX. But like the 48G, it doesn't have any slots for
expansion cards. I'd guess that the only development required for it was
to use the RAM chip from the 48GX, and changing the model number.
As for speed, the 48G series processor runs about twice as fast as the
48S series processor.
Note that having more memory available for the stack generally means
that garbage collections won't be needed as often, but when a garbage
collection is needed, it will take longer, which many perceive as a
slowdown and find objectionable. Similarly, when you turn the calculator
on, it checks on "what's out there" so having more memory, and
potentially more libraries, probably slows that down too. So "more is
better" isn't necessarily true.
Regards,
James