FlashFloppy / Gotek floppy emu working with OSI disk images

Mark
Posts: 292
Joined: Tue Sep 16, 2008 6:04 am
Location: Madison, WI
Contact:

Re: Flash Floppy / Gotek floppy emu working with OSI disk images

Post by Mark »

I have recently flashed my 2nd Gotek drive with the current HxC firmware and have been experimenting with it.
As others have pointed mentioned, FlashFloppy works great, HxC does not. HxC seems to read OK, but writes are not working well.

I've been decoding the corrupted HFE data created by HxC and have some theories, but no solutions today. I'm happy to hear the OSIHFE images are working well with FlashFloppy. OSIHFE was built to emulate the data and timing found in the kryoflux conversions, except the tracks are all padded to the same length.

Decoding HxC corruptions, I find the track data is perhaps written with dirty memory, possibly old memory buffers are being reused. Generally data is written with clock bits and zero's for data when there in no OSI data (preceding an index hole, between sectors, or at the end of track), but I am seeing blocks of all NULLs from HxC (a no-no for FM data) as well as data left over from previous tracks. Perhaps the RAW FM tracks are too long or perhaps HxC needs loss of sync (NULS) at the end of track... I'm looking into a number of things.

If you have HxC Gotek, I believe you can reflash with the free FlashFloppy firmware. Although I have now used both serial flash as well as USB-A to A, the USB method is a lot less error prone. You don't have to deal with possibly dodgy serial chipset drivers and cloned serial chips!
Please let me know about your successes and failures with conversions!

-Mark
Last edited by Mark on Thu Sep 19, 2019 4:56 am, edited 1 time in total.
tanteju
Posts: 17
Joined: Mon Dec 24, 2018 12:28 am

Re: HxC / Gotek floppy emu working with OSI disk images

Post by tanteju »

Mark wrote: Mon Jan 21, 2019 1:52 am I have recently flashed my 2nd Gotek drive with the current HxC firmware and have been experimenting with it.
As others have pointed mentioned, FlashFloppy works great, HxC does not. HxC seems to read OK, but writes are not working well.

I've been decoding the corrupted HFE data created by HxC and have some theories, but no solutions today. I'm happy to hear the OSIHFE images are working well with FlashFloppy. OSIHFE was built to emulate the data and timing found in the kryoflux conversions, except the tracks are all padded to the same length.

Decoding HxC corruptions, I find the track data is perhaps written with dirty memory, possibly old memory buffers are being reused. Generally data is written with clock bits and zero's for data when there in no OSI data (preceding an index hole, between sectors, or at the end of track), but I am seeing blocks of all NULLs from HxC (a no-no for FM data) as well as data left over from previous tracks. Perhaps the RAW FM tracks are too long or perhaps HxC needs loss of sync (NULS) at the end of track... I'm looking into a number of things.

If you have HxC Gotek, I believe you can reflash with the free FlashFloppy firmware. Although I have now used both serial flash as well as USB-A to A, the USB method is a lot less error prone. You don't have to deal with possibly dodgy serial chipset drivers and cloned serial chips!
Please let me know about your successes and failures with conversions!
I'd like to test FlashFloppy, but as mentioned before, the update procedure via USB stick does not work. HxC does not accept the UPD file from FlashFloppy. I'm not sure, what the reason is for this one. I refrain from updating via serial so far.
Mark
Posts: 292
Joined: Tue Sep 16, 2008 6:04 am
Location: Madison, WI
Contact:

Re: Flash Floppy / Gotek floppy emu working with OSI disk images

Post by Mark »

This is what I've learned.
Flashfloppy uses a different bootloader than HxC. You purchase the bootloader for HxC and it is installed with your license key. Once used it appears you can not use it again. FlashFloppy uses it's own free bootloader that is not compatible with HxC. Although you can go from HxC to FlashFloppy by installing FlashFloppy bootloader, it appears you can not go from FlashFloppy to HxC without buying another license. You can not use software updates with the other platform's bootloader.

