Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
lekernel__ joined #milkymist
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
wolfspraul joined #milkymist
wolfspra1l joined #milkymist
yizhang joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
whitequark joined #milkymist
wolfspraul joined #milkymist
wolfspraul joined #milkymist
wolfspraul joined #milkymist
cocoadaemon joined #milkymist
Martoni joined #milkymist
azonenberg joined #milkymist
<xiangfu> wpwrak, the DMX device will arrive today evening. good news. :) because I got a message yesterday. it said will delay ~5 days. :)
<xiangfu> then I will upload some pictures
<xiangfu> maybe I will got them in next 3 or 4 hours.
r33p joined #milkymist
wolfspra1l joined #milkymist
wolfspraul joined #milkymist
aeris joined #milkymist
wolfspraul joined #milkymist
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
<aw_> xiangfu, http://dpaste.com/666344/ Does it show that 'lm32-rtems4.11' compiles well and boot.bin without err ?
wolfspraul joined #milkymist
<wpwrak> looks good, yes
<wpwrak> aw_: (fedex) thanks !!
<wpwrak> aw_: what total declared value did you put ?
<aw_> wpwrak, great. I've not put declared value yet. Don't tell me now. hehe ... one day let me figured it out. just want to confirm tool is okay. :)
<wpwrak> no, i mean on the fedex shipment
<wpwrak> or did you not declare the value of the shipment ?
<aw_> ha ~ the fedex declared value I put USD 35 only. :)
wolfspraul joined #milkymist
<aw_> reason: repair since the M1 looks a repair board. :)
<aw_> do u think it's okay ?
<wpwrak> hehe ;-))
<wpwrak> let's see what happens
<wpwrak> i usually try not to give them an excuse to stop it at customs and make me go there. but well, maybe it works.
<aw_> i did mostly like that way. so hopefully it goes through
<aw_> one question: how can I know mostly that compiler works well in linux environment ? just dig into each Makefile to see what they do ? or other way ?
wolfspraul joined #milkymist
wolfspra1l joined #milkymist
<aw_> in the window IDE environment, I usually see the 'output windows' to see the results of compilation. And smart IDE tool with different color automatically to point err /or warn lines.
<aw_> so in terminal, how should I focus on compiling ?
<aw_> Are my questions stupid enough ? or don't ask in that way, and just _do_ it ?
wolfspraul joined #milkymist
<wpwrak> aw_: if there's an error, it will tell you at the end :)
<wpwrak> aw_: and soon, the compilations will be less chatty. then it will be MUCH easier to spot problems
<xiangfu> aw_, ( http://dpaste.com/666344/ ) looks fine.
<xiangfu> aw_, you can try the boot.bin now.
<xiangfu> aw_, but there is no image's CRC in this boot.bin
<aw_> wpwrak, oah ~ see it now. I just intended to type wrong, compiled and understood your 'less' vs 'MUCH'. thanks ! I.e. all the results are in way of historical context.
<aw_> xiangfu, oah ~ yes. Thanks ! I also saw a file 'append_crc_len.sh'. So does it work for it ?
<xiangfu> aw_, yes. it works fine. it needs one parameter: IMAGES_DIR
<xiangfu> aw_, this patch should contain all images.
<aw_> xiangfu, I don't know them now. he. :)
<wpwrak> aw_: (less/MUCH) ah, i meant something else: the patches xiangfu just posted will reduce the output during a normal compilation. so if there is any problem, the error message will be easy to spot
<xiangfu> aw_, s/this patch/this path/
<aw_> xiangfu, wpwrak ha ~ got it.
<xiangfu> aw_, hmm... I will think about this boot.crc.bin. the release image don't have bios-rescue and splash-rescue.
<xiangfu> oh.
scrts joined #milkymist
scrts joined #milkymist
<wolfspraul> interesting, reading about Lemur http://en.wikipedia.org/wiki/Lemur_Input_Device
<wolfspraul> this was a multi-touch osc controller which sold for 1500-2000 USD and used by serious artists and performers for a few years
<wolfspraul> seems they retreated peacefully from the marketplace after the ipad showed up and killed their business...
<wolfspraul> http://www.jazzmutant.com/ (farewell post)
<wolfspraul> I am harvesting their remaining reseller links, those are all good leads for Milkymist imho http://www.jazzmutant.com/order.php
<wolfspraul> I am wondering how many were sold in total, they seem to have an impressive list of artists who used it, so I don't know
<wolfspraul> I'd say 500 at least
<lekernel__> further reason to go beyond the touchscreen...?
<wolfspraul> 500-2000 ? even more?
<wolfspraul> well if I think about their product it's clear they had no chance against the ipad
<wolfspraul> maybe they can port their software over, but then I don't know how attractive it still is to real artists...
<wolfspraul> anyway, I just foudn out about it, following old leads from guys I met
<wolfspraul> Lemur :-)
<wolfspraul> good thing I foudn their reseller list before they are shutting down the entire jazzmutant.com site, seems soon...
<lekernel__> what's worrying me (yeah, always pessimistic, I know) is they still got killed despite these resellers and impressive list of artists
<wolfspraul> how could they not?
<wolfspraul> some of those artists may not have been paying customers, we don't know
<wolfspraul> then how many additional customers are really drawn to a 1500-2000 USD product, no matter how many Bjoerks use it?
<wolfspraul> I think it will be in the hundreds, at the very most low thousands
<wolfspraul> so let's say 2000
<wolfspraul> 2000 * 1000 = 2 million USD
<wolfspraul> they have to fund everything from that, which is possible but still tough business
<wolfspraul> several people for several years, marketing, manufacturing, software development, etc.
<wolfspraul> and then the ipad comes
<wolfspraul> and booom
<wolfspraul> they have no chance
<wolfspraul> I mean that thing even looks like an ipad before the ipad, no? :-) from the pics
<wolfspraul> they should have sued Apple
<wolfspraul> unfortunately in the real world they would need at least a 100 million USD investment or so to take on such a 'project'
<wolfspraul> what do these guys do now?
<wolfspraul> must be something interesting :-)
<lekernel__> well, yes... it's an ipad :)
<lekernel__> http://www.stantum.com/en/ that's their parent company
elldekaa joined #milkymist
<wpwrak> (lemur) interesting. so that's where iCon got their idea for their USD 125 controller from :)
ab5tract joined #milkymist
<wpwrak> lekernel__: btw, any comment on my fpvm.c cosmetic changes ? okay to proceed in this direction ?
<lekernel__> wpwrak: still need to have a deeper look at it, but the idea was to make libfpvm relatively generic
<lekernel__> that's why it works on equations and not patches
<lekernel__> that's an attempt to limit spaghetti code and have clearer interfaces :)
<lekernel__> do you think the fpvm equation parser could take over within a better/more conventional patch parser (I agree it could be improved) and read characters until some delimiter? (\n, ;, etc.)
<wpwrak> stacking parsers inside parsers tends to be messy. but where do you need "naked" equations anyway ? the prologue and epilogue could be treated like regular patches as well - and look better than they do today
<lekernel__> this is more an attempt to keep some modularity than anything else
<wpwrak> if you really need "naked" equations, you can steer the grammar towards some special start state
<lekernel__> I don't need naked equations... except for prologue/epilogue as you said
<lekernel__> it's for keeping it modular
<wpwrak> naw, just makes things complicated :) the language is pretty simple. breaking things up in the middle adds mainly complexity. worse, you have a lot of information that's shared between both sides (e.g., predefined variables)
<lekernel__> libfpvm implements fast equations on the hw accelerator, with a clear interface
<wpwrak> the most straightforward solution would be to move the whole parser into flickernoise :)
<lekernel__> then you can build other stuff on top of this, like the patch parser
<wpwrak> you could make the AST or something similar the interface. then you don't break up the language
<lekernel__> that's a possibility, but then inserting the prologue/epilogue by manipulating the AST in C is messy
<wpwrak> not at all. you'd just run it through the parser like the patch itself
<wpwrak> so you build one AST or AST-like thing
<wpwrak> bascially whatever you have right above dynamic register allocation and code generation makes a "clean" interface
<lekernel__> yes, I agree with the AST interface solution
<wpwrak> below all this, you have another "clean" interface (i.e., one the scheduler uses)
<lekernel__> as long as prologue/epilogue aren't messy :)
<lekernel__> btw, you can drop the demo firmware if you make large changes like this
<wpwrak> i would hope to just have them in files :) or some long-string-embedded-in-C equivalent
<wpwrak> right now, they're kinda hard to decipher anyway
<lekernel__> nowhere near as hard as manual allocation of AST nodes :)
<wpwrak> (demo) excellent, thanks !! i was worried about that one :)
<wpwrak> you could write the prologue and epilogue in hand-optimized "assembler". then everybody would believe it's for performance ;-))
<wpwrak> but i think it'll work just fine to turn this into a "program" that looks like a regular patch
<lekernel__> not really, you need to take care of the single-use registers
<lekernel__> and assembly wouldn't even be efficient
<lekernel__> just run it through some parser like it's done now
<lekernel__> that's the best solution
<wpwrak> funny. the lemur is just how i pictured our touch screen should be. i'd just not use real multi-touch (need some buttons on the side, though) and would use less colors
sh4rm4 joined #milkymist
DJTachyon joined #milkymist
<wpwrak> i have a few openmoko touch screens lying around. these would in theory be easy for prototyping. alas, they're tiny
<wpwrak> i also have one or two P2P clones from HXD8. they're a little bigger. hmm...
<kristianpaul> wow prety futuristic this lemur, well i guess for its born time
<wpwrak> that was just 6 years ago
<kristianpaul> hum
<GitHub96> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/ec51f09c98676a6b14be3abfdaa43f995a855458
<GitHub96> [migen/master] Case support + register bank generator - Sebastien Bourdeauducq
errordeveloper joined #milkymist
<GitHub164> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/4340680704900b8836380012ca6c56dc8c4f5267
<GitHub164> [migen/master] Cleanup - Sebastien Bourdeauducq
kilae joined #milkymist
kilae_ joined #milkymist
r33p joined #milkymist
Technicus joined #milkymist
Technicus joined #milkymist
Technicus joined #milkymist
elldekaa joined #milkymist
<GitHub38> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/0e8d894a354652c6dd361f31818e8b9e625efc77
<GitHub38> [migen/master] Variable conversion - Sebastien Bourdeauducq
antgreen joined #milkymist
sh4rm4 joined #milkymist
<wpwrak> pity that we'll probably want to run algorithmic optimizations on the AST later. otherwise, the parser could just generate code directly
n0carri3r joined #milkymist
<azonenberg> Hmm
<azonenberg> The datasheet and timing analysis disagree
<azonenberg> as to the high end of the BUFG clock range
<azonenberg> I'm creating a PoC design (just a single LUT and a flipflop configured as a divide-by-two) that I want to clock as fast as I can
<azonenberg> using a 100 Mhz input clock multiplied up by a PLL_ADV
<azonenberg> The datasheet seems to suggest the global clock network runs up to 400 Mhz
<azonenberg> But my design passes timing at a 5x multiplier
<azonenberg> Any guesses as to which one to believe and how ot test this for sure?
<wpwrak> are you saying it works beyond the guaranteed specs ? where's the problem then ?
wpwrak joined #milkymist
DJTachyon joined #milkymist
<wpwrak> hmm, i wonder if variable names like "sin", "cos", etc., are valid in milkdrop. they would currently be in FNP, but that's not necessarily a nice feature.
<n0carri3r> whoa, big site update :)
<n0carri3r> thanks for the concert shots!