Sonnet 7200 PCI programming

[trixster]

I use don_adan's scsi.device, it's rather good:

http://wt.exotica.org.uk/test.html

I use LoadModule to load that from DEVS:

[fgh]

Spudje:
You need to use the loadmodule command (and tell it to not reboot, as setpatch will reboot anyway)
Then tell setpatch to not update scsi.device, as you tried before.
43.45 is on aminet in patch form, it's included in classicwb in pre-patched form. (myfiles drawer)

Don adan's patch might work but I'd consider it experimental.
(He didn't even know which version his patched version is based on, and was unable to tell me its basic features when I asked for info for my little FAQ)

[grelbfarlk]

Originally Posted by spudje

@fgh, thanks!!! That sounds like some helpful info. Where can I find that scsi.device version? And do I simply put it in devs and setpatch will use it?

Here's the file to patch your 43.43 version:
http://aminet.net/package/driver/media/SCSI4345p

If you have ClassicWB it should also be located there ready to go in sys:Myfiles/LargeHD/128GB_Support/SCSI_V43.45_ChrisToni/A4000IDE.scsi.device.43.45

You'll need to loadmodule it like:
loadmodule devs:A4000IDE.scsi.device.43.45 REVERSE NOREBOOT

[Wrangler]

I can confirm that scsi.device v43.45 as found in BoingBag 4 works fine with IDEFix.

[grelbfarlk]

Originally Posted by Wrangler

I can confirm that scsi.device v43.45 as found in BoingBag 4 works fine with IDEFix.

Not to get too off topic, but why would you need IDEFix if you have a scsi.device that already supports big drives?

[Wrangler]

Er... I never really thought about it! If it works, leave it alone tends to be my motto. IDEFix useful for atapi.device too.

[spudje]

To support a 2nd IDE cable But indeed let's get back to topic (soon as I don't have time to test at the moment).

[grelbfarlk]

Originally Posted by Wrangler

Er... I never really thought about it! If it works, leave it alone tends to be my motto. IDEFix useful for atapi.device too.

I have an IDE CDROM hooked up to my motherboard IDE with SCSI.device 43.45 and it works fine. I get that part of it, but if someone has CSPPC the onboard SCSI is 10x faster. IDE CDROM is cheap and doesn't have to be fast so I get that part of it, and from what I could tell wouldn't work with the built in scsi.device.

[spudje]

Different voodoo card, same behaviour.

[grelbfarlk]

Originally Posted by spudje

Different voodoo card, same behaviour.

Sorry if I missed that you tried this, but have you tried the MMULib with the MMU 060.library?

[spudje]

Sorry, yes, forgot to report. Also with MMUlibs same behaviour. Other voodoo was also with MMUlibs.

[grelbfarlk]

Originally Posted by spudje

Sorry, yes, forgot to report. Also with MMUlibs same behaviour. Other voodoo was also with MMUlibs.

I see you have muscan, so you obviously have mmu.library but do you have the MMU provided 68060.library? Did you also run BuildMMUConfig.rexx?

[spudje]

No haven't done the full install/configure of MMUlibs. I'll do that hopefully sometime this week. If that doesn't help I will try one final time with a clean install, with the exact versions of files that are listed in this thread and starting with my CSPPC first. If that still fails I'll probably give up...

[trixster]

I think a clean install is the way to go with this. Until you do that then you won't know if your problem is the 060 lib, the CSPPC, the ongoing issue with ahi, the sonnet itself or something else hardware related with your setup (motherboard ram, accelerator ram, power supply, random patch/software clash). The guys here told me for ages to do a fresh install and I stupidly put it off for too long.

[Hedeon]

If your sys: isn't too big or if you can strip it down to the essentials, you can archive it and send it to me for testing.

Also, in general, shut down any stuff not needed while testing. So also idefix, oxypatcher etc. You should always boot a minimalistic system while testing and expand on it while you ascertain that the current config works.

This is for example how I found out that DefIcons caused a slow down.

People tend to drop in the sonnet in an working system and while that worked for some, IF it gives trouble it is very hard to find the error (if it is software). So just make that 100 mb partition and start from scratch, I'd say.

Or pay 20 euros travel expenses and 15 for food and drinks :-P

[grelbfarlk]

You should do all those things Trixster and Hedeon suggest but trying the full MMULib install shouldn't take more than a few minutes.

[spudje]

And with full MMUlib install also same behaviour With following MMU-configuration.

;*************************************************************************
;** MMU Configuration file **
;** **
;** this file is read on startup by the mmu.library and used to modify **
;** the pre-calculated or scanned MMU table **
;** **
;** © 1999-2016 THOR Software, Thomas Richter **
;*************************************************************************



