Amiga 4000 will not boot after boing bag 2 update

[sovietconscript]

specs
NTSC Amiga 4000
OS 3.9
amigakit 4gb CF hard drive
2 MB chip RAM
24MB FAST RAM
(16MB RAM on MB, 8MB on GVP A4000 scsi zoro expansion card)

just did the boing Bag 2 update as well as the ROM update and now after restarting my system will not reboot. the hard drive activitly light stays on but thats it, black screen.

any ideas? can i reverse it?

[sovietconscript]

I can get to amigados if i boot without a startup sequence but even trying to load WB 3.0 via floppy disk I just takes me to AmigaDOS. I pulled the CF hard drive and it runs fine for me under WinUAE on my PC. am I going to need to find new ROM chips?

[mfilos]

Just to test if it was the ROMUpdate that is making the problem, just log into Amiga DOS booting from Early startup menu without Startup-Sequence and write the following:

1> cd devs
1> rename "AmigaOS ROM Update" "AmigaOS ROM Update.bak"

then reboot and see if it will load.

[sovietconscript]

Originally Posted by mfilos

Just to test if it was the ROMUpdate that is making the problem, just log into Amiga DOS booting from Early startup menu without Startup-Sequence and write the following:

1> cd devs
1> rename "AmigaOS ROM Update" "AmigaOS ROM Update.bak"

then reboot and see if it will load.

that seemed to work, after I did that the OS booted up fine like before. do I have to do anything more or was that a temporary fix?

[mfilos]

OK good.
Let me explain a bit of what's happening here.

The file AmigaOS ROM Update contains the following modules:



When the command SetPatch runs... it tries to find the file "AmigaOS ROM Update" from Devs folder. If it finds it, it check if the appropriate modules are already loaded and if not... it loads these appropriate modules into memory and reboots.

Normally in default BB2 installations the SetPatch command looks something like this:
C:SetPatch SKIPROMMODULES "scsi.device" QUIET

That means that SetPatch will load EVERYTHING from the "AmigaOS ROM Update" file but SKIP the scsi.device, as some devices has problem booting from the newest scsi.device (like some GVP controllers afaik).

What we done here was rename the file alas SetPatch didn't find it alas it didn't load any new modules and your system booted. That means that one or more modules, aren't compatible for some reason with your system and you need to find what module is doing the problem and isolate it by leaving it outside the loading process.

What is your SetPatch declaration tbh?

[sovietconscript]

I'm guessing its probibly my GVP card. unfortunitly i've only recently have been fiddleing with the the side of AMIGA that isnt "insert game disk and play" so i'll probibly need guided through the process. i have no idea how to check my setpatch declaration but if you can tell me how i'll check it. also since were talking about booting. is it normal for a machine to take a minute or more to boot? my machine has always since I recieved it taken forever to boot up useing either a floppy disk or a hard drive.

[emufan]

boot without startup-sequence (early boot menu). when you see the amigados prompt, type:
ed s/startup-sequence
and search for your setpatch line. ed command has menu driven gui, so you can quit and/or save.
(if system ask for env: or t: just "cancle", not important at that step).

you can add as the very first line in your startup-sequence this:
set echo on
with that line you see all commands executed, you can catch the line where your system gets stuck.

[demolition]

I had some problems after installing WB3.9+BB1+BB2. After applying the ROM fix and resetting, it would guru just as it would try to boot from HDD. If I went into the early boot menu and disabled SS, it would still guru when trying to boot.

After creating the ENV file to ensure it would load the line with 'SKIPROMMODULES "scsi.device"' instead, it now boots fine.

Curious thing is that I'm using the internal IDE port with a CF card without any splitter/IDEfix.

[videofx]

Or if you feel like redoing it. Just reinstall OS 3.9 and when it asks if you want to update the ROMS say NO

[demolition]

I don't feel like redoing it. Hate doing OS installs.

And like I wrote, it seems to work fine now, just without the scsi.device update. I have now updated to another scsi.device which works fine.

Next step would probably be to integrate the modules into a 1MB ROM for acatune.

[mfilos]

That would be the best solution.

[klx300r]

@ mfilos

reviving this old thread! thanks for the info as it solved my black screen problem on my A4000 after installing Boing Bag 2 update

It boots fine now but get popup saying " cannot open "workbench.library"ver 45 cannot open AmiDock"

any ideas why? I only modified the setpatch command with the SKIPROMMODULES command as mentioned in this thread

UPDATE:
commented out end/if statement before the setpatch line and finally booting up normally :-)

[Daedalus]

There is a bug in the BB2 scsi.device that stops it from working with certain hard drives while others work fine. Replacing it with a later version should solve the problem. For the record, adding SKIPROMMODULES scsi.device to your Setpatch line should be a last resort, only really for troubleshooting. The OS 3.9 startup-sequence includes logic for running different Setpatch lines depending on individual scsi.device setups, and also includes a manual option for disabling the update without modifying the startup-sequence (saving the NOSCSIUPDATE Env variable), but even that should not be required once the version of scsi.device being used is up to scratch.

[kublai]

Originally Posted by demolition

I had some problems after installing WB3.9+BB1+BB2. After applying the ROM fix and resetting, it would guru just as it would try to boot from HDD. If I went into the early boot menu and disabled SS, it would still guru when trying to boot.

After creating the ENV file to ensure it would load the line with 'SKIPROMMODULES "scsi.device"' instead, it now boots fine.

Curious thing is that I'm using the internal IDE port with a CF card without any splitter/IDEfix.

Can you show me how to set the env file? I'm having the same issue on my real A1200 giving me a red screen at bootup if I rename the Amiga OS ROM Update, however WHLOAD iGame would not work.

[Daedalus]

SetEnv SAVE NOSCSIUPDATE 1

Or just create a file with anything in it called NOSCSIUPDATE in ENVARC: (SYS:Prefs/env-archive).

[kublai]

Originally Posted by Daedalus

SetEnv SAVE NOSCSIUPDATE 1

Or just create a file with anything in it called NOSCSIUPDATE in ENVARC: (SYS:Prefs/env-archive).

I am sorry but I'm Amiga igorant and still learning.


Do I put this line SetEnv SAVE NOSCSIUPDATE 1 in the startup-sequence?
If this line goes in startup-sequence, does it need to go above or below the C:SETPATCH line?

[Daedalus]

No, you just need to type it in a Shell window once and enter it as a command. That sets the variable, and the SAVE keyword means it's saved to the hard drive until you change or remove it at some point in the future.

With a non-booting machine however, you'll need to boot without startup-sequence: Hold down both mouse buttons while the machine boots, then select boot with no startup-sequence from the early startup menu. This will give you an AmigaDOS shell window and a prompt. Enter the command

Assign ENV: RAM:

first, then enter the SetEnv command from above. When you reboot, that should do the job.