Announcement

Collapse

Maintenance

The forum could be offline for 30-60 minutes in the very near future for maintenance (said 3pm Pacific). I was behind on getting this notice. I do apologize.
See more
See less

NMI's and PB3.5 : redirection?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • NMI's and PB3.5 : redirection?

    I have a neat little ancient handheld DOS computer, a Husky FS/2.

    It's an 8mhz NECv25+ (8088 enhanced) with 1mb NVRAM. Cool machine for
    survey data collection. Waterproof, bulletproof, mono-LCD is good
    from full sunlight to dark (backlit), 2 COM ports, goes approx. 30hrs
    on 3AA's. You might be suprized at how hard it is to find something
    with these specs in the modern world.

    In the 'Systems Developer's Guide' there is a section about PB
    compatability. It says :

    "NMI's: Spectra Publishing's POWER BASIC, a derivative of Borland's
    TURBO BASIC, redirects the NMI handler, causing FS/2 to hang or
    crash
    as described above. To run POWER BASIC on the FS/2, you must
    patch the compiler to disable the NMI redirection as follows:
    -Obtain a copy of the PBPREP.EXE program ... and run it..."

    So, obviously very out of date. Google can't even find PBPREP.EXE.

    But the question remains (and these forums don't seem to contain
    an answer): Does PB3.5 redirect the NMI handler?

    If not, I will re-wire myself a serial connector and start programming
    for this nifty little beast to be a remote (via RF modems) data-entry
    terminal.

    If PB3.5 does 'redirect the NMI handler', then is there a way to
    fix it? (I'm not expecting you good folks to rewrite the mythical
    PBPREP.EXE for PB3.5)

    I am just hoping that someone here can still remember this factum,
    and put the issue to rest (on the don't bother side) if they are
    reasonable sure that it won't work. Otherwise, I will spend a day
    playing, and let you all know if it worked.

    Cheers, Criss.



    ------------------
    What can go wrong will go wrong.
    Anything can go wrong.
    What hasn't?!?!
    What can go wrong will go wrong.
    Anything can go wrong.
    What hasn't?!?!

  • #2
    NMI, as in Non-Maskable Interrupt? I'd forgotten the PC ever had one
    of those. Hmmm, well... I'll see what I can find out. It may take a
    few days.

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Comment


    • #3
      Thanks for checking into it Tom. Here is some more info from the
      manual, to help put the issue in context. Oh yeah, NMI = non maskable interrupt.
      Please don't mind any typo's.

      17.1.1 Problems with interrupts

      NMI's: on IBM PC's, NMI's are used for RAM parity errors or not at all,
      but the FS/2 uses NMI's for several other purposes. While this is
      generally not a problem, it can affect the use of certain packages,
      described here.

      If an application redirects the NMI vector, it will crash or hang
      the FS/2. Programs that do this include Codeview and TurboBasic (PowerBAsic).
      To use such a program, you must patch the code to either prevent
      redirection or cascade the application's NMI handler from the FS/2 one.
      An application's NMI handler is normally used as "catch all"
      error handlers, eg to catch numeric co-processor errors, on a
      PC-AT system.

      While co-operative task schedulers pose no special problems, pre-
      emptive task schedulers will also crash or hang the FS/2. They
      switch tasks by working off a timer tick, passing a different
      return cs c and flags to the processor. The FS/2 timer tick is
      actually generated within the NMI handler, so the return address
      on the stack is not to the application's code segment, but to the
      BIOS segment.

      Maskable iterrupts: Finally, applications which rely on the use of
      the CLI instructions to mask (disable) all interrupts other than
      NMI may also cause problems, since NMI's are issued regularly on
      the FS/2, unlike the PC (where it indicates a memory error and
      halts the system).

      What can go wrong will go wrong.
      Anything can go wrong.
      What hasn't?!?!

      Comment


      • #4
        The news is, PB/DOS already cascades the NMI... so, if that's the only
        qualification, it should simply work as-is. Try it.

        If it doesn't work, I'm afraid there's no simple solution. The NMI
        handling is tied to floating point support. It's an intrinsic part
        of the PB/DOS runtimes and can't readily be modified or removed.
        You could, possibly, contract for a custom version of PB/DOS but,
        it would not be an inexpensive solution.


        ------------------
        Tom Hanlin
        PowerBASIC Staff

        Comment


        • #5
          Thanks Tom. From what it says in the manual, cascading
          the NMI's should work just fine. Thank's for checking it out.

          I now deem it very worthwhile to build a serial cable, and
          proceed with trying out programming for this cool little
          dinasour.

          Now I'll see if I can figure out how to supply correct voltage
          for the recharging circuit, just got the NiCad A cells.

          I'll share my success with you all, or beg for more help
          if things seem to be within reach but out of my grasp.

          Thanks, Criss
          What can go wrong will go wrong.
          Anything can go wrong.
          What hasn't?!?!

          Comment

          Working...
          X