Zz9900 Guru RTG only

  • Amiga model: 4000D CR
  • 680x0 CPU: 68060 A3660
  • RAM Configuration: 16mb via motherboard 256 via ZZ
  • Kickstart, AmigaOS Versions: 47.96, 47.3
  • ZZ9000 Firmware version: 1.9.1
  • ZZ9000 Driver version: 1.9
  • Monitor model: Dell u2713HM
  • Other Zorro cards: FastATA 4000 MK VI

If I start the amiga with auto boot I get a guru 8000 0004 error or boot loops. using the none autoboot firmware the system will boot to desktop.

However the system will become progressively unstable when using RTG modes. Having said that the system can idle without a problem, its only when I start opening programs/workbench windows problems start to become apparent.

At first its just a random Guru error every now and then (8000 0004, 8100 005, 8000 000A). Programs like iBrowser seems to trigger more guru errors, freezing or lock ups then anything else. but just opening workbench folders or scrolling a guide in multiview can also have the same outcome.

Over time system instability starts to be come so rampant that at it worst it the system would crash as soon as the desktop loaded.

I’ve tried fresh installs of workbench/drivers/Picasso96 but the outcome is all ways the same.

However if I just use the zz9900 as a scandoubler the system seems very stable. I’ve been using that way for over a fortnight and everything seems fine.

Hi, could you try the new 1.10 Firmware and tell me if it makes a difference? Available here: Releases · Amiga / zz9000-firmware · GitLab

Hi, I’ve just spent a large part of the day testing the 1.10 firmware. When testing different combos of hardware and software I installed a fresh copy of Workbench 3.2.1 onto a CF card along with Picasso (icomp), Roadshow and ZZ9000 drivers.

At first glance it seems the system will boot without an error with ever the autoboot or none autoboot firmware (However there seems to be new problems introduced, more on that latter).

However if MMu libs are installed when booting from the onboard 68EC030 I get a 8000 0004 error and boot loops . This happened with ever the libraries provided with WB3.2 or the leanest ones on aminet (47.4). If the libraries are absent the system will boot fine. Having a FPU fitting or not doesn’t seem to affect the outcome. Not really a problem as I use the a3660 but worth noting none the less.

As of 1.10 I’ve now been getting Recoverable Alert 0100 000c and 0100 000c. I’ve had this happen when opening a folder, extracting a lha file from Dopus or even just opening a file requester. I normally get several in a row. in most cases they are recoverable but the system will become unstable and lock up or produce a requester error or full screen guru error. At first it seemed like it might only happen when using the autoboot firmware but I was unable to find a consistent reproducible test after swapping between firmware.

Just about pulling my hair out on this one :stuck_out_tongue:

Ok! I believe I’ve worked out what the problem is (well at lest one of two problems) after inspecting the Super Buster chip I noticed two of the legs where slightly out of alignment. After carefully straightening them out and fitting the chip back in its socket the system has been rock solid. I’ve not had any error messages, freezing or reboots at least while the computer is out side of its case.

However I am getting strange boot loops when the system is installed back in the case. It seems random and not the result of any particular combo of hardware. I suspect maybe a grounding issue but I need to do more testing/investigating. For not I’m going to keep running it outside the case for the rest of the long weekend to see if it remains stable.

FINALLY one with the exact same issues I have.
My original thread was this one: Video freezes with scrolling - #4 by EvilDragon

But yours explains the issues a lot better.

I can confirm the Gurus (yep, same numbers), the lockups, the freezes!
And it happens especially often when something is scrolling. Either when browsing through the music list of EaglePlayer, reading through a guide or simply just catting a text file on the shell.

And yes, not using the ZZ9000 graphics modes but switching to the Amiga ones makes the Amiga perfectly stable.

With FW1.9.1 I had the crashes almost every 2 minutes, so my Amiga became useless. Now I’ve updated to FW1.11 - and the Amiga worked without a single crash for over 30 minutes. So it’s a LOT better.

But yes, then the same thing happened that happened to you: It started to crash more regularly, and in the end, it crashed again every few minutes. Or as soon as the desktop shows up.

So while FW1.11 makes things better, after a while, the system becomes unstable again.

I checked with ZZTop and at the beginning, the core temp was around 55°C and at around 69°C when it started to crash. Is the temperature already too high? Or should that still be safe? I can install a fan, if need be.

My Amiga is a stock A4000/040. I’ve got a new power supply in there and am booting via an IDE->SD adapter, all caps have been replaced.
The board is still one which has the Buster soldered.
I have not tried running the board outside of the case, but the same board works fine with a PicassoIV card and passes every DiagROM check. I have three working 4000 mainboards and they all behave the same, so it can’t really be the mainboard itself.

