BigRAM2630: Boot hangs after AmigaOS 3.2.1 module update

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!

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?

By the way, just to confirm, if I add ALLTOCHIP to the LoadModule call, the machine doesn't hang. But that's not a great long-term solution, as I still want fast memory to be used; just not from the BigRAM if it's not compatible.

Now that I think about it, this is probably the same issue that was being reported here: BigRAM 2630 issues with intuition.libary, WHDLoad

Quote from Jens

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. 🙂

Quote from Jens

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?

Quote from BigRAM2630 Registers

$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.

Quote from Jens

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.

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:

If you were to subsequently send:

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.

vinceb I may have made a mistake writing that from memory. I’m still not in front of my Amiga now, so you could run “BigRAM ?” to try and identify my mistake. Otherwise I can look later today.

vinceb Are you sure you didn't make a typo? I just double-checked with " bigram help", and those are the right command arguments. And here's a post with Jens saying the exact same command five years ago