Local slot autoconfig - how?

[Heiroglyph]

I've got a question about A3000/A4000 local slot autoconfig.

There is no CFGIN/OUT on the 200 pin slot as far as I can tell, so how does the SCSI, etc on CPU cards autoconfig?

It would seem that if you responded to the Z3 autoconfig address as if you were the card currently configuring, then the actual first zorro card would conflict and respond as well.

How is it done?

[Heiroglyph]

Almost every non-Commodore A3000/A4000 CPU card has bootable SCSI so there is a way to do this, I just don't know how Expansion.library picks up on it.

Even if the SCSI was mapped to some reserved static location, how does Expansion.library know where to find the ROM?  To autoboot, Expansion has to be aware of its existence.

Anyone?

[Heiroglyph]

That's what I'm starting to think as well.

Respond to the autoconfig address locally until my device is configured, then act like the device has been told to shut up and let the motherboard respond instead.

[Heiroglyph]

It's easy in theory, but there are no documented details on how to do it.  It's easy to say "just add a ROM", but how the heck does it get run?

After talking to Toni Wilen on EAB I'm looking at possibly putting a resident module at 0x00F00000.

Either that or just responding as if its the first zorro card long enough to initialize my ROM.

[Heiroglyph]

There will be an FPGA, so it's pretty flexible.  Id rather not eat into Z3 config space unless I have to, but I absolutely don't want compatibility problems.

It's funny to me that we use CPU cards like this every day for 20 years and we're still not sure how they configure themselves.

You'd think it would be documented somewhere as to what works well and what is a hack.

[Heiroglyph]

Is RAMSLOT limited to 128MB? Couldn't faking a Zorro3 Autoconfig give you a couple gigs of local Accelerator RAM mapped to Zorro memory area, and have Autoconfig know about it when doing real Zorro3 boards? Wouldn't that be a useful thing to do? Though I think there's undefined address space above Zorro3 that wouldn't be able to be used this way. (If RAMSLOT is NOT limited to 128MB, then maybe not useful)

I need to find time to actually read through the slot spec. I've looked at bits and pieces, butg that's been a while too.

The change log for KS3.1 says they expanded the memory check to add an additional 3x256MB, but I haven't tested it on hardware yet.

I'm not planning to use RAMSLOT though, I'd rather decode it myself.

From what I've seen, the Zorro 3 area is actually placed higher than the original spec says anyway, so there is room for 896MB like the changelog says.

I think the A2000 has a CFGOUT didn't it? Or do I remember wrong? My service manuals are buried in storage, I'm limited to what my feeble memory gives me.

Yeah, it did.  Not sure why they removed it on the 3000 other than trying to enforce the suggestion of "storage goes in Zorro, RAM and CPU's go on the local slot".

[Heiroglyph]

Interestingly, the Warp Engine 040 seems to be faking Z3 for the SCSI.

It's mapped as the first Zorro3 card in the Z3 address space and its configuration information looks just like a Zorro3 card.

I guess that validates one way of doing it.

Looks like the Cyberstorm MK3 uses the diagnostic ROM area to configure like Toni suggested.

Since pretty much everything has to work with the Cyberstorms and it doesn't take up zorro 3 space, that sounds like the direct, easy way to go.

No weird address changes needed either.

[Heiroglyph]

I can't remember where I found it, but it's in the kickstart 3.1 change log.

Here is the part for expansion library:

Code: [Select]

expansion 40.2

    - New - A1200 specific build that can detect CPU Slot RAM ($08000000)
if you have a 32-bit addressing CPU installed.  The CPU slot area
is 128meg in size (just like the A3000) but has the addition of
a wrap check at each 1meg of space in the CPU address space to make
low-cost RAM expansion possible without jumpers.  (It is now possible
to get 128Meg SIMMs so a single SIMM on a CPU card could make a
128Meg of FAST RAM system )

The reason that this has to be A1200 specific (at least for now)
is that the behavior of the existing A500/A2000 CPU cards with
respect to 32-bit addresses is very undefined.  They act very
strangely and differently making it very difficult to safely figure
out if these cards are operating correctly or not.

No code changes for anything but the new A1200 version of the
library.  (39.8)

    - Bumped version to V40.  (40.1)

    - Two major bugs found in the A3000 memory test/CPU Card test.
Both were fixed.  (40.1)

    - CPU Card space is now able to be more than 128Meg.  (We can grab
3 * 256Meg more since we don't start Zorro-III until $40000000
anyway...)  (40.1)

    - CPU Card space test now also does mirror testing.  (40.1)

    - Due to the fixes, some forms of the code have gotten a bit smaller,
specifically, the A3000, A4000, and A1200 versions.  (40.1)

    - Reworked the memory test to deal with extra-high capacitance
bus systems.  (40.2)

Accidentally posted too early...

RAMSLOT seems to just be a chip select.  I'm not sure why you wouldn't just decode it yourself, it seems of little help.

[Heiroglyph]

That really only tells me that the access is in the local slots range and as far as I know I'd have to wait on the 25mhz ramsey instead of running at full CPU speed for local accesses.

The local slot docs even mention that if speed is a concern (when isn't it?) you should decode it yourself and ignore RAMSLOT.