Local slot autoconfig - how?

[Zac67]

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.)

[Zac67]

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).

[Zac67]

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.

[Zac67]

_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).

[Zac67]

True. When you're not running synchronously to the mobo it doesn't make sense anyway.

[Zac67]

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.