The purpose of this thread is to gauge interest in a collaborative Virtual Boy emulator project within the PVB community. First and foremost: you don’t have to be a developer to help out! There’s a lot of thinking that needs to be done, and I know this community has a lot of dedicated, talented and diverse members, so my hopes are high.

Before any work can be done, though, it’s important to see where everyone stands and how to best tackle the project. Ergo, this thread you’re reading.

Open Source

Developers welcome, but even if I do the programming myself, I’m totally fine with that. Either way, the project will be open-source and a version-controlled source repository will be open to the public… well, it might be restricted to PVB members, but that’s public enough.

I have made one executive decision, though: the main trunk of the project will be written in the C programming language. Not C++, but vanilla C, for the sake of simplicity. C is about as close as you can get to machine code without writing architecture-dependent programs, meaning it’ll be about as fast and memory-efficient as they come.

Additional languages are welcome as ports, and I’d love to see a Java version maintained alongside the C project, but even if it’s just C, that’s fine for now.

Now my question to you guys: What kind of version control solutions are out there? I have a passing familiarity with git and Mercurial, but I don’t know what would be best to use because I don’t work with collaborative projects all that much. I understand git is about the most common, so there’s a better chance of people being able to use it (Linux command line is a big boon here). I welcome any input, as this is not my area of expertise.

Emulation Core

At minimum, the job of the emulator will be to run Virtual Boy software on computers that are not Virtual Boys. That’s what emulators do, and emulators don’t need to do any more than that. The core module of the emulator project will be just that: something that runs the software and nothing more. Let me explain…

Envision a C library with a source file or two and a header file. You build these into your application. You prompt the user for a VB ROM file, and with just a couple function calls, you’ve got a fully-functional Virtual Boy emulator at your disposal! Granted, I/O will be handled by your application, but you just pass in the user input, process a frame, and all of a sudden you have audio buffers and image pixel data that you can display to the user. Easy!

Also, 3DS homebrew. Just sayin’.

The emulation core module of the project will be only the code required to emulate a game. No I/O stuff (not even disk access for loading files), no GUI stuff, no nothing. Just the emulation part. This will enable the core to be portable to just about any application capable of running C code. Or if not, it can be built into a dynamic library (think Windows DLL) that can be used from just about any language.

Debugger

One of my pet peeves with emulators is that they seldom have useful debugging tools. I like to do a lot of hacking, and when I have things like memory-access breakpoints or “step out” at my disposal, things get a lot easier.

Some of the things I’d like to see:

• Runtime disassembler with break, step/in, step out and step over.
• Read, write and execute breakpoints on ranges of addresses.
• Pattern breakpoints. For example, pause execution whenever a certain pixel pattern gets written to CHR memory. Could also apply to audio memory or RAM in general if known data is being hacked.
• Function isolator that tracks the addresses of functions at runtime as the are called, and can parse apart where each function starts and ends within a ROM. Notes or high-level code can be associated with each function and saved to disk, aiding in reverse engineering or decompiling games.
• GUI interfaces for CPU state, RAM, video memory, audio memory and hardware components like the timer or link port.

Anyone else with a hacking background have anything to bring to light?

Recorder

Once upon a time, recording features were used in emulators to produce “movies” that you could send to other users, perhaps demonstrating how to do something in a game. Lately, recording and re-recording from savestates has become more popular in the “TAS” community (or tool-assisted speedrun). I want to accommodate TAS users.

While I’m no TASer myself, I’ve done some research on some of the ways people do it:

• Slow-motion and frame-step are required for frame-precise input.
• An on-screen controller should be present to allow the user to determine input via mouse for each button on each frame.
• Savestates are used extensively for when something goes awry. A particular path through an RPG dungeon might avoid any random encounters, for instance. In the spirit of “try, try again”, a state might be loaded several times in order to produce just the right results.

Bundling this all together, I’m thinking about a record file that contains not only save states along with the input log, but also allows for branching input paths using save states as nodes in a tree. That way, the user can examine which path is most efficient depending on what parts of the game they try to skip or whatever. I can see it working where multiple branches can be played back simultaneously on-screen, giving the user a much better picture of which branch is best.

Somehow or other I need to devise a practical means of frame-stepping in reverse. I’ve thought about it many times over the years but never settled on a satisfactory technique.

How about you guys? Any experienced TASers have any insights or wishes?

It’s not time to turn in our homework yet, but Gookanheimer and I have made some handsome progress.

Attachments:

1. 

   aspromised.png
   

I brought the handsome, Guy brought the progress.

[Guy Perfect]

It’s that time again, and attached to this post are the spoils. It’s only built for 32-bit Windows at the moment, mainly because Debian has an older version of SDL and I’ll need to build my own cross compilers for the ARM architectures, but hey, there’s the source code!

To use it, find yourself a Virtual Boy ROM file and drag it onto app.exe.

Controls:
• F6 – Step Over (works on functions and branches alike)
• F7 – Single Step (aka Step Into)
• Up – Scroll up (experimental – somewhat buggy)
• Down – Scroll down (experimental – somewhat buggy)

Eventually the emulated program will hang because it’s waiting on some hardware activity. Wario Land in particular checks for the VIP ready status, which of course never comes because that component isn’t implemented yet. If that happens during a Step Over, then the actual emulator program will hang as well, but such are the joys of alpha development.
__________

So what was done in August?

Emulation Core

This thing is every bit as delicious as I hoped it would be. There’s a single object type used to represent the entire emulation state of a virtual Virtual Boy, and a handful of API functions for working with it. You supply it with a ROM file and tell it to emulate, and off it goes.

Like mentioned before, various control points can be hooked into by the application to intercept things like bus accesses or pause before an instruction is executed. Clever use of these control points can enable things like disassembler and cheat engines to work without bogging down the library with excess code.

The disassembler in this build doesn’t actually use these control points. It just runs the emulate command with a maximum cycle target of 1, meaning it will break after every instruction. Lazy, sure, but again, this is what we call “the alpha stage of development.”

CPU Emulation

A joint effort between myself and handsome up there, the CPU emulator is very nearly implemented in its entirety. The missing features are bit string instructions (pending research), floating-point instructions (pending development) and exception handling (NP was set, what was I to do?).

Each instruction has its own function called by the library, and the library can be compiled in one of two ways depending on the compiler and speed of the target platform: use a big switch statement, or use function pointers. Never too many options, I guess.

Every instruction takes some number of CPU cycles to complete, and bus accesses may factor into that. Cycles are tracked and enumerated, and additional features will make use of that figure in order for everything to remain properly synchronized. When the time comes, all the other hardware components will be told to “do whatever you can in this many CPU cycles.”

GUI Subsystem

You wouldn’t know it from this program, but there’s a full-featured GUI subsystem in there. It supports a hierarchy of elements–each of which can have nested child elements–and handles mouse and keyboard focus on all of them.

I ended up doing the exact opposite of what I said I would do: I wrote a wrapper around SDL for cross-platform support and I’m doing the rendering with OpenGL directly. These decisions were made because SDL’s setup isn’t really analogous to how the emulator application works, and because OpenGL gives us some useful tools that SDL’s rendering API doesn’t.

Simple font support was implemented, and will be expanded in a future build. All fonts will be bitmaps in this program, and Unicode will be supported. Right now, only block 0x0000-0x00FF is supported, but the plan is for strings internal to the application to have full support for UTF-8 up to 0xFFFF, save for some fancy things like combining diacritics and oddball control characters (right-to-left, etc).
__________

So what will be done in September?

I don’t know about you, but I’ve always felt like having “only the CPU” was kind of a small step in terms of writing an emulator, but every time I sit down to think about it, I realize just what a percentage of the overall project it really is. The remaining system components are way less complex and will not take as long to implement, so I think this project is going to come together a lot faster than I expect.

That being said, I have some goals for September:
• Implement CPU exception processing.
• Implement the VIP. The whole VIP.
• Implement the game pad interface.
• Create basic GUI controls (buttons, scroll bars, etc.)

If time permits (aka “stretch goals”):
• Finish UTF-8 font support
• Create fileopen dialog
• Create disassembler window
• Create memory hex editor window

Something we here at Planet Virtual Boy can do in the mean time is toss around some designs for the user interface. What would you like to see? How would you organize things? What tools do you want to have at your disposal? Now’s the time to talk about it, because we’re nearing the time when we can make it happen.

Alright kids, see you on September 30!

• This reply was modified 8 years, 2 months ago by Guy Perfect.
• This reply was modified 8 years, 2 months ago by Guy Perfect.

Attachments:

1. pvbe_20160901.zip

[Guy Perfect]

EDIT:

The following post was partly based on an assumption that turns out to be false. The fact of the matter is that C# and .NET simply cannot incorporate stock C code like I thought it could. Toss in the cross-platform considerations and .NET is kind of not really an option.

