Differences

This shows you the differences between two versions of the page.

--- tutorial:custom_oses [2014/09/07 05:23]
sangar created
+++ tutorial:custom_oses [2020/03/29 21:04] (current)
thepuzzlemaker [What's Available?] Add some undocumented functions/libraries available in OSes without compatibility libraries or OS-level libraries
@@ Line 1: / Line 1: @@
 Writing custom OSes
 ===================
-Starting with OpenComputers 1.3 computers need an "Operating System" to function - OpenOS is no longer built-in. While this makes it slightly more annoying to set up computers, it opens up a lot more possibilities for people that want to write their own OSes; which is what this article is all about!
+Starting with OpenComputers 1.3 computers need an "Operating System" to function - OpenOS is no longer built-in. As of 1.4(.2?) you even need an EEPROM in your computers, which acts as the BIOS of the machine. While this makes it slightly more annoying to set up computers, it opens up a lot more possibilities for people that want to write their own OSes; which is what this article is all about!
 Booting
 -------
-The only thing built-in now is the "kernel". This is a non-editable Lua script responsible for setting up the sandbox and super-low-level interaction with the "host" side of things (that being Java/Scala). When a computer is powered on, the kernel script is loaded and run. After estabilishing the sandboxed environment a bootstrapper script is executed:
+The only thing built-in now is the "machine" booting the BIOS. This "machine" wrapper is a non-editable Lua script responsible for setting up the sandbox and super-low-level interaction with the "host" side of things (that being Java/Scala). When a computer is powered on, that script is loaded and run. After estabilishing the sandboxed environment it looks for an EEPROM and tries to run the data on it as a Lua script. If that fails the computer crashes. Otherwise that BIOS is run. For the provided one (Lua BIOS, crafted using EEPROM + book) it will perform the actions previously done by the machine itself:
 . It looks for a file system with address set via `computer.setBootAddress` (read via `computer.getBootAddress`).
@@ Line 11: / Line 11: @@
 . If it succeeds, that's it. The user script is now in control. If it fails, it iterates over all present file systems, performing step 2 again until it succeeds.
 . If no working `init.lua` script is found, the computer crashes with a `no bootable medium found` error.
+But since you can program the EEPROM however you like you could also boot from a network device, for example.
 What's Available?
 -----------------
-There are a few libraries documented on the wiki that are in fact part of OpenOS, so when you're implementing your own operation system, those won't be at your disposal. Most notably that includes the `io`, `package` and `filesystem` libraries. For a definite reference for what's available in an init script, check the kernel. The following list isn't guaranteed to be complete and/or up-to-date!
+There are a few libraries documented on the wiki that are in fact part of OpenOS, so when you're implementing your own operation system, those won't be at your disposal. Most notably that includes the `io`, `package` and `filesystem` libraries. For a definite reference for what's available in an init script, check the kernel or [[https://github.com/MightyPirates/OpenComputers/blob/master-MC1.12/src/main/resources/assets/opencomputers/lua/machine.lua|machine.lua script for your current OpenComputers version]]. The following list isn't guaranteed to be complete and/or up-to-date!
 ```lua
@@ Line 59: / Line 61: @@
 coroutine.yield
+debug.getinfo
 debug.traceback
+debug.getlocal
+debug.getupvalue
 math.abs
@@ Line 121: / Line 126: @@
 component.doc
+component.fields
 component.invoke
 component.list
 component.methods
 component.proxy
+component.slot
 component.type
@@ Line 132: / Line 139: @@
 computer.energy
 computer.freeMemory
+computer.getArchitectures
+computer.getArchitecture
 computer.getBootAddress
+computer.getDeviceInfo
+computer.getProgramLocations
+computer.isRobot
 computer.maxEnergy
 computer.pullSignal
 computer.pushSignal
 computer.removeUser
+computer.setArchitecture
 computer.setBootAddress
 computer.shutdown
@@ Line 154: / Line 167: @@
 unicode.wlen
 unicode.wtrunc
+-- Lua 5.3 only:
+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
+```
+Accessing components in BIOS
+-----------------
+Unlike in OpenOS you don't have the primary system for components in BIOS. That means you cannot just write `component.redstone.setOutput`, you have to manually create your proxy for the component first. For several reasons the proxy system is provided via the machine itself, so you can still use that. To get a proxy, use the `component.proxy` method. It expects the address of the component to wrap. You can either write that down manually, or get the list of components using `component.list` and go from there.
+For example, to get the first best redstone component, you can do the following:
+```lua
+local r = component.proxy(component.list("redstone")())
 ```
+This works because `component.list` returns a Lua iterator: a function that can be called repeatedly to get the next element in whatever it iterates over, returning `nil` once there are no more elements.
 A few more things