Big Update :)

(sorry for not doing much the past weeks had to get 4th place at the botball competition real quick)

Changelog

• Implemented heap allocator (partially and broken)
• Implement PIC (Programmable Interrupt Controller) Init + get basic IRQ stuff working
• Fix GDT (was missing a few entries)
• Fix TSS (IST1-4 interrupt stacks were missing)
• Implement interrupts for vectors #0 through #31
• Update Panic for most interrupts to give way more details (example: pagefault in attached image)
• Replace Mutex with IrqMutex for text writing and holding CHAINED_PICS

Current State

I’ve noticed that my so far work has been kinda sloppy, so I’m currently working on improving everything (as u can see on the changelist above ive already started). I’m doing this because when I started with IRQs, stuff started breaking a lot. My goal is to get everything thread-safe and ready in a way that it’ll work in later stages of the kernel too.

Next up?

Next, I’ll be working on fixing logging (add a ringbuffer to prevent interrupts creating half-printed or partially drawn logs)

Partial Live CPU Data working! :)

I’ve managed to get the live CPU stats (usage, per-core usage and (approx.) clock speed) and the CPU usage graph running.

One problem with the current approach for measuring values (which is done using OSHI) is that on Windows, things like CPU temperature, CPU clock speed and others are not reliable.

Why?

On Windows, metrics like CPU temperature are read over WMI. However, the actual CPU temp is often only partially or not at all correctly exposed via WMI. CPU clock is often a stale/cached value or sometimes not at all given.
 
This requires an external source of data which is both correct and more reliable.

Technical Architecture of HwManager and live stats/graphs

The hardware manager is a class that can provide all sensor data necessary. It abstracts OSHI and any future methods of aquiring data into one class (with instances of other classes such as Cpu).
It has its own thread which calls the pollValues method of all subclasses (Cpu, …) which then update their internal values, which can be retrieved via getter functions.

The Window class has an internal timer which calls the update method of TopPanel, MiddlePanel and BottomPanel, which then call each component panel’s update method which then update their stats and graphs.

Fan Panel and Disks Panel done!

After once again a little time away from this project, I finally finished the fan panel and the disks panel! :)

Fan Panel

The fan panel has a 2x3 grid which expands in columns if more than 6 fans are present (which also expands the width of the panel). Each fan is just a Stat instance.

Disks Panel

Each Disk is given params such as name, type (NVMe, SATA SSD/HDD, …), usage percentage and read/write rates. Then, the Disk instance manages the layout and drawing.
 
The Disk class extends BaseBottomEntry, which is a horizontal JPanel with a BoxLayout and a name label. Then, Disk adds a JPanel on the right side of itsself and places stats like the ones given above (type, read/write activity, …) in it. For usage, there’s also a PercentageBar which is also custom-written.

Looking forward to finishing the UI and then getting started on the actual stats reading! :)

UI coming together even more!

The core UI structure is done now. This includes:

• Top Row
• Middle Row
• Bottom Row

Top Row

The top row contains CPU and RAM, same as in the last devlog.

Middle Row

The middle row contains all GPUs and fan speeds. This means it can contain 2..n component panels (if n is number of GPUs minus one).
It is horizontally scrollable which prevents this row over-cluttering the popup (which would be caused by methods like wrapping excess panels to the next row).

Bottom Row

This row contains two panels which fill the window’s width. The first panel - the disks panel - contains info about all disks or drives in the computer. It will have one “entry” (one row inside the panel with info such as drive name, transfer speed and used/total size).
 
Same goes for the network panel, which contains all network adapters. It will display info such as download, upload, adapter state and name.

UI Overhaul!!!!

I’ve decided I wanna go for a slightly different UI style, with CPU and RAM in the first row in a 2:1 ratio. Below, there’s the GPU row with 2 cols and as many rows as needed, and below will be one panel for all disks (including their usage, current transfer and so on) and one for all network adapters and their stats.

What changed already

The CPU and RAM panel are now positioned exactly how they will be in the final product. The CPU panel is also basically done, as its got the usage graph on top and stats on the bottom.

Technical Details

There are two new classes: Stat and Graph. A Graph is… well pretty self explanatory I hope, and a Stat is one value with text on what it is. (as seen below the red graph).

UI Overhaul!! :)

I finally got the UI working in a way I like. You now have one panel per component.

The Structure

The window contains a JScrollPane (for scrolling when the content gets larger than the window) which contains a JSplitPane for dividing the contents into top and bottom.
 
Additionally, there are the TopPanel and BottomPanel. The TopPanel contains three fixed panels: CPU, GPU and RAM. (still need to figure out how to properly display multi-GPU setups like this but future problem i guess)
The BottomPanel contains all other devices, like drives and network adapters.