The question now is: What’s happening? And how can we fix it?
As FW1.11 got a lot more stable, it seems to be something that can be fixed in software.

One thing I noted: When I do the Bus test in ZZTop, half of the screen gets messes up with lines. Is that supposed to happen?

It passes all bus tests.

Hi EvilDragon,
I’d been meaning to post an update. after getting a tone of stability issues with the system out side the case I’m now back the square one with my troubleshooting. I had posted over on English amiga board when I suspected the problem was with the case. I did get some good tips, none that resulted in a fix. I did however discover that I had stupidly soldered the coin sell battery holder in the wrong way round. Remove it had zero impact.

I will however try the new 1.11 firmware and report back. Interesting to see you have the same problem with more then one 4000. I’m not rolling out the problem is with my motherboard but this gives hope.

The bus test does the same for me as well. I believe its normal(?) I’m guess as data is been written to the buss its manifesting as visual garbage. The same can be seen on lukas’ twitter posts when testing mp3 playback. So I’m guessing it visual feedback/debugging for him.

Not sure if this is relevant but I recently reinstalled vanilla OS 3.1 on my A4000D IDE CF card, with ZZ9000 running v1.8 FW/SW, and was getting #8000 0004 gurus. I fixed those gurus by changing the MAXTRANSFER on my partitions on the CF card to x1FE00.

Like I said, not sure if it is pertinent here, but it was a recent experience for me with similar hardware.

Thanks for the info, however MAXTRANSFER rate was all ready set. Quick question do you have Direct SCSI transfer enabled? The amiga guide for HD Toolbox seems to imply it should be set for newer systems. Does that include ide on the a4000? no idea. However I’ve got it enabled and the drive is formatted with the DS version of PFS all in one.

Interesting find. I never had the idea that it might be related to the Maxtransfer rate of the IDE partition, as the Amiga works perfectly when not using the ZZ9000 screenmodes… but I’ll check that. I forgot if I’m using PFS3 AIO here. I certainly did that earlier, but I might’ve switched to FFS when I reinstalled OS3.2 from scratch (as I wanted to have a cleanly installed OS for testing).

I’ll check.

So far, I exchanged these components:

  • A4000 Mainboards (also with different buster revisions)
  • A4000 CPU Boards (68040 030 / 040 version)
  • Memory chips and setup
  • Riser board

I did not change:

  • SD Card / IDE adapter setup
  • ZZ9000 (as I only have one).

So the only thing that can cause the issue is either the ZZ9000, the SD Card / IDE setup or some misconfiguration.

Unknown. I don’t see anything in HDToolBox, other than “reselection”. Is that it? I’m using vanilla OS3.1 and a 1GB CF card.

What version of P96 are you using? Mine is v3.1.2 from I-Comp.

must have bee added in 3.2.1:

as of yesterday I’m on 3.3.0 for p96

I didn’t have Maxtransfer rate set, but according to Hyperion, this is not needed anymore with OS 3.2.1

After setting it, the system runs a lot slower but still crashes like hell.

So no luck. I have Direct Transfer disabled and all partitions are stock FFS.

I don’t think it has anything to do with the Harddisk (or SD card) though.
From what I’ve read, if Maxtransferrate is not properly set, the data can be corrupted while writing on the disk, or it can lead to read errors which can trigger the Gurus.
But that should also happen when the Zz9000 modes are not being used - or when using a different card like the PIcassoIV - and it doesn’t.

I really wonder whether the Zz9000 simply has some defect. It’s weird that it works for others but not here with basically three different Amigas and a stock OS installed.

I also tried various P96 versions (also one I bought a year ago from icomp), it’s always the same.

if there’s anyone with a working system and a Zz9000 who would like to test if my Zz9000 is working, let me know and I’ll ship it to you.
My Amiga is unusable for over 2 years now after I replaced the PicassoIV with the Zz9000 :frowning:

I noticed that the only A3640 boards I have here that work are Rev 3.0 … could that be the issue?
I tried fixing my 3.1 one and already found some broken vias which I repaired, but it doesn’t work yet.

FWIW, my A3640 is v3.1

I also have a Toccata sound card installed and a fan on the 040/25.

It came this way when I bought it last year. All I’ve really done is replace the CyberVision 64 with the ZZ9000, swap CF cards and reinstall OS3.1 from scratch.

My ZZ9000 came with v1.8 FW installed and I’ve never changed it.

