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

st506.hfe (scripts/mk_hfe.py --rate 5000 --rpm 3600 --cyls 153)

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.

[srgkmv]

@ejona86 Hello,
I was looking for a way to emulate an MFM/RLL hard drive for my Soviet clone of the PDP-11 and came across your code. I happen to have a couple of Gotek drives with an STM32F105, so I wanted to try out your solution.

Could you share some information on what configuration should be specified in the FF.CFG and IMG.CFG files? And how to properly create an empty disk image?

[srgkmv]

I checked the pull-up resistors, and they all turned out to be OK.
I connected Gotek to a logic analyzer and observed its response to control signals:

• DS (S0) – turns on the LED on the board.
• SS – changes the displayed disk side on the LED display when DS is low. Data on RDATA is interrupted regardless of the DS level.
• STP – does nothing. I'm not sure under which combinations of control signals it starts switching tracks.

On my system, the only boot device shares the same bus as Gotek, and it cannot function while Gotek occupies the data bus.

Anyway, thank you for your work! I'll be waiting for your code updates while also trying to reverse-engineer DREM using photos and bitstream sources (it's just too expensive for a hobby).

[ejona86]

I'll need to check whether SS is actually ignored when not selected; again, I'm surprised, but it wouldn't actually hurt much. But STP not cutting out is good. The way to swap tracks is to bring DS low and then do a STP pulse (low briefly). If it reacts to STP when not selected that will cause the host and drive to become out-of-sync.

You have more than one device that uses the same ST506 data bus? That's surprising. My controller only supports a single HDD, but the ST506 OEM manual shows each drive getting its own data bus. Wikipedia says the same thing:

While up to four drives can share a control cable, each drive has its own dedicated data cable connecting it to the hard disk controller (HDC).

In the OEM manual I don't see any output enable on the RS-422 driver either. I poked around at some DEC stuff and didn't see anything stand out. I'd love more info about your setup.

Supporting a shared data bus would need changes to the adapter board. Using SN7534051 for the 422 would give an output enable that could be driven by S0/S1 after an inverter. But that's assuming everything else is normal. I'd really want to study up on the controller's expectations.

[srgkmv]

On my system, the ST506 interface is implemented using a WD1010 and is combined with the floppy interface on an i8272. This means that the floppy drive and the hard drive share the same interface.

On the data connector, only the +MFM READ and −MFM WRITE differential lines are used, and these same lines are connected to RDATA and WDATA of the floppy drive. Yes, it looks strange. Yes, it does not conform to the ST506 specification. But hard drives like the ST225 work just fine on my system, sharing the same data bus with the floppy drive.

I will try to do as you suggested. I will attempt to use an SN7534051 and connect S0 to OE through an inverter.

[ejona86]

I think the biggest question is does the ST225 just put the 422 driver in a fixed state that the machine can handle, or does it disable the 422 driver when not selected. If it is a fixed state, that can be adjusted in software. I can try to look at one of my drives or schematics later to see if the 422 driver even has an output-enable. The best thing is to reproduce what the drive did.

A quick look at the last page of the ST-225 schematic has "5N" at the top right which doesn't appear to have any output enable signal. I see OUTPUT ENABLE is enabling/disabling the control bus, but it isn't routed to 5N. That would seem to imply the most it could do is have a fixed output. So maybe this doesn't require any hardware changes.

[ejona86]

Looking at the ST-412 schematic in region D1 shows what appears to be an enable for RDATA from the disk-select (and the some goes to WDATA).

[liveboxandy]

Looking at schematics for Seagate ST-412 and ST-4096 which are ST-506/ST-412 MFM interface drives, they use AM26LS31 and AM26LS32 for reading/writing differential signals both of which have enable/disable for outputs. Obviously the ST-225 has more LSI integration but from what I remember it still disables the 422 driver part of R/W LSI chip when not selected.

…

On Tue, 1 Apr 2025 at 17:03, Eric Anderson ***@***.***> wrote: I think the biggest question is does the ST225 just put the 422 driver in a fixed state that the machine can handle, or does it disable the 422 driver when not selected. If it is a fixed state, that can be adjusted in software. I can try to look at one of my drives or schematics later to see if the 422 driver even has an output-enable. The best thing is to reproduce what the drive did. A quick look at the last page of https://archive.org/details/bitsavers_seagatemfm_515145 has "5N" at the top right which doesn't appear to have any output enable signal. I see OUTPUT ENABLE is enabling/disabling the control bus, but it isn't routed to 5N. That would seem to imply the most it could do is have a fixed output. So maybe this doesn't require any hardware changes. — Reply to this email directly, view it on GitHub <#644 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATAD235PVKGJ64VBRFNL6J32XK2ENAVCNFSM6AAAAABR4UGX4GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRZGA3DQOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>