fuse-emulator-devel — Development of Fuse (the Free Unix Spectrum Emulator), the associated utilities and libspectrum, the ZX Spectrum file-format handling library.

Re: [fuse-emulator-devel] W5100 emulation in Fuse

[Andrea <mar...@gm...>]

On 28/04/2021 15:12, Alan Cox wrote:
> On Tue, 27 Apr 2021 08:21:14 +0100
> Andrea <mar...@gm...> wrote:
> 
>> I see FUSE has a W5100 Ethernet card emulation
>> I think this is what VirtualBox does.
> 
> Take a look at
> 
> https://github.com/kvmtool/kvmtool/tree/master/net/uip
> 
> It's a dead project now but the uip code in it turns a raw network
> connection into host tcp, udp etc. You'd still probably need the DHCP
> proxy in there but it should let you turn macraw into host sockets for at
> least the simple stacks used on micros. There is a much better version of
> the code in very old versions of the Intel clear containers but I've no
> idea where you'd dig that out on the net any more.
> 

Yes, I can see they make up DHCP replies. This is exactly what I meant.
Would be nice to extract it and reuse it.

> Another bizarre but effective approach is to make your emulator one end
> of a simple VPN/IPIP tunnel instead and run the server end somewhere.


not sure I understand this. would it not require privileges too?

Re: [fuse-emulator-devel] W5100 emulation in Fuse

[Andrea <mar...@gm...>]

On 27/04/2021 12:46, Philip Kendall wrote:
> Andrea,
> 
> On Tue, Apr 27, 2021 at 8:57 AM Andrea <mar...@gm... <mailto:mar...@gm...>> wrote:
> 
>     I see FUSE has a W5100 Ethernet card emulation
> 
> 
> [ ... ]
> 
>     So this is the question I have for you: have you got any example of a ZX80 software that does DHCP
>     and this works with your W5100 emulation?
>     If yes, I am really curious to see how you did it.
> 
> 
> The simple answer here is "no" - what I realised while writing the W5100 emulation was
> 
> 1) that DHCP was hard (and needed root access, which I wanted to avoid)

So far in AppleWin the emulation requires libpcap and the capability to inject and receive raw packets.

> 2) The Spectranet (which is why Fuse has the W5100 emulation) can function with only TCP and UDP.
> 

I think this makes it a lot more portable and able to use non ethernet networks (the above code only 
works on an ethernet card in promiscuous mode, no wifi, vpn normally).

> so I took the easy route and just did TCP and UDP :-) As you've probably noticed, Fuse's W5100 
> support isn't really "emulation" but more proxying through to the OS's underlying stacks.

I think that as long as the guest software runs, it is doing its job.

Do you mind giving me some instructions on how to run Spetranet (I have never used fuse before).
I'd like to see the code in a debugger.

> 
> Cheers,
> 
> Phil

Andrea

Re: [fuse-emulator-devel] W5100 emulation in Fuse

[Philip K. <ph...@sh...>]

Andrea,

On Tue, Apr 27, 2021 at 8:57 AM Andrea <mar...@gm...> wrote:

> I see FUSE has a W5100 Ethernet card emulation
>

[ ... ]

So this is the question I have for you: have you got any example of a ZX80
> software that does DHCP
> and this works with your W5100 emulation?
> If yes, I am really curious to see how you did it.
>

The simple answer here is "no" - what I realised while writing the W5100
emulation was

1) that DHCP was hard (and needed root access, which I wanted to avoid)
2) The Spectranet (which is why Fuse has the W5100 emulation) can function
with only TCP and UDP.

so I took the easy route and just did TCP and UDP :-) As you've
probably noticed, Fuse's W5100 support isn't really "emulation" but more
proxying through to the OS's underlying stacks.

Cheers,

Phil

[fuse-emulator-devel] W5100 emulation in Fuse

[Andrea <mar...@gm...>]

I see FUSE has a W5100 Ethernet card emulation

https://sourceforge.net/p/fuse-emulator/fuse/ci/master/tree/peripherals/nic/w5100_socket.c

I am writing an emulation for this card for AppleWin (Uthernet 2).

I have a POC and was trying to understand if I could use the one from fuse.
I noticed the following difference:

fuse emulates udp and tcp, while I need ipraw and macraw.

So I did my homework and got them working.
But I then hit a few issues and wanted to understand how you solved them

- raw sockets require privileged access (annoying)
- impossible to forward udp packets for dhcp (root or no root).

