00:00:23 | jyp | It thought this was temporary so I didn't care too much |
00:00:37 | jyp | same as for the entire built process |
00:01:16 | Bagder | so why the make.inc changes? |
00:01:20 | jyp | I put my changes in the diff so you can see what I've done... But I'm perfectly aware it must be changed to accomodate |
00:02:16 | jyp | Well, that not strictly necessary (and I'm not sure at all it is the best method to achieve my goal) ... |
00:02:38 | jyp | but since I work with an experimental compiler I often need to check the intermedate ouptuts |
00:02:41 | jyp | (.i & .s) |
00:02:56 | jyp | so I spliced in ad-hoc stuff |
00:03:24 | Bagder | fair enough, but that shouldn't be committed... |
00:03:31 | jyp | sure |
00:04:37 | jyp | Though if you have a clean method to generate intermediate targets that would be cool to provide it |
00:05:02 | Bagder | we don't |
00:05:05 | amiconn | Regarding the sizeof(int) problems: What about simply changing the places where 4 byte integers are necessary to use long instead? This wouldn't hurt the other platforms |
00:05:09 | Bagder | but I agree it would be good |
00:05:25 | Bagder | amiconn: I think we should do that, yes |
00:06:24 | amiconn | int should then be used in places where 2 bytes might be enough, but 4 bytes won't hurt either. The compiler can then decide depending on the platform |
00:06:55 | jyp | Sure |
00:07:12 | amiconn | In this case it is often better than explicitly use short, because the code sometimes gets considerably larger. |
00:07:28 | Bagder | yes, we should avoid using short when int is fine |
00:08:03 | jyp | I specified only u32 or s32, and only where that was necessary |
00:08:25 | jyp | but still it can be replaced with long |
00:08:29 | Bagder | I vote for using long and unsigned long |
00:08:37 | amiconn | So it should be easy to replace this with unsigned long resp. long, and all would be fine. |
00:08:57 | amiconn | :) |
00:09:33 | Bagder | jyp: other minor nits: we use /* C comments */ |
00:09:43 | jyp | Oh yes... |
00:10:12 | jyp | When I realized that was too lazy to change before submitting the patch :P |
00:10:19 | Bagder | haha ;-) |
00:11:16 | jyp | Also, do you insist on C style, as opposed to C99 ? |
00:11:19 | amiconn | Bagder: I never really got why this is a requirement, but since this is rockbox style, I stick to it. In fact, this is sometimes useful, in that I put my debugging comments in // C++ style. This way they are easy to spot. |
00:11:37 | Bagder | jyp: yes |
00:11:55 | Bagder | amiconn: it started as a requirement to make it possible to build with older plain C compilers |
00:12:05 | | Join lImbus [0] (lImbus@200-167.244.81.adsl.skynet.be) |
00:12:10 | Bagder | but now it is mostly for consistent style |
00:12:10 | lImbus | good evening |
00:12:17 | amiconn | hi lImbus |
00:12:21 | jyp | go for K&R style :P ;) |
00:12:33 | Bagder | let's not overdo it ;-) |
00:15:46 | amiconn | (short or char vs. int) I tried this while developing the grayscale lib, in order to slim down the control structure a bit. The code grew by more than 500 bytes, which was roughly 10% of the whole library... |
00:16:41 | amiconn | ...of course I reverted it. |
00:16:47 | Bagder | :-) |
00:18:35 | Bagder | jyp: does hwgmini.h really fit in the export/ dir? |
00:19:05 | jyp | don't know |
00:19:19 | | Quit pfavr ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20050105]") |
00:19:23 | jyp | maybe it should not exist at and be merged with other files |
00:19:35 | jyp | That's something I wanted to ask... |
00:19:46 | jyp | And there's debug stuff in there too |
00:19:50 | Bagder | I removed the include of it from the cpu.h header file now |
00:20:01 | Bagder | didn't seem to fit the pattern from the other cpu includes |
00:21:51 | Bagder | jyp: what's the emu_ functions for in kernel.c ? |
00:22:02 | jyp | hmmm; that's debug stuff |
00:22:18 | Bagder | want me to ignore that or move it into the tcc370 section? |
00:22:21 | jyp | again I put those anywhere... |
00:22:31 | Bagder | ok, so I remove that for now |
00:22:32 | jyp | They are spotted by the emulator |
00:23:06 | jyp | which outputs the message |
00:24:05 | amiconn | jyp: Did you update the calmrisc gcc? |
00:24:14 | jyp | yes |
00:24:25 | jyp | not perfect but better than the original |
00:24:47 | jyp | I currently use it to compile my stuff |
00:24:48 | | Quit midk (Remote closed the connection) |
00:27:17 | Bagder | I spotted a mistake in ata.c |
00:27:31 | Bagder | you spelled the cpu TC730 in the initial #if |
00:27:45 | jyp | mmm, that shouldn't have made it to the patch |
00:28:09 | jyp | purely work in progress ;) |
00:28:17 | jyp | thanks for the info though :P |
00:28:50 | Bagder | I'm thrilled by your fast development |
00:29:20 | jyp | heh ;) |
00:29:44 | jyp | We spent a lot of time preparing for a sudden jump ;=) |
00:29:47 | amiconn | Bagder: I have a small question concerning mp3_playback.c... |
00:29:53 | | Join Ka [0] (~tkirk@pcp0010732484pcs.howard01.md.comcast.net) |
00:30:06 | Bagder | amiconn: try me! |
00:30:18 | jyp | Joking aside, having a "full fledged" emulator makes things easier |
00:31:22 | gromit` | i'm thrilled by jyp :) |
00:31:39 | amiconn | ...concerning mp3_init(). Is there a reason why for MAS3507, mpeg_sound_channel_config() is called before all other settings (line 1019), while for the other MAS' it is called much later (line 1036)? |
00:32:30 | *** | Saving seen data "./dancer.seen" |
00:32:44 | Bagder | oh |
00:32:53 | Bagder | I have absolutely no idea! ;-( |
00:33:39 | Bagder | that's Linus and Jörg's area |
00:34:33 | Bagder | jyp: in thread.c:create_thread() |
00:34:43 | Bagder | shouldn't there be a store_context() for tcc730? |
00:34:50 | jyp | no |
00:35:05 | jyp | I have a slightly different approach |
00:35:10 | amiconn | I need to mess with that in order to get the variable stereo width in. In fact, I even see no reason why this is a separate function, while all other settings are handled by mpeg_sound_set() |
00:36:50 | amiconn | Ah no, I just found that this is used both ways... |
00:37:12 | Bagder | jyp: any particular reason? |
00:38:37 | Bagder | jyp: you've added emu_debug() calls in the middle of generic code |
00:38:39 | jyp | The problem faced was that I needed an address register to store the context |
00:39:07 | Bagder | perhaps you should use DEBUGF() for your emulator stuff |
00:39:33 | Bagder | since DEBUGF is already used in the cod for debug output |
00:39:35 | Bagder | code |
00:39:36 | jyp | that was difficult so I changed it to store on the stack, which in turn led to the other changes |
00:39:44 | jyp | Ok |
00:39:55 | jyp | I'll use DEBUGF then |
00:40:18 | jyp | Sorry, newbie here :@ |
00:40:26 | Bagder | no worries |
00:40:54 | Bagder | please don't take this as complaints, there are just remarks on how to get your code mixed with the existing in a better way |
00:41:14 | jyp | Heh, alright ;) |
00:50:37 | | Quit Ka (Read error: 60 (Operation timed out)) |
00:50:51 | Bagder | I don't like the 'DISKLESS' and 'NOPOWERMGT' defines in config-gmini120.h |
00:51:04 | jyp | Of course |
00:51:19 | jyp | that was just to make the stuff compile |
00:51:37 | Bagder | compiling is good! ;-) |
00:51:57 | jyp | ... a requirement to run ;) |
00:59:40 | Bagder | I gotta go to sleep now |
00:59:47 | jyp | me too |
00:59:49 | Bagder | I committed a bunch of files |
00:59:58 | jyp | alright, thanks |
01:00 |
01:00:02 | Bagder | some of them slightly edited by me |
01:00:31 | Bagder | good night |
01:00:40 | jyp | Shall I re-submit a cleaned up patch for the rest ? |
01:00:49 | Bagder | please do |
01:00:53 | jyp | ok |
01:00:57 | jyp | see you |
01:00:59 | lImbus | good night |
01:01:03 | jyp | night! |
01:01:11 | | Part jyp ("Leaving") |
01:02:59 | amiconn | Bagder: You broke the sim builds, and caused a warning for Ondio... |
01:03:06 | Bagder | I noticed |
01:03:22 | Bagder | I think I fixed at least some of them afterwards |
01:04:43 | amiconn | I wonder why it was necessary to take out the led() call from panic.c. led() was empty anyway if HAVE_LED was undefined (Ondio) |
01:05:13 | Bagder | I think jyp is a bit quick to remove function calls that don't do anything |
01:05:37 | Bagder | I'll revert that change |
01:07:02 | Bagder | ok, then it should get all green again |
01:07:16 | amiconn | I plan to add some indication for MMC activity to the Ondio version, using the led() calls that are already there to switch a flag. The status bar function would then use this flag to show an icon. |
01:07:49 | amiconn | Ok, maybe this is unnecessary (and even won't work) from panic.c... |
01:07:56 | Bagder | hehe |
01:08:18 | Bagder | sleep time! |
01:08:35 | amiconn | The MMC-USB bridge is able to signal activity to the controller, so Ondio can also show if there is activity while on USB |
01:08:42 | amiconn | Nite, btw |
01:09:04 | lImbus | nite |
01:09:54 | amiconn | I think I'll follow the example. Goodnight. |
01:10:10 | | Join scott666 [0] (~18f53a30@labb.contactor.se) |
01:10:20 | lImbus | nite 2, amiconn |
01:10:23 | | Part amiconn |
01:10:36 | | Join Ka [0] (~tkirk@pcp0010732484pcs.howard01.md.comcast.net) |
01:10:54 | scott666 | do I read the change log correctly? is the gmini120 really supported now? |
01:11:34 | lImbus | there are some people working on it, yeah |
01:11:59 | scott666 | is it finished? or just new code in preparation for it? |
01:12:01 | lImbus | namely 'jyp' |
01:12:09 | lImbus | preparation. |
01:12:22 | lImbus | but they seem to work fast |
01:41:04 | gromit` | he is magic :) |
01:42:22 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
01:58:33 | | Quit Stryke` (Read error: 110 (Connection timed out)) |
02:00 |
02:00:04 | | Quit scott666 ("CGI:IRC") |
02:32:31 | *** | Saving seen data "./dancer.seen" |
02:33:08 | Strath | :) |
02:42:20 | midk | that was random |
02:55:02 | | Quit midk ("Leaving") |
03:00 |
03:06:18 | | Join lImbus_ [0] (lImbus@200-167.244.81.adsl.skynet.be) |
03:07:14 | | Quit lImbus (Read error: 54 (Connection reset by peer)) |
03:07:14 | | Nick lImbus_ is now known as lImbus (lImbus@200-167.244.81.adsl.skynet.be) |
03:17:29 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
03:27:04 | | Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) |
03:27:30 | | Quit Stryke` (Remote closed the connection) |
04:00 |
04:32:33 | *** | Saving seen data "./dancer.seen" |
04:36:38 | | Join ze__ [0] (psyco@adsl-67-123-43-94.dsl.lsan03.pacbell.net) |
04:36:52 | | Quit ze (Nick collision from services.) |
04:36:57 | | Nick ze__ is now known as ze (psyco@adsl-67-123-43-94.dsl.lsan03.pacbell.net) |
06:00 |
06:17:07 | z351 | hi |
06:20:52 | | Quit Strath ("Client closed") |
06:32:34 | *** | Saving seen data "./dancer.seen" |
06:45:16 | | Quit jkarns ("Leaving") |
07:00 |
07:16:28 | | Join TexJoachim [0] (~TexJoachi@pD955F728.dip.t-dialin.net) |
07:32:52 | | Join LinusN [0] (~linus@labb.contactor.se) |
07:33:20 | dwihno | hola señor |
07:36:51 | LinusN | buenos dias |
08:00 |
08:04:08 | dwihno | You got a fat directory sorting utility? :) |
08:07:14 | LinusN | a what? |
08:12:21 | dwihno | well, an utility which will sort the directories by name, as opposed to using old DOS "defrag <drive> /sn" |
08:12:52 | LinusN | as a kind of file system optimization? |
08:13:00 | dwihno | you could say that |
08:13:14 | LinusN | why? |
08:13:34 | dwihno | The iriver firmware won't do the sorting for me (dumb, dumb dumb) |
08:13:55 | LinusN | seriously? |
08:14:17 | dwihno | yeah |
08:14:23 | LinusN | fascinating |
08:14:45 | dwihno | Haven't found a menu option for it (and I've checked the entire settings menu) |
08:14:51 | LinusN | wow |
08:15:06 | dwihno | I _could_ read the manual, but something tells me I won't find anything there. |
08:16:31 | dwihno | you know what CPU the ifp models use? |
08:17:11 | LinusN | i have no idea |
08:17:18 | dwihno | ok |
08:18:18 | dwihno | As a quick test, I've reformatted the unit and now I'm copying the files to the unit chronologically |
08:19:41 | dwihno | Do you think there is such an utility btw? |
08:21:28 | LinusN | check this: http://www.geocities.com/andreigaceff/DefragNT.html |
08:30:17 | | Quit midk ("poof") |
08:32:36 | *** | Saving seen data "./dancer.seen" |
08:41:03 | | Join Zagor [242] (~bjst@labb.contactor.se) |
08:56:16 | | Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
09:00 |
09:10:35 | | Join LePoulpe [0] (~lpos@AMontpellier-251-1-31-32.w83-113.abo.wanadoo.fr) |
09:11:53 | LePoulpe | Hi all |
09:11:58 | Zagor | hi |
09:12:02 | lImbus | salut |
09:12:23 | | Quit Bagder (Read error: 110 (Connection timed out)) |
09:14:44 | Zagor | oh crap, we'll need to to a monster commit to make all code 16-bit safe to run on the gmini |
09:15:02 | lImbus | uh |
09:15:17 | * | lImbus braces for commit |
09:15:29 | Zagor | not yet :) |
09:15:34 | LinusN | yeah, isn't it wonderfulö |
09:16:03 | Zagor | i'm not sure what I think is the least ugly way to do it |
09:16:58 | lImbus | typedefs for types ? or is it more cpu-specific ? |
09:17:48 | Zagor | i really don't like typedefs |
09:18:18 | lImbus | defines ? *duck* |
09:18:19 | LinusN | me neither |
09:18:29 | LinusN | i see two options |
09:18:36 | LinusN | 1) use typedefs |
09:18:53 | LinusN | 2) use "long" whenever a 32-bit type is required |
09:19:48 | lImbus | is there a way to influence padding and packing outside of structs ? |
09:20:11 | LinusN | lImbus: gcc has a few command line options for it |
09:20:26 | LinusN | i think |
09:20:38 | Zagor | as much as I dislike typedefs, 2) is far from obvious when reading the code and would likely result in many bugs |
09:20:50 | LinusN | probably |
09:21:45 | LinusN | when we started the rockbox project, it was such a relief when we didn't have to bother about 16-bit targets :-) |
09:22:04 | Zagor | yes |
09:22:32 | LinusN | and now we're back in type size hell |
09:24:21 | Bagder_ | apparently jyp didn't hit many 16bit problems yet |
09:24:25 | | Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) |
09:25:04 | Zagor | Bagder: but he/we will. so we need to think about how to handle them. |
09:25:11 | Bagder | indeed |
09:26:10 | Bagder | I think I vote for using long for 32 bits and int for 16/32 |
09:28:14 | * | lImbus thinks a bignum-approach for > bit numbers drops out due to lack of cpu-power... |
09:28:19 | Zagor | i'm not sure what I think yet. i'll need to meditate over this a while. |
09:28:23 | lImbus | > 16 bit that is |
09:28:45 | Zagor | lImbus: how do you mean? |
09:29:20 | lImbus | well, bignums. used on "normal" architectures to handle numbers > 32 bit |
09:29:35 | lImbus | there, where you don't have __int and so on |
09:30:01 | lImbus | AND where you need precision, there where float does not meet your needs as well |
09:30:13 | lImbus | basically the values are stored in strings... |
09:30:17 | Zagor | we have no choice but to use bignums on the 16-bit platforms. we cannot (will not) rewrite all code to use 16 bits only |
09:30:28 | lImbus | of course |
09:30:50 | lImbus | plus it takes lot of cpu-power... |
09:30:52 | Bagder | it has 32 bit longs |
09:31:13 | Zagor | Bagder: ah, it does? that's good. |
09:38:47 | LinusN | using long will solve the problem |
09:42:51 | pike | <- checking your IriverPort page. looking mighty fine. Will everything have to be 100% before it's usable ? |
09:43:36 | lImbus | what do you call useable |
09:43:37 | lImbus | ? |
09:43:47 | lImbus | for music, nearly, but remote control-stuff |
09:44:48 | LinusN | the first version will probably not support the remote lcd |
09:45:06 | pike | playing a mp3 and listen to it, is remote support a big thing (tm) to make ? |
09:45:07 | LinusN | "usable" to me means "mp3 playback works" |
09:45:38 | lImbus | to me too |
09:46:03 | LinusN | remote lcd is not technically difficult, but it requires quite a lot of changes in the rockbox architecture, since rockbox currently only supports one lcd |
09:46:23 | | Quit TexJoachim ("Bye!") |
09:47:11 | LinusN | the iriver remote is a completely new interface, which requires multiple instances of the dir browser, wps etc |
09:47:58 | pike | okie. which mp3 decoder are you gonna use? Any clue if it is more or less efficient than the iriver fw one ? |
09:48:29 | LinusN | we'll use libmad |
09:48:59 | LinusN | and i don't know if it is more efficient than the iriver one |
09:49:05 | LinusN | it probably isn't |
09:49:08 | Zagor | it will most likely be less efficient, at least to begin with |
09:49:34 | pike | before you optimize the hell out of it |
09:49:40 | LinusN | exactly |
09:49:58 | pike | the Foobar mpeg decoder is very much optimized btw |
09:49:59 | Zagor | also it will most likely be better quality |
09:50:21 | Zagor | pike: isn't that floating point? |
09:50:31 | pike | probably, let me check |
09:51:59 | pike | I own a 20gig iriver myself, and lately I've started thinking of upgrading the HD. I filled it long ago and realize I want more space |
09:52:39 | Zagor | you need to wait for the new slim 40 gig drives. current 40 gigers are thicker and don't fit in the h120 |
09:53:01 | Zagor | 5mm vs 7mm iirc |
09:53:27 | pike | yeah saw that. any idea what pricerange such a hdd would land in? |
09:53:34 | Zagor | no idea |
09:53:47 | pike | I suspect very expensive unless you buy large quantities |
09:53:59 | Zagor | problably |
09:54:15 | pike | but the 1900mAh replacement batteries seems interresting |
09:54:53 | pike | although 2100mAh seems even more interresting, but they're 1mm thicker |
09:58:56 | pike | fb2k's decoder is 32bit FP, figures :p |
09:59:21 | Zagor | most decoders use floating point, for obvious reasons |
09:59:34 | pike | except portable players |
10:00 |
10:00:07 | Zagor | right. and they mostly use proprietary codecs optimised by the processor manufacturer |
10:01:00 | pike | shame motorola didnt opensource theirs :) |
10:02:06 | Zagor | their license for it is rather nice, actually. you get it for free and can distribute all you want. but you only get binaries, no source. |
10:04:07 | lImbus | so there is no way to include it in rockbox ? |
10:04:22 | Zagor | we're not very fond of binary-only code |
10:05:08 | lImbus | no, I mean there is no way to lib/link it ? |
10:05:18 | Zagor | do you mean technically or legally? |
10:05:25 | pike | both I guess |
10:05:33 | lImbus | mhmm. both. I don't know a lot of GPL |
10:06:04 | Bagder | it would violate GPL, yes |
10:06:30 | Zagor | technically I would assume it could be done. legally we can't link to it since it is not gpl compatible. |
10:06:31 | pike | damn gpl.. (we got the same rules for XBMC) |
10:06:36 | lImbus | so with GPL you're not allowed to distribute even free closed source ? |
10:06:50 | Bagder | nope |
10:06:59 | LinusN | in this particular case, i don't care |
10:07:11 | Zagor | don't slam the gpl. it works like this for good reasons. |
10:07:19 | LinusN | i wouldn't want to use the motorola binary even if i could legally |
10:07:25 | Zagor | LinusN: i agree |
10:08:11 | lImbus | I wouldn't slam GPL as long as I'm not sure I understood it fully. It's just that I thought including free closed source would be ok. |
10:08:18 | LinusN | using a binary black box for the mp3 codec is a no-no if it can be avoided |
10:09:10 | lImbus | plus I suppose we don't need the cpu-power saving. what would you want to do during music listeing ? |
10:09:24 | lImbus | +n |
10:09:30 | Bagder | you could run the CPU slower |
10:09:33 | LinusN | well, less cpu means longer playtime |
10:09:34 | Bagder | to save battery |
10:09:35 | Zagor | lImbus: the purpose of GPL is the promote Free Software, meaning software including source code. closed source, even freely distributable, is not Free Software. |
10:09:48 | lImbus | ah, of course. variable cpu-speeds |
10:10:26 | lImbus | I suppose that inclusion would work with lGPL then ? I know the other way round is allowed. |
10:11:12 | Bagder | yes, with lgpl it is allowed |
10:14:20 | | Join Lynx_ [0] (HydraIRC@134.95.189.59) |
10:14:55 | | Join MooMaunder [0] (~paul@cpc1-stkp4-5-0-cust117.mant.cable.ntl.com) |
10:15:32 | pike | what cpu did the iriver have ? |
10:15:53 | lImbus | Coldfire Motorola |
10:15:54 | Zagor | motorola coldfire |
10:15:56 | lImbus | hehe |
10:16:06 | pike | how many mHz ? |
10:16:08 | | Join amiconn [0] (~3edc1c11@labb.contactor.se) |
10:16:11 | pike | mips etc |
10:16:31 | pike | wonder if it's similar to what si used in ie their A925 phone |
10:16:38 | LinusN | 140MHz |
10:16:45 | pike | sounds like it |
10:16:52 | pike | Symbian UIQ compatible ? |
10:16:58 | LinusN | but we will probably run it somewhere in the 70MHz range |
10:17:18 | LinusN | i have no idea if symbian runs on it |
10:17:20 | Zagor | pike: i don't even know what that means. but i would assume it's listed on motorolas pages about it. |
10:18:17 | amiconn | hi |
10:18:34 | LinusN | hi amiconn |
10:19:04 | lImbus | hi |
10:20:15 | pike | är Coldfire ARM9 baserad ? |
10:20:19 | pike | oops sorry |
10:20:30 | pike | is Coldfire ARM9 based? |
10:21:07 | Zagor | no, coldfire is the core. you could call it a boosted 68k |
10:21:36 | * | Bagder spotted some swedish slipping through! ;-) |
10:21:58 | pike | ok, then they are not compatible, pardon my swedish, hehe |
10:32:38 | *** | Saving seen data "./dancer.seen" |
10:49:24 | | Join golot [0] (~chatzilla@212.29.252.122) |
10:49:39 | golot | Hey all |
10:49:42 | golot | anyone here? |
10:49:52 | Zagor | yup |
10:49:53 | Lynx_ | hi |
10:51:48 | golot | oh :) whats up? |
10:52:09 | Bagder | we rock our boxes! |
10:52:51 | golot | I wanna start in saying how grateful I am for your great effort in making a so-so product (archos rec with archos firmware) into the best HDbased player in the market (archos Rec with ROCKBOX) ! |
10:53:11 | Lynx_ | is there any docs accessible somewhere that describe how the MDB works? |
10:53:58 | golot | I wondered if the Archos is capable of charging 2600mah batteries.? |
10:54:31 | golot | (some charged only charge up to XXXXmah - is the archos box different?) |
10:56:31 | Zagor | Lynx_: afaik only the micronas datasheet |
10:57:02 | Zagor | golot: i doubt there is any problem charging 2600 batteries unless they are a different type |
10:57:42 | golot | type = like NiMH and so on? |
10:57:47 | Zagor | yes |
10:57:56 | golot | I mean NiMH 2600... |
10:58:00 | golot | ok, sounds cool :) thx |
10:58:03 | Lynx_ | Zagor: is that accessible? i just want to know the general principle out of interest... |
10:58:47 | Zagor | Lynx_: i was wrong. linus has written a short description here: http://www.rockbox.org/twiki/bin/view/Main/MicronasDynamicBass |
10:59:38 | golot | Bjorn - do you have any spare Jukebox recorder Front buttons (my On-Off buttons are broken) ? do you know where I can start looking for this? |
11:00 |
11:00:08 | Lynx_ | Zagor: thx, that's what I wanted to know |
11:01:00 | Zagor | golot: www.newmp3technology.net sells spare parts. maybe they have buttons too. |
11:01:30 | golot | cool |
11:02:46 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
11:03:10 | golot | oh :( they dont have any spare buttons... |
11:03:37 | Zagor | golot: try emailing them. they might know where to find any. |
11:05:20 | [IDC]Dragon | I could solder a button off |
11:05:48 | golot | what do you mean? |
11:05:57 | golot | the button is made of plastic |
11:09:25 | golot | [IDC]Dragon: ? |
11:09:40 | lImbus | hehe, now tell me Dragon is not monitoring this channel via current.txt :-) |
11:09:48 | [IDC]Dragon | ;-) |
11:10:09 | [IDC]Dragon | golot: I thought you bean the switch |
11:10:14 | [IDC]Dragon | mean |
11:10:21 | golot | ahh cool, thx... |
11:10:34 | [IDC]Dragon | the plastic part I don't have |
11:10:44 | golot | yeah... |
11:11:14 | golot | anyone here replaced his jukebox light color? I saw someone asking what type to get but does anyone know how to do it? could be cool... |
11:11:51 | [IDC]Dragon | you mean, the backlight? |
11:11:58 | Zagor | i have white backlight |
11:12:06 | [IDC]Dragon | me too |
11:12:10 | golot | yeah backlight* |
11:12:22 | golot | is it complicated to a total noob like me? |
11:12:29 | Zagor | yes :) |
11:12:33 | lImbus | gotta go, bbl |
11:12:34 | golot | lol :) |
11:12:38 | golot | bye |
11:13:14 | [IDC]Dragon | golot: so what button part do you need? |
11:13:15 | | Quit lImbus (" HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!") |
11:13:18 | golot | white gotta look WOOOT!!! |
11:13:20 | dwihno | I've soldered for the first time since my good old school days! |
11:13:27 | dwihno | Although I forgot about "flussmedel" :) |
11:13:36 | [IDC]Dragon | flux |
11:13:40 | golot | ammm I need the On\Off button |
11:13:50 | dwihno | [IDC]Dragon: is that really needed? |
11:13:57 | [IDC]Dragon | the switch or the knob? |
11:14:03 | golot | and I could use a Play button... but not "must"... |
11:14:19 | golot | the plastic part, (what you actually press on)... |
11:14:29 | [IDC]Dragon | then I can't help |
11:14:53 | [IDC]Dragon | dwihno: you do, it's included in the solder |
11:15:26 | golot | dont you guys have like 2000000000000 jukeboxes lying around just like that? ;) |
11:16:04 | dwihno | [IDC]Dragon: it is? aah, nice :) |
11:16:16 | dwihno | [IDC]Dragon: In my old school days, we applied it by hand |
11:16:42 | golot | lol how old are you - 150 ? :) |
11:18:09 | Lynx_ | wasn't there a webpage on the backlight mod? Can't seem to find it now. |
11:18:24 | dwihno | golot: ayy! ye olde landlubber! ;) |
11:19:05 | golot | hehehe :D |
11:19:13 | dwihno | soldering is fun... although you should keep a stable blood sugar level or you will have a hard time soldering while shaking more than a vibrator on steroids |
11:19:27 | golot | LoL |
11:20:11 | dwihno | Now if I could get my hands on a 2.5mm stereo connector |
11:20:15 | golot | anyone can reccomend on really good NiMh batteries? |
11:20:27 | dwihno | the GP batteries are good |
11:20:32 | golot | oh, I have many of those, all kind of connectors... |
11:20:43 | golot | yeah, I have the 2000 GP... |
11:21:05 | golot | you dont know how cool I made my jukebox look |
11:21:23 | dwihno | a portable christmas tree? :)= |
11:21:40 | golot | I scrobbed the metal part and its now shinning and looks amazing :) |
11:21:41 | dwihno | Zagor, Bagder, LinusN, do you think clas ohlson keep 2.5mm stereo connectors? |
11:21:54 | dwihno | golot: pics! pics! :) |
11:21:57 | golot | not gone that far :D making a Xmas tree |
11:22:12 | Bagder | dwihno: I'd say very likely |
11:22:24 | golot | My jukebox is topless now but Ill take some pictures anyway... |
11:23:08 | dwihno | Bagder: ah, okay... I'll check after work |
11:26:19 | golot | Pictures are coming! |
11:30:10 | dwihno | Bagder: seems like CO doesn't have them :( |
11:34:50 | golot | http://www.geocities.com/golot_boots/jukebox/index.html <−−- look ! |
11:35:33 | golot | not so good pictures, but you get the idea... :) its really shinny and looks cool, Im really proud of myself... |
11:35:39 | [IDC]Dragon | haha |
11:38:06 | golot | comments? |
11:38:24 | golot | you should really see it, not in pictures... in real, its so cool... :D |
11:38:25 | dwihno | shinny :D |
11:38:54 | golot | 2 better pictures are comming in a minute |
11:38:57 | [IDC]Dragon | I rarely look at the underside of my JB |
11:39:37 | [IDC]Dragon | the Ipod has a shiny back, so you can see the fingerprints better ;-) |
11:39:43 | golot | yeah, lol, but its also the sides and the up and down sides (where you connect stuff to it) |
11:40:00 | [IDC]Dragon | apart from that, I see no benefit |
11:40:14 | golot | fun making it ? :) |
11:40:24 | [IDC]Dragon | ok, sure |
11:40:48 | golot | I wish they would make the front panel and the battery covers out of metal too |
11:40:53 | | Join quelsaruk [0] (~50678515@labb.contactor.se) |
11:40:58 | golot | then I could have one shinning jukebox :D |
11:41:05 | quelsaruk | hi, good morning to all |
11:41:13 | golot | http://www.geocities.com/golot_boots/jukebox/DSCN0033.JPG |
11:41:18 | golot | http://www.geocities.com/golot_boots/jukebox/DSCN0034.JPG |
11:41:33 | golot | oh no, the first one is bad |
11:42:04 | golot | second one is better |
11:42:13 | golot | look at this: http://www.geocities.com/golot_boots/jukebox/DSCN0034.JPG |
11:46:15 | quelsaruk | amiconn, Bagder : Archos is finally going to replace my jukebox :) |
11:48:47 | pike | golot get a better host.. |
11:49:06 | golot | its down? |
11:49:09 | golot | oh :( |
11:49:52 | golot | Im uploading to a different account! |
11:55:00 | quelsaruk | cu l8r! |
11:55:24 | | Part quelsaruk |
12:00 |
12:01:00 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
12:01:01 | golot | Look - http://www.geocities.com/golot2001/DSCN0034.JPG |
12:12:50 | | Join Kultivator [0] (Taxi@oslo-dhcp-248-180.bluecom.no) |
12:32:42 | *** | Saving seen data "./dancer.seen" |
12:33:25 | Bagder | "With the ARCHOS patented retro-recording system, it is possible to record the radio after the song has already started." |
12:33:38 | dwihno | patented? |
12:33:39 | Bagder | patented being the word |
12:33:40 | dwihno | :-) |
12:34:34 | Hadaka | I bet you guys have seen the archos linux based player stuff :) |
12:34:53 | Bagder | I have |
12:35:07 | dwihno | there is a linux based player now? |
12:35:10 | Bagder | yes |
12:35:14 | Bagder | Archos' latest |
12:35:20 | Bagder | PMA400 |
12:35:23 | Hadaka | well, to be released still, but yes |
12:35:29 | Bagder | http://www.archos.com/products/overview/pma_400.html |
12:35:31 | Hadaka | and they are giving out a "full SDK", whatever that means |
12:35:53 | Bagder | word is they use qtopia |
12:36:07 | Hadaka | yeah, they even say it |
12:36:11 | Bagder | ok |
12:36:15 | dwihno | I sense NDA |
12:36:27 | Bagder | dwihno: not likely since this is all based on linux |
12:36:44 | dwihno | Bagder: Was thinking about the SDK |
12:36:45 | Bagder | I bet they ship a prebuilt gcc version for cross-compiles |
12:38:29 | Bagder | or possibly, they'll never deliver their promise :-) |
12:38:39 | Bagder | I mean, they are Archos after all |
12:39:50 | Hadaka | yeah, remains to be seen |
13:00 |
13:19:28 | [IDC]Dragon | I'm getting mailing list postings now from rockbox@rockbox.org instead of rockbox@cool.haxx.se, is that the new way? |
13:19:53 | [IDC]Dragon | If so, I have to adjust my mail filter, no problem |
13:20:34 | Zagor | sounds like a bug to me |
13:21:25 | Bagder | I get them from @cool.haxx.se |
13:21:35 | Zagor | or, rather, this one person sent his mail to rockbox.org instead of cool.haxx.se and we didn't bounce it |
13:21:52 | Zagor | Bagder: look at From: joerch.net@web.de |
13:22:38 | Bagder | you mean the To: line? |
13:22:42 | Zagor | yes |
13:22:54 | Bagder | that's because those users mailed to that address |
13:22:57 | Bagder | and it works |
13:23:21 | Bagder | the software doesn't care about the To: line |
13:23:22 | Zagor | right. but should it work? people are filtering on the To: address, so there is some value in keeping it constant |
13:24:13 | Bagder | its more work to prevent it |
13:40:41 | golot | anyone here has a GMINI ? |
14:00 |
14:18:13 | | Quit z351 ("Leaving") |
14:27:01 | | Join Nibbler [0] (~nibbler@p508C6091.dip.t-dialin.net) |
14:32:44 | *** | Saving seen data "./dancer.seen" |
14:45:36 | | Join golot_ [0] (~chatzilla@212.29.252.122) |
14:45:37 | | Quit golot (Read error: 54 (Connection reset by peer)) |
14:52:44 | amiconn | Bagder: Speaking about the rockbox mailing list - is there a reason why I get the reminder mails twice? |
14:53:12 | Bagder | no idea ;-) |
14:53:13 | LinusN | perhaps because you are subscribed to two lists? |
14:53:23 | Bagder | no, it should sent one for all lists |
14:53:26 | Bagder | send |
14:54:56 | lImbus | amiconn: is it the same password for both mails ? |
15:00 |
15:03:41 | [IDC]Dragon | I also get 2 each time |
15:04:15 | | Join Strath [0] (~mike@dgvlwinas01pool0-a230.wi.tds.net) |
15:04:53 | Bagder | hey Strath |
15:05:11 | Strath | hey Bagder |
15:05:14 | lImbus | uh, I'm gettin 2 as well. same password... |
15:06:28 | Bagder | Strath: noticed jyp's recent Gmini work on Rockbox? |
15:07:50 | Strath | ya, he sure is fast |
15:08:08 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:09:30 | Strath | when he started coding for the gmini emulator, he had IRQ, DMA, IDE, and UART all working within a couple weeks |
15:12:09 | [IDC]Dragon | how is IDE emulated? |
15:12:58 | [IDC]Dragon | (and the other external interfaces) |
15:21:38 | | Quit golot_ (Read error: 104 (Connection reset by peer)) |
15:25:26 | | Join R3nTiL [0] (~zorroz@217.30.249.225) |
15:28:29 | | Join TexJoachim [0] (~TexJoachi@pD955F728.dip.t-dialin.net) |
15:30:37 | | Quit midk (Read error: 104 (Connection reset by peer)) |
15:45:56 | | Join bogeyman [0] (~os_proxy@24-165-22-162.san.rr.com) |
15:59:03 | | Nick mbr_ is now known as mbr (~mb@stz-softwaretechnik.de) |
16:00 |
16:02:58 | Strath | IDE accesses a disk image file, UART uses a named pipe |
16:03:48 | Strath | now there is a gui too, so buttons are well, buttons |
16:06:42 | | Part LinusN |
16:11:20 | [IDC]Dragon | Strath: very nice |
16:11:55 | [IDC]Dragon | so you bring the low level IDE commands back up into an image access |
16:12:09 | Strath | ya |
16:17:04 | amiconn | Bagder: I'm only subscribed to one list, and the mails look identical.. |
16:19:39 | | Nick Strath is now known as StrathAFK (~mike@dgvlwinas01pool0-a230.wi.tds.net) |
16:23:42 | | Quit R3nTiL () |
16:24:03 | | Join jyp [0] (~jp@172.9-136-217.adsl.skynet.be) |
16:25:01 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
16:32:47 | *** | Saving seen data "./dancer.seen" |
16:33:25 | Lynx_ | I get two mails, too, that started last december, before that i got only one |
16:33:41 | | Quit jyp (niven.freenode.net irc.freenode.net) |
16:33:41 | NSplit | niven.freenode.net irc.freenode.net |
16:34:32 | NHeal | niven.freenode.net irc.freenode.net |
16:34:32 | NJoin | jyp [0] (~jp@172.9-136-217.adsl.skynet.be) |
16:40:14 | [IDC]Dragon | anybody with an idea if Fujitsu or Toshiba 100GB is better? |
16:41:07 | [IDC]Dragon | it used to be Fujitsu, but now the Toshiba specs are a bit more quiet and low power |
16:41:51 | [IDC]Dragon | did Toshiba improve something about it? |
16:42:57 | Zagor | no idea |
16:44:07 | | Join teuvvo [0] (~54e68f48@labb.contactor.se) |
16:44:56 | teuvvo | Hello. Any news -good/bad - about the Rockbox iRiver? |
16:48:56 | | Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a230.wi.tds.net) |
16:49:46 | | Join mecraw_ [0] (~lmarlow@69.2.235.2) |
16:57:17 | | Part Zagor |
16:59:23 | | Join einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de) |
17:00 |
17:08:10 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
17:25:15 | | Quit mecraw_ (Read error: 110 (Connection timed out)) |
17:39:45 | | Join Spida_ [0] (Spida@p50859E29.dip.t-dialin.net) |
17:50:46 | | Quit Spida (Read error: 110 (Connection timed out)) |
18:00 |
18:04:30 | | Quit amiconn ("CGI:IRC 0.5.4 (2004/01/29)") |
18:12:27 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it") |
18:32:48 | *** | Saving seen data "./dancer.seen" |
19:00 |
19:01:12 | | Join amiconn [0] (~jens@pD9E7FBFD.dip.t-dialin.net) |
19:02:25 | | Join webguest19 [0] (~534e2b4d@labb.contactor.se) |
19:02:47 | lImbus | [IDC]Dragon: I tested my broken OndioFM with an external MMC yesterday |
19:02:54 | lImbus | it does not work either |
19:03:16 | | Quit webguest19 (Client Quit) |
19:15:22 | | Quit teuvvo ("CGI:IRC (EOF)") |
19:15:52 | | Join TuDo [0] (~chatzilla@a80-126-54-179.adsl.xs4all.nl) |
19:18:19 | | Quit MooMaunder (Read error: 110 (Connection timed out)) |
19:21:25 | | Part TuDo |
19:25:38 | | Quit [IDC]Dragon ("CGI:IRC") |
19:30:28 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
19:30:32 | _aLF | hi |
19:30:48 | jyp | hi |
19:36:05 | crash_ | ah jyp :) i talked so strath |
19:36:35 | jyp | good |
19:36:41 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
19:37:16 | crash_ | i'll start to copy most of the infos from donat to rockbox |
19:37:30 | crash_ | but only the not too technical stuff |
19:37:39 | jyp | ok |
19:37:41 | crash_ | at the moment he wants to keep his wiki |
19:37:52 | crash_ | but he has no problem with puttin it on rockbox |
19:37:59 | jyp | too bad I'm still unable to access it :/ |
19:38:07 | crash_ | it should |
19:38:17 | crash_ | he said it had been fixed yesterday |
19:38:38 | jyp | Right, but is broke again today |
19:38:47 | jyp | up, down, ... |
19:41:02 | jyp | up, down, ... |
19:42:26 | Strath | ya.. don't know why |
19:42:49 | crash_ | i can reach it tough |
19:43:18 | Strath | where are you crash? |
19:43:22 | crash_ | germany |
19:43:31 | crash_ | at the moment at schlund+partner backbone |
19:43:44 | crash_ | aka 1&1 |
19:44:19 | Strath | wierd |
19:45:35 | Strath | could set up an http proxy for jyp :) (assuming he can reach that) |
19:45:47 | crash_ | hehe |
19:46:03 | crash_ | just checking if i can rech it via t-online backbone |
19:46:06 | crash_ | but i dont reach home |
19:47:28 | | Join einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de) |
19:47:43 | Strath | could it be blocking? |
19:48:13 | crash_ | from home i dont reach it |
19:48:31 | crash_ | so the router from here at work seems to be antoher one than at home |
19:50:11 | Strath | strange |
19:54:05 | crash_ | quite strange yeah |
19:54:20 | crash_ | unfortunatly i wont reach donat.org from home |
19:54:23 | | Nick gromit` is now known as gromit`rip (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
19:54:29 | crash_ | i think i'll have to copy it via my server ;) |
19:54:36 | crash_ | gotta go |
19:54:39 | crash_ | see you later |
19:54:48 | jyp | good by |
19:54:52 | Strath | oy |
19:54:59 | Strath | alright |
20:00 |
20:18:46 | | Nick Spida_ is now known as Spida (Spida@p50859E29.dip.t-dialin.net) |
20:23:18 | | Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) |
20:32:51 | *** | Saving seen data "./dancer.seen" |
20:41:40 | | Join Tang [0] (~chatzilla@ARennes-204-1-42-176.w217-128.abo.wanadoo.fr) |
20:41:54 | Tang | Helloguys! |
20:42:16 | jyp | hi |
20:44:05 | Strath | ola |
20:45:11 | Tang | :) |
20:45:28 | Tang | Nothing news with the iRiverport theses lats days? |
20:46:46 | jyp | I can only give news about the Gmini port :P |
20:49:45 | | Join dcran [0] (dcran@c-24-118-33-67.mn.client2.attbi.com) |
20:50:33 | dcran | Ok quick question, I see in todays log that Linus said you were going to use the libmad decoder....any reason not to use the Helix decoder as I imagine that would be better??? |
20:51:47 | | Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") |
20:52:37 | Stryke` | From what I can tell from the website, the Helix decoder is MP3 only (i.e. no layer-I or layer-II support), is written in C++, and is licensed under the Real Networks Public Source License (RPSL). For those reasons, and the fact that MAD is tried and tested, I think we should stick with MAD −− DaveChapman |
20:52:41 | Stryke` | from the wiki |
20:53:42 | jyp | In what way Helix would be better ? |
20:53:54 | dcran | interesting.......I mean thats fine I would think though that Helix (Open REaL) would be more tested than libmad |
20:54:32 | dcran | libmad may be more tested in rockbox, but I would say overall Helix has been tested on many more platforms |
20:55:51 | * | dcran notes that he is not a firmware dev or a audio dev and is just a stray dog with a comment |
21:00 |
21:04:34 | | Join lImbus_ [0] (lImbus@144-185.244.81.adsl.skynet.be) |
21:04:47 | | Nick lImbus_ is now known as lImbusHome (lImbus@144-185.244.81.adsl.skynet.be) |
21:12:01 | Spida | hi lImbusHome |
21:12:29 | lImbusHome | tach Spida |
21:14:33 | Spida | bist du morgen mit $hardware im hermann? |
21:15:06 | lImbusHome | let's stay in english |
21:15:14 | lImbusHome | yes, I will be there, with my devices |
21:15:36 | lImbusHome | (no need anymore to bring with you the mcc-card, I was able to do another test yesterday) |
21:43:08 | jyp | Any ATA guru online ? |
21:44:43 | | Quit dcran ("dcran has no reason") |
22:00 |
22:00:41 | | Quit Stryke` (Read error: 110 (Connection timed out)) |
22:03:57 | | Join teuvvo [0] (~54e68f48@labb.contactor.se) |
22:13:09 | teuvvo | Any news on the Rockbox iRiver? |
22:15:45 | | Join LinusN [0] (~linus@labb.contactor.se) |
22:16:04 | LinusN | teuvvo: nope, no news. been busy. |
22:17:11 | teuvvo | Okay. Just want You to know how eagerly people are waiting for it, works so fine with the Archos! |
22:17:19 | LinusN | jyp: i have some questions about your context switch code |
22:17:26 | teuvvo | You guys are doing a tremendous job here! |
22:17:35 | LinusN | teuvvo: thx |
22:17:51 | jyp | yes ? |
22:18:00 | teuvvo | I hope I could do something, but haven't yet found the programmer in me... ;) |
22:18:53 | LinusN | jyp: i wonder why you did the initial context differently than the other platforms |
22:19:26 | Bagder | I asked that too ;-) |
22:19:27 | LinusN | checking a flag in load_context instead of saving a valid context in create_thread |
22:20:04 | * | LinusN knows nothing about the cpu in question |
22:20:09 | jyp | I didn't know where to put the start address in the context |
22:20:26 | jyp | so I changed it to make the jump explicitly |
22:20:44 | LinusN | how does a function call return in your architecture |
22:20:45 | LinusN | ? |
22:21:27 | jyp | jumps to a register address |
22:21:37 | LinusN | and if the functiuons nest? |
22:21:56 | jyp | then push it on the stack |
22:22:08 | LinusN | just like the sh7034 then |
22:23:13 | jyp | The truth is I didn't realize the code relied on optimization till late |
22:23:28 | jyp | so I made up my own method... |
22:23:39 | LinusN | relied on optimization? |
22:23:55 | jyp | It fails if not compiling with -O1 |
22:24:16 | LinusN | you mean the frame pointer removal? |
22:24:29 | Bagder | its the inline stuff, isn't it? |
22:24:41 | jyp | I mean spilling registers on the stack |
22:25:32 | LinusN | jyp: it doesn't rely on any other optimization than the frame pointer exclusion |
22:26:18 | LinusN | (and the inline of course) |
22:26:47 | jyp | You're right... |
22:26:58 | jyp | My method does :@ |
22:27:09 | LinusN | hehe |
22:27:18 | * | Bagder giggles |
22:27:36 | | Quit lImbusHome (" HydraIRC -> http://www.hydrairc.com <- :P") |
22:27:52 | | Join lImbus_ [0] (lImbus@144-185.244.81.adsl.skynet.be) |
22:27:55 | LinusN | jyp: you should probably look at the 7034 code |
22:28:30 | LinusN | btw, how does the cpu handle 32-bit operations? does it combine two registers? |
22:29:12 | jyp | yes |
22:29:36 | Strath | combine two registers: exactly |
22:29:43 | LinusN | kind of guessed that, since the push operation pushed two registers |
22:30:43 | jyp | I can revert to saving the context in a memory location, but the cpu like to store on the stack better I think |
22:31:05 | jyp | Also, I didn't quite understand what's "volatile context" |
22:32:19 | LinusN | the volatile context is the scratch registers |
22:32:46 | jyp | callee saved |
22:32:48 | jyp | ? |
22:32:52 | *** | Saving seen data "./dancer.seen" |
22:33:04 | LinusN | the non-volatile context are callee saved |
22:33:15 | LinusN | the volatile context is not saved at all |
22:33:39 | LinusN | the context switch saves the non-volatile context |
22:33:51 | jyp | I meant non-volatile then |
22:33:55 | LinusN | i see |
22:34:27 | jyp | however all registers are callee saved on the calmrisc |
22:34:28 | | Quit teuvvo ("CGI:IRC (EOF)") |
22:34:57 | LinusN | wow |
22:35:15 | jyp | At least all address registers |
22:35:26 | jyp | maybe r0-r1 are not |
22:36:06 | Strath | most of the time they are |
22:36:42 | jyp | Strath: gcc & calmshine don't use exactly the same calling convention... |
22:36:56 | Strath | i didn't think they would |
22:37:25 | Strath | jyp, does your Makefiles depend on absolute paths? |
22:37:49 | Strath | "/home/jp/gmini/rockbox/firmware" |
22:37:50 | jyp | Some times yes :) |
22:38:13 | jyp | problem is I gave you a snapshot of my working directory... |
22:38:25 | Bagder | the makefiles are generated to use abs paths |
22:38:34 | Bagder | at least in the root one |
22:39:16 | jyp | and unfortunately I changed the generated makefile by hand |
22:39:27 | Bagder | fool |
22:39:30 | Strath | right |
22:39:31 | Bagder | :-) |
22:39:47 | Strath | anyways... i've got a rockbox.o now |
22:40:10 | Bagder | jyp: why do you want that? |
22:40:20 | Bagder | what's wrong with the .a? |
22:40:28 | jyp | nothing |
22:40:39 | jyp | I'm just walking in the dark |
22:40:43 | Strath | lol |
22:40:44 | Bagder | ok |
22:40:55 | Bagder | then don't sent it in revised patches to me! ;-) |
22:40:57 | Strath | and he's leading me through this first time |
22:41:35 | jyp | Just ignore everything related to he build process ... sorry ... |
22:41:44 | Bagder | ok, will do |
22:42:19 | Bagder | I have a few more questions |
22:42:53 | Bagder | I didn't commit the export/types.h |
22:43:05 | jyp | It shouldn't have been in. |
22:43:15 | jyp | I thought I removed it |
22:43:18 | Bagder | right, but the code in ata.c uses types from there |
22:43:32 | jyp | It shouldn't have been in either. |
22:43:46 | * | jyp boinks his head |
22:47:01 | LinusN | jyp: wanna know what set_irq_level() does? |
22:47:18 | jyp | sure |
22:47:25 | jyp | I guess I know |
22:47:30 | jyp | but in precision |
22:47:32 | LinusN | it sets the irq level, and returns the old one |
22:48:18 | jyp | problem is there's no such thing as an irq level in my chip |
22:48:34 | LinusN | a single irq? |
22:49:04 | jyp | we can individually mask the irqs |
22:49:19 | jyp | but up till now there's only timer implemented |
22:50:26 | LinusN | do you have a general irq mask bit, that disables all irq:s? |
22:50:40 | jyp | yes |
22:51:42 | LinusN | then that is your irq level |
22:51:45 | LinusN | 0..1 |
22:52:05 | jyp | ok |
22:52:20 | LinusN | set HIGHEST_IRQ_LEVEL to the mask value of the status register where the bit is |
22:52:59 | LinusN | i.e #define HIGHEST_IRQ_LEVEL (1<<bitnumber) |
22:53:20 | LinusN | then have it return the old value of the bit |
22:54:42 | jyp | thanks for the info |
22:55:37 | LinusN | i'm impressed by your work |
22:55:49 | jyp | thanks ;) |
22:56:32 | jyp | But I owe everything to my guide and master, Strath ;) |
22:56:43 | LinusN | :-) |
22:56:52 | Strath | too late now suck up :P |
23:00 |
23:03:25 | Bagder | jyp: you need to stop using ifdef platform when you want ifdef feature |
23:03:35 | | Quit methangas (" HydraIRC rocks! -> http://www.hydrairc.com <-") |
23:03:51 | jyp | I tried to correct it... |
23:04:00 | jyp | where did I sinned ? |
23:04:04 | Bagder | lcd-recorder.c |
23:04:10 | jyp | ha... |
23:04:13 | Bagder | I've just added a good define to use |
23:04:19 | jyp | ok |
23:04:58 | Bagder | and btw, shouldn't flash.lds just be #ifdef'ed within app.lds? |
23:05:21 | Bagder | app.lds is the link file, just preprocessed before it is used |
23:05:29 | Bagder | to allow #ifdefs etc |
23:05:36 | jyp | I didn't know the existence of the file till now |
23:05:40 | Bagder | :-) |
23:05:41 | Strath | ya, you slice that lazy jyp a new one Bagder :D |
23:06:11 | * | Strath cracks a whip |
23:06:11 | jyp | screw you guys, i'm going home |
23:06:17 | Bagder | :-) |
23:06:24 | Strath | lol |
23:06:33 | * | jyp leaves |
23:06:35 | jyp | ;) |
23:07:30 | lImbus_ | nite |
23:08:13 | Strath | gnite lImbus_ |
23:08:49 | lImbus_ | euh, I'm not yet goin. |
23:08:55 | lImbus_ | it was to jyp |
23:09:04 | Strath | :) |
23:09:11 | Strath | humor |
23:09:36 | lImbus_ | aah, sorry, it's quite late here around |
23:09:54 | Strath | i know... :) |
23:14:51 | | Join Zagor [242] (foobar@h254n2fls31o265.telia.com) |
23:14:53 | | Quit courtc (Read error: 104 (Connection reset by peer)) |
23:15:23 | Bagder | hey dr Z |
23:15:32 | Zagor | good evening |
23:16:23 | LinusN | mr Z |
23:16:42 | lImbus_ | zzzzZZZzZZzzZ :D |
23:18:28 | Bagder | jyp: shouldn't the crt1.c contents be in system.c instead? |
23:18:43 | | Join courtc [0] (~court@adsl-33-164-40.asm.bellsouth.net) |
23:19:12 | jyp | probably |
23:21:29 | Bagder | and... I don't think __attribute__ is good undontionally in sprintf.h |
23:21:38 | Bagder | I believe it gets included by the simulator |
23:21:48 | Bagder | which might be compiled with msvc at times |
23:22:08 | Zagor | which attribute? icode? |
23:22:31 | Bagder | __attribute__ ( ( format( printf, 3, 4 ) ) ); |
23:22:36 | jyp | Well, that's a cool feature to have... |
23:22:49 | Bagder | then ifdef it on some gcc symbol |
23:23:04 | jyp | There can be #define __attribute__ () when not gcc |
23:23:13 | Strath | where is at it called? |
23:23:13 | Strath | grr |
23:23:25 | Strath | wrng window |
23:23:47 | Bagder | jyp: yes, but it seems a bit overkill |
23:23:52 | Zagor | doubleplusungood __attribute__ is a compiler-internal define. messing with those are bad karma. |
23:23:52 | Bagder | to me |
23:24:10 | jyp | Nah ;) |
23:24:35 | jyp | Still __attribute__ is used at a lot of places in your code already |
23:24:42 | jyp | for section |
23:24:48 | Bagder | yes, in code that isn't used by the simulator |
23:24:54 | Zagor | ok, i'll rephrase: messing with those will get you spanked by the Code Police :) |
23:25:02 | Zagor | sure, but we don't redefine it... |
23:25:06 | Bagder | very true |
23:25:44 | Bagder | jyp: and I just can't apply that firmware/SOURCES diff |
23:25:51 | jyp | Note that __attribute__ is especially designed to be redefined |
23:25:56 | jyp | when not supported |
23:26:04 | jyp | of course |
23:26:36 | jyp | I will clean it up as soo as the rest compiles |
23:26:41 | | Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) |
23:27:28 | Bagder | I think you can start posting your updated patches to the mailing list |
23:27:55 | jyp | ok |
23:29:02 | Bagder | try to exclude stuff you know we can't commit |
23:29:09 | jyp | alright |
23:39:21 | Zagor | hmm, i've changed my mind. jyp is right. I think we should be using attribute format for printf-style functions. |
23:40:19 | Zagor | splash() is a candidate, for example. |
23:40:56 | Bagder | sure we should, we should just not make it unconditional in files used by the sim |
23:43:03 | Zagor | the question is: is it better to ifdef all uses or to ifdef __GNUC__ the definition |
23:43:37 | jyp | Thinking twice ifdef __GNUC__ the definition |
23:44:24 | Bagder | yeah, thinking about it more, I lean towards that too |
23:51:02 | | Join webguest55 [0] (~43a66d3a@labb.contactor.se) |
23:52:18 | | Join mrfry3 [0] (~43a66d3a@labb.contactor.se) |
23:52:18 | | Quit webguest55 (Client Quit) |
23:52:40 | | Quit mrfry3 (Client Quit) |
23:52:47 | | Join mrfry3 [0] (~43a66d3a@labb.contactor.se) |
23:53:28 | | Quit mrfry3 (Client Quit) |
23:53:35 | | Join mrfry3 [0] (~43a66d3a@labb.contactor.se) |
23:54:22 | | Quit TexJoachim ("Bye!") |
23:57:29 | mrfry3 | help |
23:57:38 | LinusN | mrfry3: ? |
23:57:52 | mrfry3 | can rockbox be used with gmini120 |
23:58:03 | jyp | somewhat ;) |
23:58:05 | LinusN | not yet |
23:58:27 | mrfry3 | thanks |