3.1.4 and Autoconfig

vibros

New member
Joined
Sep 28, 2009
Posts
2,067
Country
Italy
Region
Emilia-Romagna
Hello,

do you know if there is some issues with Autoconfig and zorro cards, with this new version of OS?
And if there is some materials for developer free?

Thanks in advance
Stefano
 
So far I haven't noticed any cards of mine acting strangely with OS 3.1.4. I have a very expanded Amiga 2000 and 4000.
 
Last edited:
I did a lot of testing of the 3.1.4 AutoConfig in the beta. It is actually cleaner than it was in all previous versions. We kicked some bugs that have been around (technically) since KS 1.2/1.3 - although, in all fairness, the CPUs needed to uncover them weren't around until the early 1990's. In particular, we cleaned up a number of race conditions that affected high speed CPU cards (040/060) combined with some pokey PICs - in effect, expansion hardware being too slow for the newer CPUs execution of expansion.library. There are now definitive delays between the read and write of a card's registers, and between cards handing off the AutoConfig signal to the next slot (both in Z2 and Z3 space). There was also some cleanup done on last-board/full 8M space that someone else found. Just know that designers should make their boards be able to be 'shut up' (disappear), but alas, some older hardware was never able to. A board that can't be shut up (because there's no space left) halts AutoConfig of the next board that might be able to fit if of a different type. The biggest culprit are the big 8M space cards (it's easy to over-fill that space).

I personally know of one bug that remains in Z2 config, but it's an extremely rare 'full Z2 I/O space' issue, which means you have to try to overfill the $E90000-$EFFFFF I/O zone, and also have cards that are not able to be 'shut up'. I happen to have a few rare I/O boards that consume 128K I/O slots (you wouldn't normally have 2 of them in a system) instead of the typical 64K, and a few multi-function cards that combine with them to make the perfect storm. It's actually impossible to overfill a large back plane (A2000, 3000T/4000T) with only 64K PICs (you have 7 64K windows, and at best 6 slots) even with the CPU slot and the cards currently available.

The 3rd Edition of the Hardware Reference Manual (the 5-book RKM set) still applies - there are online copies scanned that you can browse or download (PDF), although paper copies (which I prefer) won't be free unless you are opportunistic and lucky. Combined with (optional) SAS/C 6.58 (6.50 + 4 patches) or ASMOne, and the Amiga OS updated headers and includes posted on Aminet since 3.1.4 release, you will have what you need.
 
Last edited:
Hello,

thanks to all of you! I will read carefully your reply to understand if this is the case.
I have started this thread because a test of my ide card, done on a 3.1.4 system, has poorly failed. So i have read the spec. of this new 3.1.4 and read the sentence on the Hyperin's site '...it has more robust Autoconfig' i was feared about some incompatibility with the code inside my own card (made by me, look at my thread for IDE@ZII).
Later i have discovered that, the 3.1.4 was not the point, the issue on a test made on an A4000D was on the machine itself.

Many thanks

Stefano
 
Last edited:
While we went through testing, one thing to keep in mind was that with the A3000 (and presumably the A4000), the SuperBuster and the bus buffers can present a challenge when you try to poke/read at actual hardware (i.e. bi-directional registers). There are some instances, as put by some former Commodore and 3rd party engineers, where some of the bus buffers get 'sticky'. One might read a phantom value from the previous write cycle to a register. It's been suggested that hardware mirror it's registers (make one set read, the other set write), and even provide byte-swap versions of them if there are Big/Little Endian conversions involved, to ease the chances of the bus ghosts appearing. One may have to build a definable delay before performing a read off a card too soon off of a write, as circuit propagation delays were rarely an issue with the Zorro II/68K's 4-cycle (or more) 7Mhz propagation and possible code overhead, but a 68040/68060 running from an instruction cache and a high clock speed can potentially get back to that board very quickly, as in the next valid bus access.

There are some pitfalls (in general) one should account for between the different CPUs. This came out of some Zorro III discussions. One I recall is a recommendation that all registers be safe to read or write a 32-bit long word valuie, and that they appear on 32-bit long word boundaries, or even quad-longword boundaries, if performance is an issue. The 040 and 060 don't have the bus-sizing logic the 68020/68030 do, hence the 32-bit long word alignment, and of course the 68000/10 needs/prefers most everything aligned on 16-bit words.