The problem with udp packets is that I need to listen on port 67-udp and this is impossible because 
it is already taken by dnsmasqd on my system.

So this is the question I have for you: have you got any example of a ZX80 software that does DHCP 
and this works with your W5100 emulation?
If yes, I am really curious to see how you did it.

I have a solution, but it is a huge effort, where I intercept DHCP, reply wit a dummy (10.0.0.1) and 
then forward udp and tcp packets (a la NAT)
I think this is what VirtualBox does.

Thanks

[fuse-emulator-devel] Unused functions in Fuse

[Sergio B. <ser...@gm...>]

Hi,

I've used the utility callcatcher [1] to detect functions defined but
not called.

These are the results for Fuse project:

Common:
  compat_get_temp_path
  divide_refresh_page_state (leftover from 83579d refactoring and c98abd
cleanup)
  divmmc_refresh_page_state (copied from divide)
  fdd_strerror
  machine_get_id (leftover from 11b0a22 refactoring of tape_autoload)
  option_enumerate_media_phantom_typist_mode
  utils_networking_end
  utils_networking_init (should be used as both W5100 and TTX2000S
initialise sockets)

Detected only in widget UIs:
  debugger_search_instruction
  event_name
  menu_file_recording_rollbackto
  widget_dialog (superseded by widget_dialog_with_border?)
  widget_draw_rectangle_outline (superseded by
widget_draw_rectangle_outline_rounded?)

Mostly unimplemented features.

Detected only in GTK UI:
  compat_closedir
  compat_opendir
  compat_readdir
  gtkui_scroll_connect (leftover from b59fc8)
  menu_beta128a_detail
  menu_beta128b_detail
  menu_beta128c_detail
  menu_beta128d_detail
  menu_didaktik_a_detail
  menu_didaktik_b_detail
  menu_disciple1_detail
  menu_disciple2_detail
  menu_filter_detail
  menu_joystick_1_detail
  menu_joystick_2_detail
  menu_keyboard_joystick_detail
  menu_machine_detail
  menu_options_fullscreen
  menu_opus1_detail
  menu_opus2_detail
  menu_plus3a_detail
  menu_plus3b_detail
  menu_plusd1_detail
  menu_plusd2_detail
  menu_tape_detail
  scaler_select_bitformat
  ui_widget_end
  ui_widget_init
  uidisplay_spectrum_screen
  utils_read_screen

Mostly features for widget UIs.

Cheers,
Sergio

[1] https://github.com/caolanm/callcatcher

Re: [fuse-emulator-devel] End-of-life of SVGALib UI

[Sergio B. <ser...@gm...>]

On 22/2/21 0:44, Sergio Baldoví wrote:
> Last SVGALib release dates from 2001 and isn't available in major Linux
> distributions.
> 
> I'm planning to prune this UI code after the release of Fuse 1.6.0,
> barring objections.

SVGAlib UI has been removed in commit [3ee2bf].

Cheers,
Sergio

Re: [fuse-emulator-devel] Reading RZX through libspectrum

[Alexander L. <moo...@gm...>]

Hi Fredrick,

