XRoar 0.24 released

[sixxie]

Finally! I have a big set of local changes lined up (mostly a reasonable GTK+ GUI under Linux), but I've resisted the temptation to wait until that's "done"

No big difference to the snapshots that have been available for a while, so unless you hit the "won't load Rommel's Revenge" bug I rolled back before releasing this, there shouldn't be any specific need to upgrade if you have one of those.

http://www.6809.org.uk/dragon/xroar.shtml

[snarkhunter]

... so unless you hit the "won't load Rommel's Revenge" bug I rolled back before releasing this, there shouldn't be any specific need to upgrade if you have one of those.

Thank you very much for this new release of yours!
I didn't know about the issue with that game. So I've just tried to run it under 0.23 (and from a ".vdk"). The result is the emulation consistently crashing... after a seemingly random delay (or event). I just could play for a few minutes before "XRoar" eventually froze whereas at other times, this happens much, much sooner.

Well... who wants to play that game forever, anyway?!

[sixxie]

Hang on, you have a problem playing it?

I was referring to the loader failing - it has a fancy loader that scrolls a load screen up from the bottom, and I'd tried to be clever about CPU timing and that made the loader fail after a few lines.

[snarkhunter]

Hang on, you have a problem playing it?

Yes I do. The game will run for a while, then will end up "freezing": this can happen after two minutes, or at the third game in a row. The emulation suddenly gets stuck on the current display (i.e. no crashing of XRoar).

There's one thing, though: I couldn't tell for sure this works any better on a real Dragon, although I seem to remember playing this game for ages when we first had it.

I guess I could try under various configurations, as well as within MESS, for instance...


[Edit: "MESS" does crash too, in just the same way (i.e. "randomly", after plaing the game for a couple of minutes...)]

[sixxie]

The game will run for a while, then will end up "freezing": this can happen after two minutes, or at the third game in a row. The emulation suddenly gets stuck on the current display (i.e. no crashing of XRoar).

So far I've failed to reproduce this. I've tried several games in a row (holding F12 and moving around very quickly, but not really *playing* for score) but it keeps on going.

For reference, I'm using this copy here: http://www.6809.org.uk/tmp/da/games/rommels_revenge.cas

Is there anything I can do in-game that you think might increase the chances of a lock-up?

Also, if the emulation itself hasn't stopped, might be worth hitting Ctrl+V for a bit (hit it again to stop) and getting some trace data, see what it's trying to execute.

[snarkhunter]

So far I've failed to reproduce this.

So have I! My mistake: I was actually referring to Microdeal's "Rommel 3D", and not to the game from Design Design. Both games are very similar, as far as gameplay/graphics are concerned. But the former uses a PMODE4 display, and the latter, a PMODE3 one. So I've just tried the ".cas" file for the latter and couldn't experience any crashing of the system. But the former (loaded from my own "ARCAD01B.vdk" disk) does crash after a while. Perhaps I should convert it to a ".cas" file, then try it again in "32/no DOS" mode, or even try the file from the archive...

(game is loading right now...)

... Got it! the tape version of "Rommel 3D" just crashed again, at my third or fourth game. So the issue is indeed with Microdeal's game, not Design Design's.

[sixxie]

I think it's probably something to do with the fact that IRQs aren't latched quite right: something I've been trying to think of an efficient way to do for a while. I'll revisit it (it may end up being optional, because it involves checking each cycle in an instruction (edit: or at least before the last cycle in an instruction)).

That said, tracing for a while doesn't seem to reveal the usual culprit: a tight loop checking for IRQ that never sees it because the service routine runs and clears it first. Bad coding tbh, but usually things get away with it.

[sixxie]

If anyone fancies giving the GTK+ interface a go under Linux, there's a source tarball and amd64 Debian package here: http://www.6809.org.uk/tmp/xroar/. Still a lot to be done, but hey, menus! It's like we're living in the future or something.

You'll need GTK+2 and GtkGlExt headers & libraries (libgtk2.0-dev and libgtkglext1-dev packages under Debian) if you want to build it yourself.

The support code for this should also help any other new UI module, assuming I get time and documentation (and inclination, I guess - happy to help anyone else tackle it though) to make them...

[zephyr]

Thanks Ciaran!

[robcfg]

If anyone fancies giving the GTK+ interface a go under Linux, there's a source tarball and amd64 Debian package here: http://www.6809.org.uk/tmp/xroar/. Still a lot to be done, but hey, menus! It's like we're living in the future or something.

You'll need GTK+2 and GtkGlExt headers & libraries (libgtk2.0-dev and libgtkglext1-dev packages under Debian) if you want to build it yourself.

The support code for this should also help any other new UI module, assuming I get time and documentation (and inclination, I guess - happy to help anyone else tackle it though) to make them...

Hi, I compiled it in Linux Mint under VirtualBox and it's very nice to have the menus!

I cannot get the program to recognize the Dragon64 ROMS, I've followed the instructions but I don't really know now where to store the roms. I'm using the default config so they should be in /usr/local/share/xroar/roms (named D64ROM1.ROM and D64ROM2.ROM).

Anyway, Great Work! The menus were a missing feature of Xroar for a long time.