; the current version of the MMU library knows four commands that can
; be used in this file:
; CLEARTTX clears all or parts of the transparent translation registers
; ADDMEM adds memory to the exec free list pool. BE WARNED, this command
; does NOT modify the MMU tables, this must be done manually with
; SETCACHEMODE
; SETCACHEMODE defines the MMU tables.
; DESCRIPTORCACHEINHIBIT defines whether the data cache should be disabled
; for the MMU descriptors. It's usually OFF meaning the cache will remain
; enabled. This is fine for the mmu.library, but certain hacks might require
; an ON argument here. Note that this means more work for the library.


ClearTTx ;ignore all TTX registers if any. We don't need them

;DescriptorCacheInhibit ON ;make access to MMU descriptors cache inhibited


;Board specific setup follows here,
;generated by BuildMMUConfig 1.10 © 29.07.2000 THOR-Software

;General memory setup follows.
;The following lines are a compatibility kludge for some P5 boards
;which enable the MMU prior to the 68040/68060 library and leave
;the memory in CACHEINHIBIT state. You may remove the following
;lines on all other machines most likely.

SetCacheMode from 0x07000000 size 0x08F80000 Copyback
SetCacheMode from 0x70000000 size 0x10000000 Copyback
SetCacheMode from 0x50480000 size 0x0BA80000 Copyback
SetCacheMode from 0x00000000 size 0x00200000 CacheInhibit NonSerial Imprecise
SetCacheMode from 0x42D00000 size 0x00200000 Copyback

;Memory setup end.


;Setup for board 2206/161

;Setup for board 2206/33

;Setup for board 3643/32
;This board contains memory and requires no special threadment.
;In case accessing this memory with COPYBACK enabled causes crashes,
;please remove the semicolon in front of the next line:
;SetCacheMode FROM 0x70000000 SIZE 0x10000000 CACHEINHIBIT NONSERIAL IMPRECISE

;Setup for board 2145/200

;Setup for board 8512/100
;MK-III SCSI Hostadapter
For 8512 100 SetCacheMode FROM {base} SIZE {size} VALID IOSPACE CACHEINHIBIT


;P5 fixes follow here:
;If you do not own a P5 board, you may remove the following lines
;
;Several P5 boards build a private MMU setup on boot
;using a kludge called the BOOT-MMU-Port. To run this
;kludge, the following external command is run from
;LIBS:mmu/ as all other external commands
;
;This command installs also other P5 relevant MMU settings
;Hence, for P5 boards, please keep it in place even if
;you *DO NOT* see the BOOT-MMU-Port.
;
P5Init

I did notice things took additional time to load with MMUlib installed. I didn't understand how to achieve this:

Zorro space used by the Sonnet needs to be marked as CacheInhibit. If it isn't, it will not work correctly.

Should I simply uncomment following line?

;DescriptorCacheInhibit ON ;make access to MMU descriptors cache inhibited

And should I keep the manually added Muscan in my s-s, or remove/comment it out?

So I guess it's fingers crossed a clean install will either fix my issues or show what is the root cause. If this also fails and I magically still have some motivation left I may call for your help @Hedeon and buy some beer

Would my indivision mk2 (non cr) or Ratte Switch be any interfereing factor? I can hardly imagine. And I am not going to be able to remove the indi, it's stuck very strongly.

[grelbfarlk]

Originally Posted by spudje

And with full MMUlib install also same behaviour With following MMU-configuration.



I did notice things took additional time to load with MMUlib installed. I didn't understand how to achieve this:


Should I simply uncomment following line?


And should I keep the manually added Muscan in my s-s, or remove/comment it out?

So I guess it's fingers crossed a clean install will either fix my issues or show what is the root cause. If this also fails and I magically still have some motivation left I may call for your help @Hedeon and buy some beer

Would my indivision mk2 (non cr) or Ratte Switch be any interfereing factor? I can hardly imagine. And I am not going to be able to remove the indi, it's stuck very strongly.

No, to Ratte Switch. I highly doubt the Indivision is causing a problem but I don't know of anyone using one with Sonnet.

You don't need Muscan, when you are using the MMULib with MMUlib 060.library it is initialized during setpatch, but it should have installed Mumaprom in user-startup which will initialize it also.

I need to look at my MMU-Configuration again, but that doesn't look right.

[trixster]

It doesn't look like that mmu-configuration is cache inhibiting the pci space. With the sonnet initialised did you then run the buildmmuconfiguration (or whatever it's called!) arexx script? That one you have looks kind of like the default one.

One of the lines in your mmu-configuration should be something along the lines of:

SetCacheMode from 0x40000000 size 0x0FFFFFFF CacheInhibit (or something similar)

I'm using an Indivision AGA and ratte switch so I doubt that's the issue. Are you still seeing lockups with both WOS and warp3d apps/games with just the csppc? Or is the csppc stable and the lockups you're seeing are just with the sonnet?

[Hedeon]

Trickster is right. The output indicates that the pci memory range is now set to copyback. This is wrong. But if you have the same behavior with the sonnet as with the csppc, then we have also look to why the csppc is also not working.