There are two ways to install the bootloader on the Gotek drives, the TTL serial method and the USB-A to USB-A method. See https://github.com/keirf/FlashFloppy/wi ... rogramming
I have used both methods, but ran into several problems with the FDTI232 and PL2303 serial interfaces that ran me in circles for awhile. DOA circuits, windows driver issues, flakey transfers etc. If you are programming the FlashFloppy bootloader, the USB-A to A method seems the least error prone, and it's super quick! You just need to download the Dfuse software from ST Microelectronics to program it (and get/make a USB-A to USB-A cable). There is a nice description of the procedure here: http://www.binarydevotion.com/?p=228

Having spent a few more hours with HxC and OSI, I can not recommend it for use with OSI. It will need some updates from the developer before it is stable for writes. I don't think it's worth the effort to try and diagnose the problem at this point when there is a perfectly working open source solution available that runs on the same hardware. I regret I did not understand the differences between the different firmware projects when starting this thread. It should be "Flash Floppy / Gotek floppy emu working with OSI disk images".
So at worst someone with HxC firmware is out the cost of the HxC license, but FlashFloppy should make the Gotek drive work as intended. Or purchase another Gotek drive (they are less than $20) and use FlashFloppy on the new drive.

I hope the helps!

-Mark
Last edited by Mark on Thu Sep 19, 2019 4:55 am, edited 1 time in total.
tanteju
Posts: 17
Joined: Mon Dec 24, 2018 12:28 am

Re: HxC / Gotek floppy emu working with OSI disk images

Post by tanteju »

Mark wrote: Tue Jan 22, 2019 5:34 am This is what I've learned.
Flashfloppy uses a different bootloader than HxC. You purchase the bootloader for HxC and it is installed with your license key. Once used it appears you can not use it again. FlashFloppy uses it's own free bootloader that is not compatible with HxC. Although you can go from HxC to FlashFloppy by installing FlashFloppy bootloader, it appears you can not go from FlashFloppy to HxC without buying another license. You can not use software updates with the other platform's bootloader.

There are two ways to install the bootloader on the Gotek drives, the TTL serial method and the USB-A to USB-A method. See https://github.com/keirf/FlashFloppy/wi ... rogramming
I have used both methods, but ran into several problems with the FDTI232 and PL2303 serial interfaces that ran me in circles for awhile. DOA circuits, windows driver issues, flakey transfers etc. If you are programming the FlashFloppy bootloader, the USB-A to A method seems the least error prone, and it's super quick! You just need to download the Dfuse software from ST Microelectronics to program it (and get/make a USB-A to USB-A cable). There is a nice description of the procedure here: http://www.binarydevotion.com/?p=228

Having spent a few more hours with HxC and OSI, I can not recommend it for use with OSI. It will need some updates from the developer before it is stable for writes. I don't think it's worth the effort to try and diagnose the problem at this point when there is a perfectly working open source solution available that runs on the same hardware. I regret I did not understand the differences between the different firmware projects when starting this thread. It should be "Flash Floppy / Gotek floppy emu working with OSI disk images".
So at worst someone with HxC firmware is out the cost of the HxC license, but FlashFloppy should make the Gotek drive work as intended. Or purchase another Gotek drive (they are less than $20) and use FlashFloppy on the new drive.
Thanks for sharing your experience. That explains a lot.
As I have no Windows the USB Variant seems to be no option for me, as STM only provides Windows software. And I prefer not to replicate your experience with flaky serial updates. It seems I either need to buy another Gotek or wait for the developer of HxC to fix the issue. Ihave limited time next 6 weeks anyway and the computer is 35 years old, I think I can wait for another Gotek to be shipped.
tanteju
Posts: 17
Joined: Mon Dec 24, 2018 12:28 am

Re: HxC / Gotek floppy emu working with OSI disk images

Post by tanteju »

