Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: 3.1.4 and Autoconfig

  1. #11
    Jack of Many Trades, Semi-Master of Some thebajaguy's Avatar
    Join Date
    May 2017
    Country
    United States
    Region:
    Rhode Island
    Posts
    324
    Feedback
    30 (100%)

    Default

    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.
    A500(2x)/A1000/A1200/A2000(4x)/A3000D(2x)/A4000D(under repair)/A4000T (all loaded....Toys...Toys...Toys...)
    Former GVP Tech Support 1989-93 - The beatings will continue until morale improves...

  2. #12
    "Takai desu ne." -"Jinsei da." VIP
    Amibayer!
    protek's Avatar
    Join Date
    Feb 2008
    Country
    Finland
    Region:
    Oulu, Pohjois-Pohjanmaa
    Age
    45
    Posts
    3,846
    Feedback
    63 (100%)

    Default

    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.
    AMIGA 4000 060/50, AMIGA 1200 030/50, AMIGA 500, C128D, C128, C64C, C64, C16, Vic-20, Atari 520 STE, Atari 65 XE, Philips NMS-8250 MSX2, Sinclair Spectrum +3e, Sinclair Spectrum 48k, Amstrad CPC 6128, Apple Macintosh Classic, Apple IIGS, BBC Master, Memotech MTX500

  3. #13
    vibros's Avatar
    Join Date
    Sep 2009
    Country
    Italy
    Region:
    Emilia-Romagna
    Posts
    1,776
    Feedback
    104 (100%)

    Default

    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

Page 2 of 2 FirstFirst 12

Similar Threads

  1. Amiga OS 3.9 ad RAM Autoconfig
    By Violo in forum AmiOracle
    Replies: 0
    Last Post: 5th January 2016, 15:43
  2. Sold A2000/A500 8 MB RAM non-autoconfig
    By bdb in forum Sales Archive
    Replies: 2
    Last Post: 14th November 2013, 21:59

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •