Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2004-10-15

00:00:01harukiah yes, after running vbr-fix the file now lists as being ten minutes long
00:00:20amiconnyup. 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:29harukiwell thanks for helping me test this kludge ;)
00:01:57harukii wonder if that fellow who is implementing this feature is using the same methods...
00:02:02haruki;)
00:03:37amiconnI don't think so. A proper implementation would also allow to set a specific start time
00:04:08amiconn...even waking up the recorder at the right time if you either have the alarm mod or a v2/fm
00:05:34harukinow 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:51amiconnCutting mp3s is not that easy. First, cutting is only possible at frame boundaries
00:08:14amiconnIf 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:46amiconnBut it is certainly possible to implement that, even on the players
00:09:48harukiinteresting, 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:18amiconnharuki: There is already an mp3 split editor plugin, perhaps you can reuse some code
00:12:09amiconnBagder: U there now?
00:15:55harukithanks a lot amiconn!
00:16:39 Quit iRiverMan ("CGI:IRC (EOF)")
00:16:47amiconnnp
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:39amiconnYay! 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:00
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:30amiconnhi LinusN
01:30:36LinusNhi
01:41:55amiconnDid you notice my message about power drain with rockbox vs archos on Ondio?
01:42:39amiconnWe can expect ~40% longer battery life
01:47:05LinusNare you kidding?
01:47:27amiconnNope
01:47:41amiconnI wonder whether I should put the raw data into a wiki table
01:48:45amiconnI measured power consumption in various operating states and 2 different voltages with both firmwares
01:50:38LinusNwhy are we so much better?
01:51:25amiconnI 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:25amiconnSome nice values, at 4.6 V (maximum voltage): Browser, no scrolling lines - rockbox 54 mA, archos 90 mA
01:53:13amiconnWPS, no scrolling, (rockbox: peakmeter, high performance) - rockbox 65 mA, archos 92 mA
01:54:10amiconnPlayback, while reading from internal flash - rockbox 85 mA, archos 130 mA
01:54:21amiconn...
01:55:00LinusNcool
01:55:46amiconnI think this is a strong argument for rockbox on Ondio: "Wanna waste less money for batteries - use rockbox!"
01:57:33amiconnI'll put together a little table.
01:58:12LinusNyou said "did you notice my message"
01:58:17LinusNwhere was that?
01:59:20LinusNah
01:59:23LinusN<amiconn> Yay! Rockbox on Ondio is *significantly* more energy efficient than archos fw!
01:59:27amiconnyup
01:59:40LinusNmajpr coolness
02:00
02:01:29amiconnI hope Jörg will also do some measurements with his Ondio FM, for comparison. I expect similar figures
02:02:32amiconnI did thgat measurements mainly because I want to adapt the power thread runtime estimation
02:02:35amiconn*that
02:02:39 Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)")
02:04:58amiconnThe 10 hours given by archos are rather optimistic... with their firmware
02:06:51amiconnMulti-volume browsing would be the 2nd killer feature...
02:15:49LinusNabsolutely
02:17:26amiconnRe your latest commit: More viewers coming up?
02:21:21amiconnWe have an all-green build table :)
02:25:14LinusNyes, the menu had a maximum of 8, and viewers.txt had 8 also, so we couldn't add more
02:25:42LinusNfavorites.rock is next to be added
02:27:16amiconnThat reminds me I should finally do that .bmp loader...
02:35:58amiconnCurrent measurement table done.
02:45:55amiconnTts, cu
02:46:25 Part amiconn
02:57:06***Saving seen data "./dancer.seen"
03:00
03:36:33 Join MisticJeff [0] (~0c68cc30@labb.contactor.se)
03:36:46MisticJeffhowdy
03:36:54LinusNhola
03:37:03MisticJeffwhat's new?
03:37:49LinusNsiting here, debugging the threading code on my iriver
03:38:00MisticJeffwow, lots of fun
03:38:20MisticJeffim at work
03:38:29MisticJeffjust checking in, gotta run
03:39:06MisticJeffsee 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:00
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:00
05:55:11 Quit _Lucretia (Read error: 60 (Operation timed out))
06:00
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:00
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:00
08:05:13 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
08:05:48[IDC]Dragon'morning!
08:05:54LinusNhi
08:06:22[IDC]Dragondo you sleep at all?
08:06:29LinusNnot really :-)
08:06:49[IDC]Dragonwish I could do that
08:06:56LinusNme too :-)
08:09:16[IDC]DragonJens' all green build table has a stain again
08:09:26LinusNyeah, my fault
08:18:34[IDC]DragonI wonder why Rockbox consumes such significantly less power on the Ondio
08:18:49LinusNprobably the SLEEP in the threading code
08:19:03[IDC]DragonI once was comparing sleeping CPU vs. 100% busy, that was just a few mA
08:19:16LinusNhmmm
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:26amiconnMorning all
08:44:56LinusNhi
08:45:53[IDC]Dragonmorning Jens
08:46:22[IDC]DragonI haven't described my daily morning routine to you guys:
08:46:52[IDC]Dragonwhile still dark in the bedroom, I reach for my webpad, to check what you guys did last night
08:48:05[IDC]Dragonmakes me feel like a lamer sometimes, when I went to bed like 4 hours earlier
08:48:29LinusN4 hours! luxury!
08:50:05[IDC]Dragonindeed
08:50:22[IDC]Dragonwith no kids, I have no such training
08:50:28LinusN:-)
08:50:56 Join Zagor [242] (~bjst@labb.contactor.se)
08:51:12LinusNmorning Zagor
08:52:04Zagormorning
08:53:14[IDC]Dragonyawning
08:53:36*Bagder enters
08:53:41Bagderhi crowd
08:53:56amiconn[IDC]Dragon: Also no kids here...
08:53:59[IDC]Dragonhi
08:54:10[IDC]Dragonamiconn: I guessed
08:54:25[IDC]Dragona woman?
08:54:38amiconnnope
08:55:02[IDC]Dragonnow I know the secret of Jens' hacking resourcefulness
08:56:00LinusNhi Bagder
08:56:28*Bagder only has one child, LinusN has two!
08:57:11***Saving seen data "./dancer.seen"
08:58:55[IDC]Dragonamiconn: nice catch on the inits
08:59:17amiconn[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]DragonI can try, yes
09:00
09:00:15[IDC]Dragonor rather, do that (not much trying involved)
09:00:49dwihnoBagder only has one child, LinusN ;)
09:02:09amiconn[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]Dragonwhy is the order important?
09:03:20LinusNspeaking of instability, i debugged the coldfire threading code for over an hour, with the DRAM refresh turned off :-)
09:03:34[IDC]Dragonoops
09:03:34*Bagder giggles
09:03:46[IDC]Dragonhow long does it last without?
09:04:24[IDC]Dragonin the past, I found DRAMS very remarkably tolerant
09:05:02LinusNthat's why i didn't notice at first
09:05:11LinusNit lasted for minutes
09:05:34[IDC]Dragonwhow
09:05:50 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
09:05:57LinusNone or two bit faults here and there
09:07:05[IDC]Dragonamiconn: your power tests were with rombox, or reguler?
09:08:34amiconnrombox
09:09:24[IDC]Dragondid you compare rombox vs. "rambox"?
09:12:13Bagderwhoa openneo commits
09:12:24dwihnospeaking of nothing, rombox still stuffers from rld (I recall someone mentioning something about rld decrease after rombox)
09:12:44Bagder"Heap size increased to 63 KB"
09:12:46Bagderhehe
09:13:41LinusNthey are slowly sinking into the dynamic memory swamp
09:13:46Bagder"Added support for autoexec.cfg"
09:14:41BagderLinusN: indeed
09:14:55Bagderwith 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:20amiconn[IDC]Dragon: No I didn't compare, didn't think of it. Seems like a good thing to try...
10:00
10:02:51amiconnLinusN: Congrats on the iRiver progress, btw.
10:07:07LinusNit'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:41amiconnFor 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:34LinusNtrue, but you have done a remarkable job with the MMC driver
10:09:38LinusNand FAT16
10:09:45Zagorthe offer to sponsor your ondios is still valid, btw.
10:16:14[IDC]DragonOndio wasn't porting, rather "adjusting"
10:17:32[IDC]DragonZagor: thanks for the offer, I come back to that when we have users, and possibly donations from them
10:20:44[IDC]Dragonright now, ondio rockbox is a solution in search for the problem
10:20:55LinusNno
10:21:19LinusNit's a fun project for you and Jens, and Rockbox benefits from it
10:21:52[IDC]Dragonbesides that, sure ;-)
10:22:07Zagorit's also a good test bench for some of the port preparations, such as the build tools and the button code
10:23:35amiconnSpeaking 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:46LinusNwonderful
10:24:11amiconnQ: Do you agree that after this is done, usb_screen() should be ditched from the plugin api?
10:27:18LinusNmaybe
10:27:41LinusNif there isn't any use for it
10:28:18[IDC]Dragonare you happy with the cleanup callback?
10:28:20LinusNmy original idea was that the plugin should "grab" the events itself if it didn't want/like the default handling
10:28:42LinusN(like if there was a need for cleanup)
10:28:50LinusNthe callback solves most of these problems
10:29:10LinusNso i think the usb screen can go
10:29:41LinusNmy original idea looked like this:
10:29:52LinusNcase SYS_USB_INSERTED:
10:30:00LinusN cleanup();
10:30:15LinusN default_handler(SYS_USB_INSERTED);
10:30:19LinusN break;
10:30:54amiconnI first considered this approach, but there is a problem with it.
10:30:58LinusNhowever, the callback idea might be better since we don't have to add new cases for new events that need cleanup
10:31:07amiconnYes, that's the point
10:31:29LinusNand we can still do it "my way" if there is a need for it
10:32:04LinusNusb_screen() isn't directly called with my method either
10:35:03amiconnThe 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:41amiconn..and then do the following in the plugin:
10:35:54amiconnif (is_default_event(event) {
10:36:00amiconncleanup();
10:36:11amiconndefault_event_handler(event);
10:36:13amiconn}
10:44:39LinusNnah
10:45:04LinusNi admit that it's "cleaner", but i can live with the callback as well
10:47:14[IDC]Dragonbut this readsmore KISS
10:49:13amiconn?
10:49:27LinusNin the KISS sense, i'd say is_default_event() is to prefer
10:49:41[IDC]Dragonyou better see what's going on
10:49:48LinusNyup
10:57:13***Saving seen data "./dancer.seen"
10:58:01amiconnSo 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:42LinusNyes, but they can reside in the same file (misc.c)
10:59:14amiconnOf course
10:59:26LinusNstill, it isn't waterproof, as not all (future) default events would need a cleanup
11:00
11:00:27LinusNbut 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]Dragonthen call it needs_cleanup() or so
11:04:33[IDC]Dragonit can call default_event_handler() by itself if not
11:05:06LinusNlet's keep the callback
11:05:25[IDC]Dragonbut this is a bit ugly again, because only in the cleanup case you'd have to call default_event_handler() afterwards
11:05:25LinusNthen the default handler can decide if it has to call the cleanup function or not
11:12:05amiconnLinusN: That's like it is now
11:14:29LinusNyes
11:15:32amiconnOr 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:24LinusNnah, let's keep the current solution, and we'll expand it if the need arises
12:00
12:33:38 Quit scott666_ ("i'll be back...eventually...")
12:54:07[IDC]DragonLinusN: want to have a final word about file/function names for the tuner split?
12:57:17***Saving seen data "./dancer.seen"
13:00
13:01:15 Join Norrin [0] (~440d6a3e@labb.contactor.se)
13:01:42 Join Nuxator [0] (~chatzilla@pc102.ie2.u-psud.fr)
13:02:15NorrinHello 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:38LinusNhow long have you tried to charge it?
13:02:46LinusNhave you flashed rockbox?
13:02:47NorrinWhen I plug in the charger, nothing comes on the screen and you can just hear it clicking. Let it on overnight.
13:03:11NorrinYep, I've been using Rockbox for a while now.
13:03:48Nuxatorhello all
13:03:50NorrinI've tried holding F1 when I plug it in along with pressing the ON and OFF buttons, it's dead.
13:03:54LinusNtry to hold F1 when you insert the charger
13:03:58LinusN:-)
13:04:14LinusNalso try to insert the USB cable as well
13:04:20Nuxatorjust wanted to show support to linusN for iriver port
13:04:27LinusNNuxator: thanks
13:04:47Nuxatori see that screen is blicking ;)
13:04:57LinusNNuxator: blink blink
13:04:57Nuxatornext step hello world
13:05:29Nuxatorkeep going this good work see you
13:06:49 Quit Nuxator ("ChatZilla 0.8.31 [Mozilla rv:1.4.1/20031008]")
13:07:59NorrinTried 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:31LinusNtry to extract the battery and insert it again
13:09:11NorrinI 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]DragonI wonder how this still happens, and if I can improve somehow
13:11:50ZagorI don't see what we can do on the LiIon models
13:12:23[IDC]Dragonshutdown the HD even earlier?
13:13:01[IDC]Dragonright now it's done by the bootloader, if charger plugged
13:14:03[IDC]Dragonit could be done by the flash "patch list", which is processed by the boot ROM, but then unconditional
13:14:56[IDC]Dragonthe boot loader would have to conditionally switch it on again
13:19:18LinusNwe should try that
13:19:49[IDC]Dragonso far, I stayed away from that patch list
13:22:59Zagorhow long do we have the disk on today?
13:23:05Zagor100ms? 50?
13:23:22[IDC]Dragonsomething it that range, perhaps
13:23:43[IDC]Dragonas long as it takes the boot rom to descramble my bootloader
13:24:02[IDC]Dragonplus some reset holdoff time
13:24:08Zagorwhat was the reason the bootloader enables it?
13:24:33[IDC]Dragonit doesn't, it disables it if the charger is plugged
13:24:45[IDC]Dragonthe disk is on by hardware default
13:25:19Zagorso how fast does the archos firmware turn it off?
13:25:42[IDC]Dragonslower
13:26:23ZagorI thought using F1+ON was used as a "safe boot" for rundown batteries. is that not the case?
13:27:53[IDC]Dragonit is a safe mode for misflashed ucl, primarily
13:29:32Zagoryes, 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:23LinusNi have had the same problem with my fm, and it isn't even flashed
13:31:46[IDC]Dragonon sw charge controlled models, archos charges right away, vs. we are hesitating
13:32:04Zagorah ok
13:33:52[IDC]Dragonnone-flashed FMs are probably prone to flat batteries, too
13:34:26[IDC]Dragonsince Archos has to shut off the disk as well, and are not getting there earlier
13:35:15LinusNi had that exact problem with my non-flashed fm
13:35:36[IDC]Dragontheir loader is larger than mine, must take longer to descrable
13:36:09[IDC]Dragonbut the patch list is processed by the boot rom, before it descrambles
13:37:28[IDC]Dragonthe romless variant is different, that jump straight into my code
13:37:39[IDC]Dragonjumps
13:49:12 Join webguest98 [0] (~c31ce021@labb.contactor.se)
13:49:51[IDC]DragonLinusN: have you seen my question about filenames for the tuner split?
13:50:41[IDC]Dragonthe driver is currently called fmradio.c
13:51:29[IDC]DragonI locally added fmradio_i2c.c for the Philips physical interface
13:52:16[IDC]Dragonplus 2 new fils, tuner_philips.c and tuner_samsung.c, for the locical driver (the abstraction layer)
13:52:58Zagoris it probable that the fmradio_i2c.c code will be usable for another tuner?
13:53:14[IDC]Dragonno, not really
13:53:46[IDC]Dragonit transfers 5 bytes to/from a fixed I2C address
13:54:02Zagori'd rather have it called something with philips then
13:54:17[IDC]Dragonlike fmradio.c transfers 4 bytes via an SPI-ish protocol
13:54:28[IDC]Dragonfor the samsung tuner
13:54:49[IDC]Dragonyes, renaming fmradio.c as well would be nicer
13:55:07Zagoryes
13:55:33[IDC]Dragonsamsung_interface.c and philips_interface.c
13:55:58[IDC]Dragonor even with S1A0903X01 and TEA5767?
13:55:59Zagoris there really a point in putting those 100 lines of code into a separate file?
13:56:27[IDC]Dragonthat is the code to be ported, for another box
13:56:37[IDC]Dragonthe other code can stay
13:58:07[IDC]DragonI'd rather prefer to pick the files per model via SOURCES
13:58:37[IDC]Dragoninstead of #ifdef'ing two disjunct implementations
13:58:37amiconn[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]Dragonrom is unscrambled, flash is
13:59:10amiconns/rom/flash/
13:59:14 Quit webguest98 ("CGI:IRC (EOF)")
13:59:17[IDC]Dragondo you know my "extract" tool?
13:59:25amiconnNo?
13:59:37[IDC]Dragonit's in the flash subdir
13:59:50[IDC]Dragonan pulls a .ajz from a flash image
13:59:54[IDC]Dragonand
14:00
14:00:32amiconnOkay. 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]DragonI have all that taken apart already
14:01:43Zagor[IDC]Dragon: i assume there is a new tuner.h aswell?
14:02:12[IDC]DragonZagor: yes, this defines the tuner-independent interface
14:03:45Zagordo we have the philips radio datasheet?
14:03:53amiconn[IDC]Dragon: I got the archos fw flash version another way - unpacked the .ucl you provided :)
14:04:00[IDC]Dragonyes, see the Ondio wiki page
14:04:22[IDC]Dragonamiconn: that's another option, yes
14:05:10[IDC]Dragonthe flash contains the (scrambled) archos loader, plus this image
14:05:32[IDC]DragonPlayer don't have that loader, just one image
14:05:41[IDC]DragonPlayers
14:05:47Zagorhmm 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:05Zagorwhile it's not certain it will be compatible with other i2c-connected radios, it's not really philips specific either
14:07:07amiconnZagor, LinusN: Speaking about the source tree - there is one file that imho should go into another folder
14:07:17LinusNthe philips data sheet is on the regular data sheet page as well
14:07:18[IDC]Dragonthe "full" name would rather be fmradio_ondio_tea5767
14:07:48[IDC]DragonI should merge the Ondio datasheets and port map
14:08:38Zagor[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:01ZagorLinusN: how is the tuner is connected to the cpu on the iriver?
14:09:13amiconndac.h is in firmware/drivers, while it should go into firmware/export
14:09:19LinusNi2c bit-banging on port pins
14:09:33[IDC]Dragonit does, it transfers 5 bytes (the packet for that tuner) to its specific I2C address
14:10:14[IDC]Dragonit interfaces the tuner to a hardware
14:10:14Zagorwell we don't want a new file for the iriver if we can avoid it, do we?
14:10:49Zagorthe address can easily be a define, as can the port pins
14:11:08[IDC]Dragonyou at least have to adjust the port banging
14:11:38[IDC]Dragonok, then just fmradio_tea5767
14:11:49Zagorwhy not i2c?
14:12:09[IDC]Dragonbecause it's for this tuner
14:12:15Zagorit's just transfer code, isn't it?
14:12:32[IDC]Dragona fixed 5 bytes to the fixed tuner address
14:13:00Zagor<Zagor> the address can easily be a define
14:13:19[IDC]Dragonand the 5 bytes too?
14:14:02Zagorif we need to change it, we will. we'll solve that when we get to it.
14:14:16[IDC]Dragonok
14:14:52[IDC]Dragonmy local name still is fmradio_i2c.c, i was just evaluating this
14:22:46[IDC]DragonI 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:00
15:09:19 Join elinenbe [0] (~elinenbe_@65.115.46.225)
15:11:46amiconnLinusN, Zagor: Got my remark about dac.h?
15:13:33Zagoryes. i agree if we use it in apps
15:14:04LinusNhow do we solve it in a backwards-friendly way?
15:14:25LinusNmaybe it doesn't matter
15:14:26elinenbeLinusN: nice work on the iriver... good luck with everything else.
15:14:40LinusNexports is in the include path anyway
15:14:43LinusNelinenbe: thanks
15:15:55amiconnZagor: dac.h is the only .h file in firmware/drivers , that's what I'm wondering about
15:16:42elinenbeLinusN: what is the speed of the iriver CPU?
15:16:59LinusNwe can control it via software
15:17:21LinusNup to roughly 120MHz i think
15:17:35LinusNbut we'll probably settle around 70 for mp3 playback
15:17:36elinenbeLinusN: so it could be possible to achieve gameboy quality games on it then...
15:17:43LinusN:-)
15:17:45Zagoramiconn: 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:00elinenbeit has the resolution and the grayscale, the speed and the sound.
15:18:17LinusNand the joystick :-)
15:18:28LinusNbut only 4-way
15:18:48elinenbecan anyone say gameboy emulator?
15:18:49elinenbe;)
15:19:00LinusNwould be ninja-c00l
15:19:35elinenbeit would b3 phr4k1ng c00l
15:27:19amiconnZagor: Ah ok. Didn't check yet whether it is used outside firmware/drivers
15:31:08amiconnZagor: 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:00
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:00
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:00
18:04:49einhirnA 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:21uski_battery_ extension ? what do you mean ?
18:06:03einhirnWell, copy files from the Harddisk to the MMC card and play them from there. Long time no spin. Longer Battery time...
18:07:41uskioh ok
18:07:56uskii don't know how the MMC is connected to the CPU
18:08:14uskii know that in the recorders there is not a lot of spare I/O pins
18:08:29uskisth possible would be to connect the MMC on the same port than the LCD... adding a CS line
18:10:09einhirnHmm... 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:07uskinope
18:11:18uski128kbps mp3 = only 16kbytes/sec
18:11:26uskibut that's the theory...
18:11:36uskithe lcdbus is extremely busy only while doing grayscale
18:11:51amiconnMMC is serial, so if you do bit-banging, that's a lot of work...
18:12:02uskiright
18:12:20amiconnIn 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:26uskimaybe i would be possible to add some small circuitry along with the MMC connector..
18:12:41einhirnThe 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:54uskibut it would be a pain to do
18:13:00uskiyes
18:13:47einhirnI 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:03amiconnThen the i2c clock has to be re-routed, since PB13 is needed for the serial clock
18:14:05uskiah yea
18:14:35amiconnPlus, we would have to find another free port pin to hook up the chip select
18:14:35uskii think that if you want a long autonomy simply replace the HDD with a CompactFlash card.
18:15:19einhirnYep... Thought about that too, but I'd have to cut back with the Data storage...
18:16:01einhirnOTOH, Seems like it would as hard to do as the 8mb-mod, if not harder...
18:16:13amiconnI 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:37einhirnok...
18:17:30einhirnWell, my box has still some saving potential: I can replace the original HDD with a power saving modern one...
18:18:26einhirnIt's just the tickling in the fingers, wanting to mod something on the Box, even if it doesn't make sense ;)
18:18:50amiconnI 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:55einhirn;)
18:19:00_aLFhi
18:57:26***Saving seen data "./dancer.seen"
20:00
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:00
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:00
22:09:50scott666_has anyone heard of this?
22:09:50scott666_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:43amiconnHi again Jörg
22:30:04[IDC]Dragonhi again
22:30:35amiconnI just committed logarithmic scroll speed setting
22:31:13[IDC]DragonI never felt a need to adjust that...
22:31:41amiconnThis was an old idea of mine, and not hard to implement
22:32:24amiconnCode size should be somewhat smaller again on Ondio (because of my powermgmt changes) - maybe rombox fits for you again
22:32:40[IDC]Dragonit already does
22:33:03[IDC]Dragonbut I'm about to burst is againwith the 2nd tuner
22:33:11[IDC]Dragons/is/it
22:34:08amiconnI still wonder how we should implement the 2-disk handling, without breaking the function api...
22:34:41[IDC]Dragonwhich api?
22:35:24amiconnErm, the lower layers of the firmware (fat driver, ata driver). The functions therein would need an additional parameter
22:36:03[IDC]Dragonyes, that's a bigger change
22:36:28[IDC]Dragondunno if and how it could be hidden from the other models
22:37:23amiconnYes, but that's my point here.
22:38:08amiconnThe hot-unplug dismount is much easier, but of no use without the 2-disk handling
22:39:37amiconnI did additional power measurements with ram-based rockbox and added the results to the wiki table
22:40:06[IDC]Dragonyou'd either #ifdef the prototypes, too, or accept a useless parameter for the other models
22:41:28*[IDC]Dragon reads wiki
22:41:32amiconnYup. 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]Dragonalmost the same power figures, maybe a bit less for ROM
22:43:09amiconn? 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]Dragonbut interesting to know
22:49:12 Join [av]bani [0] (~goemon@washuu.anime.net)
22:49:33 Part [av]bani
22:53:09amiconn[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:00
23:01:19[IDC]Dragonyes, I could check that
23:01:49amiconnThere is already a function for that, it only needs to be exported to the plugin api
23:03:22amiconnOndio end-of-battery usually occurs suddenly.
23:54:40 Join [av]bani [0] (~goemon@washuu.anime.net)
23:54:45 Part [av]bani

Previous day | Next day