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

I don't have an ACA1234, but I stumbled upon this thread and wanted to throw out the possibility that there may be other non-hardware issues causing MBRTest-2 to lock up. Just for kicks, I tried it on my accelerated A2000 and stock A3000. Both locked up early in testing fast RAM. So I started up my 3.2 UAE VM, and that locked up too. All of them are running 3.2 ROMs.

OK, if the emulator locks up, we can definitely exclude a hardware fault and must look for a reliable tool to test memory. Suggestions?

I will try later one or a couple of these: Aminet - Search

Maybe it also makes sense to test with different Kickstart-versions ...

I got my new toy (the Rohde&Schwarz RT3004 5GSample Scope/logic analyzer) and tinkered around with measuring any differences that MMU activation might cause. So far, I have only activated the MMU with the "CPU" command from OS3.1: The "Fastrom" option uses the MMU to map Kickstart into Fastmem. However, there is not even half a nanosecond of difference on all signals that go into the memory controller. So in essence, I only see differences that are easily explained by noise and heat that's building up in the CPU. All signals are well within spec - especially setup&hold times of signals going into the CPLD, which is what might cause instable behaviour.

Maybe I need to install Thor's MMU tools to give the MMU some exercise? My initial hope was that I see the AS signal moving significantly (5ns or more), which might explain the MMU impact. And I've thought about how I could account for that in a re-write of the memory controller all weekend. Hmm.. I'll go through other support cases before I make a decision

I still don't understand why i.e. the "Nexus 7"-demo doesn't run correctly on ACA1234 while some users explain that it ran without issues on a Blizzard 1230 ... I tried it right now with the ACA1221lc and it ran flawlessly. ...

I seem to be experiencing issues with the steps to update the CPLD via my ACA500plus.

I've successfully updated to v1.40, but on following these instructions, I simply get a white screen:

• switch it back on, press F3, then X to go to 68000 mode, then ESC to go back to main menu, then F1 to boot).

Even when trying to boot to version 1.3 without switching to 68000 mode (F2 from main menu), I get just a white screen. Using F1 to boot to version 3.1 loads workbench without issue.

Unfortunately my newly acquired A1200 is away to be recapped so I don't have the option to use this for a while.

Are there any other steps that I can take to perform the CPLD update?

Quote from OMo1972

I still don't understand why i.e. the "Nexus 7"-demo doesn't run correctly on ACA1234 while some users explain that it ran without issues on a Blizzard 1230 ... I tried it right now with the ACA1221lc and it ran flawlessly. ...

That has been explained in other threads of this forum: For Nexus7 to run faster, you'd need to activate caches in chip ram. Why that's a no-go is something that I have explained in English and German threads more than once per language. Please check those threads for the reasoning behind this decision.

Quote from stevenwarren82

I've successfully updated to v1.40, but on following these instructions, I simply get a white screen:

switch it back on, press F3, then X to go to 68000 mode, then ESC to go back to main menu, then F1 to boot).

Even when trying to boot to version 1.3 without switching to 68000 mode (F2 from main menu), I get just a white screen. Using F1 to boot to version 3.1 loads workbench without issue.

So what's the issue then? If you can launch WB 3.1 in 68000 mode, you're all set up to run the CPLD update tool.

Quote from Jens

That has been explained in other threads of this forum: For Nexus7 to run faster, you'd need to activate caches in chip ram. Why that's a no-go is something that I have explained in English and German threads more than one per language. Please check those threads for the reasoning behind this decision.

I understood that. But I'm not talking about the slow speed of the demo at some points but the fact that it's not running error-free. It gets stuck somewhere in the mid part. That doesn't happen using the ACA1221lc. It's no big problem but a bit annoying. If I had another A1200 I would pop my ACA1221lc in there for watching demos which won't run on ACA1234 - but those machines are not affordable at all anymore. 😒

Hi. Just want to tell you that after I did the CPLD update on my 1200 everything seems fine. Amiga test kit passed with no ram errors. The MBR test works but after a while locks up. Did not try it with the internal IDE port off. Thanks!

