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

Line-F exception is an FPU instruction that obviously cannot be executed, as the card does not have an FPU.

The memory test program reports errors on all bits of $c0.0000 memory. If that would be the case, the computer should not work at all. However, you wrote that you can boot normally, which means that this memory is used by the OS.

It's not the first time that "Amiga Test Kit" reports funny errors - last time we've had such a thread, it was pretty obvious that it was attempting to test memory that wasn't actually in the freemem list. I therefore have a hard time trusting that piece of software. You better use MBR2-test. I believe I have uploaded that in some other thread of this forum, but you should also be able to find it on the driver disk of the old Microbotics memory expansions.

If you still want to stick to Amiga Test Kit, make sure to switch off the MMU library that is part of the ACA500plus menu. It may interfere with the way that the program attempts to access memory.

Again, take ATK with a grain of salt. Most of the problems we have found with it are problems with the tool itself.

Quote

On another occasion I had other errors such as: D31..D024, D23..D16, D15..D8, D7..D0.

Out of curiosity I did the same check with Amiga Test Kit on my A500 (as in your case it's 2 MB chip RAM + ACA500Plus + ACA1234). Looks like I have the same error, which would suggest there's a problem with the testing program.

Quote from diegoarevalo

I leave a screenshot of the moment when the test freezes

And in my case it freezes too in MBRTest-2 - but at a different memory range.

Quick feedback on this: I can reproduce the "hang" in MBR-Test. Need to investigate what's going on - logic analyzer time.

Using:

Amiga 500 rev 5 with ACE2b, Indivision ECS v2, ACA500+, ACA1234 50MHz (33MHz), OS3.2
68000 removed, ROM removed

68030.library and mmu.library from OS3.2 copied into SYS:libs

I'm getting similar results to the original poster.

Using Amiga Test Kit I saw these:

Of course I came here and saw MBRtest-2, so I ran that and it freezes right here:

I've already pushed the latest firmware update to the ACA1234, so I can change clock speed.

Like above, I tried disabling features in the ACA500+, which didn't seem to help.

WorkBench 3.2 is booting fine, SYSinfo runs great, all the workbench basics seem fine.

What actually got me looking at the RAM in the first place was that WHDLoad was throwing random and frequent errors when I tried to play games.
I checked the 5V rail, 4.98V at the floppy drive, seemed good.

And then I ran to Amiga Test Kit to see if something else was wrong, got a bunch of errors.

And then I came here and saw this.

I've got a sort of 'temporary patch' that seems to be allowing me to use the ACA1234 without the built-in RAM.
I've used "SMARTBLOCK 40000000 47DFFFFF" early in my startup and now I can play most of the games in my WHDLoad library without constant Illegal Instruction and Bad Memory Errors dropping me out of the games.

blockmem11.lha

I'm glad to see this is already under investigation...

Quote from ljmarent

I'm glad to see this is already under investigation...

Yep, this is a hard one. I've stopped delivering ACA1234 for now, as it's happening in every configuration (A500 and A1200). Something is surely different from the pre-production units, but I haven't found a pattern yet.

Found it - and a final fix involves a CPLD update. In the meantime, Timm will make a temporary flash-update that will allocate memory that overlaps with memory in the trapdoor space.

What happened is a simple compiler error: The Xilinx tool just ignored one line of my source, which I found when checking the generated equations against my source. As a result, the $00c0.0000 trapdoor memory is located at the wrong spot of the 128M physical memory: $47c0.0000 instead of $47e0.0000.

Quote from ljmarent

I've got a sort of 'temporary patch' that seems to be allowing me to use the ACA1234 without the built-in RAM.
I've used "SMARTBLOCK 40000000 47DFFFFF" early in my startup and now I can play most of the games in my WHDLoad library without constant Illegal Instruction and Bad Memory Errors dropping me out of the games.

You can reduce that to blocking only $47c0.0000 to $47cf.ffff.

The plan for rolling out the CPLD update is to use the Amiga for this: The ACA1234 makes it easy to transfer software to the Amiga, so the update-tool is easily brought to the Amiga (after all, that part of the card works). Further, the card can be switched off and put into hibernation mode, where the CPLD is not required to keep the system running - so programming the CPLD with the 68000/68ec020 running is an option. We already have a cable that goes from Parallel port to JTAG (developed and produced for the very first batch of Buddha 20-year anniversary, back in 2018), which should be a halfway-convenient option for those who live in non-EU countries where shipping hardware back and forth is a major pain.

We will now develop a hotfix as a flash update that will allocate that offending 1M chunk of memory. Then we'll develop the CPLD update procedure and put all the information online. I will then contact all customers to ask how they prefer to do the update.

I sincerely apologize for this oversight - 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...

Flash update fixes crash/hang with MBRtest-2.

SMARTBLOCK 47C00000 47CFFFFF

In my Startup-sequence

Does indeed work exactly as well as the whole 40000000 47DFFFFF

And off I go to try the flash update

I removed the SMARTBLOCK from my Startup-sequence

Aca1234upd211117.lha applied

MBRtest-2 still locking up

Amiga Test Kit is 'working' now. I'm not getting thrown out on an error right after loading and pressing a couple menu buttons

If I try to run the Audio Test it plays music briefly and throws this error

(edit) Actually it will just crash like this on it's own if I wait long enough after booting into it.

WHDLoad works sort of.. subjectively..

Some games work fine, others still having trouble that seemed to go away with the full range blocked

I'm still getting Exception "Line 1111 Emulator"errors

Is it possible ? that there is more than one memory overlap ?
In an A500 machine with ACE2b and ACA500+ ?

(edit) Also noticed...
Before the latest firmware MBRTest-2 reported size 129024K

And now with the new firmware MBRTest-2 is still reporting 129024K
based on the loss of 1MB comment, I was assuming I'd see that 1MB removed from the total...
Of course I have no idea what exactly is being done by 'allocating' that 1MB chunk as described.

Quote from ljmarent

I'm still getting Exception "Line 1111 Emulator"errors

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

Quote from ljmarent

Is it possible ? that there is more than one memory overlap ?
In an A500 machine with ACE2b and ACA500+ ?

I doubt it. The overlap happened due to the wrong mapping of the 1MByte block for trapdoor memory. Chip ram access goes through a totally different interface. 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 ljmarent

Before the latest firmware MBRTest-2 reported size 129024K

And now with the new firmware MBRTest-2 is still reporting 129024K
based on the loss of 1MB comment, I was assuming I'd see that 1MB removed from the total...
Of course I have no idea what exactly is being done by 'allocating' that 1MB chunk as described.

The software update only allocates the offending 1MB memory space. What I believe MBRtest-2 is doing is that it remembers which chunk of memory it can allocate, and if it can't allocate it, it will run a different type of test that is non-destructive to the data. This is just an educated guess, though. I have no insight into what it's actually doing.

Same with AmiTestKit: I don't know if it's looking at allocated space, or if it just makes assumptions about the actual memory size. What I know is that the MBRtest-2 problems are gone with both CPLD versions (new and old) after the flash update has been installed.

We will still proceed to develop a method for the CPLD to be re-programmed by the machine that the ACA1234 is installed it. After all, the flash update will take away 1MByte of usable memory, so it's currently not what was promised in the product description. The CPLD update will change that.

THe tool is safe to be used on any setup that the ACA1234 works with.