Image Map Image Map
Results 1 to 9 of 9

Thread: Booting DOS from an 8086 simulation with Proteus

  1. #1

    Default Booting DOS from an 8086 simulation with Proteus


    I've been trying to make an 8086 system with Proteus that would boot DOS. The system has a timer 8253, interrupt controller 8259, PPI 8255, and 2 USARTs 8251 (one is used as a video and keyboard). Software is loaded into memory using 2 ports (I used one port as input and the other one as output to avoid logic contentions) from the 8251 from an SD card.
    So far I got these results when trying to load DOS:

    CPM86-1.0 - Shows corrupted init message then hangs
    CPM86-1.10 - Show init message, then Proteus hangs with "Internal Exception access violation"
    MS-DOS 1.0 - Hangs, never stops loading
    MS-DOS 3.10 - displays "Bad or missing Command Interpreter", then hangs
    MS-DOS 3.30 - Hangs, never stops loading
    DR-DOS 3.0 - Hangs, never stops loading
    FREEDOS - Hangs, never stops loading

    I'm not sure what DOS does when it boots and trying to debug it while loading is not an option because you can only debug your code.
    I'm thinking there is something wrong with my BIOS implementation, but if only I knew what DOS is doing when it boots it would really help...

    I'll leave the files in my onedrive:!ACnXr6aLzVwmg28

  2. #2
    Join Date
    Aug 2006
    Chicagoland, Illinois, USA
    Blog Entries


    Alternately, use the actual IBM ROM BIOS just to get it working, then once it works, switch to your own BIOS.
    Offering a bounty for:
    - A working Sanyo MBC-775 or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  3. #3


    The IBM ROM BIOS wont work in the simulation because the IO Ports I'm using are not the same as the ones used in the XT. For example: in the XT the PIC is at address 0x20 and I'm using 0x40, PIT in the XT is at 0x40 and I'm using 0x80, PPI in the XT is 0x60 and I'm using 0xC0. I had to change them because I needed all even addresses for the registers so that I can use the lower 8 bits of the data bus.

  4. #4
    Join Date
    Jun 2016
    Guisborough, England



    This may not be detailed enough for your purposes, but the book:

    Advanced MSDOS by Ray Duncan (Microsoft Press) pages 14 - 18 gives a fairly detailed step-by-step account of how MSDOS is loaded, incl a number of memory maps as the stages progress. Various components move about in memory as the process progresses.

    Have you seen this. May be online somewhere.

    Vintage Devices: Epson HX-20/TF-20, Amstrad PCW 8256 (with extras), 386 and 486 PCs with 5.25 and 3.5 floppy drives, Pentium 75 with Roland LAPC-I midi card

  5. #5
    Join Date
    May 2009
    Blog Entries


    Is your design similar to any of the other 8086 systems? Cribbing a working BIOS and OS with some minor patching for the port addresses might provide a guide as to what needs to be corrected.

  6. #6


    In cases where I can't use an actual debugger, the next tool I tend to reach for is "printf debugging". Tweak your BIOS implementation to display the interrupt number and the values of registers for each BIOS interrupt before going on to the meat of the routine. That will tell you what DOS is doing so that you can check your assumptions and see what was the last thing it did before it crashed.

  7. #7


    What about this idea: load DOS without using DMA. In that way you can keep track what your computer is loading and where it is saving the data. If it loads the wrong data or saves it at the same place, then the BIOS can be blamed. Fix that and if things work, try DMA.
    With kind regards / met vriendelijke groet, Ruud Baltissen

  8. #8


    I think there is some issue with Proteus simulation of the 8086, it seems to have some kind of bug so I'm going to cancel this project. Thank you all for the feedback!

  9. #9


    If you search the Internet, you will find the source code for MS-DOS 6.0.
    It can be used to single-step through the code and check if BIOS calls and CPU instructions work as designed.
    Tracing the code with the original assembly code next to it is tedious, but possible.
    FreeDOS is written in C and less useful for this purpose.


Posting Permissions

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