ACA1234 issue on a1200

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.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Hi there

    Just bought an ACA1234 for my a1200 2B rev,just an great piece of hardware!


    Since i havent used it for almost 20 years,after new parts(gotek,New ssd drive and brand new wb installation,psu and recaps),i decided to try one of my all time favorite demo,nexus 7 by Andromeda.


    Well,got somes bugs on it. Artefacts on texts(blink),Really slow at 3d objects(really slow),demo totally desynchronized....etc...


    Booting with no card(stock amiga 1200),it runs correctly and faster.


    Any idea?

    Cheers,

  • That is a known issue - the demo seems very sensitive on chipram timing. Generally for demos the advice is to run them on the platform they were made for :) ie: disable the turbo card

  • thanks tobias for your answer.

    -

    What you say doesnt enjoy me at all,the last accelerator card i owned(20 years ago) was an 68060 at 50mhz and everything was working fine on it

    Specially for demos with 3d stuffs on it,an better and faster processor make it more enjoyable to watch 😉

  • I tried Nexus 7 with my A1200 2B + ACA1233 (non 'n' version) the red one. I had some slowdowns where that disco ball or whatever it is was spinning. So I think this is probably normal when using accelerators. At least for this demo. Probably some others aswell

  • I tried Nexus 7 with my A1200 2B + ACA1233 (non 'n' version) the red one. I had some slowdowns where that disco ball or whatever it is was spinning. So I think this is probably normal when using accelerators. At least for this demo. Probably some others aswell

    Its not normal my friend,others accelerators card doesnt have this issue !

    and its not this demo only,somes others too.

    If it got slowdown on demos,what about games or others softwares which can’t be visible...

  • Its not normal my friend,others accelerators card doesnt have this issue !

    And these "other accelerators" achieve this by the dirty trick of enabling instruction cache on chip ram. However, there is no means on the Amiga and on the 68030 CPU to invalidate the cache when a DMA is ahppening to cached areas.


    This working for older demos does not mean it's correct. It's a dirty hack that is just asking for trouble. Not the iComp method.


    If it got slowdown on demos,what about games or others softwares which can’t be visible...

    WHDload games are usually patched to work with accelerators. If you want to deviate from the original rules from the demo party that the specific demo was released at, just patch it to move code to fastmem. Or just go by the original rules and view it on a plain A1200, which it was designed for. I will not deliberately make the card worse, just because someone makes a request for it.

  • i didnt asked to make it worst as you say,and even less because im asking something i dont know,its just that i wanted to know by my poor knownedge in amiga hardware,why this happened as long i remember it was working 😉

    Thanks for your work and explanations

  • Clearly I don’t know all the details, but this sounds like a situation where we could ask WHDLoad with a tool type to send the ACA1234 a control bit to enable the dirty trick. Then when the game is over WHDLoad sends a control bit back to play fair mode 😀


    Perhaps we can’t do this on the fly 😔

  • There's no space left in the CPLD for an additional option bit. Also, I explained why it's not a good idea to enable caches in chip ram. I'm not a fan of introducing known-bad practises, especially not when there are better ways to make this software work:


    - use the originally-intended config (=CPUoff option of ACA1234)

    - place code in fastmem (=create a WHDload version of Nexus7 that moves the code to cache-able fastmem)

  • I received my ACA1234 about 2 days ago as it lay in limbo for 3 weeks with the postal carriers. I immediately received the CPLD email, installed the ACATool and the patch. Over the next two days I was so impressed with the card that I wrote a semi-review (in the states, the use of "semi" means half-assed).


    Once I transferred all my files to the onboard CF card, I turned off the Amiga's IDE interfaced and noticed that the ACA's onboard green LED activity light was unhelpful with the case closed; locating it on the edge of the card at "D1," I wondered if there was a way to bring the activity lines externally -- i.e., track the CF card activity for life vs death. I could solder wires to either side of the LED (thus voiding my warranty), but wondered what the developers thought of my minor issue and any other solution before I even considered such a heinous crime.

  • I like to use photo transistors to pick up the iComp LEDs and run their wires into the case. Soldering to the board is easy, but if you want to move it, you need connectors and you open yourself up to questions for warrantee ,,, the non contact photo transistors just work and no one needs to know anything.

  • DanBeaver Do you want to enable the A1200-HD-LED when ACA1234 is acccessing the CD-card?

    Commodore: A1200/1B, ACA1234/50/68882, Indi AGA MK3, Gotek, OS3.2.1 | A1200/1D.1, ACA1221lc/26,67, OS3.1 | A500/6a, ACA500+, Indi ECS V3, OS3.1 | A500/8A, Vampire v2+, Indi ECS V2, A2048, Gotek, OS3.9| A500/5, 512kB Trap, sealed, Kick 1.2 | 2×C64C, U II+, Turbo Chameleon V2, 2×1541II, Datassette | 1084S-CRT ······· Atari: Falcon030 | 1040STE | 800XL

  • I like to use photo transistors to pick up the iComp LEDs and run their wires into the case. Soldering to the board is easy, but if you want to move it, you need connectors and you open yourself up to questions for warrantee ,,, the non contact photo transistors just work and no one needs to know anything.

    The photo resistors are a solution, just a bit more complicated than I had hoped.

  • Then you have to connect the left contact of R12 (the side with the "R12"-labeling) on ACA1234 with pin 39 of the onboard-IDE of the A1200.

    Commodore: A1200/1B, ACA1234/50/68882, Indi AGA MK3, Gotek, OS3.2.1 | A1200/1D.1, ACA1221lc/26,67, OS3.1 | A500/6a, ACA500+, Indi ECS V3, OS3.1 | A500/8A, Vampire v2+, Indi ECS V2, A2048, Gotek, OS3.9| A500/5, 512kB Trap, sealed, Kick 1.2 | 2×C64C, U II+, Turbo Chameleon V2, 2×1541II, Datassette | 1084S-CRT ······· Atari: Falcon030 | 1040STE | 800XL

  • Commodore: A1200/1B, ACA1234/50/68882, Indi AGA MK3, Gotek, OS3.2.1 | A1200/1D.1, ACA1221lc/26,67, OS3.1 | A500/6a, ACA500+, Indi ECS V3, OS3.1 | A500/8A, Vampire v2+, Indi ECS V2, A2048, Gotek, OS3.9| A500/5, 512kB Trap, sealed, Kick 1.2 | 2×C64C, U II+, Turbo Chameleon V2, 2×1541II, Datassette | 1084S-CRT ······· Atari: Falcon030 | 1040STE | 800XL

  • Its not normal my friend,others accelerators card doesnt have this issue !

    and its not this demo only,somes others too.

    If it got slowdown on demos,what about games or others softwares which can’t be visible...

    I seem to remember most whdload demos I tried ran fine on my ACA1233/A1200 2B combo. There is probably a few, like Nexus 7 that has problems then. As for games, my setup seems to have no trouble with any whdload games I've tried. However, when you pair 020/030 accelerators with A500 or A600 then you get slowdowns in some whdload games. Due to the 16bit bus on A500/A600 causing some kind of asynchronous wait state or something when combined with 24/32bit accelerators. In many cases that can be fixed by using 'Cache' in Tool Types. But sometimes that can lead to artifacts or other unwanted behaviour.


    The A1200 with it's 32bit bus is very compatible with whdload games when using an accelerator like ACA1233. I assume the same goes for the ACA1234. whdload was originally made for A1200/A4000 so no surprise there really.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.