English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 12 October 2019, 15:46   #1
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Exclamation Software failures 68040 CPU on Amiga 4000 EC030

Hi folks,

I am having an Amiga 4000 EC030 with KS 3.1.4 and Workbench 3.1.4. All works fine. I recently bought a 68040 CPU (3640) so I replaced the 68030. Both j-100 jumpers on the Amiga main board have been set to EXT to be able to use this CPU. MapRom on the CPU is enabled.

I have replaced the hard disk with another one which is completely empty to do a clean install again. Also I have removed my Mediator to be sure nothing is interfering. First I want to have a plain Workbench 3.1.4 running on hard disk.

I am able to boot from my WB 3.1.4 disk and do a clean install to my hard disk. After installation it requires me to copy the CPU library 68040 to the LIBS folder which I did. However, when booting I am always getting a c:setPatch 'Software failure' error. I have tried different versions of the 68040.library (old, new, the one from MMULIB, the one from the Amiga OS 3.9 CD) All the same problem...

I have updated the Workbench 3.1.4 with the latest update (July 2019) but this doesn't make any difference.

I am not able to boot the Workbench (it keeps hanging with software failures and ask me to reboot). No matter how many times I install the Workbench. I can only boot the WB 3.1.4 installation disc. I am able to run 'SysInfo' from a floppy. It shows half the speed and FPU and MMU are not in use.

I changed the Kickstart 3.1.4 roms with the original Kickstart 3.1 roms. I am able to boot the Workbench 3.1. When I run 'SysInfo' it shows the full speed and FPU/MMU are enabled. So it seems to be fine with Kickstart 3.1, but not with Kickstart 3.1.4.

I have also tried with the MapRom disabled on the CPU but this doesn't make any difference. It keeps hanging with software failures at boot on hard disk with Workbench 3.1.4.

Has anybody an idea?
astremler is offline  
Old 12 October 2019, 18:56   #2
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 2,008
Hi, which software failure numbers do you get? Please list them in detail, as they report what was wrong.
gulliver is offline  
Old 13 October 2019, 02:47   #3
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
See attached screenshots. These errors appears at the boot.

I have tested with 'SysInfo' using Kickstart 3.1.4. FPU and MMU seems to be disabled.

I have also tested with Kickstart 3.1 with same setup and it works normal. (FPU and MMU enabled)

Basically it fails on everything at boot. If I comment 'SetPatch' then the next command will fail.
Attached Thumbnails
Click image for larger version

Name:	IMG_2088.jpg
Views:	54
Size:	456.5 KB
ID:	64748   Click image for larger version

Name:	IMG_2090.jpg
Views:	43
Size:	777.6 KB
ID:	64749   Click image for larger version

Name:	IMG_2097.jpg
Views:	38
Size:	693.4 KB
ID:	64750   Click image for larger version

Name:	IMG_2096.jpg
Views:	34
Size:	849.7 KB
ID:	64751  

Last edited by astremler; 13 October 2019 at 02:53.
astremler is offline  
Old 13 October 2019, 04:02   #4
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Conflict A3640 with IDE bus

I did some further investigation. I changed the Kickstart roms back to 3.1 and tried to install Workbench 3.1. I was able to partition the hard disk (80 GB) with a small 500 MB partition using HDInstTool but after reboot this partition is never been recognized in the Workbench. So I could not format this partition.

I changed the CPU back to 68030 and did the same. I created the partition again and after reboot I am able to format it. I have installed Workbench 3.1 and boots fine.

I have put back the 68040 CPU again and it doesn't boot anymore. The partition is not recognized ending up with the Kickstart screen.

So this problem is not about Workbench 3.1.4, but it's about 68040 compatibility issues with the IDE bus on the main board. Once the 68040 is in place the internal IDE gets messed up. However, it works all fine with the 68030.

Does anyone have an idea why?

Last edited by astremler; 13 October 2019 at 04:08.
astremler is offline  
Old 13 October 2019, 12:58   #5
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 2,008
Oh what a pitty!

You should get your A3640 board checked by an Amiga technician. If you don't have anyone specialized at hand, try starting to see if someone can recap your A3640 board (and doing that also to your Amiga will certainly extend its lifspan).
gulliver is offline  
Old 13 October 2019, 13:56   #6
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by gulliver View Post
Oh what a pitty!

You should get your A3640 board checked by an Amiga technician. If you don't have anyone specialized at hand, try starting to see if someone can recap your A3640 board (and doing that also to your Amiga will certainly extend its lifspan).
This board has already been recapped recently. It came from another working Amiga 4000 before I bought it. I think the issue is more at the IDE bus side of the Amiga. The previous owner of my Amiga did some customisation there.
astremler is offline  
Old 13 October 2019, 14:08   #7
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 51
Posts: 1,156
You can try to use other SetPatch, or try to use LoadModule at first and replace ROM modules one by one. Maybe any new ROM module cause this problem? scsi.device for A4000?
Don_Adan is offline  
Old 13 October 2019, 14:19   #8
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by Don_Adan View Post
You can try to use other SetPatch, or try to use LoadModule at first and replace ROM modules one by one. Maybe any new ROM module cause this problem? scsi.device for A4000?
See my previous post. I went back to basic by putting my old Kickstart 3.1 roms back and installing Workbench 3.1 on a clean disk. I couldn't manage to partition my hard disk with the 68040. Putting the 68030 back everything works fine again. I think there is a hardware issue but strangely everything works fine with 68030.

