GreaseMonkey

Besides, in a Minecraft mod you do not have enough resources to run a proper operating system.

MS-DOS is a proper operating system. Writing an x86 emu will be a pain in the arse, but there's enough resources to do it.

Heck, I got pretty close to getting Linux to mount root w/ OCMIPS.

I did have to modify the config to allow 8MB of RAM though, but allegedly you can *juuust* squeeze Linux into 4MB of RAM.

For extra fun, I managed to get Lua 5.3.2 (~350KB) to boot off a T1 stick of RAM (192KB) using a virtual memory microkernel.

I would argue that it's possible to emulate a C64 - probably not at full speed or accuracy - in Lua. The real thing has 64KB of RAM.

Technically it's a proper operating system.

those are all in their "alpha" stages.

OCMIPS is complete enough in the emulator department. It just lacks software.

Once that's working, the best way to proceed involves getting "lua.elf" (built from the luarom folder) to stop crashing (the bug is in the malloc implementation somewhere).

What libc are you using? You can just use newlib.

TIP: sbrk() returns the value of the break before it was called. Here, have a completely free* implementation:

 

#include <stdint.h>

extern char end;
void *current_break = (void *)&end;
void *sbrk(intptr_t increment)
{
  void *ret = current_break;
  current_break += increment;
  return ret;
}

*it's also completely untested. but hey, it's free!

EDIT: I had a look at your code, it appears you've rolled your own malloc(). TIP: Use the memory allocator that newlib provides in its libc. Then you only have to write sbrk().

12. #oc, where people actively avoid calling Sangar by any names that might namedrop him.

1. Lua is not an acronym. With that said, that could be pretty cool.

2. Look for something called MineOS. It kinda does what you say but it's more based around Mac OS X aesthetically.

3. This is an exercise left to the reader.

4. This would be useful. It's the sort of thing you'd put on a loot disk.

5. There's a competition on right now. You should have your entry done by about the 20th of July. As for you specifically, you should have a go at this - it doesn't have to be a technical masterpiece, just have a go at it, it might be really fun.

10. #oc, the constant sound of software falling apart.

There's a couple of custom OC architectures floating around that could benefit from this.

Really, we need people to write software and we don't have in-mod C compilers yet.

I'll give you my setup (with a few distro-specific things stripped out):

../binutils-2.25.1/configure --target=mipsel-none-elf --disable-multilib --disable-nls --enable-lto
../gcc-5.3.0/configure --target=mipsel-none-elf --disable-nls --enable-languages=c,c++ --enable-lto
../newlib-2.3.0.20160104/configure --target=mipsel-none-elf --enable-lto

For ARM I use arm-none-eabi as my target, but arm-none-elf might work better.

If you're on Windows, you'll probably want to use Cygwin to build this stuff. MSYS might also work if you prefer that.

If you're on Linux or BSD, you shouldn't need anything fancy.

Basically, you'll want binutils, gcc, and newlib. You build them all "out of tree".

Step 1: Binutils

Here's my setup. Version numbers and targets will likely be different, although number of make threads may be the same.

 

mkdir xbinutils-mips
cd xbinutils-mips
../binutils-2.25.1/configure --target=mipsel-none-elf --disable-multilib --disable-nls --enable-lto
make -j8
sudo make install
cd ..

With a fairly beefy system it should build in under a minute.

That's the easy bit.

Step 2: GCC, part 1

You only want to build part of this. Look closely at the make commands.

 

mkdir xgcc-mips
cd xgcc-mips
../gcc-5.3.0/configure --target=mipsel-none-elf --disable-nls --enable-languages=c,c++ --enable-lto
make -j8 all-gcc
sudo make install-gcc
cd ..

If you got that working, good job. If not, please give me the info I need to know.

Step 3: newlib

This is a libc implementation designed for embedded software.

The general idea is that you compile something, find out what syscalls are missing, then implement those syscalls.

Enough about how to use it, let's actually build it.

 

mkdir xnewlib-mips
cd xnewlib-mips
../newlib-2.3.0.20160104/configure --target=mipsel-none-elf --enable-lto
make -j8
sudo make install
cd ..

Step 4: GCC, part 2

Oh, you thought you were done? WRONK.

By the way, DO NOT RECONFIGURE YOUR COMPILER.. Just do this:

cd xgcc-mips
make -j8
sudo make install
cd ..

EDIT: If you have C++ enabled (as you would if you just use those config lines), libstdc++ whinges about it not being supported or something like that. Here's the fix:

In gcc-*.*.*/libstdc++-v3/configure, find this line and comment it out like so:

 

    #as_fn_error "No support for this host/target combination." "$LINENO" 5

I found this at line 78194 (GCC 6.1.0), so please please please use your search function.

Step 5: Compile things

If you got through those 4 steps without any errors, find or make some stuff to compile and compile it. Whee!

It depends on the architecture that you are using. Feel free to bug the maintainers of said architectures on how to write software for their things.

