NeoFlock/neonucleus
9
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity

updated readme

Browse Source
This commit is contained in:
IonutParau
2026-04-02 10:46:41 +02:00
parent 3f6ef63737
commit e66b11c5c3
2 changed files with 18 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
README.md
View File

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

15
TODO.md
View File

@@ -1,19 +1,19 @@
# For MVP functionality # For MVP functionality
- finish `eeprom` class and volatile eeprom - `gpu`, `screen` class implementations
- `filesystem`, `drive`, `gpu`, `screen` class implementations
- `ncomplib` with reference component implementations (depends on libc)
- write a tester OS, basically a menu with tests to run - write a tester OS, basically a menu with tests to run
- volatile drive - move veeprom into NCL as tmpeeprom
- volatile filesystem - tmpdrive
- tmpfs
- device info - device info
- userdata support
# To re-evaluate # 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 - 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. 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. - Exposing more internal functions that may be useful to the user to prevent pointless rewriting and duplicate machine code.
# Vanilla components needed # 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?) - `data` component (note: maybe add hamming code support?)
- `modem` component - `modem` component
- `tunnel` component - `tunnel` component
- `internet` component
- `relay` component (note: OCDoc still refers to it as `access_point`) - `relay` component (note: OCDoc still refers to it as `access_point`)
- `computer` component - `computer` component
- `geolyzer` component - `geolyzer` component