Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: cehofer on December 06, 2018, 09:11:10 PM
-
I have two A4000T, one with Quikpak XP 060/50 rev2 w/ SCSI controller and the other with Quikpak Rev 4 no SCSI controller. They are loaded with 128m RAM I have an additional 16meg of ram on the MB. I am using the A4000 SCSI controller on both. Both have Deneb USB cards.
From time to time and for what seems no real reason, both throws a Software Failure 8000000B. The Quikpak XP rev 2 is more unstable than the Quikpak Rev4. I have been all over the net trying to track this down and I found this:
"This is caused when trying to execute FPU instructions on a processor without an FPU. It can also occur on the 040 and 060 machines if there are problems with
68040. library or 68060. library respectively.
Presumably, because the operating software of the card was not or not properly installed. The 68060 cards from Phase5 / DCE (Blizzard PPC, Blizzard 1260 and Cyberstorm Mk III / Cyberstorm PPC) and ACT (Apollo 1260/3060/4060) included software that was used to install a dummy 68040.library, the then called the needed 68060.library. If the original 68040.library of the Amiga OS is loaded instead of the dummy library (this happens in the startup sequence by calling SetPatch), the computer crashes immediately (usually with a Guru Meditation # 8000 000B)."
My Libraries:
68040.library 8/6/1996 1k version 68040-stub 1.1 (12/29/1995) c1995 Ralph Babel
68060.library 8/6/1996 65k version 68060.library 2.2 (07/26/1996) c 1996 Jeff Boyer
I have also seen mentioned on the net that disk access can contribute to this.
Are there any updated libraries or is just the nature of the beast?
-
Since you're unable to be civil, and lash out at people trying to help you, and are also unable of following very simple instructions, this advice has been deleted.
-
Another issue I have is that I wanted to utilize the onboard SCSI of the Quikpak XP. It says in the manual that JR8 is the SCSI enable its default jumper is off but mine is on. So I connected my SCSI drive to it but it doesn't recognize the disk. Also if I remove JR8, the machine is dead like i disabled the CPU. This is the 4000T that is less stable and I thought maybe having two SCSI controller enabled might be causing some issues but it seems I can't disable the Quikpak onboard SCSI.
https://www.bigbookofamigahardware.com/bboah/product.aspx?id=1892. XP documentation.
Does anybody have their Quikpak XP onboard SCSI working? My A4000T SCSI card works just fine.
Do others that have the A4000T made by Amiga Technologies running solid?
-
Like NinjaCyborg said, forget those libraries and try Thor's MMUlibs instead.
-
I looked at the 68060.library and it is the same as what I have. So I don't think it is going to help any.
Version 2.2 (07/26/1997)
c 1996 Jeff Boyer
-
Since you're unable to be civil, and lash out at people trying to help you, and are also unable of following very simple instructions, this advice has been deleted.
-
The MMU libs are updated frequently, and they're rock-solid. Install those and see how it goes.
Almost forgot: You state that both machines have started throwing up this error together - well I'm sure you don't need me to tell you that this is almost certainly some software update you have performed or similar.
-
Do you want me just to swap the 68060.library file or install this whole thing? I swapped just the 68060.library and I first get a 3F02803E Recoverable error. Then after a while of working I get a new error 8000003D.
I have an 4000 Desktop with the first version of the Cyberstorm 060. That thing was rock solid. I have to do a capacitor swap on the board and then I will fire that up to compare.
It has been a long time working on my 4000Ts since I got my Amigaone XE running solid. I know the 4000Ts are at Boing Bag 2 possible 3. My 4000D is at the same level as the 4000Ts. One thing I can say for sure, my 4000D can run and has run Magic Menu for years without issue. Both 4000Ts cannot run it for very long without the guru. The only difference is the 060 boards and SCSI cards. My 4000D has an Oktagon2008. I have been temped to swap my Cyberstorm in my 4000D to my weakest 4000T to see if it is solid.
The program I use most and want to get solid is StormC4. I have applied the updates to get it to the 3rd and last update. With the MMU 68060.library, it crashes on stormshell.
-
Since you're unable to be civil, and lash out at people trying to help you, and are also unable of following very simple instructions, this advice has been deleted.
-
Ninja,
First, what amiga are you using? Secondly, nobody has read my questions and just jumped on this bandwagon of install all these new libraries.
I am not a novice Amiga user. I have been using an Amiga since 1988 when I purchased my 2000HD and then moved up to an Amiga 4000D in 1994 with the first version Cyberstorm 060. It has been rock solid for years. I have since acquired the two 4000Ts both made in 1996 that exhibit the same issue.
Since I have a solid 4000D without said libraries, why would I want to add yet another variable to the mix and if it doesn't work, I have to back it all out manually?
I also asked before your rude post that do you want me to install the 68060.library or the whole thing. That was not answered. For you information, I went through the documentation and it is cryptic at best and full of Q and A.
So logically, if I have a 4000d with a cyberstorm running solid and two 4000Ts running not so stable, why would I add another variable into the mix with MMUlibs? My guess is that the Quikpak 060 or its libraries are unstable either due to AmigaTechnologies just throwing it together or the caps on the boards are dried out and leaky as they are now on my 4000d. I have already had to replace leaky caps on one 4000T on the audio card and one on the mother board near its slots and that is the more stable one. It looks like those 22uf caps are total garbage as I had 3 three physically leaking.
If somebody said that they knew the 060 Quikpack libs are incomplete or buggy, I would move forward in install the MMUlibs.
I would like to know if anybody out there has a 4000T Amiga Technologies vintage with a quikpack 060 cpu running solid from stock software 3.9 and boing bag updates.
In this same thread, I have also asked if anybody has the SCSI controller on their Quikpack XP working? That is unanswered.
>:(
-
Since you're unable to be civil, and lash out at people trying to help you, and are also unable of following very simple instructions, this advice has been deleted.
-
Saying SCSI is irrelevant is a crap statement to say the least. YOU think it is irrelevant, but many still use it and as it is an installed item in our machines we intend to continue using it.
How about you back off a tad and help folks rather than insult them? And if you don't want to do that fine, just don't say anything.
Your nasty comments are less than appreciated..
-
Outlaw,
Thank you very much! If SCSI is so irrelevant, why are they making and selling SCSI2SD V6 cards. One of which I just purchased and installed.
Did I log into Facebook by accident? Is this what Amiga.org has turned into a bunch of faceless people that like to insult instead of help? It seems like every time I have posted questions I get somebody that wants to be rude and argue.
My naive questions:
1. Does anybody have an Amiga Technologies 1996 4000T running the 060 quikpack cpu having my issues or running solid?
2. Does anybody have a Quikpack XP rev 2 or rev 4 running solid in A3000/A4000?
3. Why on my Quikpack XP rev 2 when I pull JR8 "SCSI enable" kill the cpu and won't boot per documentations listed that I bothered to read. It will also not recognize a scsi device. Using the CPU onboard SCSI device will be a lot faster than using IDE controller on the MB but that that is my naive opinion.
4. Has anybody running an 060 have it throw 800000B error regularly?
-
The 800000B is likely to be caused by missing software that the system is expecting to be present. Exodus reported that error after the patch created a new and hence incomplete directory for Exodus: The Last War and I ran the executable. Different accelerators have different libraries that are required, in addition the A4000T requires a different version of Workbench and Setpatch creates problems IMHO. You probably know all of the above but just trying to help. I agree that the onboard SCSI is very useful.
-
Bozzer,
That is very good information. I did not know that the 4000T requires different Workbench and setpatch. Would you happen to know what versions?
These subtle differences is why my 4000D is solid and my 4000Ts are not. I just have to find them.
Setpatch 44.38 (03/08/2002) - I believe I read this is the latest version.
Kickstart 45.57
Workbench 45.3
loadwb 44.2
I have also captured the output of setpatch to a file so see what it is actually doing. I have attached that file.
AMIGA ROM Operating System and Libraries
Copyright © 1985-2002 Amiga, Inc.
All Rights Reserved.
SetPatch (V44.38) has been installed. Patch list:
68060 Support Code Loaded
Enabled Advanced Graphics Modes
HWG IEEE Single Precision Mul/Div/FPU Fix
ramlib signal usage
stack size check for CON:, RAW:, RAM:, PAR:, PRT:, SER:
graphics/WritePixelLine8()
graphics/WriteChunkyPixel()
Enabled data cache
ROM updates installed by SetPatch:
shell, shell 45.7 (13.01.2002)
console.device, console 44.8 (12.6.2001)
ram-handler, ram 44.23 (8.4.2001)
scsi.device, IDE_scsidisk 43.43 (16.1.2002)
NCR scsi.device, A4000T_scsidisk 43.43 (16.1.2002)
FileSystem.resource, filesysres 45.10 (3.8.2001)
filesystem, fs 45.13 (3.8.2001)
bootmenu, bootmenu 44.7 (25.2.2002)
exec.library, exec 45.20 (6.1.2002)
AmigaOS ROM Update, ROMUpdate 44.57 (25.2.2002)
-
I think it's 'workbench.library' that is missing in the A4000T ROM when compared to other Amiga models, hence they needed a unique Workbench disk with that library included (due to space constraints on the ROM). I'm not sure about Setpatch. However, a clean 3.9 install is highly likely to know about all of that I'm sure! Anyway, it loads Workbench so I sincerely doubt that is the issue here.
It's been a long time since I thoroughly read the MMULib docs, but I'm pretty sure I patched my Setpatch (via included patch) so that it loads the correct 680x0.library directly via hardware detection instead of this 68040.dummy library nonsense. You might want to read the docs to see if it can be loaded via the 68040 dummy library. I'm not sure off of the top of my head as it's been years since I used the dummy library. I know for sure I don't have a dummy library in my libs and haven't done for years and years. Thor does include an Install script for the whole package which he assures us takes care of everything. I've never used it, but he's usually right about things.
Of course, your other option of testing is custom boot disks. Make up a Workbench disk with the Quikpak libs installed and do a cold boot of the disk. Run some floppy based software. I wouldn't start running programs from your hard drives unless you know what you're doing regarding the 4GB limit in the 3.1 ROM etc. Also, It could be a reset resident module on your 3.9 install causing trouble. Have you made any changes recently on both machines which correlate with these errors you are seeing? Anything new been added to the startup-sequence or WBStartup etc?
-
I have been making some progress but no fix yet. I found greg donners site http://www.gregdonner.org/gvp4060/downloads.html. He seems real knowledgeable because the GVP and the Quikpacks are kinda a like. There was some licensing thing going on there at the time. He also is working with a guy on the 060 libraries.
I have found on my Rev 4 machine that the exec.library has a checksum error. So I think that means I have a bad ROM perhaps? It is the most stable of the two so go figure.
I see this on my setpatch capture, however setpatch seems to update all the files as it does on my XP rev 2.
Checksum failure! exec.library, exec 45.20 (6.1.2002)
Checksum failure! exec.library, exec 45.20 (6.1.2002)
AMIGA ROM Operating System and Libraries
Copyright © 1985-2002 Amiga, Inc.
All Rights Reserved.
SetPatch (V44.38) has been installed. Patch list:
68060 Support Code Loaded
Enabled Advanced Graphics Modes
HWG IEEE Single Precision Mul/Div/FPU Fix
ramlib signal usage
stack size check for CON:, RAW:, RAM:, PAR:, PRT:, SER:
graphics/WritePixelLine8()
graphics/WriteChunkyPixel()
Ralph Babel created a new 68060.library 2.3 in 2018 for the GVP/Quikpack. I tried it and will boot without error but as soon as I load StormC4 update 3 I get the 8000003D error. I have also installed enforcer to give me insight as to what is crashing the system.
Nothing new added to the machines other than when I first got them I added the USB Deneb but the Quikpack was giving issue before I installed that. I kinda gave up on my 4000Ts for awhile and focused on my Amigaone XE. I have that solid now with 4.1FE and I want to start writting programs again on both new and legacy systems. It hard to program and compile with your machine crashing.
-
I seem to recall there being an issue with either bb3 or bb4 installing card.resource, and apparently this can be a source of instability on A4000 machines.
-
trixter,
I upgraded with BB3&4. I didn't see anything in there about the card.resource but I did find another link about that.
If you load this file, it replaces with this file that plays nice with fastram
C:LoadModule >NIL: L:cardres.ld.strip REVERSE
The upgrades and this file hasn't really helped much.
-
Here is an update as I still don't have a fix. Working with Greg Donner, i have learned a lot about the 060 and the many revisions. Both of mine are Rev 1. These are have issues with SuperScalar and Load/Store Buffer bypass. It took me awhile to find a version of cpu060 that would let me manipulate these 060 options. The Quikpack cpu060 would not let me do anything but list the 060 without the rev number. I found my phase five cpu060 v1.6 and it let me see all the options and only let me disable SuperScalar. Disabling SuperScalar has made it the most stable it has ever been. I then found Phase Five cpu060 v1.9 and it allowed me to disable the Load/Store Buffer bypass as well. This made very little difference.
I then installed a 2nd scsi HD. I copied the system to it and worked on it a few days to make sure it was stable and no difference in performance. I then installed the MMUlib. This made it worse as it will now completely freeze, HD light stays on. I have let it stay like that for 10 minutes and only a reboot will fix it. Sometimes now when it reboots, it will get up to the point of installed amidock and freeze as described above.
Yesterday, I tried installed the 3.1.4 ROMs and booted off the "Install Disk" but it won't recognized any of my scsi devices which live on the scsi.device LUN0 address 1 CD and address 5 HD. I reinstalled the 3.1 ROMs and the machine booted as normal.
-
Here is an update and it is finally fixed. I received the new 3.1.4 4000T ROMs. These are different from 4000 ROMs as they do not have the native SCSI controller support of the 4000T so beware of that. Amiga on the Lake was nice enough to exchange ROMs for me.
So the symptoms were that the I was getting 8000000B '060' Software failures. After upgrading to 3.1.4 it seem to be worse. Anything while working on Workbench, clicking on icons, going to information, opening editpad, an opening system or work partitions would throw some sort of 8000000x software failure. If it crashed bad enough, it would cause the HD light to stay on and freeze again. It would usually take three times to get booted up again.
I even recapped all the surface mounts on the MB and all the cards. I even replaced all the caps in the powersupply. Same thing.
I added an IDE drive and moved the system to that and disconnected SCSI all together. Same symptoms.
I had changed CPU cards to my original 3640 and it exhibited the same thing. As a final ditch effort, I went in my user-startup and started commenting out programs I didn't know or ones I hadn't used for a long time.
Other symptoms were that it would sometimes for whatever reason, it would boot into some low res screen, Intuition would complain that it couldn't close certain windows and then fix itself and boot fully up. Other times it would freeze, then next boot freeze on opening Amidock, then next time some other Commodity, then next boot finally boot fully up.
I came across an entry that was just "fbl_68020". I searched that and found it is FastBlitz 6.6 a hack that is suppose to speed up the Blitter. I commented it out.
I rebooted and I immediately noticed that the FastBlitz 6.6 DOS screen entry was gone and the machine booted without issue right into WB. I could click around and I worked on it for over a 1/2 hour without a crash. I even ran Magic Menu because that was a certain crash if I used it. The machine was still stable. However, I was still on IDE. I moved back to SCSI. It is stable without issues now.
The only thing I can think of is that FastBlitz was conflicting with my PicassoIV card or Workbench when trying to draw screens.
I don't even know where it came from but it is gone now.
-
I know the issue you ran into was resolved, but (FWIW) there is a newer version (v2.3, link below) of the GVP-M 'cousin' 68060.library from Ralph Babel that might be more of a custom fit with your QuikPak XP board:
http://babel.de/amiga.html#tekmagic
-
the moral of this story is don't run patches on refreshed systems