Alceste Scalas

Yes, I think so. Thanks!

I tested r39922, and it looks good to me. Thanks! I am attaching a small patch that improves the error message when the Ethernet cartridge emulation cannot be initialized. The main use case the patch addresses is: a user enables Ethernet cartridge emulation without first setting up ETHERNET_INTERFACE (either on .vicerc or via the GUI). When this happens, VICE selects a default interface (eth0 on Unix) that may not even exist, and this may be quite puzzling.

Just for clarity, I am attaching the Ethernet settings window I can see on my system, running r39902. This drop-down box allows users to select the TUN/TAP device, without having to write its name in a textbox: would this be enough, besides some polish and more helpful error messages? Besides: I have noticed that vice is now sometimes trying to load the libpcap Ethernet driver first, and causing errors without falling back to the TUN/TAP driver (even if I select the latter in vicerc, via ETHERNET_DRIVER="tuntap")....

Just for clarity, I am attaching the Ethernet settings window I can see on my system, running r39902. This drop-down box allows users to select the TUN/TAP device, without having to write its name in a textbox: would this be enough, besides some polish and more helpful error messages? Besides: I have noticed that vice is now sometimes trying to load the libpcap Ethernet driver first, and causing errors without falling back to the TUN/TAP driver (even if I select the latter in vicerc, via ETHERNET_DRIVER="tuntap")....

Just for clarity, I am attaching the Ethernet settings window I can see on my system, running r39902. This drop-down box allows users to select the TUN/TAP device, without having to write its name in a textbox: would this be enough, besides some polish and more helpful error messages? Besides: I have noticed that vice is now sometimes trying to load the libpcap Ethernet driver first, and causing errors without falling back to the TUN/TAP driver (even if I select the latter in vicerc, via ETHERNET_DRIVER="tuntap")....

Regarding the GUI support: I also wanted to only show TUN/TAP devices, but I could not find a portable way to list TUN/TAP devices. There is some code in iproute2, but it is Linux-specific Besides listing the TUN/TAP interfaces, it may also be advisable to only list the devices that have type TAP (not TUN!) and are accessible by the current user. However, I suspect that this would require even more non-portable code... In any case, users needs to set up the TAP device they want use with vice, so...

Great news! Unfortunately I will be very busy in the upcoming weeks, but I will try to update the documentation. Meanwhile, here are a few answers: one thing i didnt quite understand: why at the bottom of rawnetarch.c there is (bunch of #ifdefs)? Good question! Those #ifdefs are a leftover from the original patch, and they should be removed. Now both rawnetarch_tuntap.c and rawnetarch_unix.c are always compiled under Unix (see Makefile.am), and they have their own #ifdefs to check whether their dependencies...

Great news! Unfortunately I will be very busy in the upcoming weeks, but I will try to update the documentation. Meanwhile, here are a few answers: one thing i didnt quite understand: why at the bottom of rawnetarch.c there is (bunch of #ifdefs)? Good question! Those #ifdefs are a leftover from the original patch, and they should be removed. Now both rawnetarch_tuntap.c and rawnetarch_unix.c are always compiled under Unix (see Makefile.am), and they have their own #ifdefs to check whether their dependencies...