Activity for Philip Kendall
-
Philip Kendall modified ticket #440
Remove use of deprecated `gdk_keymap_get_default`
-
Simpler version merged from branch patch-440-remove-gdk_keymap_get_default-2
-
Remove use of deprecated `gdk_keymap_get_default`
-
Remove use of deprecated `gdk_keymap_get_default`
-
Segmentation fault in readbyte (memory_pages.c)
-
Defensive code added to timer.c, going to close this one now, many thanks for the investigation and the fix here.
-
Segmentation fault in ula_contend_port_early (peripherals/ula.c)
-
Closing as a "duplicate" as this has the same root cause as #504.
-
For what it's worth, I know where the very large tstates value is coming from - in timer_frame, we set an event 10 (real world) milliseconds into the future. That's fine when running at "reasonable" speeds but when we get to silly speeds that becomes a rather large number. Given this is a "housekeeping" event used for speed control/calculations and the like, the simple method here would just be to cap the max time for that event to something reasonable. Agreed in the longer term it might be nice...
-
Bug #504 fix overflow in event_add_cmp
-
Thank you, great find. This is clearly a good fix and I'll merge it, but if you're able to find out what's generating the event with a very high tstates value that would be amazing. I thought the event times are always in "Spectrum time" so shouldn't be impacted by the emulation speed, but there may be something I'm forgetting.
-
(1) will as commented elsewhere do bad things to RZX playback; RZX frames can run to more than tstates_per_frame if they were created on an inaccurate emulator. (2) I'd be against as it is in the hot path. (3) has to a very real extent already been done in that the array is 80000 long as opposed to the 70908 tstates of the longest official model (+ a bit of bodge room for RZX). Making it a million long seems very wrong. I feel the correct fix here is to work out why tstates is so far out of bounds...
-
This will at best do bad things to RZX playback where tstates can go beyond the official frame length. I'll comment on the original issue.
-
Arbitrary scaling
-
Sergio: your comment on the wiki page says that this is unusable on Wayland and you have an idea to test - I assume this is still the case? (Sorry, not able to test Wayland at the moment as I'm running NVIDIA drivers for various reasons...)
-
Suppress a couple of -Wunused-result warnings from gcc
-
I think this one is now ready to go. Any objections to merging it?
-
Suppress a couple of -Wunused-result warnings from gcc
-
Thanks Berto, applied in [b0c7e5b7].
-
Fuse Next Release Plan
-
Arbitrary scaling
-
And a wiki page now created to evaluate whether this code is ready to go into a release... https://sourceforge.net/p/fuse-emulator/wiki/Arbitrary%20scaling/
-
Arbitrary scaling
-
I've just committed a change which prevents the forced resize of the window on scaler change if the scaler change was itself caused by a window resize. This led to a "fight" between the window manager wanting the window to be one size and Fuse trying to force it to another which caused some of the glitches when resizing the window.
-
Thanks Kevin. Just in case you're not aware, the reason that the +D messes up the ZX Printer is because they both try and use the same I/O port (0xfb). There's a valid argument that Fuse should give some clearer guidance if you select two peripherals which use the same port, but it's actually quite rare for people to try this...
-
OK, branch updated and we now have true full screen Fuse (in GTK+ 3 land, anyway). Hit F11 for goodness. There are quite a lot of glitches here with regards to window resizing / restoring after fullscreen mode but it basically works.
-
Let's commit these - the conclusion of my survey was that people prefer the "naive" integer scaling to 3x3 or similar pixels, so we'll certainly be keeping that around, just with arbitrary scaling "filling in" the gaps between the integers (or for going bigger than our largest scaler).
-
OK, first cut at this in the feature-138-larger-keyboard-image branch. Much less code, I like it. What would be nice here would be for the image to be resizeable... (and obviously Win32 support as well). (Whoops, meant to add: Happy New Year, folks :-) )
-
OK, first cut at this in the feature-138-larger-keyboard-image branch. Much less code, I like it. What would be nice here would be for the image to be resizeable... (and obviously Win32 support as well).
-
If anybody wants a go at this, it should be fairly easy to replace the code in ui/gtk/picture.c with some calls to the gtk_image_* functions.
-
Use a larger keyboard image
-
Looks good to me.
-
hq3x scaler is not redrawing properly
-
VNC keyboard not recognised by Fuse on Pi
-
Closing as this doesn't look like a Fuse issue. As an aside, the lack of press/release events on iOS is part of the reason for the Recreated ZX Spectrum doing such strange things with its keypresses...
-
And one more branch, "bug-414- remove-gdk-window-process-updates" which does what you'd expect; gdk_window_process_updates() isn't needed any more with changes in GDK. Again, I'll merge in a couple of days unless anyone finds a problem with it.
-
OK, a first attempt at this for GTK+ 3.0 only is in the "feature-135-arbitrary-scaling" branch. The basic principle is to use the scalers as we currently do scale up by integer amounts, and then to hand off to Cairo to do "the last mile". Seems to work pretty well to me, other than some glitches which occur when scaling the window as you move from 1.99x (1x scaler, Cairo providing 1.99x scaling) to 2.00x (2x scaler, Cairo scaling not being used). However, for the first time you can now maximize the...
-
Allow arbitrary scaling of Fuse window
-
GTK 3.x build uses deprecated functions
-
That branch merged as well.
-
Mouse grab causes GTK+ 3 display to stop updating
-
Merged as there were no objections :-)
-
Branch bug-414-remove-device-grab-functions removes the gdk_device_(un)grab functions. Probably worth testing in conjunction with the bug #435 fixes.
-
Caused by the disabling of the warping in bug #435 as the code assumes this happens. Might need a bit of a rework to look at storing diff from previous value instead.
-
Kempston mouse Y values are random on GTK+ 3.x / X11
-
A regression caused by half doing the changes in bug #435; fixed by completing that change properly.
-
Mouse grab causes GTK+ 3 display to stop updating
-
Kempston mouse Y values are random on GTK+ 3.x / X11
-
Kempston mouse values are random on GTK+ 3.x / Wayland
-
Kempston mouse Y values are random on GTK+ 3.x / X11
-
Kempston mouse Y values are random on GTK+ 3.x / X11
-
And some more extensive testing shows that we do actually want gtkui_drawing_area on GTK+ 2.x. So therefore: On GTK+ 2.x, warp relative to gtkui_drawing_area as before. On GTK+ 3.x / X11, warp relative to gtkui_window. On GTK+ 3.x / Wayland, don't warp. This is now all done in the bug-435-improve-kempston-mouse-handling branch. Please give it a test if you can... On Wayland, the values returned seem to be junk. I'll create a separate bug for that.
-
Some further trial and error guessing shows that changing the window used as dest_w to XWarpPointer from gtkui_drawing_area to gtkui_window makes things work on my machine (on both GTK 2.x and 3.x). Sergio, could you test this on your machine?
-
At least on my machine, this seems to be related to XWarpPointer even on X11; removing the call means that everything works.
-
Merged as nobody objected :-)
-
Anyone object if I merge the bug-414-gtk-deprecations branch, removing the use of gtk_widget_override_font?
-
And merged.
-
Thanks Sergio, that's definitely better - but still not quite right; At 1x1 scale, I get a thin transparent area to the right of the screen (see Fuse-1x1.png), and at maximum size, things get clipped again (Fuse-3x3.png). I'll apply the patch anyway as it's an improvement!
-
gcc 8 produces a number of warnings compiling Fuse
-
Warnings removed in the bug-436-remove-warnings branch, I'll merge in the next couple of days unless anyone objects.
-
And merged.
-
gcc 8 produces a number of warnings compiling Fuse
-
Mouse grab causes GTK+ 3 display to stop updating
-
GTK 3.x build uses deprecated functions
-
GTK 3.x build uses deprecated functions
-
The one use of gtk_widget_override_font in GTK+ 3 code removed in the bug-414-gtk-deprecations branch (one use remains in the GTK+ 2 memory browser).
-
Fuse's display fails horribly with GTK+ 3 under Wayland
-
Right, after many attempts finally got somewhere working out what's going on here - it's a Wayland issue. Running GDK_BACKEND=x11 ./fuse works absolutely fine, running GDK_BACKEND=wayland ./fuse (or just ./fuse as Wayland is the default backend on my laptop) produces the very broken display. As far as I can tell, this is a consequence of this issue reported on the GTK+ development list in 2017 where windows get an extra 52 pixels allocated under Wayland. That interacts very badly with our attempts...
-
OK, a first pass at this which adds a bp:data debugger system variable is now in the feature-134-data-byte-to-breakpoints branch. Point for discussion: the read breakpoints were currently tested before the memory location/port was actually read. Obviously this needs to happen afterwards in order for us to get the value. This has a couple of consequences if people are using conditional breakpoints (or the Python hooks): The timing of the breakpoint will be different Any effects of the read will have...
-
Expose the byte being read/written to breakpoints
-
Patches (almost exclusively from Alistair Cree[1]) now in the feature-133-ttx2000s branch. [1] who requested this feature in the first place ;-)
-
Emulate the OEL/Volex TTX2000S
-
1.5.6 regression: save binary no longer saves 64KB
-
1.5.6 regression: save binary no longer saves 64KB
-
Whoops! Now fixed in the bug-434-save-binary-cannot-save-64k branch which I'll merge in the next couple of days unless somebody finds a problem. Sorry...
-
Moonlighter does not load if loader detection is on
-
Unhelpful error message if a directory is specified on the command line
-
MASK does not load at all
-
Gauntlet 3 is not accelerated
-
Space Crusade is not accelerated
-
Dinaload games are not accelerated
-
Microprose loader is not accelerated
-
Software Projects loader is not accelerated
-
Software Projects loader is not accelerated
-
Gauntlet 3 is not accelerated
-
Fixed in branch bug-428-gauntlet3-not-accelerated. This also fixes Outrun Europa (sha256 93239ae632eedf467d168825bfe895aca00ab08e3c95a805fe2a0f135377d64f) and Shadow Dancer (sha256 854e5f0ddccb084b01a860b837cb2b9369c34f98e8c20b0fba5e826823b30abe).
-
Gauntlet 3 is not accelerated
-
Space Crusade is not accelerated
-
Fixed in branch bug-427-space-crusade-not-accelerated. This also fixes Lotus Esprit Turbo Challenge (sha256 79c8f9af9c450e8089c4e256d0d8b5b829b8cad2eebce3a3d91484d8927d1724).
-
Space Crusade is not accelerated
-
Dinaload games are not accelerated
-
Fixed in branch bug-412-dinaload-games-not-accelerated; this also fixes Astro Marine Corps (sha256 f5537ef00dfc0295fb5aa5765c26acf7f9b42116b77f0883120f012b32f9d46e).
-
SCF/CCF Z80 flags
-
And me. Applied (with a ChangeLog entry).
-
And merged.
-
Saving binary data increments tstate count
-
And done. Turned out there wasn't enough common code in the "load binary data" variants to be worth abstracting out, but there is now a utils_save_binary function if anyone wants it. I'll merge sometime early next week unless anyone objects.
-
OK, here we go :-) Ensure you've got the Python development headers installed on your system (python3-dev if you're a Debian person). Tested with Python 3, might work with Python 2. Check out the feature-131-embedded-python branch from git Run Fuse as PYTHONPATH=. ./fuse breakpoint.tap --debugger-command $'break 49153\nhook 1 1\nbreak 49154\nhook 2 1' RUN the not very complicated BASIC. Watch the screen turn blue and the attributes area be dumped to a file. To customize what happens, edit debugger.py...
-
OK, here we go :-) Ensure you've got the Python development headers installed on your system (python3-dev if you're a Debian person). Tested with Python 3, might work with Python 2. Check out the feature-131-embedded-python branch from git Run Fuse as PYTHONPATH=. ./fuse --debugger-command $'break <address of assert failure>\nhook 1 1' Watch memory be dumped to memory.bin when the assert failure hits To customize what happens, edit debugger.py - the breakpoint function will be called every time a...
-
Win32 / macOS: yes, definitely should change these as well. Let's add a single function for doing this so we don't have 4 copies around the codebase (there's another one in the Python integration now, which is why I spotted this!) Loading binary data: yes, should use writebyte_internal().
1 >
