BFE is an Emulator with an instruction set made for beginning OS developers and bare-metal programmers written in Java. It is very focussed and graphics, but also has a text buffer. It gets the Keyboard from the user using the GUI framework Swing that also handles the rendering of the frame and text buffer.
Today also a small update, I am working towards the end! I added some more privileged fields. The System control, Display Mode and overall Video Memory.
I also slightly changed the documentation to include the newest instruction. I might have written to the wrong file for that though (will fix that very soon).
And mostly I added new characters, those being all lowercase letters and the period. (See screenshot below)
I will add new arithmetic instructions because now you can’t actually add one variable to another. And I will handle some more security stuff!
Mostly unfinished work today. Firstly, I changed the halt instruction. It now halts the instructions until an interrupt is handled. If interrupts are disabled, the halted state will automatically be set to false after 10 million cycles (around 3.75 seconds) by the watchdog.
I also added a priviliged mode, but I only actually made a few instructions priviliged and no registers and such yet. For this all I added instructions 241 and 30. 241 allows a user to switch security modes (only if the program is executing within ROM, so no user programs can do this). 30 allows you to change the interval of the timer interrupt.
That’s it for today, I probably will be back tomorrow.
As for the screenshot, that’s just the output when I was testing the watchdog system.
A tiny addition today, I added three new instructions. One for manually raising interrupts, one for toggling interrupts and one for changing the IVT (Interrupt Vector Table).
The latter allows you to change the addresses for existing interrupts and add new interrupts up to 255. (When an undefined interrupt is raised, the PC will be set to the start of RAM)
Nothing today
I will probably fix the jump instruction because some things bug me about it.
The screenshot below shows terminal output. Most of the output is debug messages, but one important thing is the line ‘Handling interrupt! Type 4’. Type 4 is a custom interrupt!
I finally did it. Interrupts are now a thing.
There are, as of now, three interrupts. Timer, Keyboard and one without purpose.
Each interrupt is allocated 50 bytes of memory at the end of the program.
The standard locations in the Vector Table are 1850, 1900 and 1950.
An instruction with opcode 18 or 0x12 was added for a so called “State Return”. This instruction is mandatory at the end of an interrupt. It will set the PC back to the IRP (Interrupt Return Pointer) and and all the flags back to their saved state.
The screenshot below is a program that utilizes the Timer interrupt to create a simple fade-in animation.
As for changes, not a lot happened. Small tweaks in the Timer and Keyboard handlers to make them raise interrupts and of course additions to the CPU loop. Main was also slightly changed to make sure everything closes correctly on a System Control 0x01 call. (Shutdown)
Frankly, I do not have anything concrete planned. I am thinking of adding a few instructions for interrupts (Specifically Disable, Enable and Raise. For Syscalls in a possible OS maybe?) and overall expanding upon them where I can.
I added new IO registers. Display mode, Random number, System control and Timer. The screenshot shows where all of these are found in memory.
The timer takes up four bytes, the rest all one.
The Display mode register is a read-write register that stores one byte to determine the display mode. 0 for text, 1 for video. The panel updates to this every CPU cycle internally.
The random number register simply returns a random byte. It is read-only.
The System control register is a write-only register that doesn’t actually save a value. If you write 1 to it, the system will shut down. If you write 2, the system will reboot. If you write any other value the system will continue operation.
And finally the Timer register. The Timer is a read-only register that stores the uptime of the system as four bytes. It stores this is in milliseconds.
I changed the way the keyboard register stores the last key. Instead of a single byte, it is now a buffer. The status is 0 if the buffer is empty. The buffer has FIFO structure.
Next I want to make a system for interrupts. This way the operating system or any other program running on the emulator can catch certain events such as Timer updates (With programmable interval, preferably), Keystrokes and maybe even more in the future, we’ll see!
I created IO registers for the Keyboard, with one address for the status and one for the key.
The keys being pressed are detected by swing.
Using this system I created a very simple program to render the last key pressed in the first cell of the text buffer.
I changed the handling of the load_reg_mem instruction to only read the first byte if it would otherwise read out-of-bounds.
I changed glyph renderer to support more characters
I added a glyph for the comma
The keyboard program:
0D 00 00 00 13 44 06 00 00 00 00 00 07 00 0D 01 00 00 13 45 0E 00 00 0B CD 01 05 00
I created a renderer for the Text buffer. I created a simple image format called BImg (BFE Image) and with that I made images of 5 * 8 for (currently only uppercase) letters. Currently all characters are true cyan (#00FFFF)
In the machine code, text can only be inputted by writing to the buffer (addresses 3024 to 4932). There are 36 lines of 53 characters.
There is one pixel of padding on the right and bottom side of the glyphs. The padding is also coloured (#000101).
All letter images are saved as .bin files in the resources folder in the jar.
I created a renderer for the framebuffer. It simply loops over the framebuffer and renders the corresponding pixel using Swing. This allows me to write programs in machine code to make patterns like the one posted below.
I had to do some improvements before being able to do this however. I added a new instruction to load to a pointer stored in a register. The entire bytecode for the program used below is:
02 00 00 00 00 00 02 01 00 00 07 D0 03 00 03 11 01 7F 03 01 03 06 00 00 00 0B D0 08 0C
I added a system to handle file input and using that I verified if all instruction handlers worked. They did not.
I fixed a lot of bugs in instruction handling. The one I thought was most obvious was that, when a conditional jump didn’t jump because the condition wasn’t met, the PC wasn’t changed. This resulted in the program looping infinitely.
I finished at least a basic version of the CPU.
It handles 17 different instructions.
I will admit I spent a good 80% of the time logged fixing this one bug where the Program Counter (PC) kept jumping to 24 even when it shouldn’t even be able to get under 1000. It turned out I needed to use “->” in my switch instead of “:”.
The CPU itself currently does not do much, it reads a bit, checks what opcode it is, calls the handler for it and passes the PC until the PC reaches another segment of memory. It should now be able to handle all instructions, I will test it some more and then start working on actually parsing instructions from a file so we can have file input instead of hardcoding programs.
I started working on the “CPU” to parse the opcodes, I made most of the initial instruction set but then noticed a lot of mistakes.
Firstly, there were no pointers at all, so you couldn’t actually access memory and registers. I added some new instructions for that but realized once again things need changing.
The registers need to become 32-bit so I can use them to store pointers (since that is pretty much their primary use). I’m going to change the load_reg instruction to fetch the next four bytes instead of just one.
I need to make a lot of other things 32-bit as well to match the address space. I did so for the load_mem instruction, but for example all of the jump instructions still need changing. I might write a helper function for big-endian (both ways).
The most significant change today was the changed instruction set and the addition of the parser within the CPU. Of that there is a screenshot below.
After pondering for a bit I completely revamped the memory layout. It’s more clear now and I segregated everything adding a Bus class for universal access. I updated most of the instruction handlers, but not everything is updated yet.
In the meantime I started working on a simple CLI help menu, I added some info about the memory for example. As seen in the screenshot below.
I added a basic instruction set and added handlers for all the instructions
I made an ‘init()’ function to initialize basic memory and registers and designed some of the memory layout.
