Conference hydra::amiga_v1

    From what I've heard, chip ram cannot be expanded beyond 512K due
    to the custom chips ability to only access that ammount.  Fast ram
    can be added up to 9 Megs (Yes 9, not 8), but you have to do some
    hardware work to make it recognize 9Megs.  The Pal expansion system
    has one Meg on board expandable to 9 megs of fast ram.  They call
    fast ram, because there are no wait states, and the cpu has total
    access over it.  The custom chips won't touch it.
    
    I was thinking though, if you wanted to expand the amiga beyond
    9.5 megs, you could develop a bank switched set of 8 Meg boards
    to have a massive Ram drive (maybe I'll try to build it)
    
    Some other hardware mods you can do, is replace the Kickstart Ram
    with ROMs, and have the extra Ram (256K) as fast ram.  That requires
    Kickstart in ROM though, and if you have any Kickstart 1.1 dependent
    software that you use a lot, you are up a creek.
    
    Well, I have rambled enough.  Has anyone purchased the Amiga schematics
    from Cardinal Software?  I was thinking of buying them sometime.
    
    Derek Bosch
    

    Yes I know the custom chips cannot address more than 512k - but
    it doeesn't necessarily mean you coudn't put more than 256k
    expansion memory in the front slot; I'd say it depends if there
    are enough address lines for the slot??? MAybe it's not as fast
    as fast ram if the custom chips access the low 512k thru the same
    bus, but it's nevertheless a possibility for memory expansion -
    besides it saves the expansion slot on the side for other purposes.
    (Some of the less expensive fat RAM expansions don't seem to
    pass thru the bus).
    
    ??? 
    

re: .1

>    Well, I have rambled enough.  Has anyone purchased the Amiga schematics
>    from Cardinal Software?  I was thinking of buying them sometime.
>    
>    Derek Bosch
    
A friend got his directly from Commodore.  They were cheaper, too, $20 
instead of $25(?).

John

    the chip memory expansion slot only has address lines for the 256K
    board.  The key to understanding chip vs fast ram is the two busses
    in the Amiga.  One connects the 68000 and the custom chips, the
    other connects the 68000 to the expansion bus.  Memory connected
    to the custom chip bus is chip memory, memory connected to the
    expansion bus is fast memory.
    
    The chip memory gets complicated by the max 512K addressing that
    the current custom chips can do.  2 Meg of addressing space is reserved
    for chip memory.  You can have "pseudo-fast" memory residing in
    that 1.5 Meg space (like fast memory since the custom chips can't access
    it, but like chip memory since you can get bus contention with
    the custom chips).
    
    -dave

    So how does this company make their 768k add-on memory work?
    Has the chip memory bus *no* address address lines for >512k
    (in which case they must be lying) or are the additional
    lines (up to 2 meg = 2 more lines) just not brought to
    the connector?

    you guessed it, the additional lines are not in the connector.
    
    the 768K upgrade you mentioned sounds like its a 256K + 784K = 1 Meg
    upgrade.  

    -dave

    re .6: Reread .0, that's exactly what I said in the first place
    - but how do they do it if there aren't enough address lines?
    
    The ad says you take out the 256k expansion and plug in theirs (768k);
    so you'll be left with 256k internal + 768 k expansion = 1 mb
    (+ the old 256 k expansion to be used as a boat anchor [probably
    too light for that]).
    
    Is the additional line for addressing 1 mb on this bus available
    internally? Knowing how advertising works, it wouldn't surprise
    me if they conveniently forgot to mention you have to do some HW
    hacking to make this work.

    re: .7: Reread .4, the potential is there for the address lines
    inside the case.  But the current chips don't use it.
    
    There is an article in a recent issue of Amazing Computing that goes
    into hardware hacking detail of how get get at the addressing lines
    inside the case.  They chose to do the upgrade internally - just
    ignore the 256K board - because of need to run those extra
    address lines to the connector.  Maybe someone has found a way
    to do minimal changes to the internals?  I've seen the ST
    memory upgrades progress from piggybacked chips to a daughter
    board connected to one of the few socketed chips.  Maybe if
    some of the ST daughterboard companies thought they could
    sell to the Amiga market, we might not have too long to wait
    for no solder cheap memory expansion.
    
    -dave

    re .-1: BTW, a German company is offering an add-on (fast) memory
    that goes to the 68 k chip socket - plug out the 68k, plug in the memory,
    and the 68k into the memory board. But it is very expensive though
    there isn't much HW involved (no case etc). If I remember coreectly
    it was >$500 for 1mb.
    

    How about a bank switched memory board, maybe 1 Meg, that plugs
    into the 256K expansion port?  That would get around the need
    to gross hack inside the case - just need the hardware to software
    select which banks are active.  And the memory would be chip ram.
    Think of the potential - blitter ram disk, animations by bank
    switching, lots of chip ram available with careful programming.
    
    The following is from the Usenet ST newsgroup.  It describes a ramdisk
    for the ST cartridge port, something that used to be considered
    a read-only port with 128K of address space.  If they can do it...
    Any hardware hackers out there care to comment?
    
    -dave
    
    
    Newsgroups: comp.sys.atari.st
Path: decwrl!decvax!ucbvax!sdcsvax!ucsdhub!hp-sdd!ncr-sd!ncrcae!usceast!tech
Subject: Re: An external RAM disk for the ST
Posted: 1 Mar 87 04:48:16 GMT
Organization: Csci Dept, U of S. Carolina, Columbia
 
In article <587@viper.UUCP> john@viper.UUCP (John Stanley) writes:
>A question to Bill Wood on the PolyDisk ramdisk cartridge:

....
	I don't have the circuit figured out completely yet either so
the following is possibly subject to change.
	The Polyram has a 4-meg address space. That is they (I think)
support 32 64k blocks. Memory reads are performed in the first bank of
the cartridge address space and they map the second bank of the
cartridge for the writes. I am not sure yet how they are doing this.
The 4-meg above came from a conversation with their engineers. 
	There is a way according to them to piggy-back more rams onto
the board but it requires cutting traces and they were not interested in
telling me how.
	The circuit consists of 31 IC's of which 16 are 256k dram. Five
of the chips are dual 4 to 1 multiplexers which I believe are used to
multiplex the addresses into the ram. I believe that the circuit can be
broken down into 4 major component areas: refresh timer, clock control,
address multiplexers and ram. This would make sence if they were
decoding a one meg address space as a piggyback expansion would suggest.
Another piece of evidence is that it takes 10 bits at a time for address
generation in a one meg space and they have 10 total multiplexers. They
use a ls123 timer for refresh timeout. That is they do nothing at all
about refresh when the system is running since the activity on the
cartridge address buss is enough to refresh the ram. The timer is
necessary to keep the memory alive when a reset occurs since the address
buss 'hangs' while the button is held down, and of course with a battery
backup it becomes necessary. The clock control is just a mapping of the
highest bit of the address to a clock chip expansion board. I am pretty
sure of this since their people said that you would have to disable the
clock control to go from a 2-meg space to a 4-meg space.
	The rest of the chips are simple ttl glue and a couple of byte
wide latches. I tend to think that synthesizing a write line is pretty
easy if you are willing to live with two or possibly three cartridge reads
for every write into the external address space. A base address with an
offset of 0-255 would allow the address buss to be used as a 'data'
buss, it then becomes necessary to do something similar to setup an
'address' buss and a write line.
	All in all, I think the circuit is pretty simple and elegant. I
can kind of understand their unwillingness to disclose to much since
there are sure to be several 'imatations' in the near future. I am going
to expand this one to one meg just as soon as I figure out how since I
am about 200k short of what it takes to get all of the compiler and
utilities out there that I want.
	I have not benchmarked this unit extensively but it is slower
than eternal.prg by what seems to be a factor of 2. This makes sence if
they must do two or several reads to the cartridge port to do a write.
In closing, I like this unit a lot and would recommend it to the rest of
you. 
.... 
			Bill Wood (!usceast!tech)
    

    I'd always thought that the true beauty of the 68000 architecture
    (if there is any) is that with the 24-32 bit address space, you
    wouldn't have to resort to such gross hacks as bank switching.
    
    Memory management on a smaller page size than 256K would be nice,
    but switching banks of 64-256K hunks is precisely the thing I thought
    we were trying to get away from.

    ...but since the custom chips have a limitation of 512K, doing a
    bank-switched ram add-on makes good practical sense, even if it
    makes pretty unpleasant architectural (un)sense.
    
    -jim

    Judging from the title on .14:
    
    Hardware may be easier than software, but making the software fly
    with bank switched 256K (or smaller) chunks of chip RAM can be a
    real dog.
    
    For instance, how do you explain this to the memory allocator? 
    Assuming you don't, how do you insure that there aren't any tasks
    residing in the bank switched RAM that don't know about this?  You
    flip the bank to get another hunk of your picture, and in the mean
    time, some task who thought it was loaded into that section of memory
    starts up, and tries to execute some garbage that isn't part of
    its task image, because it has been bank switched away.
    
    Yeah, you can make it work after a fashion, but what you'll end
    up with is either 256K of CHIP RAM thats usable by the system itself,
    or 512K of CHIP RAM, with all the bank switched stuff virtually
    unaccessible because there aren't many good ways to get all those
    other guys occupying the RAM out of the way when you switch banks.

    re: .15
    
    how about if you do a
      Forbid()
        switch banks, grab the info out of it, switch back to original
        bank
      Permit()
    
    The memory allocator should only see the original chip memory, the
    "special application" is the only one who needs to or knows how
    to access the bank switching.  (unless you could teach the memory
    allocator about bank switching...)
    
    -dave

    Doesn't matter how badly your forbid things, the CHIPs are still
    going to be trying to fetch things out of CHIP memory, which is
    what the stuff on the front of the Amiga memory expansion bus is
    (unless you can put something other than CHIP memory there, and
    if you can, it nearly makes this discussion moot).  Since this is
    CHIP memory, there's a strong possibility that there's some display
    images in it.  If you switch banks, the graphics chips aren't going
    to be checking the status of Forbid/Permit (or even Enable/Disable,
    since Forbid isn't going to prevent interrupt processing, which
    you hope isn't going to use any of this magic RAM), you're going
    to have a problem.  At best, the graphic data will just be that,
    and you'll end up displaying garbage from the other bank of memory.
    At worst, there may be a copper list in that switched RAM, and there's
    no telling what'll happen once the copper guy starts going wild
    in that "new" memory.
    
    Still doesn't sound good.

    is it possible to reserve/allocate memory residing at specific address,
    like a 16K chunk of chip ram, for an application?
    
    If yes, then maybe that could be grabbed by the application during
    system startup, before the system allocates the memory for other purposes.
    
    If not, then this discussion is moot too.
    
    -dave 

    .15 says what I was trying to say in .14.  Building the hardware
    to do bank switching is much easier than building the software
    necessary to deal with bank switching.  I suspect that adding
    the additional address lines would be easier than building the
    software alluded to in .15-.18.
        John Sauter

    
    From reading this, it sounds like the problem is not enough Chip
    ram. I don't think new graphics chips are comming anytime soon (
    the best solution ). But one idea might be to add Fast RAM to the
    system and a memory to memory DMA engine. There are some very good
    DMA controllers that could be used by a program to do a high speed
    block move.
    	The software would be easy. The DMA engine could move any number
    of bytes just were you want them. The DMA engine could also be used
    to speed up floppy transfers ( not by much ).
    
    
    		Steve Peters
    

    
    I think a memory to memory swap is a good idea in principle and
    the 68000 could do it, but multitasking would have to be disabled
    for it to really work.  After all you may be swapping out a task
    which EXEC will try to execute.  If you can't run anything else at
    the same time then you might as well have the program take over
    the machine and have the code manage the entire 512K.  Once you've
    done this memory to memory swaps are easy, they're called assignment
    statements :-).

    Of course I may have totally misunderstood what you meant...
        
    regards,
    
    steve mcafee
    

    .21:
    
    That's mostly true.  You'd also have to disable the graphics chips,
    or at least make sure that they aren't going to be looking at the
    memory that you're about to switch.  Since we've been talking about
    CHIP RAM, there's a pretty good chance that you're about to switch
    something out from under the graphics chips.  Don't want to think
    about what it would look like ;-)

    re: .20
    
    an external DMA fast ram disk is what Commodore is currently selling
    for the C64/C128 according to an interview with the folks who wrote
    GEOS.  They said it was faster to move bits by DMA thru the ram disk,
    than to move them memory to memory.  I believe it comes in a 128K
    and a 512K version.
    
    re: the graphics chips vs swapped memory
    complex software and flexible hardware is what the Amiga is famous
    for... :-)    
    
    -dave

    I've been following this thread with interest, since I often perceive
    the 512K chip RAM to be a limitation on current Amigas.  Can someone
    answer this for me... As an experiment, run DPaint, in any resolution,
    then pull down the DPAint drag bar to uncover the Workbench screen
    underneath.  Then, run a chip/fast memory monitor, such as RSLClock.
    
    Go back into the DPaint screen, and grab a large chunk of screen
    as a brush.  Move the mouse on and off of the screen, taking the
    brush with you.  Notice that the chip memory remaining goes up and
    down as the brush covers and uncovers the screen.
    
    My question is, is DPaint smart enough to surrender chip memory
    that is not on the active screen area, or is some electromagical
    illusion going on?  Bear in mind that I have absolutely no
    understanding of the Amiga, or much of anything else for that matter,
    so this may be a dumb question.
    
    Do all 'correctly written' applications have the decency to return
    unused chip memory to the system?  If this were the case, then chip
    memory would not be much of a constraint, since I could have up
    to 8 med-res screens, or 12 lo-res screens in chip memory at one time, 
    more than I can generally keep track of.

    
    re .24
    
    Most likely the dpaint screen is allocated differently than the
    workbench screen.  For example, if one uses SMARTREFRESH and
    the other uses NOSMARTREFRESH then when something is hidden in the
    first screen more memory will be consumed than in the second screen.
    This is basically because intuition will keep track of the hidden
    bits in the one scheme.
    
    Any other suggestions?
    
    regards,
    
    steve mcafee