thox startup

thox can boot in multiple Lua environments; therefore, in order to simplify compatibility management within the system itself, we need to manage it beforehand, by offering a uniform interface to it like Multiboot in real-world system design.

On thox, this is accomplished using the startup script, which unifies the environment and available resources in a single canonical form while preserving all of the capabilities.

The obtained environment is composed of the following:

  • Standard implementations of the utilities are available directly; we base ourselves on the Lua 5.3 manual for what should be available.

  • Everything non standard is isolated within the bios module.

Todo

Could this be run as a custom BIOS on ComputerCraft?

Todo

Describe the steps up to this point: the Java functions, how they are provided to Lua, the bios.lua, then how and when the current startup script is loaded.

Maybe quote the unbios.lua script which could be useful.

Todo

Restrict the number of available utilities?

Todo

This component could also check system integrity.

Todo

How does this component run the system?

Startup standard APIs

The following utilities are available as described in the Lua 5.3 manual:

_G
_VERSION

assert
error
getmetatable
ipairs
load
next
pairs
pcall
rawequal
rawget
rawlen
rawset
select
setmetatable
tonumber
tostring
type
xpcall

coroutine.create
coroutine.resume
coroutine.running
coroutine.status
coroutine.wrap
coroutine.yield

math.abs
math.acos
math.asin
math.atan
math.ceil
math.cos
math.deg
math.exp
math.floor
math.fmod
math.huge
math.log
math.max
math.min
math.modf
math.pi
math.rad
math.random
math.randomseed
math.sin
math.sqrt
math.tan

os.clock
os.date
os.difftime
os.time

string.byte
string.char
string.dump
string.find
string.format
string.gmatch
string.gsub
string.len
string.lower
string.match
string.rep
string.reverse
string.sub
string.upper

table.concat
table.insert
table.pack
table.remove
table.sort
table.unpack

On certain conditions, the debug utilities might be available:

debug.gethook
debug.getinfo
debug.getlocal
debug.getmetatable
debug.getupvalue
debug.getuservalue
debug.sethook
debug.setlocal
debug.setmetatable
debug.setupvalue
debug.setuservalue
debug.traceback
debug.upvalueid
debug.upvaluejoin

On Lua 5.3 if available, the following utilities are also available:

coroutine.isyieldable

string.pack
string.unpack
string.packsize

table.move

math.maxinteger
math.mininteger
math.tointeger
math.type
math.ult

utf8.char
utf8.charpattern
utf8.codes
utf8.codepoint
utf8.len
utf8.offset

Todo

Check if we have access to debug, in what circumstances, and so on.

Startup peripherals API

The main abstract bus is available through the bus global variable, which corresponds to the main abstract bus. Every device has the following variables:

class startup.Peripheral

A peripheral representation.

parent: Peripheral

The reference to the parent bus as a peripheral. The main abstract bus sets this to nil.

address: string or number

The address of the peripheral on the parent bus, which format depends on the bus type.

manufacturer: string

The name of the peripheral’s manufacturer, as a string; usually represents the mod which brings the device, e.g. "computercraft".

name: string

The name of the peripheral, as a string; usually represents the device type, e.g. "modem" or "computer".

available: boolean

A boolean indicating if the peripheral is still available for calling. When attached, this attribute is set to true. If the peripheral gets disconnected, this attribute is set to false and does not evolve from here; references to this peripheral object should be lost, as a new object will be created if the peripheral is reattached.

interfaces: table<string>

The name of the interfaces a given device implements, in order to recognize devices through their functions (and therefore the methods we can use on them) rather than by their name.

methods: PeripheralMethods

The methods of the given object. The content of this table can be guaranteed by the interfaces provided above.

class startup.PeripheralMethods: table, string, function

A set of peripheral methods. This class is to be overloaded for every interface that a peripheral implements.

class startup.BusPeripheralMethods

Methods for when a peripheral implements the "bus" interface.

listPeripherals()

Get the list of all peripherals on this bus.

Returns

a list of all peripherals on this bus.

Return type

table<Peripheral>

getPeripheral(address)

Get the reference to a peripheral.

Parameters

address (string or number) – the address of the peripheral to get a reference of

Returns

the reference to the peripheral object or nil

Return type

Peripheral