• Please review our updated Terms and Rules here

FlashFloppy Hard Sector Testing

E

ejona

Member
Joined
Mar 24, 2023
Messages
32
Location
Sunnyvale, CA
In another thread, I mentioned the Gotek firmware FlashFloppy had hard sector FDD support. It sounded like there was interested and I would like more testing of it. It works well enough for my usage on the Vector 4, and I'm hoping it works well enough to be useful on other machines.

My expectations:
  • There will be some issues
  • Reading should be possible for all hosts
  • Writing should be fine on hosts that do verify-after-write, with an okay flash drive
  • Formatting requires a particularly good flash drive, but some errors are probably okay. If the first 5ish tracks have no errors, it may be good enough
Steps:
  1. Flash your Gotek with the latest FlashFloppy v4.x (currently 4.7a)
    • If your Gotek already has FlashFloppy, you can use the easy USB flash drive-based update
    • For Linux-only folks, I have successfully used vanilla stm32flash on at32f415 Goteks. I've attached a patch I use for stm32flash to program at32f435. I built at commit 5ac0ffb, but I expect master is fine too
  2. Choose a USB flash drive, fat32 formatted. Create the file FF.CFG with the contents (I'm assuming the drive is shugart-style):
    Code: 
    index-suppression = false
track-change = realtime
write-drain = realtime
interface = shugart
  3. Make any necessary HFEv3 images:
    • HxCFloppyEmulator_soft can convert from some disk image formats (Northstar, Heath). "Load" the image, then "Export" as HFE rev 3
    • mk_hfe.py creates blank (unformatted) images, with the --hard-sectors 10 or 16 argument.
    • vgi2hfe.py (attached) could be modified to fit your system. 0x8F is an "index hole" byte code. 0x0F is "noop," for padding
  4. Copy HFE image files over to the flash drive. The file extensions will be .hfe. The file contains the hard sector information.
  5. Set the jumper on the Gotek, to S0 (disk select 0) or S1 (disk select 1). If you want DS2 or DS3 then you'd need to solder a jumper wire
Notes:
  • FlashFloppy remembers your config file. So if you try other options, they are saved even after you delete them. You can reset the saved configuration
  • Ideally, your machine would have a working floppy drive, for A/B testing
  • The USB flash drive can matter, especially for writes. If you have trouble, try changing to a different brand or capacity. SD cards with USB adapters are good too. Most flash drives I've tried have been acceptable, but different drives do indeed behave differently
  • AT32F415 Goteks have limited memory. STM32 and AT32F435 Goteks/OpenFlops are preferred, but STM32 are hard to find. If you are buying one new, that means look for a seller that explicitly mentions AT32F435
  • Verifying reads after writes make the floppy emulation easier. The read provides an extra 200 ms for the flash drive to accept the write. Most writes to flash are plenty fast, but 1 out of 100 writes may be much slower. Some flash drives take well over 100 ms to write 512 bytes in those slow cases
 

Attachments

  • stm32flash-at32f435.patch.txt
    1.3 KB · Views: 16
  • vgi2hfe.py.txt
    4.8 KB · Views: 18
Last edited by a moderator:
did you mean to highlight the difference between ARTERY AT32F435 and AT32F415? I have a couple 415 and some original STM32F105RB
 
I have tried this with a number of different usb drives, both the low spec'd new MCU and the original STM32, either drive 0 or drive 1, with or without the functional floppy drive installed and set to the other device (it has the termination resistor populated). I've managed to get the green LED to illuminate when the computer tries to read the image, but I don't see anything interesting on the OLED (the track counter doesn't seem to move). I've tried this with several disk images that work in the northstar advantage emulator and converted them to HFEv3 using the hxc tool. I'm probably gonna keep trying different combinations tonight, but I'm wondering what sort of logic analyzer traces or log files might be useful to see what's going on.
 
With almost all of those hardware combinations, you should expect at least some seeking. Green motor light tells you it was trying to use a drive, but not which one. No seeking at all is what I associate with something wrong with the drive select. Since you already tried without the functional floppy, can you use the same drive select it is jumpered for? The other main option is no disk image is selected by FlashFloppy...

You can get some extra logging by using the logfile firmware.

For logic analyzer:
Disk Select (whichever you are using for the drive)
Index
Step
Read Data
(Direction, once things work more)
 
Actually, from what I can tell when I try to boot from drive 0 and the flash floppy board is jumpered for drive 1 I get no seek light, same the other way around. The flash floppy board seems to only light up when I try to address the drive it's jumpered for. I have also tried swapping the drive jumper on my real floppy drive and I can load a real floppy in both configurations, drive 0 or drive 1 with or without the flash floppy board also on the bus with the other drive selected.

I take it back about the track indicator, I do see it almost imperceptibly blip from T00.0 to T01.0 and then right back. Just for the tiniest fraction of a second when the machine tries to read from that drive.

I'm doing all this testing on an stm32 since the nicer artery one is in the mail and the only other ones I have are the less powerful artery ones.
 
