Release SuperZaxxon - Beta 2 released


So all the time ZXDunny was joking about the printer thing? Either I'm dumb or the irony wasn't all that obvious…


The kind of information that could be written down (on a piece of paper, ZXDunny, of course :rolleyes: ), would include the UUID, the SD Card/USB drive model and name, the size, the first few bytes like proposed above (though if you added files to it in the meanwhile, without affecting other files, this can behave weirdly), and possibly the PNDs being run from each of them; things that are simple, quick and can be obtained without too much work. I don't know exactly how the handling of these devices work, but I doubt it's anything very hard to do.


As of asking questions about the user on suspend and wake up, the more I think about it, the less I like it, actually. Maybe it is because I didn't explain my idea thoroughly. It could become inefficient, because it could be doing this every time you suspend the system. However, I think there's still a way to make it lighter and faster, and always optional. Before suspending, open a window that will show a list of all the removable devices. Click 'OK' to suspend, 'Cancel' to, well, cancel the suspend, otherwise auto suspend in 10 seconds or so. Actually, that list could be part of a suspend confirmation part. As of it being optional, I don't know where this could be turned back on, maybe in some system settings, but I don't know how these work. When waking up, there could be a window comparing the devices before and after, showing a green check mark for every device that is mounted and corresponds to one in the list. Of course, one could add plug in new devices too without disturbing this process. When one device is missing, a red X will be shown. If there is no X, it automatically closes in a few seconds; if there is one or more, it prompts for plugging back before restarting PNDs (though this can be a bit long for a simple wake up, how faster can we restore safely all PNDs?) or to stop or ignore the PNDs running from that card/drive.


Being optional is very important, because some might find it long and boring while they're trying to save time at the Pandora starting process.


What do you think?
 
OK, how about this:


have two sleep scripts, one safe and one unsafe (no unmount).


Make it user configurable and leave the default as safe.


This way everyone is happy, whoever knows what they are doing would use the unsafe one, and all others would use the safe.


What do you think?


I'd be happy to test it out myself, but no Pandora yet.... (since October 2008 and counting... ;)
 
