Activity for gpz
-
gpz committed [r46060] on Code
libsdl-image1.2 might work better
-
update download-artifact@v4 -> download-artifact@v8 and upload-artifact@v4 -> upload-artifact@v6
-
update checkout@v4 -> checkout@v6
-
update github-script@v7 -> github-script@v8
-
use apt upgrade -y
-
perhaps we should use ubuntu-latest at all places
-
apt upgrade perhaps?
-
lets try if we only need the updated regular package
-
apparently the updated ubuntu24.04LTS package is name libflac12t64, lets try this
-
libflac8 -> libflac12 (as in Ubuntu 24.04LTS)
-
output a log message when a disk image was attached
-
some rework of the joystick mapping in the SDL UI. Buttons/Mappings are now always shown completely and the naming does not change per selected controller, which made it really annoying to create a complete mapping (sorry Blacky :)). Fixed Paddles, added 'paddles from controller' option, added 'load/save mapping' items.
-
well that is the same file as before ;)
-
So? Are you going to provide such file?
-
gamepad mapping
-
implemented in trunk
-
Use XBox/PS4 controller as multibutton joystick
-
implemented in trunk
-
Paddle Controller Support in WinVICE64...?
-
mapping analog axes to paddles can be done in trunk now
-
Map any emulator function to controller buttons
-
implemented in trunk
-
Only one fire on multiple button joystick
-
this can be done in trunk now
-
Add support for Paddles and other input devices
-
mapping paddles to analog axes works now in trunk, for both GTK and SDL
-
Would the goal of the generic API be specifically to add monitor support for accessing the memory on all different types of cartridges? It should be able to cover all cartridge and internal expansions, on all emulated machines. It should support all kinds of monitor commands and features (see eg the "condition" command), and follow the same design pattern as with the other callbacks for cartridge things, so when a new kind of cartridge is added, only the respective hooks need to be implemented and...
-
Would the goal of the generic API be specifically to add monitor support for accessing the memory on all different types of cartridges? It should be able to cover all cartridge and internal expansions, on all emulated machines. It should support all kinds of monitor commands and features (see eg the "condition" command), and follow the same design pattern as with the other callbacks for cartridge things, so when a new kind of cartridge is added, only the respective hooks need to be implemented and...
-
Unfortunately this doesn't follow the idea expressed in the comment of the future request - it is quite REU specific. We really want some kind of generic API that will work with other (all) cartridges, so we dont end up with dozens of special cases like this
-
put direction hint into signal names, remove unused textfield, fix editing mapped signals > 0x40
-
write controller, OS and port -info into the mapping file
-
c1541 geoswrite incorrect [3.1]
-
Cool, thanks! closing then :)
-
better handling of files with windows-like CRLF
-
ooops. copypaste bug, fixed in r46043
-
fix copy/paste bug :)
-
Ok that was trivial, r46042 uses ascii names for geosextract :) Please test some more and report if all is fine now, so we can close this :) cheers!
-
for geosextract, don't convert destination filename (it is already ascii)
-
r46041 adds the geoslist command. will have a look at geosextract now - what else?
-
add 'geoslist' command
-
So is everything working ok? :) Then how do we proceed with the upperlowercase inconsistencies? There are basically two ways to fix it: change geosread/delete to accept filenames like printed by the -list function. Basically requiring to use "petscii" for the filenames, similar to how you'll have to do when working with them via plain CBM DOS or: change geosextract to use "ascii" filenames, which then equals more the way filenames are represented in GEOS itself. I somewhat lean to the first (as that...
-
In r46040 i have added the "geosdelete" command. For now it needs the same uppercase/lowercase swapping as the other geos commands.
-
add 'geosdelete' command to delete GEOS files
-
I think i know why "delete" does not work correctly - it requires the filename in actual petscii. That means an extra "geosdelete" function is needed. At this point the question is, how do we want filenames to work for GEOS files... i find it a bit odd myself that geosread/geoswrite will require to "reverse case" the filenames (really unintuitive), and would prefer to be able to use them like they are shown by the -list function (ie in the directory)
-
Please try r46039 - configure extracts correctly now with geosread (again only that one was changed)
-
don't output first VLIR record twice
-
Have you configured GOES for REU or something? The content looks different to what i expected at least :) edit: oh it seems the VLIR records are in a different order in the geosread file. but WHY
-
Have you configured GOES for REU or something? The content looks different to what i expected at least :)
-
damn, configure note to self: dont extract this d64 in the vice dir, it produces interesting errors on next attempt to compile seems that configure extracted with geosread is already very different to the convert file. damn :)
-
damn, configure note to self: dont extract this d64 in the vice dir, it produces interesting errors on next attempt to compile :)
-
could you try extracting the new disk, and then compare the result with the first set of files? also... i am not into GEOS enough for this, but isnt there still some copy protection lingering around, which might rely on the disk layout?
-
for delete i think you'll have to append ,u for it to work with USR files (just like on a CBM drive). Not sure why you'd get no output at all though when it fails.... will investigate
-
Sooo... yeah the difference in the data blocks is just unused garbage again. Try r46038 - the extracted font looks fine to me now (again, please check other files - only geosread was changed this time)
-
when reading the record block of a GEOS file, scan all 128 possible T/S offsets for valid links.
-
Also in the data blocks? that sounds... weird. wow
-
Seems you forgot the file, could you attach it? (Perhaps also one extracted with dirmaster - just in case) Wonder whats different with fonts
-
USBSID-Pico not connected error log
-
applied in r46037 - thanks!
-
suppress USBSID-Pico error message at startup, fixes #2219. patch by Loud
-
It is related to https://github.com/LouDnl/USBSID-Pico The message is harmless however (but you are right, it shouldn't be there)
-
Checkpoint prints a wrong cycle id
-
OK i misread that - you were indeed talking about an extra function in each implementation. I am not sure if that is a good idea - or even necessary. It would be these: $ grep -rn "read_pra =" src src/vic20/vic20via1.c:303: via->read_pra = read_pra; src/vic20/vic20via2.c:229: via->read_pra = read_pra; src/vic20/vic20ieeevia1.c:199: via->read_pra = read_pra; src/vic20/vic20ieeevia2.c:200: via->read_pra = read_pra; src/drive/iec/cmdhd.c:1048: via10->read_pra = read_pra10; src/drive/iec/cmdhd.c:1084:...
-
OK i misread that - you were indeed talking about an extra function in each implementation. I am not sure if that is a good idea - or even necessary. It would be these: $ grep -rn "read_pra =" src src/vic20/vic20via1.c:303: via->read_pra = read_pra; src/vic20/vic20via2.c:229: via->read_pra = read_pra; src/vic20/vic20ieeevia1.c:199: via->read_pra = read_pra; src/vic20/vic20ieeevia2.c:200: via->read_pra = read_pra; src/drive/iec/cmdhd.c:1048: via10->read_pra = read_pra10; src/drive/iec/cmdhd.c:1084:...
-
Checkpoint prints a wrong cycle id
-
c1541 geoswrite incorrect [3.1]
-
-geoswrite should be fixed in r46036 - please test a bit with files of different length and type
-
correctly check for EOF in -geoswrite as well, don't always write the full (first) data block
-
i'll check - looks like geoswrite has a very similar bug
-
so you were actually correct, the problem was that mon_stopwatch_show() always used the default memspace. should be fixed in r46035 - please test
-
pass memspace to mon_stopwatch_show() instead of always using the current default memspace, should fix #2215
-
OK full reproducer: (C:$e5d1) >1000 ea 4c 00 10 (C:$e5d1) r pc = 1000 (C:$e5d1) break 1001 BREAK: 1 C:$1001 (Stop on exec) (C:$e5d1) dev 8: Setting default device to `Disk8' (8:$ec2d) x #1 (Stop on exec 1001) 66/$042, 3/$03 .C:1001 4C 00 10 JMP $1000 - A:00 X:00 Y:0A SP:f3 ..-...Z. 19335986 (C:$1001) chis 4 .C:e5d4 F0 F7 BEQ $E5CD A:00 X:00 Y:0a SP:f3 ..-...Z. 19050814 .C:e5cd A5 C6 LDA $C6 A:00 X:00 Y:0a SP:f3 ..-...Z. 19050817 .C:e5cf 85 CC STA $CC A:00 X:00 Y:0a SP:f3 ..-...Z. 19050820 .C:1000...
-
First observation: its not the stopwatch clock that is written into the cpu history, its always the actual CPU clock (which can never be "reset" like the stopwatch) Also it correctly writes the origin memspace (alternating 1 and 2) and different clock values. The function we are looking at is monitor_cpuhistory_store() in mon_memmap.c
-
But you are correct, its wrong in chis... looking
-
Checkpoint prints a wrong cycle id
-
It looks correct to me so far: Note that the two clock counters may look very similar unless you reset one of them (C:$e633) z .C:e5d1 8D 92 02 STA $0292 - A:00 X:00 Y:0A SP:f3 ..-...Z. 5346688 (C:$e5d1) .C:e5d4 F0 F7 BEQ $E5CD - A:00 X:00 Y:0A SP:f3 ..-...Z. 5346692 (C:$e5d4) .C:e5cd A5 C6 LDA $C6 - A:00 X:00 Y:0A SP:f3 ..-...Z. 5346695 (C:$e5cd) dev 8: Setting default device to `Disk8' (8:$ec34) z .8:ec3b 88 DEY - A:00 X:00 Y:01 SP:45 ..-...ZC 5426722 (8:$ec3b) .8:ec3c 10 F3 BPL $EC31 - A:00 X:00...
-
Please do. Please also check extracting some more (other) GEOS files - i shouldn't have broken it, but you never know :) Other than that i think the problem is fixed now (unless there is another error in -geoswrite)
-
Indeed, the t/s links are still there (so i will not zero them in c1541 either) There is garbage in the first block that looks like directory entries - perhaps the convert program reuses memory there and doesnt zero it either. Indeed looks like this is not relevant (and i will certainly not reproduce THAT in c1541 :))
-
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
-
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...
-
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?
-
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 :)
-
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 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...
-
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 :)
-
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...)
-
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)
-
uneducated try to fix build failing with use of undeclared identifier '_NSGetExecutablePath'
-
remove pointless initialization
-
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
-
don't abort 'extract' command on a cyclic file, extract remaining files instead :) fixes #2216
1 >
