Activity for VICE
-
gpz modified ticket #2178
Breakpoint check is flawed
-
ok, great, closing this one
-
Yeah, actually seeing that code made me remember this ticket - but whatever it tried to do, it doesn't work :)
-
rice123 posted a comment on ticket #2126
looks like there was an attempt to fix something potentially related in https://sourceforge.net/p/vice-emu/code/39075/
-
r45820 works, thanks. I don't know about any other edge cases, #2126 is the only major reliability problem known to me for now.
-
A similar check could also be done directly inside the monitor: when doing a G XXXX (and possibly other similar commands) it would do the breakpoint check and not even leave the monitor if it says that there is a breakpoint at XXXX. That was what i had in mind too - and no, i don't like it either :) BUT perhaps it is a good temporary workaround for the time being - with low potential to break other stuff (?)
-
try r45820 ... would be great if you could come up with some more edge cases (and post them here), i'll make tests out of those
-
move breakpoint range check into the loop instead of trying early exit, should fix #2178
-
I'll look at this, it should be unrelated to the other problem(s)
-
A similar check could also be done directly inside the monitor: when doing a G XXXX (and possibly other similar commands) it would do the breakpoint check and not even leave the monitor if it says that there is a breakpoint at XXXX. That was what i had in mind too - and no, i don't like it either :)
-
Breakpoint check is flawed
-
Thanks for the fix, but having read the code changed in r45813 I think there are more fundamental problems here... I'll file a new bug.
-
Olaf Seibert posted a comment on ticket #2177
Another thought. The longer I think about it, the less I like the way that you get into the monitor via Alt-H: with that IK_TRAP and interrupt_do_trap(). This is set up in monitor_open_action() -> monitor_setup_trap() -> interrupt_maincpu_trigger_trap() which adds a trap which would apply before the next instruction is executed. Since this makes 2 different ways of getting into the monitor, it creates a difference in the checks that are made after you leave the monitor. Essentially that was already...
-
Two possible solutions come to mind right away but I don't really like either of them. Maybe there is a third one. monitor_startup(CALLER); would get a return value, which indicates either "continue normal flow" or "flow has changed". In the second case, the breakpoint check (but probably also the icount and watchpoint checks) need to be done again right away. A similar check could also be done directly inside the monitor: when doing a G XXXX (and possibly other similar commands) it would do the...
-
To my confusion, this bug doesn't happen as described with the following patch. It includes the change for the cpu history, but that should not make a difference. Index: 6510dtvcore.c =================================================================== --- 6510dtvcore.c (revision 45818) +++ 6510dtvcore.c (working copy) @@ -285,6 +285,7 @@ if (TRACEFLG) { \ debug_nmi(CPU_INT_STATUS, CLK); \ } \ + monitor_cpuhistory_store(CLK, 0xFFFA, 0, 0, 0, reg_a_read, reg_x, reg_y, reg_sp, LOCAL_STATUS(), ORIGIN_MEMSPACE);...
-
interesting! graphene-1.10.8 is also what i have installed (but no gtk4 whatsoever - my distro doesnt even have a package for it yet)
-
Mads Nielsen posted a comment on ticket #2176
==> Fetching downloads for: gtk4 ==> Downloading https://ghcr.io/v2/homebrew/core/gtk4/manifests/4.20.2 ################################################################### 100.0% ==> Fetching dependencies for gtk4: graphene ==> Downloading https://ghcr.io/v2/homebrew/core/graphene/manifests/1.10.8 ################################################################### 100.0% ==> Fetching graphene ==> Downloading https://ghcr.io/v2/homebrew/core/graphene/blobs/sha256:11188e7d3 ###################################################################...
-
Lorenzo Castelletta posted a comment on ticket #501
I might be wrong, but there is no existing cartridge emulation which provides, for example, .crt launching, which I think it is quite an advantage. It allows the user to launch .crt files without the need of using the emulator gui, which in some cases "interrupts" the vintage experience when dealing with retrosystems and on some other systems it is even tedious and unresponsive to use. But whatever, maybe someone else will be interested in this project.
-
WTF? We don't use GTK4... at all? Do you have a log of that install procedure? Maybe it pulled in some other thing (a different Pango perhaps?) that makes the difference
-
Querino posted a comment on ticket #2168
No, the ones from Github. Sadly, i have only this one system with w11 installed.
-
Advanced Cartridges Emulation (Kung Fu Flash and similar)
-
Uh, no. These are all emulators by themselves, emulating them makes no sense and doesn't really provide any advantages over the existing cartridge emulation either.
-
Advanced Cartridges Emulation (Kung Fu Flash and similar)
-
Found something interesting.. After installing GTK4 it works!
-
define sprite pattern in the makefile, so we can add additional tests easily
-
<REDACTED> posted a comment on ticket #556
DELETE THIS REQUEST
-
I think this broke along the way of fixing some other bug(s)
-
Interesting. As far as i can see, this worked back then in v3.2 (native) for windows.
-
If you do this slightly different, where you g to the instruction before the breakpoint, it works. So I'm fairly sure that this indicates that it is related to the order in which things are done in the big DO_INTERRUPT macro. Even though (as far as I can tell). Let's quote the version from c64dtvcore, the one used in x64sc which already has some changes in it as I was contemplating in the parent ticket: #define DO_INTERRUPT(int_kind) \ do { \ uint8_t ik = (int_kind); \ uint16_t addr; \ \ if (ik &...
-
I created patch 404 (nice number) to split out the issue with the cpu history.
-
Include IRQ and NMI in cpu-history
-
Yes, please make new/seperate tickets for those. (And if you can add a good -stable- testcase for the first, please give that as well)
-
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,...
-
update the Makefile too :)
-
So, i am coming back to this - i read it all again and this ticket blows my mind. There are just too many things mixed up here for me As a first countermeasure i created https://sourceforge.net/p/vice-emu/bugs/2177/ for the "Checkpoint on ADDR does not trigger after G ADDR" problem. I don't know how to deal with the rest. It would be great if one of you guys (@Algorithmix , @rhialto ) would create new, seperate(!) tickets for whatever other problem(s) from this ticket are still not fixed. We really...
-
Monitor assign registers
-
added remaining testcases, all seems OK - > closing
-
remaining testcases for bug #2025, seems all OK in trunk
-
This works in trunk (C:$e5d4) break ea31 BREAK: 1 C:$ea31 (Stop on exec) (C:$e5d4) r a = ff (C:$e5d4) reset #1 (Stop on exec ea31) 2/$002, 1/$01 .C:ea31 20 EA FF JSR $FFEA - A:00 X:F9 Y:84 SP:f9 ..-..IZC 2162287 (C:$ea31)
-
Another variable: do you build VICE yourself?
-
Fixer posted a comment on ticket #1785
Hey! Sounds like you’ve already done solid testing — since it’s working fine on GamepadTester, the hardware itself seems okay. The issue might be with how VICE maps joystick axes on macOS. Try switching the input driver from “SDL” to “HID” under Settings → Joystick Settings → Device Type. Some users also fix it by resetting their .vice config file or toggling “swap ports.” If that doesn’t help, you can double-check your controller signals on https://gampadtester.com/ — it’ll confirm whether the directional...
-
I don't see dirmaster on this system, and C64_Pro_Mono-STYLE.ttf is not in any of my system folders. Strange.
-
Do you have the pet font installed systemwide by any chance (eg for Dirmaster)?
-
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.
-
Frederic bezies posted a comment on ticket #2168
I'm using this workaround on my Vice installation in Win11. Weird, really weird.
-
And it works when starting the emulator a second time? At least thats what i see on my Windows10 ... really weird, it used to work
-
Just for your information. I tested Vice rev 45816 in a HyperV virtual machine with Win11 in it. And the same bug appears. I'm glad it is not a bug on my installation.
-
Checkpoint on ADDR does not trigger after G ADDR
-
z80 Assembler is broken
-
Drive resource values appear different than requested during '-moncommands' script, but are set correctly
-
SO, the problem really is the autostart code. With TDE off, it enables the traps for autostarting the d64. The problem here is, that it will also do this when busdevice is enabled (which should be equally sufficient) - ie it does not handle (or consider) "busdevice" at all. This can probably be fixed, but will require quite some testing. I'd rather look at this later (after XMAS)
-
Monitor copy paste is incomplete.
-
r45816 copies inverted chars like normal chars
-
copy inverted characters like normal characters from the monitor, as suggested in #2167
-
Linux evdev joystick driver fails for axes with minimum=-1 and maximum=1
-
sounds good -> closing
-
Ralph Moeritz posted a comment on ticket #2161
Just tested with my 8bitdo SN30 pro (USB, evdev) in r45815 & still works fine.
-
fix warning
-
yes, confirmed working.
-
Sooo, looking at this again. First, i have updated the script a bit to take use changed options/resources - and to resget the 4 resources on both breakpoints. The result is indeed surprising a bit: On the first breakpoint, it always (so it does not depend on the order of cmdline options) prints AutostartHandleTrueDriveEmulation=0 Drive8TrueEmulation=0 TrapDevice8=1 <- wrong! should be zero BusDevice8=1 at the second breakpoint its fine: AutostartHandleTrueDriveEmulation=0 Drive8TrueEmulation=0 TrapDevice8=0...
-
confirmed, still looks like this addr: IO ROM RAM c000: --- --- --x (uninitialized exec) c003: --- --- --x (uninitialized exec) c006: --- --- r-x (uninitialized exec) c010: --- --- r-- (uninitialized read) c020: --- --- -w-
-
Confirmed, still broken in trunk
-
A higher COM port number than 9 does not work.
-
Added a note in the docs about this \.\ stuff -> closing
-
added note on using higher COM ports in Windows
-
Monitor should wait until no more keys are pressed when closing
-
Return key press not recognized after leaving monitor
-
cant we change the parser to only match/check for a mnemonic when its the first thing in the line? somehow we have a lot of odd problems with this lex/yuck stuff, which shouldnt be issues at all :)
-
Can't re-enter monitor after monitor autostart <snapshot file> command
-
no feedback, quick test works -> closing
-
Snapshot load errors: undump API on VICE 3.3 (GTK Win32 DX sound)
-
no feedback, quick test works (on linux though) -> closing
-
-moncommands crash
-
no feedback, can't reproduce, tests work (as in not crash) -> closing
-
monitor output does not adjust to monitor window size
-
fixed in trunk
-
Remote monitor : UNIX LF also on windows.
-
Keyboard cursor control (shift)
-
closing, this cant really be fixed, as said.
-
CRTC emulation is incomplete
-
Tape position resets when attaching a disk
-
no feedback, can not reproduce -> closed
-
radius75 posted a comment on ticket #1950
Understandable. It's worth adding information somewhere that this option works this way.
-
x64: Reading D01E/1F should not clear bits in D019
-
Elite 128 has drawing issues
-
closing this - can't reproduce
-
Option Save Settings To NEW.INI saves settings only for the current computer
-
i am closing this - it seems like the current behaviour is actually the best compromise
-
archive (packed) files will not be updated when modified
-
VICE 3.7.1 (and 3.7) crashes when started from VSCODE through PowerShell script?
-
no feedback for more than two years - closing
-
Sound processing incorrectly
-
xvic systematic crash with NTSC interlace
-
Binary monitor MemoryGet causing side-effects for I/O memory
-
remote monitor cannot be deactivated
-
Impossible to redirect the help console output into a file
-
Breakpoint state corruption
-
fixed in r45813 it will still not trigger on 1000 if you start with g1000 (it triggers one instruction after that), but that is another problem that still has to be fixed.
-
when inserting checkpoints into the list, compare their start addresses (as intended). fixes bug #2122
-
I compiled with debug enabled now... and only ever see it crash when switching interlace on and then exit the emu - with a similar backtrace as compyx did shrug
1 >