My mobo is not a CR. It has had the clock battery replaced before I got it (but it isn’t working) and I’m having issues with the onboard sound (I just ordered caps for the mobo and 3640)

My CPU is a full 040 w/MMU & FPU.

I have 2MB Chip and 16MB Fast installed on the mobo. The ZZ9000 automatically adds 256MB Fast.

Not sure atm which Buster I have but I think its either 7 or 9. Would have to tear it apart to find out unless there’s a utility than can tell me.

EDIT: Also, I ran across this while looking for something else…

Definitive Buster - Definitive Buster

I’m back to suspecting it my buster chip as I’m still getting system instability. I’ve ordered a new one from Analogic as I’ve notice two of the legs on my current socked one are slightly bent. I’m hopping it the age of the chip and not the PLCC socket. the socket looks fine. I don’t see how they legs on the chip would get bent and I’m using a PLCC chip extractor to remove it. Wish me luck I’d hate to damage and second buster chip.

Hi Guys. I’ve actually got very similar issues too… i could go on and on for ages about how to got here but let me keep this simple so you’re not reading forever… and this issue has been around for … well as long as i recall even having the ZZ9000, but as of today…

If i use Dopus v4.17pre21 (Earlier versions been tested) and i open a large text file (230kb) and i start scrolling… she will freeze randomly… pretty much as EvilDragon described… This has persisted through various OS installs. I removed BigRamPlus and the motherboards fastram, leaving the 2mb chip and my Apollo 4060 128mb.

But here’s the recent info… since the new zz9000 behaviour of needing 3 reboots for FULL functions… of which is listed below…

First turn on

  • I get NO RTG… so i must reboot
    After First reboot
  • RTG is recognised and looks nice but the ZZ9000 memory is NOT recognised. I get 128mb from my Apollo 4060 so its perfectly usable at this point.
    Second reboot (or 3rd time lucky)
  • RTG is there and so is ALL my 128mb from Apollo 4060 + ZZ9000 256mb. Rock and or Roll!

I have found that when the 2nd boot is done, with 128mb Apollo ram but NO ZZ9000 memory, and if i open and scroll my dopus text, it DOES NOT FREEZE… last night i must have run that text file 6-8 times once after the other at various speeds … and it did not crash at ALL.

Then i did the 3rd reboot, got all my ZZ9000 memory available as well as my Apollo 4060 128mb… combined to 384mb or something… and now… DOPUS WILL FREEZE… the text isn’t able to complete even once. I did this TWICE as well from the start and both times it did the same, only freezing once the ZZ9000 256mb was in use.

The extra little clue i have found though is this… The only other card i have is an X-Surf 100, that X-Surf 100 NEEDS to run with the Z2 jumper, if i try it at Z3 speeds, my system will NOT boot. I hate having to run the card slower, but it works, and i wonder if the same needs to happen with the ZZ9000, i need to slow it down as i assume it is autosensing Z3 but not the fault of MNT, but more somethign is wrong with my original daughter card that it can’t keep up anymore with Z3 speeds and thus… once the memory is activated, she dies.

That’s my 2 cents for now… i wonder if knowing this helps you to draw to a similar conclusion?

Amiga 4000 D - Apollo 4060/128mb (Full 060 w/ FPU/MMU)… chip runs at 66mhz, but 50Mhz has been tested with no change to result.
I use the most current P96 3.3.2 i bought only 2 weeks ago with my 3.2.1 Kickstart roms and Workbench.
Yes i’ve had this issue from initial setup years ago to the current 1.12.1 firmward, but my feeling is there is an external issue from the card and i’m looking suspiciously at the daughter board, something i would replace but i hear there’s so many incompatibilities with cards i never considered it. I also get a Recoverable Alert when i first turn on my machine. I could unpack more and more but this is LONG.


Hm, I would love to test that, but I don’t have any additional memory athand. The reason I wanted to get the ZZ9000 was because it also has Z3 memory included.

I tested the card in multiple A4000 motherboard / riserboard / daugherboard combinations. I know ONE of the A4000 has an issue with Z3, as I need to change my PicassoIV to Z2 to get it to work there.

But the one I am using for the ZZ9000 right now works fine with the Picasso IV with Z3 enabled.

As I’ve tested multiple A4000 mainboards, daughterboards and Riserboards and ALL have the same issue, I doubt it’s any of the A4000.

Either the ZZ9000 is broken or it has generally compatibility problems with an Amiga 4000. Seeing that multiple users here have stability issues with the ZZ9000 with otherwise properly working A4000, I think there’s an issue with the ZZ9000, to be honest.