clbx / cosmic Goto Github PK

Find a way to reduce the amount of deeply nested logic in envmain

Adding a serial in and out will give standard I/O that was found on machines of the era and also makes it easier to have a "terminal" environment.

Currently building for Windows requires MinGW installed and a few extra libraries. Building with msvc would relieve these issues

Finding a way to successfully build statically would also solve this issue.

Implementing Cycles would make the project more realistic, would add a small amount of complexity

Fix the output message

Interrupts are currently "added" to the processor, but have not been tested. Interrupts need to also implemented to the assembler

Implementation on the Pi will not be possible in the current state due to the lack of OpenGL hardware support. Two options are available, using OpenGLES for the Pi build, or implementing ImTui, a text based ncurses implementation of ImGui

Get operand takes a token and separates it into its addressing mode, operator, and operant. On the last line of this it takes the operand given ( a string) and converts it to a base 16 number.

This issue occurs because of this in the resolveVariable function

This effectively converts the numbers to base 16 twice, making the addresses variables point to incorrect.

The current way of putting in the file path sucks

The first line loads in right, but after that I have no idea what it's doing.

Create CLI to run over SSH on Pi

Either using curses or ImTui

Video out window is empty on Linux confirmed on x86 needs testing on ARM

Awesome project gentlemen. Any chance you can update the source, so it compiles properly on BigSur and higher?

Right now whenever a hotkey for running the processor (Space for stepping, r for reset proc, m for reset memory) it doesn't matter what window is active

this isn't a problem right now but once we have other things that will need input it will become an issue.

Add testing of full programs to make sure that all systems are working correctly. Then add to Travis. We should make a few ROMs that test specific parts of the system and have It run on every build and compare the memory states to verify that they are working correctly.

Don't really have a reason as to why they haven't been defined yet. Will get to it eventually.

Related to #21
If pushing PSW to stack is implemented, a new RETI function will need to be added to make sure PSW is returned.

Investigate to make sure these aren't anything we need to worry about.

In addition to using a Raspberry Pi, using an Arduino could also be a good way to interact with the real world. Implementation would be limited due to the Arduino's limited resources.

Add memory mapped I/O for the raspberry pi.

Tests are rapidly approaching god class status. Find a good way to split them up.

Did some testing, doesn't seem to be linked to the ctrl+c to clear debug log, but this shortcut should be changed anyway because the debug log gets wrecked anytime you copy while working in the assembler.

Possibly only a problem with bigger files as Clay mentioned it might be that a buffer is too small.

Need to implement compare. this is just so I remember cause im going to bed

Write programs that thoroughly test each of the opcodes.

Implement a way to be automatically tested either through an existing testing library or short script.

Currently debug messages write to stdout, which is bad. Needs to be redirected to another place, preferably a panel in the GUI.

Currently 16 bit MOV just writes to the register +1 so if 2 is given, it'll write to 2 and 3 instead of 3 and 4.

Not sure how we want to handle this or if it/ how it should be taken care of in the assembler

Push at minimum status register onto the stack when an interrupt it triggered. Decide if registers should be pushed too.

Currently the GUI holds all of the execution for the processor. Remove this dependency

• Create separate GUI and CLI classes
• Dont run processor from the GUI/CLI

Use submodules in the repository instead of having dependencies (like ImGUI) in the repository.

Just shows the same thing across all tabs and doing things on other tabs does not impact memory. Separate memory editor objects will be needed

Some Instructions when given R1 take from r[0], some take from r[1].

Example:
MOV R0 points to [0]
JMP R0 points to [1]

A proper way should be decided and made uniform

Allow keyboard input to be given through the video out window (probably should rename that too)

Keyboard functionality will use 2 bytes, one to give the character given to the keyboard allowing for 256 different characters, the other to use for status. The only current planned use of the status byte is to flag when a new character is added.

Having it on an FPGA would be dope and really add usefulness.

Create 3 labs for requirements for Senior Project