Re: Beyond 8 meg limit?

[dempson@actrix.gen.nz (David Empson)]

> In article <33668F37.2B50@no.no>, Eric Jacobs <no@no.no> wrote:
> 
> > Joseph Turner wrote:
> > > I got the good impression the *meg limit is die to the hardware
> > > configuartion, i.e. not enouogh lines to decode extra banks.
> > 
> > I very much doubt that. The 65816 puts the bank address on the data lines
> > during the first half of every cycle. Since all data lines are accessible to
> > memory card, it would be possible to decode all 256 banks.

True.  However, there is more to it than just the bank number.

> > You can see this for yourself. Go in the monitor and try to access a bank
> > that you don't have. You'll get back the bank number in return.
> > 
> > Probably what Apple did is use the high order bit to decide whether to
> > route the access to expansion RAM (basic 256k and up, banks $00-$7F), or
> > to the motherboard (slow RAM, and ROM, banks $E0,$E1,$FE, and $FF).
> > Still, as I recall there was some mechanism for expansion ROM addressing
> > in the memory card slot. It may be possible to use this for adding more
> > RAM instead.

Not really - the only additional memory space supported using this
method is banks $F0 through $FB ($FD on a ROM 1), and they are only able
to be used as simulated ROM, not for standard application use.

James Keim <jkeim@unlinfo.unl.edu> wrote:

> Hmmm, I'd like someone to explain the possibility of going
> beyond the 8 meg limit.  I think I've asked this same question
> myself at some point in the past.  I don't remember what I was
> told, though.  I've been under the impression that it was a
> hardware limit.  However, I've also been told that the problem
> would lie in a major rewrite of the memory manager.  I kinda doubt
> anyone would be interested in taking on that task.

I am aware of the following limits:


1. Memory Manager toolset
-------------------------

The Memory Manager does not attempt to access memory banks beyond $7F
during its initial RAM test to determine memory size.  Banks $80 through
$DF are marked as "reserved" in the tables (a handle is set up to cover
this area during initialization).

In theory, it would be possible to patch the Memory Manager to allow
memory to be allocated in banks $80 through $DF - it just requires
freeing this handle and reserving a smaller one in its place, according
to the actual amount of RAM present.

It should be possible to do the same for banks $E2 through $EF.  I
wouldn't recommend touching banks $F0 through $FB (or $FD) as they might
be used by some ROM disk products.

It would also be necessary to patch the "total RAM size" information.


2. Memory addressing signals on the expansion slot
--------------------------------------------------

The memory expansion slot only supports 4 MB of RAM using the standard
decoding scheme.  The FPI or CYA chip decodes the bank and presents the
appropriate multiplexed address and row number to the memory card.

Cards which support more than 4 MB do so by reading the bank address
from the data bus during the first half of the cycle.  The problem with
this method is that the bank address is not provided during a DMA cycle,
so DMA will fail with these cards.

(The RamFast uses a special technique to get around this problem.  I
don't know exactly how it does it, but the end result is that the bank
address is provided to the memory expansion card, which means it should
be able to support any memory expansion card.)

In theory, this mechanism could be extended to bank numbers higher than
$7F.  However, the FPI/CYA chip (Fast Processor Interface - ROM 01, or
Control Your Apple - ROM 3) does not recognise banks $80 through $DF or
$E2 through $EF as being part of the "fast RAM" address space.

Someone would have to do some experimentation with a logic analyser to
determine exactly what happens when you try to access these areas.  [I
can probably do this with some fiddling, as I have a IIgs and a logic
analyser at work.  The main problem will be connecting the analyser to
the slot.]

It all depends on how the FPI/CYA treats these addresses.  I can think
of the following design options:

(a) The FPI/CYA checks specially for banks $E0, $E1 and $F0-$FF.  All
other banks are assumed to be fast RAM.

In this case, there is no major problem - the memory card can simply
decode more banks.  Refreshing may have to be handled specially.

(b) Banks $80 and higher are treated like ROM, with signal routing as
appropriate for banks $E0, $E1, $F0-$FB/$FD and the motherboard ROM.

This would require special handling on the memory card: the address is
encoded quite differently for ROM and fast RAM.

