Look up the age of the 8085. It dates from the era when every part of a circuit was hand optimised, and hand layout with tape and razor blade was still common (though likely Intel was using CAD systems). So it would have been designed to aggressively minimize the number of gates used. And as Tom says, you can add and subtract using the same circuit with a little care - so I think that gives you your answer.
From GBulmer's comment:
Can you see a way to produce multiple results (for example add and
subtract) simultaneously, and select the correct answer with the fewer
gates (or transistors) than logic producing only one result?
Personally, I can't. If you produce both answers, you need additional logic in the form of multiplexers to select the one you want.
Now I'm not going to run the experiment, but I suspect that if you write an ALU in VHDL, which follows this approach, a modern synthesis tool will spend a very long time (several seconds) and optimise it down to something close to the hand-optimised version.
To test this hypothesis, generate A+B, A-B, and a 2:1 multiplexer as separate modules, synthesise them separately and note resources. Then roll them up into a single design and re-run synthesis (you may need to enable optimisations, "optimise for area" and "flatten hierarchy"). The latter will be smaller : how close it is to a hand-minimised version I don't know : the challenge is set if anyone wants to add another answer!
A microprocessor trainer is a big (and worthwhile) project, try to subdivide it into several smaller milestones. Trying to debug one massive project where nothing has ever yet worked, during the final week, is to be avoided... Consider the interfaces between the various parts and plan how to approach integration testing / debug. Since you have a fixed amount of time available to work on the project, it's important to prioritize what to do. If everything goes well then you can reach for a larger scope, but if there are problems then the scope of the project can be reduced to be still useful and deliver on-time.
I'd suggest dividing the project into steps something like this:
- System power supply
- 8085 clock, reset; verify instruction fetch is incrementing address pointer (no firmware yet)
- Compile 8085 object code from PC
- 8085 running simple firmware test toggle I/O (blink LED)
- memory test -- check for address lines short or open
- I/O input from buttons
- I/O drive HD44780 LCD
- (optional) 8085 interface with PIC18 hosted I/O
- (optional) 8085 interface to RS232 (FT232 USB cable?)
- (optional) 8085 running self-hosted monitor firmware
- (optional) PIC18 better I/O panel interface, touchscreen?
- (optional) load and save 8085 memory to host PC
It is possible to build the entire 8085 trainer running with just the 8085 itself, without any other micro -- this is how the original 8085 trainers were designed. The I/O can be as simple as a small keypad matrix and some 7-segment LED displays or HD44780 alphanumeric LCD display. (The HD44780 will give longer battery life than 7-segment LEDs, and more versatile.)
Given that you have PIC18 available and are more comfortable coding PIC18 than 8085, there could be an advantage to your proposed hybrid trainer. Use the PIC18 to manage the I/O, and use the 8085 to run the user code. This is an attractive option because you're more likely to find device driver support for the PIC18 than the 8085. However it does require that you set up an 8085 toolchain (at least an assembler) as well as your PIC18 toolchain. The good news is 8085 is old enough that whatever compilers or code you find is most likely free, but the bad news is it's also most likely no longer well supported.
I do have to ask -- what if instead of an 8085 trainer, you instead build a PIC18 trainer? If the goal is to help the student learn assembly language, PIC is probably more relevant. And unlike the 8080/8085/Z80 architecture, PIC is scaleable. However 8085 is still a good introduction to the more modern PC CPUs, since a lot of the 80x86 weirdness (like segmented addressing) comes from stretching the 8080 beyond its original architectural limits.
The intel 8255 is the standard I/O chip that was used with 8080/8085 systems, but emulating 8255-style I/O is straightforward.
The intel 8253/8254 is the standard programmable timer that was used with 8080/8085 systems. Again, this could be emulated on the PIC.
A feature you didn't mention, would be an RS232 (serial port) interface to a terminal. That would be useful for running an 8085 self-hosted monitor, so the user can read and write 8085 registers on the 8085, and single-step through their code. I'm not sure if this is essential, it's kind of a different direction that you were planning to go, but something to consider. You would need to provide routines for character input and character output. That could use either an RS232 port or use on-board HD44780 and buttons.
For 8085 self-hosted monitor, you might look into glitchworks 8080 monitor for firmware to run on your trainer board. 8080 code will run on 8085.
The ancient BDS C compiler has been released as open-source as of 2002. I think that includes an assembler as well as the so-called "brain dead" C compiler... this was before the K&R C was standardized, but could still be a useful resource.
The more modern SDCC Small Devices C Compiler supports Zilog Z80, which is a superset of 8080. It's unclear to me whether SDCC really supports 8080 / 8085 however. The main focus of SDCC is on the 8051 microcontroller family, though it does support a few others.
About powering the system from 9V battery - 8085 only requires a single 5V supply (unlike the 8080), so this could work. A switch-mode power supply would give longer runtime than a 7805 linear regulator, since the 7805 has to discard 4V x load current, efficiency will be 55%. The thing about SMPS is they are very sensitive to layout and component selection, so start with an evaluation module like the TI.com simple switcher Say VinMin 7V, VinMax 14V, Vout 5V, Iout 1A for examle; TI.com website supports several designs.
This is a pretty big project for a college senior design project for a team of one person, but I think it's achievable.
Best Answer
You must study binary arithmetic. Sign flag is not enough to identify the result of the signed addition. There should be another flag called overflow which will identify if resulting value is correct or not.
8085 does not have overflow bit, unlike Z80's P/V bit, and you will not be able to identify correctness of the result using S flag only. It will be your task of programmer to ensure the overflow condition either by:
examining signs of input data. In your example, both are positive, but output is negative meaning there's an overflow. In general, values of differing signs will never trigger overflow; if signs of operands are the same, but result's sign is different, the result has overflown.
expanding size of the values to hold overflow bit. For this, in case of 8-bit registers, you may only have 6 significant bits, with two MSBs being sign [7] and overflow [6] respectively. If, after operation, these bits differ, it means overflow condition.
Your example extended to 9 bits
44h is positive 7-bit value, 43h is positive 7-bit value; result is having its sign and overflow bits set differently, 0 and 1, and it is overflow condition. Another example -
with carry discarded we see that sign and overflow bits are the same, thus result is correct, and in decimal it is -32 + 114 = 82.