3.8.1

Things we wanted to do for the 3.8 release, but are now going to be in the 3.8.1 release:

Rationale: After 3.8 we want to fix the remaining joystick/controller/mapping related things, and also merge the SDL multithread stuff. Plus fix the resulting fallout, and the remaining issues below.

However, generally do not forget about the regular Todo page, which always contains some low hanging fruit :)

Joystick

The joystick system needs to be modified/extended to properly support custom button mappings.

See Joymappings for more information.

Keyboard

Analogous to the joystick mappings, we'll need to implement separate joystick keyset files. Currently the keymap files can (and do, in the case of keyrah), contain definitions for keysets. The issue is that the vkm files are loaded after vicerc, meaning any keyset definitions of the user in vicerc are overridden. This has the unfortunate result of the user configuring a keyset and it working until the user restarts vice.
See bug #1797 for some additional info.

SDL UI

• VICE logfine related settings are missing in the SDL UI (in trunk)
• "LogLevelANE" and "LogLevelLXA" are missing (in trunk)

Rendering

• TODO: support rotating the output by 90 degrees (CHIPRotate, canvas->videoconfig->rotate)
  • FIXME: the texture should rotate and scale to the window. This is handled in video_canvas_refresh(), but doesn't work correctly :/
  • TODO: check on al OSs.
  • TODO: check/fix mouse and lightpen emulation when screen is rotated/mirrored

GTK UI

• add missing $VICERES comments in the UI files, so ./gtk3-resources.py list-missing keeps working

