| | 1 | = '''Gnusim8085 Ideas''' = |
| | 2 | |
| | 3 | == '''Generic Simulation Infrastructure''' == |
| | 4 | |
| | 5 | '''Pre requisites:''' C, ASM, Gtk+ will be an added advantage [[br]] |
| | 6 | '''Level:''' Advanced |
| | 7 | |
| | 8 | Gnusim8085 will benefit from a more generic simulation infrastructure, that would eventually facilitate implementing backends for various different architectures/processor targets, i.e. the 8086, 8051 and possibly other related processors. This would increase the user base as well as be a very useful tool for students to learn an entire coursework on Controllers and also try out new concepts and programs. |
| | 9 | |
| | 10 | ---- |
| | 11 | |
| | 12 | == '''Assembler Enhancements''' == |
| | 13 | |
| | 14 | '''Pre-requisites:''' C, ASM, Gtk+ will be an added advantage [[br]] |
| | 15 | '''Level:''' Intermediate |
| | 16 | |
| | 17 | Error messages while assembling the code are currently not very useful or does not provide proper info so as to easily rectify the mistake. In this sense, assuming that it would be difficult to improve such things in the short run, it might make sense to provide a separate, more detailed, log that contains more information about the assembly process. So that each step of the assembler is interactively shown. |
| | 18 | |
| | 19 | Eg as below: |
| | 20 | |
| | 21 | - found comment, skipping to next line [[br]] |
| | 22 | - found supported mnemonic "mvi", (expecting reg,immediate): found reg,reg [[br]] |
| | 23 | - found unknown token "foo" |
| | 24 | |
| | 25 | [[br]] |
| | 26 | Something like this would at least have the potential to allow users to see clearly where the assembler stopped succeeding with assembling the file. Also, other 8085 assemblers often support direct ways to provide numbers using a different notation: |
| | 27 | |
| | 28 | mvi a,14h |
| | 29 | |
| | 30 | mvi a,14d |
| | 31 | |
| | 32 | mvi a,01110011b |
| | 33 | |
| | 34 | Also, the "db" directive usually also supports providing the corresponding bytes as quoted strings of characters: |
| | 35 | |
| | 36 | data: db 'hello world',0A,0D,'$' |
| | 37 | |
| | 38 | dat2\: db "foo" |
| | 39 | |
| | 40 | In its current form the assembler also isn't able to compute offsets for labels defined after the position of the current instruction: |
| | 41 | |
| | 42 | mvi a,5 |
| | 43 | |
| | 44 | start: nop |
| | 45 | |
| | 46 | cmp 5 |
| | 47 | |
| | 48 | jz exit ;ERROR: exit not known because no multipass support in assembler |
| | 49 | |
| | 50 | exit: |
| | 51 | |
| | 52 | ---- |
| | 53 | |
| | 54 | == '''Peripheral Interfacing via loadable plugins''' == |
| | 55 | |
| | 56 | '''Pre requisite:''' C, ASM, GTk+ experience an added advantage, Any kind of plugin development will also be helpful [[br]] |
| | 57 | '''Level:''' Intermediate |
| | 58 | |
| | 59 | The goal is to develop a generic way to model simple peripherals such as for example I/O hardware, i.e. by mapping a certain region of memory to a corresponding grid on screen to simulate an LCD or even simple VGA screen, something like this would preferably be pretty flexible and allow for different types of hardware to be modeled,possibly using a scripting language such as lua. This interface shall help Runtime loading of any plugin which needs to be tested. We believe this feature would greatly help students to test their code related to external devices also using the simulator. |
| | 60 | |
| | 61 | ---- |
| | 62 | |
| | 63 | == '''GUI Enhancements''' == |
| | 64 | |
| | 65 | '''Pre requisite:''' C, ASM, GTk+ experience an added advantage [[br]] |
| | 66 | '''Level''': Beginner |
| | 67 | |
| | 68 | - Implementation of a grid that shows memory address, io ports, and its values. [[br]] |
| | 69 | - The UI could benefit from some minor rearrangements to make it more intuitive and less cluttered. For example, for debugging/runtime purposes there could be one comprehensive tab that provides all relevant information at a glance. |
| | 70 | * registers & flags |
| | 71 | * memory |
| | 72 | * stack |
| | 73 | * I/O ports |
| | 74 | - Possiblility to customise font size [[br]] |
| | 75 | - Provide the option to switch to an opcode view of the assembled file by using a corresponding separate tab above the editor area, i.e. two tabs that allow the user to switch between source" and (annotated) "opcode" view, the latter of which probably should be set readonly by default. [[br]] |
| | 76 | - Likewise, it would be helpful if there were dedicated tabs for viewing/manipulation of memory & I/O ports. |
