FlashFloppy - new firmware for Gotek drives, open source

[fragedthewife]

Not sure I understand sorry, Have you got a dedicated file selector to go with your flash floppy firmware. The cortex one was nice with the simulated star field

[Amiga1992]

Originally Posted by fragedthewife

Not sure I understand sorry, Have you got a dedicated file selector to go with your flash floppy firmware. The cortex one was nice with the simulated star field

Use the HxC selector.

The Cortex one won't run (it was terrible anyway).

[Keir]

Originally Posted by nguga

kaffer , in spite the hxcmount , hard disk works and i can read what inside folders and also see the text( content..) inside of files , i can not run programs... takes ages and then 2 bombs

Bus Error........................2 bombs

On reflection this is probably because hxcmount uses a non-default value for num-sectors parameter when talking to the drive. I can send you a candidate fix for this if you like?

[fragedthewife]

Will this also work using Gotek on Atari St ?

[Keir]

Originally Posted by fragedthewife

Will this also work using Gotek on Atari St ?

Yes and many other systems too.

[Mq]

I confirm. Yesterday I connected Gotek to my 1040STE and it works very well with st images. Thanks a lot once again Kaffer! Good work!

[antiriad76]

I also noticed that the latest 0.8.7a Firmware it doesn't include the alternative 7x16 Characterset firmware file with the narrower fonts for us who haven't modified the OLED Window.

Would it be possible to control the font size with a parameter in the settings file instead of having separate firmware?

Other than that this Firmware gets better and better.

Thanks again for your hard work.

Mike

[Mq]

antiriad76: Have You seen a config file example? If not, then look there better:-)

[antiriad76]

Originally Posted by Mq666

antiriad76: Have You seen a config file example? If not, then look there better:-)

You can read minds.....

[Mq]

Hi kaffer, I have a suggestion, but I think it's suggestion is "must be":-)
I'm going to build Gotek inside my Atari ST and I want to have only encoder with button instead of two standard buttons. But if that two buttons are no longer available, then I will not be able to do updates from pendrive.
To perform update we must hold on two buttons on startup.
Is it possible to duplicate this function by holding third button on startup?
I think such function will give us to overall choose between using two buttons or encoder.

[Keir]

Originally Posted by Mq666

Hi kaffer, I have a suggestion, but I think it's suggestion is "must be":-)
I'm going to build Gotek inside my Atari ST and I want to have only encoder with button instead of two standard buttons. But if that two buttons are no longer available, then I will not be able to do updates from pendrive.
To perform update we must hold on two buttons on startup.
Is it possible to duplicate this function by holding third button on startup?
I think such function will give us to overall choose between using two buttons or encoder.

Yes agreed.

Hey,just confirming that when using the Latest Original HxC Selector Autoboot file,cannot use ADF Files? Boots to Selection menu,browse dirs,select adf's,reboot with F10,use buttons to select,Shows Unknown for adf files.
Og course with forked selector can select with buttons/OLED,works ok,but no Amiga Screen Selector,etc.
Have sample FF config on drive with forked Selector & standard HxC config file with Orig Selector setup.

[Keir]

Originally Posted by skIderic

Hey,just confirming that when using the Latest Original HxC Selector Autoboot file,cannot use ADF Files? Boots to Selection menu,browse dirs,select adf's,reboot with F10,use buttons to select,Shows Unknown for adf files.
Og course with forked selector can select with buttons/OLED,works ok,but no Amiga Screen Selector,etc.
Have sample FF config on drive with forked Selector & standard HxC config file with Orig Selector setup.

This isn't the clearest bug report: Are you saying doesn't work with latest alpha HxC autoboot file selector, but does with older versions?

Not really a bug report.Forked version has no onscreen menu,using latest v0.8.7a & sample config,file,is this correct?
Ok,just now tried New V1.65a HxC onscreen Selector For Orig HxC Floppy Emu & it loads ADF's fine! That was my main concern.
Thanks for this GREAT Software!

[cbrunschen]

Originally Posted by kaffer

(Note: 1.44MB (HD) image support is not yet reliable).

Is HD support in something that may become available in the not-too-distant future? I'm asking because one of my target devices is an Ensoniq ZR-76 keyboard that uses 1.44MB DOS-formatted floppy disks.


Also, another slightly strange question / request.

I'm specifically looking to use another couple of these drives in Ensoniq VFX-SD and SD-1 keyboards, from the same era as the EPS-16+. All of these use DS/DD floppies, with a format that is almost standard MFM –but with 10 sectors per track, numbers starting from sector 0 (zero), so numbered 0 to 9.