• make autostarting disk images dragged onto the window optional (see the "Doubleclick for autostart" option for attach dialogs, perhaps extend the option to also cover drag'n'drop.
  • this should be a generic option (for all UIs) (in trunk)

integer resource "AutostartDropMode" was added to configure autostart behaviour on dropping an image onto the emulator window. Three modes: 0: attach-only, 1: attach and load, 2: attach, load and run (Default). The Gtk3 UI implements the behaviour, the resource and command line switch are generic, for future use by other UIs. (in trunk)

• Rework the "Machine" => "ROMs" dialog: much too unwieldy, there are too many different ROM file resources for the current layout.

Also either delete the "ROM sets" stuff or properly fix it.

A new ROM settings interface is in trunk, hidden behind --enable-debug-gtk3ui: with that configure switch a new settings node "Machine" -> "ROM Manager (WIP!)" will expose the new interface. The new interface actually implements saving and loading ROM set (.vrs) files, and allows users to revert a single ROM or all ROMs to default. The ROM set archive handling isn't implemented since that is a complicated mess and marked for deletion. See src/arch/gtk3/widgets/rommanager.c for details. (fixed in trunk, rommanager.{c,h} were renamed to settings_rom.{c,h} and the old ROM (set/archive) UI files were deleted)

• Check ReSID sliders: there's a good chance switching between FastSID and ReSID doesn't enable/disable the filter sliders (and reset button) properly. Both the normal emus and VSID need to be checked.

• Fix hotkeys UI: The dialog exceeds the limits set on dialog size

Rendering

• TODO: support mirroring the output (CHIPFlipX, CHIPFlipY, canvas->videoconfig->flipx/y) (enable in canvasrendermirrorwidget.c:canvas_render_mirror_widget_create())
• TODO: support rotating the output by 90 degrees (CHIPRotate, canvas->videoconfig->rotate) (enable in canvasrendermirrorwidget.c:canvas_render_mirror_widget_create())
  • the host window should change size/ratio
• TODO: check/fix mouse and lightpen emulation when screen is rotated/mirrored

• TODO: the macOS renderer must be checked and eventually updated for the new per chip resources. see eg r42892

• TODO: Window resizing needs more work to properly handle the resizing when toggling the visibility of the status bar.

Video capturing

FFMPEG (library) support is deprecated and disabled by default. We are developing two alternatives:

ffmpeg.exe

Instead of using FFMPEG via API and linking to the libraries, we use the ffmpeg executable and pipe the data to it (via web sockets).

• a runtime check and UI that warns when the exectable is missing needs to be made (fixed in trunk)
• needs to be tested and fixed on Windows, macOS
• FIXME: The port(s) that are used for streaming data to ffmpeg are currently hardcoded - this is a problem, because they might not be free to use
  • tried to use stdin for raw video+audio instead - it's a huge mess and doesn't really work as expected

ZMBV

Internal support for the ZMBV codec

• TODO: might even be possible to pipe ZMBV to external programs (such as OBS, or ffmpeg?) directly.
• somehow there are huge A/V sync issues. enabling/disabling warpmode makes it worse. (fixed in trunk)

Misc

• Chalkboard PowerPad must be added to the tables in the docs
• Implement "MachinePowerFrequency" (and -power50/-power60) for all emulators (code is already prepared for this in ifdefs), update the model-setting code accordingly, add GUI items to set power grid frequency in the model dialogs. (in trunk)
  • If it is correct that PETs do not use the power grid frequency, then the ifdef'd code should be cleaned out (removed in trunk)

• Fix WiC64 implementation
  • WiC64 logging stuff needs to be cleaned up, and all the WiC64 specific stuff removed and made generic (in trunk)
    • in the WiC64 code there shouldnt be any code related to logging, except the log_error, log_warning, log_message etc calls (in trunk)
    • colorizing shouldn't be a WiC64 specific thing, this needs to be handled in the general log system somehow (in trunk)
    • right now color codes end up in the regular log file too, because color codes are fed into the log_ calls. Instead the log_ calls should *produce* the color codes, and omit them when writing to a file.
    • +wic64colorizetrace is undocumented. this should be a global option too, not wic64 specific (in trunk)
    • "WIC64LogLevel" resource is not documented
  • WiC64 implementation has some weird "WIC64_CMD_IS_HARDWARE" command, which reports "we are an emulator". This is very much against what we want VICE to work like - it should behave like the real hardware, period. There is no reason for this kind of command, other than encouraging people to use it and somehow behave different in emulation. That's just a terrible idea, we removed all "emulator id" stuff long ago for the same reason. The emulator should behave exactly like the real hardware and software should not be able to tell the difference. (fixed accordingly in trunk)
    • "updating" the firmware does not work for that matter, seems the "restart" command hangs for some reason (does not handle the userport pins correctly)
  • Implemente WiC64_CMD_REMOTE_TIMEOUT, bump version to FW 2.1.0 (feature compatible)
  • WiC64 implementation adds resources (WIC64IPAddress, WIC64MACAddress, WIC64SecToken) which have no correspondent UI and/or commandline options - this should never be the case unless for very good reasons, which does not to apply here - eg the user might want to replicate an existing c64 setup exactly.
  • WIC64IPAddress should be initialized with the actual local IP, not some arbitrary random value, and it should be a full IP address, not just the last two octets.
    • IF the WiC64 Firmware has a DHCP option, VICE should offer that as well. If enabled, it should simply leave the resource alone, always use the current local IP, and not write that into the config

• Fix Userport system
  • The API that is used to register/show only user port devices which work on a certain machine is overcomplicated and broken:
    • Instead of trying to figure out what device works on a machine by using various flags, use a simple bit field that directly gives this info (in trunk)
    • All devices should be registered in a central function, not per emulator as it is now. (in trunk)
  • Currently the user port hooks/functions are not representing the actual user port pins. as a consequence eg user port devices that would not actually work at a real Plus4 would suddenly work on it in the emulation. This should NOT happen - only if the physical device would actually work in a machine, it should work in the emulation.
    • an acceptable exception to the above are the "internal" user ports, ie C64DTV and CBM2. However, the "rewiring" that is used should be fixed, ie using a theoretical adapter that every user port device uses.
    • Devices that work with a Plus4 currently need to either compensate for the internal re-wiring (PETSCII SNES Adapter) or adapted the VICE re-wiring and need to compensate for that when the system was fixed (Wheel Of Joy). Some appear to be plain broken (Userport I/O sim)
    • Unless any software for it exists, support for "Hummer Userport Joystick Adapter" should probably be removed from all emulators except DTV (in trunk)
      • this also applies to the userport parallel cable(s) - is there software for this? (yes, ui is fixed in trunk)
  • many functions are called by what they do in the context of the C64 emulator, this can be very confusing. Perhaps some can be renamed to refer to the actual user port pins instead.
  • the IDs should be fixed, and not change when a new device was added (update docs when fixed) (in trunk)
  • after the rework, the PET diag pin can be converted into a regular userport device (in trunk)
  • the userport rs232 interface should also be part of the userport system (in trunk)

• Fix VIC20 cartridge system
  • cartridge_get_info_list is not implemented (in trunk)
  • missing API calls: Final Expansion (.bin save, .crt save, flush image) Mega Cart (.bin save, .crt save, flush image) Ultimem (.bin save, .crt save, flush image) Vic FLash Plugin (.bin save, .crt save, flush image)
  • writeback with crt file is not implemented (in trunk)
  • missing GUI elements: Final Expansion (Flash) (save as, flush) Mega Cart (NvRAM) (save as, flush) Ultimem (Flash) (save as, flush) Vic FLash Plugin (Flash) (save as, flush)
  • adding a second cartridge via UI is broken and the code is very convoluted. perhaps introduce an extra API for this.

• Fix C128 cartridge system
  • snapshots are not supported yet (in trunk)
  • missing snapshot support in: Magicdesk128, Partner128
  • MMC Replay is broken in C128 mode

• Fix Plus4 cartridge system
  • make "exp" command in monitor work

• implement CBM2 cartridge system (in trunk)
  • don't forget to update crt.c, crtpreviewwidget.c, uicart.c (in trunk)
  • we might have to create 2 crt types for 5x0 and 6x0 machines (in trunk)

• Move "generic" cartridges into cartridge_info_t array of the respective cartridge system, then update uicart.c (GTK) to get the info from it, and remove the hardcoded stuff there. (in trunk)

• -default on cmdline should skip loading system files such as kernal from ~/.local/share/vice/$EMU/.
  • also skip customized joystick mapping and hotkeys from ~/.config/vice/.

Buildsystem

• README is currently updated from the same rule that generates infocontrib.h, this should be done in a different way

• make bindist is currently broken for USE_HEADLESSUI. (fixed only for Windows/msys2)

• some symbols appear in config.h that are not used anywhere (so they can be removed): AC_APPLE_UNIVERSAL_BUILD (?) -- This one appears to be added by autoconf itself, we don't set anything of the kind in configure.ac. --Compyx (talk)
  • EXTERNAL_FFMPEG (win32 and osx bindist greps for this in config.h!)

This is used to copy the ffmpeg DDLs into the bindist. Linking to ffmpeg is on its way out, replaced by using the (user-provided) ffmpeg executable, so I've removed the logic from the Windows scripts. The same should probably happen on MacOS, but I do not have a Mac to test this. --Compyx (talk) 08:49, 22 November 2023 (CET)

• • HAVE_EXTERNAL_LAME (osx bindist greps for this in config.h!)

• configure switch --enable-parsid should be removed and building of ParSID should be enabled when --with-libieee1284 is used.

Update the help message for --with-libieee1284 to mention ParSID building.

• configure switch --with-libieee1284 should cause an error when used on MacOS.

• we'll have to decide: do we want to keep the --without-zlib option? if yes, then we need an option to disable the GUI monitor (because vte needs zlib) and force it on when zlib is not available

Github Actions

• make-release.yml shows:

The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ (fixed in trunk)

• make sure both build-main-on-push.yml and make-release.yml (and perhaps others in the future) can "include" a common file that contains eg all configure options to use

• we need to somehow make sure that ideally 3 different configurations are tested (compiled and linked) at least once:
  • "everything" disabled. this makes sure we don't forget any stubs.
  • "everything" enabled. this makes sure all options actually work.
    • the actual posted "releases" should probably use something close to the former

The GHA should produce the html documentation and upload it to the website

• perhaps the entire website can be updated/produced/uploaded (removing another manual step from the release procedure)
• also the release tarball and binaries can be updated to sf (and zimmers perhaps?) automatically

• a GHA that builds macOS binaries should be added

• clang-tidy could be used to do more automatic codestyle checks

• Consider using a separate workflow for creating the matrices used for configure switches: right now the configure switches used for the various builds are spread over the jobs in two workflows (build-main-on-push and make-release and a shell script (build/github-actions/build-shared.sh). Using a single file for all the configure switches would make adding, editing and validating build options a lot easier.

See https://github.com/ch007m/test-github-action/blob/main/.github/workflows/reusable-config.yml for an example of how we could implement this.

Code streamlining

• In xvic the naming of the VIAs in the sourcecode is mixed up, it should be VIA1 for the one at 9110 and VIA2 for the one at 9120

• write a C <-> C++ wrapper for completions with linenoise-ng, so we can also drop linenoise (non-ng).

Headers

• many things that currently live in the archdep ui.h could be moved to the generic uiapi.h

disable non working things in the GUI

Things that don't actually work, and can't be fixed easily, should be disabled in the UI by default.

TODO: for the time being, make a list of all those things here, and keep it here, since obviously those are open ends and need to be fixed!

Some things must be enabled in the code:

Rendering:

• GTK3 UI: Mirror/Flip X/Y and Rotate 90 degrees is not working (disabled in canvasrendermirrorwidget.c:canvas_render_mirror_widget_create())

Drives:

• "IEC-Device" does not work in xvic and the IEEE machines (disabled in trunk)
• IEEE machines have no virtual device ("device traps") (disabled in trunk)

For development of certain devices, you can use --enable-experimental-devices, which defines HAVE_EXPERIMENTAL_DEVICES, to enable WIP code:

TODO: make sure the UIs use the following symbols to enable/disable the respective UI items: DRIVE_EXPERIMENTAL_DEVICES (drive.h), JOYPORT_EXPERIMENTAL_DEVICES (joyport.h), TAPEPORT_EXPERIMENTAL_DEVICES (tapeport.h), USERPORT_EXPERIMENTAL_DEVICES (userport.h) - use --enable-experimental-devices to enable experimental devices at configure time.

Drives:

• Professional DOS emulation doesn't work (https://sourceforge.net/p/vice-emu/bugs/759/) (disabled in trunk, unless DRIVE_EXPERIMENTAL_DEVICES is defined in drive.h)

Joystick port:

• Gun Stick lightpen emulation is not working (and disabled, unless JOYPORT_EXPERIMENTAL_DEVICES is defined in joyport.h)

Tape port:

• diag 586220 harness emulation is not working (and disabled, unless TAPEPORT_EXPERIMENTAL_DEVICES is defined in tapeport.h)
• DTL Basic Dongle emulation is broken (and disabled, unless TAPEPORT_EXPERIMENTAL_DEVICES is defined in tapeport.h)

Codestyle cleanup

Please make sure no files that do not respect the common code style sneak in again. Remember we removed the rule that "archdep files can ignore codestyle rules" long ago!

• use make stylecheck to run the general style checks

Status: this must be generally clear (checked by github builder)

• use ./src/findhacks.sh encoding to find files with illegal characters in them

Status: should be clean Gpz (talk) 22:47, 4 November 2023 (CET)

• use ./src/checkstyle.sh all to run some more style checks, in particular those that always produce some false positives

Status: code should be clean of C++ comments - please keep it that way!

obsolete ifdefs/resources cleanup

• TODO: VICE_USE_LIBNET_1_1 should probably get removed alltogether, unless we need to support some ancient libnet API for whatever reason

• use ./src/findhacks.sh obsolete to find defines that should no more be used - these should be replaced (eg use WINDOWS_COMPILE instead of _WIN32) or removed. Ideally this finds no files.

Status: seems clean, shows a few false positives Gpz (talk) 22:49, 4 November 2023 (CET)

• use ./src/findhacks.sh res to find obsolete resources - this should find nothing (except a couple false positives)

Status: clean, shows a few false positives Gpz (talk) 22:49, 4 November 2023 (CET)

Archdep cleanup

There are still various bits of archdep things dangling around in common code

• use ./src/findhacks.sh archdep to find such code - a lot of this (if not all) should live in arch/shared
  • remaining cases should always come with a comment telling why there is archdep stuff and why it has to be in common code

Status: shows quite a few cases, this still needs some more work/cleanup

• TODO: review ifdefs that check SDL vs GTK3 UIs - since many resources/features are available for both now, some of these checks can likely be removed
• TODO: the functions in src/arch/macOS-util.c should be renamed to archdep_... instead of vice_macos..., empty functions created for non macos, header renamed to archdep_... , and then called unconditionally from common code
• TODO: Remove support for 'classic' BeOS, only support Haiku.

Change the make bindist method for Haiku into make install.

Compiler-dependent ifdefs cleanup

vice.h is the only file where ifdefs are allowed that check for a specific compiler.

• Use ./src/findhacks.sh ccarchdep to find occurances elsewhere in the code, they should be removed in almost all cases.
  • remaining cases should always come with a comment telling why there has to be compiler specific stuff

the exception to that rule is generated code (mon_parse.c, mon_lex.c) and a few occurences in our "novte" hack

Status: Codebase seems to be clean now Gpz (talk) 16:43, 25 March 2023 (CET)

Debug and log messages cleanup

We have a lot of noise on the terminal, it might be a good idea to clean that up.

• use ./src/findhacks.sh printf to find printf calls that need to turned into log_debug calls (log_debug adds a newline, keep that in mind to avoid lots of empty lines in the log when changing printf to log_debug!).

Status: still shows quite some work to do :)

• decide if we really need that message in the log, perhaps it can be surrounded with #ifdef DEBUG / #endif so the messages are only shown when compiling with --enable-debug?
• also check disabled (commented-out) printf/log_debug calls, will we ever need them again?
• a lot of devices / modules use LOG_DEFAULT for logging, but they should use their own log_t instead (for easier filtering)
  • do NOT use LOG_ERR to log errors for that matter, use log_error, log_message, log_verbose etc for different types of messages/log levels
• if really a quick "printf" is desired, use log_printf instead, which is a "printf" at "debug" log-level
• when coloring terminal output, _always_ set both foreground _and_ background colors. Generally coloring terminal output correctly is more complex that it seems on first look - you can not assume that the background is a certain color!

static buffers cleanup

It should be good practise to allocate and use memory dynamically, instead of using global static buffers - especially if those are considerably large. However, this is still being done all over the place.

• use eg ./src/findarrays.sh list x64sc to show a list of all static arrays.
  • the largest 10 (or so) are always good candidates to be converted into dynamically allocated buffers.
  • besides the obvious few large ones, there are also many other buffers that could be dynamic (eg drive ROMs, which could be allocated and loaded only when actually used)

Resources

There are a bunch of resources that have different names in SDL or GTK3 UIs, or which are specific to one of them. We should name those that do the same thing the same, and - as far as possible - get rid of the specific ones (by implementing the same feature in the other UI)

• the same applies to the related commandline options, of course
• NOTE: CHIPxyz resources should be registered in video-resources.c and the related variables go into the video_render_config_s struct (unless they fit into the video_resources_s struct)

Resources without UI support

Some resources exist internally but should not be used by the UI. For the time being, make a list of these here (and keep it here).

Also, by all means, please avoid to create new resources that go into this list - we should rather try to eliminate all of them!

Resource	Emulators	Status
BoardType	x64, x64sc, xscpu64, x128	set implicitly by "model" API
DTVFlashRevision	x64dtv	set implicitly by "model" API
CartridgeFile	x64, x64sc, xscpu64, x128, xplus4, xvic, xcbm2, xcbm5x0	set implicitly by cartride API
WIC64IPAddress	x64, x64sc, xscpu64, x128, xvic	set implicitly by WIC64 emulation
WIC64MACAddress	x64, x64sc, xscpu64, x128, xvic	set implicitly by WIC64 emulation
WIC64SecToken	x64, x64sc, xscpu64, x128, xvic	set implicitly by WIC64 emulation
EventEndSnapshot	all except VSID	Probably command line only?
EventImageInclude	all except VSID	Probably command line only?
EventStartSnapshot	all except VSID	Probably command line only?
ExitScreenshotName	all except VSID	Command line only
ExitScreenshotName1	x128	Command line only

Docs

vice.texi:

use cd doc && ./checkdoc.mak all ; cd ..

• list of userport devices must be updated, once userport system was changed so the numbers are fixed

• split vice.texi into smaller files
  • CAUTION: various scripts use vice.texi as input

• Some info from the WIKI still needs to be revised and moved into vice.texi
  • https://vice-emu.pokefinder.org/wiki/RS232

• some descriptions of emulator formats are missing (D67, D1M, D2M, D4M...)
• descriptions of several snapshot modules are missing (Plus4, TED...)

• many nodes are not yet linked correctly, which makes some of the exporters output garbled and/or suboptimal output (unix .info).

Workaround: use the .html or .pdf documentation, which is exported correctly.

for details look at doc/Documentation-Howto.txt

Build instructions

• Update MSYS2 instructions to only use the pacman package manager, not a mix of pacman and pacboy. Although pacboy enables a user to not have to type the arch/repo prefix for packages (e.g. "mingw-w64-x86_64-"), it is highly confusing to use two package managers with different syntaxes.

See Windows-MinGW-GTK3-Howto.txt

other

• Write a HOWTO for running Github Actions locally using act.

Data

Keymaps

• Some keymaps need to be checked: cbm2-symbolic-de(gtk/sdl), cbm2-symbolic-us(gtk/sdl), plus4-symbolic-de(gtk/sdl), plus4-symbolic-us(gtk/sdl)
  • make sure to treat KP_Separator exactly the same as KP_Decimal.

ROMs

• Ultimately rename all ROM files using a naming scheme as in "kernal-901227-01.bin". Unfortunately some files could not be identified yet:
  • C128 ROMs: kernalfi, kernalfr, kernalit, kernalno
    • when ROMs have been identified, fix the code/checksums in c128rom.h/.c
  • Printer ROMs: mps801.bin, nl10.bin
  • SCPU ROM: scpu64 (wanted is the part number of the actual SCPU ROM / what is written on the sticker)
  • PET ROMs: chargen.de

3.8 Feedback threads

• https://csdb.dk/release/index.php?id=238034
• https://www.lemon64.com/forum/viewtopic.php?t=83718
• https://www.forum64.de/index.php?thread/143010-vice-3-8-has-been-released/

even later

see Roadmap for the long term plan

---

After a release was made:

• copy this page to a new X.Y.Z page.
• Move this page to Category:DONE.
• Remove all crossed-out stuff from new page.
• Update Todo and Category:TODO.
• Update Roadmap