CHGRST Workaround - Yamaha DX7II-FD Support

[whorfin]

Greetings.

First, FlashFloppy is amazing and I am thankful for your work. The basic setup, usage, stability and speed, along with the new track indicaiton, are a huge improvement from the Gotek firmware. Because the DX7II-FD neither writes nor reads a boot sector, the raw image support is crucial.

Here's the issue, first as observed Yamaha DX7II-FD behavior, and then some speculation on the whys and what we might do about it.

The DX7II-FD caches the file directory, and only attempts to reload when a disk has been ejected and re-inserted. With physical floppies, this works fine. With Gotek/FlashFloppy, it does not, despite some flailing around with configuration files. The behavior is that whichever image is active the first time the disk DIR is read, is used. Changing the selected image never gets the DX7II to notice, and if one attempts to read a file from an image other than that which was initially loaded, garbage ensues.

After banging my head against this by trying all the combinations, I broke out the Yamaha schematics, found manuals for the original floppy drive, and observed the jumpers as factory installed. I then found some Sony docs on this convention, which the retro-computing community seems to refer to as "Old Sony" [vs "New Sony"]

First, the Yamaha side:

As we can see, pin34 is ignored, so nc in FF.CFG pin02 should be some variant of chg, but presently this does not work properly. And, aha, pin01 is /DCR, which is Disk Change Reset or CHGRST in Sony Speak This is an input to the floppy drive, not an output. It is unhelpfully connected to GND on the Gotek board, which thankfully is at least harmless as the DX7II-FD uses an open-collector output to drive it.

