FlashFloppy - new firmware for Gotek drives, open source

Originally Posted by Jeff_HxC2001

I will generate some HxC-bootloader-compatible UPD file of this FF firmware. That way you have nothing to wipe . I have already done this for the Cortex firmware.

As you say you have already done this for the Cortex firmware: Is that to be found somewhere on your site? Or was that for testing only and you'll release both later this week?

Either way: Thanks. I'd really like to compare, but wouldn't want to overwrite my HxC-Bootloader.

[Jeff_HxC2001]

Originally Posted by A1k

As you say you have already done this for the Cortex firmware: Is that to be found somewhere on your site? Or was that for testing only and you'll release both later this week?

Either way: Thanks. I'd really like to compare, but wouldn't want to overwrite my HxC-Bootloader.

This will be into this archive :

http://hxc2001.com/download/floppy_d...a_firmware.zip

In the subfolder "/Old_Firmware_Versions/other".
You can already found the Cortex firmware (v1.5)

[Keir]

Originally Posted by Jeff_HxC2001

Unless you are using a piezo speaker...

Most users wouldn't know either way. My cheap mini PC speakers from Ebay (you know, the really cheap ones with 4-way female header) are iirc 8-ohm. Wouldn't want to permanently connect direct to the MCU, really, even though it can drive them.

[Keir]

Originally Posted by SunSpire

I have tried another USB stick now (1GB, unbranded) and got the same results. The procedure was as follows:

• Formatted USB stick to FAT32 in Win7 x64
• Copied HXCSDFE.CFG and AUTOBOOT.HFE to USB stick's root (from this link)
• Created blank.adf with WinUAE 3.4.0 (it was pre-formatted with bootblock and FFS file system) and copied to USB stick

• Copied X-Copy (1993)(Cachet).adf to USB stick and booted it on a 1MB A500 machine with Kick 1.3
• "Killsys" command in X-Copy, then used DOSCOPY option to clone X-Copy itself, whole disk read in one session
• Wrote disk to blank.adf without any errors

However, after it finished copying I clicked DISKINFO and it would still show up as BLANK, 99% empty. Rebooting the system from this disk does nothing, the hand appears.

I forgot to ask, did the X-Copy steps include enabling verification on the target drive?

[Jeff_HxC2001]

Originally Posted by kaffer

Most users wouldn't know either way. My cheap mini PC speakers from Ebay (you know, the really cheap ones with 4-way female header) are iirc 8-ohm. Wouldn't want to permanently connect direct to the MCU, really, even though it can drive them.

Sure, a 8 ohms on the mcu is not a good idea, but many of these "gotek sound mod" use piezo "speaker" and in this case there is no issue to use an io to drive it. Maybe one : the level sound is somewhat low...

[Amiga1992]

Originally Posted by Jeff_HxC2001

Sure, a 8 ohms on the mcu is not a good idea, but many of these "gotek sound mod" use piezo "speaker" and in this case there is no issue to use an io to drive it. Maybe one : the level sound is somewhat low...

Does your new sound modification still work this way? Sending a pulse on the pin so a piezo can buzz?

[Methanoid]

Could someone link to a cheap compatible piezo on eBay then for us less knowledgable people, please??

[SunSpire]

Originally Posted by kaffer

I forgot to ask, did the X-Copy steps include enabling verification on the target drive?

Yes, verification was enabled. Although I'm pretty sure not enabling it would give the same result e.g. the target disk not being written to.

I managed to copy some system files on a dos formatted disk in Workbench that stayed on there after a reboot (v0.2.1a FW). So something seems to happen but it is not very reliable, yet

[Keir]

Originally Posted by SunSpire

Yes, verification was enabled. Although I'm pretty sure not enabling it would give the same result e.g. the target disk not being written to.

I managed to copy some system files on a dos formatted disk in Workbench that stayed on there after a reboot (v0.2.1a FW). So something seems to happen but it is not very reliable, yet

That's good. It ought to be reliable in verify mode. If it's not and I can reproduce it then that should be a nice bug to squash.

