Activity for Olaf Seibert
-
Olaf Seibert posted a comment on ticket #2217
So viacore_peek() calls via_context->read_pra(...). Actually in the CIA core the same problem could occur, since ciacore_peek() calls ciacore_read() (which calls cia_context->read_ciapa(...)) for the port registers, claiming that this has no side effects. So I guess that the VIA is alone in having potential side effects if the port values are read? First of all it sounds suspect that just reading a port value has a side effect. If it happens inside the 1541, perhaps this is a case where the port...
-
The report mentions the Vice monitor. Could it be that the monitor has a bug in this area, while the emulation is fine? (I expect the emulation to be fine) I'm wondering about this because the "banking" ideas of the monitor are in some respects a bit, eh, complicated, and maybe a bug could slip in here. Some things just look different in the monitor, such as an "empty bus".
-
VIA timer does not wrap to $ffff
-
Closing since it seems to be fixed :)
-
r45978 contains essentially the change as described above, plus a bunch of changed or added comments that (hopefully) explain why the change is correct.
-
Fix bug 2203, caused by changing the timing of viacore_t1_zero_alarm()
-
When I compare versions r41808 with r41995, it looks like I have moved the "timer 1 zero alarm" 1 cycle earlier: In the case case VIA_T1CH: /* Write timer A high */, it was via_context->tai = rclk + via_context->tal + 2; and became via_context->tai = rclk+1 + via_context->tal ; (tai is now called t1zero) I could move it 1 later again but this would affect other things that happen in the viacore_t1_zero_alarm() function, such as setting the T1 flag in the Interrupt Flag Register and adjusting the...
-
When I compare versions r41808 with r41995, it looks like I have moved the "timer 1 zero alarm" 1 cycle earlier: In the case case VIA_T1CH: /* Write timer A high */, it was via_context->tai = rclk + via_context->tal + 2; and became via_context->tai = rclk+1 + via_context->tal ; (tai is now called t1zero) I could move it 1 later again but this would affect other things that happen in the viacore_t1_zero_alarm() function, such as setting the T1 flag in the Interrupt Flag Register and adjusting the...
-
@querino: interesting. I have my eye on an optimization that can be disabled and which then seems to fix this issue, but that was already present before the change of r41995. The names have been changed though. In that change, it changed via_context->tau += via_context->tal + 2; to via_context->tau += full_cycle; which should be the same thing. In current versions, tau has been renamed to t1reload. So you can try commenting out the line which says via_context->t1reload += full_cycle; which would...
-
The VIA core code is very old and from the time that every emulator cycle had to be saved where possible. So it doesn't keep track of the value of Timer 1 all the time. It calculates it, when needed, from the difference between current clock cycle, and the next time that T1 is supposed to be reloaded from the latch (this value is called t1reload). The calculation, in the function viacore_t1() reads as follows: return via_context->t1reload - rclk - FULL_CYCLE_2; (there is another calculation for when...
-
The VIA core code is very old and from the time that every emulator cycle had to be saved where possible. So it doesn't keep track of the value of Timer 1 all the time. It calculates it, when needed, from the difference between current clock cycle, and the next time that T1 is supposed to be reloaded from the latch (this value is called t1reload). The calculation, in the function viacore_t1() reads as follows: return via_context->t1reload - rclk - FULL_CYCLE_2; (there is another calculation for when...
-
Thanks! I applied it in revision 45958.
-
Fix options to use specific CIA versions in Denise.
-
I committed a mix of your patch and mine in revision 45957.
-
CIA SDR IRC fix for "old" CIAs.
-
Heh, I didn't see this until after I had already written more or less the same thing in another place in the thread...
-
(1) I'm pretty sure that when I made the strange_extra_sdr_flags() function, I also tested both old and new CIAs. After all, the code makes a difference between them, so it would be weird if I hadn't. (2) On the other hand, the cia?-sdr-icr-* tests now appear to pass equally on real old and new CIAs. So in a hunch, I changed strange_extra_sdr_flags() to make no difference between old and new, and always use the code for the new type. That made all those tests pass on VICE with both types of CIA....
-
Add patch from Dag Lem, from bug #1219.
-
Add test program supplied by Dag Lem in bug #1219.
-
Wow, that's another annoying "feature" of the CIA! Kudos that you found it, and even a patch for it. Fortunately it fits easily in the current code structure... I would dread another restructure. (I had already in mind that if a new restructure is ever needed, it would go in the direction of simply having one alarm that triggers every cycle and does all the state machine handing, instead of the current multiple ones that each do a part of it, but which don't have a defined order in which they trigger....
-
Segfault in BSD Joystic Code
-
I made a trivial change to the patch and I applied it to trunk. Thanks for finding this bug an fixing it!
-
Avoid use-after-free.
-
Looks good to me. Even though I haven't seen the crash, I can see how this goes wrong without the patch. I'm including it in the pkgsrc package.
-
So you are saying that in gentoo, PREFIX=/usr/games, but you want the desktop files in /usr ? In that case, maybe gentoo is a bit weird, but I suppose it can be managed. Suppose you make a new variable DESKTOPPREFIX=/usr and use this instead of every PREFIX that is currently used for desktop or icon files. Note that PREFIX is not meant for staged installs. That is what DESTDIR is for (which is empty for direct installs).
-
If it is like on the PET, then there is logic on the board to pass the high bit of the byte that was fetched from the screen memory, and feed it into a XOR that inverts the pixels of the character before it is sent to the screen. However the implementation in VICE pretends that there is actually a larger character ROM present, with the inverted chars in the second half. I think the changes that gpz made in r34561 seem to work for both cases. I tested this: Start with gtk3-xcbm2 -model 710 --chargen...
-
If it is like on the PET, then there is logic on the board to pass the high bit of the byte that was fetched from the screen memory, and feed it into a XOR that inverts the pixels of the character before it is sent to the screen. However the implementation in VICE pretends that there is actually a larger character ROM present, with the inverted chars in the second half. I think the changes that gpz made in r34561 seem to work for both cases. I tested this: Start with gtk3-xcbm2 -model 710 --chargen...
-
If it is like on the PET, then there is logic on the board to pass the high bit of the byte that was fetched from the screen memory, and feed it into a XOR that inverts the pixels of the character before it is sent to the screen. However the implementation in VICE pretends that there is actually a larger character ROM present, with the inverted chars in the second half. I think the changes that gpz made in r34561 seem to work for both cases. I tested this: Start with gtk3-xcbm2 -model 710 --chargen...
-
If it is like on the PET, then there is logic on the board to pass the high bit of the byte that was fetched from the screen memory, and feed it into a XOR that inverts the pixels of the character before it is sent to the screen. However the implementation in VICE pretends that there is actually a larger character ROM present, with the inverted chars in the second half. I think the changes that gpz made in r34561 seem to work for both cases. I tested this: Start with gtk3-xcbm2 -model 710 --chargen...
-
I think this one can be explained by the structure of DO_INTERRUPT() (yes I keep coming back to it) which reads in part: if (ik & (IK_MONITOR | IK_DMA)) { \ if (ik & IK_MONITOR) { \ if (monitor_mask[CALLER] & (MI_STEP)) { \ EXPORT_REGISTERS(); \ monitor_check_icount((uint16_t)reg_pc); \ IMPORT_REGISTERS(); \ } \ if (monitor_mask[CALLER] & (MI_BREAK)) { \ EXPORT_REGISTERS(); \ if (monitor_check_breakpoints(CALLER, (uint16_t)reg_pc)) { \ monitor_startup(CALLER); \ } \ IMPORT_REGISTERS(); \ } \ if (monitor_mask[CALLER]...
-
Checkpoint on ADDR does not trigger after G ADDR
-
I just committed the changes as above (minus the WTF comment).
-
monitor: fix bug 2177
-
I am using the same silly program but with a breakpoint on 1001. You can see that each instruction is shown twice because one of the two times shows the Stop on exec (breakpoint) and the other doesn't (single step). Also, the clock value on the right shows duplicates. But this patch doesn't make this worse or better, so I would say it is a separate bug. (C:$1004) a 1000 nop .1001 jmp 1001 .1004 (C:$1004) break 1001 BREAK: 1 C:$1001 (Stop on exec) (C:$1004) g 1000 #1 (Stop on exec 1001) 0/$000, 4/$04...
-
Ok sounds like I should commit it. I will do that soon unless there are issues. Things to test could be maybe to single-step to an instruction which has a breakpoint too. That probably didn't work quite right before and likely it still doesn't. (Each of them seems to be reported separately so you stop twice before the same instruction) That's also because those are different places in the DO_INTERRUPT macro to enter the monitor. Would the RESET command need mon_exit_change_flow instead of mon_exit_continue...
-
With the above comments in mind, here is a patch. I put some check for a breakpoint when exiting the monitor. The handling of the variable exit_mon was a bit ugly here and there. It wasn't treated like a normal boolean but weird things were done with the value 2. I cleaned that up by making it an enum. That makes the diff larger than just the part with the "real functionality". There was one place in the main loop in monitor_startup() where seemingly the monitor is supposed to exit when it isn't...
-
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);...
-
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
-
r45801 changed screenshots slightly, so adjust them
-
This was missed in r45781 Rename (virtual/trap) device related settings (bug 2162)
-
80x42 text mode does not display properly.
-
This is hopefully fixed in revision 45801.
-
Fix bug 2175: CRTC 80x42 text mode does not display properly.
-
There are at least 2 issues in play here. The screen size is set (using CRTC_REG_VTOTAL and CRTC_REG_VTOTALADJ) to 40 text lines plus 20 scan lines. The vertical sync is however set at text line 43. That text line is however never reached. Some CRTC models use the same counter to count the scan lines in a text line, and also the "vertical adjust" lines when VTOTAL text lines have been shown. The src/raster/* code is just weird and overly complex and nobody understands it. The crtc code probably works...
-
80x42 text mode does not display properly.
-
Virtual floppy device support missing in xpet 3.9
-
Let tabs be spaces...
-
I finally committed this just now.
-
Rename (virtual/trap) device related settings (bug 2162)
-
Aargh another file missing from my changelist. I regenerated the diff with attach.c included. (the annoying bit is that I have some other changed files around as well, so I can't just blindly commit everything -- and I must find the bug report again that those other changes were related to, I think we probably do want them in the end) I will delay the committing for 48 hours then.
-
Aargh another file missing from my changelist. I regenerated the diff with attach.c included. (the annoying bit is that I have some other changed files around as well, so I can't just blindly commit everything -- and I must find the bug report again that those other changes were related to, I think we probably do want them in the end)
-
Okay, I added this file to my svn changelist: Index: src/iecbus.h =================================================================== --- src/iecbus.h (revision 45779) +++ src/iecbus.h (working copy) @@ -37,7 +37,7 @@ #define IECBUS_STATUS_TRUEDRIVE 0 #define IECBUS_STATUS_DRIVETYPE 1 #define IECBUS_STATUS_IECDEVICE 2 -#define IECBUS_STATUS_VIRTUALDEVICES 3 +#define IECBUS_STATUS_TRAPDEVICE 3 /*! *
-
Okay, nobody told me anymore there is still something missing, so maybe this is finally the case. I propose that I merge this in 48 hours, monday evening some time after 19.00 CET, unless I hear that there are still some changes needed.
-
ah yes, traps.c needed some more changes for -/+trapdevice. But -/+busdevice is already in the new file src/serial/iec-ieee488-shared.c. I was away for some days, so this next version doesn't have further SDL settings changes. But I did rename machine_bus_status_virtualdevices_set to machine_bus_status_trapdevices_set and IECBUS_STATUS_VIRTUALDEVICES to IECBUS_STATUS_TRAPDEVICE which adds some more changes.
-
Yes you are right there are even more files to change... While I was in the SDL code for the settings menus, I noticed that there doesn't seem to be anything to toggle the BusDevice settings for drives. Only for printers. (and then TrapDevice and BusDevice are even missing for PETs) I suppose I can add that, if I find out how to fit it in (there are numbered arrays that presumably have some meaning and the additional entries would go in the middle somewhere)
-
Yes you are right there are even more files to change... While I was in the SDL code for the settings menus, I noticed that there doesn't seem to be anything to toggle the BusDevice settings for drives. Only for printers. I suppose I can add that, if I find out how to fit it in (there are numbered arrays that presumably have some meaning and the additional entries would go in the middle somewhere)
-
Okay, next iteration patch is attached, with the names as in the previous comments. It changes even more files, since printers and tape are also affected. And I also edited the documentation.
-
I think I like that. How would we translate that into option names? Something like -virtualdev4 -> -trapdevice4 and resource TrapDevice4 -iecdevice8 -> -busdevice8 and BusDevice8 -device8 <Type> -> -devicebackend8 <Type> and FileSystemDevice8 (that is the current name and seems fine) or with dev instead of device (currently it is mixed, so either case would be an improvement)
-
Oh, and apart from doubling the disk drives it would mean doubling the printers too!
-
"why not call them IEC/IEE-488 devices?" In a way that would be best, but to have a / in a command line option such as --iec/ieee-488-device8 would be a bit unconventional... and the option name would be getting rather long. For the resource names, which usually are only mentioned internally in VICE and in the saved settings file, the length is less of a problem but the / would be. It would certainly be possible to keep the command line options named --iecdevice8 if we want to keep the length down...
-
I have been working on this a bit. The thing that makes this harder is that for emus that have an IEEE-488 bus (so PET, CBM2, but also C64 and VIC-20 if you add their IEEE-488 cartridge) the functionality of the file system device is enabled by the resources / command line options for "virtual devices" instead of "IEEE-488 devices". "Virtual devices" are based on kernal traps (changing code in the kernel so that VICE can recognize when the IEC bus is accessed). That exists for the serial IEC bus,...
-
Indeed it is. Behind the scenes we're trying to work out how to organize and name the settings so that they make sense (such for machines with iec or ieee bus, or both (c64 with ieee cartridge)).... this turns out to be harder than I thought at first...
-
It seem the GUI has been reorganized but the PET part has been forgotten. But as far as I can see, the functionality is there: xpet -virtualdev8 +drive8truedrive uses the current directory as a file system device: *** commodore basic 4.0 *** 31743 bytes free ready. catalog 1 ". " #8:0 3 "." dir 55 ".." dir 1 "doit" prg 124 "sample.bin" prg 689 "sample.d64" prg 125 "sample.prg" prg 5 "sample.s" prg 65535 blocks free. ready.
-
Tabs to spaces...
-
Small SuperPET banking corrections.
-
Clean up some video address mask nonsense.
-
PET, HRE: small fix: we need a vertical screen size of 256 pixels, otherwise the bottom few scan lines get cut off in HRE mode.
-
Add {} so that the declaration is not directly following a case label.
-
Should be fixed in revision 45702 and appear soon at https://github.com/VICE-Team/svn-mirror/releases Please test :) Cause: file name parsing is now mostly done with cbmdos_command_parse_plus(). However this function worked slightly different when parsing ,L in a file spec. Fix: copy the logic from cbmdos_command_parse() to handle this. There seems to be still one place where the older function cbmdos_command_parse() is used. @oldwoman37 is that intentional?
-
Should be fixed in revision 45702 and appear soon at https://github.com/VICE-Team/svn-mirror/releases Cause: file name parsing is now mostly done with cbmdos_command_parse_plus(). However this function worked slightly different when parsing ,L in a file spec. Fix: copy the logic from cbmdos_command_parse() to handle this. There seems to be still one place where the older function cbmdos_command_parse() is used. @oldwoman37 is that intentional?
-
Fix bug 2146: c1541 can't read REL files
-
The manual says that read file,l out should work, and it used to work (I wrote that part of the manual). I will find out what broke.
-
c1541 can't read REL files
-
The manual says that read file,l out and it used to work (I wrote that part of the manual). I will find out what broke.
-
PET 8296 $Axxxx video ram treatment.
-
#include <termios.h> missing in Common/x3270if.c
-
c1541: fix segfault when not attaching disk image.
-
Fix some typos in comments.
-
On the 8296 we do not (invert the screen by clearing MA12).
-
And another one...
-
Forgot to include in commit...
-
Some TABs crept in...
-
Add tape port dongle to help WordCraft (PET) work.
-
Don't use my internal build name in the Makefile.
-
Add a test program for unconnected memory space in PETs.
-
Re-fix access to empty memory space.
-
The way that the caps lock key is handled by various combinations of keyboard / operating system / GUI libraries can be a bit weird. One common way of handling it is as follows. the first time you press and release caps lock, the program gets to see only a PRESS event. This would correspond to a key which has a physical lock, which locks the key in the pressed position. the next time you press and release caps lock, the program gets to see only a RELEASE event. Now the key is unlocked and no longer...
-
And the last time I made any changes for unmapped addresses in the PET, I must have been tricked by the Vice monitor which doesn't show it like the CPU sees...
-
I think I finally understand where that high address byte is coming from! This is because with a LOAD instruction, the last successful read on the bus was the high byte of the address. Example: LDA $9000 reads AD 00 90 as instruction bytes and then from $9000. Even LDA ($12),Y reads B1 12 as instruction bytes, but then 00 90 from the zero page, then from $9000. The only exception is when there is indexing with a page crossing. Then there is a dummy read from $90xx before the real read of $91xx. In...
-
yes the PET also reads the high byte of the address from empty space. I never researched deep enough to know why. And I never heard that it would behave differently for indexed addressing modes... I even found a test program from Commodore that depends on reading $E8 from $E800: r45467 | rhialto | 2025-01-28 21:14:43 +0100 (Tue, 28 Jan 2025) | 15 lines Also return empty space on E80x. I found a test program that cares about this: 8032.mem.prg from https://www.zimmers.net/anonftp/pub/cbm/pet/utilities/...
-
yes the PET also reads the high byte of the address from empty space. I never researched deep enough to know why. And I never heard that it would behave differently for indexed addressing modes...
-
fsimage_read_dxx_image() for DISK_IMAGE_TYPE_D80/D82 got its disk ID bytes from the wrong place.
-
That sounds promising. For things like pkgsrc, I am kind of assuming that if somebody is running a desktop environment built to $PREFIX, it will search for desktop files and everything else in $PREFIX/...whatever. "Assuming" because I just run ctwm and not a "desktop environment" at all.
-
Yes your understanding of $(DESTDIR) is correct. But I would use --dir=$(DESTDIR)$(PREFIX)/share/applications instead of --dir=$(DESTDIR)/usr/share/applications, so that the value from configure --prefix=/usr/local (or whatever directory) is used. (there is no / needed between the two variables, because $(PREFIX) always starts with a /, and also because$(DESTDIR) can be empty.) In the second part, rm -f $(DESTDIR)/share/applications/x64{,dtv,sc}.desktop ;\ etc, the /usr or $(PREFIX) got lost com...
-
For inclusion in pkgsrc I had already some patches to install the gtk3 desktop files properly in the staging directory. Essentially it uses --mode system to get them to the right place (the place where a privileged install would put them even though the install is done as a mere user. Install .desktop files in the system location instead of the (fake) home directory. --- src/arch/gtk3/data/unix/Makefile.in.orig 2023-12-24 17:42:17.000000000 +0000 +++ src/arch/gtk3/data/unix/Makefile.in @@ -732,7...
-
Another case of PET empty space reading.
1 >
