--- Log for 20.10.108 Server: brown.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 15 days and 3 hours ago 00.01.20 # so i'm able to run the complete tutorial to get it to FAT32. But when I try to install after that using the program, i get the RW-error...When i replug the ipod, itunes gives a message to restore it, which is good i guess, since it is in fat32-structure. However, even after this replug and the shutting down of itunes, i get the same RW-error 00.01.49 # Going back a step, after you converted it to fat32, does the ipod work as normal? i.e. does the apple firmware still work? 00.02.11 # no, when i unplug it 00.02.16 # it says to connect it to a pc 00.02.25 # and then gives me the instruction to restore it, which i ofcourse don't do 00.03.05 # That's the first problem you have to solve 00.03.34 # Are you sure it's a "5g", and not the "5.5g" ? 00.03.37 Quit mcuelenaere () 00.04.01 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 00.04.09 Quit HBK (Read error: 110 (Connection timed out)) 00.04.25 # pretty sure yeah. No search function, and 512 byte sector 00.05.12 # OK, 512-byte sectors is the important point. 00.09.14 Quit bluebrother ("leaving") 00.14.49 # Argh! 00.14.54 # Any manual expert around? 00.15.38 # So, linuxstb, when i get it to fat32, my apple firmware should still be working? 00.16.11 # MelaGo: Yes 00.21.32 # not working...Keep on auto-getting it in disk mode and itunes telling me to restore it... 00.22.50 Quit jhulst (Read error: 110 (Connection timed out)) 00.24.12 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 00.24.45 Join markun [50] (n=markun@rockbox/developer/markun) 00.24.49 # MelaGo: And after you restore with itunes, it works normally? 00.24.55 # yes 00.25.46 # Can you describe the steps you are doing? Copy and paste any commands you're typing. 00.27.26 # ok 00.27.58 # i download the 00.27.58 # 30GB Video (512-byte sectors) mbr-video30gb.bin file and put it on my desktop 00.28.06 # open up terminal 00.28.13 # and disk utility 00.28.52 # check the disk-info in disk utility for the ipod, which is: disk2s3 00.29.03 # deactivate the ipod in disk utility 00.29.31 Quit Nibbl (Read error: 113 (No route to host)) 00.30.41 # type in terminal: dd if=/Users//Desktop/mbr-video30gb.bin of=/dev/disk2 00.30.55 # then i get: 1+0 records in 00.30.55 # 1+0 records out 00.30.55 # 512 bytes transferred in 2.509447 secs (204 bytes/sec) 00.31.33 # then type: newfs_msdos -F32 -v iPod /dev/rdisk2s2 to get it in fat32 00.31.51 # Do you remove the ipod between the those two steps? 00.31.58 # no 00.32.06 # I tried it once 00.32.11 # gave the same thing 00.32.14 # should i remove it? 00.33.06 # I can't remember - it seems other people have changed those instructions since I first wrote them. 00.33.59 # alright, so now when i go to disk utility 00.34.12 # No, it doesn't seem to be required to remove and reattach. 00.34.19 # i got my ipod with the name "disk2s2" still on deactivated mode 00.34.31 # structure is: MS-DOS (FAT32) 00.34.47 # now, in order to install rockbox with the program, I have to activate it 00.35.18 # I've no idea what that means - I never had to do anything else. 00.35.36 # If you now eject your ipod, does the Apple firmware work (do nothing else after the newfs_msdos command) 00.35.39 # well, when I'd go to rockbox utilty now, it wouldn't find the ipod 00.35.43 # since it's deactivated... 00.35.56 # it gives me an error...So I have to activate to get the program to locate it 00.36.08 # sec, i'll eject 00.36.20 # haven't run rockbox yet btw 00.36.43 # Yes, I know - you need to confirm you have a working winpod first. 00.36.49 # when i eject, it reboots and 00.36.55 # YES, it works on apple firmware 00.36.57 # normally 00.37.16 # when connecting it to itunes, it asks me to name it and all that... 00.37.45 # wow, and it got a windows structure too 00.37.48 # first time i see this 00.37.51 # alright, so what's next? 00.38.26 # now i have to run rockbox utility right? 00.38.28 # Simply run rockbox utility - it should work now. 00.39.53 Quit Tetracomm (Read error: 110 (Connection timed out)) 00.40.21 Join Tetracomm [0] (n=nicholas@72.252.29.2) 00.43.38 Quit bughunter2 ("bye") 00.43.44 Quit ender` (" Theorem: a cat has nine tails. Proof: No cat has eight tails. A cat has one tail more than no cat. Therefore, a cat") 00.45.17 Quit havien ("Konversation terminated!") 00.47.32 # * sarixe skdjf 00.48.24 Join havien [0] (n=none@68-189-143-101.dhcp.wlwl.wa.charter.com) 00.48.24 # * sarixe dies 00.49.31 Quit kharo (Read error: 60 (Operation timed out)) 00.51.57 # * sarixe hi 00.52.36 # alright, so i got a succesfull install of Rockbox, but another problem arises :p...When rebooting Rockbox, i get a "Can't load rockbox.ipod" on my screen... 00.54.35 Quit Schmogel (Read error: 104 (Connection reset by peer)) 00.57.29 # So it wasn't a successful install... 00.57.47 # Did you install both the bootloader and Rockbox itself? 00.57.58 Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 00.58.08 # in the Rockbox Utility which option did you use? I've heard that there unfortunately are still problems with the "Complete installation" from the "Quick start" tab on MacOS... 00.59.23 # used complete installation 00.59.26 Quit einhirn (Read error: 104 (Connection reset by peer)) 00.59.43 # so i'll manually install the bootloader and rockbox individually? 01.00.19 Join Munkie [0] (n=Alex@dsl-245-168-10.telkomadsl.co.za) 01.00.45 # where can i download plugins? 01.00.46 Join syn4pse [0] (n=chatzill@c-68-59-8-200.hsd1.sc.comcast.net) 01.01.07 # MelaGo: It looks like the bootloader install worked - you just need to install Rockbox itself. 01.01.24 # Munkie: All plugins are included with Rockbox. 01.01.40 # rockboxdev.sh is failing for me in 64bit ubuntu, any ideas? 01.01.46 # MelaGo: no, bootloader is already installed now (that's the one that put "Can't load..." on the screen). You should be able to just install the Rockbox build from the "Installation" tab in the utility (second option) 01.01.48 # i want to get the Gameboy emulator. it is not included 01.01.58 *** Saving seen data "./dancer.seen" 01.02.18 # Munkie: Yes it is - please read in the manual about how to use it (and also about "viewer" plugins) 01.02.24 # Munkie: the emulator itself is incuded 01.02.27 # specifically it won't compile the gcc cross compiler (arm), there is an error in the number of arguments in the script. 01.02.29 # k, i manually installed rockbox (second option in the utility), still get the same error... 01.02.31 # *included too 01.02.37 # thank you 01.02.38 # Munkie: Although what mp3 player are you using Rockbox on? 01.02.48 # "can't load rockbox.ipod 01.02.50 # file not found" 01.02.58 # ipod video 30gig 01.03.07 # even though install went perfect 01.03.08 # Munkie: Then yes, it's included. 01.03.55 # MelaGo: Maybe your ipod wasn't mounted - sometimes I experienced OS X leaving ghost "/Volumes/[ipod name]/" folders 01.04.01 # oh and is sound supported in doom? 01.04.32 # There are sound effects, but no background music. 01.04.38 # ok cool 01.05.35 # It says it's activated/mounted. Got it running in disk mode now right now 01.05.54 # However, when opening the ipod in Finder, I got no Rockbox directory, don't know if that's ok... 01.05.55 Quit culture (Connection timed out) 01.07.00 # MelaGo: It's ".rockbox" (note the dot) - which is hidden by default in Finder. You can check in the terminal by typing: ls -al "/Volumes/ipod name/" 01.07.40 # I know it's hidden 01.07.46 # I can see Hidden Files 01.07.50 # defaults write com.apple.finder AppleShowAllFiles TRUE 01.07.51 # killall Finder 01.08.02 # no Rockbox though... 01.08.42 # I've rewritten the archos flashing manual chapter. It would be nice if a native english speaker could have a look at it... 01.09.59 # MelaGo: OK. You could just install the rockbox.zip manually - download it from the website, and type "unzip rockbox.zip -d "/Volumes/ipod name/" 01.10.03 # amiconn: Sure 01.11.31 Join evilnick [0] (i=60e8ce0d@gateway/web/ajax/mibbit.com/x-af43661a2407ddc4) 01.11.50 # The relevant chapter is "Advanced Topics->Rockbox in Flash" in http://www.jens-arnold.net/Rockbox/rockbox-player-r18829M-081019.pdf http://www.jens-arnold.net/Rockbox/rockbox-recorder-r18829M-081019.pdf and http://www.jens-ondiofmarnold.net/Rockbox/rockbox--r18829M-081019.pdf 01.13.01 Quit linuxstb (Remote closed the connection) 01.13.16 # They're slightly different. There are also http://www.jens-arnold.net/Rockbox/rockbox-ondiosp-r18829M-081019.pdf and http://www.jens-arnold.net/Rockbox/rockbox-fmrecorder-r18829M-081019.pdf , but there are only there for completeness. They only contain the same text blocks as the first 3, just in partially different combinations 01.14.32 # Err, the Ondio FM link should be http://www.jens-arnold.net/Rockbox/rockbox-ondiofm-r18829M-081019.pdf of course 01.17.26 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 01.18.18 # Here's the diff as well: http://www.jens-arnold.net/Rockbox/archos_flashing.diff . Practically everything has changed though... 01.18.42 # OK, I think I'll just look at the PDFs... 01.22.32 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 01.22.59 Quit MelaGo () 01.25.23 Quit Thundercloud (Remote closed the connection) 01.25.48 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 01.26.33 Quit Thundercloud (Remote closed the connection) 01.26.41 Quit Nico_P (Remote closed the connection) 01.28.27 # amiconn: I would write "three to five" instead of "3..5", (I was always taught that digits less than 10 should be written as words). Also, you say "several", but then only list two reasons. You could rephrase it to say something like "The main reason to change this is to increase the startup time of your player. The Archos bootloader is rather slow, and by putting Rockbox in flash you can decrease the startup time to around three to f 01.28.27 # ive seconds. Furthermore, you..." 01.28.41 Join gartral [0] (n=Gareth@adsl-75-33-82-140.dsl.bcvloh.sbcglobal.net) 01.28.45 # (it also says "2 files" later on) 01.28.54 # There are 3 reasons when rombox is available, hence "several" 01.29.03 # good evening everyone 01.29.08 # (Player, Ondio SP) 01.29.17 Quit MethoS-- (Read error: 104 (Connection reset by peer)) 01.29.24 # I'll change the small numbers to works 01.30.15 Quit Munkie ("Leaving") 01.30.32 # amiconn: OK, but the manual I'm reading only lists two... (ondiofm) 01.30.33 # has anyone built and released an updated rbutil? my build system has a dead hard drive atm 01.31.21 # linuxstb: Yes, two or three, depending on the availability of rombox. 01.31.38 # "it’s gonna program" -> "it is going to program" 01.31.43 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 01.31.54 Quit syn4pse ("ChatZilla 0.9.83 [Firefox 3.0.3/2008101315]") 01.32.13 # That was laziness... (reusing parts of the old text) thanks. 01.32.34 # has anyone built and released an updated rbutil? my build system has a dead hard drive at the moment 01.35.09 # linuxstb: Hmm, *increase* startup time? That would be a reason against changing it ;) 01.35.29 # amiconn: Just testing that you're still awake... 01.35.35 # hehe 01.35.47 # (i'm obviously not) 01.36.55 # lol, nvm me, i was blind and wasnt reading the "b" above the 1.0 entry in the rbutil page 01.37.17 # (gives everyone a fresh hot cup of coffee) 01.37.59 # linuxstb: how did you calculate the codec memory usage for flac? 01.38.11 # just dig through the map looking for the largest addresses? 01.38.13 # saratoga: I just manually looked at the .map 01.39.06 # amiconn: No more comments on the ondiofm manual - it reads fine to me. 01.41.27 Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 01.41.28 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.41.36 # amiconn: Recorder manual seems fine. 01.43.25 # amiconn: Player seems fine as well. 01.43.46 # * amiconn found a grammar mistake in the extra Ondio warning for Ondio SP 01.44.13 Part gartral 01.45.07 # amiconn: "These versions..." ? 01.45.14 # yep 01.45.44 # I had a mini-\opt there, but this was obviously not enough 01.45.48 # And "they are" in the next sentence. 01.46.26 # yup 01.46.35 # Is it possible to detect Archos fw versions? Maybe with a crc? 01.46.49 # You mean in RoLo? 01.47.08 # I guess I do... 01.49.42 # Doesn't look like it 01.49.47 # is there a "no plugins" make option ? It'd be nice to not have to wait for them to build and then copy over 01.50.14 # Well, a crc might work, but then the rockbox binary would need to know these "bad" CRCs 01.50.36 # saratoga: 'make bin' 01.50.36 # saratoga: "make bin" 01.50.53 # * linuxstb lost by a microsecond... 01.50.55 # amiconn won ;) 01.51.10 # * pixelma loses 01.51.22 # saratoga: "make help" should show you the options 01.51.45 # ok thanks 01.52.06 # faad only mallocs 36KB for me on a 3 minute AAC-LC file 01.52.27 # linuxstb: If rockbox wouldn't have grown so big, we could have used the size. The flash-update archos firmwares are significantly larger than the normal on-disk firmware files. But rockbox is now closer in size to the bad ones... 01.52.27 # faad or the mp4 parser? 01.52.32 # linuxstb: any idea how much of that e200v2 code works? does it build a working bin at all? 01.53.13 # JdGordon: It compiles.. But it's still very incomplete - someone (maybe me...) needs to finish reading an OF disassembly and implementing the funcitons. 01.53.37 # The CRC method may be an idea for the RoLo rework 01.53.40 # * amiconn sighs 01.53.53 # linuxstb: 36KB is as large as the mem_ptr in the malloc buffer gets 01.54.24 # i just edited the malloc,calloc,realloc functions to print the mem_ptr whenever they're called and started playing files 01.55.46 Join [i][B][e][n] [0] (n=Bensawso@unaffiliated/bensawsome) 01.56.13 # I wouldn't call 36KB "only" - it should grow linearly with the size of the mp4 file. So a 30-minute file would be 360KB, and a 2-hour file would be trouble... 01.58.29 # i still don't understand why such large seek tables are needed for MP4 01.59.04 # i started looking through the mp4 specs, but the format is surprisingly complicated 02.00.29 # You're surprised an MPEG standard is complex? ;) 02.01.43 # linuxstb: I've now committed the reworked flashing chapter. Thanks for checking! 02.01.54 # You're welcome. 02.02.00 # are these mallocs used for the life of the track? 02.02.34 # * amiconn will commit it (with an extra remark regarding the 8MB mod) to the 3.0 branch tomorrow, for building the 3.0.1 manuals 02.03.03 # JdGordon: Yes, I'm pretty sure they all will be. 02.03.08 # JdGordon: most of them are seek tables which could be needed whenever someone seeks, the rest are maybe 16KB or so of internal decoder buffers 02.03.47 # does ogg not malloc? 02.04.50 # if the seektables arnt available it can stll seek? it just has to do alot of extra work? 02.05.26 # ah Ogg duplicates the codeclib malloc functions 02.05.34 # how handy 02.06.28 # Well, ogg does this for a reason, iirc 02.06.31 Quit kharo (Read error: 110 (Connection timed out)) 02.06.51 # tomal implemented a malloc in the codec ram for ogg, in order to make it work on the iFP 02.07.08 # The iFP doesn't have enough ram for the extra malloc buffer 02.07.18 # JdGordon: I've been trying to figure that out 02.07.27 # * amiconn guesses that with today's change, no codec would work anymore on the iFP 02.08.34 Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 02.09.09 Quit sarixe (Read error: 110 (Connection timed out)) 02.11.59 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 02.13.29 # amiconn: Today's commit was a synced version of a patch by tomal 02.13.52 # I doubt he increased the codec buffer to 1MB though 02.14.14 # No, but the point is that it's now a unified buffer - that's what tomal wanted. 02.14.49 # Yes, but 1MB would be too big for the iFP, the same way as 512KB codec buffer + 512KB malloc buffer are too big 02.15.09 # Yes, but I'm sure it's not 1MB there 02.16.00 # Prior to today's commit, the codec malloc function only used the 512KB malloc buffer - as far as I could see, the unused part of the codec buffer was never used. 02.16.47 # Tomal's patch means that malloc uses the codec buffer - which we increased (for now) to 1MB on the large-mem targets, and got rid of the malloc buffer. 02.20.57 Join axionix_ [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) 02.25.12 # saratoga: IIRC, the information about the duration and sizes of frames is stored in the STTS chunk. Looking at the ALAC codec (alac.c), the decode_frame() function doesn't return a "bytes_consumed" value - that's taken from the STTS chunk. AAC also uses the STTS chunk values when decoding frames. 02.25.20 # So there are two issues - 1) Can the decoding happen without the info in the STTS chunk; 2) How do we seek without it? 02.25.37 Join webguest21 [0] (n=18aaaecf@gateway/web/cgi-irc/labb.contactor.se/x-a9b5e3a6cf35043b) 02.27.26 # linuxstb: its hard to imagine they require you to have a huge lookup table to seek through an audio file 02.27.35 # perhaps some of the atoms in the stream have time stamps or something similar 02.28.36 Quit webguest21 (Client Quit) 02.30.31 Join webguest44 [0] (n=18aaaecf@gateway/web/cgi-irc/labb.contactor.se/x-98012389bc7dbf8a) 02.31.09 Quit webguest44 (Client Quit) 02.31.48 Quit axionix (Read error: 110 (Connection timed out)) 02.32.28 Quit kachna (Read error: 113 (No route to host)) 02.44.34 # linuxstb: Actually an .ajz file has both its size and a checksum (no real crc, just a sum) in the header 02.45.51 # So checking both should be sufficient for detecting the bad archos firmwares. Problem is how to detect whether rockbox is flashed or not... 02.51.44 Quit Tetracomm (Read error: 104 (Connection reset by peer)) 02.52.53 # amiconn: That makes that part easy - and I see those values are already read by rolo... 02.53.29 Join Tetracomm [0] (n=nicholas@72.252.29.2) 02.55.57 Part pixelma 02.56.22 Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) 03.02.01 *** Saving seen data "./dancer.seen" 03.09.56 Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) 03.17.50 Quit [i][B][e][n] (Read error: 104 (Connection reset by peer)) 03.17.51 Join Bensawesome [0] (n=Bensawso@unaffiliated/bensawsome) 03.18.56 Quit saratoga ("CGI:IRC (EOF)") 03.20.23 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 03.20.39 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-b61d1122c4de7d6f) 03.21.00 Join reacocard [0] (n=reacocar@134.173.59.155) 03.25.26 Quit Bensawesome (Read error: 104 (Connection reset by peer)) 03.25.58 Join Bensawesome [0] (n=Bensawso@unaffiliated/bensawsome) 03.30.40 Quit soap (Remote closed the connection) 03.40.11 Quit intrados (Connection timed out) 03.40.17 Join soap [50] (n=soap@rockbox/staff/soap) 03.41.42 Nick Bensawesome is now known as [i][B][e][n] (n=Bensawso@unaffiliated/bensawsome) 03.42.26 Quit axionix_ (Read error: 104 (Connection reset by peer)) 03.44.51 Quit Tetracomm ("Visit: www.kompulsa.com") 03.46.54 Join EspeonEefi [0] (i=espeonee@STRATTON-SIXTY-EIGHT.MIT.EDU) 03.49.39 Quit [i][B][e][n] ("t3h 1337 h4X0R sT4t80t h42 QuiT") 03.51.49 Quit DerDome (Nick collision from services.) 03.51.50 Join DerDome1 [0] (n=DerDome@dslb-082-083-247-154.pools.arcor-ip.net) 03.52.02 Nick DerDome1 is now known as DerDome (n=DerDome@dslb-082-083-247-154.pools.arcor-ip.net) 03.52.18 Quit Strife89 ("Leaving") 03.59.18 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-5298bca6f9389c0f) 04.19.49 Nick HBK- is now known as HBK (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 04.20.47 Join blkhawk- [0] (i=HydraIRC@g227066226.adsl.alicedsl.de) 04.23.46 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 04.29.06 Join kharo1 [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 04.29.35 Join miepchen^schlaf [0] (n=miepchen@p579ECEC0.dip.t-dialin.net) 04.30.22 Quit Kopfgeldjaeger (Read error: 104 (Connection reset by peer)) 04.35.19 Quit miepchen^schlaf_ (Connection timed out) 04.36.24 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.38.10 Quit blkhawk (Read error: 110 (Connection timed out)) 04.41.05 Quit kharo (Read error: 110 (Connection timed out)) 04.49.08 Quit obo ("bye") 04.57.31 Join gkffjcs [0] (n=john-cha@131.156.249.167) 04.57.43 Quit JdGordon ("Konversation terminated!") 04.59.01 # If I make a playlist on my ipod, under rock box, how do I save it? I get to the nameing dialog, and then give it a name, but then I cannot save it, there is no option to save, and all the buttons just return me to the previous menus. 04.59.54 Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) 05.00.36 # the manual should go into this... 05.00.45 Quit mc2739 () 05.02.05 *** Saving seen data "./dancer.seen" 05.04.08 Join rocky_ba [0] (i=74e1722a@gateway/web/ajax/mibbit.com/x-7aa91f46b227afa4) 05.04.10 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 05.10.28 # gkffjcs: PLAY/PAUSE confirms those naming dialogs. 05.10.32 Join Tetracomm [0] (n=nicholas@72.252.29.2) 05.12.04 Part toffe82 05.12.14 Part mc2739 05.12.49 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 05.13.06 Join someone972 [0] (n=someone9@VDSL-151-118-8-114.DNVR.QWEST.NET) 05.13.49 Quit mc2739 () 05.14.22 Quit someone972 (Client Quit) 05.17.54 Part rocky_ba 05.18.11 Quit Tetracomm (Read error: 104 (Connection reset by peer)) 05.24.19 Join devslashnull [0] (n=delvslas@pool-71-104-116-13.lsanca.dsl-w.verizon.net) 05.25.38 Quit devslashnull (Client Quit) 05.25.56 Join devslashnull [0] (n=delvslas@pool-71-104-116-13.lsanca.dsl-w.verizon.net) 05.26.08 # thank you cool_walking_ 05.28.59 # gkffjcs: More info: http://download.rockbox.org/manual/rockbox-ipodvideo/rockbox-buildch4.html#x7-430004.1.3 05.29.03 Nick blkhawk- is now known as blkhawk (i=HydraIRC@g227066226.adsl.alicedsl.de) 05.29.21 Quit devslashnull (Client Quit) 05.35.33 Quit HBK () 05.35.39 Join HBK [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 05.40.18 # JdGordon: ping 05.46.46 # hey 05.50.02 # Just updated the scroll padding patch 05.50.12 # wow I feel stupid that I didn't think of prefix/suffix 05.50.44 Quit Horscht ("User was distributing pornography on server; system seized by FBI") 05.50.53 # after hours fighting to handle properly quotes and strings the solution was much more simple 05.50.54 # thanks 05.51.44 # hehe, sorry i didnt tihnk of it sooner also :p 05.52.15 # also about the length of the padding. 10-20 can be quite small for large screens with small fonts 05.52.26 # that's why I ended up on LCD_WIDTH / 4 05.53.01 # also it muches the logic of scroll_engine.h (before the patch) 05.53.02 # yeah, but if they are all spaces then its very obvious where the line ends anyway 05.53.18 # muches = matches 05.54.20 # SCROLL_LINE_SIZE is defined by LCD_WIDTH even if the array holds characters and not pixels 05.54.36 # by the way why is this array so big, I didn't have to change it and the padding still fits 05.57.56 # my logic is that on a huge screen (say ipod 5.5) LCD_WIDTH / 4 is 60 characters, which on all fonts will cover the extreme preferrence of one whole screen of padding. 05.58.31 # of course hardcoding to 60 characters won't make sense for ondio which will need quite fewer characters to fill in the screen 05.58.47 # which array is that? 05.58.55 # SCROLL_LINE_SIZE..? 05.59.14 # in scroll_engine.h scroll_info.line 05.59.41 # thats not the array to hold the full text of the line being scrolled is it? 06.00.42 # yes that's it 06.01.05 # that array is then put on the screen with a different offset (scrolling mechanism) 06.01.07 # then it needs to be at least MAX_PATH long 06.01.39 # yeah and it needs another half screen for the next append of the string 06.01.40 # oh, or it is the subpart of the string being displayed? 06.01.53 # the part I don't get is the 3*LCD_WIDTH/2 06.01.58 # and without the /2 for the player 06.02.09 # * JdGordon doesnt know this code much 06.02.10 # JdGordon: AFAIU is the whole string 06.02.24 Quit Seed ("cu, Andre") 06.02.31 # ... im also in windows atm so dont even have the code here 06.02.34 # lemme reboot.... 06.02.46 Quit JdGordon (Read error: 54 (Connection reset by peer)) 06.05.17 Join JdGordon [0] (n=jonno@c211-28-145-137.smelb2.vic.optusnet.com.au) 06.05.20 Quit HellDragon (Client Quit) 06.05.25 # the scrolling mechanism takes that string and types it to the screen with an offset (and that is how scrolling is achieved) 06.06.21 # JdGordon: so it is the full string plus half of the screen which some part of the string is reappended to make scrolling look normal 06.06.36 # * JdGordon wonders if scrolling could be redone with viewports so we could use a pixel spacing between start and end 06.11.38 # speaking of : 06.11.41 # ern 06.11.49 # darn keyboard 06.11.56 # anyway... 06.14.25 # JdGordon: the first version of the patch pads spaces calculated from pixels/font width 06.14.49 # but then some people said that the best would be for the user to select its own padding string 06.15.08 # yeah, I sort of followed the discussoin 06.15.28 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 06.16.18 # so what do you think, is it commitable? Any more comments? 06.18.23 # ... by overkill I meant that its wasting too much space... imo adding any more than half a dozen spaces doesnt make it any *more* readable... so having such a high limit is a waste 06.19.32 # Well, I for one, like at least half the screen with spaces. So I took as base the extreme of one screen (beyond that it isn't visible) 06.19.35 # but apart from that it looks ok 06.22.14 # okay then if you think it is good to go and you are comfortable with commiting it I would be glad. Right now though I have to go to sleep. Thanks for the tip again. :) 06.25.29 Quit Zarggg () 06.28.12 Quit XavierGr () 06.29.05 Join intrados [0] (n=intrados@rdrt-164-107-204-170.resnet.ohio-state.edu) 06.36.34 Join kushal_12_27_200 [0] (n=kushal@12.169.180.178) 06.41.00 Join Tetracomm [0] (n=nicholas@72.252.29.2) 07.02.09 *** Saving seen data "./dancer.seen" 07.28.57 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 07.36.17 Quit BHSPitMonkey (Remote closed the connection) 07.38.31 Quit nelek ("shutdown -h 0") 07.43.59 Quit n17ikh|Lappy () 07.44.37 Join HBK- [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 07.46.18 Quit Tetracomm ("Visit: www.kompulsa.com") 07.52.00 Join num1 [0] (n=brian@unaffiliated/num1) 07.53.19 Quit miepchen^schlaf () 07.57.22 Nick num1 is now known as num1_ (n=brian@unaffiliated/num1) 08.01.54 Quit HBK (Read error: 110 (Connection timed out)) 08.03.27 Quit kushal_12_27_200 ("Leaving") 08.03.47 Quit DerDome ("Leaving.") 08.05.29 Quit BigBambi (Remote closed the connection) 08.06.50 Join goffa [0] (n=goffa@216.220.23.105) 08.07.48 Quit agaffney (Read error: 104 (Connection reset by peer)) 08.13.47 Quit joe2371 (Remote closed the connection) 08.14.02 Join joe2371 [0] (n=joe@c-69-138-250-166.hsd1.md.comcast.net) 08.14.16 Quit bmbl (Read error: 104 (Connection reset by peer)) 08.15.18 Join Zagor [0] (n=bjorn@82.99.7.155) 08.16.09 Join agaffney [0] (n=agaffney@gentoo/developer/pdpc.active.agaffney) 08.19.34 Quit goffa_ (Read error: 110 (Connection timed out)) 08.27.41 Quit jhulst (Remote closed the connection) 08.29.00 Join Rob2223 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 08.34.35 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 08.44.21 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.47.44 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.48.55 Quit GodEater ("http://www.mibbit.com ajax IRC Client") 08.56.16 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 08.56.39 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 08.57.56 Quit advcomp2019 (Read error: 104 (Connection reset by peer)) 08.58.47 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 09.02.14 *** Saving seen data "./dancer.seen" 09.02.49 Join reacocard_ [0] (n=reacocar@WL-48.CINE.HMC.Edu) 09.06.39 Join lasser [0] (n=chatzill@W92b1.w.pppool.de) 09.06.58 Join petur [50] (n=petur@rockbox/developer/petur) 09.08.32 Quit reacocard (Read error: 110 (Connection timed out)) 09.14.56 Nick reacocard_ is now known as reacocard (n=reacocar@WL-48.CINE.HMC.Edu) 09.23.03 Quit Bagder (Read error: 110 (Connection timed out)) 09.23.48 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 09.26.50 Quit pixelma2 ("-") 09.26.56 Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) 09.29.47 Quit joe2371 ("Lost terminal") 09.32.15 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 09.46.36 Join Nibbl [0] (n=Nibbler@e181108183.adsl.alicedsl.de) 09.50.26 Quit JdGordon ("Konversation terminated!") 09.53.40 Quit kachna (Read error: 113 (No route to host)) 10.07.47 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 10.11.32 Join MethoS [0] (n=clemens@dyndsl-085-016-164-116.ewe-ip-backbone.de) 10.13.24 Join Slack_ [0] (n=brett@12-218-63-169.client.mchsi.com) 10.22.32 Quit MethoS (Read error: 104 (Connection reset by peer)) 10.27.54 Quit Thundercloud (Remote closed the connection) 10.44.17 Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-01e46139ed5493ac) 10.51.06 Quit reacocard (Read error: 104 (Connection reset by peer)) 10.52.13 Join kachna [0] (n=kachna@r3g248.net.upc.cz) 10.52.24 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 10.52.34 Quit nuonguy ("This computer has gone to sleep") 10.54.56 Quit Slack_ ("Ex-Chat") 11.02.15 *** Saving seen data "./dancer.seen" 11.11.21 # with _some_ targets getting a 3.0.1 the download/release page gets a bit tricky 11.11.29 # I mean, how to write on it to describe the situation 11.12.44 # do we even have to? 11.13.05 Quit culture (Connection timed out) 11.13.26 # I think so, since the users who experienced problems with 3.0 might want to know that it is now 3.0.1 11.14.56 # Probably too late to suggest this, but couldn't we just bump every target to 3.0.1 and have a changelog showing what changed - i.e. that it is only different to 3.0 for certain devices. 11.15.20 # we can still do that, if that's what we really want 11.15.28 # "UPDATE: An update, version 3.0.1, has been released to fix problems with xxx and yy on targets zzz and nnn." 11.15.43 # uh double update looks a bit silly, but you get the idea 11.16.04 # i would rather have that than "why havent you guys released 3.0.1 for my ipod yet? I dont want to be behind!" 11.16.08 # I think that's the best plan 11.16.34 # scorche: well the other side of that coin is "what is the difference between 3.0 and 3.0.1?" 11.16.53 # Zagor: The answer is a link to the changelog 11.16.54 # Zagor: and the changelog or notice should take care of that 11.16.59 # or worse: "3.0.1 sounds much worse than 3.0 on my ipod. can I have 3.0 back please?" 11.17.04 # haha 11.17.17 # can't wait to get one of those ;) 11.22.21 Quit kachna (Read error: 110 (Connection timed out)) 11.23.08 Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 11.24.50 Quit kharo1 (Read error: 110 (Connection timed out)) 11.24.51 # both sound like a BoS anyways... 11.29.11 # http://daniel.haxx.se/blog/2007/10/01/rockbox-on-dell-digital-jukebox/#comment-1016 11.29.30 # some people also obviously believe in secret development somewhere not publicly visible... 11.31.23 # B4gder: As can be seen by how many people thought 3.0, the first time, was gonna have a bunch of new features. 11.31.32 # yeah 11.31.57 # I guess I just never really learn to expect this 11.37.43 # Well, I think part of it is that people expect it to be similar to some other softwares (take GCC) where you have the 3.x and the 4.x branches. 11.38.06 # So when we did Rockbox 3.0 they expected all the previous versions had been on the 2.5 branch, and maybe they just didn't know where to get 3.x test builds. 11.38.45 # Lots of projects do that though - have a "new features" branch. 11.38.51 # yeah 11.39.24 # Maybe we should call "trunk" the "3.1" branch to make it clearer. 11.40.31 Join vitja_ [0] (n=vitja@79.120.98.174) 11.53.56 Join balou_ [0] (i=balou@cl-1844.ham-01.de.sixxs.net) 11.53.59 # hi 11.55.21 # is there a hw platform that is currently sold which is supported by rockbox? 11.55.54 # ipods don't work anymore, i dunno when iriver quit producing its players, and many other players seem to only work in older releases... 11.56.00 # nope :( 11.56.16 # but there is work in progress on several current models 11.56.18 # balou_: only used/refurbished ones 11.57.42 # balou_: if you're in the US, you can get rockbox-compatible sansas from ... uh what are they called again? 11.58.06 # froobi 11.58.07 # balou_: What do you mean, only seem to work in older releases? 11.58.10 # yeah.. but ipod videos are getting scarcer and scarcer 11.58.13 # scorche: ah, thanks 11.58.21 # amiconn, old hardware revisions 11.58.31 # btw, I'm not in the us 11.58.32 # balou_: There are many better devices for Rockbox than the ipod video 11.59.18 # what would you suggest? 11.59.33 # rockbox.org/wiki/BuyersGuide perhaps? 11.59.36 # If you want a hard-disk player, then the Gigabeat F is very good value. 12.01.11 # B4gder, good link :) 12.01.40 # * Zagor removes the "available" column 12.02.27 # It's a pity... I think there _would_ be a market for dap with flac support and for example digital output 12.02.50 # I just update unifont: "As of 20 June 2008 (by coincidence the Summer Solstice), the GNU Unifont has a glyph for every printable code point in the Unicode Basic Multilingual Plane (BMP)" 12.02.51 # it just seems that no manufacturer got that yet... 12.03.36 # balou_: the iriver h1xx has digital out 12.04.53 # and with rockbox it plays back flac of course 12.05.08 # I know, but that player has been out of production for a few years now 12.05.38 # That shouldn't stop you buying it if it has the features you want. 12.07.10 # balou_: and if you want to do some DIY work you could probably make a digital-out for the Gigabeat F dock connector :) (it has the I2S signal) 12.08.17 # sure, but I'd still like a brand new digital-out sporting rockbox-by-default hires display player more than an old player bought off ebay 12.08.20 # ;) 12.08.58 # sadly no such thing exists - so you have to compromise 12.10.18 # ...or petition a big dap manufacturer 12.10.36 # petitions dont work 12.10.36 # good luck with that 12.11.00 # I'm sure they just hadn't thought about it so a quick call will fix it 12.11.32 # balou_: Have you found such a device at all? i.e. one without Rockbox support? 12.12.09 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 12.12.38 # linuxstb, no, except if you count portable dvd players with digital out 12.12.41 Join DerPapst [0] (n=DerPapst@dhcp-25-203.fh-friedberg.de) 12.12.59 # linuxstb: according to this the Cowon Q5 will http://www.head-fi.org/forums/f15/portable-sources-w-digital-output-listing-255819/ 12.13.03 # we don't count them 12.13.38 Join moos [0] (i=moos@81-66-141-133.rev.numericable.fr) 12.14.49 # markun: Hmm, a 5" LCD makes it hard to think of it as a portable audio player... 12.14.57 # wow... a new dap that will actually have digital out 12.15.04 # 5"! 12.15.14 # http://www.purelygadgets.co.uk/showproduct.php?prodid=14963&wysiwyg=10 12.15.42 # Anyone know what an "Alchemy" processor is? 12.15.53 # markun: That was a bad commit... 12.16.05 # amiconn: what happened? 12.16.07 # * linuxstb googles and sees it's a MIPS based CPU 12.16.08 Join BigBambi [0] (i=86ceaf40@rockbox/staff/BigBambi) 12.16.09 # okay... a bit big.. 12.16.28 # markun: Check the revision log: http://svn.rockbox.org/viewvc.cgi/trunk/fonts/16-GNU-Unifont.bdf?view=log r18342... 12.16.34 Join M0rtus [0] (n=chatzill@87-194-163-210.bethere.co.uk) 12.16.55 # Unifont *was* already updated to 20080820, but with the unnecessary junk stripped, which you now re-added 12.16.59 # funny how the MIPS arch seems to still survive 12.17.15 # amiconn: oops, sorry :( 12.17.35 # I'll revert at once 12.17.36 # Q5 is claimed to run windwos CE too 12.17.51 # So it's a tablet computer... 12.18.28 # yes, with wifi and all 12.18.29 # ugh... 12.19.01 # quite an n810 competitor I'd say 12.19.17 # * linuxstb wonders if we'll ever see hard-disk based portable _audio_ players again... 12.19.38 # amiconn: I just noticed that it had more glyps. I'll be more careful next time. 12.21.10 # hello all 12.21.12 # Sure it had more glyphs than our version... but only ones which you'll never get to see for any valid unicode text. I took 20080820 and stripped those, using a perl script 12.24.29 # guys im a right in thinking that the USB does nothing on the sansa still? 12.24.48 # It should restart to the Sansa firmware 12.24.52 # And then connect 12.26.09 # emphasis on "should" 12.26.33 # * ameyer glares at whatever build server is screwing up portalplayer builds 12.28.44 # last time i tried rockbox it did just that........... and then would go back to rockbox without a reinstall :( 12.28.56 # eh? 12.29.04 # ameyer: what do you mean? 12.29.32 # M0rtus: It should reboot to the Sansa firmware to let you copy files, then when you restart, start Rockbox like normal 12.30.21 # might give it another try............ last time it would restart to sansa f/w then copy files......... reboot and sansa firmware still. 12.30.37 # That shouldn't happen 12.31.01 # Another way is to boot to the Sansa firmware, then insert USB (manual tells you how to dual boot), or plug in USB from off 12.31.18 # there's a bug with the automatic reboot though that appears in one build and vanishes in the next, but you can always get the OF for USB by either plugging from off state or start the OF manually 12.31.30 # I mean some official builds freeze on usb connect but I've never had a build I built myself that didn't restart to OF on usb connect 12.32.13 # And you have verified that all the non-working ones come from the same build server? 12.32.22 # I 12.32.24 # erm 12.32.37 # I'm not entirely sure how I'd do that 12.32.52 # On the build details page you can see which server built which build 12.32.59 # Otherwise it is pure speculation 12.33.21 # ameyer: http://build.rockbox.org/dev.cgi 12.36.42 # amiconn: git really doesn't like these big file commits :( 12.39.35 # the current mini2g build seems to have the issue 12.39.56 # assuming the ipod reboot failure is the same as the sansa reboot failure 12.40.11 # OK, so note down which build server and then try the next few as well to see if it correlates 12.40.20 # ameyer: Can you compile that same mini2g build yourself, and test that? 12.40.30 # Front page still needs fixed to explicitly mention that Rockbox does not work on the 4th gen Nano. 12.40.30 # I've experienced myself that using a downloaded build had the problem while compiling my own from the same revision did not. I didn't think it's a buildserver's fault, more like memory alignment or what's it called 12.40.50 # linuxstb: sure 12.41.26 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 12.41.28 # pixelma: But you've also experienced the problem with builds you've compiled yourself? i.e. some of your own builds work, some don't? 12.41.46 # reason: I have the problem on my c200 with self-compiled... yes 12.44.26 # erm, false alarm on the mini2g, it works right now 12.44.46 # hmm 12.44.55 # what's the reason for the codec memory rearrangement? 12.45.41 # preglow: IMO it's cleaner, and hopefully will mean we can reduce the combined size. 12.45.46 Part M0rtus 12.46.10 # IIUC, prior to that commit, the unused part of the main codec buffer remained unused. 12.48.36 # is it in any way possible the sansa charging patch could fix the mystery sansa usb reboot issue? 12.49.05 # (and adds a nasty 100% reproducible stkov) 12.49.28 # linuxstb: but the total amount, which is the same, still remaions unused... 12.49.32 Join J-23 [0] (n=kvirc@a105.net128.okay.pl) 12.49.40 # well, not unused 12.49.42 # but occupied 12.50.00 # i hate that malloc buffer, so few codecs now need it 12.50.10 # because that could also explain why my builds always seem to work 12.50.29 # erm, seem to always work 12.53.04 # preglow: I agree - but technically there is now no longer a malloc buffer, just the unused part of the codec buffer. So if we can reduce the amount of malloc'ing the guilty codecs do, we can easily reduce that buffer size. 12.53.31 # i.e. this is just the first step to reducing the memory usage of codecs 12.54.00 # preglow: I have started a wiki page on this topic here if you have time to contribute - http://www.rockbox.org/twiki/bin/view/Main/CodecMemoryUsage 12.54.49 Quit DerPapst (Read error: 104 (Connection reset by peer)) 12.54.57 # ameyer: Ah, so you run patched builds? 12.57.20 # just the sansa charging patch 12.58.23 # though, that shouldn't affect the mini2g builds, and I *think* that I've seen official builds work and my build not work on the same revision 12.58.28 # linuxstb: ah, i actually collected some data on this, i'll try to update it today 12.58.57 # B4gder: Would you be interested in writing a script to analyse the codec .map files and output the memory usage (code, rodata, bss, icode, irodata, ibss) ? I'm guessing (hoping) it's similar to what you've done for the main builds... 13.00.16 Join kachna [0] (n=kachna@r3g248.net.upc.cz) 13.01.14 # yeah, that would be awesome, the wiki data would be out of date really fast... 13.01.59 # that's a good idea, I'll look into it 13.02.20 *** Saving seen data "./dancer.seen" 13.04.04 # preglow: What are the problem codecs? IIUC, mp4 codecs have problems with the seektable info, and Tremor needs to allocate (and init) some large lookup tables, especially for floor0 files. Are there any others? 13.05.01 # * ameyer wonders how well flake -12 files would work on rockbox 13.05.50 # * scorche didnt know we had a codec for flake 13.05.52 # ameyer: The Rockbox flac decoder only supports the "flac subset" - I've no idea what "flake -12" produces. The main issue is the maximum frame size is something like 4608 samples. 13.06.11 # scorche: It's a third-party flac encoder 13.06.32 # maximum frame size could be an issue 13.06.35 # oh... 13.09.47 # linuxstb: vorbis is the major one, afaik 13.09.56 # linuxstb: and it's hard to work around, the codec has very few hard limits 13.10.07 # apparently at higher compression levels it uses 16k blocks, whatever that means. 13.10.16 # but of course, only way to handle it is to find the common limits used in encoders and hard code for that 13.10.41 # bah 13.10.52 # even the flac author himself says higher block sizes seldom matters 13.11.13 # ameyer: That's probably not going to work then - it increases the memory requirements for decoding, meaning those buffers could no longer be in the fast IRAM 13.11.26 # (which is why Rockbox limits to the subset) 13.11.57 # makes sense 13.12.52 # and i really don't think we should fix that 13.12.56 # I can't recall anyone ever complaining either, which would seem to prove that non-subset files are very rare in reality. 13.13.07 # codec authors should be aware that there are limits, if they want portable playback 13.13.31 # s/codec authors/encoder authors/ 13.14.27 # linuxstb: and lossless/lossless transcoding isn't as big of a deal as lossy/lossy 13.14.39 # ameyer: Indeed. 13.15.11 # afaik, Trent Reznor is the only person who actually uses flake 13.15.43 # It could be interesting to port it to Rockbox - I'm sure it's far more understandable than libFLAC... 13.16.00 # But IIRC, it uses floating point... 13.16.53 # well, so does flac, for lpc afaik 13.17.04 # Hmm, variable block size encoding sounds interesting... (reading the flake hompage...) 13.18.14 # sounds like a weird lossless encoder feature 13.18.40 # hard to imagine why you would want to use shorter blocks, unless there is some kind of switchable mode 13.19.55 # linuxstb: i'll update the wiki with my malloc findings right now, some of it might be inaccurate (don't think it is, tho...), but it beats nothing 13.20.07 # flake seems to use block size of 4608 in all of its presets (at least --help of flake 0.11 indicates that) 13.20.24 # er, 4608 or lower 13.23.02 # linuxstb: didn't ape use to malloc a seek table? 13.24.41 # erm, what I said about Trent Reznor apparently isn't true 13.24.50 # anyway... 13.26.48 # preglow: Ah yes, it does... 13.26.55 # I have 0.10 and flake claims to onlu use up to 4608 13.28.00 # does? i couldn't find it :/ 13.28.04 # preglow: I don't remember the details, but I expect that can be changed to a sensible sized static buffer, similar to FLAC. I'll investigate. 13.28.18 # It's in apps/codecs/demac/libdemac/ 13.28.43 # oh, there's another dir in there... 13.28.58 # btw, is it "malloc free" or "malloc-free"? as in free of mallocs 13.29.40 # I meant to say it there is no use of malloc or free. 13.30.10 # preglow: flake -h shows a table with equivalent command lines for -0 through -12 13.30.12 # oh, i meant which of the two alternatives are correct english :P 13.30.53 # preglow: Probably best to just say "Does not use malloc"... 13.31.12 Join LambdaCalculus37 [0] (n=LambdaCa@nmd.sbx09467.newyony.wayport.net) 13.31.14 # yeah, but i'm curious now :) 13.31.29 # I would use a hyphen, but I don't know if that's correct. 13.35.54 Quit kachna (Read error: 110 (Connection timed out)) 13.36.25 # linuxstb: i'll just put in entries for all the codecs that don't use malloc. they'll have to be added anyway 13.41.04 # preglow: So AAC itself uses malloc, in addition to the mp4 parser? 13.41.23 # linuxstb: it allocates buffers all over the place 13.41.32 # linuxstb: asf doesn't touch any malloc, no? 13.41.44 # As far as I can remember, no. 13.42.22 # faad mallocs a lot in ifdef places, and i can't really see which we use 13.42.29 # needs to be clarified anyway 13.42.37 # Do speex and vorbis share an ogg parser? 13.42.46 # don't think so 13.43.03 # ogg can be handled free of mallocs, but i think it requires some api changes 13.43.14 # libogg2 is supposed to deal with that 13.43.25 # Does that exist? 13.44.16 Join legendsohai [0] (n=legendso@219.93.152.34) 13.44.18 # in some form, yeah 13.44.26 # i believe tremor uses an early version of it 13.44.30 Quit moos ("Rockbox rules the DAP world") 13.44.53 Join pvbcharon [0] (n=charon@62.225.173.228) 13.45.37 # The whole Ogg thing seems such a mess... 13.45.49 # yeah... 13.49.10 # what codecs use libm4a? aac? alac? 13.49.38 Join nplus [0] (n=nplus@141.25.Globcom.Net) 13.50.00 # how do i make subheadings? how do i link to one? don't have much time, or i'd read up... 13.51.29 # More "+" signs for subheadings 13.51.47 # Yes, aac and alac are the only mp4/m4a codecs 13.53.00 Quit LambdaCalculus37 ("Ka-chunka") 13.53.45 Quit Nibbl (Read error: 110 (Connection timed out)) 13.56.44 Join HBK [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 13.57.17 # http://pastebin.com/m15a0ec79 13.57.23 # my first codec size overview 13.57.30 # from an X5 build 13.58.16 Part legendsohai 13.58.45 # bah, can't make anchors work 13.59.12 # B4gder: looks sweet 13.59.38 # B4gder: Interesting - looks like nothing is anywhere near the 512KB limit... 13.59.46 # indeed 13.59.49 # malloc use hides a bit 14.00.05 # a fair bit, in the case of vorbis and aac 14.00.40 Quit HBK- (Read error: 60 (Operation timed out)) 14.00.47 # Yes, but that's always been in the separate malloc buffer. 14.01.17 # oh yeah, just meant to say it isn't a good way to see what memory the codecs do need 14.02.06 # * linuxstb wonders how that info can be presented for the various architectures in a useful way... 14.02.25 # there's a lot of numbers... 14.02.33 # B4gder: Is const data included anywhere in those numbers? 14.02.57 # argh, isn't using anchors just going like [[#AnchorName][link here] and then putting #AnchorName in the spot you want to link to? 14.03.08 # const would be rodata won't it? 14.03.21 # yea 14.03.50 # linuxstb: each codec entry would probably just have a bunch of links to files that get updated per target per build? 14.04.13 # right, rodata is part of the Text size in that table I believe 14.04.14 # only way i can see it work and still be updated automatically 14.04.54 # Maybe the whole page needs to be generated dynamically, and include some kind of figure (or textual description) for malloc usage (taken from a static file) 14.05.51 # linuxstb: Do all malloc()s in question never free() before the codec exits? 14.06.14 # I think the entire malloc buffer is reset after each track. 14.06.17 # amiconn: we purge the malloc buffer after each track 14.06.19 # i.e. there's no free() 14.06.23 # so it doesn't matter 14.06.23 # If there are some free() calls, it _might_ help to implement a proper free() 14.06.42 # ...e.g. dbestfit or whatever that's called 14.06.50 # it _might_ help to implement a proper "malloc" too, but let's just remove the mallocs instead shall we? :) 14.07.16 # * B4gder is on the remove-them train 14.07.34 # * linuxstb lives on no-malloc street 14.07.36 # That would be much preferred. The question is whether it's possible without a major rewriet of the codecs in question. 14.08.17 # true 14.08.25 # i think it would be very possible 14.08.38 # i do not believe the codecs to malloc/free on a per frame basis, it's all init/deinit 14.08.57 # so we purely need to find the static limits that would work, for some codecs this is easy (aac), for some it is hard (vorbis) 14.10.26 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-3ebcce34ffe45c91) 14.10.44 Join Schmogel [0] (n=Miranda@p3EE21CBB.dip0.t-ipconnect.de) 14.11.43 # I committed tools/codecscan.pl now 14.13.04 # \o/ 14.13.54 Nick GodEater is now known as Goodie_Godeater (i=c2cbc962@gateway/web/ajax/mibbit.com/x-01e46139ed5493ac) 14.14.18 Nick Goodie_Godeater is now known as GodEater (i=c2cbc962@gateway/web/ajax/mibbit.com/x-01e46139ed5493ac) 14.15.20 # If anyone is interested - results for an ipod build (minus the encoders) - http://pastebin.com/mbe902de 14.16.21 # We should have a wiki page for that information. 14.17.08 # LambdaCalculus37: It would be better to generate it from the builds, rather than put it statically in the wiki. But see http://www.rockbox.org/twiki/bin/view/Main/CodecMemoryUsage 14.17.40 # linuxstb: Are your results for iPods in general, or any specific iPod? 14.18.03 # It's the ipod color build. I don't know if the codecs make use of the extra iram on nano/video... 14.18.05 # * GodEater guesses for the photo 14.18.24 # * LambdaCalculus37 will get some results later on 14.18.31 # i was about to ask about that, should we create them for all builds, or just find which targets share the same? 14.18.39 # i guess the last would require maintainance, but be preferable 14.19.18 # preglow: Is there a reason speex uses very little IRAM? it looks like lots of code could go there (if it helps...) 14.19.52 # Also, it seems like the entire wavpack codec (code and bss) could fit in IRAM... 14.20.33 # in general iram usage seem somewhat low 14.20.56 # linuxstb: speex just doesn't need much working ram, and yeah, speex is a work in progress 14.21.12 # preglow: I was thinking of icode 14.21.22 # i know, just saying that's the reason it uses little iram 14.21.42 # stuffing code in iram is always good, and can come up with some candidates for stuffing 14.21.43 # OK - I was just wondering if you had tested and found it to not be useful. 14.21.46 # but need to go soon 14.22.01 Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) 14.22.09 Quit amiconn (Nick collision from services.) 14.22.15 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 14.22.21 # speex too will probably fit nicely (at least the parts that matter) in iram 14.23.55 # * linuxstb wonders what causes wma to use so much bss 14.24.20 # linuxstb: But SPC uses even more BSS. 14.24.56 # 338784 for SPC versus 149056 for WMA... those are the highest two in terms of BSS usage. 14.24.57 # Isn't that an emulator format though? Meaning it's probably the RAM of the target device? 14.25.38 # linuxstb: Yes, it's an emulation of the SPC700 chip in the Super NES. 14.26.17 # http://snesmusic.org/files/spc_file_format.txt 14.41.22 Join tvelocity [0] (n=tony@gw1.mycosmos.gr) 15.02.24 *** Saving seen data "./dancer.seen" 15.06.32 Join pierre- [0] (n=pierre@89.179.94.138) 15.10.45 Quit Schmogel (Read error: 104 (Connection reset by peer)) 15.11.08 Join Schmogel [0] (n=Miranda@p3EE21CBB.dip0.t-ipconnect.de) 15.11.09 # ^^ 15.12.00 # does that mean anything? 15.12.38 Join Yskyflyer [0] (n=chatzill@ool-435787e5.dyn.optonline.net) 15.13.10 Quit Yskyflyer (Client Quit) 15.15.15 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 15.15.16 Join evilnick_ [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-6791dfff6c639fd3) 15.22.02 Join lol3izer [0] (n=lol3izer@72.2.63.189) 15.24.54 Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 15.45.55 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 15.53.33 # the d2 manual isn't working yet is it? 15.53.36 Join Nibbl [0] (n=Nibbler@e181103125.adsl.alicedsl.de) 15.54.27 # * B4gder read the dev ML post 15.54.56 # B4gder: I don't think there's any reference or any work done on a D2 manual. 15.55.39 # * B4gder tries it 15.55.53 # File `platform/cowond2.tex' not found. 15.56.01 # Aha! 16.04.24 Join hogeh- [0] (n=chatzill@ku38.opt2.point.ne.jp) 16.08.00 # the d2 isn't released yet too, right? 16.08.24 # * bluebrother checks 16.08.46 # it's not "supported" at all, no 16.09.19 # The m3 is missing a manual too... 16.09.45 # yep. IIRC there was still this issue with the m3 not having a main remote 16.10.08 # * bluebrother spots that this "don't show metadata lines without info" has a read bin delta :( 16.10.11 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 16.10.22 # So less is more... 16.10.46 # :( 16.11.10 # me never was annoyed by those empty lines 16.12.16 # thus I never saw a point in removing those 16.12.55 # Isn't it also useful to know what you're missing? 16.13.31 # well, my files are usually well tagged, but for some fields I have no use. Still it's useful to see those fields IMO 16.13.45 # where have you been yesterday? ;) 16.14.10 # * bluebrother scratches head 16.15.24 # I have no too strong feelings about showing or hiding empty fields (though it smells kinda like dynamic menus, and we don't want those ...) but if it's a red bin delta I kinda dislike hiding them 16.15.28 # * linuxstb reads the logs... 16.15.44 # pixelma: I was there, but missed it. JdGordon kept the discussion brief... 16.17.11 # I almost never use that screen anyway,, so don't really mind. But IMO the desired behaviour is debatable, so should have been debated... 16.17.31 # well, I didn't have too strong arguments and time to discuss (was shortly before lunch break) 16.18.15 Quit vitja_ (Remote closed the connection) 16.20.12 # * bluebrother agrees with linuxstb 16.20.30 Quit blahrus (Read error: 104 (Connection reset by peer)) 16.23.08 Quit Seed ("cu, Andre") 16.26.11 Join blahrus [0] (n=blahrus@75.150.209.185) 16.28.05 Quit EspeonEefi ("さよなら") 16.29.17 # bluebrother: what's your preffered "fixed" length about 9455? Because as I see it, it would need a big value to please all habits. 16.29.36 Quit pvbcharon () 16.30.15 # and as I comment, 32 bytes is not something that large-screen targets miss. 16.34.20 # XavierGr: well, to have a "good" spacing, especially if you use something different than spaces, 5 would be enough IMO -- something like the "+++" winamp uses is the usual thing I could think about 16.34.55 # and for spaces, well ... if you have 5 user characters and add a space in front and after them you can get to up to 7 spaces. Shouldn't that be enough? 16.36.04 # bluebrother: but thats why this became an issue. Some need a larger padding string. 16.36.39 # I am ok for a fixed value as long it is big to please all, but then small screens will just waste memory 16.36.54 # one could argue about 7 user defineable characters. But everything else is quite special-case IMO. And we can't care for every special case like people wanting the complete line as padding 16.37.40 # IMO the number of characters doesn't make much of a difference for the screen size -- on small screens you usually will use a much smaller font, so the number of characters isn't too different 16.38.33 # people repeatedly complained about rockfont on larger screens, so anyone using small fonts on a large screen can be considered a special case. IMHO :) 16.38.58 # of course that's why I am still arguing about it, array[30] from array[LCD_WIDTH / 4] is not more complex but still you get something more for only some bytes 16.39.35 # or save something more for smaller screens 16.39.56 Quit Nibbl (Read error: 113 (No route to host)) 16.39.58 # well, I don't see a point why larger screens should require more *characters*. 16.40.06 # because if it is done as a setting to only increase the space from 3 - 7 then it is a waste 16.40.24 Join PaulJam [0] (i=PaulJam_@vpn-3096.gwdg.de) 16.40.44 # well, with that setting you can include other characters, so this definitely makes things more flexible 16.41.20 # with that arguing you could consider the whole thing a waste on players with small targets if LCD_WIDTH / 4 comes around as something like 7 ... 16.42.03 # hmm, while thinking about it ... how making it part of the wps? I.e. define the scrolling line including the padding? 16.42.31 # that way one could even use different padding strings depending on tag / subline / whatever 16.42.35 # my idea first, was to achieve something like iriver scrolling which shows an empty screen at the end of scrolling, using a large pad and a big step size I get this. At the expense of 30-40 bytes 16.42.57 Join Nibbl [0] (n=Nibbler@e181103125.adsl.alicedsl.de) 16.43.12 # bluebrother: it is working on wps too, or do you mean as a tag? 16.43.19 # I mean as tag. 16.43.35 # something like %scroll(%artist +++ ) 16.43.45 # sorry for the pseudo-wps-code ... 16.44.02 # but what about the file browser? or you mean haveing both? 16.44.17 # never thought of lists -- is it really that of an issue there? 16.44.28 # but having both could be confusing 16.44.31 # hmm 16.44.32 # I might use such a feature in the wps but definitely not in lists 16.44.36 # Does FS#9455 currently affect all scrolling - i.e. in list (file) browser and WPS? 16.44.45 # yes 16.45.56 # And the binsize increase is still almost 1KB? (I see 848 bytes quoted for an earlier version of the patch on h300) 16.46.02 # * bluebrother points out that he usually uses settings sane enough to rarely require scrolling -- slow lcds make scrolling a pain 16.46.16 # linuxstb: nope it should be rather small now 16.46.19 # I should check 16.46.29 # * XavierGr checks 16.46.37 # why are you guys so obsessed with binsize? 16.47.06 # lol3izer: because more RAM for buffering means less disc spinups. Less disc spinups mean longer battery runtime 16.47.27 # but a few K 16.47.29 # is nothing 16.47.30 # and if we didn't care about it the binary would explode rather quickly. 16.47.39 # ah 16.47.43 # lol3izer: Every single K counts. 16.47.43 # I've seen this at work ... 16.47.53 Quit Zagor ("Client exiting") 16.48.12 # every byte counts ;-) 16.48.19 # lol3izer: Various reasons. Avoid inefficient code, avoid overly-complicated code, avoid feature bloat 16.48.43 # now consider some of the old targets (archos) and never targets have not much RAM, 1MB or even less 16.49.19 # that's not much given the fact that we need codecs, filesytem access, a customizable UI, ... 16.49.37 # The Archos targets have only 2MB of RAM; some like the iFP-7xx, Clip, m200 and others have even less. 16.49.39 # and we do want to use RAM for buffering ... 16.50.07 # ah, right, the archos were 2MB. Still not much 16.50.39 # Hi, it looks like test_codec is broken in current SVN. (probably related to the changes in r18834) 16.50.54 # PaulJam: Which target did you try it on? 16.51.00 # H300 16.51.10 # it doesn't compile 16.52.01 # test_codec.c:430: error: structure has no member named `get_codec_memory' 16.52.16 Join {phoenix} [0] (n=dirk@p54B474BF.dip.t-dialin.net) 16.52.50 # linuxstb: it dropped to 700 for H300. I hoped for something more 16.53.26 # * bluebrother starts to kinda like the idea of padding in the wps tags 16.54.35 # strnage... since you were the father of the previous idea 16.54.37 # why? You can just add your "padding string" as plain text in the WPS 16.55.04 # hmm indeed 16.55.24 # XavierGr: why? I just expanded that idea ;-) 16.56.13 # hehe. But indeed in wps you can alter the scrolling line with any text string you like 16.56.27 # PaulJam: I expect you just need to rename it to codec_get_buffer() 16.56.34 # the line in general though, not the "scrolling" per se 16.56.36 # is this already possible? Not really sure about that 16.57.03 # PaulJam: I'll test and commit, thanks for reporting. 16.57.06 # bluebrother: yeah you can insert any text you like before and after, though it will appear even if the line isn't scrolling 16.57.29 # linuxstb: ok, thanks. i wasn't sure, because the commit message sounded as if there were functional changes too. 16.57.35 # well, then this isn't what I've thought. 16.59.53 # it is quite similar though 17.00.41 # true 17.02.26 *** Saving seen data "./dancer.seen" 17.04.39 Part hogeh- 17.06.05 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 17.10.45 # PaulJam: A quick fix is possible, but I think test_codec needs more changes to accurately emulate the new way codecs use memory. So I'll leave it for now... 17.11.01 # PaulJam: But if you need to use it, the search/replace I suggested should work. 17.12.39 # linuxstb: i don't need test_codec. i just had it enabled in my build, so i noticed it. 17.19.07 Join Arathis [0] (n=doerk@p508A3AA3.dip.t-dialin.net) 17.19.57 Join bughunter2 [0] (n=Jelle@77.164.66.126) 17.21.01 Quit bughunter2 (Client Quit) 17.21.47 Join bughunter2 [0] (n=Jelle@77.164.66.126) 17.24.33 Join n1s [0] (n=nils@rockbox/developer/n1s) 17.24.50 Part johwil 17.25.47 Quit sarixe (Remote closed the connection) 17.26.21 Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) 17.28.55 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 17.42.18 Join Hillshum [0] (n=chatzill@75-165-224-4.slkc.qwest.net) 17.42.43 Quit BigBambi ("http://www.mibbit.com ajax IRC Client") 17.52.46 Quit evilnick_ ("http://www.mibbit.com ajax IRC Client") 18.00.18 Quit Rob2223 (Read error: 104 (Connection reset by peer)) 18.07.12 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 18.09.12 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.09.43 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 18.10.22 Quit domonoky (Client Quit) 18.10.50 Quit petur ("work->home") 18.11.44 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.12.47 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 18.12.51 Part B4gder 18.14.45 Quit robin0800 (Remote closed the connection) 18.15.25 Join funman [0] (n=fun@86.219.29.237) 18.18.49 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 18.20.57 # isn't this test run automatically on each commit (on the builders) ? 18.21.46 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 18.23.43 Join Tetracomm [0] (n=nicholas@72.252.29.2) 18.24.12 Quit rvvs89 (Read error: 60 (Operation timed out)) 18.25.23 Join lol3izer_ [0] (n=lol3izer@72.2.63.189) 18.25.35 Quit Arathis ("Bye, bye") 18.25.45 Join rvvs89 [0] (n=rvvs89@martello.ucc.gu.uwa.edu.au) 18.26.05 # test_codec is a plugin which is not part of the downloadable builds (hence not tested if it still builds) 18.29.36 # ah I thought it was a kind of test suite runnable on the build host 18.30.28 Join miepchen^schlaf [0] (n=miepchen@p579ECEC0.dip.t-dialin.net) 18.30.51 # test_codec is a plugin to test codecs (especially decoding speed) on target.. 18.31.42 Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 18.32.07 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 18.32.40 Nick Bagder_ is now known as Bagder (n=daniel@1-1-5-26a.hud.sth.bostream.se) 18.32.46 # excuse me I never used rockbox ;) 18.33.08 # funman: You're excused. :) 18.36.38 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 18.41.35 Join stoffel_ [0] (n=sfr@p57B4E535.dip.t-dialin.net) 18.42.55 Quit lol3izer_ () 18.43.32 Quit lol3izer (Connection timed out) 18.46.14 # is the m200v2 supposed to embed SDRAM ? 18.46.31 # the memory setup routines are 100% identical between Clip & M200 18.47.18 Quit miepchen^schlaf () 18.47.32 # and read timings from uninitialized stack apparently :'( 18.48.37 Join miepchen^schlaf [0] (n=miepchen@p579ECEC0.dip.t-dialin.net) 18.50.13 # What are the video pins on Sansa e200 USB connector? 18.51.44 # J-23: I think there's a wiki page describing the Sansa connector 18.52.45 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 18.52.56 # funman: I've no idea. What about the e200v2? I couldn't see any RAM chips on the photos linked from the wiki. 18.53.11 # and the e200 routine is 99.9% identical (one setting has another value) 18.53.32 # I've mounted iaudio7!! 18.53.45 # vitja: great \o/ 18.54.21 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 18.54.29 # yeah but a bit hacky wo interrupts for tx 18.55.24 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.59.21 Join mf0102 [0] (n=michi@e181132181.adsl.alicedsl.de) 19.01.47 # I found still the same code in Clipv2 OF 19.01.51 # vitja: Congratulations 19.02.06 # thanks 19.02.15 # well done! 19.02.24 # still isn't done ;) 19.02.27 *** Saving seen data "./dancer.seen" 19.02.56 # I'll commit workaround soon, so you can test it 19.05.39 Quit Exorcist- (Read error: 110 (Connection timed out)) 19.07.44 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 19.08.13 Join karashata [0] (n=kimi@69.41.192.215) 19.11.02 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 19.11.46 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.13.23 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 19.13.31 Quit Seed ("cu, Andre") 19.13.57 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 19.14.55 Join hannesd [0] (n=light@p5B1638EA.dip0.t-ipconnect.de) 19.15.04 Join kharo1 [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 19.16.05 Quit kharo (Read error: 110 (Connection timed out)) 19.21.22 Join domonoky1 [0] (n=Domonoky@g229101240.adsl.alicedsl.de) 19.21.26 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 19.22.17 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 19.22.57 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 19.23.16 Quit Seed ("cu, Andre") 19.24.02 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 19.24.09 Quit karashata (Read error: 113 (No route to host)) 19.24.17 Join karashata [0] (n=kimi@69.41.192.215) 19.30.17 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 19.30.28 Quit karashata (Read error: 113 (No route to host)) 19.30.54 Join karashata [0] (n=kimi@69.41.192.215) 19.33.20 Quit sarixe ("Ex-Chat") 19.37.36 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 19.40.16 Quit domonoky (Read error: 110 (Connection timed out)) 19.40.52 # Hmm 19.41.24 # Regarding the test plugins - maybe we should have a 'developer build' option in configure, which will enable all the test stuff? 19.42.07 # (perhaps a sub-option for advanced builds) 19.42.22 # good idea 19.42.39 # Then the build system could produce such builds, and we would see whether the test stuff still compiles 19.42.54 # amiconn: Good call. 19.43.09 # It would mean that the master would need to strip the test stuff from the .zip files before putting them into the download folder 19.43.48 # Hmm, or perhaps just build them, but don't include them in the .zip? Saves some upload time (build server -> master) as well 19.45.07 # The exclusion could be part of the standard 'make zip', 'make 7zip' etc. There could be a special 'make devzip' which includes them 19.46.24 # * LambdaCalculus37 opts to have a developer option added to configure, alongside normal, debug, et. al. 19.46.56 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 19.47.52 # They could get a separate category. That would make it trivial to exclude them 19.47.59 Quit stoffel_ (Read error: 113 (No route to host)) 19.48.30 # Well, there are 3 cases. (1) A user who wants to build his own rockbox (perhaps with a few patches). The test_* plugins should neither be built nor zipped. (2) A dev who wants the test_* plugins. In this case they should be built and zipped. (3) The build system. Here the test_* plugins should be built but _not_ ziiped 19.49.46 # My suggestion is to make building of the test_* plugins a configure option, and zipping them a separate make target 19.50.34 # What's the point in not building them? They're all tiny compared to the rest of the plugins needed to be built. 19.51.00 Join stoffel_ [0] (n=sfr@p57B4E535.dip.t-dialin.net) 19.51.02 # Build time 19.51.11 # * linuxstb thinks the build system is complicated enough already... 19.52.17 # How big would the build time difference be in practice? 19.52.49 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 19.53.44 # I didn't measure. I usually do build all test plugins, even on cygwin 19.55.27 # Actually I don't. I only build 6 of them 19.55.28 Join nanok [0] (n=nanok@194.145.183.75) 19.55.38 # * gevaerts now has a dump of the DAX nand flash 19.55.52 # gevaerts: Cool... The whole 1GB? 19.55.56 Join tessarakt [0] (n=jens@e180067134.adsl.alicedsl.de) 19.56.08 # yes. As correct as the current tcc nand driver allows 19.56.17 # * nanok salutes respectfully 19.56.19 # How long did that take? 19.56.34 # 303.998 seconds 19.56.43 # :-) 19.57.00 Join Siku [0] (n=Siku@e212-246-214-27.elisa-laajakaista.fi) 19.57.03 # * domonoky1 loves exact statements.. 19.57.49 # Speaking of exact, this is actually exactly 10^30 bytes :) 19.58.07 # vitja: usb seems to work on the dax 19.58.38 Quit stoffel_ ("Reconnecting") 19.58.48 Join stoffel_ [0] (n=sfr@p57B4E535.dip.t-dialin.net) 19.59.13 # gevaerts: That will make a nice recovery tool, assuming you can do the reverse... 19.59.54 Join peerlessdeepak [0] (n=peerless@122.164.224.187) 19.59.54 # gevaerts: so it's 1GB ;-) 20.00.15 # linuxstb: indeed. I 20.00.18 # gevaerts: problem was TX fails on big(>512) packets, RX will not work now for packets >512 20.00.31 # I'm not trying to writr yet though 20.00.38 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 20.00.59 # hope that can help with TNFL 20.01.07 # vitja: >512 byte transfers I guess. Packets are always 512-bytes max 20.01.46 # yes, but some times they are fragmented 20.02.13 # e.g. when host asks for 2 blocks usb_drv_send is called with len 1024 20.02.14 # vitja: shotofadds was here recently, sounding confident about breakthroughs with the NAND. Hopefully this will help him too. 20.02.56 # Yes. usb_drv_send is for an entire transfer 20.03.14 # so entrie transfer sometimes fails 20.03.15 Quit Thundercloud (Read error: 104 (Connection reset by peer)) 20.04.16 Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) 20.04.34 Quit peerlessdeepak (Remote closed the connection) 20.05.36 # linuxstb: nice 20.07.01 # btw how did somebody find out how the telechips_nand works? reverse engineering? 20.07.35 # denes_: Yes - I think work started almost a year ago... 20.07.47 # But only one person has really been working on it afaik 20.08.15 # * gevaerts tries to find a FAT header in the dump 20.08.18 # i see. the meizu m3 does something funky too (different from the tcc7XX) 20.11.10 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 20.11.15 Quit stoffel_ ("leaving") 20.12.04 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 20.12.57 Join Hillshum [0] (n=chatzill@75-165-224-4.slkc.qwest.net) 20.14.56 # so on the ipod nano there is some kinf of an ata-nand bridge? 20.15.12 Quit Rob2222 (Success) 20.15.16 # denes_: Which generation of nano? 20.15.36 # LambdaCalculus37: only one generation is supported, that generation 20.15.37 # denes_: Yes - for the Nano Rockbox supports. 20.16.04 Quit GodEater_ (Remote closed the connection) 20.16.05 # denes): Ahh, you mean first. I thought you were asking about other generations. 20.16.05 # ist 20.16.08 # linuxstb: interesting. 20.16.13 # * LambdaCalculus37 slaps his tab key 20.16.16 # *1st 20.16.33 Join Schmogel [0] (n=Miranda@p3EE21CBB.dip0.t-ipconnect.de) 20.16.56 Quit bmbl ("Woah!") 20.17.04 # LambdaCalculus37: yes, sorry I realize I was a bit vague 20.18.36 Quit homielowe () 20.19.00 # Looking at the 5g resource files with readelf, it just says "Machine: : 0x5f" 20.20.40 # does anyone know how the oled brightness on the clip is varied? 20.21.01 Join anselm [0] (n=anselm@e178034038.adsl.alicedsl.de) 20.22.33 # linuxstb: what about using OSX's readelf ? 20.22.58 # bertrik: the command should be defined and used in the init routine 20.23.00 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 20.23.32 # I do have a clue and I'm about to try it out now 20.23.34 # who admins flyspray? 20.24.06 # The Swedes 20.24.16 # Shout at Bagder :) 20.24.20 # So about the crypto on newer ipods (like nano 2g) i find it interesting that there seems to be no reports of people trying to brute force it... IMHO it seems it could be worthwhile to try brute forcing the RC4 crypto as: 20.24.26 # * Bagder covers ears 20.24.28 # how many people are 'the Swedes' ? 20.25.30 # funman: Three 20.25.35 # Bagder: shouldn't rockbox website / flyspray specify unicode character set ? 20.25.40 # Bagder, LinusN and Zagor 20.25.50 # our 3 swedes are: Bagder, Zagor and LinusN, hooray to them.. :-) 20.25.52 # funman: yes, "should" being the keyword there 20.26.13 # we are more dev swedes than us though 20.26.15 # domonoky1: There are only three Swedes as far as I am concerned :) 20.26.28 # is the website static? in svn? 20.26.41 # most is static and in svn, yes 20.26.56 # (apologies to the other Swedish people here ) :) 20.27.07 # * funman is going to flame webmaster@rockbox.o 20.27.23 # 1) Apple used it on ipod flash images before, 2) (AFAIK) noone else that uses the same SoC has encrypted firmware which suggests that apple did it themselves 3) analysis supports the theory that it is a stream cipher 4) if the key is short it should be doable (32 bits used on earlier flash images) reports of up to 48 bti keys brute forced in less than two weeks on distributed systems 20.27.41 # so flyspray seems to request unicode, rb home doesn't 20.28.07 # funman: feel free, that address gets lot of crap ;-) 20.28.07 # n1s: as long as you know the stream cipher algorithm 20.28.08 # any idea where the key is hidden? 20.28.40 # or maybe bruteforce all algorithms you know until you can grep 'Apple' ;) 20.29.18 # bertrik: if it's an asymetric algorithm the generating key isn't to be found, only the decrypt one 20.29.41 # well, until you brute-force that too 20.30.17 # funman: i would suggest starting with rc4 at least and also there should be no problem to find unique strings to search for... 20.30.26 Quit Rob2222 (Read error: 60 (Operation timed out)) 20.30.40 # asymmetric sounds a bit unrealistic (and perhaps quite slow?). I assume they want to protect the firmware from being decrypted, not from being encrypted. 20.31.08 # * Hillshum seconds bertrik 20.31.10 # bertrik: if we can't encrypt we probably can't run any code so... 20.31.39 # * n1s Votes for Mr Someone to try brute forcing the thing :) 20.31.56 Quit J-23 (Remote closed the connection) 20.32.23 # Or if someone sends me a new ipod and a _really_fast computer i promise i'll try it :) 20.33.35 # Bagder: unless you want to replace the code by yours 20.33.45 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 20.34.02 # * funman gives some quarks to n1s 20.34.31 # * shotofadds 's ears are burning 20.34.39 # hmm quarks tastes funny... 20.34.48 # * Hillshum has access to a 3g nano... 20.36.42 # hm I'm looking at the Clipv2 again 20.37.04 # It setups stacks past 0x50000 (more than 320kB) 20.37.20 # how different from v1? 20.38.16 # the v1 uses stack (and everything) below 0x50000 20.38.29 # but I just read that you can remap external memory (up to 4MB) at address 0 20.38.56 # that means that when booting the external memory is mapped at 0 (not the Embedded 1T-RAM of 320kB) 20.39.13 # gevaerts: about the tcc nand driver, I've a better understanding of how the various 0x13,0x15 and 0x17 block types fit together now (I'll add this info to the wiki at some point), but unfortunately the results from my "super improved" driver weren't quite as good as expected. 20.39.23 # I'll produce a patch for you to try later, though 20.40.13 # Ok. My current dump doesn't make much sense 20.40.24 # ok, it seems clip oled brightness is not controlled by the dcdc15 voltage as it is on the c200v1 and e200v1 20.41.30 # bertrik: brightness != contrast ? 20.41.54 # funman: would this mean the external memory is already mapped when we branch to rockbox ? 20.41.55 Join n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu) 20.42.14 # domonoky1: Yes, but I'm talking about Clipv2 here, not v1 20.42.26 # ah, different clips.. :-) 20.47.38 # linuxstb: I'd send you the compressed dump, but after dd-ing /dev/zero to a file via the OF and making a new dump, bzip2 compresses it to 7300 bytes so I'm pretty sure that this isn't very useful 20.47.51 Quit kharo1 (Read error: 60 (Operation timed out)) 20.48.31 Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 20.50.26 Quit pierre- (Read error: 110 (Connection timed out)) 20.50.34 Join fml [0] (n=4fd3cefa@gateway/web/cgi-irc/labb.contactor.se/x-f49c295fe2440629) 20.51.07 # XavierGr: ping. Want to talk about FS#9455? 20.53.18 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 20.53.48 Join Exorcist- [0] (n=mrtilde@cpe-66-108-229-28.nyc.res.rr.com) 20.54.46 # linuxstb: Afaics it's neither mips, nor arm, sh or m68k 20.56.09 # amiconn: is the flashing chapter in the manual in a reasonable state now? (i.e. can FS#5953 be closed?) 20.56.50 # gevaerts: That sounds odd - the nand flash should contain the firmware. 20.57.16 # linuxstb: I blame the FTL in svn 20.57.27 # Let's see what happens with shotofadds' new version 20.58.00 Join homielowe [0] (n=homielow@d206-116-134-81.bchsia.telus.net) 20.58.19 Join DerDome [0] (n=DerDome@dslb-082-083-247-154.pools.arcor-ip.net) 20.58.49 # bluebrother: you here? Have you seen my last comment in FS#9455? Do you agree with all points? 20.58.57 # gevaerts: Ah, I thought you were dumping the raw NAND pages? 20.59.05 # bertrik: IntBootSel (xpc[0]) selects ROM or external memory on the AS3525 20.59.13 # gevaerts, linuxstb: if your dump is from the rockbox driver it won't contain the firmware. that's in a separate, non exposed, area 20.59.17 Join MarcGuay [0] (n=chatzill@ip216-239-67-64.vif.net) 20.59.20 # n1s: Yes. The wiki pages still need to be updated. I'll remove the basic flashing instructions as they are covered by the manual now, and collect technical background and faq-like stuff there 20.59.36 # dump that raw NAND would be useful, though 20.59.44 # *dumping 20.59.47 # amiconn: great, I'll close that bug then 21.01.27 # funman, what do you mean to say with that? Maybe if clip v2 references "external memory" that may actually be extra RAM inside the chip, it would also allow us to boot from that RAM? 21.01.51 # shotofadds: sure, how? 21.02.23 # bertrik: no, see page 188 of the AS3525 datasheet, this setting determines what is mapped at address 0 21.02.28 *** Saving seen data "./dancer.seen" 21.03.21 # gevaerts: I would guess some combination of nand_read_raw() and black magic ;) 21.03.35 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 21.04.16 # TargetStatus could use some love from people in-the-know on the Meizu, m:robe500, GoGear HDD, and Elio. Also wondering if a "Boots Rockbox" column is needed... 21.04.28 Join Rob2222 [0] (n=Miranda@p4FDCC4BE.dip.t-dialin.net) 21.05.02 # MarcGuay: Only if you define what boots Rockbox means 21.06.00 # fml: well, I don't see a reason why someone would want to stick the first letter to the last, so why no automatic space? 21.06.14 # I have a problem I can't solve 21.06.27 Join Rob2223 [0] (n=Miranda@p4FDCE09D.dip.t-dialin.net) 21.07.08 # AS3525 ships with a ARM922T CPU, which is in the armv4 family. the BLX instruction appeared in armv5T family. The Clipv2 uses the BLX instruction. 21.07.24 # MarcGuay: The phrase "currently built by the Rockbox build system" isn't true for all of those targets. See http://build.rockbox.org/dev.cgi - maybe that should be a column as well. 21.07.47 # MarcGuay: Plus the DAX can dual-boot, and the hardware can't charge, so the charging column should be "N/A" 21.07.58 # Similarly for the m200v1 21.08.23 # does gcc allow creating arrays with a variable as size when putting them on the stack? 21.08.25 # nooooo, sandisk must have sensed we were about to port rockbox to a clip so they quickly started working to make it obsolete! 21.08.42 # bluebrother: alloca? 21.09.24 # yes 21.09.26 # linuxstb: I'm referring to 2. of fml's last comment in FS#9455 21.09.42 # linuxstb: no, char mystring[i]; 21.10.06 # funman: afaik, you can't do that. 21.10.17 # just try 21.10.22 # Which is why I suggested alloca. But I may very well be wrong... 21.10.33 # When/where is i defined? 21.10.45 # before 21.11.27 Join dany_21a_ [0] (n=dan@84-119-1-28.dynamic.xdsl-line.inode.at) 21.12.00 Join AndyIL [0] (i=AndyI@212.14.205.32) 21.12.01 # bluebrother: http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Variable-Length.html#Variable-Length 21.13.09 # bluebrother: because it makes more things possible at less cost (the code becomes simpler) 21.13.55 # n1s: FS#9380 was masked on arm by the crash bug I guess 21.14.08 # gevaerts: very likely 21.15.16 # * linuxstb should probably read a book about the other things invented by C99.... 21.16.09 # linuxstb: Does the m200 run off of AA batteries? Or did you mean that it can dual-boot? 21.16.18 # linuxstb: I think there is a (shorter than the standard) document which lists those 21.16.34 # amiconn: thanks. 21.16.51 # MarcGuay: can you recharge the AA batteries with USB ? 21.17.21 # MarcGuay: it uses AAA batteries 21.17.34 # funman: Not as far as I know. bluebrother: Thanks. 21.17.37 # let's make a deal on A* 21.17.45 # shotofadds: you could actually make a special mode that exposes the translated device as LUN 0 and the raw nand blocks as LUN 1 21.18.32 # * bluebrother is not sure if he likes this C99 feature in gcc 21.18.55 # MarcGuay: Both (well, AAA). I'm pretty sure the m200 can't charge them. 21.19.29 # The m200 can't charge the batteries. 21.19.31 # Things get confusing with the m200.. The v1 (NAND) can dual-boot but the v? (HARP) can't? 21.20.50 # MarcGuay: dual-boot really (IMO) refers to being able to load the OF. They should all be able to do that, as the bootloader is patched into the OF image, and then that modified image is flashed using the normal firmware upgrade facility in the OF 21.20.51 # MarcGuay: The v3 (HARP)? I'm not even sure if it can; I haven't tried. 21.21.23 # MarcGuay: Being able to load Rockbox is obviously dependent on a NAND driver - and you have a separate column for that. 21.21.55 Quit Exorcist- () 21.23.12 # And we can't refer to the first three types as v1,v2,v3 without confusing them... Okay, I see what you're saying... 21.23.27 Quit AndyI (Read error: 110 (Connection timed out)) 21.25.15 Join Strife89 [0] (n=michael@204.116.245.152) 21.25.30 # Speaking of the bootloader patched into the OF image, is it possible to do this already with the m200/c100 bootloaders? Or is there something still missing for that to happen? 21.26.54 Quit markun ("leaving") 21.27.03 Quit Rob2222 (Connection timed out) 21.27.10 Quit nplus (Remote closed the connection) 21.28.16 Join m0f0x [0] (n=m0f0x@189-47-11-46.dsl.telesp.net.br) 21.31.50 # LambdaCalculus37: Yes, I think it's possible. You need to #define TCCBOOT to build a dual-boot bootloader, and then patch an OF with tools/mktccboot. But I'm not 100% sure if crt0.S has the correct dual-boot button check for the m200... 21.33.46 # In Clipv1 OF external memory is initialized just after NAND, and just before LCD 21.35.06 # I have figured part of the settings, but I have trouble understanding how the remaining ones are read from the stack .. 21.35.46 # MarcGuay: the v3 (HARP) doesn't really have a port of its own right now. it really needs a new configure target, and someone to work on the SD interface 21.36.22 # gevaerts: yes, something like that might work, and shouldn't take too long to implement. shame I'm in the middle of something else right now... 21.37.33 Join midkay__ [0] (n=midkay@216-160-120-20.tukw.qwest.net) 21.38.09 Quit gevaerts (Read error: 113 (No route to host)) 21.38.37 # shotofadds: HARP is similar to the e200/c200 way of accessing the flash, isn't it? 21.38.58 Quit shodanX (Read error: 60 (Operation timed out)) 21.39.03 Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 21.39.37 Quit fml ("CGI:IRC") 21.39.39 # LambdaCalculus37: yes, it's that SD/NAND bridge. preglow's SD driver should work just fine, if and when he gets it working 21.40.07 # * LambdaCalculus37 looks in preglow's direction 21.40.15 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 21.40.22 Quit karashata ("I go, only to return again some time...") 21.41.09 # funman: regarding your blx question, the AMS3530 uses a ARMv5TEJ core, maybe they switched to that? 21.41.47 # s/M// 21.41.51 # LambdaCalculus37: "someone" will still have to port that SD driver to tcc77x 21.42.02 # my "should work just fine" was probably a bit hasty ;) 21.42.05 # could be, the OF still mentions "AS3525_2_0.cr_5_0_develop." 21.42.20 # gevaerts: Does this mean that logf-over-usb-serial is close to reality on the telechips targets? 21.42.28 # could be the AS3525 devkit with a different -mcpu option for gcc 21.42.47 # but then AS3525 an 3530 have to be VERY similar 21.42.58 Quit midkay_ (Read error: 60 (Operation timed out)) 21.43.11 # linuxstb: I think so, yes. Let me try :) 21.43.56 # Do we know the exact markings on the AMS chips inside each device? 21.45.31 # no, on the Clip the chip reads 'SanDisk' not AMS 21.45.32 # I haven't seen any scans or photos of v2 clips 21.45.54 Join markun [50] (n=markun@rockbox/developer/markun) 21.47.08 Quit Hillshum (Read error: 104 (Connection reset by peer)) 21.49.26 Quit bughunter2 ("bye") 21.50.03 Join bughunter2 [0] (n=Jelle@77.164.66.126) 21.51.48 Quit shotofadds ("Leaving") 21.56.57 Quit kharo (Read error: 110 (Connection timed out)) 21.57.25 Quit funman ("leaving") 21.58.59 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 21.59.23 Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 22.00.38 Join shotofadds [0] (n=rob@80-44-101-12.dynamic.dsl.as9105.com) 22.01.52 Quit MarcGuay ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 22.02.36 Quit massiveH ("Leaving") 22.04.08 Join petur [50] (n=petur@rockbox/developer/petur) 22.04.21 Join funman [0] (n=fun@86.219.29.237) 22.04.42 # just wanted to tell you I can write at 0x30000000 which is the Clip SDRAM (going to verify its size) 22.07.48 # my incomplete code was correct, just forgot to use system_init() in the bootloader >< 22.08.37 Join Acky [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) 22.11.00 # hmm the memory is quite slow in my opinion, may need tweaking 22.11.36 # Nice work. Is the cache enabled? 22.11.44 # the what ? >< 22.11.57 Quit Acksaw (Read error: 60 (Operation timed out)) 22.12.48 # which is faster? memcpy or strncpy? 22.13.10 # memcpy obviously (no \0 check) 22.14.18 # and if I make sure that the string has \0, what is more suitable strcpy or memcpy on the whole array? 22.14.41 # memcpy() with a nice comment why you don't use str*cpy ;) 22.15.33 # I used strncpy with the 3rd parameter strlen(string) + 1 in order to avoid writing the whole array 22.15.38 # but I was told it is not so good 22.15.55 # If there is no trailing 0, what will strlen return? 22.16.06 # then yeah you will have a problem 22.16.15 # linuxstb: don't do that. ;) 22.16.24 # and if you do a strlen, you can just as well use memcpy afterwards 22.16.36 # hmm according to my test there is more than 8MB of RAM in the Clip (didn't found the upper limit yet) 22.17.00 # oh nice, but did you check for aliases? 22.17.11 # Are you sure it's not just wrapping around? 22.17.21 # no 22.17.22 # funman: Any idea what the extra 10MB of clipv2 firmware contains? 22.17.35 # Bagder: imagine a char array of 10 characters, but the string in question might be less e.g 5. Shouldn't be more efficient to just call strcpy? 22.17.35 # I use the alias for MPMC Bank 4 22.17.56 # linuxstb: code, the firmware block is > 320kB and so it has to be in external RAM (which is mapped at 0) 22.17.57 # XavierGr: yes 22.17.59 # Bagder: instead of memcpy or strncpy on the whole array? 22.18.13 # but that doesn't explain the large overhead with no new features advertised 22.18.18 # maybe it's a debug build ;) 22.18.45 # I see, so strcpy would be better if I make sure that the \0 always exists 22.19.51 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 22.20.01 # If the array is only 10 bytes, don't worry about speed - just write something that's safe and clear (e.g. strncpy) 22.20.32 # linuxstb: it can be as much as 60 butes actually (but lower too on other targets) 22.21.34 # linuxstb: can you please check #9455 in scroll_engine.c and display_menu.c, I was told by fml that strncpy with strlen is bad 22.22.28 # or does he mean that if you call strncpy the check for \0 is done internally so the third argument needs only to be sizeof the arrya? 22.22.33 # array too 22.23.24 # * linuxstb isn't sure he wants to get involved with 9455 22.23.42 # XavierGr: using the array size is safer since strlen will keep counting until \0 so if the string wouldn't be terminated it would stop in some random place but if you use the array size it will at least stop there 22.24.03 # n1s: yup now it is more clear thanks 22.25.25 # * domonoky1 thinks you should use strncpy(dest,source,sizeof(dest)); dest[sizeof(dest)-1] = '\0' to be always safe .. :-) 22.26.10 # if 'dest' is reasonably small I'd do it similar to that too 22.26.20 # * linuxstb was about to suggest what domonoky1 suggested, but would write it "= 0", not ='\0' 22.26.38 # (if source is longer then dest, dest isnt null-terminated) 22.27.04 # domonoky1: in my case it can't be 22.27.27 # weird I used a magic to check memory wrapping and I'm already past 4MB 22.27.45 # XavierGr: its always better to be safe, than sorry. you dont know what future modifications will do.. 22.27.49 Quit {phoenix} (Remote closed the connection) 22.27.50 # maybe if the timings are wrong the data isn't correct 22.28.39 Quit kharo (Read error: 110 (Connection timed out)) 22.29.47 Join kharo [0] (n=teemu@a88-114-245-92.elisa-laajakaista.fi) 22.29.47 # funman, you could just write each SDRAM location with it's own address, then check all locations again 22.30.22 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.30.25 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-ae49ccc1f38767f3) 22.30.58 # domonoky1: sure, it is just that source points to an array which is the same length as destination (and they should be like that in any modification), but I understand your point 22.31.06 # bertrik: thanks 22.32.58 # * bluebrother was thinking to simply memset(dest, 0, sizeof(dest); memcpy(dest, src, sizeof(dest) - 1); 22.37.32 # that's slower though 22.37.49 # but that would write the whole array two times 22.38.28 # remember that strncpy() zero-pads as well 22.41.41 # true. But what happens if src is shorter than dest and dest has an old value in it? 22.41.56 # argh, overlooked that it's a local array. Ok, scrap that 22.42.15 # if I read continuously a word in memory, its value stays valid 22.42.33 # if I loop over a bigger part, the values disappear :/ 22.42.40 Quit anselm ("Ex-Chat") 22.42.54 # bus capacitance maybe? 22.43.17 # I don't know what you are talking about 22.43.34 # I'll try to understand what I'm doing, but tomorrow ;) 22.44.02 # sounds like bad memory refresh or similar 22.44.53 Quit funman ("leaving") 22.46.26 # if you read very quickly after writing, the data value can be remembered by the capacitance of the data wires, so the data bus itself can act as a kind of memory (for just 1 word of data...) 22.47.23 # bertrik: but if it the bus, it should only work for 1 word. even 2 would destroy it.. 22.47.41 # but if the value stays "if I read continuously" it is something else 22.48.00 # to me it sounds exactly like bad memory refresh 22.48.03 # ok, agreed 22.51.10 Join sarixe [0] (n=sarixe@ool-435407e9.dyn.optonline.net) 22.56.30 Quit m0f0x () 22.58.43 Quit domonoky1 (Read error: 104 (Connection reset by peer)) 23.01.44 Quit massiveH ("Leaving") 23.02.31 *** Saving seen data "./dancer.seen" 23.04.54 Part dany_21a_ 23.05.27 Quit mf0102 (Remote closed the connection) 23.05.33 Join dany_21a_ [0] (n=dan@84-119-1-28.dynamic.xdsl-line.inode.at) 23.06.45 # shotofadds: so you wrote the telechips nand ftl stuff right? you "simply" reverse engineered the OF? how long did it take? 23.10.37 # denes_: no, the tcc nand driver was initially written by examining raw nand blocks and trying to piece them together into contiguous data. Since then I've been trying to understand the OF code for almost a year now. Hope that doesn't put you off ;) 23.10.58 Part dany_21a_ 23.11.35 # shotofadds: ;) well... I looked at the meizu raw nand blocks, and couldn't yet make any sense of it. 23.12.37 # and which device uses firmware/drivers/ata_flash? because that's a similar idea 23.12.43 # I hope the meizu has a larger screen than the d2. maybe you can display a whole sector at a time :) 23.13.11 # denes_: that's iriver ifp7xx 23.13.16 # shotofadds: yeah right :) I only cared about the additional few (64) bytes in the flash page 23.13.42 # shotofadds: it should be the same usb driver as the tcc ones 23.15.05 # denes_: check if any of the 'spare' bytes are the same in all sectors of a physical block. if so it's possibly a logical block number. 23.15.20 # you can also try searching the physical blocks for known data 23.16.04 Quit bluebrother ("leaving") 23.16.09 # the fun starts when you find multiple physical blocks with the same logical block number ;) 23.16.45 Join lostnfound [0] (n=a81087b3@gateway/web/cgi-irc/labb.contactor.se/x-a9a3b925d56a0836) 23.16.51 Join Slack [0] (n=brett@12-218-63-169.client.mchsi.com) 23.16.51 # hello 23.17.15 # shotofadds: yes, I have found the first logical block. it's the 22016. page ;) 23.17.17 # I found an iPod today, and it had this operating system on it 23.17.38 # is there anyway it has information on the person that used it 23.17.45 # gevaerts: yes, usb should be a rather significant help too! any idea what I'd have to do to get logf-over-usb working (either on m200 or d2)? 23.18.05 # denes_: but is it always in the same physical location? I suspect not. 23.18.15 # shotofadds: probably not 23.18.18 # lostlogic: connect it to a computer and investigate the files on it 23.18.27 # There are a few pictures 23.18.28 # lostnfound: even 23.18.34 # but the OS is hard to get used to 23.18.59 # lostnfound: I think some of us may disagree with that 23.19.11 # I didn't want to plug it in to my computer and have it sync to the foreign iPod instead of mine 23.19.24 # shotofadds: I'm now trying to get it to work on DAX 23.19.37 # lostnfound: what, it syncs without you asking it to? 23.20.19 Join webguest64 [0] (n=1824bd5b@gateway/web/cgi-irc/labb.contactor.se/x-8efb12a830083d1d) 23.20.32 # hi 23.20.36 # is anyone there? 23.20.51 # I'm not sure 23.20.57 # great 23.21.01 # That is why I haven't connected it to the computer 23.21.12 # gevaerts: excellent work! hopefully we can find a way to spit binary data through "logf" too 23.21.19 # for fear of it syncing with my computer and giving me more work to do 23.21.24 # Do you think rockbox is going to work on the v2 versions of the sansa e200? 23.21.27 # shotofadds: I 23.21.38 # I'd really go for the mass-storage way for that 23.21.48 # I tried that 23.21.48 # yeah I know 23.21.51 # webguest64: yes, we have great hopes of that it eventually will 23.22.04 # great that is just what I wanted to hear 23.22.19 # if you could estimate how long do you think it would take? 23.22.21 # its an interesting OS concept 23.22.29 # but it won't work on my touch 23.22.35 # webguest64: if we could estimate we would, but we can't 23.22.44 # ok thanks 23.22.57 # gevaerts: yes, that sounds sensible. a quick hack to allow that should take all of 30 seconds if mass storage works 23.23.10 # No mass storage doesn't work 23.23.15 Join BigBambi_ [0] (n=Alex@rockbox/staff/BigBambi) 23.23.23 # lostnfound: true, but it runs on some 28 other music players 23.23.24 # it detects it then when you try to install it thinks it isn't there 23.23.27 Quit BigBambi (Nick collision from services.) 23.23.34 # shotofadds: I can post a patch that uses a block of RAM instead of the ata_* layer if you like 23.23.34 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-17fecfa36061c207) 23.23.35 Nick BigBambi_ is now known as BigBambi (n=Alex@rockbox/staff/BigBambi) 23.23.46 # Auto-detect finds it but when you try to install it thinks it isn't there 23.23.53 # webguest64: that discussion has nothing to do with your v2 question 23.24.07 # there are 140 persons here and there are more than one conversation at once at times 23.24.09 # o 23.24.17 # that makes sence 23.24.20 # I think 23.24.32 # Rockbox does not work on the sansa v2 at this point in time, so tryign to install it is pointless 23.24.33 # blubrother (for logs) - I can get you a H10 with "battery issues" for $15 + shipping. 23.24.33 Quit webguest64 (Client Quit) 23.24.41 # bluebrother even 23.24.44 # gevaerts: if mass storage "works" currently, I'll just tweak the ata_read_sectors to return raw data instead for now 23.24.51 Join Munkie [0] (n=Alex@dsl-245-168-10.telkomadsl.co.za) 23.25.01 # Guess I'll sell this bitch 23.25.18 # shotofadds: it works on tcc77x anyway 23.25.19 Join hd [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 23.25.26 # dunno 23.25.49 # linuxstb: the high WMA DRAM ussage is almost all look up tables 23.25.56 # If any of you are in need of a laugh, go to the apple forums and search for rockbox. 23.25.59 # the format needs a very large number of look up tables 23.26.04 # I haven't looked but is there a walkthrough on how to uninstall 23.26.04 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 23.26.13 # shotofadds: I didn't get it to run last time I tried on the D2, but you probably know that one better 23.26.29 # lostnfound: easiest way is to let itunes do a restore 23.26.31 # the LSP feature needed for files less then 16kbps uses a 32KB lookup table for one function 23.26.43 Quit Schmogel (Read error: 104 (Connection reset by peer)) 23.26.44 # gevaerts: I have my m200 here ready to try, but it'll probably have to wait til tomorrow. Time is a bit scarce at the moment :/ 23.26.53 # this could be paired down, but I haven't due to a poor understanding of how some of the codec's features work 23.26.53 # Alright, as long as it wont sync automatically. 23.27.01 Quit HellDragon (Read error: 104 (Connection reset by peer)) 23.27.21 # saratoga: But in bss? So they're calculated at init time? 23.27.42 # linuxstb: oh I didn't realize BSS was all runtime 23.27.45 # a lot are, but not all 23.28.16 # text is predefined tables and code then? 23.28.17 # Yes, "BSS" is zero-initialized data. 23.28.32 # Yes, text is code and const data 23.29.07 # then its probably the huffman tables, various trig tables, etc 23.29.25 # due to an odd detail about how the MDCT works in WMA, each trig table is roughly 2x as big as most other MDCT codecs 23.33.57 Quit lostnfound ("CGI:IRC (EOF)") 23.35.50 Quit fyre^OS (Remote closed the connection) 23.36.06 Join fyrestorm [0] (n=nnscript@cpe-68-173-234-148.nyc.res.rr.com) 23.42.44 Quit ender` (Read error: 104 (Connection reset by peer)) 23.43.19 Join ender` [0] (i=krneki@foo.eternallybored.org) 23.46.31 # Bagder: Can you remember enough about the V1 Sansas to think of what could be the issue here? http://forums.rockbox.org/index.php?topic=19091.0 23.46.46 # gevaerts: could you post that UMS-from-RAM patch? I'll try it out when I get a chance tomorrow 23.46.50 Quit Siku () 23.46.56 # shotofadds: actually I' 23.47.03 # shotofadds: actually I'm thinking of just committing it 23.47.12 Quit Munkie ("Leaving") 23.47.13 # or that :p 23.48.12 # linuxstb: the only hint is his read-mode comment, which usually implies file system breakage 23.50.06 Quit lasser (Remote closed the connection) 23.51.38 # shotofadds: committed. The size near the top is in sectors 23.52.58 Quit hd (Remote closed the connection) 23.53.25 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 23.55.52 Quit ender` (" A computer program will always do what you tell it to, and seldom what you want it to.") 23.58.08 Quit bughunter2 ("bye")