This may as well be magic as far as I'm concerned. When I first saw http://bellard.org/jslinux/ I just about shat myself. This is definitely another level of awesome. Well done.
This really is extremely well done [and I'd like to see the unminified source]. The next feature I'd want to see is networking support. I love the idea to be able to run my entire dev setup in an emulated browser session [e.g. ruby, rails, redis]. That would be a game changer on how I'd develop.
Some things would do badly at that speed. But serving basic web queries would be fine, and give you a better feel for what is slow when milliseconds spent processing turn into actual seconds.
Just for reference's sake this does vary a fair bit by computer and browser - mine never drops below ~8kIPS and runs mostly at ~15kIPS (and up to ~23kIPS).
Whilst this is nothing like the several orders of magnitude required for more capable interactive behaviour, it does make my load times noticeably faster than those claimed on the page. :)
For reference, that's about as fast as a Motorola 68030 @50MHz [1] which was used in the AppleIIx, and while that was no slouch when it was released, you wouldn't want to run a modern development environment on such a machine either ;)
I think it would be really cool to link this up with some of the Chrome App API's (TCP/UDP networking, serial). Then you could distribute lightweight programs without bothering with Emscripten or Native Client.
Go to any machine with a browser, log in, and have your dev environment pop up in the same state it was when you left it somewhere else, yet all running locally rather over some VNC connection or potentially laggy ssh connection. Log out, and have the state persisted.
I'm presently working on networking (OpenCores ethmac) support for the jor1k[1] OpenRisc emulator. The plan is to push ethernet frames out over a web socket, and pipe them into a tun interface on the server via a node/python/C/whatever backend. From there, do whatever you want using your OS' standard networking tools (if you have specific needs for the server-side of this which go beyond using your os' standard tools, please let me know).
If you're interested in this, please do make plenty of noise at me to finish. I've got a flight back to the East coast from Portland on Sunday, so I'm hoping I can get most of the browser code finished by then. After that I'm going to be somewhat distracted through the end of January, as I'm moving from Charleston, SC to Christchurch, New Zealand. I could use a bit of motivation to get this done.
I am really looking forward. If you have any wishes for an image with some tools, please let me know. Lynx, elinks, dillo, ssh, netcat, telnet ... whatever you want. Then I have to think about a demo. Maybe we can allow very limited access to some websites.
I think the biggest thing I'm overlooking right now is randomized MAC generation. I need to take a look at whether or not the ethoc driver will attempt to read the MAC from hardware before loading its own. If so, I can randomize MACs in my ethmac.js, or even make a backend service assign them to guarantee uniqueness.
Otherwise I think it'd be great to get an image together with all of those tools, especially Lynx. It'd be great if I could make the HN submission to the demo page via the emulator itself. However for now if I can get an ICMP echo I'll be happy.
I think when it's ready I'm going to set up a full-access reCaptcha-protected demo on DigitalOcean or AWS and see what happens. If people don't abuse it and if the bill isn't too bad, I'll leave it up. If not, I'll worry about how to do a restricted demo. It would be nice to get a network-friendly game in there, though.
Another great demo that we'd have difficulty with is browser-in-browser. Chrome-in-chrome, firefox-in-firefox. That would, however, be the ultimate sandbox.
Anyway, get in touch with me via e-mail or better yet, Skype (see profile). We can coordinate better there.
Wait how does this differ from JSLinux? Aren't they doing the same thing?
Also, this isn't just an x86 emulator, right? If it can boot linux, it's emulating the entire PC platform, not just x86. Very impressive of course. But I am interested in a comparison vs jslinux (also not open source).
I had a quick look at the minified source. its pretty hard to decipher (method names have been renamed too), unlike traditional minification which you can recover by just reformatting.
AFAIK most of minificators also shortened variable / function names - are there any that don't do this? (take a look at minified jquery.js for instance)
Css get minified by removing whitespace because the keywords are important.. Javascript can have some magic done to it to reduce character count because only the consistency of the keywords matters.
I just ran Bellard's JSLinux (#) on my retina iPad with iOS 7. It works! Booting took 15 sec. Claims 20 bogoMips. And I can type the commands in it and execute them:
First I tap to the edit box on the right, the keyboard rolls in, then I tap in the "console." The commands work. I just don't know how I'd type ctrl-Keys without the physical keyboard.
Copy.sh ends with unimplemented GP handler however for anything I've tried.
#) JSLinux: the PC emulator is written in Javascript with the emulated hardware: 32 bit x86 compatible CPU,
8259 Programmble Interrupt Controller,
8254 Programmble Interrupt Timer,
16450 UART,
Real Time Clock,
IDE interface and hard disk. http://bellard.org/jslinux/tech.html
Interesting bug: I can't seem to type '-', '=', '+', or '_' into the Linux image. Missing '-' in particular makes it hard to run commands with options.
Elaborate workaround:
/root% eval eq$(dmesg | grep 'e820 update' | sed 's/.*) \(.\).*/\1\1/')
/root% echo $eq
=
/root% eval dash$eq$(uname bad 2>&1 | grep Usage: | sed 's/.*\[\(.\).*/\1/')
/root% echo $dash
-
/root% uname ${dash}a
Linux (none) 2.6.34.14 #44 Tue Oct 15 20:50:15 CEST 2013 i586 GNU/Linux
The first command grabs an '=' from dmesg and sets "eq" to it (without typing '='), and then the second command grabs a '-' from the usage message of uname and sets "dash" to that (without typing '-'). The last shows how to use ${dash} in a command.
This is the most soul-crushing category of bug, the kind which keeps me up all night, drinking.
Build a skyscraper, and lock the keys inside for the ribbon cutting. Sorry pal you lost your funding
Land on Mars, see an alien, but your camera is out of batteries and everybody back on Earth thinks you're a quack.
Successfully perform open-heart surgery on a desert island, but muck up the stitches and cause a scar. Your patient will hold it against you the rest of his life (which you saved).
The soul-crushing bugs are the ones where you run a program, and nothing actually goes actively wrong, but the program overall just doesn't behave quite like it does on the real hardware.
Simple defects where a key is being ignored on certain systems are usually quite easy to fix ;)
Luckily, he was able to come up with a workaround.
Here's a soul-crushing situation that doesn't have a workaround, as far as I can tell.
You can play the original Deus Ex on OnLive. By default, it sets the fov to a very low number. It's only possible to change it in the console (there is no UI for it). But the console is disabled. However, you can get around that by pressing T, which creates a mini console with "say " prepoulated. Press delete to erase say, and type "fov 90". So close...
But they disabled the Enter key from working.
So you can get full access to the console, type the command that would fix the FOV, but you're unable to execute it because Enter key does not get sent to the game. You're completely helpless.
OnLive runs on OSX. gdb (i think) also runs on OSX. It should be possible to isolate the callback used to handle keyboard input and call it with c=10. This would take anywhere from hours to weeks of debugging though.
No, that won't work. Nothing you do client-side will help.
OnLive Client <-all input is transmitted-> OnLive Servers <-filter out Enter-> Deus Ex instance in a VM.
The enter key is filtered out on their servers. Unless you hack into their servers and change that, there is nothing you can do on the client-side. That's what makes you completely helpless.
Ah, my apologies, I thought the game was running locally. (This sort of assholeness on the part of servers is basically why 'cloud computing' is such a bad idea.)
I disagree that cloud computing is a bad idea because of this. It has advantages and disadvantages. Not being able to hack around to make changes you wish is a disadvantage, but having access to something you would not have otherwise is a much bigger advantage.
Also, any plans to implement GPF handling? I tried booting a test environment I have on it (which runs Python as part of the GRUB2 bootloader), but it failed primarily due to lack of support for trapping GPFs. (There are a few other issues I'd have to work around to make it work, but that's a major one that I can't easily work around.)
I found that bug too. First thing I did was think, "a system restore is a page refresh away and I've always wanted to test the effects of this", then I attempted to type "rm -r /*".
Pretty awesome, I for one don't think the constant stream of "x, rewritten completely in javascript" is tiring (this is not meant to be sarcastic).
[EDIT] - This post doesn't seem to say enough when I look back at it. Wanted to add this:
Seeing posts like this really excites me (and inspires me) about the future of web programming, and programming in general. Anyone that's excited about programming has to get excited about abstraction, and it doesn't get much more abstract that cross-coded/implemented virtualized systems like this. Even if you hate javascript.
Every step people take in blurring lines between systems like this should be exciting, given the large amount of abstraction that had to go into creating something like this.
Potentially, but I feel that the historical significance of these systems and the value of making them available to a newer generation of creators outweighs the technical infringement of copyright. It's basically abandonware, after all.
I feel very strongly about the importance of learning from the past, and not making the same mistakes over and over due to lack of historical perspective. I was particularly inspired by Bret Victor's talk at the DBX conference[1]. That's what motivated me to make this available in the most accessible way possible.
Then it usually dies for low memory - and I can't enter anything at all without keyboard (which doesn't pop up) - but still. The fact that I can boot up a x86 emulator in javascript in browser on ARM mobile phone is crazy.
My second computer was an IBM XT 8086. That was the first time I played and fell in love with Rogue. Every time I grab a copy of Rogue nowadays for nostalgia's sake I'm left disappointed because I can never find the version of Rogue that I played as a kid.
My friend, your emulator has that version of Rogue. The kid inside me thanks you greatly.
You might want to consider re-ordering the font list in the console though. Consolas isn't perfectly fixed-width apparently, and it made Rogue rather puzzling to play.
I know this sounds like crazy pants, but I would actually use this in the real world if it were a NodeJS module.
Not for anything compute-intensive or serious, but for creating very secure very isolated VMs to run web apps or other services in an insecure environment. It could also be a great way to take a LAMP stack app and rapidly deploy it in certain cases.
Again not for high performance, but for... I can think of a few things personally and I'm sure others can too.
(Though honestly performance wouldn't be that bad...)
Then add the ability to go back and forth between client and server, and virtual networking, and you might have a commercial "virtual DOS LAN with nodes in a browser as a service" startup. What for? Supporting legacy DOS crap: point of sale systems, etc. "Run your legacy DOS stuff in your browser with persistence in the cloud." You'd be surprised how much legacy DOS crap is out there.
The project is made with both browser and nodejs support in mind. There are still some issues to resolve, but I will definitely release a node version this year.
There are two sensible approaches: interpretation or dynamic translation.
If you want to write one as a learning experience for how the platform you're emulating works and how an emulator could work in principle, you probably want to write an interpreter: find out how the platform boots, build something to start reading and interpreting instructions, start adding emulated hardware devices, and you'll get an increasingly functional interpreter.
For a start, you could ignore emulation of devices, and just write a CPU core that interprets instructions.
If you want to learn how modern (but still non-hardware-assisted) emulation works, read about how qemu's dynamic code translator and other JIT compilers work, and build a CPU emulator based on that.
I'm not the OP but check out the book: "The Elements of Computing Systems: Building a Modern Computer from First Principles" It's quite comprehensive, not exactly about writing an emulator, but it should give you what you need.
I really like your tutorial. I been trying to learn assembly and your tutorial is really helping me put the big picture together. I hope you continue to work on making it better.
g3: Probably you have seen my emulator.
http://s-macke.github.io/jor1k/
It does more or less the same, but emulates a different CPU.
Your emulator is impressive and especially fast. I think it took a long time for you to optimize it.
I tried to start TinyCore, but it stops after decompressing the kernel. So still some work to do ;)
I saw the source and I have some tips for you:
Avoid the UInt32 Arrays and the >>> operator.
They could be transformed by the JIT compiler into doubles and slow everything down. This does not happen with the Int32 Arrays and the >> operator.
There is a plug-in called JIT-Inspector which give you this information. Unfortunately it does no longer work in Firefox 24. Firefox 22 was the last working version.
Additionally worker threads gave me an incredible speed boost in Firefox. The whole GUI stuff is then separated. Especially the costly canvas update.
Do you have any documentation to support the stuff about UInt32? The old Firefox JIT had some limitations like this but I'm not aware of anything like that in the current one (which has been shipping for multiple versions). Is it a v8 limitation similar to the 31-bit 'small integer' limitation?
Indeed at the moment I have nothing to support it. Half a year ago I had dozens of examples. Now it is more or less experience. In v8 I had two weeks ago some strange deoptimizations behavior in my code. It was almost gone after I exchanged two >>> operations. So in my experience it is still better to avoid such cases. No one knows really how the JIT compiler are working. What makes it worse. The behavior is changing every 6 weeks. And don't forget: Out there is more than Firefox and Chrome ;)
Have you consider reporting strange deoptimization behaviour to V8 team? Performance issues are better investigated than worked around.
V8 has special support for uint32 values in optimized frames to avoid converting them to doubles when they flow into truncating operations. If that support somehow became broken that would be unfortunate. (and it's actually only >>> 0 that is problematic from the optimization point of view. as long as you shift by non zero result is within Int32 range).
The problem is that I can't really explain it. I can hardly say: Hey, if I change this line (from 3000 lines) from A to B I get a 80% reduced chance that my program is deoptimized after 30 seconds and slows down by a factor of five.
No one will take the time to look at it.
What I want is information. They have to provide a tool that let me see what happens. Especially if a variable or operation is treated as double or int. The JIT-inspector for Firefox (is)/was a great tool for this. Unfortunately it does not support worker threads.
No, I think you are making a wrong assumption here. A bug report like that, that pinpoints a line in question and provides observable metrics is the best kind of performance issue that you can file against V8.
Back when I was on the V8 team I would immediately set aside some time to investigate and triage/fix/explain it because stable performance is as important for any VM as correctness.
So don't hesitate to file bugs like that against JavaScript VMs be it V8 or SpiderMonkey. You might be surprised with VM engineers' eagerness to investigate and address performance problems.
> What I want is information.
There are ways to trace optimizations and deoptimizations in V8. Unfortunately nothing as simple to use as JIT-inspector. Most of what V8 has right now is geared towards VM engineers.
I have a tool called IRHydra[1] that can display some information that V8 dumps in a more or less digestible form. It's most useful for performance investigations in the console but to a certain degree works for browser as well (biggest problem for it "multithreading": because V8 dumps part of the information into stdout and as a result it can arrive arbitrary mixed if you have many workers).
Hi s-macke. I've read the source code of your emulator before, good job.
I'm aware of the problem with big integers. I'll look into this more closely, thanks for your help.
Regarding workers: I need some restructuring to get this working. I'll also need to figure out the fastest way to exchange the canvas buffer between the worker and the browser.
I did the copying by a for loop copying In32 Arrays which is an acceptable solution. It slows down the worker thread by 1-2% by using 10fps and a screen size of 640x400x32. I think the reason why I didn't used more advanced ArrayBuffer functions to do this was the IE. Probably this has changed.
The color transformations and so on can be done in the master GUI-thread.
I'm trying to run a custom basic x86 kernel (it was an assignment for my Computer Architecture course). But I can't get it to work =/. (This image works with bochs and in a virtual machine without problems). It seems that it can get to protected mode, enable interruptions, enable paging, but it fails loading the tasks =/
This is the error that I'm getting:
Unimplemented: load system segment descriptor, type = 9
Execution stopped
FF 24 is the latest stable. FF's docs say they added this function in FF 4.0, which was several years ago. So it's a bit more complicated than you make it out to be.
EDIT: I thought FF24 wasn't working, turns out I was confused between my Linux desktop's and Mac laptop's FF versions. Sorry!
In a case like this, the more important licensing question is that of the x86 instruction set; I do not know what the strict licensing situation would be with that—it's quite possible (probable, actually) that this is technically illegal.
For the software part, why would you advocate GPLv3+ over permissive licenses like MIT/BSD/Apache?
I know keyboard codes in web browsers are a nightmare, but, afaik it is possible to get the intended ascii/unicode character code value of the key, so the emulator could translate that to the US keyboard equivalent to fix this issue.
This is beyond awesome! I'd love to read about your thought process while writing it, I guess a lot of people (including myself) would learn a lot from it. How long did it take to write?
I got Freedos working about 2 years ago, but then stopped working on it. I picked it up again earlier this year. Approximately 3 months of full time work.
I'm considering writing some articles, just need to find some free time.
When I first saw DOOM running on a bog-standard 386, I declared it to be utter nonsense. I'm no fool! I know what's possible and what's impossible, and that was clearly the latter. Sure, I knew it wasn't impossible, and in fact was true and real and a testament to the brilliance of Carmack et al, but it was still nonsense. Brilliant, astonishing nonsense.
I declare your x86 emulator similar nonsense, for all the same reasons. I take my hat off to you. Well done indeed!
Hmmm... could you add a simple edit field, <input type="text">, that sent anything typed in it directly to the emulated console? That would make it work on a phone browser.
This is quite amazing. Could someone post a blog post on the details behind how this works. I am not a JavaScrip programer, and this looks like black magic to me at the moment.
I've been waiting ages for this ever since I saw jslinux. This is freaking brilliant.
Looking at the source its been minified. How big is it before that? Are you planning on going open source? Was kind of blown away to see the single js file do all this. Would love to see the method's names to understand how it works
Has anyone had success running this on an iOS device? There are hints of it working on my iPad mini under Chrome, but with Safari it gives a "Unimplemented: #GP handler".
Could you give some tips or links on how to go about emulating an architecture? I would like to know how to go about emulating an architecture much less complicated like PIC.
Yea, Chrome DevTools has a pretty print option too, but if they ran it through something like closure compiler it renames all the vars. Would like to browse source on github or comparable -- also see the history :)
Nothing in the web platform lets you use raw (or TCP/UDP/etc) sockets. At most you could do VPN-style networking and use a bridge to talk to the rest of the internet; that bridge needs someone to host it.
1. I know it is already available via the page, but would you please open-source it so others could contribute?
2. Thought I appreciate the apps being shown in the canvas in the resolution they are supposed to use, a full-screen option would be incredible. That way I could play space invaders the way it was meant to be played, in FreeDOS, in a JS emulator, in Firefox, on a mac. (That's just so wrong, it's right.)
3. Is that your real hair? (Sorry, just had to throw in a Real Genius quote.)
This may as well be magic as far as I'm concerned. When I first saw http://bellard.org/jslinux/ I just about shat myself. This is definitely another level of awesome. Well done.
This really is extremely well done [and I'd like to see the unminified source]. The next feature I'd want to see is networking support. I love the idea to be able to run my entire dev setup in an emulated browser session [e.g. ruby, rails, redis]. That would be a game changer on how I'd develop.
At 2000 kIPS you may have a few generations of javascript engines to go before we get there.
That's not meant to take away from this project - it truly is amazing what can be interpreted in the browser now.
Dynamic translation of x86 sequences could give you some boost, as could use of asm.js.
Some things would do badly at that speed. But serving basic web queries would be fine, and give you a better feel for what is slow when milliseconds spent processing turn into actual seconds.
Just for reference's sake this does vary a fair bit by computer and browser - mine never drops below ~8kIPS and runs mostly at ~15kIPS (and up to ~23kIPS).
Whilst this is nothing like the several orders of magnitude required for more capable interactive behaviour, it does make my load times noticeably faster than those claimed on the page. :)
(I'm Chrome on Linux, i7 4th Gen, incidentally)
I'm getting here > speed 1640kIPS on the old Nexus 7, don't you mean 8kkIPS?
(This value was the average while booting Linux)
psst, the SI prefix for 10^6 is M
You mean to say, 10^7 isn't KKK?
Absolutely so, yes. Thanks. :)
8 - 23 MIPS ain't so bad, right?
For reference, that's about as fast as a Motorola 68030 @50MHz [1] which was used in the AppleIIx, and while that was no slouch when it was released, you wouldn't want to run a modern development environment on such a machine either ;)
[1] http://en.wikipedia.org/wiki/Motorola_68030
A little faster than an Arduino and a little slower than a PIC24. Not too bad.
Absolutely. This would be awesome.
I think it would be really cool to link this up with some of the Chrome App API's (TCP/UDP networking, serial). Then you could distribute lightweight programs without bothering with Emscripten or Native Client.
> That would be a game changer on how I'd develop.
Why? I'm honestly curious since I can't imagine any big advantages over more "classic" setups ...
Go to any machine with a browser, log in, and have your dev environment pop up in the same state it was when you left it somewhere else, yet all running locally rather over some VNC connection or potentially laggy ssh connection. Log out, and have the state persisted.
I use a remote dev server that behaves exactly like this, except it's just a hosted virtual server. What advantage would doing this in JS give you?
I think Sun workstations did that in the 80s or 90s.
Must plug http://www.koding.com here.
It is a "social" development platform supporting rails, mysql etc.
I'm presently working on networking (OpenCores ethmac) support for the jor1k[1] OpenRisc emulator. The plan is to push ethernet frames out over a web socket, and pipe them into a tun interface on the server via a node/python/C/whatever backend. From there, do whatever you want using your OS' standard networking tools (if you have specific needs for the server-side of this which go beyond using your os' standard tools, please let me know).
If you're interested in this, please do make plenty of noise at me to finish. I've got a flight back to the East coast from Portland on Sunday, so I'm hoping I can get most of the browser code finished by then. After that I'm going to be somewhat distracted through the end of January, as I'm moving from Charleston, SC to Christchurch, New Zealand. I could use a bit of motivation to get this done.
1: http://s-macke.github.io/jor1k/
I am really looking forward. If you have any wishes for an image with some tools, please let me know. Lynx, elinks, dillo, ssh, netcat, telnet ... whatever you want. Then I have to think about a demo. Maybe we can allow very limited access to some websites.
I think the biggest thing I'm overlooking right now is randomized MAC generation. I need to take a look at whether or not the ethoc driver will attempt to read the MAC from hardware before loading its own. If so, I can randomize MACs in my ethmac.js, or even make a backend service assign them to guarantee uniqueness.
Otherwise I think it'd be great to get an image together with all of those tools, especially Lynx. It'd be great if I could make the HN submission to the demo page via the emulator itself. However for now if I can get an ICMP echo I'll be happy.
I think when it's ready I'm going to set up a full-access reCaptcha-protected demo on DigitalOcean or AWS and see what happens. If people don't abuse it and if the bill isn't too bad, I'll leave it up. If not, I'll worry about how to do a restricted demo. It would be nice to get a network-friendly game in there, though.
Another great demo that we'd have difficulty with is browser-in-browser. Chrome-in-chrome, firefox-in-firefox. That would, however, be the ultimate sandbox.
Anyway, get in touch with me via e-mail or better yet, Skype (see profile). We can coordinate better there.
Or PHP.
Ruby's interestingness to performance ratio is not high.
With emscripten, anything is possible nowadays. And it blows your mind.
Anything has been possible since 1999. Anything at all.
http://www.zombo.com
I can't stop laughing. That was so weird and funny that I almost forgot what I was doing here on HN.
Relevant xkcd: http://xkcd.com/855/
Wait how does this differ from JSLinux? Aren't they doing the same thing?
Also, this isn't just an x86 emulator, right? If it can boot linux, it's emulating the entire PC platform, not just x86. Very impressive of course. But I am interested in a comparison vs jslinux (also not open source).
Yes, it's very similar to the jslinux project. However, I added more hardware (it can boot a real bios: seabios). Also, I'll make this open source.
Keep us updated when you do. :)
Very much looking forward to the open source release!
great to hear you are opensourcing this!
I had a quick look at the minified source. its pretty hard to decipher (method names have been renamed too), unlike traditional minification which you can recover by just reformatting.
AFAIK most of minificators also shortened variable / function names - are there any that don't do this? (take a look at minified jquery.js for instance)
Css get minified by removing whitespace because the keywords are important.. Javascript can have some magic done to it to reduce character count because only the consistency of the keywords matters.
minification can't (usually) happen on the public side of the API - that could explain jQuery, as a very large amount of it is public.
Otherwise yeah, you can just run it through a whitespace-remover. There are also often options on e.g. the YUI compressor: http://refresh-sf.com/yui/ and Google's: http://closure-compiler.appspot.com/home
wait for you to open the source.
I just ran Bellard's JSLinux (#) on my retina iPad with iOS 7. It works! Booting took 15 sec. Claims 20 bogoMips. And I can type the commands in it and execute them:
First I tap to the edit box on the right, the keyboard rolls in, then I tap in the "console." The commands work. I just don't know how I'd type ctrl-Keys without the physical keyboard.
Copy.sh ends with unimplemented GP handler however for anything I've tried.
#) JSLinux: the PC emulator is written in Javascript with the emulated hardware: 32 bit x86 compatible CPU, 8259 Programmble Interrupt Controller, 8254 Programmble Interrupt Timer, 16450 UART, Real Time Clock, IDE interface and hard disk. http://bellard.org/jslinux/tech.html
https://news.ycombinator.com/item?id=6221724
The last month always takes at least 60 days. Strong work!
Very impressive.
Interesting bug: I can't seem to type '-', '=', '+', or '_' into the Linux image. Missing '-' in particular makes it hard to run commands with options.
Elaborate workaround:
The first command grabs an '=' from dmesg and sets "eq" to it (without typing '='), and then the second command grabs a '-' from the usage message of uname and sets "dash" to that (without typing '-'). The last shows how to use ${dash} in a command.
This is the most soul-crushing category of bug, the kind which keeps me up all night, drinking.
Build a skyscraper, and lock the keys inside for the ribbon cutting. Sorry pal you lost your funding
Land on Mars, see an alien, but your camera is out of batteries and everybody back on Earth thinks you're a quack.
Successfully perform open-heart surgery on a desert island, but muck up the stitches and cause a scar. Your patient will hold it against you the rest of his life (which you saved).
The soul-crushing bugs are the ones where you run a program, and nothing actually goes actively wrong, but the program overall just doesn't behave quite like it does on the real hardware.
Simple defects where a key is being ignored on certain systems are usually quite easy to fix ;)
Whoosh
Would you like me to explain my response more clearly? :)
Luckily, he was able to come up with a workaround.
Here's a soul-crushing situation that doesn't have a workaround, as far as I can tell.
You can play the original Deus Ex on OnLive. By default, it sets the fov to a very low number. It's only possible to change it in the console (there is no UI for it). But the console is disabled. However, you can get around that by pressing T, which creates a mini console with "say " prepoulated. Press delete to erase say, and type "fov 90". So close...
But they disabled the Enter key from working.
So you can get full access to the console, type the command that would fix the FOV, but you're unable to execute it because Enter key does not get sent to the game. You're completely helpless.
OnLive runs on OSX. gdb (i think) also runs on OSX. It should be possible to isolate the callback used to handle keyboard input and call it with c=10. This would take anywhere from hours to weeks of debugging though.
No, that won't work. Nothing you do client-side will help.
OnLive Client <-all input is transmitted-> OnLive Servers <-filter out Enter-> Deus Ex instance in a VM.
The enter key is filtered out on their servers. Unless you hack into their servers and change that, there is nothing you can do on the client-side. That's what makes you completely helpless.
Ah, my apologies, I thought the game was running locally. (This sort of assholeness on the part of servers is basically why 'cloud computing' is such a bad idea.)
I disagree that cloud computing is a bad idea because of this. It has advantages and disadvantages. Not being able to hack around to make changes you wish is a disadvantage, but having access to something you would not have otherwise is a much bigger advantage.
I've found the bug. For now, try Chromium. I'll fix this tomorrow.
Thanks! What was the bug? I'd be interested.
Also, any plans to implement GPF handling? I tried booting a test environment I have on it (which runs Python as part of the GRUB2 bootloader), but it failed primarily due to lack of support for trapping GPFs. (There are a few other issues I'd have to work around to make it work, but that's a major one that I can't easily work around.)
Chromium and Firefox send different key codes for `-` and `=` (see http://unixpapa.com/js/testkey.html).
Regarding GPFs: This is one of the few things that are not completely implemented yet, I'm working on figuring this out.
I found that bug too. First thing I did was think, "a system restore is a page refresh away and I've always wanted to test the effects of this", then I attempted to type "rm -r /*".
Not `dd if=/dev/random of=/dev/kmem` ?
You could just use octal escape sequences in printf:
returns
Just change 055 for 075 (=), 053 (+) or 137 (_).
eg your $eq code can be written like this:
Good thinking; that is much simpler.
I can type -, +, = and _ from the alpha area of the keyboard, but none of the keys of the numpad works (not even the numbers)
I can't type "/" or "\" and all the shift-<number> keys combinations are wrong. I'm using an ES layout keyboard on Firefox.
Pretty awesome, I for one don't think the constant stream of "x, rewritten completely in javascript" is tiring (this is not meant to be sarcastic).
[EDIT] - This post doesn't seem to say enough when I look back at it. Wanted to add this:
Seeing posts like this really excites me (and inspires me) about the future of web programming, and programming in general. Anyone that's excited about programming has to get excited about abstraction, and it doesn't get much more abstract that cross-coded/implemented virtualized systems like this. Even if you hate javascript.
Every step people take in blurring lines between systems like this should be exciting, given the large amount of abstraction that had to go into creating something like this.
If like this you might also be interested in my port of the PCE Emulator to the browser: http://jamesfriend.com.au/pce-js/
At the moment I've only uploaded a demo of the Mac Plus emulator (classic 68k mac) but I'll upload IBM PC and Atari ST demos soon also.
That's very nice too, though aren't you going to be running into some legal issues by distributing their ROMs?
Potentially, but I feel that the historical significance of these systems and the value of making them available to a newer generation of creators outweighs the technical infringement of copyright. It's basically abandonware, after all.
I feel very strongly about the importance of learning from the past, and not making the same mistakes over and over due to lack of historical perspective. I was particularly inspired by Bret Victor's talk at the DBX conference[1]. That's what motivated me to make this available in the most accessible way possible.
[1] http://worrydream.com/dbx/
I respect that. I'm very impressed with the speed of that emulator too.
I don't know about the other games, but Wolfenstein 3D is definitely not abandonware. You can still buy it on Steam, XBLA, PSN and other places.
That image has the free shareware version of Wolf3D. It has only episode 1 and is free to distribute to anyone.
For those who are interested I have uploaded some more demos:
IBM PC with Wolfenstein 3d, Civilization, Monkey Island: http://jamesfriend.com.au/pce-js/ibmpc-games/
IBM PC with Windows 3.0: http://jamesfriend.com.au/pce-js/ibmpc-win/
Mac Plus with applications and games: http://jamesfriend.com.au/pce-js/pce-js-apps/
cute.
Heh, 1.3 MHz on a Pentium 60.
Wow.
Plan 9 iso [0] CD image fails
[0] http://plan9.bell-labs.com/wiki/plan9/download/
Just when you thought "I've written an x in JavaScript" can't get any more insane . . .
Still, this wins the Nobel Prize for awesome.
I'm still waiting for "Show HN: I built a self-modifying general AI in JavaScript".
(@Eliezer, how's the work going? ;))
Now and then I see a project which is soul crushing to me when I compare myself with other programmers. This is one of them.
It actually boots on Chrome.
On Android.
Then it usually dies for low memory - and I can't enter anything at all without keyboard (which doesn't pop up) - but still. The fact that I can boot up a x86 emulator in javascript in browser on ARM mobile phone is crazy.
Works for me on Firefox for Android, no crashes yet.
My second computer was an IBM XT 8086. That was the first time I played and fell in love with Rogue. Every time I grab a copy of Rogue nowadays for nostalgia's sake I'm left disappointed because I can never find the version of Rogue that I played as a kid.
My friend, your emulator has that version of Rogue. The kid inside me thanks you greatly.
Would have been fun if it included some interface to execute assembler code on it directly in some way (without booting an OS).
In any case, super awesome! Great work :)
EDIT: Whoa, the dos one has games on it! Can you make Wolf3D work? :)
I doubt it, but nethack might be worth a shot.
This is awesome.
You might want to consider re-ordering the font list in the console though. Consolas isn't perfectly fixed-width apparently, and it made Rogue rather puzzling to play.
Consoles isn't perfectly fixed width? That sucks. Till now it was my go-to fixed width font.
I assumed something named consolas would be a font suitable for consoles.
Which font do you like to use?
I use Consolas every day.
I'm on Linux, so that might also impact something.
Perhaps the line drawing characters are extra-small or something? Fire up Rogue and try it out...
Two things:
1. How can we help? How can I support you? 2. Please open source this.
This guy is awesome. Check out a Game of Life Turing Machine: http://copy.sh/life/?pattern=turingmachine
how do you use it to perform a calculation? or what should i be asking?
I know this sounds like crazy pants, but I would actually use this in the real world if it were a NodeJS module.
Not for anything compute-intensive or serious, but for creating very secure very isolated VMs to run web apps or other services in an insecure environment. It could also be a great way to take a LAMP stack app and rapidly deploy it in certain cases.
Again not for high performance, but for... I can think of a few things personally and I'm sure others can too.
(Though honestly performance wouldn't be that bad...)
Then add the ability to go back and forth between client and server, and virtual networking, and you might have a commercial "virtual DOS LAN with nodes in a browser as a service" startup. What for? Supporting legacy DOS crap: point of sale systems, etc. "Run your legacy DOS stuff in your browser with persistence in the cloud." You'd be surprised how much legacy DOS crap is out there.
The project is made with both browser and nodejs support in mind. There are still some issues to resolve, but I will definitely release a node version this year.
its HTML5 and SSE?
Yes its HTML5. Saw header <!doctype html> ...
I want to write an emulator as a learning experience. Any tips how should I start?
There are two sensible approaches: interpretation or dynamic translation.
If you want to write one as a learning experience for how the platform you're emulating works and how an emulator could work in principle, you probably want to write an interpreter: find out how the platform boots, build something to start reading and interpreting instructions, start adding emulated hardware devices, and you'll get an increasingly functional interpreter.
For a start, you could ignore emulation of devices, and just write a CPU core that interprets instructions.
If you want to learn how modern (but still non-hardware-assisted) emulation works, read about how qemu's dynamic code translator and other JIT compilers work, and build a CPU emulator based on that.
Canonical place to start: http://stackoverflow.com/questions/448673/how-do-emulators-w...
I'm not the OP but check out the book: "The Elements of Computing Systems: Building a Modern Computer from First Principles" It's quite comprehensive, not exactly about writing an emulator, but it should give you what you need.
https://practicingruby.com/articles/low-level-computing?u=64...
You want to write an emulator, but you probably don't want to write one for x86. A nice architecture would be 8 bit AVR microprocessors, for example.
http://codegolf.stackexchange.com/questions/4732/emulate-an-...
I recently posted about emulating the NES with JavaScript.
http://blog.alexanderdickson.com/javascript-nes-emulator-par...
Part 2 will be posted when it's done. :)
If you want to get something done much quicker, have a go at emulating the Chip-8 VM.
I also have a post, but it's less hand-holding than the first.
http://blog.alexanderdickson.com/javascript-chip-8-emulator
Good luck!
I really like your tutorial. I been trying to learn assembly and your tutorial is really helping me put the big picture together. I hope you continue to work on making it better.
I have a heap on my plate right now but will hope to do part 2 before the end of the year. Glad you enjoyed it.
I'd like to think of myself as an experienced programmer, but I still loved your tutorial ! Brilliant ! Keep up the good work.
g3: Probably you have seen my emulator. http://s-macke.github.io/jor1k/ It does more or less the same, but emulates a different CPU.
Your emulator is impressive and especially fast. I think it took a long time for you to optimize it. I tried to start TinyCore, but it stops after decompressing the kernel. So still some work to do ;)
I saw the source and I have some tips for you: Avoid the UInt32 Arrays and the >>> operator. They could be transformed by the JIT compiler into doubles and slow everything down. This does not happen with the Int32 Arrays and the >> operator. There is a plug-in called JIT-Inspector which give you this information. Unfortunately it does no longer work in Firefox 24. Firefox 22 was the last working version. Additionally worker threads gave me an incredible speed boost in Firefox. The whole GUI stuff is then separated. Especially the costly canvas update.
Do you have any documentation to support the stuff about UInt32? The old Firefox JIT had some limitations like this but I'm not aware of anything like that in the current one (which has been shipping for multiple versions). Is it a v8 limitation similar to the 31-bit 'small integer' limitation?
Indeed at the moment I have nothing to support it. Half a year ago I had dozens of examples. Now it is more or less experience. In v8 I had two weeks ago some strange deoptimizations behavior in my code. It was almost gone after I exchanged two >>> operations. So in my experience it is still better to avoid such cases. No one knows really how the JIT compiler are working. What makes it worse. The behavior is changing every 6 weeks. And don't forget: Out there is more than Firefox and Chrome ;)
Have you consider reporting strange deoptimization behaviour to V8 team? Performance issues are better investigated than worked around.
V8 has special support for uint32 values in optimized frames to avoid converting them to doubles when they flow into truncating operations. If that support somehow became broken that would be unfortunate. (and it's actually only >>> 0 that is problematic from the optimization point of view. as long as you shift by non zero result is within Int32 range).
The problem is that I can't really explain it. I can hardly say: Hey, if I change this line (from 3000 lines) from A to B I get a 80% reduced chance that my program is deoptimized after 30 seconds and slows down by a factor of five. No one will take the time to look at it.
What I want is information. They have to provide a tool that let me see what happens. Especially if a variable or operation is treated as double or int. The JIT-inspector for Firefox (is)/was a great tool for this. Unfortunately it does not support worker threads.
And yes, I think it was a ">>> 0" operation.
> No one will take the time to look at it.
No, I think you are making a wrong assumption here. A bug report like that, that pinpoints a line in question and provides observable metrics is the best kind of performance issue that you can file against V8.
Back when I was on the V8 team I would immediately set aside some time to investigate and triage/fix/explain it because stable performance is as important for any VM as correctness.
So don't hesitate to file bugs like that against JavaScript VMs be it V8 or SpiderMonkey. You might be surprised with VM engineers' eagerness to investigate and address performance problems.
> What I want is information.
There are ways to trace optimizations and deoptimizations in V8. Unfortunately nothing as simple to use as JIT-inspector. Most of what V8 has right now is geared towards VM engineers.
I have a tool called IRHydra[1] that can display some information that V8 dumps in a more or less digestible form. It's most useful for performance investigations in the console but to a certain degree works for browser as well (biggest problem for it "multithreading": because V8 dumps part of the information into stdout and as a result it can arrive arbitrary mixed if you have many workers).
[1] http://web.irhydra.googlecode.com/git/hydra.html
Hi s-macke. I've read the source code of your emulator before, good job.
I'm aware of the problem with big integers. I'll look into this more closely, thanks for your help.
Regarding workers: I need some restructuring to get this working. I'll also need to figure out the fastest way to exchange the canvas buffer between the worker and the browser.
I did the copying by a for loop copying In32 Arrays which is an acceptable solution. It slows down the worker thread by 1-2% by using 10fps and a screen size of 640x400x32. I think the reason why I didn't used more advanced ArrayBuffer functions to do this was the IE. Probably this has changed. The color transformations and so on can be done in the master GUI-thread.
Anyone know what format the floppies are expecting? It won't accept a DOS 6.22 install disk from MSDN, maybe it doesn't like DMF?
Also, swapping disks during the install might be an issue, I don't see a button...
It expects one of the standard formats (720k, 1440k or 2880k). I'll add switching disks some time in the future.
It rejected my 360Kb images :-(
I'm trying to run a custom basic x86 kernel (it was an assignment for my Computer Architecture course). But I can't get it to work =/. (This image works with bochs and in a virtual machine without problems). It seems that it can get to protected mode, enable interruptions, enable paging, but it fails loading the tasks =/
This is the error that I'm getting:
Unimplemented: load system segment descriptor, type = 9 Execution stopped
Here's a screenshot: http://i.imgur.com/DdCt8jX.png
I tried the freedos image, says something about 400kips and then down to 0. Nothing ever shows. FF 17.0.9 ESR on 1386 freebsd 8.3
I'm testing in Firefox 24. If you could tell me what the error console outputs, I'll try to fix it.
Thanks, it's under the error tab:
ReferenceError: requestAnimationFrame is not defined http://copy.sh/v24/v86_all.js Line: 239
Update to a newer Firefox. Your FF is dead old and doesnt support the new HTML5 methods... and @author, maybe add a polyfill?
FF 24 is the latest stable. FF's docs say they added this function in FF 4.0, which was several years ago. So it's a bit more complicated than you make it out to be.
EDIT: I thought FF24 wasn't working, turns out I was confused between my Linux desktop's and Mac laptop's FF versions. Sorry!
It's actually not all that complicated.
Firefox 4 added mozRequestAnimationFrame.
Firefox 23 added the unprefixed version.
It's documented in the browser compatibility table at https://developer.mozilla.org/en-US/docs/Web/API/window.requ... (note that "moz" next to the 4.0).
That must have done the trick, it starts now, thank you for your help.
FF 24.0 ESR on FreeBSD is getting there but still some issues:
http://freebsd.1045724.n5.nabble.com/Problem-with-FireFox-24...
Man, shit like this makes me feel dumb. How does this work?
Is there a non minified version of the javascript emulator file that is publicly available?
I'll put it online soon. I haven't figured licensing out yet and need to write some technical notes
Awesome - congrats on a very impressive hack.
I would like you to consider GPLv3+. Thanks and congrats on amazing work!
In a case like this, the more important licensing question is that of the x86 instruction set; I do not know what the strict licensing situation would be with that—it's quite possible (probable, actually) that this is technically illegal.
For the software part, why would you advocate GPLv3+ over permissive licenses like MIT/BSD/Apache?
I'd love to be able to use this to host a coreboot showcase. Open Source licensing would certainly help there.
... Since you're using seabios, I guess its bringup is relatively close to qemu's?
This is so cool!
I have one problem with it though, it doesn't seem to support my keyboard. For example when I try "*", it writes "-".
I'm using a Turkish Q keyboard and Chromium on OS X Mavericks GM.
It should be the US keyboard layout, because that's what the operating systems in the emulator use.
I know keyboard codes in web browsers are a nightmare, but, afaik it is possible to get the intended ascii/unicode character code value of the key, so the emulator could translate that to the US keyboard equivalent to fix this issue.
I got a kernel panic trying to boot tinycore linux:
Decompressing Linux... Parsing ELF... done. Booting the kernel. init[1]: segfault at b8e8e089 ip 08071929 sp bfb81b08 error 4 in busybox[8048000 +7c000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to ac cess hardware directly.
Both bugs are fixed now.
This is beyond awesome! I'd love to read about your thought process while writing it, I guess a lot of people (including myself) would learn a lot from it. How long did it take to write?
I got Freedos working about 2 years ago, but then stopped working on it. I picked it up again earlier this year. Approximately 3 months of full time work.
I'm considering writing some articles, just need to find some free time.
Here's a list of virtual machines in JavaScript: https://gist.github.com/ysangkok/5606032
When I first saw DOOM running on a bog-standard 386, I declared it to be utter nonsense. I'm no fool! I know what's possible and what's impossible, and that was clearly the latter. Sure, I knew it wasn't impossible, and in fact was true and real and a testament to the brilliance of Carmack et al, but it was still nonsense. Brilliant, astonishing nonsense.
I declare your x86 emulator similar nonsense, for all the same reasons. I take my hat off to you. Well done indeed!
My gods. It runs on my phone. In a web browser. Now, if only I knew how to make the onscreen keyboard pop up...
Hmmm... could you add a simple edit field, <input type="text">, that sent anything typed in it directly to the emulated console? That would make it work on a phone browser.
This is quite amazing. Could someone post a blog post on the details behind how this works. I am not a JavaScrip programer, and this looks like black magic to me at the moment.
This is incredible! At this point, it's definitely JS magic, because I'm struggling to fathom how this even exists.
Very interesting. Great job!
No xhr queries detected in firebug and firefox console. Its is done without AJAX? How its working? Thanks.
wireshark says like "encrypted allert"
saw https packets
I've been waiting ages for this ever since I saw jslinux. This is freaking brilliant.
Looking at the source its been minified. How big is it before that? Are you planning on going open source? Was kind of blown away to see the single js file do all this. Would love to see the method's names to understand how it works
Cool, I tried the linux gui OS and games worked.
sudoku and snake worked really well, but pong seemed to graphically expensive
That's awesome, I quit! :)
waiting for docker.js
Has anyone had success running this on an iOS device? There are hints of it working on my iPad mini under Chrome, but with Safari it gives a "Unimplemented: #GP handler".
Could you give some tips or links on how to go about emulating an architecture? I would like to know how to go about emulating an architecture much less complicated like PIC.
Very cool!
Btw, this is what I'm working on http://cloud306.com It's kind of similar, but not really.
Seems very like http://bellard.org/jslinux/ from a while back.
I know it is oversimplification, but in essence, isn't writing an emulator just mundane following and reading specs? a lot of specs...
Yes, following the specs will give you a correct emulator.
The trick is in writing a fast and accurate one.
...wow. Just, wow. You, my friend, are awesome.
If you add networking support to this amazing project, I think some crazy development environment tools are waiting for us.
This is a superb work! Beyond my imagination.
I can't sleep over the awesomeness of your emulator. I love you and happy birthday <3
I can just imagine the posts in a few years: "Look at my JavaScript GPU emulator!"
The FreeDOS feels only half the speed of a TRS-80
This is jaw dropping. Imagine next generation javascript.
Love it and would like to learn more. Are there any docs you could make available ?
What else is there to say? Swung for downtown and knocked it into the ocean.
Wow, very impressive! What are your plans for this? Any plans to open source?
It will be open-source. I don't know how to deal with licensing yet.
1. Pick a license. You'll probably want something compatible with Qemu (GPL2+).
2. Ship a COPYING file, add a header to your files: https://github.com/osterman/copyright-header
Dude, this is Grade-A stuff.
Cool project. Can you elaborate on the difference between this and JSLinux?
Very, very awesome. Kudos!
I can't believe this
Doesn't quite exactly work on a non QWERTY keyboard : (
Still awesome, though!
The amazing thing is it works (slowly) on my Nexus 4. Great work!
A program listing as screensaver (KolibriOS). Now, that is cool.
how does it work?
Yeah! Especially X - that's a pretty amazing X implementation!
It's not an X implementation, it's VESA emulation (disclaimer: this is a guess).
Good guess, that's correct
You should un-minify and open-source this.
I really want to make this run Node...
no network interfaces :( boo. rm -rf or halt -f are fun.
this is great work. would love to see source un-minified.
Use http://jsbeautifier.org/?
Yea, Chrome DevTools has a pretty print option too, but if they ran it through something like closure compiler it renames all the vars. Would like to browse source on github or comparable -- also see the history :)
Networking is on the todo list. I couldn't host the traffic, though.
i suppose you could try adding something to do the networking part via webrtc as the channel?
Nothing in the web platform lets you use raw (or TCP/UDP/etc) sockets. At most you could do VPN-style networking and use a bridge to talk to the rest of the internet; that bridge needs someone to host it.
damn. at least i found http://www.w3.org/TR/webrtc/#peer-to-peer-data-api which looks like its a standard to allow for peer to peer data transfer.
I'm totally impressed.
Very cool! Great job!
now waiting release for support lxc containers :)
wow
github link?
@g3 this is super-mega awesome. 3 questions:
1. I know it is already available via the page, but would you please open-source it so others could contribute?
2. Thought I appreciate the apps being shown in the canvas in the resolution they are supposed to use, a full-screen option would be incredible. That way I could play space invaders the way it was meant to be played, in FreeDOS, in a JS emulator, in Firefox, on a mac. (That's just so wrong, it's right.)
3. Is that your real hair? (Sorry, just had to throw in a Real Genius quote.)
#2 just made my day!
Fullscreen is there and yes, it will be open source.
this is beyond cool... logs off to think in some startup with this :)