Toggle sidebar

Front-page DSPico QuickReturn — Return to the Pico menu without rebooting

ChronoCrossfangirl2002 said:
Okay so: alot of the r4 card clones essentially had a time bomb that was basically a internal count down that would cause the cart to cease function after said given time which required a work around such as ysmenu to avoid the time bomb going off inevitably.
Click to expand...
This keeps popping up over and over and I just want to clear things up, its not built into the cart and never was, the "time bomb" you speak of was a time expiry built into older versions of the R4iMenu kernels of r4isdhc.com 2014+ and r4i-sdhc.com carts (colloquially known as "DEMON" carts). It was to force users to upgrade the kernel to the latest version of R4iMenu.

It was entirely in software and switching the kernel to YSMenu solved it. The latest version of R4iMenu also now have this "time bomb" removed now (v4.3 and v1.87b), although these days its better to run the DSTT port of Pico-Loader on these carts now.
 
Last edited by Coderkei,
  • Like
Reactions: SylverReZ and impeeza
impeeza said:
Why do fork instead of collaborate with the main repo and make it better?
Click to expand...
Its the best way for me to cut and build without disrupting the main flow of the project. Then when I hit a milestone (like where I am now) I submit a draft PR back to them to decide if they want to incorporate it or not. I have done that so they might choose to include it as is or make some changes to fit their needs.
 
Last edited by VideoGameMore,
  • Like
Reactions: impeeza and ber71
Coderkei said:
This keeps popping up over and over and I just want to clear things up, its not built into the cart and never was, the "time bomb" you speak of was a time expiry built into older versions of the R4iMenu kernels of r4isdhc.com 2014+ and r4i-sdhc.com carts (colloquially known as "DEMON" carts). It was to force users to upgrade the kernel to the latest version of R4iMenu.

It was entirely in software and switching the kernel to YSMenu solved it. The latest version of R4iMenu also now have this "time bomb" removed now (v4.3 and v1.87b), although these days its better to run the DSTT port of Pico-Loader on these carts now.
Click to expand...
Right, but whether it was in the cart or not it was still something to be aware of at least for awhile, but as of now I don't think the semantics of it really matter much anymore.
 
derivativeoflog7 said:
Forking is the first step in creating a pull request, that's how contributing on GitHub works
Click to expand...
yep, ofcourse but if you are willing to colaborate to the main branch you do not fork and start to release separated branch. thas is how a derivation is created and later is a mess of versions.
 
impeeza said:
Why do fork instead of collaborate with the main repo and make it better?
Click to expand...
The author of the fork already submitted a pull request to the original project, awaiting review.

https://github.com/LNH-team/pico-loader/pull/228

Also, a lot of developers prefer first forking the repository and the merging their contributions to the original repository, by doing that they can work in an isolated environment.
Post automatically merged:

NostalgicMillennial said:
Since this thing is basically a raspberry pi, I am waiting for either a hardware revision or software that will let me record and capture NDS
Click to expand...
I doubt that will ever happen since the DSPico doesn't use the same chip as the main Raspberry Pi boards (full-fledged CPU and GPU solution) but the RP2040 microcontroller chip that uses a much less powerful ARM Cortex M0+ core (two of them actually). But maybe in the far future such thing is possible with a more powerful microcontroller.
 
  • Love
Reactions: impeeza
impeeza said:
yep, ofcourse but if you are willing to colaborate to the main branch you do not fork and start to release separated branch. thas is how a derivation is created and later is a mess of versions.
Click to expand...

Nah, people do this all the time, if you develop a new feature you may as well compile the project and release it so that people can test it; also anyone can create PRs from any fork even if they don't own it, tho admittedly I'm not sure how common it is.
It's also not wise for repository owners to give blanket access to anyone who promises a new feature, while I'm sure GitHub has some protections against it, theoretically anyone can do a force push and rewrite the entire history of the repo or mess with other stuff (even if GH has protections, it would probably be a bit of a headache for the repo owner), so forks and PRs are the standard way.
 
Last edited by derivativeoflog7,
  • Like
Reactions: impeeza

Site & Scene News

New Hot Discussed User Submitted

Go to forum More news

Popular threads in this forum