Portability thoughts? Build instructions?

[ForbiddenEra]

So, I was hoping to build this - I don't have a 328p handy, maybe a 2560 but was planning trying a 32u4 as that's what I had handy, or maybe a Teensy 4.1 - (onboard sd even) - 2560 would be the most similar to a 328p though

In trying to build it with platformIO, it always complains about u8g.h - even though it's installed and recognized, for some odd reason. For example, when the lib isn't installed, the include for it is underlined squiggly; once it's installed and recognized, this goes away along with some errors but still comes back on build for some reason - I wonder if this is due to other errors.

Anyhow, all the other errors come from specific registers that are used not being found. It looks like these are for UART communication. I haven't dug - is this needed to keep timing up?

Other registers that are used are for pin change interrupts; is there also a reason for using these directly instead of something mroe portable like attachInterrupt?

Again - I haven't dug, so I'm not saying your choices weren't needed; I've built an EEPROM emulator with a teensy before and I only barely hit my target for timing and USB UART broke that (although hardware UART with the arduino lib worked fine without any effects on timing), just curious as I'd like to make use of this project for a project of my own as getting 5.25" floppies isn't the easiest for me.

[acemielektron]

At core of the fddEMU there is ArduinoFDC and ArduinoFDC works on both Leonardo and Micro, it also works on Mega, so there is no reason for fddEMU not working on these platforms. Just pins and registers of Atmega32U4 are a bit different, so fddEMU code needs some work before it runs on Atmega32U4. I am now looking at Atmega32U4 datasheet but this might take some time. I was thinking Arduino Uno/Nano/Pro mini are the most widespread micro controller development boards around the world, that nearly everyone interested in electronics has at least has one, that's why I chose Atmega328p but it seems I was mistaken.

[ForbiddenEra]

So, I've almost got it compiling on a Mega2560.

It's still complaining about u8g.h, it complained about PRR but suggested to change to PRR0, now I have

In file included from lib\petitfs\avr_mmcp.c:13:0:
lib\petitfs\pffArduino.h:77:2: warning: #warning non atmega328p&168 boards use standart arduino functions (must replace !) [-Wcpp]
 #warning non atmega328p&168 boards use standart arduino functions (must replace !)

But the only actual error now is u8g.h which is odd - but hopefully something I can solve as it's dependency.. although I've tried both the included version and pointed to it (and again, platformio seems to pick it up and I get less errors when it does) and also tried installing it as a library with platformio.. ugh

[ForbiddenEra]

At core of the fddEMU there is ArduinoFDC and ArduinoFDC works on both Leonardo and Micro, it also works on Mega, so there is no reason for fddEMU not working on these platforms. Just pins and registers of Atmega32U4 are a bit different, so fddEMU code needs some work before it runs on Atmega32U4. I am now looking at Atmega32U4 datasheet but this might take some time. I was thinking Arduino Uno/Nano/Pro mini are the most widespread micro controller development boards around the world, that nearly everyone interested in electronics has at least has one, that's why I chose Atmega328p but it seems I was mistaken.

