A query on "Errors in memory testing" (ACA 1234 + ACA 500 Plus)

Quote from Jens

That's FPU commands - you are attempting to run FPU software on a non-FPU card.

Nope..I'm not...that error is coming from an A500 game in WHDLoad...
but the CPU may be trying to do so ... if it starts executing instructions from corrupted memory for instance.

Quote from Jens

If I remember right, you have a non-standard case, power supply and some kind of Zorro acapter to "fold" the ACA500plus to a different position. Before I debug that, I'd like to see the "bug" reproduced on a recommended setup.

Quote from Jens

after compiling the release version of the CPLD, I did not do the required amount of testing - thinking "I have done so much testing already". Who would have thought that changing an ID and re-compiling will trigger a compiler error like this...

Okay..

Genuinely... I just finished writing a couple paragraphs of very direct response about testing, product readiness, and professional products vs. hobby projects. But, I've deleted all of it, because while it was incontrovertible, I 'feel', if it was directed at me, it would have been more hurtful than helpful; and frankly, that's not going to make my Amiga work or make ACA1234 better, or make me feel any better in month. [deleted]

Instead, I thank you for releasing the ACA1234, very few others are releasing accelerators, and I hope you success in your continuing efforts, I know I still want an ACA2000 and an ACA1240 in the future.

As much as you 'torture' me about my rig not being 'recommended', 'non standard', 'unusual', 'odd', I can't remember all the adjectives , it has not been the power supply that has been involved in either of the two difficulties I've experienced, and from the photos I've sent you, it's not improper shielding or improper grounding either.

1) I have found the ACA500+ more stable on the Zorro II riser card with the 68000 and ROM removed from the motherboard and the ACA500+ generating the clock. This suggests the riser increases RC on the bus, but we both know this is going to happen with extra connectors and added trace length. In the earliest case of that Zorro II board, poor routing 'likely' made this completely unworkable, I never did find an explanation, I just 'used my eyes'.

You were kind enough to point out the added loading early in my build, I pulled the unneeded chips, bridged the clock and it's been rock solid.

2) I've found a model of PS2 mouse that MicroMys doesn't play nice with, but does appear to work on a PS2 PC just fine.
It uses a knock-off chip and skinny cord, so I've 'solved' that issue with a new mouse, from a German company, with a name brand IC and thicker cord.

It's been a running inside joke with my Amiga peers, but every time I run into an issue with the Amiga,

I figure it'll be easier to get support out of iComp, if I pick a nice German supplier... SwissBit, Wurth, Perixx, etc..

