|
|
Post by ToneDeF on Jan 27, 2021 4:48:18 GMT
On [3], unfortunately the FAT32 filesystem doesn't allow symbolic links. short of adding shell support for PIF files, there is nothing we can do to name-mask files in FAT32. I take it back... the mount --bind works just as well to name-mask individual files on a FAT32 file system. Wonderful! |
|
|
|
Post by jj0 on Jan 27, 2021 10:24:11 GMT
short of adding shell support for PIF files, there is nothing we can do to name-mask files in FAT32. I take it back... the mount --bind works just as well to name-mask individual files on a FAT32 file system. Wonderful! Yes, that's how e.g. gamecontrollerdb.txt gets overmounted. But there needs to be a filename mount point to overmount on so you would for example need to have a number of zero-length filenames in the duplicate directory as mount points? Btw, what are the duplicates anyway? |
|
|
|
Post by spannernick on Jan 27, 2021 12:23:01 GMT
I did not see a reply to one of my earlier questions. Does the carousel support audio playback of compressed audio (e.g. Ogg Vorbis files; MP3 files; etc.)? Has anyone experimented with this yet? No it supports wav only, Flashlight plays the wav file, Flashlight is what the Carousel's made with and C. |
|
|
|
Post by jj0 on Jan 27, 2021 15:03:17 GMT
I tested the Hall of Fame VSF in WinVice 2.4 and experienced the exact same behavior (back to the basic prompt after the first run; starts up fine on the second run). I used WinVice 2.4 to create my own VSF snapshot of the Hall of Fame program. Unfortunately, when I restarted Win Vice 2.4 and loaded my newly created VSF snapshot, the behavior was the same (back to the basic prompt after the first run; starts up fine on the second run). This gives me the impression that the requisite emulator settings are not stored within the VSF file.
What exactly happens in the emulator after the snapshot fails to run the first time? Does the first failed run of the snapshot cause the emulator to be "calibrated" such that the second run of the same snapshot starts up just fine? If so, how can we "pre-calibrate" the emulator to start up the VSF correctly on the first run?
Ok, I have an update to report. I did some more investigation and noticed that the default settings of my WinVice 2.4 installation had the C64 Model set to "C64 PAL" and the VIC II model set to "PAL-G". When I changed the settings of the C64 Model and VIC II model to "C64 NTSC" and "NTSC-M" respectively, then the VICE Emulator started up the Hall of Fame VSF on the very first run. Wonderful!
So... perhaps the way to get around this failure-to-run-on-the-first-click behavior is to ensure that the game's corresponding TSG file has the correct display type value set.
[1] Is it just a matter of changing the video display type field from "pal" to "ntsc" in the System options line "X"?
[2] What if the video display type field is left blank to default to native display mode?
[3] Can the same video display type value be used for all of the games (if so, we could then have two distributions of PCU... one set up for PAL, and one set up for NTSC), or must it be set to the value that the VSF file seems to prefer (if so, then I would like to know where that display type information is stored within the VSF file)? Interesting analysis. So key thing is that if there is a mismatch between the pal/ntsc system type in the TSG file and the VSF file then starting the VSF leads to a BASIC screen. But then the system type of the emulator is (apparently) set to the one in the VSF so loading it again (the emulator is always running in the background) makes it run OK. [1] To fix this the pal/ntsc system type in the system file needs to be correct value. [2] I tried leaving it blank but this led to the same behaviour. [3] Changing all to pal or ntsc in the .TSG files won't work as it needs to match the VSF one. There is some limited info on snapshots available in the VICE documentation but you would probably need to dive into the VICE 2.4 sources to see how you can detect it. Normally with a standard C64 the type can be checked at memory address 876 (PAL=1, NTSC=0). By POKEing different values to this address, saving snapshots and comparing them it looks like this is stored in the 811th byte in the unzipped snapshot file. However this does not always seem top be the case so it's not conclusive enough. In case you want to experiment, here's the script I used. #!/bin/sh
cd /usr/share/the64/games/
for FILE in *.tsg
do
NAME=$(grep "F:" $FILE | cut -f2 -d ':')
if [ ! "x$NAME" = "x" ]
then
if [ `cat $NAME | gunzip -c | grep -e C64MEM` ]
then
if [ `grep -e ",pal" $FILE` ]
then
TYPE=PAL
TYPENUM=01
else
if [ `grep -e ",ntsc" $FILE` ]
then
TYPE=NTSC
TYPENUM=00
else
TYPE="NOT SET"
TYPENUM="NS"
fi
fi
x32a=`cat $NAME | gunzip -c | dd bs=1 skip=810 count=1 2>/dev/null | hexdump -ve '1/1 "%.2x"'`
if [ ! "x$TYPENUM" = "x$x32a" ]
then
echo "$FILE $TYPE doesn't match type byte $x32a in $NAME"
fi
else
echo "$NAME not a C64 snapshot."
fi
fi
done
when used on the all working standard games the output is: ANARCHY.tsg PAL doesn't match type byte 59 in games/ANARCHY.vsf.gz
BATTLE-VALLEY.tsg PAL doesn't match type byte 18 in games/BATTLE-VALLEY.vsf.gz
games/BLUESTAR.vsf.gz not a C64 snapshot.
CYBERNOID-II-2017.tsg PAL doesn't match type byte fd in games/CYBERNOID-II-2017.vsf.gz
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/GRIDRUNNER.vsf.gz not a C64 snapshot.
HEARTLAND.tsg PAL doesn't match type byte 06 in games/HEARTLAND.vsf.gz
IMPOSSIBLE-MISSION.tsg PAL doesn't match type byte 00 in games/IMPOSSIBLE-MISSION.vsf.gz
MEGA-APOCALYPSE.tsg PAL doesn't match type byte 07 in games/MEGA-APOCALYPSE.vsf.gz
MONTY-ON-THE-RUN.tsg PAL doesn't match type byte 00 in games/MONTY-ON-THE-RUN.vsf.gz
NETHERWORLD.tsg PAL doesn't match type byte 39 in games/NETHERWORLD.vsf.gz
games/PSYCHEDELIA.vsf.gz not a C64 snapshot.
RANARAMA.tsg PAL doesn't match type byte 10 in games/RANARAMA.vsf.gz
ROBIN-OF-THE-WOOD.tsg PAL doesn't match type byte 65 in games/ROBIN-OF-THE-WOOD.vsf.gz
SPEEDBALL-2.tsg PAL doesn't match type byte 7f in games/SPEEDBALL-2.vsf.gz
STEEL.tsg PAL doesn't match type byte fa in games/STEEL.vsf.gz
games/THEKEEP.vsf.gz not a C64 snapshot.
So sometimes the byte isn't 00 nor 01, and also when the type doesn't match the byte the standard games still work, It's probably easiest to note when the issue pops up with a particular game and ask spannernick to change the TSG file (or the VSF of course). |
|
|
|
Post by jj0 on Jan 27, 2021 15:04:42 GMT
I did not see a reply to one of my earlier questions. Does the carousel support audio playback of compressed audio (e.g. Ogg Vorbis files; MP3 files; etc.)? Has anyone experimented with this yet? No it supports wav only, Flashlight plays the wav file, Flashlight is what the Carousel's made with and C. Yes, Flashlight seems to be the graphics/sound toolkit that is used instead of e.g. SDL. Pity there's no documentation on it. |
|
|
|
Post by spannernick on Jan 27, 2021 18:18:59 GMT
Ok, I have an update to report. I did some more investigation and noticed that the default settings of my WinVice 2.4 installation had the C64 Model set to "C64 PAL" and the VIC II model set to "PAL-G". When I changed the settings of the C64 Model and VIC II model to "C64 NTSC" and "NTSC-M" respectively, then the VICE Emulator started up the Hall of Fame VSF on the very first run. Wonderful!
So... perhaps the way to get around this failure-to-run-on-the-first-click behavior is to ensure that the game's corresponding TSG file has the correct display type value set.
[1] Is it just a matter of changing the video display type field from "pal" to "ntsc" in the System options line "X"?
[2] What if the video display type field is left blank to default to native display mode?
[3] Can the same video display type value be used for all of the games (if so, we could then have two distributions of PCU... one set up for PAL, and one set up for NTSC), or must it be set to the value that the VSF file seems to prefer (if so, then I would like to know where that display type information is stored within the VSF file)? Interesting analysis. So key thing is that if there is a mismatch between the pal/ntsc system type in the TSG file and the VSF file then starting the VSF leads to a BASIC screen. But then the system type of the emulator is (apparently) set to the one in the VSF so loading it again (the emulator is always running in the background) makes it run OK. [1] To fix this the pal/ntsc system type in the system file needs to be correct value. [2] I tried leaving it blank but this led to the same behaviour. [3] Changing all to pal or ntsc in the .TSG files won't work as it needs to match the VSF one. There is some limited info on snapshots available in the VICE documentation but you would probably need to dive into the VICE 2.4 sources to see how you can detect it. Normally with a standard C64 the type can be checked at memory address 876 (PAL=1, NTSC=0). By POKEing different values to this address, saving snapshots and comparing them it looks like this is stored in the 811th byte in the unzipped snapshot file. However this does not always seem top be the case so it's not conclusive enough. In case you want to experiment, here's the script I used. #!/bin/sh
cd /usr/share/the64/games/
for FILE in *.tsg
do
NAME=$(grep "F:" $FILE | cut -f2 -d ':')
if [ ! "x$NAME" = "x" ]
then
if [ `cat $NAME | gunzip -c | grep -e C64MEM` ]
then
if [ `grep -e ",pal" $FILE` ]
then
TYPE=PAL
TYPENUM=01
else
if [ `grep -e ",ntsc" $FILE` ]
then
TYPE=NTSC
TYPENUM=00
else
TYPE="NOT SET"
TYPENUM="NS"
fi
fi
x32a=`cat $NAME | gunzip -c | dd bs=1 skip=810 count=1 2>/dev/null | hexdump -ve '1/1 "%.2x"'`
if [ ! "x$TYPENUM" = "x$x32a" ]
then
echo "$FILE $TYPE doesn't match type byte $x32a in $NAME"
fi
else
echo "$NAME not a C64 snapshot."
fi
fi
done
when used on the all working standard games the output is: ANARCHY.tsg PAL doesn't match type byte 59 in games/ANARCHY.vsf.gz
BATTLE-VALLEY.tsg PAL doesn't match type byte 18 in games/BATTLE-VALLEY.vsf.gz
games/BLUESTAR.vsf.gz not a C64 snapshot.
CYBERNOID-II-2017.tsg PAL doesn't match type byte fd in games/CYBERNOID-II-2017.vsf.gz
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/GRIDRUNNER.vsf.gz not a C64 snapshot.
HEARTLAND.tsg PAL doesn't match type byte 06 in games/HEARTLAND.vsf.gz
IMPOSSIBLE-MISSION.tsg PAL doesn't match type byte 00 in games/IMPOSSIBLE-MISSION.vsf.gz
MEGA-APOCALYPSE.tsg PAL doesn't match type byte 07 in games/MEGA-APOCALYPSE.vsf.gz
MONTY-ON-THE-RUN.tsg PAL doesn't match type byte 00 in games/MONTY-ON-THE-RUN.vsf.gz
NETHERWORLD.tsg PAL doesn't match type byte 39 in games/NETHERWORLD.vsf.gz
games/PSYCHEDELIA.vsf.gz not a C64 snapshot.
RANARAMA.tsg PAL doesn't match type byte 10 in games/RANARAMA.vsf.gz
ROBIN-OF-THE-WOOD.tsg PAL doesn't match type byte 65 in games/ROBIN-OF-THE-WOOD.vsf.gz
SPEEDBALL-2.tsg PAL doesn't match type byte 7f in games/SPEEDBALL-2.vsf.gz
STEEL.tsg PAL doesn't match type byte fa in games/STEEL.vsf.gz
games/THEKEEP.vsf.gz not a C64 snapshot.
So sometimes the byte isn't 00 nor 01, and also when the type doesn't match the byte the standard games still work, It's probably easiest to note when the issue pops up with a particular game and ask spannernick to change the TSG file (or the VSF of course). Like your code Jeroen..  It looks like some are not snapshots but is given the .vsf.gz extension so they could be .crt.gz (or prg.gz) and renamed to .vsf.gz so they all match. It should take a minute to update the games using PCU Game Manager and using its scraper, it downloads the game for you too, if you use c64.com and Gamebase 64 sites, it will grabs it when it scrapes the info for the game, cool idea.. |
|
|
|
Post by spannernick on Jan 27, 2021 19:10:40 GMT
I wonder... Could you hack a vsf.gz file by looking at it in HxD Hex Editor and changing its bit in it to the right one...? I guess it would be easier to make a new one with VICE. Weird PAL G, Europe and UK used PAL B... and no mention of it on Wikipedia "MOS Technology 6569 – (PAL-B, used in most PAL countries)" en.wikipedia.org/wiki/MOS_Technology_VIC-II |
|
|
|
Post by ToneDeF on Jan 28, 2021 2:30:29 GMT
I take it back... the mount --bind works just as well to name-mask individual files on a FAT32 file system. Wonderful! Btw, what are the duplicates anyway? The PCUAEv1.20b2 build had a VICE distribution in every games list folder, but that's not the case in the builds that came after it. In the recent builds, I think what is being duplicated the most now is the THEC64-HALL-OF-FAME.vsf.gz binary (it is referenced by every games list folder because the games list entry itself needs to run something when it is clicked).
An MD5 hash of all files in the distribution will help to identify files which are exact duplicates.
|
|
|
|
Post by ToneDeF on Jan 28, 2021 2:38:09 GMT
No it supports wav only, Flashlight plays the wav file, Flashlight is what the Carousel's made with and C. Yes, Flashlight seems to be the graphics/sound toolkit that is used instead of e.g. SDL. Pity there's no documentation on it. Yes, that is a shame. The large audio files looked like low hanging fruit for places to shrink the footprint of the distribution.
It looks like the WAV files are 16-bit mono 22KHz files. Will 11KHz WAV files work in Flashlight?
Also, we could create smaller WAV files (e.g. have just a single SID track rather than a medley of several SID tracks).
|
|
|
|
Post by ToneDeF on Jan 28, 2021 2:46:06 GMT
Interesting analysis. So key thing is that if there is a mismatch between the pal/ntsc system type in the TSG file and the VSF file then starting the VSF leads to a BASIC screen. But then the system type of the emulator is (apparently) set to the one in the VSF so loading it again (the emulator is always running in the background) makes it run OK. [1] To fix this the pal/ntsc system type in the system file needs to be correct value. [2] I tried leaving it blank but this led to the same behaviour. [3] Changing all to pal or ntsc in the .TSG files won't work as it needs to match the VSF one. There is some limited info on snapshots available in the VICE documentation but you would probably need to dive into the VICE 2.4 sources to see how you can detect it. Normally with a standard C64 the type can be checked at memory address 876 (PAL=1, NTSC=0). By POKEing different values to this address, saving snapshots and comparing them it looks like this is stored in the 811th byte in the unzipped snapshot file. However this does not always seem top be the case so it's not conclusive enough. In case you want to experiment, here's the script I used. #!/bin/sh
cd /usr/share/the64/games/
for FILE in *.tsg
do
NAME=$(grep "F:" $FILE | cut -f2 -d ':')
if [ ! "x$NAME" = "x" ]
then
if [ `cat $NAME | gunzip -c | grep -e C64MEM` ]
then
if [ `grep -e ",pal" $FILE` ]
then
TYPE=PAL
TYPENUM=01
else
if [ `grep -e ",ntsc" $FILE` ]
then
TYPE=NTSC
TYPENUM=00
else
TYPE="NOT SET"
TYPENUM="NS"
fi
fi
x32a=`cat $NAME | gunzip -c | dd bs=1 skip=810 count=1 2>/dev/null | hexdump -ve '1/1 "%.2x"'`
if [ ! "x$TYPENUM" = "x$x32a" ]
then
echo "$FILE $TYPE doesn't match type byte $x32a in $NAME"
fi
else
echo "$NAME not a C64 snapshot."
fi
fi
done
when used on the all working standard games the output is: ANARCHY.tsg PAL doesn't match type byte 59 in games/ANARCHY.vsf.gz
BATTLE-VALLEY.tsg PAL doesn't match type byte 18 in games/BATTLE-VALLEY.vsf.gz
games/BLUESTAR.vsf.gz not a C64 snapshot.
CYBERNOID-II-2017.tsg PAL doesn't match type byte fd in games/CYBERNOID-II-2017.vsf.gz
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/EPYX-GAMES-ntsc-rgl-jp2.crt.gz not a C64 snapshot.
games/GRIDRUNNER.vsf.gz not a C64 snapshot.
HEARTLAND.tsg PAL doesn't match type byte 06 in games/HEARTLAND.vsf.gz
IMPOSSIBLE-MISSION.tsg PAL doesn't match type byte 00 in games/IMPOSSIBLE-MISSION.vsf.gz
MEGA-APOCALYPSE.tsg PAL doesn't match type byte 07 in games/MEGA-APOCALYPSE.vsf.gz
MONTY-ON-THE-RUN.tsg PAL doesn't match type byte 00 in games/MONTY-ON-THE-RUN.vsf.gz
NETHERWORLD.tsg PAL doesn't match type byte 39 in games/NETHERWORLD.vsf.gz
games/PSYCHEDELIA.vsf.gz not a C64 snapshot.
RANARAMA.tsg PAL doesn't match type byte 10 in games/RANARAMA.vsf.gz
ROBIN-OF-THE-WOOD.tsg PAL doesn't match type byte 65 in games/ROBIN-OF-THE-WOOD.vsf.gz
SPEEDBALL-2.tsg PAL doesn't match type byte 7f in games/SPEEDBALL-2.vsf.gz
STEEL.tsg PAL doesn't match type byte fa in games/STEEL.vsf.gz
games/THEKEEP.vsf.gz not a C64 snapshot.
So sometimes the byte isn't 00 nor 01, and also when the type doesn't match the byte the standard games still work, It's probably easiest to note when the issue pops up with a particular game and ask spannernick to change the TSG file (or the VSF of course). Like your code Jeroen.. It looks like some are not snapshots but is given the .vsf.gz extension so they could be .crt.gz (or prg.gz) and renamed to .vsf.gz so they all match. It should take a minute to update the games using PCU Game Manager and using its scraper, it downloads the game for you too, if you use c64.com and Gamebase 64 sites, it will grabs it when it scrapes the info for the game, cool idea.. I like that shell script, jj0 -- nice work! Having a way to reliably detect game configuration mismatches is of vital importance, and you shell script goes a long way to getting us there. I also think that the ideas proposed by spannernick are good ones; let's do it!  |
|
|
|
Post by ToneDeF on Jan 28, 2021 2:58:43 GMT
I wonder... Could you hack a vsf.gz file by looking at it in HxD Hex Editor and changing its bit in it to the right one...? I guess it would be easier to make a new one with VICE. Weird PAL G, Europe and UK used PAL B... and no mention of it on Wikipedia "MOS Technology 6569 – (PAL-B, used in most PAL countries)" en.wikipedia.org/wiki/MOS_Technology_VIC-III wonder if the significant differences in a VSF image are numerous and in multiple locations within the image. I also wonder if there are floppy disk drive settings saved in the VSF image that could cause the game to not run properly if drive settings saved in the image which do not gel with any drive settings that are (or are not) configured in the TSG file.
I could not really find anything about PAL-G (perhaps the G stands for "Generic"), and I think NTSC-M denotes the 65-cycle American C64.
|
|
|
|
Post by retrochlop on Jan 28, 2021 8:29:45 GMT
Hello everyone. I have a problem with my game carousel made with THE C64 MAXI GAME TOOL. Well, my carousel consists of 454 games. When I enter SYSTEM INFORMATION and then click APPLY, my MAXI does not react and returns me to the MENU 😔 Can the problem be too many games that I want to install in the carousel  |
|
|
|
Post by kugelblitz on Jan 28, 2021 10:24:02 GMT
Hello everyone. I have a problem with my game carousel made with THE C64 MAXI GAME TOOL. Well, my carousel consists of 454 games. When I enter SYSTEM INFORMATION and then click APPLY, my MAXI does not react and returns me to the MENU 😔 Can the problem be too many games that I want to install in the carousel I might want to stress this again: The code for the carousel as delivered by the manufacturer is tested only for roughly 64 games. Pushing it to display more games is dangerous because it is untested. As the THEC64 has a VERY small RAM, most likely you simply run into Memory problems. The code also is NOT really stable if single screenshots are missing, there are typos in the description and more. Do expect strange behaviour once you pushed over a hundred games into one instance of the carousel. (And nobody can fix that). |
|
|
|
Post by jj0 on Jan 28, 2021 11:22:14 GMT
Like your code Jeroen.. It looks like some are not snapshots but is given the .vsf.gz extension so they could be .crt.gz (or prg.gz) and renamed to .vsf.gz so they all match. It should take a minute to update the games using PCU Game Manager and using its scraper, it downloads the game for you too, if you use c64.com and Gamebase 64 sites, it will grabs it when it scrapes the info for the game, cool idea.. I like that shell script, jj0 -- nice work! Having a way to reliably detect game configuration mismatches is of vital importance, and you shell script goes a long way to getting us there. I also think that the ideas proposed by spannernick are good ones; let's do it! Here's an updated, somewhat more intelligent script: #!/bin/sh
cd /usr/share/the64/games/
for FILE in *.tsg
do
NAME=$(grep "F:" $FILE | cut -f2 -d ':')
if [ ! "x$NAME" = "x" ]
then
rm /tmp/testfile 2>/dev/null
cat $NAME | gunzip -c >/tmp/testfile
if [ ! $? ]
then
cp $NAME /tmp/testfile
fi
case `grep -a -o -m 1 -e VIC20MEM -e C64MEM -e "C64 CARTRIDGE" /tmp/testfile` in
C64MEM)
case `grep -a -o -m 1 -e ",pal" -e ",ntsc" $FILE` in
,pal)
TYPE=PAL
TYPENUM=01
;;
,ntsc)
TYPE=NTSC
TYPENUM=00
;;
*)
TYPE="NOT SET"
TYPENUM="NS"
;;
esac
x32a=`dd if=/tmp/testfile bs=1 skip=810 count=1 2>/dev/null | hexdump -ve '1/1 "%.2x"'`
if [ ! "x$TYPENUM" = "x$x32a" ]
then
echo "$FILE $TYPE doesn't match type byte $x32a in $NAME - should be $TYPENUM"
fi
;;
"C64 CARTRIDGE")
echo "$NAME is a C64 cartridge"
;;
VIC20MEM)
echo "$NAME is a VIC-20 snapshot"
;;
*)
echo "$NAME is neither a C64 snapshot or cartridge nor a VIC-20 snapshot"
;;
esac
else
echo "$FILE doesn't contain a valid game filename"
fi
done
rm /tmp/testfileI guess for those games where the PAL/NTSC value is weird (not 0 or 1) the game is actually using the memory location for something else. |
|
|
|
Post by vic2020ian on Jan 28, 2021 11:24:00 GMT
Hello everyone. I have a problem with my game carousel made with THE C64 MAXI GAME TOOL. Well, my carousel consists of 454 games. When I enter SYSTEM INFORMATION and then click APPLY, my MAXI does not react and returns me to the MENU 😔 Can the problem be too many games that I want to install in the carousel The next version of PCUAE will likely resolve your problem. You will be able to create individual folders with approximately 225 files per folder. e.g. A, B, C... X, Y, Z Reduce your game folder size to 225 for now and it should work. |
|
|
|
Post by jj0 on Jan 28, 2021 11:27:25 GMT
Hello everyone. I have a problem with my game carousel made with THE C64 MAXI GAME TOOL. Well, my carousel consists of 454 games. When I enter SYSTEM INFORMATION and then click APPLY, my MAXI does not react and returns me to the MENU 😔 Can the problem be too many games that I want to install in the carousel I might want to stress this again: The code for the carousel as delivered by the manufacturer is tested only for roughly 64 games. Pushing it to display more games is dangerous because it is untested. As the THEC64 has a VERY small RAM, most likely you simply run into Memory problems. The code also is NOT really stable if single screenshots are missing, there are typos in the description and more. Do expect strange behaviour once you pushed over a hundred games into one instance of the carousel. (And nobody can fix that). Indeed. Plus AFAIK the standard Carousel will only read ~150 games, and the PCU one ~250? So you are better off using PCU and divide the games into subdirectories instead of using the Maxi Gametool. But if the Maxi doesn't load the update at all it's more likely that there's something wrong with the update. Are you applying the update to a standard Maxi or is it running PCU? Also, can you upload the update file(s) you are using, that will help check what's happening. |
|
|
|
Post by retrochlop on Jan 28, 2021 12:11:09 GMT
So PCU is better than THEC64 GAME TOOL Updates from the manufacturer's website are installed without any problems, but the file from the carousel with a total of 454 games is not  I will try to do everything in the PCU and then maybe I can put it all by dividing it into directories Where can I download PCU MANAGER ?? 😊 |
|
|
|
Post by vic2020ian on Jan 28, 2021 12:35:09 GMT
So PCU is better than THEC64 GAME TOOL Updates from the manufacturer's website are installed without any problems, but the file from the carousel with a total of 454 games is not I will try to do everything in the PCU and then maybe I can put it all by dividing it into directories Where can I download PCU MANAGER ?? 😊 Quit using TheC64 Game Tool. It messes with your Nand. PCUAE does not and runs all much better from USB. PCU Game Manager allows you to build the Carousel easily for PCUAE. These 2 parts are fantastic together in concert. The next version should see the new game list selector enabling unlimited carousels. For now you can reconfigure 5. Foavourites, 3 for AtoZ on C64 and 1 for Vic20 each with 225 games. If you create this in Game Manager you can reconfigure it all for as many folders as you want when Beta 5 comes out. |
|
|
|
Post by spannernick on Jan 28, 2021 13:31:06 GMT
PCUv1.20Beta 5 has now had a version name change, the next version will be PCUAEv1.30, I think it need a version change cause of the way you can now add gamelists has changed, cause of the Carousel Gamelist Selector Screen* *Carousel USB Folder Chooser by Faberfox, I changed it name so its in line with the Carousel Gamelist Screens and it sound better, thanks goes to Faberfox for make it in the first place .. .Will be releasing PCUAEv1.30.7z* today to tomorrow I am at the moment still looking for bugs and editing things in it so as soon as I have finished that then it will be released. *It will use 7zip so make sure you download 7zip and install it so you can unzip it, I use 7zip cause it makes it into a smaller file and better compression. |
|
|
|
Post by retrochlop on Jan 28, 2021 15:32:55 GMT
May I have a link to download the latest PCU version? |
|
|
|
Post by vic2020ian on Jan 28, 2021 17:08:17 GMT
May I have a link to download the latest PCU version? The link is in SpannerNick's signature in the post above which takes you to PCUAE page 1 of the thread with details of the latest version when updated. |
|
|
|
Post by vic2020ian on Jan 28, 2021 17:11:19 GMT
PCUv1.20Beta 5 has now had a version name change, the next version will be PCUAEv1.30, I think it need a version change cause of the way you can now add gamelists has changed, cause of the Carousel Gamelist Selector Screen* *Carousel USB Folder Chooser by Faberfox, I changed it name so its in line with the Carousel Gamelist Screens and it sound better, thanks goes to Faberfox for make it in the first place .. .Will be releasing PCUAEv1.30.7z* today to tomorrow I am at the moment still looking for bugs and editing things in it so as soon as I have finished that then it will be released. *It will use 7zip so make sure you download 7zip and install it so you can unzip it, I use 7zip cause it makes it into a smaller file and better compression. Nick, great work on including the new features like folders. Looking forward to spending my weekend playing with this. Thank you. Best regards, Ian |
|
|
|
Post by ToneDeF on Jan 28, 2021 17:11:49 GMT
I guess for those games where the PAL/NTSC value is weird (not 0 or 1) the game is actually using the memory location for something else. The refined/enhanced script looks good.
Is it possible that the PAL/NTSC value gets stored in a different location and/or in a different way in the VSF -- perhaps due to a combination of circumstances taken into consideration by VICE which were unique to that game's distribution? |
|
|
|
Post by ToneDeF on Jan 28, 2021 17:30:05 GMT
My apologies in advance if these questions have been answered previously somewhere in the forum.
I have two questions regarding some of the TSG files in PCUAE.
[1] What is the significance of the "-ms" suffix on the filenames of most (but not all) of the TSG files?
[2] Is "truedrive" a valid value for the "X:" setting in the TSG file. The documentation for CJM files does not mention it. Should the value be "accuratedisk" instead?
I also have a question regarding the VICE 2.4 emulator running a game kicked off by the PCUAE carousel.
[3] Is there a key combination I can press on the THEC64 maxi keyboard to toggle on or off the WARP mode of VICE?
Thank you in advance.
|
|
|
|
Post by jj0 on Jan 28, 2021 18:18:46 GMT
I guess for those games where the PAL/NTSC value is weird (not 0 or 1) the game is actually using the memory location for something else. The refined/enhanced script looks good.
Is it possible that the PAL/NTSC value gets stored in a different location and/or in a different way in the VSF -- perhaps due to a combination of circumstances taken into consideration by VICE which were unique to that game's distribution? It's unlikely. They might all be in the same a different location though if this documentation isn't correct for VICE 2.4. |
|
|
|
Post by jj0 on Jan 28, 2021 18:25:57 GMT
My apologies in advance if these questions have been answered previously somewhere in the forum.
I have two questions regarding some of the TSG files in PCUAE.
[1] What is the significance of the "-ms" suffix on the filenames of most (but not all) of the TSG files?
[2] Is "truedrive" a valid value for the "X:" setting in the TSG file. The documentation for CJM files does not mention it. Should the value be "accuratedisk" instead?
I also have a question regarding the VICE 2.4 emulator running a game kicked off by the PCUAE carousel.
[3] Is there a key combination I can press on the THEC64 maxi keyboard to toggle on or off the WARP mode of VICE?
Thank you in advance.
[1] This stems from the Maxi Game Tool which added it to the filenames IIRC. [2] The best way to find out is to try it yourself But: # strings /usr/bin/the64 | grep -e truedrive -e accuratedisk
truedrive
accuratedisk
it looks like both are supported, probably one for the TSG and the other for the CJM. [3] The standard 'Carousel' VICE: No. The full VICE that I compiled: Yes: - Left Fire anfd Right Fire: Fire - Left Triangle Snapshot&Quickload snapshot.vsf - Right Triangle: Snapshot&Quicksave snapshot.vsf - Left menu button: Speed settings&Warp mode - Left middle menu button: Quit emulator - Right middle menu button: Swap joystick ports - Right menu button: Vice menu |
|
|
|
Post by spannernick on Jan 28, 2021 19:55:46 GMT
I am still working on PCUAEV1.30, I am hoping everything is ok now, been working on it all day... Ironing out the bugs.. I have not touched the games at all at the moment maybe in next version but you should be able to sort them with PCU Game Manager, I have imported every game from PCUAE into it now so you be able to down load it soon too with all the games included. Releasing PCUAEv1.30 in the next hour... |
|
|
|
Post by spannernick on Jan 28, 2021 21:03:43 GMT
PCUAEv1.30 is now uploading to the PCU Zipped folder... enjoy |
|
|
|
Post by spannernick on Jan 28, 2021 21:18:31 GMT
Uploaded...
|
|
|
|
Post by vic2020ian on Jan 28, 2021 21:36:27 GMT
Downloaded! ...but I need a faster memory stick this takes 10+ mins to copy over...any recommendations? Thank you Nick. |
|
Feb 5, 2024 14:16:57 GMT