--- Log for 24.01.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 11 days and 11 hours ago 00.00.05 # thanks. i'll be back as soon as i get the batteries. 00.00.43 # the original batteries are 1500 mah 00.01.11 # but you can find much more powerful ones these days 00.02.20 # Bagder, are you ok with my putting the aformentioned macro in sprintf.h, or elsewhere ? 00.02.46 # you mean the __attribute__ thing? 00.02.50 # yup 00.03.12 # sure, go ahead. just make sure it builds with non-gcc as well 00.03.22 # ok, thanks ... 00.04.09 # coz this is pretty much needed to check for %d or %ld. 00.04.17 # right 00.04.18 Join NibbIer [0] (~andrer@port-212-202-193-173.dynamic.qsc.de) 00.04.30 # it'll help the int/long cleaning 00.04.56 # Of course I also have an implementation for those %l 00.05.09 # great 00.05.20 # dunno if it is canonical though 00.05.49 # Maybe you'll want to have a look at 00.05.50 # it 00.06.20 # I'll review it when you commit it ;-) 00.06.26 # thanks 00.08.15 # here it goes in. 00.12.17 *** Saving seen data "./dancer.seen" 00.13.48 # look good 00.13.51 # looks even 00.14.07 # great 00.14.20 # * amiconn looks 00.14.25 # Now the way is clear for more int -> long stuff ... 00.14.45 # I wonder if that'll cause warnings now 00.15.03 # 6 minutes to next build 00.15.06 # I think not on your machines 00.15.17 # no warning when int=long iirc 00.15.29 # perhaps not without -pedantic 00.15.34 # While we're on the format stuff 00.15.35 # right 00.16.22 # what about the "%.13s" in fat.c ? 00.16.47 # I don't know when LDEBUG() is used 00.16.58 # where that is used 00.17.23 # It turned out that I used those messages 00.17.36 # ah 00.17.47 # and thus I had to remove the length specifier 00.17.53 # but I can just revert it 00.17.59 # nah, remove it 00.18.12 # Ok 00.19.03 # fat.c & fat.h ready to commit ... 00.19.24 # quite a lengthy diff, but beside the length specifier only int -> long 00.20.14 # I'm currently wading through fat.c .... no changes though (yet). 00.21.03 # committed 00.22.41 # your indent level is not 4 00.22.55 # in fat.c ? 00.22.59 # yes 00.23.14 # not a big deal, I just noticed 00.23.20 # I must have missed some place 00.23.45 # I noticed it in fat_size 00.23.47 # Was wary to indent-region the whole file 00.24.26 # well, perhaps it was only that spot 00.25.00 # have you fixed it already ? 00.25.40 # nah, we can fix it another time when something "real" needs to be fixed too 00.27.13 # Like the problem I discovered... _if_ it is caused by fat.c 00.32.21 # jyp: warnings we got ;-) 00.32.37 # heh ... 00.32.45 # lots of yellow 00.32.56 # I can see that :P 00.33.25 # Hopefully it's interesting warnings 00.33.27 # I guess they are good catches 00.40.22 # I'll help out fix them later 00.41.45 # What's the proper way to support 'hwcompat' on the gmini ? 00.42.50 # I don't know. Jens? 00.44.08 Join Cassandra [0] (~Christi-S@213.78.124.36) 00.44.47 Part Cassandra 00.45.48 # I think if for gmini also exist different versions of the hardware, that are marked in the rom, it could be used in a similar way. 00.46.10 # Otherwise this code is archos SH platform specific 00.48.28 # I'll try to do without it ... For some reason one of my early builds required it 00.49.43 # All archos SH platform models have a ROM version, which is only important for the player, as this is the only hint for different hardware. For recorders and Ondios this is only needed for display. 00.50.17 # The recorders and Ondios have a hardware mask, where some bits tell about hardware differences 00.50.33 # Well, I'm now able to link w/o it ... 00.51.20 # my bad to even look at it ;) 00.52.13 # More yellow builds... 00.52.57 # even sims now 00.53.11 # apps/main_menu.c:149: warning: passing arg 1 of `fat_size' from incompatible pointer type 00.53.32 # int* / long* ... 00.53.46 # Yes.. type changes often recurse... I know this from my const policing. 00.55.49 # Well, let's try to get warning in the two remaing builds ... :P 00.55.58 # hehe 00.56.45 # I got my Archos back today from Linus 00.56.57 # now flashable and white backlight 00.57.13 # fun! 00.57.15 # Nice :) 00.57.24 # Is it USB2? 00.57.32 # yes, its a rec20 00.57.35 # with black bumbers 00.58.07 # rec20 (upped to 80) here, but blue bumpers. 00.58.19 # I have a 80 too 00.58.36 # not the only archos box though ;-) 00.58.57 # I only have one Archos! 01.06.09 # Aha, your thread.c uses 3 as indentation level. ;) 01.06.35 # Too bad I just done 'indent-region' on it ;) 01.07.12 # slopp Code Police obviously 01.07.17 # sloppy even 01.07.34 # lol 01.12.43 Join elinenbe [0] (trilluser@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.12.59 # jyp: how far have you come in the gmini support? 01.13.15 # We have hd working 01.13.29 # jyp: what I am trying to say, is how long until rockbox is usable on the gmini (at least to listne to mp3s?) 01.14.24 # Well, it depends on how many peope want to contribute ;) 01.14.32 # jyp: isn't that always the case! 01.14.44 # jyp: where do you live? what country? 01.14.51 # Belgium 01.15.45 # ah... it seems everyone who contributes a lot on this project is European. 01.15.51 # on the serious side, giving "release dates" isn't something I like to do. 01.16.01 # jyp: understandable 01.16.38 # good luck with everything with the gmini... 01.16.44 # well thanks 01.16.48 # I thought someone else was working on it for a while... 01.16.58 # Strath 01.17.13 # yes, did his progress help you at all? 01.17.20 # he still doing things on the loader side 01.17.23 # Of course 01.17.40 # having the tools he made was great 01.17.58 # plus the analysis of the existing firmware 01.18.06 # ah. so you two are the "main" gmini developers then. 01.18.43 # yup 01.19.38 # what models are you targeting? 120, 220, xs200? 01.19.44 # are they all similar hardware? 01.19.59 # all those. 01.20.08 # hardware very similar 01.20.20 # doesn't the 220 have a grayscale screen? 01.20.28 # yes 01.20.32 # is that the only one? 01.20.39 # That's what I consider a detail ;) 01.21.36 # elinenbe, the xs200 has a grayscale screen too 01.21.42 # If we don't want to take advantage of the grayscale feature supporting it is only a few pagefuls of code i guess. 01.21.52 # Yup 01.22.11 # the 220 has a CF slot though... 01.22.13 # how many grayscales? 01.22.14 # Maybe the grayscale stuff will be supported in rockbox for the i-river 01.22.22 # 4 i think 01.22.28 # ok, the same as the iriver then 01.22.36 # jyp: l think you should have anti-aliased fonts... 01.23.17 # First things first ... I'll take care of the sound support 01.23.32 # But I certainly welcome ANY contribution on a side issue. 01.24.33 # jyp: what DAP is in the gmini series? 01.24.56 # Strange thing... fat_create_dir flushes the whole fat cache... 01.25.54 # you know though... the gmini has a pretty nice GUI compared to the older Archos models 01.26.03 # It's much nicer... 01.26.30 # Actually, what I'm interested is supporting ogg playback 01.26.57 # doh, my gammar gets from bad to badder. 01.27.15 # haha, I'm too funny. 01.27.24 # :-) 01.27.48 # * jyp thinks he's tired. 01.27.54 # * Bagder is too 01.27.56 # Bagder: you're here! 01.28.11 # yeah, but not for long 01.28.26 # * jyp knows someone else who's tired too ;)) 01.28.49 # * Bagder has a patch for iriver scramble/descramble code in the works 01.28.49 # Good night folks. 01.28.54 # night jyp 01.29.02 # * jyp waves 01.29.03 Part jyp ("zoom!") 01.29.25 # Bagder: didn't that already exist? 01.29.35 # Still much yellow in the build table... 01.29.40 # I thought someone had made that a while back... 01.29.46 # there's a tool for it, yes, but I'm merging it into our tools 01.29.51 # oh, nice. 01.30.01 # to better fit our build system etc 01.30.41 # you know, I have a resume bug -- my recorder is set to auto-resume, and I am using a build of 3 days ago. When I turn it on and I am in a sub-dir, I am unable to exit from it... (press left to get out of it) 01.31.01 # Yeah.. get a recent daily build. 01.31.02 # * Bagder goes to sleep 01.31.49 # This was in for a couple of days, the remaining part of the fix was done on Friday (iirc) 01.31.58 # Bagder: No fixes for the yellow? 01.32.16 # *I* usually try to get the table green again for the upcoming daily... 01.32.25 # amiconn: thanks! 01.33.24 # (or better still, not causing yellow by solving the problems locally, before commit) 01.33.35 # (not always possible though) 01.39.22 # amiconn: do you just have a ondio? 01.40.06 # I have 3 archoses... a Recorder 20 (upped to 80), a Studio 10, and an Ondio SP. 01.41.14 # amiconn: when are you getting the gmini or the iriver?! 01.41.52 # No plans in that direction yet. There already much more stuff to do than time available... 01.41.59 # *There's 01.43.24 # come on... not THAT much left! 01.45.11 # My internal todo list currently contains 16 items... plus I stumble across bug after bug... 01.45.57 # oh man... what are the highlights of that? 01.46.50 # Simulator (Win32 only for now): Clickable buttons, backlight handling, grayscale support. 01.47.19 # ahhh the simulator is over-rated! 01.47.21 # Testing player flashing on oldplayers 01.47.25 # :) 01.47.43 # Ondio: MMC hotswap, MMC activity icon. 01.48.04 # Dynamic size display (including proper voicing) 01.48.56 # Code cleanup: bookmarking (not flushing the queue all over the place) 01.49.08 # Plus some smaller things.... 01.50.11 # that IS a pretty considerable about of stuff. 01.50.11 # and to think my list just has one item! 01.50.19 # a gameboy emulator for the grayscale devices ;) 01.52.16 # sprintf.c got loads of TABs now... 01.53.20 Quit elinenbe (Read error: 104 (Connection reset by peer)) 01.53.25 Join elinenbe [0] (trilluser@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.54.44 Join Trevmar [0] (~trevor@ca-agoura-cuda2h-53.ventca.adelphia.net) 01.57.59 Quit tws5 ("[BX] I theenk I need a beeger box!") 02.12.21 *** Saving seen data "./dancer.seen" 02.19.58 Join amiconn_ [0] (~jens@pD95D1D1C.dip.t-dialin.net) 02.22.47 Quit amiconn (Nick collision from services.) 02.22.48 Nick amiconn_ is now known as amiconn (~jens@pD95D1D1C.dip.t-dialin.net) 02.37.26 Quit Trevmar (Read error: 110 (Connection timed out)) 02.56.42 Join Trevmar [0] (~trevor@ca-agoura-cuda2h-53.ventca.adelphia.net) 02.57.37 Part amiconn 03.22.29 Join johntb [0] (~Baumans@66.216.165.81) 03.22.29 Quit elinenbe (Read error: 104 (Connection reset by peer)) 03.31.01 Quit Trevmar (Read error: 60 (Operation timed out)) 03.44.37 Quit johntb ("Leaving") 03.46.34 Join johntv [0] (~Baumans@66.216.165.81) 03.49.57 Quit johntv (Client Quit) 04.12.24 *** Saving seen data "./dancer.seen" 04.14.34 Quit midk ("Leaving") 05.18.27 Join Trevmar [0] (~trevor@ca-agoura-cuda2h-53.ventca.adelphia.net) 06.12.28 *** Saving seen data "./dancer.seen" 06.20.11 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 06.37.36 Quit Trevmar (Read error: 110 (Connection timed out)) 06.47.01 Join Trevmar [0] (~trevor@ca-agoura-cuda2h-53.ventca.adelphia.net) 06.49.29 Quit midk (Read error: 104 (Connection reset by peer)) 07.03.38 Join grimreap [0] (~grimreap@c-24-7-207-20.client.comcast.net) 07.42.03 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 07.52.33 Quit midk (Read error: 104 (Connection reset by peer)) 08.00.25 Quit Trevmar (Read error: 110 (Connection timed out)) 08.01.58 Join Zagor [242] (~bjst@labb.contactor.se) 08.05.34 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 08.12.32 *** Saving seen data "./dancer.seen" 09.33.56 Join kurzhaarrocker [0] (~knoppix@p5487C4C9.dip0.t-ipconnect.de) 09.36.15 Join Schnueff [0] (~mah@lap2.cs.uni-sb.de) 09.51.28 Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 09.51.31 Quit Bagder_ (Client Quit) 09.55.28 Join LinusN [0] (~linus@labb.contactor.se) 10.02.56 Quit ze ("leaving") 10.04.52 # thanks Bagder 10.05.48 # wrong name in commit comment though :) 10.05.59 # (cooper/hooper) 10.06.53 # however, the iriver tool is designed to encode entire iriver images, including the header which isn't present in the rockbox binaries 10.07.14 # so we won't be able to encode a rockbox binary as it is now 10.07.22 # hmm 10.07.30 # i'll fox that when the time comes 10.07.32 # fix 10.11.41 Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 10.11.54 # morning 10.11.58 # moo 10.12.04 # read the log 10.12.35 *** Saving seen data "./dancer.seen" 10.13.12 # * Bagder_ can't type 10.13.20 # that's no surprise ;-) 10.13.36 # it got right in the credits file though 10.13.40 # yup 10.14.08 # Bagder_: jukebox still working? :-) 10.14.21 # haven't used it yet! 10.14.40 # so i did all this work for nothing! ;-) 10.15.26 # LinusN: but I was thinking, didn't I give you it in my blue pouch? 10.15.31 # nope 10.15.35 # ok 10.19.55 Quit NibbIer (Read error: 104 (Connection reset by peer)) 10.21.29 Join NibbIer [0] (~andrer@port-212-202-193-173.dynamic.qsc.de) 10.25.59 # He didn't pay you, LinusN? 10.26.01 # :) 10.26.37 # I owe him a life time supply of pizzas by now 10.26.39 # he owes me at least three pizzas now :-) 10.27.12 # Man kan inte hålla sågen med svansen. 10.27.27 Join quelsaruk [0] (~kvirc@80.103.130.175) 10.27.32 # dwihno: always full of swedish wisdom 10.27.38 # good morning 10.27.45 # morning 10.28.39 # * dwihno <-- wise as rice! ;) 10.34.14 Join amiconn [0] (~jens@pD95D1D1C.dip.t-dialin.net) 10.34.32 # hi 10.34.39 # hi amiconn 10.35.31 Join Cassandra [0] (~Christi@213.78.106.176) 10.36.47 # Hi everyone. 10.36.53 # hi 10.36.53 Join MooMaunder [0] (~me@194.152.87.150) 10.36.55 # hi Cassandra 10.37.13 # I think my "record on start" patch has slipped through the cracks. Who do I need to prod? 10.38.40 # amiconn: did you update espanol.lang? 10.41.41 # I merely fixed the line ends. Nothing else. 10.42.09 # oh :) 10.42.14 # ok 10.42.20 # thanks 10.43.07 # microsofts autorouter is funny. Try to get from Hagesund, Norway to Trondheim, Norway using http://mappoint.msn.com/DirectionsFind.aspx and have a good laugh :) 10.43.09 # Zagor et al:Who is the fat.c expert? 10.43.45 # amiconn: zagor, i and [IDC]Dragon, i guess 10.44.53 # Did any of you read the logs? I've got a reproducable problem... 10.45.07 # Cassandra: i could have a look, but i'm swamped with work 10.45.24 # * LinusN searches the irc logs 10.46.21 # http://www.rockbox.org/irc/rockbox-20050123.txt , past 23:45 10.46.33 # reading it now 10.46.33 # linus: It's OK. I understand. I just wanted to make sure it hadn't been forgotten, really. 10.47.29 # LinusN: I tried to understand fat.c enough to fix it myself. No success so far :( 10.48.35 # you suspect a fat cache problem? 10.48.50 # Yes. 10.50.02 # It's in fact a strange problem. The video plugin can *read* the file fine, up to the end. But if it once reads past that certain position, 2 things happen: (1) It cannot seek back. (2) The root dir listing of the MMC disappears 10.50.21 # cool effect 10.50.54 # I could provide an image of that MMC, but this will be quite large (256 MB MMC, almost completely filled) 10.51.07 # that definitely suggests a cache bug 10.51.33 # large files don't scare me :-) 10.51.57 # I wanted to try adding some more strict mutexing, but for doing so I have to understand fat.c a bit more... 10.52.20 Quit NibbIer (Read error: 110 (Connection timed out)) 10.52.22 # as far as i know, the mutexing is pretty strict nowadays 10.52.36 # what would be really helpful is to try and create a plugin which reproduces the problem without user intervention 10.53.24 # Zagor: that won't help us much, since it probably only happens on this particular file system 10.53.37 # and we would need an ondio to run that plugin 10.53.49 # not if we get an image 10.53.51 # FAT16, btw? 10.54.10 # ´FAT16, yes 10.55.03 # Btw, I can't provide the image right now. MMC @home... 10.56.09 # ok 10.57.09 Join amiconn_ [0] (~jens@pD95D1D1C.dip.t-dialin.net) 10.57.41 Quit amiconn (Nick collision from services.) 10.57.42 Nick amiconn_ is now known as amiconn (~jens@pD95D1D1C.dip.t-dialin.net) 10.58.13 # amiconn: superfloppy? 11.00.25 # No, ordinary partition layout. 11.01.50 # ok 11.06.04 Join sox [0] (~s@c-af4fe353.733-1-64736c10.cust.bredbandsbolaget.se) 11.06.24 # hoy all rockboxers 11.07.01 # howdy 11.07.03 # i'm trying to build binutils, running mac os x. followed the instructions in the docs... 11.07.07 # amiconn: have you or jörg ran the fat tests on the multivolume fat16 code? 11.07.14 # Im getting this error, maybe someone can help me out 11.07.16 # *** BFD does not support target calmrisc16-unknown-elf. 11.07.16 # *** Look in bfd/config.bfd for supported targets. 11.07.16 # make: *** [configure-bfd] Error 1 11.07.32 # a gmini builder 11.07.50 # Zagor: Not me, as I don't understand the fat test code either.. 11.07.52 # from where did you download binutils? 11.08.12 # i got the CVS snapshot from gnu 11.08.29 Join ashridah [0] (ashridah@220-253-119-111.VIC.netspace.net.au) 11.08.41 # sox: there is no official gnu support for calmrisc 11.08.46 # amiconn: ok, i'll do it then 11.09.02 # i kinda had a feeling about that 11.09.14 # the instructions tell you to download binutils from sourceforge, not gnu 11.09.47 # ooops. ill try that. thanks for helping out. 11.09.51 # you're welcome 11.09.59 # "Get gcc & binutils directly from cvs" even 11.10.17 # http://www.rockbox.org/twiki/bin/view/Main/CrossCompiler#calmRISC16 11.11.11 # yup, i saw that now. sorry.... 11.11.44 # no worries 11.16.39 # Bagder: Thanks for fixing the remaining yellow, btw. I would have done this myself, but couldn't find the cause at 3 a.m. 11.17.15 # Zagor did that 11.17.22 # :-) 11.25.05 Quit Bagder_ ("Leaving") 11.28.16 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 11.28.44 # <[IDC]Dragon> hi guys 11.28.47 # hi 11.28.54 # hi Jörg 11.29.33 # <[IDC]Dragon> saw the logs 11.30.06 # <[IDC]Dragon> keep that precious image! 11.32.08 # <[IDC]Dragon> during multivolume debugging, I hacked the cod a bit to disable the fat cache 11.32.42 # <[IDC]Dragon> which, at it's time, didn't change anything 11.34.10 # <[IDC]Dragon> Zagor: I didn't run the file system test code again for multivolume 11.34.45 # <[IDC]Dragon> the tests require Linux, more or less 11.36.11 # If it is a fat cache issue with multithreading, I guess the test code won't find any problem... 11.37.10 # <[IDC]Dragon> your use case sounds singlethreaded 11.38.08 # <[IDC]Dragon> but true, the file sys test code doesn't stress multitasking 11.40.23 # I'll dump an image this evening, and then provide it. The question is: how? This is a huge file; not enough space on T-Online, and nothing for eMail. 11.41.11 # I can put it on my Amiga (dyndns address, but transfer will be a bit slow due to the dsl uplink 11.41.47 # put it up on the amiga, and i'll mirror it on the rockbox server 11.42.35 # <[IDC]Dragon> Bagder has a nice upload area on haxx 11.44.25 # Expect a transfer time of ~3.5 hours or so... 11.45.45 # wonderful :-) 11.50.46 # lunch 12.02.40 Join McLaren [0] (peteracer@ppp83-237-18-132.pppoe.mtu-net.ru) 12.03.16 # hi 12.12.38 *** Saving seen data "./dancer.seen" 12.17.55 # hi 12.23.52 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 12.32.59 # i've just received my box back from archos :) 12.33.24 # amiconn: they finally exchanged it :) 12.39.26 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 12.50.35 Join NibbIer [0] (~andrer@port-212-202-193-173.dynamic.qsc.de) 13.22.55 Quit McLaren () 13.23.30 # neat 13.23.40 # they just changed the disk? 13.25.24 # LinusN: here? 13.25.48 # yo 13.26.46 # I thought I'd just add 16 bits words and keep a 32 bit sum for a checksum 13.27.04 # then we can init the sum with a given 32 bit number 13.27.31 Join R3nTiL [0] (~zorroz@217.30.249.253) 13.27.46 # simple enough you think? 13.28.10 # should be water tight, methinks 13.28.38 # the question is, should the scramble tool take that number as an argument or should we make it like "h1xx"? 13.29.07 # I mean, should the tool know what the number is for, or should it just pass it on 13.30.09 # i think h1xx is best 13.30.19 # ok 13.30.34 # we can always change later otherwise 13.30.38 # btw, it seems like if H100 has a different scrambling 13.30.45 # than 120 and 140 13.30.54 # or maybe Dave was just assuming it 13.32.02 # I haven't seen any actual difference in the code, just that it detects them 13.32.55 Part Zagor 13.32.57 Part LinusN 13.34.08 Join LinusN [0] (~linus@labb.contactor.se) 13.35.20 # Bagder: they changed the full box 13.35.28 # aha 13.35.43 # but it is still a v1? 13.35.47 # yes 13.35.55 # goodie 13.35.56 # a V1 recorder20 13.36.07 # :) 13.36.13 # ready to install rockbox again 13.36.15 # :) 13.40.25 # hoy Linus and others, I got this error when running make install of the binutils (this time I checked out the latest version from sf) 13.40.25 Join Zagor [242] (~bjst@labb.contactor.se) 13.40.26 # ../../../../Downloads/binutils-2.15/binutils/doc/binutils.texi:5: @include `config.texi': No such file or directory. 13.40.27 # ../../../../Downloads/binutils-2.15/binutils/doc/binutils.texi:99: warning: undefined flag: VERSION. 13.40.27 DBUG Enqueued KICK sox 13.40.27 # makeinfo: Removing output file `../../../../Downloads/binutils-2.15/binutils/doc/binutils.info' due to errors; use --force to preserve. 13.40.27 # make[2]: *** [../../../../Downloads/binutils-2.15/binutils/doc/binutils.info] Error 1 13.40.28 *** Alert Mode level 1 13.40.28 # make[1]: *** [install-recursive] Error 1 13.40.30 # make: *** [install-binutils] Error 2 13.41.04 # quelsaruk: Flashable? 13.41.13 Quit Cassandra (Read error: 110 (Connection timed out)) 13.41.19 # amiconn: i hope so, haven't check yet 13.42.23 # great... 13.42.46 # i have all my batt. packs empty...i have to charge batts :( 13.44.00 # sox: linux? 13.44.31 # yes 13.44.47 # mac os x 13.44.48 # i have a vague memory about having the same error once 13.44.54 Join DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au) 13.45.04 # it was some package missing in my debian installation 13.45.17 # its only a documentation, maybe its something that doesnt really matter much for the build? 13.45.21 # with tex and such 13.45.57 # it shouldn't matter, but i don't know if it does something vital after the docs in the installation script 13.46.09 # hm... 13.46.13 # how goes the iriver? 13.46.20 # DMJC: same same 13.46.35 # is there anything a user can do? 13.46.44 # unfortunately not 13.47.07 # I mean sure I can do switch statements in C... and system calls! but yeah.. pretty useless 13.47.35 # ill try with -i and see if it works in the end... 13.47.45 # sox: good luck 13.48.07 # actually, forgetting iriver specific stuff, is it possible to hack on the rockbox interface at the moment? 13.48.19 # thanx LinusN! 13.49.12 # DMJC: yes it is 13.49.26 # build and run the simulator 13.49.53 # that also simulates display output? 13.49.58 # yes 13.50.28 # excellent 13.50.29 *** Alert Mode OFF 13.57.03 Join jyp [0] (~jp@56-6.240.81.adsl.skynet.be) 13.59.26 # hello there 13.59.31 # ho ho 13.59.34 # hi jyp 13.59.59 # what would be the proper way of testing int size (w/ preprocessor) ? 14.00.16 # there is none 14.00.32 # great ;) 14.00.48 # just what you wanted to hear 14.00.52 # I thought #if __INT_MAX__ == 0x7FFFFFFF 14.00.55 # normally people do configure tests for it and use those defines 14.01.11 # jyp: well, that could work as a poor man's version, yes 14.01.24 # jyp: why do you want a test? 14.01.46 # Looking to commit thread.c ... 14.01.53 # there I have either 14.01.58 # #define DEADBEEF 0xdeadbeef 14.01.59 # or 14.02.04 # #define DEADBEEF 0xddbf 14.02.16 # aha 14.02.29 # of course this can be dealt with differently 14.02.41 # like #define DEADBEEF (int)0xdeadbeef) 14.02.42 # the simplest way is to add a #define to config-gmini 14.02.45 # now if i tell it to build a simulated iriver.. 14.02.56 # will the firmware work in the simulator? 14.03.00 # eg display output etc? 14.03.20 # DMJC: only rockbox, not iriver firmware 14.03.20 # DMJC: it then builds a simulator, not a firmware 14.03.25 # it's a simulator, not an emulator 14.03.33 # what's the difference? 14.04.03 # jyp: like #define INTWIDTH 16 14.04.09 # so, heres another question. I get this error trying to build the Uisim build of iRiver for X11 14.04.10 # c-af4fe353:~/rockbox/rockbox-devel/build svante$ make 14.04.10 # make -C /Users/svante/rockbox/rockbox-devel/uisimulator/x11 14.04.10 # CC ../x11/thread.c 14.04.10 # In file included from ../x11/kernel.h:20, 14.04.10 *** Alert Mode level 1 14.04.10 # from ../x11/thread.c:23: 14.04.12 # ../../firmware/export/kernel.h:70: error: conflicting types for `sleep' 14.04.12 # or INTIS16BITS 14.04.14 # /usr/include/unistd.h:172: error: previous declaration of `sleep' 14.04.16 # make[1]: *** [/Users/svante/rockbox/rockbox-devel/build/thread.o] Error 1 14.04.17 # make: *** [sim] Error 2 14.04.35 # I'll have a look what AUTOCONF uses 14.05.04 # and if you feel my questions are just pain in the ass, let me know and Ill stop bugging you ... 14.05.54 # jyp et al: Is it perhaps possible to check sizeof(int) in a preprocessor directive? 14.06.06 # no 14.06.23 # sox: i've never built the simulator on os x, so you're on your own :-( 14.06.31 # the autoconf macro for doing the check builds and runs a C program 14.07.08 # DMJC: the simulator doesn't run the actual firmware, it is running rockbox on your pc 14.07.13 # ok, thanx anyways 14.07.14 # I know 14.07.22 # that makes sense 14.07.30 # now if I want to test media files 14.07.35 # DMJC: simulation v emulation is the difference between 'analyse actions/performance' and 'use to get stuff done'. 14.07.40 # k 14.07.49 # I want to try to hack on this 14.07.55 # jyp: don't invent a new way to do this. just use the config header. 14.07.57 # DMJC: the simulator doesn't play any media files at all (yet) 14.08.19 # Bagder: actually, it can play mp3 files if you compile with libmad 14.08.28 # thanks to eric lassauge 14.08.32 # will a plugin written for the archos compile for the iriver? 14.08.37 # is that applied and committed? 14.08.41 # eg, can I start writing code now 14.08.45 # DMJC: yes 14.08.53 # that's fine then 14.08.55 # Bagder: by not playing you mean, "there wont be sound", right? 14.09.03 # I don't care about sound output 14.09.10 # crash_: right 14.09.11 # crash_: the playback is simulated 14.09.15 # I have a working iriver for music heh 14.09.18 # DMJC: yeah sure, i just wanted to correct this ;) 14.09.22 # that's fine 14.09.53 # where would I put files to test with the firmware? 14.10.09 # DMJC: the firmware? 14.10.14 # the simulator 14.10.15 # heh 14.10.31 # DMJC: setup a dev env, get the source, build it, run it 14.10.35 # done that 14.10.44 # Well, let's no overdo it, I'll just use ((int)0xdeadbeef) 14.10.53 # DMJC: if you write a plugin, then add it to the plugins dir 14.10.53 # and put your files in the subdir archos 14.11.00 # ah k 14.11.02 # which is the simulated harddrive 14.11.10 Quit ashridah ("sleep") 14.11.11 # we might want to rename that :) 14.11.29 # Zagor: or leave it as a sign of our history! ;-) 14.11.33 # hehe 14.11.41 # :) 14.11.44 # (int)oxdeadbeef may create warnings about loss of precision 14.12.35 # gcc is happy with it 14.12.41 *** Saving seen data "./dancer.seen" 14.13.07 # LinusN: checksum patch for scramble coming up next 14.13.17 # nicers 14.14.11 *** Alert Mode OFF 14.14.42 # I'm not emotionally attached to the solutions, so feel free to fix whatever if you don't like 14.18.48 # thread.c committed. 14.21.57 Quit DMJC ("Leaving") 14.26.26 Join ze [0] (ze@adsl-63-205-40-9.dsl.lsan03.pacbell.net) 14.26.28 Quit R3nTiL () 14.26.33 # jyp: warnings 14.26.52 # you must use unsigned int 14.27.12 # and while you're at it, please add a comment as to why the constant is typecast 14.28.31 # k 14.33.05 # done 14.33.57 # good 14.34.37 # the build table is a good thing 14.34.40 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 14.34.40 # * Bagder runs off 14.35.31 Join Christi-S [0] (~Christi@213.78.105.189) 14.38.28 Join elinenbe [0] (~elinenbe_@65.115.46.225) 14.54.15 Join markun [0] (~markun@bastards.student.utwente.nl) 14.55.22 # I want to start coding unicode support for rockbox. I have some ideas I wrote down. Maybe someone can take a look at them before I start. 14.55.41 # markun: have you looked at the existing patch(es)? 14.55.54 # I have looked at the chinese patches. 14.56.11 # ok, good 14.56.38 # where can we see your ideas? 14.56.57 # I don't know. I can put the textfile on my webserver? 14.57.23 # sure. or make a wiki page. 14.57.42 # ok, I'll to that. 14.57.50 # (wiki) 14.58.17 # ok 14.58.53 # Don't know much about formating with wiki so I will first just put the text there, ok? 14.59.32 # go ahead 14.59.36 # sure 15.01.59 # http://www.rockbox.org/twiki/bin/view/Main/UnicodeProposal 15.02.15 # I will change the formating later. Can you take a look at it? 15.02.21 # yup 15.03.04 # Hm, the source code is pretty unreadable this way.. 15.04.05 # you can use standard html if you are more fluent in that.
 is good for source code