[BarryB]

There does appear to be an issue using X-Copy. Just tried to copy a WB 1.3 adf to a blank adf and it appears to copy, shows correct name if you use Diskinfo, but if you use Directory to get a files list it locks up and crashes the Amiga, if you boot the disk the Amiga says Disk corrupt! The adf seems to contain some data from the original, just not all of it, hexedit source/destination and the destination doesn't have all the data.

This is using an A500 Rev 6A with 512kb trapdoor RAM, Gotek with 0.21a, X-Copy September '93, Verify ON, didn't use KILLSYS!

Also, when you do a DISKINFO in X-Copy, what do all the numbers/letters mean? For each track it's either a number from 0 to 9 or letter A/B? On the original adf it shows mostly 0, but with the 'copy' there are numbers all over the place!

[Keir]

I've done quick X-Copy and Workbench-1.3 format tests and can see why these can be unreliable at the moment.

Firstly, X-Copy seems to 'bounce' the write-gate line when starting to write a track. It is asserted for some microseconds, then it becomes deasserted for a microsecond or so, before being reasserted for the full duration of the write (some 200ms). I don't know why, it's not consistent so it's probably a bug. This has scope for confusing FlashFloppy if it spots the short deasserted period in time to latch it, then it will miss the re-assert.

Secondly, WB-1.3 format, even though it verifies as it goes actually writes both tracks on a cylinder, then verifies them. Hence there are two track writes back-to-back with no verification phase between them and FlashFloppy can miss the second write if the write to the USB stick is a bit slow.

The X-Copy issue could be worked around, but the best solution for both these issues is to increase the write buffer and to allow buffering of multiple 'write phases' (separate assertions of the write gate) while analysis and write to USB stick catches up. I already intend to implement this -- I think I will prioritise it along with config-less operation.

[BarryB]

I guess this will this affect writing to 'save game' disks too? Might try one of those 1TB USB sticks off eBay for £12.99 and see if that helps

[ch40s_engineer]

I wouldn't suggest this, mate. those 1TB sticks are fake and somehow tricked to show that they have a large capacity. the truth is... they don't.

[Keir]

Save games are actually probably fine. Most save state is probably not more than a single track of data. As for buying USB sticks, as with any Flash storage, I would recommend sticking to known brands from a known retailer like Amazon (not marketplace).

[BarryB]

LOL, I know most high capacity USB stuff on eBay is junk, been 'given' a 256GB USB stick bought from eBay so that tells me the person doesn't trust them!

[Keir]

New release v0.3.0a: https://github.com/keirf/FlashFloppy/releases

* Supports config-less operation (HxC 'indexed mode' and also no config file at all!)
* Scroll long filenames (1602 LCD)
* Buzzer/speaker support (jumper JB)
* Hack workaround for X-Copy write problems (fingers crossed! Until I rework the write path, mucho work to do there)

[ch40s_engineer]

thanks, will test it tomorrow.
one thing I don't know for sure - do I need to update the bootloader/reloader each time?

[Keir]

Originally Posted by ch40s_engineer

thanks, will test it tomorrow.
one thing I don't know for sure - do I need to update the bootloader/reloader each time?

No. Generally the bootloader doesn't need update. But the option's there for anyone that wants the latest, or when I add fixes/updates in the future.

There have been some fixes since 0.2a iirc so could update if your bootloader's older than 0.2.1a. It's easy enough, just takes a minute in all rather than a few seconds.

[ch40s_engineer]

thanks for the clarification

[BarryB]

Flashed the Bootloader and firmware via USB without any issue.

LCD is scrolling the filenames so you can see which disk is which now

Also tested X-Copy and it now appears to work as expected with the 'hack' DIRECTORY shows the files and doesn't crash the Amiga now and DISKINFO shows the correct info on original/copy! The 2 disks I copied I had Verify on, the blank ADFs I copied to worked fine in the Gotek and the CRC32 matched the original ADFs

You sir, are a bloody GENIUS!!