Help save net neutrality! Learn more.

Goals for Release 3.3.0 (Developer 3.2.9)

  • Boisy Pitre

    Boisy Pitre - 2008-05-17

    Here's a list of goals for the big 3.3.0 (Developer 3.2.9) release scheduled in the future:

    NitrOS-9 V03.02.07 Release Goals TODO

        - Fix init/term bug (only seen if windowing system is successively
              brought up/torn down).  This a long-standing bug, but doesn't impact
              the typical user.  More of an irritant than anything else.
        - Backport along with keydrv, joydrv, snddrv to Level 1.

        - Backport to Level 1

        - Backport to Level 1

        - Add option to allow formatting of Dragon disk format.
        - Fix SS.WrTrk to handle high density drives (is this working now?)
        - Fix SS.WrtTrk bug which causes crashes on some CoCos (I believe the
          slowdown was employed as a temporary workaround?)
        Using a Disto Super Controller I hooked up to a 6309 CoCo 3, I
        booted to V03.02.04 and formatted /d1 which is a 5.25" 360K drive.
        I experienced the same computer lock-ups that others have seen.
        With the same setup that I made the above discovery, I made
        a new system disk with the latest code, the only thing being
        different was rb1773.asm which I retrieved from the repository
        at revision 1.10, the same revision that was part of V03.02.04.  I
        did a physical format on a 360K disk SIX times without any lockups.
        I then reverted to the format that was part of V03.02.04 and again,
        SIX physical formats yielded no lockups.

        Finally, I reinstated the latest rb1773 and format, then modified
        rb1773.asm to not slow down and speed up the CoCo 3 around the
        SS.WrTrk code.  Six physical formats did not show a single lock-up.

        Conclusion: Further research is needed to warrant what caused this
        bug in V03.02.04.  It does not appear to be related to the driver
        directly, nor to the format utility.  It may be related to the
        kernel since that component has changed since V03.02.04.  At this
        point and time, further testing of the latest repository is needed
        to confirm on other systems that this bug no longer exists.

        - Add code to select MPI slot where disk controller is (can assume
              slot 4 or allow the value to be placed in the descriptor)

        - Backport to Level 1

        - Adapt source to act as CoWP module to VTIO
          (Phill-Harvey Smith said he would tackle this... Phill?)

        - Add the -q option for quick linking of bootfiles

    All boot modules
        - Handle fragmented bootfiles
          (boot_1773 is done, others need to be modified and tested)

    • Robert Gault

      Robert Gault - 2008-06-10

      RB1773  - Add code to select MPI slot where disk controller is (can assume
      slot 4 or allow the value to be placed in the descriptor)

      I think this does not require a descriptor value. One could add to the "Boisy hardware exists code" cycling through the MPI slots. Start with slot 4, test for a write/read, and move to the next slot if write/read fails. If write/read succeeds, not only is hardware found but the slot as well.

      Any comments?

      • Boisy Pitre

        Boisy Pitre - 2008-06-10

        An interesting idea.  I think this would work at the driver's Init routine, where it would cycle through all four slots until it found one that responded.  Then it could save the slot number in its statics.

        The only pitfall I see is if someone had two or more floppy controllers in their MPI (crazy, I know, but what if?)  In that case, the first one found would be the one to be used.

        I'll think about this for a bit and add a more detailed response later.



Cancel  Add attachments