Image Map Image Map
Results 1 to 8 of 8

Thread: 80286 Real Mode emulation on 8088 ?

  1. #1
    Join Date
    Dec 2012
    Location
    Russia, Moscow
    Posts
    109

    Default 80286 Real Mode emulation on 8088 ?

    Hello,

    is it possible with INT 1 (single step)? By installing our own handler, we can learn the following opcode. Something like this: http://ivanlef0u.fr/repo/madchat/vxd...t/tudf0001.htm What do you think about it?.

  2. Default

    Quote Originally Posted by Tronix View Post
    Hello,

    is it possible with INT 1 (single step)? By installing our own handler, we can learn the following opcode. Something like this: http://ivanlef0u.fr/repo/madchat/vxd...t/tudf0001.htm What do you think about it?.
    It would be too slow to be practical - the single step interrupt alone adds 50 clocks to every instruction, including every single REP iteration!

    The interrupt handler then would take something like 200 clocks just to determine (in the most likely case) that the next opcode exists on the 8088 and return. Typical instructions would effectively run at less than 5% of normal speed.

    One possible way to get a somewhat useful 186 emulator (all 286 instructions not related to protected mode did already exist on the 80186), is to first trace through the code completely in software and patch in a breakpoint where it has to be interrupted next. This would be the emulated instructions, but also any conditional or indirect branch, so that we can keep track of where it goes.

    A further optimization would be to remember what parts of the code have already been examined, so it can then be run at full speed the next time. Modern virtual machines had to do something similar before CPUs got functionality to support them.

    It would still be slow, and a lot more complicated than your idea. Is this emulator intended to be general-purpose, or do you have some specific use in mind?

  3. #3
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,851
    Blog Entries
    1

    Default

    The "trap flag always on" was my idea for a very smooth "slowdown" or "slomo" program, but I never got around to implementing it.

    A facility exists for this on the 80286 and up (you can trap on an invalid opcode).
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,467
    Blog Entries
    20

    Default

    Would seem to be less effort to simply install a V20 or V30 in place of the 8088/8086, no?

  5. #5
    Join Date
    Dec 2012
    Location
    Russia, Moscow
    Posts
    109

    Default

    Thank you all for the answers.

    Of course, installing V20/V30 processor would be a very simple solution. But this is a challenge - run 186 code on 8088. AFAIK, no one has done this before. Some 286 programs have been patched by hands, other programs recompiled if they had source codes... But i never see realtime 80186 code execution before on 8088.

    So, it just for fun, without any definite purpose.

    Quote Originally Posted by dreNorteR View Post
    It would be too slow to be practical - the single step interrupt alone adds 50 clocks to every instruction, including every single REP iteration!

    The interrupt handler then would take something like 200 clocks just to determine (in the most likely case) that the next opcode exists on the 8088 and return. Typical instructions would effectively run at less than 5% of normal speed.
    Yes, i understand it. But it is still interesting if it is possible, despite the low speed.

    Quote Originally Posted by dreNorteR View Post
    One possible way to get a somewhat useful 186 emulator (all 286 instructions not related to protected mode did already exist on the 80186), is to first trace through the code completely in software and patch in a breakpoint where it has to be interrupted next. This would be the emulated instructions, but also any conditional or indirect branch, so that we can keep track of where it goes.
    I thought about it. For example, take the FAKE86 emulator source code, the cpu.c kernel, run the program there and log all 80186 opcodes and their CS:IP to the file. Then patch original program .EXE with INT3 on any 80186 opcodes. Make INT3 handler with recorded table from FAKE86. But yes, there is a problem with addresses and offsets. And any conditional or indirect branch and jumps.

    Quote Originally Posted by dreNorteR View Post
    Is this emulator intended to be general-purpose, or do you have some specific use in mind?
    General-purpose. For example, for run ESSCFG.COM utility for ESS1868 soundcards or Flashback game or some network packet drivers. Nothing special.

    Quote Originally Posted by Trixter View Post
    A facility exists for this on the 80286 and up (you can trap on an invalid opcode).
    I know, but i talk about 8088/86 CPU's

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,467
    Blog Entries
    20

    Default

    Well, you could certainly emulate just about any processor you have available storage for. Turing-complete and all of that.

    So, you could, theoretically, emulate an Pentium 4 on an 8080, given sufficient storage.

    There are many other solutions, such as static code analysis, patching 186-specific instructions with interrupts to allow execution by subroutine, etc. That way, the bulk of the x86 code runs at full speed, with only the x186 instructions incurring a penalty. Self-modifying code, is, of course, an issue.

  7. #7

    Default

    Quote Originally Posted by Chuck(G) View Post
    Self-modifying code, is, of course, an issue.
    May I ask, why?

    If I understand correctly, the program changes a piece of code of it self. The moment the single-stepper arrives at that part, this new code is just treated as any other code. And IMHO the stepper doesn't even "know" that the code has been changed.
    With kind regards / met vriendelijke groet, Ruud Baltissen

    www.baltissen.org

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,467
    Blog Entries
    20

    Default

    I've been talking about static code analysis--trapping only specific instructions by patching them, allowing the rest of the code to run at full speed. Once this is done, the code is frozen in amber. If it modifies itself, it could overwrite a "patch" or insert a "new" instruction somewhere.

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
  •