frankray78 / patienceos Goto Github PK

Background

Attempting to develop a whole OS is a pretty big deal, especially if you've never done anything like this before. It's also very easy to quickly become overwhelmed, disillusioned and put off, as my post PatienceOS isn’t living up to its name starts to indicate.

Approach

I suspect that maintaining focus on the most interesting things (personally), having a clear list of prioritised topics to delve into, better information management (eg. note-taking whilst also keeping the majority of information pigeonholed until actually needed), and the ability to quickly start and stop new pieces of work as time allows, are major strategies to adopt.

Some ideas to try include:

1. Follow Simon Willison’s advice in How I build a feature
2. Experiment with community involvement, eg. Top Issues GitHub Action
3. Adopt practices from the Better Software Requirements handbook

From Simon's article above, I particularly like:

"Every piece of work I do has an associated issue. This acts as ongoing work-in-progress notes and lets me record decisions, reference any research, drop in code snippets and sometimes even add screenshots and video" and also "Being able to quickly spin up a development environment for a project is crucial. All of my projects have a section in the README or the documentation describing how to do this".

I intend to make better use of Issues for PatienceOS, and this issue covers the topic of better information management.

Please upvote 👍 this issue if you are interested in it.

References

bflat Discussion #190: Best configuration for text editor usage?

Language Server Protocol (LSP)

Please upvote 👍 this issue if you are interested in it.

See PC common text modes on VGA text mode

This issue covers the ability to change the VGA text mode (aka 'mode setting) through a BIOS interrupt 10 call.

The processor state is required to be in 'real mode', otherwise interrupts are disabled.

Please upvote 👍 this issue if you are interested in it.

A custom allocator for managed .Net is ideally what's needed, failing that, just plain old malloc/free calls would be a sufficient starting place.

Reference implementations

From MOOS, this looks very interesting: private static unsafe object RhpNewFast(EEType* pEEType)

bflat PR 79: Allow manual heap deallocation with zerolib

Background reading

Visual overview of a custom malloc() implementation
Anatomy of a Program in Memory
Hijacking the .Net new() operator

Advanced reading

Memory Management - D Lang

Please upvote 👍 this issue if you are interested in it.

See PC common text modes on VGA text mode

This will require the ability to write to a native IO port, something not supported in C# .Net OOTB.

(nb. a dependency of this issue, #14. Read and write to IO Ports, has been created)

Please upvote 👍 this issue if you are interested in it.

The build toolchain is currently Windows only and a mishmash of Microsoft and GNU tooling (reasons explained here).

This issue tracks improvements to the build toolchain, some ideas being:

• Replace ld (GNU linker) with the Microsoft linker (ie. align the compile and link tooling to the Microsoft stack)
• Replace NASM with the Microsoft linker
• ISO creation, removing the dependency on QEMU -kernel command line argument
• Custom MSBuild task for compilation
• Get builds on Linux working

References

• FlingOS MSBuildTask
• Compiling assembly in Visual Studio

Please upvote 👍 this issue if you are interested in it.

The ability to read and write to IO ports is needed (nb. this is something different to memory mapped IO).

Switch between VGA text modes is a good example that requires writing to an IO Port.

Various ways exist to do this, namely:

1. Utilising the ASM plug architecture of COSMOS (see this and this)
2. Linking to a machine-specific DLL/library (nb. not great because a cross-compiler setup will be needed for each)

Background reading

1. Read/Write to Debug Port (0x80h) using C#
2. QEMU_Monitor (OS Dev)
3. QEMU Monitor Manual

This command demonstrates the ability for QEMU Monitor to dump physical memory addresses:

i/fmt addr [.index]
Read I/O port.

fmt is a format which tells the command how to format the data. Its syntax is: /{count}{format}{size}

I intend to use i 0x80 to validate a successful write to the debug port (0x80h).

Please upvote 👍 this issue if you are interested in it.

The terminal is key to providing user interactivity with PatienceOS.

Here are some ideas I'd like to implement:

Terminal output

• Multiple calls to console.Print concatenates the text across the terminal line (not exceeding the terminal width)
• Multiple calls to console.Print concatenates the text across the terminal line (wraps to the next line when exceeding the terminal width)
• Multiple calls to console.PrintLine displays the text on consecutive lines
• When calls to console.Print \ console.PrintLine exceed the terminal height, the terminal scrolls the text up (ie. the oldest visible line is discarded, the remaining text is moved up one line, the new text is displayed on the last row)
• (stretch) Ability to scroll terminal output beyond the visible dimensions ie. buffered output

Command line interpreter

• cls - clears the terminal
• fgcolor - set the terminal's foreground color
• bgcolor - set the terminal's background color
• setres - set the terminal's resolution (depends on: #15. Switch between VGA text modes)
• cursor - sets whether the cursor should be visible

nb. the above assumes some way to inform the user of an unknown command, and/or, they have not specified a required argument for an entered command (eg. a valid foreground color for fgcolor)

References

1. Basic x86 interrupts - will be required for receiving key strokes from the user.

Please upvote 👍 this issue if you are interested in it.

A wiki might be a better way to document PatienceOS as it grows and evolves, allowing the current README.md to remain much smaller and fairly static. AuraOS is a fairly good example to follow.

Please upvote 👍 this issue if you are interested in it.

A simple dashboard that lists the top issues/bugs/features and pull requests.

Top issues

1. #6 👍4
2. #15 👍1

Created by the rickstaa/top-issues-action action (last update: 6/24/2024, 12:54:37 AM).