English Amiga Board - View Single Post

Shadowfire · 27 February 2017, 03:54

Perhaps I'm missing something here, Tony, but I'm interpreting this as you wish that the Vampire used the Amiga's autoconfig protocol.

On an A500/A600, the _CONFIG line on the expansion slot is tied to ground. If you try and use auto-config on something like the vampire, it will work fine until you plug something into the expansion slot; at this point, both the cpu-socket device, and the expansion slot device, will be talking at the same time when the OS tries to enumerate the expansions (since neither one is aware of the other's presence, which would normally be arbitrated with the _CFGIN and _CFGOUT OR-GATE chains on the big box systems). The same thing applies to anything that isn't sitting on a Zorro bus or in a dedicated coprocessor slot.

So, you have to pick your poison when doing an expansion like this.

1. You can follow Autoconfig, which guarantees a bus collision (and likely nothing working at all) when anything at all is plugged into the expansion bus. This option renders the expansion bus or slot 100% useless, unless (on a slot architecture like the A500/A600; nobody would do this for a bus architecture like the A2000) the expansion slot device ALSO doesn't follow autoconfig and its hardwired assignments don't conflict with what autoconfig does with you.
2. You can hardwire your card address, and pray that the user doesn't plug anything in that gets assigned to the same area (which is what I did with my A500 IDE controller, I used the slot #6 64K I/O block that autoconfig/expansion.library would normally assign, allowing enumeration devices to slots 0-5 (IIRC) before it would conflict - slot 7 is where the devices initially appear before they are assigned an address). You can roll your own software to link a dummy expansion card structure into the system lists, so that the system can see it (which I needed to do to get auto-boot working, although for a RAM expansion you could conceivably skip this step and just AddMem() it if it isn't already in the system memory list and it would work just fine, it just wouldn't show up in Showconfig).
3. You can roll your own autoconfig-alike (in that you can disable it and map the address) hardware, and write an exec module and make sure it shows up somewhere in the memory map that Kickstart will be looking for run-time modules, so that it can get linked into the system lists at initialization time; Exec will call the Init() function, which you can use to set up software to configure your hardware after Autoconfig has done its thing; your software might need to build up a dummy expansion card structure and adds it in with the rest of the expansion.library cards.
4. You can put your device outside of the standard autoconfig assigned address ranges. There isn't a lot of address space like this on 68000 systems, and you also have to roll the configuration software, AND you REALLY don't know if there isn't some expansion memory already there in any given configuration; on top of that, the status of processor caching isn't clearly specified for these locations (or at least I haven't seen any documentation on this; although its pretty common-sense that data caches should be turned off for anything sitting in the Autoconfig I/O address slots and custom chip register spaces).

None of the "has a chance to work if something is on the expansion bus" options involves expansion.library doing the configuration, so I don't understand why you're upset about why they did things outside of Commodore's established protocols; the protocols were never designed for things that sit in the 68000 socket. (Fixing the system for Autoconfig would involve making the user cut the trace to GND on the _CONFIG line, and soldering a pickup wire to the _CONFIG line that runs to the expansion card - a completely unacceptable situation for something you expect to sell to the general public.)

Now, to add my $0.005 to the topic; I agree with Tony that the instruction set expansions are going to fragment the user base. That being said, I know that they want to make a "Modern" version of the 680x0, and this is the first hardware they have with widespread-ish distribution, and by definition, is the only one that has any chance of something resembling testing by people outside the core team, and I think that its a damned fine shoot-for-the-stars project goal. I think that 95%+ of the people that want a vampire, probably don't care about the extended ISA as long as it doesn't break existing software. This is why I'd be very, very skittish about it if I were using the Apollo core, because any changes to the stack frame (such as, extra registers being pushed onto the stack which don't exist on a 68020) are likely to cause serious compatibility issues with existing software, especially the stuff that throws the OS out... like 99% of the existing games do.

(Also, if I were in Tony's shoes, I also wouldn't even give it serious consideration until the Apollo team makes some sort of commitment to lock the implementation and make it work as documented; as our hobby projects, our time may be "free", but there is a finite amount of it, and nobody wants to spend several hundred hours on something only to have to tear it apart and rebuild it months later.)

27 February 2017, 03:54	#30
Shadowfire Registered User Join Date: Aug 2001 Location: Connecticut USA Posts: 617	Perhaps I'm missing something here, Tony, but I'm interpreting this as you wish that the Vampire used the Amiga's autoconfig protocol. On an A500/A600, the _CONFIG line on the expansion slot is tied to ground. If you try and use auto-config on something like the vampire, it will work fine until you plug something into the expansion slot; at this point, both the cpu-socket device, and the expansion slot device, will be talking at the same time when the OS tries to enumerate the expansions (since neither one is aware of the other's presence, which would normally be arbitrated with the _CFGIN and _CFGOUT OR-GATE chains on the big box systems). The same thing applies to anything that isn't sitting on a Zorro bus or in a dedicated coprocessor slot. So, you have to pick your poison when doing an expansion like this. 1. You can follow Autoconfig, which guarantees a bus collision (and likely nothing working at all) when anything at all is plugged into the expansion bus. This option renders the expansion bus or slot 100% useless, unless (on a slot architecture like the A500/A600; nobody would do this for a bus architecture like the A2000) the expansion slot device ALSO doesn't follow autoconfig and its hardwired assignments don't conflict with what autoconfig does with you. 2. You can hardwire your card address, and pray that the user doesn't plug anything in that gets assigned to the same area (which is what I did with my A500 IDE controller, I used the slot #6 64K I/O block that autoconfig/expansion.library would normally assign, allowing enumeration devices to slots 0-5 (IIRC) before it would conflict - slot 7 is where the devices initially appear before they are assigned an address). You can roll your own software to link a dummy expansion card structure into the system lists, so that the system can see it (which I needed to do to get auto-boot working, although for a RAM expansion you could conceivably skip this step and just AddMem() it if it isn't already in the system memory list and it would work just fine, it just wouldn't show up in Showconfig). 3. You can roll your own autoconfig-alike (in that you can disable it and map the address) hardware, and write an exec module and make sure it shows up somewhere in the memory map that Kickstart will be looking for run-time modules, so that it can get linked into the system lists at initialization time; Exec will call the Init() function, which you can use to set up software to configure your hardware after Autoconfig has done its thing; your software might need to build up a dummy expansion card structure and adds it in with the rest of the expansion.library cards. 4. You can put your device outside of the standard autoconfig assigned address ranges. There isn't a lot of address space like this on 68000 systems, and you also have to roll the configuration software, AND you REALLY don't know if there isn't some expansion memory already there in any given configuration; on top of that, the status of processor caching isn't clearly specified for these locations (or at least I haven't seen any documentation on this; although its pretty common-sense that data caches should be turned off for anything sitting in the Autoconfig I/O address slots and custom chip register spaces). None of the "has a chance to work if something is on the expansion bus" options involves expansion.library doing the configuration, so I don't understand why you're upset about why they did things outside of Commodore's established protocols; the protocols were never designed for things that sit in the 68000 socket. (Fixing the system for Autoconfig would involve making the user cut the trace to GND on the _CONFIG line, and soldering a pickup wire to the _CONFIG line that runs to the expansion card - a completely unacceptable situation for something you expect to sell to the general public.) Now, to add my $0.005 to the topic; I agree with Tony that the instruction set expansions are going to fragment the user base. That being said, I know that they want to make a "Modern" version of the 680x0, and this is the first hardware they have with widespread-ish distribution, and by definition, is the only one that has any chance of something resembling testing by people outside the core team, and I think that its a damned fine shoot-for-the-stars project goal. I think that 95%+ of the people that want a vampire, probably don't care about the extended ISA as long as it doesn't break existing software. This is why I'd be very, very skittish about it if I were using the Apollo core, because any changes to the stack frame (such as, extra registers being pushed onto the stack which don't exist on a 68020) are likely to cause serious compatibility issues with existing software, especially the stuff that throws the OS out... like 99% of the existing games do. (Also, if I were in Tony's shoes, I also wouldn't even give it serious consideration until the Apollo team makes some sort of commitment to lock the implementation and make it work as documented; as our hobby projects, our time may be "free", but there is a finite amount of it, and nobody wants to spend several hundred hours on something only to have to tear it apart and rebuild it months later.) Last edited by Shadowfire; 27 February 2017 at 05:51.