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

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

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

#rockbox log for 2005-11-10

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:58preglowlinuxstb: i assume we'll stuff all ipod lcd drivers into one file, or?
00:07:10preglowso i don't need to call it lcd-ipod-colornano.c or whatever
00:08:09linuxstbI 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:09linuxstbEven if we support every single ipod lcd, I think that file will still be quite small.
00:09:27preglowyeah, should be
00:09:37preglowat least, lets just pretend that's the plan for now
00:09:50preglowwe can branch and rename as much as we like when subversion is in place anyway!
00:09:56*preglow tickles Bagder
00:10:04linuxstbhehe. 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:00amiconnlinuxstb: 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:25linuxstbamiconn: True. I'm glad I decided to buy a colour model.
00:13:36XavierGrwhy if pu a button sniffing loop in my thread the system becomes unresponsive?
00:13:49XavierGr^^ if I put
00:13:52amiconnHow do you do the sniffing?
00:14:11XavierGrbutton = rb->button_get(true);
00:14:20amiconnI hope you don't use button_get() ...
00:14:21XavierGrthen switch and all in a while
00:14:24Bagderhaha
00:14:31XavierGroops
00:14:35preglowi love all the colours
00:14:36amiconnbutton_get() will eat the button events
00:14:50preglowlinuxstb: do i need to use itunes to get photos on this little bastard as well?
00:14:53XavierGrany alternative?
00:14:59preglowman, 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:59amiconn(in the core)
00:16:07preglowno!!!
00:16:08XavierGrhaha, preglow suffer, for you blasphemous choice, you shall be tortured by idiot proof programs and i-tunes alike for your punishment...
00:16:08preglow:-)
00:16:26preglowamiconn: how much does it speed it up?
00:16:31XavierGr:D
00:16:55amiconnIt's not easily possible to tell
00:16:58preglowXavierGr: idiot proof? i had to use five bloody minutes to figure out how to sync my ipod to my collection
00:17:19preglowmost unintuitive piece of coding i ever saw
00:17:23preglowmay it suffer in hell
00:17:41preglowand steve jobs be found crying in purgatory
00:17:41amiconnlcd_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:42XavierGramiconn: 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:55XavierGrpreglow: indeed...
00:18:05amiconnand it will use the stack of whatever thread will be active at that moment
00:18:23amiconnThe stack might be in iram or not
00:18:42preglowouch
00:18:42 Join ashridah [0] (i=ashridah@220-253-122-35.VIC.netspace.net.au)
00:18:45preglowi'd say use the iram
00:19:01preglowif only because i plan on riding the stack limits pretty damn close in the codecs ;)
00:19:06amiconnI simply reserve the 2 line-block buffers statically now, with IBSS_ATTR
00:19:20amiconnYeah, 320 bytes
00:20:01preglowi also happen to think the grayscale lib is a bit too sluggish at 45mhz
00:20:08linuxstbreglow: I have no idea about photos - never tried them.
00:20:52preglowman, does my h120 feel like a clunky brick after using the nano
00:22:13XavierGryes but only 2 gigs
00:23:47preglowmore than enough
00:24:16XavierGrI disagree on tha
00:24:27XavierGrexcept if you have it for specific use
00:24:59preglowi just want a lighter player for when i don't wnat to carry the clunky brick
00:25:02preglowlike short walks, etc
00:25:10amiconnpreglow: Put some flacs on it ;)
00:25:16preglowhaha
00:25:26XavierGrsome wise man once said:
00:25:32preglowall my test files will probably use 1/4 of the space
00:25:51XavierGriHP series is like Vovlo cars
00:26:07preglowihp is swedish!?
00:26:16XavierGrbig like a brick and it will survive a hit with a metorite....
00:26:20preglowhahah
00:26:22preglowtell that to amiconn
00:26:38preglowi 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:44preglowits!
00:26:56XavierGrwell he is the exception that validates the rule
00:27:18amiconnThe H1x0's hd shock protection leaves quite something to be desired
00:27:44amiconnpreglow: My test files wouldn't fit completely on your nano
00:27:50XavierGrwell 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:14amiconnThe case itself is. The hd shock protection is not
00:28:23XavierGrand don't forget amiconn that you are the exception on that. Many users have reported drops without a failure, (major drops)
00:28:50XavierGrI still think that you stood unlucky
00:28:54amiconn...and the fact that the case is quite slippy doesn't exactly keep it from dropping
00:30:09XavierGrslippy case? I think that you exaggerate a little...
00:30:16preglowamiconn: at least we wont have to do tests to ascertain the feasability of a sleep mode for the ipods
00:30:27preglowamiconn: since the damn buggers never turn themselves off by default
00:30:29amiconnzzzzzzzzzzzzzzzzzzzzzzzzzz......................
00:30:31XavierGrand if you use the case that comes with it there will be no problems
00:30:54amiconnYeah, but the leather case doesn't give access to the reset button
00:31:21XavierGrthat's true, that's why I modded mine first and then bought an outro case
00:31:26amiconn...and with the flap closed, operation the joystick is difficult
00:31:35XavierGrwhich leaves all ports accesable, plus protects the screen.
00:31:44BirdFishregarding firmware and the hex code that associates, is there ever any pattern to look for?
00:31:53BirdFishregarding images
00:31:56preglownope
00:32:15BirdFishknow of any good disassemblers for the iaudio x5
00:32:16BirdFish?
00:32:26BagderBirdFish: objdump
00:32:45Bagderits plain unscrambled coldfire code afair
00:32:53BirdFishBadger: thank you :)
00:35:52linuxstbThe shorten codec takes the prize for smallest codec (apart from WAV). shorten.codec is 18472 bytes.
00:36:02preglowlinuxstb: what should the naming scheme be? lcd_xxx -> lcd_ipod_xxx?
00:36:04Bagder:-)
00:36:20preglowforget it
00:36:44preglowwill there be any code in lcd-16bit.c at all? just helpers?
00:36:57linuxstbIt's all the code that draws into the framebuffer.
00:37:04preglow'course
00:37:20BirdFishBadger: has objdump been ported to windows?
00:37:34linuxstbI think it's just lcd_init() and lcd_update_rect() that need to be moved (plus their dependencies)
00:37:36preglowobjdump has been ported to just about everything
00:39:26BagderBirdFish: objdump is part of GNU binutils
00:40:15BagderBirdFish: 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:50XavierGrwhat?
00:40:51preglowwoot
00:40:53XavierGrwps
00:41:00XavierGryay
00:41:08XavierGrwithout bugs?
00:41:25XavierGrmajor 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:57XavierGrHurry and find TiMiD.
00:43:15XavierGror do you have cvs access?
00:43:32_FireFly_no
00:44:04XavierGrthen 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:23XavierGrah then tomorrow
00:45:34XavierGrwhat is left for the remote so far?
00:45:53XavierGrradio ,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:40amiconnImho plugins should handle the remote in whatever way they see fit
00:48:04amiconnThe core should just clear the remote lcd before calling the plugin, like it does with the main lcd
00:48:19amiconn_FireFly_: and recording screen
00:48:22XavierGr_FireFly_: you use a different wps for the remote?
00:48:30amiconn(not yet used on iriver, but it will be)
00:48:32XavierGror 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:25preglowlinuxstb: 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:34amiconnnope
00:49:41preglowcan't imagine why they'd want to compile lcd-ipod.c ...
00:49:54amiconnThe simulator uses the lcd framebuffer the same way as the target
00:50:00preglowwell, sure
00:50:07preglowbut they don't need to compile lcd-ipod.c to use it
00:50:07amiconnThe simulator code picks up the image from there
00:50:12preglowyes, yes
00:50:17preglowbut it doesn't use the ipod driver
00:50:26preglowso it makes no sense for there to be ifdef SIMULATOR in there
00:50:31amiconnIf 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:47preglowamiconn: it isn't, i'm working on removing the ipod specific parts from lcd-16bit.c
00:50:58amiconnYes I know
00:51:22_FireFly_ok time for bed good night everybody
00:51:28preglowas i see it, sims will compile lcd-16bit.c but not lcd-ipod.c
00:52:04 Quit _FireFly_ ("Leaving")
00:52:53preglowi'll just go ahead and fix the eight level indents the ipod people use as well
00:54:25preglowamiconn: but agreed, yes? SIMULATOR checks might be needed in lcd-16bit.c, but not lcd-ipod.c, lcd-h300.c, etc
00:54:35amiconnyes
00:54:38preglowgoodie
00:54:43preglowi need to start using the sims
00:55:19amiconnHmm, iiuc there were some problems with the sims on amd64?
00:55:29preglowyes
00:55:30preglowafaik
00:55:39preglowlong since i tried
00:56:08preglowbtw, does inverse display exist on colour lcd controllers?
00:56:22***Saving seen data "./dancer.seen"
00:58:03amiconnI wouldn't expect it
00:58:26preglowamiconn: 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:01preglowif we do this properly, then an lcd-sim.c could easily be added as well just for sims
00:59:28amiconnThey aren't dummies, and they are defined in the simulator code
00:59:42XavierGramiconn I don't see a function in the plugin API that it will enable us to sniff disk activity.
00:59:52amiconnuisimulator/x11/lcd-x11.c and uisimulator/win32/lcd-win32.c
00:59:57XavierGronly way is to add a function to the api, is that acceptable?
01:00
01:00:59preglowseems there are some stubs for the simulator in the various lcd drivers too, though
01:01:07preglowlike lcd_init
01:01:25amiconnYes, the init is of course target only
01:02:40 Quit Kohlrabi (Read error: 104 (Connection reset by peer))
01:02:52preglowso i somehow need to expose an lcd_init to the sim, even though that too belongs in lcd-ipod.c?
01:03:07amiconnFrom looking at lcd-h100.c, I can see no problems with the split
01:03:28preglowprobably just me being confused and tired
01:03:31amiconnI doubt lcd_init is ever called for the sims
01:03:58amiconnAh no, it must be
01:04:10amiconnOnly thing it does is creating the scroll thread
01:04:10preglowthen how should i deal with that?
01:04:18preglowahh
01:04:29preglowso we can just keep a default one somewhere?
01:04:37preglowwith an ifdef around it
01:05:06amiconnuisimulator/common/lcd-common.c should be a nice place for the simulator lcd_init
01:05:32preglowyep
01:05:33preglowgood
01:05:48amiconn(the first function that actually does something in there)
01:07:16preglowbtw, am i the only person in the world prefering to indent #ifs and #ifdefs with the code around it? :>
01:07:34amiconnSeems so ;)
01:07:46XavierGre.g?
01:07:52linuxstbpreglow: Yes :)
01:08:36 Quit ashridah ("Leaving")
01:11:31preglowhmm
01:13:12preglowscroll thread data can't be static anymore, at least
01:13:24preglowsince we instantiate the thread from another file than where it recides
01:13:45amiconnI don't think so
01:13:57preglowperhaps it's better to just let each driver contain the thread data
01:14:02amiconnYou wouldn't call the scroll_thread function from elsewhere
01:14:22preglowwell, from lcd-ipod.c i would
01:14:35amiconnYou just call create_thread from elsewhere, with the function as an argument
01:15:22preglowyes, but i also need the stack and the name string
01:15:24amiconnThe only variables that can't stay static are scroll_stack and scroll_name
01:15:30 Quit Moos ("Glory to Rockbox")
01:15:31preglowyes
01:15:33amiconn...and the scroll_thread function itself
01:15:42preglownono, the rest i'll keep static
01:19:02 Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au)
01:21:36preglowis there a generic ipod platform define?
01:22:14preglowhmm, nope
01:22:23preglowi need one for firmware/SOURCES
01:23:10linuxstbI'm not sure you should use one. Just do CONFIG_LCD==LCD_IPODNANO || CONFIG_LCD==LCD_IPODCOLOR
01:23:18linuxstb(for now).
01:23:44preglowwill do
01:25:39linuxstbShorten is a very basic codec. For example, each channel is always encoded independently.
01:26:38preglowyes, it's pretty old
01:27:00linuxstbThere 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:22linuxstbForget that....
01:27:26preglowoh?
01:27:59preglowbtw, wont we need to split lcd.h into several files now?
01:28:37amiconnhuh?
01:28:37preglowthis is going to end up with me having to split all the lcd files ...
01:28:58preglowamiconn: i'll need to include lcd.h from lcd-ipod.c, since it depends on some lcd-16bit.c functions
01:29:15preglowamiconn: but what happens when lcd-ipod.c sees a lot of its own functions declared extern all of a sudden?
01:29:27amiconnnothing
01:29:30preglowi keep forgetting that extern i default...
01:29:30preglowbah
01:29:33preglowis
01:29:39linuxstbWhat does lcd-ipod.c depend on from lcd-16bit.c?
01:30:00linuxstbI thought it would only be the other way around.
01:30:11preglowlcd_clear_display
01:30:36preglowbut perhaps that's meant to be device dependent as well?
01:31:19linuxstbMaybe you should keep lcd_init() in lcd-16-bit.c and have a low-level init function in lcd-ipod.c
01:31:19amiconnnope
01:31:56linuxstbe.g. lcd_init_device()
01:31:59preglownope to what?
01:32:17amiconnlcd_clear_display() isn't hardware dependent
01:32:32amiconnIt just clears the framebuffer
01:33:07preglowthen the dependency shall be allowed to live?
01:33:36linuxstbpreglow: Just keep lcd_init() where it is.
01:34:13preglowin lcd-ipod.c?
01:34:24amiconnlinuxstb: lcd-h100-remote does that separation (hw init and high-level init)
01:34:26preglowthat's where it is here :)
01:34:41amiconnIt has to, since the hw init has to be called everytime the remote is plugged
01:34:48linuxstbNo - in lcd-16bit.c :) Just move the low-level parts of it to lcd-ipod.c
01:35:16preglowand do a lcd_init_device() as well?
01:35:21 Join Jungti1234 [0] (n=jungti12@211.248.102.131)
01:35:46linuxstbpreglow: Yes.
01:35:47amiconn...which then should be an empty macro for the sim
01:36:10preglowi'll pretty much have to split all the other lcd drivers as well now
01:36:14amiconnCould be #defined in lcd.h ...
01:36:49preglowright, i keep forgetting lcd-16bit.c isn't used anywhere vital yet
01:36:53linuxstbWhy do you need to split anything else immediately?
01:37:01preglownevermind me
01:37:39XavierGrquick 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:22XavierGroops
01:38:34XavierGrI have to add the function to plugin.h too
01:39:22preglowbtw, 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:49amiconnThat won't work
01:39:50preglowor shall we still keep the remote as a special case?
01:39:59amiconnThe function names would be identical
01:40:04preglowi know, that's why i'm wondering
01:40:13preglowthe 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:58amiconnEither that, or use a more general concept, similar to the gui_* stuff
01:41:16preglowoh well
01:41:34preglowi vote for keeping the remote as a special case for now
01:42:00amiconnYes, not everything at once
01:44:48XavierGrdo i have to compile again the whole firmware when the api_plugin_version changes?
01:44:53preglowok, lcd_init is now just a call to lcd_clear_display and lcd_init_device
01:45:16amiconnHmm, no create_thread() ?
01:45:17preglowoh, plus scroll thread
01:45:18XavierGre.g I moved the compiled rock file to an old firmware and the error uncompatible version poped up.
01:45:20preglowi forgot that
01:45:37amiconnXavierGr: Of course
01:45:48amiconnThat's why you bump the api version
01:45:55linuxstbSo that should work for the sim if you add lcd_init_device to the x11 and win32 lcd drivers.
01:46:07amiconnThe new plugin would need a function in the api that the old core doesn't provide
01:46:18XavierGrthought so...
01:46:23amiconnIf this wouldn't be checked, rockbox would crash
01:46:24XavierGryeah it is obvious
01:46:53amiconnlinuxstb: Not necessary, see above
01:47:08amiconnlcd.h should just define it as an empty macro for the sims
01:47:53preglowwill do
01:48:26linuxstbBut couldn't it be used to actually do something useful in the sims? e.g. create the window.
01:48:59preglowyou'd need to pass info from and to that function then
01:49:08preglowcould of course keep it static
01:49:16linuxstbYes, forget that. A simulator window is also used for input...
01:49:24linuxstbSo they are not the same.
01:49:38preglowit would be doable, it would just be something of a hack
01:49:38preglowheh
01:51:02preglowso, let's try it out then
01:51:06amiconnhmpf.
01:51:07preglowbAM, linker error
01:51:24linuxstbTry a make clean
01:51:37preglowlinuxstb: man, ipod compiles looks like flowers at the moment
01:51:42preglowlinuxstb: did a reconfigure
01:51:47linuxstbflowers?
01:51:56preglowwith all the warnings and stuff
01:52:07preglowreally pretty, heh
01:52:29preglowi, riight, a lack a ton of includes
01:53:33preglowtoo tired to even write coherently, i see
01:54:52preglowok, things seem to work well
01:54:58linuxstbjust 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:52amiconnDoble the amount for when memmove() gets added
01:57:38preglowhow much iram does it have?
01:57:39 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
01:57:52amiconn4KB
01:58:26amiconnIt will fit, even with memmove() and for debug builds
01:59:01amiconnThe cvs version is the faster one
01:59:16amiconn(yet without memmove)
02:00
02:01:39XavierGranother one: bool ata_disk_is_active (void) returns a bool and says to us if the disk is spining right?
02:01:55XavierGror it returns if the spin is not powered off?
02:01:59 Join thegeek_ [0] (n=thegeek@s115b.studby.ntnu.no)
02:02:03XavierGrs/spin == disk
02:04:07preglowbut aight
02:04:11preglowi'll commit this now then
02:09:31preglowlinuxstb: going to commit shorten today?
02:12:48linuxstbpreglow: Hopefully. I'm looking at it now.
02:14:10preglowi wonder how much ram the nano has
02:14:32amiconnThe scroll thread can stay static
02:14:44linuxstbpreglow: I'm sure it's 32MB - same as all the ipods
02:14:45preglowamiconn: ahh, blast, forgot to add the static back
02:14:55 Join netcrusher88 [0] (n=8115be63@labb.contactor.se)
02:14:56preglowlinuxstb: seems like a bit of a waste, that's all
02:15:10preglowlinuxstb: you hardly need to spin up the flash all the time, so copying could happen more frequently
02:15:59linuxstbInstall linux and type "cat /proc/meminfo" :)
02:16:08preglowamiconn: anything else you see that needs fixing?
02:17:40linuxstbpreglow: 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:44amiconnLooks good so far.
02:18:08amiconnlcd_blit() won't be necessary for >4 bit displays though
02:18:35preglowso i should just remove it and put an ifdef in lcd.h?
02:18:49linuxstbamiconn: Why not? I thought that was used to write a bitmap to the LCD without going via the framebuffer.
02:19:06linuxstbOr have I misunderstood?
02:19:38netcrusher88what is the difference between recorder v2 and fm recorder?
02:19:47 Quit thegeek (Read error: 110 (Connection timed out))
02:19:52amiconnYes that's what it's for, but we won't need that for higher bit depth greyscale or colour lcds
02:20:41amiconnThis function is used for 2 things with low-depth displays: (1) grayscale library, (2) video playback in .rvf format
02:21:07amiconnI'm almost sure video will be handled different on high-depth displays
02:21:45amiconn...decoding data with a true video codec into the frame buffer, then using lcd_update() to show that
02:22:07amiconnhttp://www.rockbox.org/twiki/bin/view/Main/GraphicsAPI
02:22:30preglowyes, i think we pretty much have to
02:22:41pregloweven on h1x0 the data will become quite large when stored uncompressed
02:22:48amiconnYes
02:25:53 Part netcrusher88
02:27:04preglowamiconn: so i should just ifdef out blit in lcd.h?
02:28:21preglowprobably doesn't matter to keep it there anyway
02:28:44preglowso 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:28amiconnLotR 1 is 764MB in archos .rvf format. Will be almost 2GB on H1x0
02:31:39preglowyes, it does seem to have 32 megs ram
02:31:47preglowwe can more or less just pretend the flash is a hard drive
02:32:08amiconnThat's the same good thing as with the Ondio
02:32:15preglowcertainly seems to be the route it takes internally anyway
02:32:40preglowi think you can actually wire hard drives to a nano
02:32:53preglowamiconn: yes, and god knows what on colours displays
02:33:08linuxstbamiconn: Do things like the delayed write of the config sector still happen on the Ondio?
02:33:14amiconnyes
02:33:31amiconnIt serves another purpose than on the disk units
02:33:45amiconn...not wearing the flash more than necessary
02:35:56preglowlinuxstb: btw, has apple dropped all hfs ipods? this one came with fat32 and no questions asked about it
02:36:17amiconnpreglow: If you remove lcd_blit() from the driver, you need to comment it out in the plugin api
02:36:42linuxstbpreglow: Are you sure it came with fat32? I think mine came unformatted.
02:37:03linuxstbConnecting it to itunes caused it to be initialised.
02:37:11linuxstbIIRC
02:37:38amiconnpreglow: It seems you broke the h300 build
02:37:53linuxstbIt was working? :)
02:38:03preglowwhat linuxstb said
02:38:27preglowlinuxstb: how can it come unformatted? itunes formats it on the first go?
02:39:03preglowamiconn: no surprises there, btw
02:39:18preglowamiconn: i'm going to ignore that for now, as the fix will just be to introduce a bunch of empty functions anyway
02:39:36amiconnYes, lcd-h300.c
02:39:56preglowwont cost linus an ounce of extra work when he gets to it anyway
02:40:24amiconnI think I'll do the split for the 1bit lcd targets
02:40:30amiconnBut not now
02:40:43preglownot much of anything right now
02:40:46preglowsounds about time to go to sleep
02:40:55amiconnyeah
02:41:16linuxstbdefinitely agreed.
02:41:19preglowyuop
02:41:25preglownight, see you around
02:41:31amiconnnight
02:41:39linuxstbTime for the night shift to take over. Goodnight.
02:56:26***Saving seen data "./dancer.seen"
02:57:01elinenbeamiconn and preglow: you both have the new ipods?
03:00
03:03:52linuxstbNo, 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:45netcrusher88so...
04:01:01netcrusher88what 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:00NSplitkornbluth.freenode.net irc.freenode.net
04:15:21NHealkornbluth.freenode.net irc.freenode.net
04:15:21NJoinghode|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:17preglow_FireFly_: well, it takes the loop variable as a parameter, you can give it whatever you want
09:00
09:00:28B4gderhere's one for you ipod hackers: "Efficient programming techniques for ARM" => http://www.at91.com/www/phpBB2/download.php4?id=151
09:00:37B4gderpdf
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:54amiconn_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:36preglowdealing with this clickwheel is going to be tricky
09:06:27preglowseeing as we probably want to use velocity sensitivity
09:07:20korpsepreglow: working on the iPod port there?
09:08:10preglownot right now, no
09:08:26preglowright now i'm trying to come to grips with being awake again
09:08:55korpsethe toughest part of a day
09:08:57korpse:)
09:09:04preglowa wholly unpreferable situatuin
09:09:07preglowsituation, even
09:10:39Zagorpreglow: do you know what hardware interface you have to the clickwheel?
09:12:14preglowZagor: no, actually, i'm hoping it's something quite highlevel :)
09:12:56preglowit's quite high-resolution, it seems
09:13:48preglowB4gder: i've been looking for something like this, cheers
09:18:17*B4gder uses an "at91" at work
09:20:02preglowone of the atmel arms?
09:20:06B4gderyes
09:20:14B4gderarm920 core
09:21:59hardeepnice, 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:20hardeepi'm using the latest version with the iriver sim
09:23:33preglowB4gder: is there a general rule on when to use thumb code and when to not use it?
09:23:57B4gderpreglow: 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:26Jungti1234hi
09:24:39preglowipods have 16 bit memory :/
09:24:44*B4gder never tried insight...
09:24:56B4gderpreglow: then it might be an idea
09:28:24preglowarm assembler is pretty nifty
09:28:29B4gderindeed
09:28:41B4gderthe niftiest around imho
09:31:15 Quit hardeep (" HydraIRC -> http://www.hydrairc.com <- The future of IRC")
09:31:50Jungti1234Is DRM of rockbox supported?
09:32:11Jungti1234in H100.
09:32:31ZagorJungti1234: no
09:32:32B4gderJungti1234: if you ask if "DRM codecs" are supported, then the answer is no
09:32:50ZagorDRM and open source doesn't mix well
09:33:48B4gderDRM and enlighted users usally don't mix well either
09:34:24korpseMusepack is supported, right?
09:34:30preglowyes
09:34:37preglowit'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:02linuxstb_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:26preglowso there is indeed a decoder there
09:38:26TiMiDI'm here for 5 minutes max !
09:38:37TiMiDI looked at your patch
09:38:42TiMiDsome remarks
09:39:37TiMiDfirst I don't know why declaring 2 vars main_data and remote_data
09:40:13TiMiDhmm
09:40:17TiMiDnothing forget it
09:40:20_FireFly_these to vars hold the wps-data for both screens :)
09:40:22_FireFly_;)
09:40:26TiMiDbut just make a tab instead
09:40:36_FireFly_a tab ??
09:40:55TiMiDextern struct wps_data wps_datas[NB_SCREENS];
09:41:11_FireFly_ok
09:41:12TiMiDI think you use them to fill the lack of malloc in rb ?
09:41:14Slashereh, 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:47TiMiD(instead of doing malloc for the ptr in wps_gui you uses &main_data or remote_data
09:41:51TiMiDok
09:42:02TiMiDso 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:21TiMiDbut that's just a detail
09:42:31_FireFly_it's simple to change ;)
09:42:44Zagor_FireFly_: sure we could, but the unused memory would remain unused, so no gain
09:42:50TiMiDyes there are plenty of places where a malloc would help to reduce memory used ;)
09:42:51_FireFly_k
09:43:01B4gderI beg to differ
09:43:08ZagorTiMiD: it's an illusion
09:43:17TiMiDyes it's an illusion ...
09:43:38TiMiDwhen I see an empty tab like the one used for dir content
09:44:05TiMiDor a char buffer used to virtually malloc strings (like the one in playlist_viewer.c)
09:44:16TiMiDmaybe they donesn't take a lot of memory
09:44:21preglowSlasher: nice........
09:44:30TiMiDbut they make the code ugly (that's my opinion)
09:44:34zemath 24*30
09:44:36zedoh
09:44:41B4gderTiMiD: you'd still have to deal with the worst case, fragmentation and the additional code size required
09:44:58ZagorTiMiD: 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:14preglowSlasher: perhaps you're writing to the wrong port? :)
09:45:27TiMiDyes I know about memory fragentation, and without a MMU I know it's more difficult to handle
09:45:54TiMiDbut coding would be a lot cleaner with malloc
09:46:00preglowjust forget about it
09:46:03B4gderI disagree
09:46:10ZagorTiMiD: it would A LOT more buggy
09:46:11preglowyou have to code for the worst case anyway
09:46:13Zagorwould be
09:46:17preglowso just use buffers
09:46:20TiMiDno
09:46:34TiMiDyou can use only the ammount of memory you need
09:46:41TiMiDfor example with chained lists
09:46:45preglowand if it changes during runtime?
09:46:58B4gderand how would the playback system get the memory it needs?
09:47:07preglowthen you'll need a malloc buffer somewhere with lots of spare memory in it
09:47:08B4gderif split up my malloc?
09:47:11preglowand bang, you're back to where you were
09:47:24preglowwith buffers designed for worst case
09:47:41B4gderTiMiD: we've heard all these arguments, we've thought about them, we've dismissed them
09:47:46preglowno, i'm completely with the elders here
09:47:49preglowmalloc is bad in our case
09:48:12preglowit would clutter the memory management for no gain at all
09:48:51TiMiDit would just make programs easier to understand
09:49:07B4gderreally?
09:49:15TiMiDeven if I agree, in practice, it's difficult to implement without virtuals adressing
09:49:15preglowhow?
09:49:35preglowyou can't get much easier than static buffers
09:49:41Zagorit's not only difficult, it's pointless
09:49:48preglowand with mallocs you get a free nightmare
09:49:52preglowfree() that is
09:49:53TiMiDas I said lot of parts of the code use static buffers and do their dynamic allocation in those
09:50:02B4gderpersonally I think static memory usage is simpler than malloc ones
09:50:09TiMiDthat's not the cleanest thing I saw
09:50:26preglowcleaner than malloc
09:50:29Zagorlocal reserved pools are ugly?
09:50:34preglowon the grounds that you can just forget having ever done it after you've done it
09:50:38preglowno leaks
09:50:39TiMiDyes in some cases they are
09:50:50B4gderI don't think that is because of static vs malloc, it is just code that can be written more clearly
09:50:53TiMiDyes no leaks
09:51:23TiMiDbut even on a computer with malloc, a good programmer must know how to program wthout leaks :/
09:51:48Slasherpreglow: i have defined:
09:51:50Slasher#define SDA_LO and_l(~0x00001000, &GPIO_OUT)
09:51:57Slasher#define SCL_LO and_l(~0x00002000, &GPIO1_OUT)
09:51:59TiMiDand here the cases are trivial (at least in the app layer code) so leaking would be very difficult ;)
09:52:08ZagorTiMiD: 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:14Slasher(from fmradio_i2c) and i think that should be the right port according to schematics..
09:52:21Slasherbut the signal remains static high
09:52:43TiMiDwell I have to go
09:52:59TiMiDbut I don't agree with you on this point hehe ;)
09:53:01Zagormalloc depends on having a free UNUSED pool, which is precisely the opposite of our goal
09:53:18XShocKTiMiD: it is just not easy to implement that stuff properly without loss of memory
09:53:42B4gderTiMiD: if you'd try to write down a complete proposal, you'll start seeing our point
09:53:51linuxstb_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:55Slasherpreglow: Ah! but i could check that easily. I will force that signal low and checking how the port status changes
09:53:57ZagorTiMiD: 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:01TiMiDfor example removing the statical file buffer in tree.C would make you gain a lot of memory
09:54:18B4gderTiMiD: again, you try to show that with a *complete* proposal
09:54:23ashridahi imagine you're going to quickly run into fragmentation issues if you start using malloc
09:54:41ZagorTiMiD: then how would we show the file tree while playing music?
09:55:11linuxstb_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:38B4gderand it would be a *MESS* to may the audio system use a segmented memory system
09:55:54TiMiDZagor: 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:56B4gdermake
09:56:10*B4gder stops having this conversation
09:56:37*TiMiD g2g
09:56:43linuxstb_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:31TiMiDit 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:48ZagorTiMiD: no, because you can't use it for anything else
09:57:56linuxstb_Exactly.
09:58:00Zagorfree memory is worthless
09:58:07TiMiDand I'm not talking about having the most free memory possible, just about code sanity
09:58:28linuxstb_But malloc (and checking for errors) will just complicate the code.
09:58:49linuxstb_How do you react when a malloc fails?
09:59:18Jungti1234Can not you support DRM to H100 rockbox firmware?
09:59:38B4gderJungti1234: feel free to add
09:59:57Jungti1234:)
10:00
10:00:19linuxstb_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:37LinusNit's funny, we have this discussion with every new developer :-)
10:00:49ZagorJungti1234: 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:25Jungti1234aha
10:01:29Zagor...since that would mean their DRM gets broken in a week
10:01:39XShocKJungti1234, you can still try to ask them. god blesses you.
10:01:58Jungti1234hehe
10:02:01ZagorXShocK: we don't want to license either. the license restrictions are massive.
10:02:10LinusNi though microsoft was god ;-)
10:02:15linuxstb_Dear Bill, Please tell us how to remove the DRM from your files. Love Rockbox.
10:02:31XShocKZagor, I am not a fan of DRM anyway... I don't even have anything to play it with.. :)
10:02:35korpselinuxstb_: hahaha
10:02:52Jungti1234haha..
10:03:25LinusNdrm is not good for customers, only for corporations
10:03:27preglowTiMiD: exactly how is malloced buffers more _sane_ than static buffers?
10:03:54preglowTiMiD: 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:22linuxstb_... and the increased code size to deal with errors.
10:04:50XShocK... and it is not that much harder(if not easier) to code static code.
10:04:56SlasherLinusN: 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:56preglowit's easier
10:04:58preglowundoubtedly
10:05:04SlasherNow i try to check that SDA too
10:05:45XShocKSlasher, are you trying to implement writing to i2c?
10:05:47LinusNSlasher: oops
10:06:25LinusNwhat will you do with the eeprom?
10:07:16ashridahlinuxstb: 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:01SlasherAnd yes, SDA is GPIO1, 13
10:08:03XShocKwith no MMU, no virtual memory... it sucks
10:08:05Slasherthey have just swapped :)
10:08:09SlasherXShocK: yes
10:08:27SlasherLinusN: i will try to get it working and save the settings structure there
10:08:28ashridahyep. no paging, so no hope of consolidating free pages
10:08:48B4gderit seems we are united on this at least. We'll just have to bit the sense into TiMiD ;-)
10:08:56B4gderbeat even
10:09:05ashridahwas about to say, not biting anyone, thanks
10:09:34B4gderbut beating is fine?
10:09:47LinusNSlasher: 128 bytes won't help you much
10:09:47ashridahas long as none of their blood gets on me
10:09:52B4gder:-)
10:10:13preglowit's only 128 bytes? :/
10:10:20LinusNyes, 1kbit
10:10:31preglowdrat
10:10:40preglowSlasher: start writing settings to flash :P
10:11:11SlasherLinusN: oh.. i though it was 1 KiB :(
10:11:16Slasherso it's pretty useless then
10:11:26Slasheryes, flash seems only option then
10:11:34LinusNi 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:43LinusNtouch
10:11:47XShocK128 byte of memory... around 20 kbits/sec speed... times of first PIC microcontrollers are rising again...
10:12:14Slasherbut good to know that.. i will no longer bother working with that poor eeprom :D
10:12:25XShocKbut still do writing. :)
10:12:26Slasheri will try the flash next
10:12:44*preglow finds out he's drinking milk gone bad...
10:13:06SlasherXShocK: i can finish the driver but i don't know if we have any use for that
10:13:41LinusNdon't bother
10:14:06XShocKyes. 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:48XShocKone day.. when there is no job, no midterm, no homework, no papers... i will solder it in.
10:15:58LinusNoh, then....
10:16:22LinusNwhen you retire, that is :-)
10:17:47 Part linuxstb_
10:18:24XShocKright... 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:51LinusNXShocK: publish the schematic
10:19:54 Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se)
10:20:17linuxstb_Looks like Microsoft has reverse-engineered iPod support into the Xbox360: http://www.theregister.co.uk/2005/11/08/xbox_360_ipod/
10:20:36korpsereverse-engineered? really?
10:20:43XShocKquarz, two capacitors, and a i2c maxim rtc. nothing really to publish. :)
10:20:45korpsei would've thought they'd only need to wave their hand
10:20:51linuxstb_"there is no official relationship with Apple"
10:21:27linuxstb_But they didn't go as far as stealing the code from hymn
10:22:37Zagorlinuxstb_: the article says they *don't* have itms support in xbox
10:22:59linuxstb_That just means it doesn't support DRMed files.
10:23:27Zagorright. so the "reverse engineering" is the part where they access a USB mass-storage device and plays files from it... :-)
10:23:43linuxstb_No - it's reverse-engineering the itunes database on the ipod.
10:23:51XShocKok. i will go home tomorrow and try to find that thingy in my desk, and solder it on saturday... decided
10:23:58B4gderat least they used reverse-engineered info
10:24:05Zagorlinuxstb_: aha, ok
10:24:23B4gderZagor: you seen the file names used on an ipod? ;-)
10:24:27Zagoryes...
10:24:39Zagorotoh, they could simply scan the drive and make the list themselves. it doesn't say.
10:24:47preglowi wondows how gcc does at generating thumb code
10:24:49Zagor(unless you have other sources with more info)
10:25:12preglowwondows
10:25:14preglownice word
10:25:22Zagorthey'll need some scanning anyway to support non-ipod players
10:25:49linuxstb_Zagor: The filenames are obfuscated - so presenting a list of filenames is not useful.
10:25:53B4gderpreglow: -mthumb
10:27:20Zagorlinuxstb_: perhaps indexing tags, like we do?
10:27:33linuxstb_Zagor: Maybe.
10:29:41 Quit Hadaka (Remote closed the connection)
10:29:42preglowthe 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:02B4gdernooooo, apple is king!
10:30:05Zagorpreglow: no no, it's the BEST! you don't understand!!
10:30:06B4gder:-P
10:30:20ZagorSteve, tell him!
10:30:39B4gder /invite Steve #rockbox
10:30:41B4gderoops
10:31:03preglowit's remarkably nice to look at pictures with
10:31:06preglowconsidering the small screen
10:32:20B4gderhow big is it? I mean physically
10:33:19preglowgimme a sec
10:33:32XShocKbtw, did GCC 4.0 finally introduced any improvement in speed?
10:33:36preglow31mmx24mm
10:33:46preglowXShocK: no, quite the opposite
10:33:48 Join webguest67 [0] (n=c2848364@labb.contactor.se)
10:33:51preglowXShocK: at least for some codecs
10:34:10webguest67how long until rockbox on h3xx linus ?
10:34:17XShocKbad
10:34:27B4gderalmost the exact size of the archos rec screen
10:34:30LinusNwebguest67: not sure, i'm working on it
10:34:48 Part linuxstb_
10:35:25webguest67good but ive seen that you have got info about the lcd :D
10:36:20webguest67im really looking forward to the firmeware !:D
10:36:35LinusNwebguest67: me too :-)
10:37:37webguest67hope it wont take loong :D
10:37:48webguest67keep 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:30amiconnLinusN: [10:02:40] <LinusN> it's funny, we have this discussion with every new developer :-) <== not with me :)
10:50:36ashridahaah, the optimisim of the masses
10:50:54B4gderamiconn: you want it now instead? B-]
10:51:01amiconnNo
10:51:02preglowhaha
10:51:04preglownot with me either!
10:51:18B4gderhm, we clearly are loosing it
10:51:34amiconnB4gder: Certainly not
10:51:40preglowif me and amiconn teams up, i'm sure we can convert you to do the wonders of malloc
10:51:45B4gderhehe
10:52:31amiconnmalloc() would eat memory for no reason and bloat the code
10:52:46preglowit wouldn't eat any more memory than we currently do
10:52:51preglowbut the code would be ugly
10:53:01preglowas a matter of fact, we _would_ eat more memory
10:53:08preglowthanks to fragmentation
10:53:20B4gderand to the malloc functions
10:53:33B4gderI mean the actual additional code
10:53:37preglowno, can't say i miss mallocs
10:54:14B4gderI could imagine offering malloc() to plugins
10:54:40B4gderif we ever think of a half-baked reason that would benefit anyone
10:54:56preglowis there currently anyway to dynamically change the size of the playback buffer?
10:54:59preglowany way
10:55:14B4gderpreglow: yes, it is changed at startup
10:55:26B4gderbut only then
10:55:30preglowthat's not dynamically :)
10:55:38B4gderwell, its not fixed at build time
10:55:58preglowwe might need ways to allocate buffers in the future
10:55:58B4gderbut then no
10:56:02preglowas a matter of fact, we do now
10:56:06preglowwith the disk cache
10:56:12preglowit currently needs to reboot
10:56:31preglowwhen 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:40preglowrequiring a restart for all this is a bit ugly
10:56:46 Join amiconn_ [0] (n=jens@p54BD4E5F.dip.t-dialin.net)
10:57:08B4gderpreglow: I'll enjoy reading your suggestion on how we'll accomplish that otherwise ;-)
10:57:21preglowB4gder: it would entail flushing the buffer, of course...
10:57:27B4gderright
10:57:38preglowbut i still believe that's better than restarting
10:57:43preglowit even takes less battery
10:57:53B4gderit would of course be possible if done correctly and controlled
10:57:58preglowyes, sure
10:58:25preglowin some cases we might not even need to stop playback
10:58:35preglowif 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:31XShocKwhat am i doing at 5:30 in the morning?
11:24:33preglowam i supposed to guess? ;)
11:25:00Webguest82The Korea is 19 : 24.
11:25:33B4gderhttp://timeanddate.com/worldclock/
11:26:24Webguest82hehe..
11:27:26XShocK:)
11:27:42Webguest82Because 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:56muesli-high
12:24:25Jungti1234hi
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:08preglowanyone 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:28B4gdersourceforge is clearly not playing ball atm
12:49:38preglowno 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:14linuxstbpreglow: http://sourceforge.net/projects/ipodlinux/
12:50:38preglowso THAT web page works
12:50:38preglowhaha
12:50:47linuxstbThey've had problems recently with anon cvs for projects starting with the letter "i" :)
12:51:20preglowhahah
12:51:30preglowsounds like they've got some kind of lottery going
12:51:43linuxstbI 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:12linuxstbIt's not a very active list though...
12:52:49B4gdertheir lack development community "services" surprises me
12:53:17B4gderinsert "of" somewhere
12:53:39linuxstbYes, it's very disjointed. No single unified build system for a start. You pick up bits and pieces from different places.
12:55:25preglowi don't get their cvs
12:55:28preglowwhat should i download?
12:55:33preglowlinux? linux-2.6?
12:55:35linuxstbpreglow: Everything.
12:55:42preglowaight
12:56:08preglowsigh, one more project using sf cvs
12:56:12linuxstbIgnore 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:50linuxstbThe interesting code is in linux/arch/armnommu/mach-ipod/ and tools/podzilla/
12:56:56preglowuClinux-dist?
12:57:01 Join BirdFish [0] (n=bradbox8@64.108.5.134)
12:57:24linuxstbNo idea.
12:57:44preglowi'll just ignore that for now, then
12:58:18linuxstbpodzilla uses microwindows for display - the microwindows drivers are in tools/microwindows/src/drivers/
12:58:41linuxstbBut that doesn't give us any more info than the framebuffer kernel driver.
12:58:56Slasherpreglow: 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:07preglowhow i love the fact we don't use linux
12:59:12Slasherrombox for iriver isn't that far away now :)
12:59:13preglowSlasher: sounds nice
12:59:42SlasherAnd the functions should be safe, they refure to erase any critical areas
13:00
13:00:01linuxstbAs 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:33SlasherAnd when flashing the rombox, erasing and writing to non-critical areas are tried first before erasing the critical area
13:01:29preglowSlasher: perhaps it would be wise to do the config sector saving using some flash exhaustion preemptive methods?
13:01:34linuxstbI wouldn't want to implement things like USB, Bluetooth, ethernet, wi-fi etc in Rockbox.
13:01:39preglowi don't know how many write cycles the flash is supposed to take
13:01:55Slasherpreglow: yes, true. We should prevent unnecessary erases
13:02:06Slasherflash is guaranteed to last at least 100 000 cycles
13:02:16preglowthen i don't know whether we should worry at all
13:02:36preglowmost flash chips surpass their guaranteed limits by _far_
13:03:43SlasherHmm, and the eeprom chip endurance is 1M cycles
13:03:50SlasherSo flash is almost that good :)
13:03:59 Join justsomeperson [0] (n=92a9198c@labb.contactor.se)
13:04:10preglowbut there are ways
13:04:16preglowlike allocating eight blocks for the config sector
13:04:25Slasherpreglow: At least we could save the configs only when shutting down the unit
13:04:26preglowand using them in a round robin fashion
13:04:36Slasheryes
13:04:38preglowby writing a serial number that's incremented each time, you find out which is recent
13:04:42SlasherOne block is 4096 bytes
13:04:51preglowwe just need 512 bytes
13:04:57preglowbut all flash is erased a block at a time
13:04:59SlasherSo it can hold configs
13:05:03Slasher+8
13:05:06preglowall flash i know of at least
13:05:16preglowso we need eight blocks
13:05:17SlasherYep
13:05:19preglowfor it to matter
13:05:33preglowstill
13:05:36preglowi don't know if we should care
13:05:41SlasherWe need one block from flash but we can use that block eight times before needing erase cycle
13:05:54preglowahh, that's true
13:05:56SlasherSo practically we could get 800 000 cycles endurance for that block :)
13:06:04preglowyep
13:06:18preglowwell, it's an idea to keep at least
13:06:57Slasheryes, and should be easy to implement
13:08:06Slasherwe 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:17preglowhmm, doesn't seem like you can adjust the contrast on a nano
13:08:41preglowlinuxstb: anything you're currently working on? just so i know i'm not duplicating your effort
13:08:56preglowSlasher: yep, that's true
13:09:14Zagorpreglow: colour screens don't normally have contrast settings, do they? the cameras and mobile phones I've seen all only have brightness
13:09:26Slasheri 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:39preglowZagor: well, the colour has contrast, it seems
13:09:43preglowipod color, that is
13:09:51preglowSlasher: sounds like a good idea
13:12:53preglowZagor: forget that, i'm making a fool of myself
13:13:09Zagorok :-)
13:13:28preglowi seriously doubt there's a inversion function as well
13:14:05ZagorSlasher: what's the rewrite rating on the flash? 1000 times? 10000?
13:14:28SlasherZagor: 100 000 times says the specs
13:15:02ashridahthe iriver writes its config data to flash?
13:15:07ashridahor am i reading this wrong?
13:15:21pregloweeprom
13:15:22SlasherOh, typical endurance is 100 000 but guaranteed only 10 000
13:15:38preglowSlasher: in which case i say we definitely go for the round robin config save
13:15:56SlasherHmm, yes
13:16:04 Join tucoz [0] (n=81b17b04@labb.contactor.se)
13:16:14SlasherBut we should still save the config only on shutdown
13:16:24Zagorwhat's the typical spinup time on the 1.8" disks?
13:16:29preglowcouple of secs?
13:16:52tucozZagor: I just checked freshmeat. Rockbox is still in v2.4 over there
13:17:23SlasherThen 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:27Zagortucoz: oops
13:17:35tucoz:)
13:18:18Zagorremind me: why do we want to use the flash instead of the disk?
13:18:33preglowso we don't need to wait for it spinning up?
13:18:36SlasherZagor: probably for faster boot time when using rombox
13:18:38preglowmore battery left?
13:19:28Zagorwell 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:29Slasherbut if user has not flashed rockbox, then we shouldn't use the flash at all
13:20:00preglowof course
13:20:08Zagori 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:08SlasherHmm, my player always spins up the disk on shutdown..
13:20:18tucozThe plugins would fit in flash, right?
13:20:34preglowtucoz: i think we'll rather put the codecs there
13:21:03SlasherZagor: We can start doing other initializations (such as audio) without needing to wait the disk
13:21:17tucozpreglow: of course, that is a priority. But, if they fit as well, then that would be cool
13:21:17Slasherso it should give a few seconds faster boot.. But i will test that soon
13:21:22ZagorSlasher: do we need to the config to init the audio?
13:21:35SlasherZagor: I think currently the config is the first thing loaded
13:21:42tucozI think it is a bit annoying with the disk spinups all the time ;)
13:21:57Slasherand yes, we do.. At least on some level
13:24:16preglowlinuxstb: doesn't seem like the empty lcd-ipod.c functions will be filled anytime soon...
13:24:26preglowi'll just remove the warnings, i can't stand all the console spamming when building
13:30:27 Quit tucoz ("CGI:IRC")
13:38:53ZagorI 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:15ZagorIt's both safer and mort portable
13:40:33preglowbut the init code always will
13:40:40Zagorwhy?
13:40:40preglowyou can't do the disk cache without the settings, for example
13:40:54preglowsince that needs to work pre-mp3buffer alloc
13:41:02Zagorthen place that last
13:41:29Zagorwe can't do a complete boot without disk anyway. this is only about rearranging things so we do it the most efficient
13:42:02Zagorfonts and wps files etc need to be loaded too
13:42:13preglowlet's keep them in flash! :)
13:42:17Zagorhehe
13:42:25linuxstbpreglow: 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:15preglowyep
13:43:18preglowlooking at button driver right now
13:44:14 Quit DJDD ("Trillian (http://www.ceruleanstudios.com")
13:47:45linuxstbpreglow: 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:54amiconnSlasher: I seriously doubt that saving the configs in flash will speed up booting much
13:48:34linuxstbIt 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:39amiconnWe already discussed it in the past for archos
13:48:44preglowamiconn: not speed up booting, speed up shutting down
13:48:57amiconnOf course on the archos there's the additional problem that not all units are flashable
13:49:04preglowlinuxstb: yeah, i'll just do the button driver first, since that can be verified to work from the bootloader
13:49:22linuxstbWell, almost everything can be tested in the bootloader.
13:49:22amiconn...and the flash is way smaller
13:49:46preglowlinuxstb: anywho, i'm more in the trying-to-get-an-overview stage as of now
13:49:53preglowi might end up working on whatever. we'll see
13:50:04amiconnlinuxstb: The 16bit lcd format is known, right?
13:50:12linuxstbpreglow: Well, if I start working on anything, I'll let you know.
13:50:19linuxstbamiconn: You mean for the ipod?
13:50:39amiconnyes
13:51:16linuxstbYes - 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:20amiconnI'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:40linuxstbEach 16-bit value contains the rgb565 value for that pixel.
13:51:51amiconnThe win32 sim will be way easier to adapt than the x11 one
13:52:13B4gderhow so?
13:52:26preglowbut it seems the ipod keys can be interrupt controlled
13:52:32preglowi wonder if i should bother with that
13:53:01amiconnB4gder: Because it doesn't involve fiddling with x11 deficiencies.
13:53:13B4gderchicken! ;-)
13:53:21amiconnOn windows, a display bitmap is essentially a .bmp in memory
13:53:43preglowdoes any of the other platforms support irq for controls, btw?
13:53:54amiconnnope
13:53:59preglowokies
13:54:08preglowi think i'll just try a polling approach for now
13:54:13amiconnAll current button drivers poll the status, once per tick
13:54:29preglowthough 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:31amiconnThere is no way to fire button interrupts on these platforms.
13:56:00 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
13:56:12amiconnSome buttons are connected to gpio pins, most use resistor networks to connect several buttons to an adc input
13:56:15Zagorpreglow: shutdown can be sped up by faking it
13:56:22Zagorlike all mobile phones do
13:56:31linuxstbLinusN: Is the 16-bit mode of the H300 LCD the same as the ipod? i.e. rgb565 ?
13:56:35preglowZagor: some not successfully
13:56:50preglowamiconn: i know, but if interrupts were possible that would be all there was to it, yes?
13:56:54Zagorpreglow: how do they fail?
13:57:07preglowamiconn: just remove the handler from the tick queue and tinker with the event queue from an isr?
13:57:18amiconnyes, that should work
13:57:34amiconnThe tick functions are also running in isr context
13:57:50amiconn...of the timer tick interrupt
13:57:53preglowZagor: 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:12preglowamiconn: yes, but this way the overhead would be much lower
13:58:21preglowsince the keyhandler wouldn't be run every tick anymore
13:58:28preglowanywho, i'll deal with that later
13:59:41linuxstbThere 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:52preglowstatic void opto_i2c_init(void)
13:59:55ep0ch_Slasher: something is annoying me with the track buffering...
13:59:57preglowanyone know what that could be?
14:00
14:00:42linuxstbAll I know is that it's part of the button init code.
14:00:57preglowyeah, i know, i just wonder if i'll confine the code there
14:01:08ep0ch_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:13preglowin the button driver file, that is
14:01:30linuxstbep0ch_: 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:54preglowshouldn't it be easy to see if that's actually happened?
14:02:12preglowif the buffering pointer is behind the curplaying pointer, then it's ok and it's not been overwritten
14:02:28Zagorpreglow: ok that is bad faking. we are much better at faking! ;-)
14:02:55linuxstbIt would seem a useful optimisation.
14:03:28preglowseems i actually _have_ to use an interrupt
14:03:32preglowthe button interface is i2c
14:03:59linuxstbpreglow: Yes, my impression was that we had to use interrupts.
14:04:05preglowgrah
14:04:09preglowthis'll be a feast
14:04:35preglowi'm willing to bet the interrupt controller has to be set up first as well
14:04:54linuxstbThere is button code in the bootloader which doesn't use interrupts, but I don't think it works very reliably.
14:05:06preglowor no, i keep forgetting about the apple bootloader, perhaps that does it for us
14:05:07linuxstbAt least, not on 4G devices like ours.
14:05:41preglow1g, 2g and 3g use ordinary gpio based handling
14:07:44preglowlinuxstb: the ipl bootloader?
14:07:47preglowcan't see anything in yours
14:07:51linuxstbYes, sorry.
14:08:14linuxstbtools/ipodloader in the ipl cvs
14:08:20ep0ch_dumb question, does ipod do mp3+aac decoding in software or does it have dedicated hardware?
14:08:27linuxstbsoftware.
14:08:28preglowsoftware
14:08:31ep0ch_nice
14:08:58ep0ch_i'm really very tempted to get one now :)
14:10:11ep0ch_you played doom on your nano yet preglow?
14:10:14preglowlinuxstb: it's not in cvs?
14:10:15 Quit B4gder (Read error: 110 (Connection timed out))
14:12:53linuxstbpreglow: What isn't in CVS?
14:13:16preglowthe bootloader
14:13:26preglowcould only find it on their project page
14:13:47linuxstbYes - the ipl bootloader is in the tools/ipodloader directory of the ipl cvs.
14:14:02linuxstbThe same directory as "make_fw.c"
14:14:18preglowremarkable, the only thing i have in the tools is patch_fw and ivdeo
14:14:20preglowvideo
14:14:33linuxstbDodgy cvs checkout by the sounds of it.
14:14:54preglowyes, and now cvs refuses to answer again
14:14:55preglowbah
14:15:01preglowi'll just look at the tarball for a bit
14:15:22linuxstbMy local copy of their CVS is a mess, but I'll upload the ipodloader directory for you.
14:16:37linuxstbhttp://www.davechapman.f2s.com/rockbox/ipodloader.tgz
14:17:12preglowthanks
14:17:45linuxstbDo you think we should add make_fw to the Rockbox CVS?
14:18:21B4gd3rI 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:21linuxstbOr we could possibly add the functionality to scramble.
14:19:37B4gderthat would be even better
14:19:45B4gderif it makes sense
14:19:54preglowhmm
14:19:55linuxstbI'll have a think about it.
14:19:58preglowi don't think it does
14:20:07preglowmkboot.c is the closest thing i think we've got
14:21:29linuxstbI think you're right - scramble is for rockbox itself. We only need make_fw for the bootloader.
14:22:50preglowbut what the hell does "opto" mean??
14:26:38linuxstbNo 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:28preglowmy, my, is cygwin slow
14:47:50preglowokokok
14:47:52preglowi wont be doing that again
14:48:32preglowit overwrote parts of my second fat partition as well
14:48:38B4gdercygwin is painfully slow
14:48:48preglowand inaccurate, it seems
14:49:08preglowglad i didn't try it out on my hard drive first
14:49:56amiconncygwin isn't inaccurate
14:51:05 Join kurzhaarrocker [0] (n=Phil@p5090AFBF.dip0.t-ipconnect.de)
14:51:08preglowwhy did it screw up my partition, then?
14:51:14preglowi wrote a four meg file to sdc1
14:51:19preglowand sdc2 broke completely in the process
14:51:26linuxstbThat should have been sdc (I think)
14:51:40linuxstbSorry, forget that.
14:51:44linuxstbThought you said 4G
14:52:01 Quit B4gder ("time to say moo")
14:52:06preglowyour wiki page says partition one, and that's what i've been doing all along
14:52:22 Part kurzhaarrocker
14:52:23linuxstbYes, you're right. Ignore my previous three sentences.
14:52:24preglowand it works
14:52:38preglowdd if=rockboot.bin of=/dev/sdc1
14:52:41preglowthat's what i did with cygwin
14:52:44linuxstbAnd sdc1 should be about 80MB.
14:52:52preglow4801024 bytes (4.8 MB)
14:52:54preglowthat's what it said
14:53:06linuxstbDoes "fdisk" work in cygwin?
14:53:07preglowand now apple firmware can't find a partition as it boots
14:53:44linuxstbIt doesn't do something stupid like numbering the partitions at 0 ?
14:53:53linuxstbi.e. /dev/sdc0 for the first partition?
14:54:53amiconnpreglow: Hmm, I didn't have such problems, but then I mainly used raw devices, not partitions
14:54:56preglownow that WOULD be stupid
14:55:06preglowlinuxstb: but yes, i believe that is what has happened
14:55:11linuxstbDoes "dd if=/dev/sdc0 of=test.bin" do anything?
14:55:17preglowi'm convinced, actually
14:55:49preglowbut lookie
14:55:53preglowsdc0 doesn't exist
14:56:26linuxstbWhat about sdc2?
14:56:40***Saving seen data "./dancer.seen"
14:56:55preglowdoesn't exist
14:56:57preglowonly sdc1 exists
14:57:01preglowhahah
14:57:10linuxstbStrange.
14:58:23preglowif it now turns out that cygwin doesn't map partitions it doesn't know what is...
14:58:23preglowbah
14:58:23preglowi'll just have to turn to linux for this, i guess
14:58:23linuxstbYes, the boot partition is marked as type 0 - empty.
14:58:29 Join kurzhaarrocker [0] (n=Phil@p5090AFBF.dip0.t-ipconnect.de)
14:58:37amiconnYou could change the type of partition 1, write it, then change type back to 0
14:58:51linuxstbDoes writing to /dev/sdc work? If so, you can still do it by writing to the correct area of the drive.
14:58:52amiconn(reading & writing the mbr with /dev/sdc and count=1
14:59:41linuxstbYou would probably have to disconnect and reconnect the ipod for cygwin to re-read the partition table.
14:59:57preglowamiconn: sdc0 works, yes, and is the mbr
15:00
15:00:00preglowahh
15:00:01preglowsdc
15:00:20preglowdoes dd have a skip parameter?
15:00:27linuxstbYes, "skip"
15:00:29preglowok
15:00:31preglowso skip=1 ?
15:00:36preglowno
15:00:36preglowmore than that
15:00:41preglowhow much?
15:01:08preglowthink i'll just repartition this bitch first
15:02:32preglowitunes doesn't recognize it
15:02:33amiconnThe start of the first partition depends on the (faked) disk geometry
15:02:44 Quit kurzhaarrocker (Client Quit)
15:02:46amiconnYou can get that info from the mbr
15:03:21preglowi think i'll just boot linux
15:03:53preglowthis'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:01Slasherep0ch_: start of the song gets always overwritten with another tracks
15:08:49Slasherwhen buffering starts, it will recalculate the free buffer space while loading a new chunk, so it will overwrite the beginning
15:09:23ep0ch_hmm
15:10:00Slasherof 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:48LinusNSlasher: would it be hard to prevent overwriting the first track?
15:11:35SlasherLinusN: shouldn't be hard,
15:12:14Slasherit's just matter how efficiently we want to use the buffer space
15:12:34preglowok
15:12:50preglowsdc1 has strings MSDOS and FAT32 in it
15:13:04preglowanother reason why i'll never like cygwin, this
15:14:42Slasherfor 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:16ep0ch_how to decide what type of buffering to use will be interesting :)
15:18:11Slashertrue :)
15:19:08 Quit kurzhaarrocker (Remote closed the connection)
15:19:46ep0ch_maybe rockbox could learn the users usage pattern. or just be boring and have another user setting.
15:20:51SlasherHmm, 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:14justsomepersonproposal: 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:01SlasherThat sounds a good idea :)
15:23:26crwlmaybe load two tracks at a time first at least
15:24:23justsomepersonby loading two you already assume that full buffer will be used...
15:24:41 Quit ashridah ("sleep")
15:25:06linuxstbI think account should be taken of the bitrate of the file. This can be up to 1000kbit/s for some lossless files.
15:25:36linuxstbThe get_metadata() routine calculates the bitrate - so it's done (or should be done) before the track is loaded.
15:26:00ep0ch_more its 24bit 96khz etc...
15:26:12ep0ch_ ^if
15:26:24preglowARGJHHH
15:26:28justsomepersonits actually just size of the track and not bitrate that matters
15:26:28preglowi _HATE_ itunes
15:26:47ep0ch_whats it done?
15:27:03preglowintrusive, unusable piece of shit
15:27:15ep0ch_do you now have to pay $0.99 for all your tracks again?
15:27:24preglowhaha
15:27:36preglowi don't buy internet music
15:27:44justsomepersonright on :)
15:27:45preglowit just pops up everytime i plug in my ipod
15:27:57linuxstbpreglow: Just uninstall it :)
15:27:58preglowso i have to unplug it again to use cygwin
15:28:24linuxstbIn fact, you could do that and find a third-party app to load tracks onto the device.
15:28:38preglowsuch a thing exists?
15:29:00linuxstbI think there are many. GnuPod is a famous one for Linux. Foobar has an ipod plugin.
15:29:09ep0ch_what does foo_pod do?
15:29:23preglowokokokko
15:29:25preglowi can't stand this
15:29:32preglowevery bloody time i use cygwin dd to access the ipod
15:29:35linuxstbep0ch_: I think it syncs a playlist to your ipod.
15:29:38preglowi need to unplug it again for it to work again
15:29:42linuxstbBut I've never looked at it.
15:29:43preglowi think i'll uninstall cygwin in the same gop
15:30:21justsomepersondoes 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:38ep0ch_preglow: Configure iTunes so it does not load when you connect your iPod. (not required, but highly recommended)
15:30:38ep0ch_
15:30:54Slasherjustsomeperson: that's for buffering
15:30:57ep0ch_oops sorry for extra blank spaces
15:31:07Slasherif disk is already spinning, we will flush the old buffer
15:31:22preglowep0ch_: did that
15:31:26ep0ch_oh
15:31:27preglowep0ch_: the cygwin problem remained
15:31:29Slasher(even in the case that track can be found already from the buffer)
15:31:37preglowit's starting to dawn on me that this i linux work
15:31:38preglowbrb
15:32:21justsomepersonSlasher: aha, just that - nothing more ?
15:33:05Slashernope. It just makes sure the buffer gets fully filled when the disk is spinning
15:33:48Slasherand also that the disk will not spin up if track is already loaded to the bufer
15:34:04justsomepersonthanks, that solves one problem I was working on
15:34:11Slashergood :)
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:39amiconnlinuxstb: 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:19linuxstbamiconn: What do you mean "even for" ?
15:47:49preglowwhat the hell....
15:48:12preglowwhen i cfdisk /dev/sdb now
15:48:23preglowthe freespace doesn't have sdb1 beside it anymore
15:48:33preglowcan the part table be screwed?
15:49:08linuxstbPossibly. Have you tried restoring your whole-device backup to /dev/sdb ?
15:49:24linuxstbDid you make a full backup?
15:49:35preglowyes
15:49:49preglowthink i'll try that
15:49:52linuxstbTry restoring it, and then unplugging and reattaching.
15:50:22linuxstbIf that doesn't work, you'll probably need to run Apple's "ipod restore" program from Windows.
15:50:57preglowgiving it a go now
15:52:54preglowi miss the activity light of the h120, heh
15:53:16 Join Jungti1234 [0] (n=jungti12@58.77.81.75)
15:53:22linuxstb#define LCD_VIRTUAL
15:53:35Jungti1234hi
15:53:38linuxstbs/LCD/LED/
15:55:29 Join muesli_- [0] (i=muesli_t@Bc1ee.b.pppool.de)
15:57:01preglowlinux 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:28crwli don't think it does
15:57:30wackyhey guys, are you still looking for a dead iAudio to work on ?
15:57:32crwlyou need to specify sync in fstab
15:58:17wackyand would a dead H120 be useful to you ?
15:58:31preglowin fstab? it's usb storage we're talking about here, it's not in fstab
15:58:50crwli have it in fstab
15:59:02crwlwhere then? i don't have any automounter things here if you meant that
15:59:09crwlas a mount option anyway
16:00
16:01:51preglowi seem to do
16:03:10 Quit Kohlrabi ("Leaving")
16:04:40 Quit Zagor ("Client exiting")
16:06:09preglowwell
16:06:19preglowi can under no circumstances get the ipod bootloader button code to work
16:07:44linuxstbAre there any kernel differences in the button driver for the nano?
16:07:57preglowfor the nano, no
16:07:59preglownone as far as i can see
16:08:40linuxstbSo I would expect the bootloader code that runs for hw_rev==6 should in theory also work for the nano.
16:09:09linuxstbBut 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:05linuxstbMy 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:09preglowbut i also get some strange lcd corruptions when using it...
16:10:13preglowso i might be doing something horribly wrong
16:10:38wackywould a donation for the iAudio cause help a bit for that project ?
16:10:48wackythat porting effort ?
16:14:54preglowwacky: well, no
16:15:04preglowwacky: the coder doing the port just vanished, and i have no idea why
16:15:11wackyaustriancoder ?
16:15:14preglowi don't think a donation will lure him back again, heh
16:15:16preglowwacky: yep
16:15:26wackyhe vanished a couple of months ago, didn't he ?
16:15:38amiconnlinuxstb: "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:47wackyyeah but I read on the forums that LinusN would like to have a broken iAudio.. so he could unsolder every pieces
16:16:36wackyso I guess.. funding would help buying a broken (or a new) iAudio ? wouldn't it ?
16:17:08wackybut 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:21preglowlinuxstb: this is interesting...
16:19:36preglowlinuxstb: a snprintf with no puts after it manages to distort all text
16:20:04linuxstbpreglow: Yes, that sounds like my old problem back again.
16:20:19preglowhow the hell can that be?
16:20:47Jungti1234good night
16:21:01linuxstbpreglow: I have absolutely no idea. There are no obvious buffer overflows that I could find.
16:21:10preglowi use snprintf, it can't overflow!
16:21:21Jungti1234good luck
16:22:08 Quit Jungti1234 ("Http://www.ZeroIRC.NET ¢Æ Zero IRC ¢Æ Ver 2.8")
16:28:11preglowi am completely dumbfounded
16:28:18preglowit's seems as if we write into the font buffer somehow
16:28:53linuxstbpreglow: You could try looking at my boot.lds and crt0.S code to see if that looks correct.
16:29:04preglowhmm
16:29:09preglowthe input button code actually works
16:29:18preglowat least one shot
16:30:37preglowi'll have a quick look at crt0.S
16:30:39preglowneed to go soon
16:33:11preglowcan't see anything totaly blatant
16:33:13preglowbut i have to go
16:33:14preglowbbl
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]Dragonhi
17:07:30[IDC]DragonSlasheri, do you read?
17:08:05Slasheri[IDC]Dragon: hi, i just came back home :)
17:08:31[IDC]DragonI'd like tohave a chat with you about flash booting
17:08:48Slasherithat sounds good :) lets do so
17:08:59[IDC]DragonI'd guess you could recycle a good part of what I did for Archos
17:09:08Slasheri[IDC]Dragon: what do you think about integrating your CFI code in plugins to core rockbox?
17:09:17Slasheripossibly :)
17:09:26[IDC]DragonCFI?
17:09:45Slasherithe (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:09SlasheriReadId, EraseSector, WriteByte etc.
17:10:17Slasherithen all plugins / rockbox core could use it
17:10:24[IDC]DragonI don't like it, becouse it's potentially hazardous code
17:10:32SlasheriHmm, true..
17:10:47[IDC]Dragonabout the boot:
17:11:02[IDC]Dragondid you do a cvs co flash?
17:11:19Slasherioh, i didn't :) i will try that
17:11:23[IDC]Dragonthat contains all my tools
17:11:33Slasherii didn't know that repository at all
17:11:34[IDC]Dragonfor firmware authoring, etc
17:11:41Slashericool :)
17:11:48Slasherii will check it
17:12:10[IDC]DragonI think the dual boot would be nice for iriver, too
17:12:25[IDC]Dragonwith compression, if you have to
17:12:25SlasheriHmm, so it could have two rockbox images?
17:12:39[IDC]Dragonor original and rockbox
17:12:39amiconnIn fact the iriver bootloader is what the combination of the archos flash bootloader+bootbox is
17:12:47Slasheri[IDC]Dragon: original firmware is too big
17:12:57[IDC]Dragoneven compressed?
17:13:07[IDC]Dragondid you try ucl on it?
17:13:09Slasherihmm, then we could load it from disk also..
17:13:22[IDC]Dragonno, the point is to have a backup
17:13:25amiconnThe iriver firmware copies itself to ram, but not as one continuous block afaik
17:13:46Slasheri[IDC]Dragon: i though something like having a bootloader at beginning of the flash and after that the firmware itself
17:13:55[IDC]Dragonok, then do it in chunks
17:13:59amiconn[IDC]Dragon: The iriver bootloader *is* the backup, as it includes bootbox functionality
17:14:28[IDC]Dragonant the uncompressed iriver fw, right?
17:14:32[IDC]Dragonand
17:14:41amiconn??
17:14:43Slasherino
17:14:52Slasheriit's just a plain bootloader.. quite small in size
17:15:07[IDC]Dragonloading rockbox or iriver from disk?
17:15:08amiconnWell, it's larger than archos bootbox+flash loader
17:15:14amiconnyes
17:15:29Slasheriless than 65 KiB
17:15:33Slasheri*4
17:15:38[IDC]Dragonthat bootloader is new, or has always been like this?
17:15:48*[IDC]Dragon is iriver-confused
17:15:48amiconnIt always has been like this
17:15:50Slasheri[IDC]Dragon: it has always been present in iriver
17:16:09amiconnThe iriver firmware runs from flash although it copies itself
17:16:31[IDC]DragonI thought you patch the original to attach a loader, then flash it
17:16:33Slasheriit's loacated at the end of the flash, starting at 0x1F0000
17:16:39amiconnThe bootloader 'hooks' into the boot process and either loads rockbox from disk, or passes control to the in-flash iriver firmware
17:16:53amiconn[IDC]Dragon: Yes, that's how it is done
17:17:10[IDC]Dragonso iriver is in flash, ok
17:17:32Slasheri[IDC]Dragon: iriver firmware is currently on the flash also but there is no reason to keep it there
17:17:35amiconnYes, but in order to have rockbox in flash, we need to ditch the iriver firmware, or compress it
17:17:55[IDC]Dragonwhat's the conceptual difference to my Archos-style booting then?
17:17:58Slasheriyep, the iriver fw takes almost all available flash space
17:18:20amiconn[IDC]Dragon: In fact none, only the components are named different
17:18:34Slasheriand if we compress it, we cannot run it directly from flash.. either we can rockbox
17:18:40Slasheribut uncompressed we can
17:19:05amiconnI 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:45amiconnSo we need no additional backup
17:20:19amiconnThe bootloader could simply be moved to the start of flash, and its defaults switched
17:21:00amiconnToday 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]Dragonif you want to bring rockbox in flash, you keep the "bootbox bootloader" and attach Rockbox
17:21:06Slasheriyep, that is what i had in mind
17:21:43Slasheriit could be patched to load from disk if user presses rec and automatically from flash
17:21:48[IDC]Dragonso you're close to having it like Archos with bootbox
17:22:03[IDC]Dragonneed a plugin to flash only the Rockbox part
17:22:40amiconnSlasheri: 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:49Slasherii 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:02Slasheriamiconn: true
17:23:14Slasheriamiconn: it doesn't have to init the kernel at all
17:23:26Slasherionly when user bypasses the process by pressing rec or usb connection is found
17:23:36amiconnyes
17:23:51amiconnIt should init the SDRAM though
17:24:11[IDC]Dragonor have a 1st level loader in front of it
17:24:22[IDC]Dragon(again like Archos)
17:24:24amiconnI 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]Dragonjust trying to keep Slasheri from re-inventig the wheel
17:25:53Slasheri[IDC]Dragon: i am not trying at least re-inventing anything.. I would use the flash functions already found in your code
17:26:20Slasheribut 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]Dragoncan Rockbox rolo the iriver firmware?
17:27:16amiconnno
17:27:18Slasherinot yet, but we think it should be possible
17:27:29amiconnThere is no disk-based version of the iriver firmware
17:27:41[IDC]Dragonok
17:28:04amiconnIt can rolo, but only rockbox.iriver versions
17:28:17amiconniriver-on-disk would need special handling
17:28:34[IDC]Dragonthe scattered loading?
17:29:01amiconnyes
17:29:14amiconnImho it's not worth it
17:29:25Slasheriamiconn: 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]Dragonwhat is *all plugins* ?
17:30:22[IDC]Dragonon the contrary, for Archos it's proposed to unite the 2 flash plugins
17:30:26Slasheri[IDC]Dragon: at least the firmware flashing plugins :) And then possible rockbox core
17:30:39[IDC]Dragonbut I coudn't find the time
17:31:08[IDC]Dragon(nowadays I flash my little home network components over the net)
17:31:26Slasherihehe
17:31:31 Quit _FireFly_ ("Leaving")
17:32:08 Join webguest64 [0] (n=52214ace@labb.contactor.se)
17:33:01Slasheriamiconn: 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:28amiconnThe plugin knows this the same way, as the plugins are built per platform
17:36:30[IDC]Dragonfor Archos, I introduced a "model ID" byte
17:36:49Slasheriamiconn: Hmm, so there is no possibility user could run a "wrong" plugin?
17:37:27[IDC]Dragonthe plugin reads it for some sanity checks
17:38:43[IDC]Dragonthere's different stages of checks: the plugin is built per model, checks that byte, the image has a CRC, etc
17:38:45amiconnIsn't he model id byte for checking whether the .bin file matches the platform?
17:38:57[IDC]Dragonyes
17:39:24[IDC]Dragonfor V1 recorder, that byte is 0
17:39:34[IDC]Dragonunfortunately, out of legacy
17:39:59[IDC]DragonI introduced the byte later, when supporting more models
17:40:24[IDC]Dragonthe byte is also 0 on all unflashed boxes
17:40:29amiconnYes, 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]Dragonyes, I stupidly changed that to 2.00 with my first images
17:41:41[IDC]DragonI went more modest later
17:42:20amiconnDon'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:37amiconnOn player we have to, but afaik we do it for all platforms
17:42:50[IDC]Dragonat least the mask, I'm not sure about the version right now
17:44:38[IDC]Dragonwe preserve mask for recorders, version for players
17:45:02[IDC]Dragonthe version is another key to model indentification
17:46:31 Part ep0ch_
17:48:08ripnetuk<LinusN> it's funny, we have this discussion with every new developer <−−- I remember my turn :)
17:49:18[IDC]Dragonwhich discussion?
17:50:34ripnetukif we should have malloc or not...
17:50:42[IDC]Dragonah
17:50:52ripnetukuntil 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]Dragononce 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:45amiconnurgl
17:51:54[IDC]Dragonovely complicated, I know
17:52:02[IDC]Dragonoverly
17:52:36ripnetukhaving a huge buffer only helps when you plan all tunes (up to buffer size) in the order they are in playlist
17:52:40ripnetukwhich I very rarely do
17:52:45amiconnI know that there are ways top make malloc() work somewhat better on mmu-less platforms, but it's still messy
17:53:10[IDC]Dragonlike constant-size lists?
17:53:28Slasheriit's not possible even in theory to use malloc, because we can't free the allocated memory
17:53:39[IDC]Dragonanyway
17:53:47Slasherior we can, but it would become segmented and is useless
17:53:50amiconnFirst, separating small and large mallocs
17:54:43amiconnYes, the best that can be done is reducing fragmentation, but it's impossible to completely avoid it
17:54:48ripnetukIts as bagder said - we have to have enough available for worst possible case, so we might as well be static
17:55:10ripnetukonly case it would help is where 2 different parts of code cannot run together (ie 2 plugings)
17:55:13ripnetukin which case, they can share a buffer
17:55:17ripnetuka static one htat is
17:55:33[IDC]Dragonyou can completely avoid it, but at the cost of high waste
17:55:36ripnetuki guess malloc only makes sense when we have practically unlimited ram (ie swap)
17:56:15amiconnIt would be prossible to do this if our platforms had a mmu
17:56:22[IDC]Dragonanother wild idea of mine was to use the memory as a general disk cache, with readahead when playing
17:56:23ripnetukbtw 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:47ripnetukusing the remote that is
17:56:47amiconnYes, that's because these requests are not yet adapted
17:57:02ripnetukok, known issue then
17:57:23amiconnThere'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:44ripnetukgotta 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:59Midgey34would anyone be able to help setup and build the sim on linux?
17:59:22linuxstbMidgey34: Which distribution are you using?
17:59:28Midgey34ubuntu
17:59:49linuxstbHow far have you got? Have you downloaded the rockbox source code?
17:59:52*[IDC]Dragon waves goodby, too
18:00
18:00:00Midgey34yes, I think I'm missing some of the x11 files needed
18:00:23 Quit [IDC]Dragon ("CGI:IRC")
18:00:29Midgey34screenhack.c:38:23: error: X11/Shell.h: No such file or directory
18:00:36Midgey34where would I find these files?
18:00:54linuxstbYou need to install the x11 development package(s) for ubuntu.
18:01:14Midgey34do you know the names of these packages? my synaptic is currently broken
18:01:27Midgey34apt-get works fine though
18:02:00crwlxlibs-dev is my guess
18:02:23linuxstbTry "dpkg -S Shell.h" - that should tell you which package includes that file.
18:02:36linuxstbIn my debian installation, it's "libxt-dev"
18:03:00crwlxlibs-dev includes lots of development libraries, like libxt-dev
18:03:36Midgey34well now the build gets further but I still some errors
18:03:58Midgey34CC screenhack.c
18:03:58Midgey34screenhack.c: In function ‘main’:
18:03:58Midgey34screenhack.c:509: warning: missing sentinel in function call
18:03:58DBUGEnqueued KICK Midgey34
18:03:58Midgey34screenhack.c:520: warning: missing sentinel in function call
18:03:58***Alert Mode level 1
18:03:58Midgey34screenhack.c:540: warning: missing sentinel in function call
18:06:08Midgey34make[1] /Desktop/rockbox-all/tools/convbdf: Command not found
18:06:24Midgey34make[1]: *** [/Desktop/rockbox-all/build-dir/firmware/sysfont.o] Error 127
18:06:28linuxstbYou need to type "make" inside that tools directory before you do anything else.
18:08:29Midgey34well it appears to be building correctly
18:09:39Midgey34alright, its built now, thanks for all the help
18:11:27Midgey34and 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:20muesli_-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:19pregloweh
19:19:26preglowsucky wather, i hates it
19:19:52preglowweather too
19:27:39linuxstbpreglow: 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:54preglowlinuxstb: 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:34linuxstbWindows 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:40preglowhahaha
19:40:08preglowit'll bet that routine repeats the next time you insert it as well
19:40:39linuxstbOf course it does.
19:41:07korpseand, needless to say, you can't tell it to shut up about how damn great USB2 ports are
19:41:51HClwhat version of windows do you use?
19:42:00HClmine just says "this device can operate faster"
19:42:06linuxstbThis 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:36korpseoh that's very nice
19:42:43korpseone for the history books
19:42:48linuxstbIt's XP. It's a PC in a client's office that I use sometimes.
19:43:04linuxstbI 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:19linuxstbHCl: 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:31preglowyou wont see me try to do ipod coding in windows again, that's for sue
19:47:32preglowsure
19:48:57crwli've seen *several* XP machines that didn't accept my H120 at all because they didn't have USB2 drivers installed
19:49:03crwl(echi or whatever it is)
19:49:09linuxstbI'm sure there must be a utility that can read/write from/to a raw disk under Windows.
19:49:34preglowwell, it's not cygwin dd at least
19:49:35preglowthat's for sure
19:50:13_FireFly_i know only one for floppy disks
19:50:31_FireFly_rawwrite or something similar
19:50:41preglowyeah, but that's strictly floppy, i believe
19:53:10linuxstbpreglow: Are you a delphi person?
19:53:40 Quit muesli_- (Read error: 110 (Connection timed out))
19:55:39preglowlinuxstb: nah
19:55:43preglowlinuxstb: been years since i did pascal
19:58:22linuxstbMust be thinking of someone else.
19:58:31linuxstbCan't find any useful looking Windows utilities.
19:58:54linuxstbBut the explore2fs project has a Delphi library for reading/writing to raw disks under all Windows versions.
19:59:08linuxstbSeems that it's not an easy thing to do.
20:00
20:00:49preglowsurprise
20:04:06 Join muesli_- [0] (i=muesli_t@A9394.a.pppool.de)
20:04:39linuxstbbbl.
20:04:44 Quit linuxstb ("Client Exiting")
20:08:14amiconnpreglow: 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:08amiconnApple doesn't adhere to the standard
20:10:31preglowi just don't see why it can't support it
20:10:33preglowno bother
20:10:44preglowthere is a partition entry
20:11:22amiconnYou can always use the disk device instead of the partition
20:11:31preglowdidn't work out
20:11:37preglowseems more like a windows limitation than anything else
20:11:43preglowahh, yes, like that
20:11:46preglowi was about to do that
20:11:59preglowwhen i noticed i could only do one 'dd' before i had to reconnect the ipod
20:12:04preglowafter that the device didn't work anymore
20:12:09amiconnraelly?
20:12:11preglowand that i was not about to endure
20:12:13preglowyes, really
20:12:21amiconnStrange...
20:12:41_FireFly_what had you done ??
20:12:48amiconnI was able to freely mix dd and normal accesses, as long as I didn't write with dd
20:12:50preglowand now itunes will be going
20:12:55preglowamiconn: this is ipod...
20:13:06amiconnThis is of course something that the windows file system doesn't notice
20:13:07preglowapple has probably somehow installed a nice device driver
20:13:32muesli_-ew
20:13:34muesli_-re#
20:13:36amiconnMe likes that the Ondio is plain usb msd
20:13:54preglowwell, the ipod is as well
20:13:59preglowbut there's something strange going on
20:14:02_FireFly_yeah it's easier to handle
20:14:10CtcpIgnored 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:14amiconnYou can check what driver windows uses for your ipod
20:15:25amiconn...and also whether write caching is enabled or disabled
20:16:30preglowdisabled
20:16:33preglowi had a check
20:16:40preglowwindows always disables caching for usb devices
20:16:43preglowright 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:59amiconnpreglow: Windows does not always disable caching for usb devices
20:21:39amiconnIt 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:53amiconnI 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:34preglowamiconn: 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:33pregloww00t
20:35:34 Quit justsomeperson (Client Quit)
20:35:40preglowi can use foobar to sync my ipod
20:35:58dpassen1foo_pod?
20:36:02preglowyes
20:36:18preglownow lets get rockbox on it as soon as possible so i wont have to endure this itunes db catastrophy any further
20:39:23amiconnmemcpy() is becoming a monster, but hopefully a really fast one :/
20:43:22preglowhehe
20:48:59SlasheriHmm, 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:09Slasheri+if
20:52:15Slasheriin theory we could use flash also to store dircache etc., but that might be not so useful to do
20:52:32Slasheriat least it has plenty of space to do so
20:54:17Slasheriat least it is possible to make iriver to boot without disk at all.. :D
20:54:29Slasheripreglow: 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:26preglowi'd like to use flash as much as we can
21:01:35preglowbut it might not be a good idea for everyone, of course
21:01:40 Join mongey [0] (n=53470b89@labb.contactor.se)
21:01:48preglowwith a couple of safeguards, i don't think you can go much wrong
21:02:12SlasheriHmm, then this sounds possible to me and i would like to do it.. But indeed, everybody wouldn't like it
21:02:31Slasheriyes, we would never touch the critical sectors
21:02:50 Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr)
21:03:17SlasheriStill 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:07DrMoossure I will love it to :)
21:04:09amiconnImho 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:29Slasheriamiconn: Ah, that is a good point
21:04:41amiconnThere's an additional point why flash routines in core are suboptimal - you can't use them when running from rom
21:05:03amiconnIn fact you can't flash at all when running from rom
21:05:12amiconnYou will have to rolo first
21:05:16Slasheriamiconn: Oh, really? :/
21:05:51amiconnOf course, if you switch the flash to programming mode the same time you're running from it ......
21:05:59Slasheriyes, that's true..
21:06:32Slasherithen we only have two options.. We can copy the code to ram on boot or not to use the flash while running
21:06:52amiconnThe 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:18preglowamiconn: i think that's kind of a moot point if the flash functions have builtin safeguards
21:07:28amiconni.e. between switching the flash to programming mode and switching back at the end, *no* core function must be called
21:07:32preglowbut of course, if you're really unlucky...
21:08:00Slasheriamiconn: or.. maybe we could put the flash functions to a different section so they are located on ram?
21:08:36amiconnOn 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:50amiconn...so the flash plugins load and flash in chunks
21:11:24Slasheriamiconn: 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:44SlasheriThat would prevent unwanted commands to flash if there would be some random jump to the code
21:12:06amiconnI still don't see the point of putting it in the core
21:12:34amiconnThere are only 2 plugins that use them, maybe just one.
21:12:44preglowwell
21:12:45SlasheriThe only point would be to use it to store different more static content to flash, such as dircache for example
21:12:47preglowif you want to save settings
21:14:30amiconndircache in flash is useless because of the same reason that renders a cache file useless
21:15:41amiconnThe only use I can think of is storing settings, but that's something I wouldn't do
21:16:37preglowuseless?
21:16:44preglowyou'd free up some memory by keeping it there :)
21:16:48preglowit is fairly static, after all
21:16:50amiconnHmm?
21:17:02amiconnYou have to scan at boot or after usb
21:17:17preglowyes
21:17:22preglowyou free ram by using flash
21:17:28amiconnNah
21:17:38preglowthe cache is fairly static, so could be kept in flash
21:17:44amiconnNow that would really wear the flash...
21:17:58amiconn...and you would have to put the code in ram instead
21:18:00 Join linuxstb [0] (n=5343d4aa@labb.contactor.se)
21:18:22preglowhow would that wear the flash any more than the config sector?
21:18:26preglowbeing kept there, that is
21:18:30preglowit doesn't change much more often
21:18:39amiconnIt does
21:18:42preglowput the code in ram instead?
21:18:43preglowwhy?
21:18:47preglowthe cache isn't big
21:19:09amiconnYou can't write to the flash when running code from it
21:19:15amiconnIt would crash immediately
21:19:33preglownot 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:42preglowno, of course not
21:19:59amiconnIn addition, writing to the flash is slow
21:20:05preglowstill not impossible!
21:20:10preglowbut yeah, starting to get convoluted
21:20:10amiconnThis 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:06Slasheriwe 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:25Slasheriamiconn: writing is slow? Doesn't seem that at least with my tests. Only erasing is slow
21:23:13amiconnIt is slow. Slow as hell compared to ram, even the iriver sdram
21:23:37Slasheriyes, of course..
21:23:42amiconnHow much did you write? The full 2 MB?
21:23:53Slasheribut that doesn't matter with dircache or config sectors for example
21:23:59SlasheriAlmost that, something like 1.8 MB
21:24:01amiconnit does
21:24:06SlasheriHmm
21:24:29amiconnEven a single added or removed dir entry might change the whole dircache
21:24:35amiconn(iiuc)
21:24:50Slasherionly if the cache gets fully rebuild
21:25:17amiconnyou need to sort somehow, right?
21:25:25Slasheribut we don't need to do the full rebuild from scratch always if we have free flash space
21:25:30Slasherino..
21:25:59Slasheribut of course, cache with _many_ deleted file entries could eventually get slower
21:27:09amiconnThe handling would also get rather complex, since you can only flash block-wise
21:27:32amiconnYou would need to buffer a block in ram, apply the changes, then flash back
21:27:35Slasheriamiconn: 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:57ep0ch_please dont put the cache in flash
21:28:00amiconnSlasheri: Yeah, but without erasing you can't set a bit from 0 to 1
21:28:07Slasherithe cache doesn't need erasing blocks.. they can be added to end of the cache
21:28:14Slasheriamiconn: yes and that wouldn't be necessary
21:28:30ep0ch_what if the cache is too big to go into flash?
21:28:34Slasheriwe will only set deleted file entries to 0
21:28:46amiconnA full rebuild does need erase
21:28:49Slasheriep0ch_: then it can go to disk.. but it must be huge for that
21:28:58Slasheriamiconn: not necessarely :)
21:29:08Slasheriwith current implementation it does but it's not necessary
21:29:23amiconnI'd rather put the codecs in flash than the dircache
21:29:32MoosSlasheri: me I love the idea of put the cache in flash :)
21:29:35preglowyes, agree about that
21:29:41Slasheritrue :)
21:29:52ep0ch_does the flash have a lifespan?
21:30:11Slasheriep0ch_: yes, 10k guaranteed cycles, and 100k typical (erases)
21:30:29_FireFly_every flash has a lifespan
21:31:05ep0ch_i dont like the idea of constants writes to flash, it should be a rare occurance imho
21:31:15ep0ch_constant
21:31:17Slasheribut you would need to change the flash contents very much to make it last less than say 5 years
21:31:49Moosyes 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:36preglownew wavpack
21:40:43 Quit Remo_ (Remote closed the connection)
21:41:49preglowdoesn't look like it means any changes for us
21:41:56preglowlinuxstb: 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:14linuxstbpreglow: I didn't finish working on it last night, and I probably won't have any time tonight to continue.
21:45:02linuxstbI think there are some endian problems. There is also no metadata parsing yet (in get_metadata)
21:45:20linuxstbI'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:02preglowlinuxstb: what, i thought it was submitted in working order
21:46:14preglowlinuxstb: no metadata parser is no crisis, it works without
21:46:27ep0ch_what are you working on amiconn?
21:46:37amiconnmemcpy()
21:46:48ep0ch_ooh for coldfire?
21:46:53amiconnyup
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:47ep0ch_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:37ep0ch_what's it do?
21:54:58_FireFly_it's displays the wps ;)
21:55:16ep0ch_:s
21:55:17_FireFly_it handles multiscreen-support
21:55:21ep0ch_ah
21:55:38 Join thegeek_ [0] (n=thegeek@s175a.studby.ntnu.no)
21:56:13ep0ch_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:56muesli_-amiconn http://www.misticriver.net/showthread.php?p=336055#post336055 do you know anything more?
21:57:20ep0ch_so it tries to use the same wps as the main screen?
21:57:31ep0ch_or hardcoded?
21:57:33_FireFly_no it uses the default one ;=
21:57:36ep0ch_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:33ep0ch_oh speaking of which, did the flac test without wps ever finish or is it still running :D
21:58:39ShanachieHello people, I'm interested in writing a feature for rockbox, any suggestions where to start?
21:58:46Shanachieis 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:24ep0ch_Shanachie: there are two at www.rockbox.org
21:59:30FebsShanachie: http://www.rockbox.org/mail/
22:00
22:00:16BirdFishIs 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:24muesli-Shanachie just about curiousity...was is it?
22:01:25muesli-;)
22:01:36 Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com)
22:01:50Shanachiepodcast support
22:02:03muesli-ah ok
22:02:08Shanachiesubsribed to rockbox-devel
22:02:25ShanachieI've posted some expl. in the forum
22:02:25ep0ch_? aren't podcasts just audio files?
22:02:53Shanachieyes, but they need to be maneged to really enjoy them
22:03:15_FireFly_a simple playlist should do it
22:03:23linuxstbSo when a podcast is downloaded, what information do you get with it. i.e. you download an mp3 file and ????
22:03:56ep0ch_i think i'll live in ignorance on this one
22:04:02 Quit korpse (Remote closed the connection)
22:04:11muesli-.za ?
22:04:36Shanachielinuxstb: maybe timecode info in the future
22:04:46 Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za)
22:04:56ep0ch_oh sounds like .cue files
22:04:59Shanachiethas what I'm pushing at the moment
22:05:32Shanachieep0ch_:or bookmarks like they exist now in RB
22:05:57linuxstbSo would a standard cuefile do the same thing?
22:06:20linuxstbLots of people would like cuefile support in Rockbox (including me)
22:06:26*amiconn thinks 'oh no!'
22:06:44linuxstb:) And some poeple don't.
22:06:50ep0ch_:)
22:06:57Shanachiedoes a cuefile have a description of the timecode?
22:07:06linuxstbYes.
22:07:19ep0ch_and tags
22:07:48Shanachiedoes it support a already played field?
22:08:25Shanachiebut a cuesheets point to file, not times right?
22:08:53Shanachiehttp://en.wikipedia.org/wiki/Cue_sheet#Example.2FTutorial apperantly I'm wrong :)
22:08:55ep0ch_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:36ep0ch_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:16ep0ch_:)
22:11:33ShanachieCuesheets seem to be focust towords music, and kind off overkill
22:11:59ShanachieI think I'll try a lighter kind of file format
22:12:14linuxstbBut 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:39Shanachielinuxstb: indeed
22:12:43linuxstbThe work is not in parsing the cuefile, it's in changing Rockbox to support the concept of tracks within a file.
22:12:44ep0ch_yes and you will make lots of friends if you support cuesheets :D
22:13:03Shanachiearen't you guys coders?
22:13:31ShanachieI'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:56Zagorpreglow: here?
22:18:59 Quit muesli_- (Read error: 110 (Connection timed out))
22:19:14preglowZagor: yup
22:20:00Zagorthese guys have ported doom to pretty much every ipod: http://idoom.hyarion.com
22:20:05 Quit korpse (Remote closed the connection)
22:20:07andyhm.. seams like talk_buffer_steal() doesnt work on iriver since mp3_play_stop() is a dummy?
22:20:09Zagorought 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:54Zagorit's based on ipodlinux, but appears to support more hardware than ipl
22:21:07andytrying to include iriver recording in normal recording screen
22:21:22linuxstbZagor: Do they use a graphics library like libsdl or opengl?
22:21:34preglowi'll have a look
22:21:40Zagori don't know, i just found the site a minute ago
22:21:49andyactually got it working now, need to clean up some loose ends before commit :)
22:22:21preglowandy: i think slasheri's done some work there as well
22:22:31*preglow produlates slasheri
22:22:55andyargh
22:23:17preglowZagor: man, i was planning to not install ipodlinux, but then i saw this...
22:23:43amiconnafaik talk_buffer_steal() doesn't need to do anything on iriver, because the talk buffer isn't shared
22:23:49muesli-this kicks ass
22:25:21andyamiconn: 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:39ep0ch|do they have the music working in doom?
22:25:46preglowep0ch|: doubt it...
22:25:55 Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za)
22:26:03muesli-the video doesnt thogh
22:26:07muesli-u
22:30:43linuxstbAnyone 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:28Zagorlinuxstb: 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:17crwlDOOM is licensed as GPL
22:34:23crwlthe data isn't
22:34:48linuxstbBut that's not a problem. Like every doom port, the WADs are never included.
22:34:58crwlyeah
22:35:07linuxstbcrwl: How do you know it's GPL?
22:35:16linuxstbThe source files in iDoom don't say GPL.
22:35:22crwlwhat's iDoom anyway?
22:36:02crwlit was first released with some odd licence, but later rereleased as GPL
22:36:06crwlnot too much later, in fact
22:36:28linuxstbiDoom 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:02crwli doubt that prboom for example would be included in Debian if it wasn't GPL or similar
22:37:31crwlyes, prboom definitely says it's GPL
22:37:37Zagorwikipedia does too
22:37:46preglowsomeone please tell me what is wrong with this bootloader
22:37:48preglowthis 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:16Zagorlinuxstb: since we can't ship the wads (graphics) anyway, I'd say a doom port is not as fun as it sounds
22:39:50Zagormy purpose in pointing out the project was rather that there may be useful information to be gleaned from the source
22:39:50linuxstbI'm not that interested anyway. Just curious if it was do-able.
22:40:12crwlyou can always link to the shareware .wad or something...
22:40:34linuxstbZagor. OK. But I don't think there is - it just seems to use the kernel drivers to access the hardware.
22:40:44ashridahcrwl: the shareware version isn't completely free either, fwiw
22:41:20Zagorlinuxstb: ok, i misunderstood then
22:41:29crwlashridah, well yes, you maybe can't distribute it yourself...
22:41:36ashridahcrwl: or modify it
22:41:49crwlwell, why would you need to do that?
22:41:53linuxstbThere is an lcd driver in it, but that's well documented in all the other parts of IPL.
22:42:07linuxstbI've just looked at it, and it doesn't seem to be anything different.
22:42:50ashridahcrwl: nevermind, misinterpreted your use of 'link'.
22:42:57crwland then there's http://freedoom.sourceforge.net/
22:43:11crwlbut 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:56andypreglow, 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:30preglowandy: i haven't done much yet :/
22:50:39preglowso, does anyone have a wad for this doom? :>
22:52:01Shanachiegoodnight people
22:52:13 Quit Shanachie (Remote closed the connection)
22:52:21linuxstbpreglow: http://debian.vinita.lt/debian/pool/non-free/d/doom-wad-shareware/ (maybe!)
22:53:05RotAtoRI'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:21crwlhum, did they really release firefox 1.5 today
22:58:19Zagorno
22:58:37_FireFly_a rc1
22:58:40ashridahhaven't seen any official mention of it, and my local mirror stilll only has 1.5rc's and betaws
22:58:42crwlwhy did my firefox claim it has downloaded an important update and asked to get restarted
22:58:46amiconnomfg I don't believe it :)
22:58:51crwland now it says it's firefox 1.5
22:58:58RotAtoRit's 1.5rc2, i think
22:59:01crwli was running 1.5 rc1 before
22:59:04amiconnThe memcpy() monster does indeed work, and it is faast
22:59:08crwlMozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
22:59:23ashridahcrash_: rc2 came out yesterday
22:59:40ashridahthey're probably intending to just be able to rename it if there aren't any showstoppers
22:59:52crwli 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:34RotAtoRcrwl: yep, they finally added binary patching
23:00:57crwlashridah, well, i'm running a self-downloaded version anyway... i installed it to my home directory
23:01:03Zagorashridah: your distro probably patches out that, or at least makes it optional if it isn't already
23:01:10crwlRotAtoR, ok, i think that's mostly cool
23:01:12 Join Strath [0] (n=mike@dpc674681214.direcpc.com)
23:01:19preglowlinuxstb: do you know if the boot partition always has to be the size it ships with?
23:02:13ashridahZagor: i daresay that would be about right.
23:02:23ashridahsuits me, since i don't really want firefox getting superuser privs :)
23:05:04ashridahstrange. 1.5rc2 only seems to be available as an update
23:05:11 Quit korpse (Remote closed the connection)
23:05:40RotAtoRor here: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5rc2/
23:06:53ashridahweird. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5rc2/ just had 'update' in it
23:07:30RotAtoRstrange, they must still be in the process of rolling it out
23:07:52ashridahyeah, don't know if ftp.mozilla.org roundrobins or something
23:07:58crwli wonder where my firefox got this update then :P
23:08:07 Quit _FireFly_ ("Leaving")
23:08:22ashridahcrwl: the update is available
23:08:34ashridahjust no standalone installer on the first mirror i tried
23:08:50crwlyep
23:09:28ashridahrofl. ftp.mozilla.org has 8 ip addresses :)
23:11:46linuxstbpreglow: No. IPL works by reducing the boot partition and inserting an ext3 partition in the empty space before the FAT32 partition.
23:12:09linuxstbIn your case, I think you reduce /dev/sdb1 to one cylinder.
23:13:03preglowlinuxstb: so the ext2 part HAS to be before tha fat32 one?
23:13:06linuxstbSo /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:41linuxstbI 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:45preglowcan i just use your bootloader for loading ipl, btw?
23:13:57linuxstbYes.
23:14:32preglowrockbox code is not bothered by multiple partitions? it'll just find the first fat32 one?
23:14:41linuxstbYes.
23:14:44preglowhow nice
23:14:49linuxstbYes.
23:16:33 Join webguest22 [0] (n=c76218bc@labb.contactor.se)
23:16:41linuxstbpreglow: 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:28preglowlinuxstb: just got done repartitioning it
23:18:47linuxstbpreglow: http://www.davechapman.f2s.com/rockbox/ipod_fs_170905.tar.gz
23:18:57linuxstbuntar that to your ext2 partition (after formatting it)
23:19:23linuxstbhttp://ipodlinux.org/builds is the place to get the kernel and the podzilla binary.
23:19:34linuxstbPut the kernel on your FAT32 partition as linux.bin
23:19:48linuxstbCopy podzilla into your ext2 /bin directory.
23:20:04preglowhahaha
23:20:12preglowfdisk and cfdisk segfaults when i try to start them now
23:20:25linuxstbFinal job is to edit the /etc/rc file in your ext2 partition to make sure podzilla is started.
23:21:20preglowseems i need to restart to make sure the partitioning went ok
23:21:37linuxstbYou should just need to unplug and reinsert your USB cable.
23:22:26preglowtried
23:22:56preglowthink it worked anyway
23:22:58preglowso i'll try
23:26:00andyhm.. 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:05preglowlinuxstb: hot diggety
23:30:06preglowit works
23:30:24preglowi appreciate the way podzilla never friggin turns on the backlight
23:30:57Bagderwhat's podzilla like otherwise?
23:31:21linuxstbIt's a clone of the Apple firmware - but with more options and a file browser.
23:31:25preglowa bit hard to say
23:31:30preglowsince i can't see it, and all
23:31:59linuxstbIt'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:29linuxstbSo I haven't really used it properly either.
23:34:17linuxstbpreglow: 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:20preglowgoing at it now
23:36:51preglowcopying idoom over to the ipod just seems to take... forever...
23:37:46preglowok, something funky is going on
23:38:01preglowa 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:08preglowok
23:41:10preglowi'm playing it
23:41:12preglowwith no backlight
23:42:47preglowhaha
23:42:54preglowgive me a backlight, and this will be pretty cool
23:43:08preglowi found backlight!
23:43:47crwldoes it play realtime speed?
23:43:50crwli suppose it does...
23:43:50solexx_you're might be wrong, you could've sworn you saq a light coming on...
23:44:21crwldoom 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:48andycrwl: probably 320x200 (mode 13) =)
23:44:59crwlandy, yes, but the screen size was changeable
23:45:04crwlit wasn't smooth at all in full screen
23:45:08preglowplays realtime, yes
23:45:17crwlyes, it probably should too :)
23:45:20preglowit's somewhat difficult to play on this screen
23:45:20preglowheh
23:45:21 Quit Febs ("CGI:IRC (EOF)")
23:46:14netmcp___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:32linuxstbpreglow: I've just installed it as well. Much fun.
23:47:25amiconncoldfire memcpy() is now >1300 bytes - oops!
23:47:50preglowamiconn: damn
23:47:59preglowamiconn: planning to put it in iram?
23:48:12amiconnmemcpy() has always been in iram
23:48:38Moosdo you know how much faster?
23:48:59preglowi need to get some kind of protective case for this thing
23:49:05preglownothing scratches as easily as an ipod
23:49:41netmcp___brasso makes it all better ^_^
23:50:51Jungti1234Who is a person who develop unicode rockbox?
23:51:05preglowmarkun and phaedrusxxx
23:51:10amiconnpreglow: Speed is 240%..950% of the C implementation
23:51:18amiconn(for large blocks)
23:51:28markunJungti1234: you know that, why do you ask?
23:51:47amiconnIt always uses burst reading and writing, that means there are 16 different loops
23:51:52Jungti1234Will not I receive file?
23:52:34 Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za)
23:53:13amiconnIt even isn't complete - a slight optimisation and a iram-destination check are still missing
23:53:58amiconnWhen 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:36preglowyes, i'd think so
23:55:02amiconnI 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:53Jungti1234Let's keep early hours. :)
23:56:19preglowlinuxstb: how do i access the fat32 part?
23:56:43preglowright
23:57:29amiconnHmmm :/
23:57:39 Quit korpse (Remote closed the connection)
23:58:00linuxstbpreglow: Have you found it?
23:58:04 Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za)
23:58:18Jungti1234bye
23:58:28 Quit Jungti1234 ("Bye Bye~ http://cafe.naver.com/iriverh300")

Previous day | Next day