Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Please understand that you need to create an account to be able to post, guest posting was disabled as an anti spam measure.
Those of you who experience the problems on ACA500plus, do you also have an A1200 to test the card with? I mean, MBRtest-2 failing at 0x4008.0000 is not chip ram, but fastmem, which is all within the card.
Unfortunately there's no A1200 in my cave, but I'll happily accept one as a gift 
On a serious note, I'll do some more tests with the ACA1234 downclocked to 25MHz. After that, the only thing left for me to check will be the CPLD update when my cable arrives, I guess.
I was in the basement lab, half storage half test gear on the walls reflected in the pictures,
. . .
My basement lab is allowed to be messy and crafty
That lab looks f***ing nice!!! Wow!
Those of you who experience the problems on ACA500plus, do you also have an A1200 to test the card with? I mean, MBRtest-2 failing at 0x4008.0000 is not chip ram, but fastmem, which is all within the card.
Yuck, no, just real Amiga 500's from before that silly AGA experiment near the end... 
Speculation:
The error messages may indeed be giving us some clues, but I don't believe they are painting the picture.
For instance, at the beginning, when I posted the errors I saw, you suggested I was trying to run software that needed FPU, but of course that was not the case. The error is real, but the cause is indirect.
Imagine if something is corrupting the stack, programs work for a bit, and then later the CPU has a return that transfers control to an address that it should not...could be data space...and we start executing all sorts of strange opcodes.
The address you end up at, executing whatever illegal instruction triggered a trap, does not provide much insight into what's corrupting the stack. The only thing that's useful is that the user saw an error.
I will of course continue to post the errors I get, I do hope that one of them will lead us to a solution.
I'm only 'suggesting' we accept the error is real, but the address and opcode information is meta.
I don't believe kot_behemot53 has applied the CPLD firmware update yet.
Please kot_behemot53 , correct if I'm wrong, I'm not trying to speak for you.
For me...the MBRTest-2 would not pass reliably until after the CPLD was updated through JTAG.
note (I had two random passes out of maybe a hundred attempts with different ACA500+ configs)
It always failed very early in the test, about 3 seconds after starting... near the 4000 0000 address
Once the CPLD was JTAG updated, MBRTest-2 passes reliably for me.
There are lots of A1200 machines in my community, if you can explain a little how this will help to get the ACA500+ & ACA1234 combo working, then perhaps I can beg or borrow an A1200 for testing.
I hope that cable arrives soon, so I can start testing on my A1200! 
Another small report: when the card is downclocked to 25 MHz (using acatool), games seem to be working alright (including Supremacy & Unreal).
The diagnostic software still fails though. Interestingly, looks like it now fails slightly further on in the address pool: MBRTest-2 freezes at 400a0000 - 400affff (consistently), instead of 40080000 - 4008ffff. AmigaTestKit dies at less consistent spots, but seemingly also a bit later than at 33 MHz. As a reminder: I still don't have the CPLD update, just the firmware patch.
Cheers!
I don't expect AmiTestKit to work without the CPLD update.
The freeze at a lower Fastmem address is something I haven't been able to reproduce. However, I'd like to, so I can look at it on the logic analyzer. Can you try to make an absolutely clean test environment, maybe even boot from a floppy, so cache/burst settings are known to not be altered by any software?
Can you try to make an absolutely clean test environment, maybe even boot from a floppy, so cache/burst settings are known to not be altered by any software?
I can try. I'll boot WB 3.1 from floppy and use Kickstart 3.1. Should I set any specific settings in the ACA500Plus menu? Or do anything else?
Should I set any specific settings in the ACA500Plus menu? Or do anything else?
What I'll do is to reset to factory defaults, which will bring our systems in line with each other - if you do the same, of course. Launch with F1, the "full config" for 3.1.
What I'll do is to reset to factory defaults, which will bring our systems in line with each other - if you do the same, of course. Launch with F1, the "full config" for 3.1.
OK, will do the reset and launch with F1 config. Will come back with a report!
Hello all!
I did the CPLD-Update on my A1200 right now.
When the update was done I left the onboard-IDE active, because I thought "Perhaps I want to use it ... shouldn't make problems ..." ...
But when I started "MBRTest-2" I had a freeze again! Bummer!
But when I disabled the onboard-IDE everything went fine ... the RAM-Test was completed and everything seems okay.
So the issue is somehow regarding to the active onboard-IDE, at least with my Setup. OS 3.2 ...
BTW ... T-Zero is still not running ...
Back with a new report.
I did a factory reset of the ACA500Plus and ran it with the standard 3.1 config (F1) booting from a WB 3.1 disk.
With this config, MBRTest-2 ran correctly both at 25 MHz and 33 MHz, although after switching to 33 MHz MBRTest-2 failed twice on startup (before even running the test), but then I could not reproduce it - it ran fine again and I didn't take a picture of the error message... :-/
Then I decided to go back to the F10 menu, take the default Profile #1 from there, just switch the Kickstart to 3.1.4.
I ran the test and this worked too (I was still using WB 3.1 from floppy, just a different Kickstart to see if this maybe breaks something).
However, as soon as I added WB 3.1.4 to the mix (which I normally use) the freezes returned both at 33 MHz and 25 MHz (talking about bare 3.1.4 booted from floppy, not my HDD install). It's worth noting, that I noticed that in the F10 Profile the "MMUlib" option was set to "Automatic". With this config the MMU library was NOT used by WB 3.1, but was used by WB 3.1.4 (according to SysInfo).
Then I switched MMUlib in the menu to "Off" and retried with WB 3.1.4. This time the MBRTest-2 worked again (both at 25 MHz and 33 MHz). It perplexed me a bit, because I would swear that I already tried switching MMUlib in my original profile to "Off" and it didn't help.
So at this point I decided to try my HDD WB 3.1.4 install again, with MMUlib set to "Off". I checked SysInfo first, and it showed that mmu.library was loaded nevertheless and MMU was in use. Not surprisingly, MBRTest-2 froze. This probably explains why my previous tests, with setting MMUlib to "Off" in the profile, didn't make any difference (because my HDD install used mmu.library anyway).
So, as a final step, I decided to forcefully move mmu.library out of the Libs directory and see if this changes anything. To be able to boot my HDD WB 3.1.4 install at all, I had to move the 68030.library too (it wasn't loaded during the successful WB 3.1/3.1.4 tests anyway) and remove a bunch of things from startup-sequence. When it finally ran like this, MBRTest-2 passed indeed.
So to sum up: apart from 2 random failures at 33 MHz, MBR-Test2 seems to work as long as mmu.library & 68030.library aren't used by the OS. CPU clock speed, Kickstart version, WB version, or other factors don't seem to affect it (at least when we're talking just about the diagnostic software, not games). It still doesn't seem that running the OS without essential libraries is a good idea, but I hope this report will give you some leads.
EDIT: after all that, I reran the test with mmu.library & 68030.library back in the Libs directory, but with startup-sequence still modified (with the modifications I had to make to run the OS without the libraries) to rule out that it was the startup-sequence modification, not libs removal that "fixed" the test. And, as expected, the test froze.
EDIT2: I think, I managed to reproduce the "random error" on MBRTest-2 startup. See the attached screenshot (I'm not 100% sure that the error message was the same previously).
I'm going to bed, cheers!
Thanks for the detailed reports. I hope to find a common demoninator here - MMU appears to be a major contributor, but the report about internal IDE playing a role makes me wonder if the internal IDE holds MMU libraries for that setup?
kot_behemot53 and OMo1972 would you please mention your warranty ID here? I'd like to take a look at the CPU mask that your cards have.
kot_behemot53 and OMo1972 would you please mention your warranty ID here? I'd like to take a look at the CPU mask that your cards have.
CPU 33 MHz F91C ceramic, WARRANTY LT8Qj
Jens is probably well aware of this, but sometimes users aren't always aware of SetPatch's behavior in different versions of the OS (below is only within the context of 68030's and MuLibs - other CPUs differ):
- SetPatch in all 3.x versions will turn on the 68030 data cache by default without any CPU library present.
- SetPatch <= 3.1 does not load any MuLibs CPU library components unless manually patched for the MuLibs environment.
- A patched Setpatch, when called, then tries to load 680x0.library, which will trigger a 68030.library load.
- The CPU library load will also check ENVARC:mmu-configuration for specific options and user-defined environment settings
Your installation of MuLibs may have/may not have set the mmu-configuraton file in ENVARC: to certain ACA-friendly settings depending on your installation answers. This may be important information.
The mmu.library is called presumably only when some aspect of the MMU configuration table is read or modified by an mmu.library-aware tool. I don't believe it's needed at the library load time, but will be later if you use an MuLibs-aware tool.
I'm going to suggest getting the output of the MMU settings by using the MuSCAN tool. They may indicate an unexpected setup that Jens might spot.
I will check all of this later when I'm home from work (about 18:00) ... thanks for the information thebajaguy . I also will then post the warranty ID, Jens !
The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.
