Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Heiroglyph on August 11, 2011, 06:05:43 AM
-
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?
-
There's no AutoConfig since resources are reserved statically, no Z3 involved. CPU card resources outside memory (128 MB) are not visible from the mainboard - there's simply no way to select them. (RAM is required for Z3 DMA to work.)
-
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?
-
CFGIN is just a chip select line mapped to the Zorro II or Zorro III configuration space. You can generate it locally and not pass through access to the configuration space on the motherboard until all of your local devices are configured.
-
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.
-
Actually it's pretty easy.
A Z2/3 SCSI board has two autoconfig components: the logic and the boot ROM. Zorro passes over all boards present and configures them. Then it picks up the boot ROM and lets it link the driver into the system.
A local slot board misses the autoconfig logic (hence no CFGIN / CFGOUT) and just presents the boot ROM to the system (after configuring its hardware through some magic of its own - there's no bus / address space sharing with any other hardware it has to care about).
-
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.
-
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?
You can either overlay your bootrom so it gets run before kickstart or put rom at 0x00F00000 (I think). From here you can add resident modules in ram that will get picked up later on.
It's possible to overlay the autoconfig space with your own hardware until it's configured and then pass the reads/writes on to the main board. It's probably harder to do this though.
You could get the board to write resident modules to chip ram.
If you're really crazy you can temporarily overlay part of kickstart rom so that when it scans for resident modules then it finds yours too. However you may have compatibility issues with different versions of kickstart.
-
CFGIN is just a chip select line mapped to the Zorro II or Zorro III configuration space. You can generate it locally and not pass through access to the configuration space on the motherboard until all of your local devices are configured.
I hadn't realized the CPU slot didn't have a CFGOUT. Weird and surprising.
I do think Mongo's solution is easiest. If you have an FPGA sitting between the slot and your CPU, then this is easy to do. If the CPU would be going direct to the slot, you may need some enabled buffer or something in between to prevent the first autoconfig accesses from reaching the motherboard and the first Zorro card. (The FPGA if between slot and CPU would be this enabled buffer in that case) I'm not sure if that would be an enable buffer on the address lines out of the accelerator or some other signal.
-
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.
-
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.
You wouldn't even need to "act like shutup". You could have an accelerator with however many local Autoconfig devices on it, and use the usual CFGOUT/CFGIN chain between them, masking this from the motherboard until the accelerator is done. Once a device is Autoconfigured, it no longer responds to the Autoconfigure accesses. The first local device is done, and then it ignores Autoconfig accesses. The second local device is given CFGIN signal from the first, and it is the one to respond to Autoconfig, then third, forth, on to whatever N devices are local to the accelerator. All this time Autoconfig needs to be hidden from the motherboard, since the Zorro bus won't know that the accelerator has devices to autoconfig.
Only after all autoconfig devices known on the accelerator are done does the accelerator allow Autoconfig accesses to reach the motherboard, at which point the motherboard thinks it's the first Autoconfig to happen. Accelerator devices are done now, so they ignore all Autoconfig accesses happening with the motherboard.
Before a device is Autoconfigged, the base address of all devices is the Autoconfig base address. There are two of these Autoconfig base addresses, one for Zorro2 devices and one for Zorro3 devices.
As there are two Autoconfig runs, one for Zorro2 and another for Zorro3, choose which your accelerator will be part of. Or which one each of your local accelerator devices will be part of. Theoretically you could have some of each, but that'd probably be an odd thing to do. Choose the one that makes most sense. If you do have some of each, you'll have to trap Zorro2 Autoconfig local until done then pass that one on to the motherboard, and separately trap Zorro3 Autoconfig until done and then pass that on to the motherboard.
After a device has completed Autoconfig, it's base address to respond to changes to that assigned by the OS, so any Autoconfig access won't fit into the device's assigned address range. Nothing terribly special to do here in ignoring an access that doesn't belong to this device.
The CFGOUT/CFGIN chain tells the devices which one is currently up for Autoconfig. If a device is not yet done, and sees it's CFGIN valid, this device knows it's time for it to respond to Autoconfig. All other devices not yet done see their CFGIN as off, and continue waiting for their turn, ignoring Autoconfig accesses until it's their turn to go. At the end of an Autoconfig run for a device, the device turns on its CFGOUT so the next device knows to go on the next Autoconfig access.
The problem at hand is the chain is broken between the Accelerator and the motherboard. Perhaps Commodore didn't intend CPU cards to have local devices to Autoconfig. A strange notion as there had been A2000 Accelerators with Autoconfig memory, or at least hard-coded memory by then. You'd think they'd have seen that as a big hint that Autoconfig on the CPU board is important.
And thus we must trap and mask Autoconfig, keeping it away from the motherboard until the Accelerator knows that everything local is done. The last CFGOUT in the local Accelerator chain means you can now allow Autoconfig to go onto the motherboard.
-
I'd have thought there's a fast slot device address space select line of some kind (there's _RAMSLOT for the 128 MB expansion) - _RMC? - that selects the devices you bring with you, possibly useful for activating a ROM somewhere up high. Where are those Cyberstorm/whatever ROMs located at?
If it isn't done that way mongo's suggestion sounds nice as long as you don't pass anything serious to the mobo until your stuff is configured. May be a bit of a pain to have that logic dragging along all the time but you can short-circuit it once you're done.
@billt
There's no need to fake Zorro III devices. You'll just have to make sure your ROM 'located up high' is temporarily mapped into Zorro space and initialized. The 'fake' ROM sets up the real one and you have no need to compete for Zorro I/O space at all.
-
I'd have thought there's a fast slot device address space select line of some kind (there's _RAMSLOT for the 128 MB expansion) - _
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.
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. :(
-
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".
-
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.
-
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.
I wonder if 3.5/3.9 updates changed anything further?
Where does one read about this ramslot n 3.1 etc?
-
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:
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.
-
_RAMSLOT saves you the hassle of decoding yourself, of course it's possible (you'll need to block _AS to the motherboard though to make sure nobody else is answering).
-
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.
-
True. When you're not running synchronously to the mobo it doesn't make sense anyway.
-
This thread is a very nice read for someone who is trying to get some level of understanding about the Amiga hardware, AUTOCONFIG, etc.
I could only find the local slot documentation here:
http://www.thule.no/haynie/systems/amiga3k/docs/a3kcpu.pdf
Is there any additional documentation available that anybody is willing to share?
@Heiroglyph, curious to hear what you're working on!
-
First an unrelaited fact I got from a guy at Amitrix about a ram card they were working on.
The CDTV's diagnostic connector doesnt have autoconfig and they added the memory by having a timed delay so after x milliseconds any read from the autoconfig address is taken as being aimed at the card.
Now I would think there was a time out on the autoconfig process but as the cfg line is simply passed from board to board there may not be.
The second way is to assume before presenting the first board with a cfgin sig it looks at the autoconfig address and sees if anythings there. It would account for any CPU slot board being first on the list .
As for the ram CS line on the fast slot, still use it as that 128Meg is fixed and if not used you have lost 128Meg of address space for no reason.
-
Since you're living on our own bus you can simply emulate autoconfig for your onboard devices and start to pass it to the mainboard once you're done (think we had that before) - no need for hacks. ;)
That CDTV hack you mention seems to be faking autoconfig where it isn't possible for real (pretty dumb to miss that since autoconfig just takes a single gate per slot). There must be a little more to it than that - you'll need to do the fake after the last (real) board is configured (otherwise they'd be trying to configure simultaneously) - I guess it isn't too easy to detect the last board but there probably is a pattern to react to.
_CFGIN doesn't time out, it's more beautiful than that. _CFGIN is driven by the previous _CFGOUT ORed with the previous(!) _CFGIN. _CFGOUT is pulled low by the mainboard but driven high by an unconfigured board - that way delaying the _CFGIN for the next board if present.