<kristianpaul> one more lib http://www.hyperrealm.com/libconfig/ ;)
<kristianpaul> via zrafa at jlime mail list
<kristianpaul> just in case the current config file will just going to grow, wich i think acording to xiangfu todo's list..
<kristianpaul> xiangfu: ping
<xiangfu> kristianpaul: hi
<kristianpaul> xiangfu: for the cards you sent me, i remenber you we're not able to write then isnt?
<kristianpaul> or byw ftp at least..
<kristianpaul> i think this is a know bug, just wanted to confirm
<xiangfu> kristianpaul: yes. know bug. it's also mount as read only.
<kristianpaul> ah... that explain
<kristianpaul> how i can enable mount?
<kristianpaul> write support on mount**
<kristianpaul> btw zrafa pointed this interesting libconfig library
<xiangfu> kristianpaul: no. there is no write code in driver
<xiangfu> static int memcard_disk_block_write(rtems_blkdev_request *r)
<xiangfu> {
<xiangfu>   return -RTEMS_IO_ERROR;
<xiangfu> }
<kristianpaul> ergg ;)
<xiangfu> tems-milkymist.git/c/src/lib/libbsp/lm32/shared/milkymist_memcard/memcard.c LINE: 200
<xiangfu> kristianpaul: you can try to finish it :)
<kristianpaul> he, i wish i could..
<kristianpaul> but i bet this is already written may be in netbsd..
<xiangfu> kristianpaul: hmm... there is no bad block check in memcard.c
<kristianpaul> hmm
<lekernel> kristianpaul: yeah libconfig is great, I have already compiled for lm32/rtems and it works
<lekernel> but I don't use it atm
<lekernel> and no, the memory card driver isn't complete.
<terpstra> lekernel, if i might ask, now that there is (streaming) wishbone b.4, do you still see a need for the custom bus you used in the milkymist?
<lekernel> I don't know... haven't checked wb b4 in detail
<lekernel> there's a new lm32 software release by lattice btw
<terpstra> coolio
<lekernel> ftp://ftp.latticesemi.com/diamond/
<terpstra> the reason for your custom bus was for 1-1 tranfer-clock, as opposed to classic wishbone 1-2, right?
<terpstra> or was there another reason?
<lekernel> the main reason is to 1. allow pipelining and 2. simplify burst (just like a SDRAM, all the transfers are bursts of the same length)
<terpstra> ahh, ok
<lekernel> it also removes the wb_cyc signal I've never understood the purpose, too
<terpstra> wishbone B.4 makes burst even more complicated
<terpstra> the CYC line is used for arbitration
<lekernel> why not use STB for both?
<lekernel> it doesn't make sense to request the  bus if you're not transferring something to it
<terpstra> well, i only work with streaming wishbone, and there it makes sense
<terpstra> i am not entirely clear why you needed it for classic wishbone
<lekernel> I don't need it, but the spec says it should be there
<terpstra> for streaming wishbone you need it to keep the device 'open' while waiting for your streaming ACK/ERR/RTY lines to come back in
<terpstra> in classic wishbone you probably needed it for atomic test/set or increment
<terpstra> for streaming, it is much more useful in arbitration
<lekernel> well...  I don't need those atomic operations either
<lekernel> so far at least :-)
<lekernel> maybe someday i'll have multiple lm32 cores, then we'll see :)
<terpstra> in streaming wishbone, STB means push a (read|write) transfer into the queue and CYC means you are not done with the device yet
<terpstra> the lm32 doesn't have any atomic operations atm
<lekernel> yup
<terpstra> streaming wishbone has other annoyances though
<terpstra> ... why oh why is the lm32 rpm so damn huge. :P
<lekernel> which one are you using?
<lekernel> I have lost my lattice login so I'm trying to get it from ftp :)
<terpstra> fetching diamond_1_2-lm-92-i386-linux.rpm
<terpstra> i can extract the lm32/rtl folder and mail it to you if you like
<lekernel> ah, that would be cool
<lekernel> thanks
<terpstra> i will also see about repatching the patches on their last version
<terpstra> but really, a 300MB compressed archived for the 3MB uncompressed RTL. bah.
<lekernel> you're using exactly the same LM32 source as ours, right?
<terpstra> no
<terpstra> you never integrated my JTAG patches
<lekernel> ah, yes
<terpstra> also not the multiplier
<terpstra> (which really is a vendor-specific thing i guess)
<terpstra> both of those are vendor specific things really
<lekernel> yes
<lekernel> but except those small things, there are no other changes?
<terpstra> nope
<lekernel> ok, cool :)
<terpstra> i want to read the changelog for the new lm32
<terpstra> maybe they added proper pipelining!
<terpstra> (right now i have a nasty vhdl hackdpter to turn it's shitty B.3 burst mode into pipelined WB)
<lekernel> well... my other cores don't support it atm
<lekernel> so, later :p
<terpstra> all your stuff is verilog, right?
<lekernel> yes
<terpstra> then you can't use my vhdl crossbar switch anyway ;)
<lekernel> well, practically I could
<terpstra> it wouldn't be so nice
<terpstra> it uses records
<lekernel> but I don't really want to mix languages since it would cause additional difficulties the day we switch to open source synthesis
<terpstra> (at the bottom i instantiate the crossbar)
<terpstra> i understand
<terpstra> the people here who do the 'real hardware work' all use vhdl, so i had to make stuff compatible for them
<terpstra> they still use gcc 4.3 in the newest lm32 package
<lekernel> ah, I thought I saw a 4.4 somewhere
<lekernel> maybe that was with the theobroma gcc
<terpstra> they've included some of the portability fixes upstream!
<terpstra> or wait
<terpstra> not
<lekernel> there is also a 3.x LM32 gcc around which is super-broken
<terpstra> what does '#1' do in verilog?
<lekernel> e.g. variadic functions like printf() break the stack
<terpstra> they added it all over the place as compared to the last lm32_top
<lekernel> delay (for simulation)
<lekernel> like 'after' in vhdl
<terpstra> ahh
<lekernel> this is usually a bad idea to add it everywhere, since there are already delta delays in the simulator to perform that (though those in verilog are done in a cretinous way)
<terpstra> well, they add it to tons upon tons of assignments
<lekernel> argh ...
<lekernel> this is no good coding practice
<terpstra> done reading the diff
<terpstra> they changed nothing of consequence
<terpstra> all the (large patch) does is: add #1 to every synchronous assignment and 2) change clogb2 to clogb2_v1
<terpstra> still want it?
<lekernel> no
<terpstra> somewhat disappointing
<lekernel> yeah and we'll have to remove those #1's in the future
<lekernel> maybe they laid off the original lm32 team and gave it to some other guys who just maintain it so it somewhat works ...
<lekernel> that sounds like "let's fix that simulation problem one of our customers has... hmm..."
<lekernel> funny answer from google about VP8 not being open source:
<lekernel> At this point we felt it would be more helpful for VP8 proliferation to concentrate our resources around developing the IP itself.
<lekernel> I personally think that OS hardware has also less benefits than OS software as few people can access the required development tools and computational resources so they just don't have the capability of actually verifying the code they write. This is a big design (~1 M gates encoder and decoder combined) and it will take a week to run through the test suite with a single computer. A cluster of workstations and FPGA boards are in practice
<lekernel> pretty much mandatory. If the design was considerably smaller it would certainly make more sense.
<wolfspraul> lekernel: you got an answer from Google?
<wolfspraul> the 'do no evil' company?
<lekernel> maybe I should send them a picture of me holding a board from my 384-FPGA cluster :-)
<terpstra> hah
<wolfspraul> and they flat out said source code will not be released, or what?
<wolfspraul> I mean they made this big press PR statement about 'open' :-)
<lekernel> wolfspraul: got two answers... first they said "I took a look at the Milkymist SoC at your website and it really looks like a great project! However, our WebM RTL is not open source although it is free, so I don't know if there is a way we could make it part of that platform. Please let me know if you have a suggestion."
<terpstra> they have a 1M gate video decoder??
<wolfspraul> ahh
<wolfspraul> free as in beer
<wolfspraul> well, what I told you :-)
<lekernel> so I asked why not open source it, and they answered again
<roh> in short 'we are shitting you and our marketing isnt part of the "no evil" doctrine'
<lekernel> with only 8 hours delay... progress :-)
<lekernel> I'm not sure if they're meant to bullshit
<wolfspraul> I am not the least surprised, I read their original announcement exactly correct, I figure.
<lekernel> as they say: "At this point we felt it would be more helpful for VP8 proliferation to concentrate our resources around developing the IP itself. "
<wolfspraul> VP8 proliferation is their goal
<roh> lekernel: sure. i always assume people are that stupid before assuming they are evil ;)
<lekernel> _maybe_ they just not want to be bothered with stupid support request from people who can't pull it off
<lekernel> terpstra: 1M gates is encoder + decoder ... (whatever 'gate' means)
<wolfspraul> if Samsung calls and says they want this published under GPL so they can build some chips with it, it would be GPLed 1 week later
<lekernel> oh, certainly
<roh> wolfspraul: well.. try it. till they find out you arent from samsung.... its in the wild
<roh> i actually really like that idea
<wolfspraul> lekernel: you can try to sell them a few m1 as a cool development platform
<wolfspraul> roh: any status update on the cases?
<roh> wolfspraul: nope.
<wolfspraul> what was the latest status then? all material already ordered?
<wolfspraul> already arrived?
<roh> will need to mail the laser guy again. but we god rid of the old rooms, got new ones and are still working on setting everything up again
<wolfspraul> ah yes, please try to move this forward, especially get all the material in place etc.
<wolfspraul> I do need the cases soon, in a few weeks or so would be nice
<roh> nope.. havent ordered the acryllic yet.. seems the other lasercutter can use bigger sheets so i would like to optimize the size of the sheets
<wolfspraul> how about the rest? spacers, screws, feet
<roh> sure. just a matter of weeks anyhow. we are now working 3 weeks on the move fulltime ;)
<wolfspraul> yes I understand
<wolfspraul> cases are not on the critical path right now, so I'm still quiet
<roh> need to check. most i have in stock, some i need to order. especially if we move the top or so
<wolfspraul> but no need to let them become the critical path either
<wolfspraul> move the top?
<roh> because of the dmx sockets release button
<roh> atleast i remember some talk about it
<roh> bbl.. need to run now
<wolfspraul> at this moment it looks like we leave everything as is
<wolfspraul> some more comparisons, will let you know
<wolfspraul> but definitely please try to move ahead with the production run
<wolfspraul> it's a completely firm order on my side, down-payment made, clock ticking...
<wolfspraul> lots of things moving for the run
<wolfspraul> lekernel: have you tried the obk-2010cw camera?
<lekernel> yes
<lekernel> a little bit
<lekernel> so far it looks ok, except that there is no way to mount it on a regular camera stand
<lekernel> seems it needs to be screwed... well... I guess duct taped in most practical cases :-)
<wolfspraul> lekernel: no way? I liked the fact that it has a standard 1/4'' 20tpi threading
<wolfspraul> what kind of stand do you mean?
<lekernel> tripods for example
<wolfspraul> yes but it has a tripod threading
<lekernel> ah?
<wolfspraul> what does your camera look like? :-)
<wolfspraul> it should be a bullet-style, and at the bottom of the bullet is the tripod threading
<lekernel> ah, that's tripod compatible?
<lekernel> good, then :)
<wolfspraul> the package should also have included a tiny small stand
<lekernel> yeah
<wolfspraul> yes sure
<wolfspraul> in fact that little stand is crap
<wolfspraul> well maybe in some near hopeless cases it may actually help, but to me the main thing is the center bullet case
<lekernel> but I was thinking that the camera was specific to that small stand
<wolfspraul> tripod threading at bottom of that case
<wolfspraul> no
<lekernel> yeah I think we can omit that small stand
<wolfspraul> it's a standard 1/4'' 20tpi threading
<wolfspraul> that was one reason why I liked this particular model, over others
<lekernel> yeah great
<lekernel> well can you order without the small stand?
<lekernel> to me it's an useless thing
<wolfspraul> probably yes
<wolfspraul> will save a few cent, and some weight too
<wolfspraul> we can change a lot of things, but for rc3 I want to keep it simple
<wolfspraul> also for bigger changes there may be higher moq (200 units), or one-time fees etc.
<wolfspraul> especially with schematics changes or so
<wolfspraul> kicking out that stand should be easy
<lekernel> if the stand didn't fall when the camera is on it, it would still have some use... but if it requires screw mounting, well...
<wolfspraul> try the standard tripod threading
<wolfspraul> the stand is optional, that's the poin
<wolfspraul> point
<wolfspraul> but yes, it is very small so in most cases you need to fasten the stand somehow, most likely with screws
<wolfspraul> I'm sure we don't want to include a tripod as well :-) (just joking)
<wolfspraul> well keep trying and keep me posted about obk-2010cw feedback...
<wolfspraul> it should be more or less waterproof, btw
<wolfspraul> but maybe not for under-water shooting :-)
<aw> lekernel, yesterday you said that don't touch audio codec, could you check that Notes3 of figure 18 about SPDIF 48 pin? I am not sure if I understand it completely.
<lekernel> in what document? the datasheet?
<aw> yes, thank.
<aw> page 32.
<lekernel> yeah do not put R1
<lekernel> connect pin 44 to J3, done
<aw> yes, we don not need R1
<lekernel> iirc there is an internal pull down so we don't need anything else
<lekernel> and you connect pin 48 directly to J3 as well
<lekernel> only two trivial modifications
<aw> pin44 to J3?
<lekernel> pin 44 _and_ pin 48
<lekernel> directly to J3 without any other parts
<aw> so pin 44 to J3, means you want enable this from outside, right?
<lekernel> yes
<aw> umm...okay.
<aw> i tied pin 44 to 3V3 by h/w it self to enable, good idea to let user to enable though. thanks.
<kristianpaul> argg my lattice account loginn. but i get a 0 bytes rpm file... :S
<lekernel> anything enabled is a potential source of problems, so disable it by default :)
<aw_> some sort of a good conceipt. :)
<lekernel> yeah p.8 of the datasheet says the spdif enable pin has an internal pull down
<lekernel> so nothing else needs to be connected on it
<aw_> umm..wait see page 16.
<lekernel> Pin 48 may be used to output the PCM DAC playback data in SPDIF (IEC958) digital data format. In order to enable this output, bit SPDF in Register 5Ch should be set or pin 44 pulled high.
<lekernel> yeah so it's pulled down by default, and disabled. good.
<aw_> yeah...yes..just totally understood now. :-)
<aw_> two ways can enable this though. :-) thanks.
<terpstra> lekernel, i found an interesting paper on how to build a smaller TLB. they propose to use a single-port RAM block for BOTH ITLB and DTLB. The trick to making it run at near full speed is that they use a register to cache the last physical address loaded from the cache, thus cutting out most hits and allowing the port to be shared.
<terpstra> i'm not sure if a dual-port RAM block is actually more expensive than a single-port RAM block on most FPGAs, though
<lekernel> I think it's not
<lekernel> just routing resources
<terpstra> so more an ASIC improvement then
<roh> re
<wolfspraul> roh: ok about rc3 cases. for dmx tx, it looks like we leave everything as-is right now
<wolfspraul> I will give you the final confirmation in a few days
<wolfspraul> considering all the different options and pros and cons, the current solution is not bad, and sellable
<wolfspraul> for MIC, we still plan to move the microphone to the acrylic, and let it face the acrylic. so if you could make a small hole there, and 'MIC' label, that would be great
<wolfspraul> the final and exact positioning will take another week or so though
<wolfspraul> other than that, I think all is settled
<wolfspraul> I still like philips (+) keys better than allen keys (on top and bottom side)
<wolfspraul> but I can live with allen
<wolfspraul> (allen = inbus)
<wolfspraul> we have to be careful about the DC jack tolerances, as Adam will try to make this more precise this time
<wolfspraul> theoretically that should make things easier, but you never know, we are moving something so we have to be careful that the cases still fit
<wolfspraul> one idea we haven't talked about yet to improve the dmx tx push button is to make the entire top and bottom parts a few mm smaller
<wolfspraul> that would reduce the amount it stands 'over' the side acrylic
<wolfspraul> you are probably worried about mechanical stability...
<wolfspraul> if it would be smaller, it would presumably be easier to press down that dmx tx push button...
<wolfspraul> I think it's about 7mm right now
<lekernel> wolfspraul: tbh both the mike and dmx push button are working today, what isn't working here is publicity
<wolfspraul> but even that, I think the dmx tx button problem is not as severe as to warrant a reduction of that space
<lekernel> in the loudness of a typical concert or party the mic picks up more than enough sound
<lekernel> last time I even hard to turn down the volume in the GUI a bit
<wolfspraul> understood, but I'm not as frustrated as to stop/deny improvements when I see them and when they come easy
<wolfspraul> also I'm just going through some points for roh so we are moving forward on the cases...
<wolfspraul> on publicity, I've explained my strategy, and what I will do, several times
<wolfspraul> I will work on two angles: 1) journalists 2) actual users, word of mouth
<wolfspraul> I'm more worried about #2 than about #1 right now
<wolfspraul> if we have a good press release, it will be picked up, I'm sure
<wolfspraul> but... I sold 32 units, and I clearly don't have 32 active users right now that are dragging this unit whereever they go, preach to all their friends how great it is, etc.
<lekernel> I was talking about that in #qi-hardware the other day ... seems to me that absolutely all projects have a great deal of drawerware
<lekernel> look at openpandora ... they claim to have sold 4000 units and there are 100 users in their IRC channel
<wolfspraul> in those small electronic gadgets, you typically have 50% drawerware, even for big brands
<wolfspraul> maybe not Apple :-)
<wolfspraul> it's scary but that's how it is
<wolfspraul> so the thing is bought, and maybe turned on once, then into the drawer
<wolfspraul> you could call this a success of capitalism, or defeat. but it's reality.
<wolfspraul> for the 32 units we sold, how many do we see alive?
<wolfspraul> maybe 5?
<wolfspraul> Jon, Kristian Paul, Lars
<wolfspraul> I see 3 :-)
<wolfspraul> there are probably a few more, but a good 25 disappeared in terms of publicity
<lekernel> what can we do? more users? tutorials?
<lekernel> tutorials published in specialized magazines seem to be a good idea for me :-)
<wolfspraul> I think some of the use-case improvements we have in mind might help, for future buyers. for example the 'update' and 'next patch' buttons.
<wolfspraul> oh sure
<wolfspraul> out of the hacker scene, into audio and video lovers
<wolfspraul> so for future buyers, I think I have a solid plan, with better accessories, better out-of-box software (easier to use for beginners), etc.
<wolfspraul> whether we can kick the rc2 customers alive I don't know :-)
<wolfspraul> for journalists - well, I just hate to create fake news. I'm not good at it, I abhor it. so I won't do it. Maybe someone else is better at this, then they should go for it.
<lekernel> guyzmo: so what do you think about publishing that Lua tutorial?
<wolfspraul> so without fake news, the main thing I'm going for is a proper launch press release, once we have neatly made rc3 in stock and ready for shipping
<lekernel> wolfspraul: it doesn't have to be fake. we can contact journalists at each software release, for example.
<lekernel> and tell them a nice story
<lekernel> about how great those new features are
<lekernel> it sure takes a lot of energy and time, but I think there is no way around that
<wolfspraul> yes and no. yes for building relationships with journalists, and keeping them posted.
<wolfspraul> absolutely.
<wolfspraul> actually I do that - one reason I spend some time with montly qi news is that I then send that url to some journalists to keep them fed
<wolfspraul> another one is that a good story is not necessarily the same thing as a bunch of great facts
<lekernel> uhm well... tbh this lacks the 'nice story' aspect
<wolfspraul> yes, correct
<wolfspraul> but that's a competition of its own
<lekernel> it's good as an internal newsletter for people who are already interested in our community
<lekernel> but it's terrible for outsiders
<wolfspraul> so if you climb onto a Berlin highrise, and threaten to jump down unless slashdot (ahem) carries the MIlkymist news, and we shoot a video of that, then, as stupid as this is, that may be covered somewhere
<wolfspraul> unfortunately there are tons of marketing/pr agencies flooding the world with hyped shit all the time
<wolfspraul> but the stories are still 'good', as in Hollywood good
<wolfspraul> for a journalist it's hard to wade through this and make good decisions
<wolfspraul> the qi community news is a 'copyleft hardware' thing, specialized
<wolfspraul> for Milkymist we need an entirely different approach, that goes over the video/synthesizer effects, etc.
<wolfspraul> also to make it big fast, we need a strong marketing partner, or a whole company that resells the product, as Roland or whatever
<lekernel_> sorry, got disconnected after 'for a journalist it's hard to wade through this and make good decisions'
<wolfspraul> the qi community news is a 'copyleft hardware' thing, specialized
<wolfspraul> for Milkymist we need an entirely different approach, that goes over the video/synthesizer effects, etc.
<wolfspraul> that was all
<wolfspraul> lekernel: let's try to support Jon well. if he can really use m1 during the keynote or between presentations, that could make a difference
<wolfspraul> the ways we can support this are:
<wolfspraul> easy way for him to have some background picture, well maybe he can just point the camera to a printout :-)
<wolfspraul> rss feature would be nice, but not a must imo if it's not in-time
<lekernel> should be in time
<wolfspraul> maybe there should be a way to continously display 'powered by Milkymist', even during rendering
<wolfspraul> is that possible?
<wpwrak> wolfspraul: maybe try to see if the monthly news have one item worth brushing up and bringing to the press ? it would lose the "instantaneousness", but at least it would align with a process we already have
<lekernel> I already got atom and rss feeds from twitter downloaded and parsed by my m1
<wolfspraul> not sure he would like that, but little details like this can matter if many people just pass by and briefly look over their shoulders
<lekernel> and it displays the latest tweets from a particular hashtag on the serial port atm
<lekernel> yeah this will come with RSS as well .... it will display a background message if there was no recent entry
<wolfspraul> we can also support Jon with a press release, even if it sounds bloated. but if someone can exercise it through it may create some press coverage, or at least some journalists have heard the name
<lekernel> ah yes
<wolfspraul> but for a press release, well, it's a lot of work :-) the details have to be right
<wpwrak> wolfspraul: (powered by milkymist) for the presentation ? maybe better to just have one slide saying that this is presented on the mm1
<lekernel> wolfspraul: what exactly is Jon planning to do with the m1 during the presentation?
<wolfspraul> what is the headline? "Secretive Milkymist video synthesizer shown to larger audience at LGM for the first time" :-)
<wolfspraul> yes, see. I don't know.
<wolfspraul> I don't even know when the exact dates are, I know nothing.
<wolfspraul> if we do a press release, at least the facts have to be right
<lekernel> "Milkymist video synthesizer enters the realm of the Internet of Things"
<lekernel> :P
<wpwrak> wolfspraul: a like "video synthesizer" much better than "vj station"
<wpwrak> s/a/I/
<wolfspraul> you are not the only one, we will switch to that
<wpwrak> excellent ! :)
<lekernel> yeah, let's not sound too sophisticated
<wolfspraul> press release soudns easy, but then actually it's a lot of work to do one
<wolfspraul> and the usual quote, etc.
<wolfspraul> details details details
<wpwrak> lekernel: "video synth" also sounds less confined. "vj station" suggests that, if you're not a vj, it's not for you.
<wolfspraul> ok let's start :-) when is that lgm thing actually? :-)
<wpwrak> wolfspraul: (quote) you could interview lekernel ;-)
<wolfspraul> yes sure, he is the founder that's always good
<wpwrak> wolfspraul: if you look at them, quite a lot of those quotes do actually come from people deeply involved in whatever the news item is. so they're not really sort of an external opinion or assessment, but just a soundbite
<wolfspraul> yes
<wolfspraul> may 10-13
<wolfspraul> so it starts next tuesday
<wolfspraul> when will rejon actually turn on and use/display m1 to the widest audience he has there?
<wolfspraul> we should do the press release on that same day
<wolfspraul> rejon: can you post some factoids here? maybe we can make the release like some "during his keynote at xx am/pm today, Jon Phillips ..."
<wolfspraul> maybe we can create a nice screenshot or two in advance? not sure how we can get the LGM logo/text into the display then
<wolfspraul> first step - let's see when rejon comes back and what he says :-)
<wolfspraul> I am willing to spend a day or two to support this release, in terms of writing it, getting the pieces together, and then shopping it to journalists, whether it's picked up or not.
<wpwrak> wolfspraul: ask him to ask someone to snap a picture ?
<wolfspraul> we need to create the screenshots before the actual use, otherwise timing won't work
<wolfspraul> I'd rather not get a crappy picture in there, and delay the news for it even.
<wolfspraul> I need feedback from rejon now, I'm sure we get it when he gets up in Missouri :-)
<wolfspraul> of course if we make a release we need to promote lgm itself as well, both inside the release and also at the bottom with a paragraph, what LGM is etc.
<wolfspraul> how many people go there? a few hundred? more/less? no idea :-)
<wpwrak> i think a picture showing him in the room with the mm1 in view would certainly add value to a news item. give it credibility.
<wolfspraul> yes, but how to pull it off? :-) good quality pic, fast.
<wpwrak> does he have people there whom he knows a bit ? if yes, ask them to make a few pictures. explain the objectives.
<wpwrak> if he doesn't know anyone, ask the organizers if they can help
<wolfspraul> I'm sure he knows everybody, but I'm realistic. once in the chaos of such a conference, it's hard to pull off things in real-time.
<wpwrak> prepare some non-real-time pics as plan b, in case nothing good comes out
<wolfspraul> yes :-)
<wpwrak> he should contact them beforhand. e.g., to make sure they bring a camera ;-)
<wpwrak> otherwise you'd get some dutiful soul who will snap some phone cam shots, but that would be about it ;-)
<wpwrak> of course, if you're going for "the blair witch project" aesthetics, ... :)
<wolfspraul> I think they are quite good about documenting, tweeting, flickering, etc.
<wpwrak> you mean the conference organizers ?
<wolfspraul> yes that whole event, everybody
<wpwrak> dunno if they pay attention to producing "press" pictures.
<wolfspraul> doesn't matter if we have a good quality pic, and even officially cc-by/public domain etc. we can use it
<lekernel> hi xiangfu
<lekernel> I got libcurl to work on the M1 so you can use it later for the web update feature
<wolfspraul> lekernel: is it possible to display a static text during rendering?
<lekernel> yes
<wolfspraul> for promotion purposes, like 'powered by Milkymist'
<lekernel> atm there are OSC messages to display text, but it fades out after a few seconds
<lekernel> not hard to disable the fade out though
<lekernel> it'll come as well when I add the RSS stuff
<wolfspraul> ok
<wolfspraul> great
<lekernel> worst case we quickhack the code if we can't get that on time
<lekernel> http://www.highbeam.com/doc/1G1-169406902.html maybe that's another reason why they won't release the code
<lekernel> the VP8 codec might have common parts with stuff they licensed to anti open source companies like ARM
<guyzmo> lekernel - I'm not sure the focus on lua is really a good idea, but we're gonna discuss that with john to see what can we write about the MM1, and sure make an article in make, open Si, or electkor
<guyzmo> anyway, it'd be nice to test the MM1 with lots of projectors to show what it can do
<wpwrak> lekernel: arm probably love open source - as long as it sells chips with their IP:)
<wolfspraul> wpwrak: yes, that's exactly 100% why TI loves open source as well.
<wolfspraul> open source helps keep their partners margins in check, and them with the fattest margins and thus most innovation potential
<xiangfu> lekernel: thanks. I try that a little. not make it work. I will try libcurl http://www.milkymist.org/wiki/index.php?title=Flickernoise_build_instructions#libcurl
<lekernel> xiangfu: can you get the keymap done first? should be easy and then you will not hear about it again
<xiangfu> lekernel: ok
<lekernel> wolfspraul: also, something I noticed with the camera is that when the picture is all black, it automatically adjust brightness/contrast and this results in a lot of CCD noise at the output
<lekernel> I don't know if we can deal with that somehow, will check
<wolfspraul> interesting
<wolfspraul> that would be hard to change most likely, it's probably a feature of the Sony CCD or immediately surrounding circuitry, I would think
<wolfspraul> I guess it still tries to show something, so brightness goes up automatically?
<lekernel> yes
<lekernel> but maybe this can be dealt with by adjusting contrast/brightness in M1
<lekernel> should try
<kristianpaul> tutorials!!
<kristianpaul> i agree with guyzmo comments about lua
<lekernel> kristianpaul: send me a message on twitter with #milkymist hashtag
<lekernel> i'm testing the twit wall atm :p
<kristianpaul> ah?
<kristianpaul> wait
<kristianpaul> sent from identi.ca it should forward on twitter as well
<lekernel> yay works
<lekernel> thanks
<kristianpaul> nice so now we can control patches with twits and dents :D
<kristianpaul> s/can/could
<kristianpaul> lol
<kristianpaul> nice :-)
<kristianpaul> free advertisement !
<kristianpaul> s/free/micro
<kristianpaul> that will be the next product ;)
<kristianpaul> wolfspraul:  is this the new battery pack for the coming mm1 ? http://en.qi-hardware.com/wiki/File%3ADc168_pic3.jpg
<kristianpaul> ;-)
<wolfspraul> no just a crazy Chinese hack I found
<kristianpaul> :-)
<lekernel> so they just charge the 12V li-ion batteries by applying a continuous 12.6V to them?
<wolfspraul> did you look at the picture closely?
<wolfspraul> it's three 3.7V lithium batteries
<wpwrak> what does the contraption connect to ?
<wolfspraul> 3*3.7=11.1
<wolfspraul> the idea is to connect a 12V dc supply
<wolfspraul> it will all 'sort of' work, I guess
<wpwrak> urgh
<wolfspraul> the outside is labeled as 1800mAh
<wolfspraul> so yeah, it _should_ be 12.6
<wolfspraul> for charging
<wolfspraul> but it is 12.0, if the supply is accurate
<wpwrak> i think we could do better: bundle 40 batteries, add a diode, and charge from 110 V mains. US only ;-)
<wolfspraul> and then to draw power, I guess the camera has to be robust, i.e. also work with 11.5 or so :-)
<wolfspraul> not even the slightest attempt at managing charging cycles either
<wolfspraul> anyway
<wolfspraul> :-)
<wolfspraul> at least in China anybody can become electrical engineer
<wolfspraul> just plug some wires together and turn on and see whether it works :-)
<wpwrak> battery life is overrated anyway :)
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r657cda0 / (src/renderer.c src/rsswall.c src/rsswall.h): RSS wall: print messages on patch - http://bit.ly/jVCAJZ
<lekernel> xiangfu: btw, the interrogation mark key doesn't work on the german keyboard
<lekernel> i'll file a bug against that... but I think it will go with the rewrite of the keyboard code with the different keymaps
<xiangfu> lekernel: ok. thanks
<mumptai> hi
<lekernel> hi
<kristianpaul> ola
<rejon> wpwrak http://libregraphicsmeeting.org/ i am one of organizer
<rejon> yes, all sounds good lekernel
<rejon> i'm tempted to go to sanjose tonite to meet up with ifixit and jeri ellsworth
<lekernel> rejon: kewl
<lekernel> btw i'm putting your identi.ca by default on the RSS wall feature
<lekernel> or, ATOM for that purpose
<rejon> ha
<rejon> cool
<lekernel> it's working btw
<lekernel> just need to polish a few edges
<rejon> excellent
<mumptai> terpstra, you are knowledgeable about the different versions of the zpu?
<CIA-48> flickernoise: Sebastien Bourdeauducq master * re1eb6cd / src/rsswall.c : RSS wall: configuration dialog box - http://bit.ly/m83Ltz
<carlobar> hi lekernel, i have been doing some modifications to the HPDMC controller, there were some errors with a buffer, and thats why the controller sometimes worked and sometimes didnt... now it doesnt work at all :-D.... i dont know if the problem is on read/write or both.. when you developed it, how do you did tests? is there any way to watch signals on real time? thanks
<lekernel> use the video out
<lekernel> it's much easier to guess DRAM problems when you can visualize what they're doing on a framebuffer
<carlobar> how must i do that? do you used that in tests?
<lekernel> btw, what do you need HPDMC for?
<carlobar> write and read data sent by the processor
<lekernel> ...
<lekernel> I mean, what application?
<lekernel> do you have the source code online somewhere?
<carlobar> haha, run the kernel and some testbenches
<carlobar> no
<lekernel> ok, but what is your project about?
<carlobar> i have to run some applications and measure power consumption and execution time
<lekernel> what for?
<lekernel> company work?
<lekernel> school project?
<lekernel> personal research?
<kristianpaul> interesting this topic of transputer
<kristianpaul> may be he just want to verify your thesis results :-)
<kristianpaul> s/results/benchmarks
<carlobar> university project... the project is about a comparation between two processors running uclinux
<kristianpaul> about lm32 vs micoblaze
<kristianpaul> yay, i knew it !
<carlobar> lm32 vs leon3
<lekernel> carlobar: ok. first, please publish your code. HPDMC is GPL.
<kristianpaul> well, almost ;)
<kristianpaul> leon3, nice :-)
<lekernel> carlobar: and same for LEON3
<carlobar> ok, ill do it... github is fine right?
<lekernel> sites like github makes it very easy for you
<lekernel> yes
<kristianpaul> well make code publically avaliable is an option, but came on, sharing is good :-)
<carlobar> i was planning do that when it were working
<kristianpaul> nah
<kristianpaul> bad idea, i mean, is better publish as you go
<kristianpaul> so ask for support get interested
<kristianpaul> carlobar: will be nice you publish the bistream loader for you board
<lekernel> carlobar: btw, maybe your uni could buy a M1 for you, so you don't have to go through SDRAM problems which aren't the topic of your work I guess
<carlobar> maybe.. but sure it will take a lot of time
<kristianpaul> carlobar: may be if you publish the tests/procedures needed for your benchmark other people with a mm1 can try it out :-)
<kristianpaul> sorry i'm not in bogota but you can came to buga if you need the mm1 for a hacking day ;)
<kristianpaul> or you just pass me the binary to load, etc..
<kristianpaul> anyway, if you like work this way, just in case :-)
<kristianpaul> remenber you can use qemu for initial test, and i later can reply that on my board
<carlobar> ohh thanks :), i will take that into account
<lekernel> of course libcurl timeouts are broken on rtems. grmbl. having them work first time would have been too good to be true.
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r8d3ffcc / src/rsswall.c : RSS wall: use configuration values - http://bit.ly/iHpKiO
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r1c8d4a5 / src/rsswall.c : RSS wall: add timeouts - http://bit.ly/jI97Rn
<kristianpaul> what? the minimac2 rxb0 have two clks and one of then is the phy_rx_clk..
<kristianpaul> i tought it wasnt posible, or not recomended to do
<kristianpaul> well, not bad, the nibble is coming from the PHY and i this will not hurt once the data get in the ram
<kristianpaul> *i* *guess*
<lekernel> kristianpaul: what?
<kristianpaul> hides
<kristianpaul> i just took a quick look to the minimac2 core, i surelly missed some details ;)
<lekernel> well I don't know. maybe you have spotted some bugs
<lekernel> but yeah the minimac2 has 3 clock domains
<lekernel> those should be handled properly though
<kristianpaul> i'm checking sync part right now :-)
<carlobar> in that case do i have to create a new repo, or do fork??
<kristianpaul> fork
<kristianpaul> is better to track you using github that way
<carlobar> ok
<kristianpaul> track your changes i mean, not you actually ;)
<lekernel> kristianpaul: can you post a long tweet to test the line break? :)
<lekernel> ah, it's working already
<lekernel> great
<kristianpaul> k
<carlobar> here are my repos: https://github.com/carlobar ... i dont know if thats ok.. i had a mess here, so if something is wrong please tell me
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r6c20769 / (src/font.c src/font.h src/osd.c): OSD: multiline text - http://bit.ly/lXXfKh
<carlobar> i have to go... i'll come back in some hours...
<lekernel> carlobar: cool, thanks for uploading the source
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r62900f3 / src/cp.c : fix performance start button - http://bit.ly/kgYRO1
<lekernel> for some reason the time it takes to compress a PNG screenshot has dropped to a few seconds. I like when problems fix themselves like that with magic.
<lekernel> decoding large wallpapers is still slow, though
<azonenberg> ... wow division is slow lol
<azonenberg> I just wrote a suite of unit tests for my ALU
<azonenberg> in the time it takes to do one division it can test every other instruction on the CPU twice
<wpwrak> azonenberg: in the good old days of CISC, this wouldn't have happened. e.g., the VAX POLYH instruction. calculates an arbitrary-length polynomial with 128-bit floating-point math.
<CIA-48> flickernoise: Sebastien Bourdeauducq master * ra7caf21 / src/rsswall.c : RSS wall: do not display empty idle message - http://bit.ly/m1pXiD
<lekernel> <andrey_> Using different clock edges helps to make less spikes on the ground/power lines, using clk/2 - helps to reduce power and increases the amount of logic I can put between the registers without additional enable signals and/or double cycle timing constraints
<lekernel> ok well
<lekernel> I guess one more crap FPGA design