updated readme

This commit is contained in:
2026-04-02 10:46:41 +02:00
parent 3f6ef63737
commit e66b11c5c3
2 changed files with 18 additions and 23 deletions

View File

@@ -1,21 +1,15 @@
# NeoNucleus
The core of NeoComputers.
This repository has both NeoNucleus itself (NN) and the NeoNucleus Component Library (NCL).
It provides:
- the computer model and state implementation
- architecture system
- (NOT NOW) basic component implementations
- (NOT NOW) standard emulator
- (NOT NOW) some extra components
These libraries provides:
- the base architecture, with computer states (for running machines), components, architectures, etc.
- (NCL) base component implementations for common ones (GPU/FS/tmpfs/EEPROM/etc.)
- fine control over component limits, with default references
The library does not provide:
- The sandbox (equivalent to OpenComputer's `machine.lua`)
- Default architectures
- Default host interop (as in, the vtables that control the basic component's internals, such as the filesystem implementation)
The emulator *will* (as its gonna be made after the engine is functional) provide:
- A simple Lua sandbox
- Very simple workspaces
- Ocelot components for debug
- Headless mode (single computer, uses actual terminal for a teletypewriter).
They do not provide:
- Networking implementation, so you need to pass vtables for all network-related components
- Default architecture. While the testing emulator has a test version of the common Lua architecture seen in OpenComputers,
it is not propely sandboxed nor safe. Neither NN nor NCL provide any architectures.
-

15
TODO.md
View File

@@ -1,19 +1,19 @@
# For MVP functionality
- finish `eeprom` class and volatile eeprom
- `filesystem`, `drive`, `gpu`, `screen` class implementations
- `ncomplib` with reference component implementations (depends on libc)
- `gpu`, `screen` class implementations
- write a tester OS, basically a menu with tests to run
- volatile drive
- volatile filesystem
- move veeprom into NCL as tmpeeprom
- tmpdrive
- tmpfs
- device info
- userdata support
# To re-evaluate
- More stack manipulation functions to allow libraries to have better APIs.
- Exposing the internal non-resizing hashmap implementation.
- More stack manipulation functions to allow libraries to have better APIs. (rotate)
- Having a copy of the context stored directly in requests instead of having to use getComputerContext, as it simplifies the APIs and allows them
to be made more portable.
- Exposing more context wrappers than just the memory allocation functions.
- Exposing more internal functions that may be useful to the user to prevent pointless rewriting and duplicate machine code.
# Vanilla components needed
@@ -23,6 +23,7 @@ Not everything OC has (as a few of them are really MC-centered) but most of it.
- `data` component (note: maybe add hamming code support?)
- `modem` component
- `tunnel` component
- `internet` component
- `relay` component (note: OCDoc still refers to it as `access_point`)
- `computer` component
- `geolyzer` component