IDE & Max Transfer

[thomas]

Originally Posted by Toni Wilen

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.

Originally Posted by Toni Wilen

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 .

[Toni Wilen]

Originally Posted by AmigTart

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.

[fgh]

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

[orange]

while you're at it, could you do the Mask too?

[Toni Wilen]

Originally Posted by fgh

[*]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.

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

Yes.

[*]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)

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.

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 =)

[thomas]

Originally Posted by Brm

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.

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.

[fgh]

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

[Toni Wilen]

Originally Posted by fgh

A too high maxtransfer corrupts writes >128KB. Can it also corrupt reads?

Yes.

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.

[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.

[jdow]

Originally Posted by AmigTart

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.

{^_-}

[bitter]

With 3.1.4 ROM and WB, and using 16Gb DiskOnModule, do I still need to worry about MaxTransfer?

[Daedalus]

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.

[bitter]

Originally Posted by Daedalus

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!

Hey thanks for this info. I saw the 0x1fe00 thing in a youtube video about how to use WinUAE to set up a flash card with Classic Workbench without a floppy drive. I totally didn't do it, I was like "I have no idea what this is so I'm leaving the default and peacing out." Now it makes sense. I left it at something like 0xffffffff.

This appeared to work on my stock, freshly recapped Amiga 600 no problem. I then added a Furia, which also still appeared to be working no problem on this SD card with that default value. I could boot, launch programs, no problem. Then I was playing a demo and ran into a crash with an "exception line 1111 emulator" error. I tried using HDToolbox to change the maxtransfer value of my 3 partitions to 0x1fe00. On reboot, I get a red guru meditation!

Also, before I installed the Furia I was able to access SD and compact flash cards via the PCMCIA port, but afterwards I can't even if I use the ctrl+A+A for 3 seconds trick to disable the conflicting memory. When I mount cf0 it mounts no problem but says there's no disk in drive. I don't know what's up with that but I think it's kind of weird.

I'm not sure I chose the right filesystems and partition sizes for my primary cf card anyway so I don't really need help with anything, I'm sure I'll reinstall on this card a few more times anyhow. But I thought I'd share in case my adventure was interesting.

[Mark sealey]

Originally Posted by ranix

Hey thanks for this info. I saw the 0x1fe00 thing in a youtube video about how to use WinUAE to set up a flash card with Classic Workbench without a floppy drive. I totally didn't do it, I was like "I have no idea what this is so I'm leaving the default and peacing out." Now it makes sense. I left it at something like 0xffffffff.

This appeared to work on my stock, freshly recapped Amiga 600 no problem. I then added a Furia, which also still appeared to be working no problem on this SD card with that default value. I could boot, launch programs, no problem. Then I was playing a demo and ran into a crash with an "exception line 1111 emulator" error. I tried using HDToolbox to change the maxtransfer value of my 3 partitions to 0x1fe00. On reboot, I get a red guru meditation!

Also, before I installed the Furia I was able to access SD and compact flash cards via the PCMCIA port, but afterwards I can't even if I use the ctrl+A+A for 3 seconds trick to disable the conflicting memory. When I mount cf0 it mounts no problem but says there's no disk in drive. I don't know what's up with that but I think it's kind of weird.

I'm not sure I chose the right filesystems and partition sizes for my primary cf card anyway so I don't really need help with anything, I'm sure I'll reinstall on this card a few more times anyhow. But I thought I'd share in case my adventure was interesting.

My Furia setup is more stable with Os3.1.4.....Maprom works a treat....when i cold boot I disabled CPU cashe....and CC0(via early startup menu) as i dont use the PCMICA slot yet.....32gb SD card with the above Max transfer settings....pfs3 AIO...80 buffers on 500mb boot partion and 100 buffers on the other larger partions...if i reboot without this i get a Guru or the boot freezes.

I hear you can sort out the PCMICA with a "cardres" loadmodule hack too

[Michael]

PFS3_AIO has it's own maxtrasfer safe guards now, so you should be safe.
The same is true with 3.1.4 FFS implementation and SCSI device
But if you still use old 3.1 roms, have the first partition on any bootable media within 2GB and you should not have any issues on booting.

[Orionis5]

Anyone have and idea if max transfer limit still needs to be set if you use buffered IDE connector for connecting IDE compatible device on Amiga ?

[fgh]

Originally Posted by Orionis5

Anyone have and idea if max transfer limit still needs to be set if you use buffered IDE connector for connecting IDE compatible device on Amiga ?

A buffered interface allows longer cables but has no relation to the maxtransfer issue (which is a software ‘bug’ due to changes in the ATA specification)