From at01k@servis.net.trFri Mar 29 22:24:11 1996 Date: Fri, 29 Mar 1996 22:23:21 +0300 (EET) From: Adil Temel To: Maximo Piva Subject: Re: Mail lost? On Thu, 28 Mar 1996, Maximo Piva wrote: > I hope your receive this mail is the third time i sent it, > My mail server SUXX!!!! > > Dear Adil, > > I tested your beta version, GrEAt aNd FaaaSttt WoRk, work nearly > perfect, two problems arise: I'm really happy to hear that! ;-) > First: > ...The solution is to do it before you start pooling the goldengate memory. > You must open and close the "glib.library" so the init process happens > before the pooling. > Example: > ....code.... > LEA GLIB(PC),A1 > ... > JSR _LVOCloseLibrary(A6) > ....code.... I'll better add some optional delay between opening/closing the library, since pooling routine takes immediate action, and the libopen function of glib may well return before doing the actual board init process. > Second: The transfer rate is still low. Here is a table: > The first test is a complete log of a 1029 files CD-ROM directory > with X-TREE. > The second test is a copy of a file of 1.2 MEG from the CD-ROM > to the HD. > > OPTIONS | Reading the directory | Copying a 1.2 meg file > .... > LRU=1024 | 0:34 min | 4:38 min > LRU=1024 PREFETCH=10| 0:34 min | 4:39 min These speeds are really sloowww... I have around ~440KB/sec transfer speeds with my triple speed TOSHIBA drive without a LRUCACHE. (The drive has around 500KB raw speed on Amiga 3000 scsi-bus). > As you see the cache don't help so much, i'll point out that i > don't have a scsi drive, i have an atapi drive (ACER 2X), but the > atapi device accept scsi direct commands. i don't think that is the > problem, also the tests were preformed without the (DEBUG) option, so > the amiCDex TEXT output cannot influence the time. Also i send you > at the end of this mail the First test with LRU=1024 debugged. > Also i test the transfer of 20Megs from the Amiga to the Goldengate > with this little program. Took 12 secs. (With the goldengate running) > ... > DBF D2,LOOP1 > RTS Cache will not be of any help if you access a file for the first time (It is read directly from drive and stored into the cache). But further accesses to that file should be a lot faster. (This is true of course if you have a cache size big enough, which is not the case with your test file since it won't fit totally into the cache, besides some file-control blocks will also eat up some cache blocks. Try the test with a 1.5 or 2 Meg cache, and re-read the same file second/third times from the PC side). The loop test gives a bandwidth of 20/12 ~= 1.7 MB should suffice for the AmiCDEx. Well the problem may be that the 'dual-access' decreases the bandwidth (=PC has DMA-precedence?). > The IRQ and autoconfig features works perfectly. That's good. > Some info of the machine i use: > > A4000/40 8Megs Fast,2 Chip, 486SLC Goldengate bridgeboard with 4 Megs, > Paradise SVGA card, Spectrum 2 Megs card, 1 Gig HD partitioned as > 40 Megs Workbench, 680 Megs Work, 300 Megs MAC partition, 200 Megs > PC partition as C: drive , ACER 2X atapi CD-ROM, 340 Megs HD > connected directly to the bridgeboard IDE port as D: drive I have the MAC (shapeshifter) running up recently . Really a GREAT WORK from Christian Bauer. BTW: Do you have any info of how a Shapeshifter screen driver is programmed? I will personnaly contact the author but I think it won't be a good idea requesting support before registering the shapeshifter. THE IDEA: I'll perhaps write a fast PC-SVGA screen driver for it? What do you think? > HERE is THE DEBUG... > 7.Workbench:> amicdex SERVE DEVICE=atapi.device UNIT=1 LRUCACHE=1024 DEBUG > AmiCDEx V2.2BETA Amiga CD-ROM Driver for PC/AT Emulators > Written by Adil Temel (E-Mail: at01k@servis.net.tr) (C) 1995 > (Compilation Date: Mar 16 1996 18:01:39 for CPU: >=68020) > ----------------------------------------- > RUNNING PARAMETERS: > SERVER ID = 07a95380 SERVER SUBUNIT=0 > MSGBASE= 0x00208574 [0x00200000+0x00000000+0],MEM_USED=2432[RAW] > DEVICENAME = atapi.device UNIT = 1 LUN=0 > MODE [LRUCACHE ASYNC FCPY AUDIO VOLUME RAW ]. > BUFCACHE 32K [0K,32K],147K [36K,110K] RAW > LRUCACHE [8,4]*16=1024K > ----------------------------------------- > getscsi_buf: SCSI-DIRECT buffer allocated at 07a7b850,len=2560 > handle_timer:Checking Disk: no disk change You have started the amicdex after the PC driver has been installed (That is why it immediately knows the real MSG Base , ignore the calculation). > Checking Disk: no disk change > disk in drive > ReadUPC: REAL MCVal is FALSE [00] UPC: 00000000-00000000 > reset_audio: playstat=STOPPED > set_lastp: last_start=0 ,last_end=0 > READ TRUE TOC[ 2]:0,332995 > reset_audio: playstat=STOPPED > Max Sec = 332995(adjusted acc. to TOC) , sec size = 2352 (capacity = > 764847 KB) > IRQ Handler added. > LowMem Handler added. > Subunit 0 serving started on UNKNOWN CD-ROM drive (atapi.device unit=1 > lun=0). > You may turn ON/OFF debugging by pressing CTRL-E > MSG_BASE: 00208574 Usual AmiCDEx init procedures. It has detected that there is a disc in the drive and read UPC (Universal Product Code= BAR code of the CD, which is usually empty), the TOC (Table of Contents)information. The Max_Sector directly given from the drive sometimes do not match the TOC entry which is more accurate. > Waiting irq signal > Detected msg change init msg-base at 07a8b964 > handle_timer:Checking Disk: no disk change > ...... > ...... > reset_audio: playstat=STOPPED > Waiting irq signal > Detected msg change init msg-base at 00208574 > Received RESTART=0c sector=0 secnum=0 secmax=0 [M:00208574] > CM_RESTART: Re-initializing msg-base at 00208574 > Result 0 > Waiting irq signal > Detected msg change init msg-base at 07a8b964 > Received RESTART=0c sector=0 secnum=0 secmax=0 [M:07a8b964] > CM_RESTART: Re-initializing msg-base at 07a8b964 > Result 0 > Waiting irq signal > Detected msg change init msg-base at 00208574 > Waiting irq signal > handle_timer:Checking Disk: no disk change > > disk in drive > reset_audio: playstat=STOPPED > Waiting irq signal > Detected msg change init msg-base at 07a8b964 > Received RESTART=0c sector=0 secnum=0 secmax=0 [M:07a8b964] > CM_RESTART: Re-initializing msg-base at 07a8b964 > Result 0 > Waiting irq signal > Detected msg change init msg-base at 00208574 > Waiting irq signal Appearantly you have reset the PC during the above output. If not then it is a strange behaviour that the msg_base change occurs in a flip-flop fashion? (I'll take a look at my sources). > Received READPRE=08 sector=16 secnum=1 secmax=1 [M:00208574] > CM_READPRE: 0,sec=16 max=1 > CM_READ: setbufcache_size: not changed. > read_cache_buf: allocating dma buffer size 32K > CM_READ: [16,1,1] > read_cache_buf: REAL READ[16-31] , 16 > CM_READ: [16,1,1] > read_cache_buf: DMA_HIT[16-31] at 16 , 1 (FULL) > wait_cm_read: timeout. > read_cache_buf: no CMD_READ received. A prefetch read command has arrived from PC. This is a good opportunity to fill AmiCDEx its internal buffers (that is AmiCDEx always does real reads , and not sends the drive a prefetch read command). The timeout occuring here is normal. Infact the read routine checks the message base for further read requests before leaving in a busy loop which has much faster response time than being activated by the irq handler). > Received READ=03 sector=16 secnum=1 secmax=1 [M:00208574] > CM_READ: setbufcache_size: not changed. > CM_READ: [16,1,1] > read_cache_buf: DMA_HIT[16-31] at 16 , 1 (FULL) > wait_cm_read: timeout. > read_cache_buf: no CMD_READ received. > Waiting irq signal > Received READPRE=08 sector=20 secnum=1 secmax=2 [M:00208574] I have set the busy loop down-counter to 50000 which keeps 68030 (at 25 Mhz) busy enough to detect a further read request inside the read-routine. Appearantly this seems to be not enough for the 68040. I'll enable the BUSYCNT option to let you choose a higher value. Tracking down the further debug output , I see that the requests always arrives as 1 block lengths.Infact MSCDEX does read requests up to 32 blocks at once. This is further divided by AmiCDEx.SYS into 1 block transfers, which is totally hidden from the MSCDEX as it gets the whole chunky read upon return from AmiCDEx.SYS. As you may guess chunky reads are a lot faster than requesting every block one by one at device level (lots of init stuff goes while communicating with MSCDEX). Try to find the latest release of MSCDEX (I use currently V2.24), or if you have that try to increase sector buffers while launching MSCDEX (use /M:buf_count). To sum it up: The transfer speed may be slow because: 1- PC<-> Amiga memory transfer slows down if the PC has precedence over the Amiga. Nothing to do much to fix this problem. Try to change the transfer method of AmiCDEx. It has some hidden options. (Try: AmiCDEx PARSEDEBUG to see all hidden options). While developing for the first time I have tested different transfer methods, among which I found the FCPY routine was the fastest. It is an asynchron transfer routine which runs at the same time on both CPU's. Each byte transfer is immediately catched by the PC process and copied to the desired PC address. If the DMA causes the problem , you may try to use the SYNC switch , which lets the PC driver to wait the whole copy of 1 CD block to arrive into message base. (Do not use the BCPY function it is buggy. 2- The mentioned busy-loop counter is set too low for your system. (I'll send you another version with BUSYCNT=n option enabled). 3- The MSCDEX requests only 1 block which will have a lot of transfer overhead than chunky reads at the device level. 4- AmiCDEx process has a low priority and cannot answer requests immediately, while other Amiga tasks gets more CPU time. So , the solution would be: Install the new AmiCDEx driver with BUSYCNT= set to 100000 or higher. (If you use very high values then AmiCDEx will eat a lot of CPU time while doing busy-checks, so try & find out your best value depending of new result info printed by AmiCDEx if you quit it e.g.: CD Drive transfer: 848 blocks =1M transferred (2 timeouts.) The 'timeouts' is the total counter of missed read requests inside the read function. Upto 10-20 is normal in a 1 Meg transfer. If this value reaches the number of transferred block (>400) then you have to increase the BUSYCNT further. I'll send another uuencoded Amiga executable of AmiCDEx. I have added the glib.library stuff and enabled the BUSYCNT option (Take care: it still defaults to 50000). BTW: If you have problems with your mail-server, do not hesitate to send the same copy 1-2 days apart. I'll answer immediately whenever I receive your mail. Best Regards, - Adil +============================================================+ | // | Adil Temel | | \X/ Only Amiga makes it possible! |at01k@servis.net.tr | +============================================================+