seimet@rhrk.uni-kl.de (Uwe Seimet [Chemie]) (05/27/91)
Did anyone ever try to save the last four bytes of TT-RAM on the TT's internal hard disk? This operation always fails because the scsi controller reports a bus error. (You don't get any bombs, because it's not a processor-related error. The hard disk driver simply aborts with the usual alert.) This problem doesn't seem to be driver dependant. It looks as if the controller tries to access not only the last bytes of TT-RAM but some bytes on higher adresses, too. Of course, at these adresses there is no RAM, so this explains the bus error. If the last byte to transfer lies at least four bytes below the end of the physical RAM everything is fine. Is there any reasonable explanation or is this some kind of hardware bug? ******************************************************** * Uwe Seimet * * seimet@sun.rhrk.uni-kl.de * *------------------------------------------------------* * I hate this machine, I wish that they would sell it. * * It doesn't what I want but only what I tell it. * * (Programmer's lament) * ********************************************************
jimomura@lsuc.on.ca (Jim Omura) (05/28/91)
In article <1991May27.101719.2923@rhrk.uni-kl.de> seimet@rhrk.uni-kl.de (Uwe Seimet [Chemie]) writes: > >Did anyone ever try to save the last four bytes of TT-RAM on the TT's >internal hard disk? This operation always fails because the scsi >controller reports a bus error. (You don't get any bombs, because it's >not a processor-related error. The hard disk driver simply aborts with >the usual alert.) >This problem doesn't seem to be driver dependant. It looks as if the >controller tries to access not only the last bytes of TT-RAM but some >bytes on higher adresses, too. Of course, at these adresses there is >no RAM, so this explains the bus error. If the last byte to transfer >lies at least four bytes below the end of the physical RAM everything >is fine. >Is there any reasonable explanation or is this some kind of hardware >bug? > It sounds like the 68030 has "pre-fetch" active. You can shut this off "manually". Check a 68030 instruction list. The only problem might be that the "pre-fetch" might be built into the driver and not over-rideable without writing your own driver. That's probably not going to be a problem, but I've never seen the code so I can't say. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura
seimet@rhrk.uni-kl.de (Uwe Seimet [Chemie]) (05/29/91)
jimomura@lsuc.on.ca (Jim Omura) writes on my article <1991May27.101719.2923@rhrk.uni-kl.de> seimet@rhrk.uni-kl.de: > It sounds like the 68030 has "pre-fetch" active. You can >shut this off "manually". Check a 68030 instruction list. The >only problem might be that the "pre-fetch" might be built into >the driver and not over-rideable without writing your own driver. I don't think the 68030 is responsible for the bus error. Remember that the error is reported by the scsi controller. During dma transfer the 68030 is not active. I do use my own driver but there it is the same problem with the original atari driver. BTW, in AHDI 4.02 you still find an old error: After initialising the driver exits with PTERMRES. Instead of specifying its length to stay resident it uses its start adress as parameter for PTERMRES. The effect: after running AHDI several times you run out of memory. The first time it is started you loose about 64KBytes of RAM. This means that by using AHDI you have always less memory than with other drivers (e.g. HDDRIVER). ******************************************************** * Uwe Seimet * * seimet@sun.rhrk.uni-kl.de * *------------------------------------------------------* * I hate this machine, I wish that they would sell it. * * It doesn't what I want but only what I tell it. * * (Programmer's lament) * ********************************************************