No announcement yet.

NMI's and PB3.5 : redirection?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Criss French
    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

    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

    Leave a comment:

  • Tom Hanlin
    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

    Leave a comment:

  • Criss French
    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).

    Leave a comment:

  • Tom Hanlin
    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

    Leave a comment:

  • Criss French
    started a topic NMI's and PB3.5 : redirection?

    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
    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

    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?!?!