How does autoconfig actually work?
 

I thought this was a suitable place for such a discussion, if not, I apologise.

Can anyone give detail as to how autoconfig works exactly, and the differences between Zorro 2 and Zorro 3?

It's fully documented here:

http://amigadev.elowar.com/read/ADCD.../node028B.html

and here:

http://amigadev.elowar.com/read/ADCD.../node0414.html

You can have a look at my 68000 accelerator with AutoConfig FastRAM for a real life implementation. If you can understand Verilog it will be helpful.

https://github.com/PR77/A500_ACCEL_RAM_IDE-Rev-1

Autoconfig is what it is auto config , in really simple and probably leaving some technical words at the pub, in as much layman terms as possible the Amiga queries the expansion bus with addresses which any card listening to said addresses can respond with values in the bidirectional data lines regarding product id, size of memory etc in which case amiga listening for a response intercepts the values and thus a board has been configured , multiple boards can be configured this way and it's possible to collide with other manufacturers so a list is online to avoid said collisions.

otherwise the above posts are a good read , especially the verilog from pr77 :)

Yeah, that's the general idea. For the general details, the process is as follows for Zorro-II and Zorro-III:

- A Zorro device doesn't do anything until it receives a special Autoconfig signal
- When that signal is active, the device will respond at a special "config" address ($E80000 in 24-bit space for Zorro-II, $FF000000 in 32-bit space for Zorro-III)
- The OS reads the card's details, including its manufacturer ID, product ID, presence of a driver ROM, requirements for memory space and the type of card (RAM or I/O, noting that cards with RAM buffers to be addressed directly by the OS such as graphics cards will need to configure as RAM)
- The OS decides if the card can be used. If it can:
- If a ROM is present on the card, the OS copies the relevant contents (e.g. a device driver) to RAM
- The card will be given an address in the appropriate space ($200000-$9FFFFF for Zorro-II RAM cards, $E90000-$EFFFFF for Zorro-II I/O cards, or $10000000-$7FFFFFFF for Zorro-III cards)
- The card stores this address and responds to the new address until the system is reset
- The card passes the Autoconfig signal on to the next card in the machine (this may also be a logical card on the same physical card - e.g. many graphics cards appear as two cards - one of I/O type for control commands and one of RAM type for the video RAM)

If the OS cannot use the card (e.g., no memory space left):
- It sends a special "Shut up" command to the card
- The card passes the Autoconfig signal on to the next device
- It then does nothing until the machine is reset

- This sequence carries on until all boards have been configured. Once that's done, the machine will continue the boot process.
- If the cards have contained appropriate autoboot ROMs, the relevant devices will also be queried for bootable devices.
- When the system is booting, the BindDrivers command is typically run during the Startup-Sequence.
- This will check for any drivers in the SYS:Expansion drawer and compare them to the configured Zorro cards
- If a matching manufacturer and product ID are found for a driver, that driver is loaded into RAM from the Expansion drawer (replacing any already present, e.g. from a card ROM, allowing card-based drivers to be updated in software)

That's about it :)

Fantastic, thank you so very much everyone, this has all been very helpful and I appreciate everyone's responses. It seems like a pretty darn clever system to me.

It really is a nice, elegant solution, and is actually very close to what was later used (and is still used) for PCI.

I know this is offtopic here, so I'll keep it brief, but that makes me think of SIO on the (Yes, I know, but they are the direct ancestors to the Amiga) Atari 8-bit machines - 400/800 etc - and how it isn't a billion miles different in some aspects to what we now have in USB...

Indeed, that's a similar situation - in fact, I'm pretty sure the early USB developers quoted the Atari SIO as inspiration. Where did I read that...?

Deadalus remember IRQ ? lol.

In the old ISA days? Haha, ugh...

As for SIO/USB:

From Wikipedia. Joe Decuir was one of the key designers of USB 1.0...

That is wonderful, thanks for sharing! I just spent an evening reading the A500/A2000 TRM (a great reference for autoconfig) and pondering a quick hack to connect one of those SEEED XC9572XL boards to the side expansion. No excuses now! :)

Except expansion.library ignores $10000000-$40000000 so cards start at $40000000. At least on 3.9.

All OS versions use $40000000 Z3 start address. Officially ends at $7fffffff but only OS 4.x enforces it. 2.x/3.x won't care. (UAE has hack to force Z3 start at $10000000, mainly for better JIT compatibility, only useful today without 64-bit host OS)

Also many Z3 boards will appear at $e80000 before getting configured to Z3 space. $ff000000 is not mandatory for Z3 boards.

A tip of the hat to Daedalus on the AutoConfig explanation. Detailed enough for most to understand, and for the most part, accurate. I did have two items I thought weren't quite right.

As far as I recall (and I am talking as far back as my GVP Tech support era 1989-1993), a board that already has a driver from a ROM won't be affected by a SYS:Expansion driver activated by Bindrivers - i.e. during startup. I can't recall any board I ever encountered from 3rd party or C= offerings in that one driver replaced another this way. As far as I know, when a driver gets bound to a board, that board is no longer polled by expansion.library when another driver comes along and seeks to mate. There was a tendency to drop a controller driver into SYS:expansion, a holdover from the KS 1.2 days and floppy boot/then transfer SYS: and assignments to a HD partition. I remember even that, but it was a way to make sure if the user made another boot disk that they had the driver handy in that named folder. All patch-update functions to drivers are either via SetPatch, or via a piece of code built to directly patch the driver (presumably with vectors already in RAM) called from CLI/Startup.