Also, knowing how to write GNU linker scripts helps... at least some of the time: https://sourceware.org/binutils/docs/ld/index.html

Have fun!

OCMIPS is a mod for OpenComputers which adds a MIPS-I architecture core.

Status:

- The CPU itself is mostly complete.

- It's sorely lacking in software, although Lua 5.3.2 runs (or at least used to).

- It's got an ELF bootloader EEPROM.

- I used to be able to boot Lua off a T1 (192KB) stick of RAM when run atop Mocha + libgreen, but I accidentally broke stuff so I still need to fix that.

- The component API currently sucks. Here's a proposal that should help make it suck less for some components.

OCMIPS source: https://github.com/iamgreaser/ocmips

If you want binaries, lurk on #oc and I spit them out from time to time, although this old one might work (link is for a 1.7.10 version; github should have 1.9 stuff).

For building a cross compiler, I use binutils + gcc + newlib.

Feed "--target=mipsel-none-elf" into the configure scripts.

When building gcc, use "make all-gcc" and "sudo make install-gcc" for the first stage, build newlib, and then continue with "make all" and "sudo make install".

"--enable-languages=c,c++" should work fine. Fortran support needs to be whacked with a hammer initially so you may want to skip that unless you really need it. Other langs not tested.

Latest screenshot:

Cache works!

Mod Edit:

Pinned

~ Liz

Due to Minecraft's 20Hz tick rate, it should be completely adequate to implement a PLC environment as a program.

It shouldn't be hard to compile to Lua source code anyway... assuming you've parsed the input of course.