Technical Details

Both TopPanel and BottomPanel are containers for individual “component panels”. Each component panel (CpuPanel, DiskPanel, …) owns its own components like labels, graphs or similar. I also wrote a custom JPanelRounded class for rounded panels.

About to add a little detail to the component panels next! :)

Finally, progress again!

After being offline for a little touching… grass and stuff (idk if anyone will get the reference) I finally got to work again and made two things work:

1. Right Click Menu for the Tray Icon
2. Basic Popup Window Structure

The Window Architecture

The popup window uses one main JSplitPlane which houses two panels (TopPanel, BottomPanel). Each of these panels again contains panels (CpuPanel, GpuPanel, …), of which each one contains stuff like its own labels and other stuff.

Tray Icon is nearing completion (already)!

OK, don’t take it wrong: the app is nowhere near finished but at least the tray icon is!

The current tray icon state

The tray icon now displays the CPU temperature represented as a color, interpolated between a cold hue (green, 30°C) and a hot hue (red, 90°C). Also, I added a tooltip which shows temps for CPU and GPU (currently its placeholders but oh well)

It took embarassingly long for me to realise I needed antialiasing to eliminate the choppyness-look from the icon btw

New project alert!

I’ve started working on an app called “Thermals”. It serves the purpose of being a simple yet modern and elegant usage and temperature monitor, accessible through a tray icon, made to work on both Windows and Linux.

Current Progress

Build System, Repository and similar is set up and simple tray icon (a white square) is also working.

Looking forward to how this project comes out! :)

Whoops

Had a small bug in the left arrow key in normal editing mode and popups weren’t resizing and re-positioning correctly, fixed all that :)

FINAL RELEASE BABYYYY (hopefully)

Finally, the debugger is working properly.

If you’ve tried a beta version, especially v1.1.0, you might have noticed the debugger being broken and kinda weird. I noticed that too, so I decided to rewrite it!
(technically, I rewrote it twice but oh well)

Why it needed a rewrite

Before, the debugger worked by executing the next step in-place and jumping in loops by moving the cursor to the matching bracket.
The problem was: to jump backwards when looping, you had to keep a history which could pretty quickly get filled if you were debugging enough and overall the system was too overengineered for what it was supposed to do.

The new architecture

The new debugger does almost the same that the live tape preview already does. The live tape preview has one caveat that doesn’t allow it to be directly used for the debugger though: we cannot track loop iterations on the cursor position alone, as we always just compute until the cursor. If we’re before a loop’s end, we’re only computing the first iteration. If we move past the loop, the whole loop gets computed in one move.Instead of the cursor pos, the debugger uses an instruction counter. It basically counts how many brainf*ck instructions it should run, which solves all problems here.

Why this works

Take this program:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