Quote

But I'm not talking about the slow speed of the demo at some points but the fact that it's not running error-free. It gets stuck somewhere in the mid part.

No idea what that particular Demo does - but a lot do dirty tricks where registers or memory is being updated by the Blitter while the CPU runs freely without synchronisation. This works as long as the CPU speed isnt faster and/or slower than expected. If it is, random things will happen.

Quote from Tobias

No idea what that particular Demo does - but a lot do dirty tricks where registers or memory is being updated by the Blitter while the CPU runs freely without synchronisation. This works as long as the CPU speed isnt faster and/or slower than expected. If it is, random things will happen.

Thanks for the answer. Maybe you could just try the demo on a A1200. It's "Nexus 7" by "Andromeda" and freely available on "Demozoo". Would be interesting if you're experiencing the same issues.

I dont have an Amiga1200 But these problems are commonly known - and its not the only demo that behaves strange like this. In all cases the solution is: run it on the platform it was written for, ie disable the accelerator.

Please stop the demo discussion in this thread. It has been discussed exhaustively in other threads, and the solution is to make use of the ultimate compatibility feature of the ACA1234: Soft-switch-off.

Quote from Jens

OK, if the emulator locks up, we can definitely exclude a hardware fault and must look for a reliable tool to test memory. Suggestions?

There is no reliable tool without the source code. MBRTest-2 is fishy, let's move it to the trashcan. I cannot reproduce MBRTest-2 crashing under fs-uae, while It failed to list all memory that is shown in showconfig. I could reproduce MBRTest-2 freezing on the ACA1234 with mmu.library in place, while http://aminet.net/util/misc/pmemtest.lha works in this configuration. MBRTest-2 works with the ACA1234 without mmu.library. So far, the picture isn't conclusive.

Quote from Jens

So what's the issue then? If you can launch WB 3.1 in 68000 mode, you're all set up to run the CPLD update tool.

I think you have misunderstood here, there is no option to boot to 3.1 after entering 68000 mode, only 1.3 or 1.2.

My point here was to highlight that there seems to be an issue with the 1.3 and 1.2 on the ACA500plus profiles specifically. I need assistance on what options I have in being able to make 68000 mode work so I can perform the CPLD update.

Quote from stevenwarren82

I think you have misunderstood here, there is no option to boot to 3.1 after entering 68000 mode, only 1.3 or 1.2.

That sounds like you're still in the cloaking device menu. You missed the "ESC"-press that takes you back to the main menu.

Hi, Im just looking for information on when the cables are expected to be shipped.

Cables have already been shipped; most of them on November 30th, and all others same-day when the eMail arrived here.

Quote from Timm

I could reproduce MBRTest-2 freezing on the ACA1234 with mmu.library in place,

For the record: I have just reproduced the same hang with an old ACA1232-25, which never had a single bug report since it's introduction in 2012. What I do is always the same: Minimal installation of MuLib (nothing launched in startup-sequence): MMU is disabled on boot. In this config, MBRtest-2 will always run the whole memory test.

As soon as I launch MuForce and then MBrtest-2, I get the exact same hang as described here. This can be reproduced with all 68030 accelerators that I have here, including the Blizzard B1230-IV with 16MBytes mem installed.

I therefore have to conclude that there is a software problem when combining an activated MMU and the MBRtest-2 tool.

I will now focus on completing verification of the SD-Ram Controller re-write that I have done in the past two days. This re-write was necessary in order to make it smaller (using fewer state-bits) to make it more routable in the CPLD, as I wanted to move a few signals a bit further away from the "danger zone" (especially synchronous inputs to the 68030). All signals now have considerably more slack time, but that did not change the "freeze" situation with MMU+MBRtest-2. Please note that the previous incarnation of the SD-Ram controller does not violate any timings - my main goal was to account for possible temperature-related instabilities. I will roll this one out later this week when more testing is completed. It just feels better to use this new one.

With even the godfather of all benchmark-cards failing (the B1230-IV), I'm putting this investigation to rest, adding the MBTtest-2 tool to the "not recommended" list.