Archive for the ‘JSSpeccy’ Category

JSSpeccy (tiny bugfix)

Thursday, May 10th, 2012

A long-overdue maintenance update to JSSpeccy to apply a bugfix independently found by Antonio Villena and Andrew without-a-surname: IM 2 interrupt handlers were broken because I had an 0xfff where there should have been an 0xffff. Thanks both!

As ever, see the subversion repo for source. (Incidentally, JSSpeccy v2 was in the works a while back – will dust that off again at some point…)

JSSpeccy v20091121

Saturday, November 21st, 2009

Yesterday’s Full Frontal javascript conference turned out to be the ideal setting to compare notes with Ben Firshman of JSNES fame on the finer points of implementing emulators in Javascript – so this new release of JSSpeccy is the natural consequence of that. I’ve put in an optimisation which might possibly be a speed boost on Chrome (only writing bytes to ImageData when absolutely absolutely necessary), and the much-needed ability to load your own snapshot files, using the little-known getAsBinary method on file upload objects. (Unfortunately Firefox 3.5 is the only browser which supports it right now, but it looks like it may be in the process of getting the official W3C blessing right now.) And since I was on a roll, on the train back I implemented tape loading traps and the ability to load .TAP files (again, only on Firefox 3.5). Wahey!

JSSpeccy v20090929 (Don’t-Mess-With-Geeks Edition)

Tuesday, September 29th, 2009

I wasn’t really planning on developing JSSpeccy further, because I didn’t consider it a serious project with a future. However, it turns out that someone else did. Enough to rip it off wholesale and pass it off as their own work on the iPhone app store for £1.29 a pop, no less. Yes, thanks to the detective work of Phil Kendall we now know that ZXGamer, the much heralded Spectrum emulator for the iPhone, was nothing more than JSSpeccy with a fancy title screen tacked on. (Which of course is a blatant violation of the GPL, and being pure Javascript, would explain why it ran at less than the speed of a real Spectrum on a 600 MHz device, and why it was overwhelmingly rated at one out of five stars. Epic fail.) It’s been pulled from the app store now – so while ZXGamer is gradually disappearing from the internet, it’s time to redress the balance a bit.

A new version of JSSpeccy is out. It doesn’t run at full speed on an iPhone either (although it positively speeds along on recent versions of Safari on real computers), but it does boast the following changes:

  • GPL v3 licenced, with prominent notices to make it clear that playing silly buggers like the above will not be tolerated (even if they do include source…)
  • A bit of speed optimisation (about 15% faster maybe)
  • A pimped-up user interface with shiny icons
  • And most relevantly, entirely controllable via iPhone / iPod Touch touchscreen. In principle. (If you’re expecting an immersive gaming experience, you’ll be disappointed.)

So there you go – probably the best Spectrum emulator for the iPhone ever. And it’s free.

JSSpeccy: A ZX Spectrum emulator in Javascript

Sunday, October 19th, 2008

I’m really typecasting myself here. If there were an international “Person most likely to write a Spectrum emulator in Javascript” award, I’d have taken it for the last five years running. So here it is – probably the most stereotypical project I’ll ever come up with.

Writing this wasn’t actually such a big deal – the Z80 core was ported from the one in Fuse, with the Perl-and-C-preprocessor-munging trickery still intact, and Javascript is syntactically close enough to C that that wasn’t a mammoth task. (I got 90% of it done on the train journey back from International Vodka Party alongside recording silly songs about tube stations.) The one fiddly bit was working around the places where the Fuse code used low-level C constructs to its advantage: using unions to chop and change between individual registers and 16-bit register pairs, and relying on limited-size C data types (often in pretty subtle ways) to truncate 8-bit and 16-bit values at the right time, whereas Javascript only has integers. (Actually, the really time-consuming bit was debugging it all… luckily, Fuse has a rather excellent test suite too.)

The rest is just creative abuse of the <canvas> element, as usual… it’ll take advantage of the putImageData interface to do the pixel pushing if available (on my machine Firefox has it, Safari doesn’t) and fall back on drawing 1×1 pixel rectangles otherwise. This time I’ve thrown in Google’s ExplorerCanvas as a nod to those poor unfortunates still stuck with Internet Explorer. Incidentally, I’d be curious to know how it rates on Google Chrome (I don’t have an XP/Vista box to test on) – if the hype is true (and it implements the putImageData interface like all good up-to-date browsers should) then I’d expect it to comfortably reach 100% Spectrum speed on modest hardware.