Thanks for your reply!
The answers are inline (and while I was answering, I realized how it's
supposed to work, so in the end of this message there's a description).

On 10 Mar 2021, at 07:50, Alexander Lyashuk <moo...@gm...> wrote:
>
> There is libspectrum_rzx_playback_frame() which seems to want to update
> some pointer to a snapshot (why?),
>
>
> Some RZX files (those that have used the RZX autosaves feature for
> example) have embedded snapshots inside the file at various points.
>

Yeah I know that, it was a bit unexpected to see "snapshot" and "frame" in
one function name.

RZX file is a sequence of blocks, which can be (among other auxiliary
blocks):
- A snapshot block.
- An input recording block.

An input recording block itself is a sequence of frames, where every frame
contains:
- a number of instructions
- a number of inputs in the frame (i.e. how many of instructions were "IN"
instructions), and those inputs themselves.


> and libspectrum_rzx_playback() which gets a pointer to the
> libspectrum_byte, so maybe it would be able to write the inputs?.. But from
> which frame/block and how does it know the size..
>
>
> You might find reading the RZX specs helpful if you haven’t already.
>
> https://web.archive.org/web/20080705124004/http://www.ramsoft.bbk.org/rzxform.html
>

I've seen that document indeed. I hoped to avoid needing to write a parser
from the spec (although it's quite an easy format), but I believe now it's
the easiest way to proceed.


> I think the inputs array for a frame has libspectrum_rzx_instructions()
> number of values.
>

It returns the total number of instructions in the frame, not the number of
the IN instructions.


> There is also a way to iterate over blocks, but doesn't seem to be any way
> to extract any information except snapshots from the blocks..
>
>
> The data is probably in the array pointed to by the libspectrum_byte
> pointer above.
>



Ok, now I've reread the rzx.c from the libspectrum, and seem to understand
what's going on. For the case someone will want to do the same, here is how
to use it:

1. The following function reads blocks starting from the beginning of the
file, until it finds the @which'th input recording block, and then stops.
If the previous block happens to be a snapshot block, it writes a pointer
to that snapshot to @snap parameter.
  libspectrum_rzx_start_playback( libspectrum_rzx *rzx, int which,
libspectrum_snap **snap )

2. To fetch input values of the current frame, call
  libspectrum_rzx_playback( libspectrum_rzx *rzx, libspectrum_byte *byte )
repeatedly until it returns LIBSPECTRUM_ERROR_CORRUPT (and prints error
message to console).
With every call, it will output a single value of input at @byte pointer.

3. To go to the next input frame (which may happen to be in the different
block), use
  libspectrum_rzx_playback_frame( libspectrum_rzx *rzx, int *finished,
libspectrum_snap **snap )
If you've called libspectrum_rzx_playback wrong number of times for the
previous frame, this function doesn't do anything and returns
LIBSPECTRUM_ERROR_CORRUPT.
Also if it happened to read a snapshot block while transitioning between
input blocks, @snap parameter is also populated.


While it's in my opinion a much less nicer API than other parts of
libspectrum, it's possible to fetch the information I need.
When I have enough time/enthusiasm, I'll send a patch with the following
changes:
1. Add function libspectrum_rzx_inputs() to {return
rzx->data_frame->count;} (so that there's no need to call
libspectrum_rzx_playback until LIBSPECTRUM_ERROR_CORRUPT)
2. Move corruption detection logic from libspectrum to fuse itself, as it
relies on the z80 emulation rather than purely on file format
3. Add a bit more documentation for those functions.
4. I'd like to rename functions or change API completely, but that would
break other tools that depend on rzx, so I won't do that.
Please suggest if you think those changes would make sense.

Thanks!

Re: [fuse-emulator-devel] Reading RZX through libspectrum

[Fredrick M. <fr...@sp...>]

Hi Alexander,

Just as a caution, I’m no expert on the RZX format or API.

> On 10 Mar 2021, at 07:50, Alexander Lyashuk <moo...@gm...> wrote:
> 
> There is libspectrum_rzx_playback_frame() which seems to want to update some pointer to a snapshot (why?),

Some RZX files (those that have used the RZX autosaves feature for example) have embedded snapshots inside the file at various points.

> and libspectrum_rzx_playback() which gets a pointer to the libspectrum_byte, so maybe it would be able to write the inputs?.. But from which frame/block and how does it know the size..

You might find reading the RZX specs helpful if you haven’t already.
https://web.archive.org/web/20080705124004/http://www.ramsoft.bbk.org/rzxform.html <https://web.archive.org/web/20080705124004/http://www.ramsoft.bbk.org/rzxform.html>

I think the inputs array for a frame has libspectrum_rzx_instructions() number of values.

> There is also a way to iterate over blocks, but doesn't seem to be any way to extract any information except snapshots from the blocks..

The data is probably in the array pointed to by the libspectrum_byte pointer above.

> Also I'm a bit puzzled by "libspectrum_rzx_playback: more INs during frame %lu than stored in RZX file (%lu)" error message in libspectrum sources, why would it know about number of actual INs, if it's just a library to read a file.

You maybe could reasonably make the argument that its the emulator’s job to track this rather than libspectrums. I wouldn’t know if there was a specific reason it was done this way.

Fred

[fuse-emulator-devel] Reading RZX through libspectrum

[Alexander L. <moo...@gm...>]

Hi Fuse devs,

I'm trying to read a .rzx file using libspectrum and cannot quite get the
right way to use the API.
Basically what I need is a dump of all input values as one long list of
bytes, I don't even need to split them by frames.

If there is a ready tool to do that, that would be even better. rzxdump
only shows the number of inputs per frame, but not inputs themselves.

There is libspectrum_rzx_playback_frame() which seems to want to update
some pointer to a snapshot (why?), and libspectrum_rzx_playback() which
gets a pointer to the libspectrum_byte, so maybe it would be able to write
the inputs?.. But from which frame/block and how does it know the size...

There is also a way to iterate over blocks, but doesn't seem to be any way
to extract any information except snapshots from the blocks..

Also I'm a bit puzzled by "libspectrum_rzx_playback: more INs during frame
%lu than stored in RZX file (%lu)" error message in libspectrum sources,
why would it know about number of actual INs, if it's just a library to
read a file.

Thanks!

Re: [fuse-emulator-devel] Fuse 1.6.0 released

[Fredrick M. <fr...@sp...>]

Hi,

> On 2 Mar 2021, at 10:54, Sergio Baldoví <ser...@gm...> wrote:
> 
> Is anyone maintaining this Twitter account?
> https://twitter.com/FuseEmulator
> 
> It would be nice to post the new release.

Agreed. I think only Phil has the credentials to the twitter account.

Fred

Re: [fuse-emulator-devel] Fuse 1.6.0 released

[Sergio B. <ser...@gm...>]

Hi,

On 1/3/21 11:48, Fredrick Meunier wrote:
> A new release of Fuse, the Free Unix Spectrum Emulator, is now available
> at the SourceForge project:

Is anyone maintaining this Twitter account?
https://twitter.com/FuseEmulator

It would be nice to post the new release.

Cheers,
Sergio

[fuse-emulator-devel] Fuse 1.6.0 released

[Fredrick M. <fr...@sp...>]

A new release of Fuse, the Free Unix Spectrum Emulator, is now available at the SourceForge project:

https://sourceforge.net/projects/fuse-emulator/

Highlights of this release include:
Add TTX2000S emulation
Experimental PulseAudio sound driver
Fix activation of joystick and IF2 peripherals when loading a snapshot
GTK/Win32: New higher resolution keyboard picture on GTK and win32 UIs
GTK: Add Fuse icon to the about dialog and the main window
GTK: Load/save binary dialog remembers last values
GTK 3: Improve moving and sizing Fuse's window under Wayland
GTK 3: Fix kempston mouse values on Wayland
GTK 3: Fix bug when resizing from 2x to 3x
SDL: Fix crash when using dispmanx backend on the Raspberry Pi
SDL: Allow forcing fullscreen mode when SDL doesn't report available screen modes
WidgetUI: New dialog to load/save binary data
WidgetUI: Enable HOME and END keys in menus
WidgetUI: Use monospaced characters on memory browser
WidgetUI: Fix crash when trying to overwrite read-only files
Win32: Fix bitwise operation in debugger
Xlib: Try to keep graphic filter when the user resize the window
Fix display corruption with HQ 3x scaler
Fix antialiasing effect of AdvMAME3x scaler
Add 4x, TV 4x, Pal TV 4x and HQ 4x scalers on GTK, SDL, win32 and Xlib UIs
Allow screenshots with TV 3x, PAL TV and Timex 1.5x scalers
Various minor bugfixes
Many thanks to everyone who's contributed to this release. Source code and binaries for Windows are currenly available on the SourceForge site; compiled binaries for various other platforms should become available in the next few days.

Fred

Re: [fuse-emulator-devel] Fuse 1.6.0 Release

[Derek F. <de...@sc...>]

> I've prepared the proposed release tarballs of fuse 1.6.0[1] and
> libspectrum 1.5.0[2] and uploaded them to sourceforge in staging
> directories. The tar files can be found in
> https://www.dropbox.com/sh/ljnvwn7p5vpku77/AACOCEfjze0xeW9rh1gNY0kca?dl=0
> [3] in the meantime for your final chance to flag showstoppers.

I've tested GTK3 and SDL1 builds on Ubuntu, and ran several games from 
different file types. No problems found. :)

Re: [fuse-emulator-devel] Fuse 1.6.0 Release

[Alberto G. <be...@ig...>]

On Sat, Feb 27, 2021 at 02:44:24PM +1100, Fredrick Meunier wrote:
> Hi all,
> I think we’ve come to the end of what we can quickly address for
> this release and the next set of changes can go to the next release.
> 
> I've prepared the proposed release tarballs of fuse 1.6.0[1] and
> libspectrum 1.5.0[2] and uploaded them to sourceforge in staging
> directories.  The tar files can be found in
> https://www.dropbox.com/sh/ljnvwn7p5vpku77/AACOCEfjze0xeW9rh1gNY0kca?dl=0 [3]
> in the meantime for your final chance to flag showstoppers.

I tested them in Linux and everything seems to work fine.

Berto

Re: [fuse-emulator-devel] Fuse 1.6.0 Release

[Sergio B. <ser...@gm...>]

Hi Fred,

On 27/2/21 4:44, Fredrick Meunier wrote:
> Hi all,
> I think we’ve come to the end of what we can quickly address for this release and the next set of changes can go to the next release.

Thanks. These are the Windows binaries...

Fuse 1.6.0 (Windows installer)
https://www.dropbox.com/s/6zokd2tmpqdao4u/fuse-1.6.0-win32-setup.exe?dl=1

Fuse 1.6.0 (Windows ZIP)
https://www.dropbox.com/s/efxmanrgr3js00b/fuse-1.6.0-win32.zip?dl=1

SHA1 checksums:
e51303c792c4039bf6beb0289a7ac48d2bfa611a *fuse-1.6.0-win32-setup.exe
a6ff61934928c0bbfcdee5231ce8e51947fbee9b *fuse-1.6.0-win32.zip

Cheers,
Sergio

[fuse-emulator-devel] Fuse 1.6.0 Release

[Fredrick M. <fr...@sp...>]

Hi all,
I think we’ve come to the end of what we can quickly address for this release and the next set of changes can go to the next release.

I've prepared the proposed release tarballs of fuse 1.6.0[1] and libspectrum 1.5.0[2] and uploaded them to sourceforge in staging directories. The tar files can be found in https://www.dropbox.com/sh/ljnvwn7p5vpku77/AACOCEfjze0xeW9rh1gNY0kca?dl=0 [3] in the meantime for your final chance to flag showstoppers.

I’d appreciate it if matching Win32 binaries could be built to add to the release directories as that seems to be the key platform downloading from sourceforge.

Phil: when and if you have a chance, it would be great if you could generate a signature for the release binary and add it to the staging directory.

I will aim to have a look at whether we need another release at the end of April.

Thanks,
Fred

[1] commit b2f1ea6cb63eb2849d2c9e138313aa425808be98
[2] commit f982a143c239497cc7ad7da4a805aa2ab7855970
[3] shasum:
47f1e56212b0660ed41655288ef1f2281228f311  fuse-1.6.0.tar.gz
21582a0f0abd73852d948fcedc32cf65327d90c0  libspectrum-1.5.0.tar.gz

[fuse-emulator-devel] Discussion about Fuse changes for hardware product

[<all...@he...>]

Hi,

I'm working on a product that uses a Raspberry Pi Zero W on a custom 
board running Fuse
called the Hermit Retro ZXZero. Development is now pretty much complete 
and I thought
it'd be a good time to contact you all to start a discussion about how 
the Fuse changes
could be incorporated into the main Fuse builds.

Info about the product is here:

https://hermitretro.com

(I also see increased chatter about a new version, so my timing is 
either great or
terrible!)

In summary, I've:

- Support for buildroot environment
- New GPIO-based peripherals for handling keyboard and joystick
- Disabled various menus

I've tried to keep the changes as minimal as possible and follow the 
general style.
I've uploaded Fuse 1.5.7 as a branch to my github and the current branch 
is also
there and can be directly compared if that's easier. Or, in general, 
grep for
BUILD_HERMITRETRO_ZXZERO.

This build uses SDL1. I see from chatter that that might be 
deprecated...

Direct comparison link between Fuse 1.5.7 and current branch:

https://github.com/hermitretro/fuse-hermitretro/compare/hermitretro-zxzero-1-0-0

I've attached some commentary of the various changes and why.

Thanks in advance,

A.

Changes
-------

libspectrum

- Minor changes to configure.ac to support --with-buildroot flag which 
basically adds -DBUILDROOT and enables building under a buildroot 
environment. This isn't used within libspectrum itself but leaving it 
out confuses the Fuse build

fuse-1-5-7

configure.ac

- Added --with-buildroot which removes the hard link to /usr/include and 
/usr/lib as buildroot builds are relative (usually 
$TARGET_DIR/usr/include during cross-compilation).
- Added --with-hermitretro-zxzero. Enable specific build for this 
hardware (also implicitly adds --with-buildroot, --with-gpio-membrane 
and --with-gpio-joystick)
- Added --with-gpio-membrane. Enables build of the new gpio-membrane 
peripheral)
- Added --with-gpio-joystick. Enables build of the new gpio-joystick 
peripheral