I'm not privy to the actual code, but this is AutoConfig: A PIC is signaled to appear at the address for configuration (in Z2, this is $E80000) with the CFG_In line. Expansion library code reads the board's identifiers and requirements (maker, model, board type and size, can it be shut up, and if there is a diag ROM - (i.e. - driver) to be accounted for/activated later, and is there another on-card board (chain config) behind it, etc. Upon deciding where it can go, expansion.library writes it's configuration destination base address to the PIC and the card relocates there. The programming of the address causes the board to (if the last in the on-card chain) signal it's CFG_Out for the next card to appear at the config address. An on-card chained config would presumably act similar. Later on, expansion.library activates ROMs and allocates further resources based on driver needs.

I don't believe the OS's board config structure changes at all. Olaf Barthel (involved in the 3.1.4, also) has noted to me recently that the OS 3.5 developer updates are the (overall) current ones, and minor updates for things like the RDB and FFS structure additions are in the latest includes on AmiNet. I'm working on an updates FastPrep/ExpertPrep, and I need to deal with >32-bit integers now (large disk and partition geometry) and things like the SCSI_Direct flag for the FFS.
 
Last edited:
Hello,

i have read your reply (more times to be honest), and to link solutions to the fact that my IDE card, by someone poorly tested in a A4000D (sometimes not seen by the system and sometimes with issues with 040 cpu, like read/write errors); where actually two of them are in my plain Amiga 3000 and are used daily without any issue (by the way, is useless a card that give I/O errors!); i come to the conclusion (this card is a Zorro II card, so, as 'Slave' PIC, is the buster responsable of the cycle timing of the CPU, whatever it is) that the resistors used for the comparator to the Zorro II address are not right in value. I have used sometimes 8k Ohm for the lines with value 'one', where some old card use 10k Ohm and a well know USB card uses about 50k Ohm! My card in a A4000 fails with expecially third parts daughterboard, where in my system work rock stable.
Or far more realistic, a defective solder joint (the card was seen by the system, at first shot, then the tester has reported, later, issues): i have soldered all the parts :-/
By the way, until today i haven't seen nor pictures neither videos of this test done with my card, never seen a text file of the debug version of the device driver of my card; so i argue that the problem can be at electrical level.
I have heard about a relative new Zorro card that gave problems with 040/060 cpus; this card was a combi card with ethernet and ram, but i suppose it is a Zorro III card and not a Zorro II.

Stefano
 
I'm not sure where the answer lies (vibros) with your situation, but I happen to have gotten some real Hardware Reference Manuals (3rd edition) last week, and re-read a few areas again.

Zorro II backplane (A2000) is terminated by a cap and resistor connected to Ground for termination. Relative to that, the A500/1000 has no termination on the edge connector, sans the sidecar/addition module provides, and expansion cages could go either way. The A3000/4000 expansion must use something different, and does. It uses both pull-up/pull-down resistor pairs to be more friendly to the higher speeds needed for signal propagation. I'm not sure what the replacement Z2/Z3 daughter card uses. This difference in termenation can cause problems for some poorly designed PICs.

C= also notes that cards built to 'behavior' rather than to 'the specs' are going to have issues depending on how far out of timing they are. Buster 6/7 is going to be fine for slave-only Zorro II, but there are known issues with some Z2 DMA (and ChipRAM) that are only fixed with 1) Buster -11, and when it comes to an A3640, with the 2) Rev 3.2 fixes. Dave Haynie has documented this in his 'definitive buster' notes, and the timing fixes he mentions are provided in the revised A3640 parts some sell pre-programmed. It doesn't hurt to also chase down the A3640 wait-state removing GALs designed by SpeedGeek while you are updating the board. Other cards may also see the Z2 issue depending on the sampling of a certain signal he mentions.