Let me make this post readable (no really this looks absolutely awful in my browser - use the "code" tags if you're going to do something like this post):

https://gist.github.com/iamgreaser/a8cf17906b0a799851087eed4181ea87

Note, I could only make about a third of it readable as after that point I just gave up where it started to get inconsistent.

----

This is OpenComputers. It is not OpenPCs. Not every computer is a PC.

I would say that the computer that most of your friends use all the time does not resemble a PC at all.

It's called a "smart phone", or as I like to call it, a "surprisingly fast yet nigh unusable sack of crap that fits in your pocket".

What do you expect to be added next, Windows? That will never happen.

If any Windows version does get ported it'll be one that you've never used. (Hint, the name will probably end in "for Workgroups".)

#1 & #2:

There's no need to have a laptop when we already have tablets.

What would a laptop even add?

You can't really say "this goes faster" - the support isn't there. Even if it was, it's in the CPU, not the case.

While having a motherboard might sound intuitive, there's no real need to take this approach when we already have a server rack.

#3:

Depends on #1.

#4:

Isn't this assumed to already be part of the case?

Really, what does this actually add, other than an unnecessary step?

Furthermore, not all computers have fans in them.

By the way, what defines a power supply? It provides power.

The fan does not define the power supply, and the power supply is not the only thing that can provide a fan.

With that said, I'll illuminate the first actually usable idea I've managed to scrape out of here:

Idea #1: Make it possible for components to get hot, and to provide ways to cool components.

The best punishment for this for a Lua CPU would be to make the CPU skip ticks.

For a more conventional CPU you could slow down reads/writes.

#5 & #6:

#6 is redundant and really should be part of #5.

#5 has been proposed before. It's also something I would benefit from (the Linux kernel isn't small).

Either way, I might as well isolate this idea:

Idea #2: Add SSDs - disks that have fast access speeds.

#7:

It's possible to have multiple GPUs already. It's kinda cheating, but it does improve rendering speed.

The catch of course is that in multiplayer games it stresses the server's connection even more.

It does not need to be called "SLI" or "Crossfire" and to be blunt it never should be called that.

If you want that control panel, that is your responsibility. I'm not making that for you.

#8:

Coming up with a buttload of different CPU items is just going to confuse matters without actually providing anything useful.

"MULTI-CORE SUPPORTED"

I had this idea a few days ago and was considering posting it as a joke.

It turns out it's not actually as bad as I thought, but to be blunt it's completely unnecessary.

Of course, nothing other than insufficient programming skill is stopping you from making a mod for OC that adds an SMP core.

But what is it going to do, call coroutine.yield more often?

Multi-core CPUs don't make sense in Lua.

As for a "real" CPU, it's a pain in the arse to emulate unless you only emulate it loosely by running two emulator cores in different threads.

There's a reason I was going to post this proposal as a joke.

As for having two CPUs in the same computer... it's kinda pointless when you can just get two computers and connect them to the same component network.

#9:

More item spam for the purpose of fulfiling some urge to level up. Are you sure you don't play games on Facebook?

#10:

And out of the blue, an idea that might actually be useful:

Idea #3: Some way to extend the range of wireless things?

It's a bit vague though, so you'll have to explain further.

#11:

Please take your graphics control panel idea and stick it where the sun don't shine.

With that out of the way... what the heck IS an extended monitor anyway?

And with THAT out of the way... the next good idea:

Idea #4: Projectors!

It'll be kinda hard to pull off though. I was thinking that some sort of shadowing algorithm would work, but it would be better and much faster to just make a polygon mesh on the fly.

#12:

One word: Computronics.

Yes, this one exists... sort of. For sound there are a few "sound cards" e.g. MassSound that you could try.

They're all extra mods though. To be blunt, OC doesn't really need them built in.

#13:

See #11.

#14:

If you want a wireless GPU, set up an extra computer and write a program to relay GPU commands.

#15:

As this idea depends on some crap written by ChickenBones, this is a mod you'll want to write yourself.

Once again, if you want control panels for everything, write them yourself.

The rest of us will be happy with a CLI.

#16:

A 720KB floppy disk would be nice (NOT 700KB THAT'S NOT A VALID FLOPPY DISK SIZE).

A read-only high-capacity storage device would also be nice.

Otherwise you're just adding unnecessary crap in the name of "this resembles my PC more"

#17:

A YouTube player would stress the server's connections a bit too much.

Also, video decoding is hard.

Having said that, shameless plug, but it IS possible to make OC play video.

A general internet browser would be an interesting challenge. I'm not sure if there's one on oppm or the other package manager already.

Relevant Lua 5.3 manual section in case you want to know more about require: http://www.lua.org/manual/5.3/manual.html#pdf-require

The error says that handler is currently being loaded when it calls itself. Here's a possible workaround:

  local Handler = {object = {}}
  local workspace = {
    shell.getWorkingDirectory().."dir1",
    shell.getWorkingDirectory().."dir2"
  }

  function Handler.init()
    local key, dir
    for key, dir in pairs(workspace) do
      local element
      for element in fs.list(dir) do
        local s, e = string.find(element, "%.")
        local ext = string.sub(element, s + 1)
        local title = string.sub(element, 1, s - 1)

        if ext == "foo" or ext == "bar" then
          if Handler.object[ext] == nil then Handler.object[ext] = {} end
          local result
          result, Handler.object[ext][title] = shell.execute(dir.."/"..element)
        end
      end
    end
  end

  return Handler

and then in your main code:

local handler = require("handler")
handler.init()

--For example
local k, v
for k, v in pairs(handler.object.foo)
  v.run()
end

Also, use local more. Otherwise, you can easily bite yourself in the arse like so:

function getkey(t, kval)
  for k, v in pairs(t) do
    if v == kval then return k end
  end
  return nil
end

for k, v in pairs(foo) do
  k2 = getkey(v, "derp")
  if k2 then print(k2, v[k2]) end
end

I am currently studying C++ and know nothing about Lua. I know Batch pretty well

Let me help you rethink your life:

Lua's easier than C++ and you'll probably enjoy it much more.

It's fairly lightweight but there's some funky stuff you can do with metatables and closures and whatnot.

Also, join us on IRC, seriously.

As long as you can read some documentation and have some idea of how to use a search engine, you'll do just fine.

----

While I'm at it, might as well address this point:

Sadly, I doubt machine code will ever be a thing as it's a really big task

to emulate an actual CPU and have it run smoothly enough, load code from EEPROM,

and have all APIs implemented and stuff. Maybe someone will take on the challenge

some day, though. I'm shrugging heavily at whether or not there is a possibility.

I'll use OCMIPS as a reference. Sadly there's no post here (memo to self, get back into this stuff).

During testing (prior to actually making it into a Minecraft mod) I could get about 70-100MHz.

Current version has virtual memory, though, thus you'll probably get a slower speed;

however, it apparently does achieve at least 40MHz (higher frequencies have not been tested).

The provided EEPROM bootloader loads a statically-linked ELF file.

Yes, even with every instruction taking up 4 bytes, you can fit it in comfortably.

IIRC it took less than a week before the damn thing could run Lua. Another reason why MIPS is awesome.

(Of course, you also have newlib to thank. That meant I didn't have to write *too* much code to get it to work.)

I think it took a couple of days to get virtual memory working,

then a few more days to get a nanokernel working that could run the ~350KB of Lua 5.3.2

off a T1 stick of RAM (192KB), with about 72KB RAM spare... in about ~20 minutes.

(Disk I/O isn't instantaneous. Given sufficient RAM it takes about 5 seconds to load.)

Thus, AFAIK OCMIPS is currently the only architecture that can run programs that are bigger than RAM... without cheating.

(I don't know how far the ARM architectures are right now.)

APIwise I only have a few syscalls implemented.

I'll probably have to use a modified Lua REPL for the component and computer libraries,

as currently mocha (the nanokernel I wrote for this) doesn't handle more than one file for virtual memory mapping.

The ideal would be to get a standard OCMIPS system to be self-hosting.

Unfortunately, I've yet to get any lightweight C compilers working, so at the moment that's just a pipedream.

But to address this point:

Implementing an OS directly through this mechanism has little interest, and I'm not sure it can be done (Hint: It probably can.).

I almost got Linux to mount root properly.

It's impractical though, as you pretty much need 8MB of RAM.