VBRControl causes ~1min Enforcer startup time

[patrik]

I thought moving VBR to fast ram was rather standardized, but it seems this is an incorrect assumption.

I have been using VBRControl to move VBR to fast ram, but noticed that it causes Enforcer to behave rather weirdly on startup - it locks the computer for about a minute before reporting "Enforcer is on the job." (can't even move the mouse during that time).

Using any other of the tools available on aminet to move VBR to fast ram does not cause this behaviour. An example of a tool not giving this effect with Enforcer is VbrMove.

This is on a very standard A3000 030, 16MB RAM, Kickstart/Workbench 3.1.

Anyone else have experienced this or have an idea what might cause it?

[patrik]

Replying to myself here as I stumbled upon the reason by accident .

Was working on a tool which reads the whole interrupt vector table. On one of the machines I tested it on, I got lots of enforcer hits because I was reading past the end of fastmem.

It turns out this machine was running VBRControl and disabling it fixed the enforcer hits .

After digging some more, I found that the real reason is that VBRControl treats the interrupt vector table as it only is 256 Bytes, while it actually is 1024 Bytes plus the fact that it allocates this space from end of fastmem.

Because VBRControl allocates from end of fastmem makes it quite easy to see that it only allocates 256 Bytes:

8.Ram Disk:> vbrcontrol on 
Vector base is located at: 07FFFF00
8.Ram Disk:> work:System-Info/Scout/Scout.os3 COMMAND=memory 
 
  Address  Name                 Type     Pri    Lower     Upper  Attr

 $07000000 expansion memory     memory    30 $07000020 $08000000 $0505
 $00004000 chip memory          memory   -10 $00004020 $00200000 $0703

Enforcer also moves the interrupt vector table to a new location, but it copies the correct 1024 Bytes. So if VBRControl is run before Enforcer, it will as my tool did, also read past the end of fastmem.

At least on the A3000, reading past of the end of fastmem is very slow, thats why Enforcer takes so long time to start in this case.

Note: If the mmu.library and 68030.library from the MuTools package are loaded, the reads past fastmem end are fast and Enforcer starts without noticeable delay.