For fast RAM using 1MB rows, the lower 20 bits of the address (offset by
the amount of motherboard RAM) are provided in multiplexed form on
FRA0-9.  Two more bits are provided on CROW0-1, and the card can decode
further bits from the bank address on the data bus.  Row and column
address strobe signals tell the card when to get the multiplexed
address.  The FPI/CYA also generates refresh cycles for the RAM using
the multiplexed address and strobe signals.

For ROM (nominally banks $F0-$FB or $FD), the FRA0-9 signals contain the
lower 10 bits of the address, the A10 to A15 lines contain A10 to A15,
and the data bus has the bank address.  A different select signal is
used.  No refreshing is performed in this area.

The select signal would probably be missing.

(c) The FPI/CYA checks bit 7 of the bank address: banks $00 to $7F are
fast RAM, banks $80 and higher are special.  Banks $E0, $E1 and $F0-$FF
are then decoded as appropriate, and other banks are simply ignored.

In this case, there is no way you can add the extra memory, because the
card will not be able to detect that an access is taking place, let
alone respond to it.

Personally, I expect the third case is how it is implemented, so there
is physically no way you can access any extra memory.


3. Accelerator Compatibility
----------------------------

The TransWarp GS implements its own memory in the higher banks, e.g. for
its CDA, boot software, and application programming interface.  It would
probably not provide access to any external memory in the $80-$DF and
$E2-$EF banks.

The ZIP GS may have special handling of banks $E0 and $E1, and treat ROM
(banks $F0 up) differently from fast RAM, but I expect it would work
with memory beyond bank $7F.


4. DMA Compatibility
--------------------

I expect that DMA will not work at all beyond the 8 MB boundary (though
the RamFast might be OK).  Apple's SCSI drivers already know to avoid
DMA accesses outside the 4 MB limit, so this shouldn't be a problem with
an Apple SCSI card - you will just get slow I/O to the extra memory.

> Now, an interesting point to ponder is how the folks at Apple
> who are creating GUS, the IIgs emulator, managed to break the
> 8 meg limit in emulation.  GUS reportedly will allow you to run
> an emulated accelerated GS with up to 14 megs of memory accessible.

No problem - they just need to patch the Memory Manager to allow it to
use banks $80 to $DF (an extra 6 MB).  In theory, it could also let you
use banks $E2 to $EF (896 KB).

GUS does not have to do a precise emulation of the FPI/CYA - it has no
memory slot, refreshing etc. to deal with.  It just needs a functional
equivalent, which is basically just a matter of enabling the correct
devices according to the address range (e.g. the emulated Mega II for
banks $E0 and $E1, reading from the ROM image for banks $FC-$FF, etc.)

> Now this fascinates me because I am not technically proficient
> enough to even begin guessing what allows them to do this.  
> I'm going to though.  ;-)
> 
>    1. They have addressed the hardware limit in emulation. 
>       (and current software still works)
>    2. They have rewritten/revised the memory manager for the
>       emulator [not sure where the main memory manager code is
>       located ROM/RAM, so I don't know if this possible].

The Memory Manager is in ROM, but individual calls may be added or
patched out during GS/OS boot.  I think the extra 6 MB could be added by
a patch during GS/OS boot (which simply updates the data structures in
memory), and it could definitely done by modifying the code in the ROM
image.

>       (and current software doesn't break)

This depends on whether any software is assuming that handles appear in
certain memory locations.  For example, an application may request a
handle with the "no special memory" attribute, then assume the address
is always less than $7F0000.  This would not be correct if banks $80 to
$DF are available.

Another problem is applications which loop through banks to allocate
memory in a certain way, e.g. multiple 64K banks.  They would probably
stop at bank $7F.  The System Loader toolset uses this mechanism to
implement "bank aligned" code and data segments, but I don't know if it
has a hard-coded limit of bank $7F.  It should use the maximum memory
value reported by the Memory Manager.

(An example of an application which loops through a fixed number of
banks is PaintWorks Gold.  The release version only tries the first
eight banks, which means it doesn't have enough memory to run in recent
system software versions.  The standard patch causes it to try every
bank up to $7F, which allows it to run as long as you have enough unused
banks anywhere in the 8 MB address space.)

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand