P96 v3.2.x not activated on AOS3.2.1 if Z3 RAM is 1GB

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.
  • I have found an issue with the latest versions of P96 (recreated on 3.2.0 and 3.2.1 but not on earlier 3.x releases), when combined with KS 3.2.1.


    If using 1GB of Z3 RAM, the P96 driver doesn't seem to activate and no RTG screenmodes are available to the system.

    Reducing the Z3 RAM to 512MB or lower, does not trigger this issue.


    Steps to recreate:

    - Kickstart ROM 3.2.1 (does not occur with KS ROM 3.2)

    - AmigaOS 3.2.1

    - 1GB of Z3 RAM

    - Happens with any gfx driver, not just uaegfx. Tested with PIV also, for example.


    - Tested a fresh new installation from scratch, with nothing else but AmigaOS 3.2.1, then P96: Happens right after reboot.

    - Tested with an AmigaOS 3.2.1 installation and P96 v3.x (but < 3.2.x): Worked normally, until I upgraded P96 and rebooted.

    - Tested with AmigaOS 3.2 kickstart on the same system: Worked normally, even with the latest P96 3.2.1.


    Tested on WinUAE 4.9.0 and Amiberry 4.2.0, I'm getting identical behavior.

  • How about running Snoopdos to see if there's anything obvious? Also, it would be interesting if a standard 3.1 install will show the same problem. There may be an influence from Kick/OS 3.2.1 that you should also exclude by testing with a 3.1 system.

  • Another question: How do you check for available screen modes? Is P96Mode involved? If not, please check with that tool. You may be looking at a simple Z3 memory space clash where the (virtual) graphics card isn't found, so "showconfig" may also be a good source of information.

  • None of the P96 resolutions are shown in Screenmode, so P96Mode is not involved.

    Here is the output of showconfig when it doesn't work:

    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.102, Exec version 47.8, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$7FFFFFFF 1024.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 1GB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$80000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)


    And here is it when it does:

    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.102, Exec version 47.8, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$5FFFFFFF 512.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 512MB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$60000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)

  • I don't think that is the culprit.
    Showconfig with kickstart 3.2 (not 3.2.1) where this is not an issue this with 512M


    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.96, Exec version 47.7, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$5FFFFFFF 512.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 512MB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$60000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)



    And with 1GB

    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.96, Exec version 47.7, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$7FFFFFFF 1024.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 1GB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$80000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)

  • Showconfig with kickstart 3.2 (not 3.2.1) where this is not an issue this with 512M

    Correct - the virtual GFX card moves to $6000.0000 in that case, so bit#31 is 0, and everything in the OS is hunkydory. Note that bit#31 of pretty much any address within the OS must be 0, otherwise things start to fail.

  • But with 1GB of memory on KS 3.2, P96 works fine. Even with the virtual GFX card on $80000000.
    It's only a issue with 3.2.1. The question is if this is a P96 or kickstart bug (or feature)

  • Can you try with a Z2-emulation of a gfx card and see if there's a difference? I'd like to exclude the bit#31 issue, so a gfx card at $00e9.0000 (plus increements of 64k) would be what we're looking for.

  • A Z2 card works with 1GB

    PROCESSOR: CPU 68040/FPU 68882/MMU n/a

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.102, Exec version 47.8, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $10000000-$4FFFFFFF 1024.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60) (@$200000 8MB)

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$10000000, size 1GB, subsize same memory)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)

  • A Z2 card works with 1GB

    Good - in my opinion, this concludes it, as nothing in the Amiga world will ever work with an address bit#31=1. I have my doubts that even a previous version of P96 did that. You probably had some other setting that avoided the gfx board in $8000.0000.

  • Hang on. With kickstart version 47.96 it works just fine. The problem occurs with kickstart version 47.102.

    Here's the showconfig:

    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.96, Exec version 47.7, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$7FFFFFFF 1024.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 1GB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$80000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)

  • Hyperion did play with Z3 autoconfig, saying that they fixed a bug that must have been there for decades since introduction of Z3. They would not reveal to us what the details of the changes were, but they fixed what was broken with Kick47.96.


    However, you can clearly see that the GFX board is located in $8000.0000, so you changed more than just the Kickstart. Please: If you are testing corner cases like this, then only change one thing at a time.

  • I've not changed anything else than the kickstart.

    This is the one that doesn't work:

    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.102, Exec version 47.8, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$7FFFFFFF 1024.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 1GB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$80000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)

    This is the one that does:

    PROCESSOR: CPU 68020/FPU 68882

    CUSTOM CHIPS: AGA PAL Alice R2 (ID=$0023), AGA Lisa (ID=$00F8)

    VERS: Kickstart version 47.96, Exec version 47.7, Disk version 47.2

    RAM: Node type $A, Attributes $405 (FAST), at $40000000-$7FFFFFFF 1024.0MB

    Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF ~2.0MB

    BOARDS:

    UAE Amiga Emulator UAE - Magic Device Emulation: Prod=2011/82($7DB/$52) (@$E90000 64KB)

    UAE Amiga Emulator UAE - Z3 Ram Expansion: Prod=2011/83($7DB/$53)

    (@$40000000, size 1GB, subsize same memory)

    UAE Amiga Emulator UAE - RTG Graphics Expansion: Prod=2011/96($7DB/$60)

    (@$80000000, size 128MB, subsize same)

    UAE Amiga Emulator UAE - Boot ROM I/O access: Prod=2011/4($7DB/$4) (@$F00000 64KB)


    The diff between those two are:

    -VERS: Kickstart version 47.102, Exec version 47.8, Disk version 47.2

    +VERS: Kickstart version 47.96, Exec version 47.7, Disk version 47.2


    That said, your argument about the changes Hyperion did might explain this.

  • The funny part is that both configs are showing the RTG card at $8000.0000, which should *both* fail. So either you're confusing the text-blocks, or there is something else going on - in either case, P96 is the wrong place to look for the fault.

  • AutoConfig of a Z3 board at $8000.0000 should not be possible. The Hardware Reference Manual 3rd edition marks all space >2GB line, sans the Z3 board detect/config address, as reserved. The Z3 expansion space map is on p387.


    I found the Z3 $8000.0000 AutoConfig bug by overloading the expansion space on an A4000T. I reported it for 3.2->3.2.1 but I don't have the details of what was done, either. I had the impression what was done was a band-aid, and would be looked into again in the future.

    You have overloaded Z3 from the $4000.0000 start point upward. One of the bugs I found is that it never uses the Z3 high address space from $1000.000-$3FFF.FFFF. I've suggested they maintain the build-up sequence from $4000.0000, then build-down from that address to avoid potential issues with some customizations..


    One of the other bugs in Z3 is the inability to 'sort' smaller cards into the available address slots (like Z2 can with 64K/128K I/O and 512K/1M/2M RAM/Shared memory space cards in the 8M space). That was how I found the bug noted above.

    Your solution for now is to back off the large memory expansion configuration that results in any board being placed at $8000.0000 - at least any that causes you trouble.

    My opinion: There is a need to revisit both Z2 / Z3 AutoConfig in the future, as there are worst-case expansion-card situations that were never able to be tested back in the day. I currently have enough physical cards to overflow either the Z2 and/and Z3 expansion spaces, so I hope to help them sort it in a future update.

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

  • One of the bugs I found is that it never uses the Z3 high address space from $1000.000-$3FFF.FFFF. I've suggested they maintain the build-up sequence from $4000.0000, then build-down from that address to avoid potential issues with some customizations..

    This will require deep knowledge of Buster/Ramsey/Far Gary inner workings. Documentation for these chips is really scarce, and you may end up with conflicting addresses, possibly even "no Z3 access" when using a space below $4000.0000. It's one thing to try it in emulation, but a whole different ballgame in real machines with different chip sets (A3000 and A4000 plus variants).

    My opinion: There is a need to revisit both Z2 / Z3 AutoConfig in the future, as there are worst-case expansion-card situations that were never able to be tested back in the day. I currently have enough physical cards to overflow either the Z2 and/and Z3 expansion spaces, so I hope to help them sort it in a future update.

    You are right that such worst-case Z3 configs can easily be created these days, but as I pointed out above, you may run into problems with other components needing the bus for certain addresses. Further, all the modern Z3 expansions need to be double-checked for optimizations that will break if you use a different address space. The X-Surf-100 will work without any problem below the $4000.0000 space, but ACA630, ACA1233n and ACA1234 require the first Z3 board to be mapped to $4000.0000, as they don't store the assigned address at all. I'd have to double-check with Michael for details of ZorRAM, BigRamPlus and Deneb. Also, Lukas should check his GFX cards.


    These are just the modern cards where developers are still around. We still have A4091/Fastlane, PIV and other "iconic" cards that would have to be taken into the test-loop. This will be extremely tedious, but I'd be willing to help where I can.

  • I'm in agreement about the testing being a challenge.


    I have simulated in hardware several of the messy expansion-overload scenarios. Finding a solution that best covers the hairy-edge of physical expansion - be it by modern active developers, or what was done by the developers of the past , will take effort. FWIW - One of the scenarios before the ROM for 3.2.1 was made was my Z3 ZZ9900 had ended up at $9000.0000 in one of them. I couldn't test the quick fix they used before the release due to personal travel/work activities, but the ugly Z3 card processing in the code was acknowledged then, and was noted it will need a revisit.


    I am being mindful of your expansions in this - My hope is to get the physical systems with as many as 6 physical PICs (with chained config possibilities) addressed as best as possible. The runaway z3 config (upwards in address), the sorting of z3 cards into available smaller spaces (like z2 does), and the expansion space-filled / no shut scenarios need some future attention, though.

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

  • This will require deep knowledge of Buster/Ramsey/Far Gary inner workings. Documentation for these chips is really scarce, and you may end up with conflicting addresses, possibly even "no Z3 access" when using a space below $4000.0000. It's one thing to try it in emulation, but a whole different ballgame in real machines with different chip sets (A3000 and A4000 plus variants).

    True. I'm not sure how well Gary/Buster is prepared for the address range below 0x40000000, especially in terms of DMA. As somebody currently happens to work on a 4091 replica, I hope to get my hands on one for testing. I do have all 3 current Buster variants available (7,9,11) for cross-verification. It remains to be seen, though if the range from 0x10000000-0x3FFFFFFF is worthwhile to be included into expansion.

    You are right that such worst-case Z3 configs can easily be created these days, but as I pointed out above, you may run into problems with other components needing the bus for certain addresses. Further, all the modern Z3 expansions need to be double-checked for optimizations that will break if you use a different address space. The X-Surf-100 will work without any problem below the $4000.0000 space, but ACA630, ACA1233n and ACA1234 require the first Z3 board to be mapped to $4000.0000, as they don't store the assigned address at all. I'd have to double-check with Michael for details of ZorRAM, BigRamPlus and Deneb. Also, Lukas should check his GFX cards.


    These are just the modern cards where developers are still around. We still have A4091/Fastlane, PIV and other "iconic" cards that would have to be taken into the test-loop. This will be extremely tedious, but I'd be willing to help where I can.

    Should initial experiments yield encouraging results at some point and should there be an opportunity for release, then 0x40000000 would still stay the traditional start of Z3 expansion space, simply because people who might actually exceed 0x40...-0x7F... with actual Hardware tend to know what they are plugging together, so that the likelihood of unworking cards by configuring them below 0x40... is minimized.


    As expansion is a very sensitive component in the kickstart, changes need to be done carefully and by including active HW developers into a comfortably timed evaluation process.


    3.2.1 just contains a simple fix to expansion as the report by thebajaguy came in after the feature freeze window and close to release. That fix will configure cards that don't fit into the valid 0x40...-0x7F... space in SHUTUP mode (= unusable).


    --Henryk Richter

  • Thanks Henryk. I agree it needs careful efforts and to involve developers.


    I'm currently working on a logic proposal that would populate the PICs for the Z3 space from the top-down (instead of classic bottom-up). This would avoid going below $4000.0000 except in the worst-case expansion scenarios where a 1GB or a few 512M/256M cards are present. Only the last cards in the order are subject to the less-happy? memory spaces. With better sub-allocation of the smaller boards (which is something that we know is missing - unless they are sequentially ordered well), the chances are much reduced of an issue. Re-arranging the boards would help in most cases.


    I have other things in the proposal that look to address oddities I have found. I also have a test/developer idea or few.

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

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