<roh>
nand is _really_ scary. only watch it if you want to really know what happens with your bits in flash
<wolfspraul>
feels so much better on an SD card
<wpwrak>
however, yaffs2-shutdown = needed each time you change something, kernel-partition-"shutdown" = needed each time you change the kernel. so again, it's only comparable if you have a dedicated boot partition anyway
<roh>
wolfspraul: same problem. just more honey around it to hide it (another 8051)
<rjeffries>
Not bad at all: 20:42 <wpwrak> rjeffries: about 1 EUR per UBB, MOQ 500. I was figuring 1,000 would be an economic qty.
<wpwrak>
wolfspraul: (sd card) i'll print and frame this one ;-)
<wolfspraul>
I was kidding :-) I just wanted to advertise the fantastic proprietary technology that will 'take care' of 'all' problems once could ever encounter with raw NAND. Werner has a secret side job to advertize those bits...
<roh>
well.. hdds or dram isnt less scary in the same level of detail
<wpwrak>
rjeffries: at 1000, you'd drop down to something like 0.75 EUR/UBB. looks like a medium-volume fab. if you want to make > 10k, you probably need to go to china :)
<roh>
hdds in the end 'recieve rf from the disk and 'statistically' isolate bits there and grade and rate them. same spookyness.
<wpwrak>
wolfspraul: it's called "outsourcing" ;-)
<roh>
ram.. needs to be refreshed and has spooky realworld failrates. nobody really wants to know. often just nothing bad enough happens one even notices
<rjeffries>
wpwrak //re UBB// if you want to make > 10k, you probably need to go to china :) //and wolfspraul needs to sell more Bens//
<wpwrak>
rjeffries: for every 1000 UBB you buy, you get a free ben ;-)
<rjeffries>
I read your 2006 PDF about making the LED gdget. nice piece of work. very instructive
<wpwrak>
(so change EUR 2 per UBB. at production cost EUR 0.75 1000k+, you get a decent margin, even with the ben on top :)
<wpwrak>
err, 1k+ ;-)
<wpwrak>
rjeffries: thanks :) alas, already a bit obsolete
<rjeffries>
there is more to wpwrak than meets the eye
<rjeffries>
itwill be intereting to compart USA estimate with Tuxbrain I suspect similar prices actually
<rjeffries>
unless he is gettinga special deal from a friend of a friend or a guy who knows a guy who...
<wpwrak>
i would expect a larger price range in the US, with the silicon valley. nothing rock-bottom, though. you have to go to asia for that.
<rjeffries>
has Tuxbrain decided to push forwar with UBB. if so I will get estimates ten simply buy some for me from tuxbrain simple as tat
<rjeffries>
the cheapest price we can get is zero dollars/ea
<rjeffries>
this is so dmall and so simple that it is all setup I think
<rjeffries>
I am just learning anyway
<rjeffries>
s/ten/then
<rjeffries>
I know a great guy in Asia
<rjeffries>
It's funny, he klives in Cina, has a shop in Hong King, has people in Taiwan, and an engineer in Argentina and others in France, Germany Russia and god only knows weher else
<rjeffries>
his name sounds German but it may be just a virtual persona. not that there is anything wrong with that
<qi-bot>
[commit] David Kühling: add icon for brainless (launched in utf-8 graphics mode in a jfbterm) http://qi-hw.com/p/gmenu2x/63f462c
<bartbes>
hmm, it appears I can't use OpenID on the wiki...
<bartbes>
maybe I need to link it to my account first?
<wolfspraul>
bartbes: sorry yes, that's one of the really high priority bugs I want to fix
<wolfspraul>
knowing that you also ran into it makes it high+ priority :-)
<bartbes>
alright, then at least it isn't me ;)
<wolfspraul>
definitely not. unfortunately I've heard that there are bugs in the openid plugin on mediawiki, so I'm hoping if I just wait a little I can upgrade and it will go away.
<wolfspraul>
unfortunately it may not be that easy... oh well.
<wolfspraul>
it's 100% a bug on the server
<bartbes>
yeah, my openid provider tells me access had been granted
<bartbes>
so it got there, at least
<bartbes>
installs gforth
<bartbes>
I lost a lot of programs in that reflash..
<dvdk>
barbes: forth is just like any other programmin language.  just a matter of getting used to it.  plus i was exposed to it at pretty young age :)
<kristianpaul>
but you still using it?
<kristianpaul>
i mean not just nanonote related work..
<bartbes>
sure, but it still takes skill
<dvdk>
barbes: nowadays you can write equally obfuscated code with C++ (boost+mpl) :)
<bartbes>
heh
<kristianpaul>
hmm
<dvdk>
at least forth doesn't produce error messages, where a single message takes up > 1 screen (try boost::lambda :)
<kristianpaul>
no thanks ;-)
<bartbes>
kyak: I started writing some script to run nlove games and download them from my dropbox in case you didn't have them
<kyak>
bartbes: the idea is good! maybe even to have some simple interface to choose and run nlove games, and download them from qi's mirror if it's not downloaded yet
<bartbes>
kyak: if I can get it to work I'll probably make it create gmenu2x shortcuts too
<kyak>
yeah, would be great
<dvdk>
kristianpaul (user forth): (almost) only for fun.  as a fast script language.
<dvdk>
s/user/using/
<bartbes>
kyak: alright, it's working
<bartbes>
I probably have some outdated versions though
<bartbes>
and there's no way to update yet..
<bartbes>
maybe.. rsync?
<bartbes>
no http
<bartbes>
hmm
<kristianpaul>
k
<bartbes>
kyak: a full repo might be a bit much :P
<bartbes>
whatever, no updates for now then
<bartbes>
I'll work that out later
<kyak>
bartbes: you could speak to wolfgang about hosting soem nlove games on qi server
<kristianpaul>
games !
<kristianpaul>
open wrt current image lack some less console like games afaik.. :(
<bartbes>
btw, Textmode, you don't happen to have a game idea that works on 320x240?
<Textmode>
bartbes: nothing I would actually consider a game.
<bartbes>
aww
<Textmode>
plus, I'd have to convert it a bit.
<kristianpaul>
why port games from jlime too?
<kristianpaul>
zrafa: or those games just run on top of X?
<kyak>
i want to port supertux, it runs in SDL , but there are problem as i mentioned to zrafa above..
<kristianpaul>
and gnurobbo?
<zrafa>
morning
<kristianpaul>
Block rage?
<kristianpaul>
zrafa: morning from pole to pole :-)
<zrafa>
kyak: supertux: which stuff does not fit well?.. the menues suck a bit but you can read it completely. ANd when you are playing all the stuff is well sized.
<kristianpaul>
also an audio recoder frontend will be nice
<kyak>
block rage would also be nice to port
<zrafa>
kyak: most of the "extra packages" were not build with OE, those were built using the toolchain built by OE
<kyak>
zrafa: in jlime, yes, it's OK. since i use the same source as you use for jlime, that's why i wonder what else could be different? do you have a recipy for supertux?
<kyak>
hm, ok.. so it is not actually ported to OE
<kyak>
at least could you show the command lien you used to build it?
<zrafa>
kyak: no, no recipy. It was built with ./configure ; make I think. BUt IIRC OE added supertux qvga recently. We could check that
<kyak>
zrafa: there is no "configure". There are however autogen.sh and gp2x_configure. Also, there msut be some options for configure
<zrafa>
kyak: let me check.. but I did not do anything special. I was talking with supertux devs at that time and they just pointed me to use an specific version from svn. Let me check those sources again
<dvdk>
i think you should really have a look at allegro games.  since allegro dates back from ms-dos times, many games should still support low resolution modes
<kyak>
zrafa: sure, thanks!
<zrafa>
kyak: ah.. that is the problem. There is not sources
<kyak>
zrafa: ok, let me ask you simple. Is there any way to reproduce your build for Jlime? In general, how do you track pacakges like this (for exmaple, when releasign new Jlime version)?
<zrafa>
kyak: nobody builds that again, that is already built
<kyak>
huh? do yo umean that you just copy binary from release to release?
<zrafa>
kyak: you are asking because you see the development environment from openwrt pov. But well, there are serveral points. Extra packages are just that, extra packages built with toolchain.
<zrafa>
kyak: we do not build that again and again. we just use opkg-arget to include that into rootfs. It is not cp binaries
<zrafa>
kyak: do you know how opkg-target works?
<kyak>
zrafa: what would you do if someone want to follow your steps? Or if you want to build it again after one year?
<kyak>
no, i don't know how opkg-target works
<zrafa>
kyak: extra packages are not intended to track them and next year to build again. It is just a build done with toolchain. Then many users can test it. If all are happy, we can include that into OE properly.
<zrafa>
kyak: that is the meaning of extra packages there.
<zrafa>
kyak: you are asking about packages which are not tracke
<zrafa>
d
<kyak>
ok, i got it. extra packages are not tracked
<zrafa>
kyak: and opkg-target is a tool which let you install packages into rootfs from host. For example. Surely you build the 80% of your rootfs again and again without chagnges on those packages. Which is the goal on that?. opkg-target would let you to install those packages which you already built once and you do not need to build again
<zrafa>
kyak: if a rootfs building proccess takes 50 hours, you could do that in two hours building just the new packages or packages which changed, and then opkg-target would install the packges already built but which did not change
<kyak>
zrafa: anyway, i have problems running supertux. No matter how i tried
<kyak>
zrafa: that's why i was guessing that you made soem adjustments in the source code.. which might be not documented
<kyak>
or maybe you build it in some other way, i don;'t know
<zrafa>
kyak: no, I did not do. Dont know anything about it. BUt well, we should try supertux recipe on curretn OE. They have a qvga version, which is tracked like you need.
<zrafa>
kyak: from my side I will build it again to check on nn.
<xiangfu>
wolfgang. by pressing [F4] when poweron. u-boot will try to load ROOTFS:/boot/uImage.
<kyak>
zrafa: oh, sorry, i need another eyes :)
<xiangfu>
goto sleep
<xiangfu>
normal boot. u-boot needs ~1second, load kernel from ubifs, u-boot needs ~6seconds
<xiangfu>
with 512M rootfs of cause.
<xiangfu>
1.5G rootfs needs more time.
<kristianpaul>
256M?
<kristianpaul>
hmm nv
<rjeffries>
someone is confused. not everyone who is interest in Ben Nanonote is a code committer
<rjeffries>
some go off and figur eout how to build Werner's PCB is a very CopyLeft manner
<rjeffries>
but nice try, lekernel. God, I feel all warm and fuzzy and happy when I see your coments to me.
<rjeffries>
lekernelrjeffries: so, what code have you committed today?
<lekernel>
rjeffries: sorry, could not resist. you are right, though you also talk/troll a lot :)
<dvdk>
xiangfu: hmm, what is the reason that ubifs is *that* slow?
<kristianpaul>
dvdk: may be not ubifs itself, just u-boot implementation...
<dvdk>
but this is a pure read-only implementation?
<xMff>
regarding the opkg-target suggestion, did you look into the imagebuilder already? you can set it up to use external repos and just repack images with desired packages
<dvdk>
kristianpaul: i guess this is i/o bound speed, so for some reason, ubifs makes it necessary to read from much more blocks than just the kernel?
<dvdk>
xMff: you mean we could build out-of-the-box images with preinstalled s/w without recompilation? sounds nice.  remembers me of debian's lifecd-image tool
<dvdk>
and having lots of prebuild images (games, vs dev, vs. minimal etc.) ready for download would be very nice for users
<xMff>
it is interesting for release images as it allows you to compile the IB once and then use that to generate various images
<kristianpaul>
dvdk: perhaps, but i'll wait xiangfu wake up and ask more, i dint understand well what he pointed, so i'm bit confused
<dvdk>
kristianpaul: maybe it would help to create another, smaller /boot ubifs partition?
<kristianpaul>
dvdk: yeah i was thiking same
<kristianpaul>
xiangfu ^
<dvdk>
.. and another detail that makes things more comples :/
<dvdk>
s/comples/complex/
<kristianpaul>
hehe
<dvdk>
btw i've seen arm boxes that had soldered-on IDE-flash to get rid of such problems (i.e. wear-leveling in hw).
<dvdk>
but then i hate hw implementations that keep me from accessing my data at a low level (if things break).
<kristianpaul>
I think things will be better with no uboot in the middle
<dvdk>
kristianpaul: but how to load linux without uboot?
<kristianpaul>
a smaller boot stage
<kristianpaul>
i heard lars is working on something
<dvdk>
likes boot-loaders
<dvdk>
at least something to access, in case kernel broken
<kristianpaul>
I think irclog archive may have the ogg video of a faster boot in a dingux/pandora i dont remenber
<dvdk>
openfirmware was nice, btw
<kristianpaul>
if kernel broken in the nanonote you will have hardware-boot usbboot
<dvdk>
didn't hear much good about hardware-usbboot
<wpwrak>
dvdk: (ubifs slowness) i think it's similar to jffs2. in jffs2, you need to scan the entire partition to collect the blocks. jffs2 assumes that any block can go bad and you thus can only be sure you have the latest version of a block when you've scanned everything for updates.
<kristianpaul>
actually with kernel broken in the nanonote i still not seen usefull uboot...
<dvdk>
wpwrak: yeah, no about jffs2, thought ubifs were properly redesigned
<dvdk>
s/no/know
<wpwrak>
dvdk: (hw usbboot) the main problem is making that contact. if this was more like the reset button, it would be much easier.
<kristianpaul>
wpwrak: is it posible just drop the fs for kernel image? in the mm1 for example i think is written in a "raw" way
<dvdk>
wpwrak: yeah that'd be great, would sell my usbboot, for a boot-loader button :)
<dvdk>
kristianpaul: this is how it is done currently, afaik
<wpwrak>
dvdk: seems that ubifs shares the same O(partition_size) property. there may be specific reasons why they prefer this over a "if block X fails, just nuke it" approach
<dvdk>
kristianpaul: so changing to ubifs would make things 6s slower than now
<kristianpaul>
dvdk: oh, i got it then !
<kristianpaul>
:_)
<wpwrak>
dvdk: part of it may be wear leveling
<dvdk>
wpwrak: well at least this way it's very easy to guarantee consistency.  if in doubt, use brute force
<wpwrak>
dvdk: i.e., you don't want to update meta-data when blocks move around. thus you need to search for them
<dvdk>
^
<dvdk>
wpwrak: then let's abandon ubifs :)
<kristianpaul>
dvdk: (button) you can make a reset button for the alt + u keys i think :)
<dvdk>
kristianpaul: nope, alt+u is read by bootloader.
<wpwrak>
dvdk: (6s) iff the boot/root partition stays at 0.5 GB. if going to a unified root/data partition, that should become more like 15 s
<wpwrak>
well, 15-20 s
<dvdk>
wpwrak: yuck!
<wpwrak>
(alt u) just U is enough
<dvdk>
starts to hate ubifs
<dvdk>
kristianpaul: i.e. its a sw-button.  hw-pin is below battery
<kristianpaul>
dvdk: yes
<wpwrak>
dvdk: i like the idea of flash memory being a "black box". we all trust this approach when it comes to disks. why try to deal with physics we have very incomplete knowledge of with NAND ?
<kristianpaul>
dvdk: sorry i mean wire hw-boot pins to a convinient button
<dvdk>
wpwrak: have you ever tried what happens if you powerd down cf or ssds during use?
<dvdk>
kristianpaul: ah
<wpwrak>
(usb boot) might be interesting to just wire up U such that it connect to this selection pin by hardware. wouldn't be bullet-proof, but probably sufficient
<dvdk>
wpwrak: irrepairable inconsistencies, no reformat possible :(
<dvdk>
wpwrak: the KI button is unused, currently, afaik
<kristianpaul>
wpwrak: ah you mean wire the hw-boot pinds to a pad in the keyboard?
<kristianpaul>
s/pinds/pins
<wpwrak>
dvdk: (power down flash) so what exactly happens ? and how often does it happen ? flash memory gets powered down in mid-access all the time. yet you hear relatively little about catastrophic failure.
<wpwrak>
kristianpaul: perhaps with some logic gates, yes
<dvdk>
wpwrak: bad engineering by whoever wrote the cf/ssd internal firmware :)
<kristianpaul>
wpwrak: yeah that will be cool
<kristianpaul>
wpwrak: ah wait, you did that with the idbg i remenber now !
<kristianpaul>
of course thats other part that may be bricked too, so is trusty the button + logic arrange
<wpwrak>
kristianpaul: idbg takes a different approach. there, you simply control the BOOT_SEL1 pin from the host
<wpwrak>
dvdk: it would be good to have some experimental data for the effect of power interruption with modern flash devices. i suspect that a lot of the horror stories are quite exaggerated.
<dvdk>
wpwrak: colleague told me that no cf card they tried survived constant (1/min) power cycling for more than a day or something
<dvdk>
gotta go
<dvdk>
cu
<bartbes>
qtopia?
<bartbes>
or opie, for that matter
<bartbes>
actually, it seems it has an openembedded recipe
<bartbes>
so I guess jlime can already run it
<wpwrak>
kristianpaul: assuming the matix is scanned with active row = L, inactive rows = Z, you could implement is with a few pull-ups and a circuit that does this: http://pastebin.com/mtXibTeh
<wpwrak>
kristianpaul: (Q) is internal "memory". doesn't need to be accessible on the outside
<wpwrak>
kristianpaul: nRST would be the system-wide active-low reset (RESETP_N), KO7I would be PC16 from the CPU, KO7O would be KEYOUT7 on the keyboard matrix
<wpwrak>
actually, we can simplify this a little ...
<wpwrak>
note that KEYOUT7 and Qi+1 have the same state. with A = L, and B = Z
<kristianpaul>
wpwrak: in wich datasheet page is PC16?
<kristianpaul>
found it
<kristianpaul>
wpwrak: i was thinking some mechanism that fire usboot when usb_minib connector is pluged
<wpwrak>
that's cheating. too simple !!!!
<kristianpaul>
:D
<Jay7>
hm.. another man in ML talking about making phone :)
<wpwrak>
kristianpaul: connect USBDET to BOOT_SEL1 and you're done
<kristianpaul>
ah wait, i dint knew it about USBDET
<wpwrak>
completely unacceptable. there's not even a chance for obscure glitches and race conditions in this approach. what's left to debug then ? all the engineers will go hungry !
<wpwrak>
well, one disadvantage would be that you probably also trigger it on a software reset. that wouldn't be so nice.
<kristianpaul>
delay-reset chips are common those days too :)
<wpwrak>
larsc: may i bother you with some trivia ? when you reboot the kernel, does it use a proper chip reset (watchdog ?) or something that doens't send the chip through its internal reset process ?
<larsc>
it uses the watchdog
<larsc>
with timeout 0 seconds
<wpwrak>
larsc: thanks. so kristianpaul's approach would get you into usbboot after /sbin/reboot
<wpwrak>
phew. still some engineering left to do then :)
<wpwrak>
a latch would probably be enough, though. clock in USBDET on reset L->H
<kristianpaul>
so you still like my approach? :')
<wpwrak>
i.e., some 741G79
<wpwrak>
kristianpaul: i hate the approach
<wpwrak>
kristianpaul: because i didn't have the idea !
<kristianpaul>
hahaah xD
<wpwrak>
oh wait. there's another problem
<wpwrak>
you also end up in usbboot if you want to power up from usb in general
<kristianpaul>
yes
<kristianpaul>
i knew that
<kristianpaul>
but, well.. who really want to do that if is not for usbboot mode?
<wpwrak>
i start my bens like this all the time
<kristianpaul>
surelly some very specific scenarios
<kristianpaul>
you dont count ;)
<wpwrak>
grmbl :)
<wpwrak>
what would work is if you sample USBDET only when the reset button is pressed. but then you race with the master reset logic, which would still have to be triggered by the system reset
<wpwrak>
you could solve this by combining RESETK and RESETP_N in a gate, not with a wired AND.
<wpwrak>
so we return to needing two gates. one to latch USBDET, the other to separate the reset sources
<kristianpaul>
:-|
<kristianpaul>
if we dont use USBDET and just a logic that power-up from vusb? or a signal from charge battery when vusb is detected?
<kristianpaul>
or instead, a signal fired when no-battery is present
<wpwrak>
that doesn't seem to solve the problem that usb power may be present during normal use and also for normal power-up
<wpwrak>
however, here's another idea: dual-use the reset button. short press = reset, long press = reset to usbboot
<wpwrak>
you could accomplish this simply by putting an RC pair between RESETK and RESETP_N, plus connecting RESETK to BOOT_SEL1
<wpwrak>
the RC (parallel) pair would deliver the reset pulse. if you keep on pressing RESETK, the cap recharges. if you release RESETK, it would deliver a positive surge, though. not sure if this is a problem or if it will be just consumed by clamp diodes.
<wpwrak>
if it's an issue, use a monoflop
<kristianpaul>
i like RC idea
<wpwrak>
a diode would solve the surge problem. so, R+C+D :)
<kristianpaul>
Linux fans... thats bad thing i think, as all you can wait from fans :-/
<kristianpaul>
They just will swich to the next incartation of linux and something..
<viric>
kristianpaul: ?
<rjeffries>
Sundays are SLOOOOW here. where are your priorities, people?
<dvdk>
wpwrak: why not just connect one of the normal keyboard keys to the boot_sel pin?  when booted up, reconfigure the I/O as a gpio for keyboard function, at reset it again becomes the boot_sel pin.
<dvdk>
to prevent accidental use, you could use one of the F1-F8 keys, or some other  key that is otherwise seldomly used
<wpwrak>
dvdk: bah, yet another lamely simple suggestion. where's the engineering spirit gone ? :)
<dvdk>
is thinking how to complicate things more
<dvdk>
btw the wikireader has a nice power/reset circuit: short keypress for power-on, long keypress for power-down
<dvdk>
(completely in hardware)
<dvdk>
wpwrak: wire the mircophone input to the boot_sel pin.  then provided pre-recorded audio that triggers the correct usb-boot sequence :)
<wpwrak>
dvdk: like whistling a 1024 bit pseudo-random sequence ?
<dvdk>
wpwrak: you got it.  still too simple?
<kristianpaul>
prn? what? no !
<kristianpaul>
;)
<kristianpaul>
hey, actually i tought in taking advantage of the mechanical swich of headset input
<dvdk>
btw wrt UBI initialization: can't we just make the physical blocks larger (i.e. by combining 2 or 4 physical erase-blocks into 1 logical erase block?)
<dvdk>
this should decrease UBI initialization by factor 2 or 4
<dvdk>
also they claim that "a 1GiB NAND flash found in OLPC XO-1 devices is attached for about 2 seconds; "
<wpwrak>
dvdk: (1024 bit prs) the distributors could then sell trained birds to trigger usbboot ;)
<kristianpaul>
lol
<dvdk>
wpwrak: let's make whisteling seminars
<wpwrak>
dvdk: (ubifs) their nand may be faster than ours
<wpwrak>
rejon: phew. a voice of reason on the list. thanks.
<rejon>
wpwrak :)
<kristianpaul>
rejon: indeed :)
<rejon>
who got some scrilla to get realla
<wpwrak>
aah ! of course my usb protocol decoder can't make sense of the data ! in invert, so SE0 becomes SE1. grr.
<wpwrak>
okay. NOW i'm properly armed ;-)
<qwebirc33973>
hello everybody !!!
<qwebirc33973>
just wanted to ask if anybody has some answers regarding the future developement of nanonote ...? is this a proper place for this question ?
<kristianpaul>
Copyleft hardware - time is on our side | public logging at http://en.qi-hardware.com/irclogs | Welcome and please ask your questions...
<kristianpaul>
topic^
<mstevens>
would be interested to know about the future of nanonote also
<qwebirc33973>
well, thanks @kristianpaul ... that's a lot of reading ... but for now just wanted to know if there are going to be any other Ben variants, like a Ben notebook (just a bigger screen), or a tablet Ben ? i would want to buy open source hardware, but i need to be able to use it somehow. By now, i can't seem to find a use for the nanonote. So... any other Ben variants based on the same hardware ?
<kristianpaul>
qwebirc33973: afaik i cant promess yoy anything else beyond what is right now
<kristianpaul>
s/yoy/you
<kristianpaul>
qwebirc33973: What you dint found in the nanonote that you're looking for?
<qwebirc33973>
well... i can't use it
<kristianpaul>
You can use the Ben nanonote as it is right, now, some people listen music, other load maps on it, or take notes, or do some gaming
<kristianpaul>
yeah sure i understand that, but why?, feedback is good :-)
<qwebirc33973>
i am not a hardware enthusiast, nor an electronic one. I can't use it, i need a bigger screen
<qwebirc33973>
sory for my latency in typing
<kristianpaul>
oh, i see, so nanonote is not for you
<qwebirc33973>
i'm sorry, but in it's form righ now, is not for me. I would really like it if it had a bigger screen. Is there anything that we can do towards this direction ? a bigger Ben nanonote ?
<kristianpaul>
Support the project buying one, that will help on future develoments
<qwebirc33973>
yes ... i know that's how it works, i am well aware. BUT, what would it take to develop a bigger one ?
<kristianpaul>
I dont know, thats something that works on demand you know
<qwebirc33973>
yes... well , is there anybody interested in something similar? can a poll or something be done somewhere ?
<wpwrak>
qwebirc33973: it would take quite a bit of time and money.the idea is to keep the form factor for a while while advancing the rest of the technology (and infrastructure)
<qwebirc33973>
that sounds perfectly sane, but a bigger screen , i think, will bring more supporters, since it has a bigger degre of usability , like office use ...
<wpwrak>
qwebirc33973: it would also lose one rather distinguishing feature. also, in a small device, low specs are easier to forgive
<wpwrak>
qwebirc33973: e.g., would you buy it if it just had a bigger screen ? but the same cpu, connectivity, memory, etc. ?
<qwebirc33973>
yes , I would, is exactly what i am looking for
<kristianpaul>
There is a ereader that uses a xbusrt chip, and i think i saw it supported on the openwrt tree, larsc ?
<wpwrak>
qwebirc33973: so the absence of usb host, wifi, would not matter ? also, would "bigger screen" mean only a larger physical size or also more pixels ?
<qwebirc33973>
:) why would i want bigger pixels ? yes i think we need a screen variant with more pixels , something like 1024x600. wifi would not bother me too much. But i think a wired network could be useful, and easier to implement (this is just an opinion)
<wpwrak>
qwebirc33973: 1024*600 would mean an 8x higher memory bandwidth used for graphics. also, most graphics operations would take ~4-8x longer. so the machine would be quite slow.
<qwebirc33973>
and about low specs, i don't think you need bigger specs to read pdf, and write rich text documents
<wpwrak>
qwebirc33973: also, you'd run out of memory much quicker, because any application that actually uses that many pixels would need ~8x as much memory for them
<qwebirc33973>
well , that makes sense
<wpwrak>
qwebirc33973: so you would have a machine with a large screen but that's extremely slow otherwise. would that still be attractive ?
<qwebirc33973>
i'm guessing it should have somethig like 128 ram or something ? or more ?
<wpwrak>
qwebirc33973: i think what you're looking for is a machine in a different class of hardware. sort of a tablet, with faster cpu, more memory, more connectivity options, etc.
<wpwrak>
qwebirc33973: the problem with higher-spec machines is that a) the components get harder to obtain, b) the development cost is higher (r&d cost and also the initial investment into the first production run). who finances product that may need an investment of USD 1-2M ?
<kuribas>
What's the maximum speed for the usb port (at constant rate)?
<wpwrak>
qwebirc33973: also, by positioning it as a tablet, it competes directly with companies that produce in large volumes. so it the feature/cost ratio would be bad.
<wpwrak>
kuribas: speed doing what ? :)
<kuribas>
Recording musuc :)
<kuribas>
music
<wpwrak>
kuribas: hmm .. so the ben would act as an audio-over-usb device ?
<kuribas>
yes!
<wpwrak>
kuribas: i mean from the point of view of USB communication. there's some audio class for USB
<wpwrak>
kuribas: but i don't know it we have gadget support for this in linux
<kuribas>
usb 2.0 should be capable of high speed, right?
<qwebirc33973>
@wpwrak , you are killing my enthusiasm. This type of hardware, i think, has a user base wich relies on principles rather than actual spec/price ratios. I just wanted to know how much would it take to put a 10'' screen on the nanonote, because this is what i would support, with money (donation, buyng in advance, maybe a fundraising?) .
<wpwrak>
kuribas: the ben should be usb 2.0 high-speed capable, yes
<wpwrak>
qwebirc33973: heh, i just bring up the inconvenient facts that make this less straightforward than it may seem :)
<kuribas>
Cool.  I'll need at least 1.4 mbps for 44.1kHz * 16bit.  Prefarable 4.6 mbps for 96kHz * 24 bit.
<wpwrak>
kuribas: sounds manageable. even full-speed (USB 1 or 2) could deliver that
<qwebirc33973>
@wpwrak  well... i see ... but in your opinion, 128mb ram and a 10'' , are doable ? (or does this implies other changes)
<wpwrak>
qwebirc33973: almost everything is "doable". the main problem would be financing. if you can bring some potent investor to the project, that would open a lot of doors
<wpwrak>
qwebirc33973: e.g., if you want a display that's on par with current tablets, you'd compete with apple, samsung, hp, etc., for the attention of display manufacturers
<wpwrak>
qwebirc33973: this kind of items isn't something that just build and send to supermarkets. they're usually built to order. and if they have customers who buy hundreds of thousand units, it will be difficult for you to get in an order for only a few thousand.
<wpwrak>
qwebirc33973: also, you need to pay in advance. same for the rest of the device. chips and all that. if you need a better cpu, you need to establish contacts at companies that make such cpus. if you need a type of ram that's in demand, it's the same.
<wpwrak>
qwebirc33973: even if the companies like you very much and don't mind working with you even for small quantities, you'll spend quite a lot of time just in meetings.
<wpwrak>
qwebirc33973: by the way, there is another device in the qi-hw universe, completely different from the ben. it's the milkymist vj station. it's an even more radical design - the entire cpu core is open, implemented on an fpga.
<wpwrak>
qwebirc33973: it's designed for audiovisual effects (video in/out, etc.), but there of course other things you could do with it as well
<wpwrak>
qwebirc33973: regarding the performance of the ben base hardware, you could relatively easily double the memory bandwidth. beyond that, a major design effort would be needed.
<wpwrak>
qwebirc33973: clock speed would stay in the same range, 360 MHz maximum. usb host (full-speed, not high speed) would be possible in a redesign.
<qwebirc33973>
i'm not the enemy here. I really want to help, but it seems is out of my reach... for now. I really need to sleep right now but i will be back on this topic...  Thx you for your answers @wpwrak and @kristianpaul , and keep up the good work !!! (maybe tomorrow i'll manage to change my id/nick :) )  thx again bye bye
<wpwrak>
qwebirc33973: you would need to find ~2000-5000 potential buyers to obtain good prices. if the number is smaller, the prices multiply. the cost making small numbers is almost constant, so if you, say, only have 1000 potentual buyers,
<wpwrak>
qwebirc33973: the price would be 2-4 times than what you'd get with the larger numbers
<wpwrak>
qwebirc33973: (not the enemy) hehe ;-) naw, it's just very common to have overly optimistic assumptions about what is involved in making hardware. but don't let that kill the enthusiasm. there are ways where you can still accomplish things, you just have to choose your battles carefully :)
<kristianpaul>
qwebirc33973: /nick you_nick
<kristianpaul>
zamox: : agree with wpwrak, your questions are very common, and you should be aware of the situation for that demand
<wpwrak>
whee, welcome zamox ! :)
<wpwrak>
kristianpaul: now that we know his name, we control his soul, right ? :)
<kristianpaul>
wpwrak: :-D
<zamox>
thank you all :) , i'll be back tomorrow  :) ... a good night to everyone who is actually in the night, a good day otherwise ! :) bye
<kristianpaul>
romania, interesting
<wpwrak>
loves his scope with deep memory. DIY USB decoding is fun :)