QubIDE media layer query

[Mark Swift]

I've been wondering why QubIDE images written by QDOS Classic under emulation end up byte-swapped.
Nothing jumps to mind so I took a look at the original unmodified QubIDE sources.

The driver correctly byte-swaps word data before sending it to the IDE controller, because the controller expects word data to be little-endian.

I may be missing something; I had to scribble the logic down to picture what was going on (tidied up below).

To me it appears as if the data may well end up being written out to the end media byte-swapped.

I'm wondering if the data buffer should have been byte-swapped; simulating a little-endian source; before being byte-swapped and written to the controller; negating the need for byte-swapping the data buffer in the first place. To be honest, It's a bit mind boggling.

Anyone got any views on this?
...and has anyone ever dumped a true QL QubIDE formatted disk to a hardfile?

I'd be interested to see if it starts with "LQ1W" instead of "QLW1".

[XorA]

Dumped on a linux PC from a QL qubide!

[Mark Swift]

Dumped on a linux PC from a QL qubide!

Wow, that was quick.
I guess that means that the byte-swapped hardfile is the true QubIDE format.

[Peter]

Dumped on a linux PC from a QL qubide!

The usual mistake. One can not use a little-endian system to directly read big-endian data on a 16 bit bus.

A QL QubIDE formatted harddisk, just as a Q40/Q60 QubIDE formatted harddisk, reads "QLW1" on big-endian hardware.

[Mark Swift]

Hi,

Dumped on a linux PC from a QL qubide!

The usual mistake. One can not use a little-endian system to directly read big-endian data on a 16 bit bus.

A QL QubIDE formatted harddisk, just as a Q40/Q60 QubIDE formatted harddisk, reads "QLW1" on big-endian hardware.

I guess I jumped to a conclusion even though XorA clearly stated it was dumped from a linux PC.

There was a niggle at the back of my mind that made me think I was missing something.

However I had in mind that that the dump was probably made with dd, that compensation is made for the fact that the IDE hardware is little-endian, and that there would be an abstraction layer between the hardware and the OS to present the data in an agreed order.

Otherwise you wouldn't be able to move a linux formatted drive between systems with different endianess; which might be the case.

So I am now wondering if there is an agreed order in which modern OSs present the low level IDE storage order to the upper file system.

Is anyone running linux on big-endian and little-endian hardware?
Are they able to dump a drive to file to see if it presents in the same order?

[Peter]

However I had in mind that that the dump was probably made with dd, that compensation is made for the fact that the IDE hardware is little-endian, and that there would be an abstraction layer between the hardware and the OS to present the data in an agreed order.

Yes it can be corrected by using dd with the swab commandline option on a little endian machine.

Is anyone running linux on big-endian and little-endian hardware?

Yes, I run RedHat + Shoestring Linux on Q60 and Debian 12 on a PC. Both pull the same image from an attached IDE drive, if swab is used on the PC but not on the Q60. I did not try that exactly with a QubIDE formatted drive, but with an atari-fdisk formatted drive. "Same image" means "same image" though, regardless the content.

[XorA]

I am pretty sure the IDE port on Amiga is little endian.

So natively the Amiga will see the same byte swapped image as a PC.

[Peter]

I am pretty sure the IDE port on Amiga is little endian.

Yes, it would be exactly my next step to try and find some Amiga IDE schematics.

[Peter]

It's not easy to see due to the poor schematics, but the Amiga IDE interface does indeed byte-swap as Graeme suggested:
https://www.amigawiki.org/dnl/schematics/A4000_Rb.pdf
Atari and Q40/Q60 interfaces do not byte-swap.

[XorA]

From A600 schematic. Confirms Peters post!