As for AutoConfig, if identified as Zorro III, it gets sent high to Z3 addresses. If it is Z2 I/O, it goes to $E90000-$EF0000 or 8M space if big ($200000-8FFFFF). There's also a 3.1-OS defined potential to show up in $A00000-$B7FFFF (Page 388, and a diagram on a nearby page) but I don't think it gets used (I'm investigating) yet by any expansion.library, but may in the future). AutoConfig is the expansion library means to configure cards. 3.1.4 fixed some expansion.library code that fast CPUs could exceed the reasonable hardware speed between board config signals, but they won't fix bad or marginal board-driver behavior.
 
Last edited:
Hello,

a fast reply (with a question) because i will read carefully your whole text later. How affordable can be a Zorro II card build around a plain 3000D?

Regards
Stefano
 
Last edited:
Really quick, 2x 8-bit bi-directional data bus buffers, an 8-bit address line buffer for your 8-important address lines you typically have to listen for (8M->64K), a 74-series address decoder on the address buffer lines to know when (at what address) to respond to the bus, a GAL for the AutoConfig board-info that expansion.library reads when the Config_In line is signalled, a GAL for a custom address decode register when you are programmed by the AutoConfig/expansion.library logic (you are given your base address to move to) - it alters the decoder mentioned earlier, plus I think 2 smaller TTL logic parts will be needed for the bus signal lines you have to have good current driving on the expansion bus. Passives, headers, connectors, as needed.

Internal (on the card side), a decoder or GAL logic to split up your 64K board into something like four 16K segments, maybe decode the AutoConfig info in one 8K and the programming register(s) go in the other 8K. You will need some spare logic gates at various points to trigger basic things with clock signals and/or latch data with bus signals, so common (N)AND/(N)OR/XOR parts.

You need your choice of custom purpose chip (look at many of the I/O boards out there of PC-XT-like function), and you decode it's registers into to one of the 16K segments - the driver reads and writes to these to perform I/O. Keep an eye on best practices - 32-bit longword alignment of registers (performance killer on 68020+ if not), no odd-byte aligned 8/16/32-bit register accesses (a 68000/68010 no-no), separate read and write registers (or mirror them if bi-directional - it's an A3000/A4000 thing called sticky bus buffers). A big/little endian byte swap trick can be done with the mirroring if dealing with 16/32-bit Intel integer data.

