Activity for Algorithmix
-
Algorithmix posted a comment on ticket #2024
Of course. I think there are only 2 things left: The monitor can't break between an instruction and the interrupt-BRK "pseudo-instruction". (If a RL-based breakpoint occurs during an instruction which is immediately followed by an interrupt, the breakpoint doesn't break until after the interrupt-BRK) Not an issue for "normal" breakpoints, only for breakpoints with a rasterline (RL) condition (and possibly other timing-related conditions). This might be working as intended, and not be a bug. If so,...
-
Hey, Olaf! Thank you for your reply. Some very awesome experiments and ideas you have written about! I'll try to give some input/opinions: CPU-history I completely 1000% agree with you that it would be extremely helpful to have the "interrupt-BRK" instructions in the CPU-history as well! That would be a very valuable debugging help! And it would also better show what the CPU have been executing. (Also, i'm glad i'm not the only one who have been surprised by this xD) Right now, in your prototype,...
-
Hey, Olaf! Thank you for your reply. Some very awesome experiments and ideas you have written about! I'll try to give some input/opinions: CPU-history I completely 1000% agree with you that it would be extremely helpful to have the "interrupt-BRK" instructions in the CPU-history as well! That would be a very valuable debugging help! And it would also better show what the CPU have been executing. (Also, i'm glad i'm not the only one who have been surprised by this xD) Right now, in your prototype,...
-
Hey, Olaf! Thank you for your reply. Some very awesome experiments and ideas you have written about! I'll try to give some input/opinions: CPU-history I completely 1000% agree with you that it would be extremely helpful to have the "interrupt-BRK" instructions in the CPU-history as well! That would be a very valuable debugging help! And it would also better show what the CPU have been executing. (Also, i'm glad i'm not the only one who have been surprised by this xD) Right now, in your prototype,...
-
By the way, my last two posts were only about "Problem #2". I do not know the VICE sourcecode, so don't think i can give much input to the other posts. Let me know if you need something from me, of course :) TL;DR: "Problem #2" could be considered a bug or it could be considered expected behaviour, and this issue could be closed (and preferably write a couple of lines description in the monitor documentation). Also, maybe i'm missing something, so you guys should probably doublecheck my assumptions...
-
By the way, my last two posts were only about "Problem #2". I do not know the VICE sourcecode, so don't think i can give much input to the other posts. Let me know if you need something from me, of course :) TL;DR: "Problem #2" could be considered a bug or it could be considered expected behaviour, and this issue could be closed (and preferably write a couple of lines description in the monitor documentation). Also, maybe i'm missing something, so you guys should probably doublecheck my assumpti...
-
By the way, my last two posts were only about "Problem #2". I do not know the VICE sourcecode, so don't think i can give much input to the other posts. Let me know if you need something from me, of course :)
-
Turns out i already did this most of the test program for "Problem #2". I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction,...
-
Turns out i already did this most of the test program. I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction, the monitor does...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Turns out i already did this most of the test program. I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction, the monitor does...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Anyway, I'll still give you the test-program for "Problem #2": How to run: Load the PRG into VICE, but don't run it. Instead, open the monitor and execute the monitor commands. (just copy/paste them) Info: The test program sets up a raster-interrupt to occur at a certain rasterline, and also instructs the VICE-monitor to break at the same rasterline. Then we see what happens if we do a g XXXX in the monitor after the breakpoint has been reached. The "main-program" will just execute a lot of JMPs...
-
Turns out i already did this most of the test program. I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction, the monitor does...
-
Turns out i already did this most of the test program. I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction, the monitor does...
-
Turns out i already did this most of the test program. I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction, the monitor does...
-
Turns out i already did this most of the test program. I've looked a bit more into it today, and think i've now gotten a better understanding of what's going on - and it's not as bad as i was afraid of. This is NOW my understanding of the issue: (remember: this is just me guessing from a couple of experiments, but i do think it makes sense) For rasterline-breakpoints (an RL-condition): If you break at an instruction where an interrupt will start immediately after that instruction, the monitor does...
-
Cool that there is some activity here again. I'll do a cycle-accurate test-program for "Problem #2" as soon as possible. (perhaps won't have time today) "Problem #2" should be the only remaining unsolved issue from this ticket, i think. "Problem #1" and "Problem #3" should already have been solved by the fix for ticket #2025. (As mentioned earlier in this thread, problem #1 was not really a real bug - it was a mix between problem #3 (which was real enough) and me mistakenly thinking that the CPU...
-
Cool that there is some activity here again. I'll do a cycle-accurate test-program for "Problem #2" as soon as possible. (perhaps won't have time today) "Problem #2" should be the only remaining issue from this ticket, i think. "Problem #1" and "Problem #3" should already have been solved by the fix for ticket #2025. (As mentioned earlier in this thread, problem #1 was not really a real bug - it was a mix between problem #3 (which was real enough) and me mistakenly thinking that the CPU could startup...
-
Yes, ok - it is of course completely up to you guys. I just noticed the change, debugged what was going on, and reported my findings here, in case the change wasn't done on purpose. And it's a pretty minor issue, of course. Maybe only 1 program incompatible with the new behavior. It just seems to me like the old way of consistenly using the same shift-key for the cursor-keys has a couple of advantages (works like i believe people use the cursor-keys on a real C64, C64-programs not forced to use both...
-
Yes, of course: a) Windows 10 b) I guess the host locale is the "Windows display language" in windows? If so: "English (United States)" c) I tried all the positional keymaps, for both of the host keyboard layouts in d). d) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current...
-
Yes, of course: a) Windows 10 b) I guess the host locale is the "Windows display language" in windows? If so: "English (United States)" c) I tried all the positional keymaps, for both of the host keyboard layouts in d). d) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current...
-
Yes, of course: a) Windows 10 b) I guess the host locale is the "Windows display language" in windows? If so: "English (United States)" c) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) d) I tried all the positional keymaps, for both of the host keyboard layouts in b). Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current...
-
Yes, of course: a) Windows 10 b) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) c) I tried all the positional keymaps, for both of the host keyboard layouts in b). Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current behavior is the expected behavior? (Incompatible with at least one C64 program - EDIT: Well, perhaps unless...
-
Yes, of course: a) Windows 10 b) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) c) I tried all the positional keymaps, for both of the host keyboard layouts in b). Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current behavior is the expected behavior? (Incompatible with at least one C64 program - EDIT: Well, unless it's...
-
Yes, of course: a) Windows 10 b) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) c) I tried all the positional keymaps, for both of the host keyboard layouts in b). Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current behavior is the expected behavior? (Incompatible with at least one C64 program)
-
Yes, of course: a) Windows 10 b) Tried both Danish and US keyboard layout (selected in both Windows and under the "Host keyboard layout" setting in VICE) c) I tried all the positional keymaps, for both of the host keyboards in b). Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current behavior is the expected behavior? (Incompatible with at least one C64 program)
-
Yes, of course: a) Windows 10 b) Tried both Danish and US keyboard layout (selected in both windows and under "Host keyboard layout") c) I tried all the positional keymaps, for both of the host keyboards in b). Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current behavior is the expected behavior? (Incompatible with at least one C64 program)
-
Yes, of course: a) Windows 10 b) Tried both Danish and US keyboard layout (selected in both windows and under "Host keyboard layout") c) I tried all the positional keymaps, for both combinations of host keyboard. Ok, thanks for testing. Do you mean that it works as in "cursor keys triggers right-shift, also while left-shift is held down", or do you mean that the current behavior is the expected behavior? (Incompatible with at least one C64 program)
-
Left-shift + cursor keys together not triggering right-shift
-
Interesting that it alternates like that. (some flag/state that is used for whether or not we should break immediately before the first instruction if there is a bp there?) Haven't found anything new. Just some minor points from a bit of experimenting: Looks like entering the monitor from a breakpoint also triggers it: a c000 inc $d020 jmp $c000 break exec c000 break exec e5cf x g c000 chis 5 .C:e5d1 8D 92 02 STA $0292 A:00 X:00 Y:0a SP:f3 ..-...Z. 4124988 .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3...
-
Interesting that it alternates like that. (some flag/state that is used for whether or not we should break immediately before the first instruction if there is a bp there?) Haven't found anything new. Just some minor points from a bit of experimenting: Looks like entering the monitor from a breakpoint also triggers it: a c000 inc $d020 jmp $c000 break exec c000 break exec e5cf x g c000 chis 5 .C:e5d1 8D 92 02 STA $0292 A:00 X:00 Y:0a SP:f3 ..-...Z. 4124988 .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3...
-
Yes, you're right - also here. (sorry, i made a writing-mistake initially and wrote "jmp $c003", instead of "jmp $c000", if you were trying to reproduce what i wrote :))
-
Yes, you're right. (sorry, i made a writing-mistake initially and wrote "jmp $c003", instead of "jmp $c000", if you were trying to reproduce what i wrote :))
-
Hi @gpz. Did some testing and I think i've found a problem in r45151: Start a clean VICE (x64sc) Go to the monitor Type: a c000 inc $d020 .c003 jmp $c000 .c006 and add a breakpoint to the same address we jump to: break exec c000 g c000 If we type chis 5, then in r45151 we get this: .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 5336219 .C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 5336222 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 5336225 .C:c000 EE 20 D0 INC $D020 A:00 X:00...
-
Hi @gpz. Did some testing and I think i've found a problem in r45151: Start a clean VICE (x64sc) Go to the monitor Type: a c000 inc $d020 .c003 jmp $c003 .c006 and add a breakpoint to the same address we jump to: break exec c000 g c000 If we type chis 5, then in r45151 we get this: .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 5336219 .C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 5336222 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 5336225 .C:c000 EE 20 D0 INC $D020 A:00 X:00...
-
Hi @gpz. Did some testing and I think i've found a problem in r45151: Start a clean VICE (x64sc) Go to the monitor Type: a c000 inc $d020 .c003 jmp $c003 .c006 and add a breakpoint to the same address we jump to: break exec c000 g c000 If we type chis 5, then in r45151 we get this: .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 5336219 .C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 5336222 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 5336225 .C:c000 EE 20 D0 INC $D020 A:00 X:00...
-
Hi @gpz. Did some testing and I think i've found a problem in r45151: Start a clean VICE (x64sc) Go to the monitor Type: a c000 inc $d020 .c003 jmp $c003 .c006 and add a breakpoint to the same address we jump to: break exec c000 g c000 If we type chis 5, then in r45151 we get this: .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 5336219 .C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 5336222 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 5336225 .C:c000 EE 20 D0 INC $D020 A:00 X:00...
-
Hi @gpz. Did some testing and I think i've found a problem in r45151: Start clean VICE (x64sc) Go to the monitor Type: a c000 inc $d020 .c003 jmp $c003 .c006 and add a breakpoint to the same address we jump to: break exec c000 g c000 If we type chis 5, then in r45151 we get this: .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 5336219 .C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 5336222 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 5336225 .C:c000 EE 20 D0 INC $D020 A:00 X:00 Y:0a...
-
Very cool! That was much faster than i expected! You're a genious! :) It looks like the instruction-duplication is solved, and looks like "problem 1" wasn't actually a real problem (see below). I will run a lot of my old tests through the remote-monitor soon, to see they still behave the same as before (i use "r" and "g" in those all the time). Seems like "Problem 2" is still a thing, so i can do an issue on it, as soon as possible. I was terribly, terribly wrong about problem#1. I was mistakenly...
-
Thanks!! That was a lot of times - much more than i expected of you :) Only 2 of the cases was hit, for some reason, but that's fine (when i've tried, i usually hit them in very few tries, but i guess that's how randomness works :)) Unfortunately, it looks like the patch didn't fix the interrupt-problem ("problem#1" at least), since the "INC $104A" is still executed before the interrupt-BRK, when we break at (=after) CYC 001. Thanks again! EDIT: But i think i'll have to re-read up on my interrupt...
-
Thanks!! That was a lot of times - much more than i expected of you :) Only 2 of the cases was hit, for some reason, but that's fine (when i've tried, i usually hit them in very few tries, but i guess that's how randomness works :)) Unfortunately, it looks like the patch didn't fix the interrupt-problem ("problem#1" at least), since the "INC $104A" is still executed before the interrupt-BRK, when we break at (=after) CYC 001. Thanks again!
-
Thank you very much for running it on the build from #2525! Really appreciate it! :) It would be very interesting to get a CPU-history for all the 3 possibilities, to be sure the interrupt-problems are really fixed by the patch from #2025. I unfortunately don't have the skills to build it myself, so can't really check this myself. :'( Can you perhaps help again? I'll just add an extra "r" command to the monitor-commands, so we can see which cycle/rasterline we have breaked at and thereby identify...
-
Thank you very much for running it on the build from #2525! Really appreciate it! :) It would be very interesting to get a CPU-history for all the 3 possibilities, to be sure the interrupt-problems are really fixed by the patch from #2025. I unfortunately don't have the skills to build it myself, so can't really check this myself. :'( Can you perhaps help again? I'll just add an extra "r" command to the monitor-commands, so we can see which cycle/rasterline we have breaked at and thereby identify...
-
Thank you very much for running it on the build from #2525! Really appreciate it! :) It would be very interesting to get a CPU-history for all the 3 possibilities, to be sure the interrupt-problems are really fixed by the patch from #2025. I unfortunately don't have the skills to build it myself, so can't really check this myself. :'( Can you perhaps help again? I'll just add an extra "r" command to the monitor-commands, so we can see which cycle/rasterline we have breaked at and thereby identify...
-
Thank you very much for running it on the build from #2525! Really appreciate it! :) It would be very interesting to get a CPU-history for all the 3 possibilities, to be sure the interrupt-problems are really fixed by the patch from #2025. I unfortunately don't have the skills to build it myself, so can't really check this myself. :'( Can you perhaps help again? I'll just add an extra "r" command to the monitor-commands, so we can see which cycle/rasterline we have breaked at and thereby identify...
-
I was just about to write a ticket on this (split out from #2024). This instruction-duplication can also be reproducted without "r", but with "g XXXX" and a breakpoint. For example: Start a clean VICE Press ALT+H to enter the monitor Enter this into the monitor: a c000 inc $0400 .c003 jmp $c003 .c006 and break exec c003 g c000 If you type m 0400, you can see that address $0400 contains $22 instead of $21 If you type cpuhistory, you can also see that it's duplicated in the CPU-history EDIT: It seems...
-
I was just about to write a ticket on this (split out from #2024). This instruction-duplication can also be reproducted without "r", but with "g XXXX" and a breakpoint. For example: Start a clean VICE Press ALT+H to enter the monitor Enter this into the monitor: a c000 inc $0400 .c003 jmp $c003 .c006 and break exec c003 g c000 If you type m 0400, you can see that address $0400 contains $22 instead of $21 If you type cpuhistory, you can also see that it's duplicated in the CPU-history EDIT: It seems...
-
I was just about to write a ticket on this (split out from #2024). This instruction-duplication can also be reproducted without "r", but with "g XXXX" and a breakpoint. For example: Start a clean VICE Press ALT+H to enter the monitor Enter this into the monitor: a c000 inc $0400 .c003 jmp $c003 .c006 and break exec c003 g c000 If you type m 0400, you can see that address $0400 contains $22 instead of $21 If you type cpuhistory, you can also see that it's duplicated in the CPU-history
-
I was just about to write a ticket on this (split out from #2024). This instruction-duplication can also be reproducted without "r", but with "g XXXX" and a breakpoint. For example: Start a clean VICE Press ALT+H to enter the monitor Enter this into the monitor: a c000 inc $0400 .c003 jmp $c003 .c006 and break exec c003 g c000 If you type m 0400, you can see that address $0400 contains $22 instead of $21 If you type cpuhistory, you can also see that it's duplicated in the CPU-history (Maybe when...
-
I was just about to write a ticket on this (split out from #2024). This instruction-duplication can also be reproducted without "r", but with "g XXXX" and a breakpoint. For example: Start a clean VICE Press ALT+H to enter the monitor Enter this into the monitor: a c000 inc $0400 .c003 jmp $c003 .c006 and break exec c003 g c000 If you type m 0400, you can see that address $0400 contains $22 instead of $21 If you type cpuhistory, you can also see that it's duplicated in the CPU-history (Maybe it's...
-
I was just about to write a ticket on this (split out from #2024). This duplication can also be reproducted without "r", but with "g XXXX" and a breakpoint. For example: Start a clean VICE Press ALT+H to enter the monitor Enter this into the monitor: a c000 inc $0400 .c003 jmp $c003 .c006 and break exec c003 g c000 If you type m 0400, you can see that address $0400 contains $22 instead of $21 If you type cpuhistory, you can also see that it's duplicated in the CPU-history (Maybe it's because than...
-
Ah, ok, thank you - that sounds great! I will stop for now. (Just skimmed #2025 - on the surface of it, it sounds to only be the instruction-duplication bug ("problem #3" above), but we'll see. Otherwise, i can post the new test-code and text i've done :))
-
Hi Groepaz A few questions on how it would be most convenient for you that i split the tickets: I can create 3 new tickets where the 2 of them refer to each other. (and maybe also refers back to this ticket as parent-ticket, which can then be closed). Ok? The current test program currently requires you to run it a few times to get the right "jitter", if you want to catch a specific outcome (3 possibilities). After having split up into individual tickets, is that still ok? Or do you want me to do...
-
Thank you for your reply, gpz! I unfortunately do not have much time the next few days, so just a quick answer for now. I could split this ticket up, however, the first two "problems" are basically the same: Break exactly before an interrupt would start, and do a "g XXXX". What happens in that case can vary between "problem 1" and "problem 2" (and perhaps something else i have not yet encountered). Since i do not really know what exact condition causes VICE to behave as "problem 1" or as "problem...
-
Thank you for your reply, gpz! I unfortunately do not have much time the next few days, so just a quick answer for now. I could split this ticket up, however, the first two "problems" are basically the same: Break exactly before an interrupt would start, and do a "g XXXX". What happens in that case can vary between "problem 1" and "problem 2" (and perhaps something else i have not yet encountered). Since i do not really know what exact condition causes VICE to behave as "problem 1" or as "problem...
-
Thank you for your reply, gpz! I unfortunately do not have much time the next few days, so just a quick answer for now. I could split this ticket up, however, the first two "problems" are basically the same: Break exactly before an interrupt would start, and do a "g XXXX". What happens in that case can vary between "problem 1" and "problem 2" (and perhaps something else i have not yet encountered). Since i do not really know what exact condition causes VICE to behave as "problem 1" or as "problem...
-
Thank you for your reply, gpz! I unfortunately do not have much time the next few days, so just a quick answer for now. I could split this ticket up, however, the first two "problems" are basically the same: Break exactly before an interrupt would start, and do a "g XXXX". What happens in that case can vary between "problem 1" and "problem 2" (and perhaps something else i have not yet encountered). Since i do not really know what exact condition causes VICE to behave as "problem 1" or as "problem...
-
Thank you for your reply, gpz! I unfortunately do not have much time the next few days, so just a quick answer for now. I could split this ticket up, however, the first two "problems" are basically the same: Break exactly before an interrupt would start, and do a "g XXXX". What happens in that case can vary between "problem 1" and "problem 2" (and perhaps something else i have not yet encountered). Since i do not really know what exact condition causes VICE to behave as "problem 1" or as "problem...
-
Update: Problem 3 doesn't actually seem to always happen. I just tried a "g XXXX" where it did not happen. Then i tried the exact same "g XXXX" again, and it did happen. So not sure about the conditions.
-
3 monitor issues wrt. the "g XXXX"-command and interrupts (can "crash" the C64-code)
-
Monitor cpuhistory - show cycle and rasterline
-
@gpz: Unfortunately, the $ key-combo is a bit weird on a danish keyboard, it's AltGr+4, and it doesn't work. (Shift+4 is the "generic currency" symbol) I'm also more interested in the positional layout anyway - is it a "gtk3_pos_da.vkm" file that needs to be created? (If so (and in case i get the motivation to do one), in order to check if the mapping is correct, i guess it would be fine to use WinVICE as the "source of truth"? I.e. the mapping should work exactly as in WinVICE for all keys, right?)...
-
Ah, ok. (Was a bit surprising to me that even the "positional" layout needs a per-country keymap - but makes sense :) ) (Works fine in WinVICE2.4, btw, but different codebase and different libraries, i guess) @compyx: It would be nice if it was grayed out / removed - and really nice if a warning was displayed if the current keyboard-layout of the host is not supported (it's hard to know what's wrong otherwise). With "gtk3 keymap", do you mean the "gtk3_sym_xx.vkm" files or something internal to GTK3?...
-
(And, of course, i've tried selecting host layout = danish. But it jumps back to american, when i enter settings again or go to another section in settings and back again. Perhaps that is the problem?)
-
Note: It is the same with both "symbolic" and "positional" keyboard mapping. (By the way: It seems like "symbolic" uses positional mapping, and "positional" uses symbolic mapping - or something like that... Actually it seems like the "positional" mapping doesn't really follow an obvious pattern. (With danish keyboard at least). So perhaps the issue is larger the mapping of "$")
-
Keyboard: Can't write $ (dollar sign) on danish keyboard (Windows)
-
Running as admin worked. And as mentioned in the other ticket, after having run as admin, it now also works when running as a normal user. (so i no longer have a test-case)
-
(sorry for formatting - edit functionality seem to be missing...)
-
"GTK3VICE-3.2-win64-r35190" does not start up
-
Thank you for your answer and sorry for delay :) Yeah, it seems "load" causes a crash...
-
Monitor commands not working properly from command line "-moncommands" script (unit testing c64 code)
1