|
Post by ch1ller on Oct 11, 2018 10:32:44 GMT
Hi. I am Swingflip, the guy from that video. I am part of a team that run the community and one of the head devs for the (S)NESC scene. We are looking to extend our community and software cross platform to other "classic" systems. I always had a soft spot for the commodore 64 and the specs for the c64 mini are pretty good. I am pretty confident that we will be able to come up with a simple to use interface like we have for the nintendo classics. I got most of the scripts sorted and the custom environments and libraries sorted. I think PS1 emulation on it will be a stretch but 8/16bit emulation will work perfectly fine. I just need to rip the UBOOT from the NAND and we will work on a UARTless solution. You will be able to connect to the PC directly with the usb and telnet to the device. The hack will be injected and flashed to nand first boot by booting in FEL using the uboot button and connecting to the PC. I will rebuild the NANDB image so it nulls the root password too. You wouldn't need a UART or serious technological knowledge to inject the hack on the console (or flash back to stock!) Anyway nice to see you guys and I will keep you updated with stuff. BTW if anyone already has the uboot ripped from the C64 please let me know! (It is likely a slightly modified stock A20 uboot) Great man. *thumbs up* It would be nice, if the User Interface also had some optional Joystick adding (like for the Competition Pro USB which many c64 retro fans have or some of the Gamepads which other use (like INNEXT), or some simple way for adding other joysticks to gamecontrollerdb which are not yet in there) I have also modded my mini so for me is no problem adding Joysticks, but there are a lot out there always asking how they could add a Joystick Cheers ch1ller
|
|
|
Post by swingflip on Oct 11, 2018 19:24:04 GMT
Hi ch1ller thanks. Yeah I think the solution would be leaving the majority of the nand as RO but have a certain portion of the nand RW. The idea being that on boot the RW sub directories are "overmounted" on top of the RO directories enabling users to effectively add their own content whilst keeping the majority of the existing nand intact.
|
|
|
Post by ch1ller on Oct 11, 2018 20:50:05 GMT
Hi ch1ller thanks. Yeah I think the solution would be leaving the majority of the nand as RO but have a certain portion of the nand RW. The idea being that on boot the RW sub directories are "overmounted" on top of the RO directories enabling users to effectively add their own content whilst keeping the majority of the existing nand intact. Mhh maybe you will then also encounter another Problem adding games which has to be patched/fixed. As far as i remember, there was a Game Limit of 100 in the Carousel and if you added your own games to the mini itself and came over the 100 Games, then you had to delete/move some of the Games which came with the mini to not exceed the 100. So keep that in mind too.
|
|
|
Post by darbyram on Oct 11, 2018 21:05:59 GMT
Hi ch1ller thanks. Yeah I think the solution would be leaving the majority of the nand as RO but have a certain portion of the nand RW. The idea being that on boot the RW sub directories are "overmounted" on top of the RO directories enabling users to effectively add their own content whilst keeping the majority of the existing nand intact. Mhh maybe you will then also encounter another Problem adding games which has to be patched/fixed. As far as i remember, there was a Game Limit of 100 in the Carousel and if you added your own games to the mini itself and came over the 100 Games, then you had to delete/move some of the Games which came with the mini to not exceed the 100. So keep that in mind too. Well i have 110 on my usb boot method, so hopefully if the mod includes usb boot it may be more ;-)
|
|
|
Post by groepaz on Oct 12, 2018 20:36:33 GMT
"Yeah I think the solution would be leaving the majority of the nand as RO but have a certain portion of the nand RW.
The idea being that on boot the RW sub directories are "overmounted" on top of the RO directories enabling users to effectively add their own content whilst keeping the majority of the existing nand intact."
yeah, if you manage to add some script to the startup sequence, you can always just mount the usb stick over various interesting parts of the filesystem, no need to flash random stuff all the time.
|
|
|
Post by swingflip on Oct 15, 2018 10:50:17 GMT
Hi ch1ller thanks. Yeah I think the solution would be leaving the majority of the nand as RO but have a certain portion of the nand RW. The idea being that on boot the RW sub directories are "overmounted" on top of the RO directories enabling users to effectively add their own content whilst keeping the majority of the existing nand intact. Mhh maybe you will then also encounter another Problem adding games which has to be patched/fixed. As far as i remember, there was a Game Limit of 100 in the Carousel and if you added your own games to the mini itself and came over the 100 Games, then you had to delete/move some of the Games which came with the mini to not exceed the 100. So keep that in mind too.
Good to know. I recently picked up the c64 mini to mod so I haven't actually had much involvement with the carousel. We have a 40-60 game limit on the (S)NESC before the memory leak becomes too much for the console so we have folder elements which swap what's loaded into "memory" at that one time and reload the "carousel" binary to display the next set of 40-60 elements. I assume this might be the case also for the C64.
|
|
|
Post by swingflip on Oct 15, 2018 13:31:06 GMT
ch1ller , jj0 so using jj0's modified tool (I changed it to page size of 2112 as I have the newer ESMT F59L1G81LA nand. I managed to dump the first 1mb of nand. (compiled binary for 2112 page size = cdn.discordapp.com/attachments/496469652076232719/501386015387156490/nand_id)A friend who is very knowledge of low level and reverse engineering took my dumped and then produced... cdn.discordapp.com/attachments/496469652076232719/501384317239296040/script.bin (script.bin to be converted to script.fex) cdn.discordapp.com/attachments/496469652076232719/501384318019436544/boot0.bin (Boot0) cdn.discordapp.com/attachments/496469652076232719/501384324050976799/uboot.bin (uboot) cdn.discordapp.com/attachments/496469652076232719/501384344674369537/bootrom.bin (boot rom) So there is the required stuff for the newer revision C64 boards to blow it wide open. (There seems to be two revisions of the c64 mini. The newer one with the different brand nand, lack of external UBOOT tactile switch and no silver sticker below) So feel free to have a play. I am looking into using preexisting hakchi tools with updated DRAM configurations in attempt to work out how easy it would to port the preexisting tools over. Still no word on OSS but when we get it, it will make life easier.
Oh he also revered the main of boot0
void __fastcall __noreturn boot0_main() { int disable_uart; // r0 volatile int enable_jtag; // r0 int fel_flag; // r0 int dram_size; // r0 MAPDST int fw_load_result; // r7 int (*exec_addr)(void); // r0
bzero32(&bss_area_maybe, 0x1DCu); nullsub_6(); timer_init(); disable_uart = g_disable_uart; UART_open(disable_uart, g_gpio_list_for_uart, val_24000000); enable_jtag = g_enable_jtag; if ( enable_jtag ) boot_set_gpios(g_jtag_gpios); printf("HELLO! BOOT0 is starting!\n"); printf("boot0 version : %s\n", "3.0.0"); sub_362C(1); fel_flag = *gp_fel_flag; *gp_fel_flag = 0; if ( fel_flag == 0x5AA5A55A ) { printf("eraly jump fel\n"); nullsub_5(); _msdelay(10); exec_arg0((int (*)(void))0xFFFF0020); } mmu_system_init(0x40000000u, 0x400u, (_DWORD *)0x20000); mmu_system_init2(); dram_size = init_DRAM(0, g_dram_params); if ( dram_size ) { printf("dram size =%d\n", dram_size); exec_52000000_if_flag_set(); fw_load_result = load_Boot1_from_nand(); printf("Ready to disable icache.\n"); mmu_disable(); if ( fw_load_result ) { printf("Jump to Fel.\n"); exec_addr = (int (*)(void))0xFFFF0020; } else { set_dram_para(g_dram_params, dram_size); printf("Jump to secend Boot.\n"); exec_addr = (int (*)(void))0x4A000000; } exec_arg0(exec_addr); } printf("initializing SDRAM Fail.\n"); mmu_disable(); exec_arg0((int (*)(void))0xFFFF0020); }
|
|
|
Post by jj0 on Oct 15, 2018 15:12:05 GMT
ch1ller , jj0 so using jj0's modified tool (I changed it to page size of 2112 as I have the newer ESMT F59L1G81LA nand. I managed to dump the first 1mb of nand. (compiled binary for 2112 page size = cdn.discordapp.com/attachments/496469652076232719/501386015387156490/nand_id)A friend who is very knowledge of low level and reverse engineering took my dumped and then produced... cdn.discordapp.com/attachments/496469652076232719/501384317239296040/script.bin (script.bin to be converted to script.fex) cdn.discordapp.com/attachments/496469652076232719/501384318019436544/boot0.bin (Boot0) cdn.discordapp.com/attachments/496469652076232719/501384324050976799/uboot.bin (uboot) cdn.discordapp.com/attachments/496469652076232719/501384344674369537/bootrom.bin (boot rom) So there is the required stuff for the newer revision C64 boards to blow it wide open. (There seems to be two revisions of the c64 mini. The newer one with the different brand nand, lack of external UBOOT tactile switch and no silver sticker below) So feel free to have a play. I am looking into using preexisting hakchi tools with updated DRAM configurations in attempt to work out how easy it would to port the preexisting tools over. Still no word on OSS but when we get it, it will make life easier. Oh he also revered the main of boot0
void __fastcall __noreturn boot0_main() { int disable_uart; // r0 volatile int enable_jtag; // r0 int fel_flag; // r0 int dram_size; // r0 MAPDST int fw_load_result; // r7 int (*exec_addr)(void); // r0
bzero32(&bss_area_maybe, 0x1DCu); nullsub_6(); timer_init(); disable_uart = g_disable_uart; UART_open(disable_uart, g_gpio_list_for_uart, val_24000000); enable_jtag = g_enable_jtag; if ( enable_jtag ) boot_set_gpios(g_jtag_gpios); printf("HELLO! BOOT0 is starting!\n"); printf("boot0 version : %s\n", "3.0.0"); sub_362C(1); fel_flag = *gp_fel_flag; *gp_fel_flag = 0; if ( fel_flag == 0x5AA5A55A ) { printf("eraly jump fel\n"); nullsub_5(); _msdelay(10); exec_arg0((int (*)(void))0xFFFF0020); } mmu_system_init(0x40000000u, 0x400u, (_DWORD *)0x20000); mmu_system_init2(); dram_size = init_DRAM(0, g_dram_params); if ( dram_size ) { printf("dram size =%d\n", dram_size); exec_52000000_if_flag_set(); fw_load_result = load_Boot1_from_nand(); printf("Ready to disable icache.\n"); mmu_disable(); if ( fw_load_result ) { printf("Jump to Fel.\n"); exec_addr = (int (*)(void))0xFFFF0020; } else { set_dram_para(g_dram_params, dram_size); printf("Jump to secend Boot.\n"); exec_addr = (int (*)(void))0x4A000000; } exec_arg0(exec_addr); } printf("initializing SDRAM Fail.\n"); mmu_disable(); exec_arg0((int (*)(void))0xFFFF0020); }
swingflip This is great! Nice to see the tool had some value. For educational purposes it would be nice if your learned friend could be persuaded provide a small essay on how he translated the dump into the various parts. I look forward to more developments.
|
|
|
Post by darbyram on Oct 15, 2018 19:04:02 GMT
Great work swingflip...
|
|
|
Post by swingflip on Oct 16, 2018 9:07:49 GMT
Thanks, it's been a team effort for sure. I feel much more the facilitator at the moment as others have done most of the decoding as I am not a huge low level guy or reverse engineer but I know enough to get by. Once we got the tools to mod the uboot to include the rest of the NAND and we can easily flash kernels back and forth then the rest is trivial and I will be able to mod the kernel and set up the scripts to actually manage the day to day hack. I will keep you guys posted
|
|
|
Post by spannernick on Oct 31, 2018 12:02:07 GMT
|
|
|
Post by spannernick on Nov 1, 2018 13:39:32 GMT
Just wondered how will the hack work,I mean how will you flash it to TheC64 Mini,will you have to use the Uart,I ask cause everyone should know by now... ,mine don't work,will you be flashing it via the USB ports..?
|
|
|
Post by darbyram on Nov 1, 2018 20:07:04 GMT
Just wondered how will the hack work,I mean how will you flash it to TheC64 Mini,will you have to use the Uart,I ask cause everyone should know by now... ,mine don't work,will you be flashing it via the USB ports..? Until it been done we won't know. But I would imagine it won't be via UART, as the aim is for any person to be able to do it easily. If you take a look at the nes and snes mini's hack method, it hopefully will be fairly straightforward as that. Take a look at swingflip's Sig, you could join the discord hakchi resources channel and look for any developments.
|
|
|
Post by deerwings on Nov 1, 2018 21:03:48 GMT
It seems like the more effective way would be to create a new firmware .bin file that could be flashed via the USB stick. Simplest and easy way, and the C64 Mini is already set up to do that, and there doesn't seem to be much of an indication of a locked bootloader.
|
|
|
Post by spannernick on Nov 2, 2018 16:53:15 GMT
I had a funny feeling it would be the bin file way and I am glad,if you think about it the Uart it just display and keyboard because you can't close the64 program from theC64 Mini, if you could you would have command line or a shell on the TV and not have to connect it to a PC.
|
|
|
Post by deerwings on Nov 2, 2018 17:18:49 GMT
Using my UART, I have successfully deleted everything in the /usr/share/thec64/games folder and copied my own directory from my USB stick into /usr/share/thec64 and confirmed that all my custom games and their configuration files work successfully.
Step by Step:
Log into your UART >#mount -o rw,remount / >#mount /tmp/usbdrive1/sda1 /mnt >#cp -R /usr/share/thec64/*.* /mnt/thec64/ <---- (IMPORTANT! THIS BACKS UP YOUR CURRENT DIRECTORY IN CASE YOU MAKE A MISTAKE) >#rm -rf /usr/share/thec64/games/*.* <------(DO NOT DO THIS UNTIL YOU VERIFY YOUR DIRECTORY IS BACKED UP ENTIRELY!) >#cp -R /mnt/thec64/games/*.* /usr/share/thec64/games/ >#chmod -x /usr/share/thec64/games/*.* >#cd /usr/share/thec64/games/ >#ls <--------(MAKE SURE ALL OF YOUR NEW GAMES ARE PRESENT IN THE SAME STRUCTURE AS ORIGINAL) >#umount /mnt >#mount -o ro,remount / >#reboot
When the C64 Mini reboots, the Carousel should begin showing all the games you've added in! Just double check everything. If you make a mistake, rm -rf the /usr/share/thec64/games directory and put your backup back in.
Replacing all the files in the /usr/share/thec64/games directory is extremely easy and simple, as long as you have a UART, it seems compartmentalized very nicely for this specific purpose, so a firmware update could theoretically do the same thing if it's formatted correctly.
|
|
|
Post by ShaneRMonroe on Nov 3, 2018 2:07:04 GMT
Wow .. this is an exciting thread to follow!
|
|
|
Post by swingflip on Nov 11, 2018 14:05:31 GMT
Using my UART, I have successfully deleted everything in the /usr/share/thec64/games folder and copied my own directory from my USB stick into /usr/share/thec64 and confirmed that all my custom games and their configuration files work successfully.
Step by Step:
Log into your UART >#mount -o rw,remount / >#mount /tmp/usbdrive1/sda1 /mnt >#cp -R /usr/share/thec64/*.* /mnt/thec64/ <---- (IMPORTANT! THIS BACKS UP YOUR CURRENT DIRECTORY IN CASE YOU MAKE A MISTAKE) >#rm -rf /usr/share/thec64/games/*.* <------(DO NOT DO THIS UNTIL YOU VERIFY YOUR DIRECTORY IS BACKED UP ENTIRELY!) >#cp -R /mnt/thec64/games/*.* /usr/share/thec64/games/ >#chmod -x /usr/share/thec64/games/*.* >#cd /usr/share/thec64/games/ >#ls <--------(MAKE SURE ALL OF YOUR NEW GAMES ARE PRESENT IN THE SAME STRUCTURE AS ORIGINAL) >#umount /mnt >#mount -o ro,remount / >#reboot
When the C64 Mini reboots, the Carousel should begin showing all the games you've added in! Just double check everything. If you make a mistake, rm -rf the /usr/share/thec64/games directory and put your backup back in.
Replacing all the files in the /usr/share/thec64/games directory is extremely easy and simple, as long as you have a UART, it seems compartmentalized very nicely for this specific purpose, so a firmware update could theoretically do the same thing if it's formatted correctly.
Hi deerwings yes this is possible but I would advise against it. It's good to know that the UI just picks them up anyway. Instead of removing the RO mount and then removing and copying over files to the nand it will be much safer and cleaner to write an overmount system where by any plugged in USB or SD will simple overmount the games folder on the NAND. Or have a local storage location which will overmount via NAND. It should also be noted that the NAND from pre-release are 256mb chips and after pre-release were swapped out for 128mb units. (Not ideal) Just an update. I now have a complete copy of the oss for the c64 mini. This includes everything except the ROMS.
I am currently in the process of building a custom uboot that can be flashed to the C64 mini via FEL mode and will mean that to hack the c64 will not require UART.
The idea will work very much like hakchi ((S)NESC) and will use similar libraries. Basically you will just need to connect the power USB to the pc holding the UART button on the board. Run the app that we will put together. It will install the required driver and flash the custom uboot. It will also make a backup of your image to make sure if you cock it up it can be flashed to stock. Work on this was pretty silent as we have been working on a rebrand for the community and also been teaming up with libretro to rebuild all the emulators for RetroArch so they would work for the C64 mini as well as the (S)NESC. That means there will be around 90 available emulators for the c64 classic when the hack is ready.
I also had a quick look and it uses Vice2.4 It should be very easy to add vic20 and c128 support to the standard UI.
Anyway a lot to do and I will keep you updated. Feel free to catch up or discuss on the community discord (link in my signature) I will have the OSS up when I can get git to finally push the bloody thing. (Lots of files!)
|
|
|
Post by deerwings on Nov 11, 2018 14:43:51 GMT
Using my UART, I have successfully deleted everything in the /usr/share/thec64/games folder and copied my own directory from my USB stick into /usr/share/thec64 and confirmed that all my custom games and their configuration files work successfully.
Step by Step:
Log into your UART >#mount -o rw,remount / >#mount /tmp/usbdrive1/sda1 /mnt >#cp -R /usr/share/thec64/*.* /mnt/thec64/ <---- (IMPORTANT! THIS BACKS UP YOUR CURRENT DIRECTORY IN CASE YOU MAKE A MISTAKE) >#rm -rf /usr/share/thec64/games/*.* <------(DO NOT DO THIS UNTIL YOU VERIFY YOUR DIRECTORY IS BACKED UP ENTIRELY!) >#cp -R /mnt/thec64/games/*.* /usr/share/thec64/games/ >#chmod -x /usr/share/thec64/games/*.* >#cd /usr/share/thec64/games/ >#ls <--------(MAKE SURE ALL OF YOUR NEW GAMES ARE PRESENT IN THE SAME STRUCTURE AS ORIGINAL) >#umount /mnt >#mount -o ro,remount / >#reboot
When the C64 Mini reboots, the Carousel should begin showing all the games you've added in! Just double check everything. If you make a mistake, rm -rf the /usr/share/thec64/games directory and put your backup back in.
Replacing all the files in the /usr/share/thec64/games directory is extremely easy and simple, as long as you have a UART, it seems compartmentalized very nicely for this specific purpose, so a firmware update could theoretically do the same thing if it's formatted correctly.
Hi deerwings yes this is possible but I would advise against it. It's good to know that the UI just picks them up anyway. Instead of removing the RO mount and then removing and copying over files to the nand it will be much safer and cleaner to write an overmount system where by any plugged in USB or SD will simple overmount the games folder on the NAND. Or have a local storage location which will overmount via NAND. It should also be noted that the NAND from pre-release are 256mb chips and after pre-release were swapped out for 128mb units. (Not ideal) Just an update. I now have a complete copy of the oss for the c64 mini. This includes everything except the ROMS.
I am currently in the process of building a custom uboot that can be flashed to the C64 mini via FEL mode and will mean that to hack the c64 will not require UART.
The idea will work very much like hakchi ((S)NESC) and will use similar libraries. Basically you will just need to connect the power USB to the pc holding the UART button on the board. Run the app that we will put together. It will install the required driver and flash the custom uboot. It will also make a backup of your image to make sure if you cock it up it can be flashed to stock. Work on this was pretty silent as we have been working on a rebrand for the community and also been teaming up with libretro to rebuild all the emulators for RetroArch so they would work for the C64 mini as well as the (S)NESC. That means there will be around 90 available emulators for the c64 classic when the hack is ready.
I also had a quick look and it uses Vice2.4 It should be very easy to add vic20 and c128 support to the standard UI.
Anyway a lot to do and I will keep you updated. Feel free to catch up or discuss on the community discord (link in my signature) I will have the OSS up when I can get git to finally push the bloody thing. (Lots of files!)
If I update a .tsg live, or overwrite it from my USB stick, the UI doesn't seem to 'get' that the changes have been made until the carousel is reloaded. That can be done with killall -9 the64 but it doesn't seem 'clean' to do it that way. The only thing that seems to update live is if I overwrite an existing game file. But amending so that the /usr/share/the64/games folder is rw while the rest of the system is left alone would be better but I'm not sure if anything else needs to be rw or not.
|
|
|
Post by swingflip on Nov 11, 2018 15:08:30 GMT
will this also include a emulator for amiga? this will give the mini a whole new game library Yeah it can run the amiga core.
deerwings yeah we will either edit the carousel program to allow for live time editing or use .desktop files. Orrr we can just wrap the whole thing in bash scripts to reload the UI everytime we want to load another bunch of stuff
|
|
|
Post by darbyram on Nov 11, 2018 15:19:54 GMT
Hopefully with this we can add more joystick, Gamepad support :-)
|
|
|
Post by deerwings on Nov 11, 2018 15:38:32 GMT
will this also include a emulator for amiga? this will give the mini a whole new game library Yeah it can run the amiga core.
deerwings yeah we will either edit the carousel program to allow for live time editing or use .desktop files. Orrr we can just wrap the whole thing in bash scripts to reload the UI everytime we want to load another bunch of stuff Sounds like a great idea. Also, as an experiment, I tried to mount just the /usr/share/the64/games folder as rw and had the same issue as if I had mounted the entire filesystem as ro. My SSI games stopped working properly at that point until I remounted the entire filesystem as rw. This is making me wonder about re-writing the fstab to mount specific directories as rw but I'm not sure which ones. It would be nice if the Carousel was decoupled from Vice so that Vice ran on its own and we could create scripts that run games with specific Vice switches through commandline scripts, maybe with some kind of joystick-selectable UI on top. But the fact that it doesn't drop to a commandline prompt on screen when you terminate the64 tells me something needs to be tweaked. Also, there's not much storage on this device as a whole, so something warning users that adding games might impact ability to save states as well might be a good idea to add. I've only got 64 on mine and there's roughly about 25MB leftover, and my games folder itself is only about 13MB.
|
|
|
Post by swingflip on Nov 11, 2018 15:42:47 GMT
Yeah it can run the amiga core.
deerwings yeah we will either edit the carousel program to allow for live time editing or use .desktop files. Orrr we can just wrap the whole thing in bash scripts to reload the UI everytime we want to load another bunch of stuff Sounds like a great idea. Also, as an experiment, I tried to mount just the /usr/share/the64/games folder as rw and had the same issue as if I had mounted the entire filesystem as ro. My SSI games stopped working properly at that point until I remounted the entire filesystem as rw. This is making me wonder about re-writing the fstab to mount specific directories as rw but I'm not sure which ones. It would be nice if the Carousel was decoupled from Vice so that Vice ran on its own and we could create scripts that run games with specific Vice switches through commandline scripts, maybe with some kind of joystick-selectable UI on top. But the fact that it doesn't drop to a commandline prompt on screen when you terminate the64 tells me something needs to be tweaked. Also, there's not much storage on this device as a whole, so something warning users that adding games might impact ability to save states as well might be a good idea to add. I've only got 64 on mine and there's roughly about 25MB leftover, and my games folder itself is only about 13MB. There is plenty enough RAM to enable compression. Compressing savestates and games will allow for more storage. Also the partitioning OTB doesn't utalise the full 128MB/256MB
|
|
|
Post by deerwings on Nov 11, 2018 15:49:48 GMT
With df -h, I get
Filesystem Size Used Available Use% Mounted on none 68.9M 44.6M 24.3M 65% /dev /dev/nandb 68.9M 44.6M 24.3M 65% / tmpfs 52.7M 0 52.7M 0% /dev/shm tmpfs 52.7M 172.0K 52.5M 0% /tmp tmpfs 52.7M 8.0K 52.7M 0% /run
But I've noticed with some of my SSI games, if I remount the filesystem as rw and reboot, then it keeps my disk images persistent, but if I remount as ro, they act as if they're default again. Another remount and they're back to normal. This makes me wonder if something is being stored somewhere that's not visible as a mount. I haven't looked at the chips in a bit, but it seems like we're only being given to approximately half with the /dev/nandb mount on / and the rest is sequestered somewhere else? I'm afraid of trying to mount /dev/nanda somewhere just for shiggles to see what's on it.
|
|
|
Post by groepaz on Nov 11, 2018 16:01:53 GMT
can you upload that source somewhere, please? we'd like to host that on the VICE sf page
|
|
|
Post by swingflip on Nov 11, 2018 16:20:57 GMT
|
|
|
Post by swingflip on Nov 11, 2018 16:42:54 GMT
groepaz Actually don't worry I did the diff already https://gist.github.com/swingflip/8ed86064ab580ebac9f62fe69ef10e5b
|
|
|
Post by spannernick on Nov 11, 2018 18:30:27 GMT
Can anyone tell me how does the firmware boot the64 program (UI),anyone know there has to be a text file with a command saying to boot usr/bin/the64.I going to see if I can get it to boot before login and use autogetty to boot it.
The Carousel UI uses libc btw.
|
|
|
Post by jj0 on Nov 11, 2018 18:52:03 GMT
Can anyone tell me how does the firmware boot the64 program (UI),anyone know there has to be a text file with a command saying to boot usr/bin/the64.I going to see if I can get it to boot before login and use autogetty to boot it. The Carousel UI uses libc btw. #grep -r the64 / /etc/init.d/S99redquark: nohup the64 >/dev/null 2>&1 &
|
|
|
Post by spannernick on Nov 11, 2018 21:22:09 GMT
Whats -r for,I learning as I go,I know abit,I have heard of Grep. and what's S99redquark, a special program RG made cause RedQuark One is there beta name for TheC64 Mini..? and this bit.. nohup the64 >/dev/null 2>&1 &. I have almost got the UI working on a Cubieboard2... (Armiga)
|
|