The drive as factory installed and configured [both by Panasonic as shipped and as installed in the synth by Yamaha] sets the DC and DR jumpers (along with D0 and M0 but that's not the issue).

There's some explanation in the Panasonic docs, and more elaboration in a Sony doc:

The keyboard is thus expecting chg to be asserted until it signals back CHGRST on pin01 to the drive. From reading the code, it appears FlashFloppy resets chg upon a STEP, which the drive tellingly supports but is not the default.

So... What to do? Has anyone encountered this in other retro-computer situations? pin01 for CHGRST can't be supported without a hardware mod, clearly. But could there be a clever workaround? Noticing the behavior I observe, I am suspecting that a new FlashFloppy mode, with a configurable delay parameter, might work. Rather than resetting chg upon a STEP, chg would be asserted after a new image is selected with the buttons, and stay asserted for some new CHGRST-delay before then automatically being cleared. ...or wait for some other initiated drive command after the delay; I do not yet know if the controller resets the change signal before or after commencing any drive activity.

A last-ditch solution would be hijacking double-button-press to be CHGRST, keeping chg asserted until kicked.

I'm hopeful this can be solved without requiring a hardware hack, and be useful not only for old keyboards but for other vintage computing uses from the "Old Sony" era. At the least, I hadn't seen this elsewhere, but had seen a fair amount of speculation on why disk changes weren't working on old computers, on which I hope this sheds some light.

Cheers

[keirf]

How acceptable would a ribbon or gotek mod be to bring the host pin 1 signal into gotek pin 4? Then it could jumpered across from gotek J5 to say JB and be implemented properly?

So for example a custom ribbon where wire 4 is chopped, and wire 1 is brought across to take its place. No wire at pin 1 at the gotek ribbon connector.

[keirf]

Button based reset is also plausible. Time based reset I would worry whether the host actually regularly polls dskchg rather than waiting for some user initiated action. We could try it though. I could provide test firmwares at the weekend.

[whorfin]

That's clever. I would make a modified ribbon cable, where wire 4 is cut, wire 1 is crossed over to pin 4 location on the connector, and pin 1 on connector remains empty. Then wire J5 to JB on the connector side of the jumper block. As an alternative, while I know JA currently has a use as a button input, using JA for CHGRST instead would allow a nice and easy "jumper sideways" approach to connect J5 to JA.

The DX7II-FD connector and JU-363 listing both show pin 4 as being In Use (or /INVSE). but since current jumper settings currently have it unconnected, I guess that isn't important?

That seems like a workable solution, and I assume also needs some new firmware. I share your concern about when the host polls dskchg, but would be up for trying a test firmware[s] using a configurable delay when you have a chance to make some. Otherwise, I'll stand by for the hardware hack.

[keirf]

/INUSE is connected straight to drives activity led I think. It is unimportant and has no use on gotek at all.

JB also has existing purpose (speaker) but has a useful stm32 pin assignment making it easier to trigger an interrupt from it.

An easy gotek mod would be to cut traces to pin 1 on pcb underside, and solder a wire from pin 1 to JB (or another location, whichever we ultimately decide). To me that's easier than a new ribbon though it does need soldering and is slightly destructive (easily reversed though).

[keirf]

Some soldering required either way I think as the input really should be connected to 5v via a 1k resistor.

See https://github.com/keirf/FlashFloppy/wiki/Hardware-Mods#motor-signal for an existing optional modification to bring motor signal to the stm32.

Something similar is doable.

[whorfin]

OK, I understand. Cable mods are slightly easier for me as accessing Gotek requires digging it out of guts and unmounting to disassemble, but since the jumpering/wiring still needs doing it's not a huge difference either way. I'm more likely to want the speaker mod some day for nostalgia reasons than the pushbutton, but the interrupt pin assignment makes sense and I overlooked that.

...and yes, I just saw your additional note - right, since /CHGRST [/DCR] is open-collector on the Yamaha output side, we will indeed need a pull-up resistor.

So ultimately, just let me know which jumper is preferred. Short term, I'm up for trying a delay hack first, whenever you have time to do a firmware spin. That will be most accessible for people if we can make it work.

[keirf]

OK I can do a delay patch first. If modding is required I'd probably go for a pin on the spi flash footprint same as I did for motor signal. Its a clean unused pin.

[keirf]

Here is a delay patch for you. See the new option chgrst in examples/FF.CFG. For example: chgrst = delay-5

ff_233_1.zip

[whorfin]

Thanks very much for your work. I'm now baffled and don't understand what's missing for success. Here's what I see, with pin34=nc, pin02=chg and chgrst=delay-4 After a power cycle, device says ** Disk err Can't read/write! Retry? y/n until the timer has run out, after which hitting y will result in the disk directory being loaded. Changing images with the FlashFloppy buttons will again cause that same error message until the timer has run out. So yay, timer and signal are working. But after the timer has run, the next hitting y results in no new disk directory being loaded. The [Busy] display does not appear on the device display, disk access isn't done, no dir loaded.

I don't think wiring up the pins etc for direct signaling is the issue, but then I don't see how this can be happening the way it is now. Could it be expecting some kind of INDEX signaling or relying on MOTOR ON to provide index pulses? The first directory read after power-up always works, but it never seems to attempt to read the directory again.

In case it is a clue, with pin02 = chg and the regular chgrst = step, the device stays in the Disk err mode, implying it never tries to STEP until diskchng is cleared.

EDIT to add: With the hardware floppy, if I remember correctly, the drive would spin for about a second whenever a floppy was inserted. I don't know what was going on [drive did that itself? keyboard asserted motor on when dskchg was noticed?] but perhaps it is looking for some index pulses to confirm a disk has indeed been inserted.

[keirf]

So has default behaviour changed? Before you seemed to see that the Yamaha was oblivious to the dskchg signal and would completely ignore disk changes. Now with chgrst=step which should be same as old behaviour you say you get Error which never goes away?

The drive spin up on disk insertion in physical drive is called auto chucking. Some drives do it. It's automatic by the drive.

[whorfin]

No change in default behavior, I didn't mean to indicate that. chgrst=step behaves the same as previous default behavior. With previous default behavior, yes, error never went away. Only way to use FlashFloppy with previous firmware was signal abuse, pin02 = nrdy or pin02 = high. Disk change not detected in those cases, ie directory stale on host.

I'm just wildly speculating on whether maybe index pulses are sent if disk is selected during auto-chucking and if they are used by the Yamaha.

Right now, "disk change" is manifested by the Yamaha going into "Disk err" state until the signal is un-asserted. Fiddling with delays gives me some confidence that the Yamaha is noticing that signal. The problem now is that this doesn't trigger a re-reading of the directory - while the Yamaha now notices disk change, it doesn't cause it to re-read the dir as it does with physical floppy eject/reinsert.

Make sense? [it doesn't make sense to me yet but hopefully the explanation is more clear]

[keirf]

On a standard gotek the motor signal is not even connected and motor is always 'on'. Hence you always get RDY and index pulses while an image is mounted. Flashfloppy can properly emulate motor now but... It requires soldering and it probably isn't related to your problem, right?

We can only really speculate on chg and chgrst behaviour and timing unless you can put a scope or logic analyser on those signals.

Otherwise perhaps we can bodge cable pin 1 over to pin 4 and temporarily then jumper it across to the most convenient of JA JB JC. As a quick hack test of more proper chgrst behaviour.

[whorfin]

Hmmm. I didn't realize that, and wonder if there's any chance the opposite is true - is it possible the Yamaha looks for the absence of index pulses to trigger a state change in its handling of disks? Admittedly grasping at straws, but it seems there are only two inputs possibly at play, right?

Yes, maybe the next step is to try cable bodgeing and some jumper hackery to try a "hack test".

I can indeed put a logic analyzer on some signals, though it will take me a few days to resurrect some gear. Are you wanting to see behavior with the old floppy drive, or look at how the Yamaha is interacting with FlashFloppy now?

[keirf]

I think the cable bodge is next. I will sort a firmware later and attach here with instructions.

If that doesn't work you will need to try the motor mod or gather new info with logic analyser (on original drive).

[keirf]

Here is a new firmware to try.

You need to get pin 1 on the ribbon cable to Jumper JB (make sure you attach to the STM32 pin side of the jumper header, not to the header pin that's tied to ground!). You might do this by bodging a cable to bring wire 1 in at pin 4, and then jumper across from J5 to JB. Or perhaps hack a cable, cut wire 1, and solder on something longer to bring direct to JB. Up to you!

You do not need to pull the signal up, I'll use the internal STM32 pull up (for now).

You need the following in FF.CFG: chgrst = chgrst

Good luck!

ff_233_2.zip

[whorfin]

Fantastic, thanks! I will give this a try

[whorfin]

OK, connected wire 1 on cable directly to JB. Set chgrst = chgrst

Still can't get Yamaha to re-read directory. The signaling now seems to work exactly right, ie I can see momentary "disk not ready" if i bash on Yamaha disk read buttons while changing FF image, which resolves as quickly as the keyboard can respond. In all other aspect it behaves just like a floppy. Except it won't re-read the directory.

The Yamaha does not use the boot sector, but just "knows" what the disk layout must be. Nothing is getting weirdly cached on FF side, right? I don't see the telltale "[BUSY]" on the Yamah so I don't think it's that.

So does that mean next stop logic analyzer? Any other ideas? Which signals shall I capture? I think I only have 8 channels.

[keirf]

Two options, perform the motor signal mod and test with motor-delay = 200.

Or, gather Saleae Logic logs (I guess it's a Saleae clone you have) from physical drive, and perhaps from FlashFloppy too. Useful lines: CHGRST (1), CHG (2), IDX (8), SEL0 (10), MOTOR (16), STEP (20), RDATA (30)

I would also include READY (34) but you believe it is not connected at the Yamaha side?

Set up the analyser with correctly labelled inputs in the Logic software. Start an analyser trace, eject disk, insert disk, get directory re-read (or fail to, on FlashFloppy). Stop the trace.

Zip them up and upload somewhere or attach direct to this ticket.

[keirf]

Another quick thing to try, a hack that seems to occasionally work on some synths, is to add a jumper at MO (as well as S0), or to tie the STM32's select pin to Ground. Together with pin02=high in FF.CFG. It's quick and easy so worth a test?

[whorfin]

Thank you for the additional information, I will try the jumper fiddling next. Because nothing is quick or easy when the Gotek is buried inside a frame further buried inside the Yamaha, I am going to spend a little time making up some cables so I can have drive[s] hang out of the keyboard and hack on them without the whole teardown/rebuild dance.

along the way, an answer and questions:

• Yes, I am confident that READY (pin34) is not connected on the Yamaha side. The schematic and service parts labeling agree. The schematic is scrupulously honest, ie the "technically 16-bit DAC" has the low-order bit grounded. Before I consulted the schematic, I noticed that while flailing with pin assignments in FlashFloppy, pin34 was a effectively a "don't care".
• I had been wondering about MO jumper; looking at Gotek schematic, it appears this would only "do something" if the Yamaha were asserting MO without S0 and expecting a response. With open-collector, active-low outputs, adding the MO jumper effectively ORs /MTON and /DS0, is that right?
• "to tie the STM32's select pin to Ground" - this could be done by e.g. connecting the STM32-side pin of S1 to the STM32-side pin of J5, is that right?

[keirf]

Yes it ORs motor and sel0. Its had some success on some other synths hence I mention it.

Grounding the select line simply means a jumper wire from the stm32 side of the 3x2 jumper sub block (three pins in the s0 s1 mo section are all connected together on the pcb and wired to a pin on the stm32). And connect one of those three to any grounded pin (there are several, connected directly to the ground plane).

[whorfin]

Hooray!

1) S0 and MO jumpers on 2) wire1 of cable wired to JB 3) pin02 = chg in FF.CFG 4) pin34 = nc in FF.CFG 5) chgrst = chgrst in FF.CFG

