Acatool MAPROM breaks when setpatch is called

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.
  • I have a ACA1233n-new/55


    I played around with ACAtool setting up various items. All work fine, except for the MAPROM feature. I found that MAPROM will work fine if the "setpatch quiet" line is commented out in startup-sequence. When I add the line back, the Amiga will crash at bootup. Also, when not using maprom in the startup sequence but starting it manually from the Shell, the Amiga will freeze immediately. Therefore it seems there is some incompatibility with setpatch and acatool. I could of course choose to not use setpatch, but that makes workbench colors drop to 16 maximum, and generally setpatch is probably there for a reason.


    If I don't map the ROM, some other weird things happen like SysInfo not reading disk speed. So I would like to use both...


    Short:

    Acatool maprom + setpatch quiet = crash

    Just Acatool maprom and no setpatch = fine, but I lose functionality


    I have installed the latest ACAtool (2.1) and the latest 1233n library from the Wiki. The OS is 3.1.4 with 3.1.4.1 update with BestWB on top. ROM version is 3.1.4.


    I'm fairly new to Amiga so maybe there's something I am overlooking... any help is appreciated!


    Update: I have done a fresh install of WB 3.1.4 with no updates, no bestWB, no MuTools, no ACA1233n library, just WB 3.1.4 and acatools 2.1. MAPROM still will not work. I am really lost at this point. Seems like MAPROM just does not work with setpach, period.

  • the latest 1233n library

    ...is not required any more. The ACAtool replaces that completely. That should not cause any trouble, though.


    Does the 55MHz card have the hardware patch with the separate regulator for the oscillator? That's a rather big part near the top-right of the card. We've been shipping the cards with that patch since fall of 2019, so if you can't take a picture, you can just let us know when you've bought the card or the warranty ID.


    Also, it's very important what type of power supply you use - please let us know.

  • ...is not required any more. The ACAtool replaces that completely. That should not cause any trouble, though.


    Does the 55MHz card have the hardware patch with the separate regulator for the oscillator? That's a rather big part near the top-right of the card. We've been shipping the cards with that patch since fall of 2019, so if you can't take a picture, you can just let us know when you've bought the card or the warranty ID.


    Also, it's very important what type of power supply you use - please let us know.

    Hi Jens, thanks for your reply!


    The card has been purchased from yourselves a couple of weeks ago (order ID 73205), so it should have the hardware patches. If you like I can make pictures no problem. I did not make any modifications to the card like install an FPU.


    Good to know that the ACAtool now replaces the aca1233lib completely. Can/should I still install MMUlib, can you recommend anything there?


    The power supply is an original A500 PSU, the "light" 4,5A version. Not recapped. I have all the parts laying around for a little project to modify a Be Quiet ATX PSU to Amiga PSU, I could speed up that project if that helps the troubleshooting, and if you recommend to use an ATX PSU?

  • Can/should I still install MMUlib, can you recommend anything there?

    While "ACAinit" blocks access to the ACA's registers, I recommend not to use the mmu library.

    The power supply is an original A500 PSU, the "light" 4,5A version. Not recapped.

    You should do that re-cap some time soon.


    and if you recommend to use an ATX PSU?

    Not at all. ATX PSUs mostly have the 12V rail as their main regulation rail, and that's mostly unloaded on the Amiga. As a result, the 5V rail (which is required to be regulated in tight limits) will wobble around and potentially take the 3.3V regulators on modern hardware into oscillation, which leads to severe defects on modern hardware.


    Further, most ATX PSUs are way too powerful, mostly well-over 200W. An A1200 with accelerator consumes less than 25W, so you should not go beyond 60W max for an A1200 PSU.

  • Thanks for the information! I will not be using an ATX PSU then, instead recapping the original PSU.


    In the meantime, I found out something interesting; it boots with MAPROM and setpatch when the PCMCIA card (CF transfer kit) is removed... it does do a soft reboot automatically at cold boot, not sure if that is intended. If I plug in the PCMCIA card afterwards, it works absolutely fine, but whenever it's been plugged in the system gets unstable. Does that make sense?


    So one: does it make sense that the PCMCIA adapter makes it not boot with maprom

    And two: does the automatic reboot from cold start make sense? I thought I read somewhere that it should no longer do that.

  • but whenever it's been plugged in the system gets unstable. Does that make sense?

    Sounds like the typical "PSU does not have cable drop compensation" problem.



    And two: does the automatic reboot from cold start make sense? I thought I read somewhere that it should no longer do that.

    It depends on what you're doing in terms of MapROM: If it's from a file, you get a reboot, but if it's from ROM, the latest version of ACAtool should not do a reboot any more. Timm can give you the details - I've only put this on his todo-list :-)

  • Sounds like the typical "PSU does not have cable drop compensation" problem.



    It depends on what you're doing in terms of MapROM: If it's from a file, you get a reboot, but if it's from ROM, the latest version of ACAtool should not do a reboot any more. Timm can give you the details - I've only put this on his todo-list :-)


    Ok, is this "cable drop compensation" something that I can fix? Or should I get a better/newer PSU in which case; which would you recommend?


    About the reboot, I am loading it from ROM so it should not reboot? I just ticked "maprom" and did not selected any ROM file. Also in the startup-sequence it just calls "acatool maprom"

  • Ok, is this "cable drop compensation" something that I can fix?

    Not easily, no. It's something that only a single type of Amiga PSU had, and that was an old 2.5A type.


    Or should I get a better/newer PSU in which case; which would you recommend?

    I'm working on one that will go into production later this month. It's DC-DC converter based and regulates the 5V down to a precision of better then 20mV over a range of 0-6A load, measured *inside* the Amiga. That's a "first" in the Amiga market.


    About the reboot, I am loading it from ROM so it should not reboot?

    Right, it shouldn't. Please check if you really have the latest version of ACAtool installed. And of course wait for Timm to answer here, as he knows if/when the reboot has been removed.

  • Version is

    The reboot on MAPROM has been removed since version 2.1.


    I'm pretty sure it does reboot with Acatool 2.1... this is from cold boot. It will boot, screen stays black, power led dims for a bit, then it boots again. Booting from cold also takes considerably longer.

  • All in all I can't get the system reliable using Acatools. MAPROM just won't work reliably no matter what I try. I will probably wait for a good power adapter first, then test further from that point onwards. I hope this new PSU you're working on will be out soon :-)

  • Hi people. I just bought from you directly an aca1221lc. I use the latest acatool 2.1 and have the same problem described above.


    Acatool maprom + setpatch quiet = crash

    Just Acatool maprom and no setpatch = fine, but I lose functionality.


    Also the same happens to me

    I'm pretty sure it does reboot with Acatool 2.1... this is from cold boot. It will boot, screen stays black, power led dims for a bit, then it boots again. Booting from cold also takes considerably longer.


    I'm new to this with not much of experience.

  • If you boot OS3.1.4 and do not have a 3.1.4 ROM, then MapROM in ACATool is pointless.

    The reset is then caused by C:LoadModule ROMUPDATE from the OS3.1.4 startup procedure.

    You can choose which one does the reset; it's either ACATool 2.1 (when an OS3.1.4 ROM file is specified), or the 3.1.4 startup procedure.

  • Is this also with OS3.1.4, or some other version?


    If you boot OS3.1.4 and do not have a 3.1.4 ROM, then MapROM in ACATool is pointless.

    The reset is then caused by C:LoadModule ROMUPDATE from the OS3.1.4 startup procedure.

    You can choose which one does the reset; it's either ACATool 2.1 (when an OS3.1.4 ROM file is specified), or the 3.1.4 startup procedure.

    Hi Timm, thank you for your reply and explanation. I did still have a reset w/o MAPROM, this is indeed caused by loadModule ROMUPDATE which is, if I understand correctly, pointless if ROMs 3.1.4 are already installed. I commented out c:loadmodule romupdate and now the reboot is indeed gone.


    For the rest I am right now using MUFASTROM as that gives me also some improvement over no ROM mapping at all. I will try Acatool MAPROM again when I have a better PSU, since right now Acatool MAPROM makes the system unstable.

  • I'd rather not remove the line from the startup-sequence. If the ROM is 3.1.4 and the OS installation is 3.1.4.1, then it may still make sense (for OS3.1.4.1) that ROM updates are being installed.

    What's pointless is to map the ROM into fastmem when it's being mapped again immediately thereafter.

    If you were running OS3.1.4 without a 3.1.4 ROM, it can make sense to use ACATool to load and map the 3.1.4 ROM file. But if it's immediately mapped again in the startup procedure, this task is better left to the OS3.1.4.x.

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