Replies: 2 comments 1 reply
-
Sorry I forgot to reply to this! The answer is that the very vast majority are using D-A mode only for the AUTOBOOT file selector program, and putting guardrails on makes sense. I would consider dropping the guardrails if some special command is issued that is not going to happen by mistake. Eg. some kind of 128-bit uuid issued in a command. |
Beta Was this translation helpful? Give feedback.
-
Where is the information about direct access? I just bought a Gotek drive, put FF on it and have it connected to my PC. My intent is to modify my Ensoniq Disk Manager (EDM) to write Ensoniq files and ED* images directly to the Gotek drive. Additionally, users would be able to copy individual files to the floppy images since EDM has that capability. I have interface set to IBM-PC and host set to Ensoniq. I loaded a bunch of image files to the USB drive before connecting it to the drive. Currently EDM isn't able to read any of the disk images but I'm sure it's just some setting or jumper somewhere. Once I get all of that going, I'll be putting Gotek drives in all of my keyboards. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Let's start with the one that is currently the most important point for me (other features/discussions will follow, as there are some open questions to answer and design decisions to make for my Amiga driver prototype).
Besides the discussion in #610 - is there any good reason to block write access to other partitions?
Some background / use case: Most of my Amiga CF/SD cards have a dual RDB/MBR, where the RDB includes Amiga partitions/drivers and the MBR points to a FAT partition. With AmigaOS 3.2 CrossDOS it's pretty easy to share many large files on a medium with other operation systems. An Amiga D-A mode driver would allow access to the volumes on the FF medium - yes, very slow, but possible.
It would be nice to alter/remove the D-A mode LBA write limitation with lba_within_fat_volume (interestingly the only use of this function).
The FF option mentioned in #610 is not implemented yet. But let's face it, the limitation has been introduced to protect from an external software failure (that should have been fixed in the first place) and now prevents extended usage of the D-A mode. In fact, in my case I do not want to write anything to FF's FAT volume - no need for another FAT parser and no issues with possibly cached parallel access to the file system structures. In a perfect developer world I would like to be able to rewrite anything on the medium (lock system/device, initialize USB medium, and reset). If you want more protection, please just protect sector 0 and introduce a second I-know-what-I'm-doing parameter for sector 0 by default (a FF option to disable this check would be nice).
Best regards and many thanks for the hard work on this project.
Beta Was this translation helpful? Give feedback.
All reactions