peripherals/hermitretro

- Added bcm2835.{c,h}. Low-level library for access to Raspberry Pi pins
- Added gpio-membrane.c. This adds handling for membrane/matrix-based 
keyboards in a generic(-ish) way
- Added gpio-joystick.c. This adds handling for Atari-based joystick in 
a generic(-ish) way
- Added gpio-common.c. Shared GPIO handler and the parent for the other 
gpio peripherals

fuse.c

- Add hermitretro peripheral registration
- Disable copyright display

infrastructure/startup_manager.h

- Add hermitretro peripherals

menu_data.dat

- #ifdef a whole load of menu options this variant doesn't need. The 
only change is really to rename File/Open... to Open...

menu.c

- Add a thunk function for the renamed File/Open to Open

spectrum.c

- Add polling for the new peripherals

ui/sdl/sdl.c

- Add polling in ui_event() for the GPIO peripherals. There's a comment 
in here that I'm unconvinced this should be here but if it's not none of 
the new peripherals work when widgets are displayed

ui/widget/about.c

- Added some info about Hermit Retro

ui/widget/widget.c

- Disabled some F keys

Re: [fuse-emulator-devel] GTK 4 UI roadmap

[Alberto G. <be...@ig...>]

On Mon, Feb 22, 2021 at 12:42:23AM +0100, Sergio Baldoví wrote:

