|
|
Post by grasshopper on Dec 3, 2020 16:06:14 GMT
Hi, I've been experimenting with booting (most of) the firmware from a USB flash drive. I've done this by modifying the init script that's in the ramdisk image on nanda. I've added a few lines of code to the beginning of the script that essentially does the following:
- It first attempts to mount a USB flash drive.
- If the mount operation succeeds, then it looks in the root of the USB drive for a file called usb_init.sh.
- If the usb_init.sh file is present, then it runs that file as a shell script.
- If the USB drive couldn't be mounted, or the usb_init.sh file doesn't exist, then the init script continues to run in the normal way (i.e. it will boot the stock firmware on the nandb partition).
I haven't been brave enough to overwrite the nanda partition on my C64 Maxi. So, I'm trying this out using FEL mode, as a proof of concept. I've managed to get the stock C64 Maxi nandb image to run from a USB drive. However, for some reason, I can't get the Vic20 image to work. I'm using the image provided by spannernick. Can any of you offer any suggestions as to why the Vic20 image won't work? I've attached the following:
- My modified init script that goes in the root directory of the ramdisk.
- A sample usb_init.sh script that goes on the USB flash drive.
I wanted to attach my modified nanda image as well. Unfortunately, the forum software says it's too large. Thanks in advance. Attachments:sample_scripts.zip (1.03 KB)
|
|
|
|
Post by spannernick on Dec 3, 2020 17:00:19 GMT
if you signup up with Cloudinary(its free) you can use its plugin on the forum to upload and share bigger files, the plugin is in your profile(press the Edit Profile button on the right) under your Profile & Settings and Settings Tab, there is a link on the Cloudinary pluging page there so you can make account. I use the plugin btw and have signed up already...  nanda on THEC64 Maxi is different to the nanda on THEVIC20 so maybe that why its not working, I could not get THEVIC20 firmware to boot with THEC64 Maxi's nanda on my OPI but when I used the nanda from THEVIC20 then it worked. |
|
|
|
Post by jj0 on Dec 3, 2020 18:01:47 GMT
Hi, I've been experimenting with booting (most of) the firmware from a USB flash drive. I've done this by modifying the init script that's in the ramdisk image on nanda. I've added a few lines of code to the beginning of the script that essentially does the following:
- It first attempts to mount a USB flash drive.
- If the mount operation succeeds, then it looks in the root of the USB drive for a file called usb_init.sh.
- If the usb_init.sh file is present, then it runs that file as a shell script.
- If the USB drive couldn't be mounted, or the usb_init.sh file doesn't exist, then the init script continues to run in the normal way (i.e. it will boot the stock firmware on the nandb partition).
I haven't been brave enough to overwrite the nanda partition on my C64 Maxi. So, I'm trying this out using FEL mode, as a proof of concept. I've managed to get the stock C64 Maxi nandb image to run from a USB drive. However, for some reason, I can't get the Vic20 image to work. I'm using the image provided by spannernick. Can any of you offer any suggestions as to why the Vic20 image won't work? I've attached the following:
- My modified init script that goes in the root directory of the ramdisk.
- A sample usb_init.sh script that goes on the USB flash drive.
I wanted to attach my modified nanda image as well. Unfortunately, the forum software says it's too large. Thanks in advance. I'm unable to look at the scripts at the moment but the Maxi and VIC-20 have different kernels if I remember correctly. So if you use the Maxi kernel to boot the VIC-20's rootfs it's likely that the Mali kernel module won't load and therefore the64 won't start. Not that the kernels are actually different (I think) wrt capabilities, but I think RGL recompiles the kernel and modules for new models, so symbol versions etc will differ. Nice idea btw. But why don't you want to try it on your nanda, with the OTG fake firmware update or the Maxi/VIC-20 Rescue method you can restore the nanda if something goes really wrong. I have a different method in the works (already working on the Mini, not yet on the Maxi but the Rescue stuff gave me some inspiration) which I hope to share soon. |
|
|
|
Post by grasshopper on Dec 3, 2020 21:19:18 GMT
if you signup up with Cloudinary(its free) you can use its plugin on the forum to upload and share bigger files, the plugin is in your profile(press the Edit Profile button on the right) under your Profile & Settings and Settings Tab, there is a link on the Cloudinary pluging page there so you can make account. I use the plugin btw and have signed up already... nanda on THEC64 Maxi is different to the nanda on THEVIC20 so maybe that why its not working, I could not get THEVIC20 firmware to boot with THEC64 Maxi's nanda on my OPI but when I used the nanda from THEVIC20 then it worked. I've just signed up with Cloudinary. Unfortunately, there still appears to be a 10 MB upload limit. |
|
|
|
Post by grasshopper on Dec 3, 2020 21:37:20 GMT
But why don't you want to try it on your nanda, with the OTG fake firmware update or the Maxi/VIC-20 Rescue method you can restore the nanda if something goes really wrong.
I guess I'm just slightly paranoid. I'm afraid something unexpected might happen if the new nanda is a different size to the old one.
That's one of the reasons why I'd like to be able to backup the entire nand chip. It would provide an extra line of defence if something went wrong.
|
|
|
|
Post by jj0 on Dec 3, 2020 21:40:30 GMT
But why don't you want to try it on your nanda, with the OTG fake firmware update or the Maxi/VIC-20 Rescue method you can restore the nanda if something goes really wrong.
I guess I'm just slightly paranoid. I'm afraid something unexpected might happen if the new nanda is a different size to the old one.
That's one of the reasons why I'd like to be able to backup the entire nand chip. It would provide an extra line of defence if something went wrong.
If it's too big, bigger than the ~16MB size of the nanda partition, it will fail to write after ~16MB,so nothing to worry about. |
|
|
|
Post by spannernick on Dec 3, 2020 21:51:19 GMT
I guess I'm just slightly paranoid. I'm afraid something unexpected might happen if the new nanda is a different size to the old one. That's one of the reasons why I'd like to be able to backup the entire nand chip. It would provide an extra line of defence if something went wrong.
If it's too big, bigger than the ~16MB size of the nanda partition, it will fail to write after ~16MB,so nothing to worry about. Could you back up the whole nand with nand_rw and the FELL Mode Rescue Boot on the Maxi/VIC20, I don't mind trying it... jj0..? |
|
|
|
Post by spannernick on Dec 3, 2020 22:07:06 GMT
if you signup up with Cloudinary(its free) you can use its plugin on the forum to upload and share bigger files, the plugin is in your profile(press the Edit Profile button on the right) under your Profile & Settings and Settings Tab, there is a link on the Cloudinary pluging page there so you can make account. I use the plugin btw and have signed up already... nanda on THEC64 Maxi is different to the nanda on THEVIC20 so maybe that why its not working, I could not get THEVIC20 firmware to boot with THEC64 Maxi's nanda on my OPI but when I used the nanda from THEVIC20 then it worked. I've just signed up with Cloudinary. Unfortunately, there still appears to be a 10 MB upload limit. Upload it here onedrive.live.com/?authkey=%21AFT%5FY2kl0G331%5F8&id=DE6843E1C82A96C8%2160427&cid=DE6843E1C82A96C8 to shear it, then add the link to your first post.. |
|
|
|
Post by grasshopper on Dec 3, 2020 22:17:11 GMT
OK. Here's the link:
<iframe src="https://onedrive.live.com/embed?cid=DE6843E1C82A96C8&resid=DE6843E1C82A96C8%2160428&authkey=APQ23Dew-vgNsHI" width="98" height="120" frameborder="0" scrolling="no"></iframe>
|
|
|
|
Post by jj0 on Dec 3, 2020 22:45:33 GMT
If it's too big, bigger than the ~16MB size of the nanda partition, it will fail to write after ~16MB,so nothing to worry about. Could you back up the whole nand with nand_rw and the FELL Mode Rescue Boot on the Maxi/VIC20, I don't mind trying it... jj0..? Yes, nand_rw is meant to backup the entire nand. |
|
|
|
Post by grasshopper on Dec 4, 2020 20:21:14 GMT
Just a quick update.
As an experiment, I tried applying my init script change to a Vic20 nanda image. I then booted the image via FEL mode, and got it to switch root to a Vic20 nandb image on my USB drive.
Voila! I'm now successfully running the Vic20 firmware on my C64 Maxi. I'm actually liking the Vic20 colour scheme a little more.
I guess that proves jj0's theory that the C64's kernel is incompatible with the Vic20's modules (and presumably vice versa). I had no idea that could be an issue. Ironically, by playing around with this device, I'm learning more about Linux than I am about C64s!
|
|
|
|
Post by grasshopper on Dec 4, 2020 20:31:51 GMT
With regards to the next step, I'm considering two possibilities:
I could write a script that would detect whether it's running on a C64 Maxi or a Vic20, and then overmount the directory on nandb containing the modules with a directory containing either C64 or Vic20 modules, as applicable.
Alternatively, I'm wondering whether it would be possible to get the stock kernel to boot another kernel and ramdisk from a USB drive. If that were possible, it would open up all sorts of possibilities. I've done some googling on this subject, and there appears to be a program called kexec which does this. But it comes with a lot of caveats, and I'm not even sure whether it works on ARM devices.
|
|
|
|
Post by jj0 on Dec 5, 2020 8:38:21 GMT
Just a quick update. As an experiment, I tried applying my init script change to a Vic20 nanda image. I then booted the image via FEL mode, and got it to switch root to a Vic20 nandb image on my USB drive. Voila! I'm now successfully running the Vic20 firmware on my C64 Maxi. I'm actually liking the Vic20 colour scheme a little more. I guess that proves jj0's theory that the C64's kernel is incompatible with the Vic20's modules (and presumably vice versa). I had no idea that could be an issue. Ironically, by playing around with this device, I'm learning more about Linux than I am about C64s! I've learned a lot about kernels, modules, FEL, nand, etc since I bought my Mini :-) Pity I hardly play any games on it, most of the time I'm playing with the Linux side. Btw, if you want to make your method Maxi and VIC-20 proof you can try to find a way to use 'insmod - f <path+modulename.ko>' or 'modprobe --force' when the modules are inserted, this forces them be loaded regardless of symbol version differences or kernel module option differences. You could do this in your usb_init script as you know which module(s) will need to be loaded. Then the normal load in the /etc/init.d scripts will still fail but that won't matter. You probably need a different insmod/modprobe as the standard ones on the Maxi don't support the -f/--force options but I think you can get it from my Rescue nanda initrd. With regards to the next step, I'm considering two possibilities: I could write a script that would detect whether it's running on a C64 Maxi or a Vic20, and then overmount the directory on nandb containing the modules with a directory containing either C64 or Vic20 modules, as applicable. Alternatively, I'm wondering whether it would be possible to get the stock kernel to boot another kernel and ramdisk from a USB drive. If that were possible, it would open up all sorts of possibilities. I've done some googling on this subject, and there appears to be a program called kexec which does this. But it comes with a lot of caveats, and I'm not even sure whether it works on ARM devices. I tried kexec on the CHA, but couldn't get it to work. But maybe you can get it to work on the Maxi. I have a different method of booting alternative kernels or whole other Linux distributions from USB, not sure whether I should call it Trojan Horse os Matryoshka Doll or even Matryoshka Horse : - I've created a nanda that has a modern u-boot (that supports USB drives) instead of the kernel, and the original nanda as ramdisk and written this to my Mini's nanda
- When booting, the Mini's normal u-boot loads nanda and starts the modern u-boot
- The modern u-boot checks for something bootable (so kernel + boot instructions) on the USB drive and if available boots that
- If no bootable kernel is available the modern u-boot boots the original nanda (which was loaded masquerading as ramdisk) and the Mini starts the carousel as usual
This works great on the Mini, but on the Maxi I had the same kernel crashes as I had on the FEL Rescue method. It still loaded the Carousel fine as far as I could see but I didn't want to release it with the crashes. But as these crashes are fixed for the Rescue method I can probably fix them for this approach as well.
The only caveat is that the Linux distribution has to support using the USB drive as rootfs, meaning that this has to be compiled in the kernel and not be a separate module that's loaded after the rootfs is mounted. However that's still fixable by using a ramdisk that loads the required modules if the distribution doen't use a ramdisk or modifying an existing ramdisk if it does.
I'll see if I can pick this up again and release it in the coming week or so. |
|
|
|
Post by spannernick on Dec 5, 2020 14:19:19 GMT
Just a quick update. As an experiment, I tried applying my init script change to a Vic20 nanda image. I then booted the image via FEL mode, and got it to switch root to a Vic20 nandb image on my USB drive. Voila! I'm now successfully running the Vic20 firmware on my C64 Maxi. I'm actually liking the Vic20 colour scheme a little more. I guess that proves jj0's theory that the C64's kernel is incompatible with the Vic20's modules (and presumably vice versa). I had no idea that could be an issue. Ironically, by playing around with this device, I'm learning more about Linux than I am about C64s! I've learned a lot about kernels, modules, FEL, nand, etc since I bought my Mini :-) Pity I hardly play any games on it, most of the time I'm playing with the Linux side. Btw, if you want to make your method Maxi and VIC-20 proof you can try to find a way to use 'insmod - f <path+modulename.ko>' or 'modprobe --force' when the modules are inserted, this forces them be loaded regardless of symbol version differences or kernel module option differences. You could do this in your usb_init script as you know which module(s) will need to be loaded. Then the normal load in the /etc/init.d scripts will still fail but that won't matter. You probably need a different insmod/modprobe as the standard ones on the Maxi don't support the -f/--force options but I think you can get it from my Rescue nanda initrd. With regards to the next step, I'm considering two possibilities: I could write a script that would detect whether it's running on a C64 Maxi or a Vic20, and then overmount the directory on nandb containing the modules with a directory containing either C64 or Vic20 modules, as applicable. Alternatively, I'm wondering whether it would be possible to get the stock kernel to boot another kernel and ramdisk from a USB drive. If that were possible, it would open up all sorts of possibilities. I've done some googling on this subject, and there appears to be a program called kexec which does this. But it comes with a lot of caveats, and I'm not even sure whether it works on ARM devices. I tried kexec on the CHA, but couldn't get it to work. But maybe you can get it to work on the Maxi. I have a different method of booting alternative kernels or whole other Linux distributions from USB, not sure whether I should call it Trojan Horse os Matryoshka Doll or even Matryoshka Horse : - I've created a nanda that has a modern u-boot (that supports USB drives) instead of the kernel, and the original nanda as ramdisk and written this to my Mini's nanda
- When booting, the Mini's normal u-boot loads nanda and starts the modern u-boot
- The modern u-boot checks for something bootable (so kernel + boot instructions) on the USB drive and if available boots that
- If no bootable kernel is available the modern u-boot boots the original nanda (which was loaded masquerading as ramdisk) and the Mini starts the carousel as usual
This works great on the Mini, but on the Maxi I had the same kernel crashes as I had on the FEL Rescue method. It still loaded the Carousel fine as far as I could see but I didn't want to release it with the crashes. But as these crashes are fixed for the Rescue method I can probably fix them for this approach as well.
The only caveat is that the Linux distribution has to support using the USB drive as rootfs, meaning that this has to be compiled in the kernel and not be a separate module that's loaded after the rootfs is mounted. However that's still fixable by using a ramdisk that loads the required modules if the distribution doen't use a ramdisk or modifying an existing ramdisk if it does.
I'll see if I can pick this up again and release it in the coming week or so. You be able to do it mate, it will just take time, once everything falls in into place then it will work on the Maxi.. If you can't do it no one can.. your the Linux Brainbox.. Making the FEL Mode Rescue Boot on the Maxi should help you with this cause as you do things you learn from it.. |
|
|
|
Post by spannernick on Dec 6, 2020 0:05:15 GMT
Can't you use the insmod from the xpad driver you shared..?
|
|
|
|
Post by jj0 on Dec 6, 2020 8:44:30 GMT
Can't you use the insmod from the xpad driver you shared..? Yes, good idea, that one should work as well. Btw, the module-related commands (insmod, modprobe, rmmod, modinfo, lsmod) are all instances of the same command (kmod) so if you need the other commands you can copy them from one to the other command name on a FAT32 filesystem, or just symbolic link them (ln -s) on an ext4 filesystem. |
|
|
|
Post by grasshopper on Dec 6, 2020 20:19:45 GMT
I tried kexec on the CHA, but couldn't get it to work. But maybe you can get it to work on the Maxi. I have a different method of booting alternative kernels or whole other Linux distributions from USB, not sure whether I should call it Trojan Horse os Matryoshka Doll or even Matryoshka Horse : - I've created a nanda that has a modern u-boot (that supports USB drives) instead of the kernel, and the original nanda as ramdisk and written this to my Mini's nanda
- When booting, the Mini's normal u-boot loads nanda and starts the modern u-boot
- The modern u-boot checks for something bootable (so kernel + boot instructions) on the USB drive and if available boots that
- If no bootable kernel is available the modern u-boot boots the original nanda (which was loaded masquerading as ramdisk) and the Mini starts the carousel as usual
This works great on the Mini, but on the Maxi I had the same kernel crashes as I had on the FEL Rescue method. It still loaded the Carousel fine as far as I could see but I didn't want to release it with the crashes. But as these crashes are fixed for the Rescue method I can probably fix them for this approach as well.
The only caveat is that the Linux distribution has to support using the USB drive as rootfs, meaning that this has to be compiled in the kernel and not be a separate module that's loaded after the rootfs is mounted. However that's still fixable by using a ramdisk that loads the required modules if the distribution doen't use a ramdisk or modifying an existing ramdisk if it does.
I'll see if I can pick this up again and release it in the coming week or so. That sounds promising. It would be awesome if we could boot into something like Retro Pie.
With regards to kexec, I read somewhere that it will only work if the first kernel that gets booted supports it. It's possible that the stock RGL kernel was compiled without support for kexec.
If that's the case, then the only solution would be to build a new kernel with the source provided by RGL. Unfortunately, they haven't sent it to me yet. In fact they haven't even cashed my cheque. Maybe they're working from home because of the pandemic.
I sent them a chase-up email earlier today. But I'm not confident I'll get a reply as they didn't respond to my previous email.
|
|
|
|
Post by jj0 on Dec 6, 2020 20:25:41 GMT
I tried kexec on the CHA, but couldn't get it to work. But maybe you can get it to work on the Maxi. I have a different method of booting alternative kernels or whole other Linux distributions from USB, not sure whether I should call it Trojan Horse os Matryoshka Doll or even Matryoshka Horse : - I've created a nanda that has a modern u-boot (that supports USB drives) instead of the kernel, and the original nanda as ramdisk and written this to my Mini's nanda
- When booting, the Mini's normal u-boot loads nanda and starts the modern u-boot
- The modern u-boot checks for something bootable (so kernel + boot instructions) on the USB drive and if available boots that
- If no bootable kernel is available the modern u-boot boots the original nanda (which was loaded masquerading as ramdisk) and the Mini starts the carousel as usual
This works great on the Mini, but on the Maxi I had the same kernel crashes as I had on the FEL Rescue method. It still loaded the Carousel fine as far as I could see but I didn't want to release it with the crashes. But as these crashes are fixed for the Rescue method I can probably fix them for this approach as well.
The only caveat is that the Linux distribution has to support using the USB drive as rootfs, meaning that this has to be compiled in the kernel and not be a separate module that's loaded after the rootfs is mounted. However that's still fixable by using a ramdisk that loads the required modules if the distribution doen't use a ramdisk or modifying an existing ramdisk if it does.
I'll see if I can pick this up again and release it in the coming week or so. That sounds promising. It would be awesome if we could boot into something like Retro Pie.
With regards to kexec, I read somewhere that it will only work if the first kernel that gets booted supports it. It's possible that the stock RGL kernel was compiled without support for kexec.
If that's the case, then the only solution would be to build a new kernel with the source provided by RGL. Unfortunately, they haven't sent it to me yet. In fact they haven't even cashed my cheque. Maybe they're working from home because of the pandemic.
I sent them a chase-up email earlier today. But I'm not confident I'll get a reply as they didn't respond to my previous email.
Maybe shaunbebbers can provide some insight in where they are with providing the source? It's really the one thing where RGL is lacking, I feel they provide great support for the various models with their firmware upgrades and new games, but not so much with adhering to the license of the software they're using in their products. |
|
|
|
Post by shaunbebbers on Dec 8, 2020 11:25:59 GMT
That sounds promising. It would be awesome if we could boot into something like Retro Pie.
With regards to kexec, I read somewhere that it will only work if the first kernel that gets booted supports it. It's possible that the stock RGL kernel was compiled without support for kexec.
If that's the case, then the only solution would be to build a new kernel with the source provided by RGL. Unfortunately, they haven't sent it to me yet. In fact they haven't even cashed my cheque. Maybe they're working from home because of the pandemic.
I sent them a chase-up email earlier today. But I'm not confident I'll get a reply as they didn't respond to my previous email.
Maybe shaunbebbers can provide some insight in where they are with providing the source? It's really the one thing where RGL is lacking, I feel they provide great support for the various models with their firmware upgrades and new games, but not so much with adhering to the license of the software they're using in their products. Hello, You may look here: www.c64-wiki.com/wiki/THEC64MiniIf you require the Open GL source code please contact the support email address as that is handled by someone else. Many thanks, Shaun. |
|
|
|
Post by spannernick on Dec 8, 2020 12:50:20 GMT
Thats pointless, they do not respond to you, they don't reply, they provide update cause THEC64 Mini, at the beginning only played carousel games in it.. look at The Carousel v1.0.5 in PCUAE, it has no file Loader, I was here at the beginning and users didn't like it, it could only play one file THEC64-drive8.d64(wow I know the name of by heart now), it says that on that wiki page too, it took them a while to make the USB File Loader that came out ib the 1.1.0 update, 1.0.6, 1.0.7, 1.0.8, 1.0.9, 1.1.0. USB file loader came out on 9th October 2018 when the US version of thec64 Mini came out, it took them 6 months to make the USB file Loader, from when it was released on 28th March 2018 in Europe. and I know who RGL are and where they came from too, I like to know who I buying from... RCL, I have a ZX Spectrum Vega too so know what happed to that company, they left RCL to make RGL and killed off ZX Vega Plus handheld, the difference between RCL and RGL is RGL has a parter Roch Media, RCL had no one to keep them in check so could do what they wanted to do, they had to much freedom so took backers money and didn't make the product. At the end of the day they making the products for one thing only really, Money.. to make money from them, that why products are made, I worked in retail and at Argos(https://www.argos.co.uk) and did a retail course(before you could work in Argos you have to do a course in retail) so know how it works, in the late 80s, I use to fix C64 in a computer shop, at the time alot of them, the ICs would blow cause of the Power Brick and the 5v in them overvolting so would have to replace the ICs in them a lot..  It even happened to my C64C in the 90s, its when it will happen not if, it happens to all power bricks for the C64, with THEC64 Maxi you don't have that problem at least. They might not be replying cause of Luton beaning in Tier 3 cause Luton has hi Covid cases and if your in Tier 3 everything is closed(Shops, Bars and that), London is in tier 2 so everything is open. I see things how they are, I am Autistic. |
|
|
|
Post by kugelblitz on Dec 8, 2020 14:27:31 GMT
|
|
|
|
Post by grasshopper on Dec 8, 2020 17:10:28 GMT
Maybe shaunbebbers can provide some insight in where they are with providing the source? It's really the one thing where RGL is lacking, I feel they provide great support for the various models with their firmware upgrades and new games, but not so much with adhering to the license of the software they're using in their products. Hello, You may look here: www.c64-wiki.com/wiki/THEC64MiniIf you require the Open GL source code please contact the support email address as that is handled by someone else. Many thanks, Shaun. Hi Shaun,
I did actually write a letter to RGL on the 16th November 2020 to request the source code, and I enclosed a cheque for £5 to cover RGL's expenses.
I basically followed the instructions detailed in FAQ #18 on RGL's website:
To date, I have not received a reply to my letter. I have also not had a response to two emails that I sent RGL using the form on your website.
I would be grateful if you could chase this up for me. I'm not in a particular hurry. However, I would at least like confirmation that my letter has been received, and that the source code will be sent to me in due course.
Thanks
|
|
|
|
Post by grasshopper on Dec 11, 2020 16:55:45 GMT
Hi shaunbebbers , Did you see my earlier post above? I have still not received any communication from RGL regarding my request for the source code. Can you chase this up for me please? I realise it's not your direct responsibility. However, as you're the only employee of RGL who communicates with the user community, I'm not sure who else to turn to. |
|
|
|
Post by grasshopper on Feb 1, 2021 18:11:12 GMT
Hi shaunbebbers , In the message that you posted on the 15th December 2020 (that for some reason you subsequently deleted) you promised to chase up my request for the source code with the RGL management team. Can you tell me whether you did this, and if so, what their response was? I am disappointed to note that my cheque has still not been cashed.
At this point, I would hope to receive the source code for the latest version of the firmware (i.e. version 1.5.1).
Thanks
|
|
|
|
Post by shaunbebbers on Feb 1, 2021 18:18:46 GMT
Hi shaunbebbers , In the message that you posted on the 15th December 2020 (that for some reason you subsequently deleted) you promised to chase up my request for the source code with the RGL management team. Can you tell me whether you did this, and if so, what their response was? I am disappointed to note that my cheque has still not been cashed.
At this point, I would hope to receive the source code for the latest version of the firmware (i.e. version 1.5.1).
Thanks
I mentioned it to them at the time and will mention it again before I go. But any decision is out of my hands of course. Thanks, Shaun. |
|
|
|
Post by grasshopper on Feb 1, 2021 18:53:34 GMT
Hi shaunbebbers , In the message that you posted on the 15th December 2020 (that for some reason you subsequently deleted) you promised to chase up my request for the source code with the RGL management team. Can you tell me whether you did this, and if so, what their response was? I am disappointed to note that my cheque has still not been cashed.
At this point, I would hope to receive the source code for the latest version of the firmware (i.e. version 1.5.1).
Thanks
I mentioned it to them at the time and will mention it again before I go. But any decision is out of my hands of course. Thanks, Shaun.
OK. Thanks
|
|
It even happened to my C64C in the 90s, its when it will happen not if, it happens to all power bricks for the C64, with THEC64 Maxi you don't have that problem at least.
