--- Log for 19.11.104 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 9 days and 1 hour ago 00.01.09 Quit midk ("just STOP it arspy") 00.06.21 *** Saving seen data "./dancer.seen" 00.06.35 Quit Digital007 ("CGI:IRC (Ping timeout)") 00.13.48 Part oxygen77 ("Tcho") 00.17.04 Join AimVector [0] (AV@80.229.144.229) 00.41.07 Quit edx () 00.55.34 Join iFliP [0] (~51e28f10@labb.contactor.se) 00.56.37 Quit iFliP (Client Quit) 01.12.36 Quit AciD (Remote closed the connection) 01.13.17 Join taz2 [0] (~a@82-39-96-141.cable.ubr01.newy.blueyonder.co.uk) 01.14.03 # Does RockBox work on archos jukebox Multimedia 20? 01.15.16 Quit taz2 (Client Quit) 01.22.17 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 01.33.13 Quit midk ("just STOP it arspy") 01.33.50 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 01.46.47 Join LinusN [0] (~linus@labb.contactor.se) 01.48.13 # hi LinusN 01.48.20 # hi 01.49.17 # I now have enabled the memory guard in my personal build by default. I just found another spot that causes zero area hits... 01.49.47 # oh 01.50.58 # It's only one place - setting the peak meter release time. If you look into this setting, you may notice that the unit isn't there as well (was "units per read" in ealier rockbox) 01.51.14 # I'm already on to fixing it 01.52.01 # I just need to know where str() is defined (not STR() - already found that one) 01.58.02 # nice 02.04.37 # ATA and FAT works fine on the iriver now :-) 02.05.33 # Uiih, commit flooding :) 02.05.40 # Nice work :) 02.05.46 # thx 02.06.25 *** Saving seen data "./dancer.seen" 02.06.39 # No short-hand byte/ word swap on coldfire? 02.07.37 # swap.w exists, swaps the two 16-bit halves 02.07.51 # but no swap.b 02.08.37 Quit midk ("just STOP it arspy") 02.08.54 # we'll see if we can optimize those 02.09.02 # i just wanted something that works 02.12.10 Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") 02.16.45 # Fix committed. 02.22.09 # hmmm, i've made some major changes to ata.c, so i'll have to test it on the archos before i commit 02.22.17 # and i need to sleep 02.23.24 # I hope your other changes didn't brake something on archos 02.23.33 # s/brake/break/ 02.24.46 # let's hope that 02.25.23 # I just compiled & installed current cvs on Ondio - seems to work :) 02.26.46 # phew 02.29.45 # same for recorder :) 02.32.10 Join amiconn_ [0] (~jens@pD9E7F25F.dip.t-dialin.net) 02.32.23 Quit amiconn (Nick collision from services.) 02.32.23 Nick amiconn_ is now known as amiconn (~jens@pD9E7F25F.dip.t-dialin.net) 02.32.27 # LinusN: Do you have an idea why both -O2 and -Os create binaries that fail with an IllInstr exception? 02.34.52 # nope 02.35.33 # Anyway, probably I should get some sleep too 02.40.20 # nite 02.40.25 Part LinusN 02.51.53 # how can i connect my jukebox hard drive to my pc? 02.52.04 # the ide connector doesnt fit, my jukebox is dead 02.52.05 # :( 02.54.40 # You will either need a 2.5"->3.5" hd adapter, or an external 2.5" usb enclosure 02.56.16 # oh right 02.56.23 # i tried fixing my jukebox but no luck 02.56.25 # its dead :( 03.01.26 # Nite 03.01.40 Part amiconn 03.31.25 # anyone here? 04.00.40 # * AimVector is away: sleeping 04.06.26 *** Saving seen data "./dancer.seen" 04.30.47 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 05.18.34 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net) 06.04.22 Quit scott666_ ("i'll be back...eventually...") 06.06.27 *** Saving seen data "./dancer.seen" 06.22.05 Join Cor [0] (~42ec195b@labb.contactor.se) 06.24.27 Quit Cor (Client Quit) 06.24.54 Join Cor [0] (~42ec195b@labb.contactor.se) 06.33.08 # request: any chance of enabling FF/RW in playlist view ? 06.33.44 # 'view playlist' as it's called in the menu 06.33.52 # all the keys are used, right? 06.34.14 # ? 06.35.15 # is l/r used in the viewer? 06.36.04 # holding down the key is not, i believe 06.38.07 # hmm 06.39.35 # not uypt o me anyways :).. bagder may or may not be of service 06.39.38 # up* 06.39.41 # to* 06.39.59 # night 06.40.02 Quit midk ("just STOP it arspy") 06.44.13 # i'd also appreciate being able to stay in the 'view playlist' mode and have it scroll down to the next song when it begins playing in the 'WPS' 06.55.36 Quit matsl (Remote closed the connection) 06.56.36 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 07.14.15 Quit matsl (Remote closed the connection) 07.24.53 Join ashridah [0] (ashridah@220-253-118-223.VIC.netspace.net.au) 07.48.24 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 08.06.31 *** Saving seen data "./dancer.seen" 08.16.01 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.22.52 Join lImbus [0] (lImbus@147.182-200-80.adsl.skynet.be) 08.31.06 Join amiconn [0] (~jens@pD9E7F25F.dip.t-dialin.net) 08.31.24 # Good morning 08.40.48 # y0, hi 08.46.26 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 08.46.45 # lImbus: Nice that you added the side-by-side view in the wiki :) 08.47.24 # now browsing people need laaarge screens :) 08.47.48 # All three pics fit into my browser window 08.48.01 # !!! 08.48.13 # BTW: Ondio->recording settings->source ->digital is not really functional, isn't it ? 08.48.57 # I think so. I didn't check whether Jörg removed it or not. My Ondio SP has no recording :( 08.49.29 # what a bummer 08.49.55 # I like recording from radio, even if the quality is crap... 08.51.13 # The SP is the simplified version - no recording, no radio. 08.51.25 # Just look at my tuner board 08.52.04 # yup, I saw. but I still don't know why they named it "sp" then. SimPel ? 08.52.55 # Simple Player? 08.53.13 # uhh. 08.53.20 # * lImbus gets another cup of coffee 09.06.36 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 09.14.48 Join kurzhaarrocker [0] (~knoppix@p508778EF.dip0.t-ipconnect.de) 09.23.00 Quit AciD (Read error: 104 (Connection reset by peer)) 09.23.28 # silly player perhaps? ;-) 09.23.45 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 09.24.03 # Neither Linus nor Zagor? Are they stuck in the snow? 09.24.10 # probably 09.24.17 # we had lots of more tonight 09.24.40 # hm, that came out wrong but you get my point ;-) 09.25.07 # :) 09.42.56 # hello Bagder 09.43.42 # hi 09.43.53 # I'm working in the linav project 09.44.19 # and I was willing to use the id3 code from rockbox 09.44.22 Join Zagor [242] (~bjst@labb.contactor.se) 09.44.59 # oxygen77: you GPL your code? 09.45.27 # sure 09.45.32 # :) 09.45.42 # then go ahead! ;-) 09.45.49 # I know there is no problem regarding the license 09.46.01 # I'm informing you 09.46.08 # thanks 09.46.30 # I want to put linav headers 09.46.45 # but also keep the information that this code is comming from rockbox 09.46.47 # we are actually a whole bunch of people who've made that what it is today 09.47.27 # so how do you want this to be put? 09.47.42 # well, you should keep the (C) text and the GPL blurb from our header, then you can prepend whatever you want 09.48.01 # or possibly have your own GPL blurb of course 09.48.30 # what is the (c) text ? 09.48.36 # "Copyright (C) 2002 by Daniel Stenberg" 09.48.38 # Copyright (C) 2002 by Linus Nielsen Feltzing 09.48.40 # :) 09.48.49 # ok 09.49.12 # the id3.c mentions my name 09.49.35 # not the mp3data.h 09.49.49 # but the mp3data.c does 09.49.50 # hehe, nope 09.50.36 # I'll also keep the txt about ample project 09.50.58 # it shows the history of the file 09.51.04 # yup 09.51.07 # I don't think anything from ample is still in there now 09.51.43 # k :D 09.55.33 Join LinusN [0] (~linus@labb.contactor.se) 09.55.56 # morning LinusN 09.56.11 # hi 10.00.42 # yo 10.05.38 # from the MisticRiver forum: "If there's one thing I hate more than anything else on here and on the rockbox forums, it's the sheer amount of people kissing rockbox arse." 10.05.45 # :-) 10.06.02 # loool 10.06.03 # envy shining through? ;-) 10.06.19 # nah, i took the message out of context 10.06.32 *** Saving seen data "./dancer.seen" 10.06.39 # that's what we like! ;-P 10.06.59 # * Bagder remembers the classic: "you're only making rubbish" 10.06.59 # How do you get rid of all that lipstick? 10.07.21 # i got the "when is it ready" question for the 100th time, and someone replied "Do *NOT* hassle 'Da Man' while he's working. OK? Good." 10.08.07 # so i can understand his reaction 10.10.56 # one shouldn't expect too much from those user forums 10.12.09 # "you're only making rubbish"? 10.12.15 # * kurzhaarrocker suspects that internet forums made tv producers aware that there is a niche for afternoon talkshows. 10.12.19 # dwihno: good old mailing list posting in the past 10.12.25 # :) 10.12.41 # A name change... Rubbishbox :) 10.13.15 # http://www.rockbox.org/mail/archive/rockbox-archive-2002-09/0586.shtml 10.13.53 # we are all just silly people 10.14.34 Quit oxygen77 ("Cho") 10.14.58 # it's a true classic 10.15.57 # Ha ha ha 10.16.05 # Silly^2 ><))))8> 10.18.00 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 10.31.40 Quit AciD (Read error: 104 (Connection reset by peer)) 10.49.11 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 10.53.54 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 10.55.03 Quit oxygen77 ("Cho") 10.55.17 Join gromit` [0] (~augej@ulysse.iiens.net) 10.56.23 Join oxygen77 [0] (~oxygen@pauguste-7-82-66-87-78.fbx.proxad.net) 10.57.33 Quit gromit`_ (Read error: 113 (No route to host)) 10.58.02 # * LinusN can read and write files and directories on his iriver 10.58.16 # and handle button events 10.58.26 # backlight works 10.58.37 # hard drive spindown works too 10.59.39 # <[IDC]Dragon> LinusN: I get a habit of congratulating 11.00.14 # :-) 11.00.18 # keep it coming :-) 11.00.19 # <[IDC]Dragon> do you compile the rest of Rockbox with it? Can you browse? 11.00.48 # i added tree.c last night, but it depends on every f*cking file in rockbox... 11.01.12 # so i skipped that part for now 11.01.12 # LinusN: You broke the iRiver sim... 11.01.20 # as if i cared :-) 11.01.39 # 295 errors? not a record... 11.01.52 # <[IDC]Dragon> didn't the sime browse and show menus? 11.02.03 # yes it did 11.02.04 # <[IDC]Dragon> s/sime/sim 11.02.31 # <[IDC]Dragon> but the target make is a lot different? 11.02.43 # a lot 11.02.52 # <[IDC]Dragon> ah, ok 11.03.08 # totally fake 11.03.16 # <[IDC]Dragon> :-( 11.04.44 # [IDC]Dragon: Did you notice that I changed KeymapOndio (already 2 days ago), describing the current keyboard button assignment? 11.05.07 # <[IDC]Dragon> I just did 11.05.30 # <[IDC]Dragon> strangely, I changed it yesterday, which is not indicated 11.06.25 # <[IDC]Dragon> my intention was to describe the 2.3 state, so Christy could work it into the manual 11.08.40 # * oxygen77 is away: Chui pas là 11.08.52 # it seems like twiki has problems with the "release lock" feature 11.15.18 # Zagor et al: Given the new intended release cycle of 8 weeks, we can have a wonderful release date for 2.4: 2004-12-24 :-) 11.15.42 # <[IDC]Dragon> spoiling our vacation? 11.16.48 # it would be fun, but I expect most of us will be on Real Life duty that day 11.17.14 # <[IDC]Dragon> the iriver is working by then? ;-) 11.17.27 # <[IDC]Dragon> will it shuffle correct? 11.17.33 # haha 11.17.56 # and OTF playlists? 11.18.05 # <[IDC]Dragon> and play record mp3, ogg, wma, flac 11.18.06 # and gapless? 11.18.32 # <[IDC]Dragon> I forgot some: wav, sid, midi 11.18.41 # [IDC]Dragon: we can't have real shuffle, since we don't have an rtc. i read that on the intarnet 11.19.01 # <[IDC]Dragon> oh, what a pity 11.19.11 # i'll go make some snow angles instead 11.19.16 # <[IDC]Dragon> was that on AOL? 11.19.18 # Zagor: The release could be prepared beforehand, letting it build the packages by an automated script on 2004-12-24 11.19.52 # <[IDC]Dragon> I want to automate packages on xmas, yes 11.20.04 # hehe 11.20.17 # ;-) 11.21.22 # and a prerecorded irc discussion 11.21.32 # <[IDC]Dragon> lImbus: are you there? 11.29.29 # <[IDC]Dragon> LinusN, Zagor, Bagder: I like that "global moderator" status you have in the forums 11.29.42 # <[IDC]Dragon> will you bring us world peace? 11.30.53 # yes, that's our god given mission 11.31.33 # [IDC]Dragon: i am somehow 11.32.03 # congratz, LinusN 11.32.12 # <[IDC]Dragon> lImbus: I'm curious about that shielding in your box 11.32.37 # you saw the pictures. what do you want to know ? should I open them ? 11.32.57 # <[IDC]Dragon> better not 11.33.13 # <[IDC]Dragon> I'm wondering how it is attached 11.33.21 # maybe it's for the radio. it has HUGE bursts from the electronics (beeping for keypresses, and so on) 11.33.59 # I reassembled the ondio. but I can have a look, only it will take up to sunday. 11.34.06 # <[IDC]Dragon> that's probably why they kicked it out, replacing with Philips 11.35.05 # i suppose the only attaching point of these shield are the small soldering points you can see on the scans 11.35.20 # <[IDC]Dragon> Jens and I have been speculating about the EL backlight chip, the empty socket which is just under the white plastic in your pic 11.35.57 # <[IDC]Dragon> the pinout is different on yours 11.36.24 # 8 pins ? 11.36.33 # <[IDC]Dragon> is the white plastic glued to the shield? you didn't take it off 11.37.06 # yes, it's glued. and you don't see more if you don't take away the shield, so I led it be 11.37.31 # * lImbus has got to go very soon 11.37.33 # <[IDC]Dragon> ok 11.38.03 # the lcd_off picture is mainly for the quarz/oscillo 11.39.20 # a propos EL-backlight. It's what wrecked on my laptop yesterday evening.... the tft is now veeeery dark :( 11.39.41 # <[IDC]Dragon> ohh, how did it happen? 11.40.38 # dunno. it gave some electric sounds (like that beeping from electronic circuits in recorders recordings), then was black. in the middle of the sentense i was typing. now using rdp inhouse ... 11.41.02 # <[IDC]Dragon> laptops don't have EL backlight, but fluorescent lamps 11.41.39 # <[IDC]Dragon> sounds like the inverter gave up 11.42.06 # mhmm. I don't care. it wrecked, and it's still on guarantee, so I'll make some helpdesk-hopping today 11.44.00 # im just a small bit disappointed. a few bad things happen these days... 11.48.05 Quit AciD (Read error: 104 (Connection reset by peer)) 11.48.58 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 11.53.51 # gotta go. will we back later 11.54.00 Quit lImbus (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") 11.55.36 # lunch 12.06.36 *** Saving seen data "./dancer.seen" 12.30.27 Join Fots [0] (~fots@ppp150-72.lns1.mel3.internode.on.net) 12.30.47 # hi all 12.31.05 # hi 12.31.23 # :) i've noticed the firmware stuff u guys are doing, nice work 12.31.35 # i'm thinking about buying an mp3 player 12.31.38 # so confused :D 12.31.43 # how r u Linus ? 12.32.04 # i'm fine, a little tired, too little sleep 12.32.16 # yeah same here, had my last exam today 12.32.18 # :) 12.32.22 # oooh 12.32.34 # :D r u doing exams atm too ? 12.33.02 # hehe, that was a long time ago 12.33.08 # aahh, lol 12.33.12 # i'm 36 12.33.22 # aahh :D 12.33.24 # well i just finished my course, im 21 12.33.55 # hey Linus, what do u think of the iAudio m3 ? 12.34.02 # have u ever tried one ? 12.34.07 # i have no opinion 12.34.12 # aahh 12.34.14 # np 12.34.32 # * ashridah notes that it supports FLAC, last he heard. 12.34.45 # if you want rockbox, go for an archos recorder or an iriver H1xx 12.34.48 # lol yeah thats what i just noticed too 12.35.06 # yeah, well i dont mind either way, as long as the firmware provided is good 12.35.18 # ashridah: if it does gapless with FLAC, then im buying it 12.35.30 # but i dont know if it does gapless with flac :'( 12.35.58 # i really couldn't care less either way. FLAC in a portable player seems overly extreme by my standards. 12.35.59 # im afraid the archos recorder isnt sold in local shops here in Australia 12.36.01 # i wouldn't want a player without a display on the main unit. i don't want to have to use the remote all the time. 12.36.10 # ashridah: yep thats true 12.36.23 # Zagor: yeah, i see ur point, well i cant really find a good alternative 12.36.43 # all i want is 3 things, gapless playback + a remote + a good built product 12.36.45 # Fots: hm. i haven't seen the iaudio anywhere, that said, i haven't really been looking since i got my iriver h140 back in april or so 12.36.56 # Fots: looked at the iriver? 12.36.57 # ashridah: whats the iriver like ? 12.37.06 # yeah, i should give em another look i guess 12.37.17 # i hear that their gapless support sucks 12.37.18 # is that true ? 12.37.26 # apart from that, they look very nice 12.37.36 # in that it's not really there? you could say that, yes. 12.37.45 # ashridah: yeah 12.37.51 # thats such a shame 12.37.55 # the only problem is the remote for the h3xx series bites, in comparison to the one you get with the H1xx 12.38.06 # aahh, how do u mean ? 12.38.07 # as far as I know there is only one player that does gapless with stock formware: rio karma 12.38.11 # (that said, you can buy a replacement and it works with the H3xx perfectly, last i checked) 12.38.17 # ahhh well thats gr8 12.38.23 # Zagor: yeah 12.38.32 # Zagor: i just question the build quality of rio units 12.38.37 # but the one that comes with the H3xx has no LCD, and less buttons 12.38.38 # they dont seem very robust 12.38.48 # ashridah: ahh, well i dont really mind about that 12.38.53 # i was also considering minidisc 12.38.59 # * ashridah has been very mobile with his H140 since he got it, and hasn't had any issues) 12.38.59 # atrac+ at 256 sounds ok 12.39.02 # but not perfect 12.39.08 # Fots: you must understand we are not a generic mp3 player group. we are naturally biased towards players that can run our firmware 12.39.11 # ashridah: nice dude, i will check em out again 12.39.20 # Zagor: yep, i understand 12.39.32 # i just thought id come in and get some of your opinions 12.39.37 # and have a chat 12.39.38 # :D 12.39.52 # :) 12.40.00 # r u guys planning to do gapless and stuff on the iriver ? 12.40.03 # :) 12.40.06 # yes 12.40.10 # maybe i should just wait for ur gr8 firmware 12.40.13 # hmm 12.40.20 # i think i'll do that actually 12.40.24 # :D 12.40.50 # it just annoys me that companies can't do a proper job themselves 12.40.55 # the same happened with creative drivers 12.41.08 # and now theres an independent group www.kxproject.com developing drivers coz creative suck 12.41.09 # lol 12.41.19 # they only do enough to sell them. anything more is a waste of money. 12.41.19 # i use the kx drivers, they are so much better 12.41.24 # yeah lol 12.41.33 # it's the commercial development dilemma 12.41.53 # see thats why i enjoy iTunes, its definately a nice little program, but god the whole battery not being replaced and nongapless playback makes ipod look like shit 12.42.32 # apple are definately developing for monetary gain, not reputation among perfectionists 12.42.36 # i guess its worked so far lol 12.43.03 # i've heard people say the audio quality of ipods aren't that hot compared to some other players too, but that's complete hearsay 12.43.09 # since i've never listened to one. 12.43.17 # yeah, iv read the same ashridah 12.43.22 # they say it sounds tinny 12.43.26 # the part that scares me about ipods is taht one of my friends wants to get one purely because it comes in pink! 12.43.27 # then again, they are probly encoding at 128 lol 12.43.28 # however audio quality is always very subjective 12.43.34 # ashridah: lmao 12.43.35 # (female friend, that is) 12.43.42 # ashridah: naturally lmao 12.43.48 # see, thats what pisses me off about apple 12.43.53 # idiots 12.43.53 # lol 12.44.09 # i mean, they just released the ipod photo, and their ordinary ipod still doesnt even play music perfectly 12.44.18 # so is all the coding for firmware done in assembly? 12.44.30 # C 12.44.30 # no, 98% is C 12.44.34 # aahh nice 12.44.35 # :D 12.44.44 # 0% in java 12.44.50 # lmao good ! 12.44.52 # java = crap 12.44.53 # lol 12.44.54 # is the ipod doing hardware or software decoding? 12.44.57 # im a c++ fan 12.45.07 # ashridah: software 12.45.12 # java isn't crap, it's just not suited to some tasks. 12.45.19 # lol thats true 12.45.24 # i.e. its crap 12.45.24 # lmao 12.45.25 # j/k j/k 12.45.29 # Zagor: so what was the purpose of the proprietary chip you guys couldn't get unrestricted info on? 12.45.34 # fairplay? 12.45.59 # Fots: have you ever developed a large-scale multi-tier web application with java? 12.46.10 # come back and tell me it's crap once you've done it with people who know how to design well. 12.46.16 # it's the chip that does the decoding 12.46.16 # i cant say i have ashridah 12.46.25 # ashridah: iv used servlets 12.46.30 # which i despise 12.46.30 # lol 12.46.32 # ashridah: it's a modified arm7 core, likely with some dsp instructions to speed up decoding 12.46.44 # ah 12.46.49 # ashridah: but they are definately very robust and emphasise good structure 12.46.50 # :D 12.47.20 # ashridah: iv developed a large multi-tier web application in PHP, which isnt quite as robust as Java 12.47.45 # have u tried PHP ? 12.47.56 # * ashridah notes that the people in question were very surprised when it scaled as well as it did, AND when they found otu it took them 3 days to rip out the oracle specific stuff and replace it with postgres stuff when the client realised they couldn't afford oracle for each school in the state :) ) 12.48.15 # hahaha 12.48.44 # php is nice for quickhacks 12.48.49 # yeah 12.48.51 # yeah, php's nice. i've done plenty of adhoc stuff with it, and it does have the infrastructure available to do larger projects, but i haven't had to work with it that far yet 12.49.02 # it tends to be a bit patchy in some areas tho 12.49.09 # ashridah: yeah thats true 12.49.19 # i definately think that servlets / applets are more robust 12.49.25 # it takes discipline more than anything 12.49.36 # exactly 12.49.40 # thats totally true 12.49.43 # which is the same with pretty much any language. 12.49.48 # agreed 12.50.12 # when i say java is crap, i say it because i hate that my uni is starting to teach java first instead of c+ 12.50.15 # c++* 12.50.41 # so i kinda have this personal thing against it because i personally dont believe its a good first language 12.50.51 # not to say that its not a good language, but just not a good "first" language 12.50.55 # do u know what i mena ? 12.50.59 # mean* 12.51.35 # oh well, iv bored u all enough, i'll get outta here lmao 12.51.37 # :D 12.52.12 Quit Fots () 12.52.59 Join Tang [0] (~chatzilla@84.97.192.4) 12.53.28 # Hi all 12.53.51 # just to congratulate Linus for last progresses on iRiverport 12.54.01 # looks very fine 12.54.02 # :) 12.59.40 # thx 13.03.16 # * [IDC]Dragon spots cvs traffic 13.03.52 # <[IDC]Dragon> if LinusN proceeds like this, he'll have the pluging working tonight ;-) 13.04.01 # <[IDC]Dragon> plugins 13.04.23 # hehe 13.04.55 # <[IDC]Dragon> how much space do we grant them this time? 13.04.58 # well, my family is back from their trip, so i won't have that much time for hacking 13.05.21 # <[IDC]Dragon> ah, they've been away, hence the activity 13.05.24 # on the iriver? well, more than 32K at least :-) 13.05.57 # * [IDC]Dragon should get an iriver 13.06.14 # <[IDC]Dragon> but /me has less than zero time... 13.06.16 # LinusN: Yay for ATA progress \o/ 13.06.57 # <[IDC]Dragon> maybe I'm back in development in a good year from now 13.07.47 # lol we would hope for another LinusM's parents trip! 13.28.19 # parents? you mean wife and kids. 13.34.11 # * oxygen77 is back (gone 02:25:31) 13.36.12 # <[IDC]Dragon> LinusN looks so young 13.37.00 # <[IDC]Dragon> we have to take care when his parents are away, that he dosn't spent too much time with these computers 13.37.56 Quit ashridah ("sleep") 13.46.08 # Oh sorry LinusM indeed i thought you were younger... 13.54.51 # Bye everybody! 13.54.57 # :) 13.55.04 Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") 14.00.03 Join R3nTiL [0] (~zorroz@176-250-30-217.kgts.ru) 14.00.24 # Linus: concerning triggered recording - what do you mean with "issues with screen updates and button handling" 14.02.25 # i believe we had to change a few things to achieve faster screen updates, weren't we? (in the peak_meter_button_blabla() function) 14.03.49 # plus our discussion about the visual feedback in general, with the traffic light being in the way of long translated strings 14.04.35 # i think we should commit the traffic light (drawn after the text, so it ends up on top) and then make a new fix if we actually run into that problem 14.04.57 Quit R3nTiL () 14.05.08 # ok, and perhaps disable Pause? 14.06.06 # hmm, remind me 14.06.25 # the triggering code doesn't like to pause the recording 14.06.37 *** Saving seen data "./dancer.seen" 14.06.41 # ah, ok. how about making pause stop if in trigger mode? 14.07.20 # or just ignore it 14.07.33 # kurzhaarrocker: comments? 14.10.41 # * AimVector is back after 10h9m: sleeping 14.10.46 # LinusN hey 14.11.07 # remember my problem with my jukebox? 14.12.37 # eh, no... 14.13.16 # lol 14.13.30 # you said the clicking of my hard drive could have been the battery connectors 14.13.34 # aha 14.13.41 # well its not 14.13.52 # i plugged the hard drive into my laptop and the very same happens 14.14.08 # there you have it 14.14.12 # click click click ciick, click click click click 14.14.22 # time to go shopping then :-) 14.14.27 # lol 14.14.37 # http://www.soliton.net/content/comp/ibm/ 14.14.45 # sorry, was afk for a mo 14.15.01 # apparently if i tighten up a screw it can fix it though, dunno if you have heard of this problem before 14.15.37 # About visual feedback: we (I) can make a line with bigger display. If the trigger status has its own line it won't collide with other strings 14.17.48 # The pause mode still is something I'll have to look at. I'm not sure how I want it to behave. Probably I'll prefer to disable it while triggered recording. Imho it doesn't make sense. 14.17.58 # AimVector: worth trying :-) 14.18.17 # kurzhaarrocker: let's disable it 14.19.02 # if we use a whole line for feedback, how would it affect the setting screen? 14.19.14 # LinusN: how close are we to a rockbox working on the iriver? 14.19.35 # (btw: It wasn't the screen update but the led blinking frequency that required faster button polling) 14.19.39 # I'm excited about all your great progress 14.19.55 # <[IDC]Dragon> amiconn: r u there? 14.20.13 # In the screen settings I already have to scroll for the last line. Scrolling for another line won't hurt that much. 14.21.38 # i don't like replacing the traffic light with text. complementing is fine, but don't remove the light. 14.21.56 # <[IDC]Dragon> traffic light? 14.21.56 # Zagor: who said anything about text? 14.22.09 # I'd have something like a horizontal bigger traffic light + text in that line, Zagor 14.22.40 # [IDC]Dragon: visual feedback in the triggering mode 14.22.56 # <[IDC]Dragon> like a vu meter? 14.23.20 # http://www.rockbox.org/twiki/bin/view/Main/TriggerManual 14.23.22 # i still think we should commit it as-is and then work on improvements 14.23.35 # Zagor: okidoki 14.24.03 # <[IDC]Dragon> that setting screen is indeed different 14.24.18 # yes, not easily translated 14.24.23 # <[IDC]Dragon> probably works only in english 14.24.46 # yes. Primarily because it needs optical feedback about the trigger behaviour while setting the trigger settings 14.25.17 # <[IDC]Dragon> no voice, I guess (recording mode) 14.25.24 # perhaps it would be better with icons? (i can't believe i said that) 14.25.57 # <[IDC]Dragon> now hell breaks loose 14.30.06 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 14.32.08 # far in the back of my had some ideas about a graphical interface where you edit a curve rise.. But that's trigger V2.0 14.34.49 # :-) 14.38.04 # <[IDC]Dragon> "There will soon exist bitmapped players without RTC": they already do, Ondio 14.39.00 # players as in with a hard drive? 14.39.10 Quit Cor ("CGI:IRC (Ping timeout)") 14.39.48 # <[IDC]Dragon> this was from LinusN's clock plugin commit 14.40.04 Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 14.40.08 # <[IDC]Dragon> so far, we handled it in SOURCES 14.40.14 # silly me 14.40.51 # <[IDC]Dragon> no, double protection is good, and makes it visible from the source 14.40.54 # the simulator doesn't have SOURCES 14.41.20 # <[IDC]Dragon> ah 14.42.02 # the simulator makefiles are due for realignment with the regular builds 14.46.29 Quit midk_ ("just STOP it arspy") 14.47.42 # [IDC]Dragon: Now I'm here 14.51.46 # <[IDC]Dragon> just got a call from a Linear Technology representative 14.51.59 # <[IDC]Dragon> because of the sample I ordered 14.52.24 # <[IDC]Dragon> I was barely able to stop him from visiting here :-/ 14.52.26 # And how many thousands did you reorder? :9 14.53.10 # <[IDC]Dragon> should I not have checked the box that I'll taget 5 mio pieces/month? ;-) 14.54.09 Quit AciD (Read error: 104 (Connection reset by peer)) 14.54.17 Join MooMaunder [0] (~me@194.152.87.150) 14.55.07 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 14.57.36 Quit midk (Read error: 110 (Connection timed out)) 15.00.16 # [IDC]Dragon: I now have the memory guard enabled by default in my personal builds 15.04.00 Join oxygen77_ [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 15.04.06 Quit oxygen77_ (Read error: 54 (Connection reset by peer)) 15.05.40 # <[IDC]Dragon> how about committing that? 15.08.46 # I don't think it's a good idea commiting this, at least not without requiring an extra #define. Users may not expect rockbox to crash because of those bugs. That feature is aimed at developers only 15.09.55 # <[IDC]Dragon> but the more people testing with it, the more bugs get uncovered 15.12.08 # <[IDC]Dragon> Windows is also not masking access violations 15.14.48 # is the access trap non-recoverable? 15.14.55 # True, but on the other hand, we would need the complete debug info to analyze the report, i.e. the *exact* build version, along with the failure address 15.15.30 # Additionally, a disassembly of that exact version, and the map file are needed (would need to get those from the official build system) 15.16.19 # LinusN: with the current implementation it's not, that would require a separate handler function which I didn't bother to write. 15.16.56 # As it is now, invalid accesses trigger an execption (UserBrk), displayed by the default exception handler in rockbox 15.17.05 # Did you really never try it? 15.17.26 # i did, to verify that my mpeg fix worked 15.17.49 # my question was more like if it can be made recoverable 15.17.50 # <[IDC]Dragon> it is still helpful to get a user report how to reproduce it, regardless of map file 15.18.56 # i agree 15.19.48 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 15.20.05 # the interrupt could send an event, and the default handler could catch it 15.20.18 # and display a splash and return 15.21.20 # <[IDC]Dragon> better wait for a key, to note the address 15.21.29 # naturally 15.23.21 # gotta go 15.23.24 # cu guys 15.23.50 # LinusN: I think it's recoverable by nature 15.24.14 # Just returning from the interrupt should continue the running program 15.24.37 # However, this leaves the problem how to display a splash while in interrupt state 15.26.28 # Zagor: I've installed enscript on labb now and fixed coloured source with viewcvs on the curl repo 15.31.27 # neto 15.32.58 # amiconn: that is solved by having the splash in the default event handler 15.33.09 Part LinusN 15.33.58 # i'm off too 15.34.01 Part Zagor 15.34.42 # * amiconn doesn't understand how this could work 15.43.13 # <[IDC]Dragon> the irq sends an event into the queue, like a button press within the tick irq 15.44.08 # <[IDC]Dragon> the default handler (running in the foreground context) grabs it and does whatever 15.46.16 Join adi|home [0] (~chatzilla@12.109.187.2) 15.47.59 # [IDC]Dragon: Hmm, this might actually work, *if* it is possible to have events with parameters. 15.48.16 Nick adi|home is now known as adi|work (~chatzilla@12.109.187.2) 15.48.39 Quit einhirn (Read error: 104 (Connection reset by peer)) 15.52.38 # <[IDC]Dragon> amiconn: you probably have to store the info somewhere 15.53.59 # Yes. I just found that events include a data pointer. What to do if several (could be really many) exceptions occur until the default event handler gets called? Only store the last? Have an array (how large?)? 15.56.55 # <[IDC]Dragon> something simple, like only store and flag an event if the space is empty 15.58.52 Join einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de) 15.59.09 Join bobTHC [0] (~foo@l06v-7-163.d1.club-internet.fr) 15.59.20 # hi all 15.59.47 # <[IDC]Dragon> amiconn: and we need your bluescreen code for this 15.59.58 # <[IDC]Dragon> hi bobTHC 16.04.33 # iriver dev run amazingly quick 16.05.09 # :) and is a very good news for all 16.05.27 # [IDC]Dragon: I think Zagor was right. The display looks very blueish if the contrast is set to maximum with white backlight, especially if grayscale content is displayed. Remember, this was observed after run-away rockbox did all sorts of weird things, including arbitrary changes of other lcd parameters as well (like roll) 16.06.38 *** Saving seen data "./dancer.seen" 16.08.52 # sweedish wizards always rocks! new dev device, new challenge, and new big amount of work! but nothing is impossible for wizards ;) 16.09.27 # ^swedish 16.17.34 # <[IDC]Dragon> amiconn: mine looks especially blueish 16.17.45 # <[IDC]Dragon> with high contrast 16.18.03 # <[IDC]Dragon> well, the setting is not really contrast, but bias 16.18.30 # <[IDC]Dragon> (why should we lower the contrast on a b/w display?) 16.18.55 # * [IDC]Dragon has to reboot 16.19.00 Quit [IDC]Dragon ("CGI:IRC") 16.27.00 # * AimVector is away: nfsu2 16.33.07 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 16.34.07 # <[IDC]Dragon> amiconn: still at work? 16.34.42 # yup 16.35.09 # <[IDC]Dragon> if you're lucky, you have the board back today 16.35.23 # <[IDC]Dragon> else tomorrow 16.35.24 Quit bobTHC (Read error: 110 (Connection timed out)) 16.38.11 Join bobTHC [0] (~foo@l05m-1-120.d1.club-internet.fr) 16.38.15 # re 16.41.45 Join Cor [0] (~42ec1953@labb.contactor.se) 16.43.24 Join mecraw_ [0] (~lmarlow@69.2.235.2) 16.57.14 Quit Cor ("CGI:IRC (Ping timeout)") 17.01.48 Quit AimVector (Read error: 104 (Connection reset by peer)) 17.51.36 Part kurzhaarrocker 17.59.24 Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 18.06.41 *** Saving seen data "./dancer.seen" 18.07.56 Quit Bagder (Read error: 60 (Operation timed out)) 18.08.21 Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 18.16.01 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") 18.19.02 # * [IDC]Dragon goes jome 18.19.06 # <[IDC]Dragon> home 18.21.33 Quit [IDC]Dragon ("CGI:IRC") 18.45.56 Quit AciD (Read error: 104 (Connection reset by peer)) 19.00.37 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 19.12.13 Join Seed [0] (~ben@192.114.41.140) 19.12.16 # Hi 19.18.50 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) 19.38.27 Join oxygen77_ [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 19.38.34 Quit oxygen77_ (Read error: 54 (Connection reset by peer)) 19.38.39 Quit oxygen77 ("Tcho") 19.38.46 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 19.41.05 Part oxygen77 ("Cho") 19.47.01 Quit adi|work ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]") 19.49.41 Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) 19.50.37 Join adi|work [0] (~chatzilla@12.109.187.2) 20.06.44 *** Saving seen data "./dancer.seen" 20.34.34 Quit AciD (Read error: 104 (Connection reset by peer)) 20.35.59 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 20.44.33 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 21.08.12 Join [IDC]Dragon [0] (~idc-drago@p50861FB3.dip.t-dialin.net) 21.08.35 # <[IDC]Dragon> hi again 21.08.37 # hi again 21.08.41 # <[IDC]Dragon> ;-) 21.08.48 # hi again 21.09.22 # [IDC]Dragon: Good news! The board arrived today. I already assembled the player, it works :-)) 21.09.31 # <[IDC]Dragon> wow, great! 21.09.57 # <[IDC]Dragon> now you got work to do? 21.10.18 # Yup, now comes the fun part 21.10.42 # <[IDC]Dragon> dinner time 21.45.41 # <[IDC]Dragon> back again 21.46.12 # <[IDC]Dragon> amiconn: do you need the authoring tool, template and batch file? 21.46.30 # [IDC]Dragon: I could need some help with the make_firmware thingy. I built a firmware file, however, firmware_flash.rock refuses to flash it (eBadPlatform) 21.46.50 # <[IDC]Dragon> probably the "platform ID" 21.47.17 # Yes, I already suspected this. The template file is the original ROM dump, correct? 21.47.37 # <[IDC]Dragon> yes, the first 256 byte are sufficient 21.47.40 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 21.48.09 # [IDC]Dragon: Platform ID is 0xFB, which is 0 in my original ROM. You defined the player platform Id to be 2... 21.48.12 # <[IDC]Dragon> and I added a platform ID, byte 0xFB needs to be 0x02 21.48.26 # Simply patching that is enough? 21.48.31 # <[IDC]Dragon> yes 21.48.55 # <[IDC]Dragon> while at it, you should patch a 0x01 into 0xFA 21.49.13 # What's 0xFA ? 21.49.18 # <[IDC]Dragon> very recent addition: the boot loader version 21.50.06 # Do you have uncommitted changes for the flash tools and/ or bootloader? 21.50.06 # <[IDC]Dragon> not mandatory, but makes it possibe to phase out old booloaders 21.50.11 # <[IDC]Dragon> no 21.50.27 # <[IDC]Dragon> just a convenience batch file to call it 21.50.42 # <[IDC]Dragon> I patched the templates "by hand" 21.51.09 # Already done, a hex editor is your friend here :) 21.51.15 # <[IDC]Dragon> same here 21.51.40 # <[IDC]Dragon> boot loader and tool compilation went OK? 21.51.47 # yup 21.52.30 # bootloader is sh stuff anyway, and the necessary tools are single source files, easy to compile under cygwin (even to be run outside of cygwin) 21.53.20 # <[IDC]Dragon> the HP power polarity in the bootloader was wrong, I guess? 21.53.24 # <[IDC]Dragon> HD 21.53.58 # yes, already corrected. Plus I added the Port C button checking for player, enabling - / Play / + 21.54.30 # Btw: That rom dump is funny. While the version word clearly says 506 (and rockbox says 5.06 in the debug menu as well), archos says 5.08 on startup 21.54.56 # <[IDC]Dragon> I suggest you leave the baudrate for the "emergency boot" at 14400, like the Ondio 21.55.17 # I did (though I would really prefer 38400) 21.55.20 # <[IDC]Dragon> which needs my older uart_boot... 21.55.32 # <[IDC]Dragon> for you experiments, feel free 21.55.45 # <[IDC]Dragon> I mean, for the distribution 21.55.50 # I can always uart_boot, no flash minimon involved 21.56.08 # <[IDC]Dragon> may be handy later 21.56.08 # (but then I should test flash minimon...) 21.56.44 # <[IDC]Dragon> at the Ondio, I used the "hard" uart boot only once 21.57.06 # <[IDC]Dragon> from then on, pressing "right" was much more convenient 21.58.12 # <[IDC]Dragon> with my non-intrusive MMC dummy adapter 22.03.52 # I did the flash now. Although it seems to have worked (the unit started properly with the archos image, as there is no second image yet), after disconnecting and reconnecting power, the display doesn't work anymore :( 22.04.58 # <[IDC]Dragon> strange, because the Player has no 2nd level loader 22.05.24 # <[IDC]Dragon> the boot rom directly descrambles the final image 22.05.54 # <[IDC]Dragon> so the image can't rely on other port inits, etc. 22.06.45 *** Saving seen data "./dancer.seen" 22.06.56 # The archos firmware obviously starts, and loads rockbox from disk. I am even able to play music, just the display doesn't show anything 22.07.19 # <[IDC]Dragon> I have no clue 22.09.41 # Even uart_boot doesn't want to work anymore :(( 22.09.44 # <[IDC]Dragon> why no Rockbox in your image? 22.09.59 # <[IDC]Dragon> oops 22.10.31 # <[IDC]Dragon> that sounds impossible 22.11.02 # Hangs on "downloading monitor..." forever 22.11.26 # <[IDC]Dragon> hard uart_boot, or with keypress? 22.11.32 # hard 22.11.56 # <[IDC]Dragon> have you used it today already? 22.12.09 # Yes, several times. 22.12.21 # <[IDC]Dragon> so I didn't break it 22.13.00 # <[IDC]Dragon> leave the box off for a longer time 22.13.21 # <[IDC]Dragon> maybe something is very persistant 22.14.16 # Hmm, now it seems to work again ?¿?¿? 22.14.24 # <[IDC]Dragon> phew 22.14.40 # <[IDC]Dragon> marginal levels? 22.14.59 # Powering an open box on&off at will seems to be rather unreliable 22.15.05 # <[IDC]Dragon> power-on sequence box/converter ? 22.18.16 # Maybe powering the HD early in the loader causes problems. The player archos image does shutdown immediately if the on button is not pressed at start. So if I connect power, the box (and hd) get powered for a *very* short time 22.18.51 # It works when I connect main power while holding On 22.19.30 # <[IDC]Dragon> hmm, what a pity 22.20.06 # <[IDC]Dragon> the recorders also get a current pulse, with their disks being on by h/w default 22.20.23 # How do I calculate the rom start address for the second image? Simply the image size (with only 1 image in), rounded up to sector size? 22.20.27 # <[IDC]Dragon> wait, doesn't the boot loader check for external power? 22.20.42 # It does not (yet) 22.20.56 # <[IDC]Dragon> ah, that might be the main problem 22.21.23 # <[IDC]Dragon> image size: yes 22.21.27 # I don't power from the socket, but only by connecting my psu to the battery contacts 22.21.31 # <[IDC]Dragon> want to build rombox? 22.21.39 # yes (already did) 22.22.24 # Loader and first image only consume 52 KB (already rounded) :) 22.22.26 # <[IDC]Dragon> real precisely, it's image size minus the 4 CRC bytes, rounded up to next sector 22.22.51 # <[IDC]Dragon> yes, the player image is very small 22.23.59 # Trying rockbox.ucl at first... 22.24.19 # Wow, quick! 22.24.21 # <[IDC]Dragon> at first? 22.25.11 # I mean before tryingf rombox.ucl 22.25.16 # *trying 22.25.20 # <[IDC]Dragon> ah 22.25.52 # Cold start -> no display :( 22.25.57 # <[IDC]Dragon> people say, the Player starts pretty quick already, much faster than Recoder? 22.26.16 # <[IDC]Dragon> (without flashing, of course) 22.27.01 # Well, the startup itself is quicker than non-flashed recorder, but clearly slower than flashed recorder. Plus, you have to hold "On" rather long before it starts to boot 22.27.12 # <[IDC]Dragon> but you already had cold-started display, with uart_boot? 22.27.19 # Yes. 22.27.58 # Maybe the startup is too fast here, leaving no time for the lcd controller to get ready 22.28.10 # <[IDC]Dragon> haha 22.30.27 # No, really. I think that could be possible (perhaps some slow reset circuit) 22.31.37 # Hmm. Archos (started via "-" + On) works when I disconnect the serial converter power 22.32.21 # Btw, that is the cause for the lcd controller holding data eternally. As long as the serial converter is powered, it feeds a little power through the serial line(s) 22.32.25 # <[IDC]Dragon> else not? 22.33.05 # No (how?) 22.33.39 # <[IDC]Dragon> I meant "Archos (started via "-" + On) works when I disconnect the serial converter power" with else not? 22.34.12 # Rockbox now also works (that dreaded power off&on again too fast problem) 22.34.32 # <[IDC]Dragon> ? 22.36.03 # I really have to keep the dc power disconnected long enough to ensure a proper start afterwards 22.37.30 # Buffer: 1.830 MB :) (rombox) 22.37.48 # <[IDC]Dragon> a new record, I think 22.38.28 # No, I have 1.845 MB on my Ondio (minimized max_files_per_dir and max_playlist_size) 22.38.28 # <[IDC]Dragon> do you want a 5.08 dump, for the "official" release? 22.38.53 # Is that the .bin you already sent me? It's identical to mine... 22.39.08 # <[IDC]Dragon> I've sent you one? 22.40.04 # Yes, 10 days ago. That was the one I tested booting archos via uart_boot with 22.40.20 # <[IDC]Dragon> my 5.08 player ucl is 48403 bytes 22.40.38 # <[IDC]Dragon> 5.06 is 48393 bytes 22.41.33 # 48403 bytes here, too. That's the one that says "5.08" on boot, but has the version field set to 506... 22.42.17 # Otherwise firmware_flash wouldn't work. It checks for <= 506 22.42.42 # <[IDC]Dragon> the version field has to stay, for players 22.42.53 # <[IDC]Dragon> kind of our hardware mask 22.42.59 # Yes I know. 22.43.21 # Hmm, sometimes it works and sometimes not. Maybe the delay loops aren't unnecessary after all? 22.44.17 # <[IDC]Dragon> the extracted image has no version field, only the memory dump has 22.44.31 # I wanted to do the same you did with your distribution images 22.44.46 # <[IDC]Dragon> which is? 22.44.49 # Erm, ignore this. I was way scrolled up 22.46.33 # Ah, right. The version info is in the dump. My dump says 506, however, the image extracted from that compresses to 48403 bytes, and says 5.08 at boot 22.47.19 # <[IDC]Dragon> yes, this is a bit "decoupled", found that with other images, too 22.48.47 # Hmm, rockbox doesn't properly init the display if it's started "really cold", i.e. with connecting battery power. If I start archos first in that case, rockbox does work later on. Maybe there is a hardware init that needs to be only done when connecting battery power? 22.50.22 # <[IDC]Dragon> dunno, can you test this "really cold" with uart_boot, too? 22.51.03 # With uart_boot, rockbox coldstart always works 22.51.33 # Grr, n 22.51.51 # ow it worked!? 22.53.02 # Btw, I noticed I need to init the backlight port bit to output. As it is now, the backlight is always on 22.54.40 # It's really a power problem. I need to wait at least 30 secs before I can expect it to start properly 22.56.57 # Minimon works too (flashing red led) 22.57.15 # <[IDC]Dragon> ok 22.57.55 # -spindown doesn't work 22.58.30 # <[IDC]Dragon> that code is not suitable for Player 22.59.09 # Yes, I suspected that. The bootloader now spins the disk, but minimon is not able to stop it... 22.59.21 # <[IDC]Dragon> in uart_boot, I mean 22.59.29 # Ah. 22.59.45 # It's just setting port bits I guess? 22.59.54 # <[IDC]Dragon> minimon is innocent 23.00.01 # <[IDC]Dragon> and dumb 23.00.14 # ..and sometimes deaf ;-) 23.00.27 # <[IDC]Dragon> lol 23.00.36 # <[IDC]Dragon> it once was an ATA command, but now is a port bit 23.01.41 # uart_boot already has an option to distinguish player from recorders, -r 23.01.59 # <[IDC]Dragon> yes, the spindown code needs an if() 23.02.03 # That could be used to use the different power down for players 23.02.05 # :) 23.02.36 # I'd have to figure how to compile uart_boot on cygwin, as it uses multiple source files 23.03.10 # <[IDC]Dragon> do a make file 23.03.34 # Yes... if only I knew more about those beasts :-/ 23.06.06 # <[IDC]Dragon> I can try to export a makefile 23.06.39 # Yes, that might be a starting point (no msvc either here or at work) 23.08.00 Quit scott666_ (Read error: 110 (Connection timed out)) 23.09.54 # <[IDC]Dragon> gives a complicated file... 23.10.34 # Do you have an idea whether the might be no_rom players? 23.11.03 # <[IDC]Dragon> I doubt it, but don't know 23.12.07 # I should not build a _norom.bin without being able to test it. 23.12.17 # <[IDC]Dragon> mail on the way 23.12.50 # The cvs uart_boot is 14400 baud? 23.13.02 # <[IDC]Dragon> agreed, let a user report no_rom first 23.13.11 # <[IDC]Dragon> 14400, yes 23.13.30 # <[IDC]Dragon> I should make a switch 23.19.09 # I get loads of undefined references: 23.19.25 # _SLEEP, _GET_LAST_ERR, _Sleep 23.20.08 # <[IDC]Dragon> probably some Win32 libraries missing 23.20.13 # Ah, needed to add -mno-cygwin :) 23.21.35 # <[IDC]Dragon> I'm adding your power-down now 23.22.16 # I should commit that rather crude makefile. uart_boot is currently windows only anyway. 23.22.58 Quit AciD (Read error: 104 (Connection reset by peer)) 23.24.21 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 23.26.24 Quit scott666_ (Client Quit) 23.26.54 # <[IDC]Dragon> want a spindown uart_boot? 23.28.08 Quit matsl (Remote closed the connection) 23.28.20 # compiling with -Wall throws a number of warnings (int format mixup, an unused variable) 23.28.52 # <[IDC]Dragon> do you get an .exe? 23.28.59 # yes 23.29.27 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 23.29.36 Quit matsl (Remote closed the connection) 23.29.36 # [IDC]Dragon: Interested in the warnings? 23.30.18 # <[IDC]Dragon> let me try level 4 here 23.30.24 # spindown version: yes please, for a first test. Already committed? 23.30.35 # level 4 ?? 23.30.56 # Btw, all warnings belong to client.c 23.31.19 # <[IDC]Dragon> level 4 means most picky compiler 23.31.36 # <[IDC]Dragon> I don't get any meaningful here 23.31.51 # gcc -O -W -Wall -mno-cygwin uart_boot.c client.c flash.c uart_win.c -o uart_boot 23.31.51 # client.c: In function `ConfigFirstlevelPlayer': 23.31.51 # client.c:18: warning: int format, long unsigned int arg (arg 2) 23.31.51 DBUG Enqueued KICK amiconn 23.31.51 # client.c:27: warning: int format, long unsigned int arg (arg 2) 23.31.51 # client.c: In function `ConfigFirstlevelRecorder': 23.31.51 *** Alert Mode level 1 23.31.51 # client.c:51: warning: int format, long unsigned int arg (arg 2) 23.31.53 # client.c:69: warning: int format, long unsigned int arg (arg 2) 23.31.55 # client.c: In function `DownloadByte': 23.31.57 # client.c:81: warning: unused variable `bRecorder' 23.31.59 # client.c: In function `DownloadArchosMonitor': 23.32.15 # client.c:233: warning: int format, long unsigned int arg (arg 2) 23.33.22 # Probably all those printf()'s need %ud instead of %d 23.33.38 # <[IDC]Dragon> yes 23.34.28 # Doesn't work either (slightly changed warning though) 23.34.42 # <[IDC]Dragon> just %u 23.34.44 # <[IDC]Dragon> ? 23.35.32 # <[IDC]Dragon> or something like %ul 23.35.36 # -> client.c:18: warning: unsigned int format, long unsigned int arg (arg 2) 23.36.39 # It's %lu 23.37.16 # Could you check with msvc? 23.37.54 # <[IDC]Dragon> the compiler doesn't check, you only know at runtime 23.38.16 # What about that unised variable? 23.38.23 # *unused 23.38.29 # <[IDC]Dragon> he's right 23.38.34 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 23.39.26 # <[IDC]Dragon> %lu should be correct 23.41.12 # Now it compiles without warning, and it works :) 23.41.52 *** Alert Mode OFF 23.43.07 # <[IDC]Dragon> nice 23.43.29 # <[IDC]Dragon> I'll commit client.c and the spindown 23.43.33 # I have a number of changes (many files had no final line feed) 23.43.53 # <[IDC]Dragon> then you go first ;-) 23.44.42 # <[IDC]Dragon> tell me when I should merge 23.44.55 # Committed. 23.46.29 # <[IDC]Dragon> me too 23.46.56 # <[IDC]Dragon> please update uart_boot.c 23.47.29 # <[IDC]Dragon> oops, I committed the 38400 baud 23.47.38 # I just wanted to ask... 23.48.15 # <[IDC]Dragon> this will not work for the builtin minimon 23.48.20 # The new version has many changes against the old... 23.48.38 # <[IDC]Dragon> the test function is different 23.49.05 # <[IDC]Dragon> I was playing with a memory test, for Jake's box 23.49.13 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 23.49.21 # Sticky bit box 23.49.27 Quit mecraw_ ("Trillian (http://www.ceruleanstudios.com)") 23.49.36 # <[IDC]Dragon> yes, but it wasn't the DRAM 23.50.29 # I can only test spindown with the builtin minimon, as the boot rom does not spin the disk 23.50.50 # <[IDC]Dragon> obvious, yes 23.51.15 # <[IDC]Dragon> there's 2 places with a 38400 23.51.27 Quit AciD (Read error: 104 (Connection reset by peer)) 23.51.47 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 23.52.25 # <[IDC]Dragon> -b is already taken, for a baudrate option 23.52.29 # [IDC]Dragon: 4 new warnings :( 23.52.46 # uart_boot.c: In function `main': 23.52.46 # uart_boot.c:381: warning: comparison between signed and unsigned 23.52.46 # uart_boot.c:402: warning: comparison between signed and unsigned 23.52.46 # uart_boot.c:424: warning: comparison between signed and unsigned 23.52.47 *** Alert Mode level 1 23.52.47 *** Alert Mode level 2 23.52.47 # uart_boot.c:441: warning: comparison between signed and unsigned 23.52.47 # <[IDC]Dragon> prinf's, let me guess 23.53.32 # <[IDC]Dragon> different, aha 23.53.46 # <[IDC]Dragon> perhaps I should remove that memory test 23.54.00 # <[IDC]Dragon> and place a baudrate switch there 23.54.47 # Iirc the minimon understands a command to set the baud rate. Couldn't you use that? 23.54.57 # <[IDC]Dragon> yes 23.55.15 # <[IDC]Dragon> like the init does, too 23.55.35 # So the builtin minimon does 14400 by default, but uart_boot allows to switch to 38400 if desired 23.55.49 # <[IDC]Dragon> exactly