MMULib, weird problem

[utri007]

Problem started when I replaced hard drive with SD based solution. I just copied hard drive content to new drive after I had created new partions.

My Zorro IV / FastATA ZIV started to require soft reset to boot from hard drive.

Tried two different kickstarts and CF based soltion and result was same.

Problem started to solve, when I noticed that I can get to FastATA prefs, even from cold bot, so it does boot from hard drive, just not to OS.

Here is my startup-sequence's first lines.

C:CheckLMB
IF WARN
SYS:Prefs/FastATAPrefs
ENDIF
C:FastATA.driver QUIET
; $VER: Startup-Sequence_HardDrive 45.4 (28.5.2018)
; Startup-Sequence for hard drive systems

;C:MuMove4k
C:SetPatch QUIET
;C:MuFastZero ON FASTEXEC
C:MuFastRom ON Protect >NIL:
C:CPU CHECKINSTALL

Solution was disable MuMove4k and MuFastZero.

How this was NOT a problem with old hard drive???

[Lisko]

OS and kickstart version? I had a similar problem with mumove4k, os 3.2 and vinced boot shin; I needed an updated vnc.library recently released on aminet.

[Thomas Richter]

Originally Posted by utri007

Problem started when I replaced hard drive with SD based solution. I just copied hard drive content to new drive after I had created new partions.

Could you please state your problem more clearly, because I don't understand it.

Originally Posted by utri007

My Zorro IV / FastATA ZIV started to require soft reset to boot from hard drive.

How could MuMove4k be related to that? Or rather, without a hard drive, how is it executed?

Originally Posted by utri007

C:FastATA.driver QUIET

What does this do, and why it is required so early in the startup-sequence?

[utri007]

Originally Posted by Thomas Richter

Could you please state your problem more clearly, because I don't understand it.

Problem is my Zorro IV / FastATA ZIV required soft reset to boot from hard drive if MuMove4k and MuFastZero are on startup-sequence.

It how ever worked just fine with "real" hard drive earlier.

What does this do, and why it is required so early in the startup-sequence?

I have no idee why it is required so early on startup-sequence, but it is FastATA driver, without it, FastATA is not that speedy 8mb/s.

[utri007]

I tried to edit startup-sequence so that C:FastATA.driver QUIET is after mmulib thingies and enabled C:MuFastZero and C:MuFastZero. It didn't work, problem was there again. I needed to do soft reset to get it get it boot from hard drive.

[edit] I have also tried to disable four fist lines, that din't help either [/edit]

C:CheckLMB
IF WARN
SYS:Prefs/FastATAPrefs
ENDIF

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

C:MuMove4k
C:SetPatch QUIET
C:MuFastZero ON FASTEXEC
C:MuFastRom ON Protect >NIL:
C:CPU CHECKINSTALL
C:FastATA.driver QUIET

[utri007]

I aslo made two minits video to demonstrate problem.

[ Show youtube player ]

[Lisko]

If you disable fastata driver does mumove4k works? If yes could be the driver messing with some chipram space needed by mumove4k. What I can't understand it's why the same configuration works on mechanical hard drive and not on CF, maybe something related with your actual CF2IDE adapter I don't know...

[Thomas Richter]

Does it work if you delay upfront MuMove4K with WAIT, such that the reset comes later? Maybe the reset is triggered right while the ATA is initializing itself.

[Lisko]

Originally Posted by Thomas Richter

Does it work if you delay upfront MuMove4K with WAIT, such that the reset comes later? Maybe the reset is triggered right while the ATA is initializing itself.

He tried loading the driver after mumove4k and mufastzero and got the same results

[utri007]

Originally Posted by Lisko

If you disable fastata driver does mumove4k works? If yes could be the driver messing with some chipram space needed by mumove4k. What I can't understand it's why the same configuration works on mechanical hard drive and not on CF, maybe something related with your actual CF2IDE adapter I don't know...

FastATA driver has no any effect to result. Using or not using it at all, has no matter for the result. If mumove4kb is enabled result is same, no matter what are before or latter it.

Note this used to work with real hard drive, problem is SD and CF hard drive replacements.

[daxb]

Did you had FastATA.driver running while set up your HD/SD? Did you run FastATAPrefs and clicked on the Save button? The Readme says that all this is needed.

If you still have problems you should comment all third party stuff (Mu stuff for example) in your S-S. I.e. get a clean system running.

I'm not sure but I guess the Zorro version of the FastATA doesn't need a reset itself like the non Zorro versions may need. If so your clean system should run without any second reset.

[utri007]

Originally Posted by daxb

Did you had FastATA.driver running while set up your HD/SD? Did you run FastATAPrefs and clicked on the Save button? The Readme says that all this is needed.

