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?

[Toni Wilen]

Memory/bus controller on CPU slot board remaps Z2/Z3 autoconfig memory region to CPU slot's internal autoconfig location until all on board devices have been configured?

68000 slot (real) fast RAM expansions do something similar.

But... AFAIK most CPU slot boards/A1200 accelerators with on-board RAM/SCSI have boot ROM that adds the ram "manually" without using autoconfig protocol, usually RAM is also hardwired to specific addresses (which wouldn't work very well with autoconfig)

Use ShowConfig (for example) to see if it is proper autoconfig device.

[Heiroglyph]

For RAM I understand how it works, I can hard wire it to 8000000 and it will be detected.

What I don't understand is how things like SCSI drivers in ROM are added through this slot.

To boot from it, the SCSI driver on the local slot has to have a proper ConfigDev structure in the ExpansionLibrary devices list so that it is considered in the boot priority.

But how do you do this manually?

Originally Posted by Toni Wilen

Memory/bus controller on CPU slot board remaps Z2/Z3 autoconfig memory region to CPU slot's internal autoconfig location until all on board devices have been configured?.

Thinking about what you said here...

Are you saying that if a local slot device responds to the address $FF000000 as if it was the first Z3 autoconfig device, that since it is on the CPU's local bus, mine would be the only device given the chance to respond?

After configuration this device could shut up and stop responding at that address, allowing the real zorro devices to respond in turn as usual.

I suppose that at worst, I could add logic to ignore that address on the motherboard until after my device had configured.

[SpeedGeek]

A3000/A4000 local slot config is not Zorro bus Auto-config. There are other ways devices can self configure without following Zorro bus protocol. For example, local slot fast memory is configured by RAMSLOT address decoding courtesy of Fat Gary and Kickstart bonus code. However, accelerator boards can also implement proprietary "self configure" methods as well.

[Toni Wilen]

It meant that they may not have multiple autoconfig devices but only a single fake autoconfig "device" which is only used to call boot rom code (via diag vector) that internally calls AddMemList(), initializes scsi device driver etc..

There is also another way, 0x00F00000 ROM area which is automatically scanned for resident structures. (Used at least by some Blizzard boards)

[Heiroglyph]

Originally Posted by Toni Wilen

It meant that they may not have multiple autoconfig devices but only a single fake autoconfig "device" which is only used to call boot rom code (via diag vector) that internally calls AddMemList(), initializes scsi device driver etc..

So if I went this route I would respond as a Z3 or even Z2 device as above, but my ROM code would do it's own setup, adding any structures and devices needed.

Since my real devices wouldn't be autoconfig, I could then use the reserved area above Z3 for my devices to avoid taking up any more of the limited autoconfig space than my small bootstrap ROM needs.

I suppose that as long as my code gets run, I could act as if I didn't actually configure and take no autoconfig space at all.

Does this sound right?

There is also another way, 0x00F00000 ROM area which is automatically scanned for resident structures. (Used at least by some Blizzard boards)

Wouldn't this conflict with 1MB Kickstarts or am I looking at it incorrectly?
Edit: I was looking at it wrong, I didn't realize that the ROM halves were not mapped next to each other. This is a very appealing way to go IMHO.

Could this conflict with anything? It would seem very rare to use this location unless you are another CPU card or diagnostic cards that are not in general use.

Thanks, I really appreciate this input.

[Heiroglyph]

The Warp Engine 040 seems to be faking Z3 for the SCSI so that looks like a valid way of doing it.

I'll try to get more info on other cards, but so far that's pretty easy to set up and decently documented other than the configuration address trick.

[Heiroglyph]

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.

[Toni Wilen]

Small warning about diagnostics ROM area usage: It is also possible to use that area for IO but it is very bad idea because MMU setup done by 680x0.libary may not mark it uncacheable == bad things happen, sooner or later.

Expansion device IO regions should always be Z2 or Z3 boards.

[SpeedGeek]

Agreed Zorro2 or Zorro3 I/O space is a better place to configure expansion devices (except memory expansions) than diag ROM area. However, any non-Zorro bus based device should provide it's own cache disable function in hardware. 680x0.library works on MMU equiped CPU's but what about 68EC040/060?

[Toni Wilen]

Originally Posted by SpeedGeek

Agreed Zorro2 or Zorro3 I/O space is a better place to configure expansion devices (except memory expansions) than diag ROM area. However, any non-Zorro bus based device should provide it's own cache disable function in hardware. 680x0.library works on MMU equiped CPU's but what about 68EC040/060?

They should but it does not appear to be true.. For example 68060 + FastATA Z3 (at least some versions) hang during HD detection and Blizzard SCSI Kit driver crashes if its IO location (It is 128k Z2 board) is not uncacheable.

I noticed these issues when working with m68k AROS. (I wanted to have all caches enabled earlier just because it would be nice. AOS only have code caches enabled until c:setpatch does its job)

MMU tables that mark IO regions uncacheable fixed both problems 100%.

I think I read somewhere that non-MMU 040/060 is not recommended because of above issues with some boards. Or something like that.

[Heiroglyph]

That makes sense, I'll check into exactly what the cyberstorm is doing.

I assumed that I'd need to use CIIN to mark them as uncacheable.

The approach the warp engine took is pretty straight forward too and would give me none of those issues.

I guess that with lots of RAM and an I/O device on the local slot, using a little Z3 space isn't such a bad thing. It's really just zorams that eat up all the z3 space and this would negate the need for them.

Regardless, I now know two good ways of accomplishing what I needed so I have choices.

Thanks again.

[Toni Wilen]

Originally Posted by Toni Wilen

I think I read somewhere that non-MMU 040/060 is not recommended because of above issues with some boards. Or something like that.

Found it, it was AmigaMail article: http://amigadev.elowar.com/read/ADCD.../node0161.html

"The 68040 and Zorro III" chapter.

[SpeedGeek]

The above article was interesting but inaccurate on the vitually non-existant problem of burst mode caching. While CIIN may not be able to abort a burst cycle to non-cachable addresses' it really never had to. There are no known 3rd party 040/060 accelerators which support burst mode to any motherboard resource. Most 040/060 boards use an asynchrounous design which made burst mode unuseable except to local fast memory which is cachable. Even the C= A3640 (one of the very few synchrounous designs) never did and never will support burst mode. So CIIN was always a practical way to disable cache for non-cachable address'. Also, TBI (040) or CBACK (030) could easily be logically OR'ed with CIIN.