The FlashFloppy WIki describes a procedure how to USB-load a Gotek drive via USB from Mac or Linux. I've sacrificed two USB cables and indeed, this worked instantly.

And now I can write to the drive and read back. GREAT SUCCESS!

But (didn't you expect it?):
1. Multisector tracks created with OSIHFE could only be overwritten in sector 1 and 2. If sector 3 is overwritten, the track markers get corrupted. Only way around is storing all sectors in RAM, init the track and then write the sectors on a fresh track. That works.
2. Every write on disk gets back ERR#9. The written data is there and the track is error free, but this error is strange. I know, there was a command in 8" OS65D to disable this error. But I have no such error writing on 5,25" disc. Any setting in FlashFloppy to get this solved?
3. The controller maps drive a and b to both sides of a single drive. It seems like the Gotek cannot do anything similar, mimicking a double sided disk. Any workarounds known?

I've now first of all saved all data that still was readable from my last partly working floppy to Gotek and will now try to get a working disc.

Thanks so far for all the help.
Mark
Posts: 292
Joined: Tue Sep 16, 2008 6:04 am
Location: Madison, WI
Contact:

Re: FlashFloppy / Gotek floppy emu working with OSI disk images

Post by Mark »

Great news getting FlashFloppy to work!

#1: The timing and spacing of data on the HFE file could be wrong. OSI uses a delay between sectors that may be too short in the HFE image created by OSIHFE. If the track is formatted and written by Gotek, the timing between sectors may be more accurate. However it doesn't seem like this is working for you. It could be a problem with the RawFM implementation in FlashFloppy.

I am confused by #2. ERR#9-"Can't find track header within one revolution of diskette." If the index signal was sent at the wrong time this could happen. Early OSIHFE images had this problem when there was not enough delay at the start of track. (The simulated index signal was still active when the track data started & OSI ignored the start of track data.) Unfortunately I'm not sure how FlashFloppy generates this signal. I haven't worked with FLashFloppy much yet to be honest.

According to OSI, command "D9" will disable error 9, required to load some V1.5, V2.0 files on 8" systems. Not sure what this actually does or what OS65Dv1.5 or 2.0 did to require this command.
I haven't seen ERR#9 on every write on FlashFloppy on 5.25" drives. I do see this with HxC. If you are using 8" drives, then I believe you are the first! Although Dave's gone from Kryoflux 8" to HFE to get disk timing, I don't have Gotek connected to an 8" controller to test. Maybe I misunderstood.

If you use the '-v' option with OSIHFE, it will spit out a lot of information found during decode, including the gaps found by counting FM 0's. That may tell you more about the corruption on multisector tracks.

Code: Select all

osihfe -v -d dska0000.hfe
Track 0
-------- Zeros 376

22 00 08 A9 01 8D 5E 26 20 BC 26 A9 2A 85 FF 20
54 27 86 FE 20 67 29 20 79 2E 8E 01 F4 8E 00 F4
8E 03 F4 CA 8E 01 DF 8E 02 F4 AD 06 FB 8E 05 FB
...
Track 1
-------- Zeros 1491

43 57 01 58  Zeros 247

76 01 08 52 41 43 4B 20 00 68 20 92 2D BA 86 FC
20 54 27 E8 8E 5E 26 20 C4 28 A9 00 85 F9 20 98
...
You can play with the timings generated with OSIHFE. It's easy to build OSIHFE from source on Mac, as long as you have the free Apple compiler XCode installed. In Terminal, type 'make' in the OSIHFE source directory, find osihfe executable in the /build folder. To change track timing see ~line 469 in hfe.cpp, intersector delay is a hacked value ln# 855.

#3 - I don't see why FlashFloppy would have a problem writing to side B as long DRVSEL & SIDE1 are hooked up right. Right now OSIHFE just fills side B with FM sync signals, no data. Have you tried formatting it? If I recall right, disk A side B would be disk "C", at least on my system if I had it wired right. I haven't tested that... not sure how my 2 drive system is wired up!
I could have OSIHFE write data to side B too. It just seemed too complicated at the time having two disk images in one HFE file.
According to OSIDump PB5 is side select. PA6 is drive select. I guess you could wire it how you like.

Code: Select all

;SELECT DRIVE PB5 PA6  DRIVE (1-4)
;              0   0	#4
;              0   1	#3
;              1   0	#2
;              1   1	#1
Good luck,
-Mark
Mark
Posts: 292
Joined: Tue Sep 16, 2008 6:04 am
Location: Madison, WI
Contact:

Re: HxC / Gotek Flash floppy emu working with OSI disk images

Post by Mark »

I recently uncovered a bug with OSIHFE that prevented successful creation of OS65U disk images. The sector length was a few bytes too short. This has been fix in the latest version 1.4. I have not yet attached Flash Floppy as an 8" drive so it took me a while to notice this!

I've also increased the index hole timing gap used when writing an 8" floppy image at 5.25" speeds for Flash Floppy, all of which makes successful boot of OS65U on a 5.25" minifloppy system possible. (Not sure why you would want to do that, but you can.) The OS thinks your machine is faster than it is because it expects 8" floppy clock & spin rates but is getting 5.25" rates. (250kHz/360rpm vs 125kHz/300rpm). This is what I see on my C4PMF:
os65u on 5.25"
os65u on 5.25"
os65u5.jpg (47.02 KiB) Viewed 8860 times
(I haven't played with it much except to boot it, and run a few commands.)

The disk image clean option in OSIHFE has been updated to show when OS65U tracks fail checksum too, which will prevent load by the OS.

I've also become aware of some much more extensive disk timing documentation in Compute's Gazette #20 which makes me believe the sector timing generated by OSIHFE will be off for multi-sector OS65D disk images. You should be able to read all data, but if a sector is rewritten insitu, it may corrupt later sectors. This is not a problem for other OS' that write disks a track at a time. More investigation is needed.

Attached is OS65U v1.44 CD7 HFE image in case someone wants to play with it. You can't write it to a real 5.25" floppy, but you can use it in Flash Floppy.

Update: It needs 32K to boot!

-Mark
Attachments
OS65U-5.zip
OS65U HFE image for 5.25" drive systems
(255.57 KiB) Downloaded 530 times
Last edited by Mark on Wed Nov 20, 2019 4:44 pm, edited 3 times in total.
dave
Site Admin
Posts: 710
Joined: Tue Sep 09, 2008 5:24 am

Re: HxC / Gotek floppy emu working with OSI disk images

Post by dave »

Mark wrote: Tue Jan 22, 2019 5:34 am I regret I did not understand the differences between the different firmware projects when starting this thread. It should be "Flash Floppy / Gotek floppy emu working with OSI disk images".
Hi Mark,

The thread title is the subject line of the first entry. I changed it to FlashFloppy instead of HxC. Are you able to edit the subject of the first post as well? I don't think this forum expires the edit rights.

The subject in the followup posts doesn't automatically change, since people can make the subject whatever they want.

Dave
Mark
Posts: 292
Joined: Tue Sep 16, 2008 6:04 am
Location: Madison, WI
Contact:

Re: FlashFloppy / Gotek floppy emu working with OSI disk images

Post by Mark »

Ah, didn't know I could do that. Thanks Dave
lowrybt1
Posts: 212
Joined: Sun Mar 08, 2015 3:42 pm
Location: New York State

Re: FlashFloppy / Gotek floppy emu working with OSI disk images

Post by lowrybt1 »

Hello,

Has anyone figured out the mechanics of connecting a GoTEK to an 8" floppy drive? I have about 50 8" floppies that I would like to write onto a thumbdrive using the GoTEK

Tom
C8PDF w. 48K, 2x 520 24K RAM boards and Glitchworks 64K board
OSI 567 Telephony board
Spare 8" drives
Klyball D-13
Post Reply