The other item I question is the onboard ROM copy to RAM. I clearly recall all Commodore A2090a/2091 initial drivers, and GVP (v1.0-v2.3 class) dual-ROM offerings didn't have their ROM code copied to RAM. There was even a CARDROM definition/option in the Dave H. pre-KS 2.0 SETCPU tool to arrange moving the driver of the CARDROM-defined board (there were many besides C= and GVP) into presumably 32-bit memory space with the MMU helping. I know that when Ralph Babel created GVP's v3.x and later single-ROM drivers (including GuruROM), it is executing from an 8-bit addressed memory space (16K of address space, 8 or 16-bit wide) on the card. That driver then has it's own code that copies it's relevant parts to what is (hopefully) the fastest (i.e.- highest-priority) RAM in the system, which one hopes is fast 32-bit. I remember having this very conversation with Ralph in 1990 when the first single-ROM v3.x was burned for the original -2-ROM Impact cards. If the ROM driver wants to be executed from ROM, it will, by default.

Back in the early days, RAM was expensive, and 16K of RAM was saved by keeping it in ROM (instead of ChipRAM - all that some had) made sense. After controller+RAM offerings became the majority, having the driver in FastRAM, preferably 32-bit RAM (if present), was best.

Also: It doesn't matter if a ROM (or ROMs if paired) are on a different board, and later found after the hardware is configured. Provided the ROM address/data line decode is the same, and the board's ROM address space is large enough for the ROM code, you could, in theory, put C= 7.0 ROMs on an original GVP Impact HC, or a Microbotics HardFrame board, and it will seek out an A2091 when activated. I've put a GuruROM on an I/O extender ROM socket, and it finds the A2091 and the GVP Series II boards just fine.

On the hardware side, the A500/1000 86-pin edge expansion connectors Config-out signals are grounded, making them auto-config enable signaled to what is connected. The 86-pin CPU slot of the A2000 has it's config input grounded much the same, making it first active, if present, at $E80000, and when done hands it off to the expansion slot logic. The A2000 Rev 6.2 schematics, page 7 (expansion bus), U606 at the top, then have all of the AutoConfig signal In/Out circuitry going through it on each slot's pins 12 and 11 of the various 100-pin expansion slots.

This is not guaranteed to work, it only works if boot rom:
a) ignores device base address that diaginit routine gets (because it would point to "wrong" board), some boards may use it to reset some IO registers.
b) main rom code uses FindConfigDev() to find the board, not GetCurrentBinding() (which would return "wrong" board)

So basically it means it works if ROM is designed to support multiple boards even if not all boards have boot rom installed.

This is presumably why you & Toni had to do special tricks to make the 'matze' RTG graphics card work with your Zorro adaptor and the ACA500+'s Fast ram?

Still very stable, btw. Excellent work.

There's a thing on aminet to move the A2091 ROM to FAST. I assume this'll also work on the A590; I intend to try it out once I get a chance.

Hmmm, interesting. My understanding was that it would override the ROM, provided that driver wasn't already in use (i.e., a storage drive with a volume mounted), but it is a long time since I've looked into that end of things. I must look at this again...

From what I can tell, it depends on the intention of the driver. If it is to execute code (e.g. to patch something in Kickstart) as opposed to simply presenting a DOS node, then it will present itself as a diag module, which is copied to RAM and executed. This isn't necessary for a simple device driver, but could still be done for performance reasons if desired. I honestly don't know which boards did this or which kept it in the ROM in Zorro space, but it was definitely a part of the expansion initialisation routine - I guess I should have pointed out that it was just an option.


Toni did the special tricks, I just did testing/troubleshooting ;)

Sort of, the problem with the ACA wasn't really to do with the RAM, but to its support for A1200 accelerators, which don't really play by the Autoconfig rules. Essentially, the accelerator had its own internal Autoconfig routines that would also trigger the actual Zorro-II hardware Autoconfig in parallel (since they both had the same unconfigured address), so only one would get recognised.

Great to hear, thanks :great

BindDrivers skips configdevs that don't have cd_Flags CDB_CONFIGME bit set (="I don't have driver yet"). Expansion.library always sets it. ROM driver normally clears it. If autoboot is disabled, BindDrivers loaded driver clears it (if matching driver was found).

More practical reason:

Part of ROM is always copied to RAM (Expansion.library checks DiagArea to find size and type of ROM) but reason why driver part of ROM is copied is very simple: ROM needs to be at least 16-bit wide to be executable, most boards use single 8-bit ROM (A590/A2091 uses 2x8 = rom is executable) and define only small DiagArea (with nybble wide size because of KS 1.3 byte-wide expansion bug), tiny "loader" code allocates memory, copies rest of ROM to RAM, using byte copy (to save ROM space, nybble wide would waste half of ROM). This also explains why nearly all 8-bit autoconfig ROM dumps have corrupt looking data at the beginning (nybble-wide part) with the rest of ROM looking normal. (clear ascii text, m68k code)