English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware > Hardware mods

 
 
Thread Tools
Old 11 August 2011, 08:04   #1
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
Local slot autoconfig - how?

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?
Heiroglyph is offline  
Old 11 August 2011, 10:00   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,500
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.
Toni Wilen is offline  
Old 11 August 2011, 17:10   #3
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
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?

Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by TCD; 11 August 2011 at 17:23.
Heiroglyph is offline  
Old 11 August 2011, 17:55   #4
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 56
Posts: 485
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.
SpeedGeek is offline  
Old 11 August 2011, 17:56   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,500
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)
Toni Wilen is offline  
Old 11 August 2011, 18:31   #6
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
Quote:
Originally Posted by Toni Wilen View Post
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?

Quote:
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.

Last edited by Heiroglyph; 11 August 2011 at 19:10.
Heiroglyph is offline  
Old 12 August 2011, 05:27   #7
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
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 is offline  
Old 12 August 2011, 06:59   #8
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
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.
Heiroglyph is offline  
Old 12 August 2011, 09:07   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,500
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.
Toni Wilen is offline  
Old 12 August 2011, 18:05   #10
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 56
Posts: 485
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?
SpeedGeek is offline  
Old 12 August 2011, 18:22   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,500
Quote:
Originally Posted by SpeedGeek View Post
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.
Toni Wilen is offline  
Old 12 August 2011, 19:07   #12
Heiroglyph
Registered User
 
Join Date: Jun 2010
Location: USA
Posts: 88
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.

Last edited by Heiroglyph; 12 August 2011 at 19:07. Reason: didn't finish my sentence
Heiroglyph is offline  
Old 13 August 2011, 19:14   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,500
Quote:
Originally Posted by Toni Wilen View Post
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.
Toni Wilen is offline  
Old 14 August 2011, 16:17   #14
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 56
Posts: 485
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.

Last edited by SpeedGeek; 14 August 2011 at 16:29.
SpeedGeek is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Amiga 4000 Local Slot pin configuration? Geijer Hardware mods 3 12 November 2011 20:15
Help converting an 8bit ISA slot to 16bit ISA slot Smiley support.Hardware 4 25 April 2006 12:20
Amiga 2000 autoconfig prob Scarab support.Hardware 5 04 March 2005 17:14
OS 3.9 romupdate causes autoconfig data to dissapear, how to resolve that? keropi support.Hardware 3 17 January 2005 17:46
Which slot is the video slot ? THX1138 support.Hardware 13 21 November 2003 13:35

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09019 seconds with 13 queries