| 00:00:18 | amiconn_ | 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 | elinenbe | forget the calendar problem... there is a problem with recursive insert! |
| 00:02:35 | Bagder | then fix it! ;-) |
| 00:04:52 | | Part hubble |
| 00:07:22 | Bagder | amiconn: I'll make a little fix I think may fix the icon/image too |
| 00:07:45 | amiconn | Should I wait? I was about to apply simfix-10 |
| 00:07:56 | Bagder | try the -11 instead |
| 00:09:54 | amiconn | Building... |
| 00:10:30 | Bagder | Linux host detected |
| 00:10:33 | Bagder | Enabling win32 crosscompiling |
| 00:10:37 | Bagder | Using i386-mingw32msvc-gcc 2.95.3-6 (295) |
| 00:10:42 | LinusN | elinenbe: can you explain what is wrong with the insert? |
| 00:11:19 | Bagder | almost worked! |
| 00:11:43 | LinusN | elinenbe: ok, i see it |
| 00:15:14 | amiconn | 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 | Bagder | hehe, ftruncate() is defined to NULL in the old sim |
| 00:17:02 | Bagder | but no plugin uses it |
| 00:18:50 | HCl | wow, it actually compiled |
| 00:18:51 | HCl | o.o |
| 00:18:55 | HCl | without any compiler errors. |
| 00:19:04 | HCl | no internal compiler errors |
| 00:19:05 | HCl | i mean |
| 00:19:42 | amiconn | Bagder: Some warnings remain (in plugin.c and uisimulator/win32/io.c), and the image & icon are still missing |
| 00:20:10 | Bagder | I ignore the warnings for now, focusing on getting the build on all combos |
| 00:21:19 | HCl | woot. |
| 00:21:21 | HCl | what does this mean xD |
| 00:21:30 | HCl | I0B:Line-F |
| 00:21:35 | amiconn | 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 | HCl | at 30066BB8 |
| 00:21:53 | LinusN | HCl: illegal opcode |
| 00:21:54 | amiconn | HCl: That means an illegal 68k instruction |
| 00:21:59 | HCl | okay XD |
| 00:22:16 | HCl | thanks. |
| 00:24:12 | | Join webguest83 [0] (~447ad93b@labb.contactor.se) |
| 00:24:38 | amiconn | 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 | Bagder | 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 | Bagder | looks like a C99 requirement |
| 00:27:15 | amiconn | Bagder: Similar warnings when building the X11 sim with cygwin |
| 00:27:32 | amiconn | Bagder: Did you try the iriver sim? |
| 00:27:37 | Bagder | yes |
| 00:27:57 | Bagder | works fine, except the win32 crosscompile |
| 00:28:01 | amiconn | I could try the same. Do you have an idea what causes the still missing bg image + icon? |
| 00:29:02 | Bagder | not really, my win32 build at least builds a uisw32-res file... |
| 00:29:05 | Bagder | uh |
| 00:29:12 | Bagder | does it need to be name like the output perhaps? |
| 00:29:25 | amiconn | Nope |
| 00:29:29 | Bagder | I don't know much about resource files |
| 00:29:47 | amiconn | You renamed the .exe a while ago, it still had image + icon |
| 00:29:59 | Bagder | ah, I fixed a little thing |
| 00:30:05 | Bagder | $(WINDRES) −−include-dir $(OBJDIR) -i $< -o $@ |
| 00:30:14 | Bagder | is the new line, in win32/Makefile |
| 00:30:36 | amiconn | Currently building iriver-win32 sim, to check whether tremor builds... |
| 00:30:54 | Bagder | you have a newer gcc than my win32 |
| 00:31:07 | Bagder | so it might just work fine |
| 00:31:43 | * | HCl goes to figure out whats wrong with his opcode |
| 00:34:11 | amiconn | Bagder: Building tremor only shows a line 'AR /home/Administrator/rb-patched/simulator-build/iriver/libTremor.a' !?? |
| 00:34:57 | amiconn | mpa2wav.c errors out |
| 00:35:11 | amiconn | mpa2wav.c:94: undefined reference to `_mad_stream_init' |
| 00:35:16 | amiconn | mpa2wav.c:63: undefined reference to `_mad_stream_buffer' |
| 00:35:36 | Bagder | well, those are issues beyond this current work |
| 00:35:50 | amiconn | Yes of course. Only wanted to mention that |
| 00:36:13 | amiconn | The important thing is that the simulator itself and most plugins build, and work |
| 00:36:21 | Bagder | yes |
| 00:36:31 | amiconn | The rest is then solved case by case |
| 00:37:53 | amiconn | Bagder: Haha, funny: 'make install' now copies the executable into archos/ on the sims... |
| 00:38:08 | Bagder | oh |
| 00:38:16 | Bagder | very useful! |
| 00:38:18 | Bagder | :-P |
| 00:38:53 | amiconn | Hmm, plugins don't work on both sims... :( |
| 00:39:00 | HCl | hm. |
| 00:39:05 | LinusN | elinenbe: i have fixed the recursive insert, please try the next bleeding edge, or tomorrow's daily build |
| 00:39:07 | amiconn | The X11 sim says 'Win32 error 5' |
| 00:39:46 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 00:39:50 | AC | hi |
| 00:40:42 | Bagder | so, I'll hold off the commit |
| 00:40:47 | linuxstb | AC: Hi. How are things with wv? |
| 00:41:55 | AC | linuxstb: i should have it in about 30 mins |
| 00:42:04 | HCl | i don't get this... |
| 00:42:09 | HCl | DOH> |
| 00:42:12 | HCl | nevermind >.> |
| 00:42:15 | linuxstb | 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 | amiconn | 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 | AC | linuxstb: not yet... in a few minutes |
| 00:44:12 | Bagder | amiconn: ok, I duplicate the logic for it |
| 00:45:58 | amiconn | And I found the problem with the missing image / icon: You do not link with uisw32-res.o ... |
| 00:46:03 | rashur | 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 | Bagder | amiconn: I need to add that special somewhere? |
| 00:47:19 | amiconn | This needs to be linked to the sim executable. |
| 00:49:34 | Bagder | but I don't see why it isn't |
| 00:49:58 | amiconn | It does not appear on the linker command line... |
| 00:50:23 | Bagder | no, since it is in the libsim.a |
| 00:50:45 | Bagder | try 'ar tv libsim.a' to view the contents of it |
| 00:51:24 | amiconn | Yes, it's there. However, this may not be enough |
| 00:51:58 | amiconn | 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 | amiconn | Btw, I can't find the place where the executable is linked. Is that now part of apps/Makefile? |
| 00:53:15 | AC | is there a way to debug a plugon on the iriver? |
| 00:53:20 | Bagder | amiconn: yes it is |
| 00:53:38 | Bagder | I like the new look on the cvs table while a build is in progress! |
| 00:54:48 | Bagder | crappy estimate though |
| 00:54:50 | Bagder | :-) |
| 00:54:59 | Patr3ck | 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 | linuxstb | AC: Not really. You could open a file and write debugging information to it - or display information on the LCD. |
| 00:55:43 | AC | linuxstb: ok |
| 00:55:46 | Bagder | AC: simple plugins can be run in the simulator, but I guess yours isn't ;-) |
| 00:56:05 | amiconn | 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 | Bagder | ok, then we just need to make that happen in a nice way |
| 00:56:46 | amiconn | Or find out how to link kin a resource from a library |
| 00:56:55 | amiconn | *link in |
| 00:57:05 | AC | semms that there is an error in WavpackUnpackSamples function... will look closer at it |
| 00:57:27 | Bagder | rashur: probably not that much from .dk |
| 00:57:44 | Bagder | I need to sleep now |
| 00:57:49 | rashur | That's what I figured. And I'm not too keen on paypal really. |
| 00:57:58 | amiconn | Bagder: No commmit? |
| 00:58:10 | linuxstb | AC: Does your plugin crash at the moment? |
| 00:58:14 | Bagder | I don't feel like sitting up fixing the quirks now |
| 00:58:19 | Bagder | I'll try to do it tomorrow |
| 00:58:32 | AC | linuxstb: yep... i am looking at the moment why |
| 00:58:48 | amiconn | Bagder: Hmm, okay :-/ (no offense) |
| 00:58:48 | AC | linuxstb: i know where it crashes |
| 00:58:57 | *** | Saving seen data "./dancer.seen" |
| 00:59:05 | Bagder | amiconn: worst case, you can do the commit, there's a fresh patch uploaded |
| 00:59:19 | linuxstb | AC: Does it make use of the stack? If I remember correctly, the stack is currently about 32K. |
| 00:59:33 | Bagder | good night |
| 00:59:35 | amiconn | Bagder: I think it's easier to fix the quirks within cvs |
| 00:59:48 | Bagder | amiconn: it is |
| 00:59:55 | Bagder | feel free to commit if you want to |
| 00:59:57 | amiconn | Does it at least build on Linux |
| 00:59:58 | amiconn | ? |
| 01:00 |
| 01:00:04 | Bagder | yes it does |
| 01:00:10 | AC | linuxstb: it looks now much better... |
| 01:00:10 | Bagder | both plain and sim |
| 01:00:53 | AC | linuxstb: it is not working atm, but i got a step into the correct dir |
| 01:01:06 | amiconn | 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 | HCl | okay. |
| 01:01:19 | HCl | i'm at the point |
| 01:01:25 | HCl | where i just need an assembly-level debugger |
| 01:01:25 | amiconn | Bagder: Good night. |
| 01:01:26 | HCl | :( |
| 01:02:01 | Patr3ck | I have created a few simple functions for profiling that use e.g. file.h, sprintf.h from rockbox |
| 01:02:14 | Patr3ck | these should be used by the codec libraries |
| 01:02:15 | amiconn | Bagder: I'll check for that odd windows linker problem meanwhile |
| 01:02:50 | Patr3ck | can someone point me into a general direction how to get access to these from the codec libraries? |
| 01:03:40 | Patr3ck | at the moment I get undefined references |
| 01:03:51 | Patr3ck | when linking |
| 01:04:07 | amiconn | You cannot use these rockbox includes directly from within plugins |
| 01:04:20 | amiconn | Instead, you have to use the plugin api |
| 01:04:32 | | Quit pillo (Read error: 110 (Connection timed out)) |
| 01:04:40 | Patr3ck | These are used in the codec libraries... |
| 01:04:49 | Patr3ck | not in the plugin itself |
| 01:05:03 | amiconn | Yes, and the codec libraries are use from within the plugins... |
| 01:05:15 | amiconn | The codec libs are never linked against core rockbox |
| 01:06:08 | AC | sometimes it is nedded |
| 01:06:17 | Patr3ck | can I access the plugin api from within e.g. libmad? |
| 01:06:21 | AC | e.g. strcpy |
| 01:06:34 | AC | it would be nice, if i could use it in the codec |
| 01:06:48 | preglow | well you'll pretty much have to, heh |
| 01:06:54 | amiconn | Hmm. I don't know how it is adapted currently. You would need a copy of the plugin api pointer |
| 01:07:03 | preglow | i don't think the ordinary functions are even available |
| 01:07:16 | linuxstb | 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 | AC | fine |
| 01:07:40 | Patr3ck | so at the moment it is not possible? |
| 01:07:42 | amiconn | The only other option is to compile and link a private version, but that's ugly imho |
| 01:07:54 | preglow | yes, it is |
| 01:08:04 | linuxstb | 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 | amiconn | linuxstb: How do you wrap? |
| 01:09:26 | Patr3ck | linuxstb: i could add the profiling functions there too and access them from within the codec library? |
| 01:09:39 | preglow | hrm |
| 01:09:48 | preglow | perhaps i should try coding my profiling idea |
| 01:10:08 | linuxstb | amiconn: the codecs libraries themselves include firmware/include/*.h, and then I implement those functions in xxx2wav.c by calling rb->??? |
| 01:11:43 | amiconn | 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 | amiconn | The question is, how do you wrap these function in the codecs? |
| 01:14:47 | amiconn | 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 | amiconn | I think this is okay for the test plugins |
| 01:15:36 | AC | so i can use strcpy via the plugin api? |
| 01:16:06 | amiconn | 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 | linuxstb | 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 | linuxstb | 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 | AC | ok |
| 01:18:12 | Patr3ck | linuxstb: I am trying to add them to xxx2wav.h and use the plugin api |
| 01:18:51 | Patr3ck | linuxstb: they are only temporary anyway I think |
| 01:19:03 | linuxstb | Patr3ck: the problem with that is that the codecs shouldn't really be including xxx2wav.h |
| 01:19:42 | Patr3ck | linuxstb: ah, too bad, only the plugin itself should do that? |
| 01:20:14 | linuxstb | It's a bit like a system library including part of your application. |
| 01:20:24 | Patr3ck | yes |
| 01:21:08 | Patr3ck | I could wait, but performance measurement would be helpful now |
| 01:21:36 | amiconn | linuxstb: I just found that you define dprintf(). Imho this shouldn't be necessary, you can use debugf() |
| 01:22:35 | linuxstb | amiconn: Does debugf do the same as my dprintf? |
| 01:23:12 | amiconn | Almost. It does printf() in the simulators (unless you hook a win32 sim into a windows debugger) |
| 01:23:31 | linuxstb | OK, I'll change to use that then. Thanks. |
| 01:23:35 | amiconn | On the target, it does the same (i.e. nothing) unless you create a debug build |
| 01:24:19 | amiconn | A debug build can actually output this using a gdb stub. I know, no such stub does exist yet for iriver. |
| 01:25:29 | HCl | mmmm. |
| 01:25:31 | HCl | tell me about it :/ |
| 01:25:46 | amiconn | HCl: There is a debug stub for archos... |
| 01:25:48 | linuxstb | 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 | HCl | amiconn: tell me when you got some free time to help me with rockboy a bit... |
| 01:26:11 | preglow | is it hard to generate an address map of all rockbox functions? |
| 01:26:17 | HCl | i think i need a bit of help with debugging it |
| 01:26:22 | preglow | i'd pretty much need that for the profiler |
| 01:26:48 | amiconn | preglow: When you compile, a .map file should be created too... |
| 01:27:22 | amiconn | However, it does only list global functions. Statics are left out |
| 01:28:05 | preglow | amiconn: yes, so it seems... |
| 01:28:12 | preglow | hmm |
| 01:28:16 | preglow | that might be a show stopper |
| 01:28:47 | Patr3ck | linuxstb: I will try that |
| 01:29:46 | rashur | hrm |
| 01:29:48 | | Nick rashur is now known as rasher (~rasher@62.79.64.148.adsl.hs.tiscali.dk) |
| 01:29:49 | rasher | better. |
| 01:29:58 | preglow | amiconn: no codec symbols are included, and that's pretty much the reason i want to make a profiler |
| 01:30:59 | Patr3ck | linuxstb: but I am wondering how this would give me access to the rockbox functions |
| 01:31:21 | | Quit Renko ("Leaving") |
| 01:35:24 | XShocK | 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 | XShocK | #define ICR0 (*(volatile unsigned long *)(MBAR + 0x04c)) |
| 01:35:40 | XShocK | #define ICR4 (*(volatile unsigned long *)(MBAR + 0x050)) |
| 01:35:40 | XShocK | #define ICR8 (*(volatile unsigned long *)(MBAR + 0x054)) |
| 01:35:40 | DBUG | Enqueued KICK XShocK |
| 01:35:40 | XShocK | #define ICR6 (*(volatile unsigned long *)(MBAR + 0x052)) |
| 01:36:59 | linuxstb | Patr3ck: You're right, it wouldn't. |
| 01:37:00 | XShocK | ICR6 was added by me, so it is not in rockbox in cvs |
| 01:37:16 | LinusN | the internal register map is not byte addressable |
| 01:37:36 | XShocK | aa ok. didn't think about that. |
| 01:40:17 | Patr3ck | linuxstb: seems there is no clean solution at the moment |
| 01:40:54 | linuxstb | 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 | Patr3ck | 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 | preglow | woot, iram for codecs |
| 01:46:42 | | Quit AC ("CGI:IRC (EOF)") |
| 01:47:21 | preglow | speed test it, quick! |
| 01:47:23 | preglow | :) |
| 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 | amiconn | Does the coldfire have a cache? I guess so... |
| 01:51:01 | preglow | amiconn: instruction cache |
| 01:51:14 | amiconn | Ah, so this may be HCl's problem... |
| 01:51:19 | elinenbe | LinusN: thanks so much... works great for me! |
| 01:51:20 | HCl | what? |
| 01:51:25 | preglow | amiconn: indeed |
| 01:51:28 | HCl | what? |
| 01:51:40 | HCl | o.o |
| 01:51:41 | preglow | amiconn: plus there's 96kbyte of iram that's single cycle access |
| 01:51:51 | amiconn | HCl: The coldfire has an instruction cache. Doing dynarec is the same as having self-modifying code... |
| 01:52:06 | HCl | well, yes. but. um. huh? |
| 01:52:19 | HCl | how does that relate to what i'm doing? |
| 01:52:26 | amiconn | You need to invalidate the cache in order to tell the cpu to re-read from memory |
| 01:52:41 | preglow | no, it's not really the same at all, i think |
| 01:53:07 | HCl | i'm sort of doing the same thing when loading a module |
| 01:53:15 | HCl | except i'm not loading code from disk but writing it on the fly |
| 01:54:29 | amiconn | Yes, that's correct. However, if you load a new module, the area was not previously cached |
| 01:55:08 | amiconn | And if you load a new module in place of an old one, this may indeed cause the same problem |
| 01:56:07 | amiconn | That just came to mind as I read a bit about a ZX Spectrum emulator for the Amiga. |
| 01:57:10 | amiconn | LinusN: Does rockbox already handle these caching issues? |
| 01:57:26 | HCl | um... |
| 01:57:36 | HCl | what do you mean the area was not previously cached... |
| 01:57:46 | LinusN | amiconn: the cache is invalidated when loading plugins |
| 01:57:59 | HCl | LinusN: where's the code for invalidating the cache..? |
| 01:58:12 | LinusN | system.h |
| 01:58:15 | HCl | kay.. |
| 01:58:22 | HCl | but i don't think it has to do with it though |
| 01:58:28 | HCl | cause earlier i got an invalid opcode error |
| 01:58:31 | HCl | and now it just freezes |
| 01:58:42 | HCl | i added a return from subroutine opcode to it.. |
| 01:58:49 | amiconn | HCl: You may need to call that every time you compile a new sequence |
| 01:58:55 | HCl | amiconn: yea, i get the idea |
| 02:00 |
| 02:01:21 | HCl | kay, i added that. |
| 02:01:38 | | Quit Patr3ck () |
| 02:03:10 | amiconn | LinusN: I guess using invalidate_icache() is okay within plugins, as it is an inline function anyway? |
| 02:03:23 | LinusN | yes |
| 02:03:27 | LinusN | gotta go to sleep |
| 02:03:32 | LinusN | cu tomorrow |
| 02:03:36 | AC | good night |
| 02:03:39 | | Part LinusN |
| 02:03:58 | HCl | nop, freezes |
| 02:06:11 | HCl | 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 | MO-Pantsu | sleep? |
| 02:06:26 | MO-Pantsu | how dare he sleep. he must work 24/7 on iRiver! :D |
| 02:06:56 | amiconn | HCl: Yes it worked. However, I changed that meanwhile if you have a look at apps/plugins/rockboy.c |
| 02:07:13 | amiconn | Now I use a struct instead of an array, within the correct pointer type |
| 02:09:35 | preglow | 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 | HCl | k.. |
| 02:10:33 | | Join mecraw [0] (~mecraw@c-24-9-220-243.client.comcast.net) |
| 02:10:58 | rasher | Mostly because I have no idea why I started it. |
| 02:12:31 | HCl | oh.. well.. yea. |
| 02:12:32 | HCl | i'm dumb. |
| 02:12:33 | HCl | o.o |
| 02:12:41 | * | HCl thinks he found the bug ^^ |
| 02:12:56 | HCl | hm, wait, nm :/ |
| 02:13:56 | * | AC needs help |
| 02:14:09 | AC | warning: this decimal constant is unsigned only in ISO C90 |
| 02:14:21 | AC | warning: integer overflow in expression |
| 02:14:30 | AC | min_shifted = (min_value = -(long)2147483648 >> shift) << shift; |
| 02:16:19 | HCl | ugly code.. |
| 02:16:29 | rasher | >.< |
| 02:16:40 | HCl | first of all |
| 02:16:44 | AC | not mine... libwavpack |
| 02:16:45 | HCl | get the min_value bit out |
| 02:16:53 | HCl | and make min_shifted = min_value << shift; |
| 02:17:25 | linuxstb | 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 | preglow | just tested it at 6.50 here :/ |
| 02:17:57 | preglow | does −−best encoding give more lpc frames? |
| 02:18:01 | linuxstb | I must have a faster iRiver then :-) |
| 02:18:05 | XShocK | and isn't it better to make that 2147483648 be 0x80000000 |
| 02:18:31 | preglow | XShocK: LONG_MIN even better |
| 02:18:41 | AC | XShocK: i dont know... |
| 02:18:52 | XShocK | preglow: yes. |
| 02:19:01 | linuxstb | preglow: I forget the details, but http://flac.sourceforge.net/ has excellent documentation. "man flac" is also good. |
| 02:20:10 | AC | where is LONG_MIN declared? |
| 02:20:22 | | Quit mecraw () |
| 02:20:38 | preglow | −−best sets max order lpc = 12, hyes |
| 02:20:47 | preglow | AC: limits.h, might not be in rockbox for all i know |
| 02:21:21 | linuxstb | preglow: According to the man page, "−−best" is equivalent to "-8", which means it searches for order-12 lpc predictors. |
| 02:21:30 | AC | preglow: so we need now a limits.h |
| 02:22:18 | preglow | AC: just use 0x80000000 |
| 02:22:32 | AC | preglow: ok |
| 02:28:33 | | Quit edx (Read error: 110 (Connection timed out)) |
| 02:35:07 | MO-Pantsu | MP3 b4 everything! ;) |
| 02:41:19 | | Nick MO-Pantsu is now known as DeadMan (Rori@deadman3000.plus.com) |
| 02:46:40 | preglow | but bed |
| 02:46:53 | | Quit preglow ("omglolmao") |
| 02:48:36 | XShocK | 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 | XShocK | 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:00 |
| 03:03:32 | | Quit amiconn (" HydraIRC -> http://www.hydrairc.com <- Leading Edge IRC") |
| 03:05:46 | DeadMan | 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 | bagawk | [IDC]Dragon, hey |
| 03:56:55 | bagawk | Me have forums :) http://leepil.dyndns.org/phpbb2 |
| 04:00 |
| 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:00:05 | | Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 05:44:00 | | Quit cYmen ("leaving") |
| 06:00 |
| 06:01:29 | | Join YouCeyE [0] (foobar@vp089036.reshsg.uci.edu) |
| 06:35:02 | rasher | 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 | rasher | okay, nevermind me |
| 06:59:03 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:00:29 | rasher | 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 | rasher | Heh |
| 08:12:15 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 08:15:45 | [IDC]Dragon | 'morning! |
| 08:16:15 | LinusN | morning |
| 08:17:42 | dwihno | howdy ho |
| 08:18:27 | LinusN | 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 |
| 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 | bobTHC | good morning ! |
| 09:33:01 | | Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 09:36:22 | HCl | morningsomething |
| 09:39:58 | ashridah | hcl |
| 09:40:17 | * | HCl falls asleep again |
| 09:47:06 | | Join amiconn [0] (~jens@pD9E7FF98.dip.t-dialin.net) |
| 09:47:26 | amiconn | hi |
| 09:50:17 | [IDC]Dragon | 'morning! |
| 09:50:51 | rasher | It sure is. |
| 09:58:55 | amiconn | Bagder: R u there? |
| 10:00 |
| 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 |
| 11:00:22 | LinusN | amiconn: how are the sim builds working for you? |
| 11:03:12 | amiconn | 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 | amiconn | His -11 fix works, sort of, while his -13 fix breaks |
| 11:07:44 | DeadMan | 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 | ashridah | 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 | DeadMan | will be interesting to see what happens |
| 11:14:44 | ashridah | 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 | DeadMan | aye |
| 11:15:33 | ashridah | 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 | HCl | yawn. |
| 11:48:14 | HCl | morning thing. |
| 11:53:32 | Bagder | amiconn: so what's the prob with -13? |
| 11:55:22 | amiconn | For win32, it produces a linker error |
| 11:55:36 | amiconn | The x11 build doesn't even compile to the end |
| 11:57:16 | amiconn | 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 | Bagder | aha |
| 11:57:33 | Bagder | thanks |
| 11:59:20 | * | HCl wonders whether amiconn has auto accept.. |
| 11:59:30 | amiconn | I have... |
| 11:59:30 | HCl | amiconn: here's my source for rockboy at the moment |
| 11:59:53 | Bagder | amiconn: but the win32 build failed to link with the sim_ftruncate for some reason |
| 12:00 |
| 12:00:14 | amiconn | Yeah... it doesn't find the symbol when linking... |
| 12:00:33 | amiconn | I did not yet find the reason why |
| 12:03:38 | amiconn | I'll retry; perhaps it was my fault... |
| 12:04:21 | | Join Ka_ [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) |
| 12:08:45 | amiconn | Bagder: Hmm, strange. Now it worked... (win32). |
| 12:09:04 | Bagder | probably just the bad dependency stuff |
| 12:09:07 | Bagder | that hit you |
| 12:09:29 | amiconn | I thought I did 'make clean', but now I'm not so sure... |
| 12:09:30 | Bagder | I found the x11 problem too |
| 12:09:52 | Bagder | there's a patch -14 now |
| 12:12:24 | amiconn | Did you add the direct resource linking? |
| 12:14:29 | amiconn | lunch.. |
| 12:17:18 | | Quit linuxstb (Read error: 60 (Operation timed out)) |
| 12:18:45 | Bagder | 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 | Bagder | 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 | HCl | do instructions have to be memory aligned? and if so, how do i make sure they are? |
| 12:59:07 | amiconn | ..back |
| 12:59:11 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:00:38 | ashridah | HCl: from my basic 68k knowledge, no. only the stack has to be two-byte aligned. |
| 13:01:11 | amiconn | HCl: I think 68k can work without, but proper alignment wil speed things up |
| 13:02:12 | HCl | yea. |
| 13:02:27 | HCl | *sighs* |
| 13:04:10 | amiconn | What's the problem with aligning them? If you start the block aligned, further instructions should be aligned as well |
| 13:05:33 | HCl | yea, i know |
| 13:05:42 | HCl | i'm just not sure on the definition of aligned |
| 13:05:42 | HCl | :p |
| 13:06:13 | HCl | i'm still a bit annoyed at not being able to call a function that does a simple return from subroutine.. |
| 13:06:58 | ashridah | anyone happen to have a link to a reference for gnu assembler's syntax |
| 13:07:06 | ashridah | ? |
| 13:07:09 | HCl | amiconn has one.. |
| 13:07:49 | ashridah | hmm. guess i can use the info page in a pinch |
| 13:08:56 | amiconn | ashridah: http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC104 |
| 13:11:18 | ashridah | amiconn: nice. that'll help too. definently unfamiliar with c/asm mixing. |
| 13:16:53 | amiconn | Bagder: Both win32 and x11 build now. Image & icon are there for win32 |
| 13:16:59 | Bagder | cool |
| 13:17:21 | amiconn | X11 is working nicely, Win32 still misses the execute permission on plugins |
| 13:17:21 | Bagder | should I commit? |
| 13:17:40 | Bagder | 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 | amiconn | There are some warnings left, but I think you could commit |
| 13:18:05 | Bagder | ok, buckle up |
| 13:18:09 | Bagder | huge commit coming |
| 13:18:12 | | Join Patr3ck_ [0] (~patr3ck@pD9ECF5DD.dip.t-dialin.net) |
| 13:18:13 | amiconn | I'll try to fix the remaining warnings in the evening |
| 13:18:46 | sox | hoy all, I asked this before but havent found any way to solve it so I figure I might ask again |
| 13:19:18 | sox | I get this error trying to run make for the iriver build on my mac os x 10.3.8 |
| 13:19:19 | Bagder | committted |
| 13:19:29 | sox | Using m68k-elf-gcc 3.4.3 (304) |
| 13:19:29 | sox | Created Makefile |
| 13:19:29 | sox | c-503fe255:~/rockbox/rockbox-devel/uibuild svante$ make |
| 13:19:29 | DBUG | Enqueued KICK sox |
| 13:19:29 | sox | make[1]: *** No rule to make target `#pragma', needed by `/Users/svante/rockbox/rockbox-devel/uibuild/dep-firmware'. Stop. |
| 13:19:29 | sox | make: *** [all] Error 2 |
| 13:19:57 | Bagder | I believe your gcc produces a #pragma file in the shell magic in the top of the firmware/Makefile |
| 13:20:00 | sox | this time i tried building the uisim, but it's the same error building the normal version |
| 13:20:07 | Bagder | a #pragma line even |
| 13:20:45 | sox | this error came from nothing three days ago, some change in the code must have caused it |
| 13:20:55 | ashridah | sox: can you show us a copy of the Makefile that's being generated by tools/configure ? |
| 13:21:26 | sox | the whole file? |
| 13:21:29 | amiconn | Bagder: Different thing: There is still no current daily for Ondio FM, and the daily windows installer builds are also missing... |
| 13:21:44 | ashridah | sox: toss it up on a website or something'd be easiest. |
| 13:22:01 | ashridah | although i suspect i'm asking for the wrong makefile. |
| 13:22:11 | Bagder | amiconn: I know, but I have no time to fix that now |
| 13:22:23 | Bagder | zagor or Linus will have to do it, or wait |
| 13:22:50 | amiconn | Okay, just wanted to mention... |
| 13:23:05 | sox | ashridah: http://jordfrihet.org/Makefile |
| 13:23:12 | Bagder | it is most likely because of the "flash full" error |
| 13:23:15 | Bagder | somehow |
| 13:24:26 | sox | ashridah: that's the root Makefile, did you want the firmware/Makefile? |
| 13:24:34 | Bagder | sox: can you show us how your dep-firmware looks like? |
| 13:25:13 | sox | http://jordfrihet.org/Makefile_fw is for firmware |
| 13:25:59 | ashridah | yeah, put up a copy of the dep-firmware file. |
| 13:26:18 | sox | Bagder: where is it? |
| 13:26:22 | ashridah | just run 'make dep' if it doesn't exist. (don't know if it gets destroyed) |
| 13:26:26 | Bagder | sox: in your build dir |
| 13:26:29 | ashridah | should be in the directory you're compiling in |
| 13:27:13 | sox | sorry, it's not there |
| 13:27:45 | Bagder | ok |
| 13:27:53 | ashridah | wait. this is an osx box isn't it? are you using gnu make or bsd's make? |
| 13:27:59 | ashridah | try gmake ? |
| 13:28:07 | sox | not found |
| 13:28:09 | Bagder | ah! |
| 13:28:11 | Bagder | indeed |
| 13:28:15 | Bagder | you must use GNU make |
| 13:28:24 | sox | ok! |
| 13:28:28 | ashridah | okay. i'm not that familiar with osx, so i don't know which it includes. |
| 13:28:56 | sox | 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 | ashridah | yeah, usually environments that add it give it a different name, hence 'gmake' for gnu make on these systems. |
| 13:29:44 | ashridah | i'm not sure why that wouldn't be there, unless you didn't install the development resources for osX |
| 13:29:52 | sox | i sure did |
| 13:30:15 | ashridah | okay, what's the first line of output from running 'make −−version' |
| 13:30:16 | ashridah | ? |
| 13:30:48 | sox | GNU Make version 3.79,... |
| 13:30:56 | ashridah | hm. that should be okay then |
| 13:31:01 | ashridah | run 'make dep' |
| 13:31:20 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new IRC era") |
| 13:31:22 | sox | make: *** No rule to make target `dep'. Stop. |
| 13:31:34 | Bagder | it is meant to handle them automaticly |
| 13:31:39 | amiconn | 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 | Bagder | amiconn: I don't know |
| 13:32:11 | ashridah | ah, hang on. the dep target is only in the firmware makefile, not the simulator one |
| 13:32:12 | ashridah | odd |
| 13:32:18 | Bagder | amiconn: perhaps there was a sys/types.h in the past |
| 13:32:34 | Bagder | ashridah: the sim uses the firmware makefile nowadays |
| 13:32:55 | ashridah | Bagder: yeah, i'm curious as to why these two are markedly different. |
| 13:32:59 | Bagder | oh right, there's a 'dep' there |
| 13:33:35 | Bagder | but there's no 'dep' in the root Makefile so it doesn't work |
| 13:33:39 | amiconn | Bagder: It gave this warning for uisimulator/common/dir.h, uisimulator/common/file.h and uisimulator/x11/kernel.h |
| 13:34:05 | sox | are you talking about something that affects my error too? |
| 13:34:42 | Bagder | ouch, player build broke |
| 13:34:46 | ashridah | sox: okay, run 'make -n' |
| 13:34:59 | ashridah | and take a copy of the entire output, toss it into a file, and show us it |
| 13:34:59 | sox | make -C /Users/svante/rockbox/rockbox/firmware |
| 13:34:59 | sox | make[1]: *** No rule to make target `#pragma', needed by `/Users/svante/rockbox/rockbox/build/dep-firmware'. Stop. |
| 13:34:59 | sox | make: *** [all] Error 2 |
| 13:35:06 | sox | that's it |
| 13:35:28 | | Quit Patr3ck (Read error: 110 (Connection timed out)) |
| 13:35:45 | Bagder | sox: cd to the firmware dir,then run this command: |
| 13:36:33 | Bagder | cat SOURCES | gcc -E -P |
| 13:36:50 | Bagder | eh, no... |
| 13:36:57 | Bagder | ...it'll fail on the include |
| 13:37:41 | Bagder | cat SOURCES | gcc -Iexport -I. -E -P |
| 13:37:53 | Bagder | I suspect it adds #pragma lines to the output |
| 13:38:04 | sox | "no input files" |
| 13:38:15 | Bagder | cat SOURCES | gcc -Iexport -I. -E -P - |
| 13:38:20 | Bagder | (added a dash) |
| 13:38:47 | sox | the first line says: #pragma GCC set_debug_pwd "/Users/svante/rockbox/rockbox/firmware" |
| 13:38:53 | Bagder | there it is |
| 13:38:58 | Bagder | the problem is identified |
| 13:39:02 | | Join jyp [0] (~jp@234.81-201-80.adsl.skynet.be) |
| 13:39:10 | Bagder | now we need a way to switch off that |
| 13:43:14 | ashridah | seems to be an apple-specific feature |
| 13:43:21 | sox | yes |
| 13:43:22 | Bagder | "feature" |
| 13:43:25 | Bagder | ;-) |
| 13:43:47 | Bagder | try adding -xassembler-with-cpp to the gcc options |
| 13:43:53 | | Join R3nTiL [0] (~zorroz@217.30.249.222) |
| 13:43:57 | ashridah | haha |
| 13:44:01 | ashridah | " |
| 13:44:01 | ashridah | 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 | Bagder | they should've used -E as a hint |
| 13:44:49 | Bagder | eh, no I mean -P |
| 13:45:08 | Bagder | (which is the disable #line lines option) |
| 13:46:31 | sox | is there any easy way to do this so that I dont have to do it manually every time |
| 13:46:50 | Bagder | we need to fix the Makefiles to use this option |
| 13:47:05 | Bagder | the same trick is used in most Rockbox makefiles |
| 13:50:58 | amiconn | Bagder: Red builds for the player sims (didn't check these :( ) and an fprintf is left in radio.c |
| 13:51:01 | sox | I tried adding -xassembler-with-cpp to the GCCOPTS, didnt change anything, any other places I have to change |
| 13:51:04 | ashridah | 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 | Bagder | ...I noticed, working on some of them |
| 13:51:35 | ashridah | sox: the preprocessor probably doesn't get passed GCCOPTS |
| 13:51:42 | Bagder | sox: the GCCOPTS is not used for that invoke |
| 13:51:47 | ashridah | since it's not, strictly speaking, compiling anything. |
| 13:51:47 | sox | ah ok |
| 13:51:54 | ashridah | it's just the preprocessor |
| 13:52:08 | Bagder | sox: try the extra defines |
| 13:52:24 | Bagder | but it's a hack |
| 13:52:41 | Bagder | even if it might work as a quick work-around |
| 13:55:05 | sox | Bagder: you mean like this: "export EXTRA_DEFINES=-xassembler-with-cpp" |
| 13:55:23 | Bagder | yes |
| 13:55:41 | sox | it compiles, but with a shitload of errors |
| 13:56:23 | Bagder | :-/ |
| 13:57:31 | ashridah | Bagder: for a stopgap, he could try using the preprocessor that he would have built targetting the m68k? |
| 13:57:43 | Bagder | ah, yes |
| 13:57:53 | sox | 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 | ashridah | it probably won't do the trick for the simulators, but it'd get him a built firmware |
| 13:58:07 | Bagder | in fact, we were using that before...and I changed to the native one, which is why this problem appeared |
| 13:58:11 | ashridah | sox: apple modified the c preprocessor to add extra junk for their IDE xcode |
| 13:58:41 | ashridah | 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 | sox | Bagder: ok |
| 13:59:01 | Bagder | this is truly the fault of Apple's gcc doing stupid things |
| 13:59:17 | Bagder | stupid stupid stupid |
| 13:59:29 | Bagder | but it doesn't help you |
| 13:59:32 | sox | OK Ill call them asap :-/ |
| 14:00 |
| 14:00:19 | ashridah | sox: i wouldn't bother. knowing them, they won't fix it until the next major release, if then. |
| 14:00:29 | sox | nah I was kidding |
| 14:00:40 | ashridah | your best bet is to join the chorus bitching on their development forums and placing bug reports. |
| 14:01:04 | sox | so there's no simple workaround then... |
| 14:01:18 | ashridah | sox: yes, there is. |
| 14:01:23 | ashridah | use m68k-elf-cpp |
| 14:01:26 | ashridah | instead of 'gcc' |
| 14:01:47 | Bagder | $(GCC) is the target one |
| 14:02:03 | ashridah | in the SRC variable inside the firmware/Makefile file. |
| 14:02:09 | Bagder | $(CC) even |
| 14:03:23 | Bagder | the problem was that my win32 cross-compile gcc doesn't support the -include option |
| 14:03:29 | ashridah | 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 | ashridah | which should do in a pinch |
| 14:04:06 | ashridah | argh. |
| 14:04:14 | Bagder | sox: you need this fix in all Makefiles that do this trick |
| 14:04:15 | ashridah | bagder's right. m68k-elf-gcc |
| 14:04:33 | ashridah | hrm. and more than one place? ick. |
| 14:04:39 | Bagder | yes |
| 14:04:48 | Bagder | :-( |
| 14:04:58 | ashridah | Bagder: ouch. could at least have used CC instead of 'gcc' in the command :) |
| 14:05:00 | Bagder | but we need to fix this |
| 14:05:46 | sox | this works, but you're right, I have to modify all Makefiles |
| 14:05:56 | amiconn | Bagder: Is it possible to replace your oldish windows cross-gcc with something newer? What would be necessary to do this? |
| 14:06:00 | ashridah | well, googling for the parameter shows a lot of people bitching, the occasional reference to xcode, and the odd dodgy workaround |
| 14:06:00 | Bagder | 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 | Bagder | 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 | amiconn | 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 | Bagder | 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 | amiconn | So how did you create the old cross gcc? |
| 14:08:52 | Bagder | that's why this is a mingw cross-compile thing |
| 14:09:13 | Bagder | I'm afraid to tell ;-) |
| 14:09:22 | Bagder | ... I downloaded a binary |
| 14:09:24 | Bagder | hehe |
| 14:09:34 | sox | ashridah: I had to modify the makefiles in apps/, plugins/, plugins/lib/ and firmware/ but after doing it it compiled fine |
| 14:09:42 | sox | ashridah: so thanks for the help |
| 14:10:21 | sox | ashridah: i hope this is something that you can solve (since I can't, lack programming abilities ;-() |
| 14:10:54 | amiconn | Bagder: Maybe this url is helpful: http://www.wxwidgets.org/technote/crosscmp.htm |
| 14:12:17 | Bagder | for "egcs on Linux" |
| 14:12:42 | Bagder | but I'll keep the URL and try next week |
| 14:13:27 | ashridah | sox: it's really something apple can 'solve' |
| 14:13:30 | ashridah | we can only really work around it |
| 14:13:51 | sox | ashridah: I understand that |
| 14:14:20 | sox | ashridah: and this workaround is OK, not very time consuming |
| 14:14:20 | amiconn | Bagder: "EGCS was an experimental step in the development of GCC, the GNU C compiler." |
| 14:14:27 | Bagder | I know |
| 14:14:33 | Bagder | even older than the version we use atm |
| 14:14:45 | Bagder | but it might still work with newer versions |
| 14:16:27 | ashridah | 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 | Bagder | "fix it" |
| 14:17:55 | ashridah | apply patch |
| 14:19:25 | * | sox feels enlighted! |
| 14:21:44 | Bagder | added a note about this on ThingsTodo |
| 14:21:55 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 14:25:57 | Bagder | I'm off for a week now |
| 14:25:59 | Bagder | 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 | ashridah | uh. what's bagder's actual name? :) |
| 14:32:37 | linuxstb | ashridah: http://www.rockbox.org/twiki/bin/view/Main/IrcNicks |
| 14:34:48 | ashridah | heh. i should have known |
| 14:35:02 | ashridah | too late now. i'll probably get told this on the mailing list too |
| 14:35:15 | ashridah | nevertheless, i've summarised the situation there. |
| 14:38:23 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 14:41:16 | ashridah | sox: you still around? |
| 14:41:36 | sox | ashridah: japp |
| 14:42:36 | ashridah | 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 | ashridah | shot even |
| 14:43:40 | ashridah | hm. might be able to drop -D__GNUC__ |
| 14:44:26 | sox | ashridah: tried both, the first one gave me this error: <command line>:6: warning: "__GNUC__" redefined |
| 14:44:26 | sox | <command line>:1: warning: this is the location of the previous definition |
| 14:44:34 | ashridah | yeah, that's okay. |
| 14:44:49 | ashridah | you can drop the -D__GNUC__ bit. |
| 14:44:51 | sox | the other one the usual : make[1]: *** No rule to make target `#pragma' |
| 14:44:56 | ashridah | okay. |
| 14:44:58 | ashridah | no fix there then |
| 14:45:28 | ashridah | i suppose an easier check would be to get you to have run echo "hi" | gcc −−traditional -P -E - |
| 14:45:29 | ashridah | anyway :) |
| 14:45:41 | * | ashridah keeps searching for a fix |
| 14:45:56 | sox | ahridah: thanks for your work.... |
| 14:45:56 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 14:46:00 | AC | hello |
| 14:46:02 | ashridah | the fixes i'm seeing seem to suggest that an older cpp still exists on apple boxes. |
| 14:46:35 | sox | ahridah: i got that impression too |
| 14:46:41 | ashridah | sox: okay, try echo "hi" | gcc -undef -P -E - |
| 14:46:56 | ashridah | (just run it) |
| 14:47:06 | ashridah | see if it still outputs the pragma |
| 14:47:10 | sox | #pragma GCC set_debug_pwd "/Users/svante/rockbox/rockbox/build" |
| 14:47:10 | sox | hi |
| 14:47:19 | sox | unfortunately... |
| 14:47:34 | * | AC checks wav generated from wv2wav |
| 14:47:55 | ashridah | damnit. |
| 14:48:05 | * | ashridah resumes kicking apple |
| 14:48:41 | * | sox joins in kicking |
| 14:49:28 | AC | wav file is 152 kb big, but it seems to be damed :( |
| 14:53:33 | AC | wavpack codec seems hell fast |
| 14:54:53 | amiconn | ashridah, sox: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2003-November/003725.html |
| 14:56:53 | sox | ashridah: do you think that solution might apply to rockbox as well, adding the -x |
| 14:56:53 | sox | assembler-with-cpp to all makefiles and hoping it works on other platforms? |
| 14:56:59 | ashridah | yeah, that's what bagder suggested before, but sox seemed to think it didn't work. |
| 14:57:14 | sox | ashridah: I didnt? |
| 14:57:15 | ashridah | sox: it'd be easy enough to test the platform in tools/configure |
| 14:57:17 | linuxstb | AC: Am I correct in saying that you have a running wv2wav, but you have a problem with the wav output? |
| 14:57:28 | ashridah | sox: i thought you tried it |
| 14:57:35 | ashridah | of course, you might have tried it in the wrong place ;) |
| 14:58:07 | AC | linuxstb: yep... it seems to decode correct, but must look if i get a wav-checking tool, to see whats wrong |
| 14:58:13 | amiconn | another solution: http://lists.gnu.org/archive/html/bug-gnustep/2003-07/msg00269.html |
| 14:58:15 | sox | ashridah: tell me again and i will try it |
| 14:58:21 | ashridah | amiconn: the problem is, that's a command for the preprocessor specifically |
| 14:58:45 | ashridah | 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 | AC | linuxstb: will try a bigger file |
| 14:59:25 | ashridah | sox: hang on. |
| 14:59:34 | sox | ashridah: im here waiting |
| 15:00 |
| 15:00:19 | linuxstb | 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 | ashridah | aha |
| 15:01:17 | AC | linuxstb: will look if portage has sox in it :) |
| 15:02:40 | * | sox wonders why everybodys talking bout me ;-) |
| 15:03:02 | ashridah | hrm |
| 15:03:14 | ashridah | sox: because the problem is something every apple user will face |
| 15:03:18 | ashridah | as they update |
| 15:04:38 | ashridah | hrm. the manpage suggests one can use echo "hi" | gcc -Wp,xassemble-with-cpp -P -E - |
| 15:04:50 | AC | linuxstb: about 120000% with wv2wav.. its very hard to ready, as it is changeing so fast |
| 15:05:00 | AC | will take a foto |
| 15:05:01 | ashridah | but that bitches about xassemble-with-cpp not being found as a file, which is clearly wrong |
| 15:05:14 | dwihno | AC: cool |
| 15:06:13 | AC | foto is quite ugly.. |
| 15:06:14 | amiconn | 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 | ashridah | heh. sounds good enough to me. |
| 15:07:37 | * | AC cant ready how many seconds the decoding is running |
| 15:07:38 | ashridah | got to make sure it deals with directories with spaces in the name tho |
| 15:07:48 | ashridah | which could get a little frustrating. |
| 15:08:19 | ashridah | might just be able to get away with matching the pragma and then trimming the entire line |
| 15:08:38 | ashridah | it seems like a common (and fugly, imho) workaround |
| 15:09:17 | amiconn | Yeah, it doesn't look nice, but the the apple gcc behaviour isn't nice either |
| 15:09:50 | sox | treat them like they treat us ;-) |
| 15:09:55 | amiconn | 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 | ashridah | 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 | ashridah | of course, apple do all sorts of strange things |
| 15:11:48 | ashridah | like not rolling out bugfixes for opengl until the next MAJOR release |
| 15:12:02 | linuxstb | 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 | ashridah | 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 | AC | linuxstb: i am filled in all infos |
| 15:15:00 | AC | linuxstb: x-factor.dyndns.org/rockbox/wv2wav.c |
| 15:16:55 | linuxstb | AC: What about file_info.samplerate ? |
| 15:17:25 | ashridah | 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 | AC | linuxstb: i have seen it yet.. mom will fix it |
| 15:18:31 | ashridah | ... 'mom will fix it'?! |
| 15:18:33 | amiconn | Hmm. I cannot try that. No Mac anywhere near me. I don't even know someone who uses a Mac |
| 15:18:49 | ashridah | amiconn: it should work as a command on all platforms |
| 15:19:01 | ashridah | ie, it should be a generic gcc option |
| 15:19:15 | ashridah | as -xassemble-with-cpp is a generic cpp option. |
| 15:19:15 | amiconn | Yes, but I cannot test if it does the desired thing |
| 15:19:21 | ashridah | that's okay |
| 15:19:29 | ashridah | as long as it actually runs at all |
| 15:19:44 | ashridah | ie, it doesn't toss out a weird error about the command line options |
| 15:19:48 | ashridah | then we can get sox to test it |
| 15:19:53 | ashridah | who, funnily enough, has a mac :) |
| 15:21:57 | * | sox feels almost like someone is making fun of me ... ;-/ |
| 15:22:38 | AC | linuxstb: runns now wirh more then 100%.. speed is growing |
| 15:22:41 | sox | hoy then i demand that we make fun of windows users and their cygwin mess too ;-) |
| 15:22:48 | AC | 109% |
| 15:23:08 | ashridah | sox: that's okay, windows makes fun of itself |
| 15:23:16 | AC | linuxstb: 115% |
| 15:23:26 | ashridah | sox: i'm just picturing the happy-nowhere mac advert parody, that's all |
| 15:23:59 | sox | ashridah: im with you |
| 15:24:05 | AC | 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 | AC | 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 | AC | linuxstb: and about 8,6 MB big |
| 15:27:41 | ashridah | "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 | ashridah | 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 | sox | ashridah: still looking for solutions |
| 15:36:47 | sox | ? |
| 15:38:09 | ashridah | better solutions, yeah. |
| 15:38:34 | ashridah | for the time being, replacing the 'gcc' with 'cpp -xassemble-with-cpp' should do the trick |
| 15:38:49 | ashridah | aghl. |
| 15:39:21 | ashridah | -xassembler-with-cpp even |
| 15:40:02 | sox | that works |
| 15:40:23 | sox | but we still have to modify all makefiles, no? |
| 15:40:33 | ashridah | well, ultimately, yes. |
| 15:40:33 | sox | or can this work for other platforms as well? |
| 15:40:37 | ashridah | but we'll do that in cvs |
| 15:40:46 | ashridah | well, since all platforms use gcc, it should be fine |
| 15:40:59 | sox | well, then its solved? |
| 15:41:11 | * | sox goes to bake a cake |
| 15:41:13 | ashridah | there's workarounds. |
| 15:42:53 | linuxstb | AC: That's excellent news. Can you make a tarball, and I'll add it to CVS. |
| 15:43:24 | ashridah | i can't commit anything to cvs myself tho. |
| 15:44:00 | sox | ashridah: neither can I (who couldve guessed that...) |
| 15:45:42 | sox | linuxstb: how far away is getting sound out of rockbox on iriver? |
| 15:46:09 | AC | 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 | linuxstb | 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 | linuxstb | 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 | AC | linuxstb: ok.. i will ask one of them |
| 15:47:30 | sox | linuxstb: aha, and that work is next on the list, or are other stuff more prioritized? |
| 15:48:49 | linuxstb | 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 | AC | iriver is little endian? |
| 15:49:09 | linuxstb | AC: No, big-endian! |
| 15:49:26 | AC | linuxstb: oh.. that is the probelm with wv2wav |
| 15:49:38 | sox | ashridah: got to go, thanks for your work today, means a lot to me and three or four other mac users.... |
| 15:49:55 | linuxstb | Check my flac2wav code - I think that has an LE_S16 macro defined which you can use to swap bytes. |
| 15:50:09 | AC | 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:00 |
| 16:07:00 | HCl | hi |
| 16:12:04 | amiconn | linuxstb: I wonder why you reinved macros... Rockbox has SWAB16, SWAB32 and SWAW32 to handle endianess |
| 16:12:13 | amiconn | *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 | linuxstb | 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 | amiconn | Well, rockbox had to handle endianess for a long time. The SH1 is big endian too. |
| 16:38:32 | amiconn | 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 | linuxstb | 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 | amiconn | Well, the SH1 has byte and word-swap asm instructions. So SWAB16 and SWAW32 are one instruction, SWAB32 uses 3 |
| 16:40:39 | amiconn | I guess similar instructions exist for the coldfire |
| 16:40:53 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 16:41:30 | preglow | coldfire has swap instruction |
| 16:42:08 | preglow | only swap.w, unfortunately |
| 16:42:20 | | Quit ashridah ("Leaving") |
| 16:42:40 | amiconn | Hmm. So at least SWAW32 can be coded as one instruction |
| 16:43:20 | preglow | asm("swap.w %0" : "=d" (input) : "d" (swapedinput)); should do the job |
| 16:43:36 | preglow | %1, i mean |
| 16:44:05 | amiconn | Not quite. First, %0 is correct for the first parameter |
| 16:44:35 | amiconn | 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 | preglow | yes, i don't know that syntax, so that was i guess ;) |
| 16:45:04 | amiconn | asm("swap.w %0" : : "+d"(data)); |
| 16:45:24 | amiconn | Oops, one colon too much |
| 16:45:42 | preglow | yep, then we agree |
| 16:46:31 | preglow | but how to swap bytes quickly |
| 16:46:31 | preglow | hmm |
| 16:46:45 | | Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 16:49:10 | HCl | mrf |
| 16:49:46 | amiconn | preglow: For SWAB16, there might be no faster solution than shift high byte right, shift low byte left, then or |
| 16:50:18 | amiconn | However, for SWAB32 there is probably a better method than shifting around all 4 bytes |
| 16:50:55 | preglow | swaw is probably the least used of them as well, so bah |
| 16:56:14 | preglow | 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 | HCl | 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 |
| 17:00:13 | | Join XShocK [0] (~cddef002@labb.contactor.se) |
| 17:03:55 | preglow | 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 | HCl | preglow: you tell me |
| 17:10:15 | HCl | :( |
| 17:10:47 | HCl | someone should port a gdb stub :/ |
| 17:13:24 | XShocK | 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 | HCl | nice |
| 17:13:45 | HCl | is it in cvs yet? |
| 17:13:53 | XShocK | no, not in cvs |
| 17:14:12 | XShocK | in original firmware DMA is used |
| 17:14:21 | HCl | *nods* |
| 17:17:03 | XShocK | it can be put in cvs, but should it? because audio framework is not there anyway. |
| 17:17:36 | HCl | nah, but update the link maybe? and put it online? |
| 17:19:17 | XShocK | ok. |
| 17:19:32 | | Join R3nTiL [0] (~zorroz@217.30.249.220) |
| 17:19:39 | HCl | maybe change status to 90% (dma not working yet) |
| 17:19:40 | HCl | 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 | XShocK | sound input does not work yet. |
| 17:20:30 | HCl | ok |
| 17:20:32 | HCl | 50% then |
| 17:21:16 | HCl | plus digital out.. digital in.. line out.. line in.. |
| 17:21:56 | XShocK | 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 | preglow | HCl: have you tried dumping the code you generate and running a disassembler on it? |
| 17:42:53 | HCl | yes. |
| 17:42:55 | HCl | it seems fine. |
| 17:43:15 | preglow | 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:00 |
| 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 | preglow | ask away |
| 18:59:16 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:00:26 | | Join [LoKi] [0] (LoKi@211.Red-81-39-209.pooles.rima-tde.net) |
| 19:00:36 | [LoKi] | Anyone? |
| 19:00:39 | preglow | 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 | Tang | 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:00 |
| 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 | condor9 | I'm having a config.cfg problem with 2.4 stable ... can anyone help? |
| 20:07:16 | amiconn | Any linux user around? |
| 20:07:40 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 20:07:54 | condor9 | hey amiconn ... you were helping me the other day ... got a second? |
| 20:08:00 | amiconn | If yes, please check what 'echo $OSTYPE' on the command line outputs |
| 20:08:25 | amiconn | condor9: just ask... |
| 20:08:30 | condor9 | linux |
| 20:08:37 | amiconn | o.k. |
| 20:08:55 | condor9 | My fonts aren't loaded from the config.cfg If I browse and load them they're fine. |
| 20:09:09 | amiconn | Where are you fonts located? |
| 20:09:16 | condor9 | I tried a simple config.cfg with just the font loading and that didn't work either. |
| 20:09:19 | condor9 | .rockbox/fonts |
| 20:09:45 | amiconn | Did you try saving a .cfg after loading the desired font? |
| 20:10:09 | condor9 | 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 | amiconn | Hmm, strange. Works perfectly here. |
| 20:11:50 | condor9 | Yeah, seems to work for most people. Let me ask, could it be a problem with HD cache ... too large perhaps? |
| 20:11:56 | amiconn | Perhaps the font name is too long? |
| 20:12:09 | condor9 | I renamed the font to "bold.fnt" :) |
| 20:12:35 | amiconn | Hmm, that should definitely work. |
| 20:13:06 | amiconn | Didn't you have other problems with .cfg files as well? |
| 20:13:10 | condor9 | 2.2 is works great but I would like to rombox my recorder, so I need 2.4. |
| 20:13:20 | condor9 | Same problem. I isolated it to font loading. |
| 20:13:48 | condor9 | Other settings are restored ... the font is the only thing that doesn't load. |
| 20:14:18 | amiconn | What line ends does your .cfg file use? |
| 20:14:51 | amiconn | Other method, simply drop me your .cfg and the font in question, I'll try it here |
| 20:14:55 | condor9 | I tried the default ^M and then removed them ... doesn't seem to matter. |
| 20:15:42 | condor9 | I'm in a coffee shop without my recorder, otherwise I'd send you my config. |
| 20:16:01 | condor9 | I also tried moving the font line to different positions in the config ... that didn't work either. |
| 20:17:29 | condor9 | It doesn't matter what font I use ... none of them autoload ... just the default. |
| 20:19:52 | amiconn | 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 | amiconn | ...and (3) is a vaild font of course |
| 20:20:33 | amiconn | Unfortunately I have no idea what fails if it doesn't. |
| 20:20:40 | condor9 | Yeah, I know ... that's why I'm asking here. :) |
| 20:21:27 | amiconn | Hmm. Other settings are preserved across reboots? |
| 20:21:45 | condor9 | Yes. |
| 20:21:48 | amiconn | AH, you said 2.2 works... so I guess they are |
| 20:22:50 | condor9 | 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 | condor9 | Is there some way I can debug the loading of a config file? |
| 20:23:42 | amiconn | Hmm. I'm afarid I can't help without being able to reproduce the problem |
| 20:24:06 | condor9 | Ok. Thanks for your time amiconn. |
| 20:27:00 | amiconn | You may drop me the font & config file when you have access to your box again. |
| 20:27:19 | condor9 | Ok. |
| 20:30:35 | linuxstb | 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 | amiconn | linuxstb: Thanks. So this variable seems to exists almost everywhere... nice :) |
| 20:31:21 | linuxstb | Does cygwin have it? |
| 20:31:29 | amiconn | cygwin - OSTYPE=cygwin |
| 20:31:54 | amiconn | Now I only need to know how to check that env variable in a Makefile... |
| 20:32:14 | linuxstb | Can't you just use OSTYPE in the Makefile? |
| 20:32:23 | amiconn | No, it's empty.... |
| 20:33:45 | amiconn | 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 | linuxstb | Then just use configure to add it to the build Makefile. |
| 20:38:47 | amiconn | Hmm, here's why I'm digging for that. There are 3 related problems with the cygwin build: |
| 20:39:44 | amiconn | - 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 | amiconn | - 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 | amiconn | - But, uname isn't constant on cygwin, it has the form CGYWIN_NT-5.1 |
| 20:41:40 | amiconn | - Makefiles can only check for equal/not equal, so this would need mangling |
| 20:42:05 | amiconn | 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 | linuxstb | I've just tested, and the line "ifeq ($(OSTYPE),linux-gnu)" seems to work in a Makefile |
| 20:45:34 | linuxstb | GNU Make 3.80 |
| 20:47:49 | linuxstb | 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 | linuxstb | 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 | amiconn | Because the problem also occurs when building the x11 sim on cygwin... |
| 20:52:34 | linuxstb | But what if someone is cross-compiling? either to or from windows? |
| 20:54:12 | amiconn | 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 |
| 21:00:07 | HCl | hi.. |
| 21:00:20 | linuxstb | 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 | amiconn | I didn't figure how to access OSTYPe within the script, so I added UNAME instead, as was probably intended anyway |
| 21:01:24 | amiconn | Then I needed to change the check in apps/plugins/Makefile to use findstring |
| 21:02:26 | linuxstb | 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 | amiconn | 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 | amiconn | 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 | sox | 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 | amiconn | Certainly, the UNAME variable could be checked for this too. The question is how to hand the option to the preprocessor... |
| 21:17:14 | sox | amiconn: eg, cpp -xassembler-with-cpp in the Makefiles |
| 21:17:29 | sox | amiconn: instead of gcc |
| 21:19:11 | | Join markun [0] (~markun@bastards.student.utwente.nl) |
| 21:19:51 | markun | Is anyone here running the X11 uisimulator? |
| 21:20:06 | amiconn | sox: Does gcc -Wp,-xassembler-with-cpp also work? |
| 21:21:03 | amiconn | Of course in addition to the other options |
| 21:21:55 | sox | amiconn: hang on, testing |
| 21:22:23 | markun | uisimulator crashes here when trying to scroll a line.. |
| 21:23:24 | linuxstb | markun: Yes, I noticed the other day, but I had forgotten about it. |
| 21:23:57 | amiconn | linuxstb, markun: Linux? |
| 21:24:01 | linuxstb | I can't remember ever seeing it work - I very rarely have any files in my archos directory. |
| 21:24:07 | linuxstb | Yes, Linux. |
| 21:24:23 | markun | I was trying to debug my unicode stuff and thought I broke scrolling, but it also fails for a clean checkout. |
| 21:24:24 | amiconn | Lemme check with cygwin, perhaps it ddoes also crash... |
| 21:24:31 | markun | amiconn: no, FreeBSD. |
| 21:25:02 | sox | amiconn: no: cc1: error: unrecognized option `-xassembler-with-cpp' |
| 21:25:15 | markun | 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 | linuxstb | gdb tells me line 381 - when accessing the pf->width array. |
| 21:27:40 | stripwax | ello |
| 21:27:50 | amiconn | hmm, scrolls like mad here... (recorder sim). Building iriver x11 sim... |
| 21:29:09 | markun | linuxstb: I hope it wasn't anything I changed before comitting Tremor that makes LOW_ACCURACY produce only static.. |
| 21:29:59 | linuxstb | amiconn: The segfault I get is in line 381 of drivers/lcd-recorder.c |
| 21:30:18 | sox | amiconn: so gcc -Wp,-xassembler-with-cpp does not work |
| 21:30:26 | linuxstb | markun: No, I don't think so. I compared your version and the original, and didn't see any significant changes. |
| 21:32:12 | amiconn | iRiver x11 sim also working.. strange |
| 21:33:39 | markun | Yes, very strange.. Maybe it's because you use a different X server. |
| 21:34:31 | amiconn | flac2wav doesn't compile here for the sim... undefined reference to `_iramstart' / undefined reference to `_iramcopy' / undefined reference to `_iramend' |
| 21:34:46 | preglow | yes, linus committed those yesterday |
| 21:35:21 | amiconn | Yes, I know. However, I wonder why this doesn't work here, while the official builds seem to work |
| 21:35:33 | preglow | ahh |
| 21:37:44 | sox | so now Im out in the cold building the sim: "Unsupported system: Darwin, fix configure and retry" |
| 21:41:06 | sox | I guess I could fix it if I knew the right LDOPTS for Darwin |
| 21:42:09 | linuxstb | Does anyone know what the circle with a dot inside means in the top-right corner of the screen? |
| 21:42:38 | linuxstb | (I'm using the iRiver X11 simulator) |
| 21:44:51 | amiconn | Hmm, I don't get this here, but then I can't use 'make install' |
| 21:45:17 | amiconn | make install tries to remake missing files, and it fails because of those symbols I mentioned... |
| 21:45:36 | amiconn | This symbol shouldn't be there, or does the iRiver not have a hd led? |
| 21:46:05 | preglow | it does |
| 21:46:28 | linuxstb | amiconn: are you talking about my symbol? |
| 21:46:34 | amiconn | linuxstb: yes. |
| 21:47:14 | amiconn | 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 | linuxstb | 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 | amiconn | ??? lcd-recorder.c !!! I thought you were building the iriver sim... |
| 21:51:29 | | Quit sox ("This machine just fell asleep") |
| 21:51:37 | linuxstb | I am - I guess that's the place for generic graphical LCDs. |
| 21:52:12 | amiconn | Note quite. For iriver, lcd-h100.c is used instead |
| 21:53:18 | amiconn | lcd-recorder.c is for archos recorders, ondio, and gmini |
| 21:54:13 | linuxstb | Strange. My build/Makefile contains "TARGET=-DIRIVER_H100", but the sim is definitely building and linking drivers/lcd-recorder.c |
| 21:54:47 | amiconn | Yes, it is doing the same here, and that is most likely the problem |
| 21:55:14 | amiconn | There is a maximum number of scrolling lines; I doubled that for iriver some time ago |
| 21:55:39 | amiconn | 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 | hubble | XShocK: yo, are you there? |
| 21:56:48 | hubble | XShocK: i've got Dma sort of working |
| 21:56:54 | linuxstb | Yep, that's the bug. I renamed lcd-h100.c to lcd-recorder.c and the sim now works fine. |
| 21:57:58 | hubble | 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 | hubble | XShocK: so it good news, only bad thing is that the pitch is little wrong (too slow) =) |
| 21:58:40 | linuxstb | 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 | amiconn | 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 |
| 22:00:32 | hubble | XShocK: think it's because my pcm buffer is in SDRAM.. going to move it to SRAM now |
| 22:02:03 | amiconn | 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 | amiconn | I'm not sure how to handle this :( |
| 22:03:01 | preglow | they should have bundled a couple of megabytes of sram |
| 22:03:16 | linuxstb | No, nor am I. I wonder why those config-*.h files don't define the hardware for the simulators. |
| 22:04:25 | amiconn | Imho there shouldn't be that #ifndef SIMULATOR... |
| 22:04:49 | linuxstb | amiconn: I've just deleted it from config-h100.h and I will see what happens... |
| 22:06:04 | linuxstb | I now get an error compiling system.c - it is trying to compile some assembly code. |
| 22:07:14 | amiconn | Hmm, that's bad. |
| 22:07:46 | amiconn | I guess the current problem also results from the simulator build system change |
| 22:08:27 | linuxstb | 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 | amiconn | If any, only CONFIG_CPU should be protected by #ifdef SIMULATOR, imho |
| 22:09:36 | amiconn | #ifndef SIMULATOR of course |
| 22:09:38 | | Quit DrRick () |
| 22:13:36 | amiconn | Hmm. Doesn't work either... |
| 22:14:30 | | Join olivierd [0] (~d444e358@labb.contactor.se) |
| 22:16:32 | olivierd | hi there, trying to compile gcc for coldfire on cygwin |
| 22:17:05 | olivierd | I get an error in the m68040 part, is there a way to only build for the coldfire target? |
| 22:18:16 | preglow | m68040 part? |
| 22:18:33 | preglow | why would m68040 be involved? |
| 22:19:31 | olivierd | I use m68k-elf as a target and it seems to build a lot more than coldfire |
| 22:23:57 | preglow | it probably builds for all 68k, yes |
| 22:23:58 | linuxstb | 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 | preglow | but i've never seen an error |
| 22:24:10 | preglow | what gcc version? |
| 22:24:57 | amiconn | linuxstb: Okay. It's ugly, but it works for now. You could commit this, with a comment stating FIXME or such... |
| 22:26:28 | linuxstb | 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 | XShocK | hubble: i am here finally :) |
| 22:36:34 | | Join olivierd [0] (~chatzilla@212.68.227.88.brutele.be) |
| 22:37:11 | XShocK | hubble: cool! :) |
| 22:37:15 | XShocK | can you send it to me? |
| 22:37:30 | olivierd | preglow: sorry, got caught up in a fight with my IRC client |
| 22:37:45 | preglow | olivierd: didn't have much to add anyway, what gcc version? |
| 22:37:52 | Chamois | Xshock : when WAV will be commit on CVS ? |
| 22:37:53 | preglow | olivierd: are you trying to build, that is |
| 22:38:01 | olivierd | 3.4.3 |
| 22:38:11 | preglow | olivierd: weird, works fine here. binutils? |
| 22:38:29 | olivierd | cvs as instructed in the wiki |
| 22:38:58 | XShocK | chamois: i would guess when kind of sound framework will be done. |
| 22:39:11 | preglow | olivierd: weird, i've never had that not work |
| 22:39:42 | XShocK | 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 | Chamois | sound is more than the 10% we can see on the wiki ? |
| 22:40:44 | Chamois | hubble and you made lot of progress ? no ? |
| 22:40:48 | XShocK | chamois: hubble did DMA now, so i guess it is somewhere near 50. :) |
| 22:41:02 | Chamois | ok ! good ! |
| 22:41:06 | preglow | with recording being the remaining 50%? |
| 22:41:13 | XShocK | yes |
| 22:41:14 | stripwax | heh :-) |
| 22:41:19 | olivierd | 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 | hubble | um.. how big is the SRAM of iriver ? |
| 22:41:25 | preglow | XShocK: like it works perfectly? |
| 22:41:30 | preglow | hubble: 96kbyte |
| 22:41:34 | preglow | hubble: try not to use too much of it |
| 22:41:37 | hubble | hehe |
| 22:41:38 | stripwax | hubble - 64KB can be used by DMA |
| 22:41:38 | hubble | =) |
| 22:41:50 | preglow | hubble: yes, it needs to be in the uppers 64kb |
| 22:41:53 | preglow | upper |
| 22:41:59 | hubble | Strath: um.. what? |
| 22:42:03 | hubble | stripwax: what? |
| 22:42:27 | stripwax | hubble? DMA controller can only use the 64KB SRAM bank not the 32KB bank |
| 22:42:29 | preglow | hubble: only 64kb out of the 96 can be accessed by dma |
| 22:42:38 | XShocK | it sounds perfect even without DMA. with AUDIOTICk it tend to get more CPU, but still it sounds very good |
| 22:43:06 | preglow | XShocK: how about an example rockbox.iriver? :) |
| 22:43:07 | hubble | um.. well.. i just tried to use DMA to transfer from SDRAM and that was no problem |
| 22:43:08 | stripwax | hubble what did you use to measure that it plays slowly without SRAM? |
| 22:43:15 | XShocK | hubble: i think there would be problems, i also read somewhere that SRAM will be problem |
| 22:43:23 | stripwax | hubble you were talking about SRAM not SDRAM, no? |
| 22:43:28 | XShocK | since it is not addressable by DMA |
| 22:43:42 | preglow | sram is addressable by dma |
| 22:43:44 | preglow | just not all of it |
| 22:43:50 | XShocK | preglow: ok. :) |
| 22:44:00 | hubble | hm.. oh, what.. i used a buffer allocated by buffer_alloc |
| 22:44:04 | preglow | you have access to 64kb of it, but don't even think about using that much, heh |
| 22:44:29 | stripwax | Couldn't it all be used for PCM buffer? |
| 22:44:34 | preglow | hell no |
| 22:44:38 | stripwax | Why not |
| 22:44:41 | preglow | we need space for performance critical code and data |
| 22:44:46 | stripwax | the other bank? |
| 22:44:47 | XShocK | hubble: aah, then ok. but still.... i think SRAM is not very needed, |
| 22:44:48 | preglow | lots of space |
| 22:45:11 | Strath | hrm? |
| 22:45:36 | hubble | XShocK: you dont? it didn't run at normal pitch, but maybe that's because of cpu speed? |
| 22:45:42 | Strath | ah... username autocomplete :) |
| 22:45:49 | XShocK | hubble: since it even worked with PIO without SRAM, i don't see why wouldn't it work with DMA |
| 22:46:11 | XShocK | maybe there is another prblem? |
| 22:46:16 | hubble | XShocK: yes, maybe |
| 22:46:36 | preglow | how do you know it doesn't run at normal pitch? what's the reference |
| 22:46:37 | preglow | ? |
| 22:46:58 | stripwax | Is this the output of the sine or actually a WAV output? |
| 22:47:09 | preglow | you do ofcourse set the sample frequency? :) |
| 22:47:18 | hubble | stripwax: so, um.. where's the upper 64kb of sram? 0x10010000 -> 0x100020000 ? |
| 22:47:49 | hubble | 0x10010000 -> 0x10020000 i mean |
| 22:48:18 | stripwax | Well it can be moved by MBAR |
| 22:48:20 | hubble | iriver's dma buffer starts at 10000810 |
| 22:48:24 | hubble | hum |
| 22:48:49 | preglow | /* 64K DMA-capable SRAM at 0x10000000 |
| 22:49:31 | hubble | preglow: oki.. so it's 0x10000000 -> 0x10010000 |
| 22:49:38 | | Quit Chamois ("CGI:IRC (EOF)") |
| 22:49:43 | preglow | hubble: well, it would pretty much have to be |
| 22:49:57 | preglow | that's where the non-dma sram starts, at least |
| 22:50:03 | preglow | it's set up in crt0.s in firmware/ |
| 22:50:39 | stripwax | oh so only the 32KB can be used by DMA? |
| 22:51:02 | stripwax | scratch that, misread |
| 22:56:22 | stripwax | Meant RAMBAR not MBAR, obviously. Both SRAM banks can be moved to any 16KB boundary, independently |
| 22:56:33 | XShocK | 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 | XShocK | Please correct me if i am wrong, since I am learning. :) |
| 22:56:56 | stripwax | by the way, there's theoretically power management benefits from marking either bank as only holding data, or code. |
| 22:57:42 | stripwax | 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 | XShocK | yes, it will, but corssfading between tracks is not possible, |
| 22:58:39 | XShocK | or it is possible, but will make crossfading much harder for processor. |
| 22:58:59 | stripwax | 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 |
| 23:00:18 | stripwax | How were you planning to implement crossfading? |
| 23:01:12 | linuxstb | 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 | stripwax | Really? What for? |
| 23:02:15 | amiconn | Imho the pcm buffer should only hold a few frames worth of samples |
| 23:02:15 | linuxstb | I'm thinking mainly for safety - we don't want the buffer to ever become empty. |
| 23:02:42 | stripwax | Agreed - what would cause it to starve? |
| 23:03:14 | XShocK | 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 | hubble | 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 | hubble | err, 256 not 128 =) |
| 23:04:01 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 23:04:15 | XShocK | 0x80... 128 i think |
| 23:05:06 | | Quit Strath ("Client closed") |
| 23:06:06 | hubble | XShocK: but the buffer seams to be 256 bytes if you look at 10000810 (the next buffer starts at 10000910) |
| 23:06:12 | hubble | wierd |
| 23:08:03 | preglow | hubble: have you got an ida setup for the firmware? |
| 23:08:34 | XShocK | yes |
| 23:08:42 | XShocK | oops.. question not to me.. :) |
| 23:08:53 | hubble | preglow: you want? |
| 23:08:57 | preglow | i don't care who answers, what i want to know is, may i have it? ;) |
| 23:09:01 | stripwax | 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 | hubble | preglow: sure |
| 23:09:27 | preglow | stripwax: depends, it sure would be nice, but a gdb stub just might be easier and better |
| 23:09:42 | preglow | but would require a hardware mod, i guess |
| 23:09:43 | stripwax | hubble does your ida setup handle the CF5249 instructions? |
| 23:10:02 | hubble | stripwax: no, i have to manually fix some things |
| 23:10:05 | XShocK | hubble: where does it set the buffer to be 0x100, since i see only 0x80 even in the handler. |
| 23:10:32 | stripwax | 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 | hubble | XShocK: it doesnt, but the buffer itself seams to be 0x100 |
| 23:10:47 | stripwax | gdb hardware mod should be easy enough however |
| 23:10:56 | XShocK | aahh, ok :) |
| 23:11:00 | stripwax | oops, ^gdb^serial |
| 23:11:52 | hubble | 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 | preglow | 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 | preglow | hubble: why 1.40, btw? |
| 23:21:24 | HCl | 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 | preglow | HCl: yeah, know, just have to find a suitable place on the player for wires to be sticking out :P |
| 23:21:47 | HCl | mmm. |
| 23:21:53 | preglow | HCl: you'd also need a logic level converter |
| 23:21:58 | HCl | well, we could write a gdb stub that works on audio signals :P |
| 23:22:08 | preglow | haha |
| 23:22:13 | preglow | serial over s/pdif |
| 23:22:32 | stripwax | haha |
| 23:22:34 | hubble | 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 | stripwax | XShocK/hubble are you using bdm or not? |
| 23:27:52 | hubble | stripwax: no, just the bootloader |
| 23:28:09 | * | HCl sighs and wishes he knew why rockboy crashed :/ |
| 23:28:56 | XShocK | no |
| 23:28:58 | stripwax | 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 | Renko | has any1 built the bdm from those plans? |
| 23:29:20 | XShocK | all i have is USB cable and the player itself. :)) |
| 23:30:57 | preglow | hubble: what ida version did you say you used? |
| 23:31:40 | hubble | preglow: 4.7 |
| 23:32:19 | stripwax | What's diff over 4.3 or 4.5? |
| 23:33:04 | hubble | 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 | XShocK | mine is also 4.7, and i couldn't open the hubble's base with neither 4.15 or 4.3 |
| 23:37:53 | rasher | >< |
| 23:38:05 | rasher | What is the requirements of the m3us? |
| 23:38:14 | rasher | 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 | stripwax | rasher - no absolute drive letters for one.. |
| 23:45:10 | stripwax | I don't use them however |
| 23:45:35 | stripwax | oh, and the direction of the slash must be correct (tho can't remember if it's forward slash or backslash..) |
| 23:46:09 | preglow | back |
| 23:56:36 | hubble | 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 | rasher | stripwax: Thanks |
| 23:58:42 | preglow | hubble: no idea |
| 23:58:59 | stripwax | hubble, what preglow said |
icon identifies that the person is a core developer (has commit access).