English Amiga Board


Go Back   English Amiga Board > Support > support.Hardware

 
 
Thread Tools
Old 10 June 2011, 10:41   #41
thomas
Registered User
thomas's Avatar
 
Join Date: Jan 2002
Location: Germany
Posts: 5,717
Quote:
Originally Posted by Toni Wilen View Post
Should WinUAE detect this situation and warn about it? It is easy to emulate this exactly as ATA-1 spec says which is technically right thing to do but may not the best choice from non-technical point of view
A warning would be nice, but a fix would "break" the advantage: currently you can use IDE0 to setup your real-Amiga harddrive and will stumble across the MaxTransfer problem already in WinUAE. With a fix, the problem would only appear on the real Amiga, just like when using UAEHF.
thomas is offline  
Old 10 June 2011, 12:02   #42
AmigTart
 
Posts: n/a
Quote:
Originally Posted by Toni Wilen View Post
Max transfer is filesystem parameter, filesystem (if it cares about the parameter) splits the request in less than max transfer pieces before sending it to device driver.
Device driver does not know nothing about max transfer parameter.
(and check also post 25)
It is obviously different than in DOS or TOS - if it is really so. Filesystem usually don't care about device characteristics, actually even don't care what kind of device is it (may be RAMdisk too) . Filesystem sends request which contains usual block parameters as sector count, lba, + memory loc. where to load (or save from). It is normal to expect that driver, which deals with HW should care about such things as "max sectors transferrable with one command" - I changed thread title to more precise formulation . In any case, by Amiga is many thing different .
 
Old 10 June 2011, 12:11   #43
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by AmigTart View Post
It is obviously different than in DOS or TOS - if it is really so. Filesystem usually don't care about device characteristics, actually even don't care what kind of device is it (may be RAMdisk too) . Filesystem sends request which contains usual block parameters as sector count, lba, + memory loc. where to load (or save from). It is normal to expect that driver, which deals with HW should care about such things as "max sectors transferrable with one command" - I changed thread title to more precise formulation . In any case, by Amiga is many thing different .
Amiga is always different

Amiga device drivers are supposed to not have any transfer limits. If program asks for 1M transfer, it should get 1M of data (as long as request is valid and not out of bounds etc), not some kind of weird error depending on hardware.

It is device driver's task to handle splitting automatically and transparently.
Toni Wilen is offline  
Old 04 September 2011, 21:05   #44
fgh
Registered User
 
Join Date: Dec 2010
Location: Norway
Posts: 628
Great detective work by Alex, Toni and Thomas!

With this new knowledge, could you confirm for us mere users that:
  1. There are no maxtransfer issues on SCSI equipment
  2. It might affect any IDE device using scsi.device (CF, SD, SSD or HDD)
  3. It makes no sense to use 0xFE00 over 0x1FE00
Thanks!

Best regards
Frode
fgh is offline  
Old 04 September 2011, 22:56   #45
orange
Registered User
orange's Avatar
 