A ROM can go into another 16K (2x 8K EPROMS, or signal in AutoConfig it's 8-bit diag, and to copy it to RAM) or none if you will load software for it later.

If the chip and the Amiga should share common SRAM, you could put 16K (8K x 8 x 2 give 16-bit) of it in another bank, or leave it for future expansion with another add-on chip. Additional logic overhead for this might apply.

For a memory board, the base logic is the same for AutoConfig (but that board address segment disappears from the address space once configured), and with address decode still needed once programmed, although simpler. The bus buffers will still be needed, plus you have to add memory refresh logic with DRAMs using additional logic and clocks. Any one of the 2MB or 8MB FastRAM boards made of TTL logic are examples.

Much of the non-buffer logic items can eventually end up in a 5V-tollerant custom gate array component. JTAG programmable devices might be able to be directly connected to the needed TTL bus buffer/driver parts, and you just plug in your chip of choice on the 'other side' and do your pin programming/glue logic from there.

Hope that helps. I take this basic list from the GVP Series I and II cards, A2091, and a few others of the I/O type.
 
Last edited:
Hello,

as ever, thanks for your reply; i will read it later, and sorry about my poor english language: on the post above, i mean 'i reply with a question'!.

- - - Updated - - -

C= also notes that cards built to 'behavior' rather than to 'the specs' are going to have issues depending on how far out of timing they are. ...

that's true! I have built hardware and software (i mean content of the PLD of the card) with regard of what i have read on the document 'A500 A2000 Technical Reference Manual' about the signals of the Zorro II bus and the timing, and all was respected (nature of every signal generated by the PLD) during develop of this card; then the technical manuals of Motorola for MC68000, MC68020 and MC68030 and the specs of the IDE bus and his timing, by X3 (from T9.2 and succ.); and all the signals was measured and i was happy and sure about a good result...and that was on my Amiga 3000D.

If i could to sketch a graph of what happened to my card sent for a test, this will look, more or less, so:

the first day the card was seen by the system (Autoconfig) but the device driver (installed later) fails; presumably this happens more time the same day;

a new day, time to change daughterboard and later motherboard of an Amiga 4000D; the card is sometime seen by the system, but not with some third party daughterboards; fears about 3.1.4 happens here; the line of the graph sinks terribly!

after a couple of days i receive an info that a CF formatted under 3.9 is not seen by my tool that mounts DOS partitions; formatted on my card, the CF is not seen as DOS device on the internal IDE port of the A4000! Anyway, the line of the graph, rises positively...

after that, just short comunications that 'more test are needed'; the line of the graph stop his job...'comunication interrupted'.

I have requested the return of my card and possibly, with an old and not working A3640, to check my card into my Amiga with a 040 cpu. So, if you wish to donate an old A3640, without cpu, in not working state; and/or a 2000 motherboard (about revision 6), withou any socketed IC except the two CIAA and CIAB, i will be wery grateful!

Chers
stefano
 
Hi Stefano,

Not much one can do when the information/feedback disappears. Maybe they made a mistake handling the hardware (theirs or yours). Maybe one of them failed. Maybe real life kicked in and took them away from the Amiga indefinitely. I've had all of that happen.

One thing about A3000/A4000 I noted briefly above is to watch out for the 'sticky buffer' issue on those busses. Some of the bus buffer behavior, if you try to write to a register, and then immediately read from it, retains the old data you wrote. You also need to make sure that wherever you end up in the memory map (Z3 types can place you high), that you are properly set to not cache. One of the issues on the 68030 is the CIIN errata. A 32-bit write to a location in memory with the data cache on (and not marked as non-cache by the ttx register programming, or the MMU table) ignores the hardware Cache-Inhibit hardware signal from the bus on the write. If you re-read the location very soon after, you may get stale cache data instead of hardware data. This is why OS 3.1.4 reports the CIIN bug when detected. The only fixes for it include:

1. The TTx register can mark the I/O and shared memory zone as no cache, but it's granularity is 16MB - as in the entire 68K 24-bit address space becomes no-cache for data (ChipRAM needs this, so it has to be done for this - and Z2 FastRAM gets no data caching). This is the only fix for 68EC030, and only one of the reasons 68EC040/060 is not supported by Amiga OS with the data cache. Having all your 32-bit RAM >16MB is, however, safe to cache (with proper DMA cache clearing functions in the OS).
2. The MMU can fix it with more granularity than the TTx. Hence the need for the CPU support libraries.

3. All drivers must cooperatively resort to using 8 or 16 byte writes to the hardware's registers so as to not be cached (standard cache behavior), but that isn't always best for efficiency.

Thor's 68030.library toggles the TTx on the 680EC030, and places simple MMu protection for shared memory and I/O spaces. SetCPU FastROM also fixes it for systems with the 68030 MMU. I know that the 2.x/3.x CPU command from the OS does NOT fix it. OS 3.1.4 doesn't support Kickstart remap function (only detects some), and relies on other tools (MuLibs/SetCPU/etc) to fix the issue and handle ROM remap. I haven't tested any other 68030+MMU tools beyond them.

C= also noted that it's safer to mirror your registers in your I/O space and treat one set as read and the other one as write. You might make control registers 16-bit or 8-bit or less in actual value, but make them all safe to write as 32-bits, too.

Right now I'm limited on the equipment I can part with. I don't have any non-working 6.x series A2000s (I have one working unit that is my bench system), although I have two 4.x with expansion-bus/86-pin CPU slot issues from the usual battery (but they boot). My A3640 card is functional, but it needs to go on to an A3660 PCB when I have time. I have the 060 CPU in an adapter, and it still needs to gain the Speedgeek and v3.2 update GALs (I have them), and would need recap if it was not going to get transferred. I'm just limited in time.
 
Sorry for hijacking the thread but should the 3.1.4 ROM work off the shelf with an 68EC060 CPU? I’ve got one in my A3640 via an adapter.
 
Hello,

as ever, i will read the replies of 'thebayaguy' later and carefully. I have just to say that my card has not read/write registers, just (outside Autoconfig) a status register (with, as you guess, stores the state of the Interrupt) as read-only register.
About your tips, i wish to use logic and decode all your valuable informations; and two things come to my eyes: you have spoked about 'this difference in termination can cause problems for some poorly designed PICs' and ' ...but they won't fix bad or marginal board-driver behavior'. This tell me about my lack of experience about this matter. I need to think where i have failed, in the design of this board, because i have measured all the possible and, on your replies, seems that there is not differences between an Amiga 3000 and an Amiga 4000 by the point of view of a PIC.
Now i have to say that two days ago i have tried a configuration used some months ago as one of the last test done with the last prototype of my IDE card; just two HardDisk of 3.5", attached to the IDE channel as 'Master' (the most modern one) and 'Slave' (the old one). This configuration was pictured and posted here on Amibay, as proof of the feature of this card to do automatic selection of PIO timing (between 0 and 1). The old one as showed values as PIO 0 only device and the modern one has runned in PIO 1 mode.
Now, as said, two days ago, in the search for a clue in what my IDE card has failed to be affordable, attached the two drives in the same way done some months ago (end of the year before), this configuration has failed; there was noise on the data bus of the IDE channel, and the result was a card sometime not seen by the system (as reported by the tester), or wrong values from an 'Identify Device' command. It seems to be i have pointed on the right direction: found the problem (it was an equation of a couple of signals that i have changed in the meantime without pay attention at the consequences!) and restored the content of the PLD to the previous statements (that was ok on the prototypes) now seems to be all ok..at least i hope!
Someone has sent to me an old A3640, just to test the IDE@ZII (and the software for this card) with a 'First class' cpu. The A3640 needs to be fixed in some points and i am not sure to complete this job: i will open the fat book 'MC68040UM' and start to learn...and learn...and learn more...
Seriously, i am very grateful for what the user 'thebayaguy' has wrote as replies on this thread; all was very interesting and pleasantful to read; anyway, most infos was know by me and respected during the develop of this card.

Cheers
Stefano
 
Hi Stefano,
...
Right now I'm limited on the equipment I can part with. I don't have any non-working 6.x series A2000s (I have one working unit that is my bench system), although I have two 4.x with expansion-bus/86-pin CPU slot issues from the usual battery (but they boot). My A3640 card is functional, but it needs to go on to an A3660 PCB when I have time. I have the 060 CPU in an adapter, and it still needs to gain the Speedgeek and v3.2 update GALs (I have them), and would need recap if it was not going to get transferred. I'm just limited in time.

Hello,

please, i don't mind to ask to you something, just to someone that reads this thread. Thanks anyway!

I have just forgotten to say that on my card, there is at least another two registers, that are write-only and they are 1) the register that generates valid chip-select signals (because my card can do something else when the IDE bus is quite) and 2) the register that choose the timing (PIO 0 or PIO 1).
I am, as already said, a newbie and the thing called 'sticky bus' or what is called, i don't understand completely. I don't understand how this failure can happen when a timing is correct (i mean especially in set-up time and in hold-time). Anyway, if it is related to the condition of the CPU called 'read-modify-write', it is taked into consideration in my code because at least one IDE register has two different meanings if it is read or wrote.

Cheers
Stefano
 
Hi Stefano,

"Avoid the TAS instruction" is written twice in the Hardware Reference Manual. Pages 196, 223. That's good enough to never be concerned about that kind of access. Even if you support it, it shouldn't be an issue.

The sticky buffer problem has to do with writing a register with a fast CPU, and then reading immediately from that same register, expecting back something different (like a status, or data). The CPU may be faster than the bus buffers/peripheral when it comes to changing directions, and the value written may very well be the value that it reads back before the buffers change output direction. The solution is to mirror your register somewhere within your PIC address space (a 32-bit longword away is sufficient, but a 2k or 4k boundary may also be logistically easier). A fresh memory access cycle to the new location is forced on all hardware involved.

Here is the other thing I mentioned regarding port mirroring: http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0161.html. The behavior of 68030's and 68040's (and 68060's) cache and burst behavior differences should also be considered when troubleshooting.

Robert
 
Last edited:
Hello,

thanks, as ever, for your valuable reply.
About some issues i have my own idea, anyway, as already said, i am a newbie, so i don't tell more.
What can i say now?...buy my IDE card!!!

By the way, i have done two similar prototypes, as last test: one with the usage of XRDY to delay ZorroII cycles and one with the usage of DTACK. On my basic 3000D they work the same, but i have read of some problems on A4000D and the usage of XRDY. So the final design uses DTACK...And i agree completely on the design with the respect of every signal and is nature and not regards what is measured with instruments.

Regards
Stefano
 
Back
Top Bottom