Cybergraphx hangs in OS3.9

[Ral-Clan]

Hi, I'm installing OS3.9 on an Amiga 3000/040/48MB Fast RAM.

When I first installed Cybergraphx (from my v4 CD-ROM) it worked fine.  I think after installing the BoingBag updates it now hangs at the Cybergraphx boot picture.

If I remove the Cybervision64 monitor driver from my DEVS:Monitors drawer I can boot into regular OS NTSC screenmodes.  As soon as I put this monitor driver back, things will hang up when the Cybergraphx boot pic is displayed.  You can see the Cybergraphx logo on the screen, and there is a few more seconds of disk activity, but then the hard drive stops and nothing more happens.

I tried using SET ECHO ON to see what was happening in the boot process.  I think things hang when IPREFS is executed.

I read on the official OS3.9 bug page to disable AMIGA OS ROM UPDATES.  I did this.  I renamed them all, and even tried putting them in another directory.  This did not help.  I also updated my cgxsystem.library with the latest update patch.  I didn't help.

Cybergraphx DOES work fine if I boot from my OS3.9 EMERGENCY FLOPPY DISC.  That's the disk created by the OS3.9 CD-ROM.

Another question:

- what is the correct syntax to have the ECHO command output the startup-sequence to a text file as it is being executed.  I've tried

SET ECHO ON >DH0:startuplog.txt

but it doesn't work.

[Ral-Clan]

I did install the rc6 patch already.  It didn't help.

I will try the "fixer" option you suggested though.  Thanks.

[Ral-Clan]

Tried your suggestions at lunch-time.

Update to version 42_rc6 does nothing to improve situation.
Amiga still hangs at Cybergraphx bootpic.

Next tried cgx44fixer.

At command prompt typed: cgx44fixer cgxsystem.library (after CD'ing to libs: drawer).

It output the following:

cgx44fixer by Harry "Piru" Sintonen
     patch 0: offset: 0x000000
     patch 1: offset: 0x000000
     cgxsystem.library patched failed.


 :cry:

There is a cgxsystem.library in my libs drawer, and it is not write protected or inhibited in any way from being modified.

Don't know what is so special about my Amiga that I cannot fix a recognized bug that hundreds of other people have managed to fix successfully.

This is on a new, clean install of OS3.9/CGX4.

[Ral-Clan]

I do have this icon present in the DEVS:Monitors/ drawer.  :-(

I just thought of something else: I have installed a new 68040 Mercury card into this computer.  I believe it installed its own INIT040 software in the first line of the startup sequence to initiate the 040 processor.  I can't remember right now, but it MIGHT be executing BEFORE the SETPATCH command. I wonder if this could cause such a problem.  :-?

[Ral-Clan]

the problem "seems" at the LoadWB stage.

It's hard to tell.  The last part of my startup sequence that I can see just before the screen goes dark to load the Cybergraphx bootpic is C:IPREFS (or similar).

There is a little bit of hard drive activity while the bootpic is displayed, then the hard drive just stops.

If I remove the Cybervision64 monitor drive from my DEVS:Monitors drawer I can then boot my Amiga into normal NTSC modes.

Once booted, I can manually activate the Cybervision64 monitor driver by double clicking on it.  However, no Cybergraphx modes are showin in Screenmode preferences, and when I try to start a progam which opens a new screen the Amiga locks up.

As I stated above, if I boot from my Emergency disk (which also has the Cybervision64 drive) everything is fine.  I get Cybergraphx modes and can start programs in those modes.

Therefore it is the recognized bug caused by the BoingBag updates.  But why can't I solve it by doing what everyone else has?

[Ral-Clan]

Hi!  I might have to install Picasso96 in the end, but I've got Cybergraphx4.x running well on my A2000 under OS3.9 and would like to have the same system on my A3000.  Also, ImageFX is designed to run well under Cybergraphx and I use that program a lot.

I did a total clean re-install OS3.9 last night and got a little further.  I can now boot into Workbench at a Cybergraphx 640x480 mode and see all my Cybergraphx modes and ECS modes available in Screen Preferences.  

So, Cybergraphx seemed to be working.  However, when opening a program on an ECS screen the Amiga just seemed to 'lock up'.  The Amiga wasn't actually frozen, it just had switched over to the ECS screen but wasn't showing me the ECS screen.  If I hit AMIGA-N I could toggle back and forth between the Workbench screen and the invisible ECS screen.  Hard to desribe....I would always see the workbench screen, but when the "invisible" screen was the active one my pointer would freeze until I hit AMIGA-N and toggled back to my Cybergraphx Workbench screen.  This apparent "lock up" would also happen when in Screenmode Preferences I would "TEST" an ECS screenmode.  During the test the Amiga would appear to be frozen until the TEST automatically ended (after 10 seconds), then it would come back.  I would never see the test pattern at all.

As I said, disabling "PASS THROUGH" in Cybergraphx Prefs seemed to fix this.

However, now another problem: If I try to switch to 800x600 resolution in Screenmode Preferences I just get a black screen.  I haven't had the time to check yet, but I think this MIGHT have something to do with my monitor not being able to handle the mode Cybergraphx is throwing at it.  I will have to try with another monitor.  The WIERD thing about this is that this monitor DEFINITELY CAN handle 800x600.  It does it when connected to a PC and also my Amiga OS3.9 Emergency disk (with an older Cybergraphx monitor driver on it) boots up nicely in 800x600 mode!  :-?

Lastly, if I try to run some programs in Cybergraphx 640x480 mode (Bars & Pipes in particular) it appears to be okay, but when selecting menus or having lots of windows opened that are filled with white or bright colours, parts of the monitor screen fade to dark in a very analogish way.

So there is definitely something up with my Cybergraphx driver.  It's working now, but the way it's driving the monitor is wrong.  I will have to look at the specs on the working driver in the Emergency disk and see if there is some difference in the scan rates of the different modes or something.

Whew!