...and it now works perfectly. chgrst was definitely the magic, but it needed the MO jumper as well to work properly.

Thanks for your help, tips, and the new firmware. This works great now

[keirf]

That's good news. I need to get chgrst implementation in a suitable state for inclusion in a proper firmware release now. Firstly I will be shifting the chgrst attachment point to a pin on the SPI Flash footprint. Secondly I'm not sure I have the exact semantics of DC and DCR correct on these drives, wrt state of drive select. Do you have the full Panasonic and Sony datasheets for the drives that implement DCR? Can you send them to me to take a look at?

[whorfin]

Is it possible to keep a version which works with JB without an additional pullup? It is very easy to do from a mod perspective, and also now it works and I'd rather not have to pull everything apart again...

Attached is all the info I have on the panasonic drive, and the most informative datasheet I could find on Sony behavior. Panasonic_JU-363_364_JU-386_JU-394_Brochure_Mar87.pdf Sony_Microfloppy_Disk_Drive_OA-D32W_OA_D32V_OEM_Manual_Sep83.pdf

[keirf]

No, it's quite inconvenient to have a multi-purpose jumper, it was just a hack to stick it there.

However I could make it optional to jumper to JTCK_SWCLK (pin PA14)? If you look at the programming header on your Gotek, the row of pins nearest the power connector, if you have 3 or more pins there then the third from right (looking with Gotek rear towards you) is JTCK_SWCLK.

