XRoar 0.23 released

[sixxie]

(Finally!)

Home page: http://www.6809.org.uk/dragon/xroar.shtml
Source: http://www.6809.org.uk/dragon/xroar-0.23.tar.gz
Windows binary: http://www.6809.org.uk/dragon/xroar-0.23-windows32.zip
Mac OS X binary: http://www.6809.org.uk/dragon/XRoar-0.23.dmg

Changes:

* Full CoCo RAM select emulation.
* Implemented SAM FAST mode.
* Fullscreen fixes.
* Better handling of -load and -run options.
* Include "dark orange" VDG text mode colour.
* Initial ALSA sound module (-ao alsa).
* Read a configuration file on startup.
* Sun audio fixes.
* Experimental curses user interface.
* Run first non-option argument.
* WD279x fix.
* Fixed segfault in SDL joystick code.
* Work around nasty hang bug in SDL's pulseaudio module.
* Add ROM search path to Windows build.
* Add -gl-filter option to select OpenGL texture filter.
* Support directly loading ASCII files (.bas, .asc) as gapped ASCII BASIC.
* Write-back support for VDK and JVC disk images.
* Request filename when creating a blank disk.

The ASCII BASIC thing is kinda fun: type BASIC programs in your favourite text editor and load them in directly. You still need line numbers (and probably caps lock) unfortunately.

-gl-filter means you can choose linear (smoothed) or nearest (hard edge) scaling. The default (auto) gives hard edges when screen size is an exact multiple of 320x240, and smoothed otherwise.

Accepting a filename as the first non-option argument probably means you can set XRoar as a "handler" for some file types, maybe?

Oh and finally you can move your ROMs to "~/Application Data/XRoar/roms/" on Windows instead of having to keep them in the same directory. The ~ means your user settings directory (would be your HOME directory in Unix), and apparently is usually something like "C:\Documents and Settings\username" or "C:\Users\username".

The previous version didn't work with Mac OS X 10.6 apparently, and I've no ability to test this one, but seemingly SDL has seen some updates in the meantime which means it might now work.

Hope this is all useful!

[zephyr]

Excellent! Thanks Ciaran!

[sixxie]

Cheers

Also, I've just found someone with a fancy mac running 10.6, and it does indeed seem to work on there. Woo!

Edit: and in the process of that testing, found a bug in cart insertion from the UI. Brown Paper Bag release imminent...

[Alastair]

Thanks, I like the hard edge screen, it's much appreciated. But I have a problem with the sound, the Windows version creates a constant clicking even when I try "-fast-sound" or other releases of sdl.dll and libsndfile-1.dll. The only way to get rid of it is with "-ao null" but that's not really a workaround.

[rolfmichelsen]

Great stuff

[zephyr]

Thanks, I like the hard edge screen, it's much appreciated. But I have a problem with the sound, the Windows version creates a constant clicking even when I try "-fast-sound" or other releases of sdl.dll and libsndfile-1.dll. The only way to get rid of it is with "-ao null" but that's not really a workaround.

I don't have that problem on my PC under 32-Bit Windows 2000. The only problem I have is that it crashes (display goes black for a second, and xroar just seems to shut down?) when I switch to full screen using ctrl+f. Full screen mode has never worked properly on my machine. The early versions worked perfectly the first time switching to full screen mode, but crashed every time after that. Only a full power down/up or reboot would restore full screen after the crash. All other Dragon/CoCo (MESS, VCC etc) emulators work perfectly at full screen.

[Alastair]

Just adding that I am using XP (Home, SP3, 32-bit) and that I still have the sound problem with xroar-0.23a-windows32. However, unlike for Zephyr full screen works perfectly for me.

[zephyr]

Update:

Testing xroar 0.23a with '-vo sdlgl' and '-vo sdlyuv' video module settings produces the constant clicking fault described by Alastair above. Only the video output module setting that I normally use by default (-vo sdl) works without producing the constant clicking sound.

Full screen mode works perfectly when the '-vo sdlgl' setting is used, but this and '-vo sdlyuv' (which crashes badly in full screen mode) are way too slow to be practical on my 1 GHz PIII (Dragon emulation) machine. CPU usage is typically around 80-90% for these two settings while '-vo sdl' uses only around 40% at most.

[sixxie]

Thanks for the bug reports - I'm going to try and do a better job of logging them from now on.

The audio crackling does sound like a CPU issue, exacerbated by a lack of hardware assist in the scaling video drivers. If SDL doesn't find any hardware assist it can use, it does it in software which is nice and slow.

I'm not convinced '-vo sdlyuv' will ever be quick under Windows, but '-vo sdlgl' *should* be, *if* you have a graphics card and driver that supports render-to-texture without having to do it in software (now a relatively old OpenGL feature). I must admit, I've never had a report from any Windows user saying that the OpenGL output is nice and fast

The crash on switching to then from fullscreen in '-vo sdl' is very interesting: I was part way through a reply here when I tried it under Wine, and it managed to kill off X! Thankfully I can just restart that, but this gives me a test case. For this unscaled output mode, SDL requests a change in screen mode from the hardware (instead of scaling the image).

I'm going to test it with the pre-built SDL DLL from http://www.libsdl.org/download-1.2.php, but only after I've submitted this I'm not sure what I can do about a lack of hardware assist scaling in the other modes, but I'll have a google about and see if this is a common problem.

If it comes down to it, I'm willing to write a "Direct3D"(?) video output module if I can find some example code online - maybe that would be quicker.

[sixxie]

Ok, with the pre-built SDL DLL, in '-vo sdl', switching to and from fullscreen not only killed X, it left my console unusable. I had to log in remotely and reboot. I'll see if there are any other approaches to leaving fullscreen.

Out of interest, in the scaling modes, does '-fskip 2' (or more) alleviate the crackling at all? It's not ideal, but...