Currently, raw disk image files in certain standard formats are recognized by their size; an 800 kB image such as those would be (512 bytes * 10 sectors * 80 tracks * 2 sides = 819200 bytes = 800 kBytes) would be recognized as having the correct number of tracks & sectors & sides, but would likely be served as having sectors number 1 to 10, rather than 0 to 9 as the keyboard expects.

So against that background; would it be possible to have something somewhere in a configuration file that might allow specifying that "any file with this extension should be treated as a raw disk image with these particular settings"? That way, I wouldn't need to convert the disk images to HFE format.

Best wishes,

// Christian

[Keir]

Originally Posted by cbrunschen

Is HD support in something that may become available in the not-too-distant future? I'm asking because one of my target devices is an Ensoniq ZR-76 keyboard that uses 1.44MB DOS-formatted floppy disks.

In this case you can use 1.44MB IMG files no problem.

I'm specifically looking to use another couple of these drives in Ensoniq VFX-SD and SD-1 keyboards, from the same era as the EPS-16+. All of these use DS/DD floppies, with a format that is almost standard MFM –but with 10 sectors per track, numbers starting from sector 0 (zero), so numbered 0 to 9.

Currently, raw disk image files in certain standard formats are recognized by their size; an 800 kB image such as those would be (512 bytes * 10 sectors * 80 tracks * 2 sides = 819200 bytes = 800 kBytes) would be recognized as having the correct number of tracks & sectors & sides, but would likely be served as having sectors number 1 to 10, rather than 0 to 9 as the keyboard expects.

So against that background; would it be possible to have something somewhere in a configuration file that might allow specifying that "any file with this extension should be treated as a raw disk image with these particular settings"? That way, I wouldn't need to convert the disk images to HFE format.

Yes something like this is possible. I was thinking perhaps when opening an IMG file to search the same subfolder for a format specifier file (img.cfg?)

But it could instead be done as a global config file specifying a set of suffix -> {sides/sectors/sec_sizes/sec_ids} type info?

[Supamax]

Hi kaffer,
I don't remember having asked it or not before, but:

do you think it would be easy to implement a direct access (on FAT/FAT32 filesystem) for the USB key, so that one could save a file from WB to USB and then see it directly on the PC?

It would be a GREAT (definitive, I would say) way of transferring files from Amiga to PC and vice-versa.
Way better than using PCMCIA-CF adapters or the not-yet-finished SD floppy interface.

EDIT: it wouldn't be limited in file sizes, also (one could transfer multi-megaBytes files). A beautiful solution!

[Keir]

Originally Posted by Supamax

Hi kaffer,
I don't remember having asked it or not before, but:

do you think it would be easy to implement a direct access (on FAT/FAT32 filesystem) for the USB key, so that one could save a file from WB to USB and then see it directly on the PC?

It would be a GREAT (definitive, I would say) way of transferring files from Amiga to PC and vice-versa.
Way better than using PCMCIA-CF adapters or the not-yet-finished SD floppy interface.

EDIT: it wouldn't be limited in file sizes, also (one could transfer multi-megaBytes files). A beautiful solution!

It could be done, something in this direction already is the hxcfe copy utility: https://github.com/gonk23/HXCFE_Amiga_copy_utility

This would be better if it was presented as a block-device driver which AmigaOS could then mount as a fat filesystem. I don't think this would necessarily be very hard, I have personally never done an AmigaOS device driver though.

The other thing to bear in mind is that copies will happen at floppy speed, which is approx 25kB/s, or 40 seconds per megabyte. Pretty slow.

[Supamax]

Originally Posted by kaffer

It could be done, something in this direction already is the hxcfe copy utility: https://github.com/gonk23/HXCFE_Amiga_copy_utility

Interesting .
I see that it (still) has a big limitation, though: not able to copy from Amiga to HxC. Only the opposite.

The other thing to bear in mind is that copies will happen at floppy speed, which is approx 25kB/s, or 40 seconds per megabyte. Pretty slow.

Ok. Not a big problem for me .

EDIT: could it implement realtime compression/decompression while copying? (to save time during copy)

[Keir]

Originally Posted by Supamax

Interesting .
I see that it (still) has a big limitation, though: not able to copy from Amiga to HxC. Only the opposite.

I would quite like to pursue this down the line, but I have other priorities on FlashFloppy for now, and little enough time.

Ok. Not a big problem for me .

EDIT: could it implement realtime compression/decompression while copying? (to save time during copy)

Real-time compression would be the problem, particularly on an unaccelerated Amiga.