ST506 is possible

[ejona86]

ST506 is the common interface name used by "RLL" HDDs before IDE took over. It is very similar to floppy signaling, but is 5 MHz data rate (MFM is 10 MHz). Since the microcontroller on the Gotek is 72 MHz, that leaves only 7 cycles to process a half-bitcell, or 14 cycles for full bitcell/data bit. I was very uncertain whether it was possible, but it also wasn't clearly impossible... Except for current Artery; it needs to fully buffer an HFE track and current Artery doesn't have enough RAM. With stm32, there's only enough RAM to emulate a single platter.

I've been working on this for some months, and as of this weekend it seems to work. Ugly code is at https://github.com/ejona86/flashfloppy/tree/st506 . It requires a hardware adapter to convert to ST506, but it basically just rearranges the pins and has a RS-422 differential driver/receiver for RD/WD. It also involves removing two resistors.

In the end I did overclock to 80 MHz to have stronger syncing on the host. It also makes write decoding more reliable and provides 16 cycles per bitcell as otherwise 8 value load/stores (stmdb/ldmdb) entering/exiting functions can block DMA long enough to cause rare-but-not-rare-enough bit flips.

I have seen this mostly work on Vector Graphic Inc's Vector 4 with its Dual-Mode Disk Controller, but my testing has exposed that my Vector needs repair since sometimes the WG won't activate. I had trouble with an actual ST506, but I blamed it on the drive which crashed soon thereafter. The Vector has been able to write and read many sectors successfully, and isn't bothered by slow seek speeds.

Needless to say, this took some invasive work, but might not be as invasive as you (err, probably only keirf) might expect. Some of the changes I think would be fair to do for floppies, but I'll need to take some time and clean things up and break it into pieces. I've been targeting MFM; RLL(2,7) would have a performance issue to resolve.

While the changes turned out not to be too bad, getting there was quite an effort. This taught me a lot about the stm32 so that I can really appreciate the performance of the rp2040. PIO, clock multipliers+dividers, memory bandwidth, freedom to over/under clock and officially still use USB, peripheral queues, dual core, fast DMA... Any one of those items opens the door for much easier solutions. Although upgrading the stm32 chip does allow for some things as well.

The adapter plugs into the floppy connector and performs approximately this mapping:

Amiga CN11/Gotek to ST506
Pin	Gotek	ST506
2	DC	DENSEL (NC)
4	INU		
6	DS4 NC	WG
8	IDX	SEEK COMPLETE (DC)
10	DS1	TK0
12	DS2	WRITE FAULT (WP)
14	DS3 NC 	SS
16	MOT		
18	DIR 	SS1 (MOT; jumper to JC)
20	STP 	IDX
22	WD  	READY
24	WG  	STP
26	TK0 	DS1 (DS1 and DS2, via jumper)
28	WP  	DS2 (DS1 and DS2, via jumper)
30	RD  	DS3 (DS1 and DS2, via jumper)
32	SS  	DS4 (DS1 and DS2, via jumper)
34	READY  	DIR

1		DRIVE SELECTED (RD)
3
5
7
9
11
13		WDATA (WD; remove PU7)
15
17		RDATA (INU; jumper to JA; remove PU2)

[keirf]

The constraints of the current Gotek hardware and the need for an interface board anyway raises the question: Why not port to rp2040? The Pi Zero board would be quite convenient to solder direct to an interface+buffers board. The main thing I'm not clear on is how STM32 peripherals translate across: eg stm32 idiom is to lean on timers+dma a lot, but I haven't seen how/whether these concepts port across to the rp2040 pio engines?

The other thing is if you wait a bit longer (hopefully just weeks) you'll get Gotek board with AT32F435, 384kB RAM configurable up to 512kB, and 288MHZ Cortex-M4. Which would be a lot more comfortable for HDD emulation!

[ejona86]

When I started I knew PIO with rp2040 would make it much easier, but I had not designed a board before and it would require more involved porting which would have its own set of headaches. In short, I didn't want to boil the ocean, especially since I knew I also had the option to replace the stm32 chip.

Originally I thought the Cortext-M3 at 72 MHz was the primary limiting factor. So it was mainly a question of "can I produce efficient enough code" for a few critical sections. I hadn't found the DMA controller documentation so I hadn't realized how slow DMA is nor fully understood the memory bus organization. And I definitely hadn't read the AHB-Lite documentation to learn about batched accesses to explain rare bit flips.

The AT32F435 would be very welcome, and would allow more features. Things are actually working with the STM32F105, but it is hard to acquire for any new interested users. The flash space would be nice; I disabled SD support to make space for my ST506 work. The extra memory would allow for more platters, although I don't personally have a strong need for that.

[keirf]

Originally I thought the Cortext-M3 at 72 MHz was the primary limiting factor. So it was mainly a question of "can I produce efficient enough code" for a few critical sections. I hadn't found the DMA controller documentation so I hadn't realized how slow DMA is nor fully understood the memory bus organization. And I definitely hadn't read the AHB-Lite documentation to learn about batched accesses to explain rare bit flips.

I never measured the F1 DMA performance but I suppose it is indeed bad, FlashFloppy's bandwidth requirements are pretty limited really. STM32F2+ all have redesigned DMA with FIFO buffering so it can do bigger memory transactions. Unfortunately the AT32F435 DMA peripheral is F1-style.