> - Deprecate the GTK 2 UI before the release of Fuse 1.6 and prune the
> code after the release.
> - Integrate the feature request #135 (arbitrary-scaling) to get rid of
> window geometry hints.
> - Improve the code of GTK 3 UI following the migration guide [2],
> without the hassle of keeping GTK 2 compatibility.
> - We could stick to GTK 3 for a while and (optionally) develop GTK 4 UI
> - If it's hard to support both versions maybe split the UI build tree.

The plan looks good to me, thanks !

Berto

[fuse-emulator-devel] End-of-life of SVGALib UI

[Sergio B. <ser...@gm...>]

Hi,

Last SVGALib release dates from 2001 and isn't available in major Linux
distributions.

I'm planning to prune this UI code after the release of Fuse 1.6.0,
barring objections.

Cheers,
Sergio

[fuse-emulator-devel] GTK 4 UI roadmap

[Sergio B. <ser...@gm...>]

Hi,

GTK 4 was released in december 2020 and GTK 2 has reached its end of
life [1].

Supporting two major GTK versions is a pain to code and maintain but in
a long term we will probably support both GTK 3 and GTK 4.

The steps I foresee are:

- Deprecate the GTK 2 UI before the release of Fuse 1.6 and prune the
code after the release.
- Integrate the feature request #135 (arbitrary-scaling) to get rid of
window geometry hints.
- Improve the code of GTK 3 UI following the migration guide [2],
without the hassle of keeping GTK 2 compatibility.
- We could stick to GTK 3 for a while and (optionally) develop GTK 4 UI
- If it's hard to support both versions maybe split the UI build tree.

