ACA1234 - ROMFILE

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! Got a problem loading a rom file with this command line:

    ACATOOL ROMFILE <full path to kickstart.rom>


    No matter what rom image I use I get checksum error. I even used ImageMount to get the kicka1200.rom off the AmigaOS3.2CD (I ripped physical CD to get complete image to Amiga HD for installation) - same error. Strangely, this file was flashed ok using the acatool GUI and is mapped fine, but no luck with the command line. :(


    In fact, after I mapped the kickstart 3.2 rom via GUI I've got a problem of switching maprom function off. My current OS is still 3.0 and it doesn't load with the mapped kickstart 3.2 - complains on icons.library and workbench.library. I managed to copy these files off the OS3.2CD image to the LIBS drawer, icons.library seems to be accepted fine, but the system keeps asking for the workbench.library. Well, I guess it was stupid to maprom kickstart 3.2 with WB3.0, but according to OS3.2 manual installation requires kickstart 3.1, 3.1.4 or 3.2.


    I tried to downgrade kickstart with the ACATOOL ROMFILE, but neither 3.0 nor 3.1 roms are accepted - bad checksum. I thought maybe it gets wrong while I transfer the files to Amiga via windows formated CF in PCMCIA slot, then tried to use the file I flashed previously (3.2) - and see the same error. Thus it looks like ACTOOL ROMILE command is not working :(


    I guess there is no way to switch maprom function off via commandline?

    Oh, I suspect the checksum problem might be caused by the OS3.0 copy command :( as noted here and perhaps it didn't reveal itself when flashing the ROM in the Acatool GUI, because at that time I pointed to the file directly in the OS3.2 CD image.

    Thanks, Jens! I deemed the jumper as the last resort :) I'll try to lha the kickstart files from PCMCIA CF and CD image to the internal IDE-CF instead of using OS 3.0 copy command - perhaps this would allow to defeat the chesksum problem and let me downgrade KS via comand line.


    Still I can't find any explanation of the /S, /K, /N switches in the command line syntax. Perhaps I just misuse it.


    So far I only have 2 modes on my Amiga available:

    1. Mapped OS3.2 kickstart with safeboot and no startup-sequence - loads to the CLI and lets me copy files, and turn ACA1234 off (CPUOFF). PCMCIA CF not available, but internal IDE-CF and ACA-CF are accesible.

    2. ACA1234 off, WB3.0 loads from internal IDE-CF. PCMCIA CF is accessible, but somehow several CFs stopped working, a couple of them still works.


    So I switch between these modes to get files in via PCMCIA and fiddle with Acatool command line. :)


    I might try to copy the OS3.2 content to the boot partition of ACA-CF and try to install WB3.2 with the mapped KS3.2 - I read somewhere that it should work. The ACA-CF bootable partition is available in the early boot menue when ACA is ON.

    Quote from Glidewell

    Still I can't find any explanation of the /S, /K, /N switches in the command line syntax.

    That's the standard Amigs DOS template designators. I believe this is in chapter 6 of the Amiga DOS manual (but Timm can of course elaborate on that - he wrote the tool).

    Quote from Glidewell

    1. Mapped OS3.2 kickstart with safeboot and no startup-sequence - loads to the CLI and lets me copy files, and turn ACA1234 off (CPUOFF). PCMCIA CF not available,

    Make sure you do NOT have any extra PCMCIA driver installed. It will clash with the ACA1234 PCMCIA driver.

    /N is numerical modifier, /S is a switch, /K requires the keyword. Please consult your operating system manuals for more details. :-)

    Assuming we are talking about acatool 3.0.1, and applying only to the ACA1234, as stated in the documentation:

    Use the GUI to save settings. [...] It is now possible to map a ROM file once, without saving it to flash and making it a permanent change (see ROMFILE option, only via command line).


    In other words: The ROMFILE option maps the ROM file only once on the ACA1234 - so you can check if a ROM file is functional and behaves properly. It's not getting saved via command line, the setting is made permanent only if saved via GUI.


    This of course doesn't explain checksum errors.


    The recommendation for OS3.2 is: Use your OS3.0 or OS3.1 ROM during installation of OS3.2. Later check if you can map the OS3.2 ROM successfully - and in the case of the ACA1234 this can be done with the command line and the ROMFILE option.

    Tons of thanks for the info!


    Good news - it was indeed the OS3.0 copy command problem. I used LHA to transfer kickstart roms from PCMCIA CF and OS3.2CD.iso image onto internal IDE-CD (compressed and decompressed to the target drawer) then ACATOOL ROMFILE comman worked with no checksum errors. I was able to maprom to KS3.0 this way, boot normally to WB3.0, open acatool GUI and switch it to mapping internal KS3.0. :)


    Perhaps the OS3.0 copy problem deserves mentioning in some sort of FAQ, I learned it browsing this forum for a few hours :)


    The OS3.2 manual requires at least KS3.1 for installation, also it says that upgrading KS first is preferable to avoid copying a lot of extra data - this is why I tried to maprom KS3.2 first :)


    As for CF driver conflicts, when I first installed ACA1234 the workbench screen would redraw every 5-6 seconds. I unchecked the PCMCIA CF mount option in Acatool - flicker stopped and CFs in PCMCIA worked fine. :) By the way, after reverting acatool to mapping internal rom CFs, which didn't work while KS3.2 was mapped, started to work fine, namely its Kingston 1Gb CF.

    As in OS3.5, neither ROM files nor physical ROMs are needed. OS3.2 ROMs can pose some nasty trouble and catch-22 situations in the real world, and this includes a variety of our own products. I consider installing (and operating) OS3.2 on OS3.1 ROMs more reliable and generic, because OS3.2 removed some important libraries from the ROM. This was a really bad idea in my opinion.

    How about 3.1.4 rom for use with WB3.2 - better or worse than 3.1 rom?


    Another thing, learned while browsing the forum, is the problem of some demos not liking accelerators... - another justification for double boot with internal IDE-CF and it might be a good idea to have OS3.1.4 or 3.2 on interal CF rather then the stock OS3.0. But since ACA1234 will have to be disabled for such demos, its maprom function and interal CF will not be available, hence replacing the stock kickstart chips with upgraded rom might be not a total waste of money :) However I still study other options for soft kickstarting with the internal IDE-CF, perhaps it won't be too inconvinient compared to the ease of reverting Amiga to its original state.

    I don't remember the situation with OS3.1.4, I have seen it only shortly and then OS3.2 came out. OS3.1.4 caused a lot of trouble with our products and we're glad it's history. :-)

    OS3.1 ROMs are most likely the best option for compatibility in all directions, especially if you include things like demos and games - we in individual Computers certainly do.

    We have several software updates and new products in the pipeline to aid with switching ROMs and help with compatiblity, and with special regard to OS3.2.

    If I remember right, at least wb library is not in the 3.1.4 ROMs.


    As for demo compatibility, I don't remember any difference between 3.0 and 3.1, so if you have 3.0 right now, I'd use them as compatibility-fallback and don't buy anything on top of that (unless there's a killer title that requires 3.1, but I'm not aware of any).

    Thanks, guys! I'll stay with 3.0 then for double boot or might try 3.1 out of curiosity - don't know the difference yet :).


    Last question before I forgot it :) the wiki page for ACA1234 currently lists ACA1234upd220228.lha as latest firmware, but in the next section installation instruction suggests to download ACA1234-CPLD-UpdateV3.lha. I downloaded and installed both updates, but didn't understand the purpose or difference bethween them :) Are they really both necessary (my ACA1234 was from the first batch).

    Quote from Glidewell

    but in the next section installation instruction suggests to download ACA1234-CPLD-UpdateV3.lha

    Only for those who got theirt board in October last year with the very first batch that was shipped. You can skip the CPLD update - all later boards have it, and they also have the blue wire that allows to switch on iCache in chip ram. If you have that wire, you also have CPLD V3.


    Quote from Glidewell

    (my ACA1234 was from the first batch).

    Let me know your order ID if you're not sure. We've come out with the update *very* quickly after the pre-orders were shipped, so it is very likely that you don't need the CPLD update.

    Nope, I don't have the wire link and yep my card was from that batch - you wrote me an email then to choose whether to return the card or update CPLD myself - I chose to keep it (and got the cable to parallel port from you - thanks!). I only lately got my A1200 recapped, keyboard overhauled (hard membrane :)), plus new modern PSU from Poland (with fancy LED display :)) - all this put together and running to finally try this card at work :) (though I also tested it with ACA500+ back in winter).


    The order ID is 106694.


    Anyways, I have already flashed both updates (not sure if both were necessary), but don't plan to bother with the wire link yet - haven't learned yet what this link is ment to improve. The card works fine so far, memory tests ok.


    P.S. I also got an FPU from AmigaStore kind of 'garanteed' to be ginuine. I read that you don't support it because of widely faked FPUs out there and I don't plan to bother with the FPU in the nearest couple of years (to keep the waranty), but may be in the future will attemp to install a socket and try it - another reason to postpone the wire link soldering to the FPU contacts :)

    Quote from Glidewell

    plus new modern PSU from Poland (with fancy LED display :))

    Sorry to say it, but that's known-bad, as it's based on a MeanWell PSU chassis. This is no good for an expanded Amiga. You should return it for false advertising. Our PSU FAQ has all the details. The LED display is even showing how bad the design is: If shows you the voltage at the source, not at the sink.


    Quote from Glidewell

    haven't learned yet what this link is ment to improve.

    That's for compatibility with certain games and demos that were written for non-accelerated A1200s. If you haven't noticed anything bad yet, you probably won't need that wire. It took the Amiga community well over ten years to notice that "something" is different with our accelerators. I've addressed it in this year's Revision seminar (sorry, unfocused camera and my first-ever attempt at video editing, as usual in a hurry before the deadline).


    The FPU socket *must* be modded: The "FPU sense" pin must not have any contact with the board, as that pin is expected to have the wire link to the CPU. The pin should be completely removed from the socket.

    Thanks, I'll remember to cut the socket pin and solder the wire when I get to the installation in a couple of years.


    Oh, your wonderful CA-PSU if finally back in-stock! How come I missed it :) Hopefully I'll be able to afford it this summer before it's sold out again.


    I've got 3 original PSUs with my Amigas and none of them look clean on the oscilloscope compared to even an old rusty no-name ATX PSU (which I know you also don't recommend in the PSU FAQ), not anywhere close to ATX. All voltages are off the specs. I am scared to connect these PSUs to Amigas and hardly will have time this year to open and recap them. I will check how this new/bad one looks on oscilloscope compared to ATX - will probe inside A1200 later (case still opened).

    I installed OS3.1 with mapped KS3.1 on ACA-CF, then moved the card to internal IDE-CF and installed OS3.2 on a new CF in ACA. It didn't boot after installation untill I mapped KS3.2. So, looks like propper/matching KS is mandatory to run OS3.2. Now I have 3.0 and 3.1 for compatibility fallback :)

    Good to hear that it works - and that the large flash space of the ACA1234 is being put to good use :-) Yet another reason to think about "large flash" for future products.

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

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • 8|
    • :cursing:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3