jorallan: (Default)
Another post on the long-running Vega+ saga. Vague apologies if this is of no interest to you, but there seems to be some confusion around all this which it's worth clearing up...

The Vega+ is running Fuse. Nobody disputes this. As noted last year, the Fuse team had nothing to do with the port of Fuse to the Vega+ - as it happens, the port was done by Private Planet, a company owned by Janko Mrsic-Flogel, Retro Computer's CTO. As required by the GNU GPL, RCL have released the code for the port; this was the first time I (or anyone outside of RCL / Private Planet as far as I know) had seen the source code for the port.

I had a look at the port last week and "live tweeted" my findings. To summarise here:
  • This is a good faith effort to comply with the GPL. It's not perfect as the libspectrum source should be available as well. but it's better than a lot of efforts. The inclusion of the build instructions explaining how to build it is one of the most often overlooked GPL requirements and RCL did include those.
  • That said, it's technically not a great port. The changes are monkey-patched into the generated files rather than being included properly.
  • Therefore I took the port and tidied it up a bit.
It's worth noting here exactly what the tidied up port does and doesn't do:
  • It doesn't fix any issues in the final binary, it just makes it all easier to work with so if anybody does find any issues and wants to fix them it will be easier to do so.
  • More crucially than that, it doesn't give a way to load the binary onto the Vega+. That's not something I can help with without a device, and quite probably not even then (whether I would be inclined to help is a different question and one I don't know the answer to at the moment).
  • Any changes to Fuse are never going to fix the well-reported issues with the Vega+ buttons. That's a hardware problem.
  • It's going to be pretty tricky to fix the performance issues as well. Fuse is pretty well optimized already, and it's not going to be easy at all to find the kind of performance gains needed - unless you're prepared to sacrifice accuracy, which is probably a valid decision.
jorallan: (Default)
If you're not involved in the ZX Spectrum emulation scene, feel free to skip this post. In fact, it's probably best if you do. For avoidance of doubt, this views in this post are purely my personal views and are not intended to reflect the views of the Fuse team in any way.

Just about anyone who's been around the ZX Spectrum emulation scene in the past 18 months or so is probably aware of the ongoing saga of the Vega+ and its failure to be released. One of the allegations which has been made is that the emulator involved in the original Vega (not Plus) was in fact a rip-off of Fuse, and not the work of Chris Smith. This is frankly, complete rubbish, and I've told Retro Computers that in the past. While it's pretty easy for those of us who enjoy digging into t-state timings to spot the differences, there's actually one very easy way to tell: as part of Fuse's development, the team have developed a utility called "fusetest" which digs into a few dark corners of the ZX Spectrum's behaviour. The primary use of this tool is as a regression test to make sure that we haven't broken anything before doing a new release, but it can serve a secondary purpose of spotting differences between one emulator and another.

And what happens if you run fusetest on the Vega? Yep, you guessed it, it displays significantly different behaviour from Fuse - in particular, it fails the "floating bus" test in both 48K and 128K modes, and the "High port contention 2" test in 128K mode. You can see all this in this short video I made with my Vega.

Let's hope this puts to bed any further repetitions of this allegation.

Oh, and anyone playing silly buggers in the comments, either here or on YouTube, will discover that I can play quite well too.

jorallan: (Default)
Imagine the situation: you've written a ZX Spectrum emulator. Because ZX Spectrum games took a while to load and your modern self has a short attention span, your emulator plays various tricks in order to speed up the loading of games. Unfortunately, these tricks aren't infallible so sometimes they actually mean the game fails to load instead of loading quickly. This is a bad thing.

The good news is that you can look at where the tricks are going wrong, work out why they're going wrong and change the code so that the game you're looking at now loads properly... however, how do you know that you haven't broken some other game somewhere? Well, about the only way to do that is to test things, and because I'm lazy and don't fancy loading in hundreds of games and working out if they've loaded or not, I want to automate that. In order to automate that, you need some way of detecting whether a game has loaded successfully or not.

Oh look, what do we have here? A database of 78 (as I write this - expect this number to grow) games, each of which annotated with a value that the Z80's program counter will reach if the game loads successfully. That sounds useful if you're, well... me. And maybe somebody else somewhere in the world, but who knows? The biggest problem here is that I can't distribute the games themselves as that would be a copyright violation[1], so you'll have to source them yourselves - but I have given you the SHA-256 of each game so you can know if you're using the same file as I am. And almost all of them are available from a certain well known site...
  1. Please don't start a debate on this.


jorallan: (Default)

April 2019

1415 16 17181920


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Apr. 22nd, 2019 11:02 pm
Powered by Dreamwidth Studios