X64sc "chis" only works sometimes.
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
#1994 X64sc "chis" only works sometimes.
Most of the time it shows nothing and doesn't matter if I use it right after entering the monitor or after a breakpoint.
(C:$f140) x
(C:$e5d1) chis
(C:$e5d1) chis
(C:$e5d1) chis
(C:$e5d1) chis
(C:$e5d1) chis
(C:$e5d1) chis
(C:$e5d1) n
.C:e5d4 F0 F7 BEQ $E5CD - A:00 X:00 Y:0A SP:f3 ..-...Z. 5401760433
(C:$e5d4) n
.C:e5cd A5 C6 LDA $C6 - A:00 X:00 Y:0A SP:f3 ..-...Z. 5401760436
(C:$e5cd) n
.C:e5cf 85 CC STA $CC - A:00 X:00 Y:0A SP:f3 ..-...Z. 5401760439
(C:$e5cf) chis
.C:e5d1 8D 92 02 STA $0292 A:00 X:00 Y:0a SP:f3 ..-...Z. 5401760429
.C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 5401760433
.C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 5401760436
please try r45004 - if you still get the problem, please tell :)
Seems to work just after starting vice, but if a breakpoint is triggered two or more times:
I configure with
./configure --enable-ffmpeg --enable-debug
if it might be of some use to know...
Edit: If I keep running the breakpoint, sometimes it works and sometimes it doesn't, but with no apparent logic.
it would really help if you could track down the revision that broke it... i cant reproduce it anymore, not even when going back some revisions - super weird
edit: and not after reconfiguring like you said either
Last edit: gpz 2024-02-28
Meanwhile i try to find which version works fine (on my machine at least) can you try setting breakpoints around, even in the drive.
Close and reopen the monitor window... i don't know, really.
Later i post here the terminal prompt that vice produce when chis is used.
I tried a bunch of things already, i cant trigger the problem anymore. EVEN when going back to the version before this fix - it all seems to be very random.
I recommend to do a clean compile, ie "make clean" first and then reconfigure - and check if the problem persists. It could be one of those rare cases when a structure changed in some header, and then the buildsystem didnt pick up the depedencies correctly, and some file that should have been rebuild was not - which causes the odd problem.
Oh my gosh.
I have always done the installations from scratch.
The only thing I didn't delete was the config file.
Now I tried running vice by removing it and it seems to work.
I'll do some more testing but that seems to be the problem.
If I use Vice with the default configuration everything works perfectly.
But just enable a 1581 on drive 9 and the bug reappears.
Without drive on device 9 everything works.
please try increasing the size of the chis buffer (in the settings) to something like 100000 and then try again
Setting chis buffer to 100000 seems to fix.
Anyway i asked to test on Windows with Vice 3.7.1 and the problem is the same: setting device 9 as 1581 cause chis malfunctions.
The solution might be to either sync the emulation more often (drives vs main cpu), or at least force a sync when the monitor is entered (which probably is what you'd want anyway in a debug situation).
That said, does it have to be 1581? ie with a 1541 the problem does not occur?
Seems that also a 1541 cause the problem.
it seems the 'culprit' was
https://sourceforge.net/p/vice-emu/code/39502/
but i guess you figured it out yourself.
Yes, that one is the "problem" - it increases the required buffersize (The other problem that was fixed by my cleanup is still mysterious).
In any case - please test some more, and confirm that increasing the buffer size will indeed fix it in all cases.
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
Yeah, the needed buffer size depends on a) the number of CPUs and b) how often they are synced in the emulation (that depends on the type of drive, and perhaps the emulator)
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.
That creates another problem: now we have to keep track of the order of events (which happens automatically when one buffer is used) so we can output the history correctly for more than one CPU at a time
Yeah, CPUs would need to lock some incremented event id to keep the order. That'd be slightly faster than locking a shared buffer for writes, but more complicated as chis would then need to join data from multiple buffers... Deterministic solutions come at a price sadly :)
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?
each history entry is 20 bytes (if i counted correctly) - do the math :) we should probably limit it to some reasonable number (and not crash when it runs out of memory either =D)
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?
the emulation is synced at least once per frame... so ~20k cycles per CPU, which is 10k instructions at most, that means the bug will no more occur if the buffer is ~50k lines big, which makes it 1MB. Seems okish :) (That is, if all CPUs run at 1Mhz)
I committed a hack in r45129 - it will now always allocate a buffer that is (hopefully) large enough, ie one frame worth of instructions, multiplied by 5.
To limit the flooding in the monitor itself when using chis, the number of chis lines is no more directly related to the buffer size, ie a small number will still work (the buffer is still large, it will only show less). This should hopefully also fix the problem that you will sometimes see only a few lines of history.