IRC log for #qi-hardware on 20170306

04:30.12*** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org)
04:30.12*** mode/#qi-hardware [+v _whitelogger] by ChanServ
05:20.15*** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg)
06:09.11*** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org)
06:09.11*** mode/#qi-hardware [+v _whitelogger] by ChanServ
06:53.00planasbDocScrutinizer05: can I use Nokia N950 with SIM which has different sizes ?
07:02.50eintopfI putted some smaller sim in a bigger slim slot... but it was somehow a lossy connection
07:03.06eintopfyou need to put some papers around it, that it cannot move around
07:03.12eintopfor buying adapters
07:03.54eintopfs/putted/put/
07:04.13eintopfalways "ed" english words for past time
07:07.22planasbeintopf: thanks
07:08.15eintopfplanasb: https://de.aliexpress.com/item/4-in-1-Nano-SIM-Card-Adapters-Micro-SIM-Adapters-Standard-SIM-Card-Adapter-Eject-Pin/32489148250.html
07:08.54eintopfforget the ".de"
07:09.11planasbeintopf: thanks
07:11.09erichvkeintopf, always putting .de before english words too
07:11.49planasb:)
07:11.51eintopf:-)
07:20.08*** join/#qi-hardware dandon (~dandon@185.16.53.101)
07:21.23*** join/#qi-hardware ecloud (quassel@nat/qt/x-arzeocdsychpemgv)
08:25.31*** join/#qi-hardware eintopf_ (~eintopf@unaffiliated/eintopf)
09:00.36DocScrutinizer05planasb: no, iirc it is printed in BOLD in user maual of N950: "DO NOT USE SIM ADAPTERS!"
09:01.24planasbDocScrutinizer05: thanks.. just removed
09:01.28DocScrutinizer05and I heard of several N950 that got killed by the SIM adapter locking up in the holder and breaking it by removal
09:02.01planasbDocScrutinizer05: i remembered you was talking about it..
09:02.21DocScrutinizer05the contacts springs lock up in the gap between SIM and adapter frame
09:02.34eintopf:o
09:02.40eintopfsorry
09:02.44eintopfI didn't know that
09:02.48planasbeverything ok
09:03.51eintopfthought it's just different form-factor
09:12.13DocScrutinizer05it is, and so you need an adapter frame
09:13.40DocScrutinizer05and any tiny gap or step between SIM and that adapter frame will catch the contact springs
09:15.04DocScrutinizer05at least that's what I heard, can't confirm first hand ;-)
09:17.28DocScrutinizer05maybe 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
09:17.37DocScrutinizer05nottom*
09:18.05DocScrutinizer05dang, Bottom
09:22.28eintopfmaybe put some "sellotape" around to fill the gaps
09:22.34eintopfbut not on the contacts
09:23.06eintopfthen everything will also be smother to not cratch the contacts
09:23.09eintopfsmoother
09:23.14eintopf:-)
09:26.50DocScrutinizer05yes, might help. On your own peril though
09:29.07DocScrutinizer05and 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
09:30.39DocScrutinizer05note I've heard of some broken N950 due to that issue, but never of a repaired one
10:27.57*** join/#qi-hardware pcercuei (~paul@137.71.226.54)
11:15.40planasbhello. 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.46planasbDocScrutinizer05: eintopf ?
11:16.50DocScrutinizer05sorry?
11:17.00DocScrutinizer05please rephrase
11:17.21planasbok, i will try
11:20.08DocScrutinizer05applying pattern recognition and associative solving, I think the answer is "use IRQ attached to VBLANK"
11:20.52planasbI 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:21.36planasbDocScrutinizer05: If Arduino will send many commands. But if it's not ready to write to framebuffer ?
11:23.28planasbDocScrutinizer05: I need make another command ? And Arduino will check if data is written to FPGA VRAM ?
11:23.36DocScrutinizer05I'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
11:23.56planasbyes
11:24.26planasbDocScrutinizer05: How it's solved on CGA ? it's so luxury to have shadow buffer ..
11:24.35planasbMDA had SNOW :)
11:24.53DocScrutinizer05if 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
11:26.47DocScrutinizer05*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
11:27.32DocScrutinizer05very busy changes on VRAM cause display to dim somewhat
11:28.28DocScrutinizer05this assumes your writes take a fraction of one scanline, so 1/16000s / N
11:29.38planasbDocScrutinizer05: thank you!
11:29.54DocScrutinizer05each write. When you have multiple writes during one frame (1/50s or 1/100s) then you have multiple tiny black stipes in that frame
11:30.15planasb:)
11:30.29DocScrutinizer05you should avoid too busy writes for too long time
11:30.51DocScrutinizer05so never gave >25% of a frame 'muted'
11:30.54DocScrutinizer05have*
11:31.28DocScrutinizer05but usually that's given by the way the write algos work
11:35.28DocScrutinizer05another 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:36.07planasb:)
11:36.20DocScrutinizer05and CPU always writes to the bank that's not read by Video out same time
11:36.50planasband how they synched ?
11:36.56planasbtwo buffers ?
11:36.59DocScrutinizer05you still need to synchronize to VBLANK and make sure you update both buffers
11:37.09planasbah, yes
11:37.37DocScrutinizer05it's just the smarter way instead the aformentioned DMA-copy
11:39.09DocScrutinizer05could 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
11:41.15DocScrutinizer05or 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
11:42.20DocScrutinizer05in that scenario the swapping/reprogramming needs to get synced to VBLANK. You'll see tearing or whatsitcalled if you don't
11:43.12DocScrutinizer05.
11:43.29DocScrutinizer05all this very much depends on your particular hardware and what it can do
11:45.05planasbthank you! I will try to use shadow vram
11:45.12DocScrutinizer05:-)
11:47.52planasbhttps://kesrut.wordpress.com/2015/02/10/driving-ibm-5151-monitor-with-fpga-wip/
11:48.02planasball my skills :/
11:55.27planasbDocScrutinizer05: 'you still need to synchronize to VBLANK and make sure you update both buffers' << So i need sync in HBLANK periods ?
11:56.20DocScrutinizer05VBLANK
11:56.27planasbok
11:57.19DocScrutinizer05HBLANK is once per scanline and thus 500 to 2000 times per frame, for a very short time span
11:58.08DocScrutinizer05VBLANK is between two frames, for 'an eternity' compared to HBLANK
11:58.37DocScrutinizer05'eternity' = several dozen complete scanlines duration
11:59.31DocScrutinizer05and your next frame has a new complete content that has no artifacts from switching old->new
12:00.01planasb'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.40DocScrutinizer05switching Video readout framebiffer addr is faster than doing a copy
12:01.19DocScrutinizer05it easily can get done during VSYNC, no matter how slow's your CPU
12:01.57planasb'switching Video readout framebiffer addr is faster than doing a copy' makes sense
12:05.59DocScrutinizer05https://en.wikipedia.org/wiki/Multiple_buffering
12:07.06planasbthanks!
12:12.14DocScrutinizer05https://en.wikipedia.org/wiki/Multiple_buffering#Page_flipping
12:22.46DocScrutinizer05also 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
12:23.45DocScrutinizer05the "incorrect" part in my description is about the way the switching/swap is handled
12:24.59DocScrutinizer05and >>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
12:31.34DocScrutinizer05if 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.36DocScrutinizer05bank (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
12:33.55DocScrutinizer05if 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
12:35.38DocScrutinizer05tearing only is a problem when you got moving content
12:36.58DocScrutinizer05particularly 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
12:38.50DocScrutinizer05if 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
12:39.20whitequarkinterestingly on this laptop I get diagonal tearing
12:39.21DocScrutinizer05unless my math sucks
12:39.25whitequarkwhen scrolling in chromium
12:39.28whitequarknot sure what's up with it
12:46.41DocScrutinizer05whitequark: always or only when displaying videos?
12:46.58whitequarkalways
12:47.12whitequarkwhy would displaying videos matter?
12:47.16DocScrutinizer05strange
12:47.35DocScrutinizer05videos use special buffer handling to get the needed framerate done
12:48.05whitequarknah, chromium does that for everything
12:48.29DocScrutinizer05not unusual that the video 'screen' lags behind when you move the window containing it
12:48.32whitequarkit better, because this is a 3200x1800 display and you can't render fast enough to get decent scroll on CPU
12:50.23DocScrutinizer05(tearing) and it's only chromium? or everything?
12:50.24larscmaybe the buffers are tiled
12:50.44whitequarkchromium is where I noticed it
12:51.10larscor what's the angle?
12:51.10whitequarkdoesn't seem to happen in my editor, for some resaon
12:51.16whitequarklarsc: 45°
12:51.24larscthat's funny
12:51.31DocScrutinizer05indeed
12:52.21DocScrutinizer0545° independent of scrolling speed?
12:52.32whitequarkyeah
12:52.39DocScrutinizer05ultra-weird
12:52.49DocScrutinizer05no idea how that happens
12:52.57whitequarkit seems like there's a race between the pixel output 'thread' and rasterizer 'thread'
12:53.24whitequarkand e.g. it can rasterize 1.1 scanline while outputting 1.0 scanline to display
12:53.36DocScrutinizer05rotation chip involved?
12:53.45whitequarkrotation chip?
12:53.56DocScrutinizer05(when the display scans left-to-right instead up-to-down)
12:54.19whitequarkit's 45° from top left to right bottom
12:54.22whitequarkso no rotation needed
12:55.59DocScrutinizer05nah, 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
12:56.18DocScrutinizer05hail smartphones :-/
12:56.55whitequarkahh
12:57.39DocScrutinizer05done in Pyra :-S
12:58.09DocScrutinizer05design wise and technically a nightmare
12:58.40DocScrutinizer05and I could see the rotation chip introducing exactly this type of 45° tearing, possibly
12:59.39whitequarkno, this is intel integrated video
12:59.45whitequarkit always supported rotation in hardware
12:59.50DocScrutinizer05ok
13:03.14DocScrutinizer05well, "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
13:05.32DocScrutinizer05for 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
13:08.03DocScrutinizer05for an 8*8 framebuffer you need to scan 0,8,16,24,32,40,48,56,1,9,17...
13:15.48DocScrutinizer05hen you write (X direction -> ) and read (Y top-down) to such a rotating framebuffer concurrently, I can see diagonal tearing being the result
13:16.05whitequarkah, hm
13:17.15DocScrutinizer05for up-down and left-right the tearing diagonal is upper-left to lower-right
13:18.08DocScrutinizer05and 45° for identical framerates on a 1:1 side ratio display
13:20.36DocScrutinizer05you again would need pingpong buffering for the rotator function block, decoupling writes from scan reads
13:21.41DocScrutinizer05if your scan counters can get programmed, you exploit the genuine double buffering (when there's any)
13:27.46DocScrutinizer05what a stinking pile of ancient legacy, this whole raster scan paradigm :-/
13:33.00DocScrutinizer05particularly the interface protocols that still have stuff like VSYNC and HSYNC and a left-right/top-down concept
13:34.11DocScrutinizer05well, it works (as a concept), but...
13:35.53DocScrutinizer05ideally a LCD would have 'random access' memory to address any pixel individually, and user defines a format how they're sending the data
13:41.20DocScrutinizer05left-right/top-down is so... CRT
13:42.05DocScrutinizer05or actually even mirror prism ;-)
13:43.08DocScrutinizer05CRT would already benefit from left-right-LEFT/top-down-TOP ;-)
13:44.08DocScrutinizer05technically, not physiological (like "avoid flicker" etc)
13:50.00DocScrutinizer05idly 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:53.34DocScrutinizer05prolly 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
13:54.30DocScrutinizer05s/(brightness)/\1 and resolution/
13:54.30qi-botDocScrutinizer05 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"
13:54.42DocScrutinizer05LOL that works!
14:14.34*** join/#qi-hardware erichvk (~esh@ppp118-210-80-110.lns20.adl2.internode.on.net)
14:16.52DocScrutinizer05didn't know that https://de.wikipedia.org/wiki/Wobbelgenerator wasn't a term in English
14:23.39DocScrutinizer05also s/ mirror prism / https://en.wikipedia.org/wiki/Nipkow_disk /
14:29.18*** join/#qi-hardware sandeepkr (~sandeepkr@43.231.59.251)
15:54.23*** join/#qi-hardware pcercuei (~paul@137.71.226.54)
16:14.15*** join/#qi-hardware fengling (~fengling@223.223.187.142)
16:19.40*** join/#qi-hardware xiangfu (~xiangfu@223.223.187.142)
16:40.28*** join/#qi-hardware xiangfu (~xiangfu@223.223.187.142)
18:40.17*** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander)
18:59.10*** join/#qi-hardware sandeepkr (~sandeepkr@43.231.58.214)
19:03.46*** join/#qi-hardware pcercuei (~pcercuei@92.177.36.45)
20:02.34*** join/#qi-hardware sandeepkr (~sandeepkr@43.231.58.214)
20:22.31*** join/#qi-hardware sandeepkr (~sandeepkr@43.231.58.214)
21:27.27*** join/#qi-hardware infobot (ibot@rikers.org)
21:27.27*** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
21:27.27*** mode/#qi-hardware [+v infobot] by ChanServ
21:27.39*** join/#qi-hardware sandeepkr (~sandeepkr@43.231.58.214)
21:58.45*** join/#qi-hardware sandeepkr (~sandeepkr@43.231.59.220)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.