Using the Gotek as usb transfer
 

Is it possible to transfer files on the usb drive attached to Gotek and get files on main system or is just for adf only?

It's for adf and possibly other formats (hfe/ipf?) so the files have to fit on floppy. You can access adf contents using adf opus on a pc.

https://sourceforge.net/projects/adfopus/

The hardware does have the capability of reading/writing any sector of the USB drive from the Amiga. That's how the selector program can read the list of files.
Someone "just" needs to write a .device to allow access to it. Then you could mount the partition and use fat95 to access files from the Amiga.

Is there any more discussion of that idea elsewhere on the web, mark_k? I hadn't realized that potential existed, and now I'm intrigued.

This is just how i have designed the HxC Direct Access protocol for the SD HxC Floppy Emulator. The HxC File selector running on the host machine "just" access directly to the flash media and mount the main partition to browse and select the hfe/adf images. Cortex and ff have made a copycat of this protocol.
Basically you can (slowly :D) access to 2TB of data trough the floppy interface.
The file selector software can be "easily" extended to copy files from/to the usb stick/sd card to/from the host system

Btw there is already a driver allowing you to mount Hard disk image on Atari ST from the floppy emulator : http://hxcmount.atomas.com/

And on Amiga someone have made an tool from the hxc file selector sources to make these copy possibles (without driver) :
http://torlus.com/floppy/forum/viewt...=1853&start=15

File selector sources (SD HxC / Gotek and Cortex compatible) :

https://github.com/jfdelnero/HXCFE_file_selector

Protocol documentation :
http://hxc2001.com/download/floppy_d...ccess_mode.pdf

You should not expect insane access speeds, though. :)

Sure. ~20KB/s

We've been spoiled. Even @~20KB/s it's still a cool option - why isn't this more widely discussed? Seems a valid PC<>Amiga file transfer option for anyone without any other options and a GoTek.

Thank SignMan for asking!

Sure, that's definitely slightly faster than putting all of your files on HFEs and having to load/eject them.

I'm imagining using this technique to play adventure games on my 1000, since I don't have a hard drive. With 6+ disks, it should be faster than disk-swapping on the HxC, no?

Is this game can be installed on hard disk ? If so, an special driver may do the trick. But i am not able to do this and it seems that few (nobody?) here are able to code an Amiga WB driver.

I think it's not a matter of ability, but a matter of willingness.
Someone might, eventually, though!

This is not a simple application. You have to know how to integrate the driver into the system by using the special low level api and without hacking. unless there is some documentations or similar driver sources somewhere, this is not a straightforward task at all.

Actually this kind of system friendly trackdisk.device-style driver would be quite simple. OS fully supports taking over floppy hardware temporarily.

No, I am not going to volunteer, at least not until it can be completely developed under emulation.

Ability to send SCSI commands would make it even more flexible (device driver could return correct max lba and other nice things). Can the hardware support some kind of USB SCSI passthrough?

If you poke the number of tracks word in the trackdisk private unitdata and set it to at least 512, you can access the HxC direct access mode through trackdisk.device. However, as it is presented as PC/DOS tracks you have to use TD_RAWREAD and decode the track yourself.

If the direct access mode could be presented as an Amiga track, it would be super simple to read using CMD_READ (no manual decoding) and it would also give a bit higher transfer rates as the data density of an Amiga track is higher than a PC/DOS track.

Perhaps just at another track number than 255/510 to not cause incompatibility with current direct access mode software. Would that be possible Jeff?

I prefer doing direct access with system friendly temporary "takeover" of the hardware (like SuperDuper did), makes it much more flexible.

Poking some system structures = no no. (It also would not work with KS1.x and I refuse to write programs that require KS 2.0+ unless there is some very good reasons :))

Yep to do it in a system-friendly way you'd need to at least write your own step-to-track-255 and track-writing code to tell the unit to "listen" on a different track number. Then you could maybe read/write with mfm.device to avoid having to MFM-encode/decode yourself. But since you already wrote code to issue the initial track-change command you wouldn't gain much.


If some future firmware has an alternate way to access the unit initially, you could maybe avoid writing your own low-level code. For example, if the firmware were to count outward step pulses when at track 0, stepping to track -123 or whatever could trigger it, but the Amiga would think the heads are at track 0 so you could read/write using mfm.device. But that technique might only be applicable to the Amiga, not platforms with normal floppy controllers (ST, CPC, etc.). One advantage of it though, would be that detection code wouldn't cause any clicking/noise, since almost all real floppy drives don't move the heads when told to step outwards at track 0.

Unfortunately all anti-clickers also work in this way, by constantly stepping out, so eventually the anti click would trigger the data transfer mode.

Add time as a condition also?

The best solutions are the simplest, good point. :-)

So you can copy files To and From the USB but can you run files from it?