Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 109 reacties
Submitter: Reggino

De Nederlander Tim de Koning heeft een Commodore 64-emulator naar javascript geport, waarbij hij gebruikmaakte van het Canvas-element zoals gestandaardiseerd door de Web Hypertext Application Technology Working Group.

De port moet gezien worden als een proof-of-concept, schrijft De Koning op de website van zijn bedrijf, Kingsquare. Jsc64, zoals de applicatie heet, is een port van de C64-emulator die Darron Schall en Claus Wahlers in ActionScript schreven. De javascript-versie is wel minder snel dan die applicatie, moet De Koning toegeven.

Voor het scriptmatig dynamisch renderen van bitmapbeelden maakte De Koning gebruik van het Canvas-element. Dit element is gestandaardiseerd door het WHATWG, gaat mogelijk deel uitmaken van html5 en wordt al ondersteund door de laatste versies van Firefox, Chrome en Safari. De Nederlandse programmeur heeft de broncode op zijn site geopenbaard en demonstreert Jsc64 op zijn site met verschillende roms, zoals die van Galaga, Hellgate en Voidrunner.

JSC64

Moderatie-faq Wijzig weergave

Reacties (109)

valt dit te draaien op een blackberry ?
Ik denk nog niet, bij mij is de proof of concept in firefox extreem traag... en dat is dan op een dualcore met 4 gig ram..
Al was het een quadcore of meer, firefox maakt maar gebruik van 1 core. :)
én zelfs al zou je hem in een multi threaded browser gebruiken (Chrome) dan pakt ie toch maar 1 core per core per JavaScript applicatie.
Zojuist getest op een i5:
1x C64 – 1 Process Google Chrome Helper 100% CPU
2x C64 – 2 Processen Google Chrome Helper 100% CPU
3x C64 – 3 Processen Google Chrome Helper 100% CPU
4x C64 – 4 Processen Google Chrome Helper 95% CPU

Kortom, de emulator pakt altijd maar één core ook al ondersteund je browser multi-core.
Dit mag je niet verbazen gezien javascript niet multi-threaded wordt geprogrammeerd en dit volgens mij ook niet mogelijk is.

Je kan ook een java toepassing schrijven die precies hetzelfde gedrag vertoond.
Hiervoor zijn Web Workers uitgevonden. John Resig heeft er een leuk stuk over geschreven, zie: http://ejohn.org/blog/web-workers/.
Web Workers werken al in Safari 4 en Firefox 3.5.
Nou.. wat je in javascript is gebruik maken van een Timer (setTimeOut).. Daarmee kunt je soms een soort van multi-threaded dingen krijgen.. Maar dat vaak een drama en heel erg lastig te debuggen.

En ik denk dat de meeste browsers dit stiekem single threaded doen.
Dan is het volgens mij inderdaad nog steeds niet multithreaded. Asynchroon via timeslicing misschien, maar de javascript VM werkt nog steeds maar met 1 thread tegelijk en kan dus geen gebruik maken van meerdere cores.
Nou.. wat je in javascript is gebruik maken van een Timer (setTimeOut).. Daarmee kunt je soms een soort van multi-threaded dingen krijgen..
Daar is niets multithreaded aan, alle events worden gewoon sequentieel in dezelfde thread afgehandeld. Als je een setTimeout doet, en je blokkeert vervolgens net zo lang tot de timeout verstrijkt met een loopje oid, dan zal de timeout functie niet meteen worden aangeroepen, maar pas als je returnt uit je code.
Dan nog is het gewoon niet mogelijk. Als je een 2e thread zou aanmaken in javascript zou je meteen last krijgen van synchronisatie problemen. Als je mutlithreading wilt hebben in javascript zullen ze toch echt de taal moeten aanpassen.
Firefox 3.5.7 gebruikt bij mij toch alle 4 de cores (Q9550 met Windows 7 x64). CPU usage ligt op zo'n 25%. Waarom gebruikt Firefox bij jullie dan maar 1 core?
1/4 = 25%, lijkt me duidelijk dat hij bij jou dus ook maar 1 van jouw 4 cores gebruikt?
Hele verhalen op jou reactie maare er wordt duidelijk vermeld dat Firefox javascrips maar singel threath kan draaien (zie net dat het miss anders kan maar dan wel heel complex wordt)

