27 March 2018, 06:22 | #1 |
Registered User
Join Date: Jan 2015
Location: Melbourne, Australia
Posts: 548
|
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? |
27 March 2018, 06:33 | #2 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,632
|
It's fully documented here:
http://amigadev.elowar.com/read/ADCD.../node028B.html and here: http://amigadev.elowar.com/read/ADCD.../node0414.html |
27 March 2018, 17:18 | #3 |
Registered User
Join Date: Oct 2017
Location: Germany
Posts: 193
|
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 |
28 March 2018, 01:21 | #4 |
Registered User
Join Date: Sep 2017
Location: birmingham, uk
Posts: 548
|
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 |
28 March 2018, 10:33 | #5 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
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 |
28 March 2018, 10:36 | #6 |
Registered User
Join Date: Jan 2015
Location: Melbourne, Australia
Posts: 548
|
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.
|
28 March 2018, 10:49 | #7 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
|
28 March 2018, 10:53 | #8 |
Registered User
Join Date: Jan 2015
Location: Melbourne, Australia
Posts: 548
|
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...
|
28 March 2018, 11:04 | #9 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
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...?
|
28 March 2018, 11:05 | #10 |
Registered User
Join Date: Sep 2017
Location: birmingham, uk
Posts: 548
|
Deadalus remember IRQ ? lol.
|
28 March 2018, 11:09 | #11 | |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
In the old ISA days? Haha, ugh...
As for SIO/USB: Quote:
|
|
01 April 2018, 20:53 | #12 | |
Hittin' the hardware...
Join Date: Feb 2002
Location: Mountain View, CA
Age: 44
Posts: 156
|
Quote:
|
|
01 April 2018, 21:46 | #13 |
Semi-Retired
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 2,001
|
Except expansion.library ignores $10000000-$40000000 so cards start at $40000000. At least on 3.9.
|
01 April 2018, 22:34 | #14 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
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. |
06 April 2018, 02:11 | #15 |
Registered User
Join Date: Mar 2017
Location: Rhode Island / United States
Posts: 201
|
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. Last edited by thebajaguy; 06 April 2018 at 03:12. |
06 April 2018, 02:26 | #16 |
Registered User
Join Date: Mar 2017
Location: Rhode Island / United States
Posts: 201
|
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.
Last edited by thebajaguy; 06 April 2018 at 02:52. |
06 April 2018, 11:24 | #17 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
Quote:
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. |
|
06 April 2018, 14:13 | #18 | ||
Banana
Join Date: Jul 2016
Location: Darmstadt
Posts: 1,214
|
Quote:
Still very stable, btw. Excellent work. Quote:
|
||
10 April 2018, 10:45 | #19 | ||||
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,336
|
Quote:
Quote:
Quote:
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. Quote:
|
||||
10 April 2018, 11:26 | #20 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,510
|
Quote:
Quote:
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) |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Autoconfig + /DTACK | Graz | Hardware mods | 4 | 04 October 2015 21:29 |
indirect Filesystem autoconfig | Leandro Jardim | support.WinUAE | 5 | 09 September 2015 12:54 |
WinUAE-Debuuger: Memwatchpoint and AUTOCONFIG | selco | support.WinUAE | 2 | 16 March 2015 10:19 |
Local slot autoconfig - how? | Heiroglyph | Hardware mods | 13 | 14 August 2011 15:17 |
Amiga 2000 autoconfig prob | Scarab | support.Hardware | 5 | 04 March 2005 16:14 |
|
|