TI99 support reads but does not write

[mvancopp1]

Hi,
Thanks for supporting the Gotek drive and theTI99!
I am using FlashFloppy with a Geneve (a TI99 compatible with some differences). This setup uses a Myarc floppy/HD controller. When setting up the FF.CFG with host = ti99 the 180k and 360k dsk files read correctly but cannot write. If the file exists and you copy it again the drive appears to read/write and completes without error (and the file is good). If you copy a new file the drive again appears to read and write but the errors trying to update the FAT. If you re-format the dsk the format and verification succeed but the old file are still intact and good (the write never occurred).
If I install a real TI FDC instead of the HDFC the read/writes work on the 180k and the 360k is not supported on that FDC.
Should I be able to remove the host = ti99 and make this work with an equivalent IMG.CFG file and entries? I have tried but have not been successful with the IMG.CFG. I am hoping this is a gap setting issue that could be solved in the IMG.CFG.
BTW, both the TI FDC and Myarc HDFC work on real drives.

Any help is diagnosing this would be appreciated!

Thanks
Mark

[keirf]

IMG.CFG setup for TI99 images is quite complex. I attach what I think is correct for 180k and 360k images. Note the images must be exactly that size: some are 3 sectors longer containing a bad-sector map, and will not match the given IMG.CFG stanzas.

Is this an Artery or STM32 Gotek do you know?

IMG.zip

[mvancopp1]

This is an Artery.
I removed the FF.CFG and reset the drive. This made all dsk files unreadable.
Added the IMG.CFG to the FF folder on USB stick. Both 180k and 360k files read, thank you. Writes still fail.

I need to find away to get the gap(1-3) information and see if changing those corrects the issue. Since this is an emulated drive and the file is sequential sectors, what does the interleave and cskew do? Are they just for timing?

Thanks for your help.

[keirf]

Interleave rearranges sectors on each track so that logically sequential sectors are spaced at the interleave factor. It gives the host more time to process one sector before needing to read the next.

Skew rotates the sectors on successive tracks so that sector 1 isn't always the first on a track. It means that after allowing for stepping from one track to next, you don't miss the first sector and have to wait a full revolution.

Reason to believe Artery is less reliable for writes than STM32 due to having half as much ram so less buffering available. It may depend on the host that's connected. It may depend on the usb stick (try another if you can)

[mvancopp1]

I have tried four different USB sticks of different sizes and all different brands. No USB3 sticks, all 2.0 of 8 gig or smaller.
I understand cskew and interleave and their purpose. Do you actually rearrange the sectors or just artificially change the timing before presenting the next sector? Just curious.
Buffer size for: 9 secs * 256 bytes * 1.5 overhead = 3375 -> 36 secs * 256 bytes * 1.5 overhead = 13.5k.
Those are just rough estimates based on writing a PC99 emulator and the average track size (PC99 read the original tracks and emulated the disk at the track level). I don't know what RAM overhead the rest of FlashFloppy needs to operate but it looks like ~13.5k (~42%) of the RAM is needed for the largest possible floppy. In any case even the DSSD fails to write at the lower 125k write speed and 9 secs. Is buffer size at that level still a concern? This seems more likely an emulated track detail issue (I am hoping a problem is in the gaps).

Mark

[keirf]

Maybe compare real drive versus Gotek via dumping hardware such as Greaseweazle?

[keirf]

You could also try alpha release FlashFloppy v4.3a which buffers writes in a very different and more efficient manner.

[mvancopp1]

I don't mind buying the Greaseweazle but I am not sure how that will help. I can select the dsk file and read it fine and the writes act as if they are working (the write led "-" flashes and reads occur as it tries to find space on the drive) but the data is never altered on the disk (in the dsk file). The dsk file remains unchanged. So I am not sure how reading the data off the Gotek will help when the data is not altered and the reads work. Thoughts?
I just received information on the AtariAge forum' TI99 section that a user has a Lotharek with HxC software and it suffers the same reads ok but cannot write issue. This maybe a hardware incompatibility although the many different real floppy drives work.
I'll look at the newer releases. I assume I can back down to the 3.X software if I need too?

[mvancopp1]

Confirmed v4.3a has the same issue. Are there any new CFG knobs that can be tweaked?

[keirf]

By doing raw dumps from real disk vs Gotek you could possibly load the dumps into a track visualiser such as HxC tools, and then inspect for differences in gaps, etc.