[Reactie gewijzigd door Mellow Jack op 12 januari 2010 09:18]

1 single thread kan wel uit meerdere processen bestaan, en die kunnen op verschillende core's draaien maar moeten wachten op elkaar, wat ongeveer neerkomt op hetzelfde als single core. Vandaar dat je niet hoger komt dan 25% bij een quad en 50% bij een dualcore en 100% bij single core. ;)
1 single thread kan wel uit meerdere processen bestaan
Andersom (een proces kan meerdere threads draaien) ;)
Wat er hier dus gebeurt is dat er een single threaded proces getimesliced wordt over meerdere cores. Iedere core krijgt om de beurt een stukje te verwerken. Wat dit wel als voordeel heeft is dat je niet een core volledig aan het werk zet terwijl de rest uit z'n neus peutert. Ik kan me voorstellen dat dat voordelen oplevert als dat de hitte door gedeelde belasting beter verspreidt wordt over de die... En het ligt er een beetje aan of de processor in kwestie een split power plane heeft ... misschien is het beter alle cores enkele power states terug te laten vallen dan om een core vol open te hebben staan of, als er geen split power plane is, de hele die op vol vermogen te laten werken alleen maar omdat er een core op 100% moet draaien...
I7 920 @4.4GHz valt het goed mee. Gaat niet vlot maar eigenlijk even onhanding als de orginele. Dus misschien nog een tikkeltje extra snelheid en je krijgt een core die niet volledig uitgeperst wordt.

[Reactie gewijzigd door Rizon op 11 januari 2010 22:44]

I7 920 @4.4GHz valt het goed mee. Gaat niet vlot maar eigenlijk even onhanding als de orginele. Dus misschien nog een tikkeltje extra snelheid en je krijgt een core die niet volledig uitgeperst wordt.
Dit gaat natuurlijk alleen om de 'omdat het kan'-factor. Als je serieus C64 code wil draaien, zijn daar voor alle gangbare platformen (inclusief mobieltjes) genoeg applicaties voor. ;)
Hier draaien de roms lekker vlot op 1MHz!!! Damn wat is m'n 6510 snel. Kill ff je achtergrond processen want het kan toch niet zo zijn dat jouw 4GHz bak het aflegt tegen mijn donkerbeige 1MHz. ;)
Op mij macbook Core2 duo 2.53GHz doet hij het anders prima, gewoon in safari.. De CPU load blijft bij mij op ongeveer 90% staan, single thread dan..
Op een eeepc 900 hier ook gewoon hoor.
safari is dan ook 10x sneller dan firefox met javascript :)
nou.... 3x sneller ongeveer. Maar wel 40x sneller dan IE7 :P _/-\o_
bron: http://news.zdnet.com/2100-9595_22-272792.html
Maar niet 40x sneller dan ie8, waarom dus vergelijken met een oudere versie browser. Toegegeven het is nog steeds 5x sneller dan ie8.
Pfft

Ik zit op 22 cm van mijn buro, en kan het goed zien nu ....

Werkelijk iets om je druk om te maken
[c64 insider mode]

Als POC lijkt het inderdaad best leuk om een keer uit mijn HTC die kreet te horen.

Another visitor! Stay a while. Staaaaay, FOREVER!!!!"

[/c64 insider mode]

Alhoewel ik me afvraag waar ik dat spel mee moet gaan besturen. Mijn oude joysticks zullen wel niet helemaal passen op die mini USB poort :+
Het duurt alleszins al heel lang om te 'booten' op de website van de emulator met een 500mhz android met 256mb :)
De reboot sys 64738 duurt nog langer. Maar werkt wel!
wel als je html5 ondersteunt :p
Om alvast een paar toekomstige reacties voor te zijn:

Gewoon, omdat het kan :)

Ik vind het altijd leuk, dit soort dingen. Ten eerste omdat het toch best knap is om alleen al op het idee te komen, en om het vervolgens ook nog met (gedeeltelijk) succes uit te voeren.
Hulde _/-\o_
Laat ik de vraag dan maar stellen: is er daadwerkelijk nog iemand die hier behoefte aan heeft? Kijk, als je het nou zo weet te maken dat je het op een iPhone oid redelijk kan draaien dan denk ik: ja, het heeft toegevoegde waarde. Nu zie ik die totaal niet. Er zijn zo een stuk of 3 C64 emulators waar je geen supercomputer voor nodig hebt te vinden.
Laat ik het zo zeggen: In de tijd dat jij die emulator schrijft, kan je waarschijnlijk de meeste populaire spellen herschrijven.

