https://github.com/ekimekim/gbos

A basic operating system for the Game Boy. Because I can.
https://github.com/ekimekim/gbos

Last synced: 2 months ago
JSON representation

A basic operating system for the Game Boy. Because I can.

• Host: GitHub
• URL: https://github.com/ekimekim/gbos
• Owner: ekimekim
• Created: 2017-05-01T09:40:09.000Z (about 7 years ago)
• Default Branch: master
• Last Pushed: 2019-09-25T14:53:55.000Z (over 4 years ago)
• Last Synced: 2024-01-24T16:46:35.215Z (5 months ago)
• Language: Assembly
• Size: 156 KB
• Stars: 25
• Watchers: 3
• Forks: 4
• Open Issues: 0
• Metadata Files:
  • Readme: README

Lists

• awesome-gbdev - gbos - A basic operating system for the Game Boy. (Related projects / Post processing)
• awesome-gb-dev-zh - gbos

README

        
A just-for-fun project for approximating an "operating system" for the original Game Boy.

Goals:

	Time-sharing scheduler

	Negotiation of access to shared resources

		eg. vram, audio, input, RAM

	IPC

	task spawning

	sleep()

Stretch goals:

	Text interface application

	Split screen access to vram

Non goals:

	Full state switching (eg. all io regs, vram, ...) to allow 'bare metal' programs to run

	Security - all programs must obey the rules but if they don't we can't stop them

Notes:

'Core' code is the OS itself, is located in ROM0 and uses RAM0. It has a dedicated stack.

'Tasks' (generally) run in an arbitrary ROM bank and may use a RAM bank allocated at runtime.

This allows for limited dynamic memory management without needing to make code relocatable.

There will probably also be 'core tasks' that are tasks that do async core work, and so not all

tasks will have a dedicated ROM bank. Currently design allows for up to one ROM and RAM bank per task.

These banks are only loaded when the task is.

Tasks are in charge of managing their own stack.

TODO allocate some stack space (and other space?) for tasks that don't otherwise need their own RAM bank.

Functions with 'T_' prepended, eg. 'T_Foobar' are suitable for calling 'into' core.

Generally, these don't actually trigger a task switch onto the core stack, but do some core-managed job

on the task's stack before returning, ie. they're normal functions, just semantically seperated

as being allowed to touch core stuff.