mdfl64/lunatic-core

John Lua OS

lunatic-core's Issues

Test libs

Prune base lib

Ditch loadfile, dofile, collectgarbage, gcinfo, newproxy.

Keep coroutine garbage and print, for now.

Error handling

If the kernel errors, return into the loader and have it print the error.

Totally remove screen lib from core. Have the kernel worry about IO.

Loader Memory Map

• 0x00000: Reserved stuff, ~32k for loader code.
• 0x10000: Read Data
• 0x20000: FAT Table Cache
• 0x30000: ?
• 0x40000: ?
• 0x50000: Loader Stack
• 0x60000: Core Info Table
• 0x70000: Page Tables
• 0x80000+ is sketchy
• 0x00F00000: COULD BE Memory mapped hardware!
• 0x01000000 (16meg) - 0xC0000000 (~3GB): Core
• 0xC0000000: 1GB of memory mapped hardware
• 0x100000000+ is more memory for core, not currently supported.

Components/Naming

• Bootloader (NewMoon.asm): Written to the first few sectors of the boot disk. Puts the processor in the right mode and loads everything in Lunatic/Init into memory, then jumps into the core's start method. I'll probably just try to rewrite most of it in C if I ever get an excuse to.
• Core (FullMoon.exe): Loaded into memory by the bootloader. This is your standard issue PE executable. Why? Because I can. Contains the LuaJIT VM, a very minimalistic and probably incorrect standard library, and code to run the kernel script.
• Kernel (kernel.lua): The damn kernel script. Lives in the main repo. This is where the actual OS design shit comes in to play, so I am a bit spooked. At a bare minimum this needs to be able to load symbols for LuaJIT. Somehow.

Bootloader hangs when it can't find a kernel?

Also should change "cant find file" -> "cant find directory".

Figure out context switching

Brief look at the coroutine api leads me to think this is probably doable.

Consolidate Build Scripts

Actual, working memory allocator

Load root script from init files.