Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Discussions


Index du Forum » Discussions » Gray timings on fx-9750GII
Redcmd Hors ligne Membre Points: 306 Défis: 5 Message

Gray timings on fx-9750GII

Posté le 15/06/2021 14:46

I found the "correct" gray timings for my calculator fx-9750GII
The screen runs at 64Hz (maybe slightly less 63.99998 or TMU is slightly off??)
so the timings for gray are just flickering the screen at some ratio of 64Hz
tho sadly there are only 4 "usable" shades of gray, with only 2 being "good"
No tuning adjustment required

66:33 produces ~98% gray (almost black)
50:50 produces ~55% gray (good)
33:66 produces ~20% gray (good)
25:75 produces ~10% gray (very light, flickers)

I'm using the TMU, to control the frequency
Pϕ/1024 to Pϕ/4 works. Pϕ/4 seems to flicker a bit tho
Can use the RTC, tho it flickers every few sec (skips ticks every so often for some reason?)



(Looks better in real life)

!!Warning!!
The addin attached here is very unstable
It can and will freeze your calculator (only requires reset button on back)
If you leave it running for too long. TMU overflows (it runs in the background too)
Use at your own risk
It is only a prototype
It does take Overclocking into account to maintain 64fps
It should work:tm: on Graph35EII+ and Graph 75+E(fx-9860GII)
Does NOT work on SH3, including the SDK
gray9750.g1a

Controls:
[MENU] (twice) to exit program
[REPLAY] to modify target fps. Number is fixedpointed 5 to the left
[EXE] Fullscreen
[EXP] change Pϕ (Pϕ/4, Pϕ/16, Pϕ/256)
[TAN] increase gray level
[->] decrease gray level

On screen numbers from the top
current fps
number of ticks to wait (Pϕ/X)
active spinning while loop. if value goes to 0, calc is lagging
gray level (does go negative)
Pϕ clock timing
target fps

Fichier joint


Lephenixnoir En ligne Administrateur Points: 20767 Défis: 143 Message

Citer : Posté le 15/06/2021 22:13 | #


This is nice, thank you!

Since you mention that the display runs at 64 Hz, I checked the documentation and it actually specifies the frequency (page 32), which makes me feel really stupid for not checking before. xD

As you can see there are various possibilities for the frame frequency f_FR, it would be nice if we could compute it to properly synchronize the driver and screen on all models (since it is known that not all models look good at the same frequencies).

Pϕ/1024 to Pϕ/4 works. Pϕ/4 seems to flicker a bit tho
Can use the RTC, tho it flickers every few sec (skips ticks every so often for some reason?)

Pϕ/4 is more precise, I don't see why it would be different - maybe with a slighly different delay (in the order of ±128 units)? The RTC is exactly 64 Hz, there is a chance that the extra processing cost of interrupts delays some frames and causes irregularities. I assume this is a standalone executable and you actively wait on the timers to expire without using interrupts?

The addin attached here is very unstable
It can and will freeze your calculator (only requires reset button on back)

Can you share the source code? Usually freezing would happen if interrupts are requested in shorter intervals than the CPU can handle, but of course this wouldn't happen if you don't use interrupts.

I have tested it on my Graph 75+E (fx-9860G II) and the results are already better than gint's default. This is a very nice progress! Thanks a lot

As for the 63.99998 this is a 5 nano-second difference. Even without counting the Pϕ divider, variations in the clock generation, overhead CPU time, variations in frame generation or access to VRAM due to cache, variations in the power supply, or really any low-level effect, 5 nanoseconds is still 10 times smaller than a Pϕ cycle. I'm pretty sure there's no way the timer can capture that small a difference
Redcmd Hors ligne Membre Points: 306 Défis: 5 Message

Citer : Posté le 15/06/2021 22:26 | # | Fichier joint


Here is the attached code GRAY9750.zip
I shall warn you, the code is very very messy
I've copy and pasted various pieces of code from old projects and online libs
A lot of variables don't do what they say they are
And a lot of functions don't even get used

Ajouté le 16/06/2021 à 08:28 :
I checked the documentation
Duty cycle 1/65? none of the numbers seem to line up with 64Hz, that I can see

