This article reviews the GNUSim8085 (v1.3.7) a graphical simulator, assembler and debugger for the Intel 8085 microprocessor.

The Intel 8085 is an 8-bit microprocessor that was launched by Intel in 1977 and hence is something that we have never seen around. So why do we need to learn about the programming model and instruction set of this old microprocessor? The microprocessors we use are all for general-purpose computing but there are other applications of computers such as making automatic solar tracking-panels, automatic power-controls, or security control systems. For such applications, general-purpose CPUs are unnecessary-a waste of resources; a low powered CPU is what we need. The Intel 8085 is one of the candidates. To program this piece of hardware, we first need to know the programming model-the logical structure of the programmable registers, flags, and the instruction set.

The Intel 8085 has seven internal general-purpose 8-bit registers A, B, C, D, E, H, L and 5 flags — S (sign), Z (zero), AC (Aux Carry), P (Parity) and CY (Carry). The BC, DE and HL registers can be used as register pairs and work as 16-bit registers, with some specific instructions. Besides these, there are two other registers: one is the program counter (PC), which is a 16-bit register, and always points to the memory address of the next instruction to be processed; the other is the stack pointer (SP), a 16-bit register that points to the top of the stack. The processor has a total of 246 instructions with which we can manipulate data in the processor registers and memory, and also perform conditional branching in code with the help of flag values, which are set by the instructions, depending on the result. This is a brief overview of the programming model; see the References for links to more information. Programming the Intel 8085 or similar microprocessors is not like present-day programming-there is no editor, compiler or assembler, and not even a monitor. You can probably have a 7-segment display, which has to be manually interfaced, to show the memory content. You need to burn in the assembled program (essentially, some numbers in memory), connect the memory with the processor, and the microprocessor starts to run the code. There are programmers to burn the code into memory, and microprocessor kits that help you program the microprocessor interactively by providing additional controllers, 7-segment displays, a 4×4 keyboard, etc. However, you still have to hand-assemble the code. Now, no code is perfect the first time; that’s why we have bugs. Debugging code on an 8085 itself is a real pain. Even if you use a microprocessor kit with a debugging facility, the limited debugging features make it a complex and slow process, not suited for a beginner. So, essentially, to know if your code is correct or not, completely depends on your skills, the expected outputs of the code, and the minimal debugging interface. Wouldn’t it be great to be able to test the code and develop it completely before even touching the actual processor? This is what a simulator lets you do – the very purpose of the GNUSim8085 Intel 8085 Microprocessor Simulator.

About the Simulator

The 8085 microprocessor simulator simulates the Intel 8085 programming model, with the same instructions available as on the real system. The input and the output of the actual machine and the simulator are identical, although the internal processing method may differ. The simulator lets you view the contents of the registers, the memory and I/O port values, execute one instruction at a time, and also write code in mnemonics instead of hand-assembled code. While I was pursuing my undergraduate course, I began to look for a FOSS-based 8085 simulator. Simulators supplied with text books, and others available on the Internet either did not fulfil my needs, or were not FOSS. Then I recalled that LFY had once published a review of GNUSim8085, and downloaded the software. The basic features listed on the official site are:

  • It comes with an 8085 assembler.
  • The editor has syntax highlighting.
  • Register and Flags display are available.
  • Has a hex-to-decimal converter.
  • Provides a view of memory, I/O and stack contents.
  • Step-by-step execution support.
  • Print support.
  • Has UI in different languages.

Now, let’s take a detailed look at this software.

The interface

Simulator Screenshot
Simulator Screenshot

When the software is launched, the editor starts with a template-sample code you can edit-or, you can open a new file, and start coding. The editor lines are numbered. The code highlighting is good, and makes it easier to read the code. To run or assemble code, you need to save it first, before compilation is allowed.

Left side Panel
Left side Panel

