8085 simulator in C

Discussion in 'C Programming' started by activearun.83@gmail.com, Jun 4, 2007.

  1. Guest

    Hi everyone,

    Can anyone give some idea about developing an 8085 simulator
    program in C? What techniques can be handled to develop this?
    , Jun 4, 2007
    #1
    1. Advertising

  2. In article <>,
    <> wrote:

    > Can anyone give some idea about developing an 8085 simulator
    >program in C? What techniques can be handled to develop this?


    -Personally-, I wouldn't bother unless it was an assignment or
    a pet learning project (and even then, I'd reconsider whether
    8085 was the right choice of processors.)

    If you wanted an 8085 simulator, I'd look around and try out
    http://sourceforge.net/projects/sim85
    or Vaneet Singla's 8085 simulator (available in a wide variety of places)
    --
    If you lie to the compiler, it will get its revenge. -- Henry Spencer
    Walter Roberson, Jun 4, 2007
    #2
    1. Advertising

  3. user923005 Guest

    user923005, Jun 4, 2007
    #3
  4. Guest

    On Jun 4, 1:30 pm, -cnrc.gc.ca (Walter Roberson)
    wrote:
    > In article <>,
    >
    > <> wrote:
    > > Can anyone give some idea about developing an 8085 simulator
    > >program in C? What techniques can be handled to develop this?

    >
    > -Personally-, I wouldn't bother unless it was an assignment or
    > a pet learning project (and even then, I'd reconsider whether
    > 8085 was the right choice of processors.)


    I don't think 8085 is such a bad choice. Very simple instruction set.
    I did this one weekend about 20 years ago just for the heck of it. I
    had an old single board PC I wanted to emulate on a VAX.

    The OP wanted suggestions on techniques to do this. As I recall, the
    upper nibble of the opcode pretty much tells you what the instruction
    will do, so I made an array of 16 functions and used the upper nibble
    to index into the array. Then I had 16 individual functions to handle
    the operations. The lower nibble is mostly for addressing, so that too
    can index into an array for the correct register. Setting the flags
    properly was the trickiest part.
    , Jun 5, 2007
    #4
  5. Ben Pfaff Guest

    writes:

    > The OP wanted suggestions on techniques to do this. As I recall, the
    > upper nibble of the opcode pretty much tells you what the instruction
    > will do, so I made an array of 16 functions and used the upper nibble
    > to index into the array. Then I had 16 individual functions to handle
    > the operations. The lower nibble is mostly for addressing, so that too
    > can index into an array for the correct register. Setting the flags
    > properly was the trickiest part.


    This sounds like a fun instruction set on which to practice
    writing a (static or dynamic) binary translator. (Of course,
    there's no way to actually run the translated code without
    invoking undefined behavior, from a comp.lang.c point of view.)
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jun 5, 2007
    #5
  6. Chris Hills Guest

    In article <>,
    writes
    >On Jun 4, 1:30 pm, -cnrc.gc.ca (Walter Roberson)
    >wrote:
    >> In article <>,
    >>
    >> <> wrote:
    >> > Can anyone give some idea about developing an 8085 simulator
    >> >program in C? What techniques can be handled to develop this?

    >>
    >> -Personally-, I wouldn't bother unless it was an assignment or
    >> a pet learning project (and even then, I'd reconsider whether
    >> 8085 was the right choice of processors.)

    >
    >I don't think 8085 is such a bad choice.

    It is if you want o buy one... I am certain the are obsolete these
    days,.

    > Very simple instruction set.
    >I did this one weekend about 20 years ago just for the heck of it. I
    >had an old single board PC I wanted to emulate on a VAX.


    Exactly....20 years ago It might be technically nice but getting the HW
    is another matter. As for the tools.... i will dust of the compiler on
    the 5.25" floppies.....

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris Hills, Jun 5, 2007
    #6
  7. Guest

    On Jun 5, 10:45 am, Chris Hills <> wrote:
    > In article <>,
    > writes>On Jun 4, 1:30 pm, -cnrc.gc.ca (Walter Roberson)
    > >wrote:
    > >> In article <>,

    >
    > >> <> wrote:
    > >> > Can anyone give some idea about developing an 8085 simulator
    > >> >program in C? What techniques can be handled to develop this?

    >
    > >> -Personally-, I wouldn't bother unless it was an assignment or
    > >> a pet learning project (and even then, I'd reconsider whether
    > >> 8085 was the right choice of processors.)

    >
    > >I don't think 8085 is such a bad choice.

    >
    > It is if you want o buy one... I am certain the are obsolete these
    > days,.
    >
    > > Very simple instruction set.
    > >I did this one weekend about 20 years ago just for the heck of it. I
    > >had an old single board PC I wanted to emulate on a VAX.

    >
    > Exactly....20 years ago It might be technically nice but getting the HW
    > is another matter. As for the tools.... i will dust of the compiler on
    > the 5.25" floppies.....


    You can still get the Z80 at DigiKey. Same instruction set, even
    easier to connect up (the address and data bus are not multiplexed
    like on the 8085). But then the OP just wants to emulate it, not build
    one (but I would suggest doing so anyway). And since he wants to do it
    in C, if he has trouble along the way his questions will likely be on
    topic for this group. As to the rest of this discussion...
    , Jun 5, 2007
    #7
  8. writes:

    > You can still get the Z80 at DigiKey. Same instruction set, even
    > easier to connect up (the address and data bus are not multiplexed
    > like on the 8085).


    I think you are confusing 8080 and 8085.

    --
    Jean-Marc, who has programmed both but could be the one doing the confusion
    Jean-Marc Bourguet, Jun 5, 2007
    #8
  9. Guest

    On Jun 5, 11:28 am, Jean-Marc Bourguet <> wrote:
    > writes:
    > > You can still get the Z80 at DigiKey. Same instruction set, even
    > > easier to connect up (the address and data bus are not multiplexed
    > > like on the 8085).

    >
    > I think you are confusing 8080 and 8085.
    >
    > --
    > Jean-Marc, who has programmed both but could be the one doing the confusion


    Nope, the 8080 used an external clock generator (8224) and system
    controller (8228) that were built into the 8085. There are a couple of
    undefined opcodes in the 8080/8085 that the Z80 defined to extend the
    architecture of the 8080/8085. It doubled the number of registers,
    demuxed the IO, and added a few new registers. However, as long as you
    don't use those undefined opcodes, it is 100% software compatible
    (only the timing is different).
    , Jun 5, 2007
    #9
  10. Ben Pfaff wrote:
    >
    > writes:
    >
    > > The OP wanted suggestions on techniques to do this. As I recall, the
    > > upper nibble of the opcode pretty much tells you what the instruction
    > > will do, so I made an array of 16 functions and used the upper nibble
    > > to index into the array. Then I had 16 individual functions to handle
    > > the operations. The lower nibble is mostly for addressing, so that too
    > > can index into an array for the correct register. Setting the flags
    > > properly was the trickiest part.

    >
    > This sounds like a fun instruction set on which to practice
    > writing a (static or dynamic) binary translator. (Of course,
    > there's no way to actually run the translated code without
    > invoking undefined behavior, from a comp.lang.c point of view.)


    How so? You have a struct holding the emulator's CPU registers, and a
    64K unsigned char array (or two 32K arrays, since I seem to recall the
    standard not requiring support for 64K arrays) representing the memory.

    Now, emulating the hardware which might be surrounding the CPU is
    another story. (Though you're probably more likely to run into
    "implementation defined" or "unspecified" behavior than actual UB.)

    :)

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Jun 5, 2007
    #10
  11. In article <>,
    Kenneth Brody <> wrote:
    >Ben Pfaff wrote:


    >> This sounds like a fun instruction set on which to practice
    >> writing a (static or dynamic) binary translator. (Of course,
    >> there's no way to actually run the translated code without
    >> invoking undefined behavior, from a comp.lang.c point of view.)


    >How so? You have a struct holding the emulator's CPU registers, and a
    >64K unsigned char array (or two 32K arrays, since I seem to recall the
    >standard not requiring support for 64K arrays) representing the memory.


    Ben is talking about binary *translator* -- i.e., that the 8085 binary
    code be examined and converted to code native to the hosting system
    and run directly as native code instead of by emulating each 8085
    instruction. And he is correct that you can't actually run the
    translated code without undefined behaviour, as C does not offer
    any mechanism to compute native code and set that code into execution.

    For example, C does *not* offer

    unsigned char object_code[SomeSizeOrOther];
    object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
    ((void(*)()) object_code)(); /* undefined behaviour! */

    There is no C facility to convert an object pointer into a function
    pointer.
    --
    Is there any thing whereof it may be said, See, this is new? It hath
    been already of old time, which was before us. -- Ecclesiastes
    Walter Roberson, Jun 5, 2007
    #11
  12. <> wrote in message
    news:...
    > On Jun 5, 11:28 am, Jean-Marc Bourguet <> wrote:
    >> writes:
    >> > You can still get the Z80 at DigiKey. Same instruction set, even
    >> > easier to connect up (the address and data bus are not multiplexed
    >> > like on the 8085).

    >>
    >> I think you are confusing 8080 and 8085.
    >>
    >> --
    >> Jean-Marc, who has programmed both but could be the one doing the
    >> confusion

    >
    > Nope, the 8080 used an external clock generator (8224) and system
    > controller (8228) that were built into the 8085. There are a couple of
    > undefined opcodes in the 8080/8085 that the Z80 defined to extend the
    > architecture of the 8080/8085. It doubled the number of registers,
    > demuxed the IO, and added a few new registers. However, as long as you
    > don't use those undefined opcodes, it is 100% software compatible
    > (only the timing is different).

    Oops, only 99.99% software compatible -- if you did an 8 bit add or
    subtract, the 8080/8085 would save the parity of the result into the 'parity
    flag', while the Z80 would save whether the operation overflowed into the
    parity flag. That generally came up only if you were deliberately writing
    code that would work differently on the different processors, but it is a
    difference.

    --
    poncho
    Scott Fluhrer, Jun 6, 2007
    #12
  13. Walter Roberson wrote:
    >
    > In article <>,
    > Kenneth Brody <> wrote:
    > >Ben Pfaff wrote:

    >
    > >> This sounds like a fun instruction set on which to practice
    > >> writing a (static or dynamic) binary translator. (Of course,
    > >> there's no way to actually run the translated code without
    > >> invoking undefined behavior, from a comp.lang.c point of view.)

    >
    > >How so? You have a struct holding the emulator's CPU registers, and a
    > >64K unsigned char array (or two 32K arrays, since I seem to recall the
    > >standard not requiring support for 64K arrays) representing the memory.

    >
    > Ben is talking about binary *translator* -- i.e., that the 8085 binary
    > code be examined and converted to code native to the hosting system
    > and run directly as native code instead of by emulating each 8085
    > instruction.


    Ah. I was thinking "emulator" rather than "translator". Of
    course, something that generates (portable) C source code which
    is to be compiled elsewhere could qualify as a "translator".

    > And he is correct that you can't actually run the translated code
    > without undefined behaviour, as C does not offer any mechanism to
    > compute native code and set that code into execution.
    >
    > For example, C does *not* offer
    >
    > unsigned char object_code[SomeSizeOrOther];
    > object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
    > ((void(*)()) object_code)(); /* undefined behaviour! */
    >
    > There is no C facility to convert an object pointer into a function
    > pointer.


    Is this actually UB, or is it "implementation defined"?

    Also, isn't a compiler allowed to define the behavior which is UB
    according to the standard? In other words, a compiler _could_
    explicitly allow such a construct, with the caveat (of course)
    that the pointer must point to valid machine code, to allow
    things similar to Java's JIT[1] compiler.


    [1] JIT == "Just In Time". As I understand it, the Java bytecode is
    compiled into native machine code as the program runs.

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Jun 6, 2007
    #13
  14. Guest

    On Jun 5, 5:01 pm, CBFalconer <> wrote:
    >
    > He is better off simulating the 8080 instruction set, which can
    > then be expanded into the Z80 set, which in turn can be expanded
    > into the 64180 set. The 8085 is a dead end.
    >


    I think you are confusing 8085 and 8086/8088.
    , Jun 6, 2007
    #14
  15. "Kenneth Brody" <> wrote in message
    news:...
    > Walter Roberson wrote:
    >>
    >> In article <>,
    >> Kenneth Brody <> wrote:
    >> >Ben Pfaff wrote:

    >>
    >> >> This sounds like a fun instruction set on which to practice
    >> >> writing a (static or dynamic) binary translator. (Of course,
    >> >> there's no way to actually run the translated code without
    >> >> invoking undefined behavior, from a comp.lang.c point of view.)

    >>
    >> >How so? You have a struct holding the emulator's CPU registers, and a
    >> >64K unsigned char array (or two 32K arrays, since I seem to recall the
    >> >standard not requiring support for 64K arrays) representing the memory.

    >>
    >> Ben is talking about binary *translator* -- i.e., that the 8085 binary
    >> code be examined and converted to code native to the hosting system
    >> and run directly as native code instead of by emulating each 8085
    >> instruction.

    >
    > Ah. I was thinking "emulator" rather than "translator". Of
    > course, something that generates (portable) C source code which
    > is to be compiled elsewhere could qualify as a "translator".
    >
    >> And he is correct that you can't actually run the translated code
    >> without undefined behaviour, as C does not offer any mechanism to
    >> compute native code and set that code into execution.
    >>
    >> For example, C does *not* offer
    >>
    >> unsigned char object_code[SomeSizeOrOther];
    >> object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
    >> ((void(*)()) object_code)(); /* undefined behaviour! */
    >>
    >> There is no C facility to convert an object pointer into a function
    >> pointer.

    >
    > Is this actually UB, or is it "implementation defined"?


    Undefined Behavior. "Implementation defined" means that the implementation
    is required to document it, and the Standard places no such requirement.

    >
    > Also, isn't a compiler allowed to define the behavior which is UB
    > according to the standard?


    Of course. Undefined Behavior means the Standard places no requirements,
    and so the implementation is free to do whatever it wants. If it wants to
    define the behavior in a particular way, and additionally to document what
    this behavior is, that's just fine.

    > In other words, a compiler _could_
    > explicitly allow such a construct, with the caveat (of course)
    > that the pointer must point to valid machine code, to allow
    > things similar to Java's JIT[1] compiler.
    >
    >
    > [1] JIT == "Just In Time". As I understand it, the Java bytecode is
    > compiled into native machine code as the program runs.
    >
    > --
    > +-------------------------+--------------------+-----------------------+
    > | Kenneth J. Brody | www.hvcomputer.com | #include |
    > | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    > +-------------------------+--------------------+-----------------------+
    > Don't e-mail me at: <mailto:>
    >
    >
    Scott Fluhrer, Jun 6, 2007
    #15
  16. Bill Leary Guest

    <> wrote in message
    news:...
    > You can still get the Z80 at DigiKey. Same instruction set, even
    > easier to connect up (the address and data bus are not multiplexed
    > like on the 8085).


    Not the same instruction set. The common denominator is the 8080. The Z80
    adds a lot of new instructions. The 8085 added a few new instructions.
    Some of those new ones for the 8085 use the same op-codes as new ones for
    the Z80, but do entirely different things. There were also a few flags
    which responded differently on the 8085 than they did on the 8080 or Z80.
    When we wanted a single executable to run on two or three of these devices,
    we used to write "detector code" which nudged at these flags and
    instructions to figure out which machine the code was running on.

    If one want's to use other processors "based" at 8080 there's also the
    64180, the Z180 (Z80's with MMUs and a few other new features) and the
    processor in the original Game Boy, which included some, but not all, of the
    Z80 additional instructions and, as I recall, a few of it's own, and I seem
    to remember an Intel 8080 or 8085 based CPU intended specifically for the
    embedded market which had a few other additional instructions specifically
    intended to cut down on external I/O hardware.

    - Bill
    Bill Leary, Jun 7, 2007
    #16
  17. Kenneth Brody wrote:

    > Walter Roberson wrote:
    >>
    >> For example, C does *not* offer
    >>
    >> unsigned char object_code[SomeSizeOrOther];
    >> object_code[SomeLocationOrOther] = SomeNativeOpcodeOrOther;
    >> ((void(*)()) object_code)(); /* undefined behaviour! */
    >>
    >> There is no C facility to convert an object pointer into a function
    >> pointer.

    >
    > Is this actually UB, or is it "implementation defined"?


    The C standard does not define the behaviour, therefor it is UB.
    This does not preclude other standards (like POSIX), or the compiler
    writers themselves to specify what behaviour will happen.

    UB merely means that the C standard does not restrict the behaviour of
    the construct. Therefor, you should not use such constructs in code
    that must be portable to all possible C implementations, as you can't
    know what the behaviour will be.

    In practice do compilers also implement other standards, like POSIX, or
    have people come to rely on certain behaviours which all may indicate a
    certain behaviour for constructs that are UB under the C standard
    alone.

    Due to the topicality of this group, we only look to the C standard to
    see what behaviour we will get, so we will mark thing as undesirable
    (due to UB) which are fairly common in other environments.

    >
    > Also, isn't a compiler allowed to define the behavior which is UB
    > according to the standard? In other words, a compiler _could_
    > explicitly allow such a construct, with the caveat (of course)
    > that the pointer must point to valid machine code, to allow
    > things similar to Java's JIT[1] compiler.


    Yes, and other standards may even require that the compiler does so.

    Bart v Ingen Schenau
    --
    a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
    c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    c.l.c++ FAQ: http://www.parashift.com/c -faq-lite/
    Bart van Ingen Schenau, Jun 7, 2007
    #17
  18. CINVESTAV

    Joined:
    Jan 9, 2012
    Messages:
    1
    hi

    i'm interested in your idea. i would like to know if could deloveped the program in c. i have some ideas and i wonder if you could help me
    CINVESTAV, Jan 9, 2012
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dipu bhaskar

    vhdl code for 8085

    dipu bhaskar, Jun 30, 2003, in forum: VHDL
    Replies:
    2
    Views:
    2,685
    Ray Andraka
    Feb 11, 2004
  2. Basuki Endah Priyanto

    Free VHDL Simulator

    Basuki Endah Priyanto, Aug 15, 2003, in forum: VHDL
    Replies:
    1
    Views:
    5,314
    Tuukka Toivonen
    Aug 15, 2003
  3. Mike Kopp

    VHDL Simulator Options

    Mike Kopp, Sep 22, 2003, in forum: VHDL
    Replies:
    3
    Views:
    725
  4. Kingsley Oteng

    Bit-Level C Simulator

    Kingsley Oteng, Jan 17, 2004, in forum: VHDL
    Replies:
    4
    Views:
    611
    Tuukka Toivonen
    Jan 21, 2004
  5. Chaos Master

    Free VHDL simulator

    Chaos Master, Jun 17, 2004, in forum: VHDL
    Replies:
    5
    Views:
    19,067
    Chaos Master
    Jun 18, 2004
Loading...

Share This Page