Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My x86 emulator written in JavaScript

copy.sh

Post reply on HN
Print view View original

151–160 of 194 posts

Re: Show HN: My x86 emulator written in JavaScript

#151

Post by Aardwolf »

g3 wrote: post #144
batuhanicoz wrote: post #76

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.

Re: Show HN: My x86 emulator written in JavaScript

#152

Post by api »

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.

Re: Show HN: My x86 emulator written in JavaScript

#153

Post by Aardwolf »

Narishma wrote: post #148
mambodog wrote: post #109

Earlier quoted context omitted.

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…

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.

Re: Show HN: My x86 emulator written in JavaScript

#155

Post by j1vms »

to3m wrote: post #52
Sheepshow wrote: post #37

Earlier quoted context omitted.

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…

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

Re: Show HN: My x86 emulator written in JavaScript

#156

Post by senorsmile »

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.

Re: Show HN: My x86 emulator written in JavaScript

#157

Post by darkstalker »

JoshTriplett wrote: post #25

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: /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.…

I can't type "/" or "\" and all the shift- keys combinations are wrong. I'm using an ES layout keyboard on Firefox.

Re: Show HN: My x86 emulator written in JavaScript

#158

Post by JoshTriplett »

laumars wrote: post #128
JoshTriplett wrote: post #25

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: /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.…

You could just use octal escape sequences in printf : printf '\055' returns - Just change 055 for 075 (=), 053 (+) or 137 (_). eg your $eq code can be written like this: eval eq$(printf '\075\075')

Good thinking; that is much simpler.

Re: Show HN: My x86 emulator written in JavaScript

#159

Post by s-macke »

mraleph wrote: post #129
s-macke wrote: post #119

Earlier quoted context omitted.

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…

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 o…

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.

Re: Show HN: My x86 emulator written in JavaScript

#160

Post by s-macke »

g3 wrote: post #145
s-macke wrote: post #67

Earlier quoted context omitted.

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…

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.
Post reply on HN