not all models look good at the same frequencies
I didn't have to tune any timings. Other than just setting the screen refresh rate to 64Hz

actively wait on the timers to expire without using interrupts
That is correct. When using Pϕ/4 and holding down any key, the frame rate flucturates around alot by a small amount. TCNT seems to be delayed by 1-2 ticks. Also happens at random intervals for a random period of time. Pϕ/16, Pϕ/64, Pϕ/256 and Pϕ/1024 do not have this problem. And Pϕ/4 is less stable at very high frame rates, flucturating around, while the others stay fine until almost max fps is reached. 145 fps (~700fps when overclocked)

Usually freezing would happen if interrupts are requested in shorter intervals than the CPU can handle
Is just the TCNT overflowing and me having no code to account for it. yet

5 nanoseconds is still 10 times smaller than a Pϕ cycle
Overclocked the calc during that testing. Timing wasn't precise enough at lower clock speeds. Still was able to get the perfectly timing tho. Screen moves 1 pixel every 30sec or so

Should try overclocking, seting the fps to 768 and looking at the fullscreen screen. All shades (except 1) are static. Happens at every frame setting that is a multiple of 64. Also notice that everything slowly moves down and setting the fps slightly higher causes it to move upwards
RedCMD#4299 - Discord
Mandelbrot SNKEmini Minesweeper Sudoku
Lephenixnoir En ligne Administrateur Points: 20767 Défis: 143 Message

Citer : Posté le 16/06/2021 09:11 | #


Your figures are definitely accurate. It tried with 768 Hz, and got the same result as you (alternating black/white stripes due to VRAM changing while rendering is performed).

I had an idea. Some shades are much cleaner at higher refresh rates, while others are only visible at smaller ones (typically: just 64, anything else gives static stripes). This suggests that a different encodingof gray values on the VRAM might give better uniform results. (I haven't looked at your VRAM encoding yet, but I will sure do soon enough!)

I didn't have to tune any timings. Other than just setting the screen refresh rate to 64Hz

Maybe 64 Hz is the "unifying" factor that works everywhere, and previous engine delays were affected by overclock or other independent sources. I hope so, it would make things much easier! I will try on a variety of models when I can.

Pϕ/16, Pϕ/64, Pϕ/256 and Pϕ/1024 do not have this problem. And Pϕ/4 is less stable at very high frame rates, flucturating around, while the others stay fine until almost max fps is reached.

This seems to make sense. In this case, let's use whatever works best!
Redcmd Hors ligne Membre Points: 306 Défis: 5 Message

Citer : Posté le 16/06/2021 16:38 | # | Fichier joint


This suggests that a different encoding of gray values on the VRAM might give better uniform results.



[TAN] and [->] range is now from 13 to 127
70 is halfway, 26 and 115 are smooth
ManyGray9750.zip
Should work on SH3 now
RedCMD#4299 - Discord
Mandelbrot SNKEmini Minesweeper Sudoku
Lephenixnoir En ligne Administrateur Points: 20767 Défis: 143 Message

Citer : Posté le 16/06/2021 16:50 | #


Now that does look good for sure! Unfortunately, it's unstable on my Graph 75+E and it doesn't work at all on my Graph 35+E II (freezes at startup). Are there specific overclock needs or other settings that this might depend on?

I wouldn't be surprised if differences between models still existed ultimately, so as long as we can find parameters for all models, this would end up working.

Anyway, this is starting to look less like a cool improvement and more like a complete breakthrough! I love it!
Ninestars Hors ligne Membre Points: 2384 Défis: 22 Message

Citer : Posté le 18/06/2021 18:54 | #


In short, we could get 64 steps from white to black, instead of 4 currently ?
Sounds great
Lephenixnoir En ligne Administrateur Points: 20767 Défis: 143 Message

Citer : Posté le 19/06/2021 14:15 | #


64 steps ? It doesn't seem to be headed that way (to me at least). 64 Hz doesn't mean you can get 64 steps. I think the first obvious outcome is increase the quality of 4-color gray, then look for 8 or 16 if that is possible. But that would still need quite a bit of work in software to convert and display images.

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2021 | Il y a 125 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd