--- Log for 22.02.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 18 days and 15 hours ago 00.00.18 # Ah. With calendar.c modified to use fdprintf(), it now compiles to the end... 00.00.41 Quit amiconn (Nick collision from services.) 00.00.42 Nick amiconn_ is now known as amiconn (~jens@pD9E7FF98.dip.t-dialin.net) 00.01.26 # forget the calendar problem... there is a problem with recursive insert! 00.02.35 # then fix it! ;-) 00.04.52 Part hubble 00.07.22 # amiconn: I'll make a little fix I think may fix the icon/image too 00.07.45 # Should I wait? I was about to apply simfix-10 00.07.56 # try the -11 instead 00.09.54 # Building... 00.10.30 # Linux host detected 00.10.33 # Enabling win32 crosscompiling 00.10.37 # Using i386-mingw32msvc-gcc 2.95.3-6 (295) 00.10.42 # elinenbe: can you explain what is wrong with the insert? 00.11.19 # almost worked! 00.11.43 # elinenbe: ok, i see it 00.15.14 # Bagder: Still those 'conflicting types for built-in function' warnings, and a couple other. I'll try again with reconfigure... 00.15.56 Quit Chamois ("CGI:IRC") 00.16.42 # hehe, ftruncate() is defined to NULL in the old sim 00.17.02 # but no plugin uses it 00.18.50 # wow, it actually compiled 00.18.51 # o.o 00.18.55 # without any compiler errors. 00.19.04 # no internal compiler errors 00.19.05 # i mean 00.19.42 # Bagder: Some warnings remain (in plugin.c and uisimulator/win32/io.c), and the image & icon are still missing 00.20.10 # I ignore the warnings for now, focusing on getting the build on all combos 00.21.19 # woot. 00.21.21 # what does this mean xD 00.21.30 # I0B:Line-F 00.21.35 # You can leave the Win32 specific warnings for me to fix. However, I don't understand one of the warnings in abovementioned io.c 00.21.36 # at 30066BB8 00.21.53 # HCl: illegal opcode 00.21.54 # HCl: That means an illegal 68k instruction 00.21.59 # okay XD 00.22.16 # thanks. 00.24.12 Join webguest83 [0] (~447ad93b@labb.contactor.se) 00.24.38 # Bagder: Rather, I understand the warning, but don't know the best way to fix it. Somehow this file needs the struct plugin_api declaration... 00.26.53 # Tremor doesn't build cross-compiled for win32 ;-) 00.26.55 Quit Sucka`away ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 00.27.13 # looks like a C99 requirement 00.27.15 # Bagder: Similar warnings when building the X11 sim with cygwin 00.27.32 # Bagder: Did you try the iriver sim? 00.27.37 # yes 00.27.57 # works fine, except the win32 crosscompile 00.28.01 # I could try the same. Do you have an idea what causes the still missing bg image + icon? 00.29.02 # not really, my win32 build at least builds a uisw32-res file... 00.29.05 # uh 00.29.12 # does it need to be name like the output perhaps? 00.29.25 # Nope 00.29.29 # I don't know much about resource files 00.29.47 # You renamed the .exe a while ago, it still had image + icon 00.29.59 # ah, I fixed a little thing 00.30.05 # $(WINDRES) --include-dir $(OBJDIR) -i $< -o $@ 00.30.14 # is the new line, in win32/Makefile 00.30.36 # Currently building iriver-win32 sim, to check whether tremor builds... 00.30.54 # you have a newer gcc than my win32 00.31.07 # so it might just work fine 00.31.43 # * HCl goes to figure out whats wrong with his opcode 00.34.11 # Bagder: Building tremor only shows a line 'AR /home/Administrator/rb-patched/simulator-build/iriver/libTremor.a' !?? 00.34.57 # mpa2wav.c errors out 00.35.11 # mpa2wav.c:94: undefined reference to `_mad_stream_init' 00.35.16 # mpa2wav.c:63: undefined reference to `_mad_stream_buffer' 00.35.36 # well, those are issues beyond this current work 00.35.50 # Yes of course. Only wanted to mention that 00.36.13 # The important thing is that the simulator itself and most plugins build, and work 00.36.21 # yes 00.36.31 # The rest is then solved case by case 00.37.53 # Bagder: Haha, funny: 'make install' now copies the executable into archos/ on the sims... 00.38.08 # oh 00.38.16 # very useful! 00.38.18 # :-P 00.38.53 # Hmm, plugins don't work on both sims... :( 00.39.00 # hm. 00.39.05 # elinenbe: i have fixed the recursive insert, please try the next bleeding edge, or tomorrow's daily build 00.39.07 # The X11 sim says 'Win32 error 5' 00.39.46 Join AC [0] (~5078751e@labb.contactor.se) 00.39.50 # hi 00.40.42 # so, I'll hold off the commit 00.40.47 # AC: Hi. How are things with wv? 00.41.55 # linuxstb: i should have it in about 30 mins 00.42.04 # i don't get this... 00.42.09 # DOH> 00.42.12 # nevermind >.> 00.42.15 # AC: Any indication of decoding speed yet? 00.42.27 # * HCl kind... of... forgot the return instruction at the end of a dynarec block >. 00.42.43 # Bagder: The plugins miss the "execute" permission. I had that before with the Win32 sim, but not the X11. When I manually change that, they work... 00.43.16 # linuxstb: not yet... in a few minutes 00.44.12 # amiconn: ok, I duplicate the logic for it 00.45.58 # And I found the problem with the missing image / icon: You do not link with uisw32-res.o ... 00.46.03 # linuxstb: the line that says "Speed" in the *2wav viewers, is that % of realtime? 00.46.33 Join ashridah [0] (ashridah@220-253-121-237.VIC.netspace.net.au) 00.46.43 # amiconn: I need to add that special somewhere? 00.47.19 # This needs to be linked to the sim executable. 00.49.34 # but I don't see why it isn't 00.49.58 # It does not appear on the linker command line... 00.50.23 # no, since it is in the libsim.a 00.50.45 # try 'ar tv libsim.a' to view the contents of it 00.51.24 # Yes, it's there. However, this may not be enough 00.51.58 # The old build included it directly in the linker command. Maybe there is a special way to tell the linker to use this version from libsim.a 00.52.36 # Btw, I can't find the place where the executable is linked. Is that now part of apps/Makefile? 00.53.15 # is there a way to debug a plugon on the iriver? 00.53.20 # amiconn: yes it is 00.53.38 # I like the new look on the cvs table while a build is in progress! 00.54.48 # crappy estimate though 00.54.50 # :-) 00.54.59 # if I want to add a few functions that should be used by all codecs libraries, do I need to create a separate library? 00.55.11 # AC: Not really. You could open a file and write debugging information to it - or display information on the LCD. 00.55.43 # linuxstb: ok 00.55.46 # AC: simple plugins can be run in the simulator, but I guess yours isn't ;-) 00.56.05 # Bagder: That's it. I added the .o directly on the linker command line as a test, this works 00.56.24 # * rashur wonders how much it'd cost to transfer money directly to a Swedish bank account 00.56.25 # ok, then we just need to make that happen in a nice way 00.56.46 # Or find out how to link kin a resource from a library 00.56.55 # *link in 00.57.05 # semms that there is an error in WavpackUnpackSamples function... will look closer at it 00.57.27 # rashur: probably not that much from .dk 00.57.44 # I need to sleep now 00.57.49 # That's what I figured. And I'm not too keen on paypal really. 00.57.58 # Bagder: No commmit? 00.58.10 # AC: Does your plugin crash at the moment? 00.58.14 # I don't feel like sitting up fixing the quirks now 00.58.19 # I'll try to do it tomorrow 00.58.32 # linuxstb: yep... i am looking at the moment why 00.58.48 # Bagder: Hmm, okay :-/ (no offense) 00.58.48 # linuxstb: i know where it crashes 00.58.57 *** Saving seen data "./dancer.seen" 00.59.05 # amiconn: worst case, you can do the commit, there's a fresh patch uploaded 00.59.19 # AC: Does it make use of the stack? If I remember correctly, the stack is currently about 32K. 00.59.33 # good night 00.59.35 # Bagder: I think it's easier to fix the quirks within cvs 00.59.48 # amiconn: it is 00.59.55 # feel free to commit if you want to 00.59.57 # Does it at least build on Linux 00.59.58 # ? 01.00.04 # yes it does 01.00.10 # linuxstb: it looks now much better... 01.00.10 # both plain and sim 01.00.53 # linuxstb: it is not working atm, but i got a step into the correct dir 01.01.06 # Hmm, maybe I should stop here too for today. I'd say commit tomorrow, and then we fix the quirks 01.01.07 Quit webguest83 ("CGI:IRC (EOF)") 01.01.15 # * HCl sighs. 01.01.16 # okay. 01.01.19 # i'm at the point 01.01.25 # where i just need an assembly-level debugger 01.01.25 # Bagder: Good night. 01.01.26 # :( 01.02.01 # I have created a few simple functions for profiling that use e.g. file.h, sprintf.h from rockbox 01.02.14 # these should be used by the codec libraries 01.02.15 # Bagder: I'll check for that odd windows linker problem meanwhile 01.02.50 # can someone point me into a general direction how to get access to these from the codec libraries? 01.03.40 # at the moment I get undefined references 01.03.51 # when linking 01.04.07 # You cannot use these rockbox includes directly from within plugins 01.04.20 # Instead, you have to use the plugin api 01.04.32 Quit pillo (Read error: 110 (Connection timed out)) 01.04.40 # These are used in the codec libraries... 01.04.49 # not in the plugin itself 01.05.03 # Yes, and the codec libraries are use from within the plugins... 01.05.15 # The codec libs are never linked against core rockbox 01.06.08 # sometimes it is nedded 01.06.17 # can I access the plugin api from within e.g. libmad? 01.06.21 # e.g. strcpy 01.06.34 # it would be nice, if i could use it in the codec 01.06.48 # well you'll pretty much have to, heh 01.06.54 # Hmm. I don't know how it is adapted currently. You would need a copy of the plugin api pointer 01.07.03 # i don't think the ordinary functions are even available 01.07.16 # The current system is just temporary - there will be a "codec api" which will give codecs access to the standard functions like "strcpy" etc. 01.07.25 # fine 01.07.40 # so at the moment it is not possible? 01.07.42 # The only other option is to compile and link a private version, but that's ugly imho 01.07.54 # yes, it is 01.08.04 # For the moment, I have just implemented wrappers in plugins/lib/xxx2wav.c for functions like memcpy, and also added a simple malloc implementation (without free). 01.08.46 # linuxstb: How do you wrap? 01.09.26 # linuxstb: i could add the profiling functions there too and access them from within the codec library? 01.09.39 # hrm 01.09.48 # perhaps i should try coding my profiling idea 01.10.08 # amiconn: the codecs libraries themselves include firmware/include/*.h, and then I implement those functions in xxx2wav.c by calling rb->??? 01.11.43 # In the plugins, you don't need to include these. Plugins are allowed to only ever include plugin.h, or priovate include files. They must not include other rockbox includes 01.12.21 # The question is, how do you wrap these function in the codecs? 01.14.47 # You can use rb->* in the codecs too, but that means your test plugins always have to have a global plugin api struct pointer, and it always needs to be called rb 01.15.06 # I think this is okay for the test plugins 01.15.36 # so i can use strcpy via the plugin api? 01.16.06 # If you want a somewhat cleaner implementation, look at the grayscale lib. This lib has its own private plugin api pointer, and an init function to provide its value 01.16.45 # AC: Yes, your "wv2wav" program can use the plugin API, but the code in codecs/libwavpack/ can not. Have a look at the code in apps/plugins/lib/xxx2wav.[ch] to see what I did for similar functions. 01.17.23 # I still think of this as a temporary solution until the codec API is written, which will give the codecs access to libc type functions. 01.17.54 # ok 01.18.12 # linuxstb: I am trying to add them to xxx2wav.h and use the plugin api 01.18.51 # linuxstb: they are only temporary anyway I think 01.19.03 # Patr3ck: the problem with that is that the codecs shouldn't really be including xxx2wav.h 01.19.42 # linuxstb: ah, too bad, only the plugin itself should do that? 01.20.14 # It's a bit like a system library including part of your application. 01.20.24 # yes 01.21.08 # I could wait, but performance measurement would be helpful now 01.21.36 # linuxstb: I just found that you define dprintf(). Imho this shouldn't be necessary, you can use debugf() 01.22.35 # amiconn: Does debugf do the same as my dprintf? 01.23.12 # Almost. It does printf() in the simulators (unless you hook a win32 sim into a windows debugger) 01.23.31 # OK, I'll change to use that then. Thanks. 01.23.35 # On the target, it does the same (i.e. nothing) unless you create a debug build 01.24.19 # A debug build can actually output this using a gdb stub. I know, no such stub does exist yet for iriver. 01.25.29 # mmmm. 01.25.31 # tell me about it :/ 01.25.46 # HCl: There is a debug stub for archos... 01.25.48 # Patr3ck: I agree it would be very helpful to have your code and start profiling, I'm just not sure of the best way to incorporate it into Rockbox. Maybe put "profile.h" and "profile.c" in apps/codecs, and then apps/codecs/Makefile would compile it, and make it available to be linked against the ???2wav plugins. 01.26.02 # amiconn: tell me when you got some free time to help me with rockboy a bit... 01.26.11 # is it hard to generate an address map of all rockbox functions? 01.26.17 # i think i need a bit of help with debugging it 01.26.22 # i'd pretty much need that for the profiler 01.26.48 # preglow: When you compile, a .map file should be created too... 01.27.22 # However, it does only list global functions. Statics are left out 01.28.05 # amiconn: yes, so it seems... 01.28.12 # hmm 01.28.16 # that might be a show stopper 01.28.47 # linuxstb: I will try that 01.29.46 # hrm 01.29.48 Nick rashur is now known as rasher (~rasher@62.79.64.148.adsl.hs.tiscali.dk) 01.29.49 # better. 01.29.58 # amiconn: no codec symbols are included, and that's pretty much the reason i want to make a profiler 01.30.59 # linuxstb: but I am wondering how this would give me access to the rockbox functions 01.31.21 Quit Renko ("Leaving") 01.35.24 # Linus: Maybe it is better to set ICR register each byte long, and have all 12 different ICR register than 4 compound ones as now? 01.35.39 # #define ICR0 (*(volatile unsigned long *)(MBAR + 0x04c)) 01.35.40 # #define ICR4 (*(volatile unsigned long *)(MBAR + 0x050)) 01.35.40 # #define ICR8 (*(volatile unsigned long *)(MBAR + 0x054)) 01.35.40 DBUG Enqueued KICK XShocK 01.35.40 # #define ICR6 (*(volatile unsigned long *)(MBAR + 0x052)) 01.36.59 # Patr3ck: You're right, it wouldn't. 01.37.00 # ICR6 was added by me, so it is not in rockbox in cvs 01.37.16 # the internal register map is not byte addressable 01.37.36 # aa ok. didn't think about that. 01.40.17 # linuxstb: seems there is no clean solution at the moment 01.40.54 # Patr3ck: No. If I was you, I would just do an "unclean" solution for now, and we can try and think of something clean later. 01.42.18 # linuxstb: for now it seems wrapping the needed functions in xxx2wav.h and including this in the codec library is the only working way 01.46.40 # woot, iram for codecs 01.46.42 Quit AC ("CGI:IRC (EOF)") 01.47.21 # speed test it, quick! 01.47.23 # :) 01.48.19 Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") 01.48.34 Join AC [0] (~5078751e@labb.contactor.se) 01.50.53 # Does the coldfire have a cache? I guess so... 01.51.01 # amiconn: instruction cache 01.51.14 # Ah, so this may be HCl's problem... 01.51.19 # LinusN: thanks so much... works great for me! 01.51.20 # what? 01.51.25 # amiconn: indeed 01.51.28 # what? 01.51.40 # o.o 01.51.41 # amiconn: plus there's 96kbyte of iram that's single cycle access 01.51.51 # HCl: The coldfire has an instruction cache. Doing dynarec is the same as having self-modifying code... 01.52.06 # well, yes. but. um. huh? 01.52.19 # how does that relate to what i'm doing? 01.52.26 # You need to invalidate the cache in order to tell the cpu to re-read from memory 01.52.41 # no, it's not really the same at all, i think 01.53.07 # i'm sort of doing the same thing when loading a module 01.53.15 # except i'm not loading code from disk but writing it on the fly 01.54.29 # Yes, that's correct. However, if you load a new module, the area was not previously cached 01.55.08 # And if you load a new module in place of an old one, this may indeed cause the same problem 01.56.07 # That just came to mind as I read a bit about a ZX Spectrum emulator for the Amiga. 01.57.10 # LinusN: Does rockbox already handle these caching issues? 01.57.26 # um... 01.57.36 # what do you mean the area was not previously cached... 01.57.46 # amiconn: the cache is invalidated when loading plugins 01.57.59 # LinusN: where's the code for invalidating the cache..? 01.58.12 # system.h 01.58.15 # kay.. 01.58.22 # but i don't think it has to do with it though 01.58.28 # cause earlier i got an invalid opcode error 01.58.31 # and now it just freezes 01.58.42 # i added a return from subroutine opcode to it.. 01.58.49 # HCl: You may need to call that every time you compile a new sequence 01.58.55 # amiconn: yea, i get the idea 02.01.21 # kay, i added that. 02.01.38 Quit Patr3ck () 02.03.10 # LinusN: I guess using invalidate_icache() is okay within plugins, as it is an inline function anyway? 02.03.23 # yes 02.03.27 # gotta go to sleep 02.03.32 # cu tomorrow 02.03.36 # good night 02.03.39 Part LinusN 02.03.58 # nop, freezes 02.06.11 # amiconn: what're your experiences with casting an int to a function and calling it.. could you just return from it normally..? 02.06.13 # sleep? 02.06.26 # how dare he sleep. he must work 24/7 on iRiver! :D 02.06.56 # HCl: Yes it worked. However, I changed that meanwhile if you have a look at apps/plugins/rockboy.c 02.07.13 # Now I use a struct instead of an array, within the correct pointer type 02.09.35 # linuxstb: what efficiency did flac2wav have again? 02.10.27 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 02.10.27 # * rasher feels sortof silly spending a few hours decoding an mp3 02.10.28 # k.. 02.10.33 Join mecraw [0] (~mecraw@c-24-9-220-243.client.comcast.net) 02.10.58 # Mostly because I have no idea why I started it. 02.12.31 # oh.. well.. yea. 02.12.32 # i'm dumb. 02.12.33 # o.o 02.12.41 # * HCl thinks he found the bug ^^ 02.12.56 # hm, wait, nm :/ 02.13.56 # * AC needs help 02.14.09 # warning: this decimal constant is unsigned only in ISO C90 02.14.21 # warning: integer overflow in expression 02.14.30 # min_shifted = (min_value = -(long)2147483648 >> shift) << shift; 02.16.19 # ugly code.. 02.16.29 # >.< 02.16.40 # first of all 02.16.44 # not mine... libwavpack 02.16.45 # get the min_value bit out 02.16.53 # and make min_shifted = min_value << shift; 02.17.25 # preglow: It's somewhere between 7% and 8% of realtime for my tests. I think Linus said it was about 90% at 140MHz. 02.17.43 # just tested it at 6.50 here :/ 02.17.57 # does --best encoding give more lpc frames? 02.18.01 # I must have a faster iRiver then :-) 02.18.05 # and isn't it better to make that 2147483648 be 0x80000000 02.18.31 # XShocK: LONG_MIN even better 02.18.41 # XShocK: i dont know... 02.18.52 # preglow: yes. 02.19.01 # preglow: I forget the details, but http://flac.sourceforge.net/ has excellent documentation. "man flac" is also good. 02.20.10 # where is LONG_MIN declared? 02.20.22 Quit mecraw () 02.20.38 # --best sets max order lpc = 12, hyes 02.20.47 # AC: limits.h, might not be in rockbox for all i know 02.21.21 # preglow: According to the man page, "--best" is equivalent to "-8", which means it searches for order-12 lpc predictors. 02.21.30 # preglow: so we need now a limits.h 02.22.18 # AC: just use 0x80000000 02.22.32 # preglow: ok 02.28.33 Quit edx (Read error: 110 (Connection timed out)) 02.35.07 # MP3 b4 everything! ;) 02.41.19 Nick MO-Pantsu is now known as DeadMan (Rori@deadman3000.plus.com) 02.46.40 # but bed 02.46.53 Quit preglow ("omglolmao") 02.48.36 # Linus: I think it does support byte addressing, and each different ICR can be done as in move.b d0,($40000053).l in original firmware 02.49.24 # oops, didn't realize that he is gone 02.58.26 Quit AC ("CGI:IRC (Ping timeout)") 02.59.00 *** Saving seen data "./dancer.seen" 03.03.32 Quit amiconn (" HydraIRC -> http://www.hydrairc.com <- Leading Edge IRC") 03.05.46 # anyone fancy a giggle? beware contains adult content http://home.comcast.net/~furrbear/PhuckaMon/flx2.swf 03.26.59 Part Bluechip 03.34.46 Join StrathAFK [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) 03.34.56 Quit Strath (Nick collision from services.) 03.34.58 Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a239.wi.tds.net) 03.47.15 Join bagawk [0] (Lee@bagawk.user) 03.48.34 # [IDC]Dragon, hey 03.56.55 # Me have forums :) http://leepil.dyndns.org/phpbb2 04.03.38 Quit bagawk ("Leaving") 04.09.57 Join edx [0] (edx@pD9EAAF32.dip.t-dialin.net) 04.21.18 Quit skav () 04.29.09 Quit YouCeyE ("Leaving") 04.34.18 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") 04.59.01 *** Saving seen data "./dancer.seen" 05.00.05 Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) 05.44.00 Quit cYmen ("leaving") 06.01.29 Join YouCeyE [0] (foobar@vp089036.reshsg.uci.edu) 06.35.02 # Sortof off-topic, but what could be wrong when the iRiver firmware tells me "playlist error" when trying to load a playlist? 06.36.35 # okay, nevermind me 06.59.03 *** Saving seen data "./dancer.seen" 08.00.29 # or not.. is it just that iRiver requires CR/LF instead of just LF? 08.04.00 # <[IDC]Dragon> oops, I had the IRC window on all night 08.04.10 # Heh 08.12.15 Join LinusN [0] (~linus@labb.contactor.se) 08.15.45 # <[IDC]Dragon> 'morning! 08.16.15 # morning 08.17.42 # howdy ho 08.18.27 # yo 08.19.28 Quit pill (Read error: 110 (Connection timed out)) 08.28.56 Quit midk ("Leaving") 08.30.28 Quit ashridah (Read error: 110 (Connection timed out)) 08.36.43 Join pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) 08.59.04 *** Saving seen data "./dancer.seen" 09.00.21 Join jyp [0] (~jp@234.81-201-80.adsl.skynet.be) 09.11.53 Join ashridah [0] (ashridah@220-253-120-233.VIC.netspace.net.au) 09.20.40 Join bobTHC [0] (~foo@l06v-2-125.d1.club-internet.fr) 09.20.59 # good morning ! 09.33.01 Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) 09.36.22 # morningsomething 09.39.58 # hcl 09.40.17 # * HCl falls asleep again 09.47.06 Join amiconn [0] (~jens@pD9E7FF98.dip.t-dialin.net) 09.47.26 # hi 09.50.17 # <[IDC]Dragon> 'morning! 09.50.51 # It sure is. 09.58.55 # Bagder: R u there? 10.28.42 Quit Ka (Read error: 110 (Connection timed out)) 10.34.30 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 10.59.08 *** Saving seen data "./dancer.seen" 11.00.22 # amiconn: how are the sim builds working for you? 11.03.12 # Currently not at all (with Bagder's latest patch as well as without) - that's why I want to talk to Bagder... 11.03.38 # His -11 fix works, sort of, while his -13 fix breaks 11.07.44 # lol can't be for real surely http://www.neowin.net/comments.php?id=27171&category=main 11.08.54 Quit midk (Read error: 60 (Operation timed out)) 11.10.34 # DeadMan: they've been trying to push the subscription services angle for ages. this is just another prong, and one that's going to be justifiable in the name of 'security' if someone bitches. 11.12.22 # will be interesting to see what happens 11.14.44 # i imagine it'll create as many problems as it solves for everyday users, but any business with a reasonable amount of pcs that isn't using SUS or some other distribution system and just blocking outbound access to ms's site completely will do things the way they always have 11.15.00 # aye 11.15.33 # which, will typically just mean more money for smalltime computer shop techs, and slightly more headaches for large site sysadmins. 11.27.13 Part LinusN 11.28.10 Join Renko [0] (~Renko@host217-43-59-61.range217-43.btcentralplus.com) 11.33.56 Join Patr3ck [0] (~patr3ck@p548CB835.dip.t-dialin.net) 11.44.59 Join Lurkski [0] (~Lurkski@cpe-70-93-109-209.socal.rr.com) 11.48.02 Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) 11.48.09 # yawn. 11.48.14 # morning thing. 11.53.32 # amiconn: so what's the prob with -13? 11.55.22 # For win32, it produces a linker error 11.55.36 # The x11 build doesn't even compile to the end 11.57.16 # Another hint: You don't need the fancy workaround for ftruncate() on Windows. There is _chsize() the same way as _commit corresponds to fsync() 11.57.26 # aha 11.57.33 # thanks 11.59.20 # * HCl wonders whether amiconn has auto accept.. 11.59.30 # I have... 11.59.30 # amiconn: here's my source for rockboy at the moment 11.59.53 # amiconn: but the win32 build failed to link with the sim_ftruncate for some reason 12.00.14 # Yeah... it doesn't find the symbol when linking... 12.00.33 # I did not yet find the reason why 12.03.38 # I'll retry; perhaps it was my fault... 12.04.21 Join Ka_ [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) 12.08.45 # Bagder: Hmm, strange. Now it worked... (win32). 12.09.04 # probably just the bad dependency stuff 12.09.07 # that hit you 12.09.29 # I thought I did 'make clean', but now I'm not so sure... 12.09.30 # I found the x11 problem too 12.09.52 # there's a patch -14 now 12.12.24 # Did you add the direct resource linking? 12.14.29 # lunch.. 12.17.18 Quit linuxstb (Read error: 60 (Operation timed out)) 12.18.45 # ah, no... 12.25.14 Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) 12.26.44 Quit linuxstb ("Leaving") 12.27.51 Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) 12.32.16 Join zezayer [0] (~c2534472@labb.contactor.se) 12.33.34 Quit zezayer (Client Quit) 12.36.58 # there's a -15 patch now 12.39.14 Quit midk ("Leaving") 12.39.26 Quit linuxstb ("Leaving") 12.40.01 Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) 12.42.20 Quit jyp (Read error: 110 (Connection timed out)) 12.48.06 # do instructions have to be memory aligned? and if so, how do i make sure they are? 12.59.07 # ..back 12.59.11 *** Saving seen data "./dancer.seen" 13.00.38 # HCl: from my basic 68k knowledge, no. only the stack has to be two-byte aligned. 13.01.11 # HCl: I think 68k can work without, but proper alignment wil speed things up 13.02.12 # yea. 13.02.27 # *sighs* 13.04.10 # What's the problem with aligning them? If you start the block aligned, further instructions should be aligned as well 13.05.33 # yea, i know 13.05.42 # i'm just not sure on the definition of aligned 13.05.42 # :p 13.06.13 # i'm still a bit annoyed at not being able to call a function that does a simple return from subroutine.. 13.06.58 # anyone happen to have a link to a reference for gnu assembler's syntax 13.07.06 # ? 13.07.09 # amiconn has one.. 13.07.49 # hmm. guess i can use the info page in a pinch 13.08.56 # ashridah: http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC104 13.11.18 # amiconn: nice. that'll help too. definently unfamiliar with c/asm mixing. 13.16.53 # Bagder: Both win32 and x11 build now. Image & icon are there for win32 13.16.59 # cool 13.17.21 # X11 is working nicely, Win32 still misses the execute permission on plugins 13.17.21 # should I commit? 13.17.40 # I'm gonna leave so I won't be around to fix any remaining nits 13.17.57 Join sox [0] (~sox@c-503fe255.733-1-64736c10.cust.bredbandsbolaget.se) 13.17.58 # There are some warnings left, but I think you could commit 13.18.05 # ok, buckle up 13.18.09 # huge commit coming 13.18.12 Join Patr3ck_ [0] (~patr3ck@pD9ECF5DD.dip.t-dialin.net) 13.18.13 # I'll try to fix the remaining warnings in the evening 13.18.46 # hoy all, I asked this before but havent found any way to solve it so I figure I might ask again 13.19.18 # I get this error trying to run make for the iriver build on my mac os x 10.3.8 13.19.19 # committted 13.19.29 # Using m68k-elf-gcc 3.4.3 (304) 13.19.29 # Created Makefile 13.19.29 # c-503fe255:~/rockbox/rockbox-devel/uibuild svante$ make 13.19.29 DBUG Enqueued KICK sox 13.19.29 # make[1]: *** No rule to make target `#pragma', needed by `/Users/svante/rockbox/rockbox-devel/uibuild/dep-firmware'. Stop. 13.19.29 # make: *** [all] Error 2 13.19.57 # I believe your gcc produces a #pragma file in the shell magic in the top of the firmware/Makefile 13.20.00 # this time i tried building the uisim, but it's the same error building the normal version 13.20.07 # a #pragma line even 13.20.45 # this error came from nothing three days ago, some change in the code must have caused it 13.20.55 # sox: can you show us a copy of the Makefile that's being generated by tools/configure ? 13.21.26 # the whole file? 13.21.29 # Bagder: Different thing: There is still no current daily for Ondio FM, and the daily windows installer builds are also missing... 13.21.44 # sox: toss it up on a website or something'd be easiest. 13.22.01 # although i suspect i'm asking for the wrong makefile. 13.22.11 # amiconn: I know, but I have no time to fix that now 13.22.23 # zagor or Linus will have to do it, or wait 13.22.50 # Okay, just wanted to mention... 13.23.05 # ashridah: http://jordfrihet.org/Makefile 13.23.12 # it is most likely because of the "flash full" error 13.23.15 # somehow 13.24.26 # ashridah: that's the root Makefile, did you want the firmware/Makefile? 13.24.34 # sox: can you show us how your dep-firmware looks like? 13.25.13 # http://jordfrihet.org/Makefile_fw is for firmware 13.25.59 # yeah, put up a copy of the dep-firmware file. 13.26.18 # Bagder: where is it? 13.26.22 # just run 'make dep' if it doesn't exist. (don't know if it gets destroyed) 13.26.26 # sox: in your build dir 13.26.29 # should be in the directory you're compiling in 13.27.13 # sorry, it's not there 13.27.45 # ok 13.27.53 # wait. this is an osx box isn't it? are you using gnu make or bsd's make? 13.27.59 # try gmake ? 13.28.07 # not found 13.28.09 # ah! 13.28.11 # indeed 13.28.15 # you must use GNU make 13.28.24 # ok! 13.28.28 # okay. i'm not that familiar with osx, so i don't know which it includes. 13.28.56 # can i run both simultaneously? 13.29.01 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) 13.29.25 # yeah, usually environments that add it give it a different name, hence 'gmake' for gnu make on these systems. 13.29.44 # i'm not sure why that wouldn't be there, unless you didn't install the development resources for osX 13.29.52 # i sure did 13.30.15 # okay, what's the first line of output from running 'make --version' 13.30.16 # ? 13.30.48 # GNU Make version 3.79,... 13.30.56 # hm. that should be okay then 13.31.01 # run 'make dep' 13.31.20 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new IRC era") 13.31.22 # make: *** No rule to make target `dep'. Stop. 13.31.34 # it is meant to handle them automaticly 13.31.39 # Bagder: I now updated my two working copies. While on one I got the usual message about removed files ('xyz is no longer in the repository'), the other gave me a warning: 'xyz is not (any longer) pertinent'. What does that mean? 13.31.59 # amiconn: I don't know 13.32.11 # ah, hang on. the dep target is only in the firmware makefile, not the simulator one 13.32.12 # odd 13.32.18 # amiconn: perhaps there was a sys/types.h in the past 13.32.34 # ashridah: the sim uses the firmware makefile nowadays 13.32.55 # Bagder: yeah, i'm curious as to why these two are markedly different. 13.32.59 # oh right, there's a 'dep' there 13.33.35 # but there's no 'dep' in the root Makefile so it doesn't work 13.33.39 # Bagder: It gave this warning for uisimulator/common/dir.h, uisimulator/common/file.h and uisimulator/x11/kernel.h 13.34.05 # are you talking about something that affects my error too? 13.34.42 # ouch, player build broke 13.34.46 # sox: okay, run 'make -n' 13.34.59 # and take a copy of the entire output, toss it into a file, and show us it 13.34.59 # make -C /Users/svante/rockbox/rockbox/firmware 13.34.59 # make[1]: *** No rule to make target `#pragma', needed by `/Users/svante/rockbox/rockbox/build/dep-firmware'. Stop. 13.34.59 # make: *** [all] Error 2 13.35.06 # that's it 13.35.28 Quit Patr3ck (Read error: 110 (Connection timed out)) 13.35.45 # sox: cd to the firmware dir,then run this command: 13.36.33 # cat SOURCES | gcc -E -P 13.36.50 # eh, no... 13.36.57 # ...it'll fail on the include 13.37.41 # cat SOURCES | gcc -Iexport -I. -E -P 13.37.53 # I suspect it adds #pragma lines to the output 13.38.04 # "no input files" 13.38.15 # cat SOURCES | gcc -Iexport -I. -E -P - 13.38.20 # (added a dash) 13.38.47 # the first line says: #pragma GCC set_debug_pwd "/Users/svante/rockbox/rockbox/firmware" 13.38.53 # there it is 13.38.58 # the problem is identified 13.39.02 Join jyp [0] (~jp@234.81-201-80.adsl.skynet.be) 13.39.10 # now we need a way to switch off that 13.43.14 # seems to be an apple-specific feature 13.43.21 # yes 13.43.22 # "feature" 13.43.25 # ;-) 13.43.47 # try adding -xassembler-with-cpp to the gcc options 13.43.53 Join R3nTiL [0] (~zorroz@217.30.249.222) 13.43.57 # haha 13.44.01 # " 13.44.01 # The GCC 3.3 preprocessor inserts a new pragma, #pragma GCC set_debug_pwd, as part of the new Distributed Builds feature. (See below.) This may surprise tools and scripts that depended on the exact form of preprocessed output from GCC. These scripts should be rewritten to ignore unrecognized pragmas." 13.44.38 # they should've used -E as a hint 13.44.49 # eh, no I mean -P 13.45.08 # (which is the disable #line lines option) 13.46.31 # is there any easy way to do this so that I dont have to do it manually every time 13.46.50 # we need to fix the Makefiles to use this option 13.47.05 # the same trick is used in most Rockbox makefiles 13.50.58 # Bagder: Red builds for the player sims (didn't check these :( ) and an fprintf is left in radio.c 13.51.01 # I tried adding -xassembler-with-cpp to the GCCOPTS, didnt change anything, any other places I have to change 13.51.04 # it's sad to see all the stupid hacks people have to go through because apple screwed up the default behavior of the c preprocessor 13.51.16 # ...I noticed, working on some of them 13.51.35 # sox: the preprocessor probably doesn't get passed GCCOPTS 13.51.42 # sox: the GCCOPTS is not used for that invoke 13.51.47 # since it's not, strictly speaking, compiling anything. 13.51.47 # ah ok 13.51.54 # it's just the preprocessor 13.52.08 # sox: try the extra defines 13.52.24 # but it's a hack 13.52.41 # even if it might work as a quick work-around 13.55.05 # Bagder: you mean like this: "export EXTRA_DEFINES=-xassembler-with-cpp" 13.55.23 # yes 13.55.41 # it compiles, but with a shitload of errors 13.56.23 # :-/ 13.57.31 # Bagder: for a stopgap, he could try using the preprocessor that he would have built targetting the m68k? 13.57.43 # ah, yes 13.57.53 # still, I wonder what made this problem come up, because three days ago I was compiling without problems, and the pragma line was added then too? 13.57.53 # it probably won't do the trick for the simulators, but it'd get him a built firmware 13.58.07 # in fact, we were using that before...and I changed to the native one, which is why this problem appeared 13.58.11 # sox: apple modified the c preprocessor to add extra junk for their IDE xcode 13.58.41 # without doign the sane thing of turning it off by default and having xcode set a flag to specifically add it (which is the intelligent approach) 13.58.42 # Bagder: ok 13.59.01 # this is truly the fault of Apple's gcc doing stupid things 13.59.17 # stupid stupid stupid 13.59.29 # but it doesn't help you 13.59.32 # OK Ill call them asap :-/ 14.00.19 # sox: i wouldn't bother. knowing them, they won't fix it until the next major release, if then. 14.00.29 # nah I was kidding 14.00.40 # your best bet is to join the chorus bitching on their development forums and placing bug reports. 14.01.04 # so there's no simple workaround then... 14.01.18 # sox: yes, there is. 14.01.23 # use m68k-elf-cpp 14.01.26 # instead of 'gcc' 14.01.47 # $(GCC) is the target one 14.02.03 # in the SRC variable inside the firmware/Makefile file. 14.02.09 # $(CC) even 14.03.23 # the problem was that my win32 cross-compile gcc doesn't support the -include option 14.03.29 # ie, make it SRC := $(shell cat SOURCES | m68k-elf-cpp -DMEMORYSIZE=$(MEMORYSIZE) $(INCLUDES) $(TARGET) $(DEFINES) $(EXTRA_DEFINES) -E -P -include "config.h" - ) 14.03.52 # which should do in a pinch 14.04.06 # argh. 14.04.14 # sox: you need this fix in all Makefiles that do this trick 14.04.15 # bagder's right. m68k-elf-gcc 14.04.33 # hrm. and more than one place? ick. 14.04.39 # yes 14.04.48 # :-( 14.04.58 # Bagder: ouch. could at least have used CC instead of 'gcc' in the command :) 14.05.00 # but we need to fix this 14.05.46 # this works, but you're right, I have to modify all Makefiles 14.05.56 # Bagder: Is it possible to replace your oldish windows cross-gcc with something newer? What would be necessary to do this? 14.06.00 # well, googling for the parameter shows a lot of people bitching, the occasional reference to xcode, and the odd dodgy workaround 14.06.00 # ashridah: it wasn't a nice fix anyway, it should use $(CC) and we should make it not use -include but instead add an #include "config.h" first in all SOURCES 14.06.37 # amiconn: I was about to the other day, but it is very sparse with docs and help for anything but the version we already use 14.07.47 # Iiuc, this basically means building a gcc on Linux as a cross compiler to build windows binaries the same way as the cross-gcc for the targets build sh1 and m68k binaries, right? 14.08.24 # the general idea would be that, but I've gotten the impression that it isn't supported in the main gcc branch 14.08.51 # So how did you create the old cross gcc? 14.08.52 # that's why this is a mingw cross-compile thing 14.09.13 # I'm afraid to tell ;-) 14.09.22 # ... I downloaded a binary 14.09.24 # hehe 14.09.34 # ashridah: I had to modify the makefiles in apps/, plugins/, plugins/lib/ and firmware/ but after doing it it compiled fine 14.09.42 # ashridah: so thanks for the help 14.10.21 # ashridah: i hope this is something that you can solve (since I can't, lack programming abilities ;-() 14.10.54 # Bagder: Maybe this url is helpful: http://www.wxwidgets.org/technote/crosscmp.htm 14.12.17 # for "egcs on Linux" 14.12.42 # but I'll keep the URL and try next week 14.13.27 # sox: it's really something apple can 'solve' 14.13.30 # we can only really work around it 14.13.51 # ashridah: I understand that 14.14.20 # ashridah: and this workaround is OK, not very time consuming 14.14.20 # Bagder: "EGCS was an experimental step in the development of GCC, the GNU C compiler." 14.14.27 # I know 14.14.33 # even older than the version we use atm 14.14.45 # but it might still work with newer versions 14.16.27 # sox: yeah, well, someone will probably roll something into the makefiles shortly. it's just not really a perfect solution 14.17.40 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 14.17.40 # * sox ponder about what "rolling something" into a makefile means 14.17.51 # "fix it" 14.17.55 # apply patch 14.19.25 # * sox feels enlighted! 14.21.44 # added a note about this on ThingsTodo 14.21.55 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 14.25.57 # I'm off for a week now 14.25.59 # see ya 14.26.02 Quit Bagder ("Off to search for that connect-resetting peer guy!") 14.26.17 Quit lostlogic ("Going to the moon") 14.31.44 # uh. what's bagder's actual name? :) 14.32.37 # ashridah: http://www.rockbox.org/twiki/bin/view/Main/IrcNicks 14.34.48 # heh. i should have known 14.35.02 # too late now. i'll probably get told this on the mailing list too 14.35.15 # nevertheless, i've summarised the situation there. 14.38.23 Join elinenbe [0] (~elinenbe_@65.115.46.225) 14.41.16 # sox: you still around? 14.41.36 # ashridah: japp 14.42.36 # can you try using 'gcc -traditional -D__GNUC__' instead of m68k-elf-gcc in those makefiles and see if it makes a difference? i'm not expecting it to, but it's worth a short 14.42.38 # shot even 14.43.40 # hm. might be able to drop -D__GNUC__ 14.44.26 # ashridah: tried both, the first one gave me this error: :6: warning: "__GNUC__" redefined 14.44.26 # :1: warning: this is the location of the previous definition 14.44.34 # yeah, that's okay. 14.44.49 # you can drop the -D__GNUC__ bit. 14.44.51 # the other one the usual : make[1]: *** No rule to make target `#pragma' 14.44.56 # okay. 14.44.58 # no fix there then 14.45.28 # i suppose an easier check would be to get you to have run echo "hi" | gcc --traditional -P -E - 14.45.29 # anyway :) 14.45.41 # * ashridah keeps searching for a fix 14.45.56 # ahridah: thanks for your work.... 14.45.56 Join AC [0] (~5078751e@labb.contactor.se) 14.46.00 # hello 14.46.02 # the fixes i'm seeing seem to suggest that an older cpp still exists on apple boxes. 14.46.35 # ahridah: i got that impression too 14.46.41 # sox: okay, try echo "hi" | gcc -undef -P -E - 14.46.56 # (just run it) 14.47.06 # see if it still outputs the pragma 14.47.10 # #pragma GCC set_debug_pwd "/Users/svante/rockbox/rockbox/build" 14.47.10 # hi 14.47.19 # unfortunately... 14.47.34 # * AC checks wav generated from wv2wav 14.47.55 # damnit. 14.48.05 # * ashridah resumes kicking apple 14.48.41 # * sox joins in kicking 14.49.28 # wav file is 152 kb big, but it seems to be damed :( 14.53.33 # wavpack codec seems hell fast 14.54.53 # ashridah, sox: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-November/003725.html 14.56.53 # ashridah: do you think that solution might apply to rockbox as well, adding the -x 14.56.53 # assembler-with-cpp to all makefiles and hoping it works on other platforms? 14.56.59 # yeah, that's what bagder suggested before, but sox seemed to think it didn't work. 14.57.14 # ashridah: I didnt? 14.57.15 # sox: it'd be easy enough to test the platform in tools/configure 14.57.17 # AC: Am I correct in saying that you have a running wv2wav, but you have a problem with the wav output? 14.57.28 # sox: i thought you tried it 14.57.35 # of course, you might have tried it in the wrong place ;) 14.58.07 # linuxstb: yep... it seems to decode correct, but must look if i get a wav-checking tool, to see whats wrong 14.58.13 # another solution: http://lists.gnu.org/archive/html/bug-gnustep/2003-07/msg00269.html 14.58.15 # ashridah: tell me again and i will try it 14.58.21 # amiconn: the problem is, that's a command for the preprocessor specifically 14.58.45 # so 'gcc -P -xassembler-with-cpp' isn't right. need to modify it to send it to the preprocessor (which i don't know, but is probably in the manpages) 14.59.12 *** Saving seen data "./dancer.seen" 14.59.16 # linuxstb: will try a bigger file 14.59.25 # sox: hang on. 14.59.34 # ashridah: im here waiting 15.00.19 # AC: If you have a copy, the command-line "sox" program is very useful. It includes a program called "play", and you can use that to play the wav file as if it was raw data - so you can try different combinations of parameters (such as endianness, signed/unsigned etc). That will tell you if the WAV header is wrong, or if your data is not signed little-endian. 15.00.51 # aha 15.01.17 # linuxstb: will look if portage has sox in it :) 15.02.40 # * sox wonders why everybodys talking bout me ;-) 15.03.02 # hrm 15.03.14 # sox: because the problem is something every apple user will face 15.03.18 # as they update 15.04.38 # hrm. the manpage suggests one can use echo "hi" | gcc -Wp,xassemble-with-cpp -P -E - 15.04.50 # linuxstb: about 120000% with wv2wav.. its very hard to ready, as it is changeing so fast 15.05.00 # will take a foto 15.05.01 # but that bitches about xassemble-with-cpp not being found as a file, which is clearly wrong 15.05.14 # AC: cool 15.06.13 # foto is quite ugly.. 15.06.14 # ashridah: What do you think about the solution of passing the generated file through sed to get rid of the #pragma line? 15.06.26 # * AC hast only a handy with a shit camera in it 15.07.09 # heh. sounds good enough to me. 15.07.37 # * AC cant ready how many seconds the decoding is running 15.07.38 # got to make sure it deals with directories with spaces in the name tho 15.07.48 # which could get a little frustrating. 15.08.19 # might just be able to get away with matching the pragma and then trimming the entire line 15.08.38 # it seems like a common (and fugly, imho) workaround 15.09.17 # Yeah, it doesn't look nice, but the the apple gcc behaviour isn't nice either 15.09.50 # treat them like they treat us ;-) 15.09.55 # The second link I posted does drop the whole line iiuc 15.10.37 Join lolo-laptop [0] (~lostlogic@68.251.84.226) 15.10.56 # it's just silly. they HAD to have realised it'd break other things. i can't understand why they just didn't add an -xcode option that does funky-magic[tm] for their specific build environment 15.11.38 # of course, apple do all sorts of strange things 15.11.48 # like not rolling out bugfixes for opengl until the next MAJOR release 15.12.02 # AC: Something is obviously wrong with the statistics your wv2wav is keeping. The "file_info.current_sample" variable should contain the number of samples decoded so far (one sample is normally 4 bytes (2 16-bit words)). You also need to set the file_info.sample_rate variable to the correct value (or just hard-code it to 44100 for now). 15.12.04 # so people who want to play recent games are forced to buy an upgrade for osX to play it 15.12.49 Quit R3nTiL () 15.13.27 # linuxstb: i am filled in all infos 15.15.00 # linuxstb: x-factor.dyndns.org/rockbox/wv2wav.c 15.16.55 # AC: What about file_info.samplerate ? 15.17.25 # amiconn: anyway, if you can figure out how to get gcc to pass the xassemble-with-cpp option to the preprocessor, we're on a winner. 15.18.07 # linuxstb: i have seen it yet.. mom will fix it 15.18.31 # ... 'mom will fix it'?! 15.18.33 # Hmm. I cannot try that. No Mac anywhere near me. I don't even know someone who uses a Mac 15.18.49 # amiconn: it should work as a command on all platforms 15.19.01 # ie, it should be a generic gcc option 15.19.15 # as -xassemble-with-cpp is a generic cpp option. 15.19.15 # Yes, but I cannot test if it does the desired thing 15.19.21 # that's okay 15.19.29 # as long as it actually runs at all 15.19.44 # ie, it doesn't toss out a weird error about the command line options 15.19.48 # then we can get sox to test it 15.19.53 # who, funnily enough, has a mac :) 15.21.57 # * sox feels almost like someone is making fun of me ... ;-/ 15.22.38 # linuxstb: runns now wirh more then 100%.. speed is growing 15.22.41 # hoy then i demand that we make fun of windows users and their cygwin mess too ;-) 15.22.48 # 109% 15.23.08 # sox: that's okay, windows makes fun of itself 15.23.16 # linuxstb: 115% 15.23.26 # sox: i'm just picturing the happy-nowhere mac advert parody, that's all 15.23.59 # ashridah: im with you 15.24.05 # linuxstb: 118% 15.24.15 # * amiconn just doubts whether he should dig into the #pragma fun any further... 15.25.35 Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 15.25.39 # linuxstb: 166 sec for a song that is 5 min and 50 sec long 15.25.57 Quit cYmen (Read error: 104 (Connection reset by peer)) 15.26.03 # linuxstb: and about 8,6 MB big 15.27.41 # "i don't feel i'm operating the mac so much as i'm just there, sharing the mac experience. And if i can do something useful, while the mac is willing, so much the better" 15.27.43 # heh 15.30.15 Quit DeadMan () 15.31.40 Quit cYmen_ (Connection reset by peer) 15.32.05 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 15.36.45 # ashridah: still looking for solutions 15.36.47 # ? 15.38.09 # better solutions, yeah. 15.38.34 # for the time being, replacing the 'gcc' with 'cpp -xassemble-with-cpp' should do the trick 15.38.49 # aghl. 15.39.21 # -xassembler-with-cpp even 15.40.02 # that works 15.40.23 # but we still have to modify all makefiles, no? 15.40.33 # well, ultimately, yes. 15.40.33 # or can this work for other platforms as well? 15.40.37 # but we'll do that in cvs 15.40.46 # well, since all platforms use gcc, it should be fine 15.40.59 # well, then its solved? 15.41.11 # * sox goes to bake a cake 15.41.13 # there's workarounds. 15.42.53 # AC: That's excellent news. Can you make a tarball, and I'll add it to CVS. 15.43.24 # i can't commit anything to cvs myself tho. 15.44.00 # ashridah: neither can I (who couldve guessed that...) 15.45.42 # linuxstb: how far away is getting sound out of rockbox on iriver? 15.46.09 # linuxstb: later... i want to get a correct wav file out of it... i am looking at the moment whats wrong. Could i have later a own cvs account.. current libwavpack doesn't support wv files version 3 and encoding isn't there also 15.46.25 # The actual sound playback is working, but no work has started on the actual infrastructure to link rockbox, the audio codecs and the hardware yet. 15.46.56 # AC: I'm not able to give others CVS accounts - one of the core developers will have to do that (Bagder, LinusN or Zagor). 15.47.16 # linuxstb: ok.. i will ask one of them 15.47.30 # linuxstb: aha, and that work is next on the list, or are other stuff more prioritized? 15.48.49 # sox: Everyone has different areas they are working on. LinusN and others are working on the low-level hardware stuff, others are working on optimising the codecs, But I think a few of us (including me) are currently working on the audio playback part of things. 15.48.51 # iriver is little endian? 15.49.09 # AC: No, big-endian! 15.49.26 # linuxstb: oh.. that is the probelm with wv2wav 15.49.38 # ashridah: got to go, thanks for your work today, means a lot to me and three or four other mac users.... 15.49.55 # Check my flac2wav code - I think that has an LE_S16 macro defined which you can use to swap bytes. 15.50.09 # linuxstb: thanks 15.50.22 # * AC makes a short break 15.54.04 Join R3nTiL [0] (z0rr0@217.30.249.43) 15.54.38 Quit sox ("time to go to kindergarten and get the kid...") 16.07.00 # hi 16.12.04 # linuxstb: I wonder why you reinved macros... Rockbox has SWAB16, SWAB32 and SWAW32 to handle endianess 16.12.13 # *reinvent even 16.25.31 Quit ripnetuk ("Arrrrghhhh") 16.26.18 Quit R3nTiL () 16.27.17 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 16.30.13 # amiconn: Simply because I didn't spot the existing ones - or even expected them to exist. I'll start using them, thanks. 16.36.30 # Well, rockbox had to handle endianess for a long time. The SH1 is big endian too. 16.38.32 # Hmm. The abovementioned macros are not asm optimised for coldfire, unlike the SH1 ones. Are yours asm optimised? 16.39.29 Quit [IDC]Dragon ("CGI:IRC (EOF)") 16.39.33 # No, they are only used is a couple of the WAV output routines at the moment - not in the core codec code. 16.40.17 # Well, the SH1 has byte and word-swap asm instructions. So SWAB16 and SWAW32 are one instruction, SWAB32 uses 3 16.40.39 # I guess similar instructions exist for the coldfire 16.40.53 Join preglow [0] (thomj@s183a.studby.ntnu.no) 16.41.30 # coldfire has swap instruction 16.42.08 # only swap.w, unfortunately 16.42.20 Quit ashridah ("Leaving") 16.42.40 # Hmm. So at least SWAW32 can be coded as one instruction 16.43.20 # asm("swap.w %0" : "=d" (input) : "d" (swapedinput)); should do the job 16.43.36 # %1, i mean 16.44.05 # Not quite. First, %0 is correct for the first parameter 16.44.35 # Second, if you only have the option that input and output are identical, you have to use the combined input/output sysntax. 16.44.47 # yes, i don't know that syntax, so that was i guess ;) 16.45.04 # asm("swap.w %0" : : "+d"(data)); 16.45.24 # Oops, one colon too much 16.45.42 # yep, then we agree 16.46.31 # but how to swap bytes quickly 16.46.31 # hmm 16.46.45 Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 16.49.10 # mrf 16.49.46 # preglow: For SWAB16, there might be no faster solution than shift high byte right, shift low byte left, then or 16.50.18 # However, for SWAB32 there is probably a better method than shifting around all 4 bytes 16.50.55 # swaw is probably the least used of them as well, so bah 16.56.14 # linuxstb: shouldn't linus' lates change have sped our libflac up somewhat? if i'm not mistaken, it has moved lpc_restore_signal_order to iram 16.57.58 # dammit. i need someone to help me with writing an return from subroutine instruction in memory, and calling it successfully without dying.. on iriver 16.59.14 *** Saving seen data "./dancer.seen" 17.00.13 Join XShocK [0] (~cddef002@labb.contactor.se) 17.03.55 # what makes that so hard? 17.05.57 Quit XShocK ("CGI:IRC") 17.09.54 Join XShocK [0] (~cddef002@labb.contactor.se) 17.10.13 # preglow: you tell me 17.10.15 # :( 17.10.47 # someone should port a gdb stub :/ 17.13.24 # hi. someone actually can change the status of sound in wiki, since it is interrupt based, and quality is perfect, the only DMA is not working yet, but digging the original firmaware helps. 17.13.41 # nice 17.13.45 # is it in cvs yet? 17.13.53 # no, not in cvs 17.14.12 # in original firmware DMA is used 17.14.21 # *nods* 17.17.03 # it can be put in cvs, but should it? because audio framework is not there anyway. 17.17.36 # nah, but update the link maybe? and put it online? 17.19.17 # ok. 17.19.32 Join R3nTiL [0] (~zorroz@217.30.249.220) 17.19.39 # maybe change status to 90% (dma not working yet) 17.19.40 # or something 17.20.08 Ctcp Ping from R3nTiL!~zorroz@217.30.249.220 17.20.10 Ctcp Version from R3nTiL!~zorroz@217.30.249.220 17.20.12 Ctcp Time from R3nTiL!~zorroz@217.30.249.220 17.20.24 # sound input does not work yet. 17.20.30 # ok 17.20.32 # 50% then 17.21.16 # plus digital out.. digital in.. line out.. line in.. 17.21.56 # yeah. :) 17.24.45 Quit R3nTiL () 17.25.21 Join mecraw [0] (~mecraw@69.2.235.2) 17.33.26 Quit XShocK ("CGI:IRC (EOF)") 17.39.47 # HCl: have you tried dumping the code you generate and running a disassembler on it? 17.42.53 # yes. 17.42.55 # it seems fine. 17.43.15 # and you're aware of the alignment issues on the coldfire? 17.54.10 Join R3nTiL [0] (~zorroz@217.30.249.146) 17.57.02 Quit AC ("CGI:IRC (Ping timeout)") 18.02.02 Join hubble [0] (hubble@h13n1fls302o1033.telia.com) 18.03.07 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- Chicks dig it") 18.07.37 Part Lurkski 18.07.49 Quit Patr3ck_ ("User pushed the X - because it's Xtra, baby") 18.14.40 Quit jyp ("poof!") 18.17.37 Quit R3nTiL () 18.44.15 Join ]LoKi[ [0] (LoKi@211.Red-81-39-209.pooles.rima-tde.net) 18.44.34 # <]LoKi[> hey 18.47.49 # <]LoKi[> I've got a couple of questions, can anyone help? 18.54.11 # ask away 18.59.16 *** Saving seen data "./dancer.seen" 19.00.26 Join [LoKi] [0] (LoKi@211.Red-81-39-209.pooles.rima-tde.net) 19.00.36 # <[LoKi]> Anyone? 19.00.39 # 18:54 < preglow> ask away 19.00.40 # <[LoKi]> Bueller? 19.00.46 # <[LoKi]> oh 19.00.51 # <[LoKi]> soz, I got disc'ed 19.01.38 # <[LoKi]> anyway :P 19.01.38 # <[LoKi]> How can I get Rockbox to pic up a microphone hooked up to the Line In jack 19.01.52 # <[LoKi]> I choose the input and it's just silent 19.02.12 # <[LoKi]> (V2 Recorder, btw) 19.03.47 Quit ]LoKi[ (Read error: 60 (Operation timed out)) 19.04.53 # <[LoKi]> and the other one is... is there anyway to go to the next song without going to the File List when in Repeat 1 mode? 19.09.17 Quit [LoKi] () 19.10.34 Join Tang [0] (~chatzilla@ARennes-252-1-50-109.w83-195.abo.wanadoo.fr) 19.10.56 # hi World :) 19.11.52 Join DrRick [0] (DrRick@81-86-219-9.dsl.pipex.com) 19.18.40 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) 19.25.17 Quit preglow ("woop") 19.33.40 Quit Renko (Remote closed the connection) 19.50.51 Join blahdood [0] (~423d9017@labb.contactor.se) 19.51.03 Nick blahdood is now known as drewslater (~423d9017@labb.contactor.se) 19.51.44 Quit drewslater (Client Quit) 20.02.21 Join Sucka [0] (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) 20.04.21 Join condor9 [0] (jch@xmission.xmission.com) 20.05.41 # I'm having a config.cfg problem with 2.4 stable ... can anyone help? 20.07.16 # Any linux user around? 20.07.40 Join preglow [0] (thomj@s183a.studby.ntnu.no) 20.07.54 # hey amiconn ... you were helping me the other day ... got a second? 20.08.00 # If yes, please check what 'echo $OSTYPE' on the command line outputs 20.08.25 # condor9: just ask... 20.08.30 # linux 20.08.37 # o.k. 20.08.55 # My fonts aren't loaded from the config.cfg If I browse and load them they're fine. 20.09.09 # Where are you fonts located? 20.09.16 # I tried a simple config.cfg with just the font loading and that didn't work either. 20.09.19 # .rockbox/fonts 20.09.45 # Did you try saving a .cfg after loading the desired font? 20.10.09 # Yes. 2.2 is ok, but 2.3 and 2.4 are not. I used the new convbdf to convert from bdf to fnt 20.11.20 # Hmm, strange. Works perfectly here. 20.11.50 # Yeah, seems to work for most people. Let me ask, could it be a problem with HD cache ... too large perhaps? 20.11.56 # Perhaps the font name is too long? 20.12.09 # I renamed the font to "bold.fnt" :) 20.12.35 # Hmm, that should definitely work. 20.13.06 # Didn't you have other problems with .cfg files as well? 20.13.10 # 2.2 is works great but I would like to rombox my recorder, so I need 2.4. 20.13.20 # Same problem. I isolated it to font loading. 20.13.48 # Other settings are restored ... the font is the only thing that doesn't load. 20.14.18 # What line ends does your .cfg file use? 20.14.51 # Other method, simply drop me your .cfg and the font in question, I'll try it here 20.14.55 # I tried the default ^M and then removed them ... doesn't seem to matter. 20.15.42 # I'm in a coffee shop without my recorder, otherwise I'd send you my config. 20.16.01 # I also tried moving the font line to different positions in the config ... that didn't work either. 20.17.29 # It doesn't matter what font I use ... none of them autoload ... just the default. 20.19.52 # The last selected font should even autoload on boot, without using a .cfg file, if it is (1) located in /.rockbox/fonts and (2) doesn't have a too long name 20.20.03 # ...and (3) is a vaild font of course 20.20.33 # Unfortunately I have no idea what fails if it doesn't. 20.20.40 # Yeah, I know ... that's why I'm asking here. :) 20.21.27 # Hmm. Other settings are preserved across reboots? 20.21.45 # Yes. 20.21.48 # AH, you said 2.2 works... so I guess they are 20.22.50 # I know the font format changed ... so I made sure to use the new convbdf. The font works if I just browse to it. Very strange. 20.23.34 # Is there some way I can debug the loading of a config file? 20.23.42 # Hmm. I'm afarid I can't help without being able to reproduce the problem 20.24.06 # Ok. Thanks for your time amiconn. 20.27.00 # You may drop me the font & config file when you have access to your box again. 20.27.19 # Ok. 20.30.35 # amiconn: I've ssh'ed around a few machines I have access to: Debian - OSTYPE=linux-gnu, RedHat - OSTYPE=linux-gnu, SuSE - OSTYPE=linux, Solaris - OSTYPE=solaris, MacOSX 10.2 - OSTYPE=darwin 20.30.35 Quit condor9 ("Leaving") 20.31.10 # linuxstb: Thanks. So this variable seems to exists almost everywhere... nice :) 20.31.21 # Does cygwin have it? 20.31.29 # cygwin - OSTYPE=cygwin 20.31.54 # Now I only need to know how to check that env variable in a Makefile... 20.32.14 # Can't you just use OSTYPE in the Makefile? 20.32.23 # No, it's empty.... 20.33.45 # It seems that all variables which are accessible in all rockbox Makefiles are defined in the build-dir's Makefile, which is created by configure 20.35.50 # Then just use configure to add it to the build Makefile. 20.38.47 # Hmm, here's why I'm digging for that. There are 3 related problems with the cygwin build: 20.39.44 # - plugins are dlls on Windows. These need the execute flag set, otherwise they can't be executed. So there is a check in the makefile, comparing UNAME. However, this doesn't work 20.40.17 # - The uname variable is set in configure, but not exported to the Makefile. This alone would be easy to solve 20.41.11 Join Zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) 20.41.15 # - But, uname isn't constant on cygwin, it has the form CGYWIN_NT-5.1 20.41.40 # - Makefiles can only check for equal/not equal, so this would need mangling 20.42.05 # So OSTYPE seems to be much better... 20.42.34 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 20.44.34 Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") 20.44.58 # I've just tested, and the line "ifeq ($(OSTYPE),linux-gnu)" seems to work in a Makefile 20.45.34 # GNU Make 3.80 20.47.49 # amiconn: I think I'm mistaken, I think it's only used if you type "export OSTYPE" in the shell before typing "make". 20.51.40 # Unless I'm misunderstanding, you need to do something extra only for the win32 simulator - so why don't you test "SIMVER" in the Makefiles? 20.52.07 # Because the problem also occurs when building the x11 sim on cygwin... 20.52.34 # But what if someone is cross-compiling? either to or from windows? 20.54.12 # I don't know exactly what will happen in that case. The old check tried to do the same what I intend to do, but with UNAME, and it failed because of the non-exported variable 20.59.18 *** Saving seen data "./dancer.seen" 21.00.07 # hi.. 21.00.20 # There's already a lot of variables in the master make file, so I don't think adding OSTYPE would be a problem. 21.00.56 # I didn't figure how to access OSTYPe within the script, so I added UNAME instead, as was probably intended anyway 21.01.24 # Then I needed to change the check in apps/plugins/Makefile to use findstring 21.02.26 # In tools/configure, just add the line "export OSTYPE=$OSTYPE" to the end of all the export statements. You will then have the line "export OSTYPE=cygwin" in your Makefile. 21.04.07 Quit Aison (Read error: 54 (Connection reset by peer)) 21.04.22 # Now there are only those 2 warnings left for the win32 sim, but I don't get these when building myself. It is most likely a problem of the oldish crosscompiler used on the official server. GCC 2.95 you know... 21.05.17 # The dependencies also need fixing, but I don't know how to do that.... 21.11.27 Join sox [0] (~sox@c-ce38e255.733-1-64736c10.cust.bredbandsbolaget.se) 21.12.37 Quit sox (Client Quit) 21.12.52 Join sox [0] (~sox@c-ce38e255.733-1-64736c10.cust.bredbandsbolaget.se) 21.15.18 # amiconn: couldnt that OS specific configuration be useful to get the workaround for the mac os x pragma problem as well? 21.16.23 Quit Zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") 21.16.51 # Certainly, the UNAME variable could be checked for this too. The question is how to hand the option to the preprocessor... 21.17.14 # amiconn: eg, cpp -xassembler-with-cpp in the Makefiles 21.17.29 # amiconn: instead of gcc 21.19.11 Join markun [0] (~markun@bastards.student.utwente.nl) 21.19.51 # Is anyone here running the X11 uisimulator? 21.20.06 # sox: Does gcc -Wp,-xassembler-with-cpp also work? 21.21.03 # Of course in addition to the other options 21.21.55 # amiconn: hang on, testing 21.22.23 # uisimulator crashes here when trying to scroll a line.. 21.23.24 # markun: Yes, I noticed the other day, but I had forgotten about it. 21.23.57 # linuxstb, markun: Linux? 21.24.01 # I can't remember ever seeing it work - I very rarely have any files in my archos directory. 21.24.07 # Yes, Linux. 21.24.23 # I was trying to debug my unicode stuff and thought I broke scrolling, but it also fails for a clean checkout. 21.24.24 # Lemme check with cygwin, perhaps it ddoes also crash... 21.24.31 # amiconn: no, FreeBSD. 21.25.02 # amiconn: no: cc1: error: unrecognized option `-xassembler-with-cpp' 21.25.15 # gdb tells me it segfaults in lcd-x11.c:118, but I can't see anything strange about it. 21.27.10 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 21.27.36 # gdb tells me line 381 - when accessing the pf->width array. 21.27.40 # ello 21.27.50 # hmm, scrolls like mad here... (recorder sim). Building iriver x11 sim... 21.29.09 # linuxstb: I hope it wasn't anything I changed before comitting Tremor that makes LOW_ACCURACY produce only static.. 21.29.59 # amiconn: The segfault I get is in line 381 of drivers/lcd-recorder.c 21.30.18 # amiconn: so gcc -Wp,-xassembler-with-cpp does not work 21.30.26 # markun: No, I don't think so. I compared your version and the original, and didn't see any significant changes. 21.32.12 # iRiver x11 sim also working.. strange 21.33.39 # Yes, very strange.. Maybe it's because you use a different X server. 21.34.31 # flac2wav doesn't compile here for the sim... undefined reference to `_iramstart' / undefined reference to `_iramcopy' / undefined reference to `_iramend' 21.34.46 # yes, linus committed those yesterday 21.35.21 # Yes, I know. However, I wonder why this doesn't work here, while the official builds seem to work 21.35.33 # ahh 21.37.44 # so now Im out in the cold building the sim: "Unsupported system: Darwin, fix configure and retry" 21.41.06 # I guess I could fix it if I knew the right LDOPTS for Darwin 21.42.09 # Does anyone know what the circle with a dot inside means in the top-right corner of the screen? 21.42.38 # (I'm using the iRiver X11 simulator) 21.44.51 # Hmm, I don't get this here, but then I can't use 'make install' 21.45.17 # make install tries to remake missing files, and it fails because of those symbols I mentioned... 21.45.36 # This symbol shouldn't be there, or does the iRiver not have a hd led? 21.46.05 # it does 21.46.28 # amiconn: are you talking about my symbol? 21.46.34 # linuxstb: yes. 21.47.14 # The Ondio does not have a disk (well: MMC) led, so [IDC]Dragon implemented an activity indicator in the top right corner. 21.47.23 # I've sort of tracked down the crash (but not the reason). When I scroll down slowly (pressing and releasing the down error), then that symbol appears when I get to the penultimate line. If I then press any key, it wil crash in line 381 of lcd-recorder.c 21.50.41 # ??? lcd-recorder.c !!! I thought you were building the iriver sim... 21.51.29 Quit sox ("This machine just fell asleep") 21.51.37 # I am - I guess that's the place for generic graphical LCDs. 21.52.12 # Note quite. For iriver, lcd-h100.c is used instead 21.53.18 # lcd-recorder.c is for archos recorders, ondio, and gmini 21.54.13 # Strange. My build/Makefile contains "TARGET=-DIRIVER_H100", but the sim is definitely building and linking drivers/lcd-recorder.c 21.54.47 # Yes, it is doing the same here, and that is most likely the problem 21.55.14 # There is a maximum number of scrolling lines; I doubled that for iriver some time ago 21.55.39 # So if the sim uses the wrong file, an out-of-boud array access will happen... 21.55.47 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 21.56.40 # XShocK: yo, are you there? 21.56.48 # XShocK: i've got Dma sort of working 21.56.54 # Yep, that's the bug. I renamed lcd-h100.c to lcd-recorder.c and the sim now works fine. 21.57.58 # XShocK: I'm using "DCR0 = DMA_INT | DMA_EEXT | DMA_CS | DMA_SINC " 21.58.04 Join Chamois [0] (~3e234217@labb.contactor.se) 21.58.36 # XShocK: so it good news, only bad thing is that the pitch is little wrong (too slow) =) 21.58.40 # amiconn: The problem is in firmware/SOURCES - the CONFIG_LCD variable isn't defined for the simulator builds. So it defaults to lcd-recorder.c 21.58.56 # I was about to say the same... 21.59.53 Nick Sucka is now known as Sucka`away (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) 22.00.32 # XShocK: think it's because my pcm buffer is in SDRAM.. going to move it to SRAM now 22.02.03 # linuxstb: It's probably the same thing that causes the funny symbol. HAVE_LED is also only defined for the targets (that have one)... 22.02.39 # I'm not sure how to handle this :( 22.03.01 # they should have bundled a couple of megabytes of sram 22.03.16 # No, nor am I. I wonder why those config-*.h files don't define the hardware for the simulators. 22.04.25 # Imho there shouldn't be that #ifndef SIMULATOR... 22.04.49 # amiconn: I've just deleted it from config-h100.h and I will see what happens... 22.06.04 # I now get an error compiling system.c - it is trying to compile some assembly code. 22.07.14 # Hmm, that's bad. 22.07.46 # I guess the current problem also results from the simulator build system change 22.08.27 # It looks like lots of the code depends on those #ifdefs being defined only for the target. The SIMULATOR variable isn't used. 22.09.16 # If any, only CONFIG_CPU should be protected by #ifdef SIMULATOR, imho 22.09.36 # #ifndef SIMULATOR of course 22.09.38 Quit DrRick () 22.13.36 # Hmm. Doesn't work either... 22.14.30 Join olivierd [0] (~d444e358@labb.contactor.se) 22.16.32 # hi there, trying to compile gcc for coldfire on cygwin 22.17.05 # I get an error in the m68040 part, is there a way to only build for the coldfire target? 22.18.16 # m68040 part? 22.18.33 # why would m68040 be involved? 22.19.31 # I use m68k-elf as a target and it seems to build a lot more than coldfire 22.23.57 # it probably builds for all 68k, yes 22.23.58 # amiconn: The only variable I can see to use is the CONFIG_KEYPAD variable. It's not the right thing to do, but it works. 22.24.05 # but i've never seen an error 22.24.10 # what gcc version? 22.24.57 # linuxstb: Okay. It's ugly, but it works for now. You could commit this, with a comment stating FIXME or such... 22.26.28 # OK, I'll commit it. 22.29.04 Quit olivierd ("CGI:IRC (EOF)") 22.29.53 Join olivierd [0] (~d444e358@labb.contactor.se) 22.32.01 Join Renko [0] (~i_dont_wa@host217-43-59-61.range217-43.btcentralplus.com) 22.33.25 Quit olivierd (Client Quit) 22.36.18 # hubble: i am here finally :) 22.36.34 Join olivierd [0] (~chatzilla@212.68.227.88.brutele.be) 22.37.11 # hubble: cool! :) 22.37.15 # can you send it to me? 22.37.30 # preglow: sorry, got caught up in a fight with my IRC client 22.37.45 # olivierd: didn't have much to add anyway, what gcc version? 22.37.52 # Xshock : when WAV will be commit on CVS ? 22.37.53 # olivierd: are you trying to build, that is 22.38.01 # 3.4.3 22.38.11 # olivierd: weird, works fine here. binutils? 22.38.29 # cvs as instructed in the wiki 22.38.58 # chamois: i would guess when kind of sound framework will be done. 22.39.11 # olivierd: weird, i've never had that not work 22.39.42 # or of course it can be added somewhere near, just giving a basic sound API 22.40.06 Join Patr3ck [0] (~patr3ck@pD9E5C0E7.dip.t-dialin.net) 22.40.20 # sound is more than the 10% we can see on the wiki ? 22.40.44 # hubble and you made lot of progress ? no ? 22.40.48 # chamois: hubble did DMA now, so i guess it is somewhere near 50. :) 22.41.02 # ok ! good ! 22.41.06 # with recording being the remaining 50%? 22.41.13 # yes 22.41.14 # heh :-) 22.41.19 # well... I've been trying to get it to work for a few days. gets operands mismatch in .../src/gcc-3.4.3/gcc/libgcc2.c -o libgcc/m68040/_fixunsdfsi.o 22.41.23 # um.. how big is the SRAM of iriver ? 22.41.25 # XShocK: like it works perfectly? 22.41.30 # hubble: 96kbyte 22.41.34 # hubble: try not to use too much of it 22.41.37 # hehe 22.41.38 # hubble - 64KB can be used by DMA 22.41.38 # =) 22.41.50 # hubble: yes, it needs to be in the uppers 64kb 22.41.53 # upper 22.41.59 # Strath: um.. what? 22.42.03 # stripwax: what? 22.42.27 # hubble? DMA controller can only use the 64KB SRAM bank not the 32KB bank 22.42.29 # hubble: only 64kb out of the 96 can be accessed by dma 22.42.38 # it sounds perfect even without DMA. with AUDIOTICk it tend to get more CPU, but still it sounds very good 22.43.06 # XShocK: how about an example rockbox.iriver? :) 22.43.07 # um.. well.. i just tried to use DMA to transfer from SDRAM and that was no problem 22.43.08 # hubble what did you use to measure that it plays slowly without SRAM? 22.43.15 # hubble: i think there would be problems, i also read somewhere that SRAM will be problem 22.43.23 # hubble you were talking about SRAM not SDRAM, no? 22.43.28 # since it is not addressable by DMA 22.43.42 # sram is addressable by dma 22.43.44 # just not all of it 22.43.50 # preglow: ok. :) 22.44.00 # hm.. oh, what.. i used a buffer allocated by buffer_alloc 22.44.04 # you have access to 64kb of it, but don't even think about using that much, heh 22.44.29 # Couldn't it all be used for PCM buffer? 22.44.34 # hell no 22.44.38 # Why not 22.44.41 # we need space for performance critical code and data 22.44.46 # the other bank? 22.44.47 # hubble: aah, then ok. but still.... i think SRAM is not very needed, 22.44.48 # lots of space 22.45.11 # hrm? 22.45.36 # XShocK: you dont? it didn't run at normal pitch, but maybe that's because of cpu speed? 22.45.42 # ah... username autocomplete :) 22.45.49 # hubble: since it even worked with PIO without SRAM, i don't see why wouldn't it work with DMA 22.46.11 # maybe there is another prblem? 22.46.16 # XShocK: yes, maybe 22.46.36 # how do you know it doesn't run at normal pitch? what's the reference 22.46.37 # ? 22.46.58 # Is this the output of the sine or actually a WAV output? 22.47.09 # you do ofcourse set the sample frequency? :) 22.47.18 # stripwax: so, um.. where's the upper 64kb of sram? 0x10010000 -> 0x100020000 ? 22.47.49 # 0x10010000 -> 0x10020000 i mean 22.48.18 # Well it can be moved by MBAR 22.48.20 # iriver's dma buffer starts at 10000810 22.48.24 # hum 22.48.49 # /* 64K DMA-capable SRAM at 0x10000000 22.49.31 # preglow: oki.. so it's 0x10000000 -> 0x10010000 22.49.38 Quit Chamois ("CGI:IRC (EOF)") 22.49.43 # hubble: well, it would pretty much have to be 22.49.57 # that's where the non-dma sram starts, at least 22.50.03 # it's set up in crt0.s in firmware/ 22.50.39 # oh so only the 32KB can be used by DMA? 22.51.02 # scratch that, misread 22.56.22 # Meant RAMBAR not MBAR, obviously. Both SRAM banks can be moved to any 16KB boundary, independently 22.56.33 # i think SRAM is not very needed, since if we use it then we anyway need another bigger PCM buffer. I am sure that I am making some big mistake. But why anyone would want to copy data from PCM buffer to SRAM, since it would take even more CPU cycles than if we just make DMA copy from PCM buffer. I think bigger PCM buffer is needed since if we use crossfading between tracks, it is more than SRAM would give space for. 22.56.54 # Please correct me if i am wrong, since I am learning. :) 22.56.56 # by the way, there's theoretically power management benefits from marking either bank as only holding data, or code. 22.57.42 # Couldn't the decoder decode directly into SRAM (i.e. PCM buffer IS in SRAM) or would that just not work? 22.57.54 Nick Sucka`away is now known as Sucka (~NNSCRIPT@host81-156-213-142.range81-156.btcentralplus.com) 22.58.08 # yes, it will, but corssfading between tracks is not possible, 22.58.39 # or it is possible, but will make crossfading much harder for processor. 22.58.59 # As for crossfading, probably need two PCM buffers in SDRAM and generated the crossfaded buffer into SRAM so again no copying 22.59.23 *** Saving seen data "./dancer.seen" 23.00.18 # How were you planning to implement crossfading? 23.01.12 # Even if the whole 64K of DMA'able SRAM was used for PCM data, it would only hold 16000 stereo samples - which is only about a third of a second. I think we would need a bigger buffer than that, even without cross-fading. 23.01.53 # Really? What for? 23.02.15 # Imho the pcm buffer should only hold a few frames worth of samples 23.02.15 # I'm thinking mainly for safety - we don't want the buffer to ever become empty. 23.02.42 # Agreed - what would cause it to starve? 23.03.14 # one idea is that if we get decoder decode at somewhere near 105-110%(throwing info, did not calculate exactly), then before the track finished playing, the decoder already start to decode second track(several seconds before) and mix the info to the end of the first track. of course it require tracks to be a normal length( but i doubt that there are mant tracks shorter that one minute) 23.03.15 # the wierd thing about the original iRiver firmware is they only transfer 128 bytes each DMA transfer (and that buffer is 128), although they have 2 x ~9000 byte buffers in SRAM also.. I have not found out how they fill that 128 byte buffer 23.03.58 # err, 256 not 128 =) 23.04.01 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 23.04.15 # 0x80... 128 i think 23.05.06 Quit Strath ("Client closed") 23.06.06 # XShocK: but the buffer seams to be 256 bytes if you look at 10000810 (the next buffer starts at 10000910) 23.06.12 # wierd 23.08.03 # hubble: have you got an ida setup for the firmware? 23.08.34 # yes 23.08.42 # oops.. question not to me.. :) 23.08.53 # preglow: you want? 23.08.57 # i don't care who answers, what i want to know is, may i have it? ;) 23.09.01 # anyone ever make any modifications to the coldfire emulator? I never got a chance to do much but it seemed like it's not really necessary? 23.09.13 # preglow: sure 23.09.27 # stripwax: depends, it sure would be nice, but a gdb stub just might be easier and better 23.09.42 # but would require a hardware mod, i guess 23.09.43 # hubble does your ida setup handle the CF5249 instructions? 23.10.02 # stripwax: no, i have to manually fix some things 23.10.05 # hubble: where does it set the buffer to be 0x100, since i see only 0x80 even in the handler. 23.10.32 # preglow - a gdb simulated target might be better but then would probably just be a port of the coldfire emulator to the gdb sim framework :-( 23.10.45 # XShocK: it doesnt, but the buffer itself seams to be 0x100 23.10.47 # gdb hardware mod should be easy enough however 23.10.56 # aahh, ok :) 23.11.00 # oops, ^gdb^serial 23.11.52 # preglow: i use the rule that better to comment stuff (even if it might be wrong first) and fix later.. DCC or mail? 23.12.27 # hubble: thomj@pvv.ntnu.no, please 23.18.34 Quit preglow ("reboot") 23.20.24 Join preglow [0] (thomj@s183a.studby.ntnu.no) 23.21.24 # hubble: why 1.40, btw? 23.21.24 # preglow: the iriver has a fairly accessable serial port, the gdb stub can use that, all you have to do is solder some wires to it to make it work, i think 23.21.42 # HCl: yeah, know, just have to find a suitable place on the player for wires to be sticking out :P 23.21.47 # mmm. 23.21.53 # HCl: you'd also need a logic level converter 23.21.58 # well, we could write a gdb stub that works on audio signals :P 23.22.08 # haha 23.22.13 # serial over s/pdif 23.22.32 # haha 23.22.34 # preglow: i started looking at the iriver_memory_map wiki page and tried to follow.. had lots of problems before i understood things =) 23.22.44 # * HCl goes to sleep.. 23.27.16 # XShocK/hubble are you using bdm or not? 23.27.52 # stripwax: no, just the bootloader 23.28.09 # * HCl sighs and wishes he knew why rockboy crashed :/ 23.28.56 # no 23.28.58 # yeah.. I bought a BDM wiggler but haven't got around to opening the iRiver yet. I can't really afford to just donate it to Rockbox but I'll consider selling it at a discount if anyone needs it? 23.29.06 # has any1 built the bdm from those plans? 23.29.20 # all i have is USB cable and the player itself. :)) 23.30.57 # hubble: what ida version did you say you used? 23.31.40 # preglow: 4.7 23.32.19 # What's diff over 4.3 or 4.5? 23.33.04 # stripwax: think 4.7 is the first with the integrated debugger (for x86).. hum.. other than that i dont know 23.33.42 Quit olivierd ("Chatzilla 0.9.67 [Firefox 1.0/20041107]") 23.35.15 # * rasher punches iRiver's m3u support 23.35.25 # mine is also 4.7, and i couldn't open the hubble's base with neither 4.15 or 4.3 23.37.53 # >< 23.38.05 # What is the requirements of the m3us? 23.38.14 # For iRiver to be able to load it 23.41.14 # * HCl hasn't had any problems with m3u support.. 23.44.20 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- 100,000+ downloads can't be wrong") 23.44.45 # rasher - no absolute drive letters for one.. 23.45.10 # I don't use them however 23.45.35 # oh, and the direction of the slash must be correct (tho can't remember if it's forward slash or backslash..) 23.46.09 # back 23.56.36 # preglow, stripwax: do you know if you have to use DMA1 to transfer from SRAM (cause iriver does that and when I try to use DMA0 it works from SDRAM but not from SRAM) ? 23.58.38 # stripwax: Thanks 23.58.42 # hubble: no idea 23.58.59 # hubble, what preglow said