Feature request: Disk Change / Ready signal using standard F1 bluepill for WinUAE

[f1ac0]

Dear Greaseweazle creators,

I used the Greaseweazle with a F1 bluepill board some time ago to backup my disks. Thank you ! The Beta WinUAE integration made me want to try it again. It works great.

However, a popup windows says it would be even better with the DISK CHANGE pin ! My drive is a PC drive adapted to work inside an Amiga, it has the READY signal, so I want to use that.

I understand it is based on the F1 "plus" board by solarmon, I tried to adapt the following things to the F1 bluepill design :

• Connect the _READY signal pin 34 to A8 with a 5V pullup
• Tie C14 to ground so the Greaseweazle will identify to a "F1 plus" to WinUAE
• Change the Greaseweazle code to keep the pin configuration for standard F1, even if it reports as a "plus" : in mcu/stm32f1/board.c : [F1SM_plus] = { .flippy = FALSE, .user_pins = _user_pins_std, .msel_pins = _msel_pins_std }, and in mcu/stm32f1/floppy.c : case F1SM_plus: / Determine whether input pins must be internally pulled down. / configure_pin(index, GPI_pull_down); delay_us(10); GPI_bus = (get_index() == LOW) ? GPI_pull_up : GPI_floating;

With this configuration WinUAE detects the GreaseWeazle accordingly, the motor spins, but the system does not load from floppy. I believe there is something else that I forgot, or maybe it requires some other features from the "plus" ? Or it could be a problem on the WinUAE side ? Otherwise it would be great to add it to the "F1 "Blue Pill": Direct Connection" wiki page, autodetect is presence in the code (like you detect when the other input pins are floating) and maybe robsmith could make it a default for WinUAE ?

[keirf]

I am considering direct support for this in Gresaeweazle firmware. The main problem with your approach is that READY is not the same as DSKCHG. WinUAE is expecting DSKCHG. This is on pin 2 on your Amiga drive and will need to be brought to pin 34 (as if it were a PC drive).

Anyway, in terms of supporting this in the firmware, I would suggest C15 to ground, C14 left floating, and I would identify this as "F1 + DSKCHG". What do you think?

[f1ac0]

I was in fact confused by the two connector formats: I always connected the drive with shugart pinout on my Greaseweazle and it worked so far. However your reply pointed out that in fact the actual pinout on the diagram on the BluePill wiki page is the IBM PC one ! As I now understand, the READY signal is not required nor used by Greaseweazle and WinUAE, even if it is required by the Amiga computers.

I now connected a PC drive to my Greaseweazle with the hardware and software modifications listed in my first post, and it works just fine with WinUAE !

I believe am an not expert enough to point out the best direction, but here are some thoughts if I can help:

• instead of an ID on C14/C15, maybe the pullup on DSKCHG pin can be autodetected ? pullup=feature is present ; floating = feature is absent. The firmware would then stay compatible with older hardware and be compatible with newer boards without consuming an ID that might be required for future enhancements.
• in order not to rely on device or board name to determine the presence of features, the firmware should provide configuration flags to the host with each bit corresponding to one feature (be a software or a hardware one). gw or WinUae would only have to check this bit-field and not test the board name. This should help when there will be several versions of the firmware/boards and compatible applications in the wild (I believe other emulators and FPGAs will follow !) Your proposition or the suggestions above would make it possible to document the diskchange feature inside the greaseweazle repository. I believe users like me who already own a bluepill will appreciate it when they will want to try the device with their favourite emulator :).

In addition :

• the new hardwares with pin 34 connected on A8 might accommodate both drive pinouts by swapping the pins inside the firmware since pin 2 is already connected to B9. This will not be necessary however if I am the only moron trying to connect a shugart drive on a device with IBM pinout...

[keirf]

On some Greaseweazles pin 2 is output only as it is buffered one way. I probably won't get into making it bidirectional on some boards only.

Feature detect of this particular feature is via the CMD_GET_PIN firmware command. If an error is returned, the feature is unavailable. No need for a separate feature detection method for this feature.

Pullup vs not is interesting... I'll have a think, that could probably work!