#qi-hardware IRC log for Monday, 2017-03-06

--- Mon Mar 6 201700:00
planasbDocScrutinizer05: can I use Nokia N950 with SIM which has different sizes ?06:53
eintopfI putted some smaller sim in a bigger slim slot... but it was somehow a lossy connection07:02
eintopfyou need to put some papers around it, that it cannot move around07:03
eintopfor buying adapters07:03
eintopfs/putted/put/07:03
Action: eintopf always "ed" english words for past time07:04
planasbeintopf: thanks07:07
eintopfplanasb: https://de.aliexpress.com/item/4-in-1-Nano-SIM-Card-Adapters-Micro-SIM-Adapters-Standard-SIM-Card-Adapter-Eject-Pin/32489148250.html07:08
eintopfforget the ".de"07:08
planasbeintopf: thanks07:09
erichvkeintopf, always putting .de before english words too07:11
planasb:)07:11
eintopf:-)07:11
DocScrutinizer05planasb: no, iirc it is printed in BOLD in user maual of N950: "DO NOT USE SIM ADAPTERS!"09:00
planasbDocScrutinizer05: thanks.. just removed09:01
DocScrutinizer05and I heard of several N950 that got killed by the SIM adapter locking up in the holder and breaking it by removal09:01
planasbDocScrutinizer05: i remembered you was talking about it..09:02
DocScrutinizer05the contacts springs lock up in the gap between SIM and adapter frame09:02
eintopf:o09:02
eintopfsorry09:02
eintopfI didn't know that09:02
planasbeverything ok09:02
Action: eintopf thought it's just different form-factor09:03
DocScrutinizer05it is, and so you need an adapter frame09:12
DocScrutinizer05and any tiny gap or step between SIM and that adapter frame will catch the contact springs09:13
DocScrutinizer05at least that's what I heard, can't confirm first hand ;-)09:15
DocScrutinizer05maybe 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 device09:17
DocScrutinizer05nottom*09:17
DocScrutinizer05dang, Bottom09:18
eintopfmaybe put some "sellotape" around to fill the gaps09:22
eintopfbut not on the contacts09:22
eintopfthen everything will also be smother to not cratch the contacts09:23
eintopfsmoother09:23
eintopf:-)09:23
DocScrutinizer05yes, might help. On your own peril though09:26
DocScrutinizer05and 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 springs09:29
DocScrutinizer05note I've heard of some broken N950 due to that issue, but never of a repaired one09:30
planasbhello. 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 ? 11:15
planasbDocScrutinizer05: eintopf ?11:15
DocScrutinizer05sorry?11:16
DocScrutinizer05please rephrase11:17
planasbok, i will try11:17
DocScrutinizer05applying pattern recognition and associative solving, I think the answer is "use IRQ attached to VBLANK"11:20
planasbI 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. 11:20
planasbDocScrutinizer05: If Arduino will send many commands. But if it's not ready to write to framebuffer ?11:21
planasbDocScrutinizer05: I need make another command ? And Arduino will check if data is written to FPGA VRAM ?11:23
DocScrutinizer05I'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 span11:23
planasbyes11:23
planasbDocScrutinizer05: How it's solved on CGA ? it's so luxury to have shadow buffer ..11:24
planasbMDA had SNOW :)11:24
DocScrutinizer05if 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 completed11:24
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 black11:26
DocScrutinizer05very busy changes on VRAM cause display to dim somewhat11:27
DocScrutinizer05this assumes your writes take a fraction of one scanline, so 1/16000s / N11:28
planasbDocScrutinizer05: thank you!11:29
DocScrutinizer05each write. When you have multiple writes during one frame (1/50s or 1/100s) then you have multiple tiny black stipes in that frame11:29
planasb:)11:30
DocScrutinizer05you should avoid too busy writes for too long time11:30
DocScrutinizer05so never gave >25% of a frame 'muted'11:30
DocScrutinizer05have*11:30
DocScrutinizer05but usually that's given by the way the write algos work11:31
DocScrutinizer05another 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, ...11:35
planasb:)11:36
DocScrutinizer05and CPU always writes to the bank that's not read by Video out same time11:36
planasband how they synched ?11:36
planasbtwo buffers ?11:36
DocScrutinizer05you still need to synchronize to VBLANK and make sure you update both buffers11:36
planasbah, yes11:37
DocScrutinizer05it's just the smarter way instead the aformentioned DMA-copy11:37
DocScrutinizer05could 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 row11:39
DocScrutinizer05or 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-copy11:41
DocScrutinizer05in that scenario the swapping/reprogramming needs to get synced to VBLANK. You'll see tearing or whatsitcalled if you don't11:42
DocScrutinizer05.11:43
DocScrutinizer05all this very much depends on your particular hardware and what it can do11:43
planasbthank you! I will try to use shadow vram11:45
DocScrutinizer05:-)11:45
planasbhttps://kesrut.wordpress.com/2015/02/10/driving-ibm-5151-monitor-with-fpga-wip/11:47
planasball my skills :/11:48
planasbDocScrutinizer05: 'you still need to synchronize to VBLANK and make sure you update both buffers' << So i need sync in HBLANK periods ?11:55
DocScrutinizer05VBLANK11:56
planasbok11:56
DocScrutinizer05HBLANK is once per scanline and thus 500 to 2000 times per frame, for a very short time span11:57
DocScrutinizer05VBLANK is between two frames, for 'an eternity' compared to HBLANK11:58
DocScrutinizer05'eternity' = several dozen complete scanlines duration11:58
DocScrutinizer05and your next frame has a new complete content that has no artifacts from switching old->new11:59
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 ?12:00
DocScrutinizer05switching Video readout framebiffer addr is faster than doing a copy12:00
DocScrutinizer05it easily can get done during VSYNC, no matter how slow's your CPU12:01
planasb'switching Video readout framebiffer addr is faster than doing a copy' makes sense12:01
DocScrutinizer05https://en.wikipedia.org/wiki/Multiple_buffering12:05
planasbthanks!12:07
DocScrutinizer05https://en.wikipedia.org/wiki/Multiple_buffering#Page_flipping12:12
DocScrutinizer05also 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 works12:22
DocScrutinizer05the "incorrect" part in my description is about the way the switching/swap is handled12:23
DocScrutinizer05and >>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 here12:24
DocScrutinizer05if 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 12:31
DocScrutinizer05bank (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 it12:31
DocScrutinizer05if 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 swapping12:33
DocScrutinizer05tearing only is a problem when you got moving content12:35
DocScrutinizer05particularly scrolling text upward will possibly cause loss / hiding of a line of text (or more) at the border between upper old and lower new content12:36
DocScrutinizer05if 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.5s12:38
whitequarkinterestingly on this laptop I get diagonal tearing12:39
DocScrutinizer05unless my math sucks12:39
whitequarkwhen scrolling in chromium12:39
whitequarknot sure what's up with it12:39
DocScrutinizer05whitequark: always or only when displaying videos?12:46
whitequarkalways12:46
whitequarkwhy would displaying videos matter?12:47
DocScrutinizer05strange12:47
DocScrutinizer05videos use special buffer handling to get the needed framerate done12:47
whitequarknah, chromium does that for everything12:48
DocScrutinizer05not unusual that the video 'screen' lags behind when you move the window containing it12:48
whitequarkit better, because this is a 3200x1800 display and you can't render fast enough to get decent scroll on CPU12:48
DocScrutinizer05(tearing) and it's only chromium? or everything?12:50
larscmaybe the buffers are tiled12:50
whitequarkchromium is where I noticed it12:50
larscor what's the angle?12:51
whitequarkdoesn't seem to happen in my editor, for some resaon12:51
whitequarklarsc: 45°12:51
larscthat's funny12:51
DocScrutinizer05indeed12:51
DocScrutinizer0545° independent of scrolling speed?12:52
whitequarkyeah12:52
DocScrutinizer05ultra-weird12:52
DocScrutinizer05no idea how that happens12:52
whitequarkit seems like there's a race between the pixel output 'thread' and rasterizer 'thread'12:52
whitequarkand e.g. it can rasterize 1.1 scanline while outputting 1.0 scanline to display12:53
DocScrutinizer05rotation chip involved?12:53
whitequarkrotation chip?12:53
DocScrutinizer05(when the display scans left-to-right instead up-to-down)12:53
whitequarkit's 45° from top left to right bottom12:54
whitequarkso no rotation needed12:54
DocScrutinizer05nah, 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 then12:55
DocScrutinizer05hail smartphones :-/12:56
whitequarkahh12:56
DocScrutinizer05done in Pyra :-S12:57
DocScrutinizer05design wise and technically a nightmare12:58
DocScrutinizer05and I could see the rotation chip introducing exactly this type of 45° tearing, possibly12:58
whitequarkno, this is intel integrated video12:59
whitequarkit always supported rotation in hardware12:59
DocScrutinizer05ok12:59
DocScrutinizer05well, "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 another13:03
DocScrutinizer05for 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 versa13:05
DocScrutinizer05for an 8*8 framebuffer you need to scan 0,8,16,24,32,40,48,56,1,9,17...13:08
DocScrutinizer05hen you write (X direction -> ) and read (Y top-down) to such a rotating framebuffer concurrently, I can see diagonal tearing being the result13:15
whitequarkah, hm13:16
DocScrutinizer05for up-down and left-right the tearing diagonal is upper-left to lower-right13:17
DocScrutinizer05and 45° for identical framerates on a 1:1 side ratio display13:18
DocScrutinizer05you again would need pingpong buffering for the rotator function block, decoupling writes from scan reads13:20
DocScrutinizer05if your scan counters can get programmed, you exploit the genuine double buffering (when there's any)13:21
DocScrutinizer05what a stinking pile of ancient legacy, this whole raster scan paradigm :-/13:27
DocScrutinizer05particularly the interface protocols that still have stuff like VSYNC and HSYNC and a left-right/top-down concept13:33
DocScrutinizer05well, it works (as a concept), but...13:34
DocScrutinizer05ideally a LCD would have 'random access' memory to address any pixel individually, and user defines a format how they're sending the data13:35
DocScrutinizer05left-right/top-down is so... CRT13:41
DocScrutinizer05or actually even mirror prism ;-)13:42
DocScrutinizer05CRT would already benefit from left-right-LEFT/top-down-TOP ;-)13:43
DocScrutinizer05technically, not physiological (like "avoid flicker" etc)13:44
Action: 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°13:50
DocScrutinizer05prolly 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-wise13:53
DocScrutinizer05s/(brightness)/\1 and resolution/13:54
DocScrutinizer05LOL that works!13:54
DocScrutinizer05didn't know that https://de.wikipedia.org/wiki/Wobbelgenerator wasn't a term in English14:16
DocScrutinizer05also s/ mirror prism / https://en.wikipedia.org/wiki/Nipkow_disk /14:23
--- Tue Mar 7 201700:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!