On the left-hand pane, all the registers and flags are listed in a very easy-to-read manner. All the register values are displayed in hexadecimal format. The hex to decimal conversion box, which is very useful in such applications, is in this pane. Personally, I feel that the implementation ought to have been a bit different. To convert from decimal to hex, or vice-versa, you need to type in the number and click the correct button to make the conversion. I would have liked it if it automatically converted as the input box value change; this would make things much faster and more convenient. Then the I/O Ports space is displayed as a spin-box. The spin-box index is the port number, and the text box beside it shows the contents of this I/O port. Similarly, the Memory space is shown with another spin-box. Note that the values shown in both are all in decimal. The default input for these is in decimal, but to enter a value in hex, you add an ‘h’ after it; if the number starts with a letter of the alphabet, you need to add a zero before it. For example, AB is entered as ‘0abh’. On the right-hand side, there are three tabs. The Data tab shows the data variables you have defined with the assembler EQU pseudo op-code (discussed later). The next tab shows the stack state. After you initialize the stack pointer (SP) and execute PUSH, CALL or other stack-manipulation instructions, this tab will show the address and value of the entire stack, along with the associated pushed register pair or program label (for call). This is especially helpful when you’re debugging code with many nested subroutines, or using stack-manipulation instructions like XTHL. When pushing the contents of the PSW register (Accumulator and Flags), the Register name under the “Proc/Reg” field is incorrect, although the performed operations have no problem. This is a really helpful tool for debugging.

Instruction Keypad
Instruction Keypad

The third tab contains a virtual keypad, consisting of keys corresponding to each instruction. It looks good, but I do not think this is a feature that will get used a lot. It is much easier and simpler to type in mnemonics, than to click buttons to code. In the text box on the top labelled “Load me at”, you can enter an address location, and make the assembled code load, starting at that memory location. The default input is decimal; to enter hex, use the same rules as before. An empty or invalid address means the program will be loaded at 4200h by default. The ‘Assembler’ menu has three items. The first, ‘Assemble (F8)’, is used to assemble the program and load it into memory (at the load address). There is no practical use of only assembling the code in the current version, as you cannot generate an output assembled binary file that you could burn into the memory interfaced with 8085. The next, ‘Execute (F9)’, would execute the compiled program. The following entry is ‘Show Listing (Ctrl + L)’, which shows you the assembled machine code, along with the memory address op-codes, mnemonics and comments. This window is especially useful when you have successfully run a program in the simulator, and are ready to run it on the actual 8085; you simply need to enter the proper load location, and then either display the listing, or save it into a file and print it out, before entering it into the actual machine. This saves you from the hassles of hand assembly.

From version 1.3.7 two more tabs are added which allow grid editing of memory and I/O port data.

Simulator Screenshot Step Executing
Simulator Screenshot Step Executing

The ‘Debug’ menu has the ‘Step in (F5)’, ‘Step Over(F6)’ and ‘Step Out(F7)’ options, along with the program breakpoint management. These features are very helpful for debugging code by inspecting the register and memory contents at each step, or at breakpoints. From the ‘Reset’ menu, you can reset the state of registers, I/O ports, flags and memory, individually or all at once. It is useful when you want to remove old data from the simulator without writing extra 8085 code. The toolbar is concise and clutter-free. It contains the normal save, load and new icons, apart from execution and debug short-cut buttons. The icon of the big red cross is to stop (terminate) execution when you are stepping through code, or in between. At the bottom of the window is the assembler error message output panel, where you see any errors, with the line number and a brief description of the error. Clicking the error message highlights the line with the error.

Assembler

This simulator comes with an assembler: you write the code in Intel 8085 mnemonics, and it is converted to machine code by the assembler, freeing you from the pain of hand assembly. The assembler supports four types of syntax parts:

  • The assembler Intel 8085 mnemonics: The instruction strings as in the manuals.
  • Labels: A named point in the code, the target for JMP or CALL instructions.
  • Comments: Anything on a line after a semicolon ‘;’ is ignored by the assembler, and used to write comments explaining the code.
  • Pseudo op-codes: Are not actual op-codes, but instructions to the assembler that provide some features to ease the coding process.

