Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: IBM PC AT Bios - reading a track at a time on 1.2M...

  1. #11
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    3,960
    Blog Entries
    1

    Default

    I hope you get a chance to run it through the debugger and see how it is allocating memory. That sounds like the type of problem where changing the amount of memory by adding a device driver or using a higher capacity drive (like a 2.88 MB) would cause read failures to show up again.

  2. #12
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    28,919
    Blog Entries
    20

    Default

    The usual way is to allocate a buffer of nearly twice the size that you need and determine where the buffer will not "straddle" the 64K boundary. You can return any excess left over. Use the library function to allocate a "far" buffer for maximum flexibility.

  3. #13

    Default

    I'm not saying it is the best way, but here is what I'm doing:

    Code:
    UINT8PTRTYPE * __fastcall SingleSegmentAllocate(uint16_t Size)
      {
        UINT8PTRTYPE * P[16], *M;
        uint16_t i1,us1;
    
        M=NULL;
        for (i1=0;i1<16;i1++)
          P[i1]=NULL;
        for (i1=0;i1<16;i1++)
          {
            P[i1]=new UINT8PTRTYPE[Size];
            if (P[i1]==NULL)
              goto end;
            movmem(((char*)&P[i1])+2,&us1,2);
            us1=(uint16_t)((0x1000-((us1&0xfff)))*16);
            if (us1>=Size)
              {
                M=P[i1];
                P[i1]=NULL;
                goto end;
              }
          }
    
        end:
        for (i1=0;i1<16;i1++)
          if (P[i1]!=NULL)
            delete[] P[i1];
        return M;
      }

  4. #14

    Default

    Flakiness is a big red flag. Something is being left in a bad state. I don't think your compiler is the cause of the problem though.

    Do you have stack overflow checking turned on? Can you absolutely confirm that you are not crossing a 64K boundary? (That's easy enough to do - at runtime add a check to the pointer you are using for the buffer.) Did you hook any interrupts?

    Lastly, I can't remember if this is required or just good practice but you might try resetting the drive controller after a read error and trying again. I think the reset might be required after a read error, which is why it seems to work better after a reboot.

    And "Address mark not found" is an indication of a marginal diskette. Try cleaning the heads and using a freshly formatted diskette.

  5. #15

    Default

    I don't think I have stack overflow checking on, but it should have the same stack in either state and I don't use any recursive functions so I'm not sure this is it, but it is easy enough to turn on/try.

    When I printed the pointer address, it wasn't crossing the 64K boundary.

    No interrupts being hooked.

    I am NOT resetting the drive controller and maybe this is something to implement.

  6. #16

    Default

    Definitely reset the drive controller after an error.

    The pointer address will change often depending on run-time conditions, so printing it is useful but you really need a stronger check to enforce it the requirement.

    I don't have the source code to my disk imaging program in front of me, but I'm pretty sure that I do it. And the Phoenix BIOS reference that I used might be the source of that technique.

  7. #17

    Default

    The pointer should always be good if my SingleSegmentAllocate function above works. I'll first try to make sure I can reproduce the issue (dos just loading the compiler cause it, does compiling cause it, etc.), then I'll try adding the reset to see if it changes things.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •