XRoar 0.28 available

[Alastair]

I do not see the problem that Rob sees with the GTK version when using the DLLs in either gtk+-bundle_2.24.10-20120208_win32.zip (the latest version) or gtk+-bundle_2.16.6-20100912_win32.zip (mentioned here). But with both bundles I had to make a copy of "zlib1.dll" and rename the copy "libz-1.dll" before XRoar would start.

[sixxie]

Good to hear, in a way...

There is one significant change in the OpenGL code since I last built a Windows GTK+ exe: it uses vertex arrays now. But this is supposed to be the recommended approach anyway, and should make it easier to adapt to an OpenGL ES version.

The way it's described, it sounds like the OpenGL context thinks it has the space of the menu bar as part of its geometry... Just out of interest, what happens if you resize the window?

[Alastair]

Just out of interest, what happens if you resize the window?

In my case it works just fine, see pic below. One difference between my set-up and Rob's is that I use the "Classic" theme in XP whereas Rob appears to be using the default theme in Windows 7. Could this be the cause of the problem or could it be the GTK DLLs that Rob is using?

Rob, in an effort to check the latter, would you download gtk_libs_for_xroar-windows32.zip from here, unzip the DLLs to the same directory as xroar-gtk.exe, then make a copy of zlib1.dll and rename the copy libz-1.dll, then try running XRoar again?

[robcfg]

Hi,

If I resize the window, the menu bar appears normally, but the moment I stop clicking the mouse, it turns black again.

[sixxie]

Do the borders top and bottom look even with the blacked out menu, or does that make the top border look larger? Another way of asking I guess: if you put it into a graphics mode, does the menu stay black, or is it drawn over by the coloured border?

[robcfg]

Nice one!

It remains black.

[robcfg]

Hey, I tried the dll pack Alastair mentioned and I don't get that problem anymore. Weird...

Thanks for your help!

[Alastair]

Hey, I tried the dll pack Alastair mentioned and I don't get that problem anymore. Weird...

Thanks for your help!

Good to hear, this means that the issue was a DLL problem rather than an XRoar or Win 7 problem.

[zephyr]

I've had a go at fixing most of the issues in this thread, and pushed new snapshot builds out here:

http://www.6809.org.uk/tmp/xroar/

Hopefully no regressions... The Address-Dependent CPU rate mode doesn't seem to quite tally, but it's much closer.

This also includes new VDG code that copes with sub-scanline mode switching a lot more accurately. Specifically, it accounts for the fact that changes to CSS and !INT/EXT are delayed in relation to all the other mode select lines - this can be explored with the 'stripe' test from http://www.6809.org.uk/tmp/da/tests/. Controls:

Code: Select all

; Video mode changing test.

; Timed to render a diagonal stripe across the screen using only
; mode changing.

; Controls:
;     Up, Down, Left, Right - move stripe around by changing timings.
;     1, Q - Set/reset !A/G, GM2, GM1
;     2, W - Set/reset GM0 (and !INT/EXT)
;     3, E - Set/reset GM2, GM1 (switch between 32- and 16-byte graphic modes)
;     4, R - Set/reset CSS
;     Enter - Cycle through different screen patterns
;     Break - Return to BASIC

; Hold Shift to apply mode changes to background instead of stripe.

Another amusing extra is support for keyboard "ghosting" - test by holding down 'W' and 'S' and pressing Shift a few times. And note how Shift+Clear+/ doesn't generate a backslash, like on real hardware.

Ciaran, I notice that you have released two snapshot versions since. What changes did you make after the release of 20120922?

[sixxie]

Ciaran, I notice that you have released two snapshot versions since. What changes did you make after the release of 20120922?

A few bits and bobs but the biggest work in progress (and I stress that it is *horribly* incomplete) would be the -machine-cpu option.