Instead of repeating the assembler features of the simulator here, I recommend you read the official site, where every detail is documented: http://gnusim8085.org/doc/asm-guide.html. From version 1.3.7, this assembler tutorial is included with the software, available at Help -> Assembler Tutorial.

After using this software for quite a long time, I have found some positive and negative points about it, which I will discuss below.

The highs

  • Has a detection mechanism for when your code goes wild. For example, if you forget to place a HLT to stop processing, the simulator will automatically stop program execution and warn you about this.
  • If you do more POP operations than PUSH, the simulator stops execution and tells you to check the logic. Although there is no warning on the real 8085 (it cannot-it would simply take the contents of SP as the top of the stack), this is very helpful, because such unbalanced stack operations are hard to detect in a large program.
  • The stack view and tracing is a good feature and is really helpful for debugging code with many subroutines and a lot of PUSH, POP and other stack-related instructions.
  • Like most simulators, this has a very good and easy-toread register and flag views, which helps in programming.
  • It provides an assembler and lets you enter the program in Intel 8085 mnemonics instead of hand assembly as on the real 8085 (when programmed manually).
  • Has debugging features.
  • Has assembler listing with address location, op-codes, mnemonics and comments — all as a single list. This listing can be followed when entering the code manually on the real 8085, and also keep the mnemonics of the opcodes at hand. Good for documentation.
  • The editor has good highlighting, which makes the code easier to read.
  • Most importantly, it has a very simple and clutter-free interface.

The lows

Here are some points that I felt needed improvement:

  • The label line needs to be assigned at least a line of code. For example, if you do something like the following:
      mvi c, 0ah
      mvi b, 05h
      xra a
    loop:
      add b
      dcr c
      jnz loop
    

    The above code would not assemble, as the line with the label ‘loop’ does not have any code. Either you have to move the ADD B to the ‘loop:’ label line, or simply include a NOP beside the label ‘loop’.

  • The memory and I/O contents are displayed in decimal, which causes a lot of confusion as the registers’ displays are in hex. Thus, each time, you need to convert the values and check the output. Also, because of this difference, if you are working with code that manipulates a good amount of data from memory, it becomes even more difficult to trace, as each time you need to pay attention to the base of the number you are looking at.
  • Representation of the I/O, and the memory editing with the spin-box makes memory data entry and inspection very slow. For example, if you enter some data manually in memory, then you need to: click on the text box, enter data, click Update… and continue like this. I would recommend that memory and I/O should be editable with the mouse and also with easy keyboard short-cuts. For example, a grid display with scroll-bars showing 10-20 memory locations, navigable with the keyboard, would be extremely helpful.

    A grid view is available from version 1.3.7 from the right hand side pane. This really helps viewing the data and editing it.

  • The editor has only one tab-so if you open another file when one file is already open, the new replaces the old. An MDI feature would be great, but as it is, this is not much trouble, in my opinion.

Bugs

