RomWBW + CP/M 3: floppy driver

[Anna Christina]

Hallo,

I am experimenting with RomWBW and CP/M 3.

While testing, I am experiencing the following:

I compiled the latest git version of RomWBW using this configuration:

----

#include "cfg_rcz80.asm"
;
CPUOSC          .SET    7372800         ; CPU OSC FREQ IN MHZ
DEFSERCFG       .SET    SER_115200_8N1  ; DEFAULT SERIAL LINE CONFIG (SEE STD.ASM)
;
DSRTCENABLE     .SET    TRUE            ; DSRTC: ENABLE DS-1302 CLOCK DRIVER (DSRTC.ASM)
;
ACIAENABLE      .SET    FALSE           ; ACIA: ENABLE MOTOROLA 6850 ACIA DRIVER (ACIA.ASM)
;
SIOENABLE       .SET    TRUE            ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)
SIOCNT          .SET    2               ; SIO: NUMBER OF CHIPS TO DETECT (1-2), 2 CHANNELS PER CHIP
;
FDENABLE        .SET    TRUE            ; FD: ENABLE FLOPPY DISK DRIVER (FD.ASM)
FDMODE          .SET    FDMODE_RCWDC    ; FD: DRIVER MODE: FDMODE_[DIO|ZETA|DIDE|N8|DIO3]
;
IDEENABLE       .SET    TRUE            ; IDE: ENABLE IDE DISK DRIVER (IDE.ASM)
IDE0MODE        .SET    IDEMODE_RC      ; IDE 0: DRIVER MODE: IDEMODE_[DIO|DIDE|MK4|RC]
;
PPIDEENABLE     .SET    FALSE           ; PPIDE: ENABLE PARALLEL PORT IDE DISK DRIVER (PPIDE.ASM)
;
AYENABLE        .SET    TRUE            ; AY: ENABLE AY PSG SOUND DRIVER
AYMODE          .SET    AYMODE_RCZ80    ; AY: DRIVER MODE: AYMODE_[SCG/N8/RCZ80/RCZ180]
;
DIAGENABLE      .SET    FALSE

----

Then, I copied the CP/M 3 files from the different RomWBW directories to a floppy disk.

To make it bootable, I first booted into the ROM disk and used SYSCOPY to make the floppy disk bootable (using CPMLDR.SYS).

Afterwards, I booted from floppy and reached CP/M 3 just fine.

Now, my problem / bug report / question is:

From this point onwards, the floppy disk LED stays on and the floppy motor keeps running.

The floppy seems to work just fine, but it keeps on "running".

Did I configure anything wrong or did I find a bug?

Thank you!!

Regards,

Anna

[Jim McGinnis]

Hi Anna,

I have a similar problem/interesting behavior with the FDC driver.

If I run a submit file that accesses the floppy, the floppy remains selected (light on) and turning even though the submit "script" is done with the floppy.

The FDC selected state only terminates when the submit script ends. I am not sure how much of a liability this presents to the floppy disk itself.

It just seems like unnecessary wear and tear. Note also that the script (SUB file) is not running from the floppy.

I am running a pre32 build of RomWBW/CPM 2.2.

Just adding more data to the discussion...

Take care and be safe.

Cheers

Jim

[Wayne Warthen]

So, yeah, I noticed this as well.

First, let me explain that the floppy motor timeout has always been problematic because not all RomWBW systems have a periodic 50Hz timer.  To work around this, RomWBW counts all calls to keyboard status checks and implements a countdown timeout.  Once the count reaches zero, the floppy motor is turned off.  The count is reset upon every floppy access.

Apparently, CP/M 3 does more "stuff" between each check for keyboard characters.  The result is a much elongated timeout on the floppy motor.  It has been my experience that if I just wait long enough (1-2 mins. I think), the motor does shut off.

FYI, this mechanism has always been problematic when doing anything that does not check the keyboard frequently.  When I say keyboard, I mean any type of character read call including serial port input status checking.

I guess I need to pursue use of the periodic timer when available because that will allow me to shutoff the floppy motor after an exact amount of time (which is correct behavior).  Unfortunately, this will not solve the problem for some systems (like the very popular RC2014 Z80) because they have no periodic timer.

Perhaps reducing the counter limit would be a reasonable workaround for systems with no periodic timer.  I will look into this.

Thanks,

Wayne

[Jim McGinnis]

Hi,

A bit more data from closer observation:

The drive I am using is a MITSUMI D359M3. Once the diskette is inserted, the heads are loaded against the diskette surface.

As such, there is no lifting mechanism other than the eject process.

The FDC drive continues to rotate after the initial accessing and immediately (2-3 seconds) stops rotation if I abort the SUBMIT file.

I need to put a long delay into the submit file to see just how long the FDC continues to spin the diskette.

As it is now, I get back to the diskette reads after about 20-30 seconds of other activity with the SD0 or PPIDE drives.

I will see how long they spin in the SUBMIT process next...

UPDATE:   If I execute VEDIT in the submit script - once the VEDIT is loaded and I let it just sit there (no keyboard io by human), the FDC drive stops spinning about 15 seconds later.

- this delay is reasonable, IMHO.

Cheers

Jim

NZ4J

[Wayne Warthen]

On Tuesday, March 24, 2020 at 8:17:20 AM UTC-7, Jim McGinnis wrote:

UPDATE:   If I execute VEDIT in the submit script - once the VEDIT is loaded and I let it just sit there (no keyboard io by human), the FDC drive stops spinning about 15 seconds later.

- this delay is reasonable, IMHO.

Thanks Jim.  This is about what I would expect.  I agree, not ideal, but not unreasonable given the hardware constraints.  I will still revisit the downcounter initial value and may reduce it.

-Wayne 

[Wayne Warthen]

For what it is worth, I have decreased the motor timeout time and I have made it somewhat more consistent across different CPU speeds.  This change is checked into the master branch at GitHub.

This seems significantly better in all of my use cases.

The primary thing is to ensure that the motor is not being turned off so quickly that it winds up turning on and off during high disk activity.  In my testing, the lower timeout still works well to keep the motor on throughout heavy disk I/O.

-Wayne

[Anna Christina]

Am Dienstag, 24. März 2020 20:57:37 UTC+1 schrieb Wayne Warthen:

Hallo Wayne,

For what it is worth, I have decreased the motor timeout time and I have made it somewhat more consistent across different CPU speeds.  This change is checked into the master branch at GitHub.

Thank you very much.

I just updated and recompiled RomWBW - and it seems to work just fine on CP/M 3.

I will test it further the next days.

Best regards,

Anna

[Wayne Warthen]

Excellent.  Thanks for trying it!

[Jim McGinnis]

Wow. Wayne, that was lightning fast!   I will rebuild this evening, as well.  Thanks for your generous support!

Cheers

Jim