Hi Finn,
On 14/08/23 11:37, Finn Thain wrote:
The Q40 does not have an on-board IDE controller. IDE is accessed via
a common ISA PC Super-IO card. When you do a 16-bit transfer from the
ISA I/O address the data comes out backwards and the CPU needs to
byteswap it.
I found it interesting and quite unexpected that 5.13 read data from
the IDE drive byte-swapped. I had prepared a drive for the machine
with an MBR partition table and an ext4 filesystem but the kernel did
not recognise either. After a while I realised I had to byte swap the
entire drive with 'dd conv=swab', and then it worked.
For my 6.4 patch I enabled byte swapping in the
pata_falcon_data_xfer() function -- this allows me to use an IDE drive
with everything in the normal/compatible byte ordering, which makes
life much easier. I assume this is the intended behaviour.
That would be the sane behaviour, but the designers of both the Falcon
and apparently the TiVo decided otherwise, wired up the IDE data bus
byte-swapped and saved the byteswap operations in the driver. I'm unsure
how this was intended to work on Q40.
Why did Atari do that? Was it because they wanted to interoperate with
exotic filesystems (i.e. Microsoft) without paying a byte swapping tax in
software? (Despite the 68000 instructions for that purpose.)
Interoperability cannot have been a concern - otherwise they would have
made sure the on-disk format was compatible. Saving a byte swap
operation for each word transferred must have seemed worth it.
They just took what was available in terms of hard drive interfaces
(SCSI as well as IDE). IDE was 16 bytes wide, and the drive identify
data were ending up in the 'wrong' byte order, so they just swapped
those data.
As far as I know, neither floppy nor disk FAT formats are 100% identical
to the PC ones, just somewhat compatible.
I wonder if any existing Q40 users are actually storing all the data
on their drives byte-swapped just to avoid the overhead of
byte-swapping on every read/write. I suppose this would work just fine
until you need to connect that drive to another machine.
Yes, it does work just fine with that little inconvenience. (When I had
to fix a corrupted partition table an FAT, I had to hook the Falcon disk
up to a PC and run ARAnyM on it to get byte-swapped access to the data.)
Now the question is how data on legacy Q40 IDE disks have been stored.
If it's byte-swapped, we'd better keep that byte order in the current
driver (meaning your changes to pata_falcon_data_xfer() won't be needed,
but you would have to swap back data on your disk). If it's always been
in PC compatible byte order, all data (not just the identify data) must
be swapped.
I'd like to have Richard's opinion on this (or hear from any other
former Q40 user).
Yes.
If the Linux port for Q40 could use pata_legacy unmodified, that has to be
more maintainable. However, I could imagine a scenario where the standard
Q40 firmware, bootloader and/or vendor operating system would cease to
interoperate with Linux if Linux has no byteswapping IDE driver. If true,
would it matter?
I use the Atari TOS partition that the Falcon boots into to run the boot
loader from, and I transfer kernels to that partition from Linux using
the vfat file system (after copying them to the Linux partition over
ethernet). That would all break without a byte swapping IDE driver.
Something similar may be true for Q40 users, but there can't be many of
these left, otherwise I'd have expected to hear about the broken
pata_falcon issue a lot sooner.
Unix has a long tradition of pushing the byteswapping problem onto
userland for those who need to migrate data. Hence tools like cpio and dd
which are able to do byteswapping. One has to wonder whether drivers and
peripherals are the wrong places for that.
Probably not - in that regard, not caring about the on-disk format might
even be the Right Thing to do.
I suspect there's a way to do byte swapping on the fly using a loopback
device and some dm magic, so disks with the 'wrong' byte order could be
accessed on non-native systems. I just have never been bothered enough
about the issue to find out.
Most other Falcon users might use SCSI (and SCSI-SD adapters) to
transport data between systems. Not an option for Q40.
Cheers,
Michael