We’re pretty much down to just C or Java at this point.

__________

I have a dilemma. I’d appreciate any and all insights before I drastically change the project requirements.

What I’m considering doing is keeping the C89-compliant emulation core library branch of the project, but trashing all the GUI work and using either Java or .NET for the application.

Not that I’ve encountered difficulties, mind you. I’m actually having a lot of great success with the GUI side of things and am quite proud of the API I came up with. It’s just that the strengths of application-centric development platforms and the relative weaknesses of C for application development are really making themselves apparent.

I’m a big fan of Java when it comes to application development, but I find myself leaning towards C# thanks to its ability to straight-up use C code verbatim. Cross-platform concerns come to mind, but the Mono project seems to be picking up speed lately, so it would at least run on all our target platforms.

I don’t much like the idea of requiring our developers to install Visual Studio, but at the same time, it’s not ostensibly different from requiring them to install the JDK, and I also don’t like the idea of porting the emulation core library to Java and maintaining two versions of the same thing in tandem.

Tell me your take on this situation, mysterious reader. Which path should lead to the future?
• Continue implementing GUI stuff in C code, missing out on a lot of modern features, relying on SDL for cross-platform support
• Use C#, allowing the C library to be used, relying on Mono for cross-platform support
• Use Java, allowing the application to run on many platforms, but require maintaining a ported copy of the C library

• This reply was modified 8 years, 2 months ago by Guy Perfect.

1) Great work!

2) Is there a makefile or other build script/instructions available? I’m using MinGW, and I’d like to be able to make the odd contribution now and then.

3) To answer your question, I would prefer that you stick to plain C, or maybe C++ (but whatever you do, please don’t add a V. Studio dependency on Windows).

4) If you must add a non-C language for the GUI, you could do much worse than my personal favorite scripting language: Ruby.
* It’s easy to learn.
* It runs on all the target platforms (and is easy to install on any of them).
* It’s built to allow easy wrapping of C code inside a “C extension” (and there are even tools like SWIG which perform most of the work for you).
* If you don’t need a “rubyish” OOP interface, you can simply call functions inside DLLs from Ruby code.
* There’s a great, well-maintained, cross-platform, graphics/input/sound library for it called Gosu (which is a clean, well-designed API wrapper around SDL2 and OpenGL. BTW, it’s written in C++ and the Ruby version is made using SWIG). It already does fonts (using TTF, but individual characters or the whole font can use custom bitmap images) and text input. You can even incorporate custom OpenGL code into its pipeline.
* There are many other useful libraries available in the form of “gems” (at http://www.rubygems.org/) installable with a nice package manager that comes with Ruby (e.g. getting Gosu is as easy as “gem install gosu”).

5) The word “acknowledgment” is misspelled in the copyright notice.

RunnerPack wrote:
2) Is there a makefile or other build script/instructions available? I’m using MinGW, and I’d like to be able to make the odd contribution now and then.

There’s a makefile that I set up to compile for different platforms depending on the target name passed to the make command, but I ran into some complications when it came time to set up the build environment in a VM.

Turns out you have to build your own cross-compilers that run on the platform of your choice to do the compiling–OS distributions don’t pre-build compilers for other architectures for you. Keeping these up to date means periodically rebuilding them from source.

Another problem is that there’s no elegant way to do Mac development without developing on a Mac, and I don’t have a Mac. It’s possible to copy over all the headers and libs, which I’m not opposed to doing, but it can’t be updated very easily.

RunnerPack wrote:
3) To answer your question, I would prefer that you stick to plain C, or maybe C++ (but whatever you do, please don’t add a V. Studio dependency on Windows).

I’ve been going back and forth on this one all afternoon. I don’t want to add another development language into the mix, but doing so comes with a lot of benefits. Those issues regarding cross-compilers and Mac OS don’t apply to Java, and it packs a fully-featured GUI system to boot.

Still trying to weigh the pros and cons in my head, but I can’t shake the thought that if I try to do the GUI myself, I’m going to overlook something important or fail to implement something that needs to be in there.

I’m not a fan of Microsoft in general, and I’m pleased that they don’t offer anything over Java with regards to this project. (-:

RunnerPack wrote:
5) The word “acknowledgment” is misspelled in the copyright notice.

