I'm not sure if I should open a new issue as it's related to this one. I'm using a Sidblaster Tic-Tac Edition (Github link) and it sounds like the first 3 channels of the SID are working fine, but the noise channel seems to be off. It has its own hardsid.dll in both 32 and 64 bit varieties(hardsid_library/SIDBlasterUSDB_Beta_driver 2015 (Windows).zip in the repo). The noise channel sounds high-pitched when playing back digitized sound samples on a 6581. Using ACID 64 Player Pro, the samples play...
I'm not sure if I should open a new issue as it's related to this one. I'm using a Sidblaster Tic-Tac Edition (Github link and it sounds like the first 3 channels of the SID are working fine, but the noise channel seems to be off. It has its own hardsid.dll in both 32 and 64 bit varieties(hardsid_library/SIDBlasterUSDB_Beta_driver 2015 (Windows).zip in the repo). The noise channel sounds high-pitched when playing back digitized sound samples on a 6581. Using ACID 64 Player Pro, the samples play back...
make UI less amigious because i am dumb
Well, you only needed to ask! I'll try to provide a patch next week ! :-)
Removing that code is on the todo list, as always it also needs someone to actually do it :)
I am not sure the API changed much between 5.x and 7x. And, if so, why don't you remove that code altogether?
but x64sc -default -virtualdev1 works just fine, it just hangs with an additional -cia1model "0" -cia2model "0" so... model "C64 PAL" hangs with VDT on, whereas model "C64C PAL" works. and it's like that until back to VICE v3.0
use of AVFormat from ffmpeg 4.x is deprecated
Thats why support for ZMBV and the ffmpeg executable was added - we cant be bothered to fix the libav support all the time because of breaking api changes. There is no documentation whatsoever on how to migrate to the new API either for that matter.
I made a mistake in the title. It should have been "use of AVPicture from ..."
Startup delays
use of AVFormat from ffmpeg 4.x is deprecated
this nc does the same: https://eternallybored.org/misc/netcat/ but it is windows only. it looks like the connection isn't closed properly. strangely it only happens after "closing" the monitor using x and then killing nc so... no idea if this is a VICE issue or nc
ok, i can make it working on windows, sort of. if the mon.hex is binary, i can use something like netcat -o output localhost 6502 < mon.hex > received or (if you have the tools) the mon.hex can be ascii cat mon.hex | xxd -r -p | netcat -o output localhost 6502 > received but i need to terminate netcat (or whatever) manually, i cannot use -close, this will send only it looks, and that won't work. //edit: the best solution i found now is nc64 instead of netcat: cat mon.hex | xxd -r -p | nc64 -w 1 -o...
ok, i can make it working on windows, sort of. if the mon.hex is binary, i can use something like netcat -o output localhost 6502 < mon.hex > received or (if you have the tools) the mon.hex can be ascii cat mon.hex | xxd -r -p | netcat -o output localhost 6502 > received but i need to terminate netcat (or whatever) manually, i cannot use -close, this will send only it looks, and that won't work. //edit: the best solution i found now is nc64 instead of netcat: cat mon1.hex | xxd -r -p | nc64 -w 1...
ok, i can make it working on windows, sort of. if the mon.hex is binary, i can use something like netcat -o output localhost 6502 < mon.hex > received or (if you have the tools) the mon.hex can be ascii cat mon.hex | xxd -r -p | netcat -o output localhost 6502 > received but i need to terminate netcat (or whatever) manually, i cannot use -close, this will send only it looks, and that won't work.
ok, i can make it working on windows, sort of. if the mon.hex is binary, i can use something like netcat -o output localhost 6502 < mon.hex > received or (if you have the tools) the mon.hex can be ascii cat mon.hex | xxd -r -p | netcat -o ggg localhost 6502 > received but i need to terminate netcat (or whatever) manually, i cannot use -close, this will send only it looks, and that won't work.
fix warning maybe perhaps :)
Bug in old CIA where timer B of CIA 1 does not start.
so, -virtualdev1 causes the problem. Solution: turn it off (always try with default setting when something does not work)
Round two...
Log attached
so where is a proper nc for windows? :)
this ncat is a different program ... it doesn't work for me at all in linux (the binary that is, i didn't compile from source yet)
configure with --enable-debug should enable this
On Arch Linux, the repository has two differnet netcat's - gnu-netcat and openbsd-netcat. They use different arguments but seem to be the same in basic functionality. I am always using 'cat' with a binary file containing the 21 bytes, and this seems to work same with either 'nc'. ALSO, I don't know much about auto-tools; is there a simple way to make a debug build that can give me a useful stack dump from the core file? All I get from the current core file is the raw address of the crash and no symbol...
the game loads fine for me too, using x64sc.exe -default both, x64.exe and x64s.exe
so it seems the different netcat implementations work differently? or the OS itself handles it differently? maybe my netcat expects a binary input?
i used the one at the bottom, ncat-portable-5.59BETA1.zip yes, i get it's ancient, but this is the one that runs just out of the box. and it doesn't matter, the same happens if i extract a new one from the https://nmap.org/dist/nmap-7.95-setup.exe package. it only has a ton of dependencies. ncat localhost 6510 but right now i figured out, the funny stuff only happens if i press x in the "monitor shell" and then terminate ncta using CTR-C. it does NOT happen if i press CTR-C right after some monitor...
yes, what i do is > 9b 12 34 then run the command with nc, and to check m 9b
still does not change 9b/9c for me, neither my own compile nor the one from github. though there is no -qoption available here in netcat. but... just to make really sure i did understand properly: 9b/9c is the memory in the emulator, right? so after doing the remote commands i should see the changes if is use the "standard monitor" and do something like m b9?
It works for me shrug - please attach the vice log (which will tell your exact settings). There must be something else involved
Of course I meant 6526 , not 2526 (I'm tired)...
Bug in old CIA where timer B of CIA 1 does not start.
mmmh also please tell exactly what cmd you are using with this ncat - it does not appear to work for me at all shrug
Which one exactly?
really weird. The send errors are expected (if not waiting for the response). And the receive error just indicates that the connection was dropped (also expected). shrug
I made a fresh build using the tar ball for r45354. No real difference. Still does a core dump for me. The error messages that are output are somewhat different with the new version, as shown below. Error - vice_network_send: internal error (ret:-1 buffer_length:12 errno:32 - Broken pipe) Error - vice_network_send: internal error (ret:-1 buffer_length:42 errno:32 - Broken pipe) Error - vice_network_send: internal error (ret:-1 buffer_length:12 errno:32 - Broken pipe) Error - vice_network_send: internal...
one that does the funky thing i got from here: https://nmap.org/dist/ really strange. the emulator runs at 100%, but the cursor blinks almost twice as fast.
It changed 9b/9c for me... but only after i made this "fix" and recompiled - no idea why
would still be interesting to be able to reproduce... such funky behaviour should never happen :)
indeed telnet works... i also tested 2 other ncat versions, and one of them also works, the one from msys2 itself gnu-netcat-0.7.1-2-x86_64.pkg.tar.zst so i guess this can be closed...
Oops, sorry missed your last response. My apologies. I am quite likely not able to invest much time in this in the for the next two months or so (probably not getting air to breathe before the xmas holidays), so i don't want to make any promises i can't realistically keep. It might take a while... :-(
mmmh with telnet it works... what package has the "ncat" command you are using?
remote monitor cannot be deactivated
yeah, i tested another netcat, so cat mon.hex | netcat -x -o test --close localhost 6502 gives no error, but i also don't see 9b/9c changed. but this was not different in VICE 3.6, was it? the output in the file test is 00000000 30 32 30 32 20 30 61 30 30 20 30 30 30 30 20 63 0202 0a00 0000 c 00000010 64 61 62 20 33 34 31 32 20 30 32 30 30 20 39 62 dab 3412 0200 9b 00000020 30 30 20 39 63 30 30 20 30 30 30 30 20 30 30 30 00 9c00 0000 000 00000030 34 20 30 30 0D 0A 0D 0A 4 00.... that seems to be...
part2: please try r45354 - it works for me. i don't know why - it shouldn't change anything :) (maybe you need a clean rebuild?)
this may or may not fix #2076 :)
part1: use something like cat mon.hex | nc -q 5 localhost 6502 | hex and the send errors go away (these are about the reply the command sends)
@elgonzo please? :)
Binary monitor crash on simple memset command (Linux)
Binary monitor crash on simple memset command (Linux)
it doesn't crash for me in linux (using GTK build though) - but 9b/9c are not being modified either :) Also tried in x64sc - exactly the same. Oh and i also get those errors.
it doesn't crash for me in linux (using GTK build though) - but 9b/9c are not being modified either :)
Hi compyx, yes, i confirm, there is a menu entry Emulators (though this itself does not have an icon) where our links are present - with their icons. After copying data/common/C64_48.png to vice-C64_48.png and running After creating x64sc.desktop and running xdg-icon-resource install --theme hicolor --context apps --size 48 vice-C64_48.png I now see task bar icons on mint 22.
Interesting. The 21-byte command is trying to set the values at $9b/$9c. If you can look at those addresses in the debug monitor before/after the command, it should be obvious if the command did anything.
Interesting. The 21-byte command is trying to set the values at $9b/$9c. If you looked at those addresses in the debug monitor before/after the command, it should be obvious if the command did anything.
Interesting. The 21-byte command is trying to see the values at $9b/$9c. If you looked at those addresses in the debug monitor before/after the command, it should be obvious if the command did anything.
doesn't crash on windows, but i also get the log entries... Error - vice_network_send: internal error Error - vice_network_send: internal error Error - vice_network_send: internal error monitor_binary_receive(): vice_network_receive() returned -1, breaking connection but the vice_network_receive() returned -1, breaking connection i also get with older VICE versions, so makes me wonder whether this actually really worked.
This appears to work on Mint 22: An x64sc.desktop file in /usr/share/applications/ with the following: [Desktop Entry] Type=Application Name=VICE (x64sc) Comment=Commodore 64 emulator Exec=/usr/local/bin/x64sc Terminal=false Icon=vice-C64_48.svg Categories=Game;Emulator; And then running: xdg-icon-resource install --theme hicolor --context apps --size 48 vice-C64_48.png (having copied data/common/C64_48.png to vice-C64_48.svg to provide a vendor prefix of "vice"). I'll check if I can update the .deb...
Apparently the application icons are now supposed to be taken from the .desktop files and not by calling gtk_window_set_icon(), which is now a fallback for older desktops and Windows/Mac and is removed in Gtk 4. The issue seems to be the icons need to be in the /usr/share/icons/hicolor directory and not where we install them ($PREFIX/share/vice/, pointing to files outside the system icons directory (in our .desktop files) doesn't work anymore on modern-ish desktops. So I'll be looking into using...
Don't pop up a second ui_error message when ffmpeg executable was not found. also reset/stop the recording status in the statusbar when recording is no more active.
Still not working unfortunately. I tried r45352 with above commands. Neither sudo update-desktop-database or reboot helps.
please try again, apparently the category was wrong
Audio/Video delay when recording video
should be fixed in ffmpeg too
Monitor always shows stack pointer value of 0 in program break heading
So?
improve error handling a bit. a proper error is now shown when ffmpeg executable can not be started - however, as a result the UI becomes unresponsible, and the emulator appears to still run (?). likely a locking problem, perhaps screenshot_stop_recording() needs to be wrapped accordingly
fix recording video using the ffmpeg executable, should skip warp and keep a/v sync the same as ZMBV
Gtk3: update 'Categories' entries in .desktop files
Gtk3: set categories in .desktop files for `--enable-desktop-files`
Binary monitor crash on simple memset command (Linux)
again: please tell exactly what you are doing, step by step. ALT-H has nothing to do with a breakpoint that hits for that matter, no idea what you even mean by this
Damnit. Am having that on Fedora 40. Let me check some other distros...
I've hit Alt-H instead.
resid: uninitialized var in old filter
applied in r45348 - thanks!
fix uninitialized var in old filter, patch by leandro nini
this also works C:$e5e8) break fff6 BREAK: 1 C:$fff6 (Stop on exec) (C:$e5e8) x (sys 65526) #1 (Stop on exec fff6) 184/$0b8, 5/$05 .C:fff6 FF FF FF ISB $FFFF,X - A:00 X:00 Y:00 SP:f7 ..-..... 35877157 (C:$fff6) r ADDR A X Y SP 00 01 NV-BDIZC LIN CYC STOPWATCH .;fff6 00 00 00 f7 4c 48 00100000 184 005 35877157 (C:$fff6)
please tell exactly what you are doing - this works for me: (C:$e5ef) break load fff0 ffff WATCH: 1 C:$fff0-$ffff (Stop on load) (C:$e5ef) x #1 (Stop on load fffe) 187/$0bb, 63/$3f .C:e5ea 85 CC STA $CC - A:00 X:00 Y:0A SP:ef ..-..IZ. 12750740 #1 (Stop on load ffff) 187/$0bb, 63/$3f .C:e5ea 85 CC STA $CC - A:00 X:00 Y:0A SP:ef ..-..IZ. 12750740 (C:$ff72) r ADDR A X Y SP 00 01 NV-BDIZC LIN CYC STOPWATCH .;ff72 00 00 0a ef 4c 48 00100110 187 063 12750740
i can't reproduce this (both working fine)
No scrolling in monitor
Monitor always shows stack pointer value of 0 in program break heading
resid: uninitialized var in old filter
fixed with ZMBV via r45346 and r45347
skip video recording when warpmode is active, this does not, and can not, work and will result in massive a/v delays
yes, it runs cinnamon by default. $ cinnamon --version Cinnamon 6.2.7 $ lsb_release -a No LSB modules are available. Distributor ID: Linuxmint Description: Linux Mint 22 Release: 22 Codename: wilma The files you mention exist here too. $ find /usr/ -name '*x64*.desktop' /usr/share/applications/vice-org-x64sc.desktop /usr/share/applications/vice-org-x64dtv.desktop /usr/share/app-install/desktop/vice:x64.desktop sudo update-desktop-database does not solve the problem.
encode zmbv video at proper (fractional) frame rate, prepare some stuff to skip frames if needed. "warpmode" and "no audio" still needs to be fixed
add printf-format attribute macros also for clang
change printf to log_printf
Yes, the files in build/debian are used by the Github Actions to build the .deb packages. they aren't used when building and installing from source. As @groepaz stated the .desktop files are generated during build and installed into /usr/share/applications/ when running make install. On my Debian machine I have this: $ find /usr/ -name '*x64*.desktop' /usr/share/applications/vice-org-x64dtv.desktop /usr/share/applications/vice-org-x64sc.desktop /usr/share/applications/vice-org-x64.desktop That's...
Yes, the files in build/debian are used by the Github Actions to build the .deb packages. they aren't used when building and installing from source. As @groepaz stated the .desktop files are generated during build and installed into /usr/share/applications/ when running make install. On my Debian machine I have this: $ find /usr/ -name '*x64*.desktop' /usr/share/applications/vice-org-x64dtv.desktop /usr/share/applications/vice-org-x64sc.desktop /usr/share/applications/vice-org-x64.desktop That's...
I think the files in build/debian are probably only used when you actually build a .deb If you compile yourself it will use the files from src/arch/gtk3/data/unix/ which are then patched to contain the prefix you used during configure, and installed in /usr/share/applications/ For me (with prefix=/usr/games) it looks like this: $ cat /usr/share/applications/vice-org-x64sc.desktop [Desktop Entry] Type=Application Name=VICE (x64sc) Comment=Cycle-exact C64 emulator (Gtk3 UI) Exec=/usr/games/bin/x64sc...
I repeated the test with a mint 21.4 VM and a mint 22 VM. I use VirtualBox 7.0. Both VMs i installed from scratch (hard disk installation, no live system). I installed the guest additions in each. Then, after apt-get for all dependencies, i run cd ~ rm -rf vice svn co https://svn.code.sf.net/p/vice-emu/code/trunk/ vice cd ~/vice/vice ./autogen.sh ./configure --enable-gtk3ui --enable-desktop-files make -j 4 sudo make install ./src/x64sc in both of them, x64sc comes up without any desktop icon in the...
I suspected there would be more, I'll fix those as well.
Sigh apt-get thinks 1.40 is the most recent version. I directly downloaded 1.44 .deb files for gir and dev but the package installer warns I will be breaking dependencies and refuses to install them. I suppose there would be a command line way to install, but I'm afraid of breaking things since it seems core to the OS. I guess it's time to bite the bullet and upgrade my Mint installation.
Sigh apt-get thinks 1.40 is the most recent version. I directly downloaded 1.44 .deb files for gir and dev but the package installer warns I will be breaking dependencies and refuses to install them. I suppose there would be a command line way to install, but I'm afraid of breaking things. I guess it's time to bite the bullet and upgrade my Mint installation.
fix crash when native monitor is enabled, emulator was NOT started from a terminal, and then monitor fails to open
https://docs.gtk.org/Pango/method.FontDescription.get_variations.html says you need at least Pango 1.42 (released roughly 6 years ago, btw). It is a separate package (libpango-dev 1.0 or sth like that), so you might be able to update it