At wit's end with Accelerated A500 + SCRAM500 SCSI

[psoma]

Hey all,

Spent 2 days trying to make sense of this. My setup:

A500 6A
1MB Chip (all onboard)
SCRAM500 SCSI + 2MB Fast
VXL*30 68030 Accelerator (no RAM32)
3.1 ROM
IBM 9GB HDD / SyQuest 270MB

So I spent the first day trying to get the SCRAM500 seeing anything at all, but I have that going now... HDToolBox sees both the 9GB HDD and the SyQuest 270MB drive. This is where the "what the?!?" bit starts:

- If I setup a 200MB partition with FFS with the acceleration disabled (68000 mode) - I can install and OS and the thing boots/runs fine.

- If I flick it over to 68030 mode, the disk still appears, but I get Checksum errors almost immediately and while the drive will start booting, it hits Checksum/Read errors parsing startup-sequence. I want to work in 68030 mode predominantly, so this won't do.

- If I setup a 200MB partition with PFS3 and the acceleration disabled (68000 mode) the DH0 icon appears after reboot and I can format the drive using pfs3format.

- If I flick it over to 68030 it won't even boot and if I use a boot disk, DH0 doesn't appear.

- If I try and setup a partition with PFS3 in 68030 mode, everything seems to work alright in HDToolBox, but after rebooting, the "NDOS" disks don't appear as I'd expect them to, and after running HDToolBox again, the disk information is blank - it doesn't remember the disk type or partition information.

I'm at wits end with this thing. Sure, it runs fine in 68000 mode, but I (obviously) want to use my 68030 accelerator. The SCRAM documentation says it "flies" with a 68030 so I'm presuming it has been tested with a 68030... I just can't for the life of me work out what would cause the bizarre symptoms above?!?!?!?!?

The input of the EAB gurus would be very much appreciated!

Cheers,

Tom

[Wrangler]

To start with the simple stuff, is the SCSI chain properly terminated at both ends with power being applied to the terminators? (Lack of proper termination causes all sorts of weird errors)

[Toni Wilen]

If you haven't already tried, try installing mmulib from Aminet. Bad 68030 cache configuration can cause strange problems with expansions. Early 68030 boards can also have random problems with some expansions.

Does anything change if you remove all fast RAM? Does the system work normally (no hangs or crashes) if you disable the HD controller and boot from floppy (with fast RAM installed)? Perhaps it is VXL<>fast RAM problem and HD problems are only a side-effect?

[psoma]

@Wrangler: yep, SCSI is terminated actively at the disk. Have also tried turning off active termination on the disk and using external termination with the same result. Having no termination leads to freezes when trying to even scan the bus, so I’m almost certain the termination is right.

Toni: FastMem + Floppy boot works fine. I was getting freezes with 1.3 and 2.05 ROMs when clicking on icons in WB but that stabilised with 3.1. Will give mmulib a try. Tried disabling the 68030 cache on boot but it didn’t get far enough into the boot process before giving disk errors using FFS to successfully run the command! Will also try disabling the fastmem and reporting back.

Cheers,

Tom

[DrBong]

Initially I thought it might be a MaxTransfer problem, but then that doesn't fit with your SCSI hard drive working on 68000 and not 68030. Delving into it a bit further, perhaps it's your hard drive's mask value. According to the VXL*30 manual:

"If you have a DMA disk interface (such as CBM's 590 or GVP's Series II), memory mapped high will create an access problem. Change the mask value to 0x00fffffe (see your drive's Rigid Disk Block prep software and documentation) else map the memory low."

Hopefully that will do the trick if nothing else suggested above does.....

[psoma]

Thanks DrBong,

I’m pretty sure that only comes into effect when there’s a RAM32 board as well. I don’t have one, but just to eliminate it, I went to check the Mask setting and found it already was that

Disabling the FastMem didn’t help either... exactly the same symptoms. I’ve downloaded mmu.library but how do I actually load the library?

Cheers,

Tom

[DrBong]

Originally Posted by psoma

I’m pretty sure that only comes into effect when there’s a RAM32 board as well. I don’t have one, but just to eliminate it, I went to check the Mask setting and found it already was that

Sure, but I'd wondered if the fastram on your SCSI controller was perhaps causing the same sort of hard drive problems attributed to the VXL-32 in the manual.

Originally Posted by psoma

Disabling the FastMem didn’t help either... exactly the same symptoms.

I guess not!

Originally Posted by psoma

I’ve downloaded mmu.library but how do I actually load the library?

Run the installation script or, alternatively, just copy mmu.library to LIBS: (should say as much in the AmigaGuide docs).

[psoma]

Run the installation script or, alternatively, just copy mmu.library to LIBS: (should say as much in the AmigaGuide docs).

Hmmm, I dropped mmu.library into Libs but SysInfo isn’t showing it as loaded... wasn’t sure if I needed to add anything to my Startup-Sequence as I’m only booting off the WB3.1 Install disk...

Cheers,

Tom

[mark_k]

Is there any difference if you change each partition's Mask value to 0x001FFFFE?

[DrBong]

Originally Posted by mark_k

Is there any difference if you change each partition's Mask value to 0x001FFFFE?

....and perhaps BufMemType = 3 ??

[psoma]

Will give both of these a try, cheers.

Just a thought... I have the 68030EC processor meaning it doesn’t actually have an MMU - I assume this makes the whole mmu.library thing moot?

Cheers,

Tom

[psoma]

Alrighty... so no dice there unfortunately. I've spent a lot of time on this now trying every combination and permutation of termination, Mask and scram8.device (2.557 on the ROM, 1.0 on the floppy). Even when I know it's definitely using the Chip Mem for buffering (because I have 200k less chip mem and 200k more fast mem depending on the BufMemType setting), it still won't boot off DH0:.

The issue seems to be that when accelerated, the SCSI bus scans are intermittent - it doesn't always find the disk, and if it does, it doesn't always retrieve the details saved to it. I'm thinking that it doesn't even get a chance to check the Mask so it's never going to be stable enough to boot and use.

I'm getting close to just retiring the VXL and fitting a 68010 to get WHDLoad quit support unless anyone has any other ideas?!?

Cheers,

Tom

[psoma]

Argh! I worked it out. After spending *months* of late nights running through every combination and permutation of memory, file system, Mask setting, KS ROM, disk drive etc. etc. turns out...

It was the power supply!

Switched in one of my A600 PSUs and it works a treat. Finally I’m disked up and accelerated! Whew.

Thanks for everyone's help!

[DrBong]

@psoma
I'm glad you finally worked it out mate! Have to say it's quite bizarre that it was a PSU problem as original A500 PSUs are quite beefy and I've had no problems with using A500 set-ups with DKB 030 cards + onboard ram with/without an external GVP hard drive/ram enclosure hanging off the side (admittedly powered by its own PSU). Makes me wonder if the homebrew-style SCRAM SCSI controller/ram card is unusually power-hungry!

[psoma]

Thanks DrBong. What's even stranger is that this is the "heavy" type A500 PSU which is why I didn't even suspect it. It nominally claims to have twice the amperage of my A600 supplies but I guess it ain't well.

I opened it up and found a dry solder joint so reflowed all the solder. Interestingly, it worked for a day or so and then started playing up again. Am now doing a full recap and will see if that sorts it out.

Really weird though. Especially as all the devices connected to the SCRAM are externally powered so I would imagine the power draw of the SCRAM itself to be negligible. Perhaps the VXL is a bad design?!? From memory, the thing would freeze from time to time with the VXL and no SCRAM connected... at least I think it did. Without a HDD attached, I didn't really spend a whole lot of time using it!