Activity for Querino
-
Querino posted a comment on ticket #2058
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.
-
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.
-
btw, "send formfeed to userport" does nothing it seems. //edit: hm. it seems i don't really understand what it is supposed to do. :\ maybe this works only with real printers? need to check the documentation.
-
btw, "send formfeed to userport" does nothing it seems. //edit: hm. it seems i don't really understand what it is supposed to do. :\
-
btw, "send formfeed to userport" does nothing it seems.
-
deleted...
-
error: found dangling spaces in the following files: ./src/crtc/crtc.c make: *** [Makefile:929: stylecheck] Error 255 Error: Process completed with exit code 2.
-
there's also issues with the filename when printing to the filesystem. once the file is open, there seems no way to change it. not even if we deactivate/activate the printer. and if i launch the emu like x64sc -default -userportdevice 1 -prtxtdev1 test.out x64sc opens viceprnt.out and prints to this file, although in the GUI it says test.out at least in ms windows.
-
there's also issues with the filename when printing to the filesystem. once the file is open, there seems no way to change it. not even if we deactivate/activate the printer. and if i launch the emu like x64sc -default -userportdevice 1 -prtxtdev1 test.out x64sc opens viceprnt.out and prints to this file, although in the GUI it says test.out at least in ms windows. //edit: nonsense, deactivate/activate the printer in the GUI does close the file and i can set a different filename at least. no idea...
-
there's also issues with the filename when printing to the filesystem. once the file is open, there seems no way to change it. not even if we deactivate/activate the printer. and if i launch the emu like x64sc -default -userportdevice 1 -prtxtdev1 test.out x64sc opens viceprnt.out and prints to this file, although in the GUI it says test.out at least in ms windows.
-
there still seems to be a small problem here. if i start x64 with x64sc -default -userportdevice 1 the testprog indeed works. but if i start with x64sc -default and then enable manually the userport printer, the output is only "BCZ" instead of "ABCZ".
-
it seems this was introduced somewhere here... https://sourceforge.net/p/vice-emu/code/40678/ https://sourceforge.net/p/vice-emu/code/40679/ if that helps.
-
ok i get that. weird device.... so if i want to use the testprog (where i have to select the port first) i need to do this before setting the cp device to cx85. still i am not able to "press" the emulated no, del and yes key (in joyride 1.4b). * on the other hand, + - and . on my host keyboard do nothing in the test progs. yes and 0 are switched in joyride and the vice testprog.
-
possible bug in keypad atari cx85
-
Is the VICE test program also wrong? that doesn't seem to work at all. it doesn't show any key presses, except the permanently pressed "0" (still a ? for me). ah well... i also wonder how the atari CX85 is supposed to wor, the keyboard doesn't work at all if i select this one. also, the KEYPAD_KEYS_NUM 20 doesn^t match the actual number of defined keys. not sure if this is a real issue or if i am doing something wrong. i get it this isn't the proper place here if it's an issue.
-
but now according to "joyride 1.4b" the "0" key seems to be pressed all the time. is that correct?
-
any news here? :) i wonder if the current state still is better than what we have before?
-
the ROM seems to be in his github download. https://github.com/bvenneker/Chat64/tree/69b810a8acef2acf321a7a390431bf5c8d8f20d8/Kick%20ASM/Bin_file no idea how it works though, so this isn't of much help. :) kinda weird that it simply exits the emu (in void chat64_reset()) if there's no connection.
-
after r45177 ICU64 doesn't show the colors right after launching. only after doing a power cycle. i hjave no idea if this is correct, i just noticed.
-
Ah. ICU64 now also shows colors... wasn'tlike this before.
-
looks fine...
-
i haven't tested the functionality, but now i always get a viceprnt.out even if i don't use the printer at all. //edit: ok, i tested above basic prog, and i get (using windows) a viceprnt.out containing "ABCZ". so this seems to work.
-
i haven't tested the functionality, but now i always get a viceprnt.out even if i don't use the printer at all.
-
Which one did you select? probably the "WOJ userport joy adapter" :) here a question arises. why some joystick adapters (in userport devices) are labeled as "userport xxxxxx joy adapter" while others are "xxxxxx userport joy adapter"? what is the logic behind this?
-
btw, the example qbove: a c000 nop nop nop nop nop rts delete break exec $c000 g $c000 which does not break. but entering the monitor again and throw another g $c000 it DOES break. next g $c000 won't break, another g $c000 will break again... and so on.
-
btw, the example below: a c000 nop nop nop nop nop rts delete break exec $c000 g $c000 which does not break. but entering the monitor again and throw another g $c000 it DOES break. next g $c000 won't break, another g $c000 will break again... and so on.
-
well, i wish i could help more, but i don't really have the knowledge. but i see, this one does not break at all in r45151 a c000 nop nop nop nop nop rts break exec $c000 g $c000 whereas this one (note the different breakpoint) a c000 nop nop nop nop nop rts break exec $c001 g $c000 indeed breaks properly. as far as i can tell: (C:$c001) chis 3 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 2398026 .C:e5d1 8D 92 02 STA $0292 A:00 X:00 Y:0a SP:f3 ..-...Z. 2398029 .C:c000 EA NOP A:00 X:00 Y:0a...
-
well, i wish i could help more, but i don't really have the knowledge. but i see, this one does not break at all in r45151 a c000 nop nop nop nop nop lda #0 lda #1 lda #0 rts break exec $c000 g $c000 whereas this one (note the different breakpoint) a c000 nop nop nop nop nop lda #0 lda #1 lda #0 rts break exec $c001 g $c000 indeed breaks properly. as far as i can tell: (C:$c001) chis 3 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 2398026 .C:e5d1 8D 92 02 STA $0292 A:00 X:00 Y:0a SP:f3 ..-...Z....
-
well, i wish i could help more, but i don't really have the knowledge. but i see, this one does not break at all in r45151 a c000 nop nop nop nop nop lda #0 lda #1 lda #0 rts break exec $c000 g $c000 whereas this one a c000 nop nop nop nop nop lda #0 lda #1 lda #0 rts break exec $c001 g $c000 indeed breaks properly. as far as i can tell: (C:$c001) chis 3 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 2398026 .C:e5d1 8D 92 02 STA $0292 A:00 X:00 Y:0a SP:f3 ..-...Z. 2398029 .C:c000 EA NOP A:00...
-
ah. haha. now i know why i didn't get what the code actually was supposed to do. :) at least i can confirm now your observations.
-
hm. a c000 inc $d020 jmp $c003 break exec $c000 g $c000 this doesn't break at all here in r45151 ? only when using the "workaround".
-
i ran it 20 times now. just the monitor commands, i have mo other tools.
-
this is the output i get after applying the patch from #2025 (C:$e5cf) break exec 1035 BREAK: 1 C:$1035 (Stop on exec) (C:$e5cf) #1 (Stop on exec 1035) 128/$080, 57/$39 .C:1035 4C 35 10 JMP $1035 - A:0F X:01 Y:16 SP:f2 ..-..... 18366825 (C:$1035) delete 1 (C:$1035) break exec 0000 FFFF if RL == $fe BREAK: 1 C:$0000-$ffff (Stop on exec) Setting checkpoint 1 condition to: RL == $fe (C:$1035) #1 (Stop on exec 1035) 254/$0fe, 0/$00 .C:1035 4C 35 10 JMP $1035 - A:0F X:01 Y:16 SP:f2 ..-..... 18374706 (C:$1035)...
-
this is the output i get after applying the patch from #2024 (C:$e5cf) break exec 1035 BREAK: 1 C:$1035 (Stop on exec) (C:$e5cf) #1 (Stop on exec 1035) 128/$080, 57/$39 .C:1035 4C 35 10 JMP $1035 - A:0F X:01 Y:16 SP:f2 ..-..... 18366825 (C:$1035) delete 1 (C:$1035) break exec 0000 FFFF if RL == $fe BREAK: 1 C:$0000-$ffff (Stop on exec) Setting checkpoint 1 condition to: RL == $fe (C:$1035) #1 (Stop on exec 1035) 254/$0fe, 0/$00 .C:1035 4C 35 10 JMP $1035 - A:0F X:01 Y:16 SP:f2 ..-..... 18374706 (C:$1035)...
-
i did try ist. and indeed it looks this "horrible hack" fixes the 3 initial posted probs, plus the other two as well. the 5 cases: break 1000 break e147 a 1000 INC $D020 RTS sys 4096 r a = ff chis 4 break 1000 break e147 a 1000 INX STX $D020 RTS sys 4096 r a = ff chis 5 break 1000 break e147 a 1000 INC $D020 RTS sys 4096 r pc = 1003 chis 5 break 1000 r a = ff reset a c000 inc $0400 jmp $c003 break exec c003 g c000 m 0400 chis 2 seem to work as expected. BUT i am a complete n00b when it comes to stuff...
-
i did try ist. and indeed it looks this "horrible hack" fixes the 3 initial posted probs, plus the other two as well. the 5 cases: break 1000 break e147 a 1000 INC $D020 RTS sys 4096 r a = ff chis 4 break 1000 break e147 a 1000 INX STX $D020 RTS sys 4096 r a = ff chis 5 break 1000 break e147 a 1000 INC $D020 RTS sys 4096 r pc = 1003 chis 5 break 1000 r a = ff reset a c000 inc $0400 jmp $c003 break exec c003 g c000 m 0400 chis 2 seem to work as expected. BUT i am a complete n00b when it comes to stuff...
-
i did try ist. and indeed it looks this "horrible hack" fixes the 3 initial posted probs, plus the other two as well. the 5 cases: break 1000 break e147 a 1000 INC $D020 RTS sys 4096 r a = ff chis 4 break 1000 break e147 a 1000 INX STX $D020 RTS sys 4096 r a = ff chis 5 break 1000 break e147 a 1000 INC $D020 RTS sys 4096 r pc = 1003 chis 5 break 1000 r a = ff reset a c000 inc $0400 jmp $c003 break exec c003 g c000 m 0400 chis 2 seem to work as expected. BUT i am a complete n00b when it comes to stuff...
-
windows 7: (x64sc.exe:6308): Pango-WARNING **: 10:28:12.736: couldn't load font "C64 Pro Mono Bold Italic Not-Rotated 9", falling back to "Sans Bold Italic Not-Rotated 9", expect ugly output.
-
but support for Windows 7/8 is still pending honestly, the whole font thingy is a pain in the a$$ in windows 7 since the very beginning of the GTK3 version. all fonts in the 'common' folder are locked after using VICE and cannot be deleted. and despite that, the fonts don't show up in VICE. probably some GTK3 issue. i get it that win 7 is't supported anymore, but xxxFontResourceEx() should still work.
-
Also, switching between these hacks makes VICE segfault eventually .... only if you're in a rush... just wait until the machine actually finishes booting before clicking another hack. :) the bug itself started after https://sourceforge.net/p/vice-emu/code/37497/
-
yes, up to version v3.2 the limit was 4096 lines hardcoded. so what's a reasonable number? :) i wonder if there indeed is a usecase for >1mio lines?
-
btw, what would be the max (useful) lines? we can enter 99999999 in the GUI, but doing so, x64sc crashes for me. using 9999999 and chis, x64sc hangs. i guess such big numbers don't make much sense?
-
Wouldn't a separate buffer for each CPU be the proper solution? this was my thought too, but maybe that's not as easy. setting the buffer to something like 100000 may cover all cases (4 drives), but if we only use 1 drive we get a boatload of output lines.
-
increasing the chis buffer to 16384 already fixed the problem for me using an additional drive #9. but activating even more drives needs also bigger buffer. also it depends on the drive type. typing just chis in monitor: buffer size 16384, drive 8; 1541 output: 5720 lines buffer size 16384, drive 8: 1541, drive 9: 1541 output: 3867 lines buffer size 16384, drive 8: 1541, drive 9: 1541, drive 10: 1541 output: 0 lines
-
it seems the 'culprit' was https://sourceforge.net/p/vice-emu/code/39502/ but i guess you figured it out yourself.
-
where is this "fast copy" supposed to be??
-
fixed already. https://sourceforge.net/p/vice-emu/bugs/1974/
-
jpg has ben in VICE for many many years. see screenshot from version 3.6.1. but finally it was removed . And a lossy format for such small screenshots with maximum of 16 colors makes no sense anyway. exactly what i said for ages, but i always got told: "jpg is today's most common picture format".
-
ah ok. so for the gtk3 user the only thing changed he can choose the screenshot format. btw, what happend to jpg?
-
call me an idiot, what is this actually doing? i haven't looked at the code, but in the GUI i don't see anything new?
-
call me an idiot, what is this actually doing?
-
i tested it before, and it solved the issue for me. but i am no experienced user.
-
it's now even removed from the GUI, so i guess chances are small it will come back.
-
interesting, i always thought it makes sense the way it currently is. each emulator only writes its own settings, so if we start a new, empty config file, it will only contain the settings from the current emulator. if we "save settings to" and point to an existing config file, only the current emulators settings are updated, leaving the other settings untouched. as expected.
-
That seems weird indeed - and could be a GUI issue. @compyx can tell perhaps :) i see the same issue in the old winvice gui. it checks fordrive_check_type(DRIVE_TYPE_4000, num - 8) maybe the driveroms aren't unloaded.
-
for me, the SDL 3.7.1 version does exactly the same.
-
sorry to bring this up again.... but why isn't SNAP_MINOR increased in drivecpu65c02.c, as it is in drivecpu.c ?
-
x128 fails to display 960x540 interlace monochrome mode in VDC Mode Mania V1.2
-
Roberto?
-
https://sourceforge.net/p/vice-emu/code/31615/
-
see my edit. :) but i noticed the TAP is stuck at counter 142, but that happened before too. shrug.
-
but it still loads using the same command line. xvic.exe -default -memory 0,1,2,3,5 -dstapewobbleamp 0 -dsspeedtuning 1 /edit: actually it loads without setting anything fancy, just using 16k ram
-
but it still loads using the same command line. xvic.exe -default -memory 0,1,2,3,5 -dstapewobbleamp 0 -dsspeedtuning 1
-
i can say the initial behaviour is fixed. no more LED toggling after a reset.
-
well yes, i did. and it mostly works, but as said, it's all a bit confusing. x64sc -default -drivesound -soundrecdev wav -soundrecarg test.wav and x64sc -default -drivesound -sounddev wav -soundarg test2.wav produce the same wav output file. though there 's no "recording" shown in the statusbar (first line, where i think there should), the second has no hearable sound (that's expected i guess). so after all it works, i just don't see any use case for something like "-sounddev wav", everyone will...
-
well yes, i did. and it mostly works, but as said, it's all a bit confusing. x64sc -default -drivesound -soundrecdev wav -soundrecarg test.wav and x64sc -default -drivesound -sounddev wav -soundarg test2.wav produce the same wav output file. though there 's no "recording" shown in the statusbar (first line, where i think there should), the second has no hearable sound (that's expected i guess). so after all it works, i just don't see any use case for something like "-sounddev wav", everyone will...
-
also, the doc says: -soundrecdev <name> Specify recording sound driver (SoundRecordDeviceName). (aiff, dump, fs, iff, mp3, flac, ogg, speed, voc, wav)</name> so why dump and fs is NOT in the list of "snapshot -->> save/record media"?
-
confused by -sounddev and -soundarg
-
that is correct, i had no idea this is related, i thought this is some completely different issue.
-
x128 drives not working properly when switching to c64 mode.
-
try ffmpeg.exe? not sure if it works though.
-
if i do x128.exe -default activate "always switch to c64...." autostart still_ready.g64 i get a "?device not present error" if i autostart it again, it works. /edit: ok, this has nothing to do with recent drive changes. -->>> GTK3VICE-3.7.1-win64-r44095 GOOD -->>> GTK3VICE-3.7.1-win64-r44101 BAD
-
if i do x128.exe -default activate "always switch to c64...." autostart still_ready.g64 i get a "?device not present error" if i autostart it again, it works.
-
yes, seems to work, although i haven't tested thoroughly.
-
x128: drive 1571cr not working
-
ok then, have fun. :)
-
i had to add an #include <assert.h> in mon_profile.c after applying profiler_fix_aliasing.patch
-
i still wonder why it works just fine for me... same vice.ini, same windows version... no crash. i launched x64sc.exe about 10 times, jiffy is loaded, drive type 9 is CMD 4844.
-
protopad: button 7 (maybe) acting weird.
-
works for me too, nice.
-
ok, i could compile it. and it works . i used newest SDL2 2.65.5, so that is not the problem. the official biaries don't really crash, they just hang. the ones i tried a while ago did hang right after launching. new ones sooner or later hang (and eat 100% of that cpu core) while i am typing at the ready. "prompt".
-
VICE can load the Flimbo Quest TAP side A to the end, i did try 5 times. let's hope nothing else is broken. :)
-
GTK3VICE-3.7.1-win64-r43443 GOOD ...... GTK3VICE-3.7.1-win64-r43447 BAD i think we need Olaf...
-
i now tried, but it didn't want to compile with my old GCC 6.5 some tools (like sed) seem to be too outdated and error out. i might try again later and fix this, although i'm not really feel like playing around too long.
-
btw, both SDL variants don't work under windows 7 anymore, they crash. maybe it's the newer runtimes. just for information, i know no one cares about win 7. :)
-
this seems to work now. but... sha1 might be a bit of an overkill just for this. :)
-
yes, i noticed this too, related to https://sourceforge.net/p/vice-emu/code/43621/
-
ok, now i see, bzip2 packed files do NOT store a file name, it repacks the same TEMP name like gzip, but we do not see this in the packed file. after all i now commented out the whole recompress code in the local code here. sorry, i wanted to select "windows" not "android" port.
-
strange handling of archive files
-
i'm afraid i am not of much help here, as i'm not familiar with printers and printing at all. it seems now there is no driver loaded for NL10, but i guess this is intended now. NL10 in graphic and text mode at least prints.
-
i see something that confuses me a bit. when launching x64sc -default, the log comes up with Loading system file Z:\MSYS64N\home\Thomas\vice\GTK3\bin\..\PRINTER\nl10.bin'. although printer4 defaults to mps-803. if i now change the printer4 in GUI to NL10, the log shows Loading system file Z:\MSYS64N\home\Thomas\vice\GTK3\bin\..\PRINTER\8023-325320-02.bin'. which actually is the commodore 8023 ROM.
-
as a windows user myself i always wonder why other windows users start a GUI prog from the command line.
-
btw, both denise and hoxs64 fail too.
-
work,s for me, traps are set properly. loading works. maybe needs better testing though.
-
doesn't crash on windows. however, we get the same log errors. it looks it's r42129 which causes the trouble.
-
doesn't crash on windows. however, we get the same log errors. it looks it's r42128 which causes the trouble.
-
ah i now see what you mean. formfeed indeed does nothing. open1,4,0:print#1,"test 0" press formfeed print#1,"test 1" press formfeed print#1,"test 2" press formfeed close 1 prints the 3 lines on the same page. the same as without formfeed. open1,4,0:print#1,"test 0":close1 open1,4,7:print#1,"test 7":close1 yes, we end up with only "test 7". because VICE overwrites the existing BMP. so yes, the printing stuff is buggy, and as far as i remember, it never really worked properly.
1 >