--- Log for 15.10.104  Server: burroughs.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 10 days and 23 hours ago

00.00.01 #       <haruki> ah yes, after running vbr-fix the file now lists as being ten minutes long
00.00.20 #       <amiconn> yup. Odd playing time for both files. Iirc rockbox does not write the correct vbr geader when timesplit is on (probably it would take too long)
00.01.29 #       <haruki> well thanks for helping me test this kludge ;)
00.01.57 #       <haruki> i wonder if that fellow who is implementing this feature is using the same methods...
00.02.02 #       <haruki> ;)
00.03.37 #       <amiconn> I don't think so. A proper implementation would also allow to set a specific start time
00.04.08 #       <amiconn> ...even waking up the recorder at the right time if you either have the alarm mod or a v2/fm
00.05.34 #       <haruki> now that will be a very cool feature. hey i just had an odd idea, do you think the recorder is capable of a cutup feature? where it would "randomly" rearrange an mp3 file?
00.06.51 #       <amiconn> Cutting mp3s is not that easy. First, cutting is only possible at frame boundaries
00.08.14 #       <amiconn> If the bit reservoir is used, you will certainly hear a glitch at the cut point. Even without bit reservoir (independent frames) there will be a slight glitch
00.08.46 #       <amiconn> But it is certainly possible to implement that, even on the players
00.09.48 #       <haruki> interesting, i think i may look into that, i wonder if anyone would be interested in it besides me
00.10.03 Join    iRiverMan [0] (~acba8081@labb.contactor.se)
00.11.18 #       <amiconn> haruki: There is already an mp3 split editor plugin, perhaps you can reuse some code
00.12.09 #       <amiconn> Bagder: U there now?
00.15.55 #       <haruki> thanks a lot amiconn!
00.16.39 Quit    iRiverMan ("CGI:IRC (EOF)")
00.16.47 #       <amiconn> np
00.18.17 Join    einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de)
00.18.19 Quit    haruki (Remote closed the connection)
00.33.14 Quit    einhirn (Read error: 54 (Connection reset by peer))
00.34.39 #       <amiconn> Yay! Rockbox on Ondio is *significantly* more energy efficient than archos fw!
00.38.03 Join    einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de)
00.39.28 Join    gromit` [0] (~gromit@ALagny-151-2-8-106.w82-121.abo.wanadoo.fr)
00.46.13 Quit    _aLF ("Leaving")
00.57.02 ***     Saving seen data "./dancer.seen"
01.20.27 Quit    AciD (Remote closed the connection)
01.24.15 Join    napgravy [0] (user@S0106004095d1df8f.cg.shawcable.net)
01.24.43 Quit    napgravy (Client Quit)
01.30.20 Join    LinusN [0] (~linus@labb.contactor.se)
01.30.30 #       <amiconn> hi LinusN
01.30.36 #       <LinusN> hi
01.41.55 #       <amiconn> Did you notice my message about power drain with rockbox vs archos on Ondio?
01.42.39 #       <amiconn> We can expect ~40% longer battery life
01.47.05 #       <LinusN> are you kidding?
01.47.27 #       <amiconn> Nope
01.47.41 #       <amiconn> I wonder whether I should put the raw data into a wiki table
01.48.45 #       <amiconn> I measured power consumption in various operating states and 2 different voltages with both firmwares
01.50.38 #       <LinusN> why are we so much better?
01.51.25 #       <amiconn> I think its because rockbox uses the sleep feature of the CPU. Power consumption varies much more with rockbox than it does with archos
01.52.25 #       <amiconn> Some nice values, at 4.6 V (maximum voltage): Browser, no scrolling lines - rockbox 54 mA, archos 90 mA
01.53.13 #       <amiconn> WPS, no scrolling, (rockbox: peakmeter, high performance) - rockbox 65 mA, archos 92 mA
01.54.10 #       <amiconn> Playback, while reading from internal flash - rockbox 85 mA, archos 130 mA
01.54.21 #       <amiconn> ...
01.55.00 #       <LinusN> cool
01.55.46 #       <amiconn> I think this is a strong argument for rockbox on Ondio: "Wanna waste less money for batteries - use rockbox!"
01.57.33 #       <amiconn> I'll put together a little table.
01.58.12 #       <LinusN> you said "did you notice my message"
01.58.17 #       <LinusN> where was that?
01.59.20 #       <LinusN> ah
01.59.23 #       <LinusN> <amiconn> Yay! Rockbox on Ondio is *significantly* more energy efficient than archos fw!
01.59.27 #       <amiconn> yup
01.59.40 #       <LinusN> majpr coolness
02.01.29 #       <amiconn> I hope Jörg will also do some measurements with his Ondio FM, for comparison. I expect similar figures
02.02.32 #       <amiconn> I did thgat measurements mainly because I want to adapt the power thread runtime estimation
02.02.35 #       <amiconn> *that
02.02.39 Quit    mecraw__ ("Trillian (http://www.ceruleanstudios.com)")
02.04.58 #       <amiconn> The 10 hours given by archos are rather optimistic... with their firmware
02.06.51 #       <amiconn> Multi-volume browsing would be the 2nd killer feature...
02.15.49 #       <LinusN> absolutely
02.17.26 #       <amiconn> Re your latest commit: More viewers coming up?
02.21.21 #       <amiconn> We have an all-green build table :)
02.25.14 #       <LinusN> yes, the menu had a maximum of 8, and viewers.txt had 8 also, so we couldn't add more
02.25.42 #       <LinusN> favorites.rock is next to be added
02.27.16 #       <amiconn> That reminds me I should finally do that .bmp loader...
02.35.58 #       <amiconn> Current measurement table done.
02.45.55 #       <amiconn> Tts, cu
02.46.25 Part    amiconn
02.57.06 ***     Saving seen data "./dancer.seen"
03.36.33 Join    MisticJeff [0] (~0c68cc30@labb.contactor.se)
03.36.46 #       <MisticJeff> howdy
03.36.54 #       <LinusN> hola
03.37.03 #       <MisticJeff> what's new?
03.37.49 #       <LinusN> siting here, debugging the threading code on my iriver
03.38.00 #       <MisticJeff> wow, lots of fun
03.38.20 #       <MisticJeff> im at work
03.38.29 #       <MisticJeff> just checking in, gotta run
03.39.06 #       <MisticJeff> see you later and good luck...  let me know if you or Zagor or both want to get an H140
03.39.35 Part    MisticJeff
03.40.51 Part    LinusN
04.52.29 Quit    scott666_ ("i'll be back...eventually...")
04.54.39 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
04.57.08 ***     Saving seen data "./dancer.seen"
05.55.11 Quit    _Lucretia (Read error: 60 (Operation timed out))
06.08.30 Join    _Lucretia [0] (~munkee@abyss2.demon.co.uk)
06.19.48 Join    ashridah [0] (ashridah@220.253.119.91)
06.42.39 Join    LinusN [0] (~linus@labb.contactor.se)
06.57.09 ***     Saving seen data "./dancer.seen"
07.20.58 Join    gromit`` [0] (~gromit@ALagny-151-2-8-139.w82-121.abo.wanadoo.fr)
07.32.50 Join    Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU)
07.37.31 Quit    gromit` (Read error: 110 (Connection timed out))
07.40.44 Quit    _Lucretia (Read error: 110 (Connection timed out))
07.41.41 Join    _Lucretia [0] (~munkee@abyss2.demon.co.uk)
07.43.32 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
08.05.13 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
08.05.48 #       <[IDC]Dragon> 'morning!
08.05.54 #       <LinusN> hi
08.06.22 #       <[IDC]Dragon> do you sleep at all?
08.06.29 #       <LinusN> not really :-)
08.06.49 #       <[IDC]Dragon> wish I could do that
08.06.56 #       <LinusN> me too :-)
08.09.16 #       <[IDC]Dragon> Jens' all green build table has a stain again
08.09.26 #       <LinusN> yeah, my fault
08.18.34 #       <[IDC]Dragon> I wonder why Rockbox consumes such significantly less power on the Ondio
08.18.49 #       <LinusN> probably the SLEEP in the threading code
08.19.03 #       <[IDC]Dragon> I once was comparing sleeping CPU vs. 100% busy, that was just a few mA
08.19.16 #       <LinusN> hmmm
08.20.26 Join    MoGle3 [0] (mogle3@213.177.236.210.adsl.griffin.net.uk)
08.33.14 Join    Lucretia_ [0] (~munkee@abyss2.demon.co.uk)
08.34.57 Quit    _Lucretia (Read error: 110 (Connection timed out))
08.35.56 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
08.40.33 Quit    MoGl53 (Read error: 110 (Connection timed out))
08.44.01 Join    amiconn [0] (~jens@pD95D1768.dip.t-dialin.net)
08.44.26 #       <amiconn> Morning all
08.44.56 #       <LinusN> hi
08.45.53 #       <[IDC]Dragon> morning Jens
08.46.22 #       <[IDC]Dragon> I haven't described my daily morning routine to you guys:
08.46.52 #       <[IDC]Dragon> while still dark in the bedroom, I reach for my webpad, to check what you guys did last night
08.48.05 #       <[IDC]Dragon> makes me feel like a lamer sometimes, when I went to bed like 4 hours earlier
08.48.29 #       <LinusN> 4 hours! luxury!
08.50.05 #       <[IDC]Dragon> indeed
08.50.22 #       <[IDC]Dragon> with no kids, I have no such training
08.50.28 #       <LinusN> :-)
08.50.56 Join    Zagor [242] (~bjst@labb.contactor.se)
08.51.12 #       <LinusN> morning Zagor
08.52.04 #       <Zagor> morning
08.53.14 #       <[IDC]Dragon> yawning
08.53.36 #       * Bagder enters
08.53.41 #       <Bagder> hi crowd
08.53.56 #       <amiconn> [IDC]Dragon: Also no kids here...
08.53.59 #       <[IDC]Dragon> hi
08.54.10 #       <[IDC]Dragon> amiconn: I guessed
08.54.25 #       <[IDC]Dragon> a woman?
08.54.38 #       <amiconn> nope
08.55.02 #       <[IDC]Dragon> now I know the secret of Jens' hacking resourcefulness
08.56.00 #       <LinusN> hi Bagder
08.56.28 #       * Bagder only has one child, LinusN has two!
08.57.11 ***     Saving seen data "./dancer.seen"
08.58.55 #       <[IDC]Dragon> amiconn: nice catch on the inits
08.59.17 #       <amiconn> [IDC]Dragon: If you want to check something concerning the energy consumption rockbox<->archos, you could check whether archos fw holds the flash /cs low all the time (I didn't do this)
08.59.39 #       <[IDC]Dragon> I can try, yes
09.00.15 #       <[IDC]Dragon> or rather, do that (not much trying involved)
09.00.49 #       <dwihno> Bagder only has one child, LinusN ;)
09.02.09 #       <amiconn> [IDC]Dragon: (inits) Wasn't that easy to find, although the USB init problem was clearly visible in "Show IO ports", once I had a clue what might cause the instability
09.03.02 #       <[IDC]Dragon> why is the order important?
09.03.20 #       <LinusN> speaking of instability, i debugged the coldfire threading code for over an hour, with the DRAM refresh turned off :-)
09.03.34 #       <[IDC]Dragon> oops
09.03.34 #       * Bagder giggles
09.03.46 #       <[IDC]Dragon> how long does it last without?
09.04.24 #       <[IDC]Dragon> in the past, I found DRAMS very remarkably tolerant
09.05.02 #       <LinusN> that's why i didn't notice at first
09.05.11 #       <LinusN> it lasted for minutes
09.05.34 #       <[IDC]Dragon> whow
09.05.50 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
09.05.57 #       <LinusN> one or two bit faults here and there
09.07.05 #       <[IDC]Dragon> amiconn: your power tests were with rombox, or reguler?
09.08.34 #       <amiconn> rombox
09.09.24 #       <[IDC]Dragon> did you compare rombox vs. "rambox"?
09.12.13 #       <Bagder> whoa openneo commits
09.12.24 #       <dwihno> speaking of nothing, rombox still stuffers from rld (I recall someone mentioning something about rld decrease after rombox)
09.12.44 #       <Bagder> "Heap size increased to 63 KB"
09.12.46 #       <Bagder> hehe
09.13.41 #       <LinusN> they are slowly sinking into the dynamic memory swamp
09.13.46 #       <Bagder> "Added support for autoexec.cfg"
09.14.41 #       <Bagder> LinusN: indeed
09.14.55 #       <Bagder> with 256K ram, 63 in the heap seems... excessive
09.25.34 Join    einhirn [0] (Miranda@bsod.rz.tu-clausthal.de)
09.30.23 Quit    ashridah ("woohoo! pizzapizzapizzapizzapizza PIZZA.... damn. that means i need the phone. sucky house")
09.59.20 #       <amiconn> [IDC]Dragon: No I didn't compare, didn't think of it. Seems like a good thing to try...
10.02.51 #       <amiconn> LinusN: Congrats on the iRiver progress, btw.
10.07.07 #       <LinusN> it's nothing compared to what you guys have done with the Ondio, my hat is off
10.07.40 #       * LinusN proudly hands over the Rockbox Speed-Porting award to Jens and Jörg
10.08.41 #       <amiconn> For Ondio, we could re-use a large part of rockbox as-is, and we didn't have to deal with the lowest level.
10.09.34 #       <LinusN> true, but you have done a remarkable job with the MMC driver
10.09.38 #       <LinusN> and FAT16
10.09.45 #       <Zagor> the offer to sponsor your ondios is still valid, btw.
10.16.14 #       <[IDC]Dragon> Ondio wasn't porting, rather "adjusting"
10.17.32 #       <[IDC]Dragon> Zagor: thanks for the offer, I come back to that when we have users, and possibly donations from them
10.20.44 #       <[IDC]Dragon> right now, ondio rockbox is a solution in search for the problem
10.20.55 #       <LinusN> no
10.21.19 #       <LinusN> it's a fun project for you and Jens, and Rockbox benefits from it
10.21.52 #       <[IDC]Dragon> besides that, sure ;-)
10.22.07 #       <Zagor> it's also a good test bench for some of the port preparations, such as the build tools and the button code
10.23.35 #       <amiconn> Speaking of porting: As the init issues on Ondio are solved now, I'll go ahead and adapt some more plugins to Ondio. On the way I'll change all of them to use the default event handler.
10.23.46 #       <LinusN> wonderful
10.24.11 #       <amiconn> Q: Do you agree that after this is done, usb_screen() should be ditched from the plugin api?
10.27.18 #       <LinusN> maybe
10.27.41 #       <LinusN> if there isn't any use for it
10.28.18 #       <[IDC]Dragon> are you happy with the cleanup callback?
10.28.20 #       <LinusN> my original idea was that the plugin should "grab" the events itself if it didn't want/like the default handling
10.28.42 #       <LinusN> (like if there was a need for cleanup)
10.28.50 #       <LinusN> the callback solves most of these problems
10.29.10 #       <LinusN> so i think the usb screen can go
10.29.41 #       <LinusN> my original idea looked like this:
10.29.52 #       <LinusN> case SYS_USB_INSERTED:
10.30.00 #       <LinusN>    cleanup();
10.30.15 #       <LinusN>    default_handler(SYS_USB_INSERTED);
10.30.19 #       <LinusN>    break;
10.30.54 #       <amiconn> I first considered this approach, but there is a problem with it.
10.30.58 #       <LinusN> however, the callback idea might be better since we don't have to add new cases for new events that need cleanup
10.31.07 #       <amiconn> Yes, that's the point
10.31.29 #       <LinusN> and we can still do it "my way" if there is a need for it
10.32.04 #       <LinusN> usb_screen() isn't directly called with my method either
10.35.03 #       <amiconn> The other solution I discussed with Bagder is to introduce a second function that checks whether an event is to be handled by the default handler.
10.35.41 #       <amiconn> ..and then do the following in the plugin:
10.35.54 #       <amiconn> if (is_default_event(event) {
10.36.00 #       <amiconn> cleanup();
10.36.11 #       <amiconn> default_event_handler(event);
10.36.13 #       <amiconn> }
10.44.39 #       <LinusN> nah
10.45.04 #       <LinusN> i admit that it's "cleaner", but i can live with the callback as well
10.47.14 #       <[IDC]Dragon> but this readsmore KISS
10.49.13 #       <amiconn> ?
10.49.27 #       <LinusN> in the KISS sense, i'd say is_default_event() is to prefer
10.49.41 #       <[IDC]Dragon> you better see what's going on
10.49.48 #       <LinusN> yup
10.57.13 ***     Saving seen data "./dancer.seen"
10.58.01 #       <amiconn> So I think I should implement it that way... Only issue is that you have to remember to adapt this function as well whenever a new default event is added
10.58.42 #       <LinusN> yes, but they can reside in the same file (misc.c)
10.59.14 #       <amiconn> Of course
10.59.26 #       <LinusN> still, it isn't waterproof, as not all (future) default events would need a cleanup
11.00.27 #       <LinusN> but so far, all SYS_ events need cleanup
11.02.57 Join    ashridah [0] (ashridah@220-253-120-64.VIC.netspace.net.au)
11.03.49 #       <[IDC]Dragon> then call it needs_cleanup() or so
11.04.33 #       <[IDC]Dragon> it can call default_event_handler() by itself if not
11.05.06 #       <LinusN> let's keep the callback
11.05.25 #       <[IDC]Dragon> but this is a bit ugly again, because only in the cleanup case you'd have to call default_event_handler() afterwards
11.05.25 #       <LinusN> then the default handler can decide if it has to call the cleanup function or not
11.12.05 #       <amiconn> LinusN: That's like it is now
11.14.29 #       <LinusN> yes
11.15.32 #       <amiconn> Or with the 2-function approach, the first function could be called get_default_event_class() with an enum return value { DEFAULT_EVENT_NONE, DEFAULT_EVENT_SIMPLE, DEFAULT_EVENT_COMPLEX }, or such
11.18.24 #       <LinusN> nah, let's keep the current solution, and we'll expand it if the need arises
12.33.38 Quit    scott666_ ("i'll be back...eventually...")
12.54.07 #       <[IDC]Dragon> LinusN: want to have a final word about file/function names for the tuner split?
12.57.17 ***     Saving seen data "./dancer.seen"
13.01.15 Join    Norrin [0] (~440d6a3e@labb.contactor.se)
13.01.42 Join    Nuxator [0] (~chatzilla@pc102.ie2.u-psud.fr)
13.02.15 #       <Norrin> Hello all.  I have a Archos FMRecorder which I let the battery run down on.  Now I can't get it to take a charge to turn back on.
13.02.38 #       <LinusN> how long have you tried to charge it?
13.02.46 #       <LinusN> have you flashed rockbox?
13.02.47 #       <Norrin> When I plug in the charger, nothing comes on the screen and you can just hear it clicking.  Let it on overnight.
13.03.11 #       <Norrin> Yep, I've been using Rockbox for a while now.
13.03.48 #       <Nuxator> hello all
13.03.50 #       <Norrin> I've tried holding F1 when I plug it in along with pressing the ON and OFF buttons, it's dead.
13.03.54 #       <LinusN> try to hold F1 when you insert the charger
13.03.58 #       <LinusN> :-)
13.04.14 #       <LinusN> also try to insert the USB cable as well
13.04.20 #       <Nuxator> just wanted to show support to linusN for iriver port
13.04.27 #       <LinusN> Nuxator: thanks
13.04.47 #       <Nuxator> i see that screen is blicking ;)
13.04.57 #       <LinusN> Nuxator: blink blink
13.04.57 #       <Nuxator> next step hello world 
13.05.29 #       <Nuxator> keep going this good work see you 
13.06.49 Quit    Nuxator ("ChatZilla 0.8.31 [Mozilla rv:1.4.1/20031008]")
13.07.59 #       <Norrin> Tried USB cable also, nothing.  I can barely see a little bit of the green light on when I plug it in.  when I listen closely to the recorder, I can hear it clicking when it's plugged in.  Not a hard drive click but something else.
13.08.31 #       <LinusN> try to extract the battery and insert it again
13.09.11 #       <Norrin> I was afraid you would say that.  That's not so easy so I'll have to try it later and get back to you.
13.11.00 #       <[IDC]Dragon> I wonder how this still happens, and if I can improve somehow
13.11.50 #       <Zagor> I don't see what we can do on the LiIon models
13.12.23 #       <[IDC]Dragon> shutdown the HD even earlier?
13.13.01 #       <[IDC]Dragon> right now it's done by the bootloader, if charger plugged
13.14.03 #       <[IDC]Dragon> it could be done by the flash "patch list", which is processed by the boot ROM, but then unconditional
13.14.56 #       <[IDC]Dragon> the boot loader would have to conditionally switch it on again
13.19.18 #       <LinusN> we should try that
13.19.49 #       <[IDC]Dragon> so far, I stayed away from that patch list
13.22.59 #       <Zagor> how long do we have the disk on today?
13.23.05 #       <Zagor> 100ms? 50?
13.23.22 #       <[IDC]Dragon> something it that range, perhaps
13.23.43 #       <[IDC]Dragon> as long as it takes the boot rom to descramble my bootloader
13.24.02 #       <[IDC]Dragon> plus some reset holdoff time
13.24.08 #       <Zagor> what was the reason the bootloader enables it?
13.24.33 #       <[IDC]Dragon> it doesn't, it disables it if the charger is plugged
13.24.45 #       <[IDC]Dragon> the disk is on by hardware default
13.25.19 #       <Zagor> so how fast does the archos firmware turn it off?
13.25.42 #       <[IDC]Dragon> slower
13.26.23 #       <Zagor> I thought using F1+ON was used as a "safe boot" for rundown batteries. is that not the case?
13.27.53 #       <[IDC]Dragon> it is a safe mode for misflashed ucl, primarily
13.29.32 #       <Zagor> yes, i just thought I had read somewhere about people having better luck booting with f1 when batteries are low. guess i was wrong.
13.30.23 #       <LinusN> i have had the same problem with my fm, and it isn't even flashed
13.31.46 #       <[IDC]Dragon> on sw charge controlled models, archos charges right away, vs. we are hesitating
13.32.04 #       <Zagor> ah ok
13.33.52 #       <[IDC]Dragon> none-flashed FMs are probably prone to flat batteries, too
13.34.26 #       <[IDC]Dragon> since Archos has to shut off the disk as well, and are not getting there earlier
13.35.15 #       <LinusN> i had that exact problem with my non-flashed fm
13.35.36 #       <[IDC]Dragon> their loader is larger than mine, must take longer to descrable
13.36.09 #       <[IDC]Dragon> but the patch list is processed by the boot rom, before it descrambles
13.37.28 #       <[IDC]Dragon> the romless variant is different, that jump straight into my code
13.37.39 #       <[IDC]Dragon> jumps
13.49.12 Join    webguest98 [0] (~c31ce021@labb.contactor.se)
13.49.51 #       <[IDC]Dragon> LinusN: have you seen my question about filenames for the tuner split?
13.50.41 #       <[IDC]Dragon> the driver is currently called fmradio.c
13.51.29 #       <[IDC]Dragon> I locally added fmradio_i2c.c for the Philips physical interface
13.52.16 #       <[IDC]Dragon> plus 2 new fils, tuner_philips.c and tuner_samsung.c, for the locical driver (the abstraction layer)
13.52.58 #       <Zagor> is it probable that the fmradio_i2c.c code will be usable for another tuner?
13.53.14 #       <[IDC]Dragon> no, not really
13.53.46 #       <[IDC]Dragon> it transfers 5 bytes to/from a fixed I2C address
13.54.02 #       <Zagor> i'd rather have it called something with philips then
13.54.17 #       <[IDC]Dragon> like fmradio.c transfers 4 bytes via an SPI-ish protocol
13.54.28 #       <[IDC]Dragon> for the samsung tuner
13.54.49 #       <[IDC]Dragon> yes, renaming fmradio.c as well would be nicer
13.55.07 #       <Zagor> yes
13.55.33 #       <[IDC]Dragon> samsung_interface.c and philips_interface.c
13.55.58 #       <[IDC]Dragon> or even with S1A0903X01 and TEA5767?
13.55.59 #       <Zagor> is there really a point in putting those 100 lines of code into a separate file?
13.56.27 #       <[IDC]Dragon> that is the code to be ported, for another box
13.56.37 #       <[IDC]Dragon> the other code can stay
13.58.07 #       <[IDC]Dragon> I'd rather prefer to pick the files per model via SOURCES
13.58.37 #       <[IDC]Dragon> instead of #ifdef'ing two disjunct implementations
13.58.37 #       <amiconn> [IDC]Dragon: Speaking about the scrambling: When I tried to disassemble the archos rom yesterday, I noticed the scrambling. Is this the same scrambling algo that is used for .ajz?
13.58.59 #       <[IDC]Dragon> rom is unscrambled, flash is
13.59.10 #       <amiconn> s/rom/flash/
13.59.14 Quit    webguest98 ("CGI:IRC (EOF)")
13.59.17 #       <[IDC]Dragon> do you know my "extract" tool?
13.59.25 #       <amiconn> No?
13.59.37 #       <[IDC]Dragon> it's in the flash subdir
13.59.50 #       <[IDC]Dragon> an pulls a .ajz from a flash image
13.59.54 #       <[IDC]Dragon> and
14.00.32 #       <amiconn> Okay. I guess Iwon't need it now, since the init problems are solved. Maybe I have to use it again when I get to tackle the palyer flashing
14.01.02 #       <[IDC]Dragon> I have all that taken apart already
14.01.43 #       <Zagor> [IDC]Dragon: i assume there is a new tuner.h aswell?
14.02.12 #       <[IDC]Dragon> Zagor: yes, this defines the tuner-independent interface
14.03.45 #       <Zagor> do we have the philips radio datasheet?
14.03.53 #       <amiconn> [IDC]Dragon: I  got the archos fw flash version another way - unpacked the .ucl you provided :)
14.04.00 #       <[IDC]Dragon> yes, see the Ondio wiki page
14.04.22 #       <[IDC]Dragon> amiconn: that's another option, yes
14.05.10 #       <[IDC]Dragon> the flash contains the (scrambled) archos loader, plus this image
14.05.32 #       <[IDC]Dragon> Player don't have that loader, just one image
14.05.41 #       <[IDC]Dragon> Players
14.05.47 #       <Zagor> hmm I changed my mind. if fmradio_i2c.c is as simple as the current fmradio.c, I'd say fmradio_i2c is a good name.
14.07.05 #       <Zagor> while it's not certain it will be compatible with other i2c-connected radios, it's not really philips specific either
14.07.07 #       <amiconn> Zagor, LinusN: Speaking about the source tree - there is one file that imho should go into another folder
14.07.17 #       <LinusN> the philips data sheet is on the regular data sheet page as well
14.07.18 #       <[IDC]Dragon> the "full" name would rather be fmradio_ondio_tea5767
14.07.48 #       <[IDC]Dragon> I should merge the Ondio datasheets and port map
14.08.38 #       <Zagor> [IDC]Dragon: not unless it contains tea5767-specific code. which I understand it doesn't. no need to make the name more narrow than necessary.
14.09.01 #       <Zagor> LinusN: how is the tuner is connected to the cpu on the iriver?
14.09.13 #       <amiconn> dac.h is in firmware/drivers, while it should go into firmware/export
14.09.19 #       <LinusN> i2c bit-banging on port pins
14.09.33 #       <[IDC]Dragon> it does, it transfers 5 bytes (the packet for that tuner) to its specific I2C address
14.10.14 #       <[IDC]Dragon> it interfaces the tuner to a hardware
14.10.14 #       <Zagor> well we don't want a new file for the iriver if we can avoid it, do we?
14.10.49 #       <Zagor> the address can easily be a define, as can the port pins
14.11.08 #       <[IDC]Dragon> you at least have to adjust the port banging
14.11.38 #       <[IDC]Dragon> ok, then just fmradio_tea5767
14.11.49 #       <Zagor> why not i2c?
14.12.09 #       <[IDC]Dragon> because it's for this tuner
14.12.15 #       <Zagor> it's just transfer code, isn't it?
14.12.32 #       <[IDC]Dragon> a fixed 5 bytes to the fixed tuner address
14.13.00 #       <Zagor> <Zagor> the address can easily be a define
14.13.19 #       <[IDC]Dragon> and the 5 bytes too?
14.14.02 #       <Zagor> if we need to change it, we will. we'll solve that when we get to it.
14.14.16 #       <[IDC]Dragon> ok
14.14.52 #       <[IDC]Dragon> my local name still is fmradio_i2c.c, i was just evaluating this
14.22.46 #       <[IDC]Dragon> I gotta go
14.22.56 Quit    [IDC]Dragon ("CGI:IRC")
14.28.48 Join    edooo [0] (~edooo_188@82.129.244.5)
14.29.01 Quit    edooo (Remote closed the connection)
14.57.21 ***     Saving seen data "./dancer.seen"
15.09.19 Join    elinenbe [0] (~elinenbe_@65.115.46.225)
15.11.46 #       <amiconn> LinusN, Zagor: Got my remark about dac.h?
15.13.33 #       <Zagor> yes. i agree if we use it in apps
15.14.04 #       <LinusN> how do we solve it in a backwards-friendly way?
15.14.25 #       <LinusN> maybe it doesn't matter
15.14.26 #       <elinenbe> LinusN: nice work on the iriver... good luck with everything else.
15.14.40 #       <LinusN> exports is in the include path anyway
15.14.43 #       <LinusN> elinenbe: thanks
15.15.55 #       <amiconn> Zagor: dac.h is the only .h file in firmware/drivers , that's what I'm wondering about
15.16.42 #       <elinenbe> LinusN: what is the speed of the iriver CPU?
15.16.59 #       <LinusN> we can control it via software
15.17.21 #       <LinusN> up to roughly 120MHz i think
15.17.35 #       <LinusN> but we'll probably settle around 70 for mp3 playback
15.17.36 #       <elinenbe> LinusN: so it could be possible to achieve gameboy quality games on it then...
15.17.43 #       <LinusN> :-)
15.17.45 #       <Zagor> amiconn: the way I see it, if dac is only used by other drivers and not from apps code, it should stay there and not be exposed
15.18.00 #       <elinenbe> it has the resolution and the grayscale, the speed and the sound.
15.18.17 #       <LinusN> and the joystick :-)
15.18.28 #       <LinusN> but only 4-way
15.18.48 #       <elinenbe> can anyone say gameboy emulator?
15.18.49 #       <elinenbe> ;)
15.19.00 #       <LinusN> would be ninja-c00l
15.19.35 #       <elinenbe> it would b3 phr4k1ng c00l
15.27.19 #       <amiconn> Zagor: Ah ok. Didn't check yet whether it is used outside firmware/drivers
15.31.08 #       <amiconn> Zagor: It is not used from apps but from firmware (mpeg.c and mp3_playback.c)
15.32.01 Quit    Headie (Read error: 104 (Connection reset by peer))
15.46.41 Part    Zagor
15.47.14 Part    LinusN
16.02.24 Quit    elinenbe (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool")
16.05.44 Quit    midk (Read error: 104 (Connection reset by peer))
16.26.52 Quit    ashridah ("gone")
16.27.29 Join    methangas [0] (methangas@0x50c61d20.virnxx10.adsl-dhcp.tele.dk)
16.37.28 Join    MoGl53 [0] (mogle3@213.177.236.210.adsl.griffin.net.uk)
16.55.39 Quit    MoGle3 (Read error: 113 (No route to host))
16.57.03 Join    MoGle3 [0] (mogle3@213.177.236.210.adsl.griffin.net.uk)
16.57.22 ***     Saving seen data "./dancer.seen"
17.01.56 Join    uski [0] (~uski@lns-th2-5f-81-56-234-40.adsl.proxad.net)
17.13.52 Quit    MoGl53 (Read error: 113 (No route to host))
17.16.25 Join    mecraw__ [0] (~lmarlow@69.2.235.2)
17.20.26 Quit    MoGle3 (Read error: 113 (No route to host))
18.04.49 #       <einhirn> A little question: Now that we have MMC- and Fat16-Support due to the Ondio port, would it be possible to incoorporate an MMC-Card into the Jukebox recorder as "Battery extension"? I am just picking up an Idea that went through the Mailing list sometime 2002...
18.05.21 #       <uski> _battery_ extension ? what do you mean ?
18.06.03 #       <einhirn> Well, copy files from the Harddisk to the MMC card and play them from there. Long time no spin. Longer Battery time...
18.07.41 #       <uski> oh ok
18.07.56 #       <uski> i don't know how the MMC is connected to the CPU
18.08.14 #       <uski> i know that in the recorders there is not a lot of spare I/O pins
18.08.29 #       <uski> sth possible would be to connect the MMC on the same port than the LCD... adding a CS line
18.10.09 #       <einhirn> Hmm... something like that... But isn't the LCD-Bus too busy? I am speaking about lets say 64MB or so, copied while playing? I think the management would be a pain...
18.11.07 #       <uski> nope
18.11.18 #       <uski> 128kbps mp3 = only 16kbytes/sec
18.11.26 #       <uski> but that's the theory...
18.11.36 #       <uski> the lcdbus is extremely busy only while doing grayscale
18.11.51 #       <amiconn> MMC is serial, so if you do bit-banging, that's a lot of work...
18.12.02 #       <uski> right
18.12.20 #       <amiconn> In the Ondio, the MMC is hooked up on the serial port #1, so the remote control support would have to go for sure.
18.12.26 #       <uski> maybe i would be possible to add some small circuitry along with the MMC connector..
18.12.41 #       <einhirn> The guy on the Mailing list thought about using Compact flash since it comes with ATA-like interface. And then attaching it as slave to the Harddisk bus...
18.12.54 #       <uski> but it would be a pain to do
18.13.00 #       <uski> yes
18.13.47 #       <einhirn> I would even think about leaving out the mmc-connector... ;) I'd just solder thin wires to the card and stuff it inside the box...
18.14.03 #       <amiconn> Then the i2c clock has to be re-routed, since PB13 is needed for the serial clock
18.14.05 #       <uski> ah yea
18.14.35 #       <amiconn> Plus, we would have to find another free port pin to hook up the chip select
18.14.35 #       <uski> i think that if you want a long autonomy simply replace the HDD with a CompactFlash card.
18.15.19 #       <einhirn> Yep... Thought about that too, but I'd have to cut back with the Data storage...
18.16.01 #       <einhirn> OTOH, Seems like it would as hard to do as the 8mb-mod, if not harder...
18.16.13 #       <amiconn> I think the 8 MB mod clearly shows that extending the memory doesn't yield that much of additional runtime, since the hd is not the only power-sucker. With 8 MB you have a >4 times as large buffer, but the runtime increases by a mere ~22 %
18.16.37 #       <einhirn> ok...
18.17.30 #       <einhirn> Well, my box has still some saving potential: I can replace the original HDD with a power saving modern one...
18.18.26 #       <einhirn> It's just the tickling in the fingers, wanting to mod something on the Box, even if it doesn't make sense ;)
18.18.50 #       <amiconn> I have put in an 80 GB disk, and I have white backlight...
18.18.53 Join    _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
18.18.55 #       <einhirn> ;)
18.19.00 #       <_aLF> hi
18.57.26 ***     Saving seen data "./dancer.seen"
20.11.44 Join    Domonoky [0] (~trillian@pD9E41C4E.dip.t-dialin.net)
20.37.30 Quit    AciD (Connection reset by peer)
20.38.00 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
20.43.06 Quit    _aLF (Read error: 54 (Connection reset by peer))
20.43.40 Part    Domonoky
20.57.28 ***     Saving seen data "./dancer.seen"
21.47.10 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
21.52.56 Quit    einhirn (Read error: 54 (Connection reset by peer))
22.09.50 #       <scott666_> has anyone heard of this?
22.09.50 #       <scott666_> http://www.jetaudio.com/products/iaudio/m3/index.html
22.09.54 Nick    scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.21.13 Join    einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de)
22.29.33 Join    [IDC]Dragon [0] (~idc-drago@pD9FF8743.dip.t-dialin.net)
22.29.43 #       <amiconn> Hi again Jörg
22.30.04 #       <[IDC]Dragon> hi again
22.30.35 #       <amiconn> I just committed logarithmic scroll speed setting
22.31.13 #       <[IDC]Dragon> I never felt a need to adjust that...
22.31.41 #       <amiconn> This was an old idea of mine, and not hard to implement
22.32.24 #       <amiconn> Code size should be somewhat smaller again on Ondio (because of my powermgmt changes) - maybe rombox fits for you again
22.32.40 #       <[IDC]Dragon> it already does
22.33.03 #       <[IDC]Dragon> but I'm about to burst is againwith the 2nd tuner
22.33.11 #       <[IDC]Dragon> s/is/it
22.34.08 #       <amiconn> I still wonder how we should implement the 2-disk handling, without breaking the function api...
22.34.41 #       <[IDC]Dragon> which api?
22.35.24 #       <amiconn> Erm, the lower layers of the firmware (fat driver, ata driver). The functions therein would need an additional parameter
22.36.03 #       <[IDC]Dragon> yes, that's a bigger change
22.36.28 #       <[IDC]Dragon> dunno if and how it could be hidden from the other models
22.37.23 #       <amiconn> Yes, but that's my point here.
22.38.08 #       <amiconn> The hot-unplug dismount is much easier, but of no use without the 2-disk handling
22.39.37 #       <amiconn> I did additional power measurements with ram-based rockbox and added the results to the wiki table
22.40.06 #       <[IDC]Dragon> you'd either #ifdef the prototypes, too, or accept a useless parameter for the other models
22.41.28 #       * [IDC]Dragon reads wiki
22.41.32 #       <amiconn> Yup. However, #ifdef'ing the prototypes will add a whole lot of #ifdefs. Or I'd have to duplicate almost all code
22.42.25 #       <[IDC]Dragon> almost the same power figures, maybe a bit less for ROM
22.43.09 #       <amiconn> ? The figures are a bit less when running from RAM, except for card access. This sucks a bit more, but for a shorter time
22.43.10 #       <[IDC]Dragon> but interesting to know
22.49.12 Join    [av]bani [0] (~goemon@washuu.anime.net)
22.49.33 Part    [av]bani
22.53.09 #       <amiconn> [IDC]Dragon: I had an idea for making the flash plugins a bit more safe. They should only allow to flash if the battery level is safe. Imagine Ondio batteries running out of power while flashing...
22.57.32 ***     Saving seen data "./dancer.seen"
23.01.19 #       <[IDC]Dragon> yes, I could check that
23.01.49 #       <amiconn> There is already a function for that, it only needs to be exported to the plugin api
23.03.22 #       <amiconn> Ondio end-of-battery usually occurs suddenly.
23.54.40 Join    [av]bani [0] (~goemon@washuu.anime.net)
23.54.45 Part    [av]bani