00:01:30 | | Quit unique311 ("I am Using Ebless ScripT v8 Special For Ops, If you Want Best Channel Protection, DownLoad your Copy From - http://i.am/Ebles") |
00:02:37 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
00:05:03 | | Quit Febs ("CGI:IRC (EOF)") |
00:06:58 | preglow | linuxstb: i assume we'll stuff all ipod lcd drivers into one file, or? |
00:07:10 | preglow | so i don't need to call it lcd-ipod-colornano.c or whatever |
00:08:09 | linuxstb | I was thinking the same thing - one generic lcd-ipod.c file. |
00:08:30 | | Quit Jungti1234 ("Good Bye~ http://cafe.naver.com/iriverh300") |
00:09:09 | linuxstb | Even if we support every single ipod lcd, I think that file will still be quite small. |
00:09:27 | preglow | yeah, should be |
00:09:37 | preglow | at least, lets just pretend that's the plan for now |
00:09:50 | preglow | we can branch and rename as much as we like when subversion is in place anyway! |
00:09:56 | * | preglow tickles Bagder |
00:10:04 | linuxstb | hehe. Where has Bagder gone? |
00:10:23 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
00:10:28 | * | Bagder stands far far away in the corner looking at linuxstb and preglow |
00:11:00 | amiconn | linuxstb: If the 2bit ipod lcd has horizontal pixel blocks, it would be the first platform with a different mono_bitmap and font format |
00:11:24 | | Quit BirdFish (Read error: 110 (Connection timed out)) |
00:13:25 | linuxstb | amiconn: True. I'm glad I decided to buy a colour model. |
00:13:36 | XavierGr | why if pu a button sniffing loop in my thread the system becomes unresponsive? |
00:13:49 | XavierGr | ^^ if I put |
00:13:52 | amiconn | How do you do the sniffing? |
00:14:11 | XavierGr | button = rb->button_get(true); |
00:14:20 | amiconn | I hope you don't use button_get() ... |
00:14:21 | XavierGr | then switch and all in a while |
00:14:24 | Bagder | haha |
00:14:31 | XavierGr | oops |
00:14:35 | preglow | i love all the colours |
00:14:36 | amiconn | button_get() will eat the button events |
00:14:50 | preglow | linuxstb: do i need to use itunes to get photos on this little bastard as well? |
00:14:53 | XavierGr | any alternative? |
00:14:59 | preglow | man, how i hate itunes |
00:15:46 | * | amiconn is undecided whether he should commit a small change that helps grayscale_lib speed, but needs 320 bytes of iram just for that |
00:15:59 | amiconn | (in the core) |
00:16:07 | preglow | no!!! |
00:16:08 | XavierGr | haha, preglow suffer, for you blasphemous choice, you shall be tortured by idiot proof programs and i-tunes alike for your punishment... |
00:16:08 | preglow | :-) |
00:16:26 | preglow | amiconn: how much does it speed it up? |
00:16:31 | XavierGr | :D |
00:16:55 | amiconn | It's not easily possible to tell |
00:16:58 | preglow | XavierGr: idiot proof? i had to use five bloody minutes to figure out how to sync my ipod to my collection |
00:17:19 | preglow | most unintuitive piece of coding i ever saw |
00:17:23 | preglow | may it suffer in hell |
00:17:41 | preglow | and steve jobs be found crying in purgatory |
00:17:41 | amiconn | lcd_blit() uses two line-block buffers to spread a mono bitmap to 2bit. Right now it uses the stack, but the grayscale lib uses lcd_blit() from within an ISR, |
00:17:42 | XavierGr | amiconn: anyway I don't need button sniffing at all. Just a way to figure how it will be triggered when the HD spins up. |
00:17:55 | XavierGr | preglow: indeed... |
00:18:05 | amiconn | and it will use the stack of whatever thread will be active at that moment |
00:18:23 | amiconn | The stack might be in iram or not |
00:18:42 | preglow | ouch |
00:18:42 | | Join ashridah [0] (i=ashridah@220-253-122-35.VIC.netspace.net.au) |
00:18:45 | preglow | i'd say use the iram |
00:19:01 | preglow | if only because i plan on riding the stack limits pretty damn close in the codecs ;) |
00:19:06 | amiconn | I simply reserve the 2 line-block buffers statically now, with IBSS_ATTR |
00:19:20 | amiconn | Yeah, 320 bytes |
00:20:01 | preglow | i also happen to think the grayscale lib is a bit too sluggish at 45mhz |
00:20:08 | linuxstb | reglow: I have no idea about photos - never tried them. |
00:20:52 | preglow | man, does my h120 feel like a clunky brick after using the nano |
00:22:13 | XavierGr | yes but only 2 gigs |
00:23:47 | preglow | more than enough |
00:24:16 | XavierGr | I disagree on tha |
00:24:27 | XavierGr | except if you have it for specific use |
00:24:59 | preglow | i just want a lighter player for when i don't wnat to carry the clunky brick |
00:25:02 | preglow | like short walks, etc |
00:25:10 | amiconn | preglow: Put some flacs on it ;) |
00:25:16 | preglow | haha |
00:25:26 | XavierGr | some wise man once said: |
00:25:32 | preglow | all my test files will probably use 1/4 of the space |
00:25:51 | XavierGr | iHP series is like Vovlo cars |
00:26:07 | preglow | ihp is swedish!? |
00:26:16 | XavierGr | big like a brick and it will survive a hit with a metorite.... |
00:26:20 | preglow | hahah |
00:26:22 | preglow | tell that to amiconn |
00:26:38 | preglow | i think he's got a select couple of words to tell you about it's sturdiness |
00:26:43 | * | amiconn has to disagree |
00:26:44 | preglow | its! |
00:26:56 | XavierGr | well he is the exception that validates the rule |
00:27:18 | amiconn | The H1x0's hd shock protection leaves quite something to be desired |
00:27:44 | amiconn | preglow: My test files wouldn't fit completely on your nano |
00:27:50 | XavierGr | well comapring to other DAP I think that this beautie is quite strong |
00:28:02 | | Join BirdFish [0] (n=bradbox8@64.108.5.134) |
00:28:14 | amiconn | The case itself is. The hd shock protection is not |
00:28:23 | XavierGr | and don't forget amiconn that you are the exception on that. Many users have reported drops without a failure, (major drops) |
00:28:50 | XavierGr | I still think that you stood unlucky |
00:28:54 | amiconn | ...and the fact that the case is quite slippy doesn't exactly keep it from dropping |
00:30:09 | XavierGr | slippy case? I think that you exaggerate a little... |
00:30:16 | preglow | amiconn: at least we wont have to do tests to ascertain the feasability of a sleep mode for the ipods |
00:30:27 | preglow | amiconn: since the damn buggers never turn themselves off by default |
00:30:29 | amiconn | zzzzzzzzzzzzzzzzzzzzzzzzzz...................... |
00:30:31 | XavierGr | and if you use the case that comes with it there will be no problems |
00:30:54 | amiconn | Yeah, but the leather case doesn't give access to the reset button |
00:31:21 | XavierGr | that's true, that's why I modded mine first and then bought an outro case |
00:31:26 | amiconn | ...and with the flap closed, operation the joystick is difficult |
00:31:35 | XavierGr | which leaves all ports accesable, plus protects the screen. |
00:31:44 | BirdFish | regarding firmware and the hex code that associates, is there ever any pattern to look for? |
00:31:53 | BirdFish | regarding images |
00:31:56 | preglow | nope |
00:32:15 | BirdFish | know of any good disassemblers for the iaudio x5 |
00:32:16 | BirdFish | ? |
00:32:26 | Bagder | BirdFish: objdump |
00:32:45 | Bagder | its plain unscrambled coldfire code afair |
00:32:53 | BirdFish | Badger: thank you :) |
00:35:52 | linuxstb | The shorten codec takes the prize for smallest codec (apart from WAV). shorten.codec is 18472 bytes. |
00:36:02 | preglow | linuxstb: what should the naming scheme be? lcd_xxx -> lcd_ipod_xxx? |
00:36:04 | Bagder | :-) |
00:36:20 | preglow | forget it |
00:36:44 | preglow | will there be any code in lcd-16bit.c at all? just helpers? |
00:36:57 | linuxstb | It's all the code that draws into the framebuffer. |
00:37:04 | preglow | 'course |
00:37:20 | BirdFish | Badger: has objdump been ported to windows? |
00:37:34 | linuxstb | I think it's just lcd_init() and lcd_update_rect() that need to be moved (plus their dependencies) |
00:37:36 | preglow | objdump has been ported to just about everything |
00:39:26 | Bagder | BirdFish: objdump is part of GNU binutils |
00:40:15 | Bagder | BirdFish: follow the rockbox build instructions for cygwin and wham, you'll have it |
00:40:37 | _FireFly_ | it works :) |
00:40:46 | _FireFly_ | my wps-widget ;) |
00:40:50 | XavierGr | what? |
00:40:51 | preglow | woot |
00:40:53 | XavierGr | wps |
00:41:00 | XavierGr | yay |
00:41:08 | XavierGr | without bugs? |
00:41:25 | XavierGr | major one at least... |
00:41:26 | * | preglow looks forward to seeing all the outl()s go |
00:41:47 | * | XavierGr looks forware to finally use the remote |
00:42:12 | _FireFly_ | the problem was i had forgotten tath there are two init functions one for simn and one for target ;) |
00:42:37 | _FireFly_ | and the init functions for wps was only on the init for the sim ;) |
00:42:57 | XavierGr | Hurry and find TiMiD. |
00:43:15 | XavierGr | or do you have cvs access? |
00:43:32 | _FireFly_ | no |
00:44:04 | XavierGr | then discuss it with Timid to see if there are any left overs. |
00:45:09 | _FireFly_ | i will make one test then have to go to bed ;) |
00:45:23 | XavierGr | ah then tomorrow |
00:45:34 | XavierGr | what is left for the remote so far? |
00:45:53 | XavierGr | radio ,plugins (i don't count that) and what else? |
00:46:40 | _FireFly_ | radio, playlist-viewer, the quick-screen , onplay-screen |
00:47:35 | _FireFly_ | i don't know if my code is bugfree for this more testing is needed |
00:47:40 | amiconn | Imho plugins should handle the remote in whatever way they see fit |
00:48:04 | amiconn | The core should just clear the remote lcd before calling the plugin, like it does with the main lcd |
00:48:19 | amiconn | _FireFly_: and recording screen |
00:48:22 | XavierGr | _FireFly_: you use a different wps for the remote? |
00:48:30 | amiconn | (not yet used on iriver, but it will be) |
00:48:32 | XavierGr | or the same that it will chop what it can't fit? |
00:48:43 | _FireFly_ | and maybe display a text that plugins should use the remote if needed |
00:48:56 | _FireFly_ | XavierGr: yepp |
00:49:06 | _FireFly_ | the default wps is similar to the main |
00:49:25 | preglow | linuxstb: do you think it's safe for me to remove all the ifdef SIMULATOR? doesn't the sims use their own lcd drivers? |
00:49:34 | amiconn | nope |
00:49:41 | preglow | can't imagine why they'd want to compile lcd-ipod.c ... |
00:49:54 | amiconn | The simulator uses the lcd framebuffer the same way as the target |
00:50:00 | preglow | well, sure |
00:50:07 | preglow | but they don't need to compile lcd-ipod.c to use it |
00:50:07 | amiconn | The simulator code picks up the image from there |
00:50:12 | preglow | yes, yes |
00:50:17 | preglow | but it doesn't use the ipod driver |
00:50:26 | preglow | so it makes no sense for there to be ifdef SIMULATOR in there |
00:50:31 | amiconn | If it is defined in lcd-16bit.c, then it should work ok |
00:50:32 | _FireFly_ | the peakmeter is also left currently i have the peakmeter only for the main screen aktivate-able |
00:50:47 | preglow | amiconn: it isn't, i'm working on removing the ipod specific parts from lcd-16bit.c |
00:50:58 | amiconn | Yes I know |
00:51:22 | _FireFly_ | ok time for bed good night everybody |
00:51:28 | preglow | as i see it, sims will compile lcd-16bit.c but not lcd-ipod.c |
00:52:04 | | Quit _FireFly_ ("Leaving") |
00:52:53 | preglow | i'll just go ahead and fix the eight level indents the ipod people use as well |
00:54:25 | preglow | amiconn: but agreed, yes? SIMULATOR checks might be needed in lcd-16bit.c, but not lcd-ipod.c, lcd-h300.c, etc |
00:54:35 | amiconn | yes |
00:54:38 | preglow | goodie |
00:54:43 | preglow | i need to start using the sims |
00:55:19 | amiconn | Hmm, iiuc there were some problems with the sims on amd64? |
00:55:29 | preglow | yes |
00:55:30 | preglow | afaik |
00:55:39 | preglow | long since i tried |
00:56:08 | preglow | btw, does inverse display exist on colour lcd controllers? |
00:56:22 | *** | Saving seen data "./dancer.seen" |
00:58:03 | amiconn | I wouldn't expect it |
00:58:26 | preglow | amiconn: well, the sims will have to start defining its own dummies for lcd_update and so on now, then, since they're placed in lcd-ipod.c, etc |
00:59:01 | preglow | if we do this properly, then an lcd-sim.c could easily be added as well just for sims |
00:59:28 | amiconn | They aren't dummies, and they are defined in the simulator code |
00:59:42 | XavierGr | amiconn I don't see a function in the plugin API that it will enable us to sniff disk activity. |
00:59:52 | amiconn | uisimulator/x11/lcd-x11.c and uisimulator/win32/lcd-win32.c |
00:59:57 | XavierGr | only way is to add a function to the api, is that acceptable? |
01:00 |
01:00:59 | preglow | seems there are some stubs for the simulator in the various lcd drivers too, though |
01:01:07 | preglow | like lcd_init |
01:01:25 | amiconn | Yes, the init is of course target only |
01:02:40 | | Quit Kohlrabi (Read error: 104 (Connection reset by peer)) |
01:02:52 | preglow | so i somehow need to expose an lcd_init to the sim, even though that too belongs in lcd-ipod.c? |
01:03:07 | amiconn | From looking at lcd-h100.c, I can see no problems with the split |
01:03:28 | preglow | probably just me being confused and tired |
01:03:31 | amiconn | I doubt lcd_init is ever called for the sims |
01:03:58 | amiconn | Ah no, it must be |
01:04:10 | amiconn | Only thing it does is creating the scroll thread |
01:04:10 | preglow | then how should i deal with that? |
01:04:18 | preglow | ahh |
01:04:29 | preglow | so we can just keep a default one somewhere? |
01:04:37 | preglow | with an ifdef around it |
01:05:06 | amiconn | uisimulator/common/lcd-common.c should be a nice place for the simulator lcd_init |
01:05:32 | preglow | yep |
01:05:33 | preglow | good |
01:05:48 | amiconn | (the first function that actually does something in there) |
01:07:16 | preglow | btw, am i the only person in the world prefering to indent #ifs and #ifdefs with the code around it? :> |
01:07:34 | amiconn | Seems so ;) |
01:07:46 | XavierGr | e.g? |
01:07:52 | linuxstb | preglow: Yes :) |
01:08:36 | | Quit ashridah ("Leaving") |
01:11:31 | preglow | hmm |
01:13:12 | preglow | scroll thread data can't be static anymore, at least |
01:13:24 | preglow | since we instantiate the thread from another file than where it recides |
01:13:45 | amiconn | I don't think so |
01:13:57 | preglow | perhaps it's better to just let each driver contain the thread data |
01:14:02 | amiconn | You wouldn't call the scroll_thread function from elsewhere |
01:14:22 | preglow | well, from lcd-ipod.c i would |
01:14:35 | amiconn | You just call create_thread from elsewhere, with the function as an argument |
01:15:22 | preglow | yes, but i also need the stack and the name string |
01:15:24 | amiconn | The only variables that can't stay static are scroll_stack and scroll_name |
01:15:30 | | Quit Moos ("Glory to Rockbox") |
01:15:31 | preglow | yes |
01:15:33 | amiconn | ...and the scroll_thread function itself |
01:15:42 | preglow | nono, the rest i'll keep static |
01:19:02 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
01:21:36 | preglow | is there a generic ipod platform define? |
01:22:14 | preglow | hmm, nope |
01:22:23 | preglow | i need one for firmware/SOURCES |
01:23:10 | linuxstb | I'm not sure you should use one. Just do CONFIG_LCD==LCD_IPODNANO || CONFIG_LCD==LCD_IPODCOLOR |
01:23:18 | linuxstb | (for now). |
01:23:44 | preglow | will do |
01:25:39 | linuxstb | Shorten is a very basic codec. For example, each channel is always encoded independently. |
01:26:38 | preglow | yes, it's pretty old |
01:27:00 | linuxstb | There is an lpc_restore function which is very similar to FLAC. But the decoder adds the residuals inside the restore loop. I may fix that and add your emac routine. |
01:27:22 | linuxstb | Forget that.... |
01:27:26 | preglow | oh? |
01:27:59 | preglow | btw, wont we need to split lcd.h into several files now? |
01:28:37 | amiconn | huh? |
01:28:37 | preglow | this is going to end up with me having to split all the lcd files ... |
01:28:58 | preglow | amiconn: i'll need to include lcd.h from lcd-ipod.c, since it depends on some lcd-16bit.c functions |
01:29:15 | preglow | amiconn: but what happens when lcd-ipod.c sees a lot of its own functions declared extern all of a sudden? |
01:29:27 | amiconn | nothing |
01:29:30 | preglow | i keep forgetting that extern i default... |
01:29:30 | preglow | bah |
01:29:33 | preglow | is |
01:29:39 | linuxstb | What does lcd-ipod.c depend on from lcd-16bit.c? |
01:30:00 | linuxstb | I thought it would only be the other way around. |
01:30:11 | preglow | lcd_clear_display |
01:30:36 | preglow | but perhaps that's meant to be device dependent as well? |
01:31:19 | linuxstb | Maybe you should keep lcd_init() in lcd-16-bit.c and have a low-level init function in lcd-ipod.c |
01:31:19 | amiconn | nope |
01:31:56 | linuxstb | e.g. lcd_init_device() |
01:31:59 | preglow | nope to what? |
01:32:17 | amiconn | lcd_clear_display() isn't hardware dependent |
01:32:32 | amiconn | It just clears the framebuffer |
01:33:07 | preglow | then the dependency shall be allowed to live? |
01:33:36 | linuxstb | preglow: Just keep lcd_init() where it is. |
01:34:13 | preglow | in lcd-ipod.c? |
01:34:24 | amiconn | linuxstb: lcd-h100-remote does that separation (hw init and high-level init) |
01:34:26 | preglow | that's where it is here :) |
01:34:41 | amiconn | It has to, since the hw init has to be called everytime the remote is plugged |
01:34:48 | linuxstb | No - in lcd-16bit.c :) Just move the low-level parts of it to lcd-ipod.c |
01:35:16 | preglow | and do a lcd_init_device() as well? |
01:35:21 | | Join Jungti1234 [0] (n=jungti12@211.248.102.131) |
01:35:46 | linuxstb | preglow: Yes. |
01:35:47 | amiconn | ...which then should be an empty macro for the sim |
01:36:10 | preglow | i'll pretty much have to split all the other lcd drivers as well now |
01:36:14 | amiconn | Could be #defined in lcd.h ... |
01:36:49 | preglow | right, i keep forgetting lcd-16bit.c isn't used anywhere vital yet |
01:36:53 | linuxstb | Why do you need to split anything else immediately? |
01:37:01 | preglow | nevermind me |
01:37:39 | XavierGr | quick question: I want to add to the api structure a new function. 1. I make sure that the .h file is included in plugin.c 2. I add the function to the api 3. I boost the api define number by one. correct? |
01:38:22 | XavierGr | oops |
01:38:34 | XavierGr | I have to add the function to plugin.h too |
01:39:22 | preglow | btw, how will we handle it when rockbox needs both lcd-2bit.c and lcd-1bit.c, as will be the case with h100. main unit will use 2bit and remote 1bit |
01:39:49 | amiconn | That won't work |
01:39:50 | preglow | or shall we still keep the remote as a special case? |
01:39:59 | amiconn | The function names would be identical |
01:40:04 | preglow | i know, that's why i'm wondering |
01:40:13 | preglow | the alternative is not including the remote in this scheme |
01:40:15 | | Quit Jungti1234 ("Http://www.ZeroIRC.NET ¢Æ Zero IRC ¢Æ Ver 2.8") |
01:40:58 | amiconn | Either that, or use a more general concept, similar to the gui_* stuff |
01:41:16 | preglow | oh well |
01:41:34 | preglow | i vote for keeping the remote as a special case for now |
01:42:00 | amiconn | Yes, not everything at once |
01:44:48 | XavierGr | do i have to compile again the whole firmware when the api_plugin_version changes? |
01:44:53 | preglow | ok, lcd_init is now just a call to lcd_clear_display and lcd_init_device |
01:45:16 | amiconn | Hmm, no create_thread() ? |
01:45:17 | preglow | oh, plus scroll thread |
01:45:18 | XavierGr | e.g I moved the compiled rock file to an old firmware and the error uncompatible version poped up. |
01:45:20 | preglow | i forgot that |
01:45:37 | amiconn | XavierGr: Of course |
01:45:48 | amiconn | That's why you bump the api version |
01:45:55 | linuxstb | So that should work for the sim if you add lcd_init_device to the x11 and win32 lcd drivers. |
01:46:07 | amiconn | The new plugin would need a function in the api that the old core doesn't provide |
01:46:18 | XavierGr | thought so... |
01:46:23 | amiconn | If this wouldn't be checked, rockbox would crash |
01:46:24 | XavierGr | yeah it is obvious |
01:46:53 | amiconn | linuxstb: Not necessary, see above |
01:47:08 | amiconn | lcd.h should just define it as an empty macro for the sims |
01:47:53 | preglow | will do |
01:48:26 | linuxstb | But couldn't it be used to actually do something useful in the sims? e.g. create the window. |
01:48:59 | preglow | you'd need to pass info from and to that function then |
01:49:08 | preglow | could of course keep it static |
01:49:16 | linuxstb | Yes, forget that. A simulator window is also used for input... |
01:49:24 | linuxstb | So they are not the same. |
01:49:38 | preglow | it would be doable, it would just be something of a hack |
01:49:38 | preglow | heh |
01:51:02 | preglow | so, let's try it out then |
01:51:06 | amiconn | hmpf. |
01:51:07 | preglow | bAM, linker error |
01:51:24 | linuxstb | Try a make clean |
01:51:37 | preglow | linuxstb: man, ipod compiles looks like flowers at the moment |
01:51:42 | preglow | linuxstb: did a reconfigure |
01:51:47 | linuxstb | flowers? |
01:51:56 | preglow | with all the warnings and stuff |
01:52:07 | preglow | really pretty, heh |
01:52:29 | preglow | i, riight, a lack a ton of includes |
01:53:33 | preglow | too tired to even write coherently, i see |
01:54:52 | preglow | ok, things seem to work well |
01:54:58 | linuxstb | just switching computers... |
01:55:02 | | Part linuxstb |
01:55:35 | * | amiconn is undecided whether 8% higher speed for byte aligned data justify using 32 bytes more iram on archos |
01:55:52 | amiconn | Doble the amount for when memmove() gets added |
01:57:38 | preglow | how much iram does it have? |
01:57:39 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
01:57:52 | amiconn | 4KB |
01:58:26 | amiconn | It will fit, even with memmove() and for debug builds |
01:59:01 | amiconn | The cvs version is the faster one |
01:59:16 | amiconn | (yet without memmove) |
02:00 |
02:01:39 | XavierGr | another one: bool ata_disk_is_active (void) returns a bool and says to us if the disk is spining right? |
02:01:55 | XavierGr | or it returns if the spin is not powered off? |
02:01:59 | | Join thegeek_ [0] (n=thegeek@s115b.studby.ntnu.no) |
02:02:03 | XavierGr | s/spin == disk |
02:04:07 | preglow | but aight |
02:04:11 | preglow | i'll commit this now then |
02:09:31 | preglow | linuxstb: going to commit shorten today? |
02:12:48 | linuxstb | preglow: Hopefully. I'm looking at it now. |
02:14:10 | preglow | i wonder how much ram the nano has |
02:14:32 | amiconn | The scroll thread can stay static |
02:14:44 | linuxstb | preglow: I'm sure it's 32MB - same as all the ipods |
02:14:45 | preglow | amiconn: ahh, blast, forgot to add the static back |
02:14:55 | | Join netcrusher88 [0] (n=8115be63@labb.contactor.se) |
02:14:56 | preglow | linuxstb: seems like a bit of a waste, that's all |
02:15:10 | preglow | linuxstb: you hardly need to spin up the flash all the time, so copying could happen more frequently |
02:15:59 | linuxstb | Install linux and type "cat /proc/meminfo" :) |
02:16:08 | preglow | amiconn: anything else you see that needs fixing? |
02:17:40 | linuxstb | preglow: If the bootloader works, then I think that means you have 32MB of RAM. IIRC, I am using a high part of that memory for the BSS |
02:17:44 | amiconn | Looks good so far. |
02:18:08 | amiconn | lcd_blit() won't be necessary for >4 bit displays though |
02:18:35 | preglow | so i should just remove it and put an ifdef in lcd.h? |
02:18:49 | linuxstb | amiconn: Why not? I thought that was used to write a bitmap to the LCD without going via the framebuffer. |
02:19:06 | linuxstb | Or have I misunderstood? |
02:19:38 | netcrusher88 | what is the difference between recorder v2 and fm recorder? |
02:19:47 | | Quit thegeek (Read error: 110 (Connection timed out)) |
02:19:52 | amiconn | Yes that's what it's for, but we won't need that for higher bit depth greyscale or colour lcds |
02:20:41 | amiconn | This function is used for 2 things with low-depth displays: (1) grayscale library, (2) video playback in .rvf format |
02:21:07 | amiconn | I'm almost sure video will be handled different on high-depth displays |
02:21:45 | amiconn | ...decoding data with a true video codec into the frame buffer, then using lcd_update() to show that |
02:22:07 | amiconn | http://www.rockbox.org/twiki/bin/view/Main/GraphicsAPI |
02:22:30 | preglow | yes, i think we pretty much have to |
02:22:41 | preglow | even on h1x0 the data will become quite large when stored uncompressed |
02:22:48 | amiconn | Yes |
02:25:53 | | Part netcrusher88 |
02:27:04 | preglow | amiconn: so i should just ifdef out blit in lcd.h? |
02:28:21 | preglow | probably doesn't matter to keep it there anyway |
02:28:44 | preglow | so i'll just delete it from lcd-ipod.c |
02:30:43 | | Join amiconn_ [0] (n=jens@p54BD681D.dip.t-dialin.net) |
02:31:14 | | Quit amiconn (Nick collision from services.) |
02:31:14 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD681D.dip.t-dialin.net) |
02:31:28 | amiconn | LotR 1 is 764MB in archos .rvf format. Will be almost 2GB on H1x0 |
02:31:39 | preglow | yes, it does seem to have 32 megs ram |
02:31:47 | preglow | we can more or less just pretend the flash is a hard drive |
02:32:08 | amiconn | That's the same good thing as with the Ondio |
02:32:15 | preglow | certainly seems to be the route it takes internally anyway |
02:32:40 | preglow | i think you can actually wire hard drives to a nano |
02:32:53 | preglow | amiconn: yes, and god knows what on colours displays |
02:33:08 | linuxstb | amiconn: Do things like the delayed write of the config sector still happen on the Ondio? |
02:33:14 | amiconn | yes |
02:33:31 | amiconn | It serves another purpose than on the disk units |
02:33:45 | amiconn | ...not wearing the flash more than necessary |
02:35:56 | preglow | linuxstb: btw, has apple dropped all hfs ipods? this one came with fat32 and no questions asked about it |
02:36:17 | amiconn | preglow: If you remove lcd_blit() from the driver, you need to comment it out in the plugin api |
02:36:42 | linuxstb | preglow: Are you sure it came with fat32? I think mine came unformatted. |
02:37:03 | linuxstb | Connecting it to itunes caused it to be initialised. |
02:37:11 | linuxstb | IIRC |
02:37:38 | amiconn | preglow: It seems you broke the h300 build |
02:37:53 | linuxstb | It was working? :) |
02:38:03 | preglow | what linuxstb said |
02:38:27 | preglow | linuxstb: how can it come unformatted? itunes formats it on the first go? |
02:39:03 | preglow | amiconn: no surprises there, btw |
02:39:18 | preglow | amiconn: i'm going to ignore that for now, as the fix will just be to introduce a bunch of empty functions anyway |
02:39:36 | amiconn | Yes, lcd-h300.c |
02:39:56 | preglow | wont cost linus an ounce of extra work when he gets to it anyway |
02:40:24 | amiconn | I think I'll do the split for the 1bit lcd targets |
02:40:30 | amiconn | But not now |
02:40:43 | preglow | not much of anything right now |
02:40:46 | preglow | sounds about time to go to sleep |
02:40:55 | amiconn | yeah |
02:41:16 | linuxstb | definitely agreed. |
02:41:19 | preglow | yuop |
02:41:25 | preglow | night, see you around |
02:41:31 | amiconn | night |
02:41:39 | linuxstb | Time for the night shift to take over. Goodnight. |
02:56:26 | *** | Saving seen data "./dancer.seen" |
02:57:01 | elinenbe | amiconn and preglow: you both have the new ipods? |
03:00 |
03:03:52 | linuxstb | No, preglow and I have ipods. |
03:05:45 | | Quit thegeek_ (Read error: 104 (Connection reset by peer)) |
03:09:01 | | Quit merbanan (Read error: 104 (Connection reset by peer)) |
03:56:41 | | Join netcrusher88 [0] (n=8115be63@filer3.isc.rit.edu) |
04:00 |
04:00:45 | netcrusher88 | so... |
04:01:01 | netcrusher88 | what is the difference between recorder v2 and recorder fm? |
04:02:16 | | Part netcrusher88 |
04:11:37 | | Join ghode [0] (i=testing@host-212-158-193-204.bulldogdsl.com) |
04:12:00 | | Quit ghode|afk (kornbluth.freenode.net irc.freenode.net) |
04:12:00 | NSplit | kornbluth.freenode.net irc.freenode.net |
04:15:21 | NHeal | kornbluth.freenode.net irc.freenode.net |
04:15:21 | NJoin | ghode|afk [0] (i=testing@host-212-158-193-204.bulldogdsl.com) |
04:17:09 | | Quit hardeep ("User abortion with 5 coathooks") |
04:28:59 | | Join solexx_ [0] (n=jrschulz@d001066.adsl.hansenet.de) |
04:29:18 | | Quit ghode|afk (Read error: 110 (Connection timed out)) |
04:30:58 | | Quit ghode (Read error: 110 (Connection timed out)) |
04:32:14 | | Join joshn_ [0] (n=joshn@ool-182e82f5.dyn.optonline.net) |
04:36:28 | | Join Jungti1234 [0] (n=d3f86683@labb.contactor.se) |
04:38:28 | | Quit Jungti1234 (Client Quit) |
04:39:09 | | Quit solexx (Read error: 110 (Connection timed out)) |
04:41:53 | | Quit joshn_ ("Leaving") |
04:43:30 | | Quit Midgey34 ("Download Gaim: http://gaim.sourceforge.net/") |
04:49:26 | | Join Jungti1234 [0] (n=d3f86683@labb.contactor.se) |
04:56:27 | *** | Saving seen data "./dancer.seen" |
04:57:32 | | Join DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
05:00 |
05:05:51 | | Quit Jungti1234 ("CGI:IRC (EOF)") |
05:14:54 | | Quit DJDD (Read error: 110 (Connection timed out)) |
05:17:11 | | Join |joshn| [0] (n=kvirc@ool-182e82f5.dyn.optonline.net) |
05:44:20 | | Join ashridah [0] (i=ashridah@220-253-120-173.VIC.netspace.net.au) |
06:00 |
06:10:40 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
06:22:08 | | Quit RotAtoR () |
06:29:13 | | Quit DJDD_ (Read error: 110 (Connection timed out)) |
06:56:29 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:23:14 | | Join _FireFly_ [0] (n=FireFly@p54A4558E.dip.t-dialin.net) |
07:27:54 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
07:29:15 | | Quit DJDD (Read error: 110 (Connection timed out)) |
07:31:42 | _FireFly_ | moin |
07:35:50 | _FireFly_ | TiMiD ?? |
07:38:16 | _FireFly_ | if some of the devs interresting to look at in my wps-widget here is the code: http://home.arcor.de/s.wezel/wps-widget.zip |
07:38:32 | _FireFly_ | this zip-file has only the widget code-itself |
07:38:47 | | Quit BirdFish ("reboot") |
07:38:55 | _FireFly_ | any comments, suggestions are wellcome |
07:39:00 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
07:41:38 | | Join BirdFish [0] (n=bradbox8@64.108.5.134) |
07:56:47 | | Quit |joshn| ("KVIrc 3.2.0 'Realia'") |
07:57:43 | | Join |joshn| [0] (n=kvirc@ool-182e82f5.dyn.optonline.net) |
08:00 |
08:10:59 | _FireFly_ | amiconn does your FOR_NB_SCREENS makro also work if the loop-var is not i ?? |
08:11:13 | _FireFly_ | because on some places i is already used |
08:13:52 | | Quit DJDD (Read error: 110 (Connection timed out)) |
08:17:46 | | Quit _FireFly_ ("Leaving") |
08:32:11 | | Quit ashridah ("Leaving") |
08:52:02 | | Join _FireFly_ [0] (n=icechat5@pd95b7c08.dip0.t-ipconnect.de) |
08:56:32 | *** | Saving seen data "./dancer.seen" |
08:58:41 | | Join hardeep [0] (n=hardeep@c-67-188-108-180.hsd1.ca.comcast.net) |
08:59:17 | preglow | _FireFly_: well, it takes the loop variable as a parameter, you can give it whatever you want |
09:00 |
09:00:28 | B4gder | here's one for you ipod hackers: "Efficient programming techniques for ARM" => http://www.at91.com/www/phpBB2/download.php4?id=151 |
09:00:37 | B4gder | pdf |
09:00:52 | | Join ashridah [0] (i=ashridah@220-253-120-64.VIC.netspace.net.au) |
09:03:22 | _FireFly_ | preglow: so if i give it z then the for-loop uses the var z ?? |
09:03:54 | amiconn | _FireFly_: yep |
09:04:01 | _FireFly_ | ok |
09:04:17 | | Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) |
09:05:36 | preglow | dealing with this clickwheel is going to be tricky |
09:06:27 | preglow | seeing as we probably want to use velocity sensitivity |
09:07:20 | korpse | preglow: working on the iPod port there? |
09:08:10 | preglow | not right now, no |
09:08:26 | preglow | right now i'm trying to come to grips with being awake again |
09:08:55 | korpse | the toughest part of a day |
09:08:57 | korpse | :) |
09:09:04 | preglow | a wholly unpreferable situatuin |
09:09:07 | preglow | situation, even |
09:10:39 | Zagor | preglow: do you know what hardware interface you have to the clickwheel? |
09:12:14 | preglow | Zagor: no, actually, i'm hoping it's something quite highlevel :) |
09:12:56 | preglow | it's quite high-resolution, it seems |
09:13:48 | preglow | B4gder: i've been looking for something like this, cheers |
09:18:17 | * | B4gder uses an "at91" at work |
09:20:02 | preglow | one of the atmel arms? |
09:20:06 | B4gder | yes |
09:20:14 | B4gder | arm920 core |
09:21:59 | hardeep | nice, the insight debugger works really well with the rockbox sim on cygwin |
09:22:01 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
09:22:20 | _FireFly_ | :) |
09:22:37 | _FireFly_ | some other had a problem with it with cygwin |
09:23:20 | hardeep | i'm using the latest version with the iriver sim |
09:23:33 | preglow | B4gder: is there a general rule on when to use thumb code and when to not use it? |
09:23:57 | B4gder | preglow: the general rule is to use thumb mode for 16 bit memory |
09:24:21 | | Quit XavierGr (Read error: 110 (Connection timed out)) |
09:24:26 | Jungti1234 | hi |
09:24:39 | preglow | ipods have 16 bit memory :/ |
09:24:44 | * | B4gder never tried insight... |
09:24:56 | B4gder | preglow: then it might be an idea |
09:28:24 | preglow | arm assembler is pretty nifty |
09:28:29 | B4gder | indeed |
09:28:41 | B4gder | the niftiest around imho |
09:31:15 | | Quit hardeep (" HydraIRC -> http://www.hydrairc.com <- The future of IRC") |
09:31:50 | Jungti1234 | Is DRM of rockbox supported? |
09:32:11 | Jungti1234 | in H100. |
09:32:31 | Zagor | Jungti1234: no |
09:32:32 | B4gder | Jungti1234: if you ask if "DRM codecs" are supported, then the answer is no |
09:32:50 | Zagor | DRM and open source doesn't mix well |
09:33:48 | B4gder | DRM and enlighted users usally don't mix well either |
09:34:24 | korpse | Musepack is supported, right? |
09:34:30 | preglow | yes |
09:34:37 | preglow | it's getting pretty fast as well |
09:35:11 | | Join thegeek [0] (n=thegeek@s115b.studby.ntnu.no) |
09:37:12 | _FireFly_ | TiMiD ?? |
09:37:16 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
09:38:02 | linuxstb_ | preglow: I think the clickwheel gives us an integer betweel 0 and about 95 - the position of the user's finger on the wheel. |
09:38:26 | preglow | so there is indeed a decoder there |
09:38:26 | TiMiD | I'm here for 5 minutes max ! |
09:38:37 | TiMiD | I looked at your patch |
09:38:42 | TiMiD | some remarks |
09:39:37 | TiMiD | first I don't know why declaring 2 vars main_data and remote_data |
09:40:13 | TiMiD | hmm |
09:40:17 | TiMiD | nothing forget it |
09:40:20 | _FireFly_ | these to vars hold the wps-data for both screens :) |
09:40:22 | _FireFly_ | ;) |
09:40:26 | TiMiD | but just make a tab instead |
09:40:36 | _FireFly_ | a tab ?? |
09:40:55 | TiMiD | extern struct wps_data wps_datas[NB_SCREENS]; |
09:41:11 | _FireFly_ | ok |
09:41:12 | TiMiD | I think you use them to fill the lack of malloc in rb ? |
09:41:14 | Slasher | eh, that's really weird. I have now hooked up a logic analyzer to the iriver eeprom chip but it doesn't show a signal at all - eather on scl or sda |
09:41:42 | _FireFly_ | yepp |
09:41:47 | TiMiD | (instead of doing malloc for the ptr in wps_gui you uses &main_data or remote_data |
09:41:51 | TiMiD | ok |
09:42:02 | TiMiD | so I think a tab here would be cleaner |
09:42:16 | _FireFly_ | if we had malloc we could reduce the used memory depending on the loaded wps |
09:42:19 | _FireFly_ | ok |
09:42:21 | TiMiD | but that's just a detail |
09:42:31 | _FireFly_ | it's simple to change ;) |
09:42:44 | Zagor | _FireFly_: sure we could, but the unused memory would remain unused, so no gain |
09:42:50 | TiMiD | yes there are plenty of places where a malloc would help to reduce memory used ;) |
09:42:51 | _FireFly_ | k |
09:43:01 | B4gder | I beg to differ |
09:43:08 | Zagor | TiMiD: it's an illusion |
09:43:17 | TiMiD | yes it's an illusion ... |
09:43:38 | TiMiD | when I see an empty tab like the one used for dir content |
09:44:05 | TiMiD | or a char buffer used to virtually malloc strings (like the one in playlist_viewer.c) |
09:44:16 | TiMiD | maybe they donesn't take a lot of memory |
09:44:21 | preglow | Slasher: nice........ |
09:44:30 | TiMiD | but they make the code ugly (that's my opinion) |
09:44:34 | ze | math 24*30 |
09:44:36 | ze | doh |
09:44:41 | B4gder | TiMiD: you'd still have to deal with the worst case, fragmentation and the additional code size required |
09:44:58 | Zagor | TiMiD: the point is those are necessary, and will be needed at any random point in time. so even if they were malloced, that memory would have to be available. hence it's better to ensure it always is. |
09:45:14 | preglow | Slasher: perhaps you're writing to the wrong port? :) |
09:45:27 | TiMiD | yes I know about memory fragentation, and without a MMU I know it's more difficult to handle |
09:45:54 | TiMiD | but coding would be a lot cleaner with malloc |
09:46:00 | preglow | just forget about it |
09:46:03 | B4gder | I disagree |
09:46:10 | Zagor | TiMiD: it would A LOT more buggy |
09:46:11 | preglow | you have to code for the worst case anyway |
09:46:13 | Zagor | would be |
09:46:17 | preglow | so just use buffers |
09:46:20 | TiMiD | no |
09:46:34 | TiMiD | you can use only the ammount of memory you need |
09:46:41 | TiMiD | for example with chained lists |
09:46:45 | preglow | and if it changes during runtime? |
09:46:58 | B4gder | and how would the playback system get the memory it needs? |
09:47:07 | preglow | then you'll need a malloc buffer somewhere with lots of spare memory in it |
09:47:08 | B4gder | if split up my malloc? |
09:47:11 | preglow | and bang, you're back to where you were |
09:47:24 | preglow | with buffers designed for worst case |
09:47:41 | B4gder | TiMiD: we've heard all these arguments, we've thought about them, we've dismissed them |
09:47:46 | preglow | no, i'm completely with the elders here |
09:47:49 | preglow | malloc is bad in our case |
09:48:12 | preglow | it would clutter the memory management for no gain at all |
09:48:51 | TiMiD | it would just make programs easier to understand |
09:49:07 | B4gder | really? |
09:49:15 | TiMiD | even if I agree, in practice, it's difficult to implement without virtuals adressing |
09:49:15 | preglow | how? |
09:49:35 | preglow | you can't get much easier than static buffers |
09:49:41 | Zagor | it's not only difficult, it's pointless |
09:49:48 | preglow | and with mallocs you get a free nightmare |
09:49:52 | preglow | free() that is |
09:49:53 | TiMiD | as I said lot of parts of the code use static buffers and do their dynamic allocation in those |
09:50:02 | B4gder | personally I think static memory usage is simpler than malloc ones |
09:50:09 | TiMiD | that's not the cleanest thing I saw |
09:50:26 | preglow | cleaner than malloc |
09:50:29 | Zagor | local reserved pools are ugly? |
09:50:34 | preglow | on the grounds that you can just forget having ever done it after you've done it |
09:50:38 | preglow | no leaks |
09:50:39 | TiMiD | yes in some cases they are |
09:50:50 | B4gder | I don't think that is because of static vs malloc, it is just code that can be written more clearly |
09:50:53 | TiMiD | yes no leaks |
09:51:23 | TiMiD | but even on a computer with malloc, a good programmer must know how to program wthout leaks :/ |
09:51:48 | Slasher | preglow: i have defined: |
09:51:50 | Slasher | #define SDA_LO and_l(~0x00001000, &GPIO_OUT) |
09:51:57 | Slasher | #define SCL_LO and_l(~0x00002000, &GPIO1_OUT) |
09:51:59 | TiMiD | and here the cases are trivial (at least in the app layer code) so leaking would be very difficult ;) |
09:52:08 | Zagor | TiMiD: you keep missing the point. programmer errors or difficulty is not the point here. the point is we have limited memory, which we want to use 100% of. so we need to split it up, which makes malloc completely redundant. |
09:52:14 | Slasher | (from fmradio_i2c) and i think that should be the right port according to schematics.. |
09:52:21 | Slasher | but the signal remains static high |
09:52:43 | TiMiD | well I have to go |
09:52:59 | TiMiD | but I don't agree with you on this point hehe ;) |
09:53:01 | Zagor | malloc depends on having a free UNUSED pool, which is precisely the opposite of our goal |
09:53:18 | XShocK | TiMiD: it is just not easy to implement that stuff properly without loss of memory |
09:53:42 | B4gder | TiMiD: if you'd try to write down a complete proposal, you'll start seeing our point |
09:53:51 | linuxstb_ | Regarding malloc, I think we're progressing on completely removing the need for malloc from the codecs. So I hope we'll be able to free that 512MB at some point. |
09:53:55 | Slasher | preglow: Ah! but i could check that easily. I will force that signal low and checking how the port status changes |
09:53:57 | Zagor | TiMiD: the difference between rockbox and "normal" programming, is that "normal" programs don't want to use 100% of ram at every point in time. we do. |
09:54:01 | TiMiD | for example removing the statical file buffer in tree.C would make you gain a lot of memory |
09:54:18 | B4gder | TiMiD: again, you try to show that with a *complete* proposal |
09:54:23 | ashridah | i imagine you're going to quickly run into fragmentation issues if you start using malloc |
09:54:41 | Zagor | TiMiD: then how would we show the file tree while playing music? |
09:55:11 | linuxstb_ | TiMiD: What are you going to use all this free memory for? You can't use it for audio buffering because that means your mallocs will always fail when the audio buffer is full. |
09:55:38 | B4gder | and it would be a *MESS* to may the audio system use a segmented memory system |
09:55:54 | TiMiD | Zagor: I don't see the point here : we would just have to get the exac amount of memory we need when loading a dir, it would remain in memory until next free (done when changing dir) |
09:55:56 | B4gder | make |
09:56:10 | * | B4gder stops having this conversation |
09:56:37 | * | TiMiD g2g |
09:56:43 | linuxstb_ | In order for Rockbox to function, you will need to reserve part of memory for malloc. How do you decide how big this buffer is? It has to be big enough for the worse case scenario. i.e. what we do now with static buffers. |
09:57:31 | TiMiD | it would have some drawbacks, but when you see the amount of memory taken for the dir buffer for example I'm sure it would worth it in that case |
09:57:48 | Zagor | TiMiD: no, because you can't use it for anything else |
09:57:56 | linuxstb_ | Exactly. |
09:58:00 | Zagor | free memory is worthless |
09:58:07 | TiMiD | and I'm not talking about having the most free memory possible, just about code sanity |
09:58:28 | linuxstb_ | But malloc (and checking for errors) will just complicate the code. |
09:58:49 | linuxstb_ | How do you react when a malloc fails? |
09:59:18 | Jungti1234 | Can not you support DRM to H100 rockbox firmware? |
09:59:38 | B4gder | Jungti1234: feel free to add |
09:59:57 | Jungti1234 | :) |
10:00 |
10:00:19 | linuxstb_ | I only know of DRM for WMA and AAC. Rockbox can't play WMA at all, and AAC can be de-DRMed on your PC. |
10:00:23 | | Join LinusN [0] (n=linus@labb.contactor.se) |
10:00:37 | LinusN | it's funny, we have this discussion with every new developer :-) |
10:00:49 | Zagor | Jungti1234: DRM requires licensing code and patents from the likes of Microsoft and Apple. And they won't license anything to an open source project. |
10:01:25 | Jungti1234 | aha |
10:01:29 | Zagor | ...since that would mean their DRM gets broken in a week |
10:01:39 | XShocK | Jungti1234, you can still try to ask them. god blesses you. |
10:01:58 | Jungti1234 | hehe |
10:02:01 | Zagor | XShocK: we don't want to license either. the license restrictions are massive. |
10:02:10 | LinusN | i though microsoft was god ;-) |
10:02:15 | linuxstb_ | Dear Bill, Please tell us how to remove the DRM from your files. Love Rockbox. |
10:02:31 | XShocK | Zagor, I am not a fan of DRM anyway... I don't even have anything to play it with.. :) |
10:02:35 | korpse | linuxstb_: hahaha |
10:02:52 | Jungti1234 | haha.. |
10:03:25 | LinusN | drm is not good for customers, only for corporations |
10:03:27 | preglow | TiMiD: exactly how is malloced buffers more _sane_ than static buffers? |
10:03:54 | preglow | TiMiD: whatever you say, it all ends up you using just as much memory as you did before, but now with the added overhead of malloc and all that brings along with it, like leaks |
10:04:22 | linuxstb_ | ... and the increased code size to deal with errors. |
10:04:50 | XShocK | ... and it is not that much harder(if not easier) to code static code. |
10:04:56 | Slasher | LinusN: Hi, there might be a mistake in the schematics: It looks that EEPROM_I2C_SCL is GPIO, 12 but that was marked as being SDA |
10:04:56 | preglow | it's easier |
10:04:58 | preglow | undoubtedly |
10:05:04 | Slasher | Now i try to check that SDA too |
10:05:45 | XShocK | Slasher, are you trying to implement writing to i2c? |
10:05:47 | LinusN | Slasher: oops |
10:06:25 | LinusN | what will you do with the eeprom? |
10:07:16 | ashridah | linuxstb: and lets not forget fragmentation. allocate a giantbuffer, then a tiny long lived one. then the giant buffer goes away, and you allocate a few more tiny ones. then reallocate the giant one... boom. |
10:08:01 | Slasher | And yes, SDA is GPIO1, 13 |
10:08:03 | XShocK | with no MMU, no virtual memory... it sucks |
10:08:05 | Slasher | they have just swapped :) |
10:08:09 | Slasher | XShocK: yes |
10:08:27 | Slasher | LinusN: i will try to get it working and save the settings structure there |
10:08:28 | ashridah | yep. no paging, so no hope of consolidating free pages |
10:08:48 | B4gder | it seems we are united on this at least. We'll just have to bit the sense into TiMiD ;-) |
10:08:56 | B4gder | beat even |
10:09:05 | ashridah | was about to say, not biting anyone, thanks |
10:09:34 | B4gder | but beating is fine? |
10:09:47 | LinusN | Slasher: 128 bytes won't help you much |
10:09:47 | ashridah | as long as none of their blood gets on me |
10:09:52 | B4gder | :-) |
10:10:13 | preglow | it's only 128 bytes? :/ |
10:10:20 | LinusN | yes, 1kbit |
10:10:31 | preglow | drat |
10:10:40 | preglow | Slasher: start writing settings to flash :P |
10:11:11 | Slasher | LinusN: oh.. i though it was 1 KiB :( |
10:11:16 | Slasher | so it's pretty useless then |
10:11:26 | Slasher | yes, flash seems only option then |
10:11:34 | LinusN | i didn't bother using the eeprom because of this, and i figured the original firmware would work better if we didn't tough it |
10:11:43 | LinusN | touch |
10:11:47 | XShocK | 128 byte of memory... around 20 kbits/sec speed... times of first PIC microcontrollers are rising again... |
10:12:14 | Slasher | but good to know that.. i will no longer bother working with that poor eeprom :D |
10:12:25 | XShocK | but still do writing. :) |
10:12:26 | Slasher | i will try the flash next |
10:12:44 | * | preglow finds out he's drinking milk gone bad... |
10:13:06 | Slasher | XShocK: i can finish the driver but i don't know if we have any use for that |
10:13:41 | LinusN | don't bother |
10:14:06 | XShocK | yes. we have, sorry. i have. :) by some strange reason i didn't do it myself. i made a schema of a clock... but never managed to solder it in the player... |
10:15:48 | XShocK | one day.. when there is no job, no midterm, no homework, no papers... i will solder it in. |
10:15:58 | LinusN | oh, then.... |
10:16:22 | LinusN | when you retire, that is :-) |
10:17:47 | | Part linuxstb_ |
10:18:24 | XShocK | right... i built that small schematich around 4 months ago, tested on fpga board, worked fine... opened up the player, found all places where i needed to connect wires... then i put that schematic in my desk... and never managed to use it.. saddest story |
10:19:51 | LinusN | XShocK: publish the schematic |
10:19:54 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
10:20:17 | linuxstb_ | Looks like Microsoft has reverse-engineered iPod support into the Xbox360: http://www.theregister.co.uk/2005/11/08/xbox_360_ipod/ |
10:20:36 | korpse | reverse-engineered? really? |
10:20:43 | XShocK | quarz, two capacitors, and a i2c maxim rtc. nothing really to publish. :) |
10:20:45 | korpse | i would've thought they'd only need to wave their hand |
10:20:51 | linuxstb_ | "there is no official relationship with Apple" |
10:21:27 | linuxstb_ | But they didn't go as far as stealing the code from hymn |
10:22:37 | Zagor | linuxstb_: the article says they *don't* have itms support in xbox |
10:22:59 | linuxstb_ | That just means it doesn't support DRMed files. |
10:23:27 | Zagor | right. so the "reverse engineering" is the part where they access a USB mass-storage device and plays files from it... :-) |
10:23:43 | linuxstb_ | No - it's reverse-engineering the itunes database on the ipod. |
10:23:51 | XShocK | ok. i will go home tomorrow and try to find that thingy in my desk, and solder it on saturday... decided |
10:23:58 | B4gder | at least they used reverse-engineered info |
10:24:05 | Zagor | linuxstb_: aha, ok |
10:24:23 | B4gder | Zagor: you seen the file names used on an ipod? ;-) |
10:24:27 | Zagor | yes... |
10:24:39 | Zagor | otoh, they could simply scan the drive and make the list themselves. it doesn't say. |
10:24:47 | preglow | i wondows how gcc does at generating thumb code |
10:24:49 | Zagor | (unless you have other sources with more info) |
10:25:12 | preglow | wondows |
10:25:14 | preglow | nice word |
10:25:22 | Zagor | they'll need some scanning anyway to support non-ipod players |
10:25:49 | linuxstb_ | Zagor: The filenames are obfuscated - so presenting a list of filenames is not useful. |
10:25:53 | B4gder | preglow: -mthumb |
10:27:20 | Zagor | linuxstb_: perhaps indexing tags, like we do? |
10:27:33 | linuxstb_ | Zagor: Maybe. |
10:29:41 | | Quit Hadaka (Remote closed the connection) |
10:29:42 | preglow | the apple firmware is remarkably unusable |
10:29:44 | | Join Naked [0] (i=naked@naked.iki.fi) |
10:29:44 | | Nick Naked is now known as Hadaka (i=naked@naked.iki.fi) |
10:30:02 | B4gder | nooooo, apple is king! |
10:30:05 | Zagor | preglow: no no, it's the BEST! you don't understand!! |
10:30:06 | B4gder | :-P |
10:30:20 | Zagor | Steve, tell him! |
10:30:39 | B4gder | /invite Steve #rockbox |
10:30:41 | B4gder | oops |
10:31:03 | preglow | it's remarkably nice to look at pictures with |
10:31:06 | preglow | considering the small screen |
10:32:20 | B4gder | how big is it? I mean physically |
10:33:19 | preglow | gimme a sec |
10:33:32 | XShocK | btw, did GCC 4.0 finally introduced any improvement in speed? |
10:33:36 | preglow | 31mmx24mm |
10:33:46 | preglow | XShocK: no, quite the opposite |
10:33:48 | | Join webguest67 [0] (n=c2848364@labb.contactor.se) |
10:33:51 | preglow | XShocK: at least for some codecs |
10:34:10 | webguest67 | how long until rockbox on h3xx linus ? |
10:34:17 | XShocK | bad |
10:34:27 | B4gder | almost the exact size of the archos rec screen |
10:34:30 | LinusN | webguest67: not sure, i'm working on it |
10:34:48 | | Part linuxstb_ |
10:35:25 | webguest67 | good but ive seen that you have got info about the lcd :D |
10:36:20 | webguest67 | im really looking forward to the firmeware !:D |
10:36:35 | LinusN | webguest67: me too :-) |
10:37:37 | webguest67 | hope it wont take loong :D |
10:37:48 | webguest67 | keep up the good work rockbox crew ! |
10:39:16 | | Quit webguest67 ("CGI:IRC (EOF)") |
10:45:45 | | Join mashalla [0] (n=dj-dave@p5498BA9B.dip.t-dialin.net) |
10:50:30 | amiconn | LinusN: [10:02:40] <LinusN> it's funny, we have this discussion with every new developer :-) <== not with me :) |
10:50:36 | ashridah | aah, the optimisim of the masses |
10:50:54 | B4gder | amiconn: you want it now instead? B-] |
10:51:01 | amiconn | No |
10:51:02 | preglow | haha |
10:51:04 | preglow | not with me either! |
10:51:18 | B4gder | hm, we clearly are loosing it |
10:51:34 | amiconn | B4gder: Certainly not |
10:51:40 | preglow | if me and amiconn teams up, i'm sure we can convert you to do the wonders of malloc |
10:51:45 | B4gder | hehe |
10:52:31 | amiconn | malloc() would eat memory for no reason and bloat the code |
10:52:46 | preglow | it wouldn't eat any more memory than we currently do |
10:52:51 | preglow | but the code would be ugly |
10:53:01 | preglow | as a matter of fact, we _would_ eat more memory |
10:53:08 | preglow | thanks to fragmentation |
10:53:20 | B4gder | and to the malloc functions |
10:53:33 | B4gder | I mean the actual additional code |
10:53:37 | preglow | no, can't say i miss mallocs |
10:54:14 | B4gder | I could imagine offering malloc() to plugins |
10:54:40 | B4gder | if we ever think of a half-baked reason that would benefit anyone |
10:54:56 | preglow | is there currently anyway to dynamically change the size of the playback buffer? |
10:54:59 | preglow | any way |
10:55:14 | B4gder | preglow: yes, it is changed at startup |
10:55:26 | B4gder | but only then |
10:55:30 | preglow | that's not dynamically :) |
10:55:38 | B4gder | well, its not fixed at build time |
10:55:58 | preglow | we might need ways to allocate buffers in the future |
10:55:58 | B4gder | but then no |
10:56:02 | preglow | as a matter of fact, we do now |
10:56:06 | preglow | with the disk cache |
10:56:12 | preglow | it currently needs to reboot |
10:56:31 | preglow | when i get around to making dsp plugins one day, we'll probably need a way to allocate ring buffers |
10:56:36 | *** | Saving seen data "./dancer.seen" |
10:56:40 | preglow | requiring a restart for all this is a bit ugly |
10:56:46 | | Join amiconn_ [0] (n=jens@p54BD4E5F.dip.t-dialin.net) |
10:57:08 | B4gder | preglow: I'll enjoy reading your suggestion on how we'll accomplish that otherwise ;-) |
10:57:21 | preglow | B4gder: it would entail flushing the buffer, of course... |
10:57:27 | B4gder | right |
10:57:38 | preglow | but i still believe that's better than restarting |
10:57:43 | preglow | it even takes less battery |
10:57:53 | B4gder | it would of course be possible if done correctly and controlled |
10:57:58 | preglow | yes, sure |
10:58:25 | preglow | in some cases we might not even need to stop playback |
10:58:35 | preglow | if the portion of the buffer we need is already played and waiting for rebuffering |
11:00 |
11:00:05 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
11:04:17 | | Join Lost-ash [0] (i=ashridah@220-253-123-49.VIC.netspace.net.au) |
11:04:58 | | Quit ashridah (Nick collision from services.) |
11:05:00 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-123-49.VIC.netspace.net.au) |
11:06:20 | | Quit BirdFish (Read error: 110 (Connection timed out)) |
11:09:39 | | Join snarf [0] (n=snarf@62.135.199.42) |
11:10:32 | | Join amiconn__ [0] (n=jens@p54BD43B2.dip.t-dialin.net) |
11:11:45 | | Quit amiconn (Read error: 110 (Connection timed out)) |
11:11:45 | | Nick amiconn__ is now known as amiconn (n=jens@p54BD43B2.dip.t-dialin.net) |
11:13:04 | | Join Webguest82 [0] (n=jungti12@58.77.81.75) |
11:15:42 | | Quit Strath (Read error: 104 (Connection reset by peer)) |
11:18:20 | | Quit amiconn_ (Nick collision from services.) |
11:22:03 | * | preglow hugs putty |
11:23:31 | XShocK | what am i doing at 5:30 in the morning? |
11:24:33 | preglow | am i supposed to guess? ;) |
11:25:00 | Webguest82 | The Korea is 19 : 24. |
11:25:33 | B4gder | http://timeanddate.com/worldclock/ |
11:26:24 | Webguest82 | hehe.. |
11:27:26 | XShocK | :) |
11:27:42 | Webguest82 | Because of time difference, is uncomfortable. |
11:30:29 | | Quit Webguest82 ("Good Bye~ http://cafe.naver.com/iriverh300") |
11:42:12 | | Quit Jungti1234 ("Bye Bye~ http://cafe.naver.com/iriverh300") |
11:52:37 | | Quit snarf (Read error: 110 (Connection timed out)) |
11:59:37 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
12:00 |
12:00:07 | | Join webguest52 [0] (n=3e418ed5@labb.contactor.se) |
12:05:21 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
12:07:06 | | Join Febs [0] (n=cfac7a51@labb.contactor.se) |
12:07:10 | | Quit webguest52 ("CGI:IRC (EOF)") |
12:14:32 | | Join muesli- [0] (n=muesli_t@141.71.4.184) |
12:14:56 | muesli- | high |
12:24:25 | Jungti1234 | hi |
12:40:08 | | Join elinenbe_ [0] (i=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
12:40:08 | | Quit elinenbe (Read error: 104 (Connection reset by peer)) |
12:40:14 | | Nick elinenbe_ is now known as elinenbe (i=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
12:42:35 | | Quit elinenbe (Client Quit) |
12:42:53 | | Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
12:46:59 | * | preglow kicks sourceforge |
12:47:08 | preglow | anyone got the ipodlinux cvs url? |
12:47:53 | | Quit Jungti1234 ("Bye Bye~ http://cafe.naver.com/iriverh300") |
12:49:22 | | Quit linuxstb (Remote closed the connection) |
12:49:28 | B4gder | sourceforge is clearly not playing ball atm |
12:49:38 | preglow | no shit, i just thought their cvs might be |
12:49:49 | | Join linuxstb [0] (n=linuxstb@host213-123-154-169.in-addr.btopenworld.com) |
12:50:14 | linuxstb | preglow: http://sourceforge.net/projects/ipodlinux/ |
12:50:38 | preglow | so THAT web page works |
12:50:38 | preglow | haha |
12:50:47 | linuxstb | They've had problems recently with anon cvs for projects starting with the letter "i" :) |
12:51:20 | preglow | hahah |
12:51:30 | preglow | sounds like they've got some kind of lottery going |
12:51:43 | linuxstb | I forget where I found the link, but there is an ipodlinux-cvs mailing list that's worth subscribing to. The only way to reliably get diffs if you're not an ipl developer. |
12:52:12 | linuxstb | It's not a very active list though... |
12:52:49 | B4gder | their lack development community "services" surprises me |
12:53:17 | B4gder | insert "of" somewhere |
12:53:39 | linuxstb | Yes, it's very disjointed. No single unified build system for a start. You pick up bits and pieces from different places. |
12:55:25 | preglow | i don't get their cvs |
12:55:28 | preglow | what should i download? |
12:55:33 | preglow | linux? linux-2.6? |
12:55:35 | linuxstb | preglow: Everything. |
12:55:42 | preglow | aight |
12:56:08 | preglow | sigh, one more project using sf cvs |
12:56:12 | linuxstb | Ignore linux-2.6 - it's a (probably abandoned) attempt to get the 2.6 kernel working. ipl is currently using the 2.4 series. |
12:56:37 | *** | Saving seen data "./dancer.seen" |
12:56:50 | linuxstb | The interesting code is in linux/arch/armnommu/mach-ipod/ and tools/podzilla/ |
12:56:56 | preglow | uClinux-dist? |
12:57:01 | | Join BirdFish [0] (n=bradbox8@64.108.5.134) |
12:57:24 | linuxstb | No idea. |
12:57:44 | preglow | i'll just ignore that for now, then |
12:58:18 | linuxstb | podzilla uses microwindows for display - the microwindows drivers are in tools/microwindows/src/drivers/ |
12:58:41 | linuxstb | But that doesn't give us any more info than the framebuffer kernel driver. |
12:58:56 | Slasher | preglow: I will implement CFI -routines to rockbox core so it can save settings to flash if supported (and using rombox) |
12:59:01 | * | preglow strokes the Rockbox kernel |
12:59:07 | preglow | how i love the fact we don't use linux |
12:59:12 | Slasher | rombox for iriver isn't that far away now :) |
12:59:13 | preglow | Slasher: sounds nice |
12:59:42 | Slasher | And the functions should be safe, they refure to erase any critical areas |
13:00 |
13:00:01 | linuxstb | As daps start doing more things and connecting with other hardware, then I think Linux does become useful. But we're not there yet. |
13:00:33 | Slasher | And when flashing the rombox, erasing and writing to non-critical areas are tried first before erasing the critical area |
13:01:29 | preglow | Slasher: perhaps it would be wise to do the config sector saving using some flash exhaustion preemptive methods? |
13:01:34 | linuxstb | I wouldn't want to implement things like USB, Bluetooth, ethernet, wi-fi etc in Rockbox. |
13:01:39 | preglow | i don't know how many write cycles the flash is supposed to take |
13:01:55 | Slasher | preglow: yes, true. We should prevent unnecessary erases |
13:02:06 | Slasher | flash is guaranteed to last at least 100 000 cycles |
13:02:16 | preglow | then i don't know whether we should worry at all |
13:02:36 | preglow | most flash chips surpass their guaranteed limits by _far_ |
13:03:43 | Slasher | Hmm, and the eeprom chip endurance is 1M cycles |
13:03:50 | Slasher | So flash is almost that good :) |
13:03:59 | | Join justsomeperson [0] (n=92a9198c@labb.contactor.se) |
13:04:10 | preglow | but there are ways |
13:04:16 | preglow | like allocating eight blocks for the config sector |
13:04:25 | Slasher | preglow: At least we could save the configs only when shutting down the unit |
13:04:26 | preglow | and using them in a round robin fashion |
13:04:36 | Slasher | yes |
13:04:38 | preglow | by writing a serial number that's incremented each time, you find out which is recent |
13:04:42 | Slasher | One block is 4096 bytes |
13:04:51 | preglow | we just need 512 bytes |
13:04:57 | preglow | but all flash is erased a block at a time |
13:04:59 | Slasher | So it can hold configs |
13:05:03 | Slasher | +8 |
13:05:06 | preglow | all flash i know of at least |
13:05:16 | preglow | so we need eight blocks |
13:05:17 | Slasher | Yep |
13:05:19 | preglow | for it to matter |
13:05:33 | preglow | still |
13:05:36 | preglow | i don't know if we should care |
13:05:41 | Slasher | We need one block from flash but we can use that block eight times before needing erase cycle |
13:05:54 | preglow | ahh, that's true |
13:05:56 | Slasher | So practically we could get 800 000 cycles endurance for that block :) |
13:06:04 | preglow | yep |
13:06:18 | preglow | well, it's an idea to keep at least |
13:06:57 | Slasher | yes, and should be easy to implement |
13:08:06 | Slasher | we just need to locate the latest config block from the flash block. And we can use the config block version number to find it. The latest block that has a version number that matches, is also the latest one |
13:08:17 | preglow | hmm, doesn't seem like you can adjust the contrast on a nano |
13:08:41 | preglow | linuxstb: anything you're currently working on? just so i know i'm not duplicating your effort |
13:08:56 | preglow | Slasher: yep, that's true |
13:09:14 | Zagor | preglow: colour screens don't normally have contrast settings, do they? the cameras and mobile phones I've seen all only have brightness |
13:09:26 | Slasher | i think we could use the last block from flash to save the configs into. There is a few blocks free space on the flash after the bootloader |
13:09:39 | preglow | Zagor: well, the colour has contrast, it seems |
13:09:43 | preglow | ipod color, that is |
13:09:51 | preglow | Slasher: sounds like a good idea |
13:12:53 | preglow | Zagor: forget that, i'm making a fool of myself |
13:13:09 | Zagor | ok :-) |
13:13:28 | preglow | i seriously doubt there's a inversion function as well |
13:14:05 | Zagor | Slasher: what's the rewrite rating on the flash? 1000 times? 10000? |
13:14:28 | Slasher | Zagor: 100 000 times says the specs |
13:15:02 | ashridah | the iriver writes its config data to flash? |
13:15:07 | ashridah | or am i reading this wrong? |
13:15:21 | preglow | eeprom |
13:15:22 | Slasher | Oh, typical endurance is 100 000 but guaranteed only 10 000 |
13:15:38 | preglow | Slasher: in which case i say we definitely go for the round robin config save |
13:15:56 | Slasher | Hmm, yes |
13:16:04 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
13:16:14 | Slasher | But we should still save the config only on shutdown |
13:16:24 | Zagor | what's the typical spinup time on the 1.8" disks? |
13:16:29 | preglow | couple of secs? |
13:16:52 | tucoz | Zagor: I just checked freshmeat. Rockbox is still in v2.4 over there |
13:17:23 | Slasher | Then we would have guaranteed endurance 80 000 times using one block and user could reboot the player 43 times a day and that flash block would last at least 5 years |
13:17:27 | Zagor | tucoz: oops |
13:17:35 | tucoz | :) |
13:18:18 | Zagor | remind me: why do we want to use the flash instead of the disk? |
13:18:33 | preglow | so we don't need to wait for it spinning up? |
13:18:36 | Slasher | Zagor: probably for faster boot time when using rombox |
13:18:38 | preglow | more battery left? |
13:19:28 | Zagor | well it only needs to spin up when we shut down, if the disk hasn't spun since last config change. it's not very common. |
13:19:29 | Slasher | but if user has not flashed rockbox, then we shouldn't use the flash at all |
13:20:00 | preglow | of course |
13:20:08 | Zagor | i don't see much of a point anyway. what can we do in rockbox without the disk? i.e. what good is it booting fast when we must wait for the disk anyway? |
13:20:08 | Slasher | Hmm, my player always spins up the disk on shutdown.. |
13:20:18 | tucoz | The plugins would fit in flash, right? |
13:20:34 | preglow | tucoz: i think we'll rather put the codecs there |
13:21:03 | Slasher | Zagor: We can start doing other initializations (such as audio) without needing to wait the disk |
13:21:17 | tucoz | preglow: of course, that is a priority. But, if they fit as well, then that would be cool |
13:21:17 | Slasher | so it should give a few seconds faster boot.. But i will test that soon |
13:21:22 | Zagor | Slasher: do we need to the config to init the audio? |
13:21:35 | Slasher | Zagor: I think currently the config is the first thing loaded |
13:21:42 | tucoz | I think it is a bit annoying with the disk spinups all the time ;) |
13:21:57 | Slasher | and yes, we do.. At least on some level |
13:24:16 | preglow | linuxstb: doesn't seem like the empty lcd-ipod.c functions will be filled anytime soon... |
13:24:26 | preglow | i'll just remove the warnings, i can't stand all the console spamming when building |
13:30:27 | | Quit tucoz ("CGI:IRC") |
13:38:53 | Zagor | I don't like using the flash this way. The better solution is to change the init code so it doesn't require the settings. |
13:39:15 | Zagor | It's both safer and mort portable |
13:40:33 | preglow | but the init code always will |
13:40:40 | Zagor | why? |
13:40:40 | preglow | you can't do the disk cache without the settings, for example |
13:40:54 | preglow | since that needs to work pre-mp3buffer alloc |
13:41:02 | Zagor | then place that last |
13:41:29 | Zagor | we can't do a complete boot without disk anyway. this is only about rearranging things so we do it the most efficient |
13:42:02 | Zagor | fonts and wps files etc need to be loaded too |
13:42:13 | preglow | let's keep them in flash! :) |
13:42:17 | Zagor | hehe |
13:42:25 | linuxstb | preglow: You could also remove any obviously broken code from the ipod lcd driver - there are lots of drawing functions which are simply copies of the lcd-h100.c versions. |
13:43:15 | preglow | yep |
13:43:18 | preglow | looking at button driver right now |
13:44:14 | | Quit DJDD ("Trillian (http://www.ceruleanstudios.com") |
13:47:45 | linuxstb | preglow: I'm not working on anything at the moment, so carry on. If you're going to work on the buttons, then I'll probably do some work trying to get the main Rockbox building - the lds file, crt0.S etc. |
13:47:54 | amiconn | Slasher: I seriously doubt that saving the configs in flash will speed up booting much |
13:48:34 | linuxstb | It would be nice to get it to a stage where it would make sense for Bagder to add it to the automatic builds. |
13:48:39 | amiconn | We already discussed it in the past for archos |
13:48:44 | preglow | amiconn: not speed up booting, speed up shutting down |
13:48:57 | amiconn | Of course on the archos there's the additional problem that not all units are flashable |
13:49:04 | preglow | linuxstb: yeah, i'll just do the button driver first, since that can be verified to work from the bootloader |
13:49:22 | linuxstb | Well, almost everything can be tested in the bootloader. |
13:49:22 | amiconn | ...and the flash is way smaller |
13:49:46 | preglow | linuxstb: anywho, i'm more in the trying-to-get-an-overview stage as of now |
13:49:53 | preglow | i might end up working on whatever. we'll see |
13:50:04 | amiconn | linuxstb: The 16bit lcd format is known, right? |
13:50:12 | linuxstb | preglow: Well, if I start working on anything, I'll let you know. |
13:50:19 | linuxstb | amiconn: You mean for the ipod? |
13:50:39 | amiconn | yes |
13:51:16 | linuxstb | Yes - the lcd driver is working fine. The data is written to the LCD as a 32-bit value consisting of two horizontally adjacent pixels. |
13:51:20 | amiconn | I'm thinking about adapting the simulator code for highcolour, then one could work on the drawing routines without having a high colour target |
13:51:40 | linuxstb | Each 16-bit value contains the rgb565 value for that pixel. |
13:51:51 | amiconn | The win32 sim will be way easier to adapt than the x11 one |
13:52:13 | B4gder | how so? |
13:52:26 | preglow | but it seems the ipod keys can be interrupt controlled |
13:52:32 | preglow | i wonder if i should bother with that |
13:53:01 | amiconn | B4gder: Because it doesn't involve fiddling with x11 deficiencies. |
13:53:13 | B4gder | chicken! ;-) |
13:53:21 | amiconn | On windows, a display bitmap is essentially a .bmp in memory |
13:53:43 | preglow | does any of the other platforms support irq for controls, btw? |
13:53:54 | amiconn | nope |
13:53:59 | preglow | okies |
13:54:08 | preglow | i think i'll just try a polling approach for now |
13:54:13 | amiconn | All current button drivers poll the status, once per tick |
13:54:29 | preglow | though doing it interrupt style would just entail accessing the event quue from the isr, yes? |
13:54:53 | | Join B4gd3r [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
13:55:31 | amiconn | There is no way to fire button interrupts on these platforms. |
13:56:00 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
13:56:12 | amiconn | Some buttons are connected to gpio pins, most use resistor networks to connect several buttons to an adc input |
13:56:15 | Zagor | preglow: shutdown can be sped up by faking it |
13:56:22 | Zagor | like all mobile phones do |
13:56:31 | linuxstb | LinusN: Is the 16-bit mode of the H300 LCD the same as the ipod? i.e. rgb565 ? |
13:56:35 | preglow | Zagor: some not successfully |
13:56:50 | preglow | amiconn: i know, but if interrupts were possible that would be all there was to it, yes? |
13:56:54 | Zagor | preglow: how do they fail? |
13:57:07 | preglow | amiconn: just remove the handler from the tick queue and tinker with the event queue from an isr? |
13:57:18 | amiconn | yes, that should work |
13:57:34 | amiconn | The tick functions are also running in isr context |
13:57:50 | amiconn | ...of the timer tick interrupt |
13:57:53 | preglow | Zagor: in my case it just seems like it pretends to shut off long before it does, but it's easily visible in that the lcd is active long after it appears to have been shut off |
13:57:55 | | Join ep0ch_ [0] (n=ep0ch@84.12.192.105) |
13:58:12 | preglow | amiconn: yes, but this way the overhead would be much lower |
13:58:21 | preglow | since the keyhandler wouldn't be run every tick anymore |
13:58:28 | preglow | anywho, i'll deal with that later |
13:59:41 | linuxstb | There is one new feature the ipods have - charging via USB. IPL handles it by asking a user what they want to do when they insert a USB cable - charge or enter disk mode. |
13:59:52 | preglow | static void opto_i2c_init(void) |
13:59:55 | ep0ch_ | Slasher: something is annoying me with the track buffering... |
13:59:57 | preglow | anyone know what that could be? |
14:00 |
14:00:42 | linuxstb | All I know is that it's part of the button init code. |
14:00:57 | preglow | yeah, i know, i just wonder if i'll confine the code there |
14:01:08 | ep0ch_ | Slasher: basically if i play a song that is buffered and hit left to restart the track again, why does the song get rebuffered from disk and not memory? |
14:01:13 | preglow | in the button driver file, that is |
14:01:30 | linuxstb | ep0ch_: Because the data has been marked "dirty" and has possibly been overwritten with a future track. |
14:01:30 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
14:01:54 | preglow | shouldn't it be easy to see if that's actually happened? |
14:02:12 | preglow | if the buffering pointer is behind the curplaying pointer, then it's ok and it's not been overwritten |
14:02:28 | Zagor | preglow: ok that is bad faking. we are much better at faking! ;-) |
14:02:55 | linuxstb | It would seem a useful optimisation. |
14:03:28 | preglow | seems i actually _have_ to use an interrupt |
14:03:32 | preglow | the button interface is i2c |
14:03:59 | linuxstb | preglow: Yes, my impression was that we had to use interrupts. |
14:04:05 | preglow | grah |
14:04:09 | preglow | this'll be a feast |
14:04:35 | preglow | i'm willing to bet the interrupt controller has to be set up first as well |
14:04:54 | linuxstb | There is button code in the bootloader which doesn't use interrupts, but I don't think it works very reliably. |
14:05:06 | preglow | or no, i keep forgetting about the apple bootloader, perhaps that does it for us |
14:05:07 | linuxstb | At least, not on 4G devices like ours. |
14:05:41 | preglow | 1g, 2g and 3g use ordinary gpio based handling |
14:07:44 | preglow | linuxstb: the ipl bootloader? |
14:07:47 | preglow | can't see anything in yours |
14:07:51 | linuxstb | Yes, sorry. |
14:08:14 | linuxstb | tools/ipodloader in the ipl cvs |
14:08:20 | ep0ch_ | dumb question, does ipod do mp3+aac decoding in software or does it have dedicated hardware? |
14:08:27 | linuxstb | software. |
14:08:28 | preglow | software |
14:08:31 | ep0ch_ | nice |
14:08:58 | ep0ch_ | i'm really very tempted to get one now :) |
14:10:11 | ep0ch_ | you played doom on your nano yet preglow? |
14:10:14 | preglow | linuxstb: it's not in cvs? |
14:10:15 | | Quit B4gder (Read error: 110 (Connection timed out)) |
14:12:53 | linuxstb | preglow: What isn't in CVS? |
14:13:16 | preglow | the bootloader |
14:13:26 | preglow | could only find it on their project page |
14:13:47 | linuxstb | Yes - the ipl bootloader is in the tools/ipodloader directory of the ipl cvs. |
14:14:02 | linuxstb | The same directory as "make_fw.c" |
14:14:18 | preglow | remarkable, the only thing i have in the tools is patch_fw and ivdeo |
14:14:20 | preglow | video |
14:14:33 | linuxstb | Dodgy cvs checkout by the sounds of it. |
14:14:54 | preglow | yes, and now cvs refuses to answer again |
14:14:55 | preglow | bah |
14:15:01 | preglow | i'll just look at the tarball for a bit |
14:15:22 | linuxstb | My local copy of their CVS is a mess, but I'll upload the ipodloader directory for you. |
14:16:37 | linuxstb | http://www.davechapman.f2s.com/rockbox/ipodloader.tgz |
14:17:12 | preglow | thanks |
14:17:45 | linuxstb | Do you think we should add make_fw to the Rockbox CVS? |
14:18:21 | B4gd3r | I think so |
14:18:26 | | Nick B4gd3r is now known as B4gder (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
14:18:52 | | Quit muesli- ("ich will Kühe!!!") |
14:19:21 | linuxstb | Or we could possibly add the functionality to scramble. |
14:19:37 | B4gder | that would be even better |
14:19:45 | B4gder | if it makes sense |
14:19:54 | preglow | hmm |
14:19:55 | linuxstb | I'll have a think about it. |
14:19:58 | preglow | i don't think it does |
14:20:07 | preglow | mkboot.c is the closest thing i think we've got |
14:21:29 | linuxstb | I think you're right - scramble is for rockbox itself. We only need make_fw for the bootloader. |
14:22:50 | preglow | but what the hell does "opto" mean?? |
14:26:38 | linuxstb | No idea. |
14:28:52 | | Quit mashalla (Read error: 104 (Connection reset by peer)) |
14:33:10 | | Quit paugh ("Leaving") |
14:33:38 | | Quit Febs ("CGI:IRC (Ping timeout)") |
14:44:10 | * | preglow wonders what device his ipod is under cygwin... |
14:45:10 | * | preglow finds out |
14:46:28 | preglow | my, my, is cygwin slow |
14:47:50 | preglow | okokok |
14:47:52 | preglow | i wont be doing that again |
14:48:32 | preglow | it overwrote parts of my second fat partition as well |
14:48:38 | B4gder | cygwin is painfully slow |
14:48:48 | preglow | and inaccurate, it seems |
14:49:08 | preglow | glad i didn't try it out on my hard drive first |
14:49:56 | amiconn | cygwin isn't inaccurate |
14:51:05 | | Join kurzhaarrocker [0] (n=Phil@p5090AFBF.dip0.t-ipconnect.de) |
14:51:08 | preglow | why did it screw up my partition, then? |
14:51:14 | preglow | i wrote a four meg file to sdc1 |
14:51:19 | preglow | and sdc2 broke completely in the process |
14:51:26 | linuxstb | That should have been sdc (I think) |
14:51:40 | linuxstb | Sorry, forget that. |
14:51:44 | linuxstb | Thought you said 4G |
14:52:01 | | Quit B4gder ("time to say moo") |
14:52:06 | preglow | your wiki page says partition one, and that's what i've been doing all along |
14:52:22 | | Part kurzhaarrocker |
14:52:23 | linuxstb | Yes, you're right. Ignore my previous three sentences. |
14:52:24 | preglow | and it works |
14:52:38 | preglow | dd if=rockboot.bin of=/dev/sdc1 |
14:52:41 | preglow | that's what i did with cygwin |
14:52:44 | linuxstb | And sdc1 should be about 80MB. |
14:52:52 | preglow | 4801024 bytes (4.8 MB) |
14:52:54 | preglow | that's what it said |
14:53:06 | linuxstb | Does "fdisk" work in cygwin? |
14:53:07 | preglow | and now apple firmware can't find a partition as it boots |
14:53:44 | linuxstb | It doesn't do something stupid like numbering the partitions at 0 ? |
14:53:53 | linuxstb | i.e. /dev/sdc0 for the first partition? |
14:54:53 | amiconn | preglow: Hmm, I didn't have such problems, but then I mainly used raw devices, not partitions |
14:54:56 | preglow | now that WOULD be stupid |
14:55:06 | preglow | linuxstb: but yes, i believe that is what has happened |
14:55:11 | linuxstb | Does "dd if=/dev/sdc0 of=test.bin" do anything? |
14:55:17 | preglow | i'm convinced, actually |
14:55:49 | preglow | but lookie |
14:55:53 | preglow | sdc0 doesn't exist |
14:56:26 | linuxstb | What about sdc2? |
14:56:40 | *** | Saving seen data "./dancer.seen" |
14:56:55 | preglow | doesn't exist |
14:56:57 | preglow | only sdc1 exists |
14:57:01 | preglow | hahah |
14:57:10 | linuxstb | Strange. |
14:58:23 | preglow | if it now turns out that cygwin doesn't map partitions it doesn't know what is... |
14:58:23 | preglow | bah |
14:58:23 | preglow | i'll just have to turn to linux for this, i guess |
14:58:23 | linuxstb | Yes, the boot partition is marked as type 0 - empty. |
14:58:29 | | Join kurzhaarrocker [0] (n=Phil@p5090AFBF.dip0.t-ipconnect.de) |
14:58:37 | amiconn | You could change the type of partition 1, write it, then change type back to 0 |
14:58:51 | linuxstb | Does writing to /dev/sdc work? If so, you can still do it by writing to the correct area of the drive. |
14:58:52 | amiconn | (reading & writing the mbr with /dev/sdc and count=1 |
14:59:41 | linuxstb | You would probably have to disconnect and reconnect the ipod for cygwin to re-read the partition table. |
14:59:57 | preglow | amiconn: sdc0 works, yes, and is the mbr |
15:00 |
15:00:00 | preglow | ahh |
15:00:01 | preglow | sdc |
15:00:20 | preglow | does dd have a skip parameter? |
15:00:27 | linuxstb | Yes, "skip" |
15:00:29 | preglow | ok |
15:00:31 | preglow | so skip=1 ? |
15:00:36 | preglow | no |
15:00:36 | preglow | more than that |
15:00:41 | preglow | how much? |
15:01:08 | preglow | think i'll just repartition this bitch first |
15:02:32 | preglow | itunes doesn't recognize it |
15:02:33 | amiconn | The start of the first partition depends on the (faked) disk geometry |
15:02:44 | | Quit kurzhaarrocker (Client Quit) |
15:02:46 | amiconn | You can get that info from the mbr |
15:03:21 | preglow | i think i'll just boot linux |
15:03:53 | preglow | this'll end with me destroying my disks thanks to some whim of windows, i'm sure |
15:04:31 | | Join kurzhaarrocker [0] (n=Phil@p5090AFBF.dip0.t-ipconnect.de) |
15:08:01 | Slasher | ep0ch_: start of the song gets always overwritten with another tracks |
15:08:49 | Slasher | when buffering starts, it will recalculate the free buffer space while loading a new chunk, so it will overwrite the beginning |
15:09:23 | ep0ch_ | hmm |
15:10:00 | Slasher | of course if you have more tracks buffered, skipping to the beginning will not spin up the disk - unless it's the first buffered dirty track |
15:10:48 | LinusN | Slasher: would it be hard to prevent overwriting the first track? |
15:11:35 | Slasher | LinusN: shouldn't be hard, |
15:12:14 | Slasher | it's just matter how efficiently we want to use the buffer space |
15:12:34 | preglow | ok |
15:12:50 | preglow | sdc1 has strings MSDOS and FAT32 in it |
15:13:04 | preglow | another reason why i'll never like cygwin, this |
15:14:42 | Slasher | for example if user skips tracks a lot, then we probably shouldn't even use the all available buffer space. Instead we could keep old tracks in buffer and load only a few new tracks |
15:16:16 | ep0ch_ | how to decide what type of buffering to use will be interesting :) |
15:18:11 | Slasher | true :) |
15:19:08 | | Quit kurzhaarrocker (Remote closed the connection) |
15:19:46 | ep0ch_ | maybe rockbox could learn the users usage pattern. or just be boring and have another user setting. |
15:20:51 | Slasher | Hmm, setting for this could be too overkill. Probably a good solution is just to keep the first track (with some limit with memory size) |
15:22:14 | justsomeperson | proposal: load just one track at a time unless user listened two two tracks in a row in which case full buffer is used |
15:23:01 | Slasher | That sounds a good idea :) |
15:23:26 | crwl | maybe load two tracks at a time first at least |
15:24:23 | justsomeperson | by loading two you already assume that full buffer will be used... |
15:24:41 | | Quit ashridah ("sleep") |
15:25:06 | linuxstb | I think account should be taken of the bitrate of the file. This can be up to 1000kbit/s for some lossless files. |
15:25:36 | linuxstb | The get_metadata() routine calculates the bitrate - so it's done (or should be done) before the track is loaded. |
15:26:00 | ep0ch_ | more its 24bit 96khz etc... |
15:26:12 | ep0ch_ | ^if |
15:26:24 | preglow | ARGJHHH |
15:26:28 | justsomeperson | its actually just size of the track and not bitrate that matters |
15:26:28 | preglow | i _HATE_ itunes |
15:26:47 | ep0ch_ | whats it done? |
15:27:03 | preglow | intrusive, unusable piece of shit |
15:27:15 | ep0ch_ | do you now have to pay $0.99 for all your tracks again? |
15:27:24 | preglow | haha |
15:27:36 | preglow | i don't buy internet music |
15:27:44 | justsomeperson | right on :) |
15:27:45 | preglow | it just pops up everytime i plug in my ipod |
15:27:57 | linuxstb | preglow: Just uninstall it :) |
15:27:58 | preglow | so i have to unplug it again to use cygwin |
15:28:24 | linuxstb | In fact, you could do that and find a third-party app to load tracks onto the device. |
15:28:38 | preglow | such a thing exists? |
15:29:00 | linuxstb | I think there are many. GnuPod is a famous one for Linux. Foobar has an ipod plugin. |
15:29:09 | ep0ch_ | what does foo_pod do? |
15:29:23 | preglow | okokokko |
15:29:25 | preglow | i can't stand this |
15:29:32 | preglow | every bloody time i use cygwin dd to access the ipod |
15:29:35 | linuxstb | ep0ch_: I think it syncs a playlist to your ipod. |
15:29:38 | preglow | i need to unplug it again for it to work again |
15:29:42 | linuxstb | But I've never looked at it. |
15:29:43 | preglow | i think i'll uninstall cygwin in the same gop |
15:30:21 | justsomeperson | does anyone knows why in playback.c when loading a track there is special handling of the case when disk is not spinning (i.e. event is not queued in initiate_track_change() ) |
15:30:38 | ep0ch_ | preglow: Configure iTunes so it does not load when you connect your iPod. (not required, but highly recommended) |
15:30:38 | ep0ch_ | |
15:30:54 | Slasher | justsomeperson: that's for buffering |
15:30:57 | ep0ch_ | oops sorry for extra blank spaces |
15:31:07 | Slasher | if disk is already spinning, we will flush the old buffer |
15:31:22 | preglow | ep0ch_: did that |
15:31:26 | ep0ch_ | oh |
15:31:27 | preglow | ep0ch_: the cygwin problem remained |
15:31:29 | Slasher | (even in the case that track can be found already from the buffer) |
15:31:37 | preglow | it's starting to dawn on me that this i linux work |
15:31:38 | preglow | brb |
15:32:21 | justsomeperson | Slasher: aha, just that - nothing more ? |
15:33:05 | Slasher | nope. It just makes sure the buffer gets fully filled when the disk is spinning |
15:33:48 | Slasher | and also that the disk will not spin up if track is already loaded to the bufer |
15:34:04 | justsomeperson | thanks, that solves one problem I was working on |
15:34:11 | Slasher | good :) |
15:35:51 | | Nick Slasher is now known as Slasheri (i=miipekk@ihme.org) |
15:36:34 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-128-235.pools.arcor-ip.net) |
15:41:39 | amiconn | linuxstb: Bitrate is 1411kbis/s even for 44.1/16/stereo wav |
15:42:43 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
15:45:43 | | Join Midgey34 [0] (n=Midgey34@c-67-172-68-52.hsd1.mi.comcast.net) |
15:46:19 | linuxstb | amiconn: What do you mean "even for" ? |
15:47:49 | preglow | what the hell.... |
15:48:12 | preglow | when i cfdisk /dev/sdb now |
15:48:23 | preglow | the freespace doesn't have sdb1 beside it anymore |
15:48:33 | preglow | can the part table be screwed? |
15:49:08 | linuxstb | Possibly. Have you tried restoring your whole-device backup to /dev/sdb ? |
15:49:24 | linuxstb | Did you make a full backup? |
15:49:35 | preglow | yes |
15:49:49 | preglow | think i'll try that |
15:49:52 | linuxstb | Try restoring it, and then unplugging and reattaching. |
15:50:22 | linuxstb | If that doesn't work, you'll probably need to run Apple's "ipod restore" program from Windows. |
15:50:57 | preglow | giving it a go now |
15:52:54 | preglow | i miss the activity light of the h120, heh |
15:53:16 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
15:53:22 | linuxstb | #define LCD_VIRTUAL |
15:53:35 | Jungti1234 | hi |
15:53:38 | linuxstb | s/LCD/LED/ |
15:55:29 | | Join muesli_- [0] (i=muesli_t@Bc1ee.b.pppool.de) |
15:57:01 | preglow | linux doesn't automatically disable write caching for usb devices, does it? |
15:57:06 | | Join wacky [0] (n=wacky@modemcable129.119-82-70.mc.videotron.ca) |
15:57:28 | crwl | i don't think it does |
15:57:30 | wacky | hey guys, are you still looking for a dead iAudio to work on ? |
15:57:32 | crwl | you need to specify sync in fstab |
15:58:17 | wacky | and would a dead H120 be useful to you ? |
15:58:31 | preglow | in fstab? it's usb storage we're talking about here, it's not in fstab |
15:58:50 | crwl | i have it in fstab |
15:59:02 | crwl | where then? i don't have any automounter things here if you meant that |
15:59:09 | crwl | as a mount option anyway |
16:00 |
16:01:51 | preglow | i seem to do |
16:03:10 | | Quit Kohlrabi ("Leaving") |
16:04:40 | | Quit Zagor ("Client exiting") |
16:06:09 | preglow | well |
16:06:19 | preglow | i can under no circumstances get the ipod bootloader button code to work |
16:07:44 | linuxstb | Are there any kernel differences in the button driver for the nano? |
16:07:57 | preglow | for the nano, no |
16:07:59 | preglow | none as far as i can see |
16:08:40 | linuxstb | So I would expect the bootloader code that runs for hw_rev==6 should in theory also work for the nano. |
16:09:09 | linuxstb | But I also didn't have very much success with that code. |
16:09:17 | | Quit _FireFly_ ("REALITY.SYS Corrupted: Re-boot universe? (Y/N/Q)") |
16:10:05 | linuxstb | My feeling was that the bootloader code only detected changes in the button status. i.e. if you held a button down, then ran the bootloader, then it wouldn't know about the keypress. |
16:10:09 | preglow | but i also get some strange lcd corruptions when using it... |
16:10:13 | preglow | so i might be doing something horribly wrong |
16:10:38 | wacky | would a donation for the iAudio cause help a bit for that project ? |
16:10:48 | wacky | that porting effort ? |
16:14:54 | preglow | wacky: well, no |
16:15:04 | preglow | wacky: the coder doing the port just vanished, and i have no idea why |
16:15:11 | wacky | austriancoder ? |
16:15:14 | preglow | i don't think a donation will lure him back again, heh |
16:15:16 | preglow | wacky: yep |
16:15:26 | wacky | he vanished a couple of months ago, didn't he ? |
16:15:38 | amiconn | linuxstb: "Even for" was related to "This can be up to 1000kbit/s for some lossless files." and "<ep0ch_> more its 24bit 96khz etc..." |
16:15:47 | wacky | yeah but I read on the forums that LinusN would like to have a broken iAudio.. so he could unsolder every pieces |
16:16:36 | wacky | so I guess.. funding would help buying a broken (or a new) iAudio ? wouldn't it ? |
16:17:08 | wacky | but maybe not.. I know he doesn't have much time.. so I guess it won't be a priority |
16:18:18 | | Join Febs [0] (n=40be24f0@labb.contactor.se) |
16:19:21 | preglow | linuxstb: this is interesting... |
16:19:36 | preglow | linuxstb: a snprintf with no puts after it manages to distort all text |
16:20:04 | linuxstb | preglow: Yes, that sounds like my old problem back again. |
16:20:19 | preglow | how the hell can that be? |
16:20:47 | Jungti1234 | good night |
16:21:01 | linuxstb | preglow: I have absolutely no idea. There are no obvious buffer overflows that I could find. |
16:21:10 | preglow | i use snprintf, it can't overflow! |
16:21:21 | Jungti1234 | good luck |
16:22:08 | | Quit Jungti1234 ("Http://www.ZeroIRC.NET ¢Æ Zero IRC ¢Æ Ver 2.8") |
16:28:11 | preglow | i am completely dumbfounded |
16:28:18 | preglow | it's seems as if we write into the font buffer somehow |
16:28:53 | linuxstb | preglow: You could try looking at my boot.lds and crt0.S code to see if that looks correct. |
16:29:04 | preglow | hmm |
16:29:09 | preglow | the input button code actually works |
16:29:18 | preglow | at least one shot |
16:30:37 | preglow | i'll have a quick look at crt0.S |
16:30:39 | preglow | need to go soon |
16:33:11 | preglow | can't see anything totaly blatant |
16:33:13 | preglow | but i have to go |
16:33:14 | preglow | bbl |
16:36:28 | | Part LinusN |
16:40:59 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
16:43:24 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
16:49:56 | | Quit justsomeperson ("CGI:IRC (EOF)") |
16:56:44 | *** | Saving seen data "./dancer.seen" |
17:00 |
17:00:21 | | Join _FireFly_ [0] (n=FireFly@p54A47C10.dip.t-dialin.net) |
17:02:08 | | Join muesli- [0] (i=muesli_t@Bc129.b.pppool.de) |
17:06:58 | | Join [IDC]Dragon [0] (n=d90a3255@labb.contactor.se) |
17:07:20 | [IDC]Dragon | hi |
17:07:30 | [IDC]Dragon | Slasheri, do you read? |
17:08:05 | Slasheri | [IDC]Dragon: hi, i just came back home :) |
17:08:31 | [IDC]Dragon | I'd like tohave a chat with you about flash booting |
17:08:48 | Slasheri | that sounds good :) lets do so |
17:08:59 | [IDC]Dragon | I'd guess you could recycle a good part of what I did for Archos |
17:09:08 | Slasheri | [IDC]Dragon: what do you think about integrating your CFI code in plugins to core rockbox? |
17:09:17 | Slasheri | possibly :) |
17:09:26 | [IDC]Dragon | CFI? |
17:09:45 | Slasheri | the (common) flash interface code |
17:09:58 | [IDC]Dragon | (tm) |
17:10:07 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
17:10:09 | Slasheri | ReadId, EraseSector, WriteByte etc. |
17:10:17 | Slasheri | then all plugins / rockbox core could use it |
17:10:24 | [IDC]Dragon | I don't like it, becouse it's potentially hazardous code |
17:10:32 | Slasheri | Hmm, true.. |
17:10:47 | [IDC]Dragon | about the boot: |
17:11:02 | [IDC]Dragon | did you do a cvs co flash? |
17:11:19 | Slasheri | oh, i didn't :) i will try that |
17:11:23 | [IDC]Dragon | that contains all my tools |
17:11:33 | Slasheri | i didn't know that repository at all |
17:11:34 | [IDC]Dragon | for firmware authoring, etc |
17:11:41 | Slasheri | cool :) |
17:11:48 | Slasheri | i will check it |
17:12:10 | [IDC]Dragon | I think the dual boot would be nice for iriver, too |
17:12:25 | [IDC]Dragon | with compression, if you have to |
17:12:25 | Slasheri | Hmm, so it could have two rockbox images? |
17:12:39 | [IDC]Dragon | or original and rockbox |
17:12:39 | amiconn | In fact the iriver bootloader is what the combination of the archos flash bootloader+bootbox is |
17:12:47 | Slasheri | [IDC]Dragon: original firmware is too big |
17:12:57 | [IDC]Dragon | even compressed? |
17:13:07 | [IDC]Dragon | did you try ucl on it? |
17:13:09 | Slasheri | hmm, then we could load it from disk also.. |
17:13:22 | [IDC]Dragon | no, the point is to have a backup |
17:13:25 | amiconn | The iriver firmware copies itself to ram, but not as one continuous block afaik |
17:13:46 | Slasheri | [IDC]Dragon: i though something like having a bootloader at beginning of the flash and after that the firmware itself |
17:13:55 | [IDC]Dragon | ok, then do it in chunks |
17:13:59 | amiconn | [IDC]Dragon: The iriver bootloader *is* the backup, as it includes bootbox functionality |
17:14:28 | [IDC]Dragon | ant the uncompressed iriver fw, right? |
17:14:32 | [IDC]Dragon | and |
17:14:41 | amiconn | ?? |
17:14:43 | Slasheri | no |
17:14:52 | Slasheri | it's just a plain bootloader.. quite small in size |
17:15:07 | [IDC]Dragon | loading rockbox or iriver from disk? |
17:15:08 | amiconn | Well, it's larger than archos bootbox+flash loader |
17:15:14 | amiconn | yes |
17:15:29 | Slasheri | less than 65 KiB |
17:15:33 | Slasheri | *4 |
17:15:38 | [IDC]Dragon | that bootloader is new, or has always been like this? |
17:15:48 | * | [IDC]Dragon is iriver-confused |
17:15:48 | amiconn | It always has been like this |
17:15:50 | Slasheri | [IDC]Dragon: it has always been present in iriver |
17:16:09 | amiconn | The iriver firmware runs from flash although it copies itself |
17:16:31 | [IDC]Dragon | I thought you patch the original to attach a loader, then flash it |
17:16:33 | Slasheri | it's loacated at the end of the flash, starting at 0x1F0000 |
17:16:39 | amiconn | The bootloader 'hooks' into the boot process and either loads rockbox from disk, or passes control to the in-flash iriver firmware |
17:16:53 | amiconn | [IDC]Dragon: Yes, that's how it is done |
17:17:10 | [IDC]Dragon | so iriver is in flash, ok |
17:17:32 | Slasheri | [IDC]Dragon: iriver firmware is currently on the flash also but there is no reason to keep it there |
17:17:35 | amiconn | Yes, but in order to have rockbox in flash, we need to ditch the iriver firmware, or compress it |
17:17:55 | [IDC]Dragon | what's the conceptual difference to my Archos-style booting then? |
17:17:58 | Slasheri | yep, the iriver fw takes almost all available flash space |
17:18:20 | amiconn | [IDC]Dragon: In fact none, only the components are named different |
17:18:34 | Slasheri | and if we compress it, we cannot run it directly from flash.. either we can rockbox |
17:18:40 | Slasheri | but uncompressed we can |
17:19:05 | amiconn | I already said it two times: Our iriver rockbox bootloader is what the combination of the flash bootloader *and* bootbox is on archos |
17:19:32 | * | [IDC]Dragon is sorry for being so dumb |
17:19:45 | amiconn | So we need no additional backup |
17:20:19 | amiconn | The bootloader could simply be moved to the start of flash, and its defaults switched |
17:21:00 | amiconn | Today it loads from disk by default, and only loads from flash if either (1) you hold REC while booting or (2) the previous disk boot failed |
17:21:04 | [IDC]Dragon | if you want to bring rockbox in flash, you keep the "bootbox bootloader" and attach Rockbox |
17:21:06 | Slasheri | yep, that is what i had in mind |
17:21:43 | Slasheri | it could be patched to load from disk if user presses rec and automatically from flash |
17:21:48 | [IDC]Dragon | so you're close to having it like Archos with bootbox |
17:22:03 | [IDC]Dragon | need a plugin to flash only the Rockbox part |
17:22:40 | amiconn | Slasheri: Yes, and there's an additional shortcut that the bootloader can take: If loading rockbox from flash, it could skip ata init, lcd init etc |
17:22:49 | Slasheri | i think i will write a different flash plugin for iriver because the procedure is so different.. And include CFI interface functions in rockbox core with additional safety checks |
17:23:02 | Slasheri | amiconn: true |
17:23:14 | Slasheri | amiconn: it doesn't have to init the kernel at all |
17:23:26 | Slasheri | only when user bypasses the process by pressing rec or usb connection is found |
17:23:36 | amiconn | yes |
17:23:51 | amiconn | It should init the SDRAM though |
17:24:11 | [IDC]Dragon | or have a 1st level loader in front of it |
17:24:22 | [IDC]Dragon | (again like Archos) |
17:24:24 | amiconn | I would also prefer to keep flash functions out of the core |
17:25:10 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
17:25:13 | [IDC]Dragon | just trying to keep Slasheri from re-inventig the wheel |
17:25:53 | Slasheri | [IDC]Dragon: i am not trying at least re-inventing anything.. I would use the flash functions already found in your code |
17:26:20 | Slasheri | but iriver would have slightly different structure because of the bootloader |
17:26:27 | [IDC]Dragon | (hopefulley) no vanity of mine here, I just try to help |
17:27:04 | [IDC]Dragon | can Rockbox rolo the iriver firmware? |
17:27:16 | amiconn | no |
17:27:18 | Slasheri | not yet, but we think it should be possible |
17:27:29 | amiconn | There is no disk-based version of the iriver firmware |
17:27:41 | [IDC]Dragon | ok |
17:28:04 | amiconn | It can rolo, but only rockbox.iriver versions |
17:28:17 | amiconn | iriver-on-disk would need special handling |
17:28:34 | [IDC]Dragon | the scattered loading? |
17:29:01 | amiconn | yes |
17:29:14 | amiconn | Imho it's not worth it |
17:29:25 | Slasheri | amiconn: I would like to have the flash functions in the core, because that way all plugins could use them - safely if they need to. By default those functions would not allow to do anything harmful to the flash contents |
17:29:49 | [IDC]Dragon | what is *all plugins* ? |
17:30:22 | [IDC]Dragon | on the contrary, for Archos it's proposed to unite the 2 flash plugins |
17:30:26 | Slasheri | [IDC]Dragon: at least the firmware flashing plugins :) And then possible rockbox core |
17:30:39 | [IDC]Dragon | but I coudn't find the time |
17:31:08 | [IDC]Dragon | (nowadays I flash my little home network components over the net) |
17:31:26 | Slasheri | hehe |
17:31:31 | | Quit _FireFly_ ("Leaving") |
17:32:08 | | Join webguest64 [0] (n=52214ace@labb.contactor.se) |
17:33:01 | Slasheri | amiconn: the core itself also should have always correct information about the platform so it knows exactly how the flash is arranged without guessing |
17:35:02 | | Quit muesli- (Read error: 110 (Connection timed out)) |
17:35:28 | amiconn | The plugin knows this the same way, as the plugins are built per platform |
17:36:30 | [IDC]Dragon | for Archos, I introduced a "model ID" byte |
17:36:49 | Slasheri | amiconn: Hmm, so there is no possibility user could run a "wrong" plugin? |
17:37:27 | [IDC]Dragon | the plugin reads it for some sanity checks |
17:38:43 | [IDC]Dragon | there's different stages of checks: the plugin is built per model, checks that byte, the image has a CRC, etc |
17:38:45 | amiconn | Isn't he model id byte for checking whether the .bin file matches the platform? |
17:38:57 | [IDC]Dragon | yes |
17:39:24 | [IDC]Dragon | for V1 recorder, that byte is 0 |
17:39:34 | [IDC]Dragon | unfortunately, out of legacy |
17:39:59 | [IDC]Dragon | I introduced the byte later, when supporting more models |
17:40:24 | [IDC]Dragon | the byte is also 0 on all unflashed boxes |
17:40:29 | amiconn | Yes, and your first firmware_flash plugins fiddled with the rom version ;) That's why my rec v1 now has a v1.28 rom, which it didn't before flashing |
17:41:22 | [IDC]Dragon | yes, I stupidly changed that to 2.00 with my first images |
17:41:41 | [IDC]Dragon | I went more modest later |
17:42:20 | amiconn | Don't we keep the rom version nowadays? |
17:42:26 | | Join ripnetuk [0] (n=george@82-70-100-230.dsl.in-addr.zen.co.uk) |
17:42:37 | amiconn | On player we have to, but afaik we do it for all platforms |
17:42:50 | [IDC]Dragon | at least the mask, I'm not sure about the version right now |
17:44:38 | [IDC]Dragon | we preserve mask for recorders, version for players |
17:45:02 | [IDC]Dragon | the version is another key to model indentification |
17:46:31 | | Part ep0ch_ |
17:48:08 | ripnetuk | <LinusN> it's funny, we have this discussion with every new developer <−−- I remember my turn :) |
17:49:18 | [IDC]Dragon | which discussion? |
17:50:34 | ripnetuk | if we should have malloc or not... |
17:50:42 | [IDC]Dragon | ah |
17:50:52 | ripnetuk | until today I still thought i was right ( i thought we should have it), but the comment about worst possible case convinced me |
17:51:36 | [IDC]Dragon | once I was thinking about a fancy heap, using all free chunks for playback buffer |
17:51:38 | | Join hardeep [0] (n=hardeep@c-67-188-108-180.hsd1.ca.comcast.net) |
17:51:45 | amiconn | urgl |
17:51:54 | [IDC]Dragon | ovely complicated, I know |
17:52:02 | [IDC]Dragon | overly |
17:52:36 | ripnetuk | having a huge buffer only helps when you plan all tunes (up to buffer size) in the order they are in playlist |
17:52:40 | ripnetuk | which I very rarely do |
17:52:45 | amiconn | I know that there are ways top make malloc() work somewhat better on mmu-less platforms, but it's still messy |
17:53:10 | [IDC]Dragon | like constant-size lists? |
17:53:28 | Slasheri | it's not possible even in theory to use malloc, because we can't free the allocated memory |
17:53:39 | [IDC]Dragon | anyway |
17:53:47 | Slasheri | or we can, but it would become segmented and is useless |
17:53:50 | amiconn | First, separating small and large mallocs |
17:54:43 | amiconn | Yes, the best that can be done is reducing fragmentation, but it's impossible to completely avoid it |
17:54:48 | ripnetuk | Its as bagder said - we have to have enough available for worst possible case, so we might as well be static |
17:55:10 | ripnetuk | only case it would help is where 2 different parts of code cannot run together (ie 2 plugings) |
17:55:13 | ripnetuk | in which case, they can share a buffer |
17:55:17 | ripnetuk | a static one htat is |
17:55:33 | [IDC]Dragon | you can completely avoid it, but at the cost of high waste |
17:55:36 | ripnetuk | i guess malloc only makes sense when we have practically unlimited ram (ie swap) |
17:56:15 | amiconn | It would be prossible to do this if our platforms had a mmu |
17:56:22 | [IDC]Dragon | another wild idea of mine was to use the memory as a general disk cache, with readahead when playing |
17:56:23 | ripnetuk | btw i found a little problem with the new LCD remote code tImId did - you cannot say yes on the 'are you sure you want to delete' screen |
17:56:47 | ripnetuk | using the remote that is |
17:56:47 | amiconn | Yes, that's because these requests are not yet adapted |
17:57:02 | ripnetuk | ok, known issue then |
17:57:23 | amiconn | There's a lot that doesn't work yet on the remote |
17:57:28 | * | ripnetuk is well chuffed with recent progress on remote |
17:57:44 | ripnetuk | gotta go, talk to you guys latter |
17:57:57 | | Quit ripnetuk ("Ninja IRC v1.5.8.1(#1) exiting after 15m32s of use") |
17:58:59 | Midgey34 | would anyone be able to help setup and build the sim on linux? |
17:59:22 | linuxstb | Midgey34: Which distribution are you using? |
17:59:28 | Midgey34 | ubuntu |
17:59:49 | linuxstb | How far have you got? Have you downloaded the rockbox source code? |
17:59:52 | * | [IDC]Dragon waves goodby, too |
18:00 |
18:00:00 | Midgey34 | yes, I think I'm missing some of the x11 files needed |
18:00:23 | | Quit [IDC]Dragon ("CGI:IRC") |
18:00:29 | Midgey34 | screenhack.c:38:23: error: X11/Shell.h: No such file or directory |
18:00:36 | Midgey34 | where would I find these files? |
18:00:54 | linuxstb | You need to install the x11 development package(s) for ubuntu. |
18:01:14 | Midgey34 | do you know the names of these packages? my synaptic is currently broken |
18:01:27 | Midgey34 | apt-get works fine though |
18:02:00 | crwl | xlibs-dev is my guess |
18:02:23 | linuxstb | Try "dpkg -S Shell.h" - that should tell you which package includes that file. |
18:02:36 | linuxstb | In my debian installation, it's "libxt-dev" |
18:03:00 | crwl | xlibs-dev includes lots of development libraries, like libxt-dev |
18:03:36 | Midgey34 | well now the build gets further but I still some errors |
18:03:58 | Midgey34 | CC screenhack.c |
18:03:58 | Midgey34 | screenhack.c: In function ‘main’: |
18:03:58 | Midgey34 | screenhack.c:509: warning: missing sentinel in function call |
18:03:58 | DBUG | Enqueued KICK Midgey34 |
18:03:58 | Midgey34 | screenhack.c:520: warning: missing sentinel in function call |
18:03:58 | *** | Alert Mode level 1 |
18:03:58 | Midgey34 | screenhack.c:540: warning: missing sentinel in function call |
18:06:08 | Midgey34 | make[1] /Desktop/rockbox-all/tools/convbdf: Command not found |
18:06:24 | Midgey34 | make[1]: *** [/Desktop/rockbox-all/build-dir/firmware/sysfont.o] Error 127 |
18:06:28 | linuxstb | You need to type "make" inside that tools directory before you do anything else. |
18:08:29 | Midgey34 | well it appears to be building correctly |
18:09:39 | Midgey34 | alright, its built now, thanks for all the help |
18:11:27 | Midgey34 | and we have playback on mp3s excellent |
18:13:59 | *** | Alert Mode OFF |
18:21:06 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
18:33:40 | | Join muesli_- [0] (i=muesli_t@Bc14a.b.pppool.de) |
18:34:00 | | Quit Midgey34 ("Download Gaim: http://gaim.sourceforge.net/") |
18:34:03 | | Join arkascha [0] (n=arkascha@xdsl-213-168-117-82.netcologne.de) |
18:35:20 | muesli_- | re |
18:38:58 | | Join justsomeperson [0] (n=92a9198c@labb.contactor.se) |
18:45:25 | | Quit justsomeperson ("CGI:IRC") |
18:56:47 | *** | Saving seen data "./dancer.seen" |
18:58:40 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
19:00 |
19:03:41 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
19:07:42 | | Quit arkascha (Read error: 104 (Connection reset by peer)) |
19:08:24 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
19:19:19 | preglow | eh |
19:19:26 | preglow | sucky wather, i hates it |
19:19:52 | preglow | weather too |
19:27:39 | linuxstb | preglow: Any ideas about the corrupt LCD? |
19:28:01 | | Nick Lynx_ is now known as Lynx_awy (n=lynx@tina-10-4.genetik.uni-koeln.de) |
19:32:54 | preglow | linuxstb: nope, i was just wondering about that |
19:33:08 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-128-235.pools.arcor-ip.net) |
19:34:17 | | Join _user_ [0] (n=c762142c@labb.contactor.se) |
19:35:05 | | Quit _user_ (Client Quit) |
19:35:13 | | Quit hardeep (" HydraIRC -> http://www.hydrairc.com <- 100,000+ downloads can't be wrong") |
19:36:34 | linuxstb | Windows is so helpful. I've plugged my H140 into a windows PC on a company network and it helpfully tells me that it is connected via USB1 and that USB2 is better. It then offers to find me a USB2 port. I accept the offer, and then it tells me there are no usb2 ports... |
19:39:40 | preglow | hahaha |
19:40:08 | preglow | it'll bet that routine repeats the next time you insert it as well |
19:40:39 | linuxstb | Of course it does. |
19:41:07 | korpse | and, needless to say, you can't tell it to shut up about how damn great USB2 ports are |
19:41:51 | HCl | what version of windows do you use? |
19:42:00 | HCl | mine just says "this device can operate faster" |
19:42:06 | linuxstb | This is the same Windows PC that immediately deleted the tag database used by the iriver firmware (without asking me) when I first plugged my H140 into it. It claimed it contained a virus. |
19:42:36 | korpse | oh that's very nice |
19:42:43 | korpse | one for the history books |
19:42:48 | linuxstb | It's XP. It's a PC in a client's office that I use sometimes. |
19:43:04 | linuxstb | I have no control over what's on it, and just use it to transfer files to/from the company network. |
19:43:33 | | Join _FireFly_ [0] (n=FireFly@p54A47C10.dip.t-dialin.net) |
19:44:19 | linuxstb | HCl: Yes, that's the message I get. And an offer to do something about it - I forget the exact words. |
19:44:33 | _FireFly_ | good evening :) |
19:47:31 | preglow | you wont see me try to do ipod coding in windows again, that's for sue |
19:47:32 | preglow | sure |
19:48:57 | crwl | i've seen *several* XP machines that didn't accept my H120 at all because they didn't have USB2 drivers installed |
19:49:03 | crwl | (echi or whatever it is) |
19:49:09 | linuxstb | I'm sure there must be a utility that can read/write from/to a raw disk under Windows. |
19:49:34 | preglow | well, it's not cygwin dd at least |
19:49:35 | preglow | that's for sure |
19:50:13 | _FireFly_ | i know only one for floppy disks |
19:50:31 | _FireFly_ | rawwrite or something similar |
19:50:41 | preglow | yeah, but that's strictly floppy, i believe |
19:53:10 | linuxstb | preglow: Are you a delphi person? |
19:53:40 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
19:55:39 | preglow | linuxstb: nah |
19:55:43 | preglow | linuxstb: been years since i did pascal |
19:58:22 | linuxstb | Must be thinking of someone else. |
19:58:31 | linuxstb | Can't find any useful looking Windows utilities. |
19:58:54 | linuxstb | But the explore2fs project has a Delphi library for reading/writing to raw disks under all Windows versions. |
19:59:08 | linuxstb | Seems that it's not an easy thing to do. |
20:00 |
20:00:49 | preglow | surprise |
20:04:06 | | Join muesli_- [0] (i=muesli_t@A9394.a.pppool.de) |
20:04:39 | linuxstb | bbl. |
20:04:44 | | Quit linuxstb ("Client Exiting") |
20:08:14 | amiconn | preglow: cygwin dd does work, and it does work correctly given the partition table is correct. A partition type of 0 isn't valid, so you can't blame cygwin for not handling it |
20:09:08 | amiconn | Apple doesn't adhere to the standard |
20:10:31 | preglow | i just don't see why it can't support it |
20:10:33 | preglow | no bother |
20:10:44 | preglow | there is a partition entry |
20:11:22 | amiconn | You can always use the disk device instead of the partition |
20:11:31 | preglow | didn't work out |
20:11:37 | preglow | seems more like a windows limitation than anything else |
20:11:43 | preglow | ahh, yes, like that |
20:11:46 | preglow | i was about to do that |
20:11:59 | preglow | when i noticed i could only do one 'dd' before i had to reconnect the ipod |
20:12:04 | preglow | after that the device didn't work anymore |
20:12:09 | amiconn | raelly? |
20:12:11 | preglow | and that i was not about to endure |
20:12:13 | preglow | yes, really |
20:12:21 | amiconn | Strange... |
20:12:41 | _FireFly_ | what had you done ?? |
20:12:48 | amiconn | I was able to freely mix dd and normal accesses, as long as I didn't write with dd |
20:12:50 | preglow | and now itunes will be going |
20:12:55 | preglow | amiconn: this is ipod... |
20:13:06 | amiconn | This is of course something that the windows file system doesn't notice |
20:13:07 | preglow | apple has probably somehow installed a nice device driver |
20:13:32 | muesli_- | ew |
20:13:34 | muesli_- | re# |
20:13:36 | amiconn | Me likes that the Ondio is plain usb msd |
20:13:54 | preglow | well, the ipod is as well |
20:13:59 | preglow | but there's something strange going on |
20:14:02 | _FireFly_ | yeah it's easier to handle |
20:14:10 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
20:14:10 | * | preglow sees itunes go out the window while screaming "good riddance" |
20:14:14 | amiconn | You can check what driver windows uses for your ipod |
20:15:25 | amiconn | ...and also whether write caching is enabled or disabled |
20:16:30 | preglow | disabled |
20:16:33 | preglow | i had a check |
20:16:40 | preglow | windows always disables caching for usb devices |
20:16:43 | preglow | right there it beats linux |
20:17:42 | _FireFly_ | flash-devices with fat-fs will be very fast unuseable without write-cache |
20:18:43 | _FireFly_ | because the sectors, in which the fat resist will be fast going beyond there max write-cycles when writes aren't cached |
20:19:19 | _FireFly_ | so the mount option sync under linux is bad for flash-devices when fat-fs is used on these devices |
20:19:40 | _FireFly_ | only my 2 cents about it ;) |
20:20:12 | * | muesli_- opens his purse and grabs them ^^ |
20:20:40 | _FireFly_ | ;) |
20:20:59 | amiconn | preglow: Windows does not always disable caching for usb devices |
20:21:39 | amiconn | It does so when using the builtin msd driver, but for devices which aren't 100% compatible and therefore use own drivers, caching might be enabled |
20:21:53 | amiconn | I had this with my jukebox Studio |
20:24:20 | | Quit Febs ("CGI:IRC (EOF)") |
20:27:25 | | Join arkascha [0] (n=arkascha@xdsl-195-14-206-150.netcologne.de) |
20:28:21 | | Quit godzirra (Read error: 110 (Connection timed out)) |
20:28:34 | preglow | amiconn: happened for ipod at least, i had a look in dev manager |
20:31:09 | | Join hardeep [0] (i=hardeeps@norge.freeshell.ORG) |
20:33:23 | | Join justsomeperson [0] (n=92a9198c@labb.contactor.se) |
20:35:33 | preglow | w00t |
20:35:34 | | Quit justsomeperson (Client Quit) |
20:35:40 | preglow | i can use foobar to sync my ipod |
20:35:58 | dpassen1 | foo_pod? |
20:36:02 | preglow | yes |
20:36:18 | preglow | now lets get rockbox on it as soon as possible so i wont have to endure this itunes db catastrophy any further |
20:39:23 | amiconn | memcpy() is becoming a monster, but hopefully a really fast one :/ |
20:43:22 | preglow | hehe |
20:48:59 | Slasheri | Hmm, do you all think i should not implement flash interface to core? Then i will just use plugins that sounds a bad idea :) |
20:49:09 | Slasheri | +if |
20:52:15 | Slasheri | in theory we could use flash also to store dircache etc., but that might be not so useful to do |
20:52:32 | Slasheri | at least it has plenty of space to do so |
20:54:17 | Slasheri | at least it is possible to make iriver to boot without disk at all.. :D |
20:54:29 | Slasheri | preglow: what do you think about this? :) |
20:55:12 | | Join Remo_ [0] (n=Remo@degas.physik.unibas.ch) |
20:56:49 | *** | Saving seen data "./dancer.seen" |
21:00 |
21:01:26 | preglow | i'd like to use flash as much as we can |
21:01:35 | preglow | but it might not be a good idea for everyone, of course |
21:01:40 | | Join mongey [0] (n=53470b89@labb.contactor.se) |
21:01:48 | preglow | with a couple of safeguards, i don't think you can go much wrong |
21:02:12 | Slasheri | Hmm, then this sounds possible to me and i would like to do it.. But indeed, everybody wouldn't like it |
21:02:31 | Slasheri | yes, we would never touch the critical sectors |
21:02:50 | | Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
21:03:17 | Slasheri | Still those features would be enabled only after rockbox has been flashed over iriver firmware |
21:03:32 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
21:03:32 | | Quit mongey (Client Quit) |
21:04:07 | DrMoos | sure I will love it to :) |
21:04:09 | amiconn | Imho flash routines in the core are potentially dangerous. Imagine a function pointer gets overwritten and suddenly points to the flash function. Next time this function pointer gets called nasty things may happen |
21:04:24 | | Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) |
21:04:29 | Slasheri | amiconn: Ah, that is a good point |
21:04:41 | amiconn | There's an additional point why flash routines in core are suboptimal - you can't use them when running from rom |
21:05:03 | amiconn | In fact you can't flash at all when running from rom |
21:05:12 | amiconn | You will have to rolo first |
21:05:16 | Slasheri | amiconn: Oh, really? :/ |
21:05:51 | amiconn | Of course, if you switch the flash to programming mode the same time you're running from it ...... |
21:05:59 | Slasheri | yes, that's true.. |
21:06:32 | Slasheri | then we only have two options.. We can copy the code to ram on boot or not to use the flash while running |
21:06:52 | amiconn | The only way to avoid rolo would be if the flash procedure is in a plugin, but it means the whole procedure must be self-contained, |
21:07:18 | preglow | amiconn: i think that's kind of a moot point if the flash functions have builtin safeguards |
21:07:28 | amiconn | i.e. between switching the flash to programming mode and switching back at the end, *no* core function must be called |
21:07:32 | preglow | but of course, if you're really unlucky... |
21:08:00 | Slasheri | amiconn: or.. maybe we could put the flash functions to a different section so they are located on ram? |
21:08:36 | amiconn | On archos it isn't self-contained, because the flash plugins use only the plugin ram (that means you can flash during playback), but the plugin ram is too small to hold the whole flash image at once |
21:08:50 | amiconn | ...so the flash plugins load and flash in chunks |
21:11:24 | Slasheri | amiconn: I have an idea how to make the functions safe: We could initially store the flash interface command address code in a variable, that has for example 0x5555 - 0x2000; Then, before we do one safety check we would increment that address by 0x1000. And after final safety checks, it would be incremented to 0x5555 |
21:11:44 | Slasheri | That would prevent unwanted commands to flash if there would be some random jump to the code |
21:12:06 | amiconn | I still don't see the point of putting it in the core |
21:12:34 | amiconn | There are only 2 plugins that use them, maybe just one. |
21:12:44 | preglow | well |
21:12:45 | Slasheri | The only point would be to use it to store different more static content to flash, such as dircache for example |
21:12:47 | preglow | if you want to save settings |
21:14:30 | amiconn | dircache in flash is useless because of the same reason that renders a cache file useless |
21:15:41 | amiconn | The only use I can think of is storing settings, but that's something I wouldn't do |
21:16:37 | preglow | useless? |
21:16:44 | preglow | you'd free up some memory by keeping it there :) |
21:16:48 | preglow | it is fairly static, after all |
21:16:50 | amiconn | Hmm? |
21:17:02 | amiconn | You have to scan at boot or after usb |
21:17:17 | preglow | yes |
21:17:22 | preglow | you free ram by using flash |
21:17:28 | amiconn | Nah |
21:17:38 | preglow | the cache is fairly static, so could be kept in flash |
21:17:44 | amiconn | Now that would really wear the flash... |
21:17:58 | amiconn | ...and you would have to put the code in ram instead |
21:18:00 | | Join linuxstb [0] (n=5343d4aa@labb.contactor.se) |
21:18:22 | preglow | how would that wear the flash any more than the config sector? |
21:18:26 | preglow | being kept there, that is |
21:18:30 | preglow | it doesn't change much more often |
21:18:39 | amiconn | It does |
21:18:42 | preglow | put the code in ram instead? |
21:18:43 | preglow | why? |
21:18:47 | preglow | the cache isn't big |
21:19:09 | amiconn | You can't write to the flash when running code from it |
21:19:15 | amiconn | It would crash immediately |
21:19:33 | preglow | not at all? regardless of bank you're writing to? |
21:19:38 | | Join Philip_0729 [0] (n=Miranda@user-3645.lns1-c8.dsl.pol.co.uk) |
21:19:42 | preglow | no, of course not |
21:19:59 | amiconn | In addition, writing to the flash is slow |
21:20:05 | preglow | still not impossible! |
21:20:10 | preglow | but yeah, starting to get convoluted |
21:20:10 | amiconn | This isn't mass storage flash |
21:20:20 | _FireFly_ | if someone want to test my widget : http://home.arcor.de/s.wezel/wps-widget.zip |
21:21:06 | Slasheri | we can put the flash code to ram and keep other code in flash.. that would be simple :P |
21:22:17 | | Join actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) |
21:22:25 | Slasheri | amiconn: writing is slow? Doesn't seem that at least with my tests. Only erasing is slow |
21:23:13 | amiconn | It is slow. Slow as hell compared to ram, even the iriver sdram |
21:23:37 | Slasheri | yes, of course.. |
21:23:42 | amiconn | How much did you write? The full 2 MB? |
21:23:53 | Slasheri | but that doesn't matter with dircache or config sectors for example |
21:23:59 | Slasheri | Almost that, something like 1.8 MB |
21:24:01 | amiconn | it does |
21:24:06 | Slasheri | Hmm |
21:24:29 | amiconn | Even a single added or removed dir entry might change the whole dircache |
21:24:35 | amiconn | (iiuc) |
21:24:50 | Slasheri | only if the cache gets fully rebuild |
21:25:17 | amiconn | you need to sort somehow, right? |
21:25:25 | Slasheri | but we don't need to do the full rebuild from scratch always if we have free flash space |
21:25:30 | Slasheri | no.. |
21:25:59 | Slasheri | but of course, cache with _many_ deleted file entries could eventually get slower |
21:27:09 | amiconn | The handling would also get rather complex, since you can only flash block-wise |
21:27:32 | amiconn | You would need to buffer a block in ram, apply the changes, then flash back |
21:27:35 | Slasheri | amiconn: i can flash any byte i want, but i can only erase blocks |
21:27:40 | | Join ep0ch_ [0] (n=ep0ch@84.12.192.105) |
21:27:57 | ep0ch_ | please dont put the cache in flash |
21:28:00 | amiconn | Slasheri: Yeah, but without erasing you can't set a bit from 0 to 1 |
21:28:07 | Slasheri | the cache doesn't need erasing blocks.. they can be added to end of the cache |
21:28:14 | Slasheri | amiconn: yes and that wouldn't be necessary |
21:28:30 | ep0ch_ | what if the cache is too big to go into flash? |
21:28:34 | Slasheri | we will only set deleted file entries to 0 |
21:28:46 | amiconn | A full rebuild does need erase |
21:28:49 | Slasheri | ep0ch_: then it can go to disk.. but it must be huge for that |
21:28:58 | Slasheri | amiconn: not necessarely :) |
21:29:08 | Slasheri | with current implementation it does but it's not necessary |
21:29:23 | amiconn | I'd rather put the codecs in flash than the dircache |
21:29:32 | Moos | Slasheri: me I love the idea of put the cache in flash :) |
21:29:35 | preglow | yes, agree about that |
21:29:41 | Slasheri | true :) |
21:29:52 | ep0ch_ | does the flash have a lifespan? |
21:30:11 | Slasheri | ep0ch_: yes, 10k guaranteed cycles, and 100k typical (erases) |
21:30:29 | _FireFly_ | every flash has a lifespan |
21:31:05 | ep0ch_ | i dont like the idea of constants writes to flash, it should be a rare occurance imho |
21:31:15 | ep0ch_ | constant |
21:31:17 | Slasheri | but you would need to change the flash contents very much to make it last less than say 5 years |
21:31:49 | Moos | yes indded even this is theoric |
21:32:09 | _FireFly_ | or have a fat-fs in it and a driver which doesn't do write-cache ;) |
21:32:52 | _FireFly_ | but in this case it doesn't matter |
21:33:00 | _FireFly_ | because no fs is needed |
21:34:34 | | Quit Philip_0729 ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
21:34:57 | | Quit korpse (Remote closed the connection) |
21:37:31 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
21:37:50 | | Join Febs [0] (n=40be24f0@labb.contactor.se) |
21:39:27 | | Join Shanachie [0] (n=bart@d54C03D79.access.telenet.be) |
21:40:36 | preglow | new wavpack |
21:40:43 | | Quit Remo_ (Remote closed the connection) |
21:41:49 | preglow | doesn't look like it means any changes for us |
21:41:56 | preglow | linuxstb: how's shorten coming along, btw? |
21:42:11 | | Join ashridah [0] (i=ashridah@220-253-122-134.VIC.netspace.net.au) |
21:42:35 | | Quit korpse (Remote closed the connection) |
21:44:14 | linuxstb | preglow: I didn't finish working on it last night, and I probably won't have any time tonight to continue. |
21:45:02 | linuxstb | I think there are some endian problems. There is also no metadata parsing yet (in get_metadata) |
21:45:20 | linuxstb | I'll probably just post a comment to the patch and leave it for now. |
21:45:27 | * | amiconn is running out of registers :( |
21:46:02 | preglow | linuxstb: what, i thought it was submitted in working order |
21:46:14 | preglow | linuxstb: no metadata parser is no crisis, it works without |
21:46:27 | ep0ch_ | what are you working on amiconn? |
21:46:37 | amiconn | memcpy() |
21:46:48 | ep0ch_ | ooh for coldfire? |
21:46:53 | amiconn | yup |
21:47:43 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
21:51:04 | | Join yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at) |
21:51:17 | _FireFly_ | any comments/objections about my wps-widget ?? |
21:52:48 | | Quit korpse (Remote closed the connection) |
21:52:54 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
21:53:31 | | Join webguest35 [0] (n=55d2161a@labb.contactor.se) |
21:53:39 | | Quit webguest35 (Client Quit) |
21:53:47 | ep0ch_ | where? what? why? |
21:54:09 | _FireFly_ | http://home.arcor.de/s.wezel/wps-widget.zip |
21:54:14 | | Quit actionshrimp (Read error: 104 (Connection reset by peer)) |
21:54:21 | | Join actionshrimp [0] (i=dave@dhcp-163-1-214-173.seh.ox.ac.uk) |
21:54:37 | ep0ch_ | what's it do? |
21:54:58 | _FireFly_ | it's displays the wps ;) |
21:55:16 | ep0ch_ | :s |
21:55:17 | _FireFly_ | it handles multiscreen-support |
21:55:21 | ep0ch_ | ah |
21:55:38 | | Join thegeek_ [0] (n=thegeek@s175a.studby.ntnu.no) |
21:56:13 | ep0ch_ | well, i dont use my remote but i could try it out i guess |
21:56:48 | _FireFly_ | currently it has no support for loading a wps-file for the remote |
21:56:56 | muesli_- | amiconn http://www.misticriver.net/showthread.php?p=336055#post336055 do you know anything more? |
21:57:20 | ep0ch_ | so it tries to use the same wps as the main screen? |
21:57:31 | ep0ch_ | or hardcoded? |
21:57:33 | _FireFly_ | no it uses the default one ;= |
21:57:36 | ep0ch_ | k |
21:57:45 | _FireFly_ | yepp similar to the default one for the main |
21:57:54 | _FireFly_ | but without the peakmeter |
21:57:58 | | Quit korpse (Remote closed the connection) |
21:58:18 | _FireFly_ | the peakmeter doesn't work currently on the remote |
21:58:33 | ep0ch_ | oh speaking of which, did the flac test without wps ever finish or is it still running :D |
21:58:39 | Shanachie | Hello people, I'm interested in writing a feature for rockbox, any suggestions where to start? |
21:58:46 | Shanachie | is there a mailing list? |
21:58:59 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
21:59:23 | * | BirdFish wonders what conditions features have to meet to be included in rockbox? |
21:59:24 | ep0ch_ | Shanachie: there are two at www.rockbox.org |
21:59:30 | Febs | Shanachie: http://www.rockbox.org/mail/ |
22:00 |
22:00:16 | BirdFish | Is everything tested for stability? |
22:00:41 | | Quit Kohlrabi (Nick collision from services.) |
22:00:45 | | Join Kohlriba [0] (n=Kohlrabi@dslb-082-083-128-235.pools.arcor-ip.net) |
22:00:56 | | Join muesli- [0] (i=muesli_t@A9707.a.pppool.de) |
22:01:24 | muesli- | Shanachie just about curiousity...was is it? |
22:01:25 | muesli- | ;) |
22:01:36 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
22:01:50 | Shanachie | podcast support |
22:02:03 | muesli- | ah ok |
22:02:08 | Shanachie | subsribed to rockbox-devel |
22:02:25 | Shanachie | I've posted some expl. in the forum |
22:02:25 | ep0ch_ | ? aren't podcasts just audio files? |
22:02:53 | Shanachie | yes, but they need to be maneged to really enjoy them |
22:03:15 | _FireFly_ | a simple playlist should do it |
22:03:23 | linuxstb | So when a podcast is downloaded, what information do you get with it. i.e. you download an mp3 file and ???? |
22:03:56 | ep0ch_ | i think i'll live in ignorance on this one |
22:04:02 | | Quit korpse (Remote closed the connection) |
22:04:11 | muesli- | .za ? |
22:04:36 | Shanachie | linuxstb: maybe timecode info in the future |
22:04:46 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:04:56 | ep0ch_ | oh sounds like .cue files |
22:04:59 | Shanachie | thas what I'm pushing at the moment |
22:05:32 | Shanachie | ep0ch_:or bookmarks like they exist now in RB |
22:05:57 | linuxstb | So would a standard cuefile do the same thing? |
22:06:20 | linuxstb | Lots of people would like cuefile support in Rockbox (including me) |
22:06:26 | * | amiconn thinks 'oh no!' |
22:06:44 | linuxstb | :) And some poeple don't. |
22:06:50 | ep0ch_ | :) |
22:06:57 | Shanachie | does a cuefile have a description of the timecode? |
22:07:06 | linuxstb | Yes. |
22:07:19 | ep0ch_ | and tags |
22:07:48 | Shanachie | does it support a already played field? |
22:08:25 | Shanachie | but a cuesheets point to file, not times right? |
22:08:53 | Shanachie | http://en.wikipedia.org/wiki/Cue_sheet#Example.2FTutorial apperantly I'm wrong :) |
22:08:55 | ep0ch_ | http://en.wikipedia.org/wiki/Cue_sheet |
22:09:50 | | Quit korpse (Remote closed the connection) |
22:10:07 | _FireFly_ | is there any objections which speaks against that my wps-widget would get into cvs ?? |
22:10:36 | ep0ch_ | whys it not in the patch tracker? |
22:10:54 | _FireFly_ | because i have forgot it :) |
22:11:00 | _FireFly_ | to put it in |
22:11:07 | _FireFly_ | will do it now |
22:11:07 | | Quit thegeek (Read error: 110 (Connection timed out)) |
22:11:10 | _FireFly_ | will do it now |
22:11:16 | ep0ch_ | :) |
22:11:33 | Shanachie | Cuesheets seem to be focust towords music, and kind off overkill |
22:11:59 | Shanachie | I think I'll try a lighter kind of file format |
22:12:14 | linuxstb | But the principle is the same - splitting a long file into tracks and making next/prev buttons in Rockbox go the next/prev tracks inside the current file. |
22:12:39 | Shanachie | linuxstb: indeed |
22:12:43 | linuxstb | The work is not in parsing the cuefile, it's in changing Rockbox to support the concept of tracks within a file. |
22:12:44 | ep0ch_ | yes and you will make lots of friends if you support cuesheets :D |
22:13:03 | Shanachie | aren't you guys coders? |
22:13:31 | Shanachie | I'll look in to the code and see what I can do |
22:15:01 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:15:26 | | Nick ep0ch_ is now known as ep0ch (n=ep0ch@84.12.192.105) |
22:15:34 | _FireFly_ | ok submitted |
22:15:39 | | Nick ep0ch is now known as ep0ch| (n=ep0ch@84.12.192.105) |
22:18:44 | | Join andy [0] (i=golbeck@h72n2fls304o1033.telia.com) |
22:18:45 | | Join Zagor [0] (i=foobar@pdpc/supporter/sustaining/Zagor) |
22:18:56 | Zagor | preglow: here? |
22:18:59 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
22:19:14 | preglow | Zagor: yup |
22:20:00 | Zagor | these guys have ported doom to pretty much every ipod: http://idoom.hyarion.com |
22:20:05 | | Quit korpse (Remote closed the connection) |
22:20:07 | andy | hm.. seams like talk_buffer_steal() doesnt work on iriver since mp3_play_stop() is a dummy? |
22:20:09 | Zagor | ought to be some good info in their source |
22:20:31 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:20:54 | Zagor | it's based on ipodlinux, but appears to support more hardware than ipl |
22:21:07 | andy | trying to include iriver recording in normal recording screen |
22:21:22 | linuxstb | Zagor: Do they use a graphics library like libsdl or opengl? |
22:21:34 | preglow | i'll have a look |
22:21:40 | Zagor | i don't know, i just found the site a minute ago |
22:21:49 | andy | actually got it working now, need to clean up some loose ends before commit :) |
22:22:21 | preglow | andy: i think slasheri's done some work there as well |
22:22:31 | * | preglow produlates slasheri |
22:22:55 | andy | argh |
22:23:17 | preglow | Zagor: man, i was planning to not install ipodlinux, but then i saw this... |
22:23:43 | amiconn | afaik talk_buffer_steal() doesn't need to do anything on iriver, because the talk buffer isn't shared |
22:23:49 | muesli- | this kicks ass |
22:25:21 | andy | amiconn: oki, I thought talk_buffer_steal was a generic to call before stealing the mp3 buffer :) |
22:25:33 | | Join len0x [0] (n=len0x@193.113.235.183) |
22:25:35 | | Quit korpse (Remote closed the connection) |
22:25:39 | ep0ch| | do they have the music working in doom? |
22:25:46 | preglow | ep0ch|: doubt it... |
22:25:55 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:26:03 | muesli- | the video doesnt thogh |
22:26:07 | muesli- | u |
22:30:43 | linuxstb | Anyone know the license - the source files say "DOOM Source Code License as published by id Software" |
22:30:58 | | Quit korpse (Remote closed the connection) |
22:33:28 | Zagor | linuxstb: the source could be ok, but the data isn't |
22:33:54 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:34:17 | crwl | DOOM is licensed as GPL |
22:34:23 | crwl | the data isn't |
22:34:48 | linuxstb | But that's not a problem. Like every doom port, the WADs are never included. |
22:34:58 | crwl | yeah |
22:35:07 | linuxstb | crwl: How do you know it's GPL? |
22:35:16 | linuxstb | The source files in iDoom don't say GPL. |
22:35:22 | crwl | what's iDoom anyway? |
22:36:02 | crwl | it was first released with some odd licence, but later rereleased as GPL |
22:36:06 | crwl | not too much later, in fact |
22:36:28 | linuxstb | iDoom is the iPod port of Doom. I'm looking at that version of the source. We should obviously go back to the original then. |
22:37:02 | crwl | i doubt that prboom for example would be included in Debian if it wasn't GPL or similar |
22:37:31 | crwl | yes, prboom definitely says it's GPL |
22:37:37 | Zagor | wikipedia does too |
22:37:46 | preglow | someone please tell me what is wrong with this bootloader |
22:37:48 | preglow | this is pissing me off |
22:38:59 | | Quit korpse (Remote closed the connection) |
22:39:12 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:39:16 | Zagor | linuxstb: since we can't ship the wads (graphics) anyway, I'd say a doom port is not as fun as it sounds |
22:39:50 | Zagor | my purpose in pointing out the project was rather that there may be useful information to be gleaned from the source |
22:39:50 | linuxstb | I'm not that interested anyway. Just curious if it was do-able. |
22:40:12 | crwl | you can always link to the shareware .wad or something... |
22:40:34 | linuxstb | Zagor. OK. But I don't think there is - it just seems to use the kernel drivers to access the hardware. |
22:40:44 | ashridah | crwl: the shareware version isn't completely free either, fwiw |
22:41:20 | Zagor | linuxstb: ok, i misunderstood then |
22:41:29 | crwl | ashridah, well yes, you maybe can't distribute it yourself... |
22:41:36 | ashridah | crwl: or modify it |
22:41:49 | crwl | well, why would you need to do that? |
22:41:53 | linuxstb | There is an lcd driver in it, but that's well documented in all the other parts of IPL. |
22:42:07 | linuxstb | I've just looked at it, and it doesn't seem to be anything different. |
22:42:50 | ashridah | crwl: nevermind, misinterpreted your use of 'link'. |
22:42:57 | crwl | and then there's http://freedoom.sourceforge.net/ |
22:43:11 | crwl | but that's not complete |
22:44:16 | | Quit korpse (Remote closed the connection) |
22:44:33 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
22:45:56 | andy | preglow, linuxstb: cool work with the ipod btw! |
22:47:37 | | Join ehntoo [0] (n=ehntoo@24-177-146-220.dhcp.mrqt.mi.charter.com) |
22:49:37 | | Quit korpse (Remote closed the connection) |
22:50:30 | preglow | andy: i haven't done much yet :/ |
22:50:39 | preglow | so, does anyone have a wad for this doom? :> |
22:52:01 | Shanachie | goodnight people |
22:52:13 | | Quit Shanachie (Remote closed the connection) |
22:52:21 | linuxstb | preglow: http://debian.vinita.lt/debian/pool/non-free/d/doom-wad-shareware/ (maybe!) |
22:53:05 | RotAtoR | I've got the full version wad ;) ~10mb |
22:53:30 | | Part ep0ch| |
22:54:45 | * | preglow repartitions his ipod |
22:56:50 | *** | Saving seen data "./dancer.seen" |
22:57:21 | crwl | hum, did they really release firefox 1.5 today |
22:58:19 | Zagor | no |
22:58:37 | _FireFly_ | a rc1 |
22:58:40 | ashridah | haven't seen any official mention of it, and my local mirror stilll only has 1.5rc's and betaws |
22:58:42 | crwl | why did my firefox claim it has downloaded an important update and asked to get restarted |
22:58:46 | amiconn | omfg I don't believe it :) |
22:58:51 | crwl | and now it says it's firefox 1.5 |
22:58:58 | RotAtoR | it's 1.5rc2, i think |
22:59:01 | crwl | i was running 1.5 rc1 before |
22:59:04 | amiconn | The memcpy() monster does indeed work, and it is faast |
22:59:08 | crwl | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 |
22:59:23 | ashridah | crash_: rc2 came out yesterday |
22:59:40 | ashridah | they're probably intending to just be able to rename it if there aren't any showstoppers |
22:59:52 | crwl | i haven't earlier seen any autoupdate thing like this under linux, must be new in 1.5 series |
23:00 |
23:00:07 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
23:00:31 | * | ashridah would prefer it if that was left to his distro |
23:00:34 | RotAtoR | crwl: yep, they finally added binary patching |
23:00:57 | crwl | ashridah, well, i'm running a self-downloaded version anyway... i installed it to my home directory |
23:01:03 | Zagor | ashridah: your distro probably patches out that, or at least makes it optional if it isn't already |
23:01:10 | crwl | RotAtoR, ok, i think that's mostly cool |
23:01:12 | | Join Strath [0] (n=mike@dpc674681214.direcpc.com) |
23:01:19 | preglow | linuxstb: do you know if the boot partition always has to be the size it ships with? |
23:02:13 | ashridah | Zagor: i daresay that would be about right. |
23:02:23 | ashridah | suits me, since i don't really want firefox getting superuser privs :) |
23:05:04 | ashridah | strange. 1.5rc2 only seems to be available as an update |
23:05:11 | | Quit korpse (Remote closed the connection) |
23:05:40 | RotAtoR | or here: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5rc2/ |
23:06:53 | ashridah | weird. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5rc2/ just had 'update' in it |
23:07:30 | RotAtoR | strange, they must still be in the process of rolling it out |
23:07:52 | ashridah | yeah, don't know if ftp.mozilla.org roundrobins or something |
23:07:58 | crwl | i wonder where my firefox got this update then :P |
23:08:07 | | Quit _FireFly_ ("Leaving") |
23:08:22 | ashridah | crwl: the update is available |
23:08:34 | ashridah | just no standalone installer on the first mirror i tried |
23:08:50 | crwl | yep |
23:09:28 | ashridah | rofl. ftp.mozilla.org has 8 ip addresses :) |
23:11:46 | linuxstb | preglow: No. IPL works by reducing the boot partition and inserting an ext3 partition in the empty space before the FAT32 partition. |
23:12:09 | linuxstb | In your case, I think you reduce /dev/sdb1 to one cylinder. |
23:13:03 | preglow | linuxstb: so the ext2 part HAS to be before tha fat32 one? |
23:13:06 | linuxstb | So /dev/sdb1 will be the boot partition, /dev/sdb2 is FAT32, and /dev/sdb3 is ext3 - but the ext3 partition is physically before the FAT32 partition. |
23:13:41 | linuxstb | I don't know if it HAS to be that way, but that's how all the IPL howtos tell you to do it. |
23:13:45 | preglow | can i just use your bootloader for loading ipl, btw? |
23:13:57 | linuxstb | Yes. |
23:14:32 | preglow | rockbox code is not bothered by multiple partitions? it'll just find the first fat32 one? |
23:14:41 | linuxstb | Yes. |
23:14:44 | preglow | how nice |
23:14:49 | linuxstb | Yes. |
23:16:33 | | Join webguest22 [0] (n=c76218bc@labb.contactor.se) |
23:16:41 | linuxstb | preglow: Have you found a kernel and a filesystem to install on your ext2 partition? |
23:16:44 | | Quit webguest22 (Client Quit) |
23:17:54 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
23:18:28 | preglow | linuxstb: just got done repartitioning it |
23:18:47 | linuxstb | preglow: http://www.davechapman.f2s.com/rockbox/ipod_fs_170905.tar.gz |
23:18:57 | linuxstb | untar that to your ext2 partition (after formatting it) |
23:19:23 | linuxstb | http://ipodlinux.org/builds is the place to get the kernel and the podzilla binary. |
23:19:34 | linuxstb | Put the kernel on your FAT32 partition as linux.bin |
23:19:48 | linuxstb | Copy podzilla into your ext2 /bin directory. |
23:20:04 | preglow | hahaha |
23:20:12 | preglow | fdisk and cfdisk segfaults when i try to start them now |
23:20:25 | linuxstb | Final job is to edit the /etc/rc file in your ext2 partition to make sure podzilla is started. |
23:21:20 | preglow | seems i need to restart to make sure the partitioning went ok |
23:21:37 | linuxstb | You should just need to unplug and reinsert your USB cable. |
23:22:26 | preglow | tried |
23:22:56 | preglow | think it worked anyway |
23:22:58 | preglow | so i'll try |
23:26:00 | andy | hm.. on the 5249, if a dma transfer is aborted by setting DCR to 0, is the interrupt generated? |
23:29:34 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
23:30:05 | preglow | linuxstb: hot diggety |
23:30:06 | preglow | it works |
23:30:24 | preglow | i appreciate the way podzilla never friggin turns on the backlight |
23:30:57 | Bagder | what's podzilla like otherwise? |
23:31:21 | linuxstb | It's a clone of the Apple firmware - but with more options and a file browser. |
23:31:25 | preglow | a bit hard to say |
23:31:30 | preglow | since i can't see it, and all |
23:31:59 | linuxstb | It's still buggy on my ipod - the LCD driver isn't working properly, so lots of menu options don't appear at all. |
23:32:29 | linuxstb | So I haven't really used it properly either. |
23:34:17 | linuxstb | preglow: Are you going to try iDoom? |
23:34:37 | | Quit korpse (Remote closed the connection) |
23:34:43 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
23:35:20 | preglow | going at it now |
23:36:51 | preglow | copying idoom over to the ipod just seems to take... forever... |
23:37:46 | preglow | ok, something funky is going on |
23:38:01 | preglow | a four meg wad file does not take an hour to copy |
23:39:48 | | Quit korpse (Remote closed the connection) |
23:40:32 | | Quit webguest64 ("CGI:IRC (Ping timeout)") |
23:41:08 | preglow | ok |
23:41:10 | preglow | i'm playing it |
23:41:12 | preglow | with no backlight |
23:42:47 | preglow | haha |
23:42:54 | preglow | give me a backlight, and this will be pretty cool |
23:43:08 | preglow | i found backlight! |
23:43:47 | crwl | does it play realtime speed? |
23:43:50 | crwl | i suppose it does... |
23:43:50 | solexx_ | you're might be wrong, you could've sworn you saq a light coming on... |
23:44:21 | crwl | doom worked very well with my 386/20, at least with screen size of 176x132 or similar :) |
23:44:44 | | Join netmcp___ [0] (i=user@c-67-165-211-238.hsd1.co.comcast.net) |
23:44:48 | andy | crwl: probably 320x200 (mode 13) =) |
23:44:59 | crwl | andy, yes, but the screen size was changeable |
23:45:04 | crwl | it wasn't smooth at all in full screen |
23:45:08 | preglow | plays realtime, yes |
23:45:17 | crwl | yes, it probably should too :) |
23:45:20 | preglow | it's somewhat difficult to play on this screen |
23:45:20 | preglow | heh |
23:45:21 | | Quit Febs ("CGI:IRC (EOF)") |
23:46:14 | netmcp___ | sorry to disturb anyone, but I'm having some trouble with a gmini 220 of mine, and I'm wondering if anyone might be able to help troubleshoot it before I decide to send it in |
23:46:32 | linuxstb | preglow: I've just installed it as well. Much fun. |
23:47:25 | amiconn | coldfire memcpy() is now >1300 bytes - oops! |
23:47:50 | preglow | amiconn: damn |
23:47:59 | preglow | amiconn: planning to put it in iram? |
23:48:12 | amiconn | memcpy() has always been in iram |
23:48:38 | Moos | do you know how much faster? |
23:48:59 | preglow | i need to get some kind of protective case for this thing |
23:49:05 | preglow | nothing scratches as easily as an ipod |
23:49:41 | netmcp___ | brasso makes it all better ^_^ |
23:50:51 | Jungti1234 | Who is a person who develop unicode rockbox? |
23:51:05 | preglow | markun and phaedrusxxx |
23:51:10 | amiconn | preglow: Speed is 240%..950% of the C implementation |
23:51:18 | amiconn | (for large blocks) |
23:51:28 | markun | Jungti1234: you know that, why do you ask? |
23:51:47 | amiconn | It always uses burst reading and writing, that means there are 16 different loops |
23:51:52 | Jungti1234 | Will not I receive file? |
23:52:34 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
23:53:13 | amiconn | It even isn't complete - a slight optimisation and a iram-destination check are still missing |
23:53:58 | amiconn | When the destination is iram, it is probably faster to just copy than to ensure burst writing with excessive copying/shifting |
23:54:10 | | Part netmcp___ |
23:54:36 | preglow | yes, i'd think so |
23:55:02 | amiconn | I am very unsure whether this approach is feasible. With the second direction for memmove(), the size will double again :-( |
23:55:37 | | Quit Zagor ("Client exiting") |
23:55:53 | Jungti1234 | Let's keep early hours. :) |
23:56:19 | preglow | linuxstb: how do i access the fat32 part? |
23:56:43 | preglow | right |
23:57:29 | amiconn | Hmmm :/ |
23:57:39 | | Quit korpse (Remote closed the connection) |
23:58:00 | linuxstb | preglow: Have you found it? |
23:58:04 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
23:58:18 | Jungti1234 | bye |
23:58:28 | | Quit Jungti1234 ("Bye Bye~ http://cafe.naver.com/iriverh300") |