Alsnog hulde ervoor, het is knap. En voor de mensen die het tijdverdoening vinden: Ik ben zelf bezig een game te maken in actionscript (rts), puur omdat ik het leuk vind, ik zal het nooit terugverdienen en de game zal waarschijnlijk nooit populair worden.

Overigens voor alle Flash-bashers: Zo zie je maar dat dit nog voor geen meter draait in JS, en AS toch een stuk geschikter is voor dit soort zaken zolang de browsers nog achterlopen. Probeer dit geintje maar eens in IE te draaien ;)

[Reactie gewijzigd door poepkop op 12 januari 2010 00:45]

Als Flash dan eens goed beschikbaar wordt op alle platformen dan kun je het pas goed vergelijken. Maar zolang er nog geen goede Flash implementatie is op de iPhone, Android, Windows Mobile, etc, dan blijven dit soort alternatieven noodzakelijk.
Apple houdt Flash actief van de Iphone af en probeert in plaats daarvan html5 sneller aan te passen voor extra webkit features met css3. Vroeger zorgde Apple er gewoon voor dat ze zelf met een beter alternatief kwamen. Microsoft probeert dat nu met Silverlight. Html5 is echt nog veel te ver weg, daar zorgt Microsoft wel weer voor.

As3 blijft trouwens natuurlijk altijd sneller dan javascript, want precompiled en type based. Begrijp me niet verkeerd, ik werk met as3 en javascript en ik ben zo mogelijk meer verliefd op jquery dan op flash, maar het geëmmer van Apple kan Microsofts Silverlight een grotere foothold geven en dan moet ik straks .net gaan leren. Dat is nog niet eens echt de ish - het is vast ook een mooie taal - maar zie daar je illustrator workflow maar eens mee te integreren.
Oh, ok. Jij je zin. Als je ooit een emulator moet draaien in een browser van een computer vaan 25 jaar geleden, dan is flash een oplossing.

Voor al het andere, javascript.
Niemand heeft dit nodig. Maar dat je op elke willekeurig platform met een webbrowser kan spelen geeft wel de potentie aan van webbrowsers. Alleen de snelheid is nog een groot issue, voor de rest kan "alles" in een browser.
voor de rest kan "alles" in een browser.
Idd, straks krijg je gewoon weer een normale no-nonsense browser, binnen je browser... kan haast niet wachten. Volgens mij zitten AMD en Intel hier achter.
En dan zie je maar weer dat het hele internet (browser based) ons bijna 10 jaar terug heeft gezet in de tijd. Als je ziet hoe de webapplicaties tegenwoordig eruit zien en met welke snelheid ze draaien. Dat konden we 10 jaar geleden ongeveer ook al.

[Reactie gewijzigd door hiostu op 12 januari 2010 09:51]

Aan de ene kant grappig idd. Aan de andere kant toppunt van totale inefficientie. Zit je dan met je quadcore en 4GB RAM en weet ik het wat, spelletjes te spelen wat een apparaat 25 jaar geleden ook al kon. Over lagen gesproken...
En dat apparaatje van 25 jaar geleden deed het nog sneller ook. :+ Maar goed, je draait dan ook een C64 emulator op een Java virtual machine (ook een soort van emulatie). En tja, emulatie is nou niet bepaald iets wat bekend staat om de hoge efficiëntie.
Als je bijvoorbeeld kijkt naar VMware dan is het ook geen emulatie wat ze doen; dat draait grotendeels native, juist omdat het anders te traag wordt om bruikbaar te zijn.
Eh.. Javascript is heel iets anders dan Java.. Als je dit in Java implementeert dan is het wel snel hoor. En de Java Virtuele Machine is juist geen Emulatie.. Maar is een JIT compiler.. Compleet verschillend.
Precies dit soort dingen maken me altijd weer vrolijk omdat ik dus niet de enige ben die die oude bakken nog een warm hart toedragen :)
Toevallig mijn oude C64 dit weekend meegenomen van bij mijn ouders op zolder.. Echt good old times.

Edit: kan je ook je eigen roms loaden?

[Reactie gewijzigd door Vinzz op 11 januari 2010 20:41]