Would that be convenient?

The disadvantage is that some Gotek models don't have that pin available. But I think new Goteks in the marketplace all do...

[keirf]

Jumper JC is also a possibility. I would have to poll it, but every 200us only while chg is asserted wouldn't be too expensive really. It does have the advantage that it's present on every gotek, and always has a header pin soldered there. And its current usage (to select ibmpc interface) is already overrideable in FF.CFG

[whorfin]

JTCK_SWCLK would be fine, as would JC.

[keirf]

Okay I will work on a new patch for you to try, which will be suitable for direct inclusion into the main firmware if it works.

[keirf]

Here you go. Transfer your jumper wire from JB to JC, and change the FF.CFG line to: chgrst = jc

ff_233_3.zip

[keirf]

By the way, interface = shugart should work fine in FF.CFG, and you can get rid of the pin02 and pin34 lines.

[whorfin]

Unfortunately, this doesn't work reliably. Mostly I get the * Disk err Can't read/write! Retry? y/n message, although with constant retrying it will sometimes then read the directory. From that point it's fine until the image is changed. So it is acting as if the CHGRST signal is not reliably being detected. Could there be a problem with the internal pull-up? I moved the wire1 jumper wire from JB to JC, and didn't do anything else. Or perhaps the polling interval is missing reliable triggering.

[keirf]

I expect the polling doesn't work and the Yamaha expects a faster response to its reset request. Unfortunately I can't interrupt on JC as that interrupt mux is already used for STEP. So I will have to try SWCLK I think, and make another patch. That mux is available but shares an interrupt vector with MOTOR. I can probably deal with that.

