BigRAM2630: Boot hangs after AmigaOS 3.2.1 module update

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.
  • AmigaOS 3.2.1 was just released today, and it updates some modules via LoadModule. If I let my A2000 apply the updates, the machine reboots (expected), reads the disk very briefly, and then hangs on a black screen. If I hold both mouse buttons after the reboot and check the "Trace startup sequence" box, it doesn't even get to the point of letting me step through the startup-sequence - it just hangs on the black screen. What might be happening here? If i remove the BigRAM2630, it successfully boots with the module updates. And if I comment out the LoadModule call, it successfully boots with the BigRAM2630.


    I haven't noticed any other issues - just this issue with 3.2.1. Thanks!

  • We've had an update for the BigRam2630 that corrects a bit for the added memory. Let me check where that is...


    Edit: Found it - attached. This one corrects the memory settings for resident modules.

  • Thanks, Jens! I ran bigram help, but I'm not sure which option I'm supposed to be using to correct the autoconfig settings. The section about using the bigram tool directly to make modules resident wouldn't be applicable here. Or are you saying I need to use the bigram tool to add the memory from now on instead of AutoConfig?

  • Or are you saying I need to use the bigram tool to add the memory from now on instead of AutoConfig?

    No - just flash the unit once, and it'll be persisted for all future boots.


    if I add ALLTOCHIP to the LoadModule call, the machine doesn't hang.

    ...confirming that the improved settings for the addmem that's executed from flash will solve your problem.

  • No - just flash the unit once, and it'll be persisted for all future boots.


    ...confirming that the improved settings for the addmem that's executed from flash will solve your problem.

    I guess I wasn't clear about my question: what am I typing into the shell? I don't know what parameters to give the bigram tool to flash the settings you're suggesting. 🙂

  • AFAIR (and it's some years ago), there are three options: C0 memory, Fastmem and MapROM. I'd do C0 memory and Fastmem only.

    Never mind, it finally came back to me how bigram works. It's non-obvious, even with what you just said, until you remember the implementation detail that no state is remembered and bigram is literally writing out directives to be run at boot, not just toggling feature flags. Without knowing that, it makes no sense to send the same settings I already had, especially since I don't remember what settings I had in the first place.


    Before I saw you said to enable C0, I found in previous posts you'd suggested addmem and maprom as the default options. I did that with the version of bigram you attached, and it seems to have fixed the issue. I didn't turn on C0 memory because I didn't know what it was. Is it this?


    $00c0.0000 to $00db.ffff
    optional trapdoor ram, normally switched off. This 1.8M memory space may only be switched on if no DMA-capable Zorro cards are in the system.


    That sounds like most people definitely do not want that on, right? My SCSI controller uses DMA.


    Thanks for the pointers in the right direction, Jens.

  • That sounds like most people definitely do not want that on, right? My SCSI controller uses DMA.

    Right - C0 trapdoor space is in the 24-bit address area that is reachable from Z2 slots, so yes, you should turn that off,


    The MapROM part is also not desirable for OS3.2.1, as you most likely want the Kickstart to be mapped in Fastmem. However, soft-kicking is not possible with BigRam2630 due to the limitation that the lower 64k (again, if I remember right) need to be binary-identical with the physical ROM. You may be better off using the MMU to map a new ROM.

  • Right - C0 trapdoor space is in the 24-bit address area that is reachable from Z2 slots, so yes, you should turn that off,


    The MapROM part is also not desirable for OS3.2.1, as you most likely want the Kickstart to be mapped in Fastmem. However, soft-kicking is not possible with BigRam2630 due to the limitation that the lower 64k (again, if I remember right) need to be binary-identical with the physical ROM. You may be better off using the MMU to map a new ROM.

    It's only updating select libraries and not doing a full soft kick, so it seems to be happy. I don't actually want maprom and already use MuLibs to remap the ROM to fast memory, but when I didn't have it on, it started dropping my SCSI controller when rebooting for LoadModule. It's probably the documented issue that I need another Zorro card in between the A2630 and my SCSI controller, but I don't have one to put in there right now.

  • Sorry but I didn't understand how to use the "bigram" file inside the zip file. Should I put it in the startup-sequence?

    Can you tell me the correct syntax?


    Thanks in advance


  • vinceb The key is that when you send a configuration to the BigRAM, it completely replaces the old configuration and starts from scratch. So you need to send it one command that sets all configuration options you want, like this:

    1. Shut down your Amiga
    2. Set the jumper on the BigRAM to allow changing the configuration
    3. Run BigRAM <options>
    4. Shut down your Amiga
    5. Remove the jumper

    The exact command I sent was:

    Code
    1. bigram addmem maprom

    If you were to subsequently send:

    Code
    1. bigram addmem

    that would implicitly turn off maprom. Every option you want needs to be present every time you flash options with the BigRAM tool. I personally find this incredibly unintuitive, and it’s not really explained in the documentation. But if you think about it, that’s the only way it could work given the documentation since there are no command flags to turn off a feature.


    You may not want maprom, especially if you’re using MuFastROM. I only added it because it worked around the BigRAM causing my SCSI controller to be dropped. Your mileage may vary.

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