Je zou moeten kijken naar CCS64, speelt bijna alle roms perfect... de ontwikkelaar heeft dan ook jaren de C64 bestudeerd om hem zo nauwkeurig mogelijk te emuleren. Echt een knap stukje werk.

Ik ben opgegroeid met de C64, dus idd... good old times.
Ja ken ik. Heb inmiddels een emu op mn N79 draaien. Zal mijn oude roms er weer eens bijpakken.
Momenteel nog niet; alleen de roms die je ook in het lijstje ziet op het screenshot.
Ja, met element.loadPrg(pathToPrgFile) als je een beetje kan javascripten..
snel is idd anders.
trekt hier toch 25% weg op meerdere cores, en firefox hangt zowat.

maar zoals hierboven staat; gewoon omdat het kan. dit is gewoon cool om in javascript voor elkaar te krijgen.
en wie weet wat de toekomst nog gaat brengen.
Het idee is al een tijdje oud.

Zo zijn er al emulators voor de NES en Gameboy in JavaScript, die ook net wat soepeler werken.

Toch is dit uiteraard een leuke prestatie, dus niks dan hulde voor de maker.

edit: 6x offtopic/irrelevant nog wel.

[Reactie gewijzigd door BarôZZa op 11 januari 2010 22:24]

Die zijn echt nice
bedankt voor de tip, doorgeklikt en een speelsessie van 5 minuten was genoeg om we weer helemaal verslingerd te maken aan de eerste 2 Zelda delen ;)
5 min laden op een single-core toch maar even niet gedaan. (88% tijdens laden galaga)

Maar in Opera praktisch niet merkbaar kon wel doorsurfen.
Precies 25%? Heb je toevallig een quadcore? Dan betekent dat gewoon dat ie genoeg werk heeft om één core bezig te houden (nogal logisch; het is niet bepaald snel genoeg om sleep()s nodig te hebben), maar geen gebruik maakt van meerdere threads (en dus geen gebruik kan maken van meerdere cores).
Is vast een Tweaker die Tim :) gelukkig weer eens een onderwerp waarin de oude garde zich verbonden voelt met de nieuwste materie (en ja daar hoor ik bij) ;)
Ik weet het wel zeker. De submitter (Reggino) is diezelfde Tim de Koning. :)
Kijk eens naar de submitter ;)
Hm net even geprobeerd en het is echt wel traag, firefox reageert ook niet heel snel, mss omdat ik nog op 3.0.17 zit ipv 3.5?
3.5 is hier ook niet bepaald vooruit te branden, misschien dat de 3.6-branch het sneller kan draaien...

Maar wat een uber-nerdige demo van wat je met huidige scripting engines kunt doen! _/-\o_

Hulde!
3.5 is in ieder geval wel stukken sneller dan één van de 3.0 versies. Het gebruiken van zo min mogelijk add-ons kan ook heel veel helpen.
Dat is wel erg leuk, dat je even via je browser wat kan emuleren, maar ja, via een browser gaat t altijd wat trager, zeker met javascript :P
javascript is niet de traagheids factor maar het beeld renderen. chrome gebruikt hiereen bijvoorbeeld hardware matige versnelling en is daardoor direct stukke sneller met canvas.
Zo bijzonder is dit nu ook weer niet, er bestaan ook al emulators voor andere 8-bit home computers. Zo is jsMSX een MSX1-emulator die ook geheel in JavaScript geschreven is.

En waarbij de C64-emulator nog het voordeel heeft om een ActionScript basis te hebben, was de basis van jsMSX een Java-code...

Overigens toont dit weer wel dat JavaScript, d.m.v. JIT/tracing-compilers steeds krachtiger wordt en dat meer en meer mogelijk wordt met alleen maar 'het web' als platform...
Overigens toont dit weer wel dat JavaScript, d.m.v. JIT/tracing-compilers steeds krachtiger wordt
Het toont aan dat Javascript nu de performance niveau van een moderne computer reduceert tot de performance van een computer van 25 jaar geleden.
Dit draait prima binnen Chrome! En met prima bedoel ik qua snelheid. Galaga besturen blijkt onmogelijk en die oude joystick past echt niet meer! (spatiebalk werkt wel)
Doet me denken aan jac64 (Java commodore 64) http://www.jac64.com/ :P

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True