ACA1260 issue on heavy PCMCIA loads (?)

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.

    Hello,


    I am so far very happy with my ACA1240 and I am looking forward to the upcoming firwmare. However, I noticed that on heavy or long usage of the PCMCIA devices (Ethernet card or SCSI devices through a SurfSquirrel) stall/stop working. It means the LAN communication fails or the SCSI disk is not accessible anymore.


    A good way to trigger the issue is to do a "CheckDisk squirrelscsi.device 1". It stalls in seconds usually.

    https://aminet.net/package/disk/misc/CheckDisk


    For testing, I put back my simple RAM expansion instead of the ACA1240 and it works stable.


    While I am fully aware it could work only because the original CPU from the A1200 is slow compared to the fast 040, is anyone experiencing that with the ACA1240/60 too?


    System: A1200 2B recapped.

    • Galye fix (but without the issue is the same).
    • Try to diffrent IDE/CF adapter, same. Also the adapter from icomp.
    • Indivision AGA mk3
    • Lyra v3



    Regards

    With Indivision and the ACA1240, power load is significantly higher than with a simple RAM expansion. What power supply are you using`


    Jens

    Quote from Jens

    With Indivision and the ACA1240, power load is significantly higher than with a simple RAM expansion. What power supply are you using`


    Jens

    I am using the CA-PSU from iComp.


    I made some more tests (SysInfo / Disk) as well as running the system on an SCSI Disk now, and the PCMCIA is rock solid using theRAM expansion. Of course, the system is now pretty slow compared to the ACA1240.


    Regards

    Nico

    Is this also happening on a CF card adapter? I'm not a fan of Squirre - I've looked at it when I wanted to make a PCMCIA card myself, but decided not to take any idea of that contraption, as there's no shielding at all, not even on the cable. I'd actually expect it to fail on higher data rates.


    So please test with things that are built to PCMCIA-spec, such as a CF card adapter that comes with a metal casing for the PCMCIA card. That will surely be something we can reproduce here, and if we can reproduce a fault, we actually have a chance of fixing it.


    Jens

    Hi Jens,


    Thanks for your reply. With the ACA1240:


    • CF: on CheckDisk compactflash.device 0, the system is rock solid. I stopped the test after 2 hours continuous reading.
    • PCMCIA Ethernet "dies" after a few seconds "AmiTestSpeed" where as the PicoWyfyis solid. I also have random "stalls" of the PCMCIA Ethernet just while streaming. The PCMCIA is a 3c589 chip with Roadshow latest version and latest driver from Aminet.

    PS: I did not stress the PCMCIA Ethernet with the RAM Expansion yet. I tried to avoid install/uninstall expansion card too much.


    Can you reproduce the issue through the PCMCIA Ethernet?


    I have not glue what is happening... It would be nice to get it working as I like to play around with different installation so the EZ135 is extremely practical in this regards.


    Regards

    Nicolas Det

    Quote from NicoPPC

    Can you reproduce the issue through the PCMCIA Ethernet?

    No - I'm using Ethernet all the time, and there is no change when I use one or the other accelerator. I tend to use the faster ones, as I'm impatient - so ACA1260 it is, most of the time.


    Is there anything on the clock port, either the ACA1240/1260 or the A1200-internal clock port?


    Jens

    Yes, there is some ClockPort devices:


    • on the ACA1240, the clock (from iComp)
    • on the motherboard, the Amiblaster CP
    • on the Gayle Adapter, the PicoWify

    I tried to removed the Gayle Adapter, but there was no difference.

    The Amiblaster CP is connected but inactive when the issue happens.


    Regards

    Nico

    Quote from NicoPPC

    The Amiblaster CP is connected but inactive when the issue happens.

    It is still electrically active on the data and address lines. Please remove that for a test. Note that PCICIA, IDE and clock port share the same, unbuffered address and data lines, so anything on those ports can cause cross-effects.


    Jens

    I removed the Gayle Adapter (also hosting the PicoWyfy) and the AmiBlaster. Only the RTC on the ACA1240 remains


    Unfortunately, I still loss the PCMCIA Ethernet on AmiSpeedTest (+ ping router_ip).


    Should I also removed the RTC? Might the issue be related to some weird timing of the 040 at 33Mhz ?


    PS: I always try to "touch" as few as possible this old hardware :saint:


    Thanks for you support and help!

    Quote from NicoPPC

    Should I also removed the RTC? Might the issue be related to some weird timing of the 040 at 33Mhz ?

    That's an easy thing to test, yes. Another easy thing to test is to change the CPU frequency - although the main A1200 interface is always running at 100MHz, there is of course the challenge of moving data from one clock domain to another. I'll have to test with 040@33MHz myself.


    Jens

    Ok. Testing without RTC.


    The SCSI Device stalls after a few seconds on CheckDisk but Ethernet looks fine now: AmiSpeedTest went fine and I am now listening Radio Paralax. I will keep streaming the whole day and see if it works fine.


    I understood you were not "happy" with the SquirrelSCSI design but it might trigger that clocking issue (?). I would be interesting to test that using a Blizzard 1260. Unfortunately I don't have any here.


    Cheers

    We have a pending issue with the 040/40MHz core, which might affect33MHz and possibly 25MHz operation as well. I'll write this on the list of things to check when we tackle the 040 timings again.


    Now that removing the RTC makes a difference, I'd like to know if you are using the IDE speeder?


    Jens

    Ok. Looking forward to the new firmware.


    Quote


    Now that removing the RTC makes a difference, I'd like to know if you are using the IDE speeder?


    Yes, "ACA1260tool piomode=4 maprom >NIL:" is in the User-Startup.


    PS: Still streaming without issue


    Nico

    Well, it's harder to trigger the issue with PIO=MODE 0 (removed from the Startup).


    Now, CheckDisk have hard time to trigger it (it takes at least >3000 sectors instead of a 300-400 before). However, SysInfo just stalls on disk benchmark.


    I hope it helps 🙏. Let me know if I can try anything else.



    Nico

    Is your main board PAL or NTSC-clocked? I'm asking for the exact crystal frequency. Also, do you have a possibility to try a different A1200 board, or at least run it from a different base clock source, for example by using iComp's first-ever product, the Graffiti video card?


    Jens

    Thanks, that's a genuine PAL board. NTSC boards are clocked at 28.63636MHz.


    However, your picture reveals another detail: There's EPROMs in your Kickstart sockets, which may have a higher capacitive load on the address and data bus. Since capacitive load is exactly what we're looking for here, I'd like to get the exact specification of the EPROMs you've used.


    Jens

    That's an 8MBit ROM. Did you program the contents on your own? Did you make sure to program the required mirrors? Also, the programming algorithm plays a role for overall stability of UV-erasable parts. Usually, it's "the slower, the better". The "quick" algos are often not implemented properly on China-programmers, so re-programming several times might help. If you've done that yourself, please re-do it, just to exclude flaky behaviour. Note that the MapROM function won't do a "verify" of the copied contents in RAM, because it assumes that the ROM is always correct - which might not be the case here.


    In any case, these are non-standard-enough to try stability with the original ROMs. Something in your setup is surely funky if the capacitive load of the RTC module (which is negligible) has an influence. I don't have a clue if we should start looking at address or at data lines, but I'd actually start on data lines in the upper bus half, just because there's more overlap with the RTC module, which uses 4 bits of the upper-odd addresses of a longword.


    Since your accelerator has an MMU, you should be abl to launch your 3.2 workbench without new ROMs.


    Jens