Toggle sidebar

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

  • Thread starter Thread starter VideoGameMore
  • Start date Start date
  • Views Views 1,272
  • Replies Replies 30
  • Likes Likes 19
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: VideoGameMore and impeeza
NitroRevolutionNX said:
Why such a basic feature isn't baked in is beyond me... Even a cheap R4 clone has it, but the open-source alternative doesn't?
Click to expand...
Because it's a new firmware. Anybody is welcome to take an ide and start coding the features needed or wanted
 
  • Like
Reactions: NitroRevolutionNX and derivativeoflog7
retro_tastic said:
Amazing! We are now just missing a proper save state support to make this an ultimate flashcart...
Click to expand...
Would be cool if it allowed automatic quick save on soft reset. I don't think any DS flashcart has implemented that before.
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...
A flashcart does not have the capability to capture the screens. It would have to be done in software, likely resulting in slowdowns because the game has to be paused just to take a screenshot, now imagine that 30 times a second.
Keeping in mind also that the cartridge slot does not have enough bandwidth to transmit one screen at 60 FPS, let alone both screens, and the DS is not nearly powerful enough to encode the capture into a format that would be smaller, so the best you could probably hope for is 1 screen at 30 FPS or both screens at 15 FPS. That's not even including the bandwidth that the game itself uses, so further slowdowns could be caused whenever the game is trying to load data at the same time as the screen capture is running.

I believe the GBA slot is faster so that could be a way around some of those limitations, but the obvious caveat is that you would need a GBA flashcart and a compatible DS model.
 
Last edited by The Real Jdbye,
  • Like
Reactions: derivativeoflog7 and impeeza

Site & Scene News

New Hot Discussed User Submitted

Go to forum More news

Popular threads in this forum