I normally have 328p on hand just not now, it does want to go for the Mega with no real issues besides the u8g.h issue I seem to be having with platformIO. :(

Dependency Graph
|-- <U8glib> 1.19.1
|-- <petitfs>
|-- <avrFlux>
Building in release mode
Compiling .pio\build\megaatmega2560\src\GraphicUI.cpp.o
Compiling .pio\build\megaatmega2560\src\SerialUI.cpp.o
Compiling .pio\build\megaatmega2560\src\UINotice.cpp.o
Compiling .pio\build\megaatmega2560\src\main.cpp.o
In file included from src\GraphicUI.cpp:20:0:
src\GraphicUI.h:24:10: fatal error: u8g.h: No such file or directory

Literally shows it detects u8g but just won't compile.

The reason I was asking is just a lot of the registers can be replaced with Arduino framework stuff to be instantly portable but I understand a lot of cases this doesn't work out hence the need to go lower. Only one register needed changing for the mega it seems though

[acemielektron]

If you are using the makefile it should look for u8glib in project folder libs subfolder ( fddEMU/libs/u8glib). Also you can disable graphicui from makefile if you want.

[ForbiddenEra]

I'm not using the Makefile, as I mentioned I'm trying to use PlatformIO. Weird that it picked up the other libs just fine.

Is there a #define or something to disable the graphical UI? I was planning on using it though as I do have a few of those screens handy.

There may actually be more registers that have to be changed as well; just noticed some others...

[acemielektron]

I just looked at ArduinoFDC code and look, it uses timer5 and port L. Current code wont work on Mega without change

define TIFR TIFR5 // timer 5 flag register

define TOV TOV5 // overflow flag

define OCF OCF5A // output compare flag

define ICF ICF5 // input capture flag

define TCCRA TCCR5A // timer 5 control register A

define COMA1 COM5A1 // timer 5 output compare mode bit 1

define COMA0 COM5A0 // timer 5 output compare mode bit 0

define TCCRB TCCR5B // timer 5 control register B

define CS1 CS51 // timer 5 clock select bit 1

define CS0 CS50 // timer 5 clock select bit 0

define WGM2 WGM52 // timer 5 waveform mode bit 2

define TCCRC TCCR5C // timer 5 control register C

define FOC FOC5A // force output compare flag

define OCR OCR5A // timer 5 output compare register

define TCNT TCNT5 // timer 5 counter

define IDXPORT PINL // INDEX pin port (digital pin 47, register PL2)

define IDXBIT 2 // INDEX pin bit (digital pin 47, register PL2)

define WGPORT DDRL // WRITEGATE pin port (digital pin 45, register PL4)

define WGBIT 4 // WRITEGATE pin bit (digital pin 45, register PL4)

define OCDDR DDRL // DDR controlling WRITEDATA pin

define OCBIT 3 // bit for WRITEDATA pin

[acemielektron]

define ENABLE_GUI=0 should disable GUI. I changed some of the code for 32U4, just not completed it yet.

[ForbiddenEra]

define ENABLE_GUI=0 should disable GUI. I changed some of the code for 32U4, just not completed it yet.

That would be sweet; I'm down to use either the Mega2560 or the 32u4, whichever takes less work, heh.

It's complaining about PCMSK2 and PCIE2 right now even and those are shown in the 2560 datasheet, so not sure why they're undef.

So... I changed it from #include "u8g.h" to "u8glib.h" and it actually built.

[ForbiddenEra]

I just looked at ArduinoFDC code and look, it uses timer5 and port L. Current code wont work on Mega without change

..? Mega2560 has both a timer5 and port L..?

I know I have dead pin on this mega though..heh..Hopefully I can work around that..or if you get it going on a 32u4, I'm more than happy to try that out too

[acemielektron]

on Atmega32U4 INT0 is shared with SCL, it seems I have to use PD2 (RX1) for step

[ForbiddenEra]

on Atmega32U4 INT0 is shared with SCL, it seems I have to use PD2 (RX1) for step

TX1 and RX1 are for a secondary UART that's not shoved over USB so that's fine.

Did compile and upload to mega; trying to find where pins are defined for the screen at least as it doesn't seem to be coming on attached to 20/21 aka 44/43 aka pd0/pd1 aka sda/scl

[ForbiddenEra]

I also just realized I should actually have a bare 328p or two somewhere... heh - they're the 28pin versions though..

bleh enabling GUI causes a bunch of errors ... u8g still not happy .. maybe i'll just pop 328p on a breadboard.. although it'd be nice if between us we could add 2560+32u4

[acemielektron]

I2C pins are passed to u8glib on initialization. You will find i2c pins on gui class init code. U8glib might not be using hardware i2c if so these pins could be changed freely. Edit: İt seems u8glib ignore pins passed from init and use default SDA and SCL. Although I haven't changed anything in graphicUI code I2C display is working on atmega32u4.

[ForbiddenEra]

I tried changing the pins and still didn't get any output; but then I actually enabled GUI and it then puked more u8g errors, like again as if it's not finding the lib right..

I threw a 328p on a breadboard and programmed it.. It seems to run, but watching the serial monitor at 115200 gives me garbage. I think your baud rate setup isn't accounting for 8mhz (running w/out xtal, so stuck at 8mhz)

If I set 57600, seems to give me not garbage though.. now to connect sd reader and screen, heh

[ForbiddenEra]

Well, this just threw a wrench in my plans...

My target system is an 8088; has two 5.25" drives. I was sure I had plugged this floppy cable I had in before, but I must have misaligned the pins - there's two less pins on my system than my testing floppy cable. The original drives have card edge connectors. The cable I was trying to use is a standard 34pin cable from a 3.5" I had.

Edit: nevermind, it's 34 pins all around just keyed differently on the motherboard side of the cable I have; pin 3 is blocked on one side and 5 on the other side.. where as pin 3 is blocked on the board side of my target..and the 3.5" drive I have is blocked at pin 3 as well

bleh

[acemielektron]

For emulating high density 16Mhz is barely enough, 8Mhz might work with double density images. In FloppyDrive.cpp in function FloppyDrive::load there is "(numSec > 9) ? bitLength = 16 : bitLength = 32; //DD or HD". This line selects emulation mode according to number of sectors on disk, you might have to convert it to bitLength=16

[ForbiddenEra]

For emulating high density 16Mhz is barely enough, 8Mhz might work with double density images. In FloppyDrive.cpp in function FloppyDrive::load there is "(numSec > 9) ? bitLength = 16 : bitLength = 32; //DD or HD". This line selects emulation mode according to number of sectors on disk, you might have to convert it to bitLength=16

will try it.. if it's not, maybe we can get the 32u4 or mega running but..was wanting it to be easy-ish heh.

I'm sure my machine can't do HD anyway.

I suppose I could always clock the 328 from a generator, heh.. meant to get some xtals but never did :(

Regardless, thanks for your help and for making this in the first place.

[acemielektron]

If you haven't disabled virtual floppy you might not need a floppy image for testing.

Pins for pro micro PD3-INT3-TX?-D1 -> PIN_STEPDIR PD2-INT2-RX?-D0 -> PIN_STEP PD1-INT1-SDA-D2 ->I2C_SDA PD0-INT0-SCL-D3 ->I2C_SCL PD4-ICP1-D4 -> PIN_READDATA PC6-D5 -> PIN_SIDE PD7-D6 -> PIN_INDEX PE6-INT6-D7 -> PIN_WRITEGATE PB4-PCINT4-D8 -> PIN_MOTORA PB5-OCP1-PCINT5-D9 -> PIN_WRITEDATA PF4-A3 -> PIN_TRACK0 PF5-A2 -> PIN_WRITEPROT PF6-A1 -> PIN_DISKCHANGE PF7-A0 -> SPI_SS PB1-SCK-PCINT1-D15 -> SPI_SCK PB3-MISO-PCINT3-D14 -> SPI_MISO PB2-MOSI-PCINT2-D16 -> SPI_MOSI* PB6-PCINT6-D10 -> PIN_SELECTA PB0-SS-D17-RX_LED PD5-D24-TXLED

As you can see there is no pins left for ADC input. Two pins (PB0 and PD5) are wasted on leds on pro micro board. PB7, PC7, PD6, PF0, PF1, and PE2 are not routed so 6 other pins are also wasted. A total of 8 pins are unusable (what a waste).

[ForbiddenEra]

If you haven't disabled virtual floppy you might not need a floppy image for testing.

Not sure what you mean exactly. I still never actually got it to compile; I did get the released image running on the 328p though. I did find some 360k floppy images last night though and got them ready on a 1g microSD.

I don't suppose you'd be willing to get it compiling with PlatformIO or even (ugh) the Arduino IDE? I just think these are simpler options for a lot of people - even though there's a binary, for some people, loading a sketch and pressing upload is still easier than uploading a hex for some people. PlatformIO is at least a nice middle ground. I'm assuming you're using Linux for dev?

The u8g issues are definitely confusing me a bit and I have a ton of development experience; again it's finding the other included libs fine. I'm sure there's some configuration issue somewhere that the compiler isn't seeing it but not sure..I've tried a bunch of different ways to solve.

Curious; is it possible for this to act as a secondary drive only? I see options for it to work as A:, or A: & B: - but I might run into a situation where I boot off a real floppy and want to use the emulator as the secondary. I think my target only boots off A: with no configuration.

As you can see there is no pins left for ADC input. Two pins (PB0 and PD5) are wasted on leds on pro micro board. PB7, PC7, PD6, PF0, PF1, and PE2 are not routed so 6 other pins are also wasted. A total of 8 pins are unusable (what a waste).

The 32u4's I have are indeed based off a Pro Micro. I also agree that the routing of this board is quite silly/wasteful, even if there was a specific formfactor they were trying to match, you could easily fit 4 or more pins on the opposing edge to the usb port.

I suppose the easiest solution would be to not have buttons or screen support on the micro? It, however, is not the only 32u4 board; I do believe it is one of the most popular though with tons of dirt cheap clones available.

I suppose another option could be to not use an output for write protect and allow the user to pull that up/down as needed; that would free up an analog pin for the buttons.

I'm not sure what the asterisk is denoting in your list.

The pins with LEDs can be still used for other things but obviously there's potential for issues with that besides the fact they're not brought out to easy pin holes.

I didn't finish testing the breadboard/bare 328p last night but I may tonight, hopefully 8mhz will do for dd.

Maybe I'll also try the Micro as well/instead - is it ready for a test on a micro with your last commit?

[acemielektron]

I changed write protect to PD5-D24-TXLED and buttons to PF5-A2, patched petitfs now it compiles for atmega32u4, unfortunately doesn't work yet. Screen works but floppy emulation doesn't work and it is what matters. Needs some debugging.

[acemielektron]

Maybe I'll also try the Micro as well/instead - is it ready for a test on a micro with your last commit?

Finally atmega32u4 firmware is working. I found the bug: mistyped pin register for WriteEnable in IS_WRITE() macro. @ForbiddenEra If you can verify this code e2de0be works, it would be great. In my test e2de0be is working on pro micro just without the usb-cdc serial port and I haven't tested buttons yet.

Pins for Arduino pro micro ReadData on pin 4 (PD4) WriteData on pin 9 (PB5) MotorA on pin 8 (PB4-PCINT4) SelectA on pin 10 (PB6-PCINT6) Step on pin RX (PD2-INT2) StepDir on pin TX (PD3-INT3) Side/Head on pin 5 (PC6) Index on pin 6 (PD7) WriteEnable on pin 7 (PE6-INT6) Track0 on pin A3 (PF4) WriteProtect on pin 24 TXLED (PD5) -> no routed pins left DiskChange on pin A1 (PF6) SD SlaveSelect on pin A0 (PF7) SD MISO on pin 14 (PB3) SD MOSI on pin 16 (PB2) SD SCK on pin 15 (PB1) I2C SDA on pin 2 (PD1-INT1) I2C SCL on pin 3 (PD0-INT0) ADCButtons on pin A2 (PF5-ADC5)

Sorry, because I was so focused at the task at hand (porting fddEMU to atmega32u4) I didn't realize that I haven't answered some of your comments. Now I have finished (I hope) porting I have re-read your posts:

If you haven't disabled virtual floppy you might not need a floppy image for testing.

Not sure what you mean exactly. I still never actually got it to compile; I did get the released image running on the 328p though. I did find some 360k floppy images last night though and got them ready on a 1g microSD.

Hmm, I meant a floppy image served from arduino's flash. If sd initialization fails and virtual floppy (ENABLE_VFFS=1) is enabled fddEMU serves this from drive A. If you disable all other features fddEMU compiles into a ~ 10K binary which leaves about 20K in flash unused. I thought this would be a nice feature for older machines: Suppose you need a driver or a rom addition to load before you can access your boot media (eg.: ethernet or a custom ISA card) if this driver is small enough to fit the flash space left, you program your driver into Arduino's flash then connect the Arduino directly to the motherboard (if there isn't a floppy cable causing parasitic capacitance the external pullups for Step and WriteData pins might not be needed) no sd-card, no screen, no buttons, no serial cable, no need to find and program a new bios chip and magically your computer boots.

I don't suppose you'd be willing to get it compiling with PlatformIO or even (ugh) the Arduino IDE? I just think these are simpler options for a lot of people - even though there's a binary, for some people, loading a sketch and pressing upload is still easier than uploading a hex for some people. PlatformIO is at least a nice middle ground. I'm assuming you're using Linux for dev?

I prefer linux, it is easy to use, stable and inexpensive compared to alternatives. I might consider PlatformIO, it's remote build capability is a boon, Arduino IDE threw unresolvable errors and forced me to abandon it. Still even learning and porting fddEMU to PlatformIO would take some time for me, how about I post the compiled hex file ?

So... I changed it from #include "u8g.h" to "u8glib.h" and it actually built. The u8g issues are definitely confusing me a bit and I have a ton of development experience; again it's finding the other included libs fine. I'm sure there's some configuration issue somewhere that the compiler isn't seeing it but not sure..I've tried a bunch of different ways to solve.

I have looked u8glib again and there is an u8glib.h it is in u8glib/cppsrc folder, if I did understand the documentation for u8glib correctly u8glib.h and u8glip.cpp are c++ wrappers for u8glib so u8glib should run fine without them. I'm using u8glib/csrc and u8glib/sfntsrc, your build system should use the same folders for includes and build.

Curious; is it possible for this to act as a secondary drive only? I see options for it to work as A:, or A: & B: - but I might run into a situation where I boot off a real floppy and want to use the emulator as the secondary. I think my target only boots off A: with no configuration.

In single drive mode you can use the emulated drive either as drive A or drive B. if you connect SelectA(10) and MotorA(14) pins of host to SelectA(10) and MotorA(8) pins of Arduino pro micro it works as drive A, or if you connect the SelectB(12) and MotorB(16) pins to SelectA(10) and MotorA(8) pins of pro micro it works as drive B. Just be warned on a standard floppy drive cable signals for drive A and drive B are switched on floppy drive end.

I suppose the easiest solution would be to not have buttons or screen support on the micro? It, however, is not the only 32u4 board; I do believe it is one of the most popular though with tons of dirt cheap clones available.

I suppose another option could be to not use an output for write protect and allow the user to pull that up/down as needed; that would free up an analog pin for the buttons.

e2de0be supports screen, buttons(hopefully), no serial (for now). I agree freeing an analog pin for inputs is best so I moved WriteProtect pin to TXLED.

I'm not sure what the asterisk is denoting in your list.

Asterisk meant those pins are not changeable (ICP and OCP for timer1, SPI, I2C).

You also said:

I'm down to use either the Mega2560 or the 32u4, whichever takes less work, heh.

I don't want to disassemble my 3d printer, so I don't have Mega2560 handy, on the other hand I do have an Arduino pro micro and some bare atmega32u4s. So pro micro it is.

Edit: nevermind, it's 34 pins all around just keyed differently on the motherboard side of the cable I have; pin 3 is blocked on one side and 5 on the other side.. where as pin 3 is blocked on the board side of my target..and the 3.5" drive I have is blocked at pin 3 as well

On standard floppy cable all odd numbered signals should be GND. I hope your 8080 is not different.

[ForbiddenEra]

So, I needed to pick up a chip off Amazon and it wasn't quite enough to get prime shipping, so I threw an Uno and some jumper cables on top. Now I'll have all the options.. :-)

Although, it's supposed to arrive today by 10pm and it's almost 10pm and it says it's not even out for delivery. I assume it's not coming and that it's related to the Amazon outage today. Bleh.

I'll still try and test the 32u4 if I get a chance - you were kind enough to get it working ASAP for me, just not sure I have any buttons - and I just realized as I typed that, I should've threw a few buttons on my order.. haha..

[ForbiddenEra]

So I felt like playing tonight. Loaded up the Uno I got for this project with the ROM, plugged everything in.

Screen seems to be working, it seems to read my SD card, when I press N in terminal it shows each image I have.. at first it wasn't super apparent that I needed to select a drive before l/e would do anything - I guess that would be more intuitive if I was using the 2 drive version..

Anyway, I loaded a ROM and it said loading disk, c40h2s9, great, however, the OLED didn't update..? does it not update when using the terminal or something..? it still says afddemu c80h2s18..?

Is there supposed to be any feedback on the screen or terminal that the drive is being read from or written to? Haven't got it to boot yet, I might try booting my DOS disk on drive A: and see if it can see it as B:.. also going to double check my wiring of course

EDIT: When I shut down the host, the arduino says busy. When I turn it on the arduino reboots. Hmm..hoping my floppies aren't some non-standard pinout.. they should be standard as far as I can tell, heh..

Edit again: Totally forgot the pull-ups like an idiot.

Edit: Seems like BUSY gets pulled high when the system is off, explains that. I did have some missing pins. This time, trying to boot, it says BUSY as soon as it tries to boot...and.........fingers crossed............taking longer than it did when it failed..........do we get any other output besides BUSY? like what chs it's tracking or something? like 5 min now and it's still stuck there.. which generally if this machine doesn't read a disk properly it actually reloads into the EEPROM that runs on boot.

2nd try..no busy sign..arduino rebooted..hmm..time to triple check wiring I guess. feel like I'm so close!

[acemielektron]

Is there supposed to be any feedback on the screen or terminal that the drive is being read from or written to? Haven't got it to boot yet, I might try booting my DOS disk on drive A: and see if it can see it as B:.. also going to double check my wiring of course

While in use screen should show which drive is being accessed and busy message. In the terminal you should also see the text "BUSY". And while a drive is being accessed both buttons and terminal shouldn't respond to user input.

You mentioned that arduino is rebooting this is usually caused by watchdog when arduino is hung up. And most common cause for hangup/freeze is inability to read from host caused by lack of pullup resistors. (Edit: Arduino only tries to read from host when WRITEGATE is active -host is writing into floppy-. Also without external pullup on step pin fast step pulses are lost and tracks cant be synced causing read errors on computer. If fddEMU is compiled with DEBUG option (DEBUG=1) it shows which track/sector is currently being read or written on serial terminal.)

I guess testing and understanding how fddEMU works might help resolve problems. So we need a floppy controller that we know works and luckily there is one "ArduinoFDC". I test fdd emulation using ArduinoFDC first then on my computer. If you want to be sure you can test ArduinoFDC with a working floppy disk drive first.

2nd try..no busy sign..arduino rebooted..hmm..time to triple check wiring I guess. feel like I'm so close!

I hope it works, I will try to help as much as possible. Thank you for your feedback. Without feedback I can't know if people can make fddEMU work. So please keep me informed.

[ForbiddenEra]

Of course, I'm glad you're willing to help.

So I thought that maybe I had the rows of the connector wrong - it seems that the index pins are on the side with the signals not the grounds, correct? I've not been able to find many good pinouts for floppy drives oddly enough. Totally confused actually..

However, I've swapped to that and I don't get any response now. I did get it to say "BUSY" once (with the cables in the 'wrong' place apparently, but, I suppose that's possible) when the disk tried loading too and it actually seemed to try and boot; this time it just pretty quickly quits and goes back to the eeprom. It still reset the arduino when turning the host on even after swtiching the cables, but when the cables were in what I think now is the wrong position, I was having issues with it not responding when I also plugged in the 12vdc adapter to the uno...

There's a possibility this host doesn't use a normal XT pin out. The controller side only has one pin missing unlike more modern controllers. The original drives have edge connectors on them not pins. I don't have my multimeter handy right now...I do have two scopes though.

The diagram I have shows that the keyed the side with the tab sticking out, is top pins, or odd pins, aka ground. The picture shows the connector flipped on the other side, but doesn't show the key. Neither pic shows the missing 4 pin or 4/6 pin but it is listed in the table. I can't even tell if the top side of one side of the cable goes to the bottom of the other even.. I may have left my multimeter at my old job, which..not getting it back I don't think.. heh.. uh I mean I guess there's other ways to test conductivity, but..

The floppy cable I am using is a more modern one that I had left over from a 3.5" drive, I guess it matches that pinout? Which I guess means, indeed, the sides are flipped since it says the other side has pin 3 keyed off..

But to make matters more confusing, the system only has a missing pin in position #4, which means I have to plug the floppy drive side of the cable into the host and the host side of the cable into the Arduino, so the side facing the arduino has the two blocked pins...

So.. If the blocked pins on the controller side is supposed to be 4 & 6 and, assuming my machine doesn't have 6 blocked for some reason, and I use the cable reversed then the missing pin is technically numbered 3 on the cable but since it's flipped is actually pin 4 on the controller (or actually, isn't, because it's a blocked pin) which, if I'm reading the diagram, comes across the cable to cable pin 4 device pin 3, as the diagram shows that normally, pin 4 on the controller side is blocked and pin 3 is blocked on the device side? but the cable can't flip like that because then all the pins would have to switch even/odd..

So the odd side becomes the even side becomes the odd side becomes the even side when the cables plugged in backwards and upside down? I don't even know what I'm saying anymore, haha.

Don't even get me started on the twist in the cable. Think this could get any more confusing for me?!? Can I jump off a cliff now? ;-)

Okay, I'm exaggerating a bit but you get my point. :-) I'm gonna just turn my scope on and should be easy to find the step/dir pins.

And I'm sure all of that could've be solved with a multi-meter and 30 seconds...but hey..

If you have a discord we could chat there perhaps, I definitely don't mind giving feedback - as someone who built an eeprom emulator with a teensy, this is totally up my alley 👍

[acemielektron]

There's a possibility this host doesn't use a normal XT pin out.

hmm the pinout on https://www.epanorama.net/circuits/diskstepper.html works but indeed there is a possibility of pinouts being different.

The controller side only has one pin missing unlike more modern controllers. The original drives have edge connectors on them not pins.

Even if the drive side of the floppy cable is edge connector, header on host side could be connected to ArduinoFDC and tested. This should make clear if pinout is different.

If you have a discord we could chat there perhaps.

I didn't but I have just created "fddEMU" server on discord. (Edit: https://discord.gg/gc95mMZv)

So the odd side becomes the even side becomes the odd side becomes the even side when the cables plugged in backwards and upside down? I don't even know what I'm saying anymore, haha.

Pin 1 is marked with red on cable unless you plug pin1 to pin 34 (upside down) odd side and even side should not change. Edit: But, if you installed the cable upside down not only odd and even pins are changed pin numbering should also be reversed (pins closest to red mark becomes 33 and 34 and farthest pins become 1 and 2) Edit2: Now I looked at a floppy drive cable I have that also has an edge connector: There is no twist between host side and edge connector, no closed (keyed) pins on host side (connector has a key/tab on it's outer side) and there is also a no-twist 3.5" fdd connector between host side and edge connector for drive B. Only the drive A connector at the other end of the cable has enable/motor pins twisted.