0

I'm an undergraduate and an iOS app developer. We are being taught about 8085 microprocessor at my college and I thought it would be cool and useful for me to develop an iOS simulator for the same

I want to know how I can start the app from scratch and what all I need to know about it. I'm a fast learner and I can learn and develop simultaneously. Any great advice is sincerely appreciated. Thanks.

Viki
  • 421
  • 1
  • 4
  • 12

3 Answers3

1

You can build a interpreter, programming the 8085 ISA in your iOS program, if you want to code in high level languages, you have an additional work to "compile" to the assembly of the processor and then, interpreting it.

I should strongly warn you about the IMENSE amount of work you will have, and in my opinion this will not be an practical project.

Ulysses
  • 2,281
  • 1
  • 16
  • 24
  • What do you mean by "compile to the assembly of the processor"? – Viki Feb 06 '16 at 17:32
  • If you want to write an program in C, you must first translate that code to the assembly of the microprocessor, that process is called compile :P – Ulysses Feb 06 '16 at 18:29
  • @UlyssesR:Yep you are right. It will take long to develop it. But my implementation (UI) helped me in understanding Auto layout & constraints. –  Apr 28 '16 at 17:04
  • @Ulysses the 8085 supports self modifying code. A static compiler will to my understanding not support that and an interpreter is the only option (unless you go into a full blown recompiling jit like the JVM) – Thorbjørn Ravn Andersen May 05 '23 at 13:09
1

It depends at what level of abstraction you want to simulate the 8085. Pedantically, the real chip is a 40-pin IC, so that's 40 signal lines that permutate through a defined set of transitions based on their historic states.

More usefully, you probably want either to simulate at the digital bus level, which usually means just knowing what the chip is attempting to do during each bus cycle (read from here, write to there, etc), or simply to interpret an 8085 instruction stream so as to react to each as the execution unit in a real chip might.

If the latter then the total body of code won't be so problematic — an array of bytes for the program, grab the next one the program counter says to fetch, use a switch statement to decide what to do to process it, perform the action. I've a Z80 (which is closely related to the 8085) emulator embedded within a CP/M emulator (so, just getting the instruction stream correct is enough) and that's a few hundred lines, heavily oriented around being as non-repetitive as possible, speed be damned.

Even if the former, it shouldn't be so bad. In the past I've written a Z80 emulator that had as input and output only a 64-bit integer representing a digital version of current bus state. It had a broad structure similar to the previous but necessarily involved queuing up future transitions and making additional mid-instruction decisions. If you care only about correctness and simplicity for now, you might just keep an NSArray of GCD blocks, representing what the CPU should do upon each clock transition or during each cycle.

Probably the smartest middle ground is to have the output stream from the CPU be in terms of machine cycles. They decompose exactly to bus states if you want to but also allow a much higher-level interpretation.


EDIT: In its Objective-C form, thereby making it quite a bit less compact but hopefully easiest for the poster to follow, this is the Z80 emulator in instruction-accurate form.

It postdates and adapts a much simpler C-format version that was merely a disassembler (with hindsight: writing a disassembler first is probably a good step). That project does however contain the full half-cycle accurate Z80 simulation. However I ended up deciding that I don't like that design — making a C function call, especially by function pointer, every half a cycle is overly expensive and welding that low of a level of communications directly to the emulated execution unit is probably overkill; anything that exactly describes the same process but does so in a more implicit form is acceptable.

It's a 6502 emulator instead but this is my (C++) attempt to digest those lessons learnt; it's machine-cycle-by-machine-cycle (though machine cycles are exactly one clock cycle long on the 6502, as it happens — unless you assert the ready line, it loads or stores every single cycle whether it needs to or not) and schedules its work based on an internal list of micro-ops. It all ends up in the header because I decided the best way to integrate a simulated execution unit with an arbitrary bus was to provide it as a template. If I wanted exactly quarter-cycle bus reports like the Z80 code previously linked then I'd just use the template to create somebody that serialises each machine cycle into the appropriate bus states.

(... though if you're just talking emulation then even interruptable-at-any-cycle cycle accuracy doesn't necessarily imply the serialisation into smaller steps that I'm now a fan of — this 6502 emulation I wrote about 15 years ago instead just jumps onto a separate thread and blocks via semaphore at any permitted interruption point, which are placed upon the conclusion of every cycle)

Tommy
  • 99,986
  • 12
  • 185
  • 204
0

Check the 8085 Simulator Sim8085 for iPhone and iPad for iOS 8.0 and above on App store now. Working with this app will have almost same feel as working with 8085 trainer kit. You can check the assembler and disassembler functionalities also. As an added feature, the enthusiast tab to practice logical operations that are available on 8085 microprocessor. For how to use instructions visit this link.

  • @Viki: As mentioned in the other answer, lot of time & work will there. For me it was a sample app to learn Auto layout and some other iOS features well. –  Apr 28 '16 at 16:46