Activity for Querino
-
Querino posted a comment on ticket #2216
Maybe the OP don't compile himself, i did a quich test. c1541 "Sex Show 8_cycled.d64" -extract sex show eight fucking people 1 Error: trying to extract more data than image can contain (174848), possibly a cyclic T/S chain in file 'fucking people 1'. fucking people 2 fucking people 3 fucking people 5 fucking people 6 fucking people 7 fucking people 8 fucking people 9 fucking people a fucking people b fucking people c fucking people d fucking people e fucking people f fucking people g fucking people...
-
Possible bug in Protopad
-
just a quick test, done manually. all in viavarious pass the four new wrap test pass the game works waiting for someone doing a more thorough test. :)
-
Sorry i messed up, it's actually r41808. So there were other changes to viacore, such as in r41932 (many). /edit: Ok, tried something more. viacore: [r41808] : Game works as expected [r41932] : Game won't even start/load properly (?) [r41995] : Same behavior as in current versions, hangs after pressing fire
-
Sorry i messed up, it's actually r41808. So there were other changes to viacore, such as in r41932 (many). /edit: Ok, tried something more. viacore: [r41808]: Game works as expected [r41932] : Game won't even start/load properly (?) [r41995] : Same behavior as in current versions, hangs after pressing fire
-
Sorry i messed up, it's actually r41808. So there were other changes to viacore, such as in r41932 (many).
-
It seems the game worked up to r41995
-
Weird. It's like this since the beginning when "Joyport I/O Simulation" was introduced. Kinda hard to believe that no one has noticed this in all this time.
-
Ah, i see. That's not very obvious. If we do a search in the browser itself (i did cia1-sdr-icr-3), there is only that 1 finding in the second part...
-
I wonder why most the shiftregister tests failed in the testbench (red)? A lot of them come out green if i run them manually. /edit: in the testbench from last year they were all green.
-
I wonder why most the shiftregister tests fail in the testbench? A lot of them come out green if i run them manually.
-
Also the IO area size isn't restore properly. Honestly, snapshots only work half way proper in x64(sc). * xplus4 is completely broken. xcbm5x0 even crashes. Well no, that's not true, in x64 they actually work quite well, except some small issues.
-
Also the IO area size isn't restore properly. Honestly, snapshots only work half way proper in x64(sc). xplus4 is completely broken. xcbm5x0 even crashes.
-
Did this ever work properly? Even in v3.2 it didn't. Maybe it works inside "".
-
Maybe it happens since following commit. https://sourceforge.net/p/vice-emu/code/40623/ But i haven't chaecked yet.
-
Snapshots crash if loaded in different border mode
-
Works just fine for me... /Edit: Ah, too late. It's always a good idea to try with -default
-
Works just fine for me...
-
I don't think it's even supported, so it's no surprise if there is no audio.
-
cool, got it. closed. :)
-
but...but... the koalapad is shaking, is this intentional? sorry, i didn't notice before.
-
so... it doesn't run well on the real thing too? btw, is this mousetest in the repo any different from the one on github?
-
possible mouse bug?
-
As far as i can tell, this works just fine.
-
The thing here is, to me it seems resid also sounds fine in VICE 2.4.
-
The thing here is, to me it seems resid also sounds fine in VICE 2.4 Maybe it's the new 8580 filters?
-
i always had the impression, it doesn't make any differenc if we use TCHAR or char, as long as we do an ANSI compile... ANSI compile: TCHAR -> char Unicode compile: TCHAR -> WCHAR
-
VICE 2.4 still had resid-fp, i wonder if that one did a good job too?
-
No, the ones from Github. Sadly, i have only this one system with w11 installed.
-
Interesting. As far as i can see, this worked back then in v3.2 (native) for windows.
-
I don't see dirmaster on this system, and C64_Pro_Mono-STYLE.ttf is not in any of my system folders. Strange.
-
works for me in w11. but i see it doesn't work if i start the emu as user SYSTEM or TrustedInstaller :) but then, the casual users work just fine, including admin.
-
yes, confirmed working.
-
And i can say it never worked properly in VICE, tested down to v 2.3
-
seems to be fine.
-
well, i tried it, reverting 6510core.c from r37549 to r37547, and the bug is gone (according to the bug.prg). but don't ask me why. :)
-
should be this: https://sourceforge.net/p/vice-emu/code/37549/
-
1 geta$:ifa$=""then1 2 printa$;:goto1 watch load 0816 that is working in r42405, but fails in r42417
-
but VICE implodes by just starting with something like x64sc -default -ramlinkbios "C:\MSYS\CMD\CMD_RAMLink_DOSV202.crt" -ramlink -ramlinksize "8" some sizes work, some don't. the same when changing in the GUI and do a reset.
-
https://sourceforge.net/p/vice-emu/code/45391/ maybe it helps. though i guess it was obvious.
-
https://sourceforge.net/p/vice-emu/code/45391/ maybe it helps.
-
Well, the last one that sounded properly in my short test me was 3.8.45282, while 3.8.45298 sounds as it does up to today.
-
ah i see, i beed to get rid of my text here. :)
-
it does work in x64sc if we also disable TDE and instead activate VD. it's like that since a long time, i forgot about that. without doing so, we get a ?file not found error so for x64 it would be x64sc -default -virtualdev8 -autostartprgmode "0" +drive8truedrive foo.org but these settings still don't help now in xplus4, with xplus4 -default -virtualdev8 -autostartprgmode "0" +drive8truedrive foo.prg we get the ?device not present error
-
after some simple testing with older versions, i think the problem starts here: https://sourceforge.net/p/vice-emu/code/45283/
-
r45684 breaks autostart mode "virtual filesystem"
-
r45685 fixes the save-as, thanks for reporting! confirmed working now.
-
minimon strange "save image as.."
-
works for me...
-
while playing with this, i noticed the "£" isn't copied properly, it translates to "\" but that would be a different bug (if it's one) ... and it goes back to at least v3.2
-
nice, works for me.
-
i do not have a real c64, soi canot do any testing. zibri was saying x64and x64sc are acting differently, but then: The real problem is not that, but Border Polizei shows up in the same way on my C64 (original breadbin). so my impression was that on his (original breadbin) it looks the same as on x64 but NOT x64sc.
-
hm... why is this invalid?
-
yes, it only works if numlock is ON. honestly, i thought of this as a feature... i can use the numpad as cursor keys (or however we define them) if numlock is OFF.
-
it works for me too in windows. both ports tested with Joyride-1.8
-
i can hear a difference after https://sourceforge.net/p/vice-emu/code/45158/ but i guess that's not surprising?
-
i'm absolutely no expert in this field, but to me it seems to be working under windows 11. my batch file: start tcpser -v 25233 -s 1200 -l 4 -p 6510 -i "e1" start x64sc -default -acia1 -rsdev3 "127.0.0.1:25233" -rsdev4 "127.0.0.1:25233" -myaciadev "2" "ccgms ultimate.d64" 2024-12-30 20:03:37:536969680:INFO:Server socket bound to port 2024-12-30 20:03:37:536969680:INFO:Server socket listening for connections 2024-12-30 20:03:37:536969680:INFO:Creating modem #0 2024-12-30 20:03:37:537203384:INFO:Opening...
-
i'm absolutely no expert in this field, but to me it seems to be working under windows 11. my batch file: start tcpser -v 25233 -s 1200 -l 4 -p 6510 -i "e1" start x64sc -default -acia1 -rsdev3 "127.0.0.1:25233" -rsdev4 "127.0.0.1:25233" -myaciadev "2" "ccgms ultimate.d64" 2024-12-30 20:03:37:536969680:INFO:Server socket bound to port 2024-12-30 20:03:37:536969680:INFO:Server socket listening for connections 2024-12-30 20:03:37:536969680:INFO:Creating modem #0 2024-12-30 20:03:37:537203384:INFO:Opening...
-
btw, the ROMs are here. http://blog.worldofjani.com/?p=3460#
-
The Final Chesscard
-
resid is mentioned there too. https://github.com/libsidplayfp/libsidplayfp/issues/156#issuecomment-2404195362 no idea what was fixed in the end :)
-
looks fine here, win 11 22h2
-
same here on win11, works fine try with xvic -default
-
it seems to be wrong in the GUI, max_rpm is 320.0 now
-
isn't this the same as https://sourceforge.net/p/vice-emu/feature-requests/351/ ?
-
known issue. https://sourceforge.net/p/vice-emu/bugs/2081/
-
Ah i see, my fault, i didn't overwrite these files... for me, as a workaround, i replaced the \lib\gdk-pixbuf-2.0\2.10.0\loaders.cache with the older one, and copy over the missing \lib\gdk-pixbuf-2.0\2.10.0\loaders\libpixbufloader-svg.dll that seems to work. or, simply copy/overwrite the whole \lib\ folder with an older one.
-
Ah i see, my fault, i didn't overwrite these files... for me, as a workaround, i replaced the \lib\gdk-pixbuf-2.0\2.10.0\loaders.cache with the older one, and copy over the missing \lib\gdk-pixbuf-2.0\2.10.0\loaders\libpixbufloader-svg.dll that seems to work.
-
it's not that the devs here do not fix windows bugs, i think they us windows in a VM or so... but it isn't their main priority, plus lately the development really was slow anyway.
-
nah sorry, i'm a only another regular user. the thing is, none of the devs here actually is using windows, at least not as their main system.
-
i wanted to check this, but windows 11 here on my laptop offers me only up to 175% :) and i'm using 100% on my cheap acer notebook (14" full HD).
-
Ah i see, my fault, i didn't overwrite these files... for me, as a workaround, i replaced the \lib\gdk-pixbuf-2.0\2.10.0\loaders.cache with the older one, that seems to work.
-
no idea why, but as said, r43459 works for me in windows 11. but i got crashes when i opened the monitor font settings on my older windows 7. not sure if this always happens. and yeah, i get it, windows 7 isn't supported anymore.
-
works for me, windows 11
-
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
-
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.
-
so where is a proper nc for windows? :)
-
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...
-
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?
-
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.
-
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...
-
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...
-
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.
-
"only if you're in a rush... just wait until the machine actually finishes booting before clicking another hack. :)" ok, i did some testing here on windows. my observations: 32bit builds: everything is just fine (kinda weird?) 64bit builds: x64.exe: everything is just fine 64bit builds: x64sc.exe: only +60k works fine, +256k and C64 256k will crash furthermore, the crash only happens after we deactivate the hack. //edit: i did try the ancient v2.4, but the same already back then: 32bit builds: everything...
-
"only if you're in a rush... just wait until the machine actually finishes booting before clicking another hack. :)" ok, i did some testing here on windows. my observations: 32bit builds: everything is just fine (kinda weird?) 64bit builds: x64.exe: everything is just fine 64bit builds: x64sc.exe: only +60k works fine, +256k and C64 256k will crash furthermore, the crash only happens when we deactivate the hack. so, for the C64 256k the crash happens in c64_256k_deactivate(). //edit: i did try the...
-
"only if you're in a rush... just wait until the machine actually finishes booting before clicking another hack. :)" ok, i did some testing here on windows. my observations: 32bit builds: everything is just fine (kinda weird?) 64bit builds: x64.exe: everything is just fine 64bit builds: x64sc.exe: only +60k works fine, +256k and C64 256k will crash furthermore, the crash only happens when we deactivate the hack. so, for the C64 256k the crash happens in c64_256k_deactivate().
-
"Another workaround is to use an older version of VICE. VICE 2.2 does not show the reported symptom." i'm not sure if those really worked properly. it seems to do so on "bank cpu" but at any other bank it fails too.
-
ah, this is good to know, thanks. :)
-
well, most of the time it works for me, but i mostly use x64sc plus4 snaps are completely broken since ages though. but yes, i guess this isn't the most important thing to fix.
-
Keyboard issues after playing back event
-
https://sourceforge.net/p/vice-emu/code/44566/ Hello Roberto?
-
https://sourceforge.net/p/vice-emu/code/45166/#diff-7 maybe the (unsigned int) should be back in #define TED_RASTER_CYCLE(clk)
-
btw, "send formfeed to userport" does nothing it seems. //edit: hm. it seems i don't really understand what it is supposed to do. :\ ok, it does really work in graphics mode. seems to make sense.
1 >