Say we wanna run 40 instructions. We first step over the initial ++++++++[>++++[>++>+++>+++>+<<<<- (33 instructions), and then we get to the first ].
When we do, the current cell is non-zero, meaning we jump back to the instruction after the highlighted bracket (++++++++[>++++ [ >++>+++>+++>+<<<<-).
The jump is one instruction. Then we run >++>++ and reach 40. Notice how we’re in the second iteration when it ends. If we now move the cursor forward by one, we tell the tape generator “execute 41 instructions”.
The same as before happens now (execute first bit, jump back, continue executing - but one instruction more than before this time) but we land in the second iteration again.

Popups are finished! (almost)

After a little bit of work, a popup system (which I gotta say is written kinda well compared to all the other code) is in place!

Currently, there are:

• Exit Confirmation Popup
• Save File Dialog
• Load File Dialog

One last thing is still missing though: The please press a button popup for inputs (,).

Technical Details

The popup system works by using a sub-struct inside of the global state struct (state.popup). It contains data such as whether a popup is active, if it accepts text input and handlers for drawing and the confirm button.
 
There’s a base func (create_popup_base()) that draws a new basic outline for the popup. After that, only the contents of the popup get refreshed via the custom handler set via setting a function pointer (state.popup.refresh_handler).
The popup also “captures” input. There’s a seperate if for state.popup.active before the main input validation which processes inputs and then skips the normal input processing.

The debugger works!!

After hours of work (mainly debugging and patching up code), it finally works! :DD

The power of the debugger

You can use the debugger to step forward and backward in your brainf*ck program. While stepping, a live program counter display (labelled “PC”) shows the current program counter index, while the tape in the bottom panel shows the current state of each cell, which cell is currently selected by the data pointer and what the cell contains, in both decimal and ASCII format.

The following is just for if you’re interested in the technical details ;)

Why I wanted to wipe my drive several times while making this (Problem 1)

The first main problem in writing the debugger was stepping backward. You’d think its just “do the instruction in reverse, like when you back-step a -, just do a + instead” but the problem arises when, for example, you read in something using , and the info got overwritten. How do you reverse to something that got destroyed? Well, you don’t.

The Solution to the Back-Stepping problem

I implemented backward stepping by just recomputing the entire tape from scratch on every backstep. Yes, it’s probably not the best way, but it works.

Problem 2

Loops. Once. Again.
The jumping around of loops in brainf*ck is not the simplest thing to correctly compute, especially when only partially executing a program.
When you land on a [ or a ], you also need to account for nested loops. You can probably imagine that that can definitely cause some headaches.

Live tape preview is done!

While writing or editing code or by literally just moving your cursor, you now get a live preview of the programs “tape” (basically it’s entire data it works with).

There is one big problem with the current system however. If you’re interested, feel free to read the following.

The big Issue

Loops. You see, in brainf*ck, loops work by using [ to jump to the matching ] if the current cell is zero and by using ] to jump to the matching [ if the cell is non-zero.
This behaviour is actually not that pleasant to simulate when you’re only executing to a specific point in the program, because the “simulator” (the thing that interprets the bit of brainf*ck code up until your cursor and then generates a tape from that) can’t see the matching closing ] as it comes after the cursor. This means the loop will never really execute. But, when you navigate past the entire loop block, the cells jump to a completely different state (as seen in the video at around 0:08).

How am I going to solve it then?

I’ve decided that I dont want to “solve” it by somehow making loops work in live preview. I’ve decided live preview should only be relatively basic. For serious loop-involved debugging, I wanna introduce a special “Debug Mode”. In this mode, you’ll be able to step through your code, have chars printed into the output panel live AND also have the cursor/program pointer correctly jump around.

Menubar Navigation, Code Running and Output Display works!! 🎉 :)

Today, the IDE ran its first program! (and yes, of course, it was a hello world program)

What changed?

As already mentioned in the last post, I’ve rewritten part of the menubar rendering and also implemented output field rendering. Also, I’ve refactored the run_brainfuck function to be compatible with the UI.

Changes in the run_brainfuck(...) function

Before, it just stubbornly printed to stdout and read from stdin which of course kinda conflicts with the UI. To solve this, I made it write into an output buffer and accept a function pointer for a function that needs to return an int of which char was read in. The actual reading in will be handled by the pointed to function, which will probably be a “Please press a button” popup.

What’s next

Looking forward to getting the tape reel and then popups (including file saving/loading, exit confirm and please press a button) to work!

Great News! The editor is now fully working!

I’ve managed to implement everything from syntax highlighting to special keys such as delete, home and end.

Nice! What now?

I’m also working on getting the menubar to work, which’ll require rewriting a little part of the menubar rendering, as currently, the text entries get printed in one go with the spaces. If I somehow wanna highlight the text only, I gotta draw it all seperately.

Typing works!! not

Another Memory Violation :)
Gonna debug that one too i guess

On the flip side, I got syntax highlighting working!

This was literally me after opening my code today

On a side note:

I’ve cleaned up the codebase a little and split stuff into separate files for readability, like moving the editor draw function along with all its helpers into a separate file.

I’m about to start working on finishing the editor panel now. :)

holy productivity spike

I got the editor fully working!!! :)

After wanting to throw my computer from a comically large height (multiple times), it finally runs: proper arrow-key navigation, a fully working cursor, soft wraps, line numbers, and so on. Vertical scrolling is now fully functional aswell.

Even some comfort features like using the Home and End keys work!

Fun stuff I found out in the process

In the process of getting this to work I also discovered things like the fact that the pdcurses getch() macro implicitly refreshes the stdscr and then… doesnt… flush it 😐

Anything still borked?

Some things also still don’t work fully, which kinda bothers me. The main example of this is navigating the cursor vertically into soft-wrapped lines; because of how I wrote the row up/down logic - which is to check in the editor buffer where the next or previous line feed is and then navigate based on that - I can’t just say “oh theres a soft line wrap lets just detect that instead of a \n” because the rendering (which does the soft line wrapping) and the I/O loop don’t communicate with each other

Sure, I could fix it by adding a shared data structure which contains all line wrappings, but for now, I just wanna get the more important stuff running.

Any plans now?

Anyways, I’m planning to finish the editor fully by adding writing text (wild concept, i know!) and syntax highlighting next.

Stay tuned to find out how much I continue to suffer! :’)