Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Discussions


Index du Forum » Discussions » Gray timings on fx-9750GII
Redcmd Hors ligne Membre Points: 380 Défis: 7 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 Hors ligne Administrateur Points: 24218 Défis: 170 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
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Redcmd Hors ligne Membre Points: 380 Défis: 7 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
Lephenixnoir Hors ligne Administrateur Points: 24218 Défis: 170 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!
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Redcmd Hors ligne Membre Points: 380 Défis: 7 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
Lephenixnoir Hors ligne Administrateur Points: 24218 Défis: 170 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!
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2461 Défis: 24 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 Hors ligne Administrateur Points: 24218 Défis: 170 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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Redcmd Hors ligne Membre Points: 380 Défis: 7 Message

Citer : Posté le 24/03/2022 10:15 | # | Fichier joint


Sadly flickering the screen with a different sequence other than 10, 110 or 100 causes this bad 'pulsing' effect
where the screen will 'pulse' off for quite a long time every few seconds
sequence 1110 and 1000 do flicker a small amount. more than what Gint currently does

The problem is that the 'ghosting' time of the pixels is not enough to flash a sequence more than 4 steps long
Lephenixnoir a écrit :
You need to have a regular cycle that is shorter than the "ghost time", and in this case the smallest period is far too long.
The sequence 10 is currently better than Gint's
Its almost impossible to see its flickering and there are very very few visual artifacts
110 and 100 is about on par with Gint's flickering


Next step to making more better grays
is to use another bad flaw with the display; which is its terrible 'bleed through' effect
when a pixel is on, it will 'bleed through' to all other pixels in the same column
this effect compounds. so as more pixels are turned on in the column the darker the 'off' pixels become
untill when you have 126/127 pixels on, the last 1/2 pixels will look almost 90% on

currently all gray engines turn every single pixel on the first frame, then every single pixel off the next frame
what if we instead delay every 2nd pixel by one frame
so only half the pixels are on the first frame, next frame the other half is on
this will create a interlacing effect (which you cant see) and because only half the pixels are on at any one time. (01010101)
the shade of gray will be around almost ~50% lighter!
(Left is normal, right is interlaced (still running at the same frequency and sequence))


one property of this is that the more pixels that are on together, the greater the effect of the bleed through
so instead of every 2nd pixel, why not do every 2nd group of 2 pixels. 01010101 -> 00110011
this creates a gray that is half way between the single interlaced and the original
the doubling can be done 4 more times til we alternative between the bottom and top half of the screen
giving us 7 shades of gray out of one single sequence
which can be applied to the other 4 sequences. allowing us to have 35 different grays! (tho some are very close to others)
so can safely say 8-16 shades

only problem with interlacing is that it requires all other pixels in the same coloumn to either be the same gray or off
every pixel that is black will change the shade of gray
but this is true for every other gray engine, so isn't too bad


I've recorded my screen at almost 1000 frames per second!
showing us the refresh rate of the display

Video was recorded at 960fps
Played back at 30fps
Display runs at 64fps
64Hz * 30fps / 2 screen refreshes = 960FPS
The screen refreshes every 15 frames or twice per second in the video

I've also recorded a single pixel and ploted the shades as it turns on and off


https://docs.google.com/spreadsheets/d/1s0ZnQ1j9Ve8PYBb7UETDX3ZCqb7Q8-O18C2aUyKzcU0
Every line is 1/64 of a second apart
Notice how quickly the pixel starts to fade after every screen refresh while its turning on
and then how slowly it is to turn off. only because its still getting refreshed!
as you can see in the graph, the pixel darkens extremely quickly, but the display driver only powers it for an extremely small amount of time
maybe increasing this time will give much better pixel response times, decreasing ghosting
tho the pixel is also still powered a small amount when it is off.
which can be very easily seen when increasing the contrast


Attached file: GrayGIII.G1A
Add-in is compatible with fx-9750GII, Graph 75+E (fx-9860GII) and Graph 35+E II (tho the Graph 35+E II seems to run at a different display frequency, giving bad grays) and the fx-9860GII emulator
Hold [EXE] while starting the add-in to see some stats
[VARS] changes the interlaced value on the 2nd half of the example gray
[EXP] switches between Pϕ/4 (0), Pϕ/16 (1), Pϕ/256 (2) and Pϕ/1024 (3) (Pϕ/4 seems to flicker a bit?)
[EXE] swtich to fullscreen mode, showing all 128 different sequences
[tan] increase sequence
[→] decrease sequence
[MENU] press twice to exit
[REPLAY] to change the frequency to which the display runs at (default 64fps)

List of sequences:
0      0
1      10000000
2      1000000
3      1000001000000
4      100000
5      10000100000
6      10000
7      10001000010000
8      100010000
9      1000100010000
10     10001000100010000
11     1000
12     1001000100010001000
13     100100010001000
14     10010001000
15     100100010010001000
16     1001000
17     10010010001001000
18     1001001000
19     10010010010001001001000
20     1001001001000
21     1001001001001000
22     1001001001001001000
23     1001001001001001001000
24     1001001001001001001001000
25     100
26     10100100100100100100100100
27     10100100100100100100100
28     10100100100100100100
29     10100100100100100
30     10100100100100
31     1010010010010100100100100
32     10100100100
33     1010010010100100100
34     101001001010010010100100100
35     10100100
36     101001010010010100100
37     1010010100100
38     101001010010100100
39     10100101001010010100100
40     10100
41     101010010100101001010010100
42     1010100101001010010100
43     10101001010010100
44     101010010100
45     1010100101010010100
46     10101001010100101010010100
47     1010100
48     10101010010101001010100
49     1010101001010100
50     1010101001010101001010100
51     101010100
52     10101010100101010100
53     10101010100
54     101010101010010101010100
55     1010101010100
56     101010101010100
57     10101010101010100
58     1010101010101010100
59     101010101010101010100
60     10101010101010101010100
61     1010101010101010101010100
62     101010101010101010101010100
63     10
64     110101010101010101010101010
65     1101010101010101010101010
66     11010101010101010101010
67     110101010101010101010
68     1101010101010101010
69     11010101010101010
70     110101010101010
71     1101010101010
72     110101010101101010101010
73     11010101010
74     11010101011010101010
75     110101010
76     1101010110101010110101010
77     1101010110101010
78     11010101101010110101010
79     1101010
80     11010110101011010101101010
81     1101011010101101010
82     110101101010
83     11010110101101010
84     1101011010110101101010
85     110101101011010110101101010
86     11010
87     11011010110101101011010
88     110110101101011010
89     1101101011010
90     110110101101101011010
91     11011010
92     110110110101101101011011010
93     1101101101011011010
94     11011011010
95     1101101101101011011011010
96     11011011011010
97     11011011011011010
98     11011011011011011010
99     11011011011011011011010
100    11011011011011011011011010
101    110
102    1110110110110110110110110
103    1110110110110110110110
104    1110110110110110110
105    1110110110110110
106    1110110110110
107    11101101101110110110110
108    1110110110
109    11101101110110110
110    1110110
111    111011101101110110
112    11101110110
113    111011101110110
114    1110111011101110110
115    1110
116    11110111011101110
117    1111011101110
118    111101110
119    11110111101110
120    11110
121    11111011110
122    111110
123    1111110111110
124    1111110
125    11111110
126    111111110
127    1


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 v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 38 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