Looking again at the LED, I can confirm it is lit when the Gotek is selected. So I agree we are past that. STM32 and the nicer artery behave the same right now (HFE in FFv4 isn't yet using the additional memory).

The track indicator briefly flickering probably means there's a disk read error, or maybe it isn't a bootable disk. I'm disappointed it didn't get further.

If you have the logic analyzer hooked up, you can get me a recording and if you include RDATA at 4 Mhz sampling or higher, then I can decode it. Tell me which NSI it was so I can compare. I'd ideally use PulseView to open the recording, so I can easily open raw binary samples, csv, and vcd.

If you want to look on your side, IDX should show sector pulses every 20ms, and they should be very consistent in timing. When the track changes, the index pulses should continue. Since you exported using HxC, when changing the track, the first pulse after RDATA resumes might be slightly different from the others, like up to 16 us skewed. I'm not expecting any issue there. The other thing to look at is when RDATA resumes after a track change. I'd expect it to take 12 ms, which is the default head-settle-ms. Once RDATA resumes after a track change, it should remain present until the next track change. Issues there would point to a slow or inconsistent flash drive.
 
@nullvalue, yeah, the trouble with your situation is we can't compare to a real disk to confirm the controller is working. We're dealing with multiple unknowns. I have some controllers that are partly broken, and A/B testing was really helpful to not waste my time on the wrong component.
 
I have my Altair 8800 running on a Shugart SA400 hard sector 5 1/4" drive. I currently boot into NDOS and CP/M now. Is this the drive classification you are looking to get the Gotek to replace?
 
17again said:
I have my Altair 8800 running on a Shugart SA400 hard sector 5 1/4" drive.
Click to expand...

Looking at deramp.com, seems to use 16 hard sectors. I'd expect this to work. Although converting an image to HFE would need to know the on-disk format. It looks like it only supports one drive, so copying from existing disks isn't all that easy.

Between the ReadMe at https://deramp.com/downloads/altair/software/minidisk/CPM 2.2/, the disk images there, and the 88-MDS Minidisk Manual starting on page 55, looks like we have all the needed information for making disk images. FM, 137 byte sectors, 4 µs half-bitcell size. At least 500 µs of zeros at the beginning of the sector. It'd be very similar to vgi2hfe; I'll make the changes if you are interested.
 
Oh, Northstar controller. I assumed it was Altair Minidisk.

The Northstar Single Density Controller, seems to be single-sided, FM, 10 sectors, 256 bytes each, 35 tracks. So just like the normal Northstar disks I've seen, but FM instead of MFM and single-sided, which matches the name. HxCFloppyEmulator seems to only support DD NSI files. I don't see any detailed discussion of the sector format in the manuals there. On the plus side, it supports multiple simultaneous floppy drives.

Looking at the "North Star Micro-Disk System MDS-A-D Manual", on page 33 I see the sector format is 16 zeros, 0xFB, 256 bytes of data, check byte. The check byte is initialized to zero, then XOR+rotate left for each data byte.

I've attached a script that can convert NSI images (single-sided FM, single-sided MFM, double-sided MFM) to HFEv3. It auto-configures itself based on the image size. MFM HFE output loaded fine in HxCFloppyEmulator_soft, so I'm confident of that code path. FM is less tested.
 

Attachments

  • nsi2hfe.py.txt
    5.7 KB · Views: 9
ejona said:
I've attached a script that can convert NSI images (single-sided FM, single-sided MFM, double-sided MFM) to HFEv3.
Click to expand...
I forgot to look at FluxEngine to see what was there when investigating the format. I think my nsi2hfe is writing the tracks on the second-side in the wrong order. I'll look into that more.
 
For those that want some Northstar disk images to play with, I've got a pile of them here:

I spot-verified some of them with a Northstar emulator and they worked fine.

I've got a number of Northstar MDS-AD3 drive controllers and I'm very interested in being able to use a Gotek for both reading and writing.

g.
 
I've fixed nsi2hfe's track ordering for the second side. I've put the updated nsi2hfe.py at https://ejona.ersoft.org/files/floppy/ so there's fewer versions floating around. It always uses 0xFB as the second sync byte and has no interleaving. As I mention on the Horizon vs. Advantage thread, HxCFloppyEmulator looks to format the disk incorrectly. You should try with my nsi2hfe script instead of HxCFloppyEmulator. If testing confirms my theory, we'll want to report a bug and get HxCFloppyEmulator fixed, since that may be the missing piece of HxC compatibility as well.

You might notice 'sigrok mfm decoder.zip' in https://ejona.ersoft.org/files/floppy/ . If you find yourself using a logic analyzer for floppy debugging, you might find it useful. It is a PulseView decoder that I need to spend some time to upstream (docs, examples, tests). It can decode IBM, Micropolis, and Northstar sector formats.
 
Hi. I'm working with abzman on this. Tonight we used the latest version of nsi2hfe to convert some nsi files to hfe, and we got our Advantage booting! We are using version 4.7a of Flashfloppy, and confirmed that it works with either an AT32F435, or with an original STM32. Just for kicks, we tried an AT32F415 and we confirmed it does _not_ work.

We haven't tried writing to the disk images yet, because we are having some unrelated keyboard issues. Hopefully we will be able to try that soon. Thanks for all the help!
 
There was another report of successful FlashFloppy usage with Northstar Advantage, which also included writing. So the main issue was just the small pulse misalignment in HxCFloppyEmulator.

So we've seen two successful FlashFloppy usages on each of the Northstar MDS-A-D and Vector Graphic Dual-Mode Disk Controller.
 
I'm going to be getting into trying this in a single sided single density polymorphic systems hard sector floppy controller. I don't know if anyone's ever done that before
 
You must log in or register to reply here.
Back
Top