[mvancopp1]

I have ordered a Greaseweazle but it may take until the of January to arrive.

[mvancoppenolle]

I received the Greaseweazle and made two dumps, raw and hfe formats of the same disk. I loaded the dumped disk in to the HxCFloppyEmulator (image attached). I am not sure where in the HxC I can find the gap and other relevant information. Any pointers or guidance you can give would be helpful.

Thanks,
Mark

[keirf]

Okay this is a different higher-density format, at 36 sectors per track. Would be a 720kB capacity disk. Either double density eight inch, or high density 5.25 inch (microdiskette). Probably the latter since the dump is at 300rpm. Not a typical TI99 disk?

[mvancoppenolle]

This is from the Myarc HFDC (Hard Floppy Disk Controller) and can handle formats up to 1.44MB on floppies (3.5"/80 track). I tried extracting a DSDD 40 track 5.25" but when I try and read I get a failure of "No Index" on three different drives, with and without termination. I will try more options and different formats (DSSD, SSDD, SSSD). The ability to write fails for all formats including the 1.44 HD with the TI setting or with IMG.CFG settings that match the DSDD and many other GAP values I have played with. When I experimented, taking shots in the dark, I made sure reads continued to work before trying the writes. Once I understand how to read the output I can make adjustments to the IMG.CFG file to see if that helps resolve the inability to write. Any suggestions to try and overcome the "No Index" issue? I saw a Greaseweazle option for faking index, that is the first thing I will try.

[keirf]

Sorry yes above visualisation is 1.44MB indeed, not 720kB.

No Index may be mis-addressed drive. Does the motor spin up? Is it a straight ribbon cable, and have you tried other drive identifiers (eg --drive=b)?

[mvancoppenolle]

I had a little time so I am back 0n the 5.25" DSDD. When accessing "drive=a" the drive access LED comes on but no motor movement and you get the "No Index" error. When accessing as "drive=b" the drive access LED is not on but the motor spins and you get the error in the attached screenshot. I format the floppy and move the cable from the controller to the Greaseweazle directly, drive power is not moved. This should eliminate the drive, cable, and power as variables (hopefully :-) ).

[keirf]

I think your drive is jumpered DS0. Try --drive=0

[mvancoppenolle]

--drive=0 worked (LED=on, motor=on, data dumped successfully). See the attached screenshot. Thanks for the suggestion.
Do you have any guidance on interpreting the HxC data to calculate the different gaps or other relevant information, or would you like a copy of the hfe file? I think this is the next step.

[keirf]

Okay yes zip and attach the hfe and I can take a look and get the gap3.

You could also do this dump from your Gotek, to get an equivalent emulated dump. And we could compare interleave and gap3.

You could zip up both and attach.

EDIT: To be fair, we should know the Gotek gap3 and interleave. So that's optional!

[mvancoppenolle]

Attached is a zip file containing:

1. MyarcDiskRealDSDD.hfe - The read of the real floppy formatted DSDD (360k)
2. MyarcDiskEmuDSDD.hfe - The emulated floppy (GoTek with FF 3.29)
3. FF.cfg - Used in the GoTek drive in 2
4. The original .dsk file for 2

Let me know if you need anything else.

Thanks!
Mark
TI99_MyarcDiskCompare.zip

[keirf]

Was there an IMG.CFG on the USB drive? The parameters for the emulated image are weird: interleave=10, and there's an hskew. Doesn't correspond to a built-in TI99 format, nor what I gave you in IMG.CFG attached earlier.

So either there's a bogus IMG.CFG floating about on the USB drive, or perhaps there's a bug or I'm misunderstanding the code. In which case I'll investigate using a debug build of FlashFloppy.

[mvancoppenolle]

I didn't find an IMG.CFG on the USB drive, so I reformatted the USB drive, reset the GoTek CFG (press the two buttons for 5 seconds with no USB), and loaded new FF.CFG and .dsk files on the USB. I verified the files could be read by the computer and all was successful. I used the Greaseweazle to dump the verified 360k file. The zip contents changed a little, below is the new contents:

1. MyarcDiskRealDSDD.hfe - The read of the real floppy formatted DSDD (360k)
2. MyarcDiskEmuDSDD1.hfe - The emulated floppy (GoTek with FF 3.29) Changed filename and new dump
3. FF.cfg - Config used in the GoTek drive for 2
4. DSKA0005.qde33.dsk - The original .dsk file for 2

Let me know if this works for you.

Thanks,
Mark
MayarcDiskComp_1.zip

[keirf]

Okay the new emulated image looks as expected. I assume yous till can't write to it?

Differences I see in the real dump:

• GAP3 (real has GAP3 12, emulated has GAP3 24)
• Interleave (real has 4, emulated has 5)
• Cskew (real has 0, emulated has 3)

[keirf]

Here is a new IMG.CFG to try. It should fix the emulation to closer match real:
IMG_new.zip

[mvancoppenolle]

Thanks for the follow-up. Unfortunately the behavior does not change, the writes do not occur but reads are fine. I remove the FF.CFG, reset the drives config, tried to read the drive and it failed as expected. I then added the new IMG.CFG to the USB drive and tried the read again, now successful as expected. I then tried to write a file which failed. I tried to format the drive and the format and verify complete without complaint but the contents of the disk are unchanged, the format did not write any data. In all cases the write indicator flashes when writes occur.

Let me know if there is something else I can try.

Thanks,
Mark

[keirf]

Run the logfile firmware and gather FFLOG.TXT after write and format attempts. Something should be logged on write attempts.

[mvancoppenolle]

I loaded FF log update v3.29 into the GoTek drive (the original test were 3.29). Attached are two files in the zip. The following sequence was followed for the actions and log captures:

1. I updated the drive with v3.29 log.
2. Power-cycled the drive.
3. Placed the USB drive in the GoTek. This contained the FF.CFG that setup the TI99.
4. Tested reading the .dsk file, which was successful.
5. Removed the FFLOG.TXT to start fresh.
6. Placed the USB drive in the GoTek.
7. I attempted to copy a small file which errors at the end since the FAT table is not updated.
8. Copied the FFLOG.TXT to the CopyFileDSDD.FFLOG.TXT file.
9. Removed the FFLOG.TXT file from the USB drive.
10. Placed the USB drive in the GoTek.
11. I attempted to format the DSKA0005.dsk to DSDD (already had files in it).
12. Format completed without error, verify completed without error.
13. Performed a DIR on DSKA0005.
14. Copied the FFLOG.TXT to FormatDSDD.FFLOG.TXT.

Let me know if you need anything else.

Thank you!
Mark

[Edit] During the copy and the format the LCD screen displays the "W" for the write operations and no "W" when the read operations are executing.

Format-Copy-DSDD.FFLOG.zip

[mvancopp1]

Hi Keirf,
Is there anything else I can do or anything you need from me to help resolve this issue? I appreciate your time and willing to help wherever I can.

Thanks!
Mark

[mvancopp1]

Hi Keirf,
Using a logic analyzer I looked at the timing of the signals (on the 34 pin connector on the GoTek). It looks like during a write operation, in the test cases I was formatting a floppy .dsk file) and it appears the Write Gate's rising edge occurs before the last two data bits arrive. The other timings I looked at appear to meet spec except for the ending of track write (the above issue).
Is it possible to have a configuration value to allow for a delay in the Write Gate, basically pretend the rising edge occurs X amount of time later? The X could be variable based on whatever time span you have available (2 = 2 x 1us as an example). This could be in the FF.CFG but likely it would be better in the IMG.CFG since the timing may change for SD vs DD vs HD. In my tests the timing error was consistent. I don't know if this would fix the writing issue but it seems likely.

Thanks!
Mark

[keirf]

Here's a test firmware which delays handling of WGATE deassertion, by 10 microseconds. I can adjust this if 10us isn't appropriate. You need to be logged into GitHub for the download link to work.
https://github.com/keirf/flashfloppy/suites/6441958747/artifacts/235888919

[keirf]

Any update?

[mvancopp1]

My apologies for the delay in my response. I have had a couple of family items that needed immediate attention.
I did try the special version you attached but the failure continues with the same symptoms, no change. Hopefully sometime this week I can do a complete capture of a failing write for all signals. Maybe this will show some anomaly. I did retest real floppies, three different 5.25" brands and four different 3.5" brands. All tests were successful and readable on other computers/controllers.
Thanks for you help and this follow-up. I will repost once I have the capture.

Mark

[keirf]

Do you wish to pursue this ticket further? I looked again at the FF.CFG supplied previously. There was no sign of sector writes. I wonder if your Gotek has a bad write or write-gate pin connection.