Amiga Memory Mangement

[trekiej]

Can some one tell me about memory management on the Amgia?
Some 68K cpu's had a MMU and some do not.
Thanks.

[rkauer]

trekiej wrote:
Can some one tell me about memory management on the Amgia?
Some 68K cpu's had a MMU and some do not.
Thanks.

 MMU have nothing to do in the memory management area.

 Memory is controlled by Alice/Agnus (chip RAM) and for the CPU itself (fast memory). The amount of RAM depends on the CPU address lines (24 bits on 68000, 010 and EC020 CPUs = 16Mb, where 8Mb is already taken by the Amiga chipset), up to 4Gb in 32bit CPU (full 020, 030 and over).

 But this is not fully implemented in hardware since you need:

 - a lot of mux/demux chips to route the RAM chips;

 - too much hassle to design a board with more than 128Mb using 72pin SIMM (newer memory banks must a new, designed from scratch, memory address controller). :headwall:

[weirdami]

MMU = math thingy?

[Piru]

@trekiej

On the software side, the amiga memory system is simple first fit allocation system. It is a global memory system (that is all tasks/processes share the same global memory pool). Basically this means that many applications are programmed in a way that they access each others memory at will, making it impossible to introduce memory protection (via MMU) without breaking the binary compatibility. The closest you can get is system provided by the mmu.library.

First fit allocators slow down exponentially due to memory fragmentation, the problem made worse by the global memory system. The effects of the fragmentation can be reduced with a better allocator however: for example two level segregate fit. There's a great AmigaOS 3.x implementation by Chris Hodges: TLSFMem.lha. Note that while TLSF does reduce fragmentation it doesn't remove it completely. However the fragmentation still remaining will have no effect on the allocation/deallocation performance.

PS. Fix that keyboard... :-)

@weirdami

MMU = math thingy?

No. Wikipedia: Memory Management Unit

[trekiej]

@ Piru:
It is the operator.  :-D

I feel that Zorro cards use AutoConfig.
Is there a situation where someone would use TTL chips to make a card work at a specific location?

[rkauer]

trekiej wrote:

I feel that Zorro cards use AutoConfig.
Is there a situation where someone would use TTL chips to make a card work at a specific location?

 Nope. In the case of the autoconfig cards, there is a 64kb memory area on big-box Amigas to settle the card ID and small settings.

[trekiej]

@rkauer: That leads me to believe that one would have to access that info. through the kernel or hardware to get the location of the PIC's address.
I need to finish reading Zorro3 manual.
 :-D

[rkauer]

 No need to.

 I'm certain someone (like Piru ;-)) have this information in the his mouth/fingers right now. :-)

[Piru]

The Amiga Hardware Reference Manual should have the Zorro(R) AUTOCONFIG(TM) explained pretty well.

[alexh]

Piru wrote:
@trekiej
Two level segregate fit. There's a great AmigaOS 3.x implementation by Chris Hodges: TLSFMem.lha.

Shame it was not finished, it had so much promise. It still has one or two bugs in it which make it a little incompatible with some programs. I heard that someone had taken over this project, renamed it MemTLSF, but I have seen no more releases.

[Piru]

@alexh

It still has one or two bugs in it which make it a little incompatible with some programs.

What kind of bugs exactly? Would be interesting to do last minute testing of the MOS 2.0 TLSF memsystem I wrote (it's not based on Chris' code but shares much of the ideas, so it might also share bugs).

[Damion]

I get recoverable alerts with a few programs, for example the old Chris Hames "Degrader" program gives me a "715F 0041", system eventually returns with around -530,000,000 fast mem available, and will generally crash for good shortly after, LOL.  

I've found it's fine 99% of the time though, and I have _no_ clue whether it's a TLSFmem bug or bugged program.

[Piru]

I would imagine that's just Degrader doing some rather nasty tricks, it's quite hacky program after all.

[alexh]

Wepl wrote:
It seems that TLSF returns 2,018,011,950 for AvailMem(MEMF_LARGEST).

Which causes nothing to be preloaded in WHDLoad as it uses this to calculate the puddle size for the memory pools used for the PreLoad memory.

http://eab.abime.net/showthread.php?t=33790

[Piru]

@alexh

Ok, no such problem in mine.