XSurf 100 - Autoconfig (worst case/overload)

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

  • 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).

    The X-Surf-100 uses a very optimized way of implementing shutup: If the $4c address (=shutup trigger) is written to, the Autoconfig process is ended (config_out is set), but the card does not respondo to any address any more. This is assuming that the address register(s) have not been written to, meaning that the initial config nibbles would still show at $e8.0000 just before shutup was triggered.


    So the shutup condition is stored in "address still at $e8.0000 and config_out is active". I need to look up if the config_out line is really allowed to be active in shutup state. Needless to say that this corner case wasn't tested.


    The X-Surf-100 CPLD is really full, so if the config_out line needs to remain inactive, I wouldn't have the required Macrocell to implement that:

    Don't get confused by the one unused macrocell in FB1: A neighbouring macrocell is using all the product terms of that seemingly-free one :-)

  • Noted, and thanks for the effort into looking at it.


    My assumption is that the OS (expansion.library) is processing each generic PIC while it resides at the $E8.0000 base config address (or the other Z3 high address). From there, it's either programming the card's destination address, or writing to the $4c ShutUp trigger (if supported). I have multiple A2091 and GVP DPRC cards which seem to behave as that (Shut?=Yes) feature intended. Older boards, with discrete TTL components, at a real-estate premium, and/or aiming for the most cost-reduced design, probably covered the Shut? corner case with the least amount of logic, and left it unsupported (ShutUp?=No) fairly often. I have several older cards from both noted sources, and other makers, which are like that. It's a valid solution in my opinion.


    I am going to follow up with the devs on the OS end, too. I know this dark corner of the Amiga OS wasn't deeply vetted with modern CPUs back in the OS 1.x / 68000 days. It was extended in only a basic effort for the A3000 in OS 2.x for Z3 PICs, with very little testing, and none apparently into the worst-case scenario (a full PIC environment) situation. It seems even the OS 3.x efforts that came later for the AGA systems left much of the 1991's 3rd Edition of the HRM's defined extensions unbuilt, and no further slotting refinements were added. For the OS 3.1.4 efforts, a number of fast-CPU HW race conditions were addressed in the dev efforts (I found them with fast 040/060 boards). They also addressed some address/register read/write overrun edge cases. The expansion-RelNotes cover that detail. Nothing was done to address the overall card-population logic engine.


    What the OS does with that no-shut situation remains a question to be answered, too. The card needs to either be sent somewhere 'safe', and made unavailable to it's driver/software (pseudo-shut) in order to keep processing another possible card for another expansion pool with space open, or card processing has to stop with that board and left unconfigured (at $E8.0000). I am under the belief that the OS does some kind or the former at this point, with some possibly odd results. It needs some further thought

  • Checked with the Commodore Autoconfig example (which supports Shutup), and that indeed leaves config_out unchanged if shutup is triggered. So yes, technically I'm doing the wrong thing and confirm that Autoconfig has ended, but that should not lead to a hang, as I really keep the bus completely free after that.


    I could of course un-set the shuptup-support bit, like I did for other Zorro designs. However, I'd like to know exactly why it hangs - it shouldn't, and there may be a software fix for it: I never toggle Slave after shutup, and that in turn tells all the rest of my logic to not go on the bus. Need to see what Buster does if I never do Slave, but give config_out. It *should* be OK, as it just passes the $e8.xxxx area on to the next card.

  • Side/related topic - I just tested the Buddha (20th), also in slot 4. When it encounters no Config space, Shut passes the CFG_Out to the next board, and does not hang the process. Not sure if that helps.

    Former GVP Tech Support 1989-93, GuruROM Maker/Supporter (as personal time allows)