Put another mark on the Wikipedia Fails column. I just copy/pasted the language from their zlib License article, and upon reviewing the spelling from the zlib website, I find the word is indeed spelled correctly there. Someone on Wikipedia changed it when they copied it over. (-:

I’ll fix it in all source files going forward. Thanks for pointing it out.

Contrary to personal opinion, I haven’t died!

I have, on the other hand, had something happen near the end of September: I had a surprise relocation sneak up on me (yeah, I’m moving again). And seeing as how I was unemployed at the time, I had to make a mad dash to raise a four-figure sum by the end of October. I finished up making money yesterday, and I’ll be packing my things and heading out on Saturday.

The following is the most backwards sentence posted to the web this year: Fortunately, where I’m going, I’ll have limited internet access.

Why is that a good thing? It means that computer time will be free of internetty distractions. I still have access to the internet for the sake of updates and the like, but I won’t have it on my workstation, at least not in the short term. That means more working on Virtual Boy, and less postponing working on Virtual Boy.

Not intended as an excuse, but as an explanation. Good thing no one was following this thread, or else I might have disappointed someone. (-:
__________

VIP Shenanigans

I placed a curse on myself by saying “the rest will be really simple”. Of course it isn’t simple. It’s never simple. The not-simple part is that while the VIP won’t outright explode if you feed it unexpected input, it will act in a peculiar (albeit well-defined) manner. Pinning down all the sneaky little edge cases and documenting the results has taken WAY longer than I thought it would, and in the long run won’t make a darned difference anyway. But I’m dedicated to the cause: this emulator will be accurate, take it or leave it.

What kinds of things am I talking about? Consider the following:

• What happens when you specify negative window dimensions?
• What are the maximum effective window dimensions?
• What happens when the background parallax setting approaches multiples of 4,096?
• What happens when a background is configured with more than 8 segments?
• What happens when affine-mode parallax approahces multiples of 1,024?
• How is per-row position information recorded during affine rendering?
• What is the exact frame-rendering procedure? There’s evidence that it’s not simply a matter of drawing each window one at a time in back-to-front order.

At the time I was thrust into an immediate need for full-time work, I had finished documenting the VIP memory and was in the process of documenting the VIP registers. My plan was to post the VIP section of the new draft of the tech document as a consolation prize before I started work, but I didn’t even get that far. I’m also not 100% sure I got all the anomalous details completely correct, and it’s been a month since I was last working with it…

Before I say that I’ve mastered the VIP, I’m going to want to write a sort of “acid test” program, at least for the unintended behaviors.
_________

Platform Considerations

I’ve thought long and hard about whether or not to make the primary emulator application in Java with an accompanying C library, and have decided that is indeed the route I wish to take. Both routes have their pros and cons, but in the end I believe the… well, the cons of C-only route outweigh the cons of the Java route.

The primary benefit of sticking strictly with C is that it means there’s only one code branch for the entire project, and changes made to it are immediately reflected in the release builds. This saves the work of maintaning two different versions of the library in parallel, and completely sidesteps the possibility of a dreaded desynchronization. It’s an attractive approach, and the one I wanted to do, but it has its drawbacks too…

On the other hand, the primary benefit of working with Java is that we get a cross-platform GUI out of the box. They take care of all the platform-specific stuff like window management, networking, input devices and Unicode, all of which would need to be implemented manually in a C-only project. A fair amount of a C implementation would fall into the category of “don’t screw it up”.

When it’s all said and done, there’s one detail in particular that makes Java look quite reasonable: dependencies. At its heart, C is a very portable programming language, but an application written in C will nonetheless have platform dependencies. SDL mitigates this to an admirable extent, but its scope doesn’t cover some of the emulator’s needs like directory lists or networking–some of the application will still need to be maintained for each target platform. Java, on the other hand, supports even more platforms than SDL and has industry experts making sure everything works correctly and efficiently. Java gives the emulator a bigger user base and a smaller margin for compatibility issues. When put in this context, using Java simply makes sense.

Of course, the C library will still exist alongside the Java project. It’ll be the code people can use to add Virtual Boy to their system no matter what hardware or operating system it’s running on.

Inclusion of a Java branch of the project comes with a mild caveat: the existing C library isn’t structured the way a Java package needs to be. And honestly, that was an error on my part: my original goal was to make code in C with the express intention of it being portable to other languages if need be, and then I didn’t stick by that when I implemented it. So now I get to take a step back and reorganize everything to make the C version and Java version match more closely when set side-by-side.

When I do this, I’ll take care and try to design the C library in an even more portable manner so that it can be moved to additional languages with fewer issues.
__________

At this time, I can’t give an informed estimate on a timeline for these two things will take place. Next week, after I get settled into my swag new rent-exempt abode, I should be better equipped to budget my time and assess what needs to be done going forward.

Guys! Guys! I’m done with my August homework!

Between this post and my previous one, another relocation happened, and frankly, I’d be happy to remain in just one geographic region for any appreciable amount of time. But this one’s already off to a good start, because I’ve done a ton of work on the emulator.

… Only thing is, the work I’ve done was restarting from scratch and getting to the point in the new project where I was in the old one. Why bother? I was never fully satisfied with how the old one was set up, but it was a good setup and worked well, so I went with it. After seeing yupferris and his work on Rustual Boy, I was inspired to dive back into the project in earnest, with the goal that every little thing I did would be done the best way I could possibly come up with.

And that’s exactly what I did. Attached to this post is a new CPU emulator/disassembler like the old one, except it’s substantially better–some of the best code I’ve ever written. I’m proud to present it to you guys as a taste of things to come.

Like before, it accepts a ROM file as its command argument and is compiled for 32-bit Windows. You can easily launch it by dragging a ROM file onto the EXE.

Only two controls this time:
• F6 – Step Over
• F7 – Single Step

Single Step executes a single instruction. Step Over will attempt to advance PC to whatever the next instruction’s address happens to be, executing as many instructions as necessary to get there, even entering and leaving function calls (hence the name). Due to this, overzealous use of Step Over can make the emulator hang such as when the emulated program waits for an interrupt that’s never going to happen.

The disassembler looks the same as last time save for the font, but the code backing it is cram-packed with features. Configurations include operand ordering, specifics of numeric formatting (base, delimiter, etc.), displacement notation (relative, absolute), Bcond and SETF displays, etc. I put in all that effort towards the end of “do it right now and I don’t have to redo it later on”

The github repository isn’t ready for prime time yet, but rest assured, it’s up there. The attached ZIP file does include all the source code necessary to build this program, though.

This all came together extraordinarily quickly. I’m super-excited to see what February holds.

Attachments:

1. 

   andhereweareagain.png
   

1. pvbe_20170126.zip

Good to hear you’re making progress! I admire your tenacity for the project, to rebuild from scratch in order to make it the best you possibly can (and succeed!) is no small feat.

I compiled the emulator with Clang on Haiku (haven’t tried anything else yet) and it works just fine, which is a nice improvement from the previous version that compiled and then didn’t respond to input. With “-Weverything”, it gave a lot of warnings, and while I’m sure you would disagree with many, I think you should try it out for yourself.

Thanks for looking into it, HorvatM! I always value your input because you do some of the strangest things…

It’s true that I disagree with many compiler warnings. (-:

Having said that, a goal of the project is for the emulation core library to compile in strict C89 on as many compilers as appropriate without any errors or warnings. In gcc, this meant the following options:

-std=c89 -pedantic -Wall -Wextra

And that does compile with no messages. It did entail doing some things that I disagree with, such as putting unnecessary parentheses around things like bitwise operations and assignments used as conditions, but I figure it was all for the greater good.

I don’t have Clang/Haiku handy, so I don’t know the nature of the warnings it’s giving. If you could compile just the libvue portion and give me some samples, I’d appreciate it.

I say just the libvue portion because the SDL program and disassembler in this build are temporary and will not be present in the application. Four months of deliberation have settled me on Java as the application platform, and I’m maintaining an unmodified port of libvue in Java to that end.

I’m hoping that by the end of the month I can have this disassembler in an actual GUI. (-:

It’s such a big relief seeing this finally be in a traditional window. Working up the GUI stuff in Java feels way better than what I’d done in C for the previous iteration of the project, and I feel like the sky is the limit. I’ll be coasting high on this one for a bit. (-:

Attachments:

1. 

   onthehorizon.png
   

I kinda fell off the face of the planet this month, but I’ve been working on the emulator off-and-on and have a lot to show for it. Well, not to show, exactly, since a lot of it was back-end work, but I know in my heart that good things have happened. (-:

A lot of this was slow-going because my goals for the application dealt with things I didn’t have any real prior experience in. The level of configurability (is that a word?) I have my heart set on requires a lot of planning ahead, and I took the time to do that so I wouldn’t paint myself into a corner. Among other things, the infrastructure supports the following features:

• There is no human language hard-coded into the application–all localized strings are loaded from text files. This facilitates easy translating, allowing the application to instantly switch languages.
• Application-wide commands that can be invoked via keyboard or game controller are dynamic and can be configured by the user and written to/read from file. Multiple inputs can be associated with one command.
• Individual text controls can be configured for font, color and whatever other settings are appropriate. Finally, you can do your hacking in Comic Sans if you want!

One feature I want to accommodate is scaling of other UI elements such as menus and buttons. Sometimes your display is just too small to make out what you’re working with, and an accessible application should provide a solution.

When I got all that out of the way, I got back into the disassembler and just a few minutes ago got it pretty much complete. The only thing I can think to add at this point is maybe a small toolbar that allows the user to navigate to a particular address or directly to the address in the CPU’s PC register. A full set of inputs is supported in the disassembler:

• Up and Down scroll by one instruction.
• Page Up and Page Down scroll by one “page” of instructions–the number of fully-visible instructions in the window.
• Left and Right tweak the topmost instruction’s address by 16 bits if available, in case the disassembly is misaligned. This shouldn’t be an issue in most cases, but it’s good to have the option.
• Scrolling the mouse wheel up and down scrolls by one instruction per click.
• Scrolling the mouse wheel while the CTRL key is held down will instead change the font size.

The vertical scrollbar is a custom class I had to build due to the fact that JScrollBar doesn’t accommodate a full 32-bit range very well. While working on that, I took the liberty to introduce some new functionality to make the scrollbar more usable. The following behaviors are implemented:

• Clicking on the scroll buttons scrolls by one instruction.
• Clicking on the track scrolls by one page of instructions.
• Dragging the knob seeks to the corresponding location in memory. Since there’s some 4.3 billion addresses, scrolling in this manner isn’t very useful, at least not until we have millions-of-pixels-tall monitors.

Conspicuously missing are inputs for things like Toggle Breakpoint and Step Over. These are actually application-level commands that can be invoked from places other than the disassembler, such as the Debug menu or the yet-to-exist debugging toolbar. That’ll actually be the next thing I tackle.

There’s a lot going on, and I continue to learn new skills from this project each day that goes by. It’s a real privilege to be involved with this (even if by myself), and I owe a lot of that to the PVB community’s eternal passion for the system.

Attachments:

1. 

   hackingsans.png
   

In a move that surprises absolutely nobody (except maybe that one guy), I decided to gut the program architecture and redo it with a different approach… again. Having said that, I feel like I’ve thoroughly exhausted any feasible consideration and this will be the final rework. Feel free to point me to this post in the future if such a time should come when I redo it again. (-:

We’ve been over the fact that the emulation core must be a self-contained C library. This is one of the project goals and is a concrete requirement. We’ve also been over the fact that Java is about as good as it gets when it comes to cross-platform GUI support, as well as things like networking, compression, etc. The technical challenge that I’ve brushed up against time and time again is that there’s no “perfect” way for the emulation core in C and emulator GUI in Java to interact with each other.

So I did some research…

• I can’t really do the GUI/network/etc. stuff in C because the project needs to be cross-platform. I’d be replicating what Java already does, so why not leave that stuff to the pros?
• I can’t really do the emulation core in Java because it’s an unnecessary workload and there’s no conventional way to test and debug the C version. Perhaps a Java-only project could spin up at some point…
• JNI isn’t designed to be used by rapid, trivial methods like the kind required by the emulator. Using it would introduce so much overhead that performance would be greatly impacted.
• Shared memory may be the most efficient form of IPC, but it relies on system calls and therefore doesn’t solve the problem of C and Java communicating in the first place.

Other than shared memory, inter-process communication is typically done with either sockets or pipes. Both are fully adequate for this purpose, although Sockets are perhaps overkill. Since pipes have built-in synchronization in the form of blocking when no data is available, and since the additional overhead of sockets makes them a bit slower than pipes in practice, pipes is the natural choice.

Anyone with a programming background will be familiar with the “standard input and output streams” used to communicate with the console. These are pipes, and it’s trivially easy for a Java program to launch a native binary and attach to its standard I/O streams. A request-response implementation can be set up where the C program waits for Java to ask for something, and then Java waits for it to finish. This is very nearly like a call to native code from the Java program.

Initial experiments have been extremely promising. An unexpected benefit to using pipes like this is that all components of the application can be made with absolutely no system calls–standard I/O is an intrinsic part of C. At some point we’ll probably want controller support, and then we’ll have to worry about system calls, but in the short term, it’s looking extra beautiful. <3