Two BigRAM+ cards.

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

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.

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.

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.

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

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.

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.

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

Quote from Jens

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.

Quote from Jens

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.

As a note - we were recently granted some post-3.2 bugfix/updates to begin to check out. Nothing new yet in the areas of expansion, exec.