Opinions?

Cheers,
Sergio

[1] https://blog.gtk.org/2020/12/16/gtk-4-0/
[2] https://developer.gnome.org/gtk4/unstable/gtk-migrating-3-to-4.html

Re: [fuse-emulator-devel] Any plans for a new release ?

[Sergio B. <ser...@gm...>]

Hi Berto,

On 21/2/21 20:04, Alberto Garcia wrote:
> So it is perfectly possible to let people use SDL 2 as long as they
> don't use it for the UI. I wrote a patch to do that:
> 
>    https://sourceforge.net/p/fuse-emulator/patches/430/#f60f

That would be a nice addition. I'll test it ASAP.

Cheers,
Sergio

Re: [fuse-emulator-devel] [fuse-emulator-cvs] [libspectrum] branch master updated: Updates for a "1.5.0" release

[Alberto G. <be...@ig...>]

On Fri, Feb 12, 2021 at 10:43:44PM +1100, Fredrick Meunier wrote:
> >> ## * Always increase the revision value.
> >> ## * Increase the age value only if the changes made to the ABI are backward
> >> ##   compatible.
> >> -libspectrum_la_LDFLAGS = -version-info 16:14:8 -no-undefined @WINDRES_LDFLAGS@
> >> +libspectrum_la_LDFLAGS = -version-info 17:15:8 -no-undefined @WINDRES_LDFLAGS@
> > 
> > Do you think a soname dump is required?
> > 
> > I was expecting an increase of the age value too.
> 
> Hmm I did do an api compatibility check to decide on the appropriate
> values (see attached) and it reported that both source and binary
> compatibility has been affected by the changes.
> 
> The source isn’t 100% compatible due to the removal of
> libspectrum_snap_alloc_internal() which isn’t supposed to be part
> of the public API but is still being flagged.

