| 00:06:52 | *** | No seen item changed, no save performed. |
| 00:17:16 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 00:25:42 | | Join leprezaun [0] (zazz@076-066.dialup.sunysb.edu) |
| 00:34:15 | | Quit zeekoe (Read error: 60 (Operation timed out)) |
| 00:39:12 | scott666 | kaboofa: whats so illegal about the remixes? |
| 00:39:39 | scott666 | is it anything like the grey album/double black album thing? |
| 00:42:51 | kaboofa | i don't know ;P |
| 00:42:54 | kaboofa | wait |
| 00:42:54 | kaboofa | what? |
| 00:43:04 | kaboofa | grey album? |
| 00:43:06 | scott666 | yeah |
| 00:43:10 | kaboofa | by whom? |
| 00:43:19 | scott666 | i cant remember the guy that mixed it |
| 00:43:22 | kaboofa | (please explain this concept) |
| 00:43:43 | scott666 | he remixed the beatles white album with jay z's black album |
| 00:43:50 | kaboofa | weird |
| 00:43:54 | kaboofa | why would you do that :X |
| 00:44:02 | scott666 | and someone else did the same thing but with jay z and metallicas black album |
| 00:44:07 | kaboofa | haha |
| 00:44:08 | scott666 | because they could |
| 00:44:33 | scott666 | apparently jay z released an acappella (sp?) version of his cd |
| 00:46:11 | scott666 | so theyre totally illegal because they dont have lisencing rights from either |
| 00:47:00 | | Quit uski_ ("Leaving") |
| 00:47:57 | scott666 | download both here: http://www.bannedmusic.org/ |
| 01:00 |
| 01:10:41 | | Join tpelliott [0] (telliott@208-251-255-120.res.evv.cable.sigecom.net) |
| 01:19:00 | | Quit midk|gone (Read error: 60 (Operation timed out)) |
| 01:19:14 | | Join midk|gone [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com) |
| 01:26:31 | | Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
| 01:37:49 | | Quit lImbus (" WOW! This IRC Client ownz! HydraIRC -> http://www.hydrairc.com <-") |
| 01:42:33 | | Part tpelliott |
| 01:54:53 | kaboofa | ugh |
| 01:54:57 | kaboofa | hydrairc |
| 02:00 |
| 02:06:53 | *** | Saving seen data "./dancer.seen" |
| 02:19:30 | AciD | :) |
| 02:27:51 | | Join BC [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 02:33:30 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 02:34:16 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 02:53:05 | kaboofa | moo |
| 02:57:40 | BC | kwak |
| 02:58:13 | kaboofa | mmm |
| 02:58:21 | kaboofa | rape of bandwidth |
| 03:00 |
| 03:11:18 | | Quit scott666 (Read error: 110 (Connection timed out)) |
| 03:20:24 | | Quit BC (Read error: 54 (Connection reset by peer)) |
| 03:21:44 | | Join BC [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 03:25:27 | | Join thirdworld [0] (~huszcak@161.115.209.37) |
| 03:25:41 | thirdworld | i fried my jukebox |
| 03:27:26 | BC | bummer |
| 03:27:26 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 03:27:42 | scott666 | hey BC |
| 03:27:50 | BC | Hey Satan |
| 03:28:00 | scott666 | heh |
| 03:28:10 | scott666 | my reciever is dying |
| 03:28:18 | scott666 | i cant watch requiem for a dream |
| 03:28:30 | * | scott666 is pissed |
| 03:29:27 | scott666 | do you have any idea why the center channel would output sound very quietly, when the rest of the speakers dont? |
| 03:30:40 | BC | wired up badly? |
| 03:30:45 | scott666 | nope |
| 03:30:51 | scott666 | well |
| 03:30:53 | scott666 | possibly |
| 03:30:56 | BC | amp crashed? |
| 03:30:57 | scott666 | define badly |
| 03:31:17 | BC | wrong |
| 03:31:24 | scott666 | then no |
| 03:31:38 | scott666 | because it worked yesterday and i hadnt chagned anything |
| 03:31:49 | scott666 | and i double checked |
| 03:31:51 | scott666 | repeatedly. |
| 03:32:17 | scott666 | i tested the speaker, the dvd player, and all the wires in between |
| 03:32:19 | BC | amp crashed? |
| 03:32:28 | scott666 | how can i test |
| 03:32:33 | BC | reboot |
| 03:32:42 | scott666 | then yes |
| 03:32:47 | scott666 | lol |
| 03:33:31 | scott666 | is it fixable? |
| 03:33:43 | BC | everything is fixable |
| 03:34:01 | scott666 | is it easily fixable? |
| 03:34:24 | BC | couldn't tell from here |
| 03:34:49 | scott666 | i could take a picture of the inside of the reciever |
| 03:34:53 | scott666 | lol |
| 03:35:09 | BC | no thanks |
| 03:35:10 | BC | lol |
| 03:35:17 | BC | coding atm |
| 03:35:33 | scott666 | ok |
| 03:35:36 | | Nick BC is now known as BC|coding (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 03:35:36 | scott666 | ill google for a minute |
| 03:38:24 | | Quit leprezaun (Read error: 110 (Connection timed out)) |
| 03:48:59 | | Quit thirdworld () |
| 03:49:11 | scott666 | no results |
| 03:49:16 | scott666 | damnit |
| 03:54:54 | | Quit midk|gone (Read error: 104 (Connection reset by peer)) |
| 03:55:12 | | Join midk|gone [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com) |
| 04:00 |
| 04:06:57 | *** | Saving seen data "./dancer.seen" |
| 04:21:15 | | Join dstar5 [0] (lee@ACC57F20.ipt.aol.com) |
| 04:21:15 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
| 04:24:33 | | Quit dstar5 (Client Quit) |
| 04:31:43 | | Join leprezaun [0] (zazz@076-045.dialup.sunysb.edu) |
| 04:39:36 | | Quit leprezaun ("Disconnecting") |
| 04:49:51 | | Part scott666 |
| 04:51:35 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 04:57:34 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 05:00 |
| 05:29:55 | | Quit AciD ("resistance is futile. you will be ass-stimulated") |
| 05:39:08 | | Join midknight2k3 [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com) |
| 05:39:55 | | Quit midk|gone (Read error: 54 (Connection reset by peer)) |
| 05:47:22 | | Part BC|coding |
| 06:00 |
| 06:04:45 | | Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
| 06:06:58 | *** | Saving seen data "./dancer.seen" |
| 06:10:53 | | Nick kaboofa is now known as tomsleep (~kaboofa@pcp03462569pcs.indpnd01.mo.comcast.net) |
| 06:40:58 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 06:40:58 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 06:44:28 | | Join LinusN [200] (~linus@labb.contactor.se) |
| 07:00 |
| 07:09:06 | | Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 07:09:54 | | Quit midk (Client Quit) |
| 07:11:04 | | Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 07:11:26 | | Part scott666 |
| 07:20:58 | | Join Strath [0] (~mike@dgvlwinas01pool0-a207.wi.tds.net) |
| 07:21:12 | | Part Strath |
| 08:00 |
| 08:07:01 | *** | Saving seen data "./dancer.seen" |
| 08:11:39 | | Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
| 08:46:49 | | Quit midk ("just STOP it arspy") |
| 08:46:49 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 08:57:12 | | Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 09:00 |
| 09:08:53 | | Quit midk ("just STOP it arspy") |
| 09:12:44 | | Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 09:15:39 | | Quit midk (Client Quit) |
| 09:19:27 | | Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 09:20:54 | | Join midk2k3 [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 09:21:16 | | Nick midk2k3 is now known as idk (~Zakk@c-24-18-39-204.client.comcast.net) |
| 09:21:18 | | Quit midk (Nick collision from services.) |
| 09:21:20 | | Quit midknight2k3 (Nick collision from services.) |
| 09:21:22 | | Nick idk is now known as midk (~Zakk@c-24-18-39-204.client.comcast.net) |
| 09:21:36 | | Join midknight2k3 [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com) |
| 09:27:12 | LinusN | midknight2k3: problems? |
| 09:27:30 | midk | no problems here :] |
| 09:32:03 | | Join amiconn [0] (~jens@pD9E7F944.dip.t-dialin.net) |
| 09:32:26 | amiconn | hi all |
| 09:32:39 | midk | hi amiconn |
| 09:33:58 | amiconn | LinusN: As midk now did his first commits, I wanted to add him to the nick->firstname conversion list. I checked out the whole www module, but couldn't find the "responsible" script... |
| 09:34:46 | midk | as in, i'd appear as "Zakk" isntead of "midk"? |
| 09:34:58 | amiconn | yup |
| 09:35:07 | midk | fine by me |
| 09:38:58 | LinusN | me fix |
| 09:40:06 | * | midk is happy he didn't break the sims at all |
| 09:40:48 | | Join uK|uD-alpha`omeg [0] (~treffmeis@203.214.2.115) |
| 09:41:05 | | Nick uK|uD-alpha`omeg is now known as alpha`omega (~treffmeis@203.214.2.115) |
| 09:41:10 | alpha`omega | hey guys |
| 09:41:17 | midk | hey |
| 09:41:30 | alpha`omega | umm i just made a post in the 'general' newsgroup |
| 09:41:47 | alpha`omega | about the feasibility of creating alternate firmware for another dap |
| 09:41:50 | alpha`omega | the iAudio M3 |
| 09:42:27 | midk | did you have any plans, or were you just suggesting the platform? |
| 09:43:30 | alpha`omega | plans |
| 09:43:32 | alpha`omega | as in, ideas |
| 09:43:36 | alpha`omega | oh yeah :P |
| 09:44:25 | alpha`omega | any of you guys interested? |
| 09:44:46 | DBUG | Enqueued KICK alpha`omega |
| 09:44:46 | alpha`omega | By The Way the iAudio is one of the best players out there in terms of features and capability |
| 09:44:56 | midk | so.. why does rockbox need to run on it? |
| 09:45:08 | midk | i've never heard of it - can it be that good? ;) |
| 09:45:20 | alpha`omega | There are a number of ways in which this potential could be improved |
| 09:45:26 | alpha`omega | ill quote a few off the top of my ehad |
| 09:46:36 | alpha`omega | 1. Instant resume function, like the iPod or iRiver. Eg. The iAudio turns on much quicker when plugged into the wall charger. A certain player – I forget its name – has this function, HOWEVER, it turns completely off after 1 hour, in a similar, power-saving state as the iAudio. This feature would be WELL received – quicker startups during periods of frequent use, BUT still saving power. |
| 09:46:36 | alpha`omega | 2. Option to sort files by ID3 tag – for example, tracks could be sorted by artist, album, track, genre – you name it. The option to turn this off for those who do not like it, however, would be great. |
| 09:46:36 | alpha`omega | 3. “DJ” feature a la Rio Karma – the option to create playlists on the device itself – or at least listings – based on a number of criteria such as: favourites, not played in X days, favourites not played in X days, etc. (See * below for further info) |
| 09:46:38 | alpha`omega | 4. Ability to rate tracks on the device. For example, by holding record, a rating screen could be brought up, or maybe in the form of a pop-up |
| 09:46:41 | alpha`omega | 5. Option to have a smaller font size; the iAudio’s screen is great (4 greys, same width as iPod) and in many opinions, underutilised. On this point, maybe an option to scroll through directories quicker? |
| 09:46:44 | alpha`omega | 6. Is it possible to remove the “Wait” popup which appears when HDD is being accessed? The little [H] icon would do fine by itself. If this popup was not there, other things could be done during periods of access. On this point, is it possible to adjust the read speed of the HDD in the options, like the iRiver? Eg. Quick reading for frequent song changing; slow reading and more battery life when listening to whole tracks. |
| 09:46:49 | alpha`omega | 7. Support for “lossless” audio formats has a smaller, yet still devoted following. Eg. WMA9 Lossless; FLAC; Monkeys Audio |
| 09:46:52 | alpha`omega | 8. I don’t believe it’s important, but lossless playback seems to be followed. |
| 09:46:56 | alpha`omega | and also Musepack (.mpc) |
| 09:46:58 | alpha`omega | and Bookmarking |
| 09:47:04 | alpha`omega | and pretty much all of Rockbox as well |
| 09:47:13 | midk | um, you said it *does* have good features - it sounds as if it needs lots lots lots of things.. |
| 09:47:14 | alpha`omega | http://www.jetaudio.com/forums/showthread.php?t=1785 I am treffmeister |
| 09:47:34 | alpha`omega | soz i meant to say, "it has many good features, but there is potential for more" |
| 09:47:46 | midk | tell me about some current good features..? |
| 09:48:33 | LinusN | alpha`omega: which CPU does iaudio use? |
| 09:49:13 | alpha`omega | throw the name up of the most common one i have a mind blank |
| 09:49:20 | alpha`omega | something 3500 i think |
| 09:49:27 | alpha`omega | 3520 |
| 09:49:44 | alpha`omega | http://www.jetaudio.com/products/iaudio/m3/ and it cops some reviews http://www.jetaudio.com/products/iaudio/m3/reviews.html |
| 09:49:53 | alpha`omega | and there are many people willing to help with the firmware |
| 09:50:04 | alpha`omega | we just need some professionals |
| 09:50:09 | alpha`omega | so i decided to take it to you |
| 09:51:20 | LinusN | alpha`omega: the thing is this: |
| 09:51:27 | alpha`omega | and www.iaudio.com |
| 09:51:28 | alpha`omega | shoot |
| 09:51:40 | LinusN | non of the rockbox developers has an iaudio player |
| 09:51:46 | LinusN | none |
| 09:52:05 | LinusN | and we can't develop on a platform we don't have |
| 09:52:06 | alpha`omega | is that a certain? |
| 09:52:37 | alpha`omega | even so, is it possible for youi guys to even have a days' experimentation? |
| 09:52:40 | alpha`omega | or an hour |
| 09:52:52 | LinusN | we need hands-on dissection |
| 09:53:53 | LinusN | we need lots of hardware information, like schematics, data sheets etc |
| 09:54:26 | LinusN | we need hardware |
| 09:54:27 | alpha`omega | i'm sure iAudio will provide it I will contact them now |
| 09:54:33 | alpha`omega | I have the hardware |
| 09:54:40 | LinusN | yes, you have it, i don't |
| 09:54:46 | alpha`omega | if you ask you may get a test unit |
| 09:54:58 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 09:54:58 | * | midk doubts iAudio would *support* the hacking of it |
| 09:56:39 | LinusN | alpha`omega: but most of all, i need a reason to do it |
| 09:56:56 | alpha`omega | well why did you create the RockBox firmware? |
| 09:57:16 | alpha`omega | Could you at least help us out in terms of deciphering and modifying the firmware? |
| 10:00 |
| 10:00:02 | LinusN | alpha`omega: i created rockbox because i had an archos jukebox |
| 10:00:25 | LinusN | alpha`omega: i can't decipher the firmware if i know nothing about the hardware |
| 10:01:10 | LinusN | at least i need to know which CPU it is |
| 10:01:21 | midk | <alpha`omega> something 3500 i think |
| 10:01:22 | midk | <alpha`omega> 3520 |
| 10:01:29 | LinusN | you seem to think that this is easy |
| 10:03:14 | * | midk likes the fact that he could put a jumping carrot as his boot logo on the iAudio |
| 10:03:16 | midk | :) |
| 10:05:20 | LinusN | sigmatel 3420 |
| 10:06:54 | LinusN | they use different sigmatel chips for the different models |
| 10:07:02 | *** | Saving seen data "./dancer.seen" |
| 10:08:33 | midk | OH |
| 10:08:38 | midk | *rediscovers breakout-4.c |
| 10:10:26 | LinusN | sigmatel has a quite closed architecture, no public data sheets |
| 10:10:45 | midk | hm, LinusN were you ever going to look into that button_repeat_rate function? i recall you saying that it was complicated.. |
| 10:11:35 | LinusN | sort of, yes |
| 10:11:53 | midk | any chance of it being implemented soon? |
| 10:12:36 | LinusN | i think we should export the button_read() function instead |
| 10:12:57 | LinusN | then you can implement thew repeat yourself |
| 10:13:17 | midk | ah, yes, you mentioned that |
| 10:14:09 | midk | so.. would this become something like switch(button_read()) { case BUTTON_LEFT: x−−; break; } ? |
| 10:14:23 | midk | i'll have to see how it's used |
| 10:19:43 | LinusN | all buton_read() does is return the current button status |
| 10:19:58 | midk | what exactly would it return if i pressed F1? |
| 10:20:07 | LinusN | the rest is up to you, using current_tick and TIME_AFTER() etc |
| 10:20:23 | LinusN | it would return BUTTON_F1 |
| 10:21:25 | LinusN | it returns the same values as button_get(), except that it wouldn't set the BUTTON_REL and BUTTON_REPEAT flags |
| 10:22:13 | | Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
| 10:23:54 | midk | hm |
| 10:23:58 | * | midk needs an example |
| 10:24:11 | midk | but so |
| 10:24:24 | midk | switch(button_read()) { case BUTTON_LEFT: x−−; break; } |
| 10:24:26 | | Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net) |
| 10:24:31 | midk | that would work even if it were repeating right? |
| 10:24:32 | midk | hi idc |
| 10:24:49 | [IDC]Dragon | Hi guys and gals |
| 10:25:11 | LinusN | midk: there is no "repeat" since you are reading the buttons directly |
| 10:25:16 | LinusN | [IDC]Dragon: hi |
| 10:25:31 | amiconn | hi [IDC]Dragon |
| 10:25:42 | LinusN | either the button is pushed or it's not |
| 10:26:24 | midk | linusn: but it would work if you did hold the buttons |
| 10:26:35 | midk | instead of returning button_repeat it would keep returning button_left, no? |
| 10:26:49 | LinusN | (sigh) |
| 10:26:50 | alpha`omega | so is there ANY chance whatsoever of you creating some 3rd party stuff for the iAudio if I could obtain the necessary data? |
| 10:26:55 | midk | okay, never mind |
| 10:27:03 | LinusN | it returns the current status of the buttons. period. |
| 10:27:14 | midk | okay |
| 10:27:47 | LinusN | alpha`omega: if i owned an iaudio player, all i can say is "maybe" |
| 10:28:25 | alpha`omega | Okay |
| 10:28:31 | alpha`omega | ill see what they say about a test unit |
| 10:31:20 | amiconn | LinusN, midk: Iiuc, if you use button_read() directly, the button events still queue up in the button queue. |
| 10:31:46 | midk | all i need is a faster repeat rate. |
| 10:33:00 | alpha`omega | Okay i've dispatched an email and the replies are usually pretty speedy. |
| 10:33:28 | amiconn | So the button queue has to be emptied at least before exiting the plugin, otherwise you would get a funny sequence of queued button events after that |
| 10:33:51 | amiconn | LinusN: What happens if the button queue gets full? |
| 10:34:38 | midk | amiconn: by the way.. this occurs in tetris. |
| 10:34:50 | midk | ->funny queued button sequence |
| 10:35:17 | midk | i am coding a rockblox update.. i can fix it there |
| 10:36:59 | [IDC]Dragon | I saw an Xclef 800 at Saturn Hansa |
| 10:37:20 | [IDC]Dragon | I can't say I like it |
| 10:37:49 | [IDC]Dragon | mechanics don't give a quality appeal |
| 10:40:50 | [IDC]Dragon | the "up" button of the pad touched the case when pressed, and this button had no tactile feedback any more |
| 10:41:03 | alpha`omega | I have to agree having used the Xclef myself |
| 10:41:41 | [IDC]Dragon | (same badness with my AJB, the button have an uneven feedback) |
| 10:43:19 | [IDC]Dragon | and the top faceplate of the Xclef is transparent, the kind which gets fingerprints all over |
| 10:44:24 | alpha`omega | like the iPod grrr |
| 10:44:50 | [IDC]Dragon | (the last?) AJB Recorders V2 are sold there for €199 |
| 10:44:57 | alpha`omega | In fact if one exposes the ipod to air, scratches automatically appear on its underside |
| 10:45:08 | alpha`omega | and the iRiver puts the 'box' in Jukebox |
| 10:47:23 | alpha`omega | Okay they can't 'open the source', but is it possible to decompile the firmware? |
| 10:49:21 | [IDC]Dragon | alpha`omega: you seem to underestimate how much effort reverse engineering is |
| 10:49:37 | alpha`omega | enlighten me |
| 10:50:02 | [IDC]Dragon | this would be a very long enumeration |
| 10:50:39 | [IDC]Dragon | is sum, it's probably a year of work |
| 10:51:26 | [IDC]Dragon | in sum |
| 10:52:03 | alpha`omega | can you tell me how to do it and i will do it. |
| 10:52:04 | * | alpha`omega is Back (From:Auto IdleAway after 15 minute(s)) (Gone for:1802wks 4days 8hrs 52mins 6secs) - Invincible |
| 10:52:32 | alpha`omega | thank you |
| 10:52:43 | [IDC]Dragon | alpha`omega: if I need to tell you, you can't do it |
| 10:53:13 | midk | alpha`omega, reverse engineer the firmware. |
| 10:53:28 | alpha`omega | hung? |
| 10:53:37 | alpha`omega | hunh*? |
| 10:53:47 | alpha`omega | can you give me a program, even |
| 10:53:53 | midk | reverse engineer the firmware is what you need to do. |
| 10:54:00 | midk | you have to write one |
| 10:54:02 | alpha`omega | Okay |
| 10:54:14 | alpha`omega | can you please, aven briefly, outline what i need to do? |
| 10:54:22 | midk | not really, no.. |
| 10:54:59 | LinusN | alpha`omega: like [IDC]Dragon said, if we need to tell you how to do it, then you don't have what it takes |
| 10:55:11 | *** | Alert Mode level 1 |
| 10:55:11 | alpha`omega | Okay |
| 10:55:19 | [IDC]Dragon | you need to be into low-level programming and electronics |
| 10:55:50 | alpha`omega | into both |
| 10:56:04 | alpha`omega | C for Palm. and know MUCH about electronics |
| 10:56:26 | LinusN | then open it up, fire up your multimeter, and start drawing schematics |
| 10:56:34 | * | alpha`omega is Away (Reason:Eating...) (Since:18:56:37) (Pager:on) (Logger:off) - Invincible |
| 10:56:34 | | Nick alpha`omega is now known as alpha`omega[away (~treffmeis@203.214.2.115) |
| 10:56:34 | DBUG | Enqueued KICK alpha`omega[away |
| 10:56:34 | *** | Alert Mode level 2 |
| 10:56:41 | alpha`omega[away | (eating |
| 10:56:41 | | Nick alpha`omega[away is now known as alpha`omega (~treffmeis@203.214.2.115) |
| 10:56:41 | DBUG | Enqueued KICK alpha`omega |
| 10:56:41 | *** | Alert Mode level 3 |
| 10:56:41 | LinusN | get the data sheets for the CPU and other chips |
| 10:56:53 | alpha`omega | well that's an unreasonable ask |
| 10:57:06 | alpha`omega | so i can see you guys aren't going to help make the firmware? |
| 10:57:15 | Ctcp | Ignored 3 channel CTCP requests in 7 seconds at the last flood |
| 10:57:15 | * | alpha`omega is Away (Reason:Away) (Since:18:57:18) (Pager:on) (Logger:on) - Invincible |
| 10:57:15 | | Nick alpha`omega is now known as alpha`omega[away (~treffmeis@203.214.2.115) |
| 10:57:15 | DBUG | Enqueued KICK alpha`omega[away |
| 10:57:15 | *** | Alert Mode level 4 |
| 10:57:26 | midk | it's mroe than just making the firmware |
| 10:57:52 | LinusN | why is it unreasonable to take it apart and draw schematics? |
| 10:58:03 | LinusN | that's what we did for the archos |
| 10:58:05 | midk | i think he was referring to the datasheets... |
| 10:58:34 | LinusN | if the data sheets are unavailable, then we are pretty much out of luck |
| 10:59:18 | LinusN | any company that chooses such a closed/secret chipset don't deserve rockbox, imho |
| 11:00 |
| 11:07:16 | *** | Alert Mode OFF |
| 11:17:43 | | Quit alpha`omega[away ("The wheel's spinning but the hamster's gone...") |
| 11:17:43 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
| 11:18:37 | | Nick midk is now known as midk|sleepy (~Zakk@c-24-18-39-204.client.comcast.net) |
| 11:18:50 | midk|sleepy | sleep as in 'sleepy-ing' |
| 11:18:56 | midk|sleepy | :] |
| 11:28:47 | [IDC]Dragon | amiconn: are you there? |
| 11:28:52 | amiconn | yup |
| 11:29:06 | [IDC]Dragon | how's ROMbox? |
| 11:29:35 | amiconn | I did not yet look into it (was on a holiday trip for a week) |
| 11:29:40 | [IDC]Dragon | btw, long tim no see, I thought you're on holidays or so |
| 11:29:44 | [IDC]Dragon | ah |
| 11:30:25 | amiconn | Do you have a collection of bugs/ strange behaviours that occur with rombox? |
| 11:30:36 | [IDC]Dragon | not really |
| 11:30:54 | [IDC]Dragon | the one I encountered is that it refuses to load plugins |
| 11:31:16 | LinusN | amiconn: queue overflow is not handled, so the ring buffer will just wrap around |
| 11:31:38 | [IDC]Dragon | iirc, the open() call failed, to load the plugin as a file |
| 11:31:56 | amiconn | LinusN: Ok, as long as this doesn't overwrite innocent memory |
| 11:32:05 | LinusN | no worries |
| 11:32:30 | amiconn | [IDC]Dragon: I'll look into it, but as you may know I can't use gdb, so it may take a while |
| 11:32:32 | LinusN | we could add a button_clear_queue() |
| 11:33:12 | [IDC]Dragon | amiconn: gdb is useless for debugging within ROM |
| 11:33:25 | amiconn | LinusN: Imho this is unnecessary, since it is as easy as writing: while(rb->button_get(false)) ; |
| 11:33:59 | amiconn | [IDC]Dragon: Ok, so I have no disadvantage from being unable to use it at all ;-) |
| 11:35:07 | amiconn | LinusN: Perhaps it would be useful if the button queue could be switched on and off |
| 11:35:23 | [IDC]Dragon | the plugin version of get_button() could empty the queue in additition, courtesy to the user |
| 11:36:08 | [IDC]Dragon | because if you hable buttons like this, by polling, you're not interested in queue events |
| 11:36:22 | [IDC]Dragon | s/hable/handle |
| 11:38:07 | [IDC]Dragon | button_read(), I mean |
| 11:42:04 | LinusN | [IDC]Dragon: good idea |
| 11:42:29 | LinusN | you must still empty the queue on exit... |
| 11:42:54 | LinusN | that could be done by the plugin framework though |
| 11:43:33 | [IDC]Dragon | I don't remember having seen a plugin emptying the queue on exit |
| 11:44:04 | [IDC]Dragon | if this is mandatory cleanup, the framework should do it |
| 11:44:09 | LinusN | no, but it could be done by the framework |
| 11:44:30 | LinusN | :-) |
| 11:44:45 | LinusN | lunch time |
| 11:50:48 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
| 12:00 |
| 12:07:03 | *** | Saving seen data "./dancer.seen" |
| 12:14:07 | amiconn | [IDC]Dragon: How is your linkage_flash.lds supposed to be used? If I interpret the Makefile correctly, linkage.lds is generated from app.lds. So I have to take out that step, and put linkage_flash.lds into the build dir as linkage.lds? |
| 12:15:17 | amiconn | Btw: linkage_flash.lds is adjusted for the 8 MB mod if I read it correctly |
| 12:26:57 | LinusN | amiconn: i think we have found a victim of the new asm ATA code |
| 12:27:18 | LinusN | https://sourceforge.net/tracker/?func=detail&atid=439118&aid=624697&group_id=44306 |
| 12:36:00 | amiconn | LinusN: This looks like "classic" rld to me |
| 12:38:05 | LinusN | yes, at first glance |
| 12:38:50 | LinusN | but since it has gotten worse, i suspect the optimizations as well, i have sent him a test build with C loops |
| 12:41:02 | amiconn | I'm very interested in the result of this test, since (1) fs corruption wasn't observed on the player so far, (2) this is a Hitachi DK23DA, which is "famous" for rld |
| 12:42:38 | LinusN | absolutely |
| 12:43:05 | amiconn | [IDC]Dragon: Are you around? |
| 12:55:01 | [IDC]Dragon | just got back |
| 12:55:13 | amiconn | [12:14:15] <amiconn> [IDC]Dragon: How is your linkage_flash.lds supposed to be used? If I interpret the Makefile correctly, linkage.lds is generated from app.lds. So I have to take out that step, and put linkage_flash.lds into the build dir as linkage.lds? |
| 12:55:13 | amiconn | [12:15:25] <amiconn> Btw: linkage_flash.lds is adjusted for the 8 MB mod if I read it correctly |
| 12:55:36 | [IDC]Dragon | yes, I have 8 MB |
| 12:56:23 | amiconn | In the meantime I adjusted it to 2 MB and just tried it. Then I have to take rockbox.bin, and uclpack −−none it, right? |
| 12:56:37 | [IDC]Dragon | yes |
| 12:58:28 | [IDC]Dragon | the main issue in making a nice ROM version is to decorate many arrays/structs/etc with "const" |
| 12:58:52 | [IDC]Dragon | Rockbox is almost completely neglecting const |
| 12:59:57 | [IDC]Dragon | because it makes no difference for a RAM version, but if you run from ROM you want to avoid the data being copied to RAM |
| 13:00 |
| 13:00:04 | amiconn | Imho this is the next step after making it work without bugs |
| 13:00:28 | amiconn | Maybe there are some variables declared "const" that are not really const |
| 13:00:37 | [IDC]Dragon | agreed, first we need to find the opposite cases |
| 13:01:07 | amiconn | Btw, tight fit: There are only 9896 bytes of ROM left... |
| 13:01:25 | [IDC]Dragon | not too bad |
| 13:01:40 | | Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
| 13:02:03 | [IDC]Dragon | if this looks promising in general, i'd replace the Archos s/w with a .ajz loader |
| 13:02:16 | amiconn | Different topic: I wonder what the rom-less versions are about - as they have no boot rom, perhaps this is the sh1 variant having 8K of IRAM instead? |
| 13:02:40 | [IDC]Dragon | unfortunately not |
| 13:02:46 | [IDC]Dragon | I tried that |
| 13:04:53 | amiconn | I just flashed my 182K .ucl - it boots correctly. Leaves 1793 KB of buffer |
| 13:05:25 | [IDC]Dragon | it can be more when "const"ing the font, menu, etc. |
| 13:05:54 | [IDC]Dragon | how much was it before? |
| 13:05:58 | amiconn | yup. At first I'll play aroud a bit to see what doesn't work as expected |
| 13:06:16 | [IDC]Dragon | have you tried a plugin? |
| 13:06:21 | amiconn | Iirc the ram version leaves ~1630 KB of buffer |
| 13:06:44 | [IDC]Dragon | 160 kB saved, hmm |
| 13:07:37 | amiconn | (1) Trying to use "View HW info" from the debug menu hangs the box |
| 13:08:04 | [IDC]Dragon | because it queries the flash ID |
| 13:08:23 | amiconn | I suspected that; this has to be skipped when running from flash |
| 13:08:40 | [IDC]Dragon | yes, we need a #define |
| 13:09:17 | [IDC]Dragon | or a runtime flag |
| 13:09:32 | LinusN | or run the code in RAM |
| 13:09:54 | [IDC]Dragon | hmm, and disable the interrupts meanwhile? |
| 13:09:57 | LinusN | yes |
| 13:10:32 | LinusN | still, the flash plugin will be a tough one |
| 13:10:40 | [IDC]Dragon | ;-) |
| 13:11:02 | [IDC]Dragon | I woudn't mind to run the .ajz first |
| 13:11:03 | amiconn | [IDC]Dragon: Good news - plugins can be started without problems |
| 13:11:52 | [IDC]Dragon | maybe I was const'ing too much then |
| 13:12:27 | [IDC]Dragon | when I played with that variant, I plastered "const" all over the place, to see how much I can get |
| 13:13:27 | amiconn | I just took current cvs (only deviation being my "geek mode" bitswap) and linked with linkage_flash.lds |
| 13:14:42 | [IDC]Dragon | you can make an IRAM function out of dbg_flash_id() |
| 13:15:09 | [IDC]Dragon | add the interrupt disable to it, take out the sleep()'s |
| 13:15:49 | [IDC]Dragon | (only Atmel requires them, and no box has Atmel flash) |
| 13:17:13 | amiconn | Playback seems to work correctly as well |
| 13:19:32 | [IDC]Dragon | you can make a test build for a wider audience |
| 13:19:54 | [IDC]Dragon | so you don't have to do all the testing yourself |
| 13:19:58 | amiconn | Current ram based rockbox leaves 1.630 MB of buffer, so the gain is 0.163 MB or almost 167 KB |
| 13:20:18 | [IDC]Dragon | it's a nice start, I'd say |
| 13:20:34 | amiconn | How much more free ram did you get with const'ing everything? |
| 13:20:58 | [IDC]Dragon | embarrasing, but I don't remember |
| 13:21:11 | amiconn | np |
| 13:21:44 | [IDC]Dragon | LinusN: what larger data structures do we have? |
| 13:22:01 | LinusN | what do you guys say, is there enough reason to be able to select the priority of ID3v1 and ID3v2 tags? |
| 13:22:03 | [IDC]Dragon | to my mind comes font, menus, plugin table |
| 13:22:18 | LinusN | id3 tag table |
| 13:22:52 | amiconn | It seems that rockbox runs a bit slower from ROM |
| 13:23:23 | [IDC]Dragon | that's understandable, the flash is 8 bit wide |
| 13:23:36 | [IDC]Dragon | but I didn't notice a difference |
| 13:23:50 | [IDC]Dragon | since the action code is mostly in IRAM |
| 13:24:55 | amiconn | The difference is actually small, and not noticeable with normal usage. The grayscale.rock runs ~0.81s with rockbox in ram, and 0.82..0.83s with rockbox in rom |
| 13:25:41 | [IDC]Dragon | I was talking about the feel of the box |
| 13:26:21 | [IDC]Dragon | that was even below your 3% ;-) |
| 13:27:47 | amiconn | Talking menus and talkbox works as well |
| 13:27:52 | amiconn | *work |
| 13:29:11 | [IDC]Dragon | and the voice file can be 167 KB larger |
| 13:33:52 | [IDC]Dragon | it is left to be tested if the ROM version actually improves runtime |
| 13:34:07 | amiconn | yup |
| 13:34:56 | amiconn | playing the same dir over and over again, measuring runtime |
| 13:35:11 | amiconn | Same would go for video playback |
| 13:36:19 | [IDC]Dragon | video playback doesn't run much ROM code |
| 13:36:31 | [IDC]Dragon | but benefits from larger buffer |
| 13:36:54 | [IDC]Dragon | LinusN: the credits should be const |
| 13:37:38 | [IDC]Dragon | the settings tables |
| 13:37:56 | amiconn | I'll look into const'ing after doing some runtime test (just started charging my box) |
| 13:38:07 | amiconn | *tests |
| 13:38:33 | amiconn | Perhaps I should use low capacity cells for the runtime tests... |
| 13:38:56 | [IDC]Dragon | or an ampere meter |
| 13:39:09 | [IDC]Dragon | with PC readout |
| 13:40:16 | [IDC]Dragon | more const: mp3 sound setting tables (not that big) |
| 13:40:54 | [IDC]Dragon | searching for [] finds many initialized arrays |
| 13:41:42 | amiconn | I prefer real world data - using an amp meter, I'd have to measure with a high time resolution |
| 13:42:02 | [IDC]Dragon | LinusN: are the language strings overloaded by .lng file content? |
| 13:42:30 | | Quit midk|sleepy (Read error: 104 (Connection reset by peer)) |
| 13:42:47 | LinusN | yes |
| 13:42:59 | LinusN | (i think) |
| 13:43:06 | [IDC]Dragon | then this is no const |
| 13:43:34 | amiconn | Just found a 4-set of 1200 mAh NiMH cells - will use that for measurement, and charge them in an external charger |
| 13:44:01 | [IDC]Dragon | that test will take a while... |
| 13:44:46 | [IDC]Dragon | how do you determine when it shut down? |
| 13:45:01 | [IDC]Dragon | you're not watching it, right? |
| 13:45:07 | amiconn | debug->view runtime |
| 13:45:31 | [IDC]Dragon | ah, that's what this is for |
| 13:45:34 | amiconn | Btw, is there a way to reset the top runtime? |
| 13:45:44 | [IDC]Dragon | reset the settings |
| 13:45:51 | amiconn | Ah ok |
| 13:52:25 | amiconn | "Monsters" in .data (data blocks larger thatn 256 bytes): |
| 13:54:28 | amiconn | (difficult to find, since not all of them have a public symbol) |
| 13:54:57 | [IDC]Dragon | the menus are many small ones, but still worth it |
| 13:55:38 | amiconn | language_strings, credits, rockbox logo, icons, sysfont |
| 13:56:20 | [IDC]Dragon | the logo, ah, yes |
| 13:56:24 | amiconn | The quoted strings should be const automatically |
| 13:57:10 | [IDC]Dragon | as discussed, the language strings are probably overloaded |
| 13:57:23 | [IDC]Dragon | have you tried a .lng file? |
| 13:57:38 | [IDC]Dragon | or are you running german anyway? |
| 13:57:53 | amiconn | I'm running German, yes |
| 13:58:32 | amiconn | Currently the language strings are not declared const (I looked into rockbox.map what ended up in the data section) |
| 14:00 |
| 14:02:03 | amiconn | I wonder if it is possible to declare an array in such a way that the array data itself is considered const, while the array variable itself (= the pointer) is not |
| 14:04:53 | amiconn | (without declaring an extra variable, that is) |
| 14:05:35 | LinusN | the array "variable" is not a pointer, it's a symbol |
| 14:07:04 | *** | Saving seen data "./dancer.seen" |
| 14:08:54 | amiconn | LinusN: If I declare char blah[] = "foobar"; blah[0] is equivalent to *blah , so blah is a pointer, or did I miss something? |
| 14:09:32 | LinusN | it is not equivalent |
| 14:09:55 | LinusN | if blah was a pointer, you could do this: |
| 14:10:06 | LinusN | bla = 0; |
| 14:10:11 | LinusN | but you can't |
| 14:10:37 | LinusN | a common mistake in C is to confuse arrays for pointers |
| 14:11:50 | amiconn | Ok. How come the compiler warns me if I do the following: |
| 14:12:32 | amiconn | const char blah[] = "foobar"; char *ptr; ......... ; ptr = blah; |
| 14:12:52 | amiconn | while if I leave out the "const", it doesn't warn? |
| 14:13:21 | amiconn | (iirc) |
| 14:14:16 | LinusN | maybe because blah[] is an array of constant chars, while ptr is a pointer to non-constant chars? |
| 14:15:14 | amiconn | That may be the point, but if I declare const char *ptr; the pointer itself might end up in .rodata? |
| 14:15:49 | LinusN | probably not |
| 14:16:08 | LinusN | if you declare it char * const ptr, it will |
| 14:16:12 | amiconn | It should be possible to do this if we want to gain some more ram space when running from rom |
| 14:16:39 | LinusN | or maybe char const * ptr... |
| 14:17:38 | amiconn | I think I'll have to try it out. |
| 14:17:56 | LinusN | are you trying to put the lang strings in ROM? |
| 14:18:26 | amiconn | This goes for the default lang strings as well as for the rockbox logo, the sysfont... |
| 14:19:51 | LinusN | is the logo a problem? |
| 14:19:52 | | Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 14:21:20 | amiconn | I'll look into it after doing some runtime tests, but I remember that you once changed convbdf to declare the sysfont const |
| 14:21:29 | amiconn | This lead to a number of warnings... |
| 14:23:24 | LinusN | yeah, the sysfont is rotated at boot |
| 14:24:39 | amiconn | Argh, then either it can't be declared const, or it has to be rotated at compile time |
| 14:26:11 | amiconn | (Should have remembered that, since I fiddled with font.c when changing lcd_bitmap() ) |
| 14:27:24 | [IDC]Dragon | aargh, rotation is no good |
| 14:29:24 | [IDC]Dragon | (for const) |
| 14:31:41 | amiconn | Iirc the fonts are in a somewhat standard (miniwin?) format on disk, while they have to be in the rockbox native bitmap format in ram |
| 14:32:26 | [IDC]Dragon | from disk to RAM is a different story |
| 14:33:05 | [IDC]Dragon | but it would be good if the system font, which we never kick out, can be directly used from ROM. |
| 14:33:13 | amiconn | convbdf delivers the same format as a source code array when converting the sysfont at compile time |
| 14:33:43 | amiconn | I think this could be changed to deliver an already rotated array |
| 14:42:19 | LinusN | sure |
| 14:52:18 | lImbus | amiconn: I just read you are using debug->runtime. I remember having seen the setting in the past with a short unsigned => wrap at 9 hours. has it changed in the meantime ? |
| 14:52:18 | | Quit AciD` (Read error: 104 (Connection reset by peer)) |
| 14:52:31 | | Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 14:53:34 | LinusN | lImbus: should be 18 bits |
| 14:53:54 | amiconn | lImbus: [IDC]Dragon reported that while writing the new settings code; I always wondered what this was about, since I couldn't observe a wrap |
| 14:54:06 | [IDC]Dragon | now it is 18 |
| 14:54:18 | lImbus | 18 ought to be enough ;-) |
| 14:54:51 | [IDC]Dragon | 3 days |
| 14:54:51 | lImbus | 72 hours. |
| 14:55:02 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 14:55:02 | * | lImbus wants to see these batteries |
| 14:55:03 | amiconn | The thing is that I didn't observe a wrap even with the old settings code, and I did get runtimes >10 h. Weird |
| 14:56:18 | amiconn | (Perhaps not, since unsigned short is sufficient for >18 h) |
| 15:00 |
| 15:03:13 | [IDC]Dragon | amiconn: did you notice how fast the logo appears if you run from ROM? :-) |
| 15:03:38 | [IDC]Dragon | (and maybe even faster once it's const) |
| 15:04:10 | amiconn | Yeah... no decompression necessary |
| 15:08:13 | elinenbe | amiconn, [IDC]Dragon, LinusN: is the benefit or rombox just to increase the MP3 buffer, or could the plugin/voicebox/JPEG/movie buffer be increased as well? Also, what happens if the firmware outgrows the ROM on the system? |
| 15:09:10 | amiconn | elinenbe: The mp3 buffer is used for the voice file and video playback as well, so these do benefit from rombox |
| 15:09:40 | amiconn | The plugin buffer is declared fixed, so it doesn't make a difference for plugins |
| 15:09:59 | [IDC]Dragon | and if we're out of ROM space, we have to either save or kick out the Archos s/w |
| 15:11:11 | [IDC]Dragon | for the FM, we're out of space for this kind already |
| 15:13:47 | lImbus | there could be an emergency rockbox where the archos s/w is at the moment |
| 15:14:26 | amiconn | ...or an .ajz loader, as [IDC]Dragon suggested |
| 15:15:42 | [IDC]Dragon | but we need to fix the charging for such |
| 15:16:02 | lImbus | does everybody understand the need of that file then ? (i've seen many people deleting files not needed until they reach msdos.sys) |
| 15:16:07 | amiconn | declaring the logo const saves 560 bytes, but leads to a warning when compiling main_menu.c: |
| 15:16:30 | [IDC]Dragon | currently, F1+Plugin is the workaround for starting with flat batteries |
| 15:16:32 | lImbus | if it's gone, there is no way (for noobs) to get it there when they NEED it. |
| 15:16:50 | amiconn | main_menu.c:72: warning: passing arg 1 of `lcd_bitmap' discards qualifiers from pointer target type |
| 15:17:17 | amiconn | lImbus: Of course the .ajz loader should be able to handle usb detection as well |
| 15:17:27 | [IDC]Dragon | amiconn: you will find lots of these when const'ing stuff |
| 15:18:09 | [IDC]Dragon | some follow-up work on the pointers using const arrays |
| 15:18:12 | amiconn | [IDC]Dragon: I know that these come up, so I have to find a way to avoid them. |
| 15:18:23 | [IDC]Dragon | they also need to be const |
| 15:19:42 | amiconn | I always wondered why some pointer arguments to functions are declared const ... it seems that I just understood the reason |
| 15:20:06 | [IDC]Dragon | you will be themaster of const very soon |
| 15:20:13 | | Join Strath [0] (~mike@dgvlwinas01pool0-a207.wi.tds.net) |
| 15:20:13 | amiconn | ;-) |
| 15:20:56 | [IDC]Dragon | notice the difference between a constant pointer versus a pointer to contant data |
| 15:21:54 | [IDC]Dragon | reading the declaration in reverse is a good way to understand it |
| 15:22:22 | Strath | just uploaded a little bit of an update to http://www.donat.org/archos/ |
| 15:22:26 | [IDC]Dragon | hi Strath, how's the Gmini? |
| 15:23:15 | amiconn | [IDC]Dragon: So a pointer to constant data (that's what I need most of the time) is declared "const char *ptr", while a constant pointer is declared how? |
| 15:24:51 | Strath | not too bad dragon, there is now three people working on it, and we're moving forward again |
| 15:25:14 | [IDC]Dragon | I think: char * const ptr |
| 15:25:48 | Strath | but i've only had 2 * 3 hours of sleep in the last 72 hours... it's *really* time for bed |
| 15:25:50 | [IDC]Dragon | read it in reverse: ptr is a constant pointer to a char |
| 15:26:21 | | Quit Strath ("Client closed") |
| 15:26:44 | [IDC]Dragon | versus in your first example ptr is a pointer to a char which is constant |
| 15:33:42 | amiconn | So I think all pointer arguments to functions which do not change the data the pointer points to should be changed into pointers to const data |
| 15:33:56 | amiconn | First one will be lcd_bitmap() |
| 15:41:53 | amiconn | Grr, this involves changes in 6 files |
| 15:48:17 | amiconn | It works! :)) |
| 15:48:36 | [IDC]Dragon | congratulations! |
| 15:49:20 | [IDC]Dragon | you may need to touch many files, this is true |
| 15:49:25 | amiconn | I face the job of wading through the source, looking for pointer arguments that should be const'ed |
| 15:49:48 | [IDC]Dragon | true, my friend |
| 15:50:06 | LinusN | have a nice evening :-) |
| 15:50:32 | * | [IDC]Dragon calls the const police |
| 15:51:05 | amiconn | I think I'll take the challenge... expect me to gradually commit my changes |
| 15:51:27 | [IDC]Dragon | you're most welcome |
| 15:51:39 | amiconn | (actually const'ing the logo "only" requires changing 5 files) |
| 15:52:25 | amiconn | icons.c, icons.h, lcd-recorder.c, plugin.h and lcd.h |
| 15:53:13 | [IDC]Dragon | I did this in a sloppy way before, but discarded my changes |
| 15:53:52 | LinusN | gotta go, cu around |
| 15:53:59 | amiconn | bye lImbus |
| 15:54:04 | amiconn | oops I mean LinusN |
| 15:54:05 | [IDC]Dragon | cu LinusN |
| 15:54:05 | LinusN | :-) |
| 15:54:11 | | Part LinusN |
| 15:54:20 | [IDC]Dragon | too early tab completion |
| 15:54:25 | amiconn | yup |
| 15:54:49 | [IDC]Dragon | I'm "angry" about lImbus' nick, too |
| 15:55:55 | [IDC]Dragon | amiconn: we're prepared for some colorful builds ;-) |
| 15:56:31 | amiconn | Usually I test my changes locally before committing (at least player/recorder and the respective sims) |
| 15:56:49 | [IDC]Dragon | the sims usually kill me |
| 15:57:14 | [IDC]Dragon | and a warning is easily overlooked |
| 15:57:19 | amiconn | Another challenge will be extending the configure script and Makefile to easily allow for rombox builds |
| 15:57:33 | [IDC]Dragon | (no color in my bash console) |
| 15:58:03 | [IDC]Dragon | sounds like a job for Daniel |
| 15:58:06 | amiconn | I usually compile with make >make.log, so all informative output will go to that file. Only warnings and errors show up in the console |
| 15:58:26 | [IDC]Dragon | ah, good hint |
| 15:58:59 | amiconn | You could also use make >/dev/null (didn't try that within cygwin though) |
| 16:00 |
| 16:00:06 | amiconn | 1.794 MB buffer :) |
| 16:00:20 | [IDC]Dragon | the start address for the build is currently hard-coded, as you know |
| 16:01:00 | [IDC]Dragon | 1KB gained, hoorray! |
| 16:01:05 | amiconn | Yes... we'll have to find a way how to change that (or make it really constant) |
| 16:03:06 | amiconn | The total size of the .data segment is ~11 KB, so that's the upper limit of possible gain |
| 16:03:15 | [IDC]Dragon | oooh |
| 16:03:25 | [IDC]Dragon | no more? |
| 16:03:42 | [IDC]Dragon | have you done the credits? |
| 16:04:09 | amiconn | Not yet, only the logo (as first exercise) |
| 16:04:59 | [IDC]Dragon | credits are >1KB |
| 16:06:12 | amiconn | Code is ~150 KB, rodata ~17 KB |
| 16:07:06 | *** | Saving seen data "./dancer.seen" |
| 16:08:25 | [IDC]Dragon | I'm not sure which parts get into ROM without being const |
| 16:08:45 | [IDC]Dragon | maybe the credits do |
| 16:09:22 | [IDC]Dragon | the plugin API table has >100 entries, so >400 bytes |
| 16:11:53 | [IDC]Dragon | the ID3 genres are already const, for a change |
| 16:12:10 | amiconn | The credit strings seem to go into rom by default, since credits take up 324 bytes in the data sections, which equals to 81 pointers |
| 16:12:23 | amiconn | *section |
| 16:12:34 | [IDC]Dragon | the pointers don't, aha |
| 16:15:33 | amiconn | grr, another function that needs a const * argument: lcd_putsxy() |
| 16:22:05 | amiconn | Credits pointers now in rom; credits still work... |
| 16:26:42 | amiconn | In fact, I had to write const char* const credits[] = ... to get the pointer array into rom |
| 16:36:02 | amiconn | sysfont is almost 4 KB |
| 16:45:00 | [IDC]Dragon | sorry, I was afk |
| 16:46:23 | [IDC]Dragon | font needs to be rotated, hmm, this doesn't come so easy |
| 16:46:44 | amiconn | I know, just fiddling with the icons |
| 16:47:08 | [IDC]Dragon | the menus are another candidate |
| 16:47:23 | amiconn | playlist_viewer.c doesn't use icons.h but declares bitmap_icons_6x8 by itself, urgs |
| 16:48:07 | [IDC]Dragon | once you const the menu function argument, the compiler will tell you where to change the menu struct arrays |
| 16:48:17 | amiconn | In fact, it does include icons.h |
| 16:48:55 | | Join dstar5 [0] (lee@ACC751AA.ipt.aol.com) |
| 16:48:57 | amiconn | (why it does declare bitmap_icons_6x8 again is beyond me) |
| 16:49:23 | [IDC]Dragon | sorry, I'm not following (and not trying to) |
| 16:54:20 | amiconn | bitmap_icons_6x8 is declared in icons.h. Both playlist_viewer.c and tree.c did include icons.h, and the declared bitmap_icons_6x8 again |
| 17:00 |
| 17:06:51 | | Nick lImbus is now known as _lImbus (~manuel@kernel.cycos.net) |
| 17:08:19 | [IDC]Dragon | have to leave now, cu later |
| 17:08:33 | | Quit [IDC]Dragon ("no fate but what we make") |
| 17:11:18 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
| 17:14:42 | | Nick tomsleep is now known as kaboofa (~kaboofa@pcp03462569pcs.indpnd01.mo.comcast.net) |
| 17:18:44 | dstar5 | hey kaboof! |
| 17:18:56 | kaboofa | what's up :) |
| 17:20:26 | kaboofa | yeah, i am convinced i have the best keyboard in the history of keyboards :) |
| 17:20:33 | kaboofa | Old old IBM model from 1984 |
| 17:20:36 | kaboofa | no windows |
| 17:20:37 | kaboofa | key |
| 17:20:39 | kaboofa | :D :D :D |
| 17:20:49 | kaboofa | and it's mechanical, so I can hold down like 18 keys all at the same time |
| 17:20:53 | kaboofa | and they all get registered |
| 17:26:50 | | Join Lee_ [0] (lee@ACC31159.ipt.aol.com) |
| 17:27:18 | | Quit dstar5 (Nick collision from services.) |
| 17:27:29 | | Nick Lee_ is now known as dstar5 (lee@ACC31159.ipt.aol.com) |
| 17:38:59 | dstar5 | kaboofa cool keyboard :) i missed your text, my internet conection failed |
| 17:39:25 | kaboofa | heh |
| 17:39:48 | * | dstar5 hates AOL very very much |
| 17:39:51 | kaboofa | heh |
| 17:39:55 | * | kaboofa <3s speakeasy dsl |
| 17:40:30 | dstar5 | heh the local university (OSU) has way faster than a dsl |
| 17:40:40 | dstar5 | i have been downlading at 100mbits |
| 17:40:47 | dstar5 | :) |
| 17:40:57 | dstar5 | the fastest the nic can handle |
| 17:49:04 | kaboofa | heh |
| 17:49:12 | kaboofa | i have a server on a oc 48 :D |
| 17:49:15 | kaboofa | an |
| 17:51:54 | dstar5 | 2.488 Gbps |
| 17:51:56 | dstar5 | nice |
| 17:52:12 | dstar5 | to bd you can not download at that speed anywhere :( |
| 17:52:39 | dstar5 | unless you are downloading right next to the server |
| 17:52:39 | dstar5 | lol |
| 17:56:41 | dstar5 | how much do those lines cost a month? |
| 17:56:52 | amiconn | Grr, I don't understand why the filetypes mechanism doesn't work when running from ROM |
| 18:00 |
| 18:07:09 | *** | Saving seen data "./dancer.seen" |
| 18:22:09 | | Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net) |
| 18:22:09 | | Quit Nibbler (Read error: 104 (Connection reset by peer)) |
| 18:30:43 | _lImbus | hi midk |
| 18:31:02 | midk | hi _lImbus |
| 18:32:59 | _lImbus | uhm. can't link the new alternate nick to the primary one... |
| 18:33:19 | midk | alternate nick? |
| 18:33:24 | _lImbus | _lImbus: |
| 18:33:29 | midk | link? |
| 18:34:10 | dstar5 | you want to be lImbus? |
| 18:34:21 | _lImbus | http://freenode.net/faq.shtml |
| 18:34:28 | _lImbus | I am lImbus |
| 18:34:31 | midk | do /nick lImbus |
| 18:34:47 | _lImbus | [IDC]-Dragon has some problems with that nick, too similar to LinusN |
| 18:35:01 | midk | ahh |
| 18:35:10 | _lImbus | lImbus is registered, I want to link _lImbus to lImbus |
| 18:35:17 | midk | just re-register. |
| 18:35:18 | _lImbus | like described in faq |
| 18:36:28 | _lImbus | ahh tnx, worked |
| 18:36:53 | _lImbus | reregistering before linking was not logical to me, and was not explained in faq |
| 18:36:56 | _lImbus | tnx |
| 18:37:05 | midk | you don't have to link it... |
| 18:37:08 | midk | but np. |
| 18:37:45 | _lImbus | I linked them together, so I suppose there is only one memo-account e.g. |
| 18:38:03 | midk | good job. |
| 18:38:19 | midk | but if you usually come in as _lImbus then people will just memo that one. |
| 18:38:32 | midk | :D |
| 18:39:41 | _lImbus | to how did you send that memo ? I got a query from memoserv, so the correlation is set up |
| 18:39:50 | midk | :D |
| 18:39:54 | midk | i send it to you.. |
| 18:39:55 | midk | oh sec |
| 18:40:18 | midk | sent one to lImbus |
| 18:40:28 | midk | yay |
| 18:42:23 | _lImbus | don't you use opera as irc-client too ? |
| 18:42:44 | dstar5 | me use xchat |
| 18:42:47 | midk | no no |
| 18:42:48 | midk | xchat |
| 18:42:52 | midk | xchat good. |
| 18:43:26 | _lImbus | ok. must have been either zeekoe or kaboofa (kaboofa_) then |
| 18:43:57 | midk | probably zeekoe.:p |
| 18:51:50 | | Join Bazi [0] (~Baz@80.229.144.229) |
| 19:00 |
| 19:24:32 | | Quit Ka_ (sterling.freenode.net irc.freenode.net) |
| 19:24:32 | NSplit | sterling.freenode.net irc.freenode.net |
| 19:24:32 | | Quit elinenbe (sterling.freenode.net irc.freenode.net) |
| 19:25:05 | dstar5 | netsplit :( |
| 19:25:11 | midk | ooh, really? |
| 19:25:52 | dstar5 | yes actauly |
| 19:25:56 | NHeal | sterling.freenode.net irc.freenode.net |
| 19:25:56 | NJoin | Ka_ [0] (~tkirk@pcp04776551pcs.howard01.md.comcast.net) |
| 19:25:56 | NJoin | elinenbe [0] (trilluser@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 19:26:10 | dstar5 | yay |
| 19:26:10 | dstar5 | :) |
| 19:38:59 | | Join zeekoe [0] (~zeekoe@ip51cc69f6.adsl-surfen.hetnet.nl) |
| 19:46:40 | | Join mexi` [0] (Tommy@ip94.130.1511G-CUD12K-03.ish.de) |
| 19:46:49 | mexi` | hallo? anybody there? |
| 19:47:06 | midk | hi. |
| 19:47:27 | mexi` | i have a problem with my jukebox... it always says "HD error" when i try to start it |
| 19:47:40 | mexi` | do you know any help? |
| 19:48:01 | midk | is your hd dead? |
| 19:48:15 | mexi` | i hope it's not, but i can't tell... |
| 19:48:43 | midk | funny noises? |
| 19:48:44 | midk | lack of noises? |
| 19:49:11 | mexi` | these clicks, when i put the usb in it |
| 19:49:21 | midk | odd clicks? |
| 19:49:28 | midk | sounds like a mechanical problem.. |
| 19:49:28 | mexi` | yes |
| 19:49:35 | midk | as in, hard drive failure.. |
| 19:50:18 | mexi` | i had the same noises when the batteries where empty. after loading them, the noises where gone |
| 19:51:25 | mexi` | is there anything there that would help if it was a hard drive failure? |
| 19:51:33 | midk | doubtful... |
| 19:51:39 | midk | be back soo |
| 19:51:41 | midk | n |
| 19:51:44 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 19:51:45 | mexi` | hmm... |
| 19:52:46 | dstar5 | can yo plug in USB? |
| 19:53:02 | | Quit Bazi (Remote closed the connection) |
| 19:53:06 | dstar5 | ahh clicks... |
| 19:53:15 | dstar5 | is this a player/studio unit? |
| 19:54:14 | kaboofa | uh oh |
| 19:54:17 | kaboofa | clicks |
| 19:54:32 | dstar5 | it may be dead batteries... |
| 19:54:39 | kaboofa | WHOO!! MY DRAGON LEVELD UP!!! |
| 19:54:46 | kaboofa | YEAH!!! |
| 19:54:50 | kaboofa | <3 <3 <3 |
| 19:54:59 | kaboofa | yes kids, drakengard = addiction |
| 19:55:15 | | Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
| 19:55:25 | kaboofa | chapter 4: betrayal |
| 19:55:36 | zeekoe | ayreon? |
| 19:55:56 | kaboofa | eh? |
| 19:56:08 | zeekoe | :P |
| 19:56:15 | dstar5 | mexi`: are you there? |
| 19:56:22 | kaboofa | oh |
| 19:56:25 | zeekoe | nah... that's day15-betrayal |
| 19:56:29 | kaboofa | i hope i get this chaos dragon thingie |
| 20:00 |
| 20:01:58 | | Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 20:06:41 | dstar5 | yo scott666 |
| 20:07:13 | *** | Saving seen data "./dancer.seen" |
| 20:18:09 | | Part mexi` |
| 20:27:18 | | Quit zeekoe (Read error: 110 (Connection timed out)) |
| 20:28:50 | scott666 | hey diddy |
| 20:45:37 | dstar5 | bye |
| 20:45:39 | | Quit dstar5 ("Leaving") |
| 20:59:23 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
| 21:00 |
| 21:03:19 | kaboofa | bah |
| 21:03:29 | kaboofa | just burned the hell out of my finger because of my sodering iron |
| 21:05:41 | midk | good work! |
| 21:06:30 | elinenbe | amiconn: how is rombox going? |
| 21:07:05 | amiconn | The dynamic filetypes mechanism doesn't work when romboxed - I'm just splash-debugging it |
| 21:09:31 | amiconn | If I get that bug squashed, I'll provide a test version for those who are willing to help me finding the remaining bugs |
| 21:09:53 | amiconn | Unfortunately this is currently only possible with the recorder v1 |
| 21:16:51 | | Join OPP89 [0] (~dshier89@adsl-68-255-21-48.dsl.emhril.ameritech.net) |
| 21:16:55 | OPP89 | hello |
| 21:18:28 | | Join [IDC]Dragon [0] (~idc-drago@pD95120CC.dip.t-dialin.net) |
| 21:18:33 | amiconn | hi Jörg |
| 21:18:50 | [IDC]Dragon | hi Jens |
| 21:19:00 | amiconn | Did you read the logs? |
| 21:19:23 | [IDC]Dragon | a bit |
| 21:19:59 | | Quit AciD` (Remote closed the connection) |
| 21:20:32 | amiconn | I wonder why the filetypes mechanism doesn't work when romboxed. Just found that the file open for the viewers.config fails (-4) |
| 21:21:07 | [IDC]Dragon | maybe this is like the file open I was remembering? |
| 21:21:37 | amiconn | Yes, maybe. I have to find out why this open fails, while others seem to work |
| 21:23:02 | [IDC]Dragon | back in time we didn't have the dynamic file types |
| 21:23:35 | | Quit midk ("just STOP it arspy") |
| 21:23:35 | [IDC]Dragon | maybe some path/name is tried to modify, while being in ROM |
| 21:23:54 | [IDC]Dragon | is that all you've found? |
| 21:25:23 | amiconn | Until now, yes. I stopped const'ing things when I found that, suspecting my changes causing it. However, this occurs with plain cvs too. |
| 21:25:37 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 21:26:20 | [IDC]Dragon | then I guess you can commit what you've done so far |
| 21:29:19 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
| 21:29:20 | amiconn | -4 means open() couldn't open the dir, and the open function tampers with the path/filename strings, while declaring it const char * (!) Argh!!!! |
| 21:32:50 | amiconn | I wonder if the argument declaration for open() is an ANSI requirement - if yes, the open function would need an internal buffer for copying the string, what in turn would impose a length limit |
| 21:37:44 | [IDC]Dragon | open() is POSIX, not ANSI |
| 21:39:53 | amiconn | Still I need to know if the "const" in open(const char *pathname, int flags); is a standards requirement |
| 21:40:04 | [IDC]Dragon | hang on |
| 21:41:04 | amiconn | Same goes for creat(), remove() and rename() |
| 21:41:59 | amiconn | All these use open(), and open tampers with the string in a way that it temporarily replaces the last "/" with a "\0" to separate path and filename |
| 21:42:34 | [IDC]Dragon | for walking the dirs, I remember |
| 21:42:51 | amiconn | For the opendir() call, yes |
| 21:42:52 | | Part _lImbus |
| 21:43:18 | [IDC]Dragon | see this: http://cplus.kompf.de/posixlist.html#ToC1 |
| 21:43:53 | [IDC]Dragon | open takes a const argument |
| 21:44:34 | amiconn | So if we want to retain posix compatibility (and I guess we want to do that), the open function has to copy the pathname internally |
| 21:45:05 | [IDC]Dragon | and only the open() calls with a fixed neme file, correct? |
| 21:45:30 | [IDC]Dragon | mp3 playback works because the names are dynamically composed? |
| 21:45:43 | amiconn | Yes, as well as the plugin loading. |
| 21:46:04 | [IDC]Dragon | with a fixed name fail, I mean |
| 21:46:26 | | Quit OPP89 (Read error: 104 (Connection reset by peer)) |
| 21:47:11 | [IDC]Dragon | we can peek at OpenNeo, if and how they changed it |
| 21:47:25 | [IDC]Dragon | the Neo runs from ROM |
| 21:47:25 | | Quit AciD (Read error: 54 (Connection reset by peer)) |
| 21:49:08 | [IDC]Dragon | which code are you looking at? |
| 21:49:18 | amiconn | Funny enough, opendir(), which does need to separate the path components further, does copy the string internally. |
| 21:49:34 | amiconn | firmware/common/file.c |
| 21:49:40 | amiconn | and dir.c |
| 21:50:11 | amiconn | The problematic call comes from apps/filetypes.c, line 446 |
| 21:50:38 | amiconn | fd == -4 after that |
| 21:50:57 | amiconn | (when running from ROM of course) |
| 21:51:29 | [IDC]Dragon | quite obvious, yes |
| 21:51:56 | [IDC]Dragon | nice dagnosis, wee done! |
| 21:52:00 | [IDC]Dragon | well |
| 21:52:16 | [IDC]Dragon | I type like drunk today |
| 21:52:18 | amiconn | Splash debugging :-| |
| 21:52:40 | [IDC]Dragon | flash debugging |
| 21:52:47 | amiconn | http://www.ssiamerica.com/open/ ==> DB Error: unknown error :( |
| 21:53:50 | [IDC]Dragon | is this the official location? |
| 21:55:27 | amiconn | At least it seems to be. http://www.ssiamerica.com/ talks about the neo itself; if you click on "Open neo" this dir gets called. http://www.ssiamerica.com/open/binaries/ works, but these are only the binaries. |
| 21:55:45 | amiconn | It seems that OpenNeo isn't that open :-/ |
| 21:55:56 | [IDC]Dragon | definitely not |
| 21:56:16 | [IDC]Dragon | that was subject of many discussions |
| 21:58:15 | [IDC]Dragon | amiconn: I think an extra buffer for open(), etc. is no problem |
| 21:58:27 | [IDC]Dragon | we have a length limit anyway |
| 21:58:55 | amiconn | Yes, MAX_PATH. I already found that |
| 21:59:38 | [IDC]Dragon | or we make sure that a filename never comes from ROM |
| 22:00 |
| 22:00:14 | amiconn | I wonder if a simple declaration of a string of that length may overflow the stack (however, this is done within opendir() so it may not be a problem) |
| 22:00:39 | | Join Smooth [0] (909510b8@ACB9E508.ipt.aol.com) |
| 22:00:58 | [IDC]Dragon | the directory delete has a resursion |
| 22:01:03 | [IDC]Dragon | recursion |
| 22:01:13 | * | [IDC]Dragon checks |
| 22:01:25 | Smooth | Hi |
| 22:02:59 | [IDC]Dragon | ah, you already said that opendir() copies it already |
| 22:07:16 | *** | Saving seen data "./dancer.seen" |
| 22:11:12 | [IDC]Dragon | amiconn: only the open() function does this patching? |
| 22:12:28 | amiconn | I only found it there so far. This should only be a problem if the argument is declared const anyway. |
| 22:13:22 | [IDC]Dragon | which it is |
| 22:13:38 | [IDC]Dragon | the clean solution would be a copy, I'd suggest that |
| 22:13:42 | amiconn | I'm the const police ;) |
| 22:13:55 | [IDC]Dragon | yes sir yes |
| 22:14:37 | [IDC]Dragon | for one project, I made a circuit to detect write access to the ROM region |
| 22:14:48 | [IDC]Dragon | to find bug like this |
| 22:15:16 | amiconn | An MMU would be of great use here too |
| 22:15:41 | [IDC]Dragon | for deluxe controllers, yes |
| 22:15:58 | [IDC]Dragon | in my case it was a Siemens C161 |
| 22:16:03 | [IDC]Dragon | (16 bit) |
| 22:16:47 | [IDC]Dragon | did you do anything to the flash ID code? |
| 22:16:54 | amiconn | In fact, rockbox is my first project to deal with controller programming. |
| 22:17:38 | amiconn | So far I only dealt with "real" computers, although even back in the 8 bit era. This is why I know "a bit" about asm |
| 22:18:03 | [IDC]Dragon | or a byte ;-) |
| 22:23:21 | | Quit Smooth ("leafChat IRC client: http://www.leafdigital.com/Software/leafChat/") |
| 22:25:57 | [IDC]Dragon | I now remember the "old" failures from ROM: back then the viewers were hard coded |
| 22:26:15 | [IDC]Dragon | so it was unable to load those plugins |
| 22:28:32 | [IDC]Dragon | in general, it looks like Rockbox can relatively easy be fixed to run from ROM |
| 22:29:54 | amiconn | Grr, the MIN() macro isn't available within file.c |
| 22:30:38 | [IDC]Dragon | you don't want to dynamically allocate, do you? |
| 22:30:49 | [IDC]Dragon | what do you need it for? |
| 22:31:03 | amiconn | No, but I want to make sure the path part of the argument doesn't overflow my buffer |
| 22:31:45 | [IDC]Dragon | then you can take the difference of the position and the start |
| 22:32:23 | amiconn | Yes, I do that, but I have to check if this is < MAX_PATH. That's what I wanted to use the MIN() macro for |
| 22:32:59 | amiconn | Line 105..109 read now: |
| 22:33:00 | [IDC]Dragon | or use strncpy() |
| 22:33:00 | amiconn | pathlen = MIN(name - pathname, MAX_PATH - 1); |
| 22:33:00 | amiconn | memcpy(path, pathname, pathlen); |
| 22:33:00 | DBUG | Enqueued KICK amiconn |
| 22:33:00 | amiconn | path[pathlen] = '\0'; |
| 22:33:00 | amiconn | dir = opendir(path); |
| 22:33:59 | [IDC]Dragon | why not copy the whole pathname right at the start, then work with the copy? |
| 22:34:03 | amiconn | strncpy() doesn't append a \0 byte if the source string length == n. |
| 22:34:41 | [IDC]Dragon | do a name[MAX_PATH] = '\0' to be sure |
| 22:35:03 | [IDC]Dragon | MAX_PATH-1, actually |
| 22:35:46 | [IDC]Dragon | but you way is more efficient |
| 22:35:50 | [IDC]Dragon | your |
| 22:36:02 | amiconn | I f I copy the whole string, the maximum allowed length would be a bit smaller (by the filename part) |
| 22:36:34 | amiconn | Furthermore, memcpy() is more efficient that strncpy(). I should know that one ;-) |
| 22:36:54 | [IDC]Dragon | that's what I meant. |
| 22:37:29 | [IDC]Dragon | opendir is just using strncpy+forced termination. |
| 22:37:52 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 22:37:53 | [IDC]Dragon | strncpy(namecopy,name,sizeof(namecopy)); |
| 22:37:53 | [IDC]Dragon | namecopy[sizeof(namecopy)-1] = 0; |
| 22:37:59 | amiconn | Maybe the next thing to do after romboxing is optimizing the other string functions (at least those that are used often) |
| 22:38:28 | [IDC]Dragon | I don't think they are used in tight code |
| 22:38:58 | [IDC]Dragon | and optimized implementations tend to get lengthy |
| 22:39:21 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
| 22:39:25 | amiconn | Remember that memchr() / strchr() & co can be done much more effiecient with a special asm instruction that is never used by gcc? |
| 22:39:59 | amiconn | cmp/str compares 4 bytes in one clock cycle |
| 22:45:04 | amiconn | Of course the straight copy thing is the easier solution |
| 22:48:04 | [IDC]Dragon | interesting instruction, no, I don't remember that one |
| 22:48:23 | | Join Smooth [0] (909510b8@ACB9E508.ipt.aol.com) |
| 22:48:26 | | Quit Smooth (Client Quit) |
| 22:48:53 | amiconn | You once asked for a fast memchr() which I offered to do. I would have used this very instruction for it. |
| 22:49:12 | [IDC]Dragon | :-) |
| 22:50:21 | | Join lImbus [0] (lImbus@185.107-200-80.adsl.skynet.be) |
| 22:50:32 | amiconn | With the modified open() function it works (I took the simple approach for now) |
| 22:50:40 | | Nick lImbus is now known as _lImbus (lImbus@185.107-200-80.adsl.skynet.be) |
| 22:50:42 | [IDC]Dragon | great |
| 22:50:59 | [IDC]Dragon | how often have you flashed today? |
| 22:51:27 | amiconn | Err ... umm ... I didn't really count. Perhaps 10..20 times |
| 22:52:09 | [IDC]Dragon | do you want me to fix the flash ID code? |
| 22:52:21 | [IDC]Dragon | (placing it in IRAM) |
| 22:53:14 | amiconn | This would have been my next step - if you would do that - great. |
| 22:53:31 | amiconn | (Just checking the builds for warnings) |
| 22:54:01 | _lImbus | [IDC]Dragon, is my new nick ok ? I would really appreciate keepin something with 'lImbus' in. |
| 22:54:24 | [IDC]Dragon | _lImbus: don't change it, I wasn't serious |
| 22:54:36 | _lImbus | mhmm. das sah aber nicht danach aus. |
| 22:54:56 | [IDC]Dragon | du hast mich gar nicht gesehen ;-) |
| 22:55:17 | _lImbus | maybe it fed up somebody else (amiconn?) too, so this may be a good solution. |
| 22:56:48 | amiconn | _lImbus: I should look at tab-completed nicks before hitting return, so it was my fault anyway |
| 22:58:34 | amiconn | <[IDC]Dragon> too early tab completion |
| 22:58:34 | amiconn | [15:54:33] <amiconn> yup |
| 22:58:34 | amiconn | [15:54:57] <[IDC]Dragon> I'm "angry" about lImbus' nick, too |
| 22:58:50 | _lImbus | yeah, that was it ;-) |
| 22:59:04 | amiconn | It was not me that was angry... |
| 22:59:12 | [IDC]Dragon | see, it was in quotes |
| 22:59:32 | _lImbus | yup, I see. I tought idc was angry too, so must have been ami. |
| 22:59:41 | _lImbus | well. I changed it on two clients now. We remember it' s no odds, so we take the easy solution: keeping as it is atm |
| 22:59:51 | [IDC]Dragon | _lImbus is very sensitive... |
| 23:00 |
| 23:00:14 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 23:00:14 | * | [IDC]Dragon feels sorry |
| 23:00:24 | _lImbus | that means ? better or worse ? (english is my fourth language98 |
| 23:00:26 | _lImbus | ) |
| 23:01:12 | _lImbus | should I go back ? this would be for good then (i hope) |
| 23:02:01 | [IDC]Dragon | you're most welcome to freely pick your nick |
| 23:02:22 | amiconn | _lImbus: I preferred your former nick. Nicks with special chars in front are not so easy to enter, even with tab completion, as they require finger acrobatics on the keyboard ;) |
| 23:02:23 | [IDC]Dragon | make it LinusM if you like |
| 23:04:08 | _lImbus | noooo |
| 23:04:34 | _lImbus | Limbus (with lImbus) is my nick since a few years, this is why I want to keep it. |
| 23:04:50 | _lImbus | so I'll go back to lImbus for good. |
| 23:05:00 | | Nick _lImbus is now known as lImbus (lImbus@185.107-200-80.adsl.skynet.be) |
| 23:06:36 | midk | yyyyyaaaaaaaaaaaaaay |
| 23:09:37 | scott666 | long live lImbus |
| 23:17:59 | | Quit midk (Remote closed the connection) |
| 23:18:45 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
| 23:22:10 | [IDC]Dragon | amiconn: fix to debug_menu.c committed, can you try it out? |
| 23:23:10 | amiconn | yup |
| 23:23:28 | [IDC]Dragon | gotta leave now |
| 23:23:38 | [IDC]Dragon | thanks and bye |
| 23:23:46 | | Quit [IDC]Dragon () |
| 23:48:03 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 23:49:29 | elinenbe | amiconn: nice commits −− how long until rombox is a reality? |
| 23:51:36 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 23:52:36 | amiconn | It depends - hunting for other bugs is necessary, and in order to work for the v2/fm, the flash image has to be changed to only contain a .ajz loader, otherwise it won't fit |
| 23:52:40 | | Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) |
| 23:53:23 | amiconn | Remember that flashing doesn't currently work when running from flash (for obvious reasons) |
| 23:54:07 | amiconn | So if you want to update rombox, you first have to rolo into ram-based rockbox |
icon identifies that the person is a core developer (has commit access).