Solra Bizna

Fairly early in the OC-ARM development process, the question of component IO came up. I spent a good bit of time doing research and checking my assumptions. Then, I set out to create an interchange format with the following properties: Trivially maps to every object type OpenComputers itself allows (implied by the above) Trivially maps to the Lua representation Feasible to implement in hardware Simple to implement in software Independent of architectural details Compact This is what came out. There are two versions of this format: packed and unpacked. Packed is more compact, and is suitable f

It might be better to have clearly separated subforums for each of {architecture,component}: one for discussing development in general, another for threads for specific mods. Specifications would belong in a general architecture development discussion forum, IMO. Other than that, looks good to me.

If you're interested in compiling programs for this on an Ubuntu or Debian Linux machine, you can save a lot of time and effort by installing the "gcc-arm-none-eabi" package. No need to compile binutils from source, and as an added bonus, my Makefiles won't need to be modified. The simulator now has every intended feature except for touch and unmanaged drives. It simulates an OpenComputers computer with the following components: Tier 3 OC-ARM CPU (Optional) GPU of any tier, with matching screen and attached keyboard Any amount of RAM from 0 bytes to 2GiB EEPROM (not as a "component", only t

I recently resurfaced to work on my ARM architecture. I was already aware of a 6502 architecture, and was thinking of making a 65c816 architecture. I poked around the forums to see what other architecture modules were in development, and found GreaseMonkey's MIPS architecture and evidence of another ARM architecture at least as far along as mine*. A lot of work has been done by separate people on solving the various problems posed by developing a "real" architecture for OpenComputers. (The biggest of course being the component communication problem.) As far as I can tell (from not being on I

Actually, the problem is that I set up my headers lazily. I'm being more careful with this Lua porting attempt, and future code from me will avoid that problem. I know the feeling. I'm still mostly stuck in bed from the ankle fractures. On the one hand, I'm stuck for months... but on the other hand, I don't have all those pesky flu-like symptoms to make me miserable... VirtualBox can only virtualize x86 and AMD64 architectures. If you want an ARM simulator, look into QEMU... it won't do much good for OpenComputers ARM stuff, since it doesn't simulate the OpenComputers hardware, b

Sorry, I missed your earlier post. That's actually a problem with my code. It looks like I was assuming that the system's <inttypes.h> would have support for the ARM platform. That was silly of me. I appear to make that assumption with a few other headers as well, like <stdarg.h>. This is fixable, but it is not an easy fix. It would be eaiser, instead, to get VirtualBox and install some flavor of Linux in a virtual machine, and use that virtual machine to build. I use Debian Linux myself, but Ubuntu Linux is more commonly used.

Don't worry. No matter how many commands you learn, the rabbit hole always goes deeper...

"make" builds everything. Just change to a directory containing a Makefile and run "make". Make is a tool where you tell it what commands are necessary to build things and it automatically builds them for you. Included with the source is a Makefile which tells Make how to use Clang, GNU LD, etc. to go from source code to ROM/ELF.

I used commands like the ones I gave you to build and install binutils. When it's installed, all you have to do is change to the approprite JARM source code directory and "make". If the # you're seeing is in ARM assembly code, the # means "this exact value, as a constant". Without a #, it is taken as a register number instead. It has the same meaning in (at least) PowerPC, 68k, and 6502 assembly. The source code that I released is the latest source code. I'm glad that the comments are helpful, they were a lot of work. One of the reasons I didn't want to start releasing source code unti

Jeez. Getting hit once sucks enough. Hope you don't continue the pattern... I did tear a couple pieces off the car on my way down. I actually think that fight was a draw overall. Don't get too discouraged. You've been working without a safety net, and doing pretty well so far.If you're on a Mac, you're in luck, because you can get most of the tools you need just by installing XCode. That'll include GNU Make (which I use as my build system because I'm OOOOOLD(?)) and Clang (which is the best compiler to use). That'll also give you everything you need to build and install GNU Binutils from

Actually, the error is not related to that at all. The error is a StackOverflowError, which usually results from code calling itself out of control. There have been several major changes to the source code since the last build I released. Those stacktraces won't match the latest code unless you've built my mod from source. Here, in case you don't feel like wasting hours getting Gradle working, is the most recent build I made: http://mcjarm.tejat.net/0.0a2/OpenComputers-ARM-MC1.7.10-0.0a2.jar Note that all previously-released ROMs and programs will not work with this build, because I change

I initially rolled my own malloc, as well as the subset of the C library that Lua uses, in order to keep the size of the ROM down. Borrowing newlib's malloc implementation to replace my broken one is probably a good way to proceed. There are a number of debug-related settings in the configuration file (OpenComputers-ARM.cfg in .minecraft/config). Enabling them may help you get more information.

Most of the .elf files in that archive are just produced as an intermediate step toward making a .rom file, and won't work as an "arm.elf" file. Use "test.elf" (built from the jarmrom folder) to test boot0.rom and your build process. 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).

Where are you getting arm.elf from?

I used Clang as compiler, and the GNU linker. I really recommend going that route, because it's relatively easy to set up; any recent install of Clang should work, the only troublesome part is getting an ARM-oriented build of GNU binutils to go with it. (Yes, I'm still alive and following this thread. I am unfortunately too busy to pick up the mod again as yet, but I will try to help any way I can regardless.)

Unfortunately, I can't work on the project anymore. I hate to abandon the project after it generated so much interest. I really tried to keep it going, but it was taking months to achieve a few minutes of work, at disproportionate emotional cost. I hope somebody else picks up where I left off.

I know I "officially" killed the project weeks ago, but now that I've posted the complete unfinished source code it really feels dead. Sigh.

There've been a couple of big delays. The first is that I had a server-related crisis, which is now thankfully over. The second is that I recently started taking a medication which has devastated my sleep, concentration and short-term memory. I've only been on it a week, so there's no telling yet whether this side effect will go away. If it doesn't... I'll just have to adapt. Either way, I have just a few bits left to do in my Lua port, after which I plan to make another alpha release. There's probably less than 10 honest hours of work left before that point is reached. Unfortunately, I ca

Sorry about that. Half the "servers" I used to have became impossible to keep online. I've re-uploaded it to a more permanent server and updated the download link in the original post.

This post took way too long to happen. Cursed distractions. It's less awkward if you think of it as thanks for work already done rather than payment for ongoing/future work. This doesn't apply to my own Patreon since I haven't yet released my mod in a usable state; but OpenComputers is already quite mature, and is being used and enjoyed by lots of people as we speak. A Patreon would be a great way for some of those people to give tangible thanks.

Hooray for Heisenbugs! I never noticed that in my testing, but I did notice that key_down signals seem to occasionally be dropped during rapid presses. The game doesn't actually parse any signals other than key_down. I vaguely recall that runThreaded is supposed to consume exactly one signal if one is present, but my implementation can consume any number of signals in one runThreaded call, depending on how many the program happens to pop (with an internal single-signal queue). I'm not sure how deep OC's per-machine signal queue is, so I don't know how much of a problem that is... Thin

That's very odd. I had something similar happen in one of my test worlds, and once it happened ARM CPUs never ran again in that world. In that instance, I tried repeatedly to catch one of the worker threads executing my code, and couldn't. (I'm not very familiar with Eclipse's debugger.) Creating a new world "fixed" the problem. If you set traceInvocations=true, does anything show up in the log, like "sleeping for 2147483647"?

OpenComputers architecture module providing a full 32-bit CPU. It simulates a 32-bit ARMv7A processor with a tiny on-die SRAM. I'm not working on it anymore, and that's not going to change. It's open source, so feel free to fork it and finish what I started. (Start by making things OETF #1 and #2 compliant.) Current "stable" alpha release is 0.0a3 and can be downloaded at GitHub. If you're on a UNIX-like (Mac or Linux), you can use occross to build cross compilation tools for this architecture. Some useful programs and a build system that can be used to make more of them are also on

As far as I can tell, there isn't a way to donate to the OpenComputers devs. Which is a shame. I've poked around in OpenComputers' insides a lot recently, and I have to say... Most other mods are fun ideas held together by duct tape, but OpenComputers is professional-grade work. I'm not even sure I'd rate my own modding work that way. (There is, however, at least one server out there that puts OpenComputers access behind a paywall. EULA violation aside, I'm not sure I like that...)

Release of an alpha version of the ARM mod is near, and I'm now thinking about how to get new prefabbed EEPROMs / floppies into the game. What would be the best approach? (Edit: Ack! This isn't the Support forum! How did I end up here?)