|
|
Post by gurce on Jul 23, 2020 18:20:27 GMT
Heya all,
I was getting curious about qemu and building of the .rgl file.
As I'm on my macbook, didn't seem to have systemd-nspawn, so was looking for alternatives.
I don't particularly know what I'm doing with qemu, so just flailing about and learning things as I go, but felt like documenting the journey so far, so others more experienced might spot where I could be going wrong 
1st journey - Figuring out qemu
Back in 2018, I had a stab at learning qemu. Here's some notes I had on that journey...
I installed qemu with "brew install qemu"
My main point of reference was this walkthrough online:
It mentioned there to download things like:
I felt a little worried about "armhf" for some reason, and thought should I have gotten something like "arm7l" instead? As I saw, with this command:
# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 4 (v7l)
But who knows, I've got no idea and maybe hf is fine
I had some trouble with steps in the walkthrough relating to libguestfs, so I had to perform those steps via an Ubuntu VM on my macbook (slow, but I tolerated it).
Hmm, in my old notes, I grumble that the installation took hours! 
Anyways, after painfully absorbing the walkthrough steps, I seemed to get linux running through qemu via this monstrous-looking command: qemu-system-arm -M virt -m 1024 \
-kernel vmlinuz-3.16.0-6-armmp-lpae \
-initrd initrd.img-3.16.0-6-armmp-lpae \
-append 'root=/dev/vda2' \
-drive if=none,file=hda.qcow2,format=qcow2,id=hd \
-device virtio-blk-device,drive=hd \
-netdev user,id=mynet \
-device virtio-net-device,netdev=mynet \
-nographicThis gave me a log-in prompt, and I was happy-ish. It irked me that I had no gui though. Rightly or wrongly, I blamed that " -nographic" argument at the end, tried doing some googling on what to replace it with, tried various things, and then threw my hands in the air and gave up
2nd journey - Figuring out how to build the .rgl in qemu
Pressing on to 2020, feel like I'll give this qemu another chance
I saw in another thread that the .rgl souce was available at:
So thought I might be in with a shot at building this via my last attempt with qemu, perhaps not even needing a gui-environment to do so (just from the plain console).
So here's where I'm at with tonight's efforts:
- Fired up my qemu-linux thingie
- Tried to install any pre-requisites I might need for this:
sudo apt install git g++ libreadline-dev libx11-dev libxext-dev libxv-dev libxt-dev libxmu-dev libxaw7-dev make autoconf m4
- mkdir Projects
- git clone github.com/Classicmods/C64_mini_VICE.git
- cd C64_mini_VICE
./configure ./the64_configure
Running ./configure spits out various errors, and I'll take them as hints that I need to install more pre-requisites. So I'll add any that I figure out to the pre-req list above.
Well, that's where I'm at right now. Will nibble on this incrementally, but any thoughts/advice along the way is appreciated
UPDATE:
Ok, I've seemed to appeased ./configure errors for now (I still might need more pre-reqs later). Next up, I'll try build the x64 emulator with:
make x64
Some errors encountered there too, might try tackle that next time and call it quits for tonight...
Oh, another error learnt tonight, don't use "./configure", use "./the64_configure" |
|
|
|
Post by jj0 on Jul 24, 2020 21:40:08 GMT
Hi gurce, I don't know much about MacOS, but if you can install qemu-user-static you could try chroot-ing into a suitable arm7l rootfs. As test using for example the XWM rootfs: #:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ mkdir mnt
#:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ sudo mount rootfs.img mnt
#:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ sudo chroot mnt /bin/bash
root@BLADIBLA:/#
Then you don't need to run the qemu VM. You're still in a CLI environment but for compiling that's not a bad thing  . Though if you do: #:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ xhost +local:
non-network local connections being added to access control list
#:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ echo $DISPLAY
:1
#:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ mkdir mnt
#:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ sudo mount rootfs.img mnt
#:~/THEC64_Mini/img/CustomFW/XWM/TheC64-X-Windows v4$ sudo chroot mnt /bin/bash
root@BLADIBLA:/# export DISPLAY=:1
root@BLADIBLA:/# xclock &
[1] 3041
root@BLADIBLA:/#
You should see the xclock program appear. So you can run individual X programs (e.g. a text editor) that will display on your regular desktop. If the above works then you could copy the content of the mnt directory to e.g. rootfs-armv7l and use that so you'r not working from the rootfs.img which will lack enough space. Or download a somewhat more modern Armbian rootfs to use. Not if you want to build the .rgl files for experimenting then you have to git clone github.com/retro-games-ltd/redquark-sixtyfour.git and github.com/retro-games-ltd/vice-2.4.git and follow the instructions: Building
To build c64emu.rgl and vic20emu.rgl, place src for vice2 in ./src/ directory (or symlink to it), so it has the path src/vice2/
Run ./configure followed by make.
armhf means that the binary expects a CPU that supports hardware floating point operations which the armv7l CPU does. |
|
|
|
Post by gurce on Jul 25, 2020 16:28:09 GMT
Thanks JJ,
Had another stab at it tonight.
Don't think I'll try yet, maybe I'll try qemu-user-static via an Ubuntu-vm at some stage.
I tried mounting rootfs.img on the mac, but didn't have much luck there, this was my failed attempt with that, figuring out the mac-esque way to mount images:
hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount rootfs.img
/dev/disk5
sudo mount -t fuse-ext2 /dev/disk5 /Users/tramvo/mnt
mount: realpath /Users/tramvo/mnt: Input/output error
hdiutil detach /dev/disk5
"disk5" unmounted.
"disk5" ejected.
So for now, I'll just make do with the slow qemu-vm. Took your advice on cloning the right repos and things fared much better tonight
Ran qemu vm, then:
cd ~/Projects
git clone https://github.com/retro-games-ltd/redquark-sixtyfour.git
cd readquark-sixityfour
cd src
git clone https://github.com/retro-games-ltd/vice-2.4.git vice2
sudo apt install pkg-config libasound2-dev libjpeg-dev libpng12-dev bison flex
./configure
make One gotchya for me, I was only able to install libpng12 via apt, but ./configure was expecting libpng16... I worked around this by editing "configure" and swapping all libpng16 references to libpng12. Wow, it generated the .rgl files, nice For my next foray, I'll try these on the hardware to see if they work...
Then after that, I'd like to re-visit that 3/4 joystick support behaviour we were pondering in this past thread:
I've been sniffing into that "joy.c" file to get some clues on what could be done, no solid ideas yet, but just pondering what might be possible.
These "JoyDevice*" resources seem to get set via the Gui stuff, but who knows, maybe there's a way I could inject a call to resources_register_int() with hardcoded values somewhere so a gui isn't needed for this...
|
|
|
|
Post by gurce on Jul 26, 2020 15:06:26 GMT
Ok, thought I'd give the .rgl file I built a try on the maxi.
1. I added PCU to my usb-stick 2. Added my c64emu_gi.rgl file into "Carousel_Games/Options/emulators/" (alongside the others) 2. tweaked the "start.sh" script to mount my .rgl 3. Started up the maxi, went into 'System Info' and clicked on the firmware update 'apply' 4. I saw the PCU title-screen appear, but then it fades and gets stuck on the blue background (doesn't jump into carousel).
As a comparison, I tried mounting that c64emu-8580.rgl file instead, followed the same steps, and that one works.
So I feel like there's maybe something wrong with the way I generated the file...
Maybe on my next attempt (for another day), I'll try point my qemu-vm to JJ's rootfs.img and see if I could build it from there. I know JJ said there's not much space left on that image, but maybe I could expand the img to be larger with a few tools? (dd/gparted?)
|
|
|
|
Post by jj0 on Jul 26, 2020 18:22:10 GMT
Ok, thought I'd give the .rgl file I built a try on the maxi.
1. I added PCU to my usb-stick 2. Added my c64emu_gi.rgl file into "Carousel_Games/Options/emulators/" (alongside the others) 2. tweaked the "start.sh" script to mount my .rgl 3. Started up the maxi, went into 'System Info' and clicked on the firmware update 'apply' 4. I saw the PCU title-screen appear, but then it fades and gets stuck on the blue background (doesn't jump into carousel).
As a comparison, I tried mounting that c64emu-8580.rgl file instead, followed the same steps, and that one works.
So I feel like there's maybe something wrong with the way I generated the file...
Maybe on my next attempt (for another day), I'll try point my qemu-vm to JJ's rootfs.img and see if I could build it from there. I know JJ said there's not much space left on that image, but maybe I could expand the img to be larger with a few tools? (dd/gparted?)
Your c64emu_gi.rgl (md5sum f63c9b4fda2d6212ebd29206af7638e1) works fine on my Mini. Btw, if you rename the rootfs.img to rootfs.dmg can you mount it (without the hdattach stuff) then? You can expand the image (on Linux anyway) by concatenating it with an empty e.g. 512MB file, then resize2fs the new rootfs.img. |
|
|
|
Post by gurce on Jul 28, 2020 3:17:43 GMT
Hmm, strange, it works for you and not for me... I even tried it on my mini also, same problem for me.
I confirmed the md5sum, same as yours too.
Feel like I need to get in the position to run the64 binary myself from the serial-terminal and see why it fails to start up with my .rgl. I've got the uart-hack on my mini, but have forgotten the steps to get the serial-monitor stuff working. I'll revise them soon and try re-familiarise with it.
So far, didn't have any luck with the rootfs.img/dmg stuff.
Thought I might try to convert the rootfs.img into a rootfs.qcow2 file, for feeding into the qemu emulator. No success yet there either.
|
|
|
|
Post by jj0 on Jul 28, 2020 9:42:43 GMT
Hmm, strange, it works for you and not for me... I even tried it on my mini also, same problem for me. I confirmed the md5sum, same as yours too. Feel like I need to get in the position to run the64 binary myself from the serial-terminal and see why it fails to start up with my .rgl. I've got the uart-hack on my mini, but have forgotten the steps to get the serial-monitor stuff working. I'll revise them soon and try re-familiarise with it. So far, didn't have any luck with the rootfs.img/dmg stuff. Thought I might try to convert the rootfs.img into a rootfs.qcow2 file, for feeding into the qemu emulator. No success yet there either. I was mistaken, it doesn't work for me either. I thought it was dynamically loaded every time you start a game, so I replaced it while the64 was running. But in fact it is loaded once at startup. When I kill and restart the64 it doesn't work. Sorry for the confusion. |
|
|
|
Post by gurce on Jul 28, 2020 17:27:43 GMT
Hmm, I tried using my uart-hack serial connection tonight, but oddly, the terminal output seems mixed with a lot of garbage output. I still see some familiar bits of text "redquark" and "invalid password" appear, intertwined with lots of garbage characters.
At a guess, maybe my serial connection has some problems, maybe the solder connections became more temperamental over time...
Ah well, will look for alternatives. I'll try an Ubuntu VM on my macbook...
- Did "sudo apt install systemd-container qemu-user-static" to grab the dependencies you mentioned
- Unzipped your TheC64 X-Windows V3.zip
- mkdir mnt
- sudo mount rootfs.img mnt/
- xhost +
- echo $DISPLAY
:0 - sudo systemd-nspawn -D mnt/
- export DISPLAY=:0
- xclock and xeyes work, nice
As for expanding rootfs.img, still struggling with that:
For expanding the size of the rootfs.img, I tried: dd if=/dev/zero bs=1 count=1024M >> rootfs.img"
That was very slow, so killed it after it added about 100MB extra...
I couldn't figure resize2fs out, tried "resize2fs rootfs.img", but it suggested to run "e2fsck -f rootfs.img" first, I did that, then re-ran resize2fs, but didn't seem to make anything larger when I re-mounted.
Ah well, will have another stab at it tomorrow.
|
|
|
|
Post by gurce on Jul 28, 2020 17:55:40 GMT
|
|
|
|
Post by gurce on Jul 29, 2020 13:09:36 GMT
Ok, for tonight's effort:
sudo losetup --find --show rootfs.img
/dev/loop0
sudo mount /dev/loop0 mnt/ df mnt/ .
1887152KB dd if=/dev/zero bs=1 count=100M >> rootfs.img (I killed it early again, too slow, but just to test it'll work or not)
resize2fs /dev/loop0 df mnt/ . 1921708KB
sudo umount mnt/ sudo losetup -D
Ah ok, so it indeed increased the image size, nice
So tomorrow, I'll try see if there's a faster way to grow the image. The thread mentioned a 'sparse' technique, I'll give that a try...
|
|
|
|
Post by jj0 on Jul 29, 2020 15:43:21 GMT
Ok, for tonight's effort:
sudo losetup --find --show rootfs.img
/dev/loop0
sudo mount /dev/loop0 mnt/ df mnt/ .
1887152KB dd if=/dev/zero bs=1 count=100M >> rootfs.img (I killed it early again, too slow, but just to test it'll work or not)
resize2fs /dev/loop0 df mnt/ . 1921708KB
sudo umount mnt/ sudo losetup -D
Ah ok, so it indeed increased the image size, nice
So tomorrow, I'll try see if there's a faster way to grow the image. The thread mentioned a 'sparse' technique, I'll give that a try...
Try 'bs=100M count=1' that should be quicker. Quick enough for me anyway 😉 |
|
|
|
Post by gurce on Aug 3, 2020 12:10:21 GMT
Okidoke, had some time tonight to give this another stab.
The bs=100M count=10 idea worked nicely, much faster now.
But when I tried:
sudo resize2fs /dev/loop0 The file system is already 484352 (4k) blocks long. Nothing to do!
Hmm, maybe I'm going about this the wrong way, some more googling suggested a different approach:
Aah right, so no dd necessary, simply:
ls -lh rootfs.img
1.9G
resize2fs rootfs.img 3G ls -lh rootfs.img
3.0G
Neato I'll dabble some more tonight with this and see how I fare... |
|
|
|
Post by gurce on Aug 3, 2020 22:21:30 GMT
Ok, last night, managed to build the .rgl files. One thing I did differently (compared to my previous attempt building within qemu) was that instead of switching the 'configure' file to use libpng12 (which was the only version available in the repos), I decided to instead build libpng16 from the source: - www.libpng.org/pub/png/libpng.html
(working inside jj's expanded rootfs.img via systemd-nspawn)
cd /root
tar xvf libpng-1.6.37.tar.gz
cd libpng-1.6.36
sudo apt install zlib1g-dev
./configure --prefix=/opt/libpng-1.6.36
make check
make installHmm, make check not only builds, but runs a lot of tests, which I didn't have the time for, so I ctrl-c'ed them midway, and jumped to "make install".
As for my attempt with the source:
(again, inside jj's expanded rootfs.img via systemd-nspawn)
cd /root
git clone https://github.com/retro-games-ltd/redquark-sixtyfour.git
cd redquark-sixityfour
cd src
git clone https://github.com/retro-games-ltd/vice-2.4.git vice2
sudo apt install pkg-config libasound2-dev libjpeg-dev libpng12-dev bison flex g++
cd ..
PKG_CONFIG_PATH=/opt/libpng-1.6.36/lib/pkgconfig/ ./configure
make
Yeah, maybe that /opt prefix thing I tried for libpng turned out to be a bad idea, as the build had some probs with a vice-file called "pngdrv.c" and being unable to find png.h 
So I just copied all the libpng includes out of my /opt/libpng-1.6.36/include/ folder into /usr/include (I was too lazy/tired to debug it last night)...
If I had a chance to try again, maybe I would skip that libpng prefix setting. I'm guessing it'd then install to "/usr/local/", maybe that'd be good enough...
Anyways, .rgl's built fine, so this morning, I tried it out on my usb-stick via PCU, tweaking the "start.sh" script to point to my freshly built c64emu-gi2.rgl file (available here).
Whew, it worked!
Glad to get this far...
Ok, from here on in, I'll have a few nibbles to try get 3/4-player joystick support working, as time permits |
|
|
|
Post by jj0 on Aug 4, 2020 9:47:16 GMT
I'll remember that, no more faffing about with manually extending rootfs.img. Ok, last night, managed to build the .rgl files. One thing I did differently (compared to my previous attempt building within qemu) was that instead of switching the 'configure' file to use libpng12 (which was the only version available in the repos), I decided to instead build libpng16 from the source: - www.libpng.org/pub/png/libpng.htmlIf I remember correctly I installed libpng16-dev from the installation .deb package. And don't forget about joystick 1 & 2 switching!!!  |
|
|
|
Post by gurce on Aug 4, 2020 14:05:15 GMT
Ok, I had another dabble tonight, with some modest success.
I thought I wouldn't shoot for the moon with the extra 2-joyports via userport just yet, and aim a little lower, as JJ suggested, jus try and swap the joystick ports.
My initial idea was:
Inside "keyboard.c" - keyboard_key_pressed(), I saw a section that listened to the pressing of the 'restore' key, I thought that would be sufficient place to inject a swapping mechanism in for now (it's not perfect, but it'll do for proof of concept).
/* Restore */
if (((key == key_ctrl_restore1) || (key == key_ctrl_restore2))
&& machine_has_restore_key())
{
// <--- Inject my key-swap logic here
keyboard_restore_pressed();
return;
}
I noticed inside "arch/unix/gui/ui_joystick2.c" there is a function called swap_joystick_ports().
static UI_CALLBACK(swap_joystick_ports)
{
int tmp1, tmp2;
if (w != NULL) {
vsync_suspend_speed_eval();
}
resources_get_int("JoyDevice1", &tmp1);
resources_get_int("JoyDevice2", &tmp2);
resources_set_int("JoyDevice1", tmp2);
resources_set_int("JoyDevice2", tmp1);
ui_update_menus();
}
I thought I could perhaps inject something similar at the above-mentioned location, didn't work.
It gave me a sneaky suspicion that Retro Game's joystick device names probably aren't given these names.
So I tried a different tact. Inside "vice2/src/joystick.c", there are two arrays of interest:
BYTE joystick_value[JOYSTICK_NUM + 1] = { 0 };
static BYTE latch_joystick_value[JOYSTICK_NUM + 1] = { 0 };
These are index-1 arrays, where 1st joysticks is at [1], 2nd is at [2], etc...
So I thought of adding swap-logic in the access of these arrays, via any attempt to do so calling my extra 'swap' logic
int swapping = 0;
int getjoyid(int joyport)
{
if (swapping)
{
if (joyport == 1)
joyport = 2;
else if (joyport == 2)
joyport = 1;
}
return joyport;
}
I then toggle this 'swapping' global var inside the 'restore'-key checking code.
I then built the .rgl (available here), dropped it on my USB-stick with PCU's "start.sh" pointing to it.
...and hey presto! It worked! Pressing restore key swaps Joy1 and Joy2
I'm off to bed
|
|
|
|
Post by jj0 on Aug 4, 2020 15:56:04 GMT
Ok, I had another dabble tonight, with some modest success.
I thought I wouldn't shoot for the moon with the extra 2-joyports via userport just yet, and aim a little lower, as JJ suggested, jus try and swap the joystick ports.
My initial idea was:
Inside "keyboard.c" - keyboard_key_pressed(), I saw a section that listened to the pressing of the 'restore' key, I thought that would be sufficient place to inject a swapping mechanism in for now (it's not perfect, but it'll do for proof of concept).
/* Restore */
if (((key == key_ctrl_restore1) || (key == key_ctrl_restore2))
&& machine_has_restore_key())
{
// <--- Inject my key-swap logic here
keyboard_restore_pressed();
return;
}
I noticed inside "arch/unix/gui/ui_joystick2.c" there is a function called swap_joystick_ports().
static UI_CALLBACK(swap_joystick_ports)
{
int tmp1, tmp2;
if (w != NULL) {
vsync_suspend_speed_eval();
}
resources_get_int("JoyDevice1", &tmp1);
resources_get_int("JoyDevice2", &tmp2);
resources_set_int("JoyDevice1", tmp2);
resources_set_int("JoyDevice2", tmp1);
ui_update_menus();
}
I thought I could perhaps inject something similar at the above-mentioned location, didn't work.
It gave me a sneaky suspicion that Retro Game's joystick device names probably aren't given these names.
So I tried a different tact. Inside "vice2/src/joystick.c", there are two arrays of interest:
BYTE joystick_value[JOYSTICK_NUM + 1] = { 0 };
static BYTE latch_joystick_value[JOYSTICK_NUM + 1] = { 0 };
These are index-1 arrays, where 1st joysticks is at [1], 2nd is at [2], etc...
So I thought of adding swap-logic in the access of these arrays, via any attempt to do so calling my extra 'swap' logic
int swapping = 0;
int getjoyid(int joyport)
{
if (swapping)
{
if (joyport == 1)
joyport = 2;
else if (joyport == 2)
joyport = 1;
}
return joyport;
}
I then toggle this 'swapping' global var inside the 'restore'-key checking code.
I then built the .rgl (available here), dropped it on my USB-stick with PCU's "start.sh" pointing to it.
...and hey presto! It worked! Pressing restore key swaps Joy1 and Joy2
I'm off to bed
Wow, that is really cool! This will be loved by many users and might even inspire RGL to add the feature to the official release! So now we need this in two variants, one for each SID type. Do you think you can produce those? |
|
|
|
Post by spannernick on Aug 4, 2020 18:41:15 GMT
Ok, I had another dabble tonight, with some modest success. I thought I wouldn't shoot for the moon with the extra 2-joyports via userport just yet, and aim a little lower, as JJ suggested, jus try and swap the joystick ports. My initial idea was: Inside "keyboard.c" - keyboard_key_pressed(), I saw a section that listened to the pressing of the 'restore' key, I thought that would be sufficient place to inject a swapping mechanism in for now (it's not perfect, but it'll do for proof of concept).
/* Restore */
if (((key == key_ctrl_restore1) || (key == key_ctrl_restore2))
&& machine_has_restore_key())
{
// <--- Inject my key-swap logic here
keyboard_restore_pressed();
return;
}
I noticed inside "arch/unix/gui/ui_joystick2.c" there is a function called swap_joystick_ports().
static UI_CALLBACK(swap_joystick_ports)
{
int tmp1, tmp2;
if (w != NULL) {
vsync_suspend_speed_eval();
}
resources_get_int("JoyDevice1", &tmp1);
resources_get_int("JoyDevice2", &tmp2);
resources_set_int("JoyDevice1", tmp2);
resources_set_int("JoyDevice2", tmp1);
ui_update_menus();
}
I thought I could perhaps inject something similar at the above-mentioned location, didn't work. It gave me a sneaky suspicion that Retro Game's joystick device names probably aren't given these names. So I tried a different tact. Inside "vice2/src/joystick.c", there are two arrays of interest: BYTE joystick_value[JOYSTICK_NUM + 1] = { 0 };
static BYTE latch_joystick_value[JOYSTICK_NUM + 1] = { 0 };
These are index-1 arrays, where 1st joysticks is at [1], 2nd is at [2], etc... So I thought of adding swap-logic in the access of these arrays, via any attempt to do so calling my extra 'swap' logic
int swapping = 0;
int getjoyid(int joyport)
{
if (swapping)
{
if (joyport == 1)
joyport = 2;
else if (joyport == 2)
joyport = 1;
}
return joyport;
}
I then toggle this 'swapping' global var inside the 'restore'-key checking code.
I then built the .rgl (available here), dropped it on my USB-stick with PCU's "start.sh" pointing to it. ...and hey presto! It worked! Pressing restore key swaps Joy1 and Joy2 I'm off to bed
Cool, but would it work on theC64 Mini (I don't think the Restore key is mapped) or only theC64 Maxi, it will not work on TheC64 Maxi PI ,there is no Restore key mapped on a Keyrah..? |
|
|
|
Post by gurce on Aug 4, 2020 20:46:57 GMT
Hehe, thx guys :-)
JJ, ok I can give that a try next. Do you recall the tweaks needed to support the other sid? If so, I could try replicate those steps. Do you think it'd be worth compiling in both sids (so they could be swapped via shortcut key too?). Or was memory-constraints the reason for compiling them seperately?
Spannernick, ah ok, i'll try it on the mini when I get the chance, to confirm one way or the other :-) As for choice of restore-key, that was just a temporary/easy choice because I saw the code already had a check for it and I just could piggy-back off it. Ideally, we ought to pick some key-combo to trigger this. Or maybe even a button combo ((I liked your multibutton techniques in pcu afterall ;-)).
Some more general thoughts, I was considering forking their github repo to commit these changes, but I just wonder if retro games had some sensitivity to this. Technically, it's open-source and I shouldn't worry, but I suppose I just want to play nice. Maybe I should ask them how they'd feel. Perhaps I could offer them a gentler alternative, of not hosting the fork on github, but elsewhere, still public, but not promoting it heavily, just a url mention in this thread perhaps.
|
|
|
|
Post by jj0 on Aug 4, 2020 21:47:41 GMT
Hehe, thx guys :-) JJ, ok I can give that a try next. Do you recall the tweaks needed to support the other sid? If so, I could try replicate those steps. Do you think it'd be worth compiling in both sids (so they could be swapped via shortcut key too?). Or was memory-constraints the reason for compiling them seperately? Spannernick, ah ok, i'll try it on the mini when I get the chance, to confirm one way or the other :-) As for choice of restore-key, that was just a temporary/easy choice because I saw the code already had a check for it and I just could piggy-back off it. Ideally, we ought to pick some key-combo to trigger this. Or maybe even a button combo ((I liked your multibutton techniques in pcu afterall ;-)). Some more general thoughts, I was considering forking their github repo to commit these changes, but I just wonder if retro games had some sensitivity to this. Technically, it's open-source and I shouldn't worry, but I suppose I just want to play nice. Maybe I should ask them how they'd feel. Perhaps I could offer them a gentler alternative, of not hosting the fork on github, but elsewhere, still public, but not promoting it heavily, just a url mention in this thread perhaps. For SID versions see: thec64community.online/post/3455/threadRegarding forking, asking first can't hurt. |
|
|
|
Post by spannernick on Aug 5, 2020 12:42:31 GMT
On the SID 8580 version of rgl emulator thats in PCU, cause its using fast, on some games the music sounds like its missing samples, it needs to be using ReSID not Fast SID. then the music plays properly, tested it on Vice 2.4 emulator to see why it was doing it, so it 8580(ReSID), this is why I didn't enable it in PCU. it works ok with Jars Revenge(a Yars Revenge remake on the C64), it has some wicked music, it don't sound as good using SID 6581 cause it was made for the SID8580.. Fast SID  ReSID  |
|
|
|
Post by gurce on Aug 6, 2020 13:01:40 GMT
Ok I did ping them on this, explaining the situation, they responded with an affirmative emoji, so I'll interpret that as a quiet ok :-) So I'll aim to keep the fork a quiet one and won't publicise it, will just mention it here within this thread. Ok, now I'm wondering, should I fork to my personal github account, or do we prefer sharing a forked repo between us in a github group? I'm leaning towards the latter, happy to add you guys (jj and spannernick) as admins of it. I could name the group "pcu-mods" or something like that. Looking into now... Oh, one thing I forgot to check with my mod, yes, I was successful in swapping the joystick directions and main fire button, but I didn't check whether the "extra" buttons had been swapped between the joysticks or not. I'd better look into that at some stage too. Time a little limited, but I'm squeezing things in where I can.
Ok, fork created here, under a group-name of "pcu-mods":
jj and @spannernick, let me know your github usernames and I'll add you in
Also, I just pushed my work-in-progress mod into a #1-joyswap branch, available here:
That's all I can muster tonight |
|
|
|
Post by spannernick on Aug 7, 2020 19:28:15 GMT
My name is on Github... CommodoreOS .. |
|
|
|
Post by jj0 on Aug 7, 2020 20:52:47 GMT
I was much less imaginative than Spannernick so I'm just jj-0 😉
|
|
|
|
Post by spannernick on Aug 7, 2020 22:14:27 GMT
I was going to release COS32bit v1.5.1 on GitHub then realized it was too big to release on there.. |
|
|
|
Post by gurce on Aug 8, 2020 2:45:05 GMT
Cheers guys, I sent the member invites out now, with owner/admin privileges. Hopefully you'll see something pop up in your emails @spannernick - Ah nice, I never got a chance to experience CommodoreOS, one of these days I'd enjoy having a dabble. Yeah, it'd be quite cool to see it run on theC64 one day, if the hardware has enough grunt for it |
|
|
|
Post by spannernick on Aug 20, 2020 11:45:36 GMT
Cheers guys, I sent the member invites out now, with owner/admin privileges. Hopefully you'll see something pop up in your emails @spannernick - Ah nice, I never got a chance to experience CommodoreOS, one of these days I'd enjoy having a dabble. Yeah, it'd be quite cool to see it run on theC64 one day, if the hardware has enough grunt for it Can you look at this post on PCU and reply please, when you have the time, cause I added the joystick swap to PCU, Thanks.. .. thec64community.online/post/4919/threadUsers are asking for the Restore key to be changed to the key at the top left of THEC64 Maxi keyboard "<--" next to the "1" key. |
|
|
|
Post by spannernick on Aug 20, 2020 13:20:10 GMT
Cheers guys, I sent the member invites out now, with owner/admin privileges. Hopefully you'll see something pop up in your emails @spannernick - Ah nice, I never got a chance to experience CommodoreOS, one of these days I'd enjoy having a dabble. Yeah, it'd be quite cool to see it run on theC64 one day, if the hardware has enough grunt for it Can you use Linux Mint 20 to compile the c64emu.rgl file, I have to use qemu-user-static on it right..? If I can compile it then I could change the key to "<--" but what would you put for the left arrow key..? I need a walkthrough on how to compile it with qemu-user-static.. |
|
|
|
Post by gurce on Aug 20, 2020 13:31:36 GMT
I'm thinking a full read of the thread will kinda be like a walkthrough, but with my failed efforts along with my successes :-) So you'll have to skip over my failed attempts and focus on the working attempts, which my final efforts also included building it via qemu-user-static i think :-)
As for how to decide upon a key to replace restore, I didn't have the energy/time to figure out how the keys were mapped. I picked restore because the code already had a pre-existing test for the restore key (saving me the effort of having to figure out what the key mapping was), so was a temporary/quick way I went about it :-)
|
|
|
|
Post by spannernick on Aug 22, 2020 12:35:58 GMT
Idea.. instead of changing the key in the emulator you could change it in the VICE key map file so restore becomes a different key.
|
|
|
|
Post by jj0 on Aug 23, 2020 5:51:23 GMT
Idea.. instead of changing the key in the emulator you could change it in the VICE key map file so restore becomes a different key. But then it would still function as 'RESTORE' wouldn't it? |
|
. Though if you do:
