|1-Accelerators,Controllers & DMA By BullyBeef/NFA The Amiga is blessed with Autoconfig, which makes adding cards and per- iphererals a dream compared to other platforms. But it isn't always plain dailing. here are the answers to some frequently asked questions about why A won't always talk to B, and provides a few solutions along the way. Ok, so I have my hard drive and I have my accelerator and I have my 32- bit memory, but they don't seem to like each other, crashing, locking-up and slow-downs...I know this is something to do with some memory being DMA'able and some not, but it's all very confusing. The 32-bit memory you have on your accelerator can be divided into three types: Ordinary DMA'able memory; non-DMA'able memory; and only DMA'able via the on-board SCSI controller. A few accelerators have the option to switch their 32-bit memory between some of these three types. Ordinary DMA'able memory - DMA stands for direct memory access - is like that found on 16-bit memory cards which unaccelerated Amiga's use,except of course it is 32-bit and (probably) can't be ued in the 68000 fallback mode. It lies within the Amiga's 24-bit DMA'able address space - or, to be more precise , it is inside a certain 8Mb memory chunk set aside for "fast" memory.The advantage is that hard drive controllers can recognise it and DMA to it as normal as the memory is in the correct region. The disadvantages are that it is limited to a maximum of 8Mb and it has to be somehow coexist peacefully with existing memory cards. Examples of the type of card that contains ordinary DMA'able memory include the Commodore A2620/A2630 accelerator cards, which can have a maximum of 4Mb 32-bit ram on-board inside the 24-bit DMA'able address space and thus can be DMA'd to normally like any other ram expansion,and the Microbotics VXL 68030 card, which has a maximum of 8Mb 32-bit ram but if this is going to tread on the toes of an existing memory card it can move it outside the 8Mb address space (see below). There are some exceptions. The old Ronin and Hurricane accelerators have non-DMA'able ram inside the normally DMA'able 24-bit address space. The German HARMS 68020 and 68030 cards have this problem too, and it is a rater serious design flaw, although I understand there is a HARMS 3500 model which supports DMA into it's 32-bit ram when mapped into the 24- bit address space. Non-DMA'able memory means that the memory is outside the 8Mb address space. Since all Zorro-II hard drive controllers can recognise only "fast" memory inside this space, they cannot DMA to it. The advantage of doing this is that you can have (say) 32Mb of ram on the card without having to worry about squeezing it all into an 8Mb address space (which is impossible) or with it interfering with any existing memory cards. Examples of cards that contain this type of memory include the SSl A5000 and B5000 accelerators, and the CSA Mega-Midgit racer. The Microbotics VXL 68030 (see above) can,if you have an existing memory card which might interfere with it, turn it's memory inti non-DMA'able memory. ( non-DMA'able memory means that the memory is outside the 8Mb address space. Since all Zorro-II hard drive controllers can recognise only 'fast' memory inside this space, they cannot DMA to it). ^7^^450 Lastly, DMA'able via the on-board SCSI controller means that the memory is also outside the 8Mb address space but the on-board SCSI controller knows about it and can DMA to it as normal. These kind of accelerators are usually only found on cards for the A2000's CPU slot because the addition of a SCSI controller and hard drive combination takes up a fair amount of space. Examples are the GVP combo (68030 and 68040). the PP&S 68040, and the CPU boards on the A3000 and A4000 - plug an A2091 into either of these, and you will run into the DMA problem. In a similar manner to the Microbotics VXL 68030, the GVP combo can turn 32-bit memory into ordinary DMA'able memory,so it can be easily accessed by (say) an A2091 should you have a need for two SCSI controllers in one machine.You will have to ensure that you don't end up with any conflicts involving existing memory boards in that 8Mb region if you do this. Question: I have non-DMA'able memory, with no on-board SCSI controller because i couldn't afford a combo board (or I already had an A2091, or whatever). What can I do about this problem? Answer: The fact that you have non-DMA'able memory should not matter to your hard drive controller, which should, of it's own accord, find an alternative method of getting data there. Sadly, in real life very few controllers can do this. Call it a bug if you like. They generally end up either crashing the machine, or locking up, or just failing to get the data there while pretending it really is there. Many A590s and A2091s (pre-V6.6 roms) cannot handle non-DMA memory corr- ectly. Newer ones can, by falling back into PIO mode - not DMA; rather it uses the CPU to get the data from the hard disk to memory, which is not particulary fast but it is adequate, even if it does chew CPU time. The GVP series II is the best of the bunch and will get fairly high tran sfer speeds even with non-DMA memory. There is a thing called a mask for each partition on your hard drive,and if you have a "buggy" hard disk controller altering this mask will en- able you to get around the problem via the filesystem. Generally, your mask is set to Oxffffffff, which is a conveniently large number - if you work it out in decimal it comes to just under four gigabytes, which is more than the maximum your Amiga can ever hope to address. The software that comes with your hard disk controller should allow you alter this value. The A590 and A2091 use HDToolbox,the GVP series II use FaaastPrep, although it can also use HDToolbox if you add the tool type SCSI_DEVICE_NAME=gvpscsi. device to the HDToolbox icon. You may find the mask has an "e" and not an "f" at the end.This prevents the controller from trying to DMA to odd locations, again to get around a limitation of some controllers. You may find it is set to Oxfffffe, just under 16Mb, which is the top of your fast ram plus chip ram plus a few reserved areas of the Amiga's memory map. you set the mask to tell the filesystem what area's of memory your controller cannot cope with. "many A590s and A2091s (pre-v6.6 roms) cannot handle non-DMA memory cor- rectly". For the technically-minded, the filesystem takes the mask as a binary number, inverts it, ANDs it to the address you are trying to DMA to, and if that comes out as zero it knows that the hard disk controller is able to handle that region of memory. If the mask determines that the hard disk controller cannot handle a DMA request, it attempts to do the job itself. Very, very, very bably. It creates a 512 byte buffer down in low memory (chip ram or 16-bit DMA'able fast ram). DMA's to that, CPU-copies to the destination in non-DMA'able 32-bit ram, and loops back until the entire transfer has been completed. Due to the original request being split up into a lot of very tiny requests, the whole operation effect- ively slows down the transfer speed to something approaching a floppy drive. You might get 50k a second, which means loading DeluxePaint could take ten seconds where it originally took just two. The bottom line is: it's unbaerable? Note that some applications get around the filesystem's hack and manage to request a direct DMA transfer into non-DMA ram. Commodore's own HDToolbox does this, for example. This will result in garbage appearing, just as if you left the mask high for a controller which could not handle non-DMA ram. Typical symtoms include HDToolbox politely asking you to click save changes on all drives once it has loaded - which inst- antly resets your partition set-up to the default, wiping everything. So do watch out for this???? Question: My hard disk controller cannot handle my non-DMA memory so I have set my mask to Oxfffffe and everything is working. But it is slow. Help???? Answer: There is a program called DMAfix which patches three DOS library calls - read(), write() and loadseg(). IT gets in ahead of the filesystem and determines for itself if the memory involved is DMA'able. If it is, then it lets the library call go ahead as normal. If not,it allocates a chunk of chip ram for a temporary buffer,redirects the call to use this buffer and then CPU-copies afterwards, or before if it's a write. It works far faster than the filesystem's DMA-plus-CPU-copy method since it trys to allocate a buffer large enough so the loop has to be executed only once. (if you are low on chip ram it will use a 64k buffer, which is still pretty fast.) Now, you will experience some slow-down due to the CPU-copying. but not much. Speeds of over 500k a second are common where before you might have got 800k. Question: I am trying to use my A4000 with my old A2091 controller. The problem is it is slow? Answer: This is another candidate for DMAfix. Not originally meant for Commo- dore's higher end systems, it actually pparently works wonders.The A4000 has it's 32-bit memory outside of the 24-bit Dma'able space,and thus the A2091 cannot access it directly. DMAfix will correctly redirect it via chip ram. There is also a program called a4091 patch (a4091patch2.lha in hard drivr), Written by Giuliano Peritore. Not knowing about DMAfix he came up with the exact same idea. Giuliano's program patches DOS read() and write() in exactly the same way as DMAfix. It has the advantages that it uses any fast ram on the A2091 by default (you need the regist- ered version of DMAfix to do this),runs the workbench as well as from the shell, and it supports any size temporary buffer you wish. The dis- advantage is that it does not bother about loadseg(), so launching app- lications will be as slow as ever, it works under only AmigaDOS 3.x, and can affect only one partition on the drive, which you specify on the command line. Speaking Generally... If you have an accelerator with DMA'able 32-bit memory (A2630,VXL...), or an on-board SCSI controller (GVP combo, PP&S 68040...), then what are you worrying bout? If you have a GVP series II, or an A590/A2091 with v6.6 roms, set your mask to Oxfffffffe and everything should work fine. The GVP solution will certainly be fast enough for you; the Commodore solution may not, and you might like to try DMAfix in this case. If you are forced to use a mask of Oxfffffe because of a flawed hard disk controller, get a copy of DMAfix by downloading it from Aminet or a local BBS. Be aware that there are more recent utilities available to do the same job, which you might also like to try. If you are trying to use an A2091 with an A4000, get DMAfix or it's equivalent. One last point. The fact that the memory is autoconfig or not, or is sitting in the A2000's CPU slot as opposed to the 68000 socket, has nowt to do with this. Many people seem to think that any "proper" accelerator sitting in the CPU slot will automatically have DMA'able 32-bit memory. Not true. Mine doesn't. DMAfix, shareware (Aminet: disk/misc/dmafix.lzh) by Barry McConnell VB2091, freeware (Aminet: hard/drivr/vb2091.lha) by Volker Barthelmann A4091patch, freeware (Aminet: hard/drivr/a4091patch2.lha) by Giuliano Peritore |1-Bullybeef/NFA