15.04.37 #        I used  now
15.05.11 #        right, that works too
15.06.08 #        The problem with convbdf now is that it allocates space for all possible glyphs between firstchar and lastchar.
15.06.22 #        yes
15.07.11 #        how do you propose to select which glyphs to use from unicode fonts?
15.07.50 #        I don't understand your question exactly..
15.08.21 #        How to leave out glyphs from a font when converting it?
15.08.25 #        yes
15.08.58 #        unicode fonts can be huge
15.09.51 #        Maybe tell the converter which code charts to include (or exclude) (http://www.unicode.org/charts/)
15.09.58 #        unicode.org seems to be down..
15.12.01 #        I think it would also be nice to make a ttfconv tool using freetype2. We could even render them anti-aliased for greyscale LCDs.
15.12.51 #        yes
15.13.33 #        Shall I put 'int colors' in the font struct?
15.13.57 #        int depth ?
15.14.01 #        ok
15.14.22 #        i don't think we should mix this with unicode
15.14.34 #        they are two separate problems, each non-trivial
15.15.05 #        Yes, I know. I want to do unicode, maybe add greyscale later.
15.15.27 Quit    midk (Read error: 104 (Connection reset by peer))
15.15.39 Join    midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
15.15.53 #        markun: you are not proposing a caching system, are you? i.e. you want to enlarge the font buffer rather drastically?
15.17.14 #        Zagor: I thought the whole font would be in memory. Is it different from the current implementation?
15.18.03 #        no, it's the same. but current fonts are naturally quite small, since they consist of at most 224 glyphs
15.18.18 #        a unicode font can be hundreds of kilobytes large
15.19.10 #        True. I have not thought about dynamically loading part of a font (I know the chinese patch does it)
15.20.27 #        without dynamic caching, we'll need to make this conditional. many archos users are likely not going to want to "waste" runtime for unicode support
15.20.37 #        it's much less an issue on iriver players
15.22.00 Quit    Christi-S ("If I were actually witty, this quitline would be funny.")
15.23.23 #        I will think about it.
15.24.40 #        i think compile-time or even runtime selection is a good thing
15.25.26 #        Compile time is not a problem
15.27.29 #        well, it doubles the amount of options on the download page
15.28.41 #        HD space it not a problem, so runtime would be a lot better.
15.30.11 #        I think dynamic caching would be the better way.
15.30.42 #        markun: What do you think is the most suitable internal unicode representation? UTF-8?
15.30.56 #        amiconn: definitely. but it's also the most complex way. i think starting with a simpler solution will make the code easier to develop and test.
15.31.13 #        UTF-32 would be the easy, but it takes up a lot of memory..
15.32.11 #        .. easiest ..
15.32.45 #        Zagor: A propos caching - your large db table support has problems. If I browse by artist, go to a certain artist, then dive into albums & tracks and go back up afterwards, I end up at a different artist...
15.32.45 #        And I don't think it's an option for 16-bit platforms.
15.32.50 #        Is HAVE_GMINI_I2C a suitable feature/macro name?
15.33.16 #        amiconn: ok
15.33.48 #        Zagor: And the db sorting could need some fixing (or an option for songdb.pl). Currently it sorts case sensitive.
15.33.50 #        markun: all our platforms handle 32-bit data and pointers, so it's not a major issue
15.34.05 #        amiconn: yes, there is lots to do on songdb.pl
15.34.27 #        btw, is the stuck-in-dir bug fixed or not?
15.34.32 #        fixed
15.34.37 #        i see reports of it still being there
15.35.03 #        where?
15.36.00 Join    R3nTiL [0] (~zorroz@217.30.249.162)
15.37.02 #        Zagor's latest change on this (don't show browser before resume) seems to have fixed it. At least I didn't observe it any more.
15.37.24 #       * jyp assumes yes, and commits i2c
15.37.38 #        ok then, i remember having seen a report about the 0119 build not working, but maybe zagors last fix was after that
15.38.30 #        yes, the last fix was the 21st
15.38.39 #        ok then
15.43.33 Part    LinusN
15.47.08 #        jyp: sorry for not answering. the name is fine.
15.48.04 Join    DMJC-L [0] (~DMJC-L@220-245-162-47-sa-nt.tpgi.com.au)
15.48.25 #        jyp: Red builds...
15.48.36 #        yup
15.48.53 #        Where is kernel.h for the simulator ?
15.50.06 #        uisimulator/win32/kernel.c needs to be fixed
15.52.52 #        fixed.
15.54.35 #        is there anything in particular holding up the iriver port?
16.00.15 Quit    R3nTiL ()
16.01.51 #        DMJC-L: time
16.02.28 #        lack of?
16.02.34 #        or it just takes a while
16.03.14 #        lack of it, unfortunately
16.03.36 #        anyway users can help that? donations etc?
16.04.19 #        donations are always nice, but they don't buy us more spare time :-(
16.04.50 #        I've got time... no skills
16.05.13 #        gotta go; see ya all
16.05.16 Quit    jyp ("poof!")
16.05.17 #        here's something... what kind of programming skills are needed for this?
16.05.30 Quit    sox ("Leaving")
16.05.38 #        C obviously, but is there assembler being usd much?
16.06.18 #        in these first things, yes. otherwise only very little.
16.10.57 #        gotta go
16.10.58 Part    Zagor
16.12.44 ***     Saving seen data "./dancer.seen"
16.30.35 Join    sox [0] (~s@c-af4fe353.733-1-64736c10.cust.bredbandsbolaget.se)
16.31.51 #        markun: im trying to compile gcc-3.4.2 for m68k-elf, and get this error I saw you reported a while back: operands mismatch -- statement `fmovem.l %fpcr,%d1' ignored
16.31.58 #        how did you solve it?
16.32.51 #        Well, I used two different versions of binutils. Let me check.
16.33.13 #        yes thanks
16.33.38 #        I used binutils-2.15 and the cvs version. 1 to compile gcc and the other to compile rockbox.
16.33.53 #        which one for what?
16.34.08 #        cvs for rockbox I think.
16.34.45 #        ok... too bad, i couldnt compile binutils-2.15 on my mac, but the CVS was good
16.36.20 #        I compiled it on my athlon running FreeBSD (similar to Darwin)
16.36.48 #        hm, ill try again and see if i get better luck
16.39.09 #        I'm not 100% wat the order of using 2.15 and cvs was.
16.39.36 #        well, if i cant compile one of them it doesnt matter, ill have to work that out first
16.40.16 #        in the IRC logs I see you asked bagder this: One more question about gcc: can I just as well download gcc-core-3.4.2.tar.bz2 instead of gcc-3.4.2.tar.bz2?
16.40.25 #        did you use the core version?
16.41.58 #        Yes, the core is all you need.
16.42.17 #        Also used 3.4.2
16.44.29 #        compile and install binutils-2.15 -> compile and install gcc-3.4.2 -> compile and install (overwrite) binutils from cvs -> compile rockbox
16.45.02 #        ok! nice and short description
16.46.31 #        What problems did you have compiling binutils-2.15?
16.48.17 #        does veryone in here develop for rockbox?
16.49.03 #        I've not contributed any code yet
16.56.19 #        amiconn, Bagder, [IDC]Dragon.. for example :)
16.56.22 #        kurzhaarrocker also...
16.56.35 #        og
16.56.43 #        i missread your question
16.56.44 #        :D
16.56.51 #        sorry
16.57.02 #        i need a "siesta"
16.57.49 #        Buenas sueños! (is that right?)
16.57.58 Quit    kurzhaarrocker (Read error: 54 (Connection reset by peer))
16.59.01 #        hmm... more or less
16.59.12 #        buenOs..
16.59.13 #        dulces sueños is more correct
16.59.16 #        or buenos
16.59.16 #        ok
16.59.17 #        :)
17.25.23 #        hey markun, you should add your description of what to compile and in which order to the documentation (and/or wiki)
17.29.40 #        ok, I will. Did you have any luck yet?
17.29.47 Join    mecraw [0] (~mecraw@69.2.235.2)
17.33.22 Quit    mecraw (Client Quit)
17.33.51 #        well, this time binutils-2.1.5 compiled ok, im compiling gcc now
17.34.03 #        looks good
17.35.11 Join    mecraw [0] (~mecraw@69.2.235.2)
17.42.15 Join    Spida_ [0] (Spida@pD9FFA417.dip.t-dialin.net)
17.45.24 Quit    Spida (Read error: 60 (Operation timed out))
17.47.13 #        sox: I changed the wiki page. Can you take a look to see if it's clear enough?
18.10.48 #       <[IDC]Dragon> quelsaruk: r u there?
18.12.45 ***     Saving seen data "./dancer.seen"
18.12.57 #        yups
18.12.58 #        here
18.12.59 #        :)
18.13.15 #       <[IDC]Dragon> did you do that spanish voice file?
18.13.24 #       <[IDC]Dragon> (in the wiki)
18.13.24 #        but with english accent
18.13.48 #        i'm trying now to get a spanish sapi5 voice
18.13.52 #       <[IDC]Dragon> just nitpicking: I think the version is wrong
18.14.09 #        the version?
18.14.47 #       <[IDC]Dragon> it says 1.140, but I don't believe spanish.lang has 140 revisions, just like the english
18.15.02 #        spanish is version 1.16 right now
18.15.09 #        i think that's an error
18.15.21 #       <[IDC]Dragon> so I thought, yes
18.15.48 #        i made version 1.15 and amiconn corrected those windoze end of lines, so he made version 1.16 AFAIK 
18.15.52 #        :)
18.16.00 #       <[IDC]Dragon> te wiki table line was probably just copied
18.16.04 #       <[IDC]Dragon> the
18.16.14 #        posibly :)
18.16.26 #       <[IDC]Dragon> do you want to fix it?
18.16.35 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
18.16.47 #       <[IDC]Dragon> or should I put 1.15 there?
18.16.58 #        i might have asked this allready, trying to build iriver uisimulator and getting this error
18.17.01 #        you can put 1.16 (last version AFAIK)
18.17.07 #        In file included from ../x11/kernel.h:20,
18.17.07 #                         from ../x11/thread.c:23:
18.17.07 #        ../../firmware/export/kernel.h:70: error: conflicting types for `sleep'
18.17.07 DBUG    Enqueued KICK sox
18.17.07 #        /usr/include/unistd.h:172: error: previous declaration of `sleep'
18.17.12 #        anyone seen it before
18.17.13 #        ?
18.17.21 #        oh, and thanks for changing it [IDC]Dragon :)
18.17.46 #        sox: not me, sorry
18.17.58 #       <[IDC]Dragon> np
18.18.31 #        [IDC]Dragon: do you have your jukebox near? i want to check one thing
18.18.50 #       <[IDC]Dragon> yes
18.19.07 #        i installed to my bro's box yesterday's CVS and he gets an End of playlist bug
18.19.27 #        try playing something, stoping, press on to resume play
18.19.35 #        and it should say "End of playlist"
18.20.20 Quit    mecraw ()
18.20.36 #       <[IDC]Dragon> no, it asks me for resume again
18.20.55 #        ¿?
18.21.05 Join    mecraw [0] (~mecraw@69.2.235.2)
18.21.20 #       <[IDC]Dragon> I have the resume prompt active
18.21.30 #        quelsaruk: Same for me. The last remnants of the resume bugs (end of playlist, stuck in dir) were fixed on Friday.
18.21.50 #        amiconn: but you still see that?
18.22.07 Quit    Schnueff ("leaving")
18.22.21 #       <[IDC]Dragon> my build is from the 19th or later
18.22.30 #        No, I mean same as [IDC]Dragon. Works correctly.
18.22.37 #        strange then...
18.22.53 #        maybe i didn't update correctly
18.22.56 #       <[IDC]Dragon> the timestamp dosn't get updated unless I do a full rebuild
18.22.58 #        i'll check now
18.23.08 Quit    elinenbe (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool")
18.23.19 #       <[IDC]Dragon> but my g/f yesterday had a stuck in dir problem, too
18.24.09 #        my brother gets the End of Playlist bug, and after that, can't use the browser.. he is stuck in that folder :/
18.25.27 #        so i have to hear him complaining for more than a week... "why do you install bleeding edge firmwares in my box? i like 2.4 version... blablabla..."
18.25.27 #       <[IDC]Dragon> I'm also not convinced that this is 100% gone, we'll see
18.29.53 #        testing my new box, 18.7 GB copied :)
18.29.56 #        and rockbox installed
18.33.15 #        hmmm
18.33.31 #        first weird issue
18.34.22 #        free disk should be 2MB, not 18.6GB
18.34.24 #        :/
18.35.32 #        amiconn: flashable jukebox: Flash: M=BF D=D6 ROM CRC: 0x222F V1 :D
18.36.05 #       <[IDC]Dragon> amiconn: about your MMC card: do you have to restore the image every time, or does it show the bug over and over?
18.37.24 #        The bug appears over and over (no writing to the fat)
18.37.36 #       <[IDC]Dragon> good
18.37.52 #       <[IDC]Dragon> have you tried chkdisk?
18.38.16 #       <[IDC]Dragon> to see if the f/s is ok
18.38.54 #        chkdsk -> no errors found
18.42.28 #       <[IDC]Dragon> interesting subject
18.50.36 Join    einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de)
18.51.29 #       <[IDC]Dragon> I'm off
18.51.33 Quit    sox (Read error: 110 (Connection timed out))
18.51.33 Quit    [IDC]Dragon ("CGI:IRC")
18.53.08 Join    Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com)
19.03.05 Quit    einhirn (Read error: 54 (Connection reset by peer))
19.16.46 Join    grimreap- [0] (~grimreap@c-24-7-207-20.client.comcast.net)
19.34.21 Quit    grimreap (Read error: 110 (Connection timed out))
19.49.18 Nick    Spida_ is now known as Spida (Spida@pD9FFA417.dip.t-dialin.net)
20.01.03 Join    jyp [0] (~jp@56-6.240.81.adsl.skynet.be)
20.10.30 Join    sox [0] (~s@c-784de353.733-1-64736c10.cust.bredbandsbolaget.se)
20.12.48 ***     Saving seen data "./dancer.seen"
20.13.07 Quit    quelsaruk (Read error: 104 (Connection reset by peer))
20.28.43 Join    edx [0] (edx@p548793B8.dip.t-dialin.net)
20.33.55 #        sox: any progress?
20.36.40 #        no
20.37.09 #        but i wonder about one thing. in the docs for compiling the crosscompiler it says "and use another path in the --prefix parameter as well"
20.37.40 #        this is only important if i want to have crosscompilers for both sh-elf and m68k-elf, right?
20.38.58 #        sox: yes
20.39.17 #        Did you remove line 70 from kernel.h?
20.39.42 #        no...
20.40.26 #        what does it do?
20.41.51 #        and where is it?
20.41.55 #        your compiler complained sleep was defined two times. Don't know for sure if removing is here solves it, but you might try.
20.42.21 #        firmware/export/kernel.h (it was in your error message)
20.42.52 #        ah
20.43.47 #        no, that just gave me other errors
20.44.23 #        Hm, don't know then.
20.44.24 #        i dont know for sure if anyone actually got the uisim working on Darwin, I never managed to success before, when I was doing Archos stuff...
20.44.48 #        In file included from ../common/file.h:62,
20.44.48 #                         from /Users/svante/rockbox/apps/tree.h:24,
20.44.48 #                         from /Users/svante/rockbox/apps/main.c:70:
20.44.48 DBUG    Enqueued KICK sox
20.44.48 #        ../../firmware/include/file.h:49: error: conflicting types for `ssize_t'
20.46.22 #        I had the same error in FreeBSD
20.46.50 #        that's good! 
20.46.55 #        then im not alone ;-)
20.46.58 #        Just comment out lines 45 till 69 in include/file.h
20.47.45 #        ok ill try that
20.50.18 Quit    NibbIer (Read error: 110 (Connection timed out))
20.51.21 #        ok, so how about this error then..... building the uisim
20.51.25 #        /var/tmp//ccKEf9lc.s:874:Expected comma after segment-name
20.51.25 #        /var/tmp//ccKEf9lc.s:874:Rest of line ignored. 1st junk character valued 32 ( ).
20.51.25 #        /var/tmp//ccKEf9lc.s:876:Expected comma after segment-name
20.51.25 #        /var/tmp//ccKEf9lc.s:876:Rest of line ignored. 1st junk character valued 32 ( ).
20.51.25 ***     Alert Mode level 1
20.51.25 #        /var/tmp//ccKEf9lc.s:1204:Expected comma after segment-name
20.51.26 ***     Alert Mode level 2
20.51.26 #        /var/tmp//ccKEf9lc.s:1204:Rest of line ignored. 1st junk character valued 32 ( ).
20.51.28 #        make[1]: *** [/Users/svante/rockbox/build/lcd-h100.o] Error 1
20.51.30 #        make: *** [sim] Error 2
20.52.25 #        What version of gcc and binutils are you using?
20.53.06 #        i followed your recommendations
20.53.20 #        but maybe there's a problem with apples gcc (3.3)
20.53.39 #        hey ...
20.53.48 #        jyp: hi
20.54.22 #        sox, trying to compile on the mac ?
20.54.29 #        yes.......
20.54.42 #        sox: are you compiling the simulator?
20.54.57 #        uisim is not to be cross compiled
20.54.57 #        yes, the iriver
20.55.35 #        Well, for the simulator you don't need the cross-compiler.
20.55.44 #        i dont think i am cross compiling it either...
20.55.52 #        ok
20.56.06 #        It is supposed to work on an apple arch ?
20.56.21 #        theoretically!
20.56.30 #        just asking
20.56.44 #        sorry, my frustration shines through, eh
20.57.44 #        the thing is i hardly know what im doing, so i probably make mistakes that i dont know of
20.58.52 #        np. Just asking questions in case I might be of some help
20.59.01 #        Well, I think your almost there. The error you see is because the assembler (part of binutils) doesn't like the assembly code (produced by gcc)
20.59.25 #        But I'm afraid my advices would remain in the theoretical world :) since I don't have a mac.
20.59.35 #        i did what you said and replaced binutils 2.1.5 with the cvs version
21.00.19 #        I thought that was only for building the cross-compiler..
21.01.01 #        heres what you wrote, maybe i misunderstood you: compile and install binutils-2.15 -> compile and install gcc-3.4.2 -> compile and install (overwrite) binutils from cvs -> compile rockbox
21.01.27 ***     Alert Mode OFF
21.02.16 #        Yes, that's for compiling rockbox with the m68k-elf cross-compiler, but not for the simulator.
21.02.44 #        Actually one should not replace the assembler after compiling gcc
21.03.25 #        Because gcc configures itself depending on the available assembler
21.03.48 #        (Irrelevant to fix your problem)
21.04.05 #        maybe, i wouldnt know, maybe you know markun?
21.04.07 Join    Pappy [0] (~pappy@193.184-ppp.3menatwork.com)
21.04.16 #        jyp: the problem was that gcc-m68k-elf did not want to compile with cvs binutils.. and rockbox didn't want to compile with binutils 2.15
21.04.18 Part    Pappy
21.04.52 Join    Pappy [0] (~pappy@193.184-ppp.3menatwork.com)
21.05.17 #        markun, if that works, it is fine... Just a general advice on how the toolchain works.
21.05.22 #        sox: what version of gcc and binutils do you have for darwin?
21.05.30 #        s/advice/comment
21.05.33 #        hello everybody
21.05.48 #        markun: do you mean apples or the ones Ive built?
21.06.00 #        apples one.
21.06.36 #        gcc: 3.3
21.06.51 #        and apples binutils? (ld --version)
21.07.10 #        can anyone suggest a way to test my Recorder's MC34063A chip?
21.07.31 #        (I think it is fried)
21.07.51 #        Apple Computer, Inc. version cctools-525.1.obj~8
21.08.09 Quit    mecraw ()
21.08.38 #        sox: hm, don't know what version that is..
21.09.17 Join    mecraw [0] (~mecraw@69.2.235.2)
21.09.41 #        markun: ill try to look it up 
21.10.40 #        ok
21.14.23 #        I am not sure if the chip is at fault, but the current get to it, and pins 1 2 6 7 8, all show voltage when using pin 4 as ground
21.14.51 #        any ideas?
21.18.55 #        Does anyone want to know what the symptoms are?
21.19.05 Ctcp    Ignored 2 channel CTCP requests in 2 hours and 27 minutes at the last flood
21.19.05 #       * jyp declines
21.20.14 #        ok
21.20.32 #        me neither
21.21.17 #        alrighty, I'll try some other time then
21.21.33 #        peace
21.22.03 Part    Pappy
21.28.47 Quit    sox ("Leaving")
21.32.09 Quit    markun ("Leaving")
21.36.19 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
21.37.24 Quit    jyp (Remote closed the connection)
21.39.30 Join    jyp [0] (~jp@239.219-201-80.adsl.skynet.be)
21.40.23 Join    sox [0] (~s@c-784de353.733-1-64736c10.cust.bredbandsbolaget.se)
21.40.58 Quit    edx ()
21.41.37 Quit    sox (Client Quit)
22.12.52 ***     Saving seen data "./dancer.seen"
22.29.39 Join    QT [0] (as@area51.users.madwifi)
22.30.10 #        hi
22.30.29 #        hi
22.30.33 #        hi
22.30.53 #        yeah, someone around. nice :-)
22.31.34 #        i heard rockbox started something for iriver h1x0 series players....
22.31.48 #        something = port
22.32.05 #        correct
22.32.18 #        have you ever had it running on the box already?
22.32.30 #        we run our own code on it, yes
22.32.38 #        i was reading the forums.rockbox.org section
22.32.58 #        oh, see, that i didn't read yet
22.38.10 #        ok, found a post by linus saying he's running the code already from flash
22.38.48 Quit    methangas (" HydraIRC -> http://www.hydrairc.com <- :P")
22.52.10 Quit    amiconn (Read error: 104 (Connection reset by peer))
22.52.17 Join    Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com)
22.52.49 Join    amiconn [0] (~jens@pD95D1D1C.dip.t-dialin.net)
22.53.02 Quit    amiconn (Nick collision from services.)
22.53.29 Join    amiconn [0] (~jens@pD95D1D1C.dip.t-dialin.net)
23.17.19 Quit    mecraw (Connection reset by peer)
23.17.36 Join    amiconn_ [0] (~jens@pD95D1D1C.dip.t-dialin.net)
23.17.46 Join    mecraw [0] (~mecraw@69.2.235.2)
23.30.24 Join    einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de)
23.31.32 Join    quelsaruk [0] (~kvirc@80.103.136.49)
23.31.38 #        hi
23.31.46 #        evening
23.32.33 #        ¬_¬
23.32.40 #        btw
23.32.59 #        the free space in rockbox info should be more or less exact, isn't it?
23.33.46 #        only if you let Rockbox recalculate it or don't use windows
23.35.04 Quit    amiconn (Read error: 110 (Connection timed out))
23.35.04 Nick    amiconn_ is now known as amiconn (~jens@pD95D1D1C.dip.t-dialin.net)
23.35.15 #        how can i let rockbox recalculate it?
23.35.45 #        and how can i delete windoze and use my software? ;)
23.35.59 #        I don't remember how to make rockbox do it ;-)
23.38.57 Quit    Stryke` (Read error: 60 (Operation timed out))
23.39.02 Join    LinusN [0] (~linus@labb.contactor.se)
23.39.03 #        damn...
23.39.10 #        hi LinusN 
23.39.16 #        hi
23.39.20 #        hi LinusN
23.39.27 #        enter the disk debug menu, go to the disk space screen and press play
23.39.31 #        LinusN: you nicked my batteries you thief! ;-)
23.39.35 #        LinusN: do you know how to make rockbox recalculate your hd free space?
23.39.39 #        i did?
23.39.43 #        that's for me?
23.39.45 #        :d
23.39.52 #        you are faster than me
23.40.12 #        you are always spying us?
23.40.14 #        LinusN: I had 2300 mah ones, there are 2000 mah ones in my recorder now
23.40.17 #        I've put up the MMC image on my Amiga
23.40.49 #        http://amiconn.dyndns.org/mmc_dump.zip
23.40.58 #        Bagder: what did they look like?
23.41.21 #        GP ones I believe, orange and green I think
23.41.35 #        amazing... i didn't know rockbox had this option
23.41.36 #        Attention: 245 MB! And please no 2 leechers at once. Will be way too slow for either one ;-)
23.41.45 #        hehe
23.42.05 #        Bagder: i think you're wrong
23.42.17 #        I've never had any batteries like this
23.42.33 #        I've only had the original ones and my new 2300 ones
23.42.59 #        funny, since i've never seen those batteries before either .-)
23.43.36 #        you sure that the 2300 GP batteries weren't in the one that was stolen?
23.43.49 #        I'm sure
23.43.53 #        I bought 8 2300 ones
23.44.03 #        I use 4 for my camera
23.44.22 #        really weird, i have only one set of 2300 GP batteries, in my own recorder
23.44.27 #        a box stolen in sweden? :O
23.44.50 #        hm
23.44.57 #        I was wrong, there are 2300 ones
23.45.03 #        just not the ones I had
23.45.11 #        these are even
23.45.17 #        so never mind
23.45.35 #        weird indeed
23.45.47 #        no batteries in it when you bought it?
23.46.04 #        sure, the original green ones
23.47.11 #        hm