Get into Fastram you naughty EXEC

[NovaCoder]

I'm confused....again.

Specs: A1200, OS3.9 + BB2, Blizzard 030 Mk4

I've just noticed that my Exec.library is not getting loaded into FAST RAM and 'appears' to be stuck in CHIPRAM along with expansion.library.

I've got my maprom enabled and I'm using BlizKick to load exec V45.20 as a module but both SysInfo 3.24 and SysSpeed tell me that it's still in CHIP RAM?

I normally run SETPATCH with the SKIPROM update flag.

[NovaCoder]

You need to use the 'LocalFast' module in BlizKick to move the Exec.Library to FAST RAM with Blizzard 1230 boards.

Ok, thanks but what about that expansion.library, any chance of 'getting it up' and is there even any performance advantage in doing so?

[matthey]

Build your own custom ROM with Remus...

http://www.doobreynet.co.uk/beta/index.html

Apply patches and updates like these...

http://amikit.amiga.sk/patches.htm

and kick the ROM image into your FastROM with this...

http://aminet.net/util/boot/BlizKick.lha

[NovaCoder]

Seems like it might not be such a good idea to move expansion.library into FASTRAM

Fast_Exe

Interesting.....

[matthey]

Seems like it might not be such a good idea to move expansion.library into FASTRAM

Yes. I BlizKick my own custom kickstart and the expansion.library is NOT in fast ram. It's the only library not in fast ram.

[AmiDude]

What about MuFastZero?

"MuFastZero will remap the zero page of the RAM, which usually contains the
autovectors for interrupts, from ChipMem to FastMem. It will *NOT* change the
vector base register because this might result in certain incompatibilities.

It moreover replaces FastExec, which is really a bad hack, by providing a
method to relocate a chip memory based exec and expansion library to fastest
memory and hence speed up the system even more. For that, the "preparation"
tool "MuMove4K" must be run, which is contained in this archive. "MuMove4K"
replaces also the ShapeShifter "PrepareEmul" tool by something smarter.

Last but not least, MuFastZero can be told to remap the supervisor stack
to Fast memory as well."

[matthey]

I run MuFastZero in my startup-sequence and my expansion.library in still not in fast ram. I expect there is a good reason for this. Probably because chip ram is always at the same location and doesn't go away at reset which makes life at startup much easier.

[Piru]

I run MuFastZero in my startup-sequence and my expansion.library in still not in fast ram. I expect there is a good reason for this. Probably because chip ram is always at the same location and doesn't go away at reset which makes life at startup much easier.

Actually AFAIK it is. You just can't see it from the address (it's remapped with MMU).

[matthey]

@Piru

Interesting. Obviously, with MAPROM, one copy of the expansion.library would be in fast ram. If that copy were used then what program would map it into the lower memory address? The MAPROM code? The AmigaOS doesn't touch the MMU as far as I know. You would probably know if BlizKick did it. I wouldn't think there would be any need to do so by the time the 680x0.library starts. Maybe the address is in the ROM and not chip ram. I'll have to have a look at the address again. If the expansion.library in the ROM is always used then maybe the expansion.library would be unnecessary in the MAPROM kickstart. I'll have to do some investigating.

[NovaCoder]

Actually AFAIK it is. You just can't see it from the address (it's remapped with MMU).

Hi Piru,

Is it even a good idea to try and map the expansion.library to FASTRAM?

I assume that BlizKick doesn't do it is because it's a bad idea?


Thanks

[SamuraiCrow]

Note:  to use FastZero, you need an MMU and not all Amigas have them.  I think the Blizzard 1230 does though.

[matthey]

My expansion.library memory address ($46CC) shows up as being in chip memory in Scout.

$0-$200000 chip memory
$F00000-$1000000 motherboard ROM

The MMU would have to map some of chip memory somewhere else and then fast memory to the old chip memory location for the expansion.library being used to be in fast ram. I highly doubt that. It looks to me like the expansion.library is actually in chip ram.

[Piru]

@Piru

Interesting. Obviously, with MAPROM, one copy of the expansion.library would be in fast ram.

Actually it wouldn't. MAPROM just moves the ROM to fast memory. It doesn't actually change the way the ROM itself works. So expansion.library, exec.library and supervisor stack will end up to same memory regardless if you have enabled MAPROM or not.

My expansion.library memory address ($46CC) shows up as being in chip memory in Scout.

$0-$200000 chip memory
$F00000-$1000000 motherboard ROM

The MMU would have to map some of chip memory somewhere else and then fast memory to the old chip memory location for the expansion.library being used to be in fast ram. I highly doubt that. It looks to me like the expansion.library is actually in chip ram.

That's how it works, except that only chip memory needs to be mapped to fast memory. Since the expansion.library doesn't know it has been remapped elsewhere it doesn't need to have mapping the other way.

[Piru]

Hi Piru,

Is it even a good idea to try and map the expansion.library to FASTRAM?

I assume that BlizKick doesn't do it is because it's a bad idea?

By conventional means it is a bad idea. With MMU it is possible, assuming at the whole MMU page worth of chip memory is allocated for it. I believe this is what the "prepare" tool in mmulib method is doing.

However, expansion.library is rarely used so it doesn't really matter that much. exec.library and supervisor stack is much more important to have in fast mem, and this is possible even without mmu.library.

[NovaCoder]

By conventional means it is a bad idea. With MMU it is possible, assuming at the whole MMU page worth of chip memory is allocated for it. I believe this is what the "prepare" tool in mmulib method is doing.

However, expansion.library is rarely used so it doesn't really matter that much. exec.library and supervisor stack is much more important to have in fast mem, and this is possible even without mmu.library.

Ok, thanks for the info