1 files changed, 995 insertions, 0 deletions

diff --git a/www/irc/rockbox-20020610.log b/www/irc/rockbox-20020610.log
new file mode 100644
index 0000000000..4f97e91bd4
--- /dev/null
+++ b/www/irc/rockbox-20020610.log
@@ -0,0 +1,995 @@
+**** BEGIN LOGGING AT Sun Jun  9 19:13:53 2002
+
+-->     adiamas (~adiamas@as5300-9.216-194-23-77.nyc.ny.metconnect.net) has joined #rockbox
+---     Topic for #rockbox is Version 1.0 released! http://bjorn.haxx.se/rockbox/
+---     Topic for #rockbox set by adi|home at Tue Jun  4 04:41:56
+-->     motiv01 (~trillian@sdn-ar-001ncraleP205.dialsprint.net) has joined #rockbox
+-->     adam (~adam@c-24-118-162-179.mn.client2.attbi.com) has joined #rockbox
+<adam>  lo.
+<adam>  Thomas Detert - Clystron (title)
+-->     g003y2 (~foo@m198-187.dsl.rawbw.com) has joined #rockbox
+<adam>  hey
+<adam>  http://c64.org/radio/
+<adam>  == incredible
+<adiamas>       ok.. what is it?
+<adam>  heh
+<adam>  streaming radio of weird c64 remixes
+<adam>  my favs are the Clystron ones
+<adam>  which, I'll stream right now
+<adam>  http://rei.damnsw.net:8000
+<PsycoXul>      i should setup my c64 to be a kindof instrument
+<adam>  heh
+<adam>  Finally it gets a little cooler out here.
+<adam>  and I don't think my stupid id3 streaming is working
+<adam>  hmm, anyone know of a good cartoonish icon for the Archos jukebox?
+<miah>  sidstation!
+*       adam isn't using KDE or GNOME albeit uh
+<adam>  If there isn't one, I might as well make one :P
+<miah>  the sidstation rules all music devices
+<adam>  heh
+<--     g003y2 (~foo@m198-187.dsl.rawbw.com) has left #rockbox
+<adam>  fear sid
+<PsycoXul>      whats this sidstation
+<adam>  heh
+<miah>  let google be your friend
+<adam>  ahh, anne is listening to my stream
+*       adam is impressed :P
+<PsycoXul>      bah i didn't say i wanted to buy anything
+<PsycoXul>      i said i should setup shit i already got to do new things :p
+<adam>  BUT YOU KNOW YOU WANT IT!
+<PsycoXul>      naah
+<adam>  heh
+<PsycoXul>      if i'm gonna play with a synthesizer that i don't already have
+<PsycoXul>      i'm gonna make my own :p
+<adam>  indeed
+<PsycoXul>      i'd rather make my own non-electronic instrument though
+<PsycoXul>      that somehow uses magnetism and resonance conditions for suprising self-amplification
+<PsycoXul>      or somesuch :p
+*       adam will get a bottle
+<adam>  that uses the power of wind
+<PsycoXul>      heh
+<adam>  damnit
+<PsycoXul>      i was thinking something stringed
+<adam>  ants trying to get my beer
+<adam>  ants rock :p
+<adam>  efficient little creaturse
+<adam>  ...
+<PsycoXul>      either that or something that uses things no instruments have as-of-yet utilized for sound creation :p
+<PsycoXul>      heh
+<PsycoXul>      yeah life is weird stuff
+<adam>  heh
+<PsycoXul>      and if you talk to the scientists these days you'd get the impression that life isn't possible :p
+<adam>  heh
+<adam>  would a self replicating robot be too hard to make?
+<adam>  :P
+<PsycoXul>      to hell with self replicating
+*       adam notes his room is too warm
+<PsycoXul>      i'd just like any kind of machine that can not only perform useful work, but also mantain itself, and gather energy for itself, without any need for further user interaction once operational
+*       adam would like intelligent ants
+<adam>  :P
+<adam>  sapient bugs, yeah
+<PsycoXul>      you know, if we could tap into the same principles life itself runs on, we'd have no need for batteries or generators 
+<PsycoXul>      we'd have ourselves a nifty little overunity device :p
+<adam>  like photosynthesis? ;p
+<PsycoXul>      or how about the principles that atoms run on
+<PsycoXul>      they do run, afterall :p
+<adam>  heh
+<adam>  *shrugs*
+<PsycoXul>      it takes a tremendous amount of energy just for a piece of matter to exist
+<adam>  sometimes I'd just like to see it all fall down ;p
+<PsycoXul>      yeah well it'll do that
+<PsycoXul>      because once i build my technology on these principles, i'm not gonna share it.. i'll just take it and leave, and watch the commets hit some years later ... 
+<adam>  heh.
+*       PsycoXul laughs maniacally
+*       adam in turn will live in the wilderness
+<adam>  with bicycle powered electronics
+<adam>  :P
+<PsycoXul>      bah. electronics
+<PsycoXul>      primitive utilization of subatomic forces
+<adam>  indeed
+<adam>  cheap, too
+<adam>  :p
+<PsycoXul>      its too convoluted and inefficient
+<adam>  it works fine for me
+<adam>  ;)
+<adam>  of course, I'm not an evil genius
+<PsycoXul>      i've aquired a distaste of digital abstraction
+<PsycoXul>      its like a cheap and super-lossy vague ghost of what the data represents
+<PsycoXul>      its only lossless between itself since it's discrete packets of information that can be easily be recognized by our primitive techniques
+<adam>  and here is my great ant running around
+<adam>  she searches for food.
+<adam>  :P
+<PsycoXul>      yeah man
+*       adam will aquire a fondness for air conditioning
+<PsycoXul>      i want a computer that'll go out and find its own electricity :p
+<PsycoXul>      but not a computer and not electricity
+<PsycoXul>      but thats the idea you know :p
+<PsycoXul>      bbl dinner and stuff
+<adam>  heh
+*       adam will go take his beast for a walk
+<adam>  later
+<adam>  "I eated them purple berries and I feel fun"
+*       adam returns
+-->     elinenbe (trilluser@bgp01080511bgs.wanarb01.mi.comcast.net) has joined #rockbox
+<--     adam has quit (Read error: 104 (Connection reset by peer))
+-->     adam (~adam@c-24-118-162-179.mn.client2.attbi.com) has joined #rockbox
+*       adam sets up the gopher
+---     dw|weekend is now known as dwihno
+<dwihno>        Good morning people
+<adam>  hey
+*       adam notes gopher is completely useless when he is running apache on the same box
+<adam>  of course
+<adam>  it doesn't hurt to run it ;p
+*       dwihno hasn't been using any gopher stuff in ages
+<adam>  yeah, I'm going back in time, man
+<dwihno>        Timewarp! :O
+<dwihno>        I'm catching up on the email I got this wekend
+<dwihno>        I read about Linus getting past the ata: -5 error stage
+<dwihno>        (which is great for the development)
+*       adam preens his dirs
+*       dwihno yawns like crazy
+<dwihno>        2 new e-mails
+<dwihno>        I bet it's regarding me not getting any jobs ;)
+*       adam notes he should probably be heading out
+<adam>  g'night
+<--     adam has quit ("[BX] Tickle-Me Elmo uses BitchX. *giggle* *giggle* *giggle*")
+-->     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+*       Bagder committs
+*       dwihno yells
+<Bagder>        ... and we're now "OK" on 7 builds out of 9 ;-)
+<Bagder>        7 of 9... hm
+<dwihno>        yay
+<Bagder>        isn't that Start Trek? ;-)
+<Bagder>        -t
+<dwihno>        hehe
+<dwihno>        you are gay
+<dwihno>        You need to get out more often
+<Bagder>        but I don't have any 802.11 ! ;-)
+<adiamas>       okay.. was gonna hang out.. but the us-china game is on.. time to curl into bed and watch some soccer/futball
+<adiamas>       night all
+---     You are now known as adi|home
+<Bagder>        night adi|home
+<Bagder>        dwihno: you tried the latest rockbox on your recorder yet?
+<dwihno>        Bagder: not really... I'm always afraid of having the disk locked :)
+<Bagder>        chicken ;-)
+<dwihno>        blahblahblah
+<Bagder>        hehe
+<dwihno>        I'm waiting for more functionality! Like mp3 decoding, playlist etc. :)
+<Bagder>        yeah, it makes more sense when it can play those mp3s ;-)
+<dwihno>        yeah
+<dwihno>        but I'll try it as soon as the file transfers are done
+<dwihno>        I need to upgrade my player
+<dwihno>        (as in recorder)
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+-->     Zagor (~bjst@labb.contactor.se) has joined #rockbox
+<Linus> moo!
+<Bagder>        hey fellas
+<dwihno>        20 gb is not enough for both data and music
+<dwihno>        hello L and Z
+<Zagor> hi
+<Bagder>        we are down to "OK" on seven builds now
+<dwihno>        seven of nine star trek blahblahblah ;)
+<Linus> Zagor: I guess we are still mentally connected :-)
+<Zagor> yup :)
+<Zagor> Bagder: neato. warn-kill session this weekend?
+<Bagder>        Zagor: me and Linus did most of them on last friday
+<Linus> Mostly this friday
+<Bagder>        I did the the two final ones this morning
+<Bagder>        only chartable.c warnings left 
+<Linus> Tha table was so ugly with all those warnings
+<Zagor> my phone broke this weekend, so I haven't been able to read the mail SMSs
+<Bagder>        it broke?
+<Linus> display again?
+<Zagor> yeah, somehow. everything works, execept reading SMS...
+<Linus> ????
+<Bagder>        hehe
+<Bagder>        worn out ;-)
+<Bagder>        "too many SMS error"
+<Linus> Don't have it in your back pocket! :-)
+<Bagder>        "you've reached the maximum number of SMS"
+<Zagor> Linus: yes, but it's triggered by reading SMS. very strange. the screen goes blank, yet everything still works.
+<Linus> VIRUS!!!!
+<Bagder>        klez!
+<Zagor> hehe
+*       Bagder chuckles
+<Linus> I sent you an SMS full of CLS characters this friday.
+<Linus> :-)
+<Zagor> :)
+<Linus> I have given tha ATA problem a thought this weekend
+<Zagor> I don't want it to break now, there's no good phones out yet :)
+<Zagor> Linus: any result?
+<Linus> Is it possible that Andrew (or whoever it was that drew the Recorder sheets) has a Recorder10?
+<dwihno>        Yeah, I read the mailing list entry about the ATA stuffs0r
+<Zagor> Linus: a 10 or also a base "no-number" recorder
+<Linus> Maybe there are recorders out there that use address 0x300 for ATA CONTROL/ALT_STATUS?
+<Linus> we need to try an older recorder
+<dwihno>        Tell me about the serial mod
+<Linus> dwihno: what do you want to know?
+<dwihno>        How hard is it to do, and what do you basically do?
+<Zagor> dwihno: it's described on the web page
+<Linus> but only for the Player
+<Zagor> right
+<Linus> we connect serial port 1 to the line In jack
+<Linus> that way we can connect a gdb debugger
+<dwihno>        ah
+<dwihno>        <-- is newbie lamer stuff dude
+<Linus> :-)
+<dwihno>        I MUST upgrade my recorder with a 40 gig disk... I just realized that
+<Linus> Zagor: why do we need two leading // in a filename in the root
+<dwihno>        60 is too expensive
+<Zagor> Linus: do we? not on purpose, anyway
+<Linus> I tried the playlist code last friday
+<Linus> id didn't add any slashes at all, so i added one
+<Linus> and it still didn't work
+<Linus> with one slash it said "must be absolute path"
+<Zagor> odd
+<Linus> with two, it didn't find the file
+<Linus> sorry, that last thing was wrong
+<Linus> let me start over:
+<Zagor> add DEBUGF() for the opens. sine files can be opened in the root, I suspect the problem is in the playlist code rather than the file code
+<Linus> no slash: "must be absolute"
+<Linus> one slash: "file not found"
+<Linus> the file names are sent with two slashes to the mpeg thread by the dir browser as well
+<Zagor> ok, very strange
+<dwihno>        smells like pointer problenm
+<Zagor> not likely
+*       dwihno points his finger to the skies!
+<dwihno>        "IT'S A PLANE! NO, IT'S A BIRD! NO... IT'S... ZAGOR!"
+<dwihno>        Something funny to do on a rainy day: Defrag the archos over an USB 1.1 interface ;)
+*       PsycoXul wouldn't defrag his archos
+<dwihno>        heh
+<dwihno>        of course you would
+<dwihno>        The designers of the archos should have chosen a wider LCD
+<Linus> that would have been nice
+<Bagder>        yes, in colour
+<Bagder>        4"
+<Bagder>        ;*)
+<Zagor> except there's no room :)
+<Bagder>        touch screen
+<Linus> Bagder: why does the dir browser have two leading slashes in the file name when selecting a file in the root?
+<Bagder>        because it is silly?
+<Linus> maybe. i didn't think of that
+<Zagor> Linus: it's a bug, naturally
+<webmind>       isn't it a feature ?
+<dwihno>        Zagor: There is always room! :)
+<Linus> Bagder: hehe. look at the BUTTON_PLAY case in tree.c
+<Linus> that 'if' doesn't do much difference, does it? :-)
+<Linus> wait.
+<Linus> it does.
+<Linus> i am silly
+<Zagor> i know :)
+<Linus> ah! playtune() adds an extra slash
+<Zagor> aha
+<Zagor> silly code
+<Zagor> ahh, mail scan complete :)
+<Zagor> did anyone ever see code from the guy who worked on the scroller?
+<Bagder>        'playing' should be remade to be an enum for "play mode"
+<Bagder>        Zagor: he mailed it to Linus
+<Linus> I have it
+<Zagor> ok. can you send it to me? I'd like to get this working today
+<Linus> roger that
+<Zagor> Bagder: can we get some kind of "tick hook" in the simulator?
+<Bagder>        "tick hook"?
+<Zagor> yes, a periodic execution of a routine
+<Zagor> so we can get scrolling in the simulator, too
+<Bagder>        I'd prefer having "thread support"
+<Linus> can we change the playtune API to have just a full path instead of dir and name?
+<Bagder>        using setjmp/longjmp
+<Zagor> Linus: fine with me
+<Zagor> Bagder: but the thread switches aren't periodic. scrolling will look horrible if done in a thread :)
+<Bagder>        hm
+<Linus> Zagor: we can't do lcd updates in an interrupt anyway
+<Bagder>        well we could have a simulated timer tick using pthreads I guess
+<Zagor> Linus: no? we do it in UIE
+<Linus> imagine an lcd update being interrupted
+<Zagor> fine, so we mutex it
+*       Bagder gets scared
+<Zagor> uh, no
+<Zagor> bugger...
+<Linus> mutexes and interrupts don't work
+<Zagor> i know
+<Zagor> so what do we do? any bright ideas?
+<Linus> we have to do it in a separate thread
+<Zagor> we can try doing it in a thread and see how bad it looks. maybe i'm exaggerating the horridness
+<Linus> Zagor: i share your fear
+<Zagor> we'll just have to find out
+<Zagor> Bagder: do you have time to work in threading for the simulator?
+<Zagor> s/in/on
+<Bagder>        I'll see what I can do
+<Bagder>        fixed the dreaded bug now, may get time to do this today
+<Zagor> which bug was that?
+<Zagor> ah, at work?
+<Bagder>        yeah
+<Bagder>        very amusing one, I'll tell you one day ;-)
+<Bagder>        in short: when you use malloc() to allocate memory for your custom memory functions, don't do free(-1) when that thread terminates ;*)
+<Bagder>        (in pSOS)
+<Zagor> hehe
+<Bagder>        since we have certain parts using the standard malloc() too
+<Bagder>        we started getting random crashes all over when the same memory was handed out...
+<Zagor> ooh, nice
+<Bagder>        yeah, took a good while to narrow down
+-->     alkorr (alkorr@srs03v-8-217.n.club-internet.fr) has joined #rockbox
+<alkorr>        yo
+<Bagder>        howdy
+<Zagor> hi alan
+<Bagder>        I think perhaps we shuld go with pthreads all the way for threads in the simulator
+<Bagder>        and use mutex or similar to have only one run at a time
+<Zagor> sounds good to me
+<Bagder>        of course it'll make the scheduling different, but I figure we can live with that
+<Linus> hi alan
+<Zagor> Bagder: yes, we shouldn't be counting on the scheduling behaving in any specific way
+<Bagder>        right
+<Linus> Zagor: except that it isn't premptive
+<Linus> preemptive
+<Bagder>        right, we'll have to enforce that
+<Zagor> right
+<Bagder>        yield will return a mutex and then attempt to get it again
+<Linus> damn. the keys are bouncing on my Player
+<Zagor> good
+<alkorr>        what's the trouble ?
+<Linus> i think we need some kind of debouncing after all
+<alkorr>        if you don't want to poll
+<alkorr>        you can use one of 5 timers
+<Linus> we poll today
+<alkorr>        first polling
+<alkorr>        start timer
+<alkorr>        at the end of timer, polling again to check
+<alkorr>        if no change, okay
+<alkorr>        if yes restart
+<Zagor> easier to just add debouncing to the current code, i think
+<alkorr>        where it occurs this debouncing ?
+<alkorr>        oh quite now i have some difficult to compile rockbox
+<alkorr>        are you really sure of removing all dependencies ?
+<alkorr>        i mean like stdlib.h, etc.
+<Zagor> no, we still need some newlib header files
+<Linus> no we haven't
+<Zagor> i intend to fix that
+<alkorr>        i would like to change the way to handle adc so we can scan the 8 all analogic pins
+<alkorr>        but not before a working rockbox
+<alkorr>        by the way, i saw you only read 8bits instead of 10bits
+<alkorr>        maybe for the keyboard it is sufficient
+<alkorr>        but for batteries level or external power ?
+<Linus> maybe 10 bits is better for that, yes
+<Zagor> 8 bits should be enough for anybody ;)
+<Linus> actually, i haven't done any research on where the other A/D inputs go
+<Linus> the player schematics show nothing
+<alkorr>        it is why it could be interesting to investigate via software
+<Linus> but i assume that at least the battery voltage measurements use the A/D
+<Linus> alkorr: good project
+<alkorr>        so we can see any variation on one of 8 analogic pins when plugging on or off anything
+<Linus> Zagor: go ahead and remove the libc header dependencies
+<Linus> BTW, is it possible to compile gcc without any libc at all?
+<alkorr>        as you code it, i'm unsure
+<Zagor> i tried last week, and failed on some asm code
+<Linus> or does it default to glibc?
+<Linus> asm code?
+<alkorr>        no libc and glibc is different
+<alkorr>        yes
+<alkorr>        just an explanation
+<alkorr>        when you are doing C shift operation
+<alkorr>        if I remember well
+<Zagor> Linus: yes, i'll run it again and paste the error
+<alkorr>        like : i is int => i >>= 3; will call a libc shift function
+<Bagder>        libgcc, yes
+<Zagor> /home/linus/cross_sh1/gcc-3.0.4/gcc/config/sh/lib1funcs.asm: /tmp/cc7nk38J.s:47: Error: no such instruction: `rotcl r4'
+<alkorr>        if the sign doesn't matter, you must turn into (unsigned)i >>= 3 to have the opcode instaed of a external function
+<alkorr>        add -m1 ?
+<Linus> alkorr: glibc and libgcc aren't the same, are they?
+<alkorr>        equally true for multiple and divide
+<Linus> i thought glibc and newlib did the same job
+<Linus> and that libgcc did what you describe
+<alkorr>        exactly
+<alkorr>        libgcc provides some standard operation that cpu has not
+<Linus> so glibc is a gnu implementation of libc
+<alkorr>        okay, i mean glibc is not libgcc
+<Linus> and newlib is another
+<alkorr>        newlib is like a light glibc, i think
+<Linus> libgcc is built anyway, regardless of newlib or glibc
+<alkorr>        exactly
+<Linus> so, back to my question:
+<alkorr>        so don't worry about
+<alkorr>        because mine is working
+<Linus> can you build a gcc without any libc at all?
+<Linus> ok good!
+<Linus> so you don't have any linc at all?
+<Linus> libc
+<alkorr>        I only have trouble with newlib
+<alkorr>        never tried it
+<alkorr>        i don't think so
+<alkorr>        i must have it !
+<alkorr>        wait !
+<alkorr>        libc : i must have it
+<alkorr>        newlib : cannot compile it
+<alkorr>        anyway, because you have some operators in C which can be turned into CPU opcodes, they call a function from libc
+<alkorr>        so i think libgcc cannot be removed
+<alkorr>        anyway, if you code trying to avoid to use operators or functions which uses libc
+<alkorr>        your final code would keep nothing from libc.
+<alkorr>        so it isn't a trouble for us
+<alkorr>        anyway, because you have some operators in C which CANNOT be turned into CPU opcodes, they call a function from libc
+<alkorr>        i'm an forever optimist :)
+<Bagder>        we don't compile with libc today, so no we don't need it
+<Bagder>        libgcc we need however
+-->     alan (alkorr@srs07v-6-45.n.club-internet.fr) has joined #rockbox
+<alan>  sh*t ! i did not have time to read until i was disconnected
+<Linus> Bagder: i know, but i figured gcc wanted *some* kind of libc
+<alan>  what's the trouble with libc ???
+<Bagder>        Linus: nope
+<alan>  it only depends on what you need
+<alan>  int divide (int a,int b) { return a / b; }
+<alan>  ==>
+<alan>          .type   _divide,@function
+<alan>  _divide:
+<alan>          mov.l   .L2,r0
+<alan>          sts.l   pr,@-r15
+<alan>          jsr     @r0
+<alan>          nop
+<alan>          lds.l   @r15+,pr
+<alan>          rts
+<alan>          nop
+<alan>  .L3:
+<alan>          .align 2
+<alan>  .L2:
+<alan>          .long   ___sdivsi3
+<Bagder>        that's in libgcc, not libc
+<alan>  ah yes
+<alan>  sorry
+<alan>  i thought you were speaking about libgcc
+<Bagder>        we still link with libgcc
+<alan>  so you are speakink about libc and libm ?
+<Bagder>        Linus asked about libc
+<alan>  did you try without libc or libm ?
+<Bagder>        we don't link with them
+<Bagder>        so yes
+<alan>  when compiling i mean
+<alan>  because i'm quite sceptical
+<Bagder>        about what?
+<alan>  when linking of course
+<alan>  just add -nostdlib
+<alan>  to compile gcc without libc and libm
+<alan>  anyway we can avoid them with -nostdlib
+<alan>  it seems it is what you do in Makefile, am i wrong ?
+<Bagder>        no
+<Bagder>        we don't link with them
+<alan>  so all is better in the world
+<Zagor> have anyone else tried to compile gcc without newlib? i got no comments on my error.
+<alan>  i did
+<alan>  yesterday or yesterday else one
+<alan>  i must do it now ?
+<alan>  which error ?
+<Zagor> no, but I must to it to remove rockbox newlib dependencies
+<Zagor> /home/linus/cross_sh1/gcc-3.0.4/gcc/config/sh/lib1funcs.asm: /tmp/cc7nk38J.s:47: Error: no such instruction: `rotcl r4'
+<alan>  having a look
+<--     alkorr has quit (Read error: 110 (Connection timed out))
+<Linus> how about 3.0.3?
+<Zagor> haven't tried that. will do
+---     Linus is now known as Linus|lunch
+<alan>  i'm having a look on 3.0.3 lib1funcs.asm
+<alan>  see you later
+<--     alan has quit ()
+<dwihno>        ´m
+<dwihno>        Bza0!
+<dwihno>        Should I go for the 2650 or 8200 model of the Inspiron (dell) ?
+<Zagor> beats me
+<Zagor> get their 20" LCD screen, that's all I can say
+<dwihno>        :O
+<Zagor> why can't I gdb the simulator???
+<Bagder>        no idea
+<Bagder>        what happens?
+<Zagor> i doesn't hit any breakpoints, and it can't be stopped.
+<Bagder>        !
+<Zagor> do we really want lcd_putsxy() to wrap? it explicitly does
+<Zagor> lcd_puts() truncates for charcell. the bitmap code should do the same, IMHO
+<Bagder>        I agree
+<Bagder>        wrapping will hardly ever be what anyone would want
+<Zagor> exactly
+<Bagder>        watch my commit
+<Zagor> woo
+<Zagor> tested, I presume?
+<Bagder>        yes
+<dwihno>        I got mail! Yay
+<Zagor> great! I've just finished the scroll code, so this comes in handy
+<Zagor> but we need to talk about scrolling
+<Bagder>        we'll need to yeild() in the simulated I/O code to simulate that better I guess
+<Zagor> how do we want it, anyway? currently I support one line of scrolled text, but we may want to scroll the whole screen. we may also want to smooth-scroll on the recorder, if we can get that not to flicker or blur
+<Zagor> do we want to scroll several lines, independently of each other?
+<Zagor> I have the feeling that will look too chaotic to really be of use
+<Bagder>        I think so too
+---     Linus|lunch is now known as Linus
+<Linus> BTW, I tried the playlist code. It works (after I prepended a slash on the file names).
+<Zagor> nice
+<Zagor> Bagder: maybe init_threads() should be called kernel_init like in target?
+<Zagor> or, umm, they are not exactly the same thing but almost :)
+<Linus> Zagor: there is an init_threads in target
+<Zagor> oh. i
+<Zagor> 'm blind
+<Linus> it's new
+<Zagor> carry on, nothing to see here :)
+<Linus> it was born in the warning hunt last friday
+<Zagor> Linus: should main.c:init() call it, or is it called from somewhere else?
+<Linus> kernel_init() calls it
+<Zagor> ok
+<Zagor> but not we're approaching two separate init()s, one for target and one for simulator.
+<Zagor> maybe not so bad
+<Linus> possibly
+<Linus> as long as the target code doesn't get more complicated just to please the simulator
+<Zagor> Linus: is mpeg_file always open when you press stop?
+<Linus> oops.
+<Zagor> Bagder: the thread API opens up a whole can of worms... sleep() has to be redefined, and I also want a HZ constant I can use... :)
+---     Zagor is now known as Zagor|lunch
+<dwihno>        Does the RPM really make a difference if I would replace the disk in my archos?
+---     Linus is now known as Linus|meeting
+*       Bagder is back
+<Bagder>        Zagor|lunch: now what's wrong with sleep() ?
+<Hadaka>        dwihno: I'd expect RPM to affect the power expenditure
+<dwihno>        Hadaka: Yeah, but the higher RPM should also reduce the time needed to read data to the buffer...
+---     Zagor|lunch is now known as Zagor
+<Zagor> Bagder: unix sleep() is whole-seconds. the firmware sleep is ticks. and I need subsecond sleep for the scroll etc.
+<Bagder>        we already do that
+<Bagder>        uisim/x11/sleep.c
+<Bagder>        it should however return and reget the mutex
+<Zagor> bah. i'm behind again...
+<Zagor> it was me who didn't include kernel.h
+<Bagder>        ah
+<Bagder>        the downside of having identical names
+<Zagor> yup
+<dwihno>        Zagor: What kind of disk did you replace the one in your archos?
+<Zagor> a toshiba 40gig
+<dwihno>        RPM-wise?
+<Zagor> the same as all normal laptop disks: 4200rpm
+<dwihno>        so 5400 is non-standard
+<dwihno>        ?
+<Zagor> yes, 5400 is used on "performance" 2.5-inch drives
+<Zagor> such as the Toshiba 4018 GAX
+<Zagor> I have the Toshiba 4018 GAS
+<Zagor> the GAX uses almost twice as much power for spinup
+<Zagor> or maybe it's the GAP I have. can't remember.
+<dwihno>        oof
+<dwihno>        evil stuff! :/
+-->     ironi (ironi@as2-5-7.j.bonet.se) has joined #rockbox
+<ironi> hello ppl
+<Bagder>        howdy ironi
+<Zagor> hi
+<ironi> hey do oyu know if there is an open source implementation of osme kind fo rbiztalk
+<Bagder>        biztalk?
+<ironi> yeah
+<Zagor> search freshmeat.net
+<ironi> ms biztalk
+<ironi> something like it
+<Bagder>        wazzat?
+<ironi> i am doing oppsition on a masters thesis and they say biztalk is too expensive, $25k per processor
+<ironi> biztalk.org
+<ironi> (inagine micorosft using .org heh)
+<Zagor> well, that's expensive. you still haven't said what it is or does
+<Bagder>        if it can't be described in a few words, I don't care about it :)
+<ironi> http://sourceforge.net/projects/mec-eagle/
+<ironi> ok "BizTalk specificerar hur meddelandelösningar mellan applikationer och organisationer skall utformas och utvecklas vad gäller elektronisk handel. Meddelanden skickas som XML- dokument inbäddat i ett kuvert med information om dokumentet enligt SOAP "
+<Zagor> oh, boy. it's a buzzword soup
+<ironi> thats from their thesis , prolly form ms website or something hehehe
+<ironi> yep
+<ironi> ok i found mec-eagle
+*       Zagor is genetically allergic to it
+<ironi> it is a level 5 project at sourceforge
+<ironi> great stuff
+<Zagor> XML and SOAP is just idiot-speak for "plain-text protocol"
+*       Zagor feels humble today :)
+<Zagor> My "Smash" is a level 5 project too. It just says the code works.
+<Zagor> Rockbox is level 5 as well, now that I think about it...
+<ironi> Zagor =)
+<ironi> rockbox isn ot production/stable
+<Zagor> it is stable
+<Zagor> it has all the features advertised, and works 100%
+<Zagor> 1.0 is rock solid
+<ironi> heh
+<ironi> ok well
+<Zagor> marking it as "beta" just means it will be very confusing when to actually move it to "stable"
+<Zagor> way too much software is called "beta"
+<Bagder>        it is soon time for the anual mail2sms update release ;-)
+<Zagor> hehe. "mail2sms 2002"
+<Zagor> or is it called XP this time? ;)
+<Bagder>        "mail2sms XP" ... hehe
+<dwihno>        If you bundle it with other applications, you can name it XP, otherwise, just name it 2002 ;)
+<Zagor> only weenies use the same version scheme more than twice.
+<Zagor> dwihno: hehe
+<Bagder>        I'll start using names: mail2sms version "Bernie" :*)
+<dwihno>        Eww
+*       dwihno gets the shivers
+<Zagor> oooh, innovative!
+<ironi> hey have you tried linuxsms
+<ironi> it's nice, really
+<Zagor> I don't need to, we wrote smash...
+<Bagder>        why would we use that, we have a working solution! ;-)
+<ironi> Bagder: but does yours use free sms servcies?
+<ironi> or is it a sms gateway
+<Bagder>        yes, if we want to
+<Zagor> it uses any service you like
+<ironi> Zagor: oh really
+<ironi> so it can log in to 1rstwap.com and send sms?
+<ironi> without me going to the webpage
+<Bagder>        of course
+<Bagder>        curl is the answer
+<Zagor> Bagder: is there any reason we don't compile the simulators with DEBUG?
+<ironi> well
+<Bagder>        Zagor: yes, because that's the symbol taken for compiling the gdb stub :-) other reasons: no 
+<ironi> this ismple perl script does the job just as good =)
+<Zagor> Bagder: buh, change it :)
+<Bagder>        ironi: smash is a complete system for posting messages and queueing etc, it is not just a deliverer
+<Zagor> ironi: yeah, for one message every now and then. try sending a couple hundred per hour, from 16 different machines. then the little perlie isn't so fun anymore :)
+<ironi> Zagor: of course
+<ironi> I understand that
+<ironi> I just think tlinuxsms is easier to use for individuals
+<ironi> =)
+<ironi> well ANYWAY
+<Zagor> yeah, it probably is
+<Bagder>        hehe
+<ironi> i made a php/wap page
+<Bagder>        you could still use mail2sms to get your mails into a suitable text 
+<ironi> so now (since gprs i free until 31/10 on comviq) i can send FERE sms from my cellphone
+<ironi> FREEEE
+<ironi> that kinda rocks
+<dwihno>        How much do you pay for the used bandwidth after that?
+<ironi> dwihno: i think 50kr/month with 3 mb included (which is mor ethan enough to view A LOT of wap pages)
+<ironi> oops gotta go to schoo
+<ironi> l
+<ironi> later=)
+<Bagder>        see ya ironi
+<dwihno>        bajbaj
+<--     miah has quit (card.openprojects.net irc.openprojects.net)
+-->     miah (~miah@pihkal.com) has joined #rockbox
+<Bagder>        woah
+<Bagder>        check the build status
+<Bagder>        they're not red ;-)
+<Zagor> when does it run, anyway? on checkin?
+<Bagder>        no, it checks out and checks for diffs
+<Zagor> when=
+<Bagder>        every 20 mins
+<Zagor> typical. that non-building code was in for about two minutes...
+<Bagder>        hehe
+<Bagder>        well, now we got to see the 'fail' text
+<Zagor> fixing
+<Zagor> ouch, too red
+<Bagder>        you'd need a different font color for that red
+<Zagor> how about this pink?
+<Bagder>        fine
+<Zagor> and how about only showing the five last builds or something?
+<Bagder>        these are the last 20 ;-)
+<Zagor> ok, fine
+<Bagder>        so at least it won't grow bigger than this
+<Zagor> then it's good
+---     Linus|meeting is now known as Linus
+-->     edx (OKE60@pD9EAB5E1.dip.t-dialin.net) has joined #rockbox
+<edx>   hi
+<Zagor> hi edx
+<Bagder>        hey
+<edx>   hmm ... how far is ata.. read the log message of ata.c :)
+<Bagder>        edx: thread support coming to the X11 simulator soon
+<Zagor> edx: we've added threading to the simulator. time to work! :)
+<edx>   ohuoh..
+<edx>   threading should not be a problem...
+<edx>   but i wont have time before the day after tomorrow :(
+<Zagor> no problem
+<Zagor> is someone needs it before then, he'll just have to do it :)
+<edx>   hmm so what is that with the ata driver?
+<Bagder>        edx: it works
+<edx>   really? :) for the recorder.. that is great
+<edx>   that was a wrong command address im memory?
+<Bagder>        all praise to Linus for that
+*       Bagder runs on a meeting
+<edx>   * Greate  praise for Linus *
+<edx>   ok.. gotta do my homework :( .. later
+---     edx is now known as edx|homework
+<edx|homework>  ah.. Zagor, another thing
+<Zagor> yes?
+<edx|homework>  Linus changed ATA_CONTROL... in ata.c - does it still work for the player (have you tried?)
+<Linus> it works
+<edx|homework>  ok
+<edx|homework>  good job, Linus! :)
+<Linus> thx! those addresses are a story of their own
+<edx|homework>  hehe
+<Linus> the player only cares about the lower 4 bits and bit A20/21
+<Linus> the recorder cares about the lower 4 bits and bit A8/9
+<Linus> so we can support both hardwares by combining them in the same constant
+<edx|homework>  aha
+<edx|homework>  so that is there was A8/9 wrong?
+<edx|homework>  but A20/21 correct..
+<Linus> exactly
+<Linus> but i'm not sure that it was wrong
+<Linus> i'm beginning to suspect that different recorders have different address encoding...
+<Linus> we need an older recorder to try on
+<edx|homework>  hmm what firmware? "older"?
+<edx|homework>  i have a recorder.. but i guess its rather new..
+<Zagor> something that is not an r20
+<Linus> one with ISD200 USB interface
+<edx|homework>  ah ok forget about it.. i have an r20
+<edx|homework>  ok... but that one might work like the player... (?)
+<Zagor> yeah, well we'd like to find out
+<edx|homework>  hm put it on the top of the rockbox site ;)
+<edx|homework>  right in the front... <h1> tag lol
+<Zagor> a mail to the list is probably more helpful :)
+<edx|homework>  heh right...
+<edx|homework>  just if noone responds there might be people looking at the site and not joining the mailing list..
+<Zagor> Bagder: i'm getting a lot of X errors: Xlib: unexpected async reply (sequence 0x57f)!
+<Bagder>        never seen those
+<Zagor> i get them when scrolling. i'll check it in soon
+<Bagder>        X sure is magic business ;-)
+<Zagor> indeed
+<dwihno>        Magic stuff(tm)
+<Bagder>        Zagor: threads working otherwise?
+<Zagor> yup, perfectly
+<Bagder>        hm, could the X problems be due to the threads?
+<Zagor> I think so, I got the when I started working with threads
+<Zagor> there. now we have scrolling
+<dwihno>        Yay! :D
+<Zagor> playlist support and scrolling, that's what I have listed as 1.1 features on the front page...
+<Bagder>        we need to try it out more on target
+<Zagor> yup
+<dwihno>        I can test it on the r20
+<Zagor> please do
+<Linus> I'm loading it into the player now...
+<Bagder>        we did get two new warnings though
+<Zagor> oh, I introduced some warnings. fixing...
+<Linus> crash bang!!!!!
+<dwihno>        Is there an automated build process?
+<Bagder>        dwihno: yes
+<Zagor> Linus: what happens?
+<Bagder>        dwihno: http://bjorn.haxx.se/rockbox/daily.shtml
+<Bagder>        dwihno: scroll down
+<Linus> UIE09
+<Zagor> what's that?
+<Bagder>        address error
+<Zagor> boo
+<Zagor> bad bug then
+<Zagor> Linus: can you gdb it and see where?
+<Linus> ooooh. it worked the second time...
+<Zagor> looks ok?
+<Bagder>        ugha
+<Linus> how do i turn on scrolling?
+<dwihno>        I only see the "once a day" builds
+<Zagor> dwihno: at the bottom of the page: "Build status"
+<Bagder>        dwihno: the status below that is the automated builds
+<Zagor> warnings killed
+*       dwihno is blind
+-->     jedix (~liam@fwott1-1.cis.ec.gc.ca) has joined #rockbox
+<Linus> how do i turn on scrolling?
+<Zagor> Linus: it's always on
+<Linus> when?
+<Bagder>        hey jedix
+<Zagor> in the file browser
+<jedix> hey
+<Linus> well, mine doesn't scroll
+<Zagor> did you get the new tree.c and main.c ?
+<dwihno>        The "bleeding edge" binaries are not downloadable, huh?
+<Bagder>        dwihno: no
+<Zagor> dwihno: no, only the daily builds
+<Bagder>        that's bleeding enough for download ;-)
+<Zagor> the are deemed bleeding enough :)
+<dwihno>        :)
+<dwihno>        Do they have scroll stuff?
+<Bagder>        no
+<Bagder>        tomorrow they do!
+<dwihno>        Okay, then I'll wait
+<Zagor> I just checked that in, and it currently bugs too
+<Bagder>        jedix: your scroll is getting into the software now
+<jedix> sweet
+<Zagor> only i rewrote it :)
+<Bagder>        hehe
+<Linus> Zagor: is it only for recorder?
+<jedix> whaa?
+<Zagor> Linus: no, for both
+<Bagder>        time to get a coke
+<Linus> no go here
+<jedix> Bagder: yes sounds like a plan..
+<Zagor> they both work in the simulators. must be something not inited right
+<Zagor> does scroll_thread run?
+<Zagor> ahhh!
+<Zagor> my bad
+-->     alkorr (alkorr@srs05v-3-43.n.club-internet.fr) has joined #rockbox
+<Zagor> player code doesn't have lcd_init previously. I must add it. one minute.
+<Linus> hi alal
+<Linus> alan
+*       Bagder drinks ice-cold coke and says aaaaaaaaaaaaah
+<alkorr>        hi
+<alkorr>        soemtimes people have very weird ideas
+<alkorr>        there is one who like to be able to browse camera pictures on his jukebox :/
+<Linus> i assume it is a Recorder. :-)
+<Bagder>        hehe
+<Bagder>        noooo
+<Bagder>        jpg2ascii
+<Bagder>        ;-)
+<alkorr>        ahahah
+<Linus> lucky we have a scroller then :-)
+<alkorr>        quite funny, a jpg2ascii
+<alkorr>        what is it eaxctly ?
+<Bagder>        I used one once
+<alkorr>        a big page we can scroll on screen ?
+<alkorr>        or just a horizontal text scroller ?
+<Zagor> text scroll for now, for use with filenames
+<Linus> just horizontal text scroller, for file names and such
+<alkorr>        ok
+<alkorr>        128 chars max i see
+<Linus> we can sell commercial banners that displays when playing songs :-)
+<alkorr>        ahahah
+<Linus> .....drink Coke...............Just Do It..............
+<alkorr>        unhopefully we are open source, it would be very easy to get rid off ;P
+<alkorr>        or hopefully should I say :)
+<alkorr>        Zagor, you think to remove any newlib dependencies for how time ?
+<Zagor> i need to get my non-newlib gcc working first. i hope to do that tomorrow.
+<alkorr>        ok
+<alkorr>        by the way, did you try with gcc 3.0.3 instead of 3.0.4
+<Zagor> not yet
+<alkorr>        to see if errors persist ?
+<Zagor> Linus: try the new versions
+<alkorr>        it is weird that error comming from "rotcl r14"
+<Zagor> yes, very
+<alkorr>        but there is plenty of reference to this opcode in libasm1.c
+<alkorr>        which line is concerned we don't know :/ 
+<alkorr>        what is the exact message ?
+<Zagor> i have to go, we'll fix it tomorrow ok?
+<Bagder>        see ya z
+<Zagor> hope the scroll works now...
+<Zagor> bye
+<alkorr>        ok, i'm trying to get back the log
+<alkorr>        bye
+<--     Zagor has quit ("Client Exiting")
+<alkorr>        :( mirc doesn't log
+<Bagder>        mirc is evil
+<Bagder>        ;-)
+<alkorr>        arf :)
+<alkorr>        yaa...
+<Linus> what did we say about the show_logo ATA thing?
+<Bagder>        use internal-only
+<jedix> mirc implies an evil os
+<Linus> the current firmware tries to load a BMP file before ATA is initialized
+<Linus> Bagder: can you fix that?
+<dwihno>        oops
+<dwihno>        that's a typical nono :)
+<Bagder>        Linus: sure
+<jedix> why did zagor rewrite my code?
+<alkorr>        this BMP is embbeded in rockbox ?
+<Bagder>        alkorr: the BMP reader code is, yes
+<Linus> it displays a file-based logo if it exists
+<alkorr>        so it is not embedded :)
+<alkorr>        i was speaking about the picture
+<Linus> "if it exists"
+<Linus> if it doesn't, it uses the internal one
+<Bagder>        there is a logo embedded too
+<alkorr>        okay
+<alkorr>        if an external one exists displays it instead of internal one
+<alkorr>        is that so ?
+<Bagder>        yes
+<Bagder>        but not anymore ;-)
+<dwihno>        :(
+<alkorr>        ok so just rephrase my sentence in past :)
+<Bagder>        hehe, right
+<dwihno>        I'll make my own branch called "logoboX" ;)
+<Bagder>        currently, the show_logo() stuff is made before ATA is inited
+<Bagder>        we can't load a logo then
+<Bagder>        we need to move the logo-loading
+<alkorr>        well it is a matter to move the piece of code
+<Bagder>        yes, but since the initing will take a little time anyway, we'll display the internal one in the mean time
+<alkorr>        okay
+<alkorr>        why not a progress bar ?
+<Bagder>        we could add one below the logo
+---     Linus is now known as Linus|meeting
+<Hadaka>        progress bar sucks, verbose messages on what the machine is doing are nice :)
+<alkorr>        sure, people don't like not to know why their toy looks frozen
+<alkorr>        Hadaka, we don't need to surcharge code with messages
+<alkorr>        especially for initialisation part
+<alkorr>        please, we are not working with a PC full of memory...
+<Hadaka>        well true, I have no idea what memory problems you have already encountered
+<alkorr>        first, we only have 2 MB
+<alkorr>        second, to waste data and code just for displaying an initial message (that is something we don't need in fact for th rest)
+<Hadaka>        does the 2MB need to hold the buffer for the disk reads as well or is that separate?
+<alkorr>        code, data and buffer are in the same memory
+<alkorr>        so growing code and data means less buffer
+<Bagder>        hm brb
+<--     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has left #rockbox
+<Hadaka>        well your call - I personally would still want a few kilobytes used for 'ATA Init' 'DAC Init' 'FAT init' etc.
+<alkorr>        pardon ?
+<alkorr>        what do you mean ?
+<alkorr>        i was away :)
+<alkorr>        Hadaka: what do you mean ?
+<Hadaka>        um
+<Hadaka>        the same thing I meant originally
+<alkorr>        those KB are for what, code, data ?
+<Hadaka>        code and the string constants
+<alkorr>        ah yes
+<alkorr>        well, in fact
+<alkorr>        on the screen ?
+<Hadaka>        um, yes - rather than a progress bar that is
+<alkorr>        first, you wouldn't have time enough to read messages
+<alkorr>        i think the best thing is to have a progress bar and message error when occurs in module
+<alkorr>        that a minimum of messaged
+<alkorr>        d -> s
+<Hadaka>        well then we differ in what we want, simple as that
+<alkorr>        I'm speaking about player AND recorder, not only for recorder
+<--     miah has quit (card.openprojects.net irc.openprojects.net)
+<Hadaka>        I've never even seen the player, so I don't know about that
+<alkorr>        you cannot see a lot of things on playes
+<alkorr>        2 lines of 11 characters...
+-->     miah (~miah@pihkal.com) has joined #rockbox
+<alkorr>        a thing is sure, since we have an open source, we are free to add whatever we want
+<Hadaka>        It's funny how much information you can stick in L LI LIL LILO and LIL-
+<Hadaka>        maybe you could use R O C K B O X ;)
+<Hadaka>        but true, if I want it, I can code it myself
+<alkorr>        some prefers to have a minimal but efficient firmware, others plenty of stuffs but rather consumptive firmware
+<alkorr>        L LI ???? what is it LILO ???
+<Hadaka>        oh, lilo is the linux loader - it prints LILO on the screen when it runs successfully - or one of the variants if it fucks up at some point - and you can usually tell exactly where it went wrong by that
+<alkorr>        oh okay like a progress bar using a text ?
+<dwihno>        r.. o.. c.. k.. b.. [err]
+<dwihno>        or something :)
+<dwihno>        I can do neat PDF's! :D
+<alkorr>        it's an idea
+<Hadaka>        well kind of - except that you don't have to count pixels in a progress bar but can say directly that it printed 'ROC' and then someone here will say "Oh god, the ATA code is fucked again."
+<alkorr>        my only opinion is just to display something when an error really occurs
+<Hadaka>        since at a bootloader stage, anything can happen - and expecting all errors to be catchable is not possible - atleast not on PC bootloaders
+<Hadaka>        I dunno if you can catch each and every error on the archos
+<alkorr>        well just compile with gdb ;)
+<Hadaka>        err, that isn't possible when a dumb user comes with an obscure archos and tells you that his on his box, the progress bar freezes "about halfway"
+<alkorr>        well, i'm just waiting for a rockbox running without newlib. i could then add some hardware stuffs
+<dwihno>        I'm looking forward to test it tomorrow
+<alkorr>        sorry, can you rephrase ?
+<alkorr>        "obscure archos" ?
+<alkorr>        "that his on ..." ?
+<Hadaka>        compiling with gdb is not an option when a user whines that the archos freezes during loading
+<alkorr>        oh yeah it is just a joke
+<Hadaka>        obscure archos => a different model of archos no one else has had yet
+<alkorr>        gdb is for developer, we know that
+<alkorr>        there are very few chance for that
+<alkorr>        because it means a different archos firmware fisrt
+<Hadaka>        well haven't you here just pondered that does somebody have an older version of the recorder, one with ISD200?
+<alkorr>        anyway, either you catch an error message or nothing. That nothing doesn't mean if you had more explicit message you would be able to guess that you have "obscure" archos
+<alkorr>        yeah
+<alkorr>        it is normal
+<alkorr>        ISD300 was out after recorder
+<Hadaka>        well even if you would get nothing, you would be able to say that it's the ATA code that is failing - even if the archos freezes
+<alkorr>        so inevitably you can find recorder with isd200
+<alkorr>        if archos freezes, just ask for people to use another rockbox with more messages
+<Hadaka>        but the real point is just that I'd much rather see some indication of what the archos is actually doing, rather than an opaque progress bar
+<alkorr>        you can have two different rockbox for testing or for playing
+<Hadaka>        it's just a personal preference
+<Hadaka>        some people might prefer a cool progress bar, I definitely don't
+<alkorr>        okay if you think to lose 32 KB for messages and code is not a problem for you, it is your choice
+<alkorr>        as i told you it is just a matter of adding or not what you want
+<Hadaka>        yeah I agreed with that
+<alkorr>        just add it as an option, so people who don't want them ae not forced to get redi of them
+<alkorr>        rif
+<alkorr>        rid
+<alkorr>        maybe some macro which are void when not demanded for example
+<alkorr>        something like it
+<alkorr>        we should speak with other developers to know what kind of solution to have them as option
+<Hadaka>        well right now I'm quite busy at work and at other projects - I just voiced a preference - if I really want it, I'll code it myself
+<alkorr>        ok
+<Linus|meeting> I have now tried the scrolling filenames on the Player
+---     Linus|meeting is now known as Linus
+<Linus> it works Ok
+<alkorr>        good
+<Linus> i'll try it on the recorder now
+<alkorr>        i'm still waiting for a working rockbox :)
+<alkorr>        :/
+<Linus> Zagor is on the case
+<alkorr>        hopefully
+<alkorr>        my scanner/printer has no driver for linux :(
+<Linus> :-(
+<Linus> well, the scroller isn't perfect, but it's a good start
+<Linus> at least we can see the whole file name now
+<alkorr>        on pixel basis or on char basis ? (the moving)
+<Linus> char
+<alkorr>        because of player ?
+<alkorr>        well i suppose so
+<Linus> sort of
+<dwihno>        How fast is the scroller btw? :)
+*       dwihno likes'em fast
+<Linus> now it is 5 updates per second
+<Linus> it is a little too slow
+<Linus> but if we scroll too fast it gets blurry on the player
+<alkorr>        that's right
+<Linus> maybe the player lcd would be sharper if we used the internal scroll function
+<alkorr>        well if you want to scroll two lines, that coul be an idea
+<Linus> gotta go now, CU!!!
+<alkorr>        CU
+<--     Linus (~linus@labb.contactor.se) has left #rockbox
+<alkorr>        CU
+<--     alkorr has quit ()
+---     dwihno is now known as dw|gone
+---     Disconnected (Connection reset by peer).
+**** ENDING LOGGING AT Mon Jun 10 12:17:44 2002