Image Map Image Map
Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: x86 assembly question: modifying flags register on the stack

  1. #21

    Default

    You should re-enable interrupts immediately on entry to the interrupt 13h handler, otherwise the system timer might lose ticks and the clock will lag.
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

  2. #22

    Default

    Thanks, I will look into moving the STI to the top.

    For what it's worth, my interpretation of the logic analyzer was wrong -- the analysis plugin was capping the number of values it printed, and what I thought were addresses near the hang were addresses some time earlier. Capturing the data and postprocessing it myself, I get the following:

    Code:
    A4..A19                  decoded
    1010100100000000   0000:0950
    1000010100000000   0000:0A10
    1010100100000000   0000:0950
    1000010100000000   0000:0A10
    1010100100000000   0000:0950
    0110100011100000   0000:7160
    1010100100000000   0000:0950
    0110100100000000   0000:0960
    So the last thing on the address bus was in the 960-96F block. This looks to me like data, not code. Some DOS table containing device names (LPT3, COM2, COM3, COM4, ...). I'm wondering if there was a stack overflow and the CPU jumped into the unknown. Anyhow, something for me to go on, will probably get back to it this weekend.

  3. #23
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    25,230
    Blog Entries
    20

    Default

    What Krille said. It's a strongly recommended policy that interrupts be disabled for the shortest amount of time possible.

    There are ways to mitigate situations where this might appear to be impossible. For example, suppose that you have a lengthy ISR, where a device requires some amount of conversation before the interrupt condition is cleared. You can mask the interrupt in the 8259 PIC and enable general interrupts without fear of the still-pending interrupt getting in the way. In most cases, universal interrupts should not be disabled for more than a very few instructions.

  4. #24

    Default

    I think the STI turned out to be somewhat of a red herring.

    I was able to reproduce the problem without causing my handler to be invoked, at least not at the time the hang occurred. DOS only rereads the boot sector, FAT, and root directory if it thinks the floppy has been changed. On floppies without change detection, it uses a 2 second timeout since the last operation. Right after the most recent read completed and returned control to the command interpreter, I issued the delete operation and it hung before ever getting to the point of invoking my int13 handler. So, I'm pretty sure something else is going on. It could be something wrong with the image I'm using. When I get a chance, I'll try writing it to physical media (i.e. a real floppy disk) and see if it experiences the same problem.

  5. #25

    Default

    If you need help finding the problem and don't mind posting your code somewhere, I'd be happy to take a look at it.
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

  6. #26

    Default

    Quote Originally Posted by Krille View Post
    If you need help finding the problem and don't mind posting your code somewhere, I'd be happy to take a look at it.
    Sure, you're welcome to have a look, it's up on github at https://github.com/sbelectronics/ems...os330/flashbio. This is a branch where I was working on resolving the DOS 3.30 issues. The most recent checkin has a CLI at the start of the interrupt handler and a STI at the bottom... That was just me fooling with the interrupt enable. Those can probably be ignored as I'm planning on pulling them back out next time I work on this.

    The most relevant parts of the code would be int13.asm and handlers.asm, in particular the AH=2, AH=8, and AH=15 handlers. The AH=3 handler (disk write) never seems to get called. These routines all seem to work, inasmuch as the system is able to boot and is able to read the disk and execute programs. Write does work in DOS 3.10, 3.21, and 3.31. It's only DOS 3.30 that is behaving badly.

    My assembly skills are pretty rough, so expect a lot of things that could have been done better.

    Also, this whole thing is based on custom hardware, which I haven't yet made a blog post for, or posted the schematic, so you can't actually execute it. Nevertheless, an extra set of eyes on the code would be helpful. Note that there are a few places in the BDA I touch regarding motor status -- as this is a flash drive there is no motor, but I figured touching those bits was worth a shot to see if something was waiting on them.

    Scott
    Last edited by smbaker; December 8th, 2017 at 10:47 PM.

  7. #27

    Default

    why do you keep calling exchange_int13_handler? when you can just do

    pushf
    call d[RAMVARS.int13_old]

    ?

    also you are not preserving DS across int 0x13 calls when you do this exchange and re-call of int 0x13, you cant be sure what your affecting. other custom handlers might need ds from something specific in the call.

    you alre also doing a CMP DL, [CS:drive_num], which wont work if your a bios extension right? CS: will be a rom area.

    Id also say, resetting the int 13h vector in the middle of a call, and calling it, you might run into problems, its not good to take yourself out of the interrupt chain like that (I've seen lots of things like something sitting on the timer and hooking int13h after a certain amount passes or number of other int calls made, now these are not common stuff but I have seen them).

    I have not looked over the rest of the code.

    Are you targetting 8088? because I see "PUSH 0" wich is 286+ instruction.

  8. #28

    Default

    Quote Originally Posted by BloodyCactus View Post
    why do you keep calling exchange_int13_handler? when you can just do
    I saw that the XT-ide BIOS did this, so I did it myself. I agree just calling the old handler would be simpler. My assumption was that XT-ide did it that way for compatibility with some BIOS or hard drive that expected to find its own handler in the int13 vector. So when calling the old handler, I swap, int 13, and then swap back.

    Quote Originally Posted by BloodyCactus View Post
    you alre also doing a CMP DL, [CS:drive_num], which wont work if your a bios extension right? CS: will be a rom area.
    That's correct. [CS:drive_num] is a constant in the ROM area that tells which disk to emulate. It's set to disk 0, which is the first floppy. There are other constants in the ROM area as well, to define the disk geometry. All of these can be changed at build time, or in theory reflashed on an installed system.

    Quote Originally Posted by BloodyCactus View Post
    Are you targetting 8088? because I see "PUSH 0" wich is 286+ instruction.
    Let me make sure I have nasm properly configured to target 8088, as that was my intention. I am using a V20, which I think has access to 80186+ instructions, that may be why the PUSH 0 is succeeding.

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
  •