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

[MC1.7.10][OC1.5.x]ARM Architecture "OC-ARM" (alpha, updated 2016-06-07)

Recommended Posts

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 GitHub. Lua boots, OpenOS runs, and it can mostly install to a hard disk. The whole thing is an exercise in patience; Lua does not run fast on a 500KHz machine, even at one instruction per clock. (Later, if JIT is added, one should be able to up the default speed to the order of several MHz without excessive Minecraft load.)

Missing features, in roughly the order they'd need to be added: Completed test suite, interrupts and exceptions, virtual memory.

Link to post
Share on other sites

Hmm, just gave it a try, but nothing's happening? I.e. I can turn on the computer just fine, and it keeps "running", but nothing is happening. `doDaylightCylce` is true, not that that should matter. I had a look at the CPU state with the debugger, and the PC (not personal computer, program counter :P) never changes. Any ideas?

 

Setups tried: Creative Case, T1 through T3 CPU, with and without RAM, GPU1 through 3, Screen T2+Keyboard, tetris.rom flashed to EEPROM.

Link to post
Share on other sites

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"?

Link to post
Share on other sites

Welp, this then officially puts this in the "random bugs" category, the most annoying of all: it's working now, with and without that option (and yes, it does log that).

 

Looking awesome! It does occasionally seem to miss a key-up or something, because at some point blocks tend to start coming down pretty much immediately? At least I'm assuming that's what's happening, could be something else entirely.

 

Really cool demo!

Link to post
Share on other sites

Welp, this then officially puts this in the "random bugs" category, the most annoying of all: it's working now, with and without that option (and yes, it does log that).

Hooray for Heisenbugs!

 

It does occasionally seem to miss a key-up or something, because at some point blocks tend to start coming down pretty much immediately? At least I'm assuming that's what's happening, could be something else entirely.

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...

Thinking about it, it seems possible that the world time jumped ahead. The game stores the current world time at the start of the game, determines whether "time has passed" by checking if the world time is greater than the stored time, and adds a "fall period" to the stored time every time it passes. There wasn't enough room in the ROM to handle edge cases in the timing: if time stops or goes backwards (as with /time set), the stored time will take forever to arrive and pieces will remain suspended; if time jumps significantly forward, the stored time will "arrive" instantly for a large number of "fall periods" and pieces will insta-fall (and the game will quickly end).

 

Really cool demo!

Thanks!
Link to post
Share on other sites

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 can't even manage a few minutes per day right now. I've honestly been considering shutting down my Patreon so that people aren't paying for work I'm not able to do.

 

The emulator core is still missing some major bits: Thumb encoding, virtual memory, and a dozen or so obscure instructions. Otherwise I would document and release it now, with source. None of those things are important to the Lua port, but they will be important to "real" applications, especially operating systems and highly-tuned EEPROMs.

 

By the way, posts like yours encourage me to keep trying to work on this project. No need to apologize at all.

 

Edit: I spoke too soon. The server crisis continues. Edit 2: And now it's over. For real. I hope...

Link to post
Share on other sites

is there any chance i can attempt to rescue this thread i don't have much experience in java coding but i am learning so as one of my projects i would like to attempt to bring this mod back, of course i will and always will give credit where credit is due (in this case you and if you have one you're team), do you mind if i take the source code and revive this add-on?

Link to post
Share on other sites

how in the world did you get any of the files on EEPROM, every time i tried OC simple reverted my changes, don't ask my how i have no clue what so ever, if anyone could gimme a quick tip as to start this mod running so i can see where its at i would be more then willing to give it my best at updating it and finishing it

Link to post
Share on other sites

so, i have reached a large choke in the process of reviving this mod. i can work on the java, but i am just now starting to learn C and 68k so if someone would be kind enough to lend a hand that would be great until or past the point that i have learned C and or 68K please PM me for details and modified files

Link to post
Share on other sites

Well I'm a decent c/c++ and a a-bit-less-then-decent assembly programmer, but I also understand java and Minecraft modding.

If you need help you can ask me but I don't have a great deal of time so you should maybe get someone else in.

Link to post
Share on other sites

YEAH replies on a dead thread. tim and help would be better then no help, i need someone who knows c primarily because how ARM works is C to 68k via compiler. but right now i am not trying to get someone to help me go crazy i just need someone to debug the c for a specific file. it keeps throwing an error and i have no clue how to read c. i am learning but still have no clue

 

P.S. i like how 2 posts means a topic is hot on this forum, we need more community

Link to post
Share on other sites

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.)

Link to post
Share on other sites

Ha your back, i new you where alive. thanks for the help there i couldn't seem to get the official ARM studio to work on my linux so i started looking for others. i have learned a fair bit already but i am still missing many vital parts to even starting to work on this mod, for example i don't know C i am learning it slowly but i don't know it, oops. it took me 3 months to figure out that i need a hex dump to "read" your elf files. then i found the source code in a different folder (all my work figuring out how to "read" it and it was already easily readable). thanks for offering your hand. i will be glad to take you up on it. good to see you back on the forum!

 

I don't know if this was a problem when you put the mod on hold or not, but boot0.rom combined with arm.elf likes to error out "Internal error this is likely a bug", any ideas whats causing this so i can narrow down my search to fix it?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

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