I don't think that breaks source compatibility, the report is probably
because the symbol is exported in the .so file even though it is not
part of the public API.

We could hide those private symbols in this or in a future release.

> Binary compatibility is affected by the changes to the
> libspectrum_snap structure.so its a deliberate choice to not bump
> the age value.

But that's an internal structure, as far as I can see users of the
library can only see an opaque pointer.

Did you notice any compatibility problem?

Berto

Re: [fuse-emulator-devel] Any plans for a new release ?

[Alberto G. <be...@ig...>]

On Sun, Feb 21, 2021 at 11:42:15PM +1100, Fredrick Meunier wrote:
> > In case it helps the patch that I uploaded[1] contains a short commit
> > message with a description of the problem.
> > 
> > [1] https://sourceforge.net/p/fuse-emulator/bugs/369/#60ec
> 
> Thanks for your work in this area.
> 
> Is there any interaction between these, or are they both required?
> >   https://sourceforge.net/p/fuse-emulator/bugs/458/

I replied there already.

One more thing, we have an SDL 1 UI but that version of SDL has been
obsolete for a long time. I'm not sure how important that is because I
have the feeling that most (Unix) users are using the GTK UI.

There is a patch to add SDL 2 UI support (patch #430) but last time I
checked it I didn't have the time to review it carefully and I had the
impression that the code needed a bit more work.

However we also use SDL for the joystick and the audio driver, and
that code works already fine as it is with SDL 2.

So it is perfectly possible to let people use SDL 2 as long as they
don't use it for the UI. I wrote a patch to do that:

   https://sourceforge.net/p/fuse-emulator/patches/430/#f60f

(and I'm actually using it already in the Flatpak builds because SDL 1
does not come pre-installed in the runtime)

Berto

Re: [fuse-emulator-devel] Any plans for a new release ?

[Fredrick M. <fr...@sp...>]

Hi Berto,

> On 20 Feb 2021, at 23:26, Alberto Garcia <be...@ig...> wrote:
> 
> On Sat, Feb 20, 2021 at 11:00:46PM +1100, Fredrick Meunier wrote:
>>> Have you had a chance to review bug #369?
>>> 
>>> I can't review it technically but saving to tape work better with
>>> it.
>> 
>> Thanks for reminding me about this.
>> 
>> I’ll need to have another look at the TZX spec and friends as last
>> edges are something of a headache if I recall correctly. I think
>> we’d also want to add a regression test about this issue too to
>> document the behaviour.
> 
> In case it helps the patch that I uploaded[1] contains a short commit
> message with a description of the problem.
> 
> [1] https://sourceforge.net/p/fuse-emulator/bugs/369/#60ec

Thanks for your work in this area.

Is there any interaction between these, or are they both required?
>   https://sourceforge.net/p/fuse-emulator/bugs/458/
> 
> This is a fix for a well-known bug that causes loading errors with
> MASK, Lone Wolf 3, Basil and possibly others, but it's a bit of a
> bigger change:
> 
>   https://sourceforge.net/p/fuse-emulator/bugs/431/?page=1&limit=25#f102

Fred

Re: [fuse-emulator-devel] Any plans for a new release ?

[Alberto G. <be...@ig...>]

On Sat, Feb 20, 2021 at 11:00:46PM +1100, Fredrick Meunier wrote:
> > Have you had a chance to review bug #369?
> > 
> > I can't review it technically but saving to tape work better with
> > it.
> 
> Thanks for reminding me about this.
> 
> I’ll need to have another look at the TZX spec and friends as last
> edges are something of a headache if I recall correctly. I think
> we’d also want to add a regression test about this issue too to
> document the behaviour.

In case it helps the patch that I uploaded[1] contains a short commit
message with a description of the problem.

[1] https://sourceforge.net/p/fuse-emulator/bugs/369/#60ec

Berto