Activity for Daniel Kahlin
-
Daniel Kahlin created ticket #2063
monitor "bt" does not work correctly on non-"dev c:"
-
There was a rewrite of the return value types. The actual symptom reporter here remains however.
-
How do you suggest the name to be display should be derived?
-
this already exists as "h 8000 a000 8d xx 8x"
-
I think this broke mem init when having a default attached cartridge. 1: Start with x64sc -default 2: attach a RetroReplay cartridge and set as default 3: save config 4: close x64sc 5: restart x64sc Memory now contains a pattern that doesn't respect the configured RAM Reset Pattern.
-
Seems to be intialized now. Not sure if the contents are correct for such a 4-bit SRAM, but it is not retaining what was there before power cycle: >C:d800 f4 ff f1 fb f0 fb f3 ff f8 fb f0 ff f8 f5 f3 fc ................ >C:d810 f1 ff f1 fa f9 ff f0 fd f0 fe f0 ff f0 fe f0 ff ................ >C:d820 f4 fe f1 f9 f0 f7 f0 ff f2 fb f1 fd f0 ff f0 fd ................ >C:d830 f4 fd f8 fb f0 f7 f0 f7 f8 fe f1 ff f0 ff f0 fe ................ >C:d840 f4 ff f0 ff f4 ff f6 fe f2 ff f0 ff f0 fe f2 fb ...................
-
Powercycling does not initialize color ram.
-
Tested. Seems to work correcly, thanks!
-
I see, now that I know of it I will probably be turning off that option to make reset behave more like x. I can confirm that a sole g does what you say though. I wouldn't have expected that. The way I perceive g is that it forces a state on the machine, rather than smoothly continuing.
-
I see, know that I know of it I will probably be turning off that option to make reset behave mote like x. I can confirm that a sole g does what you say though. I wouldn't have expected that. The way I perceive g is that it forces a state on the machine, rather than smoothly continuing.
-
I'm so used to use x to continue execution so I have no clue how to do that in another way keeping the monitor open. If there is a way, great. For me personally, I want it to close.
-
Ok, makes sense but then I'm wondering why the window closes when doing x?
-
empty print.dump produced on running vice
-
There is a warning when using an older configuration file, but if it is known that the settings are compatible, then settings can be manually resaved and then the configuration file will be marked as current. Automatically converting older incompatible settings is not trivial to maintain, but someone involved with this part needs to reflect on that. Maybe there could be some written rules what is compatible or not. Not sure.
-
I guess this makes sense on Windows or if started via icon-click on other OSes. When started from the command line the current behaviour seems reasonable, i.e default to the current directory when started. IMO any change here would have to be done as an option.
-
I can confirm this happens on Ubuntu 20.04 r45156 as well. Not sure what "Keep monitor open" is supposed to do. I never noticed the setting.
-
Starting vice with x64sc -default -remotemonitor -remotemonitoraddress ip4://127.0.0.1:6510 and then doing echo -en 'help\n\x03\n' | nc localhost 6510 followed by a manual ctrl-C seems to trigger the condition in vice_network_send().
-
src/monitor/monitor_network.c: monitor_network_transmit() casts this back from int to size_t again, not sure where it ends up.
-
incorrect retval type used for socket API resulting in internal error
-
fix confirmed, good work!
-
Warp mode selection in the monitor always toggles.
-
Yes, but we are still finding stuff out + freeze needs to be possible in the test bench.
-
confirmed working, good work!
-
Use a more distinguishable symbol for combined write through and non 0x01 switchable.
-
well, I just encountered it while debugging this: https://sourceforge.net/p/vice-emu/bugs/2011/ so I reported it for completeness. This part of attaching is really confusing from a user perspective, unless perhaps when you know a lot about how it works internally. I only use .crt's normally.
-
Yes, but if I put on my "user hat" I feel that I, among others, have a bunch of Action Replay variants, an Atomic Power, and a Retro Replay in the drop down, but I struggling to find my Nordic Replay. If it won't be a separate entry, then perhaps the variation for a cart should be selectable separately in that dialogue?
-
Nordic Replay: incorrect behaviour of $01 in mode $22
-
Attaching an AR or AP cart .bin with incorrect size "silently" fails
-
Missing option to manually attach Nordic Replay cartridge using .bin
-
allow selecting meld for diffs
-
Attaching an RR/NR cart sometimes doesn't respect RR vs NR
-
Updated binaries to reflect the current r06 state.
-
updated documentation.
-
got rid of trailing white space.
-
add selected de01 to default save name
-
Cleaned up prefill.
-
refactored dump file reading for compatibility.
-
cosmetic tweak
-
added presentation of write through and 0x01 switchability.
-
cleaned up header
-
color output according to the switchable and writethrough attributes.
-
detect if write through to c64 ram happens.
-
detect if switchable by 0x01
-
prepared for write through detection.
-
refactored
-
refactored
-
cleaned up tagging
-
refactored raw output, added legend based on selection.
-
added support for raw hex output
-
refactored, added support for command line arguments.
-
added guard against unsupported file format.
-
got rid of trailing white space.
-
I feel copying utf-8 is a bit weird when it's not standard utf-8 characters. The font used isn't available system wide on my system (Ubuntu 20.04LTS) either.
-
I feel copying utf-8 is a bit weird when it's not standard utf-8 characters. The font used isn't available system wide on my system (Ubuntu 20.04LTS).
-
I've tested this now. It does work if I do ctrl-C in the monitor, then ctrl-Y in emacs. It does not however work when marking the text in the monitor and using middle-mouse pasting. Then the raw unicode is pasted.
-
Great, I can confirm it is working!
-
I see. This is kind of a regression if you use the monitor to analyze snippets of code which you paste into some text file for documentation. If https://sourceforge.net/p/vice-emu/bugs/2008/ was to be fixed/implemented, a workaround for this would be to switch font to the previous non-CBM default when doing such copy/paste work.
-
Not sure which abstractions that are used, here. I would have thought that it would be possible to see in a font if a particular character exists? Not ideal but, couldn't we otherwise just hinge this on that "C64 Pro Mono Regular" is the font used as CBM font and disable the mapping if another font is selected? EDIT: also note that it seems to pick up (badly formatted) CBM font characters anyway. Is that cached from the previously selected font perhaps?
-
I can confirm this is working, thanks!
-
Not sure which abstractions that are used, here. I would have thought that it would be possible to see in a font if a particular character exists? Not ideal but, couldn't we otherwise just hinge this on that "C64 Pro Mono Regular" is the font used as CBM font and disable the mapping if another font is selected?
-
Monitor does not fully respect font selection
-
Monitor does not fully respect font selection
-
Cut and paste from monitor shows unexpected characters
-
Remote monitor 'I' and 'M' unexpected char format
-
WiC64 code requires "too new" libcurl version.
-
Apparently you manually have to select that the cable should be connected to the userport as well. This is done in Settings/Userport devices dialog. If the cable is both enabled in the Settings/Drive dialog and the Settings/Userport devices dialog, then it works. This is easy to miss, so either it should be made automatic some how or at least there should be some warning/note in the GUI reminding you to do it.
-
Parallel cable emulation seems to be broken.
-
for completeness... <rsarson>: i just compiled & tested v3.7.1 from the tar. the intro does, indeed, show. flash.u2 also works. apologies, again, for the confusion ...so it appears r43912 is the sole culprit.
-
Very good, much less confusing!
-
This was presumably introduced with r43912. Resolved by r44426. Note that this was 2023-05-28 though, so it doesn't fully explain what rsarson is seeing with vice 3.7.
-
This was presumably introduced with r43912. Resolved by 44426. Note that this was 2023-05-28 though, so it doesn't fully explain what rsarson is seeing with vice 3.7.
-
rsarson initially reported this on #vice-dev and, it does not work in vice 3.7 for him.
-
x64dtv no longer gets the kernal/basic/charrom from the flash image like it should.
-
x64dtv no longer gets the kernal/basic/charrom from the flash image like it should.
-
confusing error message if rom file points to a directory, not a file.
-
So unless a there is a way to reproduce this, I guess there is nothing to fix?
-
which hardware was it tested on, i.e which 1541 variant? Also, I started rpm.prg in x64sc and I get no indication of faults, what do you mean the bug is?
-
which hardware was it tested on, i.e which 1541 variant?
-
The easiest way to check this is if you write a test program that writes the pattern to disk, then reads then pattern back and displays what it read. You might run into problems with the trailing sync when reading on a 1541. If so you could consider making the trailing part something else than $ff, perhaps $fe. Note that vice is aiming to replicate the behavior of an actual 1541 so only tests on the real hardware is relevant here.
-
There could be a delay before the data is written out such that it gets cut off when you turn off write mode. What does this do on a real 1541?
-
There could be a delay before the data is written out, such that it gets cut off when you turn of write mode. What does this do on a real 1541?
-
Good point about the "Reset" button not being standard, but that is what actually is implemented now, albeit with obfuscated naming, i.e "Soft reset". If we want to sort this out in a better way then I guess the soft reset should be optional in some way. Note that reset buttons people use are commonly fitted on freezer carts they have plugged in. These may not strictly be equivalent to pulling the RESET line low, but most are I guess. In this sense it would be logical to group it with the freeze...
-
Rename reset options to clarify their function
-
I've tested a bit and it seems to be working. l is always clean like expected. ldb always sets $ae/af and $2d/2e to the end address regardless of load address. It also sets $2b/2c to the load address which is a bit unexpected, but ok in my view.
-
how about loadbas/ ldb ? A bit contrived perhaps, but it shouldn't be the go to command if not needed.
-
how about 'loadbas' / 'ldb' ? A bit contrived perhaps, but it shouldn't be the go to command if not needed.
-
I think at least the bug when using overridden load address should be fixed here. The other behaviour might be acceptable if documented, and an alternate way to load without it is provided.
-
Seems to work now, good work!
-
Traps fail to be installed when switching C64C PAL to C64C NTSC.
-
That is a great idea!
-
So these images show the errors? I cannot see those here, but the alignment is random in the Formatted.g64 as expected. Track 7 is interesting as it begins with a data block. The header (t=7/s=10) is the last thing on the track. Try scanning with a native program to find a failing image.
-
Could you attach the program binary please? Also, you state x64. Do you mean that, or x64sc?
-
I've done a little testing here and cannot reproduce this problem. What I can see though is that when you create an empty .g64 in the dialog, it will create an idealized image that starts each track with sector 0 of that track. Now the 1541 does not have an index sensor so when doing a format on an actual 1541 the track start, i.e placement of sector 0, will be random. You are seeing exactly one error per track. My hypothesis is that this is the track wrapping point, and that the analysis tool of...
-
Interesting, could you post the corresponding .g64's?
-
monitor command to "sync" the current disk-image.
-
Doing load from monitor magically sets basic pointers (even if load address is overridden).
1 >