Announcement

Collapse
No announcement yet.

step-by-step execution in the IDE

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

  • step-by-step execution in the IDE

    My routine:
    Function SectorWrite, should write a sector to a disk directly

    My code fragment:
    Code:
     ! push ds
     ! mov  ah, &H43     ; function 'extended write'
     ! mov  al, 0        ; no verify
     ! mov  dl, &H80     ; hard disk 0
     ! mov  si, DAPofs   ;
     ! mov  ds, DAPseg   ; pointer to Disk Address Packet
     ! int  &H13
     ! pop  ds
     ! jc   SectorWriteFailed
    My environment:
    Running in the PB editor in a DOS box under Windows 95.

    My problem:
    Every time the program is run, the function signals that the call failed,
    and indeed, the sector was not written to the disk... However when the above
    code is run step by step (F7) in the PB editor, the carry flag is NOT set,
    and the sector is written to disk properly... All the other routines (like
    SectorRead) work fine any time...

    My question:
    What can cause the difference in the execution of this interrupt function?
    Could the Windows 95 direct disk access protection (without locking the drive)
    have been avoided somehow by the step by step execution?
    Does anyone know how this can be solved, so I can run the function correctly?


    Kind regards,

    ------------------
    Sebastian Groeneveld
    mailto:[email protected][email protected]</A>
    Sebastian Groeneveld
    mailto:[email protected][email protected]</A>

  • #2

    You're trying to do direct sector writes via the BIOS... from within a DOS box?!?





    Sebastian... not to be critical, but this is potentially a very dangerous thing that you're doing. If you're developing a PB/DOS program that's going to directly invoke BIOS and DOS functions to manipulate hardware this way, you should not be doing it from within a Windows 9x DOS box!!!

    I would say that the way to solve your problem, is to do this development on a DOS-only system.

    ------------------

    Comment


    • #3
      As timing is not an issue here, I'd guess that it's a register or data problem.
      Double-check that all the registers are set up properly and that your buffer is
      correctly initialized. It would also be useful to check the latest docs as, I
      think, Microsoft has made something of a habit of revising the low-level disk
      routines.

      You might also want to look into the &H440D DOS functions (IOCTL).

      Direct disk writing is considered somewhat politically incorrect, these days,
      and may be prevented by antivirus or other installed software as an alleged
      security measure. This would not seem to be the problem at the moment, though.


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

      Comment


      • #4
        Sebastian... not to be critical, but this is potentially a very dangerous thing that you're doing. If you're
        developing a PB/DOS program that's going to directly invoke BIOS and DOS functions to manipulate
        hardware this way, you should not be doing it from within a Windows 9x DOS box!!!
        Woo, don't panic! Direct disk writes are always very dangerous if you don't know what you're doing...
        I've never noticed anything special (dangerous) when running in a DOS box, and I consider it just as safe
        as in pure DOS mode... The only difference in Windows are the annoying "Direct disk write alert" popup
        windows

        Please don't get me wrong... if I *could* I would definitely run this code in pure DOS mode and even
        be glad that I could once again avoid Windows... But unfortunately the extended int13h functions I am
        using are not installed in pure DOS mode and they ARE in Windows...

        Heh, while I'm typing this message I'm also trying several things, and guess what... I found the problem!
        It's the ! pop ds right after the ! int &H13... apparently the POP instruction is executed while
        the interrupt function (write operation) has not yet been completed... so Tom was right, this was a register error,
        although not as I would expect it... Hmm, in this way it can be indeed very dangerous, when DS:SI is pointing to an
        entirely different Disk Address Packet structure.... fortunately the function just failed

        So can anyone tell me how to build in a delay in assembler of just a few clock cycles...?

        Thanks for the replies!

        Regards,

        ------------------
        Sebastian Groeneveld
        mailto:[email protected][email protected]</A>
        Sebastian Groeneveld
        mailto:[email protected][email protected]</A>

        Comment


        • #5
          Sorry, I was too fast with my conclusion.... and I should have known better by now....

          I found out that the DS register does not change in the entire routine, which means that the variable is stored in PB's data segment, right?

          When I put a breakpoint on the line ! int &h13, and then continue the program, the sector will be written.
          When I put a breakpoint on the line ! pop ds, the call has already failed.

          If I insert a (dummy) Basic statement, eg. DELAY 0 or MTIMER, between the INT and the POP, the call always succeeds. However if I insert an assembler loop of 32000 NOPs there, the call always fails....

          Added 07-05: the Basic statement simply clears the carry flag, so the call fails either way, signalling error "Disk is write-protected"... it's scary how step-by-step execution bypasses this write-protection, I wish I could do this too)

          Regards,

          ------------------
          Sebastian Groeneveld
          mailto:[email protected][email protected]</A>

          [This message has been edited by Sebastian Groeneveld (edited July 05, 2001).]
          Sebastian Groeneveld
          mailto:[email protected][email protected]</A>

          Comment

          Working...
          X