<kristianpaul> finally, ramdisk implemented
<kristianpaul> lol what i tought MM1 had 256Mb of ram :p
<kristianpaul> puh, malloc is no fun anymore when you have a 90Mb ramdisk around ;)
<lekernel> wolfspraul, I just ran my M1 continuously for some 44 hours of rendering now... no problem
<lekernel> did Adam get the PCBs back?
<wolfspraul> lekernel: sorry disconnect.
<wolfspraul> [44h] sounds great, I'm not doing any testing now but when I get back to it I will definitely report back
<wolfspraul> [adam] don't know, I don't check with everybody every day, that itself would take too much time and distract people too much
<wolfspraul> if I hear nothing, that means no problem and things are moving forward :-)
<wolfspraul> lekernel: I'm thinking what to write on the box about the VGA resolution
<wolfspraul> in general I like what we have on the Wikipedia page, it's very clear and well structured
<wolfspraul> however, under Display, it says "SVGA up to 140MHz pixel clock (1280x1024)"
<wolfspraul> that's pretty cheesy on the box I think
<wolfspraul> of course "up to" is correct, but...
<lekernel> yeah, the actual limit is 140MHz pixel clock (comes from the adv7125)
<wolfspraul> on the other hand I don't want to write 640x480, that's not so good either
<wolfspraul> sure sure, I'm just thinking what to write on the box
<lekernel> how this translates to a resolution depends on the refresh rates the monitor supports
<wolfspraul> somewhere on the side, where the specs are
<wolfspraul> the brutal option is to just say VGA 640x480
<wolfspraul> :-)
<lekernel> you can just write 'high resolution vga output'
<lekernel> that's what i'm putting on the brochure
<wolfspraul> hmm
<lekernel> later FPGA designs will probably support 1280x1024 including render mode
<wolfspraul> ok we don't need to make a final decision now
<wolfspraul> yes sure, I know all that, what's possible etc. But I'm asking what we print on the box now :-)
<wolfspraul> "up to 1280x1024" is not good I think
<lekernel> for software dependent stuff, try to highlight only the main features... not details.. .they WILL change
<wolfspraul> that's another option, no resolution at all
<lekernel> "high resolution" is fine imo
<wolfspraul> has there ever been a vga/svga resolution lower than 640x480?
<wolfspraul> I mean I remember EGA and stuff, but I think VGA started at 640x480, no?
<lekernel> yes, it's still higher resolution than CVBS which is what a lot of VJs use even today
<kristianpaul> if render is done  at 640x480 (and how many bits?) thats the fair i think
<wolfspraul> I don't like to say 'high resolution' when it is the lowest vga resolution many people will ever have heard of, if lower ones even exist
<lekernel> there's 320x200 :)
<lekernel> and the hw definitely can do 1280x1024
<wolfspraul> ok, thanks for the input. no need to decide now, easily changed...
<lekernel> just so you know, a lot of VJ equipment is PAL
<wolfspraul> I will fiddle a bit more with the box design, then I have my draft an people can review it or propose alternatives or whatever.
<lekernel> VGA is seen as "luxury" by many people
<lekernel> even most of the professional roland stuff is PAL/CVBS
<wolfspraul> understood
<wolfspraul> but what we write there is a careful exercise in expectation management
<wolfspraul> people will read this, and from reading it they may draw conclusions, they develop expectations, etc.
<wolfspraul> so ideally you want to get people excited, but you also want to keep their expectation at a level that will still leave some room up once they discover more details over time...
<mumptai> hi
<kristianpaul> hi
<lekernel> kristianpaul, i'm sure you want to integrate this in mm bios :-p
<drub> Hello, I am very new to milkymist and am wondering if there is a way to run an emulation of milymist on my PC?
<kristianpaul> yes it is drub
<kristianpaul> you can use qemu
<drub> ahh I just saw the wimi listing qemu :-)
<drub> wiki
<kristianpaul> yes
<drub> in the hardware MM1 can the inputs be switched via software?
<kristianpaul> you can do lots of things using verilog or bitbanging if you wich i think
<drub> Do you know, does RTEMS have a webserver, or can one be installed and flashed to MM1?
<drub> my goal to to create a tablet interface to control MM1
<lekernel> drub, hi
<lekernel> yes, that would be very cool. atm we can use opensoundcontrol to control MM1 from tablets
<drub> hey lekernel
<drub> cool
<lekernel> but that's a bit limited (both by the opensoundcontrol protocol and by the lack of time to implement tons of functionality through it)
<lekernel> the webserver approach is very interesting, especially given all the things you can do with javascript those days
<lekernel> for RTEMS there is http://www.rtems.com/wiki/index.php/Simple_HTTPD but I don't know what it's worth
<drub> yes, and since it could be written using Phonegap it would run on all tablet/smartphone platforms
<lekernel> I've never tried it or even had a look at the code
<lekernel> I also have friends who develop http://www.ape-project.org/
<drub> I will have to take a look
<lekernel> and who would be interested in porting it to MM1, btw
<drub> I use a port of APE with haXe now :-)
<drub> haXe would be really cool on tablets if they had fully working android/ios ports
<lekernel> haxe... hmm
<lekernel> we'd need to get the C++ compiler to work
<lekernel> atm it's crippled with bugs...
<drub> I am just getting started so I am going to have to get the qemu running on my local machine, my partner is ordering two MM1 boxes
<drub> yeah haxe is only usable in very few places atm
<drub> but phongap would work perfect, write once and run on all platforms
<lekernel> we also hopefully have a LLVM port coming soon, so this can potentially solve more programming language related problems
<drub> I think the winning answer would be to make it run a webserver with an API to control every aspect of the device
<drub> :-)
<drub> I am a dreamer :-)
<lekernel> yeah, I think the same
<lekernel> with ajax and all similar modern bling-bling :-)
<drub> yeah!  :-)
<lekernel> for QEMU, you should just take the upstream git version and compile it
<lekernel> it didn't make it way into the releases (yet)
<lekernel> then for toolchain and software just use the build script
<drub> do you have a location for that?
<lekernel> and QEMU... it's regular QEMU, just enable the "lm32-softmmu" target
<drub> oh ok cool
<drub> I hate windows, I am stuck with it at the moment, and my virtualbox is being a B!#ch
<lekernel> all our devtools (including fpga stuff) run on linux...
<lekernel> if you are stuck on windows you might have luck with cygwin
<lekernel> but afaik no one tried it yet
<drub> I am installing linux on virtualbox
<drub> so I am going to run emulation in emulation in emulation :-)  should be quite the slow experience :-)
<GitHub162> [extras-m1] sbourdeauducq pushed 1 new commit to master: http://bit.ly/jxwAyO
<GitHub162> [extras-m1/master] brochure: last page. Needs hi res logos from Tuxbrain and HD. - Sebastien Bourdeauducq
<GitHub187> [extras-m1] sbourdeauducq pushed 2 new commits to master: http://bit.ly/jPEYEj
<GitHub187> [extras-m1/master] brochure: missing file - Sebastien Bourdeauducq
<GitHub187> [extras-m1/master] brochure: use vector graphics creative commons logo - Sebastien Bourdeauducq
<drub> I cant get git clone http://git.serverraum.org/git/mw/qemu-lm32.git  to work :-(
<GitHub118> [extras-m1] sbourdeauducq pushed 1 new commit to master: http://bit.ly/lYvWBU
<GitHub118> [extras-m1/master] brochure: dance directed visuals - Sebastien Bourdeauducq