Solra Bizna

I just made an activity post on Patreon detailing my recent work on this mod and the current roadmap. For lack of a more suitable place, I'm going to be putting most of my status updates there, rather than clogging the OpenComputers boards. My mind is still totally blown about how successful this has been.

The call in question is a direct one, so I can totally do that. It would even avoid the copy in the normal case of the EEPROM never being accessed again after boot. (Why didn't I think of that? ) Hm. That's a good point. In that case, maybe I should enable it by default...

The way I'm handling the EEPROM is by, conceptually, having reads from memory above 0xFFFF0000 be accesses to the currently-installed EEPROM. What's actually happening is that every time an EEPROM is added or removed (or flashed), I'm copying the byte array off and caching it. I can store the cached byte array and restore it with the other state, but I'd rather not, since there wouldn't actually be a situation where it would be different from the current state of the EEPROM. It's just a question of when I do the copy, really. The difference between this approach and the approach used by the Lu

Thanks! I made a mistake with the link. I'll edit to fix it.

That thoroughly answers all my original questions. Thanks. Now I have new ones instead. I can definitely see why this is done the way it is, particularly since the Lua architecture doesn't (and, really, can't) have built-in fine grained timeslicing. My own emulation code, however, is designed with precisely controllable timing down to the cycle level. If, some day, support were added for architectures with "hard timing", being processed as part of the world tick... my architecture, at least, would be ready to support it. (Hypothetically. ) So, my current plan timing-wise is to have runThr

(I don't know if this is the right forum to post this in, but I didn't see a clearly better one.) Still working on my custom architecture, and I've got some open questions, mostly about issues of time. First, I note that `runThreaded` can return a "sleep" result. Does the worker pool operate such that `runThreaded` is called repeatedly on every non-sleeping instance, and only when all are sleeping is a game tick allowed to complete? If so, is there ever a situation where a number of game ticks other than exactly the requested sleep period will pass? (Consistency with "real" time is irrelev

Yay! (Except that it doesn't have the "[JARM Prototype]" bits which the readme said should be there. I guess those aren't always there. Oops. >_>)This gives me an excuse to say that, after dealing so much over the last year with Minecraft's insanity, and after the last few months of fumbling in the dark between bits of untested code, the actual code to interface with OpenComputers was a breath of fresh air. The third or fourth time in a row I had a nontrivial question, and the answer turned out to be "The way that actually makes sense, and gets good performance"... I realized that this w

After months of blood and sweat, and thousands of pages of reference manual, the prototype is here. It's a cobbled-together proof-of-concept, but a "proofy" one nonetheless. An alpha-quality emulator is there, in Minecraft. Download it and give it a try! Now that I have a prototype, I have set up my Patreon page. Please consider supporting me so I can continue to invest time in this project. Even a few pledges of $3/month would get me to the point where I could carry this project to completion. (At a significantly greater pace than brought it to prototype, since I would be able to better j

Still going! I spent an inordinate portion of the last several days hunting down that rarest of beasts---a serious, fundamental flaw in the most widely-used toolchain on the planet, which fundamentally breaks an entire class of program, yet has a practical impact on probably just one person. (Edit: Turned out to be a documentation bug at best. Fundamentally breaking an entire class of program without anyone noticing did seem improbable...) The emulator has executed its first instruction. Now I must merely fill in the gaps. Prototype isn't far off now...

I'm not dead, and neither is the mod. The last couple months have been... eventful and distracting. The uncontested highlight was that I managed to get scurvy (again). But that's a story for another day... Now that things seem to be done happening to me for a while, I can return to this mod. Turns out, emulating a complete ARMv7-A system is a lot of work. Almost 2,000 lines of untested code so far. I have a complete instruction decoder for the ARM instruction set, and a decent number of emulated instructions. The current obstacle is coprocessor support, which is necessary to support the s

Thanks. I'll keep that in mind for when I have the basic functionality in place. It claims to be "fast" which tells me it probably employs JIT, which definitely means it will be good to take a look at their approach; I'm not at all sure how to do code generation (and therefore JIT) in pure Java. Currently, I've got most of a bare skeleton in place... the application-level core registers, a memory subsystem... The ARM Architecture Reference Manual is long (2736 pages), and I don't have a lot of time to spare for this, but nevertheless I'm making progress.

I'll get right on that prototype, then. Bare-metal code would be a pretty big application of this... 4KiB isn't a lot, but you can do a lot more with 4KiB of machine code than 4KiB of Lua. (That's around 2,000 Thumb instructions!) Murder doesn't even begin to cover it. Something with paste events and an external packer perhaps? Or a TCP-powered outside server and an Internet card? For my own stuff, I have a webserver that my OC computers can download my working set from. Something like this was the long-term approach I had in my mind. The headers and such could "l

I had a few ideas for how to deal with that. Encoding the maps as a fairly primitive array of tagged key/value pairs was one. This would place the parsing burden on the software, which would be free to permute it to/from whatever data structure it prefers. I was also planning on making some sort of layer where the software could define a packed representation for specific cases and the packed representation would be used when possible. No matter what, IO would be somewhat... unrealistic. Which is fine by me since real IO can get pretty hairy.

Thanks for the reply. I'm glad I'm not the only one enthusiastic about the idea! Even though the jury is still out on whether it's going to be feasible for me to work on this mod, I've done a few hours of research in between (and sometimes instead of) things. I've made a few preliminary decisions: The CPU would be compatible with ARMv7-A, and would boot in big-endian mode to aid interoperability with other computers on the network. (And because I prefer big-endian.) The OS would be named Orca---short for "Open Real Computers on ARM". The variants would be named "Orca Personal", "Orca Professi

Edit: The project is go. My Patreon is up, and scurvy is a thing of the past. Check there for status updates. Edit 2: The project is dead. My problems got worse than I thought possible. Thanks for the support while it lasted; you literally saved me from scurvy. The complete (incomplete) source is here. This is going to be one heck of a first post. I apologize if it violates the TOS; I wasn't able to get the TOS to open, so I assumed it was a typical one. If I am in violation, just don't approve the post and I'll disappear back into the woodwork. tl;dr = Want make mod. Give OpenComputers