Blizkick 3.1.4 ROM slow performance?

[Firestone]

Yesterday I decided to try to upgrade my A1200 with Blizzard 1230IV/50Mhz with 32MB RAM and 68882/50Mhz.

This system got a large SSD PATA drive, and 3.1 was patched to make it work beyond the 4GB limit. The three first partitions are anyway below the 4GB limit and works fine when the system is unpatched. One of them is of course the SYS:-partition.

I got 3.1 in ROM.
So copied the kickstart-ROM-file from my 3.1.4 purchase into devs:
Cold boot, boot with no startup-sequence to have a clean system to test with.
Then I ran with Blizkick 1.24:

blizkick devs:kick314

The system reboots fine, and I got the new Early Startup-menu with the new options.
But here is the problem: I get a very noticeable performanceloss when this ROM is kicked. It takes significant longer for the Early Startup menu to display,
and clicking Boot With No startup-sequence after this gives me the dos-prompt of course, but everything feels slow from now on.
Scrolling text in the AmigaDOS-window is slower, disk performance is slower, pulldown menues are slower and so on.

I did nothing else than kicking the rom, nothing else is started.

So I tried to kick both 3.0 and 3.1 and the system then gets very snappy and boot is almost instant, everything is perfect.

For the past years I have lived with the same performanceloss as described when i kicked 3.1.4, but this was caused by:

LoadModule devs:scsi.device

in startup-sequence a part of making 3.1 4GB+ compatible.
I thought that going for the 3.1.4-solution would give me back the performance I had with 3.1, only with official 4GB+ support.

Is this normal behaviour for 3.1.4? I can't say that I have noticed that same slowdown on my A3000, but on the A3000 3.1.4 is Superkicked, not with Blizkick (Blizzard 4030-board).

Settings on my Blizzard 1230IV:
RAMSPEED jumper: closed
MAPROM jumper: open

My first thought when I a few years ago started to use the LoadModule-line for patching scsi.device on 3.1 was that it may have been loaded into chipram, and thinking that would had to been the reason for the performanceloss. But the whole system is slow, not just disk performance in both cases.

[daxb]

Usually blizkick should load the ROM to fastram but if it is loaded to chipram you should see it because 512kb of 2MB would be lost. I guess you checked or noticed that. You should check your S-S that SetPatch and/or LoadModule don't conflict with blizkick. Next thing to check is CPU usage (e.g. with Scout). Just in case make sure that exec.library isn't loaded to chipram for some reason.

[Firestone]

No chipram was lost, so the rom is kicked to fastram.
Checked scout with our without blizkick. Exec.library and expansion.library seems to be loaded to chipram according to Scout no matter what.

But Scout reports that exec.library is loaded to address $00001518 even when the systems performance is good. There must be something else going on.

[daxb]

If you don't run blizkick then SetPatch of OS3.1.4 will load some modules (maybe exec too?) from disk to memory because you have a physically 3.1 ROM. Is there something unusually under Scouts tasks CPU meter when the overall system is slow? Maybe some other system monitor tools can help like SnoopDOS, LibSnooper, SnoopLibs, Snoopy, ... can help to track down.

[Firestone]

I think I got this sorted out. Strange behaviour of 3.1.4 on this setup.
I seem to have gained full speed again, but I had to make Blizkick kick 3.1.4 as the first line in startup-sequence.

If I don't do that, the system will guru when it hits LoadModule ROMUPDATE.

Needs some more investigation, but the system is stable now.
The second A1200 I tried on only have kickstart 3.0, and if I install the system on that machine, it will guru on every boot when hitting the Loadmodule command.
If I use blizkick on the 3.0-machine, everything runs fine.

But I get that's one of 3.1.4's requirements: Kickstart 3.1 i ROM.

[daxb]

Blizkick is usually the first part in S-S and SetPatch starts later. LoadModule ROMUPDATE should be obsolete when you load 3.1.4 ROM file with blizkick. At least it has conflict potential if used both. You may ask THOR if it is normal behaviour (guru) when you softkick 3.1.4 ROM and later start LoadModule ROMUPDATE. Maybe LoadModule can't detect softkicked 3.1.4 ROM by blizkick and tries to update 3.1 ROM or the softkicked one.

[AMIGASYSTEM]

As mentioned by daxb you don't need to use Blizkick an file kickstart 3.1.4, if you have installed the right modules, kickstart 3.1.4 will be mapped automatically.

[Firestone]

Originally Posted by AMIGASYSTEM

As mentioned by daxb you don't need to use Blizkick an file kickstart 3.1.4, if you have installed the right modules, kickstart 3.1.4 will be mapped automatically.

That's what's strange AMIGASYSTEM, because it will guru as soon as it reaches to loadmodule-line in startup-sequence if it's not pre-kicked.....

....unless I boot with no startup-sequence, run the loadmodule romupdate-command and then run setpatch. Then it does not crash...

I will have to investigate further on that one...I'll be back

First section of startup-sequence:

; $VER: Startup-Sequence_HardDrive 45.4 (28.5.2018)
; Startup-Sequence for hard drive systems

C:Blizkick devs:kick314 QUIET

If Exists C:LoadModule
   C:Version exec.library version 46 >NIL:
   If Warn
      C:LoadModule ROMUPDATE
   EndIf
EndIf

C:SetPatch QUIET
C:CPU CHECKINSTALL

C:Version >NIL:
C:AddBuffers >NIL: DF0: 15
C:AddBuffers >NIL: HD0: 100
C:AddBuffers >NIL: HD1: 100
C:AddBuffers >NIL: HD2: 100
C:AddBuffers >NIL: HD3: 100

FailAt 21

[daxb]

My suggestion is that if you use blizkick to softkick 3.1.4 ROM you should not use LoadModule. So, comment the If Exits part.

[gulliver]

I also recommend you disable LoadModule by adding a ";" without quotes in front of it.

The problem you are getting into is quite easy to understand:

You are telling two different programs to take over the system. And they both do it in different ways, so they create conflicts between each other. Just stop using one of them.

IMHO, in this case I would keep Blizkick.

[Firestone]

Yes I know, but the problem is the opposite that you think.
There is never a crash when blizkick has been run because it will never evaluate the condition to true.
If blizkick is totally removed and I try to boot the system so that this condition is met, the system will guru, probably when the loadmodule and is executed.

[AMIGASYSTEM]

Watch this old video of mine, installed OS 3.1.4 with Kickstart 3.1, once the installation is finished KickStart 3.1.4 will be loaded automatically.

At the end of the video you will see also the initial part of the Startup-sequence


https://drive.google.com/file/d/1Daj...mDZ5PHPHr/view

[daxb]

Originally Posted by Firestone

If blizkick is totally removed and I try to boot the system so that this condition is met, the system will guru, probably when the loadmodule and is executed.

Then you should verify it be for example add "set echo on" in your S-S (first line). If the output is too fast you can add some wait commands to delay the execution.