I'd have to look at the code, but it might not be too awful to get tun/tap to work over WebSockets...
Regarding the heat, I wonder if the architecture has support for idle states. If so, the VM should "clock down" by executing its loop from a timer instead of full-bore. I wonder if this is already happening, though.
I tried adding an extra serial port some months ago, but I didn't succeed.
It would be really cool if you made this. Here's a use case I had in mind:
You go to emulator.html#http://otherwebsite.com/packages.json . The emulator's JavaScript part detects the fragment, and downloads a list of dpkg packages to the HTML5 file system. The emulator boots up, checks the HTML5 file system over 9P, and installs all those packages.
Like this, you could test any binary package over the web without fear, and it would be decentralized, you wouldn't have to modify the emulator.
But for jor1k, we'd need networking and 9P/HTML5 support (like in Arm-js). For Arm-js, just the networking would suffice, as the 9P support is already there.
Saw that issue, hope to eventually respond to it with a pull request.
Are you Sebastian Macke? [Edit: scratch that, I see he's commented elsewhere.] Either way, get in touch (info in my profile). I'm curious to hear what issues you ran into in trying to add another serial port. I'm not terribly familiar (read: not at all familiar) with OpenRISC, but I'd imagine it's just a matter of creating a second instance of UARTdev in system.js and adding it to the 'ram' object at an appropriate base address. If OpenRISC is similar to ARM, you may need to add the second uart to your platform/chip/board init as well so the system is aware of it.
Regarding networking, I intend to actually implement eth.js and wire it to a WebSocket, then on the other end I'll write a receiver which hands the frames to/polls a TAP device. At that point, you can do whatever you want on the backend with that interface. I'd like to start this weekend, but (how often does one get to say this?) I'll be at the governor's mansion and that's going to take a bunch of my time.
I'm not sure I follow on the package management bit. Would these be emulator extensions, or packages which the image would use?
This features sound like fun. But networking is not on my priority list right now.
Problem is the server and security issues. At the moment everything runs out of the box even on the simplest web server. This would change. And at the moment I don't want to implement features which you can't use on the demo web-site.
But of course, you are free to do so. You have not even to change something in the kernel-image because everything is ready to test. Exchange the dummy ethernet driver with the real one from the or1ksim project.
I think the main issue is that the console and framebuffer use canvas elements which are continuously refreshed by a javascript timeout. This tends to use up all of a single core, no matter how little of the screen is actually changed. Perhaps using requestAnimationFrame could improve the CPU utilization.
1) I am waiting for a version using networking. I know there are security issues but there are also workarounds.
2) My notebook is hot, so I checked and the Chrome CPU console is at 25% even if I am not doing anything in the console.