For all the stuff (and it's a lot) that I have bought from iComp..those two are the whole list of issues, seems pretty thin to me.

Specific to the ACA1234:

I'm going to do what I can to comply with your ask...

I have a spare A500 rev 5, ACE2b and Indivision ECS v2 and stock PSU.

I'll unplug my ACA500+ & ACA1234 and walk it over there.

I can do this, so I will do this...

Let's see what happens... Science

I'm actually happy to assist in finding bugs or confirming non-bugs as the case may be.

I am a little surprised that of the dozens of boards you've shipped, only three of us reported on the forum having seen this initial memory issue.
Despite all of us being affected.

As a result, I don't feel like I can simply wait for another customer with my configuration to speak for me.

Les.

Un-Recommended Amiga by Night

A500 rev 5 recapped with Worth Poly caps

- ACE2b

- Indivision ECS v2

- ACA500+ with SwissBit 4GB and 2GB CF cards

- Lyra 3 + WASD CODE TKL

- MicroMys v5 + Perixx Mouse

Checkmate 1500 case

Independent +5V, +12V, -12V SMPS supplies

Arduino keyboard reset signal generator

Over voltage, Under voltage, Over temp. shutdown
Temperature controlled fans

Push button on\off

I hope to do the first tests with the CPLD-update tool tomorroe. We will use the same parallal port cable as we've used for the 2018 CPLD update of the Buddha, described on the Wiki page. Customers who already have this cable can just download the tool and do the re-programming. For all other customers, we'll ship free cables.

Quote from ljmarent

Nope..I'm not...that error is coming from an A500 game in WHDLoad...
but the CPU may be trying to do so ... if it starts executing instructions from corrupted memory for instance.

You write that this is happening with the new firmware installed. However, does it also happen when blocking that 1MByte of memory? THis may indicate that the software-detection of the wrong mapping does not work, and the area isn't actually blocked.

Quote from Jens

You write that this is happening with the new firmware installed. However, does it also happen when blocking that 1MByte of memory? THis may indicate that the software-detection of the wrong mapping does not work, and the area isn't actually blocked.

Firmware patched as seen here:

No errors occurred, I take that to mean all patched

WorkBench 3.2:

Everything seems to be working great !

WHDLoad Games:

I took some time to play the WHDLoad games on my system, keeping some notes of which ones generate errors or don't, with only the patch, or with the patch and the SMARTBLOCK 40000000 47DFFFFF

I found Lemmings, Gods, Golden Axe, Shadow of the Beast, all work with just the patch in place.

Before the patch, these were throwing errors.

I have other games which are still throwing errors, but they were doing so, before the patch, after the patch and even with SMARTBLOCK, so could be bad installs, or they don't like the 030, or .. well now I'm just speculating now...

ATK:

I've run ATK fine before the ACA1234, but since installing it, that program has be highly unstable.

It crashes the computer, even if I do nothing after loading it.

No longer usable.

MBRTest-2:

I'm still 'locking-up' 3 or 4 seconds after starting the ACA1234 FastRam portion of the MBRTest-2 test
ChipRAM and whatever that 1MB local ram is, pass no problem.
not sure where the 6.8MB of 16bit FastRAM from the ACA500+ is or why it doesn't show for this test.

But, I think this is the more definitive, more interesting test than the ones above.

Since apparently the patch fixed your test system.

This is why I asked if your test system was an ACE2b, ACA500+ rig ?

I worried that trapdoor ram and the larger 2MB chip ram both come from Ranger space.

Perhaps a second overlapping region could exist or a second independent issue related to the larger ChipRam moving other thing around.

Anyway, after I finish work today, I'll power up and test the 'stock' A500 r5 + ACE2b + Indivision ECS v2
We'll see what happens.

New information...
If I disable the ACA500+ 6.8MB of FastRAM... I can run the MBRTest-2 without crashing...at least so far

I'm 5 minutes into the test now, all is good..

So...am I supposed to disable the ACA500+ FastRAM or give it a different setting to work with the ACA1234 ?

I checked the flashable 20211117 hotfix on my A500 (A500 Rev8.A1 + ACA500 + XSurf-500 + ACA1234).

The flashing apparently succeeded:

Then i did a power cycle and ran MBRTest-2.

Unfortunately, for me as well, it still freezes at an early stage of testing:

Also both MBRTest-2 and AmigaTestKit show exactly the same amount of memory as pre-flash.

In the end, I ran AmigaTestKit memory test and it failed for me as previously:

Kinda looks like the flashing did nothing?

Good luck with debugging this and thanks for quick replies!

Cheers!

Well I'm glad there are a few of us looking

Most of these cards must be going on collector shelves...

MBRTest-2 test completed success ... but I had to disable the ACA500+ 6.8MB FastRAM

Let me try Amiga Test Kit... maybe it runs now too

Quote from ljmarent

New information...
If I disable the ACA500+ 6.8MB of FastRAM... I can run the MBRTest-2 without crashing...at least so far

I'm 5 minutes into the test now, all is good..

So...am I supposed to disable the ACA500+ FastRAM or give it a different setting to work with the ACA1234 ?

I tried disabling the ACA500+ fast RAM too, but unfortunately it didn't change much in my case.

Both AmigaTestKit and MBRTest-2 failed on me at the same spots and in the same manner as previously.

I also got a random "illegal instruction" from AmigaTestKit:

Well I've had to call off the parade...
After rebooting... I can no longer pass the MBRTest-2 even with the ACA500+ FastRAM disabled...
{sniffs}

I only got to see it pass the test once...

It took ~ 9 minutes and 20 some seconds to complete at 33MHz

I should have taken a picture

Intermittent sucks....

After reading this thread, I start to suspect that my ACA1234 is affected from the same problem as well.

I've posted on the german a1k forum a test about the ACA1234, and was asked to measure the time required to load "Beneath a Steel Sky" for CD32 with "PRELOAD" set. That causes a large amount of data (>90GB, if memory serves me right) to be loaded in RAM before starting the game.

But I couldn't measure anything, since after a while my 1200 hangs and the available memory displayed turns into something strange...

This happens only when the 1234 is mounted. The Blizzard 1230-IV mounted on the very same 1200 (with CA-PSU) runs the game flawlessly. I've repeated the test many times, and could always reproduce the error.

So..this time I caught it .. and took a picture ..

With the ACA500+ FastRAM and Trapdoor RAM disabled...
It took many, many reboots, but it passed this time

Once it gets past those first 3-4 seconds ..it seems like it will finish,

So ... I'd suspect what ever the ultimate issue is... it's hiding near the beginning of the ACA1234's memory.

I definitely am not saying it's 'working' ... just that under certain circumstances ... with enough attempts, you can get the test to pass.

Quote from ljmarent

This is why I asked if your test system was an ACE2b, ACA500+ rig ?

I'll include an ACE2b in further tests today. Note that I'm not testing the new firmware any more - we're working on the CPLD update procedure. After the issue has shown on all test systems, I continued searching with an A1200 only, and after finding that the root cause is within the RAM subsystem, I did all firmware tests A1200, and only checked if the "block memory" triggers on ACA500plus - and it does.

I didn't even notice that the ACA500plus memory wasn't showing in MBRtest-2. Then again, I'm using V1.22, which may actually show it.

Now that you're writing that you can get the test to pass when switching off the ACA500plus memory, there might be a bug in MBRtest-2. After all, the ACA500plus maps memory to unusual locations.

Quote from lucadip

I start to suspect that my ACA1234 is affected from the same problem as well.

All ACA1234 shipped before November 16th are affected. As I wrote earlier, I'll contact all customers via eMail once a solution is available. Let me continue tests, and Timm implement my suggestions.

Quote from Jens

Now that you're writing that you can get the test to pass when switching off the ACA500plus memory, there might be a bug in MBRtest-2. After all, the ACA500plus maps memory to unusual locations.

For me switching ACA500Plus fast RAM off doesn't help (as I wrote earlier). And if I understand @ljmarent correctly, it works for him only once per a bunch of reboots which sounds pretty random.

Hi,

Also a aca1234 owner but other than installing it in my 1200 I've used it very little since(not even updated). After seeing this post ive ran a few games and had no issues.

I also ran a mem test which caused the system to hang(image included). If you need me to do any further tests just let me know.

Testing is only intersting if you have installed the firmware update of November 17th. If your card was shipped before November 16th, it is affected, and it will ultimately need a CPLD update. We're working on a method that lets you install this on your own.

Meanwhile, the flash update will help making software work that uses the memory from the top end first (might be 50% of all titles).

MBRTest-2 will also not display all ACA500plus memory chunks with V1.22 that I have on my installs. The memory is displayed by WB and other tools, such as showconfig and Sysinfo, so a bug in MBRtest-2.

so one could safely order one now because the bug is fixed?

Quote from turrican9

so one could safely order one now because the bug is fixed?

Yes, shipping has been halted for November 16th (Tuesday) when I found in the evening of the 15th (MOnday) that the bug was definitely within the ACA1234. After the CPLD-fix was confirmed working in all configurations, we applied that and resumed shipping on November 17th (Wednesday).

I am already in the process of testing the CPLD-upgrade procedure.

I'm glad an initial problem was detected early.

And a CPLD patch developed quickly.
And I'd be happy to apply it as soon as it's available, though I'll be one of the ones who must wait for a cable or make my own.

But...and I say this as kindly as I can...
A lack of testing at a key moment created this mandatory 'campaign' and/or 'recall' if the customer is unwilling to apply this 'invasive' patch.

I for one, would not mind one bit if this patch was deployed a little latter, if that delay would assure you have ample time to perform more exhaustive testing at lower personal stress level. There is a lot of hardware combinations and a lot of software that should be tested after the CPLD is patched.

Taguchi method could be used to reduce the number of actual tests, reducing the labour burden.

And the time used conducting your matrix experiments could be used to inform future accelerator release test plans.

But, if you're not accustom with using this tool... than this may cause excessive delays.

A stated DVP&R (it's not just automotive anymore) or at least a written qualification test plan where you share what system hardware descriptions and what software was tested in your qualification plan would go a long way to building confidence.

It's nothing you're not already doing... you just share your test notes, you can pretty it up later
Professional products have "tested to meet or exceed XYZ specification" and public access to those specifications.

There is no reason iComp can't create the specification it follows, and in doing so customers may require other makers to test to the same or hold their feet to the flames.

It would be better for all I believe, to catch all or as many bugs as possible in a single rollout, than an ongoing stream.
Especially if a second issue is subsequently found to require or benefit from a second CPLD patch.

Slow down, be thorough, have fun, at least for you, it's not human lives that are lost ...

Suggested in as kind a way as I can.

Just wanted to confirm that, after executing "blockmem 47c00000 47cfffff", I can start BASS CD32 repeatedly without errors.

Looking forward for applying the CPLD patch.

Jens Please take your time to test, I can survive a couple of weeks... if you promise that afterwards my feature request for acatool will be be implemented!

I also made a few tests ... For example Monkey Island 2 (WHDLoad) refused to start. After updating to 211117.bin it runs.