By the end of module 2, we had a microprocessor skeleton that was able to execute more than 80% of the instructions set. That's the good news. The bad news is that those instructions do not let our IP even perform like a microprocessor. We have more of a programmable logic controller (PLC) at best. There are some missing functions that differentiate a processor from other sequential logic devices. We also added a lot of instructions without performing any verification of the results.
We have just added 800 lines of code and 123 instructions since the last simulation. Does it look alright to you? At some point we must plug it into a real system and see if it actually performs. What happens if it fails? How can we track the errors to places in our code? Believe me, I once had to track a failure in a 68060 system that occurred 80 milliseconds after boot using nothing but a logic analyzer and an emulator pod. The more errors you can remove during development the better. Warning however, you still might spend so many hours in front of a logic analyzer that you can read the microprocessor instructions from a hex display of the instruction fetch.
Simulation offers a way to remove most of your errors prior to plugging your IP in for the first time. Simulation in large projects is usually performed on an iterative basis, using different methods to ensure a good chance of the overall project working the first time. We will discuss the different methods and explain when and how they are best used.
So what makes a processor so different from other sequential logic devices? I would argue that there are two primary functions that set the processor apart:
A processor has the ability to make decisions.
A processor has the ability to react to events.
We must note here that when we refer to events, the events can be either external or internal. The reason for this will become clear once you complete the module.
There is another ability that a processor has, that it shares with most microcontrollers and programmable logic controllers. That is the ability to perform a sequence of instructions outside of the current sequence, and return to the point of origin. This ability is variously referred to as procedure calls or subroutines. This ability is critical to the ability to react to events, and needed for efficient memory utilization.
Lesson 1 begins with a detailed discussion of the various simulation methodologies, Cyclic Redundancy Checks (CRC) and how to generate them, RAM coding, and integer functions. We then proceed to simulate the code we developed in Module 2, Lesson 6 and learn how to use our simulation to track down and correct errors. By the end of lesson 1 we will have a tested project skeleton containing the instructions that we have already coded. In lesson 2 we learn about the microprocessor ability to perform a sequence of instructions outside of the current sequence and return to the point of origin. Of course, we fill in the HLPC and XTHL instruction coding from Module 2, Lesson 6 exercise. Finally, we go on to complete the 8085 decision making instructions. Lesson 3 deals with the interrupt block and the ability to react to events. The DAA instruction is discussed in detail in lesson 4, particularly the changes necessary to support decimal adjust for subtract and 'TRUE SIGN' logic. This lesson completes the coding for the S8085A, S8085B, and S8085C versions. Various methods of multiplication are discussed in lesson 5 and the multiply block is encoded. Division is the topic of lesson 6, and the S8085D coding is completed in this lesson.