Posts by ljmarent

"I have started with the ACA500 plus connected in conjunction with the ACA 1234."

Just a thought..

But the ACA500+ & ACA1234 combo is still causing a lot of software to not run properly, especially when the CPLD patch is not applied and the ACA1234 is not in safe mode.

If you start with these two cards connected and try to perform the ACA500+ firmware update...

I'd be worried the updater might also be affected by the aforementioned issues...

I'd certainly not recommend updating the ACA500+ with the ACA1234 installed, until iComp has tested that specific config and found it safe

Okay...

I reset WHDLoad.prefs to stock settings and rebooted

Agony no longer crashes. but it's not playable either

It's works fine with just the ACA500+

But once you put the ACA1234 (safe mode) into the system there is all sorts of weirdness...

Also... Xenophobe is behaving like Agony ... the intro and logo's work, but once the 'game' starts the video is unusable until you die and then the menus come back and it works.. Maybe there will be WHDLoad settings that sort that..

anyway..there is a definite interaction between the ACA1234 firmware and WHDLoad as well as Amiga Test Kit
Disabling the ACA1234 firmware stops the crazy error messages and invalid instruction stuff

Okay..some good news

With the JP0 jumper in the 25MHz Safe position (edge of card position)
Supremacy and Unreal now work without causing errors in the first 60 seconds

I can actually play the games YAY!

Agony does not crash, but the game doesn't work right and the graphics once you get to the start...
Oh...let me check.. I was tinkering with that games tool types ...let me reset that one..
I'll come back in a moment...

Okay, so you are suggesting I put the JP0 in the 25 MHz safe position and test again ?

Quote from Jens

Not completely "the same"

Well ,,, from my perspective it’s exactly the same.
I take the CF card out that I built for my Checkmate ACA500+ & ACA1234 rig and put it into the TF536 rig… it’s the same card… untouched…

Perhaps I don’t understand what you mean.

How do I deactivate ACA1234 features ?

Last time I ran the ACAtool for this card, all I could change was clock speed, everything else was greyed out ?

and does the ACA1234 load software ?

I thought only the ACA500+ was doing that and the ACA1234 was just providing CPU and DRAM in my setup … but now I’m totally interested in what is happening between these two iComp cards in my setup.

Great, you go and make it ‘easy’ after the NOOB! (Me) uses it.

Quote from Jens

That appears consistent, yes. May I ask what type of "other 50MHz 68030 accel" that is, and what the exact config of that board is?

When I first noticed issues with my ACA1234 (17th), I asked Alan to send me a TF536, we live fairly close by one another (Toronto - Montreal)

I just got it, and plugged it in yesterday (23rd), I don't think it has settings ... none that I know of... I should probably look into that... I figured it just did it's thing without input from me...

Anyway.

Here is the test setup where all my WHDLoad games are working.

- A500 rev 5
- Indivision ECS v2

- ACE2b
- ROM adapter and KS3.2

- TF536

- Commodore Amiga Keyboard and Mouse

That accelerator also works in my CheckMate Amiga. (I did not think to shoot a photo)

notes:

I built my 4GB flash CF install myself..using the ACA500+, OS3.2 install files, a bunch of update files from iComp and and AmiNet downloads.

The TF536 is new to the house and should leave soon, I don't think anything in my software config is more friendly to the other accelerator. I've made zero changes to help or assist it. It's running the exact same CF card and software load as my ACA500+

Okay.. couldn't sleep with this one last thing hanging in my mind...

Everything I've done with the ACA500+ & ACA1234 combo has been in my CheckMate...
So..

I pulled the ACA500+ & ACA1234 out of my Checkmate,

Installed them into the A500 motherboard sitting on my desk, 'per the recommended manner'.
I slid the lower shield and insulator under the motherboard and attached using M3x5 screws and nuts
Plugged in my stock Commodore Amiga PSU, keyboard & mouse

Fired it up...

Agony crashed seconds after loading same error as in the CheckMate Amiga.

So... the problem follows the ACA500+ & ACA1234 card pair... even to a second motherboard... even when plugged into the side with no Zorro II card... even with stock PSU, Keyboard and mouse.

Final data point for the evening, I need to rest too

I pulled the ACA500+ and ACA1234 out and popped a different 68030 50MHz accelerator into my computer.

AND...All of my WHDLoad games work.

I even tried my backup machine with the 'other' accelerator.
Mean Well RT-50B PSU, No shielding, sitting on a wooden table
All of my WHDLoad games work....

Did not make me a better player...but Agony plays just fine

So does Supremacy

I didn't find one that didn't work...

I think I can rule out that:

- WHDLoad doesn't work with 68030 as it is setup.

- The games might have been corrupt.

- My setup of the games could have been wrong.

ACA500+ & ACA1234 setup:

After testing Agony, Supremacy and Unreal under WHDLoad
They seem to work just fine with the ACA500+ alone

However, once I plug in the ACA1234 they crash will all sorts of errors.

Other games like...
Gods, Shadow of the Beast and Golden Axe work just fine under the ACA500+ alone or the ACA500+ & ACA1234 combo

Once people get their CPLD patched,

I'd love to know if this is a me only problem, or maybe an ACA500+ config setting I've missed, or what have you.

Under Agony for instance I get errors, just after launching,
With the MMU switched off
I pretty consistently get:

And when I switch the MMU on
I very consistently get:

Under Supremacy the intro plays, just letting the intro run,

With the MMU switched off

I get:

And when I switch the MMU on

I get:

Non WHDLoad software:
- DPaint works
- PPaint works
- AMOS works
- HippoPlayer plays MODs great

- Amiga Test Kit still crashes with the ACA1234 installed, but it's fine with just the ACA500+

I imagine it will be a while for others to get their CPLD patched...
I best take up knitting

Fortunately, I keep these Weidmuller wire strippers and Wera hand tools around for when I've gotta fix German stuff...

And...lets see if my carefully calibrated JTAG tension finger is up to the task...

Looks good so far...

I better take that SMARTBLOCK command out of my startup-sequence....

Now... let's see the RAM test...

Yup that passes now...

My IKEA cables order just arrived

Please enjoy your family and your weekend better to have you sharp on Monday

I'm not condoning it... But if you do sneak into the office...

I happen to have the parts to make this cable on hand.

http://wiki.icomp.de/wiki/Budd…your_own_programmer_cable

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.

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.

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....

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

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 ?

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.

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