While using and testing the 8085, I have found some potential problems, bugs and glitches in the simulator, which are listed here.

  • The PUSH PSW shows an invalid string for the register name in the Stack debugging tab.
  • There is a bug related to opening and closing files. When you are working with one file and then open another, the editor displays the new file-but what is not obvious is that the old file (which you were working on) is not closed. This is not much trouble, since the limit for the maximum open files is quite large by default (run ulimit -n), but this should be fixed. You can check it by first launching the program, and then keeping an eye on the output of
    watch ls -l / proc/$(pidof gnusim8085)/fd
    
  • There is a severe problem with the simulator if you accidentally or intentionally put your code in an infinite loop-the simulator freezes, looping forever, and there is no way you can stop it except by killing it. The interface does not work in such a case. Running the interface and the execution module in separate threads would help, I guess.
  • A minor glitch detected while boundary testing is that if you attempt to enter a negative program-load address, or an address greater than ffffh or 65535 in decimal, the simulator does not complain, but automatically detects an invalid range and loads the assembled code at the default loading address, 4200h. But consider this scenario: you load code at fff0h, and the length of your code is more than 15 (which will try to go beyond the ffffh memory limit). With this, if you assemble/ run the code, the simulator immediately crashes. This should wrap around memory and continue to be loaded and executed from 0000h after reaching the limit ffffh, like in the real machine, or simply notify the user about this and stop.
  • Although this is a minor bug, I think it is worth pointing it out: if you enter an invalid decimal value in the decimal text box, the hexadecimal conversion shows an invalid value in the hexadecimal box. I think giving some warning of an invalid input would help users.

Version 1.3.7 vs 1.3.5

Version 1.3.7 came out recently, almost one year after the last one. On the official website, the 1.3.7 Windows binary (with and without GTK runtime) and the 1.3.7 source code is available. There are not many externally visible differences in these two versions, but some nasty bugs were killed. Version 1.3.6 was released in March 2010, but did not fix the real bugs in 1.3.5 – like in 1.3.5, clicking Help->About would crash the program immediately. If you changed source code in an open file and clicked new, loaded another file, or simply closed it, there was no prompt to save the document. These were fixed in 1.3.7. The really nasty DAA bug was killed in 1.3.7, for which reason you should avoid using 1.3.5. In 1.3.5, if you ran DAA after adding 99h and 01h, the accumulator ought to have contained 00h, and the carry flag should have been set, but though the accumulator was 00h, the carry flag would not get set. Try adding 59h and 45h and then apply DAA. The result would be in an invalid BCD form. Thankfully, this nasty bug was killed in 1.3.7. I would like to make you aware that there are a lot of simulators that have implemented DAA incorrectly, so please confirm DAA operation with the above or a similar operation as operating in boundary conditions, or with the real machine output. Some other bugs have been fixed as well, so I recommend you download the latest version 1.3.7 if it is available from your distro repository, or if not, install from source. Have a look at the version release notes: https://launchpad.net/gnusim8085/+announcement/7810.

Still to implement

  • The RST instructions (a 1-byte call instruction, jumping to a pre-determined jump location).
  • RIM and SIM instructions-you would not be able to test any interrupt or serial I/O-related code. You would notice the ‘Int-reg’ register in the simulator interface, which apparently represents the interrupt register that holds the masks, the pending interrupts, etc. This is non-functional.
  • There are problems when printing on Windows, and the Linux environment implementation is very primitive.
  • If you look at the op-codes, you will notice that there are 10 unused ones that have no mnemonics associated. These are undocumented instructions. They are not documented because they are not supported by 8086 and higher processors. These instructions and the related undocumented flags are not supported by the simulator. This will not bother many people, since, being ‘undocumented’, they are not generally used. Implementation of these is not that urgent, but the availability of the undocumented instructions would definitely make this simulator special and draw attention as these instructions can make some composite operation with a single instruction.

What you need to remember…

This is essentially a very good simulator to work with for educational purposes. If you have to practice code for your college exam, or to test the code in the practical copies, then I would recommend this simulator. Some of my friends and I have used it during our undergraduate course, and had no problems. It has a very simple and clutter-free interface, an assembler, and the best part is that being under GPL 3 GPL2 or later license, you can see the code and even edit it if you like-or request any feature update from the developers. Programming in the simulator is easy, but it should be kept in mind that if you are doing a course, you need to handassemble and enter the code when presented with the actual 8085 in your college syllabus. It is good to make a habit of hand-assembling and directly entering code on the actual machine, to keep in touch.

