3.8
Things we want to do for the 3.7.2 release:
Rationale: After 3.7.1 we want to merge Fabbo's joystick mapping stuff asap, and then fix the fallout - which perhaps includes what is listed below.
Joystick
The joystick system needs to be modified/extended to properly support custom button mappings.
See Joymappings for more information.
- Change the resources "JoyDevice{N}" to use strings with device identifiers instead of an index of the predefined and connected devices. So for example a Logitech F710 controller would be "001:006:046d:c21f" (usb-bus 1, device-no 6, vendor-Id 046d, product-Id c21f). We'll need archdep code to translate the strings into something the underlying arch driver can use, so at least handlers for Windows, MacOS, Linux and the various BSDs.
- Relying on the device product/model ID won't be enough: a user can have multiple controllers of the same model.
- Provide a joymap file per device identifier that can be loaded/edited/deleted, perhaps auto-load when JoyDevice{N} contains such an identifier.
- Make the joymap files use (UI) action identifiers instead of the "menu paths" SDL does.
- Make the joymap files human-readable by not doing what SDL does: for example: don't use 0-3 for input type, use ["axis", "button", "hat", "ball"], don't use 0-6 for the 'action' row, use "none" (or leave it out)", "joystick", "keyboard", "ui-action, "pot".
- keep in mind there needs to be a way to map both "paddles" and "joysticks"
- Dialogs need to written to handle all of this.
(moved to Joymappings)
Branch fabrizio/3.7-joystick-mapping
Joymappings (WIP) contains details about what this does
The SVN branch branches/fabrizio/3.7-joystick-mapping contains code implementing custom joystick button mapping that isn't SDL-specific. Unfortunately the branch doesn't merge with trunk. As a workaround checking out the branch and doing a diff between the branch and trunk appears to generate a diff that can be applied with patch to "merge" the branch into trunk.
The following instructions assume VICE SVN root to be at $HOME/src/vice, with $HOME/src/vice/trunk being our trunk and $HOME/src/vice/branches/fabrizio/3.7-joystick-mapping being the branch to merge. Doing a make distclean will help with avoiding diff processing autohell files.
A little script like this will do the diff'ing: (Might be an idea to add -q to the diff invocation first to see the changed files and spot any files/patterns that need to excluded with -x [glob])
#!/bin/bash CWD=$(pwd) SVN_ROOT=${HOME}/src/vice TRUNK=trunk BRANCH=branches/fabrizio/3.7-joystick-mapping SUBDIR=vice/src/ A=${TRUNK}/${SUBDIR} B=${BRANCH}/${SUBDIR} cd ${SVN_ROOT} diff --strip-trailing-cr -U 3 -r ${A} ${B} -x configure.in -x .automake.out -x autom4te.cache -x *.swp -x gtk3 cd $CWD
The script excludes src/arch/gtk3 because the gtk3/ directory in the branch is far behind trunk, leading to a lot of noise, and massive merge conflicts using svn merge.
Then run:
$ ./script.sh > ~/me-patch.diff $ cd $HOME/src/vice $ patch -p0 <~/me-patch.diff
And pray VICE compiles after that.
UPDATE 2023-01-29: Applied above in r42972.
UPDATE II 2023-1-30: Branch and diff are fucked, reverted in trunk.
UPDATE III 2023-2-1: New branch made, waiting for merge
UPDATE IV 2023-2-2: New branch merged
UPDATE V 2023-2-17: Trunk now on par with old SDL about features
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
the SDL "menu actions" should use fixed numeric IDs for the mapping to keys/joystick instead of "menu pathes" which break when the menu is rearranged(moved to Joymappings)
SDL1/2 joystick mapping improvements(moved to Joymappings)Make the 'extra joystick options' menu show what they are already mapped to(moved to Joymappings)Add menu joystick actions mapping support to the 'extra joystick options' menu(moved to Joymappings)
- TODO: support rotating the output by 90 degrees (CHIPRotate, canvas->videoconfig->rotate)
- the host window should change size/ratio
TODO: in x128 support enabling the statusbar separately for each window(in trunk)
- TODO: in x128 there is no separate cartridge menu, but x128 has extra cartridges that only exist in x128
FIX: For RAMLink, the "RAMLink RAM Image" should use the new cartridge_flush_secondary_image() and cartridge_save_secondary_image()(in trunk)
FIX: For GMOD2, the "GMOD2 EEPROM Image" should use the new cartridge_flush_secondary_image() and cartridge_save_secondary_image()(in trunk)
GTK UI
- add feature that allows to hide (only) the statusbar (use <CHIP>ShowStatusbar resource)
- Added in trunk, with command line options -<CHIP>showstatusbar and +<CHIP>showstatusbar. Needs more work to properly handle the window resizing when toggling the visibility of the status bar.
- 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.
- add missing $VICERES comments in the UI files, so ./gtk3-resources.py list-missing keeps working
- TODO: support mirroring the output (CHIPFlipX, CHIPFlipY, canvas->videoconfig->flipx/y)
- TODO: support rotating the output by 90 degrees (CHIPRotate, canvas->videoconfig->rotate)
- the host window should change size/ratio
- TODO: the macOS renderer must be checked and eventually updated for the new per chip resources. see eg r42892
- Find out why the CRT control widgets take so long to show up.
Implement CHIPAspectRatio widget as a spin button.(fixed in trunk)
Add support for setting the LogFileName resource, including setting it to "-" to redirect to stdout. Perhaps use the "Host" => "Current directory" node and rename to "Environment"?(fixed in trunk)
- Add support for opening the directory containing vice.log with the default file manager, or perhaps open vice.log with the default editor for .txt files.
- Works on Linux and Windows, no idea about MacOS.
- Add UI action and hotkey to toggle the PET diagnostic pin (allows for non-destructive reset on PET).
- 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.
TODO: Make all cartridge widgets use the defines in src/cartridge.h for the cartridge names.(fixed in trunk, some defines might be missing: CARTRIDGE_PLUS4_NAME_DIGIBLASTER and CARTRIDGE_PLUS4_NAME_SIDCARD (although that one is spelled in at least four different ways))
- FIX: generally on all cartridge tabs the widgets related to "primary image" should be at the top, then the "secondary": GMOD2, Expert, MMC Replay
- FIX: In MMC64 Tab, the "MMC64 BIOS" and "MMC64 Cartridge Image" are the same thing. The save/flush Buttons should be located under the same caption as the filename entry (Primary image only: Flash)
- FIX: In RAMLink Tab, the "RAMLink RAM Image" (Primary image is a regular ROM, secondary image is RAM). UI looks ok, but should use the new cartridge_flush_secondary_image(), cartridge_save_secondary_image(), cartridge_can_flush_secondary_image() and cartridge_can_save_secondary_image() for the RAM
- FIX: GMOD2 (Primary image: Flash, secondary image: EEPROM). UI looks ok, but should use the new cartridge_flush_secondary_image(), cartridge_save_secondary_image(), cartridge_can_flush_secondary_image() and cartridge_can_save_secondary_image() for the EEPROM
- FIX: GMOD2C128 (x128 only) (Primary image: Flash, secondary image: EEPROM) UI is missing the Flush/Save buttons for the EEPROM, should use the new cartridge_flush_secondary_image(), cartridge_save_secondary_image(), cartridge_can_flush_secondary_image() and cartridge_can_save_secondary_image() for the EEPROM
- FIX: MMC Replay (Primary image: Flash, secondary image: EEPROM). UI is missing the Flush/Save buttons for the EEPROM, should use the new cartridge_flush_secondary_image(), cartridge_save_secondary_image(), cartridge_can_flush_secondary_image() and cartridge_can_save_secondary_image() for the EEPROM
- FIX: REX RAM-Floppy (Primary image is regular ROM, secondary image is RAM). UI looks ok, but should use the new cartridge_flush_secondary_image(), cartridge_save_secondary_image(), cartridge_can_flush_secondary_image() and cartridge_can_save_secondary_image() for the RAM
- TODO: On the printer tab, some invalid combinations of options should be prevented:
- grey out "graphic" if either ASCII or RAW driver is selected (make sure you cant select "graphic" first, then change the driver to ASCII or RAW)
- grey out "text" if 1520 driver is selected (make sure you cant select "text" first, then change the driver to "1520")
- TODO: Fix hotkeys UI: saving the custom hotkeys is unwieldy and it's unclear whether the custom hotkeys file is stored in the HotkeyFile resource, in which case the user still has to save their settings to make the hotkeys available after VICE reboot, or if the hotkeys are saved in the default location with the default name, i.e. ~/.config/vice/gtk3-hotkeys-${MACHINE}.vhk and auto-loaded after a VICE reboot. So this distinction has to be made clear to the user by the UI and the UI should provide a way to make the saved hotkeys default on VICE reboot. Perhaps something like "Save hotkeys and set as default" would work?
- It also appears that when saving the hotkeys, the "Current hotkeys file" GtkEntry still shows /usr/local/share/vice/C64/gtk3-hotkeys.vhk, so that text will need be to updated on saving as well, but only when to user requests the saved hotkeys to be default ;)
- The dialog exceeds the limits set on dialog size, so that'll need fixing as well.
Linux/Unix
The path for vice.log is incorrect: currently we use $XDG_CONFIG_HOME (default: .~/config/vice/vice.log), this should become $XDG_STATE_HOME (default: ~/.local/state/vice/vice.log).(fixed in trunk, on Windows we still stuff everything in %APPDATA%\Roaming\vice)
FFMPEG
Using FFMPEG via API breaks all the time, and it is currently disabled in our windows builds.
What we want to achieve is: get rid of the breakage every time FFMPEG bumps its version. There are two things we can do (even in parallel):
- instead of using FFMPEG via API and linking to the libraries, we use the ffmpeg executable and pipe the data to it
- this means availability of FFMPEG must be a runtime check, not compile time
- instead of the internal FFMPEG, support internal ZMBV codec (which we can pull into the tree)
- this can always work, even if FFMPEG executable is not available
- if we have this, even if we do not ship with the FFMPEG executable, we have working movie recording
- might even be possible to pipe ZMBV to external programs (such as OBS) directly
FFMPEG: many distributions are -- or will be -- providing only the 5.x version of FFMPEG, with no fallback packages for 4.x. This means VICE's ffmpeg code needs to be updated to use 4.x AND 5.x. The current code is based on ffmpeg 3.x with some fixes for 4.x, so it'll involve some work. Alternatively we could decide to finally ditch FFMEPG and use a single lossless audio/video codec.
- internal FFMPEG will be dropped in favor of ZMBV.
Misc
archdep_spawn needs to be rewritten to use CreateProcess, like in coproc.c - see [1](fixed in trunk)
- Fix C128 cartridge system
- snapshots are not supported yet
- cartridges that work in C64 _and_ C128 mode are not supported yet
- comal80 does not work correctly
- implement CBM2 cartridge system
- Fix C64 cartridge system
implement functions for GMod2 EEPROM save-as/flush.(fixed in trunk)a generic API for saving and flushing EEPROM data for carts should be implemented.(fixed in trunk)- IDE64 should save its config into a separate file rather than writing a binary string into vice.ini
it is not possible to reset hotkeys to default (via UI)(fixed in trunk)- -default on cmdline should skip loading system files such as kernal from ~/.local/share/vice/$EMU/.
- Add some simple checksum algorithm to common code (CRC32 is probably fine) - right now eg the kernal loading uses simple additive checksum, which is really bad :)
- DTV should use different flash images for PAL, NTSC, Hummer
- The list of available palette files (.vpl) should get generated from the available files found in the data directory
- Fix Videochip options (also see below)
- we need to add a member to video_chip_cap_t that lets us determine whether we need PAL/NTSC options or not, then we can use this to remove -CRTCcrtdelaylinetype and -VDCcrtdelaylinetype (and the respective resources)
Buildsystem
- when configured without --enable-x64, a symlink "x64->x64sc" should be created and installed instead of x64
- 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)
- Too many files are installed in $PREFIX/share/doc/vice when doing make install (example from Linux):
CIA-README.txt coding-guidelines.txt Documentation-Howto.txt Doxygen-Howto.txt FreeBSD-GTK3-Howto.txt GTK3-cross-build-setup.md GTK3-debian-frankenvice.md GTK3-Fedora-cross-build-setup.md iec-bus.txt Linux-GTK3-Howto.txt macOS-Distribution-Howto.txt macOS-Howto.txt macOS-Xcode-Howto.txt NetBSD-GTK3-Howto.txt NetBSD-howto.txt OpenBSD-GTK3-Howto.txt Readme-SDL2.txt Readme-SDL.txt Release-Howto.txt SDL-Howto.txt vice.texi Windows-MinGW-GTK3-Howto.txt
Github Actions
A .deb is generated for headless, sdl2 and gtk3 (both amd64), with non-stripped binaries.
Still TODO is adding FFMPEG to the builds (needs support for FFMPEG 5.x in trunk)
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
The SDL1 port should also get checked
Cleanup
disable non working things in the GUI
REU does not work (yet) in x64sc, for the time being it should get removed from the UIs, the commandline options, the resources (in x64sc)(fixed in trunk)- vdrive via opencbm ("real device") does not work in xvic (disabled in trunk for gtk3)
- Professional DOS emulation doesn't work (https://sourceforge.net/p/vice-emu/bugs/759/) (disabled in trunk for gtk3)
- Mirror/Flip X/Y and Rotate 90 degrees, should they still not be implemented at release time
TODO: make a list of all those things (here, and keep it here, since obviously those are open ends and need to be fixed!)
Archdep cleanup
- there are still various bits of archdep things dangling around in common code (and some newly added *sigh*) - 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
- 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
- use ./src/findhacks.sh ccarchdep to find such code, most things should be removed
- remaining cases should always come with a comment telling why there has to be compiler specific stuff
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!).
- 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)
Headers
- many things that currently live in the archdep ui.h could be moved to the generic uiapi.h
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)
A bunch of resources have to be handled per video chip:
Resource | Action |
---|---|
VSync | Rename to CHIPVSync (in trunk) |
GTKFilter | Rename to CHIPGLFilter (in trunk) |
KeepAspectRatio, TrueAspectRatio | Rework into one resource: CHIPAspectMode (0: off, 1: custom 2: true) (in trunk) |
CHIPAspectRatio | should be used with "custom" mode, see above (in trunk) |
CHIPFlipX | (in trunk) To be implemented in GUI |
CHIPFlipY | (in trunk) To be implemented in GUI |
CHIPRotate | (in trunk) To be implemented in GUI |
JoyMapFile, JoyThreshold, JoyFuzz | Use these when implementing the joystick mapping stuff |
Resource | Action |
---|---|
VSync | Rename to CHIPVSync (in trunk) |
AspectRatio | Rename to CHIPAspectRatio (in trunk) |
SDLGLAspectMode | Rename to CHIPAspectMode (in trunk) |
SDLGLFlipX | Rename to CHIPFlipX (in trunk) |
SDLGLFlipY | Rename to CHIPFlipY (in trunk) |
SDLGLFilter | Rename to CHIPGLFilter (in trunk) |
CHIPRotate | (in trunk) To be implemented in UI |
SDLStatusbar | Rename to CHIPShowStatusbar (in trunk) |
SDLCustomWidth | Rename to CHIPFullscreenCustomWidth (in trunk) |
SDLCustomHeight | Rename to CHIPFullscreenCustomHeight (in trunk) |
- There should be non port specific cmdline options that set Window0Height, Window0Width etc
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).
Resource | Emulators | Status |
---|---|---|
BoardType | x64, x64sc, xscpu64, x128 | set implicitly by "model" API |
Docs
- split vice.texi into smaller files
- CAUTION: various scripts use vice.texi as input
- various things that are right now hidden in "Settings and Resources" -> "Miscellaneous settings" can perhaps be moved elsewhere
- Write a HOWTO for running Github Actions locally using act.
Data
- 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
- C128 ROMs: kernalfi, kernalfr, kernalit, kernalno
3.7 Feedback threads
- https://www.lemon64.com/forum/viewtopic.php?t=81099
- https://www.forum64.de/index.php?thread/132610-vice-3-7-has-been-released
- https://csdb.dk/release/?id=226991
- https://csdb.dk/forums/?csdbentrytype=release&csdbentry=226991&entrytopic=1
even later
These are the long term goals, vaguely coined "4.0":
- remove SDL1 support
- all important targets haved SDL2 now, so there is hardly a reason to keep SDL1 support. Removing it is simply about preventing bit rot and removing some complexity.
- remove x64 (possibly rename x64sc to x64)
- Soon x64sc will work fine on raspy and alike
- merge the separated GUI/Emulator-core branch
- move repository to git
- this needs to be coordinated