Fully emulating a DEC RX50

[snhirsch]

When trying to use a pair of FF drives with a DECmate III I'm running into a few situations where the software appears to count on common seek behavior. In other words, if drive A was selected and stepped to track 0 it expects that drive B will be at that position as well. Obviously this fails badly. I can see the second drive ending up on nonsensical track numbers (e.g. 159 on an 80-track image) before the error message appears.

Before I dive into circuit design (at which I'm no expert), is there any reasonable way to gang the step and direction lines across a pair of Gotek drives to ensure they track together in the case where only one is actually selected?

UPDATE: If this is commented out of IRQ_STEP_changed(void) in src/gotek/floppy.c on both drives does it get me close to RX50 behavior, or are there dangerous side-effects?

    /* Bail if drive not selected. */
    if (idr_a & m(pin_sel0))
        return;

[snhirsch]

That comes so close to the goal! With this applied:

--- a/src/gotek/floppy.c
+++ b/src/gotek/floppy.c
@@ -412,8 +412,8 @@ static void IRQ_STEP_changed(void)
     (void)tim2->ccr2;

     /* Bail if drive not selected. */
-    if (idr_a & m(pin_sel0))
-        return;
+    /* if (idr_a & m(pin_sel0)) */
+    /*     return; */

     /* Deassert DSKCHG if a disk is inserted. */
     if ((drv->outp & m(outp_dskchg)) && drv->inserted
@@ -433,12 +433,12 @@ static void IRQ_STEP_changed(void)
     /* Valid step request for this drive: start the step operation. */
     drv->step.start = time_now();
     drv->step.state = STEP_started;
-    if (drv->outp & m(outp_trk0))
+    if ((drv->outp & m(outp_trk0)) && !(idr_a & m(pin_sel0)))
         drive_change_output(drv, outp_trk0, FALSE);
     if (dma_rd != NULL) {
         rdata_stop();
         if (!ff_cfg.index_suppression
-                && ff_cfg.track_change != TRKCHG_realtime) {
+            && ff_cfg.track_change != TRKCHG_realtime && !(idr_a & m(pin_sel0)) ) {
             /* Opportunistically insert an INDEX pulse ahead of seek op. */
             drive_change_output(drv, outp_index, TRUE);
             index.fake_fired = TRUE;

It's operating as I hoped. Both drives are stepping together and only the selected unit is generating output (I think).

Problem is that that the first drive display is messed up. It looks like the display process is in a loop writing the image name and never presents anything else on the display. I do see correct seek operations on the second drive if either of them are active. For the first time I'm able to run copy operations between the diskettes without error. Any help whipping the display problem would be appreciated!

[snhirsch]

<sigh...> It seems that the messed up display has nothing to do with my mods. When I simply build the head revision of unmodified source the same thing happens. I'm wondering if my tool chain is to blame? What are the "official" tools I need to build this under Linux?

Tried using the docker container to build, but I cannot figure out where it's trying to put the output... Can anyone help me generate a working build from source code? Many thanks!

UPDATE: I was able to get the release (3.44) level code build working by clearing the configuration. However, my mods are still messing up the display.

Keir: When you get a chance I'd appreciate some sage advice on what I'm trying to accomplish. Thanks!

[keirf]

The primary-supported tools are as used in GitHub workflow. https://github.com/keirf/flashfloppy/blob/master/.github/workflows/ci.yml

Ubuntu 22.04, package gcc-arm-none-eabi.

On my personal workstation I am using Ubuntu 24.04.

Anything more bleeding edge can sometimes reveal bugs that need to be fixed for the newer, more highly optimising, tool chain.

[keirf]

This apparent STEP behaviour on DECmate III is weird. If we can confirm it perhaps we can at least support it in tree with a compile flag. You would still be left to do your own build I think.

[snhirsch]

The need for joint stepping follows from the behavior of the RX50 mechanism. Although it's arguably a poor design practice, there appears to be situations where the software expects the second drive to be at track 0 after having homed the first one. All I know is that I was able to perform disk to disk copies and creation of a CP/M system diskette ONLY after hacking in the ganged seek behavior (previously, the second drive ended up at nonsensical tracks before the process failed). Can you help me figure out why my mods cause the display to freak out? I'm not adverse to building the code.

To clarify, I was able to build working code. Apparently my modified code corrupted stored parameters on the Gotek and resulted in the release code failing with the same display issues. Clearing the configuration by holding down both buttons corrects the issue and lets the production code work again. And, yes, I did double back and confirm that my modified code (again) screws everything up.

Can you review my patch and see if I missed something critical? Is there a better way to accomplish what I'm trying to do?

[keirf]

You should probably mass erase when you flash. That would avoid any weird cached-config behaviour.

Regarding your patch, do you actually need to add the drive-selected predicates to guard the calls to drive_change_output()? That function already respects the drive-select pin. Your patch may be as simple as removing (or adding a config boolean to elide) the drive-select check at the top of the drive-step ISR.

[snhirsch]

I probably do not need the other guards. I added them as a test only after determining that eliding the first check screwed up the LCD display. Can you do a build with that change in your development environment and let me know if you see the LCD problem?

If could understand how to build using the "official" docker container I'll give it a try to eliminate my build tools as a possible issue. I've never used Docker and could not figure out where it assumes the sources to be nor where it places output.

[keirf]

I know that I would not see the LCD problem. If you are having problems building reliably, an alternative is to rely on GitHub Actions yourself. Fork the flashfloppy repo in your own GitHub account and any pushes you make to your fork should get automated CI builds that you can download and test.

[snhirsch]

Thanks for the advice, Keir. I understand you are busy and unable to assist with changes that only a handful of folks might need. Unless I misread your last reply, you are firmly of the belief that what I'm seeing is a build problem and I hope you are correct! I'll close this issue and won't be troubling you again with it.

[snhirsch]

Just FYI: Even after clearing the flash memory and using the Artery tool to program from my modified .hex file (commenting out only the select guard as you mention), the display is still corrupted. Release firmware works fine. I give up on a software solution and will fabricate a circuit that will accomplish the same thing, albeit with far more complexity.

[keirf]

Perhaps a simple question would be: if you build firmware without any code changes, does that flash okay?

[snhirsch]

It turns out that the cross-build tool chain on Ubuntu 18.04 has some sort of code generation or linker bug. Even with unmodified sources the LCD constantly scrolls the image name and never draws the rest of the display. I switched to Ubuntu 24.04 and was able to build working firmware. After a lot of experimentation I settled on this set of changes:

diff --git a/src/floppy.c b/src/floppy.c
index 1d0b63f..0af71bf 100644
--- a/src/floppy.c
+++ b/src/floppy.c
@@ -616,7 +616,8 @@ static void drive_step_timer(void *_drv)
         drv->cyl += drv->step.inward ? 1 : -1;
         timer_set(&drv->step.timer,
                   drv->step.start + time_ms(ff_cfg.head_settle_ms));
-        if (drv->cyl == 0)
+        /* No output conditioning unless selected */
+        if ((drv->cyl == 0) && !(gpioa->idr & m(pin_sel0)))
             drive_change_output(drv, outp_trk0, TRUE);
         /* New state last, as that lets hi-pri IRQ start another step. */
         barrier();
diff --git a/src/gotek/floppy.c b/src/gotek/floppy.c
index 76c861f..5cfc8c1 100644
--- a/src/gotek/floppy.c
+++ b/src/gotek/floppy.c
@@ -410,16 +410,12 @@ static void IRQ_STEP_changed(void)
 
     /* Clear STEP-changed flag. */
     (void)tim2->ccr2;
-
-    /* Bail if drive not selected. */
-    if (idr_a & m(pin_sel0))
-        return;
-
-    /* Deassert DSKCHG if a disk is inserted. */
+    
+    /* Deassert DSKCHG if a disk is inserted and we're selected. */
     if ((drv->outp & m(outp_dskchg)) && drv->inserted
-        && (ff_cfg.chgrst == CHGRST_step))
+        && (ff_cfg.chgrst == CHGRST_step) && !(idr_a & m(pin_sel0)))
         drive_change_output(drv, outp_dskchg, FALSE);
-
+    
     /* Do we accept this STEP command? */
     if ((drv->step.state & STEP_active) /* Already mid-step? */
         || drive_is_writing())   /* Write in progress? */
@@ -433,14 +429,16 @@ static void IRQ_STEP_changed(void)
     /* Valid step request for this drive: start the step operation. */
     drv->step.start = time_now();
     drv->step.state = STEP_started;
-    if (drv->outp & m(outp_trk0))
+    /* Update tr0 only when selected... */
+    if ((drv->outp & m(outp_trk0)) && !(idr_a & m(pin_sel0)))
         drive_change_output(drv, outp_trk0, FALSE);
     if (dma_rd != NULL) {
         rdata_stop();
         if (!ff_cfg.index_suppression
-                && ff_cfg.track_change != TRKCHG_realtime) {
-            /* Opportunistically insert an INDEX pulse ahead of seek op. */
-            drive_change_output(drv, outp_index, TRUE);
+            && ff_cfg.track_change != TRKCHG_realtime) {
+            /* If selected, opportunistically insert an INDEX pulse ahead of seek op. */
+            if (!(idr_a & m(pin_sel0)))
+                drive_change_output(drv, outp_index, TRUE);
             index.fake_fired = TRUE;
         }
     }

I do not want any signals from the non-selected drive to be gated onto the bus. If I understand the code path, this should prevent that from happening. Now the drives seek in tandem, as would a real RX50. I've tested under the DECmate word-processing system and under CP/M (using an add-on Z80 board). All the chronic problems I saw previously (random disk errors with at least one drive at a nonsensical track) are resolved. Spent an hour or so copying things back and forth and testing all the system diskette build scripts. Best of all, this speeds things up greatly. With separate drives almost every seek becomes a retry when it assumes both are on the same track. A lot of DEC software and system firmware seems to make that assumption in places.

I've also been limiting the max track to 79 in FF.CFG since some of the init code likes to swing both drives into very high numbers. With both in sync it does not cause an error, however a real RX50 cannot go past track 79 so I thought it best to cap things.

[keirf]

drive_change_output() will not affect the bus unless the drive is selected. But it will affect the bus next time the drive is selected. It's like adjusting the output just prior to the drive-select output buffer. This given, do you need these extra checks, really? You seem to think so?