[ejona86]

AN2548 has DMA details for F1 and some others. Section 5 covers its speed, but uncontested RAM→RAM copy takes five cycles per transfer. There is some pipelining that saves two cycles if more than one DMA channel is active, but then you pay a latency hit for throughput gain.

I had stumbled on AN4031 for F2 DMA earlier, but hadn't really looked. You are right though, it seems much improved. A single FIFO alone helps a lot, but there's also dual-port, burst transfer, and F2 has more numerous bus slaves. Would have been nice to see more peripherals have FIFOs though.

[ejona86]

stm32 idiom is to lean on timers+dma a lot

You can do that approach some. But we wouldn't need to use timers for RD and WD; those would be PIO programs. There is no need to do bit banging with the Cortext on the rp2040 in talking with peripherals like the screen as well, also because of PIO.

[keirf]

stm32 idiom is to lean on timers+dma a lot

You can do that approach some. But we wouldn't need to use timers for RD and WD; those would be PIO programs. There is no need to do bit banging with the Cortext on the rp2040 in talking with peripherals like the screen as well, also because of PIO.

Do you have some rp2040 experience? I wonder how much effort it would be to port.

Still fundamentally the Gotek factory is pumping out boards with STM32 (ish) chips so I don't suppose FlashFloppy will ever really move away from that.

[ejona86]

I am strongly tempted to try a port to the rp2040. But I keep talking myself out of it because it seems a waste of effort. The STM32F105 and AT32F435 are strong enough, even for ST506. Do you think there's value in the rp2040 just from a sourcing perspective, since the AT32F415 has had disappointing host compatibility?

[keirf]

The problem, from p.o.v. of replacing existing supply of FlashFloppy-capable units, is mass production. The Goteks are conveniently manufactured by someone else and sold widely at low cost. The advantage of the 435 is not that it's particularly crazy good, but it's almost a drop-in replacement for 105/415 and the factory seems committed to supplying Gotek boards with this chip. They are sampling 435 PCBs right now, or as soon as factory reopens, and expect batch availability of 435 chips imminently.

If you port to rp2040, then... you have to get them made yourself, or build them yourself, or expect other people to DIY it. Depending on your attitude/motivation for the project, this may be a reasonable path all the same.

[ejona86]

Update: I did clean up the st506 branch a reasonable amount so it is now semi-comprehensible. But within a week of my first post my Vector 4 stopped responding when powered on so I have even more hardware needing repair before I can usefully test this work. (I do have FF_TestBed hacked to help testing, but a retro machine is the real litmus test.)

[keirf]

I can update on 435 based boards. I have samples being sent to me, I should be in a position to OK them in approx two weeks. Then the factory will start mass production. Guess about three weeks for that, plus another two weeks for me to order and receive some. I should therefore have 435 boards/Goteks in stock to supply around mid July.

[ejona86]

It took an eternity, but I have a working Vector 4 again. Trying to repair it took a lot of my focus and energy. I'm going to be traveling soon, so it'll be a few more weeks before I get deep into things again.

[keirf]

@ejona86 I have 4 samples of the new 435-based board. Email me if you'd like one.

[a1exh]

Necro-bump : There is still a demand for cheap(er) RLL/MFM emulators for ST506 controllers. Has this project been parked? Superceeded? I'd be curious to know if this would work with the Acorn ADK52, Atari MegaFile or Commodore A590 XT.

[ejona86]

I posted when it had stalled, because my host machine was unreliable. I had focused on getting the async v4 branch accepted, which this was built on. Keir and I discussed some options but didn't reach a design. I had tried another design (file_cache), and had reimplemented this work on top of it, but I trust the older code that's still in the st506 branch (based on ringio) more at the moment.

I tried another Vector Graphic Dual-Mode Disk Controller and it also had issues. The issue is the PLL claims it is synced before it actually is, and it loses sync rapidly when the HDD is not active. That probably would not impact your hardware.

All this work was on the stm32 Gotek. You probably don't have one of those, but would you be interested in making your own adapter board and using it with the AT32F435? I'd need to make sure the adapter board works for the AT32F435, first. If you want me to send you an adapter or an unpopulated board, that could be an option as well. Either way you may need to provide me with ~40 MHz logic analyzer recordings if/when things don't work.

[a1exh]

I was an early adopter of the Gotek, well before FlashFloppy existed and so all my Gotek(s) are the original STM32s.

HOWEVER

If this project is to be usable going forward presumably it needs to work on the Gotek's that are available to buy today?

[ejona86]

"usable." We're comparing to a 40 year old HDD. Once the firmware works, then you can call it done. As long as those of us interested have stm32 models, it's fine.

Spending time on AT32F435 just hasn't made sense. Once the approach shows itself to work, then I'd look at supporting it. I don't think it'd take that long, relative to everything else.

Note that currently only single-platter HDD emulation is supported. IIRC, on my machine I can claim it is a 10 MB HDD, have two "partitions," and only format the first partition. When I get a chance, I'll probably look into what your systems expect.

The biggest wildcard is "is your system okay with occasional long pauses when seeking tracks, especially after a write?" My host was fine with it during formatting, but yours will have its own timeout settings.