The only problem (so far) is that mr drillux does not play in fullscreen anymore :( I like that game..... meyby not the biggest bug. But I would think that there might be more PNDs out there that does not plat in fullscreen.
 
Consolidation of all the mentioned possibilities/variants concerning Standby:


I failed in visualizing this as a flowchart diagram, therefore a short intro text with the suggested solutions & the program decision/flow as an indented list.


Solutions:


Solution 1 (S1): Safe by default, risky on demand utilizing mmc_core.removable (centus, urjaman)


Described by centus & urjaman, also in the spirit of EvilDragon ("if standby requested with active PNDs, go into low power mode").


I think this solution is a realistic start, as it means little implementation effort AFAIK, and by default satisfies safety needs (and distributers' accountability!) but also usage comfort on demand, for those who are responsible enough on their own (not removing devices while standby).


Solution 2 (S2): Note device list on suspend, check devices against list on resume (fredg999)


Offering usage comfort (pause/resume easily) while better preserving battery AND still ensuring safety for all kind of users and use cases.


More implementation effort. Probably a goal for somewhen later.


Approach 3: On suspend, send signal to apps, which they need to handle (torpor, sebt3, …)


Consensus was reached, that this is the most unrealistic approach of all, as EVERY app would need to implement this.


Program flow (with the various solutions):

  • Standby requested.
  • Any open files? (active mounted PNDs, etc)
  • Yes:
    S1:
    Setting "Safe": -> Safe standby not possible, going into low power mode. (EvilDragon)
  • Setting "Unsafe: -> Going into standby without unmounting storage devices. (User responsibility to not remove devices, else data loss)
[*]S2:

  • Register the storage device IDs into a variable into the RAM or NAND for safety check on resume.


[*]No:

  • Go into standby (or low power mode if something else prevents standby).



  • System wakes from standby.
  • S1:
    Setting "Unsafe"
    Storage devices remained unchanged: System resumes. No troubles expected.
  • Storage devices were changed: System resumes. Crash or data corruption likely to occur.
[*]Setting "Safe":

  • The setting "Safe" does not permit to reach Standby with active PNDs! Thus no handling necessary for this.
  • If there were no active PNDs, resuming already works fine in the current version.


[*]S2:

  • Special wake routine, halting FS access and first checks: Storage devices changed? (notaz: "difficult to implement")
  • If this takes long enough, that a user feedback is necessary (> 2 secs), display a device list with status icons besides them (fredg999)
    No device difference: Continue without prompting any user input, system ready to resume.
  • Devices differ: Inform the user to plug in the devices.
    Solution: "Polling"
    Poll for the devices every 0.5 seconds, update the status icons beside the devices on the list.
  • As soon as all devices have the OK icon, the system is ready for resume.
  • Advantage of polling: User only needs to plug in devices, no further interaction (button click/press) required
[*]Solution: "On user confirmation"

  • User plugs in all devices.
  • User confirms "Continue"
  • System checks wether all necessary devices are really there.
    Yes: System ready for resume.
  • No: Status icons beneath devices get updated, instruction updated to "The devices with the icon 'X' are still missing. Please plug them in, and then press 'Continue'".






[*]System is ready for safe resume:

  • Setting "Resume with system feedback": A short feedback is given (i.e. a green checkmark layed over the whole screen for 0.5 secs and/or an acoustic signal), then the system resumes.
  • Setting "Resume without system feedback".
 
Last edited by a moderator:
OK, how about this:


have two sleep scripts, one safe and one unsafe (no unmount).


Make it user configurable and leave the default as safe.


This way everyone is happy, whoever knows what they are doing would use the unsafe one, and all others would use the safe.


What do you think?


I'd be happy to test it out myself, but no Pandora yet.... (since October 2008 and counting... ;)

I think this is the best idea - play it safe, get give the option to those who know what they're doing.
 
Wait, I thought you had to pass something at boot time? Or is it possible to change this with the system running now?


EDIT: Nevermind, didn't read porg's post well enough.
 
Last edited by a moderator:
Dos overclocking Support mean: I can play games which needs more than 500 mhz and i have all the good things from the new cernel when i boot the new kernel??


I tought overclocking support would need about 1 Yeahr to work...


im curently download the full flash and i m looking for some new games :)
 
Overclocking support means you can overclock your CPU but not overvolt it so your maximum (stable) frequency is the highest one you can go at OPP3
 
Just tryd it out: Whit Beta 2, i can clock the pandy whit this button on the taskbar up to 800 mhz, thats allways enought for my things i want to do whit the pandora: playing games, and maybe listen to some internetradio on the radiotray pnd..


Could it be that the Beta 2 dit made something whit the Wifi Drivers? Since i flashd beta 2 my Wifi semms to work fine (it ditnt work until then, but until end 2011 it just made his job fine..)


But i have one Problem: i cant find the Button which alows me to change the Lid Close Options, i want to put the Pandy in Suspense Mode by closing the Lid..
 
Last edited by a moderator:
But i have one Problem: i cant find the Button which alows me to change the Lid Close Options, i want to put the Pandy in Suspense Mode by closing the Lid..

The utility Lid-Close-Settings currently offers these settings:

  • Turn off screen.
  • Go into low power mode (same as when pressing the power button for less than 3 seconds)
  • Shut the Pandora down.


I see no choice for "Standby" ("Suspense Mode" as you call it).


By researching your request, I found another bug:


The label "same as when pressing the power button for less than 3 seconds" is not true, as of Super Zaxxon Beta 2.

  • If I press the power button for less than 3 seconds it triggers "Standby" or "Low Power Mode", not sure which one it really is,
  • if more then 3 seconds, I start a countdown for "Shutdown", which can be aborted in the next 5 seconds, otherwise the device shuts down.
 
I am not sure what really causes "standby" and what causes "low power mode".


Could anyone who certainly knows, please clarify which events trigger which mode, and how to determine retrospectively (from ring buffer sys log) which mode(s) you really ran through.


Thanks.
 
Awesome summary and specification, porg. I vote for S1. When deciding a default value, always play safe and bet on ignorance. You'd much rather spend time explaining how the other mode can be activated and what you need to know about it, than why someone just lost all their data.
 
The specification is what I can do, being an interaction designer.


(Spent 4 hours on this. It properly cites all sources, was thought through, and comes in a structured manner)


The programming has to be conducted by someone else.


Hope that this summary can help as a guideline / requirement checklist.


That was the intention.


Glad, that it received some attention. Hope some devs carry it on. Thanks!
 
Ok: On the First Boot of the Experimental Kernel, the Button for the Lid Close Settings dosnt apeard in the Menü, so no wonder i ditnt found it,


on the second boot the Menü was fixed, but now my WLAN Seems to ditnt work, wich is strange because on the first boot it works just fine, but on the second, the wlan dosnt work (which was a problem i have since end of 2011 i have..) how to enable USB on Start from the Experimental Kernel? I want to use my Dongle Even whit the new External Kernel..


I want to bring the Pandora in "Low Power Mode" as the Standbye (Suspense) mode isnt supportet curently, but that i ben apple to put the Pandora away some hours and when i pick up the unit again to play the game, i just have to pull the Switch and the system is allready..
 
I have read through all the topic, and see no one proposed the solution I came to, that could possibly solve all the problems that arise from introduction of the suspend mode.


I have a PDA (PocketLoox 718, W*ndows Mobile 2003SE) - it has two slots, one for SD and one for CompactFlash. CF wakes up the PDA whenever it is inserted or removed, so that's not important. SD however does not, and I have made some tests to see "how they solved it".


(here was detailed description of the tests, but it was boring and I decided to remove it)


The conclusion is: on the PDA, the OS does not unmount the card on suspending, the file handlers/descriptors stay intact.


If an app makes a write after waking up, and the card has been changed to another one with different files, the fs on the new card will not be corrupted, the saved file will not appear on the card at all.


So M*crosoft managed to solve the problems. Maybe we can do that too?


My idea is following:


1. Before the suspend, flush all file buffers and sync everything on the cards, and pause all running programs.


2. Now when a file is opened, kernel (or fs driver) keeps some info for it, right? This could be unique ID in the fs, path, size, attributes, anything else? So it can use this info to check, after the wakeup, if the file still exists on the card, and if everything is identical as before the suspend. If yes, allow the descriptor to stay open.


3. After the wakeup, behave like the file has just been opened and seeked to the current position - no data in buffers, etc. Then unpause all programs.


I think this would not be very difficult to implement (but I'm not a kernel developer, so I may be wrong), and would be safe enough.
 
Yesterady i realized, that my external mouse doesn't work with the new kernel. Works with the old one though. Not even my hub is detected.
 
I have read through all the topic, and see no one proposed the solution I came to, that could possibly solve all the problems that arise from introduction of the suspend mode.


I have a PDA (PocketLoox 718, W*ndows Mobile 2003SE) - it has two slots, one for SD and one for CompactFlash. CF wakes up the PDA whenever it is inserted or removed, so that's not important. SD however does not, and I have made some tests to see "how they solved it".


(here was detailed description of the tests, but it was boring and I decided to remove it)


The conclusion is: on the PDA, the OS does not unmount the card on suspending, the file handlers/descriptors stay intact.


If an app makes a write after waking up, and the card has been changed to another one with different files, the fs on the new card will not be corrupted, the saved file will not appear on the card at all.


So M*crosoft managed to solve the problems. Maybe we can do that too?


My idea is following:


1. Before the suspend, flush all file buffers and sync everything on the cards, and pause all running programs.


2. Now when a file is opened, kernel (or fs driver) keeps some info for it, right? This could be unique ID in the fs, path, size, attributes, anything else? So it can use this info to check, after the wakeup, if the file still exists on the card, and if everything is identical as before the suspend. If yes, allow the descriptor to stay open.


3. After the wakeup, behave like the file has just been opened and seeked to the current position - no data in buffers, etc. Then unpause all programs.


I think this would not be very difficult to implement (but I'm not a kernel developer, so I may be wrong), and would be safe enough.

SD card ID would be one thing that could be checked, and most *nix filesystems have a mount-counter. If that changes when the system wakes up, you know you can no longer trust your cahces.
 
I've on multiple occassions have tried two TV Out cables on my ReBirth Pandora with Black & White showing up in old kernel.


Same cables on a Circuit Co Pandora give me color. One is a Peca (S-Video & Composite) build, the other an Askarus composite build.
 
Since Super Zaxxon 2 my Pandora had some problems if it have to power of: i push the button in the menü , there is the screen who said it going to power of, but as the shutdownbar is full, it makes nothing, i have to reset the unit and press R to made a shutdown from the bootmenü..


Its on the nonexperimental Kernel...
 
Back
Top