Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
  1. OpenComputers

    1. Announcements

      OpenComputers official announcements.

      122
      posts
    2. Feedback

      Tell us what you think.

      380
      posts
    3. IRC

      #OC channel discussion
      irc.esper.net #oc

      25
      posts
  2. Code Central

    1. Support

      Ask for support from the OpenComputers community

      3730
      posts
    2. Showcase

      Showcase what you have created for OC. No 'malware' or other junk!

      2591
      posts
    3. Tutorials

      Help other users out. Please no 'false tutorials'

      115
      posts
  3. Addons & More

    1. Addons Mods

      Show off your OC addons mods

      225
      posts
    2. Architectures

      Discussions for Architectures

      176
      posts
    3. OpenEngineering Task Force

      Discussion board for the OETF documents

      71
      posts
  4. General

    1. Lounge

      Just lounge around or have an open discussion.

      314
      posts
    2. Forum Games

      Fight boredom!

      61
      posts
    3. Showcase

      Show off your creations! (not for your programs)

      132
      posts
    4. Servers

      A place to advertise your servers

      145
      posts
  5. Archives

    1. Public Archives

      OpenComputers public archive forum

      8
      posts
  • Forum Upkeep

    In order to keep the forums updated with improvements and security fixes, we need to pay for a subscription.

    Currently, this is: $25/6-months for the forums itself and $10/6-months for the Theme (totalling $35 USD/6-months).

    You're not obligated to donate anything, but anything you do donate will be much appreciated. :)



    2% of donation goal reached.
    Donate Sidebar by DevFuse
  • Topics

  • Posts

    • I started, last year, an operating system. Today i'm presenting you that modular project. Because yes, it is mostly based on modularity, its folders make think about Windows. But enough speaking, i arleady written an introduction in the README, let me adapt it Some example image: image Fuchas haves a lot of libraries inside it. (like shin32 or shinamp which are in the same order for multi-tasking and misc operations and for audio), the "NT" part is basically just the boot/init part, originally called by init.lua or the content inside driveinit.lua if on a unmanaged drive. Fuchas is based on drivers instdead of APIs directly interfacing with components (except for components sure they are present and core to the operations), it allows for user drives, and mostly, having programs compatible with hardware from addons mod supported by Fuchas, that's a great step forward considering that without Fuchas, each software (even on MineOS) has to support the hardware themselves. For that, Fuchas will load the most relevant hardware for the configuration (e.g., for sound, if Computronics Sound Card present, use it instdead of PC Speaker), however in case of conflicts, (following is not yet implemented) it will be able to load multiple drivers and supply them, up to the program to choose the best (or to the user if it prompts for). Fuchas is also multitasking, it works with a "main thread" (originating from the boot), it cycles through all active processes and execute a "tick" of them, processes's tick should only last a short time (a "tick", best around 20ms or lower, 50ms max for stability). (TODO ->) Long-term (more than 50ms) blocking operations (like I/O) gets a part (like 10 bytes of a file, can be set via priority) of the work time. Basically Fuchas uses cooperative multitasking. Well i hope it makes it a bit interesting, however, multi-tasking is supported, but some things (like event listening) are still synchronized and blocking (for now, it's gotta change very soon)! Also, it doesn't have any installer for now, sorry guys, i was mostly interested by the "under the hood" part GitHub link of the OS
    • I understand some people might just dislike another booting method, even if implementations should be compatible with original one. And as the document might seem "empty", any criticisms (good or bad) and/or suggestions are welcomed. Note: "Application" refers as init scripts for OEFI booting. Why: Due to the limitation of current OC booting method which basically searches for an init.lua file, a new and open specification has been made: Open Extensible Firmware Interface. The limitation OEFI fix in BIOS booting in OC is: - In BIOS booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem. - The operating system, once launched, cannot return back to the BIOS (or here, the OEFI), while OEFI have oefi.returnToOEFI()! - Since BIOS booting doesn't have any native support for multiple applications. An OS that want to boot another one need to manually check for init.lua files in all filesystems, OEFI has oefi.getApplications() method for it   Specification: Every OEFI should be backward-compatible with OC original booting method which is basically booting init.lua. OEFI must also create a standard API available to the OEFI program as the first argument (of "..."), the API must implement at minimum the following: oefi.getApplications() - Return an application table as described below oefi.getAPIVersion() - Return API version number, current = 1 oefi.getImplementationName() - Returns implementation name oefi.getImplementationVersion() - Returns implementation version number oefi.returnToOEFI() - Recalls the OEFI program, most of _G structure should remain as it was at boot. Meaning that if for example, component API needs "require(...)" function, this will just crash. oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation routine computer.getBootAddress() - Return the filesystem address from which the application booted computer.setBootAddress(addr) - Provided for compatibility, does nothing Implementations can create implementation-specific methods that can be used by applications and OSes launched by them. Application Table: The application table must contains tables as entries. The tables must contains the drive address with "drive" key and the path (from drive) with "path" key Example: { { "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25", "path": ".efi/sampleos.lua" }, { "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25", "path": ".efi/osOnSameDrive.lua" }, { "drive": "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", "path": ".efi/another_os.efi" } } Application Finding: OEFI Applications can be found on any sort of drives, from disk drives to floppy, with raids, only if they contains a ".efi" directory. The OEFI should search in that ".efi" directory, and add every .lua or .efi files to its application table. ".efi" directory name has been chosen for being hidden by default on POSIX systems.   (EEPROM) Data Format: Booleans are a single character value, they are equals to "T" if true, or "F" if false 1-Byte Numbers are also single character values, they are corresponding to the ASCII character of the number (use string.char(number)), these are limited to 255 as maximum value As of API version 1: The data (512 bytes) should be written in the following format (in the same order!) : - 1-byte number, equals to the API version of the implementation (current is 1), having it at start will allow for config conversion in case of new version - Last booted application filesystem component id (always 36 bytes) (like 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b) - 1-byte number, equals to the length of the last booted application path (next value) - Last booted application path - 1 boolean for weither it should allow the OS to return back to OEFI or not   Example (line breaks should NOT be included): (ASCII character 1) 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b (ASCII character 15) .efi/fuchas.efi T
    • I never needed them in my own setup (I prefer piston-based doors), so I saw no point in supporting them. That was before this script was published here. Later I've been thinking about adding new modules, including the one responsible for controlling security doors, but that would require a quite large modification of the core script (the ability to run more than 4 modules simultaneously). I didn't know if anyone used The Guard, so I didn't want to rush into this (partly because the lack of time).   The dark theme was never tested, but I'll try to make it work. I'll add a new post when a patch is ready.
    • thx, for the quick fix! I think this program is very versatile due to its modular construction.  You are not supporting doors and the SecurityBlock?  I saw there is an option for a "Dark Theme". When i enable it it says "restart the program" but the design remains the same.
    • Yes, I can confirm it's still maintained, but due to a lack of interest support is currently limited to bug fixes only. @Quisquid I have fixed the bug, just update the library: arpm refresh arpm install gml  
  • Popular Contributors

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.