pico 8 does these pretty glitches when running a cart
i was wondering is there a way to rerun the cart like that from the code
i tried different options but it never makes the glitches
what does actually happen when i press cmd+r?

These glitches are very reminiscent of what you might see onscreen on old hardware when powering them down (like the NES for example).
On those hardware, the CPU is still running for a few frames while the RAM data is decaying before it stops running. This is not predictable behavior nor desirable behavior, and can even corrupt the memory of your saves on the cartridge, if any, so it's usually left out of emulators.
Pico 8 is another story: it's purposefully adding these glitches in for the virtual console to feel more real. (not the saves destroyed part obviously)
Here are different effect I can see :

• partial palette corruption
• short bursts of video mode change (128x64 for example)
• partial sprite sheet corruption
  This one is not trivial : you can't have all the identical tiles corrupted in the same way just from video memory. My guess is the corruption is done first and then the game runs and displays a last frame with the corrupted spritesheet.
• half the lines shifted by one pixel.

I guess all of these effects could be coded in a pico 8 cart.

Thank you @RealShadowCaster!!!
I thought actually that these glitches are artificial and not really happening because of the reboot.
Thanks for description of what is happening in there! I guess i'll try to do something like that myself.

I believe you can restart a cart in your code using a call to run(), but these glitches are not replicated.

You can cause some pretty interesting things to happen by peppering random junk into memory space,

--warning: this will corrupt save data and current execution of the cart
for i=0x0,0x7fff,rnd(0xf) do
 poke(i, rnd(0xf))
end

It'll likely break your gameplay (and user/save data!) but could be used prior to a run() call if everything's about to be reset.

When you call cartdata, your save is mapped to the 256 bytes between 0x5e00 and 0x5eff. @kozm0naut 's code is guaranteed to write random bytes to it since the steps are at most 14.999... . It can also hang the game, if the random step is 0.0
1+flr(rnd(0xf)) makes a little more sense but is as bad for the save.

That's right @RealShadowCaster, I have added a warning to the snippet above. You could also choose to focus strictly on the graphics buffer (0x6000-0x7fff) and maybe hit the draw state (0x5f00-0x5f3f) as well which shouldn't cause save corruption.

Upon further digging/testing, it actually looks like calling extcmd() with an argument of "reset" will result in the full console reset effect including the cosmetic glitches.

oh my!!! that is so great! thank you so much for finding it out @kozm0naut!!!
And actually all the rest information was also very helpful, because i'm new with coding and i didn't know how to call memory addresses with a for loop! So thank you for all that as well!

So far so good)
Thank you so much guys!🙏🙏🙏
@RealShadowCaster @kozm0naut
Still have some issues, but I’m so exited that it actually worked just the way I wanted!)

Haha, very nice! I have played around with your carts before, I really like your art style!

Hey @peter Mosevich, seems I can't @ you because of the space in your pseudo.
Awsome glitches :)
If someone is using the Peter pseudo, sorry for the poke.
@kozm0naut, nice find. Since you've experimented with it, dou you know the limitations of extcmd() when called from BBS ?
I'm particularly interested by label and folder, but if you have some general insight, I'd love to learn. There's nothing much on the wiki about it.

Thank you @kozm0naut! I really appreciate it😊

Oh Damn😅😅😅 @RealShadowCaster
I wonder if I can change my profile name now))
Btw, somehow the glitches look even cooler in the browser version