--- Log for 06.06.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 7 hours ago 00.00.47 # obo: well the bootloader is raw binary : the real code starts at offset 0x0 (the vectors) 00.01.05 # and that means that you will get some offsets wrong 00.02.29 # obo: at the end of main function I see that PC is loaded with 0x10F029FC (at offset 0x138, so 0xF8 for you) 00.02.51 # do you know to which real offset in bootloader it corresponds? 00.04.18 # funman: no. I'm going to redo without stripping anything. What does offset 0x3B98 look like to you? 00.05.40 # the start of a function 00.06.34 Quit raphi ("leaving...") 00.06.37 # notlistening: I don't know whether there is any advantage in using sapi 64 bit over sapi 32 bit or vice versa 00.06.45 # funman, any difference selecting with or without fm on the frmware? 00.07.00 # thanks amiconn 00.07.41 # notlistening: where can you select that? 00.08.05 # I was just digging a bit because (1) I wondered about the different voices listed depending on whether I used cscript sapi_voice.vbs /language:xxxx /listvoices in a cygwin bash (32 bit) or in a cmd shell (64 bit), and then learning about the sysnative virtual directory 00.08.23 # funman: i am doing some testing on my e280v2 with the latest patches, when testing playback, should I just let things play through (like an album) or would it be better to seek around? 00.09.32 # Chesteta: do whatever you want 00.09.36 # I have already done my best to describe what happens with teh radio, wheel light, and the blue lines... running a disk test now: can you think of any other pertinant things to test? 00.10.08 # use it ike an mp3 players supposed to be used? 00.10.43 # Chesteta: nope sorry, I think (not sure) kugel knows what's wrong with those blue lines 00.11.09 # mp3/4 not to undermine anybodies work :) 00.12.08 # ok: I havent done MUCH testing and am trying to do as complete of a test as i can 00.12.53 Quit B4gder ("It is time to say moo") 00.13.32 Quit flydutch ("/* empty */") 00.14.33 Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 00.15.09 # * bluebrother thinks the german translation was much worse until he redid it (not being a translator at all ...) 00.15.27 # translating is harder than you'd think :) 00.15.36 # mt: Thanks for the update :) 00.15.38 # of course it can always get improved 00.15.41 # Mikachu: indeed :) 00.16.05 # mt: And given the progress you have already made, I think we can let you focus on your finals a little :) 00.16.30 # domonoky: The porting has become relatively complicated, but I think I will be able to tell more about it on Sunday. 00.16.59 # AlexP : You're welcome :) ( pst : I was stealing some study-time .. don't tell anyone ) 00.17.25 # mt: Your secret is safe with me :) 00.18.04 # wincent: fine. 00.18.12 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 00.18.36 # and me! 00.19.38 # and my axe! 00.19.54 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.27.49 Quit stripwax (Read error: 104 (Connection reset by peer)) 00.29.16 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.31.28 Quit Xerion (Read error: 110 (Connection timed out)) 00.31.29 Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) 00.35.51 Quit bluebrother ("leaving") 00.36.36 *** Saving seen data "./dancer.seen" 00.38.25 Quit notlistening (Remote closed the connection) 00.38.47 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 00.40.40 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 00.44.25 Quit hillshum (Read error: 104 (Connection reset by peer)) 00.46.05 # amiconn: what if we add a TEST_BIT_N *and* a BIT_N? the one might even be based on the other. the 1< on the other hand, a 1< Installed and running 01.20.44 # superb :D 01.23.04 # Sansav2 all got radio? Mine does not seem to 01.23.11 Quit Lss (Read error: 104 (Connection reset by peer)) 01.23.15 Join hd [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 01.23.18 # E200v2 01.23.32 Quit HellDragon (Read error: 104 (Connection reset by peer)) 01.23.59 Quit hd (Read error: 104 (Connection reset by peer)) 01.24.16 Join HellDragon [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 01.25.59 # notlistening: see FS#10267 - Sansa AMS FM Radio fix (e200v2 specific) 01.27.03 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 01.27.05 # ahh but just out of interest if the original fw does not work with fm? 01.27.39 # no sound from mine I bought the none fm version about a year ago 01.28.18 Join moos [0] (i=mustapha@rockbox/staff/moos) 01.29.08 Part toffe82 01.29.20 # hrm, TAGCACHE_IS_NUMERIC_OR_NONUNIQUE appears to be an optimization on sh regardless of whether we're using BIT_N or TEST_BIT_N. i'm a bit surprised that gcc can't figure out that as a truth value (1<< n) & c1 || !(1 << n) & c2 == (1< notlistening: so far I thought all sansa had FM, did you try to flash an OF named e200pt.bin for example ? 01.29.58 # or e200pf.bin (f = FM) 01.31.07 # yeah as before i had no fm option in the sansa bit and i do now 01.31.34 # but it does not work even in the of 01.32.13 # git the e200pf as i asked if it made a difference earlier which firmware i used 01.32.20 # let me check the infor quickly 01.32.40 Quit DarkDefender (Remote closed the connection) 01.33.21 # notlistening: the firmwares are all identical, only the naming change 01.34.34 # see http://forums.rockbox.org/index.php?topic=14064.msg113302#msg113302 for details 01.34.58 # well i followed the instructions to name the file i added to the player e200pa so i did 01.35.20 # the changes to the of were to add fm in the menu and to get the dualboot working 01.36.00 # not all sansas have FM hardware. iirc, some european models have no FM 01.36.56 # maybe me then but then should the fm option be reomoved from my menu or disabled as it hangs the player 01.37.02 # sorry more work 01.38.24 # obo: at 0x33cc the vectors (except the reset vector) are changed 01.38.50 # notlistening: for this, see fs#10267 ;) 01.39.58 # thanks funman, lol hw is detected though :D 01.41.15 # do you mean you can see it's detected in debug menu ? 01.41.24 # yeah 01.41.59 # then i don't know why OF can't use it :/ 01.43.09 # I wukk investigate further m anyways thanks for your timr 01.46.30 # if i leave a message for domonkey and bluebrother will they get them? 01.47.41 # yes, but depending what you want to tell them you might use Flyspray 01.48.42 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 01.49.16 Join hd [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 01.49.25 # now all Sansa AMS hackers are joining again ? ^^ 01.50.07 # fdinel: hi! happy with rockbox progress on sansa ? 01.50.31 # hey funman mate :P 01.50.57 # funman: hmm dunno, should I? :P 01.51.43 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 01.52.25 # well i hope it can be released in the next release after the one about to be out (in 4 months) 01.52.48 # I see, great then :) 01.53.23 # looking at the code I was wondering if playback could be made more efficient using IRQs 01.53.49 # it already uses the DMA IRQs 01.53.57 # I see that DMA is used, but I'm not sure if IRQs could be used with it altogether 01.54.03 # well 01.54.25 # we rely on the DMA controller to know if we can transfer more data, not on the I2SO status 01.54.25 # it tells when DMA is done 01.54.39 Join HellDragon_ [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 01.54.41 Quit hd (Read error: 104 (Connection reset by peer)) 01.54.49 # kay 01.54.57 # do you think it would be better to use I2SO status? 01.55.32 # but once the controller says "hey i'm done", we do prepare another buffer and then push it again 01.55.42 # I wonder if we could prepare the buffer in advance 01.55.58 Join slyyx [0] (n=slyyx@142.46.8.26) 01.56.12 # like while the DMA is being done, let's prepare the other buffer so that once DMA is completed we only have to enable the next one 01.56.38 # maybe it's already like that, I'm quite late on the sansa dev :P 01.57.20 # there is a 128x36 bits FIFO = 128x stereo samples = 3/1000 seconds at 44.1kHz 01.57.28 Quit HellDragon (Connection timed out) 01.57.38 # woa...Is...Soaa- ever around here? 01.57.50 # sometimes, check the log 01.58.17 # ....He got further then I did on a P2 port... 01.58.45 # I wonder if he branched off his work yet... 01.58.48 # fdinel: well pcm didn't change a lot 01.58.57 Quit HellDragon_ (Read error: 54 (Connection reset by peer)) 01.59.40 Join Kupop [0] (n=Jono@cpc2-leed14-0-0-cust201.leed.cable.ntl.com) 01.59.52 # funman: kay, that's what I noticed when browsing the code :) Any idea why the clip playback sometimes freeze? 01.59.55 # (brb) 02.00.05 Join BUMBACL0T [0] (n=ORF@unaffiliated/bumbacl0t) 02.00.23 # He was _just_ online on the forums..damn 02.00.31 # no idea :/ I'd like to know if playback freezes also on m200v4 (because they have 2MB of RAM, unlike Fuze & e200v2 which work fine) 02.00.43 Part BUMBACL0T 02.00.54 # slyyx: post on the P2 forum thread, that might make him come! 02.01.03 # New commit by 03unhelpful (r21195): Add a system-wide BIT_N macro, implemented via an LUT on SH, and use it in the TAGCACHE_IS_* macros in place of per-set LUTs, removing duplication of ... 02.01.04 # I just pmd him 02.01.17 # ..I wonder if I still have the rockbox coebase. 02.01.39 # slyyx: this is an on topic channel, if you want to chat, try rockbox-community 02.01.57 # Sorry 02.02.33 # funman: is PCM done exactly the same way on all ams targets? 02.02.45 # yes 02.03.19 # and what about the OF? is it done using the DMA and its DMA IRQ or any other way? 02.03.22 # perhaps it's a problem with the very small buffer 02.03.33 # i didn't read much the pcm code of OF 02.03.55 # (small buffer) possible 02.04.16 # there is an i2sout isr 02.04.26 # which checks fifo push almost empty 02.05.05 # but it uses dma 02.05.58 # saratoga: did you notice problems with the down button of your clip with FS#10048 ? 02.06.09 # Is it is svn? Or git? 02.06.22 # funman: no thougfh I didn't use it much, just listened while running 02.06.30 # slyyx: either 02.06.35 # slyyx: it's a svn server but you can use git-svn, there is a wiki page about using git 02.06.40 # ah 02.07.42 # saratoga: i want to commit fs#10048 soon, now the only problems we have is e200v2 radio borked, and clip down button going made - not something hard to fix 02.09.20 # funman: sounds good 02.09.21 Join HellDragon [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 02.09.33 # neither of those are critical problems anyway 02.10.13 # i do not want to hurry either if other people notice problems while testing 02.11.44 # New commit by 03unhelpful (r21196): Fix undefined BIT_N on non-SH targets. 02.12.29 Quit Kupo- (Read error: 110 (Connection timed out)) 02.12.47 # funman: have you used it much on the Fuze? 02.13.10 # yeah, not much on the clip though 02.14.02 # i mostly tried on the clip which probably froze once every 20-30 minutes for me 02.14.17 # the fuze was stable for an entire album when i tried but maybe i just got lucky 02.14.28 # the Clip playback isn't stable in svn either 02.14.40 # i didn't realize that 02.15.07 # playback randomly stops, but then you can still navigate / shut down the player, but hardly resume playback 02.15.22 # the biggest problem I have seen on fuze is the playback time/counter did not advance regularly, playback was fine though 02.16.04 # is there some way to see which thread dies when it deadlocks? 02.16.13 # tmzt: the timebar isn't regular, or the displayed time change? 02.16.30 # displayed time 02.16.40 # saratoga: i don't know, if hold shuts down the screen, backlight thread is still running ;) 02.16.51 # tmzt: i thought it was a rockbox 'feature' 02.16.51 # progress, not sure about the bar itself 02.17.16 # i mean rockbox changed the actual whole duration of the file 02.17.26 # does the full nand work? 02.17.34 # no 02.17.47 # the current elapsed time 02.18.05 # weird. 02.18.23 # the internal storage can be fully accessed (1GB, 2GB, 4GB, 8GB) 02.19.14 # we still need to find what's the exact storage size, for future USB driver, and also as extra security in storage driver 02.19.17 # I need to restore my partition table and test a current revision 02.19.36 # for now we get the size from the fat32 partition 02.19.47 # exact storage size? 02.19.51 # funman: seems like the OF uses the "push fifo half empty" interrupt 02.20.09 # you mean the nand chip itself? 02.22.23 # tmzt: well i mean what's the size of internal storage 02.22.43 # fdinel: yep, i'm not sure how it is interleaved with the DMA interrupt however .. 02.24.06 # well 02.24.50 # what I would have expected is that we start a first transfer via DMA which will fill the whole fifo, no more no less 02.25.14 Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 02.25.21 # thand setup the irq so that the i2sout tells us when it is half empty (half full if your optimistic :P) 02.25.41 # then we push it some more data (more precisely a half fifo) 02.26.24 # because what I suspect if that the way we use it now, the DMA controller "blocks" the bus everytime a single sample is popped off the fifo 02.26.40 # which can mean a lot of traffic on the bus 02.26.48 # so it would transfer samples one by one ? 02.26.59 # no, a half-fifo each time 02.27.11 # i mean in our code 02.27.30 # uh? 02.27.32 # no 02.27.40 # we do setup the DMA to transfer a half fifo 02.28.08 Quit barrywardell () 02.28.18 # I think that what we're doing now is fill a quite big buffer, and setup DMA to transfer it all? 02.28.23 # yeah 02.28.30 # then setup another one and transfer, etc 02.28.33 # it's more than the i2so FIFO size 02.28.51 # yeah kay, well I think 2 things can happen 02.29.20 # first the processor can't handle processing that much samples (converting say from MP3) in such a small time (3ms) 02.29.41 Join killan [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) 02.29.44 # second, we may be overusing the data bus with small transfer (like a couple of samples) 02.29.53 # (small transfer_s_) 02.30.37 # hum the samples are already PCM (converted) ? 02.31.08 # the PCM buffer holds a lot of samples 02.31.15 # yes once we're ready to send them, but the call to "get_more" or something like that, this is what converts the samples right? 02.31.21 # not sure about on the clip but on some targets its quite large 02.31.30 # perhaps then we should calculate to transfer be a size multiple of the i2so fifo size 02.31.54 # fdinel: no i think the call to get_more will get already decoded samples 02.32.08 # ah kay I see 02.32.22 # !seen soaa 02.32.22 # the codec will fill the pcm buffer, and get_more will empty it 02.33.15 # ok, and the codec fills it during "idle" time? 02.33.27 # the codec fills it continuously until its full 02.33.37 # boosting and unboosting as needed 02.33.44 # kay 02.34.13 # i think its quite large, tens or hundreds of thousands of samples should be in it 02.34.21 # fdinel: you can see the buffer state from the debug menu -> buffering thread 02.35.10 # kay thanks I'll have a look 02.35.26 # but the my "bus overuse" think could make sense? 02.35.38 # ahem 02.35.45 # i don't know ^^ 02.35.52 # but does my "bus overuse" theory make sense? 02.35.55 # :P 02.35.58 # what do you mean overuse? 02.36.27 # like having the DMA controller constantly blocking the bus for 1-2 samples transfers 02.36.31 Quit Chesteta () 02.36.36 # i imagine the i2so requests transfer from the DMA controller at needed times 02.36.37 *** Saving seen data "./dancer.seen" 02.37.26 # + now we see very good performances, so i somehow doubt it 02.38.22 # it all depends on how the dma controller is wired to the i2sout. If the dma controller is wired so that every time a sample is taken out of the fifo it pushes an additionnal sample in, then it results in several single-sample transfers 02.38.27 # instead of a big one 02.38.39 # well yeah that's a point :P 02.38.58 # could you mesure the bus activity with an oscilloscope? 02.39.08 # the only difference between the clip and the fuze/e200 is available RAM? 02.39.43 # theorically I think I could 02.39.59 # but probably not easy to do :) 02.40.22 Join webguest22 [0] (n=8eb14de9@gateway/web/cgi-irc/labb.contactor.se/x-e2a03e6a0d7a035e) 02.40.23 # yes, except obvious lcd/buttons/light, and some GPIO mappings (radio, usb ..) 02.41.03 # Unhelpful: I found 3 places in the core where 1< What timezone are the logs in? 02.41.21 # CEST i believe 02.41.24 # funman: have we tried with a smaller PCM buffer? 02.41.27 # amiconn: bmp.c as well :) 02.41.46 # fdinel: i haven't looked at this code since i came back to rockbox coding and playback worked fine :) 02.42.12 # I think the code is in apps/pcmbuf.c 02.42.51 # Unhelpful: Oh? I wonder why my regex didn't find this... 02.42.53 # also firmware/drivers/lcd-1bit-vert.c... oddly i didn't note any binsize delta for the ones in ata.c or thread.c 02.43.23 # I searched for 1\w*<< 02.43.40 # i used something rather long and complicated, and still hit more than a little noise: egrep -i '(^|[^0-9a-zA-Z])1(lu?|ul?)? *<< *' -r * | egrep -vi '(^|[^0-9a-zA-Z])1(lu?|ul?)? *<< *[0-9]|^(tools|utils)' >../rockbox_bitn_search 02.44.16 # * amiconn doesn't understand why Unhelpful writes (u)l for integers 02.45.00 # anyone have any ideas as to why the bootloader on e200v2 can't find rockbox? 02.46.16 # habit of overspecifying, i suppose. will 1<<31 still "work"? i guess i wasn't thinking of left shift as sign-agnostic, but it won't clear the 1 when it moves into the sign bit, will it? 02.46.36 # 1u would suffice 02.48.02 # It's a bit nasty anyway, as (1) 1(u)l is 64 bit in 64 bit sims, but (2) 1(u) is just 16 bit on 16 bit targets (which were in the works once, but never finished, and have been dropped) 02.49.22 # i know, there aren't const suffixes that specify a size consistently. for that matter, there aren't type qualifiers that do so either, but at least stdint.h/inttypes.h handle those. 02.50.28 # i've seen more than a few instances of long where int32_t/uint32_t might be more appropriate... DB seek values, for example. we are never going to deal with a DB file of more than 4GB :) 02.51.02 Quit funman ("'night") 02.51.17 # I formatted/reset the player to factory defaults, changed to MSC mode, and extracted my fresh compile of .rockbox, and yes I make zip'd it first. I can get it running on my Fuze, but on this one, it cant find the files. 02.51.40 # Well, on target 'long' *is* int32_t. Then, inttypes where a quite late addition in rockbox. 02.52.39 # amiconn: on target, it is. there was a PF crash on sim, though, that turned out to be due to an array of longs allocated from the plugin buffer being the size of the entire plugin buffer on 64-bit CPUs. 02.54.20 # i should probably ammend the 1LU to 1U in the BIT_N definitions, in case it would lead to problems on sims. should the rest of the stuff wait until post-freeze, since it's only binsize savings? 02.58.18 # funman is the right bahviour to go from 62hz to 248hz on and off while playing? 02.58.58 # and is monitoring the cpu in debug a little sketchy? 02.59.00 # New commit by 03unhelpful (r21197): Replace 1UL in BIT_N with 1U to avoid turning it into a 64-bit operation on 64-bit sim targets. 03.00.36 # amiconn: i suppose something along the lines of (u)int*_t could be provided for constants, not that it really matters until we get a target where the default size for ints isn't 32-bit. 03.01.01 Quit webguest22 ("CGI:IRC (Ping timeout)") 03.02.59 # something along the lines of #define U32(n) (n ## u) 03.04.09 Quit Thundercloud (Remote closed the connection) 03.04.38 # notlistening: yes that is the way it works, it's cycling between fastbus and synchronous bus 03.07.02 # notlistening: it should only be boosting during the disk accesses though as it can play mp3 unboosted 03.08.31 Join hd [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 03.08.36 Quit Rob2222 (Read error: 110 (Connection timed out)) 03.08.41 Quit HellDragon (Read error: 104 (Connection reset by peer)) 03.09.12 # notlistening: sorry, that's with FS#10048 that it's unboosted, svn still boosts regularly as the mmu is not operating 03.10.48 # is there a way to disable apps/bookmark.c? 03.11.34 # sorry, those are just warnings 03.11.54 # filetypes.c:98: error: 'LANG_FMR' undeclared here (not in a function) 03.17.28 # Unhelpful: Of the 3 places in ata.c, only one affects sh1 03.18.06 # It looks like changing one place saves ~8 bytes. Changing a single place might get unnoticed because sh1 uses 16 byte section alignment 03.18.55 # * amiconn finally has a regex pattern that actually works 03.19.24 # 1u?l?u?\s*<<\s*[()a-z] (case insensitive; I'm using a graphical grep tool) 03.20.10 # Iiuc your method only finds a single '1', but not e.g. 0x1, 0x01 etc 03.20.16 # where do you check build status? 03.22.17 # amiconn: indeed... my intent was to exclude identifiers such as val1. i found a few 0x1 also, though. perhaps add a (^|\s|[|-+&~])(0x0*)? to the front? 03.23.30 Quit hd (Client Quit) 03.23.35 Join HellDragon [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 03.27.22 Quit Llorean (Connection reset by peer) 03.27.49 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 03.28.05 # * amiconn notices that for the 1 bit lcd driver, a char array would work better 03.29.07 # It saves the 2-bit left shift when converting the array index to an address. Only works for indices 0..7, but that would suffice there 03.30.02 # i suppose that a mod to struct screen would require a plugin API bump, since those are exposed in the API? 03.31.28 # essentially, for style hooks to be useful to plugins, they'll need access to lcd_putsxyofs. i could add it to the plugin API, but i gather that things like that are "supposed" to be accessed through rb->screens? 03.38.40 # Actually, scratch that. While it would save the shll2, it would in turn require an extu.b 03.39.23 # Otoh, loading a 32 bit value from memory requires two memory cycles (unless the data is in iram) 03.42.56 # Access to drawing functions is still a mix. Most plugins use lcd_* functions directly. This makes them not support remote displays though 03.43.00 Quit stripwax ("http://miranda-im.org") 03.46.25 # i'm not initially supporting style hooks on remotes, anyway. it takes a hook in scroll_fn and in puts_style_offset, and a support function to set the hook per-screen. the total cost is ~100B on sh, which is where i had been having the largest trouble before when using a separate hook for background clearing, text drawing, and updating. 03.47.11 # also, they're not of much use without either greylib or a color display, and i don't think we have either on a remote anywhere (excepting m3, which treats that as the main display) 03.48.26 Quit moos ("Rockbox rules the DAP world") 03.48.57 Join TPMF [0] (n=Alex@71-8-9-189.dhcp.leds.al.charter.com) 03.50.42 # it got a *lot* smaller when i changed it to a single hook function, only supported on the main LCD, that is called in lcd_scroll_fn or puts_style_offset in place of puts_xyofs. 03.54.20 Quit pano (Remote closed the connection) 03.55.27 Quit _lifeless (Read error: 110 (Connection timed out)) 03.57.23 Join jimmx2 [0] (n=6178d55e@gateway/web/cgi-irc/labb.contactor.se/x-890ba4121fc6b92f) 03.57.31 Quit chandoo (Read error: 104 (Connection reset by peer)) 03.58.20 # frist time installing rockbox....Perfect! love it 03.59.05 # btw the installer worked great on my vista64 03.59.20 Quit kkurbjun (Read error: 110 (Connection timed out)) 04.01.34 Quit jimmx2 (Client Quit) 04.01.44 # is there anyone here how is willing to make a new audio codec? the file type is drg. 04.01.53 # drg? 04.02.09 # oh, Idoser/ 04.02.22 # yep, glad you reconize 04.02.36 # im playing around with it a bit 04.02.46 # Hmm..Would be illegal 04.02.49 # TPMF: idoser is a proprietary rip-off of sbagen. drg files are sbagen scripts with (rather bad) drm added. 04.03.02 # Would be illegal anyway 04.03.15 # ahh, i see 04.03.21 # not to mention the scripts they sell for it are not useful for much of anything except placebo effect. 04.03.21 # thanks anyway 04.03.22 # There license proly says a thing or two about reverse engi 04.03.27 # Unhelpful: yeah :P 04.03.52 # If you meditate anyway, its proly no harm 04.03.59 # Just good whitenoise 04.04.09 # hadn't heard of sbagen 04.04.43 # Idoser also likes to try to sell headphones and stuff to you 04.05.11 # but that's getting offtopic. 04.05.16 # yes 04.05.18 # slyyx: sbagen is GPL, i don't think idoser *can* say much about reverse engineering, at least not and make it stick. but this is getting offtopic. ;) 04.05.19 # ture 04.05.22 # true* 04.05.32 # Unhelpful: Reversing there cheap drm though? 04.05.52 # hate drm, or any restrictions on music 04.06.06 # which is why i got Rock Box in the first place 04.06.09 # Anyway TPMF, the answer is no..unless you want to do it yourself. 04.06.20 Join onlysoaa [0] (i=42248748@gateway/web/ajax/mibbit.com/x-678649caf1207e2c) 04.06.32 # i was concidering it 04.06.50 # Make sure you look into anything legal about it. GOod luck 04.07.08 # k thanks 04.10.13 # * slyyx reads myself in irc logs... 04.10.16 # er 04.11.14 # Any of you have a good arm (free) disasmbler? 04.11.25 # Harro slyyx, I believe you were looking for me... 04.11.29 # like the one in the dev tools? 04.11.39 # onlysoaa: Hey, yes 04.11.47 # I did some work with the p2 a few months ago 04.11.52 # The one in dev tools is worked pretty well. 04.11.54 Join dmb [0] (n=dmb@unaffiliated/dmb) 04.11.56 Quit TPMF ("Leaving") 04.11.57 # Oh? 04.12.00 # Yeah 04.12.07 # What'd you accomplish? :P 04.12.08 # I got about were you are 04.12.17 # I got the LCD timings to work. 04.12.22 # Perfectly? 04.12.25 # I got em almost. 04.12.31 # I do not have my codebase anymore... 04.12.35 # I take it you didn't really read the logs. :P 04.12.47 # I got the timings to work to the extent of showing an undistorted image. 04.13.03 # Yeah, I forgot, I recall doing that, but the colour being off 04.13.21 # People will get annoyed, come talk in another channel 04.13.23 # The problem now is that the image is greenish. 04.13.50 # join #onlysoaa 04.13.52 # Why? This is Rockbox development. :P It'll go in the logs for whoever needs to refer to them later on. 04.14.04 # I hate being logged :P 04.14.14 # esp google indexed logs 04.14.23 # Oh come on, this is open development for the benefit of everyone. xD 04.14.28 # Anyway, do you have a patch for me? 04.14.42 # It's in flyspray. Just search for YP-P2 and you'll find it. 04.14.51 # Did you get my datasheet for the lcd btw? It should be on the wiki. 04.15.20 # Indeed I did! You're the one who posted it? ;D Thanks a bunch, although I didn't have much use for it yet. 04.15.44 # Long story on how I found it.... 04.15.46 # Everything seems to be set in the TCC7801's LCD controller so far. 04.15.52 # yeah 04.15.57 # I put it there just in case 04.16.08 # I wonder if the LCD settings can fix the colors though? 04.16.38 # ...then again, I doubt it, as the LCD controller is the one outputting the rgb666 data. 04.16.46 # I can mess with your patch...I hate the process for getting the firmware to load onto the p2..afraid I am going to break the reset button one of these days 04.17.04 # The controller -should- shift the bits from the rgb565 data in the framebuffer, but for some reason, it doesn't. 04.17.25 # Haha, I hope that button is durable. 04.17.37 # Hold on a sec, I'll post an updated patch. 04.17.42 # k 04.17.49 # I changed some timings to get the image aligned properly. 04.18.06 # yeah, I recall having that same issue, and fixing it... 04.18.15 # Lots of tweaking and resetting :P 04.18.53 # Yeah. The OF is either really obscure or we're just inexperienced. :P 04.19.38 # I think the latter of the two :P 04.20.18 # * slyyx ..tries to remember the reset process for the p2.. 04.20.29 # Hold down pwr and reset? 04.20.49 # ..yup 04.21.20 # ..make 04.21.48 # we don't really need the play-by-play 04.22.28 # onlysoaa: See :P 04.22.43 # That's just you. :P 04.22.51 # That "make" was actually a question 04.23.13 # What build system is this on? 04.23.22 # Well all you do right now is run configure and make. 04.23.36 # Target 143, Samsung YP-P2. 04.23.44 # in which folder? 04.23.59 # It's in /firmware/target/arm/tcc780x/ypp2 04.24.27 # k 04.25.07 Quit saratoga ("http://www.mibbit.com ajax IRC Client") 04.35.30 # Oh, oops. Alright, the new diff is posted. slyyx, check it out. 04.35.34 # I'll be right back. 04.36.39 *** Saving seen data "./dancer.seen" 04.38.00 Join andrew[andrboot] [0] (n=andrew-f@unaffiliated/andrewandrboot/x-689432) 04.41.37 # onlysoaa: lcd works now? 04.43.01 Part andrew[andrboot] ("Leaving") 04.43.35 # onlysoaa: and is it packed (16-bit) or not (32-bit)? 04.43.49 # I can check 04.44.03 # I have the datasheet around here somewhere... 04.47.56 # I'm bacl. 04.49.23 Quit notlistening (Remote closed the connection) 04.49.25 # back*. tmzt, what are you referring to when you're asking if it's packed or not? 04.49.45 # the bytes, if it's rgb666 it can't be 16-bit 04.50.04 # Well that's the output from LCD controller to LCD. 04.50.05 # the interface for the lcd is 8bit if that means anything... 04.50.09 # well, it can but then it has to scan out more than is in the framebuffer 04.50.27 # It reads from the framebuffer in rgb565 though. 04.51.34 # The problem seems to be that the LCD controller doesn't convert from rgb565 to rgb666 properly. 04.52.12 # The actual lcd is 24bit 04.52.21 # 8bits per color 04.53.00 # Perhaps it's a configuration thing, but I didn't see anything relevant to that in the TCC docs. 04.53.51 # Well it seems that the P2's LCD is hard-set at rgb666. 04.54.55 # It uses only 6 of the 8 pins per channel for the connection, and displays things way off when I use rgb888 output. 04.55.34 # Oh, ok 04.55.49 # Less pinouts I guess 04.56.16 # Less colours as a result though 04.56.51 # i've noticed a few exceptions to "no typedefs in rockbox", mostly for function pointers. i suppose adding one more wouldn't really be a big problem, especially if it saves duplicating the argument list of the function all over the place... 04.57.05 # In any case, it seems that we need to find how to make the LCD controller shift the R and G channels << 1. 04.59.53 # I am still trying to make my build system work...still says I do not have arm gcc 05.01.28 # there 05.02.37 # Guys: Any reason why it would inform me that I do not have lang.h? 05.05.06 # I have something similar LANG_FMR seems to be missing, even after running configure 05.05.33 # building for fuze 05.05.52 # Oh! Before compiling for the P2, remove all contents of apps/plugins/SOURCES and SUBDIRS. 05.06.06 # ...How abnormal 05.06.39 # Plugins don't have support for the P2's screen resolution yet, so they'll throw all sorts of errors. 05.07.55 # Oh yeah, I remember that 05.10.15 # onlysoaa: You forgot to make a keymaps file btw 05.10.50 # many of them won't care. pictureflow should compile just fine. 05.11.18 # I just touched it (SEE: touch), works now 05.11.55 Quit n1s (Remote closed the connection) 05.12.19 # Unhelpful: Did you forget to include some config file or something? 05.12.36 # also, you might look at converting the data when it's sent to the LCD, unless the LCD controller supports correct conversion from rgb565. the correct conversion would be (c << 1) | (c >> 4) 05.13.30 # Alright, feed it one bit shifted, gotcha 05.14.03 # Unhelpful: does rockbox only support 16bit then? 05.14.39 # rockbox should also have a grayscale mode for some 05.14.46 # tmzt: somebody could write an 18-bit LCD driver. we don't have one yet. :P 05.15.19 # Unhelpful: Yeah, this thing does not want to build 05.15.29 # Even if we write an 18-bit LCD driver, it won't do anything. 05.15.51 # And oops @ keymap file. Copy the D2's and rename it keymap-ypp2.c 05.15.57 # ah 05.16.07 # onlysoaa: what exactly do you mean, it won't do anything? it would not be so hard to support 18-bit bitmap data. :P 05.16.54 # What I mean is that the LCD controller supports only 1, 2, 4, 15, 16 and 24 bit input. 05.17.13 # And we already know that it must output 18-bit to work. 05.17.16 # I'll be right back. 05.18.04 # Basically, we need to feed the controller 24bit input, that is actually shifted 18bit...I think 05.18.07 # onlysoaa: yes? 05.18.22 # ah... and it doesn't properly handle 16-bit input? 05.18.34 # Apparently 05.18.51 # If I understood what he told me 05.19.23 # So we give the controller shifted 18bit, so it can give the actual lcd 18bit... 05.19.56 # onlysoaa: button-ypp2.c is broken 05.20.58 # or..no... 05.21.02 # well, we have lots of code already for handling 16-bit. so you could also use that, and convert to 24-bit before sending it to the LCD. or you could use 24-bit, and send it directly to the LCD. 05.21.13 # I think we need to feed the controller 24bit, which is shifted 16bit. 05.21.20 # yeah 05.21.22 # 18-bit sounds like a *huge* pain (because it's not a whole number of bytes) 05.21.30 # Unhelpful: We can just hand it 16bit though 05.21.38 # Indeed. :P 05.21.43 # as long as the controller gets valid 24bit, apparently 05.21.52 # How is button-ypp2.c broken? 05.22.04 # Complains that everything is a redeclaration 05.22.33 # You including some file twice? 05.23.15 #