<erichvk>
eintopf, always putting .de before english words too
<planasb>
:)
<eintopf>
:-)
ecloud has quit [Ping timeout: 246 seconds]
dandon has joined #qi-hardware
ecloud has joined #qi-hardware
eintopf_ has joined #qi-hardware
eintopf has quit [Ping timeout: 246 seconds]
eintopf_ is now known as eintopf
<DocScrutinizer05>
planasb: no, iirc it is printed in BOLD in user maual of N950: "DO NOT USE SIM ADAPTERS!"
<planasb>
DocScrutinizer05: thanks.. just removed
<DocScrutinizer05>
and I heard of several N950 that got killed by the SIM adapter locking up in the holder and breaking it by removal
<planasb>
DocScrutinizer05: i remembered you was talking about it..
<DocScrutinizer05>
the contacts springs lock up in the gap between SIM and adapter frame
<eintopf>
:o
<eintopf>
sorry
<eintopf>
I didn't know that
<planasb>
everything ok
* eintopf
thought it's just different form-factor
<DocScrutinizer05>
it is, and so you need an adapter frame
<DocScrutinizer05>
and any tiny gap or step between SIM and that adapter frame will catch the contact springs
<DocScrutinizer05>
at least that's what I heard, can't confirm first hand ;-)
<DocScrutinizer05>
maybe there's not even a 'bootom' of SIM holder opposite of the contacts, so the smaller SIM could completely "fall through" the the adapter frame and vanish inside device
<DocScrutinizer05>
nottom*
<DocScrutinizer05>
dang, Bottom
<eintopf>
maybe put some "sellotape" around to fill the gaps
<eintopf>
but not on the contacts
<eintopf>
then everything will also be smother to not cratch the contacts
<eintopf>
smoother
<eintopf>
:-)
<DocScrutinizer05>
yes, might help. On your own peril though
<DocScrutinizer05>
and when the contacts actually catch up, do NEVER USE FORCE to remove SIM! Instead insert a thin sheet of stiff metal or plastic above the SIM over the contact pads, to unlock the contact springs
<DocScrutinizer05>
note I've heard of some broken N950 due to that issue, but never of a repaired one
pcercuei has joined #qi-hardware
<planasb>
hello. i have fpga and i want to generate VGA signal. But I want connect Arduino. Arduino will send commands like 'putpixel 10 10 color'. OK, but i know what it's possible update VRAM only than VBLANK occurs. O to implement busy loop with fpga ?
<planasb>
DocScrutinizer05: eintopf ?
<DocScrutinizer05>
sorry?
<DocScrutinizer05>
please rephrase
<planasb>
ok, i will try
<DocScrutinizer05>
applying pattern recognition and associative solving, I think the answer is "use IRQ attached to VBLANK"
<planasb>
I want connect Arduino with FPGA. And FPGA will be used as VGA controller. I want to send command with Arduino to FPGA like 'putpixel x y color' .. But problem I can't write data to FPGA VRAM anytime.
<planasb>
DocScrutinizer05: If Arduino will send many commands. But if it's not ready to write to framebuffer ?
<planasb>
DocScrutinizer05: I need make another command ? And Arduino will check if data is written to FPGA VRAM ?
<DocScrutinizer05>
I'd create a VTAM shadow buffer I can write to any time I want. Then I'd (DMA?)-copy that shadow buffer to VRAM during VBLANK, in an IRQ handler that gets triggered on VBLANK. -- To Be Checked: can the copy complete during the VBLANK time span
<planasb>
yes
<planasb>
DocScrutinizer05: How it's solved on CGA ? it's so luxury to have shadow buffer ..
<planasb>
MDA had SNOW :)
<DocScrutinizer05>
if you wanna go fancy, have a flag "needs update" and copy only (during VBLANK IRQ) if that flag is set, then reset the flag after copying completed
<DocScrutinizer05>
*usually* you solve that on hw level in this way: simply output all black to VGA during access to VRAM by CPU. Though this creates atrifacts on screen, those are hardly visible since... they are black
<DocScrutinizer05>
very busy changes on VRAM cause display to dim somewhat
<DocScrutinizer05>
this assumes your writes take a fraction of one scanline, so 1/16000s / N
<planasb>
DocScrutinizer05: thank you!
<DocScrutinizer05>
each write. When you have multiple writes during one frame (1/50s or 1/100s) then you have multiple tiny black stipes in that frame
<planasb>
:)
<DocScrutinizer05>
you should avoid too busy writes for too long time
<DocScrutinizer05>
so never gave >25% of a frame 'muted'
<DocScrutinizer05>
have*
<DocScrutinizer05>
but usually that's given by the way the write algos work
<DocScrutinizer05>
another usually used method is double buffering, where VRAM is twice the needed size, two banks, and TV output is rad out from buffer 1, buffer 2, 1, 2, ...
<planasb>
:)
<DocScrutinizer05>
and CPU always writes to the bank that's not read by Video out same time
<planasb>
and how they synched ?
<planasb>
two buffers ?
<DocScrutinizer05>
you still need to synchronize to VBLANK and make sure you update both buffers
<planasb>
ah, yes
<DocScrutinizer05>
it's just the smarter way instead the aformentioned DMA-copy
<DocScrutinizer05>
could also get used together with shadow buffer to extend timespan available for the DMA-copy from shadow to VRAM to one full frame duration, at the expense you have to do it twice in a row
<DocScrutinizer05>
or if you have control over the video readout machine, you simply write to bank2 VRAM as long and as slow as you want, while video is all the time from bank1. When you're done you simply reprogram video readout to use bank2 instead of bank1 and you write to bank1 - IOW you swap the VRAM-shadow and the active VRAM bank instead of DMA-copy
<DocScrutinizer05>
in that scenario the swapping/reprogramming needs to get synced to VBLANK. You'll see tearing or whatsitcalled if you don't
<DocScrutinizer05>
.
<DocScrutinizer05>
all this very much depends on your particular hardware and what it can do
<planasb>
thank you! I will try to use shadow vram
<planasb>
DocScrutinizer05: 'you still need to synchronize to VBLANK and make sure you update both buffers' << So i need sync in HBLANK periods ?
<DocScrutinizer05>
VBLANK
<planasb>
ok
<DocScrutinizer05>
HBLANK is once per scanline and thus 500 to 2000 times per frame, for a very short time span
<DocScrutinizer05>
VBLANK is between two frames, for 'an eternity' compared to HBLANK
<DocScrutinizer05>
'eternity' = several dozen complete scanlines duration
<DocScrutinizer05>
and your next frame has a new complete content that has no artifacts from switching old->new
<planasb>
'another usually used method is double buffering, where VRAM is twice the needed size, two banks, and TV output is rad out from buffer 1, buffer 2, 1, 2, ...' << sorry don't understand how this faster than just two plain buffers ?
<DocScrutinizer05>
switching Video readout framebiffer addr is faster than doing a copy
<DocScrutinizer05>
it easily can get done during VSYNC, no matter how slow's your CPU
<planasb>
'switching Video readout framebiffer addr is faster than doing a copy' makes sense
<DocScrutinizer05>
also forget about the >>TV output is read out from buffer 1, buffer 2, 1, 2, ...' << since this actually only applies to TV for (de)interlacing. it's not a commonly useful technique. Refer to ^^^ last URL for how pingpong VRAM doublebuffering works
<DocScrutinizer05>
the "incorrect" part in my description is about the way the switching/swap is handled
<DocScrutinizer05>
and >>could also get used together with shadow buffer to extend timespan available for the DMA-copy from shadow to VRAM to one full frame duration, at the expense you have to do it twice in a row<< is mere BS referring to RAM-only compositors etc, not applicable here
erichvk has quit [Ping timeout: 240 seconds]
<DocScrutinizer05>
if you're free to choose hw implementation (is assume that from FPGA being mentioned), you should use two banks of VRAM, display active front buffer by pointing the Video readout hardware to it, while your "CPU" writes to the back (shadow) buffer. once you're done with creating a new complete image in back buffer, you set a flag that allows the VBLANK IRQ handler (might as well be hardware resp in fpga) to swap front and back VRAM
<DocScrutinizer05>
bank (point to 2nd bank) and reset the flag. Your "software" aka "CPU" must not write to back buffer as long as that flag is set, to not "destroy" the completed display. Once buffers got swapped - and flag cleared by IRQ handler - you can clear the complete back buffer and draw a new display content to it
<DocScrutinizer05>
if you accept tearing (upper half old, then lower half new image for one frame), you forget about VBLANK IRQ completely and simply let "CPU" do the swapping
<DocScrutinizer05>
tearing only is a problem when you got moving content
<DocScrutinizer05>
particularly scrolling text upward will possibly cause loss / hiding of a line of text (or more) at the border between upper old and lower new content
<DocScrutinizer05>
if you have 30 lines of text filling the screen, and a framerate of 60fps, then tearing will hide exactly one line when you scroll up by a speed of one screen (30 lines) per 0.5s
<whitequark>
interestingly on this laptop I get diagonal tearing
<DocScrutinizer05>
unless my math sucks
<whitequark>
when scrolling in chromium
<whitequark>
not sure what's up with it
<DocScrutinizer05>
whitequark: always or only when displaying videos?
<whitequark>
always
<whitequark>
why would displaying videos matter?
<DocScrutinizer05>
strange
<DocScrutinizer05>
videos use special buffer handling to get the needed framerate done
<whitequark>
nah, chromium does that for everything
<DocScrutinizer05>
not unusual that the video 'screen' lags behind when you move the window containing it
<whitequark>
it better, because this is a 3200x1800 display and you can't render fast enough to get decent scroll on CPU
<DocScrutinizer05>
(tearing) and it's only chromium? or everything?
<larsc>
maybe the buffers are tiled
<whitequark>
chromium is where I noticed it
<larsc>
or what's the angle?
<whitequark>
doesn't seem to happen in my editor, for some resaon
<whitequark>
larsc: 45°
<larsc>
that's funny
<DocScrutinizer05>
indeed
<DocScrutinizer05>
45° independent of scrolling speed?
<whitequark>
yeah
<DocScrutinizer05>
ultra-weird
<DocScrutinizer05>
no idea how that happens
<whitequark>
it seems like there's a race between the pixel output 'thread' and rasterizer 'thread'
<whitequark>
and e.g. it can rasterize 1.1 scanline while outputting 1.0 scanline to display
<DocScrutinizer05>
rotation chip involved?
<whitequark>
rotation chip?
<DocScrutinizer05>
(when the display scans left-to-right instead up-to-down)
<whitequark>
it's 45° from top left to right bottom
<whitequark>
so no rotation needed
<DocScrutinizer05>
nah, often the SoC's video hardware can only do top-down scanning while the display is basicall a portrait display scanning left-right or right-left when viewed at in landscape orientation. You need a hw rotation chip then
<DocScrutinizer05>
hail smartphones :-/
<whitequark>
ahh
<DocScrutinizer05>
done in Pyra :-S
<DocScrutinizer05>
design wise and technically a nightmare
<DocScrutinizer05>
and I could see the rotation chip introducing exactly this type of 45° tearing, possibly
<whitequark>
no, this is intel integrated video
<whitequark>
it always supported rotation in hardware
<DocScrutinizer05>
ok
<DocScrutinizer05>
well, "rotation in hardware" is an embedded rotation chip basically. Unless the video scanning hardware (those counters doing the addressing in VRAM readout) can't do it genuinely, you might see same problems from rotating the data before writing it to video buffer, or during copying it from one area of videobuffer to another
<DocScrutinizer05>
for genuine scanmode selection you need to be able to program those readout counters to do increments of <one scanline worth of bytes> instead of <one pixel worth of bytes>, and vice versa
<DocScrutinizer05>
for an 8*8 framebuffer you need to scan 0,8,16,24,32,40,48,56,1,9,17...
<DocScrutinizer05>
hen you write (X direction -> ) and read (Y top-down) to such a rotating framebuffer concurrently, I can see diagonal tearing being the result
<whitequark>
ah, hm
<DocScrutinizer05>
for up-down and left-right the tearing diagonal is upper-left to lower-right
<DocScrutinizer05>
and 45° for identical framerates on a 1:1 side ratio display
<DocScrutinizer05>
you again would need pingpong buffering for the rotator function block, decoupling writes from scan reads
<DocScrutinizer05>
if your scan counters can get programmed, you exploit the genuine double buffering (when there's any)
<DocScrutinizer05>
what a stinking pile of ancient legacy, this whole raster scan paradigm :-/
<DocScrutinizer05>
particularly the interface protocols that still have stuff like VSYNC and HSYNC and a left-right/top-down concept
<DocScrutinizer05>
well, it works (as a concept), but...
<DocScrutinizer05>
ideally a LCD would have 'random access' memory to address any pixel individually, and user defines a format how they're sending the data
<DocScrutinizer05>
left-right/top-down is so... CRT
<DocScrutinizer05>
or actually even mirror prism ;-)
<DocScrutinizer05>
CRT would already benefit from left-right-LEFT/top-down-TOP ;-)
<DocScrutinizer05>
technically, not physiological (like "avoid flicker" etc)
* DocScrutinizer05
idly wonders if, when they had invented TV in a time where there were already electron tubes for everything, they had opted for a spiral scan like a vinyl record, so both the X and Y deflection could run with sine waves phase shifted by 90°
<DocScrutinizer05>
prolly not since for constant beam deflection velocity (->brightness) it needs wobbling the deflection sine waves inverse proportional to amplitude, and that's a tad demanding implementation- and sync-wise
<DocScrutinizer05>
s/(brightness)/\1 and resolution/
<qi-bot>
DocScrutinizer05 meant: "prolly not since for constant beam deflection velocity (->brightness and resolution) it needs wobbling the deflection sine waves inverse proportional to amplitude, and that's a tad demanding implementation- and sync-wise"