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

Zen1th

Members
  • Content Count

    28
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Zen1th

  1. Nevermind, everything (relating to installation) has been fixed. And here is a computer working with Fuchas I'm glad now installing Fuchas is 100% easy (you have to press 3 keys during installation) P.S.: To have a easier dualboot, i will continue working on my (currently secret) OEFI implementation. It will allow booting other OSes instdead of just Fuchas and OpenOS (but it will be on EEPROM side, not HDD, which makes it a bit more limited). Of course we will be able to select something like "I arleady have an OEFI", "I don't have an OEFI", "I don't want an OEFI" during installation. So that people not wanting on OEFI or too lazy to install an OEFI can select their option
  2. very strange for it to be stuck. Is there disk activity (the sounds and/or blinking light on case) or did it crashed?
  3. Compatibility with OpenOS program is planned, but more core features are needed before i actually do it.
  4. Ok it turns out that i was dumb on the condition that checked GPU and screen. I forgotten to add a ~= nil. Anyways gotta publish changes, re-install in 15 minutes and it should be all good (this time it will be good!) Or you can manually edit init.lua, add "== nil" at line 19 after cp.list("screen")() And also thanks for still wanting to use the OS after all those little installation bugs i really appreciate this
  5. but you have a screen and an actual graphics card?
  6. All bugs (i know of) related to installations are now FIXED! You can now freely install Fuchas without any problems. However only dual-boot work FOR NOW. Due to the lack of "edit" command, you will have to go to OpenOS to code Fuchas programs using "edit" command. I'm planning a editor for Fuchas, i'll do it when i can!
  7. I mostly fixed installation bugs, however wait that i tell the 2nd part installer to be done before re-installing fuchas
  8. I figured out the error, the main problem seems to be that, somehow, xpcall seems asynchronous only in OC machines and that so it will result in the computer finishing Fuchas/NT/boot.lua instdead of continuing Fuchas execution. Resulting in a computer halt. Second problem is that i forgot to add the "shell" library on first download. But the xpcall error is strange
  9. Thanks for reporting the installation bug and the error after installation. I will search what is causing this error to happen and i will fix it. However the error only seems to appear on OC computers but not on OC emulators :/, i guess i shouldn't rely that much on emulators for compatibility..
  10. There is progress since last post, althought small progress. For example i added liblon (an unofficial Lua Object Notation , just made to be easier to parse). I also started the "Concert" graphical interface, but currently it's way too limited to be worth a new post (and presentation edit), alongside it i added the shin32 library wiki page (on GitHub). The rest of features are just installation fixes
  11. I'll do a proper topic for my game when it's stable, for now just wait a bit
  12. i didn't understood? Ok thanks you.
  13. Thanks for the reply, some days after asking the question i also found out that no, that's why for absolutely no reason at all i started OCCity to change this.
  14. The mod is not even yet updated for forge 1.13.X, so a version for 1.14 will maybe be in months or even year, since 1.12 and 1.13 have lot of technical changes. However i'm not a official developer of OpenComputers, so that's just guessings.
  15. I didn't finished the installer. However i added a VERY IMPORTANT FEATURE, before events were handled by programs and blocking. Now events are handled by the task manager. Meaning A process can pull event while another does something else. Which is very close to multi-tasking. However this feature is buggy and some events are skipped, this should be fixed by optimizing. Alongside this i might make a GUI soon to show the benefits of multi-tasking V.S. single-tasking (used by MineOS and tactiOS). Which would allow programs to be active (doing something without blocking GUI) rather than passive (waiting for GUI event)!
  16. OHML being complete, it just needed something next so the OHML specification is complete. And this thing is what is here: OHTP Definitions: Host - Any computer or machine with a OC-compatible modem attached to it Server - Host sending OHTP-valid data when an user attemps to connect Client - Host receiving OHTP-valid data from a Server OHTP - Open Hyper Text Protocol - Protocol used to transmit OHML - Open Hypertext Markup Language between Hosts. Specifications: The OHTP protocol doesn't take care of what is transporting it. Either it is using a socket API, going through modem, minitel or GERT. It assumes the API or transport layer you utilize supports sockets. Arguments in URLs: To put arguments inside URL, the url must end like normal, but have "?" at end, followed by "property=value" entry. If wanting to add more entries, add "&" after last entry Example: ohtp://1001.1002:1003.1004/index.html?username=admin&password=admin Client-Side: Once the socket is opened, the Client can ask data to Server The Client will send first a Request Header looking like it: OHML/MAJOR.MINOR REQUEST PAGE Example, if the REQUEST is GET, and the version 1.0, with a request page equals to /index.html (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /): OHML/1.0 GET /index.html Currently the valid REQUEST values are: GET (just receive the file) There are also request bodies, which just include "Property: Value" entries. For now, request body is unused, however, there can be non-standard properties, but they must start with "X-" So a request is constructed like that: Request Header( + Request Body) The client, even after having received the Response from Server can still send new requests. All that until socket is closed. Server-Side: Once the Server receives a Request from a client. It must replies with a Response. A Response is contructed like this: Response Header + Response Content The Response Header is constructed like this: ERRORCODE Yep, i know it's really small, making it simple to implement. Currently there are thoses error codes: 200: OK 201: Moved permanently + new URL after ERRORCODE 300: Temporaly moved + new URL after ERRORCODE 301: Switch protocol + approved protocol name after ERRORCODE 404: Page not found 500: Server error 501: Internal error sending the the fetched page (e.g. file found but not accessible from server). 502: Server-side language is errored (Detailled version of 500, optional) 503: Service temporaly down The Response Content is just the content of the fetched file (if found).
  17. For the signature, is the current version of this document is 1.0 (1 as major and 0 as minor) or is it something else? Because it's not written inside the document.. Also, the document says all string are encoded in UTF-8, ok, but must have their length at first, does it applies for the "URF" string part of the signature? There is also a lot of oddities in the entries, you say that if the entry is a file, the specifier byte must be "F", well it's ok because ASCII F byte have 6th and 7th bits equals to 1. However if the entry is a directory you say the specifier byte must be "D", but in ASCII, D equals 68 in decimal, in binary the 7th bit is 0. Also you say a entry should contains Object ID and Parent ID, but where, is parent id first or last? And is it written with 32-bit unsigned integer? Is it an ALI? You're not saying it which makes hard to make a standard implementation! P.S.: Even if document is unprecise, i managed to make an implementation of it, the first URF file is born
  18. I finished the 2nd stage installer, i'll do the 1st stage (installing from OpenOS/MineOS) when i will have more time
  19. Is there any video games for OpenComputers? As this would be cool, and no, i'm not speaking about a chip8 emulator or lunatic86. By that i mean games targetting OpenComputers Lua architecture. If no, that would be interesting to create some. After all almost all the programs i saw on the Showcase are OSes, #### control programs, drone managers, etc.
  20. Fuchas One of the best multitask OS How Fuchas Works Fuchas is a true multitask OS for OpenComputers. By true multitask, i mean it is based on a task manager. To do it simple, the task manager cycle through all the active processes. It also pulls signal with a timeout of 0.05 seconds! (Speed is best). Fuchas is also modular and based on a driver system, the driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs can easily adapt to addons hardware (e.g. Computronics cards), however for now this aspect of Fuchas isn't really well used, a re-overhaul of it is planned soon. If you don't understand all that just retain something: Unlike OpenOS, it can run tasks at same time. (Technically it's not correct, since there is like a ~0.05s delay between tasks, due to Lua nature) The major "sellpoint" of the OS is booting and being in general VERY VERY FAST I'll do proper metrics soon, but Fuchas on a full T3 (T3 CPU, 2x 3.5 memory, T3 GPU) starts almost instantly (less than ~0.3 sec), compared to ~1sec for OpenOS and ~2sec for MineOS Dedicated. On a machine where call budget is always 0 (using an emulator), MineOS is unusable, OpenOS takes literally ~5sec to write a letter, and Fuchas still seems okay. Again, metrics comin g soon. If you don't believe me just try it Interfaces Fuchas, being modular, is about not fair to have 1 interface. That's why there can be multiple interfaces. Currently only one is included: Fushell (basically like OpenOS shell). Soon to come will be "Concert", which is a GUI interface, better suited for multi-tasking. Currently, the only interface to show, Fushell: You might as well as spotted the "pl" and "kill" command. Yep! Thoses are multitask commands I'm not doing a whole documentation here, but basically "pl" lists tasks (called processes internally) and "kill", well, it kill tasks Installing Whatever from what OS you're installing it. OpenOS: Just type the following: pastebin run EbHYvEE8 MineOS: Coming soon.
  21. 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
  22. As far as i know, no, i'm not a OpenComputers developer, however i have some knowledge in Forge modding, one problem they will have to encounter is that making OC compatible with 1.13.x would need changing most of the code (mostly because it makes usage of metadata, and some other things). So it will probably be hard and long to do, since it will be long, i think it will probably be in beta (or something like that) for 1.13, and finished when 1.14 However, this is only what i'm saying, it isn't approved by any of OpenComputers active developers, so considerate what i said as a possible option
  23. Due to how computers, in real life, so also in Lua works, it's logical, the number of bits to store on the number being also finite
  24. uhmm.. can't we have more information on it? Like version, modpack (if needed) ? edit: nevermind, i just didn't looked the title, it's using all the mods 3
×
×
  • Create New...

Important Information

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