updated readme
This commit is contained in:
26
README.md
26
README.md
@@ -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
15
TODO.md
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user