Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#311 DISCiPLE fails to format a new disk

future
pending-fixed
nobody
None
5
4 days ago
2014-06-08
Fredrick Meunier
No

Phil Reynolds reports:

except Disciple which just hangs when trying to format a disc after running the setup tape

I also get this (except I get a FORMAT data lost, 4110:1 message instead of a hang).

Discussion

  • Gergely Szasz
    Gergely Szasz
    2015-02-13

    Hmm... Definitely not hangs... but i so confused:

    BTW: "FORMAT data lost n:1" means: Disciple format all track, but next does not find (maybe) the first sector.

    Fuse unlike most of other emulators, emulates disk systems on a low level and high degree. So we use four part emulation:

    1. floppy disk (data, and of course it does the image conversions)
    2. floppy disk drive/fdd (motor, head, index, etc..)
    3. floppy disk controller/fdc (fdc commands, etc)
    4. the interface

    1st and 2nd are common in all disk interfaces. 3rd is WD1772 emulation for Disciple and 4th is Disciple itself of course.

    In the Disciple schematics we cannot see any trick, the WD1772 looks like wired as usual. By the manual, there is no any trick with the disk drives too. (standard 34 pin Shugart interface) And it talk about Shugart 400 disk. So everything seems O.K.

    Only one thing about emulation. The truth is we have to say, there is no real emulation of the rotation of the floppy disk. Instead of fdd level emulation, the index hole "event" emulated in the 4th part, and it is independent of the fdd and disk state, motor on and other things :-(.

    Back to the problem. We see, Disciple do the following:

    1. issue a #d0/force interrupt command - this is O.K. stop any previouse activity of fdc
    2. than monitoring WD1772 status register
    3. when encounter an index hole issue an #f8/write track command (format)
    4. issue a #78/step out command
      ...

    It looks good, but there is a very interesting part:
    Disciple does not turn the motor on.
    In the WD1772 datasheet there is no any text about #dx switch the motor on. The #f8 (%1111 1000) write track commands 'h' flag is 1, so by the flowchart this command not start motor too.

    O.K. may Disciple think, motor is running, because fuse does periodically send index hole events.

    But when i alter emulation code to propagate "index hole" events to fdc only when fdd motor really on. But now, after Forced interrupt, Disciple read fdc status endlessly!

    O.K. my WD1772 description is not obvious about 'h' flag:

    All commands except the Force Interrupt command may be programmed via the h
    Flag to delay for spindle motor startup time. If the h Flag is set and the
    Motor On line (pin 20) is low when a command is received, the WD1770 will
    force Motor On to a logic "1" and wait 6 revolutions before executing the
    command. At 300rpm this guarantees a one second spindle startup time. If
    after finishing the command, the device remains idle for 10 revolutions, the
    Motor On line will go back to a logic "0". If a command is issued while Motor
    On
    is high, the command will execute immediately, defeating the 6 revolutions
    start up. This feature allows consecutive Read or Write commands without
    waiting for motor start up each time; the WD1770 assumes the spindle motor is
    up to speed.

    The flowchart is show a little different thing:

    For Type I commands:

               !
            +--+--+
           /  is   \  no
          ! h  =  0 !-------->-------+
           \   ?   /                 !
            +--+--+                  !
               !yes                  !
    +--------------+--------------+  !
    ! set MO, wait 6 index pulses !  !
    +--------------+--------------+  !
               !                     !
               !-------<-------------+
               !
    

    For type II and III commands:

                                 !
                               +-+-+
                           no /  is \
              +--------<-----! h = 1 !
              !               \  ?  /
              !                +-+-+
              !                  !yes
              !         +--------+--------+
              !         !  set MO, wait   !
              !         ! 6 index pulses  !
              !         +--------+--------+
              !                  !
              +------------->----+
                                 !
    

    We note that something wrong, because in the second chart the condition is h = 1 instead of h = 0. In other materials (e.g. this which claims "...corrected several errors upon original datasheet") the condition always h = 0, another materials (e.g. this scanned) the conditions looks like as here. In the text, there is no any about this "reversed h flag meaning" for type II and III commands.
    One little (?-) difference there is in different materials in the text section: some of say "...the h flag is set and.." others say "...the h flag is not set and.."

    Next, on scanned materials (e.g. this and this) we see a little(?) different chartflow for type III command:

               !
    +--------------+--------+
    !        set MO         !
    +--------------+--------+
               !
            +--+--+
           /  is   \  no
          ! h  =  1 !----->----+
           \   ?   /           !
            +--+--+            !
               !yes            !
    +--------------+--------+  !
    ! delay 6 index pulses  !  !
    +--------------+--------+  !
               !               !
               !-------<-------+
               !
    

    The text does not say anything about what happens when h flag not set. We do not know WD1772 set or not the MOTOR ON line if h = 0, only we suspect only that this case WD1772 does not wait for 6 revolution...

    Back to the charts: in the text we can read about "if MOTOR ON is low ...", but on the chart we see only that: if h = 1 (or 0 :-) then WD177x switch on the MOTOR and wait for 6 rev, otherwise not start the motor independently of MOTOR ON status.

    How we can resolve this puzzle? (noways ;-)

    We may think, the original scanned materials include the right flowchart, with a little error: it show h = 1 condition instead of h = 0. So, WD1772 always startup the motor, regardless of the state of h flag.

    But what about Type II commands (sector read and sector write)? And why Type I (head stepping) commands work differently?

    Otherwise i have to note again, the flowcharts is in contradiction to text, because text say: "If a command is issued while Motor On is high, the command will execute immediately, defeating the 6 revolutions start up."

    But the biggest problem in our case is that: Disciple wait for "index hole" event before issue any Write Track command!

    So we can assume that The Type IV command - Forced interrupt - is starting up the fdd motor... (???)

    O.k. this not looks so real, but i do not know any other real thing to solve this puzzle... ?

    Now we can fix format problam with two way:

    1. (this is a quit unreal way) we lean on the fake index events, and think the condition h is reversed for type iii commands, and start up the motor when a Write Track command issued, regardless of the h flag -- according to the scanned datasheet's flowchart.
    2. we start up the motor when a "Forced interrupt" command issued

    The 1st looks like more real on the "datasheet" base, the second looks like more real on the "Disciple behaviour" base... ?
    We have to note that, with solution 1, we get a very long formatting time, because every write track wait 6 revolution before start...

    Hmm. i attached the two patch...

    If anybody knows any further trick about WD1772 and/or Disciple ... ;-)

     
    Last edit: Gergely Szasz 2015-02-13
  • Gergely Szasz
    Gergely Szasz
    2015-02-13

    There is an interesting comment in Steem's Floppy Disk Controller (WD1772) core code

    // AFAIK the FDC turns the motor on automatically whenever it receives a command.
    // Normally the FDC delays execution until the motor has reached top speed but
    // there is a bit in type 1, 2 and 3 commands that will make them execute
    // while the motor is in the middle of spinning up (BIT_3).
    bool delay_exec=0;

    IMHO 2nd patch receive a plus point...

     
  • Gergely Szasz
    Gergely Szasz
    2015-02-20

    Here is a patch:

    • change WD1770/72 behaviour about motor on (now disciple can format blank disks ...)
    • remove individual "disk index events" from interfaces (beta_index, opus_index, etc...)
    • now fdd provides the index events, but only if a disk "loaded" and drive motor is on
    • change disk_t * to disk_t struct in fdd_t, so we do not need a higher level ..._drive struct
    • remove the unnecessary wd_fdc_drive and upd_fdc_drive type, and uses fdd_t instead of
     
  • Thanks Gergely, I had a try of this newest patch and disciple does now format disks which is great.

    Reading the patch, I had the following queries/comments:

    • You added a question mark to the +3 disk preformat handling call - you added this for bug https://sourceforge.net/p/fuse-emulator/bugs/171/ . A quick check with this code disabled shows it is still needed.
    • Beta has a d->index_pulse = 0; line commented out and a question put after index_interrupt. Do we still need some cleanup here? I see the equivalent lines are ommitted for Disciple.
    • why is disciple_memswap = 0 in disciple_reset() disabled?
    • in fdd_event() the call to set intrq for the wd_fdc is disabled. It looks like fdd_event should be part of the controller rather than fdd so that wdc can set intrq where upd doesn't (the user_data passed to fdd_event() would presumably have both the fdd and the fdc to support this)?
    • Does Beta still require this int set to be disabled to avoid interrupts while reading/writing data?
     
  • Gergely Szasz
    Gergely Szasz
    2015-02-21

    • "preformatting" - yes I just mark it, because it does not looks so real if we need a "formatted" disk to format it ...so it looks like a workaround around an unknown bug. BTW: Does anybody known about that: +3 can format or not totally blank (unformatted) disks?
    • "Beta index_interrupt" - of course, we do not need it (all this code moved to FDD)
    • the disciple_memswap = 0 is my fault, sorry. I just did test disciple on 128k Speccy (Bug[#286])...
    • the fdd_event() generates the index hole events (so it definitely belong in fdd :-)

    About the interrupts:

    • +3 uses upd765 fdc, but INT pin (18) of the IC does not connected (to the spectrum edge connector), so +3 never see FDC interrupts
    • Disciple and +D use WD1772, but DRQ(27) and INTRQ(28) pins not connected, so never mind
    • OpusDiscovery uses WD1770. DRQ pin connected to Spectrum NMI, so, WD1770 DRQ cause an NMI call, but INTRQ pin not connected...
    • Beta128 uses FD1793, the DRQ pin connected to D6 and the INTRQ pin connected to D7, so Beta128 can see the status of INTRQ line (beta_sp_read()). Beta128 can check "index_interrupt" too (i completed the code in fdd.c and wd_fdc.c...)

    About index "events":

    • now we do not emulate the rotation of disk. The emulated FDD/DISK immediately supply or receive data. (So there is no any lag when FDC read or write data)
    • during read or write FDD automatically set/reset index (fdd->index), and there is a fdd_wait_index_hole() which used by FDCs.
    • but when there is no any READ/WRITE activity, than the index state (of course) never changes. So that case Spectrum needlessly monitoring the status of index hole (e.g. Disciple start FORMAT disk with a ForcedInterrupt command, and monitoring the STATUS (bit1) of WD1772 FDC, waiting for an index "pulse").
    • to solve this "deadlock", we generating an independet "index event" (now FDD, and a little smarter way than before), and FDC uses it for their STATUS register...

    I attach a cleaned up patch.

     

    Related

    Bugs: #286

  • Thanks all.

    I plan to commit the cleaned up patch this weekend unless anyone thinks it needs more work.

     
    • status: open --> pending-fixed
     
  • Committed Gergely's fix in [r5116].

     

    Related

    Commit: [r5116]