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)

ff-st506-adapter-v1.zip
ff-st506-adapter-gerber-v1.zip

Wiring your Gotek:

• Only stm32f105 has been tested. There's some investigation of at32f435; the software is known-incompatible at the moment
• Remove PU2 and PU7, near the Gotek's jumpers. These resisters have the same name and position between at32f435 and stm32f105
• Jumper on S0 or S1. Doesn't matter which. You use the S1-S4 jumper on the adapter board instead
• Jumper sideways between JA and J5, nearest the IDC connector. The pins you don't want are GND, so you can check continuity to double-check this
• stm32f105:
  • Jumper sideways between JC and MO, nearest the IDC connector like JA+J5, but with a wire since they aren't adjacent
• at32f435:
  • Jumper diagonally between JC nearest the IDC connector, like JA+J5, and the MO in the corner, with a wire since they aren't adjacent

stm32f105:

at32f435:

[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.

[pocoaust]

G'day,
I was looking to make something similar, and came across your post.

Is it possible to get kicad file for the converter board?

Thanks
Paul in Australia

[ejona86]

@pocoaust, I just attached the KiCad and Gerber files to the bottom of the first post.

[pocoaust]

Thanks mate,

I am looking to simply emulate up to 20Meg HDD's for old Pc's etc. I don't care how much wasted space I use on the storage medium as SD cards are cheap.

I was looking to use RAW writes to the SDCARD / USB, would this improve the performance by bypassing the FAT Filesystem overhead
and reduce seek times etc? I am not concerned about image compatibility.

Also what 2 resistors did you need to remove? I assume this was on the Flash floppy hardware.

Thanks
Paul

[pocoaust]

Went through all my goteks, and NONE at stm32, and are Artery 415 ;-(
I ordered the PCB, but will need to get a 435 based unit. Did you add support for the 435 in the end?
Thanks again.
Paul

[ejona86]

I figured out the wiring with the at32f435 and added it to the first post. Bypassing FAT doesn't give a performance benefit, assuming the file isn't very fragmented. The software still hasn't been updated for the 435.

[Gary-Clark]

This solution would be very welcome as I have several machines with ST506's that need replacing at the museum and we can't afford DREM type solutions.

What is the status and future of this project ?

[ejona86]

Still only stm32f105 works, which helps nobody but myself.

Two weekends ago I rebased (but have not shared) the work on top of 3.x and my async file-cache work, which took some effort. But I haven't been able to test it much because of separate hacked-flashfloppy-testbed issues.

That rebase is important for getting at32f435 support. I got at32f435 compiling, but not yet working. The problem right now is probably of the "flip the right bit" variety, but finding which bit is time consuming.

I'm essentially back in development hell until I get things limping along again, which takes quite a bit of energy.