26 January 2020, 07:33 | #1 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
At wit's end with Accelerated A500 + SCRAM500 SCSI
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 |
26 January 2020, 13:33 | #2 |
Registered User
Join Date: Sep 2015
Location: London, UK
Posts: 414
|
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)
|
26 January 2020, 14:22 | #3 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
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? |
26 January 2020, 20:13 | #4 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
@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 |
26 January 2020, 21:50 | #5 |
HOL / AMR Team Member
Join Date: Dec 2001
Location: Australia
Posts: 2,632
|
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..... |
26 January 2020, 22:19 | #6 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
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 |
26 January 2020, 23:07 | #7 | |||
HOL / AMR Team Member
Join Date: Dec 2001
Location: Australia
Posts: 2,632
|
Quote:
Quote:
Quote:
|
|||
27 January 2020, 01:15 | #8 | |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
Quote:
Cheers, Tom |
|
27 January 2020, 15:03 | #9 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,340
|
Is there any difference if you change each partition's Mask value to 0x001FFFFE?
|
27 January 2020, 19:27 | #10 |
HOL / AMR Team Member
Join Date: Dec 2001
Location: Australia
Posts: 2,632
|
....and perhaps BufMemType = 3 ??
Last edited by DrBong; 27 January 2020 at 19:35. |
27 January 2020, 20:31 | #11 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
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 |
29 January 2020, 10:37 | #12 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
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 |
04 March 2020, 08:04 | #13 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
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! |
05 March 2020, 08:52 | #14 |
HOL / AMR Team Member
Join Date: Dec 2001
Location: Australia
Posts: 2,632
|
@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! |
12 March 2020, 21:46 | #15 |
Registered User
Join Date: Nov 2019
Location: Melbourne, Australia
Posts: 193
|
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! |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AmIRC-68000 on accelerated a500 -- thinks it is AmIRC-68020 | vext01 | support.Apps | 14 | 30 January 2020 11:41 |
at my Wits End, New Membrane for A500 and Keyboard Still not Fixed :-( | nathanm1991 | support.Hardware | 11 | 29 June 2018 00:33 |
Floppies with a '8' when formatted wit X-Copy | Vollldo | support.Hardware | 12 | 18 March 2011 19:41 |
Xopa and accelerated Amigas | Iznougoud | support.Hardware | 1 | 25 December 2008 02:17 |
Game like Krusty wit superb music | toki | Looking for a game name ? | 2 | 31 May 2005 20:51 |
|
|