<wpwrak> larsc: (weird bugs) perhaps there will be a few early retirements soon after llhdl hits the streets :)
<wpwrak> larsc: or quite a lot of night shifts
<larsc> hopefully
<sh4rm4> an opensource ultrasparc cpu ^^
<sh4rm4> 64bit even
<sh4rm4> and verilog
<xiangfu> where is the "rtems-milkymist " upstream. I cann't access "https://github.com/fallen/rtems-milkymist" anymore
<xiangfu> so this one "git://github.com/milkymist/rtems-milkymist.git" is became the upstream now right?
<wolfspraul> there is also this one https://github.com/kristianpaul/rtems-milkymist
<xiangfu> I saw the new code about ethernet all goes to git://github.com/milkymist/rtems-milkymist.git
<xiangfu> seems all git repo under lekernel/*, now switch to new URL. git://github.com/milkymist/*
<xiangfu> git://github.com/lekernel/* -- changed to --> git://github.com/milkymist/*
<xiangfu> will include all files under "https://github.com/milkymist/datasheets-m1" to data partition.
<xiangfu> for new the data partition include all patches "https://github.com/milkymist/flickernoise/tree/master/patches" and documents "https://github.com/milkymist/datasheets-m1" and only one wallpaper: http://www.milkymist.org/wiki/index.php?title=File:Comet.png
<wolfspraul> xiangfu: you mean you want to put the datasheets onto the m1 flash? why that?
<wolfspraul> I would think most are PDF, but we will not build the PDF viewer right now as it is far too slow in bootup time. And then - why would someone want to read datasheets on the m1?
<xiangfu> yes. for fill the data partition.
<xiangfu> wolfspraul: my plan is build flickernoise and flickernoise-pdf. by default the reflash_m1.sh will only flash the flickernoise (no pdf build-in)
<xiangfu> those datasheet maybe not a good idea for end user.
<wolfspraul> I think they are completely useless on the m1.
<wolfspraul> I also wouldn't bother building the PDF image, because with a startup time of 45 seconds or so that is way too much, it's only a prototype/alpha feature 'because we can'. other than that it has no value right now, imho.
<wolfspraul> I'd rather focus on improving the non-pdf version, and of course keeping the datasheets out unless I totally misunderstand how someone might want datasheets on his m1...
<xiangfu> ok.
<kristianpaul> Hi
<kristianpaul> I wasnt able to run a patchwith last firmware, i mean, gui is okay but when i just run the patch there was nothing on screeN
<kristianpaul> I was using a video projector,
<kristianpaul> i dont have the brand or model, was a quick presentation for flisol
<xiangfu> kristianpaul: you mean this one "http://www.milkymist.org/msd/msd-apr2011.tar.bz2" or last commit?
<kristianpaul> msd-apr2011.tar.bz2
<xiangfu> kristianpaul: the msd-apr2011.tar.bz2 works fine here.
<xiangfu> I am using normal LCD monitor.
<kristianpaul> i dont, well,  may be was the video projector
<kristianpaul> tomorrow i will finally have a meeting with some "VJ" related guys here,so i hope this will work there
<xiangfu> the Video-in Patch is cool.
<kristianpaul> as i said, i just lost image when rendering the patches i choosed
<kristianpaul> video-in oh yes
<kristianpaul> i did some tests, but i could set the videocamera so ijust showed some milkdrops patches and people just said,:o wow
<xiangfu> (btw: the memcards leave Beijing at "2011-04-08  00:59:12")
<xiangfu> kristianpaul: I am try to build all images in my pc. base on last commit.
<kristianpaul> oh well, i'm out home for some days, i'll let you know as soon something arrives
<kristianpaul> xiangfu: did you worked ona quick way of re-build rtems isnt?
<xiangfu> yes.
<kristianpaul> good, i'll try out soon, :-)
<xiangfu> needs some more command if build from scratch  (git clone all source code under github.com/milkymist/*)
<kristianpaul> okay
<wolfspraul> kristianpaul: I wouldn't expect that letter to arrive until late April, early May.
<kristianpaul> sure, i'm relaxed about that :-)
<xiangfu> http://www.milkymist.org/wiki/index.php?title=File:Screenshot-video-in.png
<rejon> great!
<wolfspraul> xiangfu: nice! about the GUI/render screen resolutions, what are your current binaries doing now?
<wolfspraul> is the GUI in 1024x768, and then it switches to 640x480 for rendering, and back to 1024x768 when it goes back to the GUI?
<xiangfu> by default it's 1024x768
<wolfspraul> or is it always staying in 640x480 ?
<wolfspraul> my projector can only support up to 800x600
<wolfspraul> not sure what happens if m1 displays a 1024x768 signal, probably the projector will just stay dark
<wolfspraul> when we are in the GUI, can we have some key-press to iterate through resolutions?
<xiangfu> wolfspraul: yes. it's switch to 640x480 when rendering
<xiangfu> wolfspraul: yes. we can switch 640x480, 800x600, 1024x768
<xiangfu> there are three buttons in "System Settings"
<wolfspraul> yes but if my projector can only do 800x600, I will have a hard time switching if it boots in 1024x768
<wolfspraul> because I cannot see anything :-) (need to try, but that would be what I expect)
<wolfspraul> so either we boot in 640x480 and let people increase manually, or if we think most people will have support for 1024x768, then we can boot in that, but there should be a keypress to go down for poor souls like me
<wolfspraul> in fact the keypress should just iterate through all available/hardcoded resolutions, imho
<xiangfu> good idea, keypress iterate.  what keys you recommend?  F11 or Ctrl + F11
<xiangfu> the big video-in 360x288 make m1 very slow.
<roh> ola
<xiangfu> I have to move the mouse very carefully
<xiangfu> I am working on add a switch button on video-in
<roh> wolfspraul: i am just ordering the aluminium sheets... do we want the thick (0.3) EN AW-Al Mg 3 or the thin (0.2)  EN AW-Al 99,5 ones?
<wolfspraul> hmm
<wolfspraul> forgot which one we preferred again
<wolfspraul> roh: the harder one I guess, 0.3 almg3
<wolfspraul> roh: did you see the feedback about ST ANDBY? and the lack of labels for the 3 buttons?
<roh> do you remember how much you payed?
<roh> the labels on the buttons were not there on purpose.
<roh> the ST ANDBY i can't explain
<roh> its not there on the ones i checked
<wolfspraul> ok then. I can see it on my wood one too. it looks like the T is shifted a bit up and leftwards.
<roh> the labels were ommitted since they either are different to the ones on the pcb or the numbers go from right to left, which is counterintuitive
<wolfspraul> that doesn't sound like a good argument to me.
<wolfspraul> so because we are confused about the labels ourselves, we leave out any way to identify them? :-)
<roh> its sw-defined anyhow.. left, middle, right?
<roh> in the dark nobody sees buttons anyhow
<wolfspraul> actually I thought render/on/standby are the labels for the buttons
<wolfspraul> :-)
<wolfspraul> I don't think I'm the only one.
<wolfspraul> so I press the middle button, because I think that's ON
<wolfspraul> which actually works
<wolfspraul> the buttons definitely need some type of label, imo
<wolfspraul> let's check with Sebastien
<wolfspraul> just checking on the PCB, yes the right one says "SW1", the middle one is "SW2", the left one is "SW3"
<wolfspraul> a simple 1 2 3 would do it for me, maybe in a circle? or you could write the 1 2 3 onto the actual button itself?
<wolfspraul> roh: at gemmel, I paid about 30 EUR I think
<wolfspraul> cutting (149x124) was included
<roh> ok. we'll see what they answer.
<wolfspraul> that was including VAT
<wolfspraul> lekernel: I think we need some idea for labeling the 3 buttons
<wolfspraul> not labeling them at all is not an option, it will create big confusion later
<wolfspraul> I can tell you 80% of people will think render/on/standby actually is for the buttons, the left one is 'render', the middle one 'on', and the right one 'standby'
<xiangfu> that is what I'm think at begin :-)
<wolfspraul> xiangfu: definitely. and the only reason we don't hear feedback is because people will then press the middle button which they believe is 'ON', and m1 will turn on! :-)
<wolfspraul> and most people will not go beyond that point in terms of the buttons or leds, so we hear no complaints about the button labels.
<wolfspraul> roh: another feedback - it seems sometimes after assembly and tightening the screws, one finds out that a button is continuously pressed down
<wolfspraul> so you cannot boot the m1 until you have identified that 'stuck' button
<roh> hm. that shouldnt happen at all.
<roh> atleast it worked for me when i didnt glue where it shouldnt be glued (so yes, i encountered it ;)
<roh> maybe it gets better with the more precise cut i hope to get this time
<wolfspraul> if you can, please try to glue the buttons on your side
<roh> thats mostly a question of time and labour.
<wolfspraul> gluing the buttons requires some precision, so it's best done by whoever is closest to the actual production
<roh> we are in midst of moving atm, so the next 14 days will be fun anyhow
<wolfspraul> no rush
<wolfspraul> as for buttons being stuck, I have encountered that several times
<wolfspraul> but of course you are right - the buttons were in various states of 'glue quality'
<roh> also i havent heard back from the laserguy, so maybe it could take 2-3 weeks to get everything rolling and done
<wolfspraul> we should use a glue film or so, to get a consistent glue thickness
<roh> if you find a really thin, good doublesided film, please holler
<roh> i tried some and they all were quite thick (0.2-0.3mm) and made the buttons wobbly to the side and not gave a proper button feel
<xiangfu> the rescue mode will first try to load image from tftp.
<wolfspraul> xiangfu: reflashed your latest set. when I click on Start!, my projector goes black
<xiangfu> how about switch resolution in "system setting"?
<wolfspraul> already switched to 640x480, same
<wpwrak> wolfspraul, roh: (buttons) if they're sw-defined and have "strange" numbering, maybe label them A, B, C or X, Y, Z ? that way, the letters can be in the usual left-to-right order. the mapping would be A-3, B-2, C-1.
<wolfspraul> when I'm in another resolution, I have a lot of flickering before the projector goes black
<wolfspraul> ah, tried another patch now it works
<xiangfu> yes. there are some patch have bug. in new flickernoise.
<xiangfu> back online later
<wpwrak> btw, the "patch" term. so "patch" is synonymous to "presets" ? is "presets" used in the sense of "parameters to a given process/procedure" or does it have a special meaning in mm1 terminology as well ?
<wolfspraul> xiangfu (in absentia) - since rendering switches back to 640x480, and all dialogs in the GUI will be designed to work well in 640x480 (for now?), I don't understand why the default GUI resolution should be higher than 640x480
<wolfspraul> I think it should be 640x480 by default, the others can be in the settings of course
<roh> wpwrak: patch means 'flickrnoise program'
<wolfspraul> only if we start to design the dialogs for something higher, say 800x600, I would change the default to that as well
<roh> it comes from that winamp-plugin foo.. and yes, the term 'patch' for that is as well stupid as confusing
<wolfspraul> but then we need to clearly say whether 640x480 is still supported, or works 'somewhat', or what
<roh> atleast misleading
<wolfspraul> I've had a discussion about that 'language' with Sebastien recently, and the conclusion was that it's called 'Flickernoise Patches'
<roh> but in the end it wasnt chosen within th scope of the project
<wolfspraul> roh: according to Sebastien, it was in fact especially chosen for the scope of the project
<wolfspraul> I don't care so much as to which word we use, as long as we all call it the same way
<wpwrak> roh: (patch) confusing indeed. can you have multiple patches on the same screen ?
<roh> well.. _everybody_ including musicians i know does see patch as either a cable or some 'diff' form textblock
<roh> and not 'a file with program code in it'
<wolfspraul> let's hope Sebastien is back, there is something in the backlog about it somewhere
<roh> wpwrak: i dont think so (multiple patches)
<wolfspraul> we all need to be on the same page
<wolfspraul> it's Flickernoise Patches for now...
<roh> wpwrak: check out some patch.. its like code for a weird vm which basically does math
<wpwrak> wolfspraul: unusual "official" terminology means that people will often add a "non-official" translation. e.g., think of kicad "components" or "modules". those terms are only understood in a very narrow context.
<wolfspraul> that's fine but I will still go with the 'official' one
<wpwrak> roh: (not multiple) so they're not even like real-life patches ;-)
<lekernel> sh4rm4: yeah opensparc is cool. but enormous and not appropriate for FPGAs. when you have an FPGA, you'd rather keep the CPU small instead of having all the bells and whistles of OpenSPARC and take advantage of the reconfigurability to implement custom accelerators
<wolfspraul> or rather I need to know what 'official' is. If we don't even know, maybe there is nothing official :-)
<wpwrak> i wonder if common parlance "effect" (as in "visual effect") could be synonymous with Flickernoise "patch"
<lekernel> imo opensparc wouldn't even fit in the MM1 FPGA (perhaps S1 Core would) or be slower, while our SoC only uses ~45% of the LUTs...
<lekernel> yeah everything is on github.com/milkymist now
<lekernel> kristianpaul: what resolution were you operating the GUI at? 1024x768?
<roh> wpwrak: i'd simply call them 'programs'
<roh> or scripts
<roh> like in a script for a play
<wpwrak> roh: "program" sounds more like /bin/ls and such. similar with scripts.
<lekernel> wolfspraul: label 1/2/3 yeah
<lekernel> maybe add "on" on the middle button
<wpwrak> but yes, "scripts" seems to be closer, because it also includes the procedural element
<roh> lekernel: the buttons can rotate.. so on the button is a bad idea.
<roh> lets add triangle, sqare and circle and get sued by sony... greeat marketing!
<wpwrak> roh: use symbols, [], *, and O ? :)
<roh> +u
<wpwrak> heh ;-)
<lekernel> wolfspraul: (640x480 by default) then kristianpaul's screen wouldn't work at all...
<roh> btw.. does the vga port do ddc?
<roh> some beamers need rather.. special timings... like in... special people
<lekernel> yeah it does ddc, but software doesn't
<roh> ah. nice. so the hw-part is tested?
<lekernel> there's a function to read the EDID which works, but nothing beyond that
<lekernel> yes
<roh> it was just 'read some page via i2c' right?
<lekernel> the factory test program attempts to read EDID and check its header
<lekernel> yes
<roh> wow. gemmel wants .55 euro per sheet.
<roh> and thats not drilled and doesnt have a sticker
<lekernel> aw_: wolfspraul: roh: do you have github accounts?
<wolfspraul> lekernel: [screen res] oh, didn't know about kpaul's screen
<wolfspraul> lekernel: [screen res] so what do we do then?
<wolfspraul> we must absolutely focus on one default setup, and optimize for that
<wolfspraul> if the default res is 800x600 or 1024x768, we have two problems right now:
<wolfspraul> 1) the dialogs are not optimized for such a high resolution, especially at 1024x768 everything looks too small
<wolfspraul> you would even want to use the zoom feature of some projectors, reversing the whole thing... :-)
<wolfspraul> 2) if we increase the dialogs, or settle on a higher 'default' resolution, we may as well remove the smaller ones because dialogs that don't fit on screen are really bad
<wolfspraul> 3) rendering will go back to 640x480, with a lot of flickering it seems
<wolfspraul> 3 problems
<wolfspraul> I suggest 640x480 to be the default GUI res, and there can be a keypress to iterate over resolutions
<wolfspraul> if kpaul's projector/screen doesn't work at 640x480, how about rendering?
<wolfspraul> roh: so we label then 1 2 3?
<wolfspraul> with circle?
<wolfspraul> [buttons can rotate] - good point, so not on the button for sure
<wolfspraul> seems lekernel left too early for the 'Milkymist Patches' thing
<roh> wolfspraul: if i label 1 2 3 its completely different to the pcb and schematics labels 3 2 1
<roh> and nope.. i dont have github accounts
<wolfspraul> roh: we can change the pcb for rc3
<wolfspraul> I doubt anywhere in the code we have a reference to 'sw1', 'sw2', 'sw3'
<roh> (after theit last fuckup i was laughing to hard)
<wolfspraul> lekernel: are you OK with swapping the silkscreen that says 'sw1' and 'sw3' on rc3?
<lekernel> wolfspraul: yeah
<lekernel> roh: could you create one?
<wolfspraul> roh: ok, settled. we label them 1 2 3 from the left, and the silkscreen in rc3 will be adjusted as well
<roh> lekernel: i will think about it. to be fair.. i am not really interrested in even more spam
<lekernel> been on github since august 2009, never received a spam from them
<roh> i get most my spam via accounts on google code, sourceforge and similar stuff.
<roh> lekernel: well.. not from them directly.. but from all the mindless headhunters scraping all these platforms
<lekernel> this happens everytime you have a visible project
<lekernel> wolfspraul: add an "ON" label too, no?
<wolfspraul> what are the other two used for?
<roh> lekernel: havent had it before the big github and similar platforms explosion. in the end: i dont believe in 'too big' userbase infrastructure anymore at all. just makes the fail bigger, not the problems less or smaller ;)
<wolfspraul> the middle one is 'ON'
<wolfspraul> I agree with roh about github, but it's definitely good to have more milkymist stuff in one place (even though I think that should be milkymist.org or so)
<wolfspraul> for qi-hardware, I want to keep copyleft hardware (manufacturing) related stuff together
<wolfspraul> but other than that I like the new milkymist group on github
<wolfspraul> lekernel: how about the default GUI resolution? not sure you saw my points above
<wolfspraul> I think this is important. we should have one default, and things should look good on that default.
<lekernel> wolfspraul: currently the other buttons are used to a) boot in rescue mode b) boot in SDRAM calibration mode
<roh> wolfspraul: well.. its not that bad as other hosted s*it ... atleast one has a proper backup ;)-
<wolfspraul> if kpaul's screen doesn't work at 640x480, how about rendering for him? I don't get it...
<lekernel> wolfspraul: next SoC versions will support rendering in any resolution
<lekernel> but right now, it switches back to 640x480 for rendering a patch
<wolfspraul> but right now, I think the default GUI res should be 640x480
<wolfspraul> I don't see any reason, to be honest, for a higher one except for showing that we can :-)
<wolfspraul> the dialogs are not designed for higher res, rendering will switch back (including flickering)
<lekernel> first showing that we can is good since everyone asks about that :)
<lekernel> and imo the dialogs look good in 1024
<wolfspraul> a bit small, no? :-)
<lekernel> and yeah there's this little flickering problem... but will be fixed at the same time as support for arbitrary resolution rendering is added
<wolfspraul> does this mean we should increase their size and make 640x480 unusable? or should we support multiple 'zoom states', font sizes, etc?
<wolfspraul> are you aware of any projectors/screen that cannot do 1024x768 ?
<lekernel> yeah. and we'll want to support PAL resolution (TV-Out) as well.
<wolfspraul> tv-out ?
<lekernel> yes
<wolfspraul> over the vga connector?
<lekernel> yes
<wolfspraul> alright then, let's not waste time. you say the default GUI res should be 1024x768 right now?
<lekernel> I don't care
<wolfspraul> dialogs look good, we will not increase them to not fit on 640x480 anymore, and rendering will switch down to 640x480
<lekernel> if it's 640, showing off 1024 is only two button clicks away
<wolfspraul> yes. and if we add more features, we can move everything up.
<wolfspraul> I just try to make it a really good out of the box experience.
<wolfspraul> small dialogs are not, flickering is not
<wolfspraul> so with the current feature set (as of today, literally), I would keep the default at 640x480
<wolfspraul> but I'm flexible
<wolfspraul> just trying to understand
<wolfspraul> for the 3 buttons, well sure we can label the middle one 'ON'
<lekernel> ok, let's use 640 then
<wolfspraul> but the left one 'RESCUE', that sounds scary
<wolfspraul> not to mention 'SDRAM calibration' on the right one :-)
<wolfspraul> so maybe '1', 'ON', '3' ?
<wolfspraul> also strange
<wolfspraul> '1', 'ON', '2' ? confusing
<wolfspraul> you know the product best, you tell me
<wolfspraul> LEFT, ON, RIGHT
<wolfspraul> :-)
<wolfspraul> L, ON, R
<wolfspraul> how about that?
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r533c99c / src/sysconfig.c : Make default resolution 640x480 - http://bit.ly/forcli
<lekernel> L/ON/R looks good
<wolfspraul> roh: L, ON, R it is
<lekernel> btw in the GUI I'm thinking about using them as random patch switch (for demos) / power off (long press) / reboot (long press)
<wolfspraul> great!
<wolfspraul> maybe on the silkscreen we make it SW_L, SW_ON, SW_R then
<roh> wolfspraul: i'll wait for the feedback from the laser-guy first
<wolfspraul> roh: you mean about L/ON/R ?
<wpwrak> lekernel: or free R by having  ON long -> reset, ON even longer -> power off
<wolfspraul> how about this 'Patches' thing?
<wolfspraul> lekernel: you saw above that roh and wpwrak think that's not a good term. To cut it short - until I hear from you about a new one, I will continue to call it Milkymist Patches...
<wolfspraul> other proposals above were presets, programs, more?
<wpwrak> wolfspraul: i think "presets" is also misleading, because it suggests something static
<wpwrak> wolfspraul: (more) "effects", "scripts"
<lekernel> patch is good. writing equations is just like connecting stuff together, just in a different representation.
<lekernel> script/program is for nerds
<wpwrak> "effect" ?
<wpwrak> lekernel: (writing equations) you mean verilog ? or something labview-ish ?
<lekernel> verilog? oh, no :)
<lekernel> the milkdrop-like language... I don't know labview but I'd guess yes
<roh> wolfspraul: about how he needs the files, pricing etc
<wpwrak> speaking of labview, they use "program" and "dataflow". "flow" ?
<wolfspraul> roh: don't understand. how does that relate to L/ON/R ?
<wolfspraul> L/ON/R is settled, right?
<roh> wolfspraul: that it would need changes i need to test.. and i can only test a thing at a time.. no worries.. i'll get to it soon enough
<wolfspraul> Adam will adjust the silkscreen on rc3.
<roh> now i just need to decide if i order shielding sheets for just this batch or for more
<wolfspraul> roh: oh sure. but let's say L/ON/R is in the queue then :-)
<wolfspraul> it cannot be that hard to add it, unless I completely misunderstand the process, since there is quite a bit of text there as well
<wolfspraul> don't order for the next batch now, that's too risky.
<wolfspraul> I want to sell those 80 quick, of course. but a lot will depend on the launch and whether we can find strong marketing/retail/sales partners.
<roh> you mean we have a real chance to drop the shield soon?
<wolfspraul> I didn't think about it that way.
<roh> i got an offer for 200 sheets for 110E now.
<roh> and still got 50 left. (mixed thick and thin)
<wolfspraul> what's wrong with gemmel?
<wolfspraul> just use those 50, mixed no problem
<roh> nothing.. thats their offer
<wolfspraul> get another sheet from gemmel
<wolfspraul> should be about 30 EUR
<roh> those 30 would be near what 'some thinner' and in total around 70-80 sheets would cost
<roh> just abbreviating.
<wolfspraul> I think the 0.3 almg3 is better - stiffer
<wolfspraul> I suggest you use up the 50 you have, plus another 0.3 almg3 sheet from gemmel
<roh> ok.. we'll see how much more they want per sheet if i take much less (like only 50 instead of 200)
<roh> these 'classic' companies are weird.. they asked me to fax something *g*
<wolfspraul> they don't work in how many pieces you want, they work in sq/m
<wolfspraul> their roll has a certain width
<roh> i see.
<wolfspraul> forgot how much, maybe 1m, or 1.4m or so
<wolfspraul> then you cut off some amount, 50cm, 1m
<wpwrak> lekernel: (language) looks like a script ;-) but that's the representation, not the function. i guess the function would still be something like "effect" i common terms. (i wonder what they called those little demos back in the amiga days. just "demos" ?)
<wolfspraul> just say 'the smallest they sell' (that's what I bought)
<wolfspraul> then they should cut that for you into 149x124mm pieces
<wolfspraul> throw away the leftover
<wolfspraul> done
<wolfspraul> if you go there, they will cut it right there (30 minutes or so). of course they have to have the roll in stock, which last time was the case for 0.2mm al 99.5 and 0.3mm almg3
<wolfspraul> last time I got about 40 pieces or so out of each of the two 'smallest size' sheets I bought
<wolfspraul> that would fit perfectly with that is missing for you
<wolfspraul> ask them how much 1 meter of the almg3 roll is, I believe it was 1.4m wide
<wolfspraul> I think back then I got half a meter (times 1.4m width)
<wolfspraul> would that fit? let's see... 50*140=7000 cm2
<wolfspraul> 15*12.5=187.5 - 7000/187.5=37
<wolfspraul> yes, looks right
<wolfspraul> maybe when you order online, they will not offer 0.5m of the roll, maybe the minimum is 1m? they seemed to be a little more flexible with on-site customers
<wpwrak> (amiga) yeah, "demo" or "intro". http://en.wikipedia.org/wiki/Amiga_demos
<wolfspraul> roh: ask them for a quote of 0.5m of the 1.4m wide 0.3mm thick almg3 roll, cut into 149x124mm pieces. should be around 30 EUR, including VAT.
<roh> wolfspraul: i ask directly for pieces. i dont need to care how big their roll is
<roh> going there would be much more expensive than shipping
<wolfspraul> roh: but that difference may explain the higher prices you get :-)
<wolfspraul> their computer system works in these rolls, and how many meters you want from the roll
<wolfspraul> the cutting is the second step
<wolfspraul> that's what I tried to explain
<wolfspraul> so of course you can ask for '40' pieces
<roh> wolfspraul: there is no difference. you bought something like 40sheets of each thickness.
<wolfspraul> but if a 0.5m slice of the 1.4m roll gives you 37 pieces, they may just charge you the next total increment - I'm not sure.
<roh> wolfspraul: i asked for a price for 200 of the thick ones (heavier than a mix of thick and thin ones)
<wolfspraul> anyway I gave you the background data, you can do what is best for you.
<wolfspraul> what I bought was very cheap. maybe it was even 30 EUR for all 75 sheets.
<roh> i now ordered 25 of the thick ones.
<wolfspraul> including cutting, and including VAT
<roh> eh 50.
<wolfspraul> maybe they charge you a full meter of the roll then
<roh> i dont think so. that would be unserious.
<wolfspraul> they are not charging for the cutting, interestingly. at least not when you are there.
<roh> they do. once per order
<wolfspraul> well those are all very small amounts, so the most important thing is efficiency. they are setup for some things, and not for others.
<wolfspraul> when I was there, she gave me a price. then we added the cutting later (we just had that idea later), and the price stayed the same.
<roh> wolfspraul: there are 15euro 'nebenkosten'
<wolfspraul> I think the Performance/Done./Close dialog can be removed (in flickernoise)
<wolfspraul> say if I click on the mouse, why is that dialog even popping up - no need imho
<Fallenou> is it possible to go back from performance mode to flickernoise GUI mode ? (without power cycling, or rebooting the software) ?
<wolfspraul> sure, just press the mouse button, for example
<wolfspraul> keyboard probably too?
<lekernel> (by ftdi)
<kristianpaul> never take care about close the Performance/Done dialog
<kristianpaul> lol
<lekernel> wolfspraul: when you have several patches in your performance set, this dialog shows a progress bar
<lekernel> also reports error
<wolfspraul> kristianpaul: that's why I would just remove it entirely.
<wolfspraul> alright then :-)
<kristianpaul> hmm error is important
<kristianpaul> but is part of the same code for this dialog?
<lekernel> if you have only one patch, yeah, it's useless
<kristianpaul> ah ..
<lekernel> but try making a set with ~40 patches or so
<kristianpaul> never loaded multiples patches at once
<xiangfu> lekernel: thanks for import the m1s.git to 'milkymist/scripts.git'
<xiangfu> lekernel: I have two small patch for flickernoise:
<xiangfu> http://pastebin.com/DTuF5NPs : release '0' with 'SC_RESOLUTION_640_480' in fb.c
<xiangfu> http://pastebin.com/tpJFXYay : add Ctrl+F1 for iterate switch screen resolution
<xiangfu> lekernel: if you agree. I will direct commit to flickernoise.git :)  (since I have write access now)
<lekernel> ok, commit them
<lekernel> hm wait
<lekernel> in switch_resolution() please use sysconfig_get_resolution() instead of res = SC_RESOLUTION_640_480
<xiangfu> lekernel: now. I am working on increase the Video-in preview . I will try to add two switch button. 144x180 and 288x360.
<lekernel> btw the current RTEMS API to switch resolutions is quite of a hack, so no need to spend time on fixes like patch 1
<lekernel> the current API will disappear when we have the new SoC which supports scaling (and rendering in any resolution)
<xiangfu> lekernel: ok. then no patch 1. just patch 2.
<lekernel> you can commit patch 1...
<lekernel> now that you wrote it
<xiangfu> patch 2: it's 'static' can not get value from function
<lekernel> but no need to review the code for consistency there
<lekernel> hm? remove static then
<xiangfu> patch 1: ok , understand now.
<lekernel> res = get_resolution();
<lekernel> res++
<lekernel> if(res >  SC_RESOLUTION_1024_768) res = SC_RESOLUTION_640_480;
<lekernel> set_resolution(res)
<xiangfu> oh. yes. I forget the 'set_resolution',
<lekernel> also, what happens when you press ctrl f1 while rendering?
<xiangfu> testing now.
<lekernel> it probably breaks imo :)
<lekernel> btw one small improvement for your screen grabber
<lekernel> can you remove the unneeded alpha channel? it would cut down a bit the slowness and the file size
<xiangfu> lekernel: yes. I just delay this task. will fix that today or tomorrow
<xiangfu> when rendering. 800x600 == half screen rendering. 1024x768 == black screen
<lekernel> yeah...
<lekernel> so please disable ctrl f1 when rendering
<xiangfu> but we can always go back to 640x480 with out any problem. flickernoise not freeze.
<xiangfu> lekernel: ok
<xiangfu> lekernel: new patch 2: http://pastebin.com/AfGGJk53
<lekernel> xiangfu: ok, good
<CIA-48> flickernoise: Xiangfu Liu master * r5e03616 / src/fb.c : fb.c: replease 0 with SC_RESOLUTION_640_480 - http://bit.ly/ghMfwU
<CIA-48> flickernoise: Xiangfu Liu master * rd5d459d / (src/fb.c src/fb.h src/shortcuts.c): add Ctrl+F1 for iterate switch screen resolution - http://bit.ly/e6SNP9
<xiangfu> lekernel: there is no 'fjmem' in github/milkymist .
<lekernel> xiangfu: one question: in future, all git repos under 'https://github.com/milkymist' will became milkymist upstream. right?  <= didn't get your question
<lekernel> git://github.com/psycho-nico/milkymist-openwrt.git is dead, won't move it
<lekernel> fjmem... depends whether mwalle wants to use github and/or his own servers
<xiangfu> I just found the fallen/rtems-milkymist.git is gone. I mean in future the git repos under github.com/milkymist/*  will be the official source code for m1 right?
<lekernel> yeah
<lekernel> i'll mirror fjmem anyway
<lekernel> for qemu/urjtag, all/most of it is upstream, no need to create new repositories for this imo
<xiangfu> maybe. fjmem-m1. other repo are all *-m1
<lekernel> yup, renamed
<lekernel> thanks for your attention to detail :-)
<xiangfu> :)
<xiangfu> I build those files for reflash by using 'urjtag'. it's not ready for end users.
<xiangfu> the plan is make the build automatic a little.  get all build log.
<lekernel> yeah, and let's only flash boards that come out with releases
<lekernel> not repository snapshots
<lekernel> i'll try to get another release with the new ethernet core some time before we start flashing the next batch
<lekernel> so we have time to test and maybe fix last minute bad bugs :)
<xiangfu> ok.
<xiangfu> after I flash the new image. for now the ethernet works fine. but the m1 get freeze sometimes. I will try to correct more info next time it freeze.
<xiangfu> also some patches not working with new image
<xiangfu> lekernel: do you think I send one email to list about those image is ok? for someone when want test new image?
<lekernel> what do you can 'new image'?
<lekernel> call
<lekernel> msd-apr2011?
<lekernel> and please give me the list of the patches that do not work
<lekernel> and yeah you can advertise your link on the mailing list. but make clear these are development snapshots.
<xiangfu> lekernel: patches. I will find out them tomorrow. (23:50 now. will goto sleep soon)
<lekernel> is that with the new ethernet core (minimac2)?
<xiangfu> lekernel: I update all git repo to last. and those images are build today.
<lekernel> hm, ok
<xiangfu> yes. it's minimac2.
<xiangfu> (from the git commit log :)
<xiangfu> time for sleep. see you
<CIA-48> flickernoise: Sebastien Bourdeauducq master * r65e17b5 / src/shortcuts.c : Use Ctrl-F2 for screenshot - http://bit.ly/i5Yq9B
<terpstra_> mwalle, finally got a fully working gdb over JTAG using a 1K debug ROM.
<terpstra_> works quite nicely :)
<terpstra_> quite acceptable speed as well
<terpstra_> i can load firmware via gdb's "load" command at about 3kB/s
<terpstra_> which, while not super-fast, isn't bad for a bitbanging usb cable
<mwalle> terpstra_: nice, so you are using the mini rom monitor?
<terpstra_> i wrote my own
<terpstra_> the original wasn't relocatable
<terpstra_> and i wanted to fit it into 1KB
<mwalle> with ram?
<terpstra_> 1k ROM + 256 bytes RAM
<mwalle> ok nice :)
<mwalle> does it support byte/halfword/word access?
<mwalle> (used eg for flash initialization)
<terpstra_> no, it does not
<terpstra_> i might add that later
<terpstra_> but at the moment i have other goals :)
<terpstra_> i also don't deal with bus faults
<terpstra_> which i consider higher priority than flash (which i don't have)
<mwalle> mh the qemu model of milkymists sysctl timers are totally broken :(
<terpstra_> :-(
<terpstra_> i got to run now; was a long hackathon
<terpstra_> bed time!
<terpstra_> ciao
<mwalle> gn8
<mwalle> lekernel: is there a way to know wether the mac address is valid or not (is it included in the rescue bios crc?)
<lekernel> yes, it's in the bios crc
<mwalle> we should set a valid default mac address if the crc failed, eg 02:00:00:00:00:01