Join Date: Apr 2007
Location: Belgrade
Posts: 567
while you're at it, could you do the Mask too?
orange is offline  
Old 05 September 2011, 09:29   #46
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by fgh View Post
[*]There are no maxtransfer issues on SCSI equipment
IDE-like max transfer problem is impossible (you don't get last read/write position back from SCSI commands so drivers' can't misuse it). Technically some scsi driver may have bugs causing similar issues.

AFAIK no one has ever reported any problems.

Quote:
[*]It might affect any IDE device using scsi.device (CF, SD, SSD or HDD)
Yes.

Quote:
[*]It makes no sense to use 0xFE00 over 0x1FE00
Yes. Even 0x20000 should still work because problem only happens if more than 256 sectors needs to be transferred (256*512 = 0x20000)

Quote:
Mask
Mask was designed for DMA controllers to prevent DMA transfers to unsupported memory. For example 24-bit controller (like A590/A2091 DMAC) can't DMA to 32-bit RAM or some have LONG transfer alignment requirement (like original rev 1 DMAC). NOTE!!: "24-bit" in this context means controller have 24 bit address lines. Not that memory has 24-bit data bits

Controllers do following test: if ((transfer start address & mask) == transfer start address) then { do the DMA normally } else { use PIO or DMA to supported ram (worst case chip ram), then use CPU to copy it to final address }

It does not make any sense to change mask when using non-DMA (like Amiga IDE) controllers. I am not sure if they simply ignore the mask.
Toni Wilen is offline  
Old 13 September 2011, 19:40   #47
Brm
 
Posts: n/a
I agree with Toni's post #25 ...

What still puzzles me.
Why after 256 writes of 512 byte blocks LBA address is correct and sometimes it is not (on same drive)? Im pretty sure that when I experienced these MaxTRansfer issues, trashing was more or less random.


I remember from back of the days when I bought new 80GB drive and it trashed data while my original 80MB 2.5" drive didnt, and neither did 800MB Samsung or 1.2GB Seagate (or perhaps it did trash but I never noticed it) ... I almost lost my hair trying to solve this trashing problem. Then I phoned my friend who happened to know this issue and I finally got all running nicely =)
 
Old 13 September 2011, 19:58   #48
thomas
Registered User
thomas's Avatar
 
Join Date: Jan 2002
Location: Germany
Posts: 5,717
Quote:
Originally Posted by Brm View Post
Why after 256 writes of 512 byte blocks LBA address is correct and sometimes it is not (on same drive)?
The problem does not appear if you do 256 writes of 512 bytes each. The error occurs if you do one write of 131584 Bytes or more (> 256*512).

This means the problem only happens if all of these are true:

- you copy a file which is larger than 128KB
- your copy program has a buffer size of more than 128KB
- the file system is not fragmented, so that it can write the entire buffer (more than 128KB) in one command.


Quote:
I remember from back of the days when I bought new 80GB drive and it trashed data while my original 80MB 2.5" drive didnt, and neither did 800MB Samsung or 1.2GB Seagate
Most likely the old drives followed the old ATA specs which didn't have the MaxTransfer problem while the 80GB drive is the next generation with new ATA specs.

It could also be that you didn't have a MaxTransfer problem but rather a >4GB problem. This really shows as random trashing of files, entire partitions or even the entire drive.

Last edited by thomas; 13 September 2011 at 20:08.
thomas is offline  
Old 22 September 2011, 20:58   #49
fgh
Registered User
 
Join Date: Dec 2010
Location: Norway
Posts: 628
Thanks for your answers guys!

Apologies for being a slow learner, but I have more questions:
  1. A too high maxtransfer corrupts writes >128KB. Can it also corrupt reads?
  2. Is the problem known to affect any other IDE driver than scsi.device?
  3. Do you know which of the more recent versions of scsi.device contain a fix? (IDEfix97 version does)
Thanks again
fgh is offline  
Old 22 September 2011, 21:24   #50
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by fgh View Post
A too high maxtransfer corrupts writes >128KB. Can it also corrupt reads?
Yes.

Quote:
Is the problem known to affect any other IDE driver than scsi.device?
Do you know which of the more recent versions of scsi.device contain a fix? (IDEfix97 version does)
No idea.
Toni Wilen is offline  
Old 23 September 2011, 07:02   #51
rkauer
I hate potatos and shirts
rkauer's Avatar
 
Join Date: Oct 2007
Location: Sao Leopoldo / Brazil
Age: 52
Posts: 3,482
Send a message via MSN to rkauer Send a message via Yahoo to rkauer
From a thread on Amibay surely other controllers intended from A500 (they doesn't fit on A600 nor A1200) have worse symptoms and those need to lower the max_transfer value to 0xFE00 in order to fix.

Namely the Alfa Data's Alfapower cannot cope with 0x1FE00, but works flawlessly with 0xFE00.
rkauer is offline  
Old 02 February 2014, 08:13   #52
jdow
Oh, her, from BIX.

 
Join Date: Feb 2014
Location: Southern California, USA
Posts: 10
Quote:
Originally Posted by AmigTart View Post
Actually, max sector count by IDE (ATA) is 256 sectors, because 0 in sector count registers means not 0 (nonsense) but 256 .

With 48-bit LBA (what is necessary with drives over 128GB) max count is 65536 as sector count is given as 16-bit value.
Nonetheless, it was determined by experimentation among developers that 0x1fe00 aka 130560 was the safest choice with negligible loss of speed. As the ROMs improved it was possible to ignore maxtransfer, if I recall correctly.

I seldom mucked with IDE, though. I was up to my eyeballs in HardFrames and StarDrives. They had no theoretical limit on maxtransfer. The software took care of any limits if needed.

{^_-}
jdow is offline  
Old 30 October 2018, 11:25   #53
bitter
Registered User

 
Join Date: Oct 2018
Location: Fort Mill, SC, US
Posts: 40
With 3.1.4 ROM and WB, and using 16Gb DiskOnModule, do I still need to worry about MaxTransfer?
bitter is offline  
Old 30 October 2018, 11:28   #54
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,409
It depends on your controller. For the built-in scsi.device in 3.1.4 (internal IDE ports), it is apparently fixed so the value doesn't matter. For other controllers, check the documentation for the controller.
Daedalus is online now  
Old 30 October 2018, 11:38   #55
bitter
Registered User

 
Join Date: Oct 2018
Location: Fort Mill, SC, US
Posts: 40
Quote:
Originally Posted by Daedalus View Post
It depends on your controller. For the built-in scsi.device in 3.1.4 (internal IDE ports), it is apparently fixed so the value doesn't matter. For other controllers, check the documentation for the controller.
Perfect, thanks!
bitter is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
CF Hd Max Transfer Problem flushentity support.Hardware 2 12 May 2012 23:15
IDE max transfer (CF, Hard disk, FAT95) xraynorm support.Hardware 2 27 March 2011 21:58
Max transfer & mask for CF card? PowerPie5000 support.Hardware 7 29 November 2010 13:35
IDE & Max Transfer-temp prowler support.Hardware 0 16 June 2009 22:30
CF to IDE adapter - Max size card? crispywotsits support.Other 11 19 February 2009 17:38

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08377 seconds with 13 queries