Switch off / revert back VBR Move to fast

[alexh]

If you've got a program that expects the vector table not to have moved.. what is the most simple OS legal way of putting it back?

Why?

There are rumours that Ambermoon had issues that can be solved by turning off VBR moving.

I've never had these issues in 22 years of playing so I don't know if this is true. Worth testing.

[dlfrsilver]

whdload is an awesome tool for catching program errors.

this is why a slave is a very good idea for a game this big. In case of error, whdload will give access to bug reports.

[pipper]

MMULib comes with a tool that uses a different approach: use the MMU to map the VBR to fastmem, but leave its virtual address at 0.
This should give best of both worlds. Backwards compatibility for programs expecting VBR at 0, yet have it in fastmem.

[nogginthenog]

Originally Posted by pipper

MMULib comes with a tool that uses a different approach: use the MMU to map the VBR to fastmem, but leave its virtual address at 0.
This should give best of both worlds. Backwards compatibility for programs expecting VBR at 0, yet have it in fastmem.

I was going to say that

It's even better. Page zero is mapped to fastmem. This includes AbsExecBase which almost every program accesses.

[SpeedGeek]

Originally Posted by pipper

MMULib comes with a tool that uses a different approach: use the MMU to map the VBR to fastmem, but leave its virtual address at 0.
This should give best of both worlds. Backwards compatibility for programs expecting VBR at 0, yet have it in fastmem.

Apparently, you didn't read this comment:

https://eab.abime.net/showpost.php?p...5&postcount=13

The MMUlib does not use the simple "Ad Hoc" solution of just remapping the Zero page. It uses a more "Complex" solution which may solve one compatibility problem at the expense of another.

FYI, The AmigaOS CPU "FastRom" command (up to OS 3.9) will move the VBR into Fast RAM on 020-030 with MMU systems but won't move it back to Zero if it's disabled.

[Lisko]

Originally Posted by SpeedGeek

Apparently, you didn't read this comment:

https://eab.abime.net/showpost.php?p...5&postcount=13

The MMUlib does not use the simple "Ad Hoc" solution of just remapping the Zero page. It uses a more "Complex" solution which may solve one compatibility problem at the expense of another.

FYI, The AmigaOS CPU "FastRom" command (up to OS 3.9) will move the VBR into Fast RAM on 020-030 with MMU systems but won't move it back to Zero if it's disabled.

The nice thing about MMULib's MuFastZero is that you can enable/disable it in real-time and once disabled your system is in the same state as before you enabled it and you can run problematic programs just fine.
For example as I found that the nommu and novbrmove whdload options are, reasonably, incompatible with mufastzero I simply disable and re-enable it using whdload's startup and cleanup scripts. Other programs incompatible with it that I found are some demos that require disabling mufastzero too.

[saimo]

Just a general note: the MMU slows down memory accesses a bit (depending on the MMU type, on how it's programmed and what it is asked to do); therefore, if not needed to get the hardware to work properly and/or for other functional requirements (e.g. detecting memory hits, remapping the Kickstart ROM to FAST RAM on boards which can't do that automatically, etc.), one should evaluate whether MMU usage is actually beneficial.
Personally, I wouldn't use it just to remap the vectors table in FAST RAM.

[Lisko]

In general yes @saimo you're right and with the mmu enabled on an 030 I noticed that I/O operations are the most affected and slowed down. Using mufastzero for remapping 0 page, SSP and Exec in fast ram I instead noticed the opposite with boosted and faster I/O speed and also my system seems overall snappier than ever using the mmu and mufastzero than with them disabled.

[SpeedGeek]

Originally Posted by saimo

Just a general note: the MMU slows down memory accesses a bit (depending on the MMU type, on how it's programmed and what it is asked to do); therefore, if not needed to get the hardware to work properly and/or for other functional requirements (e.g. detecting memory hits, remapping the Kickstart ROM to FAST RAM on boards which can't do that automatically, etc.), one should evaluate whether MMU usage is actually beneficial.
Personally, I wouldn't use it just to remap the vectors table in FAST RAM.

Yes, I have explained this (several times before). For 020-030 systems don't enable the MMU unless there is good reason to do this. Using the VBR imposes no performance penalty but the MMU does.

Also, even when there is a good reason to use the MMU keep in mind that how the MMU is configured can vary significantly in performance:

https://eab.abime.net/showthread.php?p=1303345

For 040-060 systems the MMU must be enabled to manage the Copyback and Non-Cache modes for the complete Amiga memory map. But there can still be compatibility problems with the "Complex" Zero page solution as noted above.

Note: The RemapZero tool included with TurboMMU040+ uses the simple "Ad Hoc" method (so it remaps the Zero page and nothing else).

[saimo]

Originally Posted by Lisko

In general yes @saimo you're right and with the mmu enabled on an 030 I noticed that I/O operations are the most affected and slowed down. Using mufastzero for remapping 0 page, SSP and Exec in fast ram I instead noticed the opposite with boosted and faster I/O speed and also my system seems overall snappier than ever using the mmu and mufastzero than with them disabled.

Opposite experience here: on my A1200 + Blizzard 1230IV, after removing MuMove4K and MuFastZero, the transfer speed of the CF connected to the internal IDE increased by about 141 kB/s.