References

  1. Official Site: http://gnusim8085.org/index.php
  2. 8085 Wiki: http://en.wikipedia.org/wiki/Intel_8085
  3. GNUSim8085 Wiki: http://en.wikipedia.org/wiki/ GNUSim8085
  4. GNUSim8085 Announcements: https://launchpad.net/ gnusim8085/+announcements
  5. ‘Microprocessor Architecture, Programming, and Applications with the 8085’ by Ramesh Gaonkar


First Publish Information
: This article was first published on Linux For You
(LFY), August 2011 Issue, under Creative Commons Licence.



Click Here To Read The Printed Edition in LinuxForU.com

Author: Arjun Pakrashi

4 thoughts on “Reviewing the GNUSim8085 (v1.3.7)

  1. I am one of the maintainers of this application. I work mainly on UI side. So I want to thank you for taking time to write so comprehensive review. And I am glad that I have managed to keep the UI as string point of this application.

    There are two issues in your review.
    1. The screenshot you have used are not from 1.3.7 version. And I am not sure if you actually used 1.3.7 while writing the review. Because the grid display for memory/IO contents is already available in 1.3.7 version. [1]
    2. The license is not GPL3. It is GPL2 or later.

    Over last few years I (as primary UI maintainer) have deliberately avoided implementing some things in UI. Because I do not want to turn the simulator into IDE for 8085 assembly language. As it is my hands are full with all the bugs and enhancement requests. Hence there is no MDI interface, no configuration management and the printing implementation is very basic.
    You have mentioned other good points from usability point of view. I will try to file bugs for them and get them fixed soon.

    [1] http://www.gnusim8085.org/screenshots.php

    1. I am aware that the screen shots are not of 1.3.7 and actually from an older version. This is because i first used an older version and took screen shots and later downloaded and installed the 1.3.7 and then tested it for the changes (mainly the bugs i discovered in the older ones), but did not take new screenshots to update, as i saw no significant change. The actual publication in LFY did not have any screenshots, and i put on some old screenshots in the web version. I definitely forgot to include the grid view update, and sorry for that, as i mostly concentrated on the backend features, because except some minor factors (mentioned) the UI is very good. I have reviewed the 1.3.7 because have tested the nasty bugs which were present in the older versions, which were removed in the 1.3.7 version (especially the DAA bug). Thanks for pointing out the grid view matter, i will soon update the screenshots to avoid confusions.

      The motivation behind this review is that, in my opinion this is the only educational purpose 8085 simulator under GPL out there which is usable and good, and there no food reviews available about this software. Therefore i tried to write a comprehensive review highlighting both the positive and negative points and review unbiased. I have downloaded and used a lot of other simulators which i had to scrap as they were too flashy or were simply unusable.

      As you handle the UI, i must say one thing. In most of the cases these simulators are used for educational purposes. In university course students are presented with 8085 simulator kits with a 4×4 interface keyboard and a 6 digit 7 segment display. Writing code in a simulator has the benefits of the simulators as i have discussed in the first paragraph, but in educational purpose hand assembly and insertion has to be done in the kits, which i feel needs some practice.
      Therefore if the simulator had an interface which mimics the address – data display only, of the 8085 kits where one has to enter the pre-assembled code, then it would be very helpful. My proposed mode is something like this:

      Only address and the data in the stored address are displayed in a line, optionally register displays, and IO address and data (like the memory address and data). Pressing enter or up will increment the address index, and down or backspace decrease the address index, and page up and page down to skip 16 bytes at once address. Pressing hex number symbols enters the value in the currently selected address/IO, and Tab to toggle between IO and memory space. ‘x’ or F7 to execute and some other key to step execute.

      This keyboard only interface is immensely useful and lightning fast when entering pre-assembled data, and keeps up the habit of hand assembly and entry. I have made a prototype and found that the interface is indeed useful. Therefore in later versions the GNUSim8085 team might like to consider such an interface.

      I would like to thank you for dropping by in this blog, it is really excellent to see one of the developer from the GNUSim8085 stopping by.

Leave a comment