Activity for VICE
-
Peter Hegt posted a comment on ticket #2218
Thank you very much for the fix build . I'll test it and get back.
-
gpz posted a comment on ticket #2218
I have comitted the fixes, please check r46034 you can extract GEOS prg files with -geosread now it will use the correct length even when the file is only one block (that removes those extra bytes) please test :) please also attach a cvt file made in GEOS (as said, any will do) and i will adjust c1541 accordingly
-
also write the correct number of bytes when the first block of a GEOS file is already the last (which can happen in GEOS PRG files)
-
look up the CBM file type of a GEOS file in the directory before extracting it (it is not limited to USR)
-
that is true - i will have a look at that
-
Any other file will do - we only want to see if it zeroes out the t/s links
-
Yes it boots however, the file is too large, which is incorrect in and of itself, and if the second block is large enough (now it is 1 byte) then it wil overwrite the vectors at 300 and failing the boot.
-
Hi, I have tried to make a geos.cvt using the "Convert 2.5" application in GEOS but unfortunately that does not work, it simply won't do it.
-
PS: after writing the c1541 cvt file the disks boots fine and the icon for the GEOS file is also ok - that also suggests it worked fine
-
OK, so... first of all, your geos.c1541.cvt looks exactly like mine (*) - the difference to the dirmaster produced file is, that dirmaster apparently zeros out the T/S links (both to data and info block) as you said. That should be no problem, since they are recreated on write anyway. (It would be interesting to know what the original convert program does, so we can reproduce that behaviour in c1541 - just in case something relies on it). The extra bytes are something that needs to be investigated...
-
Hi , Thanks for your effort. Yes I am weary of DirMaster (3.1.5) so I double check everything with VICE/c1541 and HxD. (Yes -geosread geos does indeed not work, my bad) I am working on a little project in which I am reverse engineer the GEOS boot loader (file "geos") so I can create the binary from source code. If I success, then I'll make a pull request for github mist64 geos (https://github.com/mist64/geos). I need c1541 in my build script to make a D64 so I need a correct -geoswrite. I have already...
-
Note that you can see the info block in DirMaster with SHIFT+J. The CVT file is basically a cat of a signature block (254 bytes with directory entry + GEOS info) + info block (254 bytes) + the real program.
-
This is my creation geos.build.cvt. There are differences because I have zeroed all garbage. It does boot correctly.
-
geos.c1541.cvt
-
geos.dirmaster.cvt
-
Hi , Thanks for your effort. Yes I am weary of DirMaster (3.1.5) so I double check everything with VICE/c1541 and HxD. (Yes -geosread geos does indeed not work, my bad) I am working on a little project in which I am reverse engineer the GEOS boot loader (file "geos") so I can create the binary from source code. If I success, then I'll make a pull request for github mist64 geos (https://github.com/mist64/geos). I need c1541 in my build script to make a D64 I have already successfully reverse engineered...
-
ok first observation: the file cant be extracted with -geosread, because that explicitly looks for a USR file. using -geosextract it will be extracted in cvt format (but no idea if correctly)
-
could you extract the .cvt file with dirmaster and attach it?
-
Hi gpz, Thank you for your efforts and reply. I will do some more research and get back.
-
err wait. did you actually use c1541 from 3.10? the file "geos" isnt in regular geos format for that matter - its a regular prg binary, and cant be read by -geosread at all. you should get $ c1541 -attach GEOS64.D64 -geosread geos geos.cvt OPENCBM: sucessfully loaded libopencbm.so D64 disk image recognised: GEOS64.D64, 35 tracks. Unit 8 drive 0: D64 disk image attached: GEOS64.D64. ERR = 62, FILE NOT FOUND, 00, 00 cannot read `geos' on unit 8 invalid filename Unit 8 drive 0: D64 disk image detached:...
-
err wait. did you actually use c1541 from 3.10? the file "geos" isnt in regular geos format for that matter - its a regular prg binary, and cant be read by -geosread at all. you should get $ c1541 -attach GEOS64.D64 -geosread geos geos.cvt OPENCBM: sucessfully loaded libopencbm.so D64 disk image recognised: GEOS64.D64, 35 tracks. Unit 8 drive 0: D64 disk image attached: GEOS64.D64. ERR = 62, FILE NOT FOUND, 00, 00 cannot read `geos' on unit 8 invalid filename Unit 8 drive 0: D64 disk image detached:...
-
First rule is: don't trust DirMaster. It has a long history of buggy behaviour too :) Does the file that you wrote work then? that it allocates different sectors isn't a bug :)
-
If you use DirMaster to drag & drop the geos.cvt onto the disk, the result is correct.
-
3.10 (GTK3 3.24.51, GLib 2.86.3, Cairo 1.18.4, Pango 1.56.4) Windows 11 x86_64 (64-bit)
-
c1541 geoswrite incorrect [3.1]
-
Bernhard Übelacker posted a comment on ticket #514
I made a small test with a simple test binary - and unfortunately the --strip-debug did not work as I expected - the backtrace did no longer show function names. In that regard I was after something similar to clang's -gline-tables-only, but it looks like this does not exist for gcc. Thanks for looking into it.
-
We have not considered it so far, because honestly... debugging using gdb on windows is plain impossible (it is so slow its not funny anymore, it takes literally hours for it to even start up). And WINE isn't really a target we are looking at at all :) I'd rather not mess with the bindist scripts, as that stuff is for the binary windows releases (the snapshot builds are just an artefact), and we are happy it works at all (and we don't have a windows maintainer right now).
-
I get also a backtrace with winedbg with wine-11.4: Backtrace: =>0 0x006ffff8a0d011 ID2D1Image_AddRef(This=<internal error>) [/usr/src/packages/BUILD/include/d2d1.h:3254] in d2d1 (0x007fffffa81318) 1 0x006ffff8a0d011 d2d_effect_SetInput+0x21(iface=<register RSI not accessible in this frame>, index=<register RBX not accessible in this frame>, input=<register RDI not accessible in this frame>, invalidate=<internal error>) [/usr/src/packages/BUILD/dlls/d2d1/effect.c:2805] in d2d1 (0x007fffffa81318)...
-
i get a totally different crash :) $ LANG="c" winedbg x64sc.exe MESA-INTEL: warning: Haswell Vulkan support is incomplete MESA-INTEL: warning: Haswell Vulkan support is incomplete 002c:fixme:ver:GetCurrentPackageId (00007FFFFE2FFEF0 0000000000000000): stub 00fc:fixme:wineusb:add_usb_device Interface 1 has 6 alternate settings; using the first one. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled...
-
Wanted to try the network play, but the current Debian package misses the menu entry. The SDL build starts up fine :-) Only the GTK windows build crashes instantly, but that is an issue that needs to be handled at Wine side. Thread 4 "pool-1" received signal SIGSEGV, Segmentation fault. [Switching to LWP 491] 0x00006ffff843d011 in ?? () (gdb) add-symbol-file /opt/wine-devel/lib/wine/x86_64-windows/d2d1.dll 0x6ffff8421000 Reading symbols from /opt/wine-devel/lib/wine/x86_64-windows/d2d1.dll... (gdb)...
-
I don't think this is easily possible (it will require changes in the configure script) Why run VICE in wine though? That sounds.... odd :)
-
Leave minimal debug symbols in windows builds.
-
Please no special case stuff, this must be fixed in the viacore_peek function :) Of course what i mean is: this peek_pra should be called from viacore_peek (it was late...)
-
rice123 posted a comment on ticket #2217
This is the implementation of read_pra() in /src/drive/iecieee/via2d.c: static uint8_t read_pra(via_context_t *via_context, uint16_t addr) { /* GCR data port */ uint8_t byte; drivevia2_context_t *via2p; via2p = (drivevia2_context_t *)(via_context->prv); /* IF: add bus read delay */ via2p->drive->req_ref_cycles = BUS_READ_DELAY; rotation_byte_read(via2p->drive); byte = ((via2p->drive->GCR_read & ~(via_context->via[VIA_DDRA])) | (via_context->via[VIA_PRA] & via_context->via[VIA_DDRA])); #if 0 printf("(%u)%02x",...
-
Please no special case stuff, this must be fixed in the viacore_peek function :) And yes, there were things like this in the CIA peek function too (hopefully no more, but who knows)
-
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...
-
uneducated try to fix build failing with use of undeclared identifier '_NSGetExecutablePath'
-
Roberto Muscedere modified ticket #2121
Error in graphics in C128
-
Well this was a very deep rabbit hole. I thought it was an MMU thing and made a tester, and when I finally pulled my C128 out of storage, the tester still didn't work. It turns out it was an issue with how the data port in x128 CPU worked. This code inserts itself into the C128 reboot process where it copies the colormap before the kernal fully resets. When a soft reset happens, the values of the data port are set to 0, and the "pport.data_read" wasn't updated to reflect the effect of the external...
-
Fix for bug #2121 in x128
-
remove pointless initialization
-
juergen johannes posted a comment on ticket #2150
Thank you very much for the internal explanation. For a "standard" Vice User (German) it is difficult for me to understand some things. Is there a possibility for me to try this too (you may be able to run bcopy with the screen blanked)? Instructions for a simple vice user. Would you make your hack, maybe as a "Special Vice Version" available to try. (I made a small hack on my local VICE copy to demonstrate that it is possible to get bcopy/mcopy to work (with the screen blanked)). Of course, only...
-
radius75 modified a comment on ticket #2069
From what I remember, I noticed a strange relationship between the FD2000 and the native .d2m partition, the Sonic game, and RamLink. If RamLink is disabled, the game cannot be loaded by selecting Fastload in the game. Only CompatibleLoad works for the FD2000. If I run RamLink, the game will load in Fastload mode from the native FD2000 partition. Is this correct and expected behavior? The game manual suggests that you should select Compatible for the CMD drive. = RamLink is only turned on and off,...
-
From what I remember, I noticed a strange relationship between the FD2000 and the native .d2m partition, the Sonic game, and RamLink. If RamLink is disabled, the game cannot be loaded by selecting Fastload in the game. Only CompatibleLoad works for the FD2000. If I run RamLink, the game will load in Fastload mode from the native FD2000 partition. Is this correct and expected behavior? The game manual suggests that you should select Compatible for the CMD drive.
-
Sorry, I'm not really sure what the issue is. I assume it does or doesn't load with some drives in emulation. What does a D2M files have to do with RAMLink?
-
Can't use Mcopy with CMD HD
-
I'm closing this bug as it won't be addressed until the whole underlying CPU architecture of VICE has to change. This won't be happening that soon.
-
MCOPY suffers from the same issues as BCOPY. See: https://sourceforge.net/p/vice-emu/bugs/2150/
-
CMD HD/FD/Foreign Mode
-
Sorry for the delay in getting to this. When using BCOPY and selecting two external devices, the copy process is actually done between the two devices and the main CPU remains mostly idle; it just observes to see when the work is done. So the devices are sending information to each other to perform which ever backup operation that is happening. The issue with VICE is the way it implements the emulation. Mostly due to its legacy architecture (VICE is over 30 years old), which was to emulate as fast...
-
I've attached a smaller testcase. Monitor commands: dev 8: break f35c if (A == $D6) Then autostart smallertestcase.g64 I don't know what a test program for this would look like. The exact GCR byte the drive is reading isn't deterministic, so you can't write a simple reference file expecting 1c01 to always read 0x52 (for example), it's necessary to compare values at specific positions and verify that they're always the same.
-
CPU history shows incorrect values
-
closing this - please make a new ticket if you figure out how to trigger that JSR/JAM problem
-
ewww this is really bad. A smaller testcase (with a minimal test program) would be nice
-
Strobe posted a comment on ticket #2217
The "io" command (which is what you should be using btw) also does this if you do it enough times. btw this only seems to happen to VIA #2 at $1c00 not VIA #1 at $1800...
-
some useful notes can be found in /src/core/viacore.c: /* return value of a register without side effects */ /* FIXME: this is buggy/incomplete */ uint8_t viacore_peek(via_context_t *via_context, uint16_t addr) { addr &= 0xf; switch (addr) { case VIA_PRA: case VIA_PRA_NHS: /* port A, no handshake */ { uint8_t byte; /* WARNING: this pin reads the voltage of the output pins, not the ORA value as the other port. Value read might be different from what is expected due to excessive load. */ #ifdef MYVIA_NEED_LATCHING...
-
Displaying VIA#2 Input Register A causes side effects
-
don't abort 'extract' command on a cyclic file, extract remaining files instead :) fixes #2216
-
SlagDog posted a comment on ticket #2216
Obviously you tested against the patched version, Querino? I DO compile myself and after the recent patch can confirm the issue is resolved. OP out :)
-
Querino posted a comment on ticket #2216
Maybe the OP don't compile himself, i did a quich test. c1541 "Sex Show 8_cycled.d64" -extract sex show eight fucking people 1 Error: trying to extract more data than image can contain (174848), possibly a cyclic T/S chain in file 'fucking people 1'. fucking people 2 fucking people 3 fucking people 5 fucking people 6 fucking people 7 fucking people 8 fucking people 9 fucking people a fucking people b fucking people c fucking people d fucking people e fucking people f fucking people g fucking people...
-
Please test Index: src/c1541.c =================================================================== --- src/c1541.c (Revision 46028) +++ src/c1541.c (Arbeitskopie) @@ -2883,7 +2883,7 @@ disk_image_t *disk_image; unsigned int disk_type; size_t disk_size; - size_t total_written; + size_t file_written; uint8_t *buf, *str; unsigned int channel = 2; char *p00_name = NULL; @@ -2929,7 +2929,7 @@ track = floppy->Dir_Track; sector = floppy->Dir_Sector; - total_written = 0; + file_written = 0; while (1) { int...
-
c1541 should extract all available data properly
-
8K cartridge: ROML unmapped when CPU port $01=$34 (EXROM active, LORAM=HIRAM=0)
-
ERIC NEILSON posted a comment on ticket #424
This was my mistake. I did not know there was a detailed mapping table at https://www.c64-wiki.com/wiki/Bank_Switching. I reviewed it and it looks like that batch of memory is supposed to be unmapped when I poke $01 with 34. I am withdrawing my patch. I am really much better with 6502 Apple II code.
-
rpgcollectors98 posted a comment on ticket #420
ok thanks
-
monitor works just as expected (C:$8011) m 8000 801f >C:8000 e0 9f 2f 80 c3 c2 cd 38 30 6f 20 31 39 38 33 20 ../.CBM80O 1983 >C:8010 41 74 61 72 69 2c 20 49 6e 63 2e 20 41 6c 6c 20 aTARI, iNC. aLL (C:$8020) > 1 34 (C:$8020) m 8000 801f >C:8000 55 00 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 u@....@@@@....@@ >C:8010 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 @@....@@@@....@@ (C:$8020) bank cart (C:$8020) m 8000 801f >C:8000 e0 9f 2f 80 c3 c2 cd 38 30 6f 20 31 39 38 33 20 ../.CBM80O 1983 >C:8010...
-
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".
-
We will include a couple mapping files for common controllers in the next release. Please do the following: use "joyride" for testing, and use one of the available SNES-controller emulations in VICE first map existing (on your controller) buttons 1:1 (dpad to dpad, start to start etc pp) then left analog to joystick then right analog to paddle x/y the "menu key" (on playstation controllers its the PS button) to "pause" action leave other stuff empty this is how the DS3 mapping in the repo is set...
-
is it possible to make a new version, for example gtk3vice 3.11 win64, with the gtk3-joymap-C64SC.vjm file already included in the zip file? Please let me know, thanks
-
is it possible to make a new version, for example gtk3vice 3.11, with the gtk3-joymap-C64SC.vjm file already included in the zip file? Please let me know, thanks
-
s it possible to make a new version, for example gtk3vice 3.11, with the gtk3-joymap-C64SC.vjm file already included in the zip file? Please let me know, thanks
-
Yes, it still works fine for me — no issues
-
before i put it into trunk - would you check if this still works OK with trunk?
-
MacOs fix for USBSID-Pico
-
applied in r46028 - thanks!
-
I'd also like to know the source for this information. And was it verfied on a real C64? Using the good old PLA program (which reads directly from the PLA truth table), it looks like this: For 8k Game mode (note: no ROM mapped): address | CPU R | CPU W | VIC R | $0XXX | RAM . | RAM . | RAM . | $1XXX | RAM . | RAM . | Char . | $2XXX | RAM . | RAM . | RAM . | $3XXX | RAM . | RAM . | RAM . | $4XXX | RAM . | RAM . | RAM . | $5XXX | RAM . | RAM . | RAM . | $6XXX | RAM . | RAM . | RAM . | $7XXX | RAM ....
-
Ingo Korb posted a comment on ticket #424
I'll assume that you mean GAME=1, EXROM=0 (i.e. not Ultimax mode) since you mention RAM at $8000 and there is no RAM in Ultimax mode at that address. Why do you think that this configuration should enable the cartridge ROM when LORAM=0, HIRAM=0? To my knowledge that is not what a correctly-working C64 would do and also contradicts multiple sources about the memory map, e.g.: https://archive.org/details/transactor-magazines-v6-i05/page/n55/mode/2up (oldest known public PLA reverse engineering) https://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c64/pla.txt...
-
8K cartridge: ROML unmapped when CPU port $01=$34 (EXROM active, LORAM=HIRAM=0)
-
MacOs fix for USBSID-Pico, patch by LouD
-
LouD posted a comment on ticket #423
Groundhogday!
-
There, I fixed it ;)
-
Fixed patchfile now I hope?
-
add libusb to macos build
-
MacOs fix for USBSID-Pico
-
Checkpoint prints a wrong cycle id
-
Ziggy created ticket #513
Configure Screenshot Directory
-
Possible bug in Protopad
-
START toggles autofire - and FIRE is the same as pressing SPACE in port 1. So indeed, totally normal :)
-
Possible bug in Protopad
-
.8:0700 20 4B FF JSR $FF4B A:00 X:00 Y:02 SP:45 ..-...ZC 5130723 .8:ff4b 45 9A EOR $9A A:00 X:00 Y:02 SP:43 ..-...ZC 5130729 .8:ff4d 4C 25 EB JMP $EB25 A:03 X:00 Y:02 SP:43 ..-....C 5130732 Thanks for the fix. Btw, I spotted another chis bug earlier where the whole JSR instruction was replaced with a JAM (0x02) in the C64 CPU history: .C:ed23 78 SEI A:28 X:01 Y:00 SP:f9 .V-..I.. 140626587 .C:ed24 02 JAM A:28 X:01 Y:00 SP:f9 .V-..I.. 140626589 .C:ee97 AD 00 DD LDA $DD00 A:28 X:01 Y:00 SP:f7 .V-..I.....
-
try r46026 :)
-
use JSR_FIXUP_MSB also for the drive CPU, should fix #2213
-
fix some ROM names in the 'System Files' section
-
For the records: this happens ONLY on the drive, neither x64 (old CPU core, same as drive) nor x64sc show this
-
CPU history shows incorrect values
-
put the filename passed on the command line into the initial state, else pressing STOP/START immediately after will not work
-
Partial fix committed in r46023, by removing the pointless success on save-as messages from the 3 cases where that was locking up vice. All error cases still to be resolved - listed in my 2026-03-04 comment above ( https://sourceforge.net/p/vice-emu/bugs/2205/#a611 ).
-
Partial fix for bug 2205, remove pointless "everything worked" messages from the three Save-As widgets that were locking up the GTK3-Vice GUI on Windows. A successful Save-As now no longer locks up Vice. Error case(s) still to be resolved, see ticket.
-
blind fix: disable POT mapping for (digital) HATs
-
add some comments, fix petscii data in keyboard command
1 >