Quick start quide doesn't mention that FastATA should be running when setupping system. Originally I just plugged old hard drive to FastATA ZIV and it just workded. Driver, FastATA prefs + save is needed to get speed over 1,5mb/s.

If you still have problems you should comment all third party stuff (Mu stuff for example) in your S-S. I.e. get a clean system running.

I'm not sure but I guess the Zorro version of the FastATA doesn't need a reset itself like the non Zorro versions may need. If so your clean system should run without any second reset.

Well I don't have problems, if MuMove4k and muFastZero are not running. FastATA ZIV doesn't reset system on boot.

[utri007]

Originally Posted by Thomas Richter

Does it work if you delay upfront MuMove4K with WAIT, such that the reset comes later? Maybe the reset is triggered right while the ATA is initializing itself.

FastATA ZIV it doesn't reset system on boot. It doesn't matter if FastATA driver is runnign or not, or does it run before or after MuMove4k. It works perfectly fine without a FastATA driver, just speed is degraded to 1,5mb/s, but boot still stops to MuMove4k, until A + A + CTRL is pressed.

PS. FastATA ZIV manual is same than FastATA 4000 manual.

[Lisko]

Which OS version? I would try a fresh system with only mmulibs and fastata driver installed. Just to be sure that it could work.

[utri007]

Originally Posted by Lisko

Which OS version? I would try a fresh system with only mmulibs and fastata driver installed. Just to be sure that it could work.

OS version is 3.9

Originally I had a OS3.9 with ks3.9, now I'm running OS3.9 with ks3.1.4.

Originally I also had two hard drives, OS3.9 and OS3.1 with quite plain version of it. Problem was same with all possible scenarios.

But, this problem is before any OS components are loaded, it is with FFS and SFS, it with OS3.1 and OS3.9, KS3.9 and KS3.1.4.

BUT not if hard drive is real, mechanical.

[utri007]

Clean install of OS3.1.4 and problem is same. This time no FastATA driver or prefs or any othter programs installed at all.

C:MuMove4k
C:SetPatch QUIET
C:MuFastZero ON FASTEXEC
C:MuFastRom ON Protect >NIL:
C:CPU CHECKINSTALL

With this I get to KS3.1.4 screen "Please insert disk", soft reboot A + A + CTRL and it boots to OS. After FAstATA driver instal, I can get to FastATA prefs, before it display KS screem.

Disabling MuMove4k and MuFastZero it boots normally.

And again, current install on "real hard drive" works as should.

[utri007]

Short demonstration video of problem. Now FastATA programs installed. Problem is same are they installed or not.

[ Show youtube player ]

Cold boot - > ks screen
Soft reset - > OS
Cold boot - > Left mouse button and to FastATA prefs time 1:50

[Thomas Richter]

Originally Posted by utri007

FastATA ZIV it doesn't reset system on boot. It doesn't matter if FastATA driver is runnign or not, or does it run before or after MuMove4k. It works perfectly fine without a FastATA driver, just speed is degraded to 1,5mb/s, but boot still stops to MuMove4k, until A + A + CTRL is pressed.

PS. FastATA ZIV manual is same than FastATA 4000 manual.

Very concrete advice: Put a



WAIT 5


upfront MuMove4K and report back. MuMove4K doesn't do anything fancy to reset the machine, it just runs into a ColdReboot(). It may happen that the driver/the drive is still busy initializing itself, thus the wait may help. If that does not help, well, then the driver has an "issue" by not resetting itself properly on a software-initiated reboot. There is then nothing I can do.

[daxb]

Originally Posted by utri007

Quick start quide doesn't mention that FastATA should be running when setupping system.

In the FastATA software package is a Readme file I would recommend to read carefully.

FastATA.driver reads the config file that is saved by FastATAPrefs. So, if you change your configuration without saving it the old configuration is read/in use. FastATA.driver needs to be running because it builds the scsi.device that it using. If not running the default scsi.device or whatever device is used. It is not a good idea to setup drives with for example HDToolbox using different scsi.devices.

[utri007]

Originally Posted by Thomas Richter

Very concrete advice: Put a



WAIT 5


upfront MuMove4K and report back. MuMove4K doesn't do anything fancy to reset the machine, it just runs into a ColdReboot(). It may happen that the driver/the drive is still busy initializing itself, thus the wait may help. If that does not help, well, then the driver has an "issue" by not resetting itself properly on a software-initiated reboot. There is then nothing I can do.

It doesn't help, but I if accelerator is removed, it boots past MuMove4k.

How ever this seems to be a weird problem with Blizzard 1260 and SD/CF hard drives.