[whorfin]

OK, thanks. At least for the Yamaha, we know it doesn't need MOTOR.

[keirf]

Ok here's another firmware. Jumper to PA14 (JTCK/SWCLK). Following in FF.CFG: chgrst = pa14

ff_233_4.zip

Code is in branch chgrst

[whorfin]

Glorious!

Working perfectly.

Thank you!

[keirf]

Great, I need to test that MOTOR behaviour is still okay. Then this patch will be the first new feature for v3.0a!

[keirf]

Implemented in v3.0a

[jansjobe]

Hi! I'm writing here out of desperation. I have tried to get a gotek to work with a DX7IIFD. I have isolated and bridged pin 1 to SWCLK as per instructions, set chgrst = pa14 and pin02 = chg. Latest FF version. I also have a rotay encoder and a Oled 128x68. I got so far as reading and writing OK. But disk change does not work. And also suddenly the OLED went black, but came back after a two restarts. I know how to solder, I know how to follow instructions, but it just does not work. Can You help me?

Best Regards, Jan Sjoberg SWEDEN

[jansjobe]

S1 and M0 jumpered!

[whorfin]

@jansjobe following through from above does require some careful reading My final working config was:

in FF.CFG:

interface = shugart
pin02 = chg
pin34 = nc
chgrst = pa14

keirf says pin02 and pin34 are redundant with interface=shugart FWIW

I'm not sure as to your description, but you need to ensure that pin1 on the cable ends up connected to SWCLK

Finally the big difference I note from your settings and mine:

S0 (not S1) and M0 jumpers are on in my Gotek

Cheers

[keirf]

pin34 = nc is still needed for interface = shugart as the Shugart default for pin 34 is rdy.

[jansjobe]

Well, say what happiness lasts ... My DX7IIFD worked perfectly with FF and Gotek for a while, but now the screen(OLED 128x64) is dark when turned on. The green activity LED lights up constantly as long as theres power. Pressing SELECT on startup gets me into USB update with the screen working. Tried updating, no difference. Tried with and without USB stick inserted at bootup. No difference. USB stick is a SanDisk Cruzer Fit 16GB, wich seems to work for anyone else. Could it be a power over/under-issue? What can I do? HELP! Best Regards, Jan

[jansjobe]

By the way, the synth itself works fine, less disk handling...

[jansjobe]

Ahh and ohh. I turned the synth off 15 minutes ago. Just turned it on... and it works again!!???

[jansjobe]

But the green LED is constantly lit.

[DX7IIFD]

Dear Keir, Dear Whorfin,

first of all i would like to thank you both. :) @keirf @whorfin Without people like you, my Yamaha DX7 II FD wouldn´t play "new" loaded sounds like he is doing it now. My old FDD was broken an i have choosen a Gotek and Flash Floppy to replace it. Right choice. So cool Keir, that you helped Whorfin out so fast, by configureing the Firmware for FF that it works with the DX7. Also good for me and maybe many others. Also thanks for the special corresponsing. ;) Sending you both some hugs :-)

Heres the configuration that works with my DX7:

Flash Floppy v3.22 Gotek SFR1M44-U100 2GB USB Stick - FAT formatted 0.91" OLED Rotary Switch Sound-Buzzer

Gotek connection: Jumper on S0 and M0 Take care and do not forget to put CHGRST Signal (pin 1 on DX7 floppy cable), to PA14 (JTCK/SWCLK). -> Red marked in Picture

• In FF.CFG - interface = shugart pin02 = chg pin34 = nc chgrst = pa14

Important: Create a 720kB Image with for example WinImage

That´s all. Flash Floppy recognizes this right away and with your DX7 you can chose it and save your Banks/Files in it.... Same to load files.... It works...

@jansjobe My green LED is also always on. Also when i write or read data. Only the OLED-Display (little w or r is flashing) and the Sound-Buzzer let me know, that there is something happening when say yes on the DX7 and save or read something.

Perfect. So @ the end again: SPECIAL THANKS TO KEIR AND WHORFIN. If there would be a YAMAHA Nobel Prize, you two get it. ^^ :)

Best regards and stay healthy

Frank alias DX7IIFD