User:Compyx

Who am I

I'm an old C64 scener, look me up at csdk.dk if you don't believe me ;)

Personal devlog

TODO list

• 2016-09-xx: Try to build VICE on Minix 3.2.x (2016-10-05: Minix' own ports systems fails miserably building subversion)
• 2016-09-29: Test Android SDL2 build
• 2016-09-29: Fix build system for *BSD ports (2016-10-03: Done for FreeBSD, NetBSD, DragonflyBSD)
• 2016-10-02: Gtk2 crashes NetBSD VirtualBox VM, why? Logging doesn't help, empty log
• 2016-10-08: Clean up resource/cmdline code, using some kind of memory management/free list.
• 2016-10-09: Clean up c1541 and update man page.
• 2016-10-12: Update build systems with checks for minimum version required for autoconf and automake
• 2016-10-15: Update build system to allow building shared-ffmpeg without requiring root (liblame tries to install itself in `/usr/local/lib` during VICE's configure stage)
• 2016-10-25: Update palettes: rename vice.vpl -> pepto.vpl, default.vpl -> vice.vpl DONE, renamed vice.vpl to pepto-pal.vpl
• 2016-11-05: BeOS/Haiku doesn't log anything to LOG_DEFAULT except HardSID messages at startup.
• 2016-11-05: VSID: add HVSC Songlengths.txt support, maybe STIL as well. (For 3.1 or later)

BSD build system adventures

FreeBSD/PC-BSD

Version(s) tested: PC-BSD 10.3 amd64 (PC-BSD which is a preconfigured X11 install of FreeBSD)

Use gmake when building VICE! Use normal make when installing from the ports system.

Ports

• Xaw: builds and runs
• Gtk2: builds and runs
• Gtk3: builds and runs
• SDL1: builds and runs
• SDL2: builds and runs (very well even, best performance of the ports I've tested, most likely thanks to VirtualBox using HW rendering on my host)

(Tested in VirtualBox VM with guest additions). Still need to do a write-up on which libraries should be installed for building and for each specific port.

NetBSD

Version(s) tested: 7.0.1 amd64 (on VirtualBox 5.1.6)

Use gmake!

Some notes/observations:

• It has few weird conflicts with library interdependencies: a lot of foo.so.x needed but foo.so.y found, etc. May need to test the pkgsrc system, see if that behave any better, and perhaps run the system on bare metal.
• /dev/joy0 and /dev/joy1 can't be opened, <machine/joystick.h> is there and compiling against it works, same goes for USB joysticks, after installing libusb, usbhidapi and some others, configure sees the USB joystick support, but it doesn't work. Most likely a VirtualBox problem.
• HW rendering failed to build (failed at libdrm) while installing MesaLib7 through pkgsrc. So some ports had horrible performance.
• Sounds seems to work, but VBox doesn't output anything, most likely again a VBox issue, there are no guest-additions for NetBSD, there is an effort started in 2013 to port FreeBSD's guest additions to NetBSD, but that was abandoned.

All issues are related to properly configuring NetBSD, not something for VICE to worry about.

Ports

• Xaw: builds and runs
• Gtk2: builds and runs
• Gtk3: builds, starts, but hangs on initializing the Gtk3 widget for displaying the actual screen ("Gtk-WARNING **: Allocating size to GtkWindow 0x7f7ff493cd20 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?")
• SDL1: builds and runs, no HW acceleration yet, needs Mesa, which fails to build
• SDL2: builds and 'runs' (5fps, most likely due to Gallium using software rendering)

In-tree libraries

--enable-static-ffmpeg fails when building src/lib/libx264 => configure script needs bash, standard shell fails.

OpenBSD

Version(s) tested: 6.0 amd64

Can't get the bloody X server to behave :) (Again in VBox VM)

OpenBSD doesn't provide guest additions for VirtualBox, so for me sound output failed.

Ports

• Xaw: builds and runs
• Gtk2: builds and runs
• Gtk3: builds and runs
• SDL1: builds and runs
• SDL2: doesn't build, problem with uncompilable SDL2 headers

For some reason the SDL2 configure fails on the SDL2 headers. Need to figure out why?

Dragonfly BSD

Version(s) tested: 4.6 amd64 (inside a VirtualBox 5.1.6 VM, configured as FreeBSD)

Use gmake when building VICE.

Sound in VirtualBox

VB's default emulated audio device 'ich' causes some problems, so I set it to 'Intel HD Audio'. I had to add snd_hda_load="YES" to /boot/loader.conf to tell the kernel to load the Intel HD Audio driver to get access to dev/dsp for sound output. I then installed the alsa-utils package to get access to alsamixer to set proper volume. alsamixer needed to be called with its full path `/usr/local/bin/alsamixer` since Dragonfly BSD doesn't include /usr/local/bin in PATH.

GNU gettext

Make in po/ will output an error: sed: ./vice.pot: No such file or directory, when GNU gettext isn't installed. Install gettext and gettext-tools to avoid this.

Ports

• Xaw: builds and runs
• Gtk2: builds and runs
• Gtk3: builds and runs
• SDL1: builds and runs
• SDL2: builds and runs

Minix build system

Minix 3.3.0 doesn't provide X11 out of the box (eg binary packages), so I'll start with 3.2.1. I have no experience with Minx, except for installing it once about ten years ago, and deciding it sucked.

Minix 3.2.1

Useless. Subversion must be built from source through pksrc, but building fails with circular dependencies with libtool. GCC is 2.95(!), which is ancient.

Minix 3.3.0

Perhaps I'll look a this when I have absolutely nothing better to do, or am very drunk.

Haiku nightly build

Compiling and running (inside a VBox VM) works. No sound yet. Need to issue `make CFLAGS=-O0` to avoid gcc barfing on scpu. Building with --enable-ethernet fails since there is no `src/arch/beos/rawnetarch.{c,h}`.

Preparing for removing Gtk2 in favour of Gtk3

Since most modern operating systems used for VICE have support for Gtk3 and Gtk2 is no longer maintained, it makes sense to prepare VICE for using Gtk3 in stead of Gtk2. This means, for now, using a gtk2legacy wrapper module Groepaz started. This provided wrappers around Gtk2 code using the Gtk3 API.

The idea is to use the Gtk3 API in all Gtk/Gnome code while providing wrappers in gtk2legacy that translate those Gtk3 API calls into equivalent Gtk2 API calls. Once the Gtk2 API has finally been deprecated, we can simply remove gtk2legacy and use pure Gtk3.

The minimum Gtk3 version supported should be 3.16, since that introduces GtkGlArea, which should replace GtkGlExt.

GTk3 support for various operating systems

OS	distro/version	arch	Gtk2 version	Gtk3 version	date checked	notes
Linux	Debian Jessie 8.6	amd64	2.24.25	3.14.5	2016-10-09
Linux	Fedora 24	amd64	2.24.31	3.20.9	2016-10-05
Linux	Mint 17.3	amd64	2.24.3	3.10.18	2016-10-05
Linux	Mint 18.0	amd64	2.24.30	3.18.9	2016-10-05
Linux	Ubuntu 16.10	amd64	2.24.30	3.20.9	2016-10-26
BSD	FreeBSD 10.3	amd64	2.24.29	3.18.8	2016-10-05	used the ports collection
BSD	FreeBSD 11.0	amd64	2.24.29	3.18.8	2016-10-12
BSD	NetBSD 7.0.1	amd64	2.24.30	3.20.6	2016-10-05	used binary (pkgin) packages
BSD	NetBSD 7.0.2	amd64	2.24.31	3.20.9	2016-10-30	used pkgsrc in the absence of binary packages
BSD	OpenBSD 6.0	amd64	2.24.30	3.20.6	2016-10-12	used binary packages
BSD	DragonflyBSD 4.6.0	amd64	2.24.29	3.18.8	2016-10-13
BSD	DragonflyBSD 4.6.1	amd64	2.24.29	3.18.8	2016-10-26
Minix	3.2.1	i386	n/a	n/a	2016-10-05	the whole Minix build system is broken
BEOS	Haiku hrev50610	i386	n/a	n/a	2016-10-26	Haiku doesn't have Gtk at all, uses its own C++ InterfaceKit

Porting Gtk2 container types to Gtk3 container types

The current advise of Gtk3 is to use GtkGrid for any kind of layout container. Even GtkBox will someday be deprecated in favour of GtkGrid. For now, I'll use GtkBox untill the Gtk2 port has been completely removed, then we can tackle this.

GtkHBox and GtkVBox

GtkHBox and GtkVBox have been deprecated in favour of GtkBox.

I wrote a wrapper in gtk2legacy.c so Gtk2 code can use GtkBox while using the underlying GtkHBox/GtkVBox widgets. Naturally these calls aren't fully compatible, gtk_hbox_new() and gtk_vbox_new() use a `homogeneous` argument which determines if all widgets should be the same size. Since all VICE code use FALSE for this, gtk_box_new() works without having to set the homogeneous property afterwards.

GtkTable

GtkTable has been deprecated in favour of GtkGrid, porting this should be too much hassle, but lets see.

C1541 and VDrive

Both c1541 and vdrive need a lot of updating. Many commands are poorly or not implemented, Code uses confusing variable names and values. Documentation (C1541) is very much out of sync.

Documentation

Documentation, both user and API, is poor and out of sync. I'm updating the c1541 man page to reflect the commands actually in c1541, for all commands and related function I'm adding Doxygen documentation so that perhaps we can one day generate the man page from the Doxygen docs.

Code cleanup

The c1541 and vdrive code needs cleaning up

• Names like `unit`, `drive` and `device` are used interchangeably: sometimes `unit` is an actual unit number (8-11), sometimes it's an index into a vdrive array, values are arbitrarily AND'ed, OR'ed or subtracted to convert between 'valid' values for unit numbers and drive indici.

• Often user input for commands (c1541) is assumed to be correct. Leading to either weird error messages or even segfaults.

• CBM DOS command support needs work. The VDrive command handling is lacking some functionality as opposed to the actual CBM DOS.