| 00:01:21 | | Join amiconn_ [0] (~jens@pD95D1BED.dip.t-dialin.net) |
| 00:02:06 | | Quit methangas (" Want to be different? HydraIRC -> http://www.hydrairc.com <-") |
| 00:02:34 | | Quit amiconn (Nick collision from services.) |
| 00:02:34 | | Nick amiconn_ is now known as amiconn (~jens@pD95D1BED.dip.t-dialin.net) |
| 00:03:45 | preglow | good rule: pay attention to your clobber list |
| 00:04:04 | amiconn | hehe |
| 00:04:51 | amiconn | Good rule; I know what happens if you don't... |
| 00:04:57 | preglow | yes, so do i |
| 00:05:03 | preglow | like the lockup i jjust described |
| 00:05:14 | preglow | i clobbered a5, my clobber list said a6 |
| 00:06:13 | | Join BoD[] [0] (~BoD@JRAF.org) |
| 00:06:18 | BoD[] | wouhouyouhou ! |
| 00:09:05 | BoD[] | so... |
| 00:09:08 | BoD[] | what's up ? |
| 00:11:43 | HCl | meh, watching jerks on this chat, pondering on leaving it, you? |
| 00:12:11 | preglow | jerk, am i? :P |
| 00:12:21 | HCl | noo |
| 00:12:22 | HCl | XD |
| 00:12:24 | HCl | not *this* chat |
| 00:12:27 | BoD[] | ? |
| 00:12:28 | HCl | this as in, this other chat |
| 00:12:34 | HCl | sorry |
| 00:12:41 | HCl | jerks on this other chat* |
| 00:12:52 | BoD[] | SO ANYWAY |
| 00:12:57 | BoD[] | what about iRiver ? :) |
| 00:13:12 | HCl | i have trouble getting it to not crash on dynarec. |
| 00:13:20 | BoD[] | dynarec? |
| 00:13:20 | dwihno | by which temperature does intel cpus start throttling? |
| 00:13:32 | preglow | varies |
| 00:13:50 | HCl | dynamic recompilation - for gameboy |
| 00:14:16 | BoD[] | ohh |
| 00:14:22 | BoD[] | wow |
| 00:14:32 | BoD[] | this recompiles ? |
| 00:14:50 | HCl | it writes coldfire code on the fly, yea |
| 00:14:55 | BoD[] | I didn't know emulators did that |
| 00:15:03 | BoD[] | coldfire ? :) (sorry) |
| 00:15:07 | HCl | the iriver cpu |
| 00:15:10 | BoD[] | ok |
| 00:15:22 | BoD[] | ok now the big question |
| 00:15:31 | HCl | and yea, its mostly used since.. n64 emulators got around |
| 00:15:37 | BoD[] | what model should I buy |
| 00:15:55 | HCl | h140 ? |
| 00:16:12 | BoD[] | have you seen the pmp models ? |
| 00:16:17 | HCl | yea, i have |
| 00:16:22 | HCl | no experience with them |
| 00:16:37 | HCl | read on a review that it doesn't have much battery run time |
| 00:16:44 | BoD[] | yeah me too |
| 00:16:56 | BoD[] | but I mean they're only a bit more expensive |
| 00:17:00 | BoD[] | but they can play video |
| 00:17:09 | HCl | yup. |
| 00:17:17 | BoD[] | => dilemna |
| 00:17:20 | BoD[] | :) |
| 00:17:23 | HCl | its certainly an interesting thing |
| 00:17:40 | HCl | i'm mostly waiting on something like that, but having a pda integrated |
| 00:17:48 | BoD[] | ah yeah |
| 00:17:54 | HCl | something like the zaurus sl c3000, but with more diskspace and more cpu |
| 00:17:57 | BoD[] | well Archos have a thing |
| 00:18:10 | BoD[] | linux based, IIRC |
| 00:18:29 | amiconn | preglow: Your remark concerning clobber lists reminded me of something... thanks :) |
| 00:18:56 | preglow | amiconn: my pleasure |
| 00:19:16 | BoD[] | HCl: will rockbox work on a H140 |
| 00:19:29 | preglow | BoD[]: it already does |
| 00:19:33 | BoD[] | oh |
| 00:19:35 | BoD[] | sorry |
| 00:19:45 | preglow | no need to apologize |
| 00:20:03 | BoD[] | oh nono |
| 00:20:09 | BoD[] | I mean the H300 |
| 00:20:17 | preglow | probably, yes |
| 00:20:24 | preglow | h1x0 and h3x0 are very alike |
| 00:20:28 | BoD[] | ahhh |
| 00:20:34 | BoD[] | that's a good news |
| 00:20:37 | HCl | but as far as i know |
| 00:20:54 | HCl | the h3x0 has DRM, and no digital in or/and out (it was either one, don't know which) |
| 00:21:03 | preglow | it has no s/pdif, no |
| 00:21:12 | BoD[] | oh :( |
| 00:21:19 | BoD[] | but it has usb host |
| 00:21:24 | HCl | and drm is something you don't really want either |
| 00:21:35 | preglow | HCl: well, it's 100% firmware based |
| 00:21:40 | HCl | preglow: it is? |
| 00:21:42 | preglow | HCl: afaik |
| 00:21:46 | amiconn | Hmm, and H3xx has colour display, not good for battery life... |
| 00:21:47 | HCl | didn't know that |
| 00:21:49 | BoD[] | I think I need usb host |
| 00:21:51 | preglow | HCl: you even loose it if you flash a korean firmware |
| 00:21:56 | preglow | HCl: it seems to have a key in the eeprom |
| 00:22:06 | HCl | preglow: i thought it said you just can't play drm files anymore if you flash with korean |
| 00:22:23 | HCl | but ok |
| 00:22:30 | preglow | HCl: yes, but if you flash back to us, you can't play either |
| 00:22:36 | preglow | you'll never get the key back |
| 00:22:43 | BoD[] | what does the DRM do ? |
| 00:22:53 | preglow | let you play protected music files |
| 00:23:11 | BoD[] | but for "regular" mp3 files ? |
| 00:23:16 | HCl | can't the h1x0 play drm files? |
| 00:24:08 | rasher | I don't think so |
| 00:24:12 | BoD[] | cause ... who has these files anyway ? :) |
| 00:24:40 | amiconn | preglow: If you want to know of what you did remind me, see my commit. It's a minor thing though. |
| 00:24:51 | BoD[] | if I had a drm wma, I'd just reencode it in mp3 |
| 00:26:12 | BoD[] | is there a feature comparison chart like the one for archos, but for iRiver ? |
| 00:26:50 | | Quit jyp ("poof!") |
| 00:29:07 | rasher | BoD[]: the comparison chart includes iRiver |
| 00:29:19 | BoD[] | oops :) |
| 00:29:32 | BoD[] | and do you have the url? |
| 00:29:48 | rasher | hrm |
| 00:29:59 | BoD[] | ok I found it |
| 00:30:00 | BoD[] | sorry |
| 00:30:07 | rasher | alright :) |
| 00:30:09 | preglow | amiconn: i can't see how clobber list made you think of that, but whatever ;) |
| 00:30:31 | amiconn | I don't mean io.c, but the second commit |
| 00:30:37 | amiconn | (in apps/plugins/lib |
| 00:30:39 | amiconn | ) |
| 00:31:19 | preglow | ahh, there are more |
| 00:31:32 | preglow | a bit more related, yes |
| 00:42:06 | | Quit lolo-laptop ("Client exiting") |
| 00:44:34 | BoD[] | the Automatic Volume Control works with iRiver ? |
| 00:45:36 | preglow | nothing much sound related is done yet |
| 00:45:40 | BoD[] | ok |
| 00:45:44 | preglow | just codec work and sound output |
| 00:45:59 | BoD[] | ok |
| 00:46:26 | BoD[] | I guess the chart should be re-done |
| 00:46:55 | BoD[] | with a column "iriver with rockbox" and "iriver without rockbox" |
| 00:48:30 | BoD[] | and also a column for each archos model |
| 00:49:12 | preglow | what, you mean like this? http://www.rockbox.org/twiki/bin/view/Main/FeatureComparison |
| 00:50:05 | preglow | it'll get a thorough update when we're closer to release |
| 00:50:48 | BoD[] | yeah I mean this one, but updated |
| 00:51:01 | BoD[] | hey |
| 00:51:09 | rasher | well right now "Rockbox" just means "on any model" |
| 00:51:11 | BoD[] | is there a database in rockbox now ? |
| 00:52:05 | BoD[] | like browse by artist / track / album / year / any id3 |
| 00:52:28 | BoD[] | cause I guess that's possible on iriver (right?) |
| 00:53:51 | preglow | hrmf |
| 00:54:04 | BoD[] | hmm? :) |
| 00:54:05 | preglow | my short frame imdct create funny noises |
| 00:54:12 | preglow | yes, i think that's possible |
| 00:55:47 | amiconn | BoD[]: There is a database now, also uable on archos models. Allow browse by/ search for artist/ album/ track. No year, genre or other tag yet. |
| 00:56:45 | amiconn | Why the **** xxx2wav gets linked to alpine_cdc.rock in the sim ??? |
| 00:56:50 | preglow | amiconn: did you know 68k assembly, again? |
| 00:57:03 | amiconn | Hmm, not really |
| 00:57:17 | amiconn | I have an Amiga, and looked into it a bit. |
| 00:58:03 | amiconn | I don't know all those special features. I guess SH1 asm won't help you ;) |
| 00:58:08 | preglow | haha |
| 00:58:09 | preglow | not much |
| 00:58:10 | | Quit Sucka ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 00:58:20 | preglow | i've got most of it |
| 00:58:28 | preglow | no, the addressing probably isn't what's wrong anyway |
| 00:58:31 | BoD[] | amiconn : that's great :) |
| 00:59:15 | | Join mecraw [0] (~mecraw@69.2.235.2) |
| 00:59:52 | | Quit Renko ("Leaving") |
| 01:00 |
| 01:00:21 | *** | Saving seen data "./dancer.seen" |
| 01:02:04 | amiconn | preglow: I'm currently investigating the odd behaviour of plugins (esp. the codec plugins) in the cygwin simulator builds. I wonder what a .wav header has to do in all (!) plugins... |
| 01:02:44 | amiconn | Anyone here who does simulator builds on Linux, and could check whether there is a .wav header in them too? |
| 01:03:27 | preglow | i'm yet to build a simulator at all, actually |
| 01:03:32 | preglow | haha |
| 01:03:42 | preglow | i guess that unintended |
| 01:03:46 | preglow | that's |
| 01:04:12 | amiconn | Yeah, I guess so, too. The old builds (last week's cvs) don't have that. |
| 01:04:30 | amiconn | There is a .wav header defined in xxx2wav.c |
| 01:04:32 | preglow | FOOL |
| 01:04:33 | preglow | ARGHHH |
| 01:04:55 | amiconn | It seems this gets omehow linked to all plugins. It shouldn't.... |
| 01:05:02 | preglow | small wonder everything sounds bad, i've forgotten to dereference a pointer |
| 01:05:10 | amiconn | oops |
| 01:05:20 | preglow | and asm blocks aren't very good at complaining |
| 01:06:28 | amiconn | Even helloworld.rock contains a .wav header now.... |
| 01:06:48 | preglow | hahahah |
| 01:07:41 | Patr3ck | hm, shouldn't the timer event registers on iriver... |
| 01:07:46 | Patr3ck | TER0 and TER1 be defined as MBAR+0x151 and MBAR+0x191 instead of MBAR+0x150 and MBAR+0x190? |
| 01:08:18 | Patr3ck | MCF54249UM.pdf page 178 |
| 01:08:49 | Patr3ck | arg MCF5249UM.pdf |
| 01:09:50 | preglow | i never thought i'd think 15 registers would be too little |
| 01:14:00 | preglow | i wish the libmad makefile would pick up changes |
| 01:15:15 | BoD[] | anyway thanks guys! |
| 01:15:18 | BoD[] | i go to sleep :) |
| 01:15:31 | | Quit BoD[] ("mblelop !") |
| 01:17:43 | | Quit cYmen_ (Read error: 113 (No route to host)) |
| 01:19:25 | | Quit Aison (Connection refused) |
| 01:20:20 | | Quit markun () |
| 01:21:34 | amiconn | The memmove() implementation in xxx2wav is wrong.... |
| 01:22:33 | amiconn | It only works correctly if moving backward, i.e. dest addr < source addr |
| 01:23:36 | preglow | nice |
| 01:23:37 | amiconn | The declaration is also wrong. The destination pointer obviously doesn't point to constand data |
| 01:23:45 | amiconn | *constant |
| 01:23:59 | preglow | linuxstb: defend yourself! |
| 01:24:01 | amiconn | memmove() is used by libmad and tremor |
| 01:24:14 | amiconn | err, by libmad and flac |
| 01:24:50 | amiconn | memchr() is unimplemented & does nothing. This is used by flac & tremor |
| 01:25:17 | amiconn | (although for metadata resp. framing only) |
| 01:28:48 | preglow | probably would have noticed it otherwise, yes |
| 01:30:02 | | Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) |
| 01:35:10 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so good") |
| 01:41:40 | Patr3ck | newby question: ICR0 is defined at address 0x04c, I want to change ICR2 at address 0x04e |
| 01:41:45 | Patr3ck | then I would do for example ICR0 = (ICR0 & 0xff00ffff) | 0x008c0000; /* Interrupt on level 3.0 */ |
| 01:41:57 | Patr3ck | is this correct? |
| 01:48:14 | Patr3ck | or would I do ICR0 = (ICR0 & 0xffff00ff) | 0x00008c00; /* Interrupt on level 3.0 */ |
| 01:48:30 | amiconn | Yup |
| 01:49:06 | amiconn | The coldfire is big endian |
| 01:52:59 | Patr3ck | so from left to right the first 0xff is stored at ICR0, second 0xff at ICR1, 00 at ICR2 and last 0xff at ICR3? |
| 01:54:30 | amiconn | correct |
| 01:54:37 | Patr3ck | thanks |
| 02:00 |
| 02:06:22 | linuxstb | amiconn: Good evening :-) Firstly, the xxx2wav.o is part of the plugin lib - so it's linked against every plugin in the same way the grayscale lib is. Does your HelloWorld.rock contain the grayscale lib as well? |
| 02:06:38 | amiconn | No, it doesn't |
| 02:07:29 | amiconn | That's how a library works - an object from it is only selected for linking if the binary the lib is linked to requires a symbol that is defined by the library object |
| 02:08:01 | amiconn | Otherwise almost all plugins would become too big to load on the archos |
| 02:08:29 | linuxstb | I understand that - so why does your helloworld.rock contain xxx2wav.o, but not the rest of libplugin.a ? It doesn't on my setup. |
| 02:08:46 | amiconn | I don't know, but I want to find out. |
| 02:09:14 | amiconn | Possibly this is related to the odd behaviour of the plugins here |
| 02:09:50 | linuxstb | Sounds possible - the linker must be linking it for a reason - presumably I've reused a symbol I shouldn't have done. |
| 02:10:21 | amiconn | Yes, but that would also mean all the plugins contain an unresolved symbol they shouldn't |
| 02:11:14 | amiconn | Unfortunately the plugins on Win32 are dlls and no final binary, so no .map file is generated |
| 02:11:38 | linuxstb | The strange thing is that the X11 sim helloworld.rock doesn't contain xxx2wav when compiled under Linux. |
| 02:12:05 | preglow | i give up |
| 02:13:38 | amiconn | Yes, that's what I wanted to know. The X11 sim plugins on cygwin also don't contain that .wav header, but the Win32 sim plugins do. |
| 02:14:46 | amiconn | They didn't contain that before the new build system (but then there was no xxx2wav either), and they also don't contain it when I don't link against the plugin library |
| 02:15:11 | amiconn | (but the the codec test plugins don't link successfully for obvious reasons) |
| 02:15:16 | amiconn | *then the |
| 02:15:34 | linuxstb | Going back to memchr and memmove. memchr is only used by functions in libFLAC and Tremor that we don't use - which is why there was no need to implement it. I apologise for my memmove (it was late, I wrote it very quickly just to get libFLAC to compile, and it never caused a problem, so I forgot about it). |
| 02:16:33 | amiconn | I didn't do anything about memmove() yet - first wanted to solve the odd simulator problems. |
| 02:17:07 | amiconn | A correct memmove implementation isn't hard though |
| 02:18:13 | linuxstb | I agree - as I said, I just wrote it very quickly without thinking. |
| 02:21:11 | amiconn | Hmm, I just looked at the symbol tables of xxx2wav.o and helloworld.o. I can't imagine which symbol causes the linker to link xxx2wav.o to all win32 plugins |
| 02:21:40 | amiconn | I need to hide each single function and retry until I find the offending one. |
| 02:22:48 | preglow | time for bed, later |
| 02:22:57 | | Quit preglow ("yep") |
| 02:25:11 | amiconn | linuxstb: Your check of CONFIG_HWCODEC at the top of xxx2wav.c cannot work. |
| 02:27:11 | linuxstb | Why not? |
| 02:27:55 | amiconn | Both symbols are defined in config.c and includes of it, which in turn get included by plugin.h You check before that... |
| 02:28:05 | amiconn | s/symbols/macros/ |
| 02:29:02 | amiconn | err, config.h I mean |
| 02:29:11 | linuxstb | OK. But that check is also part of the plugins/lib/SOURCES file - so the check in xxx2wav.c is redundant. |
| 02:29:14 | | Quit Patr3ck () |
| 02:29:31 | amiconn | Yes, it's only a safety measure. |
| 02:38:37 | | Quit mecraw () |
| 02:39:10 | DMJC | will rockbox read pda documents? text only? |
| 02:39:14 | DMJC | I mean pdf |
| 02:39:25 | | Join telliott [0] (~telliott@208-251-255-120.res.evv.cable.sigecom.net) |
| 02:39:46 | amiconn | If someone writes a pdf plugin, then yes |
| 02:40:58 | amiconn | linuxstb: It is definitely one of the system function equivalents in xxx2wav.c that causes this odd behaviour on windows. I 'just' need to find out which one... |
| 02:41:16 | telliott | Hi. Anyone else notice a bug with playlist creation in the latest daily builds? With recursively insert turned on, rockbox only adds the first folder under the current one. |
| 02:41:38 | telliott | I have a V1 recorder. |
| 02:41:55 | amiconn | telliott: Which build did you test? Iirc Linus fixed this recently |
| 02:43:09 | telliott | 5/21 |
| 02:44:27 | amiconn | The fix should be in 2005-02-22 |
| 02:44:34 | | Quit telliott (Read error: 54 (Connection reset by peer)) |
| 02:45:33 | | Join telliott [0] (~telliott@208-251-255-120.res.evv.cable.sigecom.net) |
| 02:46:09 | telliott | Got disconnected. I'm using Monday's build, 2/21 |
| 02:46:29 | amiconn | [02:44:17] <amiconn> The fix should be in 2005-02-22 |
| 02:46:41 | linuxstb | As amiconn said, it was fixed on the 21st so the 22nd daily build should be OK. |
| 02:47:01 | telliott | Thanks. |
| 02:47:35 | telliott | I love the id3 database brower for finding stuff. Now I need to fix all my tags. |
| 02:51:54 | | Quit DMJC ("Leaving") |
| 02:52:50 | | Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) |
| 02:59:32 | | Part telliott |
| 03:00 |
| 03:00:23 | *** | Saving seen data "./dancer.seen" |
| 03:00:34 | amiconn | linuxstb: Now I know which functions in xxx2wav.c fool the win32 linker - malloc() and free() |
| 03:01:22 | amiconn | It seems the linker wants to use these implementations instead of the system native ones for the dll init or similar. Of course this cannot work... |
| 03:01:43 | linuxstb | That explains it then. |
| 03:02:29 | amiconn | So if this shall work on all simulators, we need a workaround. Obviously these functions must be called differently, at least for simulator builds |
| 03:03:19 | amiconn | That implies a (small) change to all codecs. They need to have a header which is included by all source files (I think all codecs have one) |
| 03:03:38 | linuxstb | I think we can live with that. |
| 03:03:39 | amiconn | Then we need a #define similar to the ones in file.h |
| 03:03:51 | amiconn | #ifdef SIMULATOR |
| 03:04:13 | linuxstb | Why #ifdef SIMULATOR? Can't we just rename them for all builds? |
| 03:04:23 | amiconn | #define malloc(blurb) sim_malloc(blurb) |
| 03:04:40 | amiconn | of course we could them rename in general |
| 03:05:09 | amiconn | Something like my_malloc() or codec_malloc() or such |
| 03:06:59 | linuxstb | What do you think about adding a .h file in apps/codecs, and then including that from all the plugin files (via the "all.h" or whatever they use). |
| 03:09:19 | amiconn | Sounds reasonable. However, the question remains where this should be placed. apps/codecs would be first choice, but this header is also needed in xxx2wav.h, i.e. in apps/plugins/lib |
| 03:10:17 | linuxstb | Why is it needed by xxx2wav.h? Don't we just need define codec_mallocd() etc in xxx2wav.[ch] ? |
| 03:11:54 | amiconn | Yes, I mean xxx2wav.c. This is where codec_malloc() and friends are defined. If we declare them in xxx2wav.h (which would be the canonical place), this declaration needs to be duplicated in apps/codecs/<ournewheader>.h |
| 03:13:21 | amiconn | In fact, I wouldn't call these functions codec_*. They are placed in the plugin lib after all, and may also be useful for other plugins. One such plugin is rockboy... |
| 03:13:47 | amiconn | ...which may in fact be the cause why HCl didn't get it to run on the simulator |
| 03:14:11 | amiconn | There is also a private malloc() implementation in it... |
| 03:14:37 | linuxstb | I think rockboy failed in the simulator before I added xxx2wav, but of course that doesn't stop it being a problem. |
| 03:15:08 | amiconn | Yeah - xxx2wav causes problems because it defines malloc(). Rockboy defines malloc() itself... |
| 03:15:28 | linuxstb | But I think codec_malloc is the best name - the implementation is good enough to be used generally. They will only work if the "local_init()" function has been called - which also loads a Wav file. |
| 03:15:38 | linuxstb | ^not good enough |
| 03:16:30 | amiconn | Yes, I saw that. Of course this can be remedied. Split xxx2wav in two - the general malloc() part and the .wav handling part |
| 03:17:19 | linuxstb | I wasn't thinking that xxx2wav and the codec plugins would be permanent parts of rockbox - they are just there so people can test and optimise the codec libraries. |
| 03:17:20 | amiconn | The malloc() function would need some more work though. Somehow it needs to be initialised |
| 03:17:50 | amiconn | Yes of course. Still, the malloc() part may be useful in general - one more reason to split it apart |
| 03:18:13 | linuxstb | I think Bagder has said that he's got a malloc implementation he can use in Rockbox - which I am assuming is better than my 6 lines of C. |
| 03:18:19 | amiconn | Anyway, that doesn't need to be done right now, and we should name these functions codec_* |
| 03:20:48 | amiconn | If you want to give it a shot, feel free to do so. Otherwise I'll try to do that tomorrow. I need to sleep now. At least I know what is going wrong. |
| 03:21:41 | amiconn | Night |
| 03:21:48 | linuxstb | I probably won't have time - I have real work to do whuch is why I'm up at 2.18am. Maybe tomorrow. |
| 03:22:00 | linuxstb | Night. |
| 03:22:10 | amiconn | Already 3:22 am here... |
| 03:22:26 | | Part amiconn |
| 03:31:25 | | Join ashridah [0] (ashridah@220-253-120-15.VIC.netspace.net.au) |
| 04:00 |
| 04:05:23 | | Join QT_ [0] (as@area51.users.madwifi) |
| 04:21:17 | | Quit shx (Nick collision from services.) |
| 04:22:29 | | Quit QT (Read error: 110 (Connection timed out)) |
| 05:00 |
| 05:00:25 | *** | Saving seen data "./dancer.seen" |
| 05:19:07 | | Join ze__ [0] (ze@adsl-69-231-197-65.dsl.irvnca.pacbell.net) |
| 05:27:40 | | Quit linuxstb (Read error: 60 (Operation timed out)) |
| 05:29:27 | | Quit ze (Read error: 104 (Connection reset by peer)) |
| 05:29:27 | | Nick ze__ is now known as ze (ze@adsl-69-231-197-65.dsl.irvnca.pacbell.net) |
| 07:00 |
| 07:00:27 | *** | Saving seen data "./dancer.seen" |
| 07:13:49 | | Join StrathAFK [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 07:17:48 | einhirn | Can anyone tell me how the Battery Chain is connected? Please take a look at this Image and imagine it was a recorder. It is mainly for orientation http://www.gofurygo.de/webpost/archos_fix_1.jpg |
| 07:18:17 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 07:18:31 | einhirn | Hey Linus... |
| 07:20:22 | einhirn | So, in the Upper right Edge of the Picture there is the "GND", Battery Minus to Metal casing and to Archos mainboard (Upper Right Middle Solder Joint)... |
| 07:21:47 | einhirn | In the Upper left edge there is Battery Plus to lower Battery Minus, and Upper Metal Casing to lower Metal Casing. |
| 07:23:50 | einhirn | In the lower right edge there is A contact made with Battery Plus, and from there to Archos Mainboard. Problem here is that somehow the Metal casing (which still is connected to Battery Minus on the other side) is also connected to Battery Plus - Voila my Short Circuit. |
| 07:24:25 | | Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 07:25:23 | einhirn | Now I removed the lower Metal casing and the left side PCB, but still the Minus Pole gets somehow connected up to Plus pole in the lower Right edge... |
| 07:25:47 | einhirn | Can somebody Point me in the Right direction where I've got to search? |
| 07:26:45 | einhirn | I have to admit that I tinned the Lower-Right-Contact and the upper left one, too. I hope that that doesn't cause the Problem... |
| 07:27:10 | * | einhirn sighs - |
| 07:27:10 | einhirn | *sigh* |
| 07:29:03 | * | einhirn makes sad face - "I just want my Recorder back" |
| 07:29:29 | LinusN | poor you |
| 07:29:34 | einhirn | Thanks... |
| 07:30:13 | LinusN | which model? |
| 07:30:40 | einhirn | Recorder - Well, I have to man myself, someone out there had to go through about 6 Month without his device... |
| 07:31:35 | LinusN | i haven't followed your case, could you brief me? |
| 07:31:56 | LinusN | short cut to the casing? |
| 07:32:28 | | Quit Strath (Read error: 110 (Connection timed out)) |
| 07:32:35 | LinusN | which picture are you referring to? |
| 07:32:45 | einhirn | somewhere it seems like that. I entered a Picture link for orientation (before you got online) |
| 07:32:45 | einhirn | - just imagine it to be a recorder... http://www.gofurygo.de/webpost/archos_fix_1.jpg |
| 07:35:05 | LinusN | so when did the short happen? |
| 07:36:05 | einhirn | Err... I thought to be a smart guy. And soldered in the lower batteries using three pieces of wire... |
| 07:36:29 | LinusN | huh? |
| 07:36:33 | einhirn | I connected the wire to the Pads where the Batteries would have been seated... |
| 07:37:05 | einhirn | I did that because my batteries are longer than the original ones and were bending the PCB away... |
| 07:37:15 | LinusN | ok |
| 07:37:51 | LinusN | and you removed the end pcb? |
| 07:37:56 | einhirn | (And I removed the lower left spring to release the tension - so I had to solder the Battery... |
| 07:38:01 | LinusN | ok |
| 07:38:05 | einhirn | Yes, for "Diagnostics"... |
| 07:38:38 | LinusN | as far as i can tell, the pcb needs to be there for grounding purposes |
| 07:38:53 | einhirn | There I saw that the both Metal casings are connected together... |
| 07:39:06 | LinusN | allright |
| 07:39:44 | einhirn | Ok, then there is just the Problem why both, the Plus pole and the Minus Pole of the Battery Chain are connected to it... |
| 07:40:16 | LinusN | to the left pcb? |
| 07:40:57 | einhirn | On the Upper Right edge it seems to be designed to be so (Wire through the Spring, soldered to the metal casing) |
| 07:41:09 | LinusN | the ground, yes |
| 07:41:53 | einhirn | But somehow I get connection from Metal casing to Battery contact on the Lower right side too... |
| 07:42:19 | | Quit ashridah ("out") |
| 07:42:24 | einhirn | I think I shorted some PCB Layers or something... (don't hope so because that would seem to be fatal?) |
| 07:42:38 | LinusN | take a look at this: http://www.rockbox.org/docs/repairbattery.html |
| 07:42:57 | einhirn | Jupp... Did so before... |
| 07:43:21 | einhirn | The connections to the Metal casings were stretched out of solder on all four corners... |
| 07:43:33 | einhirn | So I resoldered them... |
| 07:43:40 | LinusN | are you sure that you haven't accidentally enlarged the solder blob to the left? |
| 07:44:17 | LinusN | next to the digi i/o connector |
| 07:45:48 | einhirn | Have done so while resoldering the metal casing... but by now I removed the Solder because I removed the Metal casing (for diagnostiscs) |
| 07:46:04 | einhirn | Is that where the both layers are shorted? |
| 07:46:13 | LinusN | could be |
| 07:46:18 | einhirn | Hmm... |
| 07:46:32 | LinusN | if the solder blob extended to the vias next to it |
| 07:46:53 | einhirn | There are three contacts on the left side, each one of them was Seperate... |
| 07:46:57 | LinusN | how did you discover the short? |
| 07:47:41 | einhirn | Plugging in Batteries and them getting warm... The Blobs never (to my knowledge) extended to another via or something... |
| 07:48:01 | LinusN | http://www.rockbox.org/internals/rec_rear_top.jpg |
| 07:48:29 | LinusN | see how the early models didn't suffer from this? :-) |
| 07:48:53 | einhirn | they used Solder sparingly but twisted the Metal casing in... |
| 07:48:59 | LinusN | yup |
| 07:49:38 | LinusN | anyway, i think it will get hot if you connect to the via right next to the blob at "94V-0" |
| 07:50:37 | einhirn | That I didn't do... Well, as I said I have to admit that I tinned the Plus pole just left above the 0127 |
| 07:50:40 | LinusN | also, you might have blown a circuit or two |
| 07:50:51 | einhirn | Oh... That would be bad... |
| 07:51:14 | LinusN | but you measure a short with a mutlimeter? |
| 07:51:19 | LinusN | multimeter |
| 07:51:31 | einhirn | Anyway, thanks so far - Will get back online when I am at my workplace... |
| 07:51:37 | dwihno | Good morning everyone! |
| 07:51:40 | LinusN | ok |
| 07:51:43 | LinusN | dwihno: morning |
| 07:51:45 | einhirn | Yup. Multimeter: Plus to Metal casing short |
| 07:52:09 | LinusN | i think you want to replace the 7416 above the lcd |
| 07:53:21 | einhirn | Hmm... I don't see anything tagged like that... |
| 07:53:29 | LinusN | IRF7416 |
| 07:53:35 | LinusN | 8 pins |
| 07:53:58 | einhirn | Two 8Pin SMDs, both tagged 4463 |
| 07:54:05 | LinusN | hmmm |
| 07:54:40 | * | einhirn has to go - can't afford being late... |
| 07:54:45 | LinusN | oki |
| 07:54:52 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 08:00 |
| 08:07:26 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 08:50:51 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 08:51:48 | einhirn | Hello... I'm back... |
| 08:52:44 | einhirn | LinusN: My agenda now is to unsolder the HDD-Connector PCB from the Device and check if the Short is located on it... |
| 08:54:23 | einhirn | If the short is not located on that board, I'll take a look at the 8pin-SMDs, they seem to/should be the Transistors that control Main Power and HDD Power - right? |
| 08:54:47 | LinusN | yes |
| 08:55:04 | einhirn | Perhaps Google will come up with a way to test these - hopefully without needing to unsolder them... |
| 08:58:42 | einhirn | I am afraid of blowing something else if I just plug in my Multimeter (at least it works with 9V - so if it injects that somewhere it doesn't belong to, it'll blow; right?) |
| 08:59:23 | einhirn | Well, I'll come back to you when I have results of the tests... |
| 09:00 |
| 09:00:30 | *** | Saving seen data "./dancer.seen" |
| 09:02:00 | | Join Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au) |
| 09:05:22 | LinusN | einhirn: what kind of multimeter do you have that uses 9V to measure conductance??? |
| 09:17:57 | | Join ashridah [0] (ashridah@220-253-120-34.VIC.netspace.net.au) |
| 09:37:18 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 09:40:26 | | Join jyp [0] (~jp@239.90-201-80.adsl.skynet.be) |
| 09:54:08 | jyp | What's the semantic of struct fat_cache_entry, field secnum ? |
| 10:00 |
| 10:00:23 | LinusN | huh? |
| 10:02:52 | LinusN | it's the sector number of the cached sector |
| 10:09:22 | jyp | As usual I like being sure ;) |
| 10:10:00 | | Join R3nTiL_ [0] (~zorroz@83.69.98.227) |
| 10:18:24 | | Join Patr3ck [0] (~patr3ck@pD9ECFFCE.dip.t-dialin.net) |
| 10:24:43 | Patr3ck | LinusN: I tried yesterday to get the free timer on iriver to work |
| 10:24:52 | LinusN | and? |
| 10:25:02 | Patr3ck | LinusN: I only managed to freeze it ;-) |
| 10:25:03 | Patr3ck | But |
| 10:25:14 | Patr3ck | I cross checked everything and spotted |
| 10:25:22 | Patr3ck | that TER0 and TER1 are defined as |
| 10:25:44 | Patr3ck | MBAR+150 and MBAR+190 |
| 10:26:03 | Patr3ck | shouldn't that be MBAR+151 and MBAR+191? |
| 10:26:34 | LinusN | not if you access them as a word |
| 10:26:40 | Patr3ck | mcf5249um.pdf page 178 |
| 10:27:00 | Patr3ck | ok |
| 10:28:07 | Patr3ck | so that was not the problem... |
| 10:28:17 | LinusN | when i designed the mcf5249.h file, i was misled by the manual that said that the internal registers weren't byte accessible |
| 10:28:36 | LinusN | i'll change that some day |
| 10:29:07 | Patr3ck | no problem, I only thought this could be the problem why my iriver froze. |
| 10:29:11 | ashridah | hrm. odd |
| 10:29:36 | ashridah | rockbox took a few minutes to recalc fsinfo just after i'd been using the iriver stock firmware to record something. |
| 10:30:03 | Patr3ck | anyway, I got some reaction from my programming ;-) |
| 10:30:11 | Patr3ck | I will try again this evening |
| 10:31:44 | LinusN | ashridah: seems like iriver invalidates the fsinfo once in a while |
| 10:32:17 | ashridah | yeah. i think i've noticed it doing that once before. |
| 10:32:29 | ashridah | after plugging the device into a usb port on a pc |
| 10:39:15 | | Quit R3nTiL_ () |
| 10:41:26 | | Quit jyp ("poof!") |
| 10:56:12 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 11:00 |
| 11:00:32 | *** | Saving seen data "./dancer.seen" |
| 11:12:22 | | Join webguest63 [0] (~c31ce021@labb.contactor.se) |
| 11:39:09 | | Join muesli- [0] (muesli_tv@c-180-220-173.cvx-h.dial.de.ignite.net) |
| 11:40:01 | muesli- | high |
| 11:40:06 | LinusN | low |
| 11:40:39 | muesli- | :-) |
| 11:40:44 | muesli- | hi linus |
| 11:41:04 | LinusN | hey ho |
| 11:44:19 | muesli- | how's goin in sweden? rode a reendeer today? |
| 11:49:32 | | Join amiconn [0] (~jens@pD95D1BED.dip.t-dialin.net) |
| 11:50:08 | LinusN | muesli-: of course |
| 12:00 |
| 12:00:04 | muesli- | :D |
| 12:00:55 | muesli- | people got very excited about the news of playing wavs |
| 12:03:25 | ashridah | omgomgomg! |
| 12:03:28 | ashridah | heh |
| 12:04:21 | ashridah | if it's just a standalone bit of code streaming a wav file to the audio output, bfd. if it's a built in thread that's feeding data from a refillable buffer... :) |
| 12:07:27 | ashridah | the hardest part is going to be determining the size of the output buffer that's going to be able to handle the worst-case scenario of codecs, AND codec swapping. |
| 12:16:14 | muesli- | uff, dunno too much about this..2 b honest..nothing... |
| 12:17:34 | ashridah | well. okay. it's not as simple as just writing data to the headphone's output. if you don't have enough buffered data already ready to go, then it's possible that the device won't have enough time to read and decode more from the disk to fill up the buffer before you run out. |
| 12:17:39 | ashridah | if that happens, you get a skip |
| 12:18:10 | muesli- | makes sense |
| 12:18:36 | ashridah | if we want to provide seamless playback between songs, we need the buffer to be big enough to handle the changeover from one codec to another, as well as reading new data from the next file. |
| 12:19:21 | muesli- | yepp |
| 12:19:46 | LinusN | most of the time, we will have several songs already loaded in memory |
| 12:20:22 | LinusN | so the pcm output buffer doesn't have to take disk loading time into account |
| 12:20:31 | | Nick QT_ is now known as QT (as@area51.users.madwifi) |
| 12:20:34 | ashridah | LinusN: that's true. |
| 12:20:40 | muesli- | how many songs can you buffer in one turn? |
| 12:20:44 | ashridah | but you have to make some allowances for potential worstcase scenarios |
| 12:20:50 | ashridah | like having to load a new codec plugin |
| 12:21:08 | LinusN | muesli-: the mp3 buffer is about 30MBytes today |
| 12:21:13 | ashridah | which could co-incide with the near depletion of the buffer, so you need watermarks and other fun stuff ;) |
| 12:21:24 | LinusN | yup |
| 12:22:03 | muesli- | so theoretically there are 32mb / ~5mb for each file possible? |
| 12:22:20 | LinusN | roughly |
| 12:22:44 | LinusN | rockbox tries to fit as much data in the buffer as possible |
| 12:23:23 | muesli- | i wonder why there are only 32mb of buffer..rams arent expensive in these days.. |
| 12:23:56 | LinusN | another 32mb won't affect the battery time that much |
| 12:24:26 | LinusN | maybe for wav playback, but not for mp3 |
| 12:24:48 | LinusN | the archos jukebox has only 2mb :-) |
| 12:24:57 | muesli- | yepp...i wonder if the next hardware mod would be exchanging that 32mb ram module with a bigger one ;) |
| 12:25:06 | LinusN | hehe |
| 12:25:23 | muesli- | theroretically it shouldnt be hard... |
| 12:27:59 | LinusN | not in theory |
| 12:28:52 | muesli- | when the archos box has only 2mb...it has spin the harddrive for buffering every 2minutes!? |
| 12:29:51 | LinusN | roughly, we have only about 1.6Mb left for buffering |
| 12:30:15 | LinusN | so every 1.5 mins |
| 12:30:18 | ashridah | muesli-: the archos would be buffering mp3 data, not pcm data (if i understand the hardware) |
| 12:30:24 | LinusN | yes |
| 12:30:26 | * | ashridah smacks head |
| 12:30:28 | ashridah | minutes. |
| 12:32:01 | muesli- | :) |
| 12:32:26 | * | LinusN goes to lunch |
| 12:32:54 | muesli- | i guess if you would increase the buffer you could increase playing time by factor 1,5 |
| 12:36:13 | muesli- | me too |
| 12:36:17 | muesli- | cya l8er |
| 12:38:11 | | Quit midk ("Leaving") |
| 12:38:19 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 12:39:00 | preglow | LinusN: when i do addressing with a base register and a scaled index register, is the index register signed? |
| 12:40:13 | | Join shx [0] (~a4810127@labb.contactor.se) |
| 12:41:08 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
| 12:55:13 | LinusN | preglow: yes |
| 13:00 |
| 13:00:35 | *** | Saving seen data "./dancer.seen" |
| 13:06:23 | preglow | hrmf |
| 13:06:40 | LinusN | ahehum! |
| 13:07:40 | preglow | i do a array[11 - i] access, which i code like neg %d7, move randomdata, 44(%a0, %d7*4). everything involved is long or long*, and %d7 contains i |
| 13:07:56 | preglow | is that wrong? :V |
| 13:08:31 | LinusN | should work |
| 13:08:49 | preglow | well, shoot |
| 13:09:05 | preglow | i've tried optimizing imdct for short blocks, just to brace myself for the bigger boys |
| 13:09:11 | preglow | but i do something wrong somewhere |
| 13:12:02 | LinusN | can i see the code? |
| 13:13:24 | preglow | sure |
| 13:13:26 | preglow | gimme a sec |
| 13:14:03 | preglow | http://glow.m0f0.net/rockbox/layer3.c |
| 13:14:08 | preglow | grep for III_imdct_s |
| 13:14:20 | | Join Patr3ck_ [0] (~patr3ck@pD9ECF008.dip.t-dialin.net) |
| 13:14:35 | preglow | i'm not done optimizing, but it should work as it is |
| 13:14:38 | * | preglow braces for stupid bugs |
| 13:15:10 | * | HCl yawns |
| 13:15:11 | HCl | hi |
| 13:15:38 | preglow | beware that imdct_s is a two dimensional array, but they should be stored sequantially |
| 13:15:41 | preglow | HCl: elo |
| 13:19:58 | LinusN | preglow: i need emac.h |
| 13:23:00 | preglow | it should be there as well |
| 13:23:14 | preglow | glow.m0f0.net/rockbox/emac.h |
| 13:24:28 | preglow | i probably won't end up using those macros anyway, so i should stop using it ;) |
| 13:26:12 | | Join Renko [0] (~Renko@host217-43-59-250.range217-43.btcentralplus.com) |
| 13:26:56 | preglow | also, the shifting of the result might be wrong |
| 13:27:14 | preglow | but that should just yield a volume change, not a different waveform altogether |
| 13:27:31 | | Join jyp [0] (~jp@239.90-201-80.adsl.skynet.be) |
| 13:29:40 | | Quit Patr3ck (Read error: 110 (Connection timed out)) |
| 13:30:24 | LinusN | i don't see anything wrong... |
| 13:32:35 | preglow | you mean in the output or in the code? |
| 13:32:35 | | Quit webguest63 ("CGI:IRC (EOF)") |
| 13:32:42 | LinusN | in the code |
| 13:32:45 | preglow | nor do i |
| 13:33:20 | preglow | the only thing i can imagine is wrong, is using mac in the first place |
| 13:33:28 | preglow | but that should only yield gain errors |
| 13:34:00 | preglow | MAD_F_MLZ does nothing but shift a 64 bit result four bits up and then return the 32 top bits |
| 13:34:10 | preglow | the emac unit always works on the top bits in fractional mode |
| 13:34:14 | preglow | so i'm stumped |
| 13:35:28 | LinusN | MLO is a load, right? |
| 13:36:27 | LinusN | aha |
| 13:36:29 | preglow | a simple 32x32 bit multiply |
| 13:36:35 | LinusN | saw that |
| 13:36:42 | preglow | it's used to overwrite the accumulator, i do a movclr instead |
| 13:38:07 | ashridah | so what's the EMAC's basic aim? |
| 13:38:33 | preglow | ashridah: it's used to multiply numbers and accumulate them as it goes |
| 13:38:45 | preglow | ashridah: which sounds simple, but it's a fundamental dsp operation |
| 13:38:57 | ashridah | i guess i don't know DSP well enough :) |
| 13:39:14 | preglow | it's also good for 3d calculations |
| 13:39:19 | preglow | ie. dot product |
| 13:39:55 | ashridah | yeah |
| 13:41:41 | | Join muesli- [0] (muesli_tv@c-180-220-232.cvx-h.dial.de.ignite.net) |
| 13:45:16 | CoCoLUS | mornin |
| 13:45:17 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
| 13:47:12 | LinusN | preglow: i'm no emac expert, but is %acc and %acc0 really the same register? |
| 13:47:30 | | Quit jyp (Read error: 110 (Connection timed out)) |
| 13:47:43 | preglow | LinusN: i think so |
| 13:47:53 | preglow | LinusN: am i using both? |
| 13:48:07 | LinusN | you clear %acc before the loop |
| 13:48:24 | preglow | no, i clear acc0 before the loop |
| 13:48:41 | LinusN | movel #0,%acc |
| 13:48:43 | preglow | at least i certainly hope so |
| 13:48:56 | preglow | objdump seems to equate the two, at least |
| 13:49:41 | preglow | but try hard coding it, then, asm("move.l #0, %acc0"); instead of the SET_MAC |
| 13:49:54 | preglow | that is what should be happening already, though |
| 13:54:08 | LinusN | yup |
| 14:00 |
| 14:00:48 | | Join jyp [0] (~jp@239.90-201-80.adsl.skynet.be) |
| 14:06:18 | LinusN | preglow: i don't see anything wrong, and i guess i'll have to run the debugger to spot the error... |
| 14:07:05 | | Quit Renko (Remote closed the connection) |
| 14:07:49 | preglow | hrmf |
| 14:08:18 | LinusN | wait a sec |
| 14:08:27 | preglow | debug facilities would be great |
| 14:09:30 | | Quit lostlogic ("Going to the moon") |
| 14:09:57 | preglow | maybe i should try making some quick emac functions i can run on the computer, just to verify results |
| 14:10:54 | LinusN | i'm a little curious about the first "move.l(%[s]+, %%a5" |
| 14:11:25 | preglow | yes |
| 14:12:14 | preglow | what about it? i'm planning on moving that outside the for i loop and using all mac fetches inside, just haven't gotten around to making asm version of the loop |
| 14:14:07 | preglow | the mac fetches happen in parallel, so the result won't be in %a5 until after the instruction is done |
| 14:14:13 | preglow | that instruction is to provide data for the first mac |
| 14:16:09 | LinusN | was a little unsure about the number of increments of %a3 |
| 14:16:30 | preglow | that's a valid concern |
| 14:16:41 | preglow | but it should be right |
| 14:16:55 | preglow | twelve per loop iter |
| 14:19:01 | HCl | okay |
| 14:19:15 | HCl | i have a problem with movem in my dynarec.. who can help me with that? |
| 14:19:28 | preglow | HCl: depends, elaborate |
| 14:19:57 | HCl | preglow: i have two movem instructions that swap into gameboy context, and one that saves the gameboy context |
| 14:20:06 | HCl | with them, rockboy crashes, without, it works. |
| 14:20:17 | HCl | but ofcourse, without, the results don't get stored so its useless |
| 14:20:28 | preglow | HCl: well, what do they look like? |
| 14:20:39 | HCl | asm volatile (//"movem.l (%0),%%d0-%%d6/%%a0-%%a1\n\t" |
| 14:20:39 | HCl | "jsr (%1)\n\t" |
| 14:20:39 | HCl | //"movem.l %%d0-%%d6/%%a0-%%a1,(%0)\n\t" |
| 14:20:46 | HCl | "a" (cpu.a) |
| 14:20:50 | HCl | maybe my cpu.a is wrong? |
| 14:20:54 | HCl | should it be &cpu.a ? |
| 14:21:31 | preglow | if a is a pointer, then no, () does dereferencing |
| 14:21:40 | HCl | its not a pointer. |
| 14:21:54 | preglow | it's where you want to save the state? |
| 14:22:03 | HCl | yea |
| 14:22:10 | preglow | well, an array is a pointer |
| 14:22:15 | preglow | so it's still right |
| 14:22:45 | HCl | its not an array :x |
| 14:22:51 | HCl | i'll make it &cpu.a |
| 14:22:51 | preglow | struct? :P |
| 14:23:04 | HCl | its an union thing in a struct |
| 14:23:18 | preglow | if so, yes, use & |
| 14:26:57 | HCl | that did something.. |
| 14:28:43 | | Quit ashridah ("sleep") |
| 14:28:47 | preglow | something good? ;) |
| 14:29:42 | HCl | sortof. |
| 14:29:46 | HCl | it didn't crash. |
| 14:29:54 | HCl | and it did change the gameboy's program counter. |
| 14:30:03 | HCl | but not to the correct value. |
| 14:30:30 | preglow | well, is %0 preserved in the call? |
| 14:30:57 | HCl | yea |
| 14:31:19 | preglow | let me see the lists after the asm statements |
| 14:32:37 | HCl | what do you mean? |
| 14:32:41 | preglow | the constraint strings |
| 14:32:52 | preglow | where you declare what variables you use in the asm block |
| 14:32:55 | preglow | ahh |
| 14:32:56 | preglow | there it is |
| 14:33:04 | preglow | you do know that %0 is an actual register, yes? |
| 14:33:21 | preglow | how do you know it isn't clobbered in the place you're jumping to? |
| 14:33:23 | HCl | yes. |
| 14:33:33 | HCl | because i control the code thats written in the place that its jumping to. |
| 14:33:44 | preglow | you don't even know what register %0 is |
| 14:33:50 | preglow | how do you know you're not overwriting it? |
| 14:33:52 | HCl | its a3/a4 |
| 14:33:54 | HCl | i mean |
| 14:33:55 | HCl | a5/a6 |
| 14:33:56 | HCl | :P |
| 14:34:05 | HCl | because this is my register clobber list for the block :P |
| 14:34:10 | HCl | : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "a0","a1", "a2", "a3", "a4" ); |
| 14:34:13 | preglow | hahaha |
| 14:34:18 | preglow | ok |
| 14:34:46 | HCl | brb. |
| 14:38:46 | * | HCl continues to work on it |
| 14:39:35 | | Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) |
| 14:47:54 | LinusN | preglow: i think i see a problem |
| 14:49:23 | preglow | LinusN: please, explain |
| 14:50:59 | LinusN | it seems the compiler doesn't see that %d0 is clobbered |
| 14:51:42 | LinusN | the outer loop is bounded by %d0 |
| 14:51:57 | preglow | how can it not see that? it's right there in the list. i thought it complained if i exhausted the registers |
| 14:52:31 | LinusN | nasty |
| 14:52:47 | preglow | why, indeed |
| 14:56:22 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 14:56:34 | preglow | if i clobber too many registers, the register allocator does complain |
| 14:56:40 | preglow | so i can't even begin to guess why it's doing this |
| 14:57:18 | LinusN | weird indeed |
| 14:57:32 | LinusN | looks like it looses track in the nested loops |
| 14:57:38 | preglow | well ok |
| 14:57:51 | preglow | i'll try merging the inner loop into the asm |
| 14:58:00 | LinusN | or both |
| 14:58:07 | preglow | probably clever |
| 14:58:30 | preglow | the movem is loop invariant, so it needs to go outside the inner loop |
| 14:59:16 | | Join edx__ [0] (edx@p548796C0.dip.t-dialin.net) |
| 14:59:19 | LinusN | now it would be nice with hardware loops... |
| 14:59:42 | jyp | I'd like to compile a codec as a standalone application... (preferably mad or tremor) |
| 14:59:51 | jyp | Advices on how to do that ? |
| 15:00 |
| 15:00:15 | HCl | 0x20390000 |
| 15:00:37 | *** | Saving seen data "./dancer.seen" |
| 15:00:53 | * | HCl scratches his head. |
| 15:01:15 | HCl | well.. at least its working correctly.. aside from doing something utterly odd to make it into 0x20390000 |
| 15:02:43 | LinusN | jyp: i believe there are examples on their respective home pages |
| 15:03:22 | preglow | LinusN: what platforms have hardware loops? |
| 15:03:52 | jyp | LinusN: i mean complie for the target |
| 15:03:53 | | Join lolo-laptop [0] (~lostlogic@68.251.84.226) |
| 15:04:02 | LinusN | preglow: most dsp's i guess |
| 15:05:22 | * | HCl sig.s |
| 15:05:23 | LinusN | jyp: you'll have to link the libmad.a into the apps code directly |
| 15:05:24 | HCl | sighs* |
| 15:05:42 | HCl | can someone tell me whats wrong with this code?: |
| 15:05:49 | HCl | 2278 0150 4e75 |
| 15:05:51 | HCl | :x |
| 15:05:51 | preglow | jyp: my god, you'll have a good time porting libmad |
| 15:06:12 | preglow | it assumes 32 bit ints pretty much the entire way |
| 15:06:48 | CoCoLUS | isn't there an alternative library? |
| 15:06:50 | jyp | Too bad |
| 15:07:08 | LinusN | HCl: you expect us to disassemble for you? |
| 15:07:15 | jyp | ... C specs never said ints were 32bits wide ;) |
| 15:07:31 | preglow | HCl: objdump is your friend |
| 15:07:33 | amiconn | preglow, LinusN: The MAS has hardware loops... |
| 15:07:46 | preglow | amiconn: i thought you guys didn't know how the mas worked |
| 15:07:48 | | Join newnick [0] (~3edba57e@labb.contactor.se) |
| 15:07:54 | HCl | well. |
| 15:07:55 | LinusN | as i said, "most dsp's" |
| 15:07:56 | HCl | the problem is. |
| 15:08:01 | HCl | if i feed it through objdump |
| 15:08:02 | LinusN | preglow: we can program it |
| 15:08:03 | HCl | its supposed to be fine |
| 15:08:09 | HCl | 20: 2278 0150 moveal 150 <main+0x142>,%a1 |
| 15:08:16 | HCl | 26: 4e75 rts |
| 15:08:39 | preglow | well, then the error is probably not here |
| 15:09:02 | HCl | :( |
| 15:09:11 | HCl | preglow: think you can help me a bit? :/ |
| 15:09:13 | LinusN | preglow: we have documentation on the DSP in the MAS, but not on the rest of the chip |
| 15:09:20 | HCl | cause i don't understand whats going wrong.. |
| 15:09:35 | preglow | LinusN: ahh |
| 15:09:51 | preglow | HCl: i'm not much of a 68k expert |
| 15:09:55 | HCl | :/ |
| 15:10:00 | | Quit edx (Read error: 110 (Connection timed out)) |
| 15:10:00 | | Join muesli- [0] (muesli_tv@c-180-220-93.cvx-h.dial.de.ignite.net) |
| 15:10:11 | muesli- | re |
| 15:10:16 | * | HCl sighs. |
| 15:10:22 | LinusN | HCl: what's the problem? |
| 15:10:27 | preglow | and right now i need to finish this optimization i'm working on, i should have been doing other things for a lot of hours now |
| 15:10:40 | HCl | LinusN: i'm writing a code block consisting of 2278 0150 4e75 |
| 15:10:44 | HCl | which according to objdump |
| 15:10:46 | LinusN | preglow: i know the feeling :-) |
| 15:11:00 | HCl | is moveal 0x150, %a1 , rts |
| 15:11:16 | HCl | and i'm calling it using this: |
| 15:11:30 | HCl | "movem.l (%0),%%d0-%%d6/%%a0-%%a1\n\t" |
| 15:11:30 | HCl | "jsr (%1)\n\t" |
| 15:11:30 | HCl | "movem.l %%d0-%%d6/%%a0-%%a1,(%0)\n\t" |
| 15:11:30 | DBUG | Enqueued KICK HCl |
| 15:11:30 | HCl | : |
| 15:11:30 | HCl | : "a" (&cpu.a), |
| 15:11:32 | HCl | "a" (b->block) |
| 15:11:35 | HCl | : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "a0","a1", "a2", "a3", "a4" ); |
| 15:12:13 | HCl | i made it dump all the registers before the movems and after calling the block and the movems... |
| 15:12:23 | HCl | and it seems to work fine, aside from completely messing up the value of %a1 |
| 15:12:42 | HCl | for some reason it turns into 0x20398000 |
| 15:12:49 | HCl | rather than 0x150 |
| 15:12:53 | LinusN | is %a1 supposed to be included in the movem? |
| 15:12:57 | HCl | yes. |
| 15:13:06 | HCl | it needs to be stored in memory |
| 15:13:11 | HCl | and fetched |
| 15:13:15 | HCl | before calling the block |
| 15:13:27 | LinusN | and cpu.a is which register? |
| 15:13:36 | HCl | d0 |
| 15:13:51 | LinusN | can't be |
| 15:14:00 | HCl | hm? |
| 15:14:12 | LinusN | movem.l needs an address register |
| 15:14:15 | HCl | it starts with d0 then it traverses it o.o |
| 15:14:23 | HCl | oh. you mean |
| 15:14:24 | HCl | in the code |
| 15:14:25 | HCl | um. |
| 15:14:26 | *** | Alert Mode level 1 |
| 15:14:26 | HCl | let me look. |
| 15:14:31 | preglow | does anyone know how gcc prefers labels in asm statements to look like? |
| 15:14:37 | HCl | its supposed to be %a5 or %a6 |
| 15:14:44 | LinusN | preglow: .label: |
| 15:14:48 | preglow | LinusN: thanks |
| 15:14:49 | HCl | let me check |
| 15:14:59 | LinusN | preglow: oh, you mean global ones? |
| 15:15:19 | LinusN | then it's just the plain name |
| 15:15:30 | HCl | 880: 4bf9 0000 0000 lea 0 <cpu_reset>,%a5 |
| 15:15:30 | HCl | 886: 2c6f 0078 moveal %sp@(120),%fp |
| 15:15:30 | HCl | 88a: 4cd5 037f moveml %a5@,%d0-%d6/%a0-%a1 |
| 15:15:30 | *** | Alert Mode level 2 |
| 15:15:30 | HCl | 88e: 4e96 jsr %fp@ |
| 15:15:30 | *** | Alert Mode level 3 |
| 15:15:30 | HCl | 890: 48d5 037f moveml %d0-%d6/%a0-%a1,%a5@ |
| 15:15:48 | HCl | whats %fp, by the way? |
| 15:16:00 | amiconn | LinusN: Really? I think if you want to define function foobar() in asm, you need to use _foobar: |
| 15:16:00 | LinusN | frame pointer |
| 15:16:02 | HCl | a6? |
| 15:16:09 | LinusN | amiconn: not for the 68k |
| 15:16:22 | LinusN | (or is it the other way around?) |
| 15:16:39 | amiconn | The underscore is definitely necessary for SH1 |
| 15:16:40 | LinusN | HCl: yes |
| 15:16:43 | HCl | k |
| 15:16:49 | LinusN | amiconn: then it isn't for the 68k |
| 15:17:18 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 15:17:18 | * | HCl sighs |
| 15:17:34 | amiconn | Strange. I thought this C -> asm label translation is independent of cpu architecture. Iirc x86 also needs this. |
| 15:17:40 | * | HCl goes to doublecheck the encoding of movea |
| 15:17:49 | LinusN | amiconn: i was surprised too |
| 15:17:50 | preglow | LinusN: no, i meant a local one |
| 15:17:58 | LinusN | then it is .label: |
| 15:18:01 | preglow | yup |
| 15:18:54 | | Join webguest33 [0] (~3edba57e@labb.contactor.se) |
| 15:19:02 | LinusN | HCl: i don't see anything wrong with that code |
| 15:19:07 | HCl | me neither :( |
| 15:19:26 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
| 15:19:44 | HCl | hrm... |
| 15:20:15 | LinusN | but then i didn't see any problem with preglow's code either :-) |
| 15:20:50 | * | HCl sighs, needs an assembly-level trace/debugger |
| 15:21:19 | * | LinusN caresses his bdm emulator |
| 15:21:23 | | Quit newnick ("CGI:IRC (EOF)") |
| 15:21:34 | HCl | heh, i don't suppose you'd be willing to debug part of rockboy? :X |
| 15:21:35 | | Quit webguest33 (Client Quit) |
| 15:21:46 | HCl | *has no idea how easy it is to debug with a bdm* |
| 15:22:04 | LinusN | it's easy |
| 15:22:11 | LinusN | but my time is extremely limited |
| 15:22:16 | HCl | yea. its ok. |
| 15:22:32 | jyp | Is the code you're talking about somewhere ? |
| 15:22:40 | HCl | let me put it on my ftp |
| 15:22:45 | HCl | binaries are on my ftp either way |
| 15:22:49 | HCl | hold on.. |
| 15:23:17 | jyp | I don't have an iRiver, so the binaries are not so useful :P |
| 15:23:29 | HCl | oh. |
| 15:23:30 | HCl | ok. |
| 15:23:34 | HCl | hold on, let me just get the code |
| 15:23:46 | jyp | take your time ;) |
| 15:23:54 | preglow | LinusN: how would a gdb stub for serial port function in comparison to the bdm? |
| 15:24:15 | LinusN | it would work great |
| 15:24:20 | HCl | ftp://titania.student.utwente.nl/rockboydyna.zip |
| 15:25:16 | jyp | where's the offending code ? |
| 15:25:31 | *** | Alert Mode OFF |
| 15:25:36 | HCl | cpu.c and dynarec.c |
| 15:25:44 | elinenbe | HCl: how is rockboy running? (well, with they dynarec, not with the bugs!) |
| 15:26:12 | HCl | elinenbe: not, cause dynarec is malfunctioning so far, but making a little progress in that calling a dynarec block doesn't crash the iriver anymore |
| 15:26:26 | elinenbe | hey, that's a step! |
| 15:26:35 | HCl | yea, but now its delivering the wrong results |
| 15:26:44 | HCl | for unknown reasons |
| 15:27:01 | elinenbe | what's the deal with #ipodlinux, it seems like there is so little interest in that project... |
| 15:27:24 | preglow | having to look up the instruction reference to see what instructions support what register types all the time is extremely annoying |
| 15:28:52 | jyp | HCl: Is the assembler code conforming to your expectations ? |
| 15:29:02 | LinusN | preglow: yeah, the standard 68k is a little nicer than the coldfire |
| 15:29:25 | HCl | jyp: what do you mean..? |
| 15:29:50 | jyp | Are you ok with the way gcc allocates registers ? |
| 15:29:56 | jyp | (basically) |
| 15:29:56 | HCl | i don't see why not. |
| 15:30:05 | jyp | I just ask ;) |
| 15:30:15 | HCl | if you browse up in the chat a bit, i pasted a dump of the assembly that gcc generates |
| 15:30:52 | jyp | btw, the purpose of the movem is to save the registers right ? |
| 15:31:00 | HCl | yea, and load |
| 15:31:16 | LinusN | a terrible waste to save all regs every time |
| 15:31:22 | HCl | cpu.h has a gameboy register -> m68k reg map |
| 15:31:26 | HCl | yesyesy. |
| 15:31:34 | jyp | I don't understand why you have to save those AND mark them as clobbered |
| 15:31:49 | HCl | because they are.. clobbered..? |
| 15:31:56 | HCl | the first movem doesn't save them, but load them |
| 15:32:00 | HCl | and the second movem writes them |
| 15:32:04 | HCl | not the other way around |
| 15:32:31 | HCl | LinusN: i'm not going for speed yet. |
| 15:32:43 | HCl | trying to get it to work first. |
| 15:32:53 | LinusN | what a unique approach! :-) |
| 15:33:05 | HCl | o.o |
| 15:35:59 | | Quit Marco (Read error: 110 (Connection timed out)) |
| 15:37:32 | * | HCl scratches his head |
| 15:37:39 | | Quit Sando (Read error: 54 (Connection reset by peer)) |
| 15:40:06 | | Nick edx__ is now known as edx (edx@p548796C0.dip.t-dialin.net) |
| 15:42:09 | LinusN | time to go home |
| 15:42:11 | LinusN | cu aroune |
| 15:42:14 | HCl | byebye |
| 15:42:17 | LinusN | cu around |
| 15:42:20 | | Part LinusN |
| 15:45:46 | | Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) |
| 15:51:15 | * | HCl sighs again. |
| 15:51:23 | * | HCl throws stuff at gcc |
| 15:52:35 | * | preglow bitchslaps gcc |
| 15:55:11 | jyp | I can't see how gcc is involved in your problem |
| 15:56:28 | HCl | its compiling my code. |
| 15:56:33 | HCl | and its doing it wrongly. |
| 15:56:49 | jyp | Ha, now we're getting into it ;) |
| 15:56:57 | HCl | and now it even crashes rockboy |
| 15:57:05 | jyp | I asked you just above and you seemed happy :P |
| 15:57:39 | preglow | yes, i'm sitting here with a screenfull of asm code thanks to gcc not doing its stuff properly |
| 15:57:42 | preglow | heh |
| 15:58:26 | CoCoLUS | file a bug report :) |
| 15:59:35 | HCl | jyp: not really. |
| 16:00 |
| 16:03:13 | jyp | preglow: is it because it doesn't understand clobbered registers properly ? |
| 16:04:36 | HCl | here it actually assigned the same register (a4) to two arguments. |
| 16:06:00 | preglow | jyp: don't know |
| 16:06:11 | preglow | and now it actually just generates invalid assembly |
| 16:06:12 | preglow | hurray |
| 16:12:35 | jyp | HCl: it can assign both an input and output to the same argument if the input is not marked as clobbered, iirc |
| 16:12:47 | preglow | -rwxr-xr-x 1 thomj users 838219936 Feb 25 16:12 mpa2wav.rock |
| 16:12:49 | preglow | what the hell |
| 16:13:16 | | Join bg_ [0] (~chatzilla@adsl-68-78-228-166.dsl.mdsnwi.ameritech.net) |
| 16:13:19 | preglow | i think a plugin the size of an iso is a bit much |
| 16:14:07 | jyp | there probably is something in a supposedly empty section |
| 16:14:37 | preglow | the .o file is correctly sized |
| 16:14:39 | preglow | hrmf |
| 16:14:45 | preglow | i wonder how this happened |
| 16:14:57 | preglow | i haven't done anything but modify some asm |
| 16:15:46 | jyp | maybe you put something around address 0x31f638a0 ? |
| 16:17:58 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 16:19:23 | AC | Hi |
| 16:19:34 | * | AC runs the last wv tests |
| 16:20:24 | preglow | could anyone skilled in the ways of Makefiles have a look and determine why libmad's makefile doesn't pick up when changes are made? |
| 16:20:34 | preglow | having to do a make clean each time i change something is very annoying |
| 16:22:44 | * | HCl sighs. |
| 16:23:06 | | Join Chamois [0] (~52e2b617@labb.contactor.se) |
| 16:26:34 | * | HCl blames the movem instruction. |
| 16:33:32 | | Join zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 16:38:37 | preglow | atrghh |
| 16:38:38 | preglow | i can't take this |
| 16:38:41 | preglow | i need to be able to debug |
| 16:45:35 | jyp | amiconn: what'd you say if panic.h looked like this: |
| 16:45:40 | jyp | #include "sprintf.h" |
| 16:45:40 | jyp | void panicf( const char *fmt, ... ) ATTRIBUTE_PRINTF(1, 2); |
| 16:46:27 | jyp | (ignoring header&trailer of course) |
| 16:48:05 | * | HCl sighs. |
| 16:48:09 | * | HCl whacks things. |
| 16:48:09 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 16:48:56 | * | HCl takes the pc calculation out... |
| 16:51:53 | * | HCl sighs and stares. |
| 16:54:06 | * | HCl goes. |
| 16:54:08 | HCl | bbl. |
| 16:54:09 | HCl | u.u |
| 16:54:39 | | Join muesli- [0] (~muesli_tv@c-180-220-219.cvx-h.dial.de.ignite.net) |
| 16:55:15 | | Join mecraw [0] (~mecraw@69.2.235.2) |
| 16:59:37 | | Quit AC ("CGI:IRC (EOF)") |
| 17:00 |
| 17:00:41 | *** | Saving seen data "./dancer.seen" |
| 17:02:44 | | Join ze__ [0] (ze@adsl-69-231-219-215.dsl.irvnca.pacbell.net) |
| 17:03:24 | | Quit ze (Nick collision from services.) |
| 17:03:29 | | Nick ze__ is now known as ze (ze@adsl-69-231-219-215.dsl.irvnca.pacbell.net) |
| 17:10:38 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 17:12:05 | | Quit muesli- (Read error: 60 (Operation timed out)) |
| 17:27:47 | HCl | is 0x150 a valid memory address? |
| 17:29:12 | HCl | on iriver? |
| 17:29:19 | HCl | where's linus when you need him.. |
| 17:32:00 | | Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") |
| 17:33:33 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 17:34:30 | HCl | gotcha. |
| 17:34:41 | HCl | my dynarec is doing (0x150), %a1 |
| 17:34:46 | HCl | instead of 0x150, %a1 |
| 17:37:01 | HCl | now i just need to fix that. |
| 17:45:50 | bg_ | is dynarec just another way of saying HLE |
| 17:45:51 | bg_ | ? |
| 17:48:29 | | Quit Patr3ck_ () |
| 17:50:27 | jyp | state what HLE means ;) |
| 17:50:55 | jyp | It's even more crytic than dynarec :p |
| 17:51:30 | elinenbe | HLE is High level Emulation |
| 17:52:04 | elinenbe | that is instead of emulating the processor... you emulate system calls. |
| 17:55:46 | jyp | No; it's not the same |
| 17:56:08 | jyp | and it cannot be done in this case since there's no hardware support for Z80 in the Coldfire |
| 17:56:31 | jyp | , bg_ |
| 17:59:07 | | Join Renko [0] (~Renko@host217-43-59-250.range217-43.btcentralplus.com) |
| 17:59:27 | bg_ | i see |
| 18:00 |
| 18:02:10 | HCl | bg_: not at all. |
| 18:02:19 | HCl | what they said :P |
| 18:02:24 | * | HCl hadn't read up yet |
| 18:02:41 | | Quit zezayer (Read error: 110 (Connection timed out)) |
| 18:02:44 | HCl | elinenbe: not just system calls, library calls |
| 18:05:41 | * | HCl goes to doublecheck... |
| 18:22:19 | | Join muesli- [0] (muesli_tv@c-180-220-60.cvx-h.dial.de.ignite.net) |
| 18:23:32 | | Join zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 18:24:40 | | Quit muesli- (Client Quit) |
| 18:26:06 | | Join hubble [0] (hubble@h13n1fls302o1033.telia.com) |
| 18:28:53 | jyp | Someone knowledgeable with the fat driver reading? |
| 18:28:54 | hubble | XShocK: ok i've got the DMA working, i think the problem is that i had a old bootloader with the rambar1 bug |
| 18:29:39 | hubble | XShocK: but i don't get why the frequency is messed up |
| 18:29:52 | hubble | XShocK: if I use DMACONFIG = 0x4300 that is |
| 18:30:42 | hubble | XShocK: doh. i was still using the sdram buffer =( |
| 18:31:13 | preglow | why shouldn't you use the sdram buffer? |
| 18:32:44 | hubble | preglow: because the audio FIFO of the coldfire is only 6 samples, so we need to use a special mode of the DMA controller called "Cycle steal" (CS) which basicly means that the dma only transfer 32-bits for each request from the audio interface (I2S) |
| 18:33:38 | preglow | hahaha |
| 18:33:40 | preglow | six samples |
| 18:33:47 | hubble | preglow: so the request must be completed before the FIFO is empty |
| 18:34:12 | hubble | preglow: i guess the problem with sdram is that (at the current CPU frequency) it is too slow |
| 18:34:34 | preglow | well, sdram is probably ok, as long as not too much is used |
| 18:34:39 | preglow | ehh |
| 18:34:39 | preglow | sram |
| 18:35:06 | hubble | preglow: i think we only need 1k or even less than that |
| 18:35:20 | preglow | yes, we'll see anyway |
| 18:37:09 | XShocK | just came... |
| 18:39:17 | XShocK | i used SRAM and needed 0x6300 for it to play nicely. maybe it is because it was stereo. |
| 18:39:52 | XShocK | or... i shouldn't be such |
| 18:40:26 | XShocK | on 4300 it works without any glitches whatsoever, but just twice as slow. |
| 18:40:50 | XShocK | so there is no problem related to the speed of SRAM. |
| 18:41:04 | hubble | ok, that is great |
| 18:41:22 | | Quit cYmen ("leaving") |
| 18:41:23 | hubble | little wierd since the iriver firmware uses 4300 |
| 18:41:26 | preglow | the sram is single cycle access, so small wonder |
| 18:41:30 | XShocK | i yes |
| 18:42:50 | hubble | XShocK: try to set AUDIOCLK in PLLCR |
| 18:43:02 | hubble | XShocK: that way 4300 should work |
| 18:43:35 | XShocK | yes, i remeber deleting the PLLCR config. |
| 18:43:39 | XShocK | will try now |
| 18:45:00 | HCl | rambar1 bug? |
| 18:45:09 | HCl | whats a rambar1 bug? |
| 18:45:24 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 18:45:27 | AC | hi |
| 18:45:28 | hubble | HCl: linus initialized SRAM wrong |
| 18:45:31 | XShocK | hubble, did you "make clean" after changing the crt0.s file? |
| 18:45:39 | HCl | hubble: ah. |
| 18:45:52 | AC | first part of libwavpack is in cvs |
| 18:45:59 | hubble | XShocK: not sure, but i'm pretty sure I saw that it compiled crt0.s |
| 18:46:04 | AC | is is realy slow.. about 3% in the worst case |
| 18:46:24 | preglow | AC: yes, we'll fix that some time ;) |
| 18:46:26 | XShocK | because i didn't do that, and had a hard time understand what was the bug, :) |
| 18:46:59 | XShocK | nop.. PLLCR didn't help |
| 18:47:10 | XShocK | aa yes, helped |
| 18:47:28 | XShocK | ok, then that is the thing... :) |
| 18:47:33 | AC | preglow: :) |
| 18:47:51 | preglow | that is, if i don't commit suicide over failing to optimize libmad some time soon |
| 18:50:28 | HCl | oh. the good news is that my dynarec is working, by the way |
| 18:50:41 | Chamois | about codecs do you have news about the mp3 codec here http://www.freescale.com/webapp/sps/download/mod_download.jsp?colCode=CFMP3DECAUDSW&prodCode=MCF5249&nodeId=02WcbfCjB1Ng9F&location=psp |
| 18:50:42 | preglow | it is? |
| 18:50:44 | preglow | what was wrong? |
| 18:51:12 | HCl | the bad news is, its generating the wrong results |
| 18:51:25 | HCl | preglow: the opcode its compiling is actually movea.l (0x150), %a1 |
| 18:51:26 | HCl | rather than |
| 18:51:32 | HCl | movea.l 0x150,%a1 |
| 18:51:53 | preglow | ahh |
| 18:52:06 | HCl | i modified hello world to give me the value at memory address 0x150 |
| 18:52:07 | preglow | is this in an asm statement? |
| 18:52:14 | HCl | and it was the value the PC was getting set to |
| 18:52:18 | preglow | or code you generate? |
| 18:52:22 | HCl | generate. |
| 18:52:43 | HCl | void DYNA_MOVEA_w_i_to_r(un16 imm, un8 dest) { |
| 18:52:43 | HCl | DWRITEW(0x2078|(dest&0x7)<<9); // unsure if correct |
| 18:52:43 | HCl | DWRITEW(imm); |
| 18:52:43 | HCl | } |
| 18:52:50 | HCl | now, it does have an unsure if correct comment. |
| 18:52:50 | HCl | so. |
| 18:52:53 | HCl | i'll look into that. |
| 18:53:50 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 18:54:09 | preglow | it is incorrect |
| 18:54:18 | HCl | yea, i think i understand what i did wrong |
| 18:54:35 | HCl | the odd thing is, when i put asm("movea.l 0x150 %%a1"); in gcc |
| 18:54:42 | HCl | it seems to generate the same wrong code as me |
| 18:54:47 | HCl | (add a , |
| 18:54:51 | HCl | )) |
| 18:55:05 | preglow | 0x207c |
| 18:55:07 | preglow | i think it should be |
| 18:55:15 | preglow | HCl: you lack a # |
| 18:55:19 | HCl | ah. |
| 18:55:25 | preglow | HCl: all constants that aren't prefixed # are taken as addresses |
| 18:55:31 | HCl | ahh. |
| 18:55:32 | HCl | okay. |
| 18:55:42 | HCl | well, i happen to have an MOVEA_l_i_to_r |
| 18:55:44 | | Quit Chamois ("CGI:IRC") |
| 18:55:47 | HCl | which is indeed 0x207c |
| 18:55:50 | | Quit linuxstb (Client Quit) |
| 18:55:53 | HCl | i'll look into it |
| 18:56:02 | HCl | anyways. |
| 18:56:08 | HCl | as i was saying, the dynarec is working |
| 18:56:12 | HCl | now i just gotta get my encoding right :) |
| 18:56:16 | preglow | ahh |
| 18:56:18 | preglow | gimme a sec here |
| 18:56:26 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 18:56:26 | | Quit linuxstb (Client Quit) |
| 18:56:34 | preglow | well, i think that's just plain wrong, in that case |
| 18:57:02 | preglow | what does w_i and l_i stand for? |
| 18:57:06 | preglow | word int? long int? |
| 18:57:13 | HCl | word/long immediate |
| 18:57:19 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 18:57:31 | HCl | 20: 227c 0000 0150 moveal #336,%a1 |
| 18:57:35 | HCl | thats what gcc generates now. |
| 18:57:40 | HCl | with the # |
| 18:57:42 | HCl | looks much better |
| 18:57:44 | preglow | looks right? |
| 18:57:47 | HCl | yea. |
| 18:57:56 | HCl | so i'll just delete my subroutine and use my _l variant instead |
| 18:58:21 | preglow | for word, it should be 0x307c |
| 18:58:38 | HCl | yea. its a bit confusing. |
| 18:58:52 | preglow | unless it turns out i can't do hex in my head any more |
| 18:58:54 | HCl | i'll get it right :) |
| 18:58:56 | HCl | hehe :P |
| 18:59:16 | HCl | i just gotta get used to the coldfire programmers manual |
| 18:59:59 | AC | linuxstb: wv2wav works for me |
| 19:00 |
| 19:00:20 | linuxstb | Is it in CVS yet? |
| 19:00:34 | AC | added it a minute ago |
| 19:00:44 | *** | Saving seen data "./dancer.seen" |
| 19:01:00 | HCl | c = 1100 ... |
| 19:01:05 | linuxstb | I'll give it a go now. Does it work with hybrid (i.e. lossless) files? |
| 19:01:38 | preglow | HCl: indeed, and the lower mode bit needs to be 1 |
| 19:01:44 | preglow | HCl: and the top register bit needs to be 1 |
| 19:01:49 | HCl | yea, its still downloading the document |
| 19:01:50 | preglow | HCl: the rest 0, which gives you c |
| 19:01:53 | HCl | i'm on this hacked wireless network |
| 19:02:10 | HCl | our city seriously has too many wireless networks |
| 19:02:30 | HCl | ok |
| 19:02:35 | preglow | most cities have, heh |
| 19:02:38 | HCl | this is indeed the opcode for #<data> |
| 19:02:51 | HCl | seems like i need to rewrite my move immediate instructions since i got them wrong |
| 19:03:09 | AC | linuxstb: here is a wv to test: http://x-factor.dyndns.org/rockbox/t1.wv |
| 19:03:36 | linuxstb | Thanks, but I've already made myself some .wv files. |
| 19:03:43 | AC | :) |
| 19:04:12 | linuxstb | But I'll download it anyway.... |
| 19:04:35 | AC | linuxstb: atm rockbox supports wv files in version 4.x |
| 19:05:07 | AC | 3.x support i will add later |
| 19:06:58 | linuxstb | What speed are you getting with your test file(s)? |
| 19:07:03 | elinenbe | HCl: dynarec is working... great! |
| 19:07:47 | AC | linuxstb: it depends on how the file was encoded.. worst 3% best 7% |
| 19:09:42 | linuxstb | AC: my file gave about 3.4% |
| 19:10:04 | linuxstb | How much work is it to support wv 3.x files? What's the difference between 3.x and 4.x? |
| 19:11:44 | AC | linuxstb: it shouldn't be hard to support version 3.x - but i dont know the exact difference |
| 19:12:05 | AC | linuxstb: i think en/decoding has ben improved in version 4.x |
| 19:13:35 | linuxstb | Are you planning on looking at any more codecs? libmusepack is about the only one I can think of that we haven't incorporated yet. |
| 19:13:38 | elinenbe | HCl: where do you live? |
| 19:14:07 | AC | linuxstb: Sure.. it quite fun to get a codec working :) |
| 19:15:03 | linuxstb | Do you know how libwavpack deals with the hybird compression (.wv and .wvc files)? It seems that it would be quite hard to fit that into Rockbox. |
| 19:15:15 | linuxstb | s/hybird/hybrid/ |
| 19:16:03 | AC | linuxstb: at the moment not, but i will check it.. i have also contact to the wavpack developer |
| 19:16:50 | HCl | elinenbe: netherlands |
| 19:20:56 | CoCoLUS | whats .wv? :) |
| 19:21:01 | elinenbe | ah... |
| 19:22:03 | HCl | yay. |
| 19:22:08 | HCl | it works it works it works |
| 19:22:28 | * | HCl just successfully executed his first dynarec block |
| 19:22:38 | * | HCl gets the debug crap out a bit. |
| 19:23:08 | elinenbe | I have a question... all the numbers that are thrown out are so low.... 3%, 7%, 5%, etc. |
| 19:23:21 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 19:23:32 | | Part elinenbe |
| 19:23:44 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 19:24:31 | elinenbe | so, when will they be moving closer to 100% (realtime, or faster)? |
| 19:26:38 | AC | must go now.. see you |
| 19:27:06 | AC | quit |
| 19:27:06 | HCl | don't look at me :X |
| 19:27:07 | | Quit AC ("CGI:IRC") |
| 19:27:44 | elinenbe | I mean... what is holding the speed back −− are you still working with an 11mhz cpu? |
| 19:28:05 | preglow | yes |
| 19:30:51 | rasher | That, and little to no optimisation |
| 19:35:03 | preglow | linuxstb: have you got any idea how to fix the libmad makefile? |
| 19:38:12 | preglow | okok, i've got an array address i want to use in an asm statement, how do i go about doing this? right now i just use "movea.l #label, %a1", but this doesn't work at all |
| 19:38:26 | preglow | #label evaluates to #0, and that's the address of a function |
| 19:45:36 | HCl | yay. |
| 19:45:40 | HCl | recompiling block 0x150 |
| 19:45:43 | HCl | unimplemented opcode :) |
| 19:45:47 | * | HCl goes for food now, dynarec is working |
| 19:46:07 | rasher | Oh boy |
| 19:50:29 | hubble | preglow: try pea #label ? |
| 19:50:44 | linuxstb | preglow: I haven't looked in detail, but I think the problem is that the apps/plugins/Makefile doesn't specify that libmad is a requirement to build mpa2wav. |
| 19:51:07 | | Part hubble |
| 19:51:08 | preglow | hubble: why would i want to push it? |
| 19:51:49 | preglow | i'm going to use it as an array, and the label is the start of the array |
| 19:52:36 | jyp | preglow: why don't you do it in C & look what the compiler outputs ? |
| 19:53:07 | preglow | i was planning to do that, but wanted to avoid having to put in the c code again |
| 19:53:10 | preglow | heh |
| 19:53:13 | preglow | but ok |
| 19:53:32 | jyp | Or look for another array :) |
| 19:53:50 | jyp | ...access, that already exists |
| 19:55:33 | preglow | it just does lea imdct_s, %a1 |
| 19:55:39 | preglow | i tried that, then it fails completely |
| 19:55:46 | jyp | in what way ? |
| 19:55:55 | preglow | player locks up |
| 19:56:35 | jyp | If I were to give my opinion, is has nothing to do with the use of "lea" |
| 19:56:38 | preglow | what the hell? |
| 19:56:56 | preglow | the compiler ends up resolving the address to be 0 as well |
| 19:57:16 | preglow | how can that be? that's most definitely not where the array is |
| 19:57:18 | jyp | I guess you are disassembling the code before relocation |
| 19:57:39 | preglow | ..... |
| 19:57:43 | preglow | that's very true |
| 19:58:26 | preglow | i didn't think of that at all |
| 20:00 |
| 20:16:16 | jyp | Still no fat guru around? |
| 20:16:32 | jyp | fat as in File Allocation Table, of course |
| 20:16:44 | jyp | <@:) |
| 20:16:47 | preglow | i think that would be zagor |
| 20:16:59 | preglow | you could try doing a summoning ritual |
| 20:17:07 | jyp | heh ;) |
| 20:21:32 | * | HCl scratches his head as his dynarec isn't too efficient yet |
| 20:23:06 | preglow | did you try moving the interpreter core to sram, btw? |
| 20:27:08 | HCl | no. |
| 20:27:12 | HCl | i wouldn't know how. |
| 20:28:26 | HCl | the biggest trouble i'm having is gameboy memory accesses, really. |
| 20:28:45 | preglow | in what way? |
| 20:31:09 | elinenbe | HCl: is the dynarec more efficient than the static emulation? |
| 20:31:26 | HCl | well, memory read/writes in gameboy go through rather complex functions |
| 20:31:48 | HCl | and before each call to them, i have to store all the gameboy registers, and fetch them again afterwards |
| 20:32:30 | preglow | you mean like indexing and shit? |
| 20:32:33 | HCl | elinenbe: it should be faster when talking about calculation, but i'm worried about memory accesses |
| 20:32:38 | HCl | yea. |
| 20:32:44 | HCl | i even spotted some recursion |
| 20:32:45 | preglow | how complexing indexing does it do? |
| 20:32:48 | HCl | which is just really icky |
| 20:32:50 | preglow | the coldfire does some of that as well |
| 20:33:15 | preglow | you got any docs on the cpu? |
| 20:33:21 | preglow | that i can sneak a peek at |
| 20:33:32 | HCl | z80? |
| 20:33:42 | HCl | why...? |
| 20:33:53 | HCl | the code for memory accesses is more relevant, really |
| 20:34:12 | preglow | i want to have a look at what addressing modes it has |
| 20:34:26 | HCl | kay.. hold on. |
| 20:34:47 | HCl | http://www.work.de/nocash/pandocs.htm#gameboytechnicaldata |
| 20:38:04 | preglow | pretty small instruction set |
| 20:38:42 | preglow | but what complex functions are you talking about? |
| 20:41:04 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 20:58:21 | | Join midk [0] (~midk@c-67-161-124-8.client.comcast.net) |
| 21:00 |
| 21:00:47 | *** | Saving seen data "./dancer.seen" |
| 21:11:36 | | Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a239.wi.tds.net) |
| 21:26:33 | | Quit Renko (Remote closed the connection) |
| 21:29:46 | | Quit edx () |
| 21:30:33 | | Quit zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") |
| 21:32:58 | | Join edx [0] (edx@p548796C0.dip.t-dialin.net) |
| 21:47:45 | XShocK | if i have a i2c bus, and i want to connect one additional device to it, what are my actions? if i understand right i only need to change the resistor on the bus line. |
| 21:49:07 | pill | tmobile got owned again.. |
| 21:49:07 | pill | http://66.40.38.42/freddurst/ |
| 22:00 |
| 22:00:07 | gromit``` | arf |
| 22:27:13 | | Quit lolo-laptop (Remote closed the connection) |
| 22:27:40 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34EF5.dip.t-dialin.net) |
| 22:28:25 | | Join lolo-laptop [0] (~lostlogic@68.251.84.226) |
| 22:28:52 | [IDC]Dragon | jyp: what do you want to know about the FAT? |
| 22:30:40 | jyp | My question was if a short int was enough for #entries in a directory |
| 22:30:54 | jyp | Also, side questions are... |
| 22:31:17 | jyp | can I trust fsck for fat, and; |
| 22:31:21 | * | [IDC]Dragon digs for the spec |
| 22:31:52 | jyp | what tool should I use to check the fat structure |
| 22:32:20 | [IDC]Dragon | chckdsk? |
| 22:33:02 | jyp | fsck 1.35 (28-Feb-2004) |
| 22:33:03 | jyp | dosfsck 2.10, 22 Sep 2003, FAT32, LFN |
| 22:34:18 | [IDC]Dragon | http://md.hudora.de/presentations/forensics/2004-10-26/fatgen103.doc.pdf |
| 22:34:38 | [IDC]Dragon | do you know that paper? |
| 22:34:44 | jyp | nope |
| 22:34:52 | [IDC]Dragon | it's the FAT bible |
| 22:37:19 | [IDC]Dragon | the # of dir entries are 16 bit for the root |
| 22:38:12 | [IDC]Dragon | sorry, that was FAT16 |
| 22:40:35 | [IDC]Dragon | better use 32 bit |
| 22:40:58 | [IDC]Dragon | for which variable? |
| 22:41:28 | jyp | fat_dir.entry* |
| 22:41:46 | jyp | fat_file.dir_entries* |
| 22:44:08 | [IDC]Dragon | the case might be a bit esotheric, but I vote for 32 bit |
| 22:44:21 | [IDC]Dragon | why so pinchy? |
| 22:45:41 | jyp | Actually I don't think it is the problem I'm facing |
| 22:45:52 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 22:47:12 | jyp | here a couple debug messages I get ... |
| 22:47:25 | jyp | drivers/fat.c:1957 next_write_cluster(0,0) |
| 22:47:29 | jyp | drivers/fat.c:773 find_free_cluster(4D380) == 4D380 |
| 22:47:34 | jyp | drivers/fat.c:837 update_fat_entry(4D380,FFFFFF8) |
| 22:48:01 | | Quit skav (Read error: 110 (Connection timed out)) |
| 22:48:20 | jyp | it this normal ? |
| 22:48:34 | jyp | ark |
| 22:48:50 | jyp | not what I wanted to paste |
| 22:50:09 | * | HCl can't stand his parents.. |
| 22:50:10 | HCl | hi. |
| 22:50:20 | HCl | preglow: memory. |
| 22:50:56 | HCl | preglow: memory mapped io puts a lot of overhead on memory accesses and complicate memory read/write functions in an emulator. |
| 22:51:12 | jyp | Anyways... I guess FFFFFF8 a fake entry for free space |
| 22:51:56 | [IDC]Dragon | it's a special marker, end of chain or so |
| 22:52:16 | [IDC]Dragon | EOF, yes |
| 22:52:56 | [IDC]Dragon | next_write_cluster(0,0) looks no good |
| 22:53:13 | preglow | hehe |
| 22:53:20 | * | preglow loves his parents |
| 22:53:51 | HCl | my dad is fine, its mostly my mom. |
| 22:53:55 | preglow | don't see enough of them these days |
| 22:54:04 | HCl | she always stresses the living crap out of me. |
| 22:54:12 | HCl | while i can't stand stress and its really unhealthy for me. |
| 22:54:24 | preglow | stress is bad, yes |
| 22:55:06 | CoCoLUS | just tell her "keep quiet, i got to work on the dynarec", and when she asks wtf that is, tell her, it's the only thing keeping your house from exploding :) |
| 22:55:15 | HCl | she doesn't listen. |
| 22:55:17 | HCl | to anything. |
| 22:55:26 | HCl | even when she's making me really stressed and pissed off |
| 22:55:30 | HCl | she just continues |
| 22:55:32 | HCl | making it even worse |
| 22:55:39 | HCl | at the end it got so bad that i had to resist hitting her |
| 22:55:44 | HCl | then i just grabbed my stuff and left. |
| 22:56:01 | HCl | first time i got my car up to 6000 rpm. |
| 22:56:12 | preglow | hahaha |
| 22:56:21 | HCl | the gear / gas thing in need for speed really works. |
| 22:56:43 | CoCoLUS | not with a cold engine i hope? :) |
| 22:56:43 | HCl | ofcourse there were boring people that followed the speedlimit so i couldn't race all the way. |
| 22:56:45 | preglow | my father's good at stressing me up as well, but i've learnt how to handle him |
| 22:57:00 | preglow | brb |
| 22:57:32 | rasher | HCl: which gear/gas thing in need for speed? |
| 22:57:56 | HCl | rasher: accelerating from 3000 rpm - about right in front of the red, then changing gears for acceleration. |
| 22:58:07 | rasher | ah |
| 22:58:13 | rasher | yes, yes that is indeed correct |
| 22:58:53 | HCl | second gear can still go pretty fast |
| 22:59:08 | rasher | (unrelated to anything, but awesome http://people.zeelandnet.nl/marco/pimpzilla/ ) |
| 23:00 |
| 23:00:50 | *** | Saving seen data "./dancer.seen" |
| 23:16:18 | jyp | [IDC]Dragon: any chance there's a tool to browse the FAT structures ? |
| 23:21:11 | | Join zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com) |
| 23:25:18 | | Quit courtc (Read error: 60 (Operation timed out)) |
| 23:26:21 | preglow | rasher: damn, my firefox looks good now |
| 23:27:40 | HCl | lol. |
| 23:27:49 | preglow | fur and gold |
| 23:28:51 | preglow | but i still can't get my damned simple imdct_s optimisation to work ://// |
| 23:31:17 | | Quit zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]") |
| 23:32:01 | preglow | jyp: do you know if objcopy translates _all_ references, or do i need to do something fancy? |
| 23:32:13 | jyp | references ? |
| 23:32:30 | | Quit lolo-laptop ("Client exiting") |
| 23:32:33 | jyp | to labels ? |
| 23:32:39 | jyp | symbols |
| 23:32:41 | preglow | well, it obviously generates position independent code |
| 23:32:42 | preglow | yes |
| 23:33:04 | jyp | I don't really know |
| 23:33:58 | jyp | but *local* labels have no relocation entry, so you won't see the symbol |
| 23:34:02 | | Join courtc [0] (~court@adsl-158-7-189.asm.bellsouth.net) |
| 23:34:07 | jyp | yet I'm not sure this is your question |
| 23:34:08 | preglow | i'm starting to suspect my label reference isn't getting relocated |
| 23:34:36 | preglow | well, the label i reference is static... |
| 23:35:03 | preglow | bah, i'll just let it be and ask linus when i see him again |
| 23:35:06 | jyp | static is still relocated |
| 23:35:40 | jyp | it's only when the label is accessed by a relative jump for example |
| 23:36:03 | jyp | You can disassemble the code after relocation to be certain |
| 23:36:54 | preglow | how do i do that? i would have to objdump the .rock file? |
| 23:37:30 | jyp | I think so |
| 23:37:44 | preglow | hmmm |
| 23:37:48 | jyp | I don't have looked into plugins yes |
| 23:37:49 | preglow | -r prints reloc entries |
| 23:37:49 | jyp | yet |
| 23:38:07 | preglow | my lea does have a reloc entry |
| 23:38:11 | jyp | If .rock is the ld output then yes |
| 23:38:30 | preglow | objdump doesn't understand .rock |
| 23:38:42 | preglow | which comes as no surprise |
| 23:39:25 | jyp | lemme have a look at the makefile |
| 23:40:11 | preglow | wooops |
| 23:40:17 | preglow | spotted one error right there |
| 23:40:31 | jyp | mm call to ld is wrapped in a script |
| 23:41:23 | preglow | let's hope this helps |
| 23:42:05 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 23:46:26 | preglow | argh |
| 23:50:03 | preglow | hah! |
| 23:50:05 | preglow | i got it! |
| 23:50:55 | preglow | the error was, as usual, in the constraint list |
| 23:51:43 | preglow | think i found a bug as well, if you list only input and output constraints, gcc doesn't think the asm block is used |
icon identifies that the person is a core developer (has commit access).