Closed Dunkelwind closed 1 year ago
Hello Steffen,
The integrated driver uses "modern" MS-DOS LBA partitions and FAT descriptors. The ROOTBLK structure you pasted seems to be for TOS format partitions. These structures aren't compatible with the MS-DOS format so your tools might be confused (I don't know SED). Structures used by the internal driver can be found in asm/a2stdrv/structs.i
TOS does not require specific on-disk structures, all it uses is the GetBPB system function to return correct pointers to FAT12/FAT16 structures on-disk, but the header can have any format as long as the boot sector has the correct checksum. I chose to use modern MS-DOS structures to maximize compatibility with modern OSes and tools.
I'm not sure whether this answer addresses your issue, feel free to ask more precise questions if you have problems or if you want more information.
JM
Hello JM, tnx for the infos & clarification. I found out that it is better to use the HATARI image for the HD emulation. This provides the correct BPB. All the hardware-related software now works (SED, Turboass, Bugaboo....) I think, deliver only the FAT-pointer is not good enough for a good emulation. Maybe you could calculate the right BPB on the fly? But anyway, I'm using the HATARI-image now. Unfortunately, the data exchange is then more complicated (using HATARI or loop devices)
Steffen
The BPB is calculated on the fly: all hard disk drivers do that by hooking the GetBPB (the system call documented here: https://freemint.github.io/tos.hyp/en/bios_functions.html). In the case of the ACSI2STM internal driver, the calculation is implemented in asm/a2stdrv/getbpb.s. The tools you use seem to recompute the BPB from structures on disk, but this only works for the partition types they are compatible with. If you want to check the actual BPB returned by the driver (and used by GEMDOS/TOS), you need to use the tool CHKDISK3.PRG provided by the AHDI v6 package. This tool uses the BIOS level interface to show the BPB and FAT structures as seen by the OS filesystem.
Because on-disk formats are more or less specific to their driver, you can't mix low level disk manipulation tools like you would do on PC, you have to use the disk management tool provided by the driver you use, and in the case of the ACSI2STM driver it's its setup tool you start by typing Shift+S at boot or running A2SETUP.TOS.
Now, there is a possibility that the driver actually returns a wrong BPB, and I'm interested in any potential bug feedback. For example, you mention Turboass in the things that don't work, and as far as I know this tool isn't doing low level access. Can you describe a bit more this use-case and how it fails ?
Thanks, JM
OK, here an example for the problem: SD-Card:
Festplatte /dev/sda: 14,87 GiB, 15946743808 Bytes, 31145984 Sektoren
Festplattenmodell: STORAGE DEVICE
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xecccb2a2
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 32 524287 524256 256M 6 FAT16
show directory with GEM:
show directory with Bugaboo:
CHKDISK3.PRG:
try fopen on Bugaboo to write output to disc:
Turboass displays a src incorrectly:
Steffen
Found the issue ! GetBPB is now fixed in the (beta) release 3.1b. rwabs in physical mode is still known to be wrong, this will be fixed for actual stable 3.10.
Hi JM,
I think, v3.10 is buggy too. Even the HATARI-image stops working properly:
V3.01 with HATARI-image works fine so far I know.
Steffen
Hint:
Manual Turboass says:
6.11 Interna des Debuggers
Bei Disketten-/Festplattenzugriffen: XBIOS 8/9 beim Lesen/Schreiben eines Sektors, XBIOS 10/18/9 beim Formatieren, Bei allen Dateioperationen wird (natürlich) das GEMDOS benutzt.
Closing as 4.00 doesn't provide a BIOS level driver anymore.
Hello, sysinfo.prg & SED (from Scheibenkleister) reports wrong BPB. Here are the infos from SED:
Why is the root sector not correct?
Top
Steffen Atari STFM. 3MByte, TOS1.04 & 2.06