exxos's Atari, Amiga & retro forum

I have a TF536 with buffered IDE, connected via a 20cm 44-pin cable to a CF card on a V.H2 adapter. It's installed in a rev 6.2 A2000. I've noticed several system freezes (no disk activity LED, no mouse pointer, no guru) when performing disk activity - this can be in something intensive like extracting Zip files or something simple like installing MagicWB. It seems to be write related as it never has an issue loading WHDLoad games, and I can run stuff like the Frontier intro or F18 Interceptor demo for hours without a problem. It does it on both a blue and white 8GB card and a 4GB Sandisk card, and is running a fresh install of OS 3.1 on Kickstart 3.1.

Has anyone else had this issue and if so did you manage to fix it?

go0se did mention this to me, but I was unable to reproduce it. My original issues were related to the patched scsi.device, but I have since removed that from the card so I thought the issue was fixed. However it seems it still occurs in specific conditions. Can you explain how can I easily reproduce this? I tried copying and deleting large directories with DOpus 4 but I had no issues.

@lilwashu @alenppc This does sound very similar to issues I've been having this week.

The 536s are ostensibly fine with booting, WHDload games, demo loops, and all memory tests check out but copying large numbers of files either between partitions or within the same partition cause the machine to lock up and require a soft reset.

The test machine was a Revision 6A A500 with no other add ons or modifications. The 536 firmware is the tf536r2-A500-A2000.zip Alen uploaded to the firmware hub https://www.exxosforum.co.uk/forum/downl ... p?id=14358

To recreate I create a temporary directory at the top level and copy a large number of WHDLoad directories and their contents across from their locations using DOpus e.g. directories A,B,C,D,E,F or, if space is tight on the card A,X,Y and Z. On some occasions the transfers will complete successfully but in around 1/3 of attempts the transfer will lock up the machine at a random point during transfer, can be almost immediate, or a few hundred MB in, seems random.

I suspect an issue with either how I've built the cards or the components that I have used. My build diagnostics were as follows :

1. Change out IDE header - I previously built some cards with standard 2mm pitch header pins rather than the 2mm box headers I prefer to use. I had some boot issues with these standard headers in the past but changing to a box header made no difference in this instance.

2. Suspected residual flux under the CPLD and/or other IC pins. - Cleaned extensively, no difference.

3. Suspect CPU. Even though I was pretty sure all the CPUs were sound, I changed out for a "full service history since the 1990s" RC50C that I am 100% confident of its provenance. Unfortunately this made no difference, the issue remains.

4. Change IDE to CF/SD adapter: I get the same issue on both V.H2 CF to IDE adapters and the generic active type SD to IDE adapters which otherwise seem to work well. Changing the media also makes no difference. Cable is 5cm version in all cases, different cables were tried.

5. Change file system on the image. The CF/SD image I usually use is built on FFS WB3.9, I tried the 8GB (3.1?) PFS image supplied by AlenPPC but the issue remains. I have yet to check the versions of setpatch used on these images.

6. IDE buffers: No change, behaviour on cards with or without buffers is the same, as it is on the same card with IDE buffers removed and 0 ohm resistors replaced.

7. Change out the CPLD(s) Event though I can recreate this issue across a few cards and all the CPLDs program without issue and seem to behave in all other tests I began to suspect the perhaps I'd damaged the CPLDs during ultrasonic cleaning. Changing out to a different CPLD didn't make any difference, although all the CPLDs did come from the same Mouser batch. I have ordered some more CPLDs from Farnell in case I've got a a batch of duds.

I've tested the same images / adapter / media on a TF330 briefly and cannot reproduce the issue on a CD32. But the next step is to perform further tests on the 330 to ensure that I wasn't just lucky when I tested that. I'll also rebuild the TF330 firmware to target the XC95288XL and put one of the CPLDs I removed from a 536 onto a 330 and see if I can recreate again. I'm hoping it is a CPLD issue and it will be resolved when this Farnell order turns up. I spoke to Alen and he can't seem to recreate the issue on his setup so I'm a bit stumped for now! :shock:

alenppc wrote: 05 Feb 2021 18:50 go0se did mention this to me, but I was unable to reproduce it. My original issues were related to the patched scsi.device, but I have since removed that from the card so I thought the issue was fixed. However it seems it still occurs in specific conditions. Can you explain how can I easily reproduce this? I tried copying and deleting large directories with DOpus 4 but I had no issues.

I've got 60MB of zipped WHDload games - when attempting to unzip these on the Amiga (unzip #?) it will hang at some point 100% of the time so far (I just tried it again and it hung on the second zip file). I can upload this somewhere if it you'd like to test it.

Otherwise it's pretty random as to when it will happen - it happened yesterday when installing MagicWB and extracting some small LHA files but didn't at all when I was doing an upgrade of 3.1 to 3.1.4.1 from a Gotek.

I would ask you to try this with my disk image just to exclude any system patches.

But essentially there seems to be an issue when copying memory to ide. If I had to guess, I would bet it probably occurs within specific buffer sizes.

I can’t seem to be able to replicate this at all on my A500; I will have to devise some way to trigger it with more certainty...

@alenppc What are the specs and revision of your A500?

EDIT* And what memory chips + CPU in your 536?

I am currently testing on a rev5 motherboard, the memory chip is a Samsung that we listed in another thread, and the cpu claims to be a RC50C but who knows what it was originally.

I don’t think this is a hardware issue - it’s either a software bug somewhere, either in AmigaOS or the cpld firmware.

Cheers. I'll dig out and set up my revision 5 A500 motherboard tomorrow and see if the behaviour is the same. I am using Micron memory chips on the 536 and don't have any of the Samsungs to test unfortunately, but will leave that avenue for now.

I'm running some compression tests as suggested above and am seeing the same system lock up behaviour during large zip creation under DOpus. Compressing WHDLoad "A" directory to \temp failed about half way through on the first attempt, almost instantly on the second attempt and is still running after about 15mins on the third attempt.

There is no functional difference between the micron and Samsung rams, I used both, so I don’t think that’s the issue. But I will try doing a zip and a lha archive and see what happens.

Edit: @go0se try flashing it with the earlier A500 firmware and see if anything changes.

@alenppc I've rolled the firmware back to an older stable version that was posted here https://www.exxosforum.co.uk/forum/viewt ... 6r2#p41739

https://www.exxosforum.co.uk/forum/downl ... p?id=12059 and tested again with the same results. The Amiga locks up every time so far when compressing the WHDLoad "A" directory to a zip so that seems like a more reliable way for me to reproduce the issue. If there is another early firmware version around that I should try then let me know.

The reason why I assume this is a build, component or setup issue rather than a firmware problem is that the current A500 firmware you posted on the firmware hub https://www.exxosforum.co.uk/forum/downl ... p?id=14358 has been around for a good few months and to my knowledge no one has reported issues with file transfers before? Admittedly I use UAE for file transfers to HDD images before running them on hardware but someone out there must use their TF536 for tasks other than just playing WHDLoad games right? :)

I will set up the R5 A500 today and also build the 330 firmware for the 288 CPLD and swap out a removed CPLD from the 536 to a 330 and see if that highlights anything.