Hi Jens,
I might have found something amiss with the X-Surf 100 AutoConfig Shut mechanism. It's not a show stopper, and more like a corner case, but maybe if you have time to look at it. This is part of my testing for the post-3.2.1 Amiga OS AutoConfig. Low priority, in my opinion:
I fill Z2 AutoConfig with a GVP G-Force 030 with AutoConfig RAM and the DPRC PIC.
- 8MB AutoConfig FastRAM at $20.0000-9F.FFFF
- 64K PIC for DPRC at $E9.0000.
I fill the next 3 Z2 slots with some early GVP Impact cards that I know are 128K sized PICs. That covers:
- 128K PIC at $EA.0000
- 128K PIC at $EC.0000
- 128K PIC at $EE.0000
Expansion space is now full - with 2 open slots in the A2000. X-Surf 100 becomes the next card in slot 4, and obviously there's not a place to put it. Power on, the LED goes bright, and AutoConfig hangs here. Not possible to get to an Early Startup menu. I know it's not getting to the point where the upstream cards' driver ROMs would activate. I have dropped in several other cards which support Shut (and the OS shuts them) so I know what should happen. I have some cards that cannot Shut, and behavior is similar to this issue. X-Surf 100 is supposed to support ShutUp (the flag is set, based on ShowConfig's debug output).
If I reduce FastRAM to 4MB AutoConfig, or remove the 8MB FastRAM PIC altogether, I have found an OS AutoConfig bug I'm reporting. The OS will drop any I/O-space card normally intended for $E9.0000-$EF.FFFF into the spare 8M space. X-Surf is ending up here in this situation, since in this scenario there is 'space' left in the 8M area. The flag for Put board into 8M space is set to No, so the OS shouldn't drop it here. I have some other I/O-space boards that balk at this 8M space destination, too (drivers crash/LED flash, or toss requesters with issues) so it's something for us to go after in expansion.library down the road.
My query is therefore: Can a check for what happens to the board when Shut is programed by the OS be done? Does the board actually accept it and 'disappear' until next reset? Will it pass the Config_Out on to the next board? or not? I have other I/O board examples where AutoConfig downstream is denied - CFG_Out is never passed to the next slot, leaving all boards downstream out of luck. I also have them where CFG_Out is allowed to go on to another slot board (and if there's no place for them they get Shut/or worse if they aren't as well behaved).
There aren't any tools at this point to figure out what the OS is doing that early, but I have enough cards' behaviors under my belt to think the X-surf board isn't doing what was planned. It's a fair bet that most developers back in the day didn't have a way to simulate/test a full expansion space, either.
A note that I also checked 3.1, 3.1.4 and 3.2 release ROMs - same behavior.