Quote:
Originally Posted by astremler View Post
I did some further investigation. I changed the Kickstart roms back to 3.1 and tried to install Workbench 3.1. I was able to partition the hard disk (80 GB) with a small 500 MB partition using HDInstTool but after reboot this partition is never been recognised in the Workbench. So I could not format this partition.

I changed the CPU back to 68030 and did the same. I created the partition again and after reboot I am able to format it. I have installed Workbench 3.1 and boots fine.

I have put back the 68040 CPU again and it doesn't boot anymore. The partition is not recognised ending up with the Kickstart screen.
astremler is offline  
Old 13 October 2019, 14:31   #9
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by AmigaHope View Post
You seem to know what you're doing, but it's always good to check... What was your maxtransfer setting for the partitions when you first installed the OS? This problem has caught many a person on OS installation from back in the day all the way up to today.
How do I check the maxtransfer settings for the partitions?
astremler is offline  
Old 13 October 2019, 14:36   #10
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,285
In HDToolBox
malko is offline  
Old 13 October 2019, 14:41   #11
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 319
Quote:
Originally Posted by astremler View Post
How do I check the maxtransfer settings for the partitions?
IN HDToolbox or whatever tool you used to create the partitions. They should be 0x1FE00 (or 0xFE00 for some less-compatible IDE devices). It doesn't have to be those exact values as long as they are *smaller* than them, but those are considered the optimal values for the maximum amount that should be access in one operation.

This *probably* isn't your problem in this case (I actually deleted my post just in case because I don't want to accidentally mislead you) but it is frequently a problem on faster Amigas. In general though MaxTransfer must be set from the very beginning when you create the partition because it can create mangled writes/reads from the beginning, so you have to have it set that way for all time.

Last edited by AmigaHope; 13 October 2019 at 14:46.
AmigaHope is offline  
Old 13 October 2019, 14:50   #12
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 319
To elaborate, the most common problem from bad MaxTransfer settings is mangled files being written beyond around 64k or 128k. So for instance your 3.1.4 rom image for maprom could have been written with glitches since it's a 512k file. Or any other files written since you set up the partition.
AmigaHope is offline  
Old 13 October 2019, 16:58   #13
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by AmigaHope View Post
To elaborate, the most common problem from bad MaxTransfer settings is mangled files being written beyond around 64k or 128k. So for instance your 3.1.4 rom image for maprom could have been written with glitches since it's a 512k file. Or any other files written since you set up the partition.
Thanks a lot for your information... This makes a lot of sense. Let me check this in detail and let you know the result.
astremler is offline  
Old 13 October 2019, 17:20   #14
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 319
Quote:
Originally Posted by astremler View Post
Thanks a lot for your information... This makes a lot of sense. Let me check this in detail and let you know the result.
For the best safety just set MaxTransfer to 0xFE00 for all your partitions, format them and do your install. Later on you can experiment setting them to 0x1FE00, rebooting, and then copying large files around your drive and then running checksums on on them to see if they are copying correctly. MaxTransfer should never ever be set higher than 0x1FE00 on the IDE bus.

Higher MaxTransfer lowers CPU overhead slightly on disk activity and can give slightly better speeds (especially on DMA SCSI controllers), and it can be set much higher on some controllers, but it's usually best practice to leave it at the regular C= IDE controller maximums for safety and just take the small performance reduction.

Back when I got my A4000 back in the 90's I had to learn all this the hard way. =(

It only got worse as systems got faster, some crappy CF cards absolutely need 0xFE00.

Edit: Also to clarify, MaxTransfer has nothing to do with transfer *SPEED*, just the transfer *SIZE*, i.e. how much data is transferred in a single I/O operation from the filesystem driver to the scsi.device or equivalent. Some drivers are smart and enforce their own limits in how they handle the data from there, some aren't. The IDE driver in scsi.device is not smart at all. The only advantage in making it larger is to reduce the number of times the filesystem driver has to call the hardware driver, saving you a few cycles each time, and potentially giving a command queueing SCSI driver more opportunities to reorder traffic (only really relevant on a spinning disk).

Last edited by AmigaHope; 13 October 2019 at 17:30.
AmigaHope is offline  
Old 13 October 2019, 17:37   #15
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 319
Also, supposedly Hyperion fixed scsi.device in AmigaOS 3.1.4 to not have transfer size problems, but obviously that won't kick in until after you've successfully booted into 3.1.4.

EDIT: On further reading it looks like the new 3.1.4 scsi.device enforces the 128k/255 sector limit (i.e. what you'd get from 0x1fe00) but if your device only works right with a 64k/127 sector limit (particularly some CF cards) you probably still have to set 0xfe00. Probably best to just set 0xfe00 in general.

What drives are you using with your A4000? Are you using an IDEfix splitter at all?

Last edited by AmigaHope; 13 October 2019 at 17:52.
AmigaHope is offline  
Old 15 October 2019, 06:20   #16
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by AmigaHope View Post
For the best safety just set MaxTransfer to 0xFE00 for all your partitions, format them and do your install. Later on you can experiment setting them to 0x1FE00, rebooting, and then copying large files around your drive and then running checksums on on them to see if they are copying correctly. MaxTransfer should never ever be set higher than 0x1FE00 on the IDE bus.
I have put back the KS 3.1.4 roms and 68040 CPU. Booted from Workbench 3.1.4 install disk and did the process again.

In HD Toolbox (see attachment) I have tried with 0xFE00, new partition & format. Installed workbench 3.1.4 and placed 68040.library in LIBS:. After reboot the same problems! Also I tried with 0x1FE00. Same issues..

Not sure why it's so complicated with 68040 compare to 68030 (with FPU) which works without any problems. I also noticed before I was using 0xFFFFFF transfer rate and no issues with 68030. Weird...

Quote:
Originally Posted by AmigaHope View Post
What drives are you using with your A4000? Are you using an IDEfix splitter at all?
I am using a Gotek and standard 3.5" Floppy drive. I am not using any IDEfix splitter. Just the standard (shitty) IDE/Floppy bus on the mainboard.
Attached Thumbnails
Click image for larger version

Name:	IMG_2110.jpg
Views:	25
Size:	685.4 KB
ID:	64767  
astremler is offline  
Old 15 October 2019, 09:25   #17
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 145
One more thing to consider: don’t use a 030 optimized version of the file system on 040/060. The 030 version may contain instructions that are not supported by 040/060. That would cause crashes during early boot or no boot at all (along with lots of gurus). That’s just a hunch; it may not apply to your specific problem.
pipper is offline  
Old 15 October 2019, 10:04   #18
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by pipper View Post
One more thing to consider: don’t use a 030 optimized version of the file system on 040/060. The 030 version may contain instructions that are not supported by 040/060. That would cause crashes during early boot or no boot at all (along with lots of gurus). That’s just a hunch; it may not apply to your specific problem.
How do I know which version of the file system I am using? How do I install a 040/060 version of the file system in stead?
astremler is offline  
Old 16 October 2019, 03:23   #19
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 319
What happens if you boot with caches disabled in early startup?
AmigaHope is offline  
Old 16 October 2019, 03:53   #20
astremler
Registered User

 
Join Date: Aug 2018
Location: Dong Guan / China
Posts: 30
Quote:
Originally Posted by pipper View Post
One more thing to consider: don’t use a 030 optimized version of the file system on 040/060. The 030 version may contain instructions that are not supported by 040/060. That would cause crashes during early boot or no boot at all (along with lots of gurus). That’s just a hunch; it may not apply to your specific problem.
I don't think this is the issue here. I am using a standard Workbench 3.1.4 installation which I guess it's also optimized for 040/060. At least I should be able to do a basic Workbench installation on a small clean partition without any fancy actions except putting the 68040.library in the the LIBS folder.

Switching file systems like SFS or PFS before installation is no option. I am unable to switch the filesystem in HD Toolbox when booting from the WB 3.1.4 install disc. i know there might be ways to do by connecting the hard disk to a PC using WINUAE, but I can't be bothered. Even not sure if this solves the issue either.

I think more it's a hardware/compatibility issues with the IDE bus since there were some customization done by the previous owner. It has changeable IC's which I was told it is not standard. I am not familiar with this.

I have 2 options:

1) Continue using the 68030 and everything works fine

2) By-pass completely the IDE bus by buying a FastATA 4000. This probably solves everything, at least I am 99% sure, but obviously need to open my wallet. Anyway I was already planning to buy this one. Let's see..
astremler is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Is this Amiga 4000 CPU slot faulty? reflex support.Hardware 11 03 October 2018 20:33
Netsurf, Real Amiga 1200 with 32mb ram and 68040 cpu utri007 Amiga scene 11 08 August 2016 01:56
FS: Amiga 4000 030 CPU module... mabus MarketPlace 0 03 August 2007 20:00
Strange A4000 kicksart rom chips and EC030 cpu card with mmu? keropi support.Hardware 5 01 August 2006 10:26
[FA] A3630 EC030@25MHz [AMIGA 3000/4000] scan_x MarketPlace 0 16 January 2004 20:13

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09360 seconds with 14 queries