Two BigRAM+ cards.

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 two BigRAM+ cards. I just acquired a ZZ9900 and had this itch to see the Amiga memory at near AutoConfig-max, so I put both BigRAM+ in the A4000T. It doesn't seem to like one of the cards.



    Host is an A4000T, TekMagic (ultrasound accelerator model) 68060/64MB/60MHz (Int Clocking) 2MB/16MB on the motherboard, Buster-11 / RAMSEY-07

    Other expansion: X-Surf 100 in the 2nd furthest slot, ZZ9900 in the closest slot (to the CPU area).


    BigRAM+ #1, gTanJ, has a 50MHz clock, and is generally reliable in the system. I have had it in either one of the two slots between the above cards.

    BigRAM+ #2 DTarP, has a 60MHz clock, and is notably unreliable in the A4000T. If it doesn't toss up a Bad entry on early startup, the memory doesn't register and AutoConfig is not passed along most of the time to the ZZ9900. Remove it, and all is back to as expected. Slot chosen really didn't matter.


    Note: - I have been running the card with the 60MHz clock fine in an A3000D/25 with Buster-11 and an AmigaNet card (my software Dev system) without issue. This was the first time I actually compared the two cards side by side. I had encountered the problem some time ago with presumably the 60MHz card, but I never chased it down since I picked up the second card somewhere, and they were working in their respective systems.


    The 60Hz clock part is a smaller can vs the 50Mhz. Neither board looks like it was modified by anyone. I gave it a decent compare under my lighted magnifying glass. Aside from some different numbers on the middle 2 lines of the Xilinx chip, and the clock part, the boards look identical down to the memory chip and all passive parts.


    Any guidance regarding the picky card? I'll probably leave it in the A3000D, but if something can be done about it, it would be nice to know.


    Edit: The 60MHz clocked board also seems to behave in an A4000D (earlier rev) 2MB/16MB, Buster -11/Ramsey 07, with a T-REX II 68060/128M/66MHz CPU card (Int clocked).


    Robert

  • BigRAM+ #2 DTarP, has a 60MHz clock, and is notably unreliable in the A4000T. If it doesn't toss up a Bad entry on early startup, the memory doesn't register and AutoConfig is not passed along most of the time to the ZZ9900. Remove it, and all is back to as expected. Slot chosen really didn't matter.

    The clock speed of BigRam+ hardly matters, as it's developed for up to 80MHz operation. You could of course try to use a different oscillator, as the cause may be a dodgy clock (note that these ocsillators are 5V parts, and they rely heavily on a clean 5V supply). Your description of this very card working reliably in a 25MHz 68030 Amiga makes me think about power supply and clocking from the accelerator - the mainboard clock may not exceed 50MHz, otherwise all bets are off. And if the PSU has excessive ripple, canned oscillators don't work properly. The latest iteration of BigRamPlus has a 3.3V oscillator, because the 3.3V side has significantly lower ripple.


    Neither board looks like it was modified by anyone.

    ...only the oscillators were hand-soldered. Four solder spots is something that is done faster manually than taping up the connector and running it through wave solder. The board is designed to work with both the 8-pin layout ans the 14-pin layout of the canned oscillators.

    Aside from some different numbers on the middle 2 lines of the Xilinx chip

    Which is probably the production batch. If I remember right, there have been two production batches of these expansions.


    Any guidance regarding the picky card?

    Since it works in two out of three Amigas, it may really be a power issue. What you could try is to replace the oscillator with a different one (any frequency between 50 and 66MHz will do, 80MHz is pushing it), or to generate a local 5V from 12V with a linear regulator and feed the 60MHz oscillator with that, see if that makes a difference. If it does, the power supply is the root cause.

  • I will probably pursue the oscillator first as I have the parts, and swapping is an easy thing from the range of spare clock parts in my drawer.


    The motherboard is stock clock rate (25MHz), based on the halved native 50.000MHz can. The accelerator uses its own 60MHz clock and doesn't drive any clock off-card.


    I have also been aware that the 'T' motherboards are, due to trace lengths, sometimes a bit more challenged when things get marginal. Maybe the presence of two 60MHz clocks in the proximity is getting picked up as noise somewhere.


    Thanks for the guidance. I'll report back if I get the chance to address it.

  • Maybe the presence of two 60MHz clocks in the proximity is getting picked up as noise somewhere.

    That's unlikely: clock-output to input of the Xilinx is a point-to-point connection with nothing else connected. The async state machine (yes, Z3 is fully async!) and RAM run off this clock, but I do not believe in a noise problem, especially because the XC9500XL series have input hysteresis ("keeper" feature of the IO pins).

  • I'll be going through my small group of Z3 cards in the system and see if I can identify any others that present issues, and I'll also look into the alternate clock on the one BigRAM+ card at this point. I did some decent testing prior to 3.1.4 on AutoConfig expansion saturation (to many PICs for address spaces). If memory serves, all other Z3 cards I have had then behaved. There was also some focus put on HW race conditions related to expansion.library / AutoConfig. There were pokey cards that may not be ready at the default config address when the config signal reached them. I'm not convinced we squashed them all, but we fixed a few potentially marginal situations..


    Thanks for the detail.

  • Some further testing.


    The 60MHz clocked board offers a tiny, but repeatable, 0.2-0.4 MB/sec performance improvement over the 50Mhz clocked board in both the A3000D/25, and the A4000D with either an A3630/25 card in it, or a T-Rex II 68060/50MHz in it. Both BigRAM+ cards were in the hosts at the same time, positions 2/3 used. I polled 0x4100.0000 and 0x5100.0000 in my bustest addr command. I swapped the card positions to confirm it followed the card. Both systems are stable with both cards.


    I added another z3 expansion card to the the A4000T - A GVP Spectrum 28/24 using z3 mode. The 60MHz BigRAM+ card still disrupts the AutoConfig from where it is placed - Reports Bad in Early Startup screen, cards after it not seen. Moving cards around didn't address the issue. It only moved the failure point to the 60MHz BigRAM+. I will pursue the clock change on that board when I get in the mood to de-solder, maybe this weekend.


    Side note/unrelated: Having learned a lesson on Z2 RAM cards and 68040/68060 bus behavior a few months ago (with Thor/MuLibs), we discovered it good policy to turn off data cache (and therefore block the native attempt to burst-access) to the Z2 address space. It made a performance improvement, and in some cases, the system health improved (repeatable hangs on that address space with 16-bit memory disappeared). I just forced the BigRAM+ card memory at 0x40000000 to use Writethrough mode (default is Copyback with no mmu-configuration file settings made) with the 2x 68060's I have, and the write performance, near 4.5MB-sec, nearly doubled for the WriteL and WriteM values (to close to the observed 68030/25 values). Other measured values remained largely unchanged (margin of error). This was in the A4000D w/T-Rex II. The same behavior was reproducible on the A4000T with the working 50MHz BigRAM+ and the ZZ9900 256MB FastRAM (it offers as Z3 memory). Net result/suggestion: use WriteThrough cache mode for 68060 and Z3 AutoConfig memory added from the Buster expansion bus. I didn't get to test 68040, but I suspect it may be the same. I will send my test results to Thor as it ay at least be an item of mention in the documentation, and he probably will want to reproduce it.


    More data on the BigRAM+ with the issue in the future.

  • The 60MHz clocked board offers a tiny, but repeatable, 0.2-0.4 MB/sec performance improvement over the 50Mhz clocked board in both the A3000D/25, and the A4000D with either an A3630/25 card in it, or a T-Rex II 68060/50MHz in it. Both BigRAM+ cards were in the hosts at the same time, positions 2/3 used. I polled 0x4100.0000 and 0x5100.0000 in my bustest addr command. I swapped the card positions to confirm it followed the card. Both systems are stable with both cards.

    This is expected, as in async systems, you always deal with probabilities to hit a certain spot (or not). The higher the clock rate of BigRamPlus, the higher the probability to not miss the current clock cycle. As you have already found, the difference is measurable, but won't make a big difference ein everyday life. You may get one or two seconds gain on an hour-long compile of a large project.

  • Understood. I've spend many times explaining how clock speed in an async accelerator-bus mating environment matters to access efficiency.


    Ok - I desoldered the 60MHz mini can, and tested a 50MHz, 60MHz, and 66MHz using a machine pin socket.


    50MHz, 60MHz, and 66MHz worked fine in the A4000D. The 50MHz board configured first and the socketed board followed it. The bump in the Bustest values took it near 9.8-10MB/sec with the tweaked MuSetCacheMode set to WriteThrough.


    The 50MHz and 60MHz clocks produced the same results as before (Early startup, Bad) regardless of slot position in the A4000T/060. The 66Hz clock had some success.


    Accelerator z2 I/O PIC
    Slot 1 - BigRAM 66MHz (256 z3)
    Slot 2 - X-Surf 100 (z3 I/O PIC)
    Slot 3 - Open

    Slot 4 - ZZ9900 (128M+256M z3)

    Slot 5 - Open

    Accelerator $F00000 z2 Interface PIC


    All board seen.


    Added the GVP Spectrum z3 card into slot 3 - all came up as expected. It adds a 2MB z3 and a 64K z2 I/O to expansion.

    Added the 50MHz BigRAM+ card to slot 5 - the 128M of the ZZ9900 reported OK, but the 256MB reported Bad (see * below). The second BigRAM+ card did not get seen. I let it sit at the Early Startup as I was recording notes, and gave it a fresh reboot. This time it came up and showed all the cards.


    Map of boards on the Early Startup (All in when it came up good):


    1, z2, 2011, 32, $E90000, 64K (I/O), OK (CPU Card)

    2, z3, 3643, 32, $4000000, 256MB (RAM), OK (Slot 1) (66MHz)

    3, z3, 4626, 100, $50000000 (I/O), 64MB, OK (Slot 2)

    4, z3, 2193, 1, $54000000 (RTG Shared), 2MB, OK (Slot 3)

    5, z2, 2193, 2, $EA0000 (I/O), 64K, OK (Slot 3)

    6, z3, 28014, 4, $58000000, 128MB (I/O & RTG Shared), OK (Slot 4)

    7, z3, 28014, 5, $60000000, 256MB (RAM), OK* (Slot 4)

    8, z3, 3643, 32, $4000000, 256MB (RAM), OK** (Slot 5) (50MHz)

    9, z3, 2017, 22, $F00000, 8MB, OK (CPU Card)


    ** - Did not appear when the card before was reported bad.


    Side by side by side, the 3x z3 RAM cards, with WriteThrough mode set, the ZZ9900 was marginally faster (maybe .5MB/sec) across the board. The faster clock board did better on writes, and the slower clock board did better on reads.


    I swapped the BigRAM+ card positions (66MHz in slot 5, 50MHz in slot 1) - it booted, no issues.

    I swapped the 66MHz card from slot 5 with the GVP Spectrum card from slot 3, and the second PIC of the ZZ9900 in slot 4 reports Bad. The GVP Spectrum z3 and z3 come up Ok.


    1, z2, 2011, 32, $E90000, 64K (I/O)

    2, z3, 3643, 32, $4000000, 256MB (RAM)

    3, z3, 4626, 100, $50000000 (I/O), 64MB

    4, z3, 3643, 32, $6000000, 256MB (RAM)

    5, z3, 28014, 4, $70000000, 128MB (I/O & RTG Shared),

    6, z3, 28014, 5, $90000000, 256MB (RAM) [BAD]

    7, z3, 2193, 1, $90000000 (RTG Shared), 2MB, OK

    8, z2, 2193, 2, $EA0000 (I/O), 64K, OK

    9, z2, 2017, 22, $F00000, 8MB, OK (CPU Card)


    There's still something a little strange about that one BigRAM+ card, although the 66MHz clock has helped it be a little less marginal in the A4000T.


    I did try an 80MHz clock, but I'm not sure of it's health. I didn't get a boot of the A4000D with it installed in the card. Aside from some slower clocks like 64MHz, and several below 40MHz, the 66MHz is the fastest I have on hand.

  • Two issues:


    1) the address of the card is probably not 4000000, but 40000000 (one more zero). I push myself to using a dot after every 16 bits, so hex numbers become more readable. The expected address for the first Z3 card in "big" address space would be $4000.0000.


    2) boards 2 and 8 appear to be located at the same address. You can swap crystals all you want, but this won't work - it's either a typo on your side, or a bug in expansion. What Kickstart are you running?

  • Thanks for the reply.


    Bot h 1) and 2) were typos on my part. It was getting late and I was doing some copy and paste.

    1) Yes, the period is a good idea. Add one more '0' is correct. I made the same short-address mistake in the second board list, too.

    2) The board on slot 2 was at $4000.0000, and the board in slot 8 was at $7000.0000.


    I had mentally noted the z3 boards all lined up on major address boundaries this time. Therefore:

    3) I spotted another typo on my part in the second board list. Board 6 should have been $8000.0000, not at the same address as board 7.


    I am positive there were no duplicate addresses for board. All were incrementing over the previous z2 or z3 location. I have fixed my typos and reprinted the board order below:


    First board list (corrected):


    1, z2, 2011, 32, $00E9.0000, 64K (I/O), OK (CPU Card)

    2, z3, 3643, 32, $4000.0000, 256MB (RAM), OK (Slot 1) (66MHz)

    3, z3, 4626, 100, $5000.0000 (I/O), 64MB, OK (Slot 2)

    4, z3, 2193, 1, $5400.0000 (RTG Shared), 2MB, OK (Slot 3)

    5, z2, 2193, 2, $00EA.0000 (I/O), 64K, OK (Slot 3)

    6, z3, 28014, 4, $5800.0000, 128MB (I/O & RTG Shared), OK (Slot 4)

    7, z3, 28014, 5, $6000.0000, 256MB (RAM), OK* (Slot 4)

    8, z3, 3643, 32, $7000.0000, 256MB (RAM), OK** (Slot 5) (50MHz)

    9, z3, 2017, 22, $00F0.0000, 8MB, OK (CPU Card)


    Second Board List: (corrected):


    1, z2, 2011, 32, $00E9.0000, 64K (I/O)

    2, z3, 3643, 32, $4000.0000, 256MB (RAM)

    3, z3, 4626, 100, $5000.0000 (I/O), 64MB

    4, z3, 3643, 32, $6000000, 256MB (RAM)

    5, z3, 28014, 4, $7000.0000, 128MB (I/O & RTG Shared),

    6, z3, 28014, 5, $8000.0000, 256MB (RAM) [BAD]

    7, z3, 2193, 1, $9000.0000 (RTG Shared), 2MB, OK

    8, z2, 2193, 2, $00EA.0000 (I/O), 64K, OK

    9, z2, 2017, 22, $00F0.0000, 8MB, OK (CPU Card)


    Kickstart is OS 3.2 release ROM for both A4000 systems. 47.96.


    Upon powering on the system to grab the Kickstart version for you, Board 6 in the second list of slot card lineup, (the ZZ9900 256M PIC) reported bad again.


    I have a weekend work event, so I probably won't poke at this again until either later today or tomorrow.


    Thanks

  • 6, z3, 28014, 5, $8000.0000, 256MB (RAM) [BAD]

    The thing that strikes me here is that it's not the iComp board that fails, and that what previously worked is now failing, with address bit A31=1. This can have two causes: Either Lukas is not looking at A31, assuming that it's never set anyway (it is kinda unlikely), or it's a DOS error. I remember that there are some parts of the OS written with the address longwords as "signed" instead of unsigned. This may cause weird bugs.


    Also, the Kickstart version you're running is known-bad on autoconfig. If you are in the OS3.2 beta team, you should use V47.97, which fixes an expansion bug, but is still considered experimental.

  • I will put a query into Lukas to see if there may be something regarding the A31 decode.


    They have not released anything to the Beta team since the RTM 3.2 CD was defined, so I don't have anything to work with yet since the 3.2 release. I also haven't been able to locate a bug that matches the keywords expansion, autoconfig, or V47.97 or a few others. If you know the number, I'll be happy to look it up. The last two e-mail discussions on the expansion.library since release was the A3000 Superkickstart/030/MMU handling and the no-floppy drive drive / no boot situation.


    I have a VA2000 I'm going to tryin the mix next.

  • I decided to mix up the card list, putting the ZZ9900 first, and now I ran into a [BAD] on the previously always good 50MHz clocked BigRAM+ when in slot 5 at $9000.0000. The other cards I have sprinkled in after the ZZ9900.


    1, z2, 2011, 32, $00E9.0000, 64K (I/O) (Accelerator I/O port $E9)

    2, z3, 28014, 4, $4000.0000, 128MB (I/O & RTG Shared) (Slot 1a)

    3, z3, 28014, 5, $5000.0000, 256MB (RAM) (Slot 1b)

    4, z3, 4626, 100, $6000.0000 (I/O), 64MB (X-Surf 1000) (Slot 2)

    5, z3, 3643, 32, $7000000, 256MB (RAM) (Slot 3) (66MHZ)

    6, z3, 28014, 1, $8000.0000, 32MB (VA2000) (Slot 4)

    7, z3, 3643, 32, $9000000, 256MB (RAM) (Slot 5) (50MHz) [BAD]

    8, z2, 2017, 22, $00F0.0000, 8MB, OK (CPU Card $F0.0000)


    This swings the questions back into AutoConfig / expansion.library. Bug 2186 opened to see if they will investigate. E-mail was also put into Lukas, but did not yet include this reply's additional findings.


    I then pulled the BigRAM+ out of slot 5, inserted the GVP Spectrum z3, and it gets placed at $8200.0000 and z2 $EA without issue.

    Something I think is amiss in AutoConfig. The board size may be playing a part in this.

  • I also haven't been able to locate a bug that matches the keywords expansion, autoconfig, or V47.97

    I'm not a betatester, as the NDA to sign was way too complicated and contained things that I rather wouldn't sign. My NDA is altered to specifically exclude source code in order not to conflict with any involvement in open-source efforts that have existed for well over twenty years.


    However, I am in good contact with the OS3.2 team, and when it became evident that mostly our A1200 products that use Autoconfig are affected, we started investigating. I don't know the details of the fix, but the A3000 thing you've mentioned appears to be related, as V47.97 was mentioned very early in the discussion. After the team was informed that it's OK to send us the 47.97 binary, we found that it fixes the problems with the A1200 Autoconfig products. Please note that these are both Z2 and Z3 autoconfig things (ACA1233n, ACA1221lc and ACA1211 are affected), so it's probably not only related the the MSB of the address-long.


    Looking at your list of cards, there's still one thing not in line with expectations, and since every single list you've typed contains the same info, I have a hard time believing in a typo, like the missing periods here and there and putting the X-Surf into an identity crisis :-)


    Your CPU card seems to add an autoconfig device to $00f0.0000 - this in itself might be "just OK" (though not clean), as the space in that area is reserved for a ROM that is checked by every single Kickstart version out there. However, the space is only 512k, yet the autoconfig entry shows 8MBytes in size, even crossing that magical 24-bit address space barrier. I suspect that this is a softwrare-added entry using the addconfigdev() function of expansion. I cannot say if this may cause additional confusion, but it's surely worth taking a closer look - hoping that the involved persons are still around.


    One thing I just did is checking the X-Surf-100 CPLD source code. I am NOT storing A31 in that one, The address comparator still looks at the physical address line A31, and de-selects the card whenever it's set. The comment behind this is "upper 2G not available" - I don't exactly remember the context of this comment, but I must have tried putting several Zorram cards into the system, pushing the X-Surf-100 prototype over certain borders (remember this is Xilinx - you have to test each and every Macrocell for proper implementation, as the ISE tool is soooo buggy).


    Here's more information to relay to the OS3.2 team: What I have found when developing the X-Surf-100 (i.e. cards never work if assigned to addresses with A31=1) is likely to also be found by other developers. It is therefore likely that A31 didn't make it's way into the address comparator of many other Z3 cards. I've sent an eMail to Michael, asking if he's looking at A31 in the BigRamPlus CPLD (Michael Böhmer did that; BRP is almost identical to ZorRAM).


    What I did instead is to make a Z3 address comparator for A30 down to A26. With the choice of 64M physical card size, the X-Surf-100 can map to literally any location in the lower 2G area. This specifically includes addresses below $4000.0000, so it may be an idea to start using the lower space before going with addresses above $8000.0000. With Dave Haynie's original Z3 example (also called "Bigram") supporting all address bits in the comparator, and not too many designers being like me (developing against an expansion lib that I expected not to change ever again), it's likely that the majority of Z3 designs will work if mapped to an address below $4000.0000.

  • Got an answer from Michael (summer not happening in Germany appears to affect response times positively):


    Both BigRamPlus and ZorRAM do store and decode A31. It's only four bits for those cards after all, so there was no need for optimizations.


    Edit: On another note, expansion appears to be lacking a feature that it certainly has on Z2: It does not fill the gap in address space that the ZZ9000 left. With the 128M space placed in $4000.0000, I can totally see that the next card with 256M size needs to be mapped to $5000.0000 to be on a natural address boundary. However, the X-Surf-100 would happily fit at $4800.0000. While the OS3.2 guys are on it, they should check why this gap isn't filled, where the "gap willing" works on Z2.

  • Sorry on the dots - I tried. I'm going to try to make it a habit to use them. I could also use a photo of the screen, but didn't want to have to take the battery case off (the data connection is iffy from the wear of daily recharging). I also despise this chicklet keyboard on my laptop - I spend too much time editing, but my desk /workspace is limited.

    I agree the 'gap filling' for cards that are able/willing is something that should always happen - but sometimes doesn't. I've tried to see what the HW RKM says about it, but the last time I read through the pages, it was kind of vague. I do recall there's unimplemented z2 expansion space mentioned that never made it into the 3.1 ROM, but is documented in the 3rd book series. The Z3 space is like the final frontier it's so big, but something just caught my eye in the Amiga memory maps - Nothing should be placed above $8000.0000! Zorro III space is $1000.0000 through $7FFF.FFFF, and above that is all reserved except for the 64K slot at FF000000-FF00FFFF. The fact that a board can operate at/above $8000.0000 is just chance. I think AutoConfig should be using $4000.0000 as the anchor point and placing boards above and below, but it's not.


    I'm still searching for the A1200 discussion, but got sidetracked by someone nearby needing their A2000 given some TLC - they still use it for Audio and video work.


    I'll be linking this discussion so they can review what has been mentioned. I don't have source access, either. I'm only a beta tester.

  • Also, the $00F0.000 is a software insert by the accelerator card. It's the trick the post-C= engineers used to tame the 68060 FPU (The legacy diagnostic / cartridge address that Kickstart checks very early on at startup). It's certainly not 8MB. It's actually a 512K 'card' at best, and the FPU taming code is less than 2K when I went looking for it years ago. The cards that have SCSI interfaces put their registers in that zone, too. The A2000 040/060 TekMagic cards also do their AddMem there. I had thought you might use that kind of trick for the A2630 memory card. It's unofficially a viable solution for any CPU slot card when you have to 'fix' things very early on.

  • and the FPU taming code is less than 2K

    Switching off the FPU of an 060 is a few bytes, definitely under 20. We have that compiled into the FPGA of the ACA1240/1260 :-)

    I had thought you might use that kind of trick for the A2630 memory card.

    That uses standard Z2 autoconfig, but with the trick of claiming the $e8.0000 accesses for the memory card. With that trick, I sneak myself before any other Autoconfig card, because the main board will not see the access to $e8.0000 unless I let it. Unfortunately, I cannot push myself into the 64k space that overlays the Kickstart, hence the limitation to only "MapROM" the physically installed ROM. So yep, this is hacky, but avoids manual addmem in startup-sequence, and actually lets expansion (and other early stuff) reside in 32-bit fastmem, as I'm also mapping to trapdoor space. But.. we're side tracking..

    It's unofficially a viable solution for any CPU slot card when you have to 'fix' things very early on.

    $f0.0000 is the second-most-powerful place to put early startup code into the CPU's way. The most powerful one is what I use on the ACA500plus: I map in a ROM at $00.0000, so I'm in control of vector fetches after reset.

    but something just caught my eye in the Amiga memory maps - Nothing should be placed above $8000.0000! Zorro III space is $1000.0000 through $7FFF.FFFF,

    I have the HRM (the physical book!) here - 3rd edition, along with the RKRMs (all three of them). One of my very first eBay purchases ever, before Y2K! Couldn't find that specific sentence browsing through the Autoconfig/Z3 chapter, but I didn't do a thorough search. Would be nice if you give me a page#, so I can quote that to anyone who says I deviated from the specs by leaving out A31 from the X-Surf-100 address storage register :-) I can't exactly remember what I did to verify that $8000.0000 doesn't work, but I know I've used the A3000T for it's 5 slots at one point, and there's a fork of the X-Surf-100 CPLD project that has the nibbles tweaked to show 1G size. While I told Michael via eMail yesterday that I used that to verify autoconfig, I can't confirm that 100%, as there's no documentation about what I used, and my memory is kinda wiped by sleepless nights caused by three wonderful kids that were born in the mean time...


    My guess is that it's not a problem for the X-Surf-100, as that's small enough (both physical and logical) to be swapped to another slot in case it ever gets mapped to the "wrong" spot. We didn't have a single support case (again, that I can remember) where the X-Surf-100 didn't work for this reason. With a nice 4-digit quantity of these in the field, I prefer to apply "don't fix it if it ain't broke".


    As for my comment to also use the space below $4000.0000, I'd like to see that only being used when an upper boundary has been reached. Reason is that my minimal Z3 implementations on the A1200 accelerators are using no address latches at all. Since I know that my board is the first in the autoconfig chain, my address comparator is fixed at $4000.0000 for those cards. This will of course break if the start address of a hypothetical new version of expansion is lowered.

    I'll be linking this discussion so they can review what has been mentioned.

    Yes, please do!


    Jens

  • That uses standard Z2 autoconfig, but with the trick of claiming the $e8.0000 accesses for the memory card. With that trick, I sneak myself before any other Autoconfig card, because the main board will not see the access to $e8.0000 unless I let it. Unfortunately, I cannot push myself into the 64k space that overlays the Kickstart, hence the limitation to only "MapROM" the physically installed ROM. So yep, this is hacky, but avoids manual addmem in startup-sequence, and actually lets expansion (and other early stuff) reside in 32-bit fastmem, as I'm also mapping to trapdoor space. But.. we're side tracking..

    I had suggested that idea (hiding the motherboard Z2 resources until after config) a few years ago to another developer on the forums when they were just learning the old lessons and pitfalls of Z2 AutoConfig and FastRAM with a 24-bit motherboard and a 32-bit addressing CPU. I still have burn marks from being the messenger, but they (and others) eventually chose that route. You probably pre-dated me on figuring it out, but good to know. The page-zero theft at startup is another good one.


    I have the HRM (the physical book!) here - 3rd edition, along with the RKRMs (all three of them). One of my very first eBay purchases ever, before Y2K! Couldn't find that specific sentence browsing through the Autoconfig/Z3 chapter, but I didn't do a thorough search. Would be nice if you give me a page#, so I can quote that to anyone who says I deviated from the specs by leaving out A31 from the X-Surf-100 address storage register :-)


    As for the A3000D memory map, Appendix D, page 315 (English version). Zorro III Expansion: $1000.0000 - $7FFF.FFFF. Diagram on the next page.


    As for my comment to also use the space below $4000.0000, I'd like to see that only being used when an upper boundary has been reached. Reason is that my minimal Z3 implementations on the A1200 accelerators are using no address latches at all. Since I know that my board is the first in the autoconfig chain, my address comparator is fixed at $4000.0000 for those cards. This will of course break if the start address of a hypothetical new version of expansion is lowered.

    I will make sure it's kept in the mind of the devs as they hopefully address it. Expansion.library was something Thor was very delicate with after I showed up on the 3.1.4 beta team with my laundry list of concerns. The initial transfer to SAS/C compiling from the old Greenwood days apparently gave them headaches when it came to working on the hardware directly. Some things were better done with inline 68K or needed some compiler optimizations worked around. Getting him to add some more hardware delays so fast CPUs did not race past multiple slow LS-rated TTL gates on older cards was all I could hope to get back then. I still have hoped they would open up the space above $009F.FFFF as overflow when the I/O space at $E9.0000 is full, or a small enough card might fit from the 8M space. It's reserved on the 68K machines, but it's actually more I/O space defined on the A3000 - also not implemented in Kickstart 3.1.

    I have asked them awhile back to consider supporting the Z3 expansion spaces on Z2 hosts for z3 cards that appear at the Z2 config space (as A3000/4000 supports, if my memory serves). It would help any of the current CPU card makers AutoConfig their RAM and other resources - being the first card to config, they might have an option as to where they want to be placed - maybe by expressing the base address(es) as an extension. I think the correction to expansion.library mainly applies to the big-box Amiga hosts. I don't think the A1200 needs any further tweaking unless we are talking officially supporting an extended 512K ROM at $E0.0000.

    One thing I'd like them build into any further update is the ability to test for and custom-add the extended ROM space at $E0.0000 - plenty do custom ROMs, and an official support option would be nice (not unlike the $F0.0000 hook). I'm thinking of the people that put them in towers, and that would open up official options for them anyway.