| 00:00:07 | DigitalDiva | well i find the difference between an analogue and digital recording almost impossible to tell |
| 00:00:28 | Zagor | the funny thing is that mp3 itself is a SCMS system, so adding a limiter is completely pointless |
| 00:00:39 | DigitalDiva | really? |
| 00:00:42 | amiconn | Zagor: The archos recording screen does have one advantage compared to the rockbox version: It shows the average bitrate next to the file size |
| 00:00:53 | DigitalDiva | Im gonna respray my archos one day, the silver paint is wearing odd |
| 00:00:54 | DigitalDiva | off |
| 00:01:02 | Zagor | DigitalDiva: yes, if you mp3 an mp3 file, it will sound worse than the original |
| 00:01:39 | Zagor | it's not a deliberate SCMS system, it's just gets that way due to the mp3 data reduction process |
| 00:01:41 | DigitalDiva | okay |
| 00:02:17 | DigitalDiva | im not particulary keen on propiretoory li-ion batteries in newer devices |
| 00:02:25 | amiconn | Zagor: Yes, but once you have an mp3, you can copy it digitally without further degradation |
| 00:02:44 | Zagor | amiconn: should be easy enough to add. in fact we've been discussing a while-recording-screen and a while-radio-screen |
| 00:02:59 | amiconn | Sounds interesting! |
| 00:03:05 | Zagor | amiconn: correct, so the spdif block does not help |
| 00:03:24 | Zagor | all it does is annoy the user |
| 00:04:02 | Zagor | ...and *force* him to make bit-perfect copies instead of degraded rerecorded copies! |
| 00:04:03 | amiconn | Zagor: For while-recording-screen and while-radio-screen, the extension would both be .wrs ?? ;) |
| 00:04:35 | Zagor | the extension naming committee is still in session about that :) |
| 00:05:00 | ze | how about while-fm-screen .wfs |
| 00:05:26 | Zagor | sounds good. i'll tell the committee ;) |
| 00:10:31 | [IDC]Dragon | USB mode works! |
| 00:10:35 | Zagor | yay |
| 00:10:46 | [IDC]Dragon | (for external MMC so far) |
| 00:10:49 | amiconn | yay! |
| 00:10:50 | amiconn | [IDC]Dragon: What was the problem? |
| 00:10:54 | Bagder | you rock Jörg |
| 00:11:08 | [IDC]Dragon | missing chip select, in addition to the collision |
| 00:11:43 | amiconn | And I just read that you found the pin that signals bridge activity to the cpu :) |
| 00:12:15 | amiconn | I though that this signal must be somewhere, because the archos fw shows those dots.. |
| 00:12:34 | amiconn | *thought |
| 00:13:16 | [IDC]Dragon | yes, so did I, but I haven't checked thorougly because of low prio |
| 00:13:39 | [IDC]Dragon | it's just an optical gimmick, and doesn't work very well |
| 00:14:04 | [IDC]Dragon | (after unmount, it still animates) |
| 00:14:32 | amiconn | I think it's nice to have, and of course we will implement it better ;) |
| 00:14:49 | | Quit Bagder ("Leaving") |
| 00:14:53 | [IDC]Dragon | if the signal is better, yes |
| 00:19:58 | [IDC]Dragon | the bridge drives the MMC with 12 MHz!? |
| 00:21:04 | amiconn | That's within specs. |
| 00:21:19 | amiconn | Depending on the card, MMC works up to 20 MHz |
| 00:23:27 | | Join bagawk [0] (lee@IC61.library.oregonstate.edu) |
| 00:23:53 | [IDC]Dragon | this idle power off during USB is annoying |
| 00:24:20 | [IDC]Dragon | I wonder why that happens, the USB detectionis obviously correct |
| 00:24:51 | amiconn | Already committed working usb mode? |
| 00:25:03 | [IDC]Dragon | I'll do that |
| 00:25:15 | [IDC]Dragon | but it's external MMC only |
| 00:25:36 | amiconn | Why's that? |
| 00:25:47 | [IDC]Dragon | don't know |
| 00:26:06 | [IDC]Dragon | maybe the chip select for the internal is wrong |
| 00:28:06 | amiconn | Do you have to assert the MMC chip select (PA9) for usb mode to work?? |
| 00:28:31 | [IDC]Dragon | yes |
| 00:28:38 | amiconn | Strange... |
| 00:28:53 | amiconn | The data sheet tells us that MMC mode does not use chip select |
| 00:29:01 | [IDC]Dragon | ah, yes |
| 00:29:13 | [IDC]Dragon | which level should it have then? |
| 00:29:28 | * | amiconn is looking it up |
| 00:30:17 | amiconn | high |
| 00:30:27 | amiconn | low is active |
| 00:31:00 | amiconn | The card is switched to SPI mode by sending CMD0 while CS is low |
| 00:31:36 | [IDC]Dragon | I switched it high, this was bullshit |
| 00:32:14 | amiconn | It *has* to be high for MMC mode (=bridge) to work |
| 00:32:19 | [IDC]Dragon | then probably the internal card didn't change from SPI to MMC mode |
| 00:32:54 | [IDC]Dragon | high is good then, but my understanding was wrong and the implementation inverted |
| 00:40:26 | | Quit AciD ("ou double !") |
| 00:40:28 | bagawk | [IDC]Dragon, Would keeping the backlight off in the charging screen save a little power, and charge better? |
| 00:40:39 | amiconn | [IDC]Dragon: Internal flash chip select *is* PA10 |
| 00:41:15 | [IDC]Dragon | bagawk: not worth it |
| 00:41:30 | [IDC]Dragon | amiconn: I think so, too |
| 00:41:38 | [IDC]Dragon | what leads you there? |
| 00:41:39 | amiconn | I'm pretty sure |
| 00:41:59 | [IDC]Dragon | the internal flash has a reset |
| 00:42:10 | amiconn | Ahem, disassembler listing :) |
| 00:42:29 | amiconn | Found the internal/external card selector routine |
| 00:42:56 | [IDC]Dragon | it that reset is controllable, we could bring the card back to MMC mode |
| 00:43:22 | amiconn | There must be a way to do that |
| 00:43:51 | [IDC]Dragon | the external has no reset |
| 00:44:17 | | Join PaulS [0] (~0d0274bd@labb.contactor.se) |
| 00:44:51 | amiconn | [IDC]Dragon: We need to know where this is connected |
| 00:45:11 | [IDC]Dragon | tricky, this is BGA |
| 00:45:37 | [IDC]Dragon | but not many ports left ;-) |
| 00:45:54 | amiconn | If I find the routine... |
| 00:46:06 | PaulS | I added a little to IriverPort to explain how to get SDRAM and SRAM images out of the firmware. |
| 00:46:13 | bagawk | i am out of disk space for my jukebox now :( |
| 00:46:59 | Zagor | PaulS: nice |
| 00:48:06 | *** | Saving seen data "./dancer.seen" |
| 00:48:15 | | Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") |
| 00:48:22 | PaulS | I didn't want to take up more space with the actual dd commands, but someone "skilled in the art" should be able to deduce that. :-) |
| 00:48:24 | [IDC]Dragon | internal MMC works! |
| 00:50:07 | [IDC]Dragon | but this broke the external |
| 00:50:36 | amiconn | ??? |
| 00:51:06 | Zagor | PaulS: indeed |
| 00:52:51 | [IDC]Dragon | PA7 seems to be the reset |
| 00:57:53 | PaulS | Hm.. I threw in a dd example anyway.. |
| 00:58:06 | | Quit DigitalDiva ("CGI:IRC (Ping timeout)") |
| 01:00 |
| 01:00:42 | amiconn | [IDC]Dragon: It seems so, I found something that looks like a reset routine. It uses PA7 |
| 01:01:33 | [IDC]Dragon | see above, yes |
| 01:02:50 | amiconn | The SanDisk datasheet is rather valuable |
| 01:05:26 | [IDC]Dragon | ok, now both are working |
| 01:06:22 | [IDC]Dragon | committed |
| 01:06:23 | amiconn | It seems I should start working on the driver itself :) |
| 01:06:39 | [IDC]Dragon | yes, the time is ripe |
| 01:06:56 | [IDC]Dragon | but we don't mind a debugged recording |
| 01:07:34 | amiconn | I'll have to wait for Linus doing some logic analyzing. Until he did that, I could work on the driver... |
| 01:08:24 | [IDC]Dragon | I work on my sleep now |
| 01:08:32 | amiconn | ;) |
| 01:09:09 | amiconn | Nite. |
| 01:09:22 | [IDC]Dragon | the cvs code is not what I'm running, I made a hack in init() to loop the main menu. |
| 01:09:31 | [IDC]Dragon | I haven't commited that. |
| 01:10:34 | [IDC]Dragon | while(1) main_menu(); |
| 01:10:50 | [IDC]Dragon | after the usb_start_monitoring() call. |
| 01:15:36 | amiconn | yEAH, ROCKBOX USB LOGO!! |
| 01:15:44 | amiconn | Ooops, caps lock |
| 01:16:35 | midk | :) |
| 01:20:12 | Zagor | bed time, bye |
| 01:20:12 | [IDC]Dragon | you're building Ondio? |
| 01:20:14 | | Quit Zagor ("Client exiting") |
| 01:20:29 | amiconn | [IDC]Dragon: I did... |
| 01:21:08 | amiconn | After extracting USB, it fails with *PANIC* disk: NULL |
| 01:21:20 | amiconn | The only way to switch it off then is to cut power |
| 01:21:44 | [IDC]Dragon | yes, because it tries to mount a partition |
| 01:21:59 | amiconn | Of course, I only wanted to tell |
| 01:22:09 | [IDC]Dragon | ;-) |
| 01:22:28 | | Quit _aLF ("good night") |
| 01:22:35 | [IDC]Dragon | you can hold OFF for 10 sec to power off |
| 01:22:50 | amiconn | I wonder how we will handle the case that someone inserts or extracts a card while rockbox is running |
| 01:23:04 | amiconn | The file system will have to be remounted |
| 01:23:20 | amiconn | This renders all open file descriptors invalid |
| 01:23:24 | [IDC]Dragon | right now I only check at init |
| 01:23:33 | [IDC]Dragon | let's worry later |
| 01:23:39 | | Quit PaulS ("CGI:IRC") |
| 01:23:44 | amiconn | Yup, only a thought |
| 01:23:47 | | Join PaulS [0] (~0d0274bd@labb.contactor.se) |
| 01:23:52 | [IDC]Dragon | goodnight, happy Ondio hacking! |
| 01:23:58 | | Quit [IDC]Dragon () |
| 01:54:39 | | Quit bagawk ("Leaving") |
| 02:00 |
| 02:03:49 | | Part amiconn |
| 02:19:57 | | Quit midk (Remote closed the connection) |
| 02:21:41 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 02:23:15 | | Join BC_ [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 02:27:33 | BC_ | just popped in to say "hi" |
| 02:27:37 | | Nick BC_ is now known as BC (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 02:27:45 | midk | hey bc |
| 02:27:53 | BC | hey mk |
| 02:28:12 | midk | there was something i wanted to commend you on, but i forget now :) |
| 02:28:21 | BC | lol - thanks |
| 02:28:22 | midk | hm, perhaps there wasn't... |
| 02:28:27 | BC | lol |
| 02:29:13 | BC | just got my head really stuck in to my new book and got fed a new bunch of MAS docs |
| 02:29:51 | midk | oh, right, that reminds me, didn't you locate a set of karaoke registers? |
| 02:29:55 | midk | real karaoke, that is |
| 02:29:56 | BC | yeah |
| 02:30:09 | midk | that sounded fascinating |
| 02:30:34 | BC | just plug a mic into the unit and use the in-built mixer |
| 02:30:50 | midk | very cool |
| 02:30:58 | BC | couple that with the centre removal system and you have a pretty good karaoke machine |
| 02:31:18 | BC | also sussed mixing of stereo mp3s |
| 02:31:35 | midk | you should consider tossing in a true karaoke mode.. i suppose there isn't room in audio-3587 though |
| 02:31:43 | BC | in fact you could do both at the same time |
| 02:31:52 | BC | what is "true" karaoke? |
| 02:32:10 | BC | do you mean a cdg displayer? |
| 02:32:19 | midk | i suppose 'true' karaoke wouldn't be possible |
| 02:32:50 | BC | you can convert true karaoke disks to a mp3/cdg pair and play those |
| 02:32:52 | midk | although if there's a seperate set of registers it'd have to be a little better than the algorithm rocbox uses... isn't it stereo-mono? |
| 02:33:27 | BC | can you explain what you mean by "true" karaoke? |
| 02:33:48 | midk | just that - actual vocal removal instead of just taking mono away from stereo |
| 02:34:19 | BC | righty - no afiak nobody has sussed it yet |
| 02:34:29 | BC | for anything anywehere |
| 02:35:06 | midk | yeah, now it sounds a bit more impossible when i have to actually think about it :) |
| 02:36:16 | BC | karaoke mode is a two minute job |
| 02:36:51 | midk | what kind of karaoke mode? |
| 02:36:57 | midk | the existing, or a new one using these registers? |
| 02:37:18 | BC | existing + mic mixer |
| 02:38:43 | midk | a karaoke plugin would be neat |
| 02:39:30 | BC | you just have to write a number to a register - it's all documented in the pdf on the rockbx site |
| 02:40:08 | midk | but with a few options i mean, like how much of a mix between mic and song, or toggling 'imitation karaoke' on or off |
| 02:41:17 | BC | yep, iirc, there is also a mic-volume level and the "st-mono" is just another couple of registers - well documented again, probably easiest to nick the code from Audio-3587 |
| 02:41:44 | BC | you could even have a dial for how much to remove the original voices |
| 02:41:54 | midk | yep, that'd be neat |
| 02:48:10 | *** | Saving seen data "./dancer.seen" |
| 02:50:01 | BC | it's on page 42 of the docs |
| 02:51:33 | BC | nite all |
| 02:51:46 | | Part BC |
| 02:57:35 | | Join bagawk [0] (Lee@ACC3220B.ipt.aol.com) |
| 03:00 |
| 03:01:00 | | Quit bagawk (Client Quit) |
| 03:13:12 | | Join pike|| [0] (amiga@h234n1fls22o1064.bredband.comhem.se) |
| 03:13:34 | | Quit pike (Nick collision from services.) |
| 03:13:34 | | Nick pike|| is now known as pike (amiga@h234n1fls22o1064.bredband.comhem.se) |
| 03:16:13 | | Join bagawk [0] (Lee@ACC0DB51.ipt.aol.com) |
| 03:31:21 | | Quit bagawk ("umount /dev/brain") |
| 03:35:40 | | Join plok [0] (s336156@student.uq.edu.au) |
| 03:41:14 | * | plok is away - Automatically set away. - messages will be saved. |
| 04:00 |
| 04:02:07 | | Quit PaulS ("CGI:IRC (EOF)") |
| 04:19:36 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 04:19:48 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 04:25:07 | | Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 04:48:14 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:28:55 | | Join grogro [0] (~gromit@ALagny-151-1-22-167.w83-114.abo.wanadoo.fr) |
| 05:37:49 | | Join dreed [0] (~45912877@labb.contactor.se) |
| 05:38:50 | dreed | hey i am having a problem compiling i think.... |
| 05:39:13 | dreed | I downloaded the 2.2 source and didn't change anything, just compiled it and this is what I got.... |
| 05:39:17 | dreed | /opt/sh1/lib/gcc-lib/sh-elf/3.3.1/../../../../sh-elf/bin/ld: section .iram [0000 |
| 05:39:17 | dreed | 00000903dd68 -> 000000000903ea9b] overlaps section .stack [000000000903dd68 -> 0 |
| 05:39:17 | dreed | 00000000903fd67] |
| 05:39:17 | DBUG | Enqueued KICK dreed |
| 05:39:17 | dreed | collect2: ld returned 1 exit status |
| 05:39:17 | dreed | make[1]: *** [/home/David/rockbox/build/rockbox.elf] Error 1 |
| 05:39:18 | *** | Alert Mode level 1 |
| 05:39:18 | dreed | make[1]: Leaving directory `/home/David/rockbox/apps' |
| 05:39:20 | dreed | make: *** [apps] Error 2 |
| 05:40:35 | midk | get a daily, first off. |
| 05:40:52 | midk | it also looks like something isn't installed correctly, tjat |
| 05:41:00 | midk | that's not a rockbox error |
| 05:41:43 | dreed | i didnt think it was a rockbox error but i just installed cygwin and i probably didnt do it right |
| 05:41:56 | dreed | rockbox rox!! |
| 05:41:58 | midk | how did you install? every package? |
| 05:42:06 | midk | (implied by the name, yes. :)) |
| 05:43:08 | dreed | i follwed the instructions step by step here:http://rockbox.haxx.se/twiki/bin/view/Main/CygwinDevelopment |
| 05:43:44 | midk | you sure you did all of them? |
| 05:43:55 | dreed | the only thing i saw is that it said to type in that one URL to get those other two packages and i did that but the version that was available was older than the one listed on your page |
| 05:44:32 | dreed | sh-gcc latest version is 3.4.1 but the one on the site was like 3.3 |
| 05:45:28 | midk | i'd still follow it exactly: if it doesn't work exactly as he says then you've got reason to complain |
| 05:45:37 | midk | i suggest an uninstall, and use bc's devkit instead. |
| 05:45:48 | midk | http://homepage.ntlworld.com/cyborgsystems/CS_Main/RockBox/RockBox.htm |
| 05:45:50 | midk | it's down the page a bit. |
| 05:46:06 | dreed | well i am not complaiing I am just a newbie and was lost :) |
| 05:46:20 | dreed | okay thanks, I'll try that |
| 05:46:38 | midk | it's np :) |
| 05:46:52 | midk | i didn't mean you were complaining, just that you should if it doesn't work like he says. :) |
| 05:49:20 | *** | Alert Mode OFF |
| 05:50:21 | | Quit maikeul (Read error: 110 (Connection timed out)) |
| 05:51:14 | | Quit dreed ("CGI:IRC (EOF)") |
| 06:00 |
| 06:42:24 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 06:43:43 | dwihno | Welcome back to *drumroll* Rockbox, your 24/7 support \o/ ;) |
| 06:43:50 | dwihno | Nah |
| 06:43:50 | dwihno | :) |
| 06:44:36 | dwihno | What should I do? My left shift button on my keyboard is not always de-clicking correctly :/ |
| 06:44:47 | midk | i know! |
| 06:44:49 | midk | (lightbulb) |
| 06:44:50 | midk | fix it. |
| 06:44:54 | midk | :) |
| 06:45:01 | dwihno | How? :) |
| 06:45:29 | midk | by.. fixing it. |
| 06:45:31 | midk | :) |
| 06:45:36 | midk | pop it off, perhaps it's gunky. |
| 06:45:51 | midk | pry it off, clean it, and the place it rests |
| 06:47:02 | dwihno | You think that's possible? I mean, this is a laptop keyboard |
| 06:47:43 | midk | oh. |
| 06:47:44 | midk | hm. |
| 06:48:15 | *** | Saving seen data "./dancer.seen" |
| 06:48:16 | LinusN | dwihno: dell? |
| 06:49:53 | LinusN | yes, you can remove the keys and clean them, i've done it myself on my dell laptop |
| 06:50:19 | dwihno | Ah |
| 06:50:24 | LinusN | they are a bit tricky to put back, but it works |
| 06:50:26 | dwihno | Nice, I have a dell aswell |
| 06:51:02 | LinusN | i spilled coffee on it, and some keys got stuck |
| 06:51:09 | dwihno | Do you have to remove the keyboard from the laptop, or do you just pry the keys off? |
| 06:51:16 | dwihno | Coffe and computers just don't mix :) |
| 06:51:32 | dwihno | I think I've managed to do that three times |
| 06:51:34 | midk | just pop off the keys. |
| 06:51:35 | LinusN | it's easier if you remove the keyboard |
| 06:51:39 | midk | hmm |
| 06:51:41 | midk | i stand corrected |
| 06:51:48 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 06:51:48 | * | midk quiets down and shuts off lightbulb |
| 06:51:49 | dwihno | Is it hard to remove it? |
| 06:52:14 | LinusN | prying it off is simple with the keyboard in place, but putting it back is easier when you have the keyboard in your hand |
| 06:52:32 | LinusN | you unscrew the top plate and then you can just lift it off |
| 06:54:23 | dwihno | top plate? |
| 06:54:40 | LinusN | the frame that surrounds the keyboard |
| 06:55:16 | dwihno | okay, so one of the screws on the bottom of the box then |
| 06:55:20 | LinusN | there are screws under the laptop marked "K" for keyboard |
| 06:55:26 | dwihno | :-) |
| 06:57:04 | dwihno | Ah |
| 06:57:07 | dwihno | 4 screws |
| 06:57:11 | dwihno | One shared with "m" |
| 06:57:18 | dwihno | and one attached to some kind of compartment |
| 06:57:32 | dwihno | Now THAT'S where the small elves' gotta be! |
| 06:57:34 | LinusN | Latitude? |
| 06:58:12 | dwihno | inspiron |
| 06:58:16 | LinusN | ok |
| 06:58:27 | dwihno | it's taller than that korean basket playing guy |
| 06:59:04 | dwihno | about 3 cm thick, and then the screen is flipped up |
| 06:59:17 | dwihno | add 8mm's or such |
| 06:59:24 | dwihno | but I love it! |
| 06:59:32 | dwihno | The only bad thing is the lack of onboard usb2 |
| 06:59:52 | LinusN | i have a latitude C840, really nice |
| 07:00 |
| 07:00:11 | dwihno | does it have those replaceable hand plates? |
| 07:00:42 | LinusN | hand plates? |
| 07:00:47 | dwihno | I'd like to remove these and clean it as well; I can see a lot of dust |
| 07:01:12 | dwihno | where you keep your arms, there are replaceable pads |
| 07:01:14 | dwihno | plastic |
| 07:01:20 | dwihno | you can buy different colors etc |
| 07:01:29 | dwihno | Would be pretty cool with yellow ones :) |
| 07:02:16 | LinusN | no, the latitude doesn't have those |
| 07:02:24 | dwihno | +−−−−−−-+ |
| 07:02:24 | dwihno | |:::::::| |
| 07:02:24 | dwihno | | | |
| 07:02:24 | DBUG | Enqueued KICK dwihno |
| 07:02:24 | dwihno | | [ ] | |
| 07:02:24 | dwihno | | | |
| 07:02:26 | dwihno | +( )_( )+ |
| 07:02:29 | dwihno | something like that |
| 07:02:44 | dwihno | the square being that pad thingy |
| 07:02:51 | dwihno | mouse pad, whateveryoucallit |
| 07:04:01 | LinusN | touch pad, i believe it's called |
| 07:04:12 | dwihno | probably |
| 07:04:24 | dwihno | mouse pad thingy \o/ :) |
| 07:04:47 | dwihno | Time for some hot choco! |
| 07:10:00 | dwihno | LinusN: I am grateful for all your guidance and help (not just this once). I just want you to know, that it's greatly apperciated. |
| 07:10:43 | LinusN | you're welcome |
| 07:23:59 | | Quit scott666_ ("i'll be back...eventually...") |
| 07:25:21 | plok | What sort of instruction set does the iRiver CPU have? |
| 07:27:02 | LinusN | plok: very similar to the 68000 |
| 07:27:28 | LinusN | kind of a RISC version of the 68k |
| 07:30:15 | plok | Aah. Is there a compatible C++ compiler for it? |
| 07:31:57 | LinusN | gcc |
| 07:32:22 | LinusN | rockbox is plain C though |
| 07:34:20 | plok | ta. Yeah I noticed that. It should be possible to write C++ code and build it with the rest of rockbox though shouldn't it (eg if someone's just messing around with the code) |
| 07:36:20 | LinusN | the linker may not be happy |
| 07:37:00 | LinusN | why is it so important with C++? |
| 07:38:12 | plok | It's not important, I just prefer C++. It's not a big deal if I can't get it going :) |
| 07:39:59 | plok | Probably the easiest thing for me to do would be to see how close rockbox goes to compiling with a C++ compiler |
| 07:46:17 | LinusN | it will compile with a c++ compiler |
| 07:52:15 | plok | :) |
| 07:54:57 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 07:56:04 | LinusN | morning zagor |
| 07:56:44 | Zagor | hi |
| 07:57:57 | plok | binutils-2.15 is not on the australian gnu mirror. Can I use 2.14 or should I get 2.15 from another server? |
| 07:58:26 | Zagor | 2.14 might work but I'd use 2.15 just to be sure |
| 07:58:40 | plok | ok, thanks. |
| 08:00 |
| 08:22:38 | plok | is the syntax simply −−target=sh-elf −−enable-languages=c,c++ if I want to include a c++ compiler when building the cross compiler? |
| 08:24:34 | Zagor | plok: yes, but you won't succeed :) |
| 08:24:52 | Zagor | the standard c++ library is not as portable as the compiler itself |
| 08:26:23 | | Join amiconn [0] (~jens@pD9E7DFB8.dip.t-dialin.net) |
| 08:26:39 | plok | !! I suppose that explains why I got an error when building with c++ enabled.. oh well |
| 08:27:01 | amiconn | good morning rockbox world |
| 08:28:44 | plok | good morning. I just noticed binutils is an anagram of builtins |
| 08:29:29 | amiconn | LinusN: r u there? |
| 08:29:50 | Zagor | plok: :) |
| 08:32:46 | LinusN | amiconn: here now |
| 08:32:49 | plok | oops, I also hadn't added my newly built binutils to the path |
| 08:33:42 | LinusN | plok: i suggest you stick with the plain c compiler |
| 08:33:43 | amiconn | LinusN: Did you read last night's backlogs? I have somer really interesting finding concerning the recording transfer, but need you r help with logic analyzing. |
| 08:33:56 | amiconn | *some |
| 08:33:59 | LinusN | plok: we won't accept any c++ conde contributions anyway |
| 08:34:04 | LinusN | s/conde/code/ |
| 08:34:21 | LinusN | amiconn: hang on, will read up |
| 08:34:24 | plok | hmm.. Linus, just switched back to the plain c compiler, trying to get gcc to build. got this weird error though: |
| 08:34:25 | plok | insn-emit.c:8549: Internal compiler error in simplify_subreg, at simplify-rtx.c:2452 |
| 08:36:05 | plok | double oops, added the root sh1 dir to the path, not sh1/bin |
| 08:37:26 | amiconn | LinusN: I would really appreciate if you could do the following: Hook up your LA and capture the recording transfer, but this time *including* PB14 (MAS demand IRQ). Please do this both for rockbox and archos fw, and if at all possible also capture the start of recording. |
| 08:39:19 | LinusN | amiconn: i'm pretty sure that EOD is the PB14 pin in my older analysis, that's why it's inverted |
| 08:40:12 | LinusN | the "Note:" sentence on top of the web page describes that |
| 08:40:39 | amiconn | But EOD is PA15 ??? |
| 08:40:48 | LinusN | hmmm |
| 08:42:05 | LinusN | PB15 = RTW in the port pin table |
| 08:43:01 | amiconn | Yes. P_B_15 = RTW, P_A_15 is EOD |
| 08:43:37 | LinusN | PB14 is the inverted PA15 |
| 08:44:07 | amiconn | really? |
| 08:44:13 | LinusN | so there will be a few nanosecs delay on one of the pins, have to check the schematics to see which one is delayed |
| 08:44:56 | LinusN | there is an inverter, since the irq can only be edge triggered on the falling edge |
| 08:47:40 | LinusN | i don't remember which one i soldered my probe to, but the polarity in the analyzer trace should give a clue |
| 08:48:17 | *** | Saving seen data "./dancer.seen" |
| 08:48:23 | LinusN | amiconn: i can't find your findings in the irc log, maybe i'm blind |
| 08:48:29 | amiconn | I can't find that inverter in the schematics.... |
| 08:49:45 | amiconn | LinusN: Look at http://rockbox.haxx.se/irc/rockbox-20040914.txt , juster after 23:26 |
| 08:50:19 | amiconn | But if PB14 is just inverted PA15, it may be that it is not that important |
| 09:00 |
| 09:00:18 | LinusN | the mas doesn't send any data until there is a S/PDIF signal |
| 09:00:19 | amiconn | Ah, the inverter is on the far left in the schematics |
| 09:00:34 | LinusN | yup |
| 09:02:02 | | Join amiconn_ [0] (~jens@pD9E7E9EB.dip.t-dialin.net) |
| 09:02:15 | | Quit amiconn (Nick collision from services.) |
| 09:02:15 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7E9EB.dip.t-dialin.net) |
| 09:03:38 | amiconn | I'll try to write an all-new recording transfer routine in the evening |
| 09:05:09 | LinusN | amiconn: what's wrong with the current one? |
| 09:06:40 | amiconn | I'll try removing the 30 byte limit, and adding a timeout to the PRTW polling. |
| 09:07:37 | amiconn | Perhaps we do without those additional delays and drain_dma_buffer() calls etc. |
| 09:07:43 | amiconn | *we can do |
| 09:13:33 | LinusN | good |
| 09:13:37 | amiconn | And using PB14 instead of PA15 should be better, because of less delay |
| 09:14:10 | LinusN | sure |
| 09:20:33 | amiconn | Hmm. Did you measure the recording transfer with archos fw some time? |
| 09:20:49 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 09:22:35 | LinusN | amiconn: i don't think so |
| 09:30:22 | Zagor | oh bugger, making display size run-time changeable is really messy... |
| 09:30:32 | Zagor | i think i'll shelf it for now |
| 09:31:32 | | Join Paco [0] (~527fc887@labb.contactor.se) |
| 09:33:05 | | Quit Paco (Client Quit) |
| 09:33:58 | | Join [av]bani [0] (~goemon@washuu.anime.net) |
| 09:34:02 | [av]bani | "The uClinux-dist also contains |
| 09:34:02 | [av]bani | an integer only mp3 player (mp3play) which runs on the 5249. |
| 09:34:02 | [av]bani | Although it needs some optimizations to play higher bit rate |
| 09:34:02 | DBUG | Enqueued KICK [av]bani |
| 09:34:02 | [av]bani | mp3s in real time (I have played with this and have it working, |
| 09:34:04 | [av]bani | just not in uClinux dist currently)." |
| 09:34:10 | [av]bani | :D |
| 09:34:36 | Bagder | nice |
| 09:36:10 | [av]bani | "For toolchains I use the uClinux m68k-elf toolchain (this is |
| 09:36:10 | [av]bani | just gcc-2.95.3 and binutils-2.14 with a couple of patches). |
| 09:36:10 | [av]bani | Follow the links for tool chains from: |
| 09:36:10 | [av]bani | http://www.uclinux.org/pub/uClinux/dist/ |
| 09:36:19 | [av]bani | This toolchain is in extensive use on ColdFire platforms, it |
| 09:36:19 | [av]bani | is well tested and generates quite reasonable code. |
| 09:36:26 | LinusN | the problem is the encoder |
| 09:36:38 | [av]bani | In terms of CPU and platform support get the latest uClinux-dist |
| 09:36:38 | [av]bani | source code package (from the above link) and start there. |
| 09:36:38 | [av]bani | From the top level if you run "make xconfig" you can select the |
| 09:36:38 | *** | Alert Mode level 1 |
| 09:36:38 | [av]bani | Motorola/M5249C3 target and compile an image (combined kernel |
| 09:36:38 | *** | Alert Mode level 2 |
| 09:36:38 | [av]bani | and root filesystem) that is ready to run on the M5249C3 board. |
| 09:36:38 | *** | Alert Mode level 3 |
| 09:36:38 | [av]bani | It is very easy. |
| 09:37:13 | [av]bani | linus, integerized asm mp3 encoders abound for 68k |
| 09:37:35 | [av]bani | atari and amiga having been quite heavily abused by demo coders :) |
| 09:37:43 | Zagor | my first option is the MAD decoder. it's pretty fast but above all Really Realy Good. |
| 09:38:10 | [av]bani | anyone confirmed if the array of pads on the left is the bdm? |
| 09:38:36 | LinusN | konrad and friends say so |
| 09:38:54 | LinusN | but it's easier to solder on the marked pads on the pcb |
| 09:38:57 | [av]bani | it must be so! :) |
| 09:39:12 | [av]bani | well, if there's a socket that can match the pads... |
| 09:39:27 | LinusN | [av]bani: you have seen fast mp3 encoders for 68k? |
| 09:39:32 | [av]bani | yes |
| 09:39:34 | Zagor | [av]bani: if you can find a nice integer encoder with free (libre) source, please toss it this way |
| 09:40:12 | Zagor | we're out of the amiga scene since, oh, about a decade ;) |
| 09:40:18 | [av]bani | i assume nobody's actually got a working bdm to the ihp yet though |
| 09:40:31 | LinusN | i've only made one demo for the amiga, and that didn't include an mp3 encoder :-) |
| 09:42:04 | [av]bani | and correct me if i'm wrong, the ISSI 4C01-3G can't possibly be a config rom for the cypress usb bridge |
| 09:42:14 | LinusN | why not? |
| 09:42:28 | [av]bani | the datasheet requires minimum 256bytes config space |
| 09:42:43 | [av]bani | 1kbit = 128 bytes |
| 09:43:33 | [av]bani | and on top of that, where would the ihp's persistent data be stored then? |
| 09:44:02 | [av]bani | i'm guessing the 1kbit is for the ihp, and the actual cypress config rom is on the underside of the board |
| 09:44:17 | LinusN | perhaps |
| 09:44:20 | Zagor | LinusN: it's time to remove the usb daughterboard |
| 09:44:27 | Zagor | :) |
| 09:44:31 | LinusN | i'll do a LA trace of the i2c data |
| 09:44:52 | [av]bani | yes, someone needs to get scans of the underside |
| 09:44:54 | [av]bani | (s) |
| 09:45:02 | [av]bani | i'm guessing there are more chips hiding |
| 09:45:15 | LinusN | certainly |
| 09:45:39 | [av]bani | fwiw the LCDs with 6800 interface are good candidates, since 68k works natively with 6800 peripherals |
| 09:46:06 | Zagor | my bet is on the solomon |
| 09:46:06 | [av]bani | they can easily be mapped into the cpu's address space |
| 09:46:15 | [av]bani | trivial |
| 09:46:39 | *** | Alert Mode OFF |
| 09:46:44 | Zagor | if they use parallell access, yes. archos didn't. |
| 09:46:55 | Zagor | (not that serial is hard either, of course) |
| 09:47:03 | [av]bani | andi denied it, though they didnt answer my followup questions |
| 09:47:14 | [av]bani | i just told them iwanted a replacement lcd for a busted ihp :) |
| 09:47:36 | [av]bani | and if they had an equivalent part |
| 09:47:41 | Zagor | [av]bani: ah you are Dan Hollis? |
| 09:47:48 | [av]bani | yeh |
| 09:47:57 | Zagor | ah, good |
| 09:48:14 | Zagor | good digging |
| 09:50:41 | [av]bani | hmm, serial would preclude any readback access to the lcd |
| 09:50:49 | [av]bani | blind writes... |
| 09:51:40 | [av]bani | would be kind of silly to pick an lcd controller with 6800 interface and not use it |
| 09:51:43 | LinusN | why would you want to read from the lcd? |
| 09:51:48 | [av]bani | but who knows what those koreans think :) |
| 09:51:59 | [av]bani | read from the controller... |
| 09:52:15 | LinusN | why would you want to read from the controller |
| 09:52:20 | [av]bani | status bits, etc |
| 09:52:31 | [av]bani | shrug |
| 09:52:43 | Zagor | we've managed fine with just writing so far :) |
| 09:53:57 | [av]bani | yeah, though higher performance would likely be possible on parallel |
| 09:54:11 | [av]bani | not to mention lower cpu usage to drive it |
| 09:54:16 | [av]bani | vs bit banging it out |
| 09:54:26 | Zagor | absolutely |
| 09:54:33 | LinusN | yes, of course, i just don't see why reading the controller is a benefit |
| 09:54:53 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 09:54:53 | [av]bani | synchronization, if the controller equires it |
| 09:55:07 | [av]bani | depends on the lcd, imho its quite likely for color LCDs |
| 09:55:15 | [av]bani | ihp-3xx |
| 09:55:33 | LinusN | you probably know more about lcd's than i do |
| 09:55:36 | [av]bani | pretty unlikely its serial interface on that :) |
| 09:55:41 | LinusN | :-) |
| 09:56:14 | [IDC]Dragon | 'morning guys! |
| 09:56:21 | LinusN | morning |
| 09:56:22 | [av]bani | nobody got working bdm yet though? |
| 09:57:01 | Zagor | not yet. our pod is in the mail. |
| 09:57:31 | LinusN | it will take a few days before i get it |
| 09:57:39 | [av]bani | hm, the ssd1845 has a status register |
| 09:57:47 | [av]bani | one of the bits indicates if the controller is busy or not |
| 09:57:53 | [av]bani | could be important, or not :) |
| 09:59:33 | [av]bani | somoene should trace the lcd connections so its easier to make a match to a datasheet |
| 10:00 |
| 10:00:09 | Zagor | it's difficult to trace the cpu, being a bga |
| 10:00:36 | Zagor | that's why we are looking for a broken device, where we can remove the cpu |
| 10:01:08 | Zagor | doesn't look like we are going to find any broken ones though, iriver appears to be very nice about replacing broken units |
| 10:01:29 | [IDC]Dragon | have you checked if the LCD is connected to the bus? |
| 10:01:37 | [IDC]Dragon | e.g. at the SDRAM? |
| 10:01:47 | [av]bani | well yeah, tracing where the lcd goes to... |
| 10:01:47 | LinusN | no |
| 10:02:18 | LinusN | [IDC]Dragon: good idea, didn't think of that |
| 10:03:12 | [av]bani | well itll go into some kind of glue chip |
| 10:03:56 | | Join LePoulpe303 [0] (~lpos@AMontpellier-251-1-35-39.w83-113.abo.wanadoo.fr) |
| 10:03:58 | [av]bani | and if its off the shelf part (likely) then you can know how its interfaced |
| 10:04:03 | [av]bani | and possibly, work out the lcd from that |
| 10:04:24 | [av]bani | just need to take off that daughterboard :) |
| 10:05:05 | LinusN | i doubt that the daughterboard has anything to do with the lcd |
| 10:05:33 | LinusN | it doesn't make any sense to have the lcd signal path go all that way |
| 10:08:12 | Ctcp | Ignored 2 channel CTCP requests in 2 hours and 31 minutes at the last flood |
| 10:08:12 | * | [IDC]Dragon is master of tracing PCBs ;-) |
| 10:15:01 | [IDC]Dragon | Bagder: do you read? |
| 10:15:08 | Bagder | I do |
| 10:15:52 | [IDC]Dragon | in my overly excitement I was thinking if we should already include the Ondio in the daily build |
| 10:16:04 | [IDC]Dragon | the get those colors :-) |
| 10:16:10 | [IDC]Dragon | to get ... |
| 10:16:20 | Bagder | yes, we could start with including it in the build table |
| 10:17:06 | Bagder | I'll set it up |
| 10:17:08 | [IDC]Dragon | the Neo is in there too |
| 10:17:16 | [IDC]Dragon | but an orphan |
| 10:17:25 | LinusN | we should remove the neo |
| 10:17:46 | LinusN | until someone that cares joins the team |
| 10:18:09 | [IDC]Dragon | the Ondio has two flavours, as you probably know, SP and FM |
| 10:18:21 | Bagder | yes, I've noticed |
| 10:18:41 | Bagder | the plugins/lib doesn't build |
| 10:18:57 | [IDC]Dragon | ah, yes |
| 10:19:05 | [IDC]Dragon | I forgot |
| 10:19:08 | Bagder | but that'll show up ;-) |
| 10:19:12 | [av]bani | anyone poked at the xclef yet? |
| 10:19:16 | [IDC]Dragon | better not include it then |
| 10:19:23 | LinusN | [av]bani: nope |
| 10:19:58 | Bagder | [IDC]Dragon: we'll fix that quirk sooner if it shows up red! |
| 10:20:31 | [IDC]Dragon | Bagder: amiconn has an uncommitted fix for the plugin make, but then lots of plugins don't build because of the limited keypad |
| 10:20:50 | Bagder | ok |
| 10:21:12 | [IDC]Dragon | but currently, plugins make no sense. We first need disk I/O |
| 10:21:18 | Bagder | I agree |
| 10:21:59 | Bagder | they build ajbrec.ajz files, right? |
| 10:22:05 | [IDC]Dragon | yes |
| 10:22:28 | Bagder | added |
| 10:22:44 | Bagder | after next commit there should be two new columns in the table |
| 10:22:46 | [IDC]Dragon | no useable .ucl yet ;-) |
| 10:22:54 | [IDC]Dragon | whow, that was quick! |
| 10:23:25 | Bagder | the build system is actually quite nicely written to allow easily adding new ones |
| 10:23:34 | [av]bani | the bdm you purchased, works with gdb? |
| 10:23:39 | LinusN | yes |
| 10:23:44 | [av]bani | yay |
| 10:23:46 | [av]bani | which one? |
| 10:23:49 | LinusN | that's why we bought it |
| 10:24:11 | LinusN | we have a wiggler, but we need to write drivers for it |
| 10:24:18 | [av]bani | :o |
| 10:24:24 | LinusN | we bought a p&e wiggler |
| 10:24:26 | [IDC]Dragon | is there some "real" hardware in it, or just a printer port adapter? |
| 10:24:43 | [av]bani | if its cheap, its likely just parallel port :) |
| 10:24:44 | LinusN | theres a 16V8 PAL |
| 10:24:47 | LinusN | on it |
| 10:24:54 | [av]bani | buffers likely |
| 10:24:54 | [IDC]Dragon | :-( |
| 10:25:21 | LinusN | the wiggler we have is just an LPT adapter with buffers for voltage diffs |
| 10:26:08 | LinusN | the p&e wiggler contains some extra logic for BKPT timing and singlestepping |
| 10:26:26 | LinusN | we have schematics and PAL descriptions for it |
| 10:26:40 | LinusN | but we don't feel like wasting time building one |
| 10:27:09 | LinusN | when we can use the donated money buying one instead |
| 10:27:55 | [av]bani | http://www.ucdot.org/article.pl?sid=04/01/20/014230&mode=thread |
| 10:28:02 | LinusN | [IDC]Dragon: how about ondio schematics? |
| 10:29:01 | LinusN | [av]bani: yes. too bad their project doesn't have a driver for the macraigor wiggler |
| 10:29:22 | LinusN | (the wiggler we have is a macraigor) |
| 10:29:37 | [av]bani | looks like it 'almos works' with the p&e |
| 10:29:39 | [IDC]Dragon | LinusN: too much work, imho not worth the effort |
| 10:29:57 | [IDC]Dragon | what we really needed is the port assignment |
| 10:30:15 | LinusN | i agree |
| 10:30:27 | [IDC]Dragon | I care only about the programmable part, not how it regulates power, etc. |
| 10:30:53 | [av]bani | ooh |
| 10:30:59 | [av]bani | http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver-old.html |
| 10:31:54 | [av]bani | if its implemented like the gal16v8 on that page, then i guess gdb already works with it |
| 10:32:42 | [IDC]Dragon | I worked a lot with GALs a dozen years ago |
| 10:32:48 | [av]bani | The new experimental version for gdb-4.18 is based on latest Magin's code and contains all my changes for the Linux 2.2.x support and better timing ( at least I hope so ). This version can be foud in the archive gdb-4.18-bdm-patches-pi1.tar.gz. There is an initial version of the ispGAL22V8 based EFICD, as well. |
| 10:33:56 | LinusN | gdb 4.18, that's old |
| 10:34:19 | [av]bani | then presumably it's been finished by now :) |
| 10:37:51 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 10:45:38 | [av]bani | woo |
| 10:46:45 | | Quit midk (Read error: 113 (No route to host)) |
| 10:47:05 | [av]bani | http://cmp.felk.cvut.cz/~pisa/#m683xx |
| 10:47:08 | [av]bani | any of those suitable? |
| 10:48:18 | *** | Saving seen data "./dancer.seen" |
| 10:49:07 | LinusN | the ones on http://sourceforge.net/projects/bdm will probably do just fine |
| 10:49:18 | LinusN | if you mean bdm drivers |
| 10:50:27 | * | LinusN just wrote his first PIC assembly code |
| 10:50:36 | [av]bani | :o |
| 10:52:59 | [IDC]Dragon | it's a horrible architecture, I prefer Atmel |
| 10:53:32 | Bagder | ok, now hopefully ondio builds will come around in... 5 minutes or so |
| 10:53:34 | LinusN | i have had a look at atmel, and so far i agree |
| 10:53:48 | [IDC]Dragon | (bank-switching already wit 128 bytes, brr) |
| 10:54:27 | [IDC]Dragon | Bagder: you committed something, to force a build? |
| 10:54:34 | Bagder | yes |
| 10:54:39 | Bagder | minor docs fix |
| 10:54:58 | [IDC]Dragon | hehe, our docs now benefit fromthe Ondio |
| 10:55:05 | Bagder | :-) |
| 10:55:06 | | Part [av]bani |
| 11:00 |
| 11:06:31 | [IDC]Dragon | Bagder: I see the Ondio :-) |
| 11:06:34 | Bagder | me too |
| 11:06:42 | Bagder | but they aren't red as they should be |
| 11:06:57 | [IDC]Dragon | ohhh |
| 11:07:20 | [IDC]Dragon | the general order of the columns is a bit weird |
| 11:07:40 | Bagder | its sorted alphabetically |
| 11:07:48 | [IDC]Dragon | ah |
| 11:07:54 | Bagder | but we should change that |
| 11:08:11 | Bagder | and I'll look into why they don't turn red |
| 11:08:42 | [IDC]Dragon | there's plenty of error in the log |
| 11:08:48 | Bagder | yes |
| 11:09:17 | [IDC]Dragon | and you need a pretty picture |
| 11:09:40 | [IDC]Dragon | for the zip part above |
| 11:09:53 | Bagder | yeps |
| 11:10:00 | | Join pillo [0] (~trillian@navlab03.dei.unipd.it) |
| 11:10:00 | | Quit pillo (Remote closed the connection) |
| 11:10:56 | | Join pillo [0] (~trillian@navlab03.dei.unipd.it) |
| 11:17:08 | Bagder | better |
| 11:19:36 | [IDC]Dragon | worse :-/ |
| 11:20:03 | Bagder | hehe |
| 11:20:34 | [IDC]Dragon | it even re-colored some old build |
| 11:20:52 | Bagder | yes, I found a parser flaw |
| 11:21:17 | Bagder | it missed that warning before |
| 11:21:23 | [IDC]Dragon | oops |
| 11:22:38 | [IDC]Dragon | how about access to the compile result? (zip) |
| 11:23:37 | Bagder | that's separate |
| 11:24:12 | Bagder | I'll fix that later, I need to go now |
| 11:25:35 | [IDC]Dragon | sure |
| 11:25:38 | [IDC]Dragon | thanks |
| 11:26:51 | Bagder | that number "30" should keep you busy :-) |
| 11:26:56 | Bagder | see ya around |
| 11:26:59 | | Quit Bagder ("Leaving") |
| 11:29:12 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 11:39:42 | amiconn | [IDC]Dragon: We'll actually need two images for the zip builds. In addition to the different marking, the top part of the SP case is violet, while the FM seems to have a blue top part of the case |
| 11:51:40 | | Join Lynx_ [0] (lynx@134.95.189.59) |
| 12:00 |
| 12:25:18 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
| 12:33:42 | [IDC]Dragon | hi Jens |
| 12:33:53 | [IDC]Dragon | just got back from lunch |
| 12:34:55 | [IDC]Dragon | Daniel will probably ask us to photograph our boxes, while showing Rockbox logo, on gray background |
| 12:41:38 | [IDC]Dragon | aniconn: he, you've traded the 30 errors with 84 errors 2 warnings |
| 12:42:01 | Zagor | ooh, nice trade ;) |
| 12:46:19 | [IDC]Dragon | clearcase installation forces me to reboot |
| 12:46:27 | | Part LinusN |
| 12:46:46 | | Part [IDC]Dragon |
| 12:47:41 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 12:48:22 | *** | Saving seen data "./dancer.seen" |
| 12:53:37 | | Join webguest05 [0] (~d9e8e020@labb.contactor.se) |
| 12:55:06 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 13:00 |
| 13:06:47 | | Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 13:08:38 | | Quit webguest05 ("CGI:IRC (Ping timeout)") |
| 13:38:08 | | Quit [IDC]Dragon (leguin.freenode.net irc.freenode.net) |
| 13:38:08 | NSplit | leguin.freenode.net irc.freenode.net |
| 13:38:08 | dwihno | are there any ways to make gcc remove all unused code when compiling? |
| 13:38:08 | Zagor | put the code in libs |
| 13:38:58 | dwihno | it only includes used stuff then? |
| 13:39:01 | NHeal | leguin.freenode.net irc.freenode.net |
| 13:39:01 | NJoin | [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 13:39:05 | Zagor | yes |
| 13:39:05 | dwihno | neato :D |
| 13:39:11 | dwihno | ranlib something something all .o, something something? |
| 13:40:03 | Zagor | ar, not ranlib |
| 13:40:32 | dwihno | hm |
| 13:40:53 | Zagor | see firmware/Makefile |
| 13:59:33 | webmind_ | my archos has become obsolete.. now what to do with the remains... |
| 13:59:46 | | Nick webmind_ is now known as webmind (~random@217-195-236-172.dsl.esined.net) |
| 14:00 |
| 14:00:07 | Zagor | which model is it? |
| 14:04:48 | Zagor | yikes, 160x128 is a lot bigger than 112x64... |
| 14:05:27 | Zagor | 15 lines + statusbar with default font... |
| 14:15:35 | [IDC]Dragon | webmind: send it to me, I have a little junkyard |
| 14:16:44 | webmind | Zagor, player |
| 14:16:47 | webmind | studio 20 |
| 14:21:20 | dwihno | Yum! Huge screen! Me likey! |
| 14:22:10 | Zagor | i think we'll be getting more demands for pretty icons |
| 14:22:50 | dwihno | Text interface forever! :) |
| 14:23:05 | [IDC]Dragon | voice interface forever! |
| 14:23:09 | Zagor | :) |
| 14:24:38 | dwihno | :-) |
| 14:25:06 | [IDC]Dragon | dwihno has a longer nose than Zagor |
| 14:25:22 | dwihno | :-¨¨) |
| 14:25:27 | * | dwihno is having a cold |
| 14:25:30 | dwihno | Damn it sucks :( |
| 14:31:05 | * | ripnetUK dreams of a Rockbox user defined WPS on my iRiver |
| 14:32:34 | ripnetUK | in theory, the iRiver /SHOULD/ be able to support a gameboy emu :) how cool would that be... |
| 14:33:08 | Zagor | I haven't even begun thinking about all the fun stuff we can do with this hardware :) |
| 14:33:39 | Zagor | lots of cpu, grayscale graphics, pcm sound. there possibilities are massive. |
| 14:35:28 | LinusN | first, we should try to execute our first CPU instruction :-) |
| 14:35:34 | ripnetUK | hehe |
| 14:36:16 | dwihno | Dreamwrecker :) |
| 14:37:06 | ripnetUK | so i guess the citical thing holding us up is that we need to know how to recover from a bad flash? using the debug BDM interface? i know nothing about that - is that a way of taking control of the bus externally (like a xbox mod chip) to inject our own code? |
| 14:37:15 | | Join ashridah [0] (~ashridah@icculus.org) |
| 14:37:23 | Zagor | http://bjorn.haxx.se/h100-boot.png |
| 14:37:43 | ripnetUK | zagor - tease :) |
| 14:37:50 | ashridah | heh. emulated progress? :) |
| 14:38:37 | Zagor | yup |
| 14:38:50 | [IDC]Dragon | my Ondio picture is for real :) |
| 14:38:56 | Zagor | hehe |
| 14:40:12 | LinusN | ripnetUK: i don't know of any other way than the bdm |
| 14:41:33 | Zagor | we're basically treading water in the code execution department until the bdm pod we've ordered arrives |
| 14:41:38 | ripnetUK | i dont know anything about bdm - is it a standard debug interface |
| 14:41:47 | Zagor | so some of us are playing with the sim instead :) |
| 14:42:13 | ripnetUK | (daft question - i know how to google!) |
| 14:42:44 | Zagor | http://bjorn.haxx.se/h100-browser.png |
| 14:43:16 | LinusN | ripnetUK: Background Debug Mode, a builtin debug interface in the CPU |
| 14:43:47 | ripnetUK | aha - looks like they start at $500ish ... |
| 14:44:01 | LinusN | rather $150ish |
| 14:44:14 | dwihno | Zagor: wee! big screen :) |
| 14:44:15 | ripnetUK | cool |
| 14:44:19 | dwihno | Zagor: me likey |
| 14:44:25 | dwihno | Imagine prop font on that one :) |
| 14:44:37 | ripnetUK | looks good |
| 14:44:47 | * | ashridah would be decidedly happy if a clock actually works (and maintains time, but somehow i doubt that) with the iriver h1xx using rockbox |
| 14:45:32 | ripnetUK | so basically if u get a bad flash, you would use bdm pod to upload a flash routine and a boot loader? even if the flash was totally broke? |
| 14:45:35 | Zagor | yeah, that'll be rather difficult... |
| 14:46:01 | Zagor | (clock) |
| 14:46:14 | ashridah | mm. i imagine without a cmos-alike and a timer to keep it ticking it's a pipedream |
| 14:46:18 | ashridah | pity |
| 14:46:19 | LinusN | ripnetUK: yes, we can recover from a bad flash with the bdm |
| 14:46:52 | LinusN | some people at miticriver seem to think that a real time clock is the key to good shuffling :-) |
| 14:46:54 | ripnetUK | and I guess verify that your code is acutally running before you know the LED registers etc |
| 14:47:45 | ashridah | LinusN: some of the people at misticriver think that the delays in firmware releases are a conspiracy, and that it's grounds for a class action suit |
| 14:47:57 | LinusN | lol |
| 14:48:01 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 14:48:14 | Zagor | haha, grounds how? irreparable damage? |
| 14:48:23 | *** | Saving seen data "./dancer.seen" |
| 14:48:29 | LinusN | current bdm wiggler location: Newark |
| 14:48:41 | Zagor | LinusN: :) |
| 14:48:54 | ashridah | nevermind that they can't prove damages, and at worst, it's an advertising misdemeanor, and that's ONLY if they never had any intension of actually delivering |
| 14:49:19 | ashridah | if they did, but were unavoidably delayed by circumstances outside their control, bye bye suit. |
| 14:49:34 | ripnetUK | lawsuit indeed :) rotfl |
| 14:51:36 | Zagor | Bagder: have you given any thought to how you'd like to see the simulator config system (or lack thereof) expanded? I now need LCD_WIDTH and HAVE_RTC and a bunch of other stuff. we should think about a good solution. |
| 14:52:15 | Bagder | I think we need to make it use the config-*.h files |
| 14:52:49 | | Quit lImbus (Remote closed the connection) |
| 14:52:52 | Zagor | thus having #ifdef SIMULATOR in the config files or in the code? |
| 14:53:20 | Bagder | no, but having LCD_WIDTH in the config-*.h files |
| 14:53:41 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
| 14:54:09 | Zagor | yeah, that I've done already. i'm just thinking setting all those HAVE_ means a lot of hardware-specific code will be compiled. but maybe it works good enough. |
| 14:55:46 | Bagder | let's start from there |
| 14:55:50 | Zagor | yup |
| 14:58:38 | Bagder | the reason we didn't do it before was my desire to allow "weird" mixing of features |
| 14:58:45 | Bagder | when doing simulation builds |
| 14:59:06 | Bagder | but I now no longer think it is sensible |
| 15:00 |
| 15:02:07 | ripnetUK | surely we need to have a variable, not a #define for lcd_width, especially as the iRiver has two lcd_widths (for main and remote LCDs) |
| 15:03:01 | Bagder | we still need a buffer etc |
| 15:03:08 | Bagder | it can't be based on a variable |
| 15:03:13 | ripnetUK | of course! no malloc |
| 15:03:38 | Bagder | malloc wouldn't make a difference for this, as I see it |
| 15:04:35 | Zagor | the double display problem is hairy. it won't be solved immediately... |
| 15:04:58 | Bagder | my gut reaction is that they should be treated as two screens |
| 15:05:13 | Zagor | we do not only need two displays, with two buffers. we also need to run all rendering code twice! |
| 15:05:34 | Zagor | ...and that's just no fun :) |
| 15:07:15 | Zagor | so this will happen one step at a time. first setting up the simulators for more varying configs. then allowing dynamic display size changes (which will break plugins). then, later, we'll start thinking of dual displays. |
| 15:07:46 | Bagder | yes, I think the first step could be made on the primary single display |
| 15:07:53 | Zagor | yup |
| 15:08:51 | | Quit midk ("just STOP it arspy") |
| 15:09:54 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 15:10:35 | Zagor | Bagder: did you see this http://bjorn.haxx.se/h100-browser.png |
| 15:10:42 | ripnetUK | it IS fun :) looking (way) forward, I will want 2 seperate WPS configs for remote and main |
| 15:10:54 | Bagder | Zagor: mucho neato |
| 15:11:05 | Bagder | ripnetUK: I agree |
| 15:11:07 | LinusN | and different fonts for the two |
| 15:11:11 | midk | haha, very cool |
| 15:11:11 | Bagder | that too |
| 15:11:25 | Bagder | LinusN: but we'd solve that with font-support in the wps config |
| 15:11:34 | Bagder | imho |
| 15:11:38 | LinusN | good idea |
| 15:12:00 | Zagor | not quite. we'd also need support for >1 loaded font |
| 15:12:14 | Bagder | right, but I meant the choosing of which font where |
| 15:12:23 | Zagor | ok |
| 15:13:11 | ripnetUK | regarding http://bjorn.haxx.se/h100-browser.png - the iRiver has a BLUE backlight :) too cool to not have in the sim |
| 15:13:26 | Zagor | hehe, me fix |
| 15:13:35 | Bagder | hahaha |
| 15:14:04 | Bagder | any pretty-picture(s) of the Ondio(s) around? |
| 15:14:12 | Bagder | (for the daily-build) |
| 15:14:21 | Zagor | there the big one in the wiki |
| 15:15:39 | Bagder | I'll annoy Jörg and Jens when they get around |
| 15:16:22 | Zagor | but i don't think we should have it in the top daily list until it runs reasonably well |
| 15:16:34 | Zagor | the bleeding list though |
| 15:17:59 | Bagder | makes sense |
| 15:19:03 | | Quit ashridah ("leaving") |
| 15:22:25 | [IDC]Dragon | Bagder: I'm around |
| 15:22:39 | [IDC]Dragon | but not my Ondio |
| 15:22:42 | Bagder | hehe |
| 15:23:11 | Bagder | well, whenever you get time, make a clear shot of the Ondio for the daily stuff |
| 15:23:37 | [IDC]Dragon | sure |
| 15:24:04 | Bagder | daily Ondio builds start tomorrow, but there is no links provided for them just yet |
| 15:24:05 | [IDC]Dragon | the first image on the wiki pake has one |
| 15:24:23 | [IDC]Dragon | s/pake/page |
| 15:24:33 | Bagder | I know, but it is just so close to the recorder |
| 15:24:39 | [IDC]Dragon | but with my JBR next to it |
| 15:24:41 | Bagder | it would be better with a more stand-alone |
| 15:25:01 | [IDC]Dragon | how did you do the others? (background) |
| 15:25:10 | Bagder | LinusN made them I believe |
| 15:25:19 | LinusN | i used my flatbed scanner |
| 15:25:59 | LinusN | the background was a white sheet of paper |
| 15:26:01 | midk | very cool daily builds page now |
| 15:26:03 | [IDC]Dragon | for this icon-ish picture we need no 1200 dpi, I think |
| 15:26:21 | LinusN | look at the device comparison page |
| 15:26:30 | LinusN | the pics are clickable |
| 15:26:51 | Bagder | midk: yes, I like the new look too |
| 15:27:15 | [IDC]Dragon | oh, I need to run Rockbox 2.2 for the photo |
| 15:27:24 | LinusN | :-) |
| 15:27:49 | midk | i think it would be nice to have an archive of daily build tarballs and/or released packages, but that would probably take up a lot of space |
| 15:28:05 | Bagder | now check the bleeding edge box |
| 15:28:18 | Bagder | ondio ajbrec links |
| 15:28:45 | midk | you should span them over the two that were previously empty |
| 15:28:50 | [IDC]Dragon | ah, nice |
| 15:28:54 | midk | instead of making the recorder column longer |
| 15:28:57 | midk | imo. |
| 15:29:10 | Bagder | ok then ;-) |
| 15:29:26 | [IDC]Dragon | I can remove the .ajz from the twiki page then |
| 15:29:33 | Bagder | yes |
| 15:31:50 | Bagder | want me to disable the plugin build for the Ondio? |
| 15:36:39 | | Join hiolo [0] (Lupettino@host178-121.pool80182.interbusiness.it) |
| 15:37:45 | [IDC]Dragon | by doing what? |
| 15:37:56 | Bagder | if'ing in the makefile |
| 15:38:25 | [IDC]Dragon | yes, I think it's better for now |
| 15:38:57 | Bagder | ok, done |
| 15:39:04 | [IDC]Dragon | thanks |
| 15:39:12 | [IDC]Dragon | (no cvs here) |
| 15:39:29 | [IDC]Dragon | (firewalled) |
| 15:39:37 | | Quit hiolo (Excess Flood) |
| 15:40:04 | [IDC]Dragon | btw, I like the new, brief make output |
| 15:40:25 | Bagder | it makes it easier to detect actual problems |
| 15:40:29 | [IDC]Dragon | with the old, flooding one I regulary overlooked warnings |
| 15:40:34 | Bagder | yes |
| 15:40:38 | Bagder | I agree |
| 15:40:47 | [IDC]Dragon | unless I did make > /dev/null |
| 15:40:59 | Bagder | that's my primary reason for doing this new output |
| 15:45:32 | [IDC]Dragon | builds green now :-) |
| 15:45:48 | Bagder | green is nice |
| 15:46:02 | [IDC]Dragon | looks friendly |
| 15:47:03 | Bagder | I'll cut off the seconds part from the batch time |
| 15:47:53 | [IDC]Dragon | ? |
| 15:48:10 | Bagder | to narrow the batch column |
| 15:48:52 | [IDC]Dragon | not showing the build time any more? |
| 15:49:06 | Bagder | not the seconds field, hour:minute is good enough |
| 15:49:08 | Zagor | 09:40 instead of 09:40:00 |
| 15:49:14 | [IDC]Dragon | ah, yes |
| 15:55:24 | [IDC]Dragon | I don't know how to "attract" Ondio users. So far, onlyJens and I have tried it. |
| 15:55:45 | [IDC]Dragon | (it=running ROckbox, checking hardware mask) |
| 15:56:03 | | Quit LePoulpe303 (Read error: 232 (Connection reset by peer)) |
| 15:56:18 | Bagder | perhaps posting on the two user forums could help |
| 15:57:01 | [IDC]Dragon | which forums? |
| 15:57:05 | * | Bagder hears a little girl waking up the next room |
| 15:57:13 | LinusN | yahoo and newmp3tech |
| 15:57:25 | Bagder | see ya |
| 15:57:26 | [IDC]Dragon | oh, I typed too loud |
| 15:57:27 | | Quit Bagder ("Leaving") |
| 15:57:38 | LinusN | and on the rockbox front page |
| 15:57:46 | [IDC]Dragon | maybe i use too much upper case |
| 15:58:07 | LinusN | gotta go, cu around |
| 15:58:07 | Zagor | which is the lesser evil: adding #ifdef SIMULATOR to the config-xxx.h files or adding lots of new #ifdef SIMULATOR in the drivers etc? |
| 15:58:35 | LinusN | i think you will need both |
| 15:59:01 | Zagor | gee thanks :) |
| 15:59:13 | LinusN | HAVE_RTC, for example, may have a simulated RTC component |
| 15:59:59 | LinusN | so you will end up defining HAVE_SIM_RTC or something in the config file |
| 16:00 |
| 16:00:11 | LinusN | and still have ifdefs in the drivers |
| 16:00:17 | LinusN | or did i miss something? |
| 16:00:32 | Zagor | no if we have a simulated driver, the config file has nothing special. there will just be an #ifdef in the driver |
| 16:01:27 | Zagor | this is more of a transition problem, since up to now the code has never been compiled with for example HAVE_MAS3587F and SIMULATOR at the same time |
| 16:01:30 | LinusN | the config file tells which hardware/features exist on the target, SIMULATOR tells if it should be simulated or not |
| 16:02:04 | LinusN | gotta run |
| 16:02:07 | | Part LinusN |
| 16:02:07 | Zagor | ...which means you advocate leaving the config files untouched and solving it in the code? |
| 16:02:08 | Zagor | ok byte |
| 16:02:11 | Zagor | bye even |
| 16:02:49 | Zagor | i don't think I want to solve this right now, so I'll #ifdef the config files |
| 16:03:29 | [IDC]Dragon | config hell. I wonder how other projects do this, with a lot of variants |
| 16:04:04 | Zagor | pretty much like this. "config.h" is usually autogenerated by a configure script. |
| 16:04:29 | [IDC]Dragon | imho, we have way too many #ifdef SIMULATOR in the code |
| 16:04:51 | [IDC]Dragon | which indicates a bad (incomplete) simulation layer |
| 16:05:12 | [IDC]Dragon | or, not enough hardware abstraction |
| 16:05:13 | Zagor | well we need simulated code. the other option is to have that code moved into separate files, but that means lots of code duplication instead. again: which is the lesser evil... |
| 16:06:12 | Zagor | we have never aimed for hardware abstraction. it rarely works well. |
| 16:06:49 | [IDC]Dragon | well, we have the driver "layer". |
| 16:07:16 | [IDC]Dragon | exchanging the driver with a sim that provides the same interface will work then,. |
| 16:07:28 | Zagor | yes, that is what we do |
| 16:07:53 | [IDC]Dragon | interesting days for Rockbox |
| 16:20:45 | | Join GhUl [0] (~tim@pD9FF1928.dip.t-dialin.net) |
| 16:25:54 | | Join methangas [0] (methangas@0x50a476b2.virnxx10.adsl-dhcp.tele.dk) |
| 16:34:18 | | Nick grogro is now known as gromit` (~gromit@ALagny-151-1-22-167.w83-114.abo.wanadoo.fr) |
| 16:46:12 | | Join mecraw_ [0] (~lmarlow@69.2.235.2) |
| 16:48:26 | *** | Saving seen data "./dancer.seen" |
| 16:49:52 | | Join LePoulpe303 [0] (~lpos@AMontpellier-251-1-35-39.w83-113.abo.wanadoo.fr) |
| 16:50:19 | | Quit LePoulpe303 (Read error: 104 (Connection reset by peer)) |
| 16:51:01 | | Join LePoulpe303 [0] (~lpos@AMontpellier-251-1-35-39.w83-113.abo.wanadoo.fr) |
| 17:00 |
| 17:19:21 | | Part Zagor |
| 17:20:02 | | Join PaulS [0] (~437e19f6@labb.contactor.se) |
| 17:20:48 | PaulS | It's kinda sad that it apears that LinusN and I are never awake at the same time.. :-) |
| 17:24:46 | | Quit PaulS (Client Quit) |
| 18:00 |
| 18:04:41 | | Quit lImbus (Remote closed the connection) |
| 18:05:47 | | Quit GhUl (Read error: 60 (Operation timed out)) |
| 18:06:34 | | Part [IDC]Dragon |
| 18:30:16 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
| 18:30:31 | | Quit mecraw_ (Read error: 104 (Connection reset by peer)) |
| 18:31:30 | | Quit lImbus (Remote closed the connection) |
| 18:35:21 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
| 18:42:32 | | Part pillo |
| 18:47:50 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
| 18:48:27 | *** | Saving seen data "./dancer.seen" |
| 18:51:05 | | Quit AciD (Remote closed the connection) |
| 18:52:41 | | Join _aLF [0] (~alex@mutualite-3-82-67-66-128.fbx.proxad.net) |
| 18:52:43 | _aLF | hi |
| 18:55:18 | | Part lImbus |
| 18:55:41 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 19:00 |
| 19:25:50 | | Join dreed [0] (~45912877@labb.contactor.se) |
| 19:25:56 | | Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!") |
| 19:29:59 | | Join R3nTiL [0] (~zorroz@164-250-30-217.kgts.ru) |
| 19:30:35 | | Quit dreed (Client Quit) |
| 19:45:07 | | Join webguest26 [0] (~4128f37f@labb.contactor.se) |
| 19:46:03 | | Quit webguest26 (Client Quit) |
| 19:57:47 | | Quit R3nTiL () |
| 19:59:33 | | Quit ripnetUK () |
| 20:00 |
| 20:33:34 | | Quit _aLF (Read error: 54 (Connection reset by peer)) |
| 20:35:48 | | Join _aLF [0] (~alex@mutualite-3-82-67-66-128.fbx.proxad.net) |
| 20:43:26 | | Quit AciD (Read error: 60 (Operation timed out)) |
| 20:44:58 | amiconn | I am silly... |
| 20:47:21 | amiconn | Note to self: check both schematics and current source before getting excited about some finding |
| 20:48:29 | *** | Saving seen data "./dancer.seen" |
| 20:54:05 | | Join zeekoe [0] (zeekoe@zeekoe.kabel.utwente.nl) |
| 20:54:31 | * | zeekoe is away: UT |
| 21:00 |
| 21:19:17 | * | zeekoe is back (gone 00:24:53) |
| 21:50:25 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34188.dip.t-dialin.net) |
| 21:50:41 | [IDC]Dragon | good evening |
| 21:50:51 | amiconn | hello Jörg |
| 21:57:35 | | Join SmoothOperator [0] (~acb978b4@labb.contactor.se) |
| 21:59:26 | | Quit SmoothOperator (Client Quit) |
| 22:00 |
| 22:05:43 | | Join elinenbe [0] (elinenbe_@207-237-224-49.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 22:11:00 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 22:20:01 | * | [IDC]Dragon needs to sleep early tonight |
| 22:20:05 | [IDC]Dragon | bye |
| 22:20:14 | | Quit [IDC]Dragon () |
| 22:35:08 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 22:48:32 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:05:59 | | Quit pike (Read error: 110 (Connection timed out)) |
| 23:08:43 | | Quit webmind (Remote closed the connection) |
| 23:08:45 | | Join webmind [0] (~random@217-195-236-172.dsl.esined.net) |
| 23:15:24 | | Join bagawk [0] (lee@IC62.library.oregonstate.edu) |
| 23:28:44 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- \o/") |
| 23:35:17 | * | zeekoe is away: busy |
| 23:53:24 | | Quit AciD ("http://swpat.ffii.org/") |
| 23:53:24 | | Quit scott666_ (Read error: 110 (Connection timed out)) |
| 23:53:25 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 23:58:38 | * | zeekoe is away: I'm busy |
| 23:58:52 | | Join LinusN [0] (~linus@labb.contactor.se) |
icon identifies that the person is a core developer (has commit access).