--- Log for 01.03.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 25 days and 15 hours ago 00.03.00 Join chuck [0] (something@61-23-62-13.rev.home.ne.jp) 00.03.20 Quit bnewhouse (Read error: 104 (Connection reset by peer)) 00.05.05 # * HCl stares at the swap instruction. 00.05.35 # hrm.. 00.06.55 # where can i find the amount of cycles a swap instruction takes 00.06.55 # ? 00.08.10 # Segfault, hrmpf 00.08.47 # hci which architecture? 00.09.17 # HCl: coldfire2um.pdf 00.09.37 # HCl: it uses one 00.10.49 # okay. 00.10.51 # thanks 00.10.56 Join amiconn_ [0] (~jens@pD9E7FAD8.dip.t-dialin.net) 00.11.09 Quit amiconn (Nick collision from services.) 00.11.10 Nick amiconn_ is now known as amiconn (~jens@pD9E7FAD8.dip.t-dialin.net) 00.11.12 # * HCl reads. 00.11.37 # 1 clockcycle is efficient, i might have to rewrite biggg parts of my dynarec, but with the swap instruction, i'd be able to free 4 data registers for calculations 00.11.56 # against 1 at the moment 00.12.29 # that's going to be valuable 00.12.47 # I saw that you have macros for byte/short/long immediate load operations. 00.13.25 # That'll be tricky to adapt to sh, because on sh there is no way to place short or long constants within the instruction flow 00.13.47 # preglow: you think..? 00.13.48 # I have to come up with some clever workaround 00.13.54 # HCl: yes 00.13.57 Quit cYmen ("leaving") 00.14.14 # more than moving registers temporarily to the address regs and back? 00.14.17 # especially with the slow ram of the h1x0 00.14.25 # huh? o.o; 00.14.28 # ahhh 00.14.35 # if you've got free address regs, then nevermind 00.14.48 # the swap swaps two words in the dataregister back and forth 00.14.51 # it doesn't do anything with memory 00.15.12 # * HCl is confused... 00.15.25 # what do you mean nevermind if i have free address regs...? 00.17.19 # i think it might be efficient.. especially if i eliminate useless swapping 00.17.52 # * HCl goes to rewrite his dynarec, yet again :3 00.20.00 # i thought you meant using a register to store two words would free up some other registers so you wouldn't have to fetch data from ram all the time 00.20.21 # well, its mostly to free them for calculation 00.20.35 # i stored 1 gameboy reg in 1 m68k reg 00.20.43 # i think that with the swap, i might be able to make it more efficient 00.25.22 # now i can store half of them, 2 in 1 reg 00.25.36 # yes, that's what i meant 00.26.08 # what? 00.26.09 # o.o 00.26.17 # so is it more efficient or not? x.x 00.27.34 # :( 00.27.49 # * HCl prods preglow 00.27.53 # depends 00.28.09 # if you need both parts of the register simultaneously, you'll have to do some magic 00.28.31 # shouldn't be much of a problem, just move them to one of the other data registers.. 00.29.05 # meh, i'll just continue with how i was doing it before, and add it to the list of possible optimizations 00.30.11 # Lovely, rockboy segfaults in mem_read() ... 00.31.21 # Hmm, maybe it's my fault after all... 00.33.02 # It doesn't crash anymore :) 00.33.10 # does it work? :) 00.33.27 # Well, gfx doesn't work correctly yet 00.33.33 # kay... 00.34.00 # It seems that only every 8th pixel line gets refreshed 00.34.13 # yes, thats true. 00.34.19 # rockboy does that as an optimization 00.34.24 # if you'd ask me, thats a flaw in the simulator 00.34.38 # cause rockbox refreshes 8 pixel lines either way due to the internal bit format 00.35.06 # Yes... rockboy could however just use the 8-line refresh. It's in no way slower on the target. 00.35.14 # uh? 00.35.17 # how so? 00.35.20 # its a function call 00.35.24 # hence its obsolete instructions 00.36.12 # Yes. You call lcd_update_rect() every 8 lines. This should stay like it is, only that we can make the rectangle it refreshes 8 pixels high 00.36.41 # oh. right. 00.36.44 # yea. 00.37.15 # Btw, guess what my mistake was that caused it to crash? 00.37.22 # i suck at guessing. 00.37.24 # :P 00.37.30 # I forgot to cater for the different endianess.... 00.37.38 # hm... how so...? 00.37.47 # x86 is big endian. isn't it? 00.37.52 # nope 00.37.54 # oh. 00.37.55 # okay. 00.38.01 # well, it has a nice define in the makefile.. 00.38.10 # Yes. 00.38.35 # I'll also check x11 sim and iriver sims, then try the 8-pixel rectangle 00.38.42 # yea. 00.38.51 # can you like, build a diff against what you sent me last time? 00.38.53 # If all this works, I need to work a bit on the makefile conditionals 00.38.59 # then i'll apply it to my dynarec version 00.39.02 # and send it back to you 00.39.20 # No, sorry. I don't have a copy of what I sent you last time 00.39.25 # no problem, i do. 00.39.40 # I updated my rockboy path to current cvs.... 00.39.48 # path..? 00.40.09 # Yes, I have several cvs paths... 'working copies' 00.40.20 # so? o.o 00.40.55 # cd /tmp; tar xvfz youroldversion.tgz; diff -c (-r?) apps/plugins/rockboy 00.41.00 # o.o 00.41.37 # Btw, you're right that my Makefile doesn't clean properly 00.41.46 # I don't know why that is yet 00.42.23 # yea, i couldn't find it either 00.55.53 # bleh, 30 m68k instructions for a sub() 00.56.03 # yes 00.56.11 # there are quite a few 00.56.21 # ? o.o. 00.56.51 # move beats them all, though 00.56.59 # a zillion encodings 00.57.05 # Okay, lcd_update_rect() fix is working, X11 sim too. 00.57.10 # amiconn: nice 00.57.14 # amiconn: does it display? 00.57.19 # yup 00.57.22 # amiconn: is it playable? :P 00.57.28 # preglow: oh, i meant that i need 30 m68k instruction to emulate a z80 sub instruction :x 00.57.35 # instructions* 00.57.35 Quit Nibbler (Remote closed the connection) 00.57.45 # Yeah... sort of. I tried recorder sim first (guess why) 00.57.52 # HCl: what the hell? how? 00.58.05 # preglow: calculating the gameboy flags is *EXPENSIVE* 00.58.10 # :( 00.58.42 # The flags shouldn't be *that* expensive, methinks 00.59.12 # i think it sounds a bit over the top myself 00.59.42 # amiconn: the halfcarry calculation gnuboy provides is expensive.. 00.59.42 # here 00.59.43 # HCl: can't you use the 68k flags? 00.59.43 # let me paste 00.59.54 # for like zero and carry 00.59.59 # preglow: thats a future optimization i hope to have, m68k does not have halfcarry 01.00.05 # it already uses zero and carry 01.00.16 # here's the c code to calculate gameboy flags: 01.00.25 # The sh1 only has carry (called t bit there) 01.00.28 # W(acc) = (un16)A - (un16)(n); \ 01.00.29 # F = FN \ 01.00.29 # | (ZFLAG(LB(acc))) \ 01.00.29 # | (FH & ((A ^ (n) ^ LB(acc)) << 1)) \ 01.00.29 # | ((un8)(-(n8)HB(acc)) << 4); } 01.01.17 # amiconn: surely its able to calculate whether something is zero or not? 01.01.25 Quit methangas (" HydraIRC -> http://www.hydrairc.com <-") 01.01.48 # That requires an extra test operation to set the t bit accordingly 01.01.56 # ah. 01.01.57 # ok 01.02.03 # anyways. 01.02.09 # thats the code for compare / subtract 01.02.13 *** Saving seen data "./dancer.seen" 01.02.28 # amiconn: queer 01.02.35 # amiconn: all platforms i've seen have zero flag 01.03.05 # if anyone has any better solutions than 26 m68k instructions, 30 with the moving of %d2 to %a3 and storing/getting the result.. be my guest :X 01.03.15 # The sh platform is risc. Coldfire, although being risc itself, is based on 68k, which is cisc 01.04.05 Join Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de) 01.04.05 Quit Nibbler (Remote closed the connection) 01.05.43 # amiconn: sure, but most risc platforms i've seen have zero flag as well 01.05.43 # heh 01.05.50 # i really can't see the savings in not having one 01.06.08 # you have a smaller instruction set, ok 01.06.20 # but going to those extremes are just annoying, imho 01.06.59 # my god, i'm tired of asm 01.07.03 # As I already mentioned, the sh also has no way of storing short or long immediates in the instruction flow. Only byte immediates are possible with some instructions 01.07.21 # ahahah 01.07.34 # The benefit is that all instructions have the same length, and it's a short length - 16 bit 01.07.40 Join Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de) 01.08.12 # amiconn: sounds like it's a pain to do asm in, though 01.09.28 # Actually I think sh asm is pretty straightforward. It's easier than Z80 (which I used looong ago), and certainly way easier than x86 01.09.28 # phew, 1/3 done with opt, and it still makes nice sound 01.09.39 # if this opt does not help, i will jump out the window 01.09.54 # x86 isn't particularily intuitive 01.09.58 # the lack of registers is plain horrible 01.10.02 Quit lolo-laptop ("Client exiting") 01.10.19 # HCl: Mario is ~20 fps on my win32 (iRiver) simulator. Looks good. 01.10.26 # nice 01.10.53 # amiconn: cpu specs? 01.11.06 # Pentium M 1.5 GHz 01.11.08 # ~20 fps isn't particularily impressive 01.11.20 # amiconn: could i have the simulator exe and try it here? 01.11.34 # No... but then it uses several layers of bit shuffling 01.12.02 # Sure... you'll need the exe and the plugins. I'll make up a zip, hang on 01.12.07 # excellent 01.12.25 Quit Sucka ("a bird in the bush is worth two in your house") 01.12.27 # i'm on a 3400+ athlon64, should improve the fps some 01.14.47 # http://amiconn.dyndns.org/rockboy-win32.zip 01.16.07 # In addition to the several layers of bitshuffling, the win32 simulator also uses a bitmap drawing function that isn't designed for animation. 01.20.57 # hmm 01.20.58 # i get no files 01.21.12 # ? 01.21.19 # in the simulator browser 01.21.23 # do i need to pass it some flags? 01.21.27 Quit xen` (Read error: 113 (No route to host)) 01.21.44 # You need to set show files to 'supported' or 'all', like on the target 01.21.50 # :-) 01.22.06 # Well, this *is* a simulator, isn't it? 01.22.14 # yes, i just plain forgot about it 01.22.31 # i just did that once on my player and them promptly forgot about it 01.23.37 # hahah 01.23.41 # it's perfectly playable 01.23.57 # nice. 01.24.14 # buttons are a bit glitchy, but works just fine 01.24.29 # here ami, can you make a diff against that...? 01.25.05 # X11 sim (iriver) also working, a bit slower as expected 01.25.38 Join YouCeyE [0] (foobar@youceye.user) 01.25.45 # i certainly hope the buttons wont handle like this on the player 01.25.52 # how so? 01.25.59 # they stick a lot 01.26.07 # ah. 01.26.21 # dynarec will probably just make that worse :P 01.26.27 # maybe, anyways 01.26.50 # I think that this is caused by a combination of 2 things 01.27.17 # (1) rockboy uses the button queue, instead of reading the button status directly. 01.27.32 # (2) For the simulator, there is also the system's button queue 01.27.34 # which it should stop doing immediatly :) 01.28.01 # mmm, also, i'd like a direct interface to the iriver lcd framebuffer... it'd save a lot, i think 01.28.05 # optimizing with this cpu speed is not very rewarding 01.28.10 # there's never a measurable difference 01.28.22 # HCl: Not much, I guess 01.28.35 # amiconn: every instruction is one 01.30.02 # Yes of course. However, you cannot access the lcd buffer directly, this is to be done with lcd commands. 01.30.34 # i'm still pretty much using a setpixel() command, it'd save a lot if i could do that directly 01.30.42 # well, not a lot 01.30.44 # but at least some. 01.31.16 # The only thing that would be saved is the intermediate storage of the LCD_WIDTHx8 pixel rectangle (LCD_WIDTH bytes) in the rockbox framebuffer 01.32.28 # YOu'd still have to do that bitshifting (setpixel as you call it). The rockbox framebuffer format is that strange because this *is* the internal data format of the lcd 01.33.18 # This won't change with the introduction of 2 bit greyscale, btw. It will even get a bit uglier 01.33.34 # less.. it requires less bitshifts/ors 01.34.01 # Imho the amount of shifts/ors per frame will be the same, or even a bit more 01.34.47 # In 2-bit mode, one lcd byte "line" consists of 4 pixel rows instead of 8. Each byte represents 4 pixels. 01.35.02 # yes. 01.35.11 # then i can just cache 4 scanlines 01.35.14 # and do like 01.35.39 # byte&0x2<<0/2/4/6 01.35.41 # | 01.35.45 # 0x3 01.35.48 # not 2, my bad 01.36.03 # at the moment its byte&0x1<<0/1/2/3/4/5/6/7 01.36.07 # | 01.36.19 # or no, even worse actually 01.36.32 # byte&0x2>>1 / << 2 3 4 5 6 7 01.36.57 # Yes. Noiw you have twice the amount of shifts per scanline block. With 2 bit you'll have twice the amount of scanline blocks instead. 01.37.11 # yea, i guess you're right with that. 01.37.12 # o.o 01.37.27 # The current implementation doesn't do all those shifts, remember? 01.37.49 # oh. darn. 01.37.50 # you're right. 01.37.52 # that was my old version 01.43.45 Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 01.48.21 # HCl: http://amiconn.dyndns.org/rockboy-new.diff 01.48.33 # great, thanks 01.49.55 # halfway done... 01.50.09 Quit mecraw () 01.50.14 # quite some rejects 01.50.44 # amiconn: can you send me your plugin.h / plugin.c / plugins/Makefile / plugins/SOURCES ? 01.50.51 # has anyone had a look at the iriver battery indicator, btw? 01.51.16 # nop. 01.51.31 # it should be added to the not working section of the iriverport rather than "inaccurate" 01.51.51 # shouldn't be too hard to rectify 01.51.57 # i wouldn't know 01.52.45 # i think you read the battery level as a plain byte 01.52.51 # only have to interpret it correctly 01.53.55 # HCl: http://amiconn.dyndns.org/rockboy-new-extra.zip 01.54.14 # thanks 01.55.27 # ok, thats everything, most of it patched cleanly 01.57.48 # The Makefile in rockboy/ is most likely a bit different, and when you want to build for the target, there are some places to activate/deactivate by adding/removing # 01.58.12 # I did not yet come around doing those conditionals properly 01.59.34 Quit Renko ("Leaving") 01.59.55 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") 02.00.37 # kay. 02.01.53 # let me finish my dynarec changes 02.04.08 Join sevenapple [0] (~sevenappl@pcp08873970pcs.glstrt01.nj.comcast.net) 02.04.18 Join coob [0] (pen0r@host-84-9-63-253.bulldogdsl.com) 02.04.34 # there docs for the rockbox api anywhere that i'm blind to? 02.05.50 Join pear [0] (user@pcp08873970pcs.glstrt01.nj.comcast.net) 02.08.48 # Anyway, nite. 02.09.08 Part amiconn 02.10.02 Part pear 02.11.22 # coob: not much, there's docs/API 02.12.02 # agh i'm blind 02.12.19 # well, it isn't much 02.17.35 # too bad amiconn left. 02.17.37 # i want to go to bed, i'm afraid i won't be able to make sense of this in the morning :P 02.17.42 # * HCl merged all the changes. 02.17.53 # time for a cvs commit 02.17.58 Quit Camilo ("Chatzilla 0.9.67 [Mozilla rv:1.8a6/20050111]") 02.18.06 # (to my local repository) >.> 02.18.23 # nahah 02.18.36 # i've been able to shave four seconds off the decode! 02.18.51 # nice :) 02.18.52 # i hope to god it performs better on linus' player 02.18.59 # or i'll be severaly depressed 02.19.02 # aww. 02.19.09 # * HCl hands preglow a stuffed animal :x 02.19.12 # hahaha 02.19.20 # * preglow cuddles 02.19.25 # :p 02.20.05 # it needed to be done anywa 02.20.05 # y 02.20.05 # but my god, it is boring 02.20.57 # tell me about it. 02.21.04 # dynarec isn't very fun at the moment either. 02.21.10 # which codec are you talking about? 02.21.37 # mostly cause in my n64 dynarec, i used to be able to simply call the interpreter core for unimplemented dynarec instructions, causing it to always work, and just speed up the more you implemented.. 02.21.46 # and gnuboy is designed in such a way that thats impossible to do 02.22.45 # not only is that gonna give me a terrible debugging time when it finally runs, its also less fun during development :/ 02.23.02 # coob: mp3 02.23.21 # libmad? these coldfire optimisations or generic C ones? 02.23.29 # coob: coldfire 02.23.34 # darn :) 02.23.35 # coob: it's pure asm... 02.23.43 # about ten screens of it 02.23.49 # is that with sacrificed quality or without? 02.23.56 # ick, assembly coding sucks :x 02.24.00 # we need someone to optimise libmsd for arm 02.24.07 # *libmad 02.24.15 # why? it already is pretty optimized for arm 02.24.24 # well, once the dual cores are working sufficiently well enough 02.24.44 # HCl: full quality 02.24.46 # it is? 02.24.54 # * coob not actually looked at it, 02.25.02 # coob: sure, you've got optimized multipliers and an imdct written in pure asm 02.25.40 # good :) 02.25.53 # optimised multipliers using lookup tables? 02.26.34 # coob: no, arm has pretty good multiplier support 02.26.40 # bleh 02.26.46 # coob: libmad needs 32x32 bit muls, and arm's got just that 02.26.52 # coob: in a way that integrates perfectly with libmad 02.26.54 # i mean division using multiplication tables 02.27.07 # there is very little division needed 02.27.18 # \o/ 02.27.21 # just two screens of code left 02.27.30 # still, multiplicaiton - few cycles, division = 10x that 02.27.50 # coob: indeed, so good thing libmad almost never uses it 02.30.43 # standard operation that's used a lot is mac, and arm supports that directly 02.35.29 Quit rovragge ("Lost terminal") 02.37.23 # i actually lose i teeny bit of precision now, but i think i'll be able to remedy that and save some cycles at the same time 02.37.56 # sounds good 02.38.49 # i just need to find out how libmad generates some constants 02.44.07 Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") 02.45.10 # mrf... 02.48.17 # haha 02.48.27 # this exceeds all expectations 02.48.31 # nearly done, and it still sounds good 02.51.49 # mmm? 02.55.54 # i've got like 500 lines of assembly, there not being a mistake some place in there is... unusual... :) 02.56.52 # heheheh. 02.57.01 # yea, i know what you mean :x 03.02.17 *** Saving seen data "./dancer.seen" 03.04.15 Quit chuck (Read error: 110 (Connection timed out)) 03.06.46 Quit YouCeyE (Remote closed the connection) 03.07.58 Join YouCeyE [0] (foobar@youceye.user) 03.11.33 Quit YouCeyE (Remote closed the connection) 03.12.09 Join YouCeyE [0] (foobar@vp089036.reshsg.uci.edu) 03.13.16 Quit YouCeyE (Remote closed the connection) 03.16.29 Join YouCeyE [0] (foobar@youceye.user) 03.16.31 Quit YouCeyE (Client Quit) 03.23.00 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 03.29.01 # ok, ok 03.29.12 # the mistakes i'm making now are unbelievable 03.29.14 # bed for me 03.29.33 Quit preglow ("leaving") 04.05.16 Join QT [0] (as@area51.users.madwifi) 04.22.22 Quit QT_ (Read error: 110 (Connection timed out)) 04.39.01 Join chuck [0] (something@61-23-62-13.rev.home.ne.jp) 04.58.29 Quit sevenapple () 05.02.20 *** Saving seen data "./dancer.seen" 05.12.12 Join rickst131 [0] (UPP@resnet-51-215.dorm.utexas.edu) 07.02.24 *** No seen item changed, no save performed. 07.12.05 Join ze__ [0] (ze@adsl-69-231-212-121.dsl.irvnca.pacbell.net) 07.28.56 Quit ze (Read error: 110 (Connection timed out)) 07.28.57 Nick ze__ is now known as ze (ze@adsl-69-231-212-121.dsl.irvnca.pacbell.net) 07.29.45 Join StrathAFK [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net) 07.34.22 Join stevenm [0] (~steve@stevenm-router.student.umd.edu) 07.36.15 Quit stevenm (Client Quit) 07.58.28 Quit Strath (Read error: 110 (Connection timed out)) 08.24.13 Join webguest25 [0] (~c28aca0a@labb.contactor.se) 08.26.43 Join YouCeyE [0] (foobar@vp089036.reshsg.uci.edu) 08.27.48 Join jyp [0] (~jp@128.139-200-80.adsl.skynet.be) 08.46.21 Join ashridah [0] (ashridah@220-253-120-77.VIC.netspace.net.au) 09.02.27 *** Saving seen data "./dancer.seen" 09.02.40 Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a239.wi.tds.net) 09.31.58 Quit webguest25 ("CGI:IRC (EOF)") 09.35.36 Quit shx ("CGI:IRC (EOF)") 09.42.37 Join LinusN [0] (~linus@labb.contactor.se) 09.45.58 # linusn 09.46.04 # hi 09.52.00 # ahoy 09.53.16 # LinusN: less talking, more getting the sound on my iriver working :-D 09.53.50 # if you do that, i'll contribute some code to rockbox 09.58.44 # didn't someone have sound working already? :) 10.00.16 Join shx [0] (~a4810127@labb.contactor.se) 10.02.13 Join amiconn [0] (~jens@pD9E7FAD8.dip.t-dialin.net) 10.04.48 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 10.05.52 # ello 10.06.35 Join bobTHC [0] (~foo@l03v-35-190.d1.club-internet.fr) 10.08.01 # ello back 10.08.49 # hi all 10.08.55 # hey amiconn 10.09.06 # hi 10.09.27 # hows the iriver lcd driver coming? 10.10.04 # Erm, why do you ask me? I have no iriver (yet) 10.10.19 # cvs commit log 10.10.54 # he's been cleanign up general bugs in the simulator. 10.10.56 # or you just accepting the patches from another? 10.11.03 # i don't see any lcd commits from amiconn 10.11.17 # linus working on it then? 10.11.33 # "Fri Feb 11 01:06:14 2005 UTC (2 weeks, 4 days ago) by amiconn " 10.12.41 # that's still stuff for the simulator. 10.12.59 # Srath- the greyscale lib has been ported to the iriver lcd but I don't think that's been cvs'd yet. check out the logs for last night (about eleven hours ago) 10.13.06 # ^irc logs that is 10.13.29 # k thx 10.14.02 # Strath - some screenshots of a mandlebrot generator and a jpeg viewer using 4-color greyscale on iriver 10.14.18 # that's a misnomer. 10.14.23 # grey isn't a colour ;) 10.14.25 # hehe, you know what i mean 10.14.35 Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) 10.14.36 # 4-level greyscale 10.14.50 # so the greyscale isn't tied directly to the iriver lcd driver and is in a lib? thats good :) 10.14.54 # 2bit greyscale 10.15.22 # Strath: it makes sense to abstract it out, other players may have 2bit or more greyscale or even colour later. 10.16.04 # ya... i'm just starting work on the gmini 220 lcd driver, 4bpp lcd 10.16.05 # Strath - yeah, the greyscale lib isn't really limited to just greys. it's really a general drawing lib. imho all of rockbox should be switched over to use it 10.16.14 # Strath - neat-o! 10.16.59 # what about linear screen buffer vs. "line of columns" ordering? 10.17.47 # Strath - should be possible to store the screen buffer in whatever way suits your hardware best 10.18.01 # stripwax: if rockbox used the grayscale lib on the archos, the ui would slow down to a crawl 10.18.26 # and possibly eat a little more battery 10.18.41 # LinusN - really? that's a shame. I wasn't suggesting using the greyscale functionality on the ui, just the api 10.18.42 # k, didn't know how much of that was throughout the code 10.19.30 # LinusN i.e. set color, draw pixel, as opposed to draw pixel/clear pixel/invert pixel 10.19.48 # heh, that's my suggestion ;) 10.20.04 # amiconn - I agree with it ;-) 10.21.55 # we will need to add multicolor to the core lcd api 10.22.19 # any tips on getting started on that driver? minimal api function needing to be implemented? getting make to use it, etc? :) 10.23.03 # LinusN: Did you have a look at the grayscale lib api? 10.23.14 # no 10.25.56 # Strath: duplicate and existing lcd-....c, change SOURCES to use it; then hack ;) 10.26.25 # :P 10.28.51 # I think the lcd drivers should share most of the code. 10.29.07 # yes 10.29.08 # Only the low level stuff needs to be lcd controller specific 10.29.26 # * jyp fully agrees 10.29.49 # the tricky part would be that the frame buffer format could differ between the platforms 10.30.27 # Yes, but e.g. the line drawing algorithm, the range checking etc is identical for all platforms 10.30.52 # I consider most graphics primitives rather high-level 10.32.02 # assuming your drawing algorithms are wholely pixel based 10.32.14 # most of them are 10.32.48 # I'm assuming vertical line drawing is optimised for the byte layout on archos/iriver? 10.32.56 # nope 10.33.23 # Well, the routines that actually change larger pixel blocks (like fillrect() and bitmap drawing) profit from knowing the pixel format 10.33.25 # oh. is text printing pixel based too? 10.33.37 # no 10.33.46 # ok that's good 10.33.50 # that'd be slow ;) 10.34.24 # quite 10.35.00 # The problem for other display might be that our font format is currently tailored for the archos lcd data format 10.35.10 # bitmaps too i'd imagine? 10.35.32 # not all archos devices use that format amiconn :) 10.36.48 # amiconn: the iriver lcd has the same format 10.36.49 # stripwax: yes. 10.36.49 # would the font bitmaps need to be regenerated then for linear mapped devices? 10.37.01 # yes 10.37.15 # LinusN: Only when using 1-bit mode. In 2-bit mode it is similar, but not identical 10.37.30 # true 10.37.33 # The question is whether we should keep that format for b&w graphics 10.37.42 # I'd vote with yes. 10.38.34 # i'd vote for linear mapped files converted at compile/link time, but then i'm biased :) 10.38.48 # Drawing an 1-bit bitmap on a greyscale (or even colour) screen needs transformations anyway, so for those the order of bits doesn't really matter 10.39.06 Join Zagor [242] (foobar@h254n2fls31o265.telia.com) 10.39.12 Join _Zagor_ [242] (foobar@h254n2fls31o265.telia.com) 10.39.14 Quit _Zagor_ (Read error: 54 (Connection reset by peer)) 10.39.42 # we could just have the bitmaps chew up huge gobs of memmory... 10.40.01 # Strath: Now exactly that is not possible 10.40.01 # amiconn - unless the mono bitmap is stored in a 2-bit format, in which case no transformations are required... what would happen if someone wants to replace a mono bitmap with a 2-bit (or 8-bit, or..) bitmap? 10.40.27 # a joke, sheesh :P 10.40.35 # stripwax: Then he would have to change the drawing function call as well 10.41.06 # the fonts should be converted to the native format for each platform 10.41.13 # amiconn - i'm liking Strath's idea, where that kind of decision could happen at compile time (auto generated #defines for each asset, for example). or is that just way ugly? 10.41.24 # the same goes for the other bitmaps 10.41.34 # My suggestion is, the drawing functions should support 1-bit, 8-bit (and leaving open the option for 24-bit) 10.42.02 # 1-bit could use plain old archos format, 8-bit and 24-bit linear mapped 10.42.24 # that would slow down the lcd drawing on the iriver 10.43.55 # I dislike the idea to support any custom bit depths in between. That'll surely become a mess to deal with, when there are more and more different platforms 10.44.37 # I.e. old archos has 1-bit, iriver h1xx 2-bit, gmini 2xx 4-bit, iriver h3xx colour... 10.44.39 # still, the hardware is limited when it comes to cpu power and memory bandwidth 10.44.40 # well, each device could have it's own assets... 1bit, 2bit, linear, columns, whatever it's native format is, sharing on the devices that use the same formats, i assume the files rarely if ever change? 10.44.55 # Strath: exactly 10.45.31 # The problem is that plugin authors would then have to supply a bitmap for each architecture in case they want to use bitmapss 10.46.03 # or we develop a tool for that 10.46.07 # or limit plugin targets 10.46.20 # The bitmaps really need to be compile-time generated per device anyway imho 10.46.26 # Strath: That's not exactly the idea with rockbox 10.47.17 # i know... be easier than getting all plugin authors to generate bitmaps for each platform... 10.47.41 # LinusN: At *least*, the files which can be loaded & contain bitmaps (i.e. fonts) then need a header info which bitmap format they contain. 10.48.04 # (especialy for existing plugins) 10.48.17 # or they are converted in runtime, when loading 10.48.37 # urgs.... 10.49.09 # :-) 10.49.11 # big 'ol' can of worms :) 10.49.13 # ... or both 10.49.52 # Runtime conversion would imho add too much code, keeping in mind the limited memory 10.50.23 # The custom bitmap approach will then make the fonts platform specific 10.50.52 # unless you devise a platform neutral format and convert on compile... 10.51.00 # or make zip or whatever 10.51.29 # ashridah: exactly 10.51.40 # I'm talking about the target format for distribution. 10.52.26 # I.e. an archos/sh .fnt will then be different from an iriver h1xx .fnt which in turn will be different from a gmini .fnt ... 10.52.35 # yup 10.52.45 # attach a format tag to assets? if there isn't one in the native format for that device it uses a convertion function? 10.52.54 # nah 10.52.55 # In addition, having >1 bit fonts leads to additional problems 10.53.50 # With 1-bit, you have the notion of foreground & background, so you can draw e.g. foreground only, leaving the background transparent 10.54.22 # A similar approach is possible with the standard greyscale format (1 byte/pixel linear), using it as an alpha value 10.54.41 # This will get *very* hard to do in the target format.... 10.55.08 # in the fonts, value 0 would be the background 10.55.34 # Yes... still, how do you handle the other 3 values? 10.55.51 # With 1 byte/pixel, doing alpha, i.e. anti-aliasing, is easy. 10.55.53 # you want more transparent colors? 10.56.02 # blending.... uhg :) 10.56.25 # With the target format, this will turn out to be way slower 10.56.44 # why would we do antialiasing in runtime? 10.57.26 # Because you simply cannot do this at compile time 10.57.36 # no, but when you design the font 10.57.56 # This won't work either 10.57.59 # LinusN - that would only work if you *assume* the background is white, no? 10.58.10 # stripwax: of coyrse 10.58.10 # antialiasing != transparence 10.58.23 # LinusN: ..and white background _only_ 10.58.31 # amiconn: yes, and why is that a problem? 10.58.32 # Imho this is not what we want 10.58.48 # LinusN - it would fail if the background is grey, for example.. 10.58.54 # is transparency used in rockbox as it stands ? 10.59.00 # E.g. it will look veeery ugly with the selection set to 'bar (inverse)'... 10.59.23 # jyp, i think only draw the '1's 10.59.59 # Strath: I know, but it is really taken advantage of at the application level 11.00.00 # ? 11.00.07 # jyp: there can be no transparency in a 1-bit display 11.00.37 # Zagor: "drawing black only" ... 11.00.43 # Zagor - sure there can 11.01.04 # ok right, if that's your definition. then yes, we support and use it. 11.01.05 # Zagor - no trans*lucency* but transparency is just a case of masking.. 11.01.05 # Zagor: There can.... and even is implemented. Just that you only have 0% or 100% transparency 11.01.44 # stripwax: aha, i'm mixing it up 11.02.30 *** Saving seen data "./dancer.seen" 11.04.09 # Alright, so we have 3 possible features to support: transparency; translucency; reverse-video 11.10.09 # in various formats 11.12.13 # imho, antialiased fonts is very unnecessary 11.12.42 # only thing with storing 1bit fonts then is the cpu tradoff in text rendering on multibit platforms and not worying about translucency or antialiasing 11.12.50 # Re-thinking the issues with transparency & greyscale again, I'd still vote for plain linear 1-byte bitmaps on all platforms capable of greyscale. This isn't necessarily much slower than using the native format. 11.14.36 # i can live with that 11.14.44 # as long as font rendering is fast enough 11.15.28 # The current 11 MHz iriver is a good testbed... 11.15.33 # sounds ok with me. 11.15.36 # amiconn, i can agree with that 11.15.47 # lower 2 bits of a byte? 11.16.30 Join preglow [0] (thomj@s183a.studby.ntnu.no) 11.16.45 # here ami, your version, with my dynarec added 11.17.32 # HCl: No, always using the full range i.e. 0== black, 255 == white 11.17.43 # but converting to a native format for a file that rarly changes doesn't add too much of a burden on developers either ;) (basic system font anyways) 11.17.50 # darn.. 11.18.09 # amiconn, correct 11.18.30 # amiconn: for the file format, right? 11.18.41 # not runtime, i hope 11.18.53 # Strath: It's not about conversion. It's about using these bitmaps at runtime, e.g. drawing a black text on a grey background 11.19.13 # LinusN: I'm talking about runtime format as well as file format 11.19.31 # wasn't someone working on a more precise timer? 11.19.45 # so the lcd_bitmap() function would have to translate the gray values in runtime? 11.20.04 # yes, but i think we might actually be talking about seperate issues then 11.21.21 # HCl: how is dynarec going? 11.22.02 Join Patr3ck [0] (~patr3ck@pD9ECFC0E.dip.t-dialin.net) 11.22.03 # LinusN: Please have a look at the grayscale lib api. It supports 1-bit bitmaps as well as 8-bit bitmaps 11.22.10 # dwihno: slowly, not too efficient cause of z80 flags. building some opcodes from gcc, its a pain, really 11.22.24 # For 1-bit, there is selectable foreground colour, background colour, and draw mode 11.22.43 # ok... transparency, ya, runtime overhead wouldn't be much higher for 1bit fonts 11.22.51 Quit stripwax (Read error: 110 (Connection timed out)) 11.23.25 Quit shx ("CGI:IRC (EOF)") 11.23.34 # (maybe lower even...) 11.23.38 # HCl: I wish you the best of luck! :) 11.23.47 # There are 4 draw modes. Draw foreground pixels only, background pixels only, draw all pixels, and invert foreground pixels 11.24.08 # amiconn: i'm not concerned about the api, i'm concerned about the runtime performance of the bitmap functions and the font rendering 11.24.39 # * HCl thinks he'll just get downright dirtyish with the iriver lcd then... doesn't want to have to shift each byte of rockboy left 6 bits, only for them to be shifted right 6 bits again for 2bit grayscale.. 11.24.43 # draw all is the only one that would really gain from having native font format 11.25.29 # Strath: Exactly, and all other operations would be slower... 11.25.54 # well, xor with read value maybe... 11.26.02 # ...probably way slower 11.27.04 # xor, and, or, actually, it could speed up, i was thinking per pixel calculations 11.27.27 # HCl: a shift isn't very expensive... 11.27.47 # HCl: one cycle on coldfire, unless i remember incorrectly 11.27.48 # LinusN: If done properly, it shouldn't be much slower for solid drawing. For other modes (and current lcd_bitmap() supports this!) it would actually be faster imho 11.27.51 # preglow: every instruction is one too many 11.29.04 # HCl: yes, but if a minor performance hit is good enough reason to bypass all apis and talk directly to the hardware, rockbox source will end up looking like shit 11.30.10 # well, i'm only planning it for where i actually need speed - rockboy 11.30.38 # amiconn: how would the grayscale value translation be done? 11.30.52 # are there various fonts already in use or just the single system font? 11.31.13 # Strath: fonts are user selectable 11.31.59 # so, preglow, there are several to choose from.. 11.32.05 # Strath: a ton 11.32.09 # k ;) 11.32.20 # they all differ inn appearance and size 11.32.40 # hm, actually, nm, if 0 = black, i don't need any bitshifts *isn't awake yet* 11.33.19 # LinusN: After applying transparency etc, it's just a right-shift by 6 and a bit inversion (iirc hardware black is all 1's) 11.33.28 # LinusN: i brain damaged myself by asm optimizing imdct36 yesterday, so let me know if you're trying out libmad on your sped up h120 again 11.33.42 # preglow: sure 11.33.51 # hm, nm :x 11.33.59 # * HCl goes back to sleep before he says more stupid stuff >.> 11.34.13 # LinusN: did your previous 95% realtime result have any code placed in sram, btw? 11.34.32 # preglow: lots of code in sram 11.35.31 # amiconn: and those transparency operations, shifts and inversions would be added to the lcd_bitmap() function? 11.35.56 # and it wouldn't be much slower? 11.36.24 # i can imagine at least double execution time 11.38.08 # 'read, transform, write' vs 'write' 11.39.17 # LinusN: My point is that it is not different from using the native format *except* for when you draw solid 11.39.59 # I..e with 8-bit linear format you need transform-write for solid, while with native format you only need write 11.40.26 # (yes, i think i am arguing both sides of the issue, sorry ;) 11.41.13 # However, for other drawing modes you need readback-transform, transform, combine, transform,write with native format 11.41.34 # With 8-bit linear you only need readback, combine, transform, write in this case 11.42.25 # In fact, it would be even better if the framebuffer is also in 8-bit linear format for grayscale 11.42.50 # This way, only lcd_update() and lcd_update_rect() need to know about the internal format 11.42.54 # 220 and xs200 use a 4bit linear format 11.43.16 # no 11.43.28 # xs200 is unknown 11.43.29 # ;? 11.43.30 # ;) 11.43.37 # so an operation using a native format could handle two pixels at once 11.43.37 # amiconn: then the frame buffer would eat a lot more precious IRAM, and lcd_update() will suffer a lot 11.44.14 # jyp, it's 2bit/pixel stored in 2pixel per byte format 11.44.34 # at least in the frame buffer or the archos firmware 11.44.41 # s/or/of/ 11.45.02 # Yup, but framebuffer is linear for the 120/SP too 11.45.08 # doesn't tell you much 11.45.15 # LinusN: True for the increased ram usage. However, doing the conversion to native format in lcd_update() might be done rather fast, because then you can always convert a whole block of pixels that corresponds to one hardware byte at one 11.45.19 # jyp :P 11.45.19 # *at once 11.45.38 # amiconn: true 11.46.24 # I actually consider doing this for the grayscale lib too to make it go faster (with also using a back buffer to only translate blocks that actually changed) 11.47.35 # Actually, the fastest way would be to use an 8-bit linear buffer, although not using 0..255, but the actual target bit depth 11.47.36 # ami, your talking about transfering the data to the lcd controler, not the frame buffer? 11.48.10 # Strath: Exactly. My suggestion is to have the framebuffer in 8-bit linear format, and doing the transformation during transfer to the controller 11.48.13 # i2c writes and what not 11.48.33 # what if your lcd controler uses dma? :) 11.49.00 # Then you would need an additional dma buffer 11.49.45 # LinusN: With that approach (using an 8-bit linear buffer together with a back buffer, storing the values in the target's bit depth), I'm quite sure to get a greyscaled cube.rock running realtime on the archos 11.51.36 # still, lcd_update() would be 5-6 times slower 11.51.43 # even more 11.52.37 # The transfer itself is going to take much longer than the conversion anyway, or am I wrong? 11.53.18 # the transfer is parallel 11.53.50 # Okay. 11.54.00 # a simple move.w 11.54.26 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 11.54.42 # I agree that this would make lcd_update() slower, but all other graphics operations should be faster. 11.55.23 # Do you have a clue what the overall performance change would be? I guess it will go faster overall... 11.55.28 # too many variables ;) 11.56.32 # bit depth, storage format, controler transfer method, pixel effects, aaaah! 11.56.32 # ...and you get the possibility for font anti-aliasing, transparency etc almost for free. 12.01.55 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 12.03.19 # ello 12.03.49 # So, power cuts across a bunch of internet routers, i just got kicked right out of cyberspace 12.03.55 # ami, a really really don't see a need at all for anti-aliasing or translucency, transparency and inversion can be done faster/easier in the native format awyways (linear vs non) 12.04.16 # s/a/i/ 12.41.03 Join webguest01 [0] (~81b1111b@labb.contactor.se) 12.41.18 Join sox [0] (~sox@c-5d3ce255.733-1-64736c10.cust.bredbandsbolaget.se) 12.42.52 Quit webguest01 (Client Quit) 12.43.40 # Strath: I agree that anti-aliasing and translucency isn't top priority, however, we certainly will see numerous requests for that. 12.44.24 # Plus, I doubt that transparency and inversion is faster & easier in the native format. 12.47.04 # but would it ever be worth implementing anti-aliasing and translucency on such a low powered device? even if requested... 12.48.31 # hahah 12.48.47 # i seriously hope transparency isn't a design constraint 12.49.07 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 12.50.55 Join shx [0] (~a4810127@labb.contactor.se) 12.53.16 # i'd love a transparent mp3 player ;) 12.53.23 # lol 12.54.16 # preglow: Transparency (as 1-bit) is already implemented. Strath etc. use the term 'transparency' for 1-bit, and 'translucency' for multi-bit transparency 13.00.10 Join [Unseen] [0] (~e@pc2996.gsf.de) 13.02.31 *** Saving seen data "./dancer.seen" 13.07.03 # * jyp spots [Unseen] 13.07.10 # Gotcha! 13.07.25 # <[Unseen]> heh? 13.07.41 # Your nick ... Nevermind :P 13.08.00 # <[Unseen]> lol 13.09.45 # silly jyp, nick are for ... 13.10.35 Nick [Unseen] is now known as SeenByJyp (~e@pc2996.gsf.de) 13.12.19 # ok, sleep to now time is it me for think I 13.18.52 Join Patr3ck_ [0] (~patr3ck@p548CBADF.dip.t-dialin.net) 13.32.41 Quit Patr3ck (Read error: 110 (Connection timed out)) 13.42.37 Quit ashridah ("sleep") 13.58.45 Quit Nibbler (Read error: 113 (No route to host)) 14.09.04 Join ze__ [0] (ze@adsl-69-231-211-53.dsl.irvnca.pacbell.net) 14.17.06 Join elinenbe [0] (~elinenbe_@65.115.46.225) 14.23.19 Quit ze (Read error: 110 (Connection timed out)) 14.23.20 Nick ze__ is now known as ze (ze@adsl-69-231-211-53.dsl.irvnca.pacbell.net) 14.26.58 Quit Zagor ("Client exiting") 14.35.44 # preglow: i have now committed a fix for the codec dependencies 14.36.44 # but i'm not yet sure how to make the plugins depend on the codec libs 14.37.03 # great nonetheless 14.37.22 # you only want the *2wav plugins rebuilt, not all of them 14.37.40 # yes, but it beats having to make clean every time 14.37.43 Quit SeenByJyp () 14.38.02 # i also moved the main stack to iram 14.39.50 # i think i'll make a separate asm file of this imdct_l business, it's quite ugly 14.40.23 # is it easy to place certain variables in iram? 14.44.48 # int myarray[1024] __attribute__ ((section(".idata"))); 14.45.03 # the mdct stuff doesn't do much but access ram and mac it, so i guess having the input and output arrays in iram will be important 14.46.46 # there's of course the penalty of moving it there 14.48.14 # why does it have to be moved there? 14.48.31 # iram is in the same address space as sdram? 14.49.48 # i mean if you want the input data in iram, you have to move it from the big sdram buffer to the small iram array before the imdct 14.50.43 Quit lostlogic ("Going to the moon") 14.50.51 # ahh 14.51.01 # well, no, not exactly 14.51.10 Join Renko [0] (~Renko@host81-152-87-182.range81-152.btcentralplus.com) 14.51.18 # it has to be handled by the huffman decoder first 14.51.33 # and that might require less memory bandwidth that way 14.51.39 # preglow, LinusN: what's the current speed of the mp3 codec on the target? 14.51.59 # there are several layers before the mdct sees it 14.52.28 # elinenbe: we have reached 95%, but that's in 140MHz and with non-CVS hacks 14.52.38 # preglow: ok 14.52.44 # it should be realtime with my latest opt 14.52.55 # at least, i'll be severely disappointed if it's not 14.53.37 # i have lowered the max freq to 96MHz in my soon-to-be committed cpu frequency fix 14.54.01 # so you'll just have to optimize some more :-) 14.54.46 # can you send me a patch? 14.55.42 # well, yes, but it's a bloody mess and has to be kept from the public :) 14.56.14 # hehe 14.56.24 # it would be easier if i could just send you the entire file, it's going to be a messy patch 14.56.29 # sure 14.56.38 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) 14.56.52 # is it stable at 96MHz? 14.57.05 # http://glow.m0f0.net/rockbox/layer3.c 14.57.42 # you'll still need the emac.h 14.58.20 # ok 14.59.56 # non-optimized mpa2wav is 40% with only my latest stack fix 14.59.59 # in 96MHz 15.00.06 # not too shabby 15.01.29 # ripnetuk: i don't know yet if it is stable 15.02.03 # but no nasty ata issues like we had at full speed yet? 15.02.33 *** Saving seen data "./dancer.seen" 15.02.35 # not yet, but i'll have to run it a while to heat up the hard drive 15.02.47 # yeah... intermittent problems are the worst 15.04.44 # preglow: quite a disappointment...46% 15.04.51 # ....... 15.05.04 # LinusN: is that with synth.c opt as well? 15.05.12 # no 15.05.15 # arhghh 15.05.34 # maybe i should try optimizing the other imdct 15.06.00 # forgot the synth.c, hang on... 15.06.14 # synth.c helped more, if i don't remember incorrectly 15.06.19 # yes 15.06.37 # but moving code and tables to iram helps a *lot* 15.07.01 # i moved plenty of constants and tables to iram last time 15.07.08 # but not now 15.07.25 # yes 15.07.56 # we'll have to find the hotspots and put that in iram 15.08.00 # i don't think we have a choice in that matter 15.08.15 # no we don't 15.10.04 Quit edx (Read error: 110 (Connection timed out)) 15.10.10 # 54% with synth.c 15.11.06 # i read somewhere that the huffman decoder is pretty demanding as well 15.11.19 # but that looks like its just a huge lookup table in libmad 15.11.42 # i moved those to iram last time, made a noticeable difference 15.13.40 # .. sorry for the dumb question, but what is "iram"? 15.14.03 # ram that's internal to the coldfire 15.14.07 # single cycle acces 15.14.20 # _very_ fast compared to the sdram, but there's only 96kb of it 15.14.28 # i thought that would be called sram... why are you calling it iram? 15.14.40 # (I)nternal RAM 15.14.44 # dunno, because everyone else is calling it iram? :P 15.14.49 # sram/iram, i don't care 15.15.49 # we weren't the other day :-p so are we moving the current track's codec's tables to sram at runtime or are we locking the contents of sram at build time? 15.16.06 # but the mdct opt has to suffice at the moment, i don't have time to optimize something that big again for a couple of days 15.16.21 # i'll clean my opts up a bit 15.16.28 # so people can use them 15.16.43 # stripwax: it'll have to be used dynamically 15.16.49 # stripwax: as i said, there's only 96kb of it 15.17.14 # preglow thanks, didn't know how big the tables would be 15.17.45 Quit HCl ("Lost terminal") 15.18.06 # LinusN: You could run test_fs for a while to see if it is stable at 96 MHz 15.18.13 # yes 15.18.21 Join hcl [0] (hcl@titania.student.utwente.nl) 15.18.25 Nick hcl is now known as HCl (hcl@titania.student.utwente.nl) 15.18.48 # Just choose the number of passes so that the file size is just below 2 GB, and let it run.... 15.19.12 # whats up? 15.21.06 # not much 15.21.32 Quit jyp (Read error: 110 (Connection timed out)) 15.21.41 # the usual optimization discussions 15.22.06 # HCl: my opt turned out to be of little signifigance... 15.22.31 Join webguest90 [0] (~c0a5d512@labb.contactor.se) 15.22.33 # preglow: are the dct constants in iram? 15.22.37 # quite luckily the weather is excellent, so i'm hard to depress 15.22.41 # LinusN: they're code 15.22.59 # LinusN: i do move.l #const, %%reg _all_ the time 15.22.59 # LinusN: I would even suggest to increase the clock gradually, and check when it starts to produce errors 15.23.15 # preglow: :( how so? 15.23.23 # amiconn: that's an idea 15.23.40 # HCl: it gained 6%, from 40% at 96mhz 15.23.51 # well, at least its something 15.23.54 # HCl: which is a bit less than i hoped for 15.23.56 # but yes 15.23.58 # i had to try 15.24.04 # preglow: from 40% to 46% realtime is a 15% speed increase 15.24.09 # clearly we'll get it to work some how, we can resort to reverse engineering the original firmware if all fails 15.24.20 # HCl: it won't come to that 15.24.28 # there are a lot of clever people around 15.24.28 # hm 15.24.31 # if you say so 15.25.10 # synth_full() should be in iram 15.25.14 # LinusN: indeed 15.25.41 # i don't know how often synth_half will be used 15.25.50 # i think that's used for half sampling rate synthesis 15.25.53 # preglow: I admit that I have problems to understand imdct. I had a quick look at the jpeg decoder, whether I could MACify it. 15.25.55 # which no one in their right mind does 15.26.36 # amiconn: that's an idct, not an imdct :P 15.27.23 # amiconn: sh1 has mac? 15.27.32 # yes 15.28.08 # preglow: It has mac. 16x16bit -> 42 bit 15.29.08 # amiconn: cool 15.29.29 # amiconn: i'd love to have a look, but haven't got time right now 15.29.55 # quick question... does the target produce any sound right now? for anyone? 15.30.38 # there's a wav play thing on the wiki. 15.36.03 # LinusN: could you tell me briefly what i need to watch out for to avoid sdram fetch stalls? do i have to keep the accesses strictly sequential? 15.36.29 # yes 15.36.48 # but i haven't enabled the page mode yet 15.36.56 # what does that do? 15.37.20 # faster access time for sequential fetches 15.37.38 # ahh 15.37.39 # goodie 15.37.40 # right now you have only burst access, very rare 15.37.46 # yes, movem only, i guess 15.39.12 Join webguest00 [0] (~81b1111b@labb.contactor.se) 15.40.35 # preglow: cpu boost committed 15.40.43 # LinusN: excellent, will test it out right now 15.40.55 # it is not enabled by default 15.41.02 # you do like this: 15.41.12 # enter debug->view i/o ports 15.41.28 # hi, I was reading the logs. Do you know that there is a demo mp3-decoder for coldfire MCF5249L 15.41.38 # then UP for max frequency (96MHz), DOWN for normal (which is 48MHz) 15.41.45 # webguest00: yes 15.41.53 # ok, hehe, guessed that 15.41.57 # or SELECT for 11MHz 15.42.05 # LinusN: great, a lot easier to time my own code now 15.42.12 # yes 15.42.26 # i'd have to perform miracles to see a difference at 11mhz 15.43.08 # pretty impressive assembler blobs in layer3.c :-) 15.43.09 Join lolo-laptop [0] (~lostlogic@68.251.84.226) 15.43.13 # LinusN: i agree 15.43.33 # i completed it at 04:00, haha 15.43.35 # my brain was fried 15.43.57 # i'll have to finish it fast, before i forget what's what 15.44.13 # preglow: the idea behind the cpu boost stuff is this: 15.44.37 # when you need extra power, call cpu_boost(), it will set the cpu frequency to maximum 15.44.48 # LinusN: hah! extremely cool 15.44.54 # when you're done, call cpu_boost(false) 15.45.01 # nice 15.45.03 # and it'll clock it at 140mhz ? 15.45.07 # 96 15.45.24 # several threads may call cpu_boost(true) 15.45.29 # ahh, yes, but using 140mhz might be viable there? 15.45.37 Part webguest00 15.45.42 # will have to test to determine that, i guess 15.45.44 # but the frequency will not be lowered until all threads have called cpu_boost(false) 15.46.01 # boosting the cpu takes up to 10ms 15.46.05 # oh 15.46.08 # is there much advantage in running in slow mode? less power usage? less overheating? 15.46.12 # pll probably needs to readjust 15.46.14 # when I say slow, i mean normal 15.46.15 # less power usage 15.46.27 # preglow: yes, it's the max locking time 15.46.46 # but wont 99% of usage be urm, playing mp3's, which seems to require the full power 15.46.52 # so you shouldn't call cpu_boost() often 15.47.12 # wtf? freq selector is locked at 11mhz 15.47.33 # the what? 15.47.43 # io ports stuff wouldn't let me choose 96mhz 15.48.13 # up for 96, down for 48, select for 11 15.48.18 # it's a veritable greased ligtning 15.48.19 # hahahaha 15.48.24 # decoded my test file like lightning 15.48.28 # 50% realtime 15.48.44 # feels nice, doesn't it? :-) 15.48.48 # it indeed does 15.49.06 # have to run, cu around 15.49.10 # yep 15.49.13 Part LinusN 15.49.20 # i'll go enjoy the sun and my h120, later 16.04.28 # He ended up using a piezo element to output the firmware as a series of sounds, which he recorded and analyzed on his PC to convert the squeaks and squawks into a digital representation of the code. He essentially turned iPod and microphone into an acoustic modem 16.04.30 # now THATS creative 16.05.06 # wot? 16.05.30 # http://www.engadget.com/entry/1234000907033676/ 16.05.34 # freaky, somewhat 16.07.18 # old news 16.07.25 # that happened in like december 16.07.38 # and they used the screenshot of all 0's where it didn't work :/ 16.07.46 # journalists = slow and lousy! 16.07.50 Quit webguest90 ("CGI:IRC (Ping timeout)") 16.09.06 # well it was news for me :) 16.09.35 # i preferred my method :-) 16.09.55 # he wanted to do it without cracking open his ipod... 16.10.13 # having sex with an iriver employee? :) 16.10.23 # social engineering, i think its called :P 16.10.32 # coob - I didn't have to open my iriver, or have sec with any employees 16.10.59 # jects/rockbox/cvs/rockbox/build/sim/rockbox_flash.o 16.11.05 # sorry... 16.11.06 # ? 16.11.12 # accedential paste 16.23.57 # hi, i have made a plugin called iriverfirm.rock that loads the original firmware (combination of helloworld.rock and LinusN's code from bootloader's main.c) - any interest in this? 16.24.13 # i need it for when I accedentially boot the rockbox when I just wanna play mp3's 16.29.40 Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) 16.29.48 # for the log, if anyone is interested i have put it at http://files.ripnet.co.uk under rockbox (iriverfirm_plugin.zip) - both source and .rock are there 16.29.56 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 16.38.12 Quit chuck (Read error: 60 (Operation timed out)) 16.52.35 Join edx [0] (edx@pD9EAB914.dip.t-dialin.net) 16.57.07 Join stevenm [0] (~steve@stevenm-router.student.umd.edu) 16.58.05 # Hello people. I'm trying to perfect the MIDI codec a bit... namely, I am getting some high-pitched hissing on high notes, especially strings. Did someone mention there being an interpolation algorithm to get rid of this? 16.58.33 Part linuxstb ("Leaving") 16.59.41 # Right now I have a ghetto lowpass filter on the output, but there must be a better way, to not cause the sampling noise in the first place? 17.02.05 Join webguest90 [0] (~c0a5d512@labb.contactor.se) 17.02.22 # Hi, i'm writing a cubic spline interpolation for yuor MIDI codec :-) 17.02.34 # I'm also making a bunch of changes in general 17.02.36 *** Saving seen data "./dancer.seen" 17.02.52 # Did you say you got looping working? 17.04.32 Join mecraw [0] (~mecraw@69.2.235.2) 17.05.08 # ah, i think i've kinda got looping working on my version here, ... kinda ... 17.11.12 # hi 17.11.28 # I did a whole bunch of work on looping last night 17.11.53 # cool, did you update your tarball? 17.11.58 # forward, reverse, and pingpong 17.11.59 # oh no 17.12.03 # I will in a second 17.12.11 # here 17.12.14 # thx! 17.13.01 # there it's up 17.13.42 # I added a few fields for looping mode, and now it loops.. forward and pingpong definitely work.. reverse should work, but I haven't been able to really test it 17.13.57 # thanks! what was the link again? 17.14.06 # http://wam.umd.edu/~stevenm/irivermidi.tbz2 17.14.07 Quit ripnetuk ("Leaving") 17.14.19 # thank you for the interpolation stuff... how would I go about coding it? 17.14.25 # and, does the thing actually make sound on Cygwin ? 17.14.25 # I've added a cubic spline interpolation, I like the way it sounds but it still uses way too much cpu. 17.14.33 # stevenm yes, that's how i'm testing it 17.14.38 # ah.. sweet 17.14.41 Quit bobTHC (Read error: 110 (Connection timed out)) 17.14.50 # cubic spline? 17.14.58 # what about linear or something ? 17.15.54 # by the way, if I don't get assigned 3 hours of EE homework, tonight I'm going to either jump on the drum sets or the envelope stuff 17.16.18 Join amiconn_ [0] (~jens@pD9E7FAD8.dip.t-dialin.net) 17.16.25 # drums seem fairly straightforward.. envelope will reqiore a hex editor and some trial and error 17.16.42 # google 17.16.42 # stripwax: Wouldn't a simple linear interpolation be sufficient 17.16.42 # ? 17.16.43 Quit Aison (Read error: 104 (Connection reset by peer)) 17.16.45 Quit amiconn (Nick collision from services.) 17.16.45 Nick amiconn_ is now known as amiconn (~jens@pD9E7FAD8.dip.t-dialin.net) 17.17.18 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 17.17.21 # How would you apply linear interpolation to this? What would you divide/multiply ? 17.18.17 Join slowdowncadet [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 17.18.21 # grrrrrRRRRRRRR 17.18.37 # any particular reason I keep getting booted out of rockbox today? 17.20.11 # (i'd love to change my name back to stripwax) 17.20.31 # ah.. hello 17.20.36 Quit methangas (Read error: 104 (Connection reset by peer)) 17.20.40 # did i miss much?/ 17.20.58 # just me asking how to even do interpolation 17.21.10 # [17:16:16] stripwax: Wouldn't a simple linear interpolation be sufficient 17.21.10 # [17:16:16] ? 17.21.20 # amiconn - i tried that, it sounded crap 17.21.25 # and me contemplating the 'fun' of hexediting random envelope bytes and seeing how that effects the waveform 17.21.40 # stevenm - hehe, yeah, i was thinking of trying that too 17.22.03 # slowdowncadet, I have a program that displays all the stats.. only graphically, and in terms of percent and milliseconds 17.22.20 # tonight... if no EE homework, then I might jump on that. 17.23.22 # I know Timidity uses envelopes... and personally I think that makes some things sound like crap 17.23.23 # stevenm - so interpolation involves just taking some sample points near the sample you want to reproduce, and output some weighted combination of those samples. e.g. linear interpolation is just s0+((s1-s0)*frac) where frac runs from 0 to 1 (i.e. frac equals "cp & 0x7ff" in your midi codec) 17.23.53 # slowdowncadet, ah, I sort of see 17.24.08 # slowdowncadet, by the way, sorry if the code and stuff is a little cryptic 17.25.26 # cubic interpolation is something like (s1+frac*(s2-s0)+frac*frac*(2*s0-5*s1+4*s2-s3)+frac*frac*frac*(s3-3*(s2-s1)-s0) >>1 ... if you rearrange a bit more it's not too bad, just mults + adds 17.26.39 # slowdowncadet, hmm.. that seems CPU intensive.. could it be done in ASM maybe? 17.26.47 # stevenm of course 17.26.52 # er, would that work fast enough if it were in ASM 17.27.59 # by the way, the new code with the looping, there's some shifts by 9 in there 17.28.08 # why 9 17.28.15 # that's just because it's divided by 2 and then shifted by 10 the other way 17.29.16 # because the loop positions are in terms of bytes, and you have to divide by 2 of you want it in samples 17.29.33 # then multiply by 1024 to get the rest of it 17.29.49 # or to get it in the right form 17.29.56 Join bnewhouse [0] (~bnewhouse@cpe-24-94-54-216.stny.res.rr.com) 17.30.23 # hm, the new version coredumps on startup for me. i'll see if i can figure out what's up 17.31.25 # core dump??? that's not good..... 17.31.34 # quite 17.31.51 # ahh 17.31.53 # stupid stupid 17.31.59 # comment out the gusload in main 17.32.15 Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") 17.32.32 # 3rd line in main. I put that there to print out some patch info.. then deleted that file to make tarball smaller. it doesn't actually do anything for playback 17.32.34 # hey... so i finally got rockbox to compile... but i cant figure out how to get my compiled version on my iriver... ive installed using the daily build... but i cant figure out how to get a similar group of files when i compile... 17.32.49 # stevenm ok thx 17.33.08 # yeah that works 17.33.12 Quit stripwax (Read error: 110 (Connection timed out)) 17.33.14 # all right, cool 17.33.24 # hey now you get your name back 17.33.34 Nick slowdowncadet is now known as stripwax (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 17.33.39 # fab 17.33.42 # :) 17.35.26 # can anyone help? :( 17.35.43 # oh you changed shifts to 10 bits instead of 11 bits? 17.36.38 # stripwax, yea 17.36.43 # bnewhouse, did you run 'make zip'? 17.36.59 # stripwax, for some reason with 11 bit shifts, it would do some very strange things to high notes 17.37.07 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 17.37.20 # stevenm hm ok 17.37.26 # like, it would play them at a low frequency, and it sounds just plain BIZZARE 17.37.33 # stripwax, 10 bit solved that 17.37.45 # hm, no i didnt thanks, i'll try that... 17.39.40 Join Aison [0] (~hans@zux166-181.adsl.green.ch) 17.40.17 Join hile__ [0] (hile@hack.fi) 17.40.19 Quit hile (Read error: 104 (Connection reset by peer)) 17.44.16 # stripwax, I'm going to go eat.. then grab bike and go to class 17.44.26 # ok i'll be here later 17.44.27 # and see if I can manage to not get hit by a car this time :) 17.44.38 # later 17.44.56 Quit stevenm ("Leaving") 17.45.51 # ok stevenm, I'll try and find some way to send my updates across to you ... 17.47.27 Quit webguest90 ("CGI:IRC (Ping timeout)") 17.47.36 # actually... i forgot that linux hides the .rockbox folder... is that there normally after compile? 17.49.47 Nick hile__ is now known as hile (hile@hack.fi) 17.50.20 # k, ill take that as a yes... 17.50.48 # bnewhouse, it's a no ;) 17.51.15 # you have to do make zip and then copy the rockbox.zip to the iriver and unzip it there 17.51.36 # haha, k thanks a lot... 17.51.41 # that should create .rockbox and rockbox.iriver 17.51.48 # alrighty 18.01.37 Quit Patr3ck_ (Read error: 104 (Connection reset by peer)) 18.13.50 Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) 18.14.33 Join zeekoe [0] (HydraIRC@zeekoe.kabel.utwente.nl) 18.16.23 # now, where's a fireplace when you need one 18.19.53 Quit bnewhouse ("Leaving") 18.21.34 # stevenm - um, rather than use loopDir to do the delta addition for sample position, you could just reverse the sign of delta ;-) 18.24.23 Join chuck [0] (something@61-23-62-13.rev.home.ne.jp) 18.26.31 Join webguest46 [0] (~c0a5d512@labb.contactor.se) 18.45.51 # bnewhouse: you're on an iriver, yes? 18.51.50 Join Tang [0] (~chatzilla@ARennes-252-1-18-15.w83-195.abo.wanadoo.fr) 18.54.13 Quit webguest46 ("CGI:IRC") 18.54.14 # bnewhouse: in that case you need to flash your iriver first, before you can use your build. see the wiki for documentation on how to do it. 18.54.28 Join webguest26 [0] (~c0a5d512@labb.contactor.se) 18.58.24 # Hello 18.58.26 # :) 18.58.35 # Nice progresses :) 18.58.51 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) 18.58.55 # idneed 19.00.33 # :) 19.00.38 # Hi Preglow 19.00.43 # :) 19.01.17 # Congrtulate Linus from my part when you see him :) 19.02.39 *** Saving seen data "./dancer.seen" 19.03.48 # i'm decoding mp3 at 50% realtime now 19.16.02 Quit Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]") 19.22.36 Join Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de) 19.28.04 # preglow: neat! 19.28.08 # at what speed? 19.28.12 # (MHz) 19.29.16 # zeekoe: 96 mhyz 19.30.48 # do you have an idea at what speed it will run eventually? 19.31.05 # no, depends on how much we want to work on it 19.31.28 # thus far, i'm the only one working on optimizing it for speed 19.31.53 # but that'll probably change as codecs become the primary focus 19.33.52 # aren't there already optimized mp3 decoders? 19.34.26 # no, not for coldfire 19.34.37 # hm 19.34.41 # ask iRiver :-P 19.34.44 # hahaha 19.34.46 # "yes" 19.34.55 # but we're doing the work ourselves 19.36.45 # :) 19.39.37 Quit webguest26 ("CGI:IRC (EOF)") 19.41.15 Join Sucka [0] (~NNSCRIPT@host81-156-214-213.range81-156.btcentralplus.com) 19.43.54 Quit elinenbe (" HydraIRC rocks! -> http://www.hydrairc.com <-") 19.45.15 Join frank [0] (~frank@p54A13939.dip.t-dialin.net) 19.50.07 Join crwl` [0] (~crawlie@CV.gprs.saunalahti.fi) 19.53.02 # looks like gcc outputs pretty sub optimal indexing code 20.00.08 # looks like the patch file envelopes are just levels (i.e. volume at each point) and rates (i.e number of milliseconds between each point). been reading the GUS SDK source, pretty dull stuff 20.00.43 Quit sox ("Snak 4.13 IRC For Mac - http://www.snak.com") 20.00.57 # stripwax: well, yes, that's an envelope for you 20.01.27 # preglow - i know - stevenm couldn't find any docs on the format but it seems pretty obvious to me 20.05.41 Quit Renko (Remote closed the connection) 20.06.14 # obvious like what? the only thing i don't know is how to convert the info to actual levels and time constans 20.09.29 Quit Sucka ("a bird in the bush is worth two in your house") 20.09.35 Join Renko [0] (~Renko@host81-152-87-182.range81-152.btcentralplus.com) 20.13.21 Quit courtc ("Leaving") 20.33.25 Join courtc [0] (~court@adsl-158-15-19.asm.bellsouth.net) 20.34.29 Join webguest26 [0] (~c0a5d512@labb.contactor.se) 20.34.31 # gcc doesn't seem to think the coldfire can compare with a constant, or is there some other reason for it always loading the constant to another register for comparing? 20.34.58 # as far as i can see, it's actually slower 20.47.36 # preglow - by 'obvious' I meant that the GUS SDK contains code to do the mapping; ... 20.47.44 # then hooray! 20.48.38 Join thedude02 [0] ([U2FsdGVkX@pm476-01.dialip.mich.net) 20.48.52 # i'm just checking this against timidity sources right now to see if they're really the same - timidity sources don't seem to really know what's going on with the offset data (comments in timidity suggest it could be either lin or log vol but timidity assumes lin) 20.49.15 # preglow: I just came across the coldfire device errata. Did you read that? 20.49.28 Join webguest93 [0] (~3f505804@labb.contactor.se) 20.49.58 Quit webguest93 (Client Quit) 20.52.24 # amiconn: i thought i did 20.52.27 # i'll look it up 20.53.19 # Errata 4 is relevant for doing EMAC stuff 20.53.54 # yes, i see 20.54.59 # nothing i need to worry about right now 20.55.09 # i use one accumulator the whole time, more or less 20.55.42 # a24 not working is pretty nasty 21.02.43 *** Saving seen data "./dancer.seen" 21.06.09 Quit mecraw (Read error: 104 (Connection reset by peer)) 21.06.51 Join mecraw [0] (~mecraw@69.2.235.2) 21.12.48 Quit thedude02 (Read error: 113 (No route to host)) 21.12.50 Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) 21.20.06 Quit webguest26 ("CGI:IRC (Ping timeout)") 21.23.14 Join pillo [0] (~burellil@adsl-ull-249-132.47-151.net24.it) 21.41.58 # HCl: r u there? 21.43.04 # hi all 21.43.32 # any reasons why the menu_* functions aren't exported via the plugin api? 21.43.54 # Erm, because they were not needed yet? 21.44.03 Join xen` [0] (~xen@planoise-2-82-227-196-9.fbx.proxad.net) 21.44.11 # that's a good answer :) 21.44.17 # There is no point in exporting unused functions, it only makes the main binary larger 21.45.03 # i wanted to add a simple menu to the viewer plugin... and found it strange nobody had used them before... 21.45.10 # Functions are added to the api as new plugins need them 21.45.24 # so that's ok if i go on and add them? 21.45.36 # Yes. 21.46.00 # btw, did someone test my viewer patch on archos players/recorders? 21.46.28 # Btw, the case of the menu functions is really a bit strange. There are several games that define their own menu functions. 21.47.23 # that's why I asked--- sounded strange not to use the already available ones. 21.50.24 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so good") 21.53.57 Quit stripwax (Read error: 60 (Operation timed out)) 22.02.30 Join [FlaT]Heidel [0] (~h@p548084D6.dip.t-dialin.net) 22.06.05 Quit crwl` ("leaving") 22.08.10 Quit zeekoe (" I love my HydraIRC -> http://www.hydrairc.com <-") 22.09.11 # amiconn: i am now 22.09.17 Quit Renko ("Leaving") 22.09.36 # HCl: I'm working on a completely new Makefile approach for building rockboy 22.09.42 # okay 22.09.51 # i sent you a copy of my version merged with yours earlier today 22.10.04 # Yes, saw that. 22.10.06 # ok :) 22.10.36 # Still, I think the first version committed to cvs should be one without dynarec. 22.10.47 # you can easily disable it 22.10.48 # It's unfinished work 22.10.51 # by taking out the -DDYNAREC 22.10.55 # in the makefile 22.10.57 # HCl: you tried rockboy on the faster rockbox? 22.11.02 # not yet. 22.11.05 # i haven't had time 22.11.07 # had a car accident 22.11.14 # ouch 22.11.14 # and i finally heard that my sis has cancer today 22.11.27 # sorry to hear that 22.11.36 # yea. well. blah. 22.11.44 # not the best of days eh :< 22.11.44 # no point in worrying or feeling bad about it. 22.11.50 # well, of course not 22.11.51 # we'll do the what we can, and we can't do more. 22.11.56 # if you're able to 22.12.02 # not all people are 22.12.02 # heh 22.12.37 # i'm teaching myself to write whole functions in 68k asm 22.13.41 # is it possible to have a plugin be several files? 22.13.48 # look at rockboy 22.13.50 # i guess that won't work with the SOURCES scheme 22.14.09 # and ask amiconn since he's working on the makefile for it :x 22.14.10 # and i can't just include them, the other file is an asm file 22.14.13 # brb 22.15.12 # preglow: My new approach for building rockboy is in fact aimed at being a bit more flexible, i.e. allowing plugins with more than one file 22.16.04 Join webguest74 [0] (~0d0cfe52@labb.contactor.se) 22.16.11 # Those plugins would then not use the SOURCES scheme, but have their directory name (conditionally) added to a list variable in apps/plugins/Makefile 22.16.31 # amiconn: sounds great 22.16.57 # using the frame pointer in asm is ok, yes? 22.17.00 # For each of these dirs, the Makefile therein gets called (by the directory being a .PHONY target) 22.17.21 # well, i'm saving it anyway 22.17.50 # preglow: I don't know about the details of the iriver build, but the sh1 target code is compiled with -fomit-frame-pointer 22.18.24 Quit webguest74 (Client Quit) 22.19.02 # If you write an asm function, you just need to know which registers are considered scratch and which aren't. This depends on the abi (?) 22.19.43 # d0-d1 and a0-a1 22.19.55 # can be clobbered 22.20.10 # For SH1, r0-r7, macl and mach are considered scratch, r8-r15 and pr must be saved 22.26.18 # hahah 22.26.21 # i actually ran out of registers 22.26.36 # registers are like disk space, i swear 22.26.52 # i complain i've never get enough, and when i get more, i squander it 22.27.40 # i just tried to compile rockbox for the iriver for the first time. i've built the crosscompiler as shown in the wiki. me problem is, that the compiler crashes with an internal compiler error. is this a known issue? 22.27.59 # frank: you're the second person i've heard talk about this, on which file does it happen? 22.28.33 # calculator.c 22.28.43 # frank: you aren't the one who mentioned this the other day? 22.29.17 # nope, it tried to built the toolchain yesterday but the binutils-cvs wasn't in a clean state 22.29.50 # would you like a copy of the compiler output? 22.29.54 # but ok, you're the second person to get an internal error on calculator.c 22.29.57 # frank: sure, msg it to me 22.30.04 # so we don't spam the channel full 22.30.58 # LD /home/frank/rockbox/rockbox/build-normal/viewer.elf 22.30.58 # OBJCOPY /home/frank/rockbox/rockbox/build-normal/viewer.elf 22.30.58 # CC bounce.c 22.30.58 DBUG Enqueued KICK frank 22.30.58 # LD /home/frank/rockbox/rockbox/build-normal/bounce.elf 22.30.59 # OBJCOPY /home/frank/rockbox/rockbox/build-normal/bounce.elf 22.31.03 # CC calculator.c 22.31.05 # calculator.c: In function `typingProcess': 22.31.09 # calculator.c:1072: error: insn does not satisfy its constraints: 22.31.11 # (insn 356 138 140 24 (nil) (set (reg:QI 9 %a1) 22.31.13 # (mem/f:QI (const:SI (plus:SI (symbol_ref:SI ("n")) 22.31.15 # (const_int 3 [0x3]))) [0 n+3 S1 A8])) 37 {*m68k.md:1060} (nil) 22.31.17 # (nil)) 22.31.19 # calculator.c:1072: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8365 22.31.21 # Please submit a full bug report, 22.31.23 # with preprocessed source if appropriate. 22.31.25 # See for instructions. 22.31.27 # make[2]: *** [/home/frank/rockbox/rockbox/build-normal/calculator.o] Error 1 22.31.29 # rm /home/frank/rockbox/rockbox/build-normal/sort.elf /home/frank/rockbox/rockbox/build-normal/bounce.elf /home/frank/rockbox/rockbox/build-normal/stopwatch.elf /home/frank/rockbox/rockbox/build-normal/firmware_flash.elf /home/frank/rockbox/rockbox/build-normal/chessclock.elf /home/frank/rockbox/rockbox/build-normal/metronome.elf /home/frank/rockbox/rockbox/build-normal/rockbox_flash.elf /home/frank/rockbox/rockbox/build-normal/viewer.elf /home/f 22.31.36 # yes, and this would be the channel :PP 22.31.36 # rank/rockbox/rockbox/build-normal/cube.elf /home/frank/rockbox/rockbox/build-normal/mosaique.elf /home/frank/rockbox/rockbox/build-normal/helloworld.elf /home/frank/rockbox/rockbox/build-normal/vbrfix.elf /home/frank/rockbox/rockbox/build-normal/search.elf /home/frank/rockbox/rockbox/build-normal/favorites.elf /home/frank/rockbox/rockbox/build-normal/snow.elf /home/frank/rockbox/rockbox/build-normal/battery_test.elf 22.31.41 # make[2]: Leaving directory `/home/frank/rockbox/rockbox/apps/plugins' make[1]: *** [rocks] Error 2 22.31.43 # sorry 22.31.45 # my fault 22.31.47 # i missed these " 22.31.49 # both of them 22.31.59 # we'll survive 22.32.16 # this is gcc 3.4.3? 22.32.33 # did anyone query the gcc-bugzilla concerning this problem? 22.33.03 # frank: don't know, feel free to do so yourself, but you'll probably have to make a simple test case that reproduces the problem 22.33.08 # yes 22.33.21 # frank: linux? 22.33.27 # i will have a look 22.33.32 # yes 22.33.47 # well, that works fine for me 22.33.50 # are newer gcc versions useable? 22.33.57 # there are no newer 22.34.30 # i thought 3.5 was allready released 22.34.46 # you mean 4.0? there is no 3.5 22.34.51 # and no, it isnt 22.35.08 Join webguest86 [0] (~5002dcd0@labb.contactor.se) 22.35.32 # will be real fun to see how gcc4 performs 22.36.09 # you're right. i most probably confused it with 3.3.5 22.36.12 # gcc4 is looking really good already, from what i've seen 22.36.33 # yup 22.47.30 # hohoh 22.47.44 # libflac is about to get a super optimized lpc-reconstruction routine 22.50.07 # nice. 22.50.52 # preglow: /msg normalperson about his flac optimisations 22.51.18 # he did some stuff for mpd/libflac 22.53.03 Join [IDC]Dragon [0] (~Joerg@pD9512BB1.dip.t-dialin.net) 22.53.51 # mpd? 22.54.01 # hi Jörg :) 22.54.08 # ltnirc 22.54.10 # <[IDC]Dragon> Hi Jens 22.54.33 # There are 2 proposals for a flash icon now :) 22.54.41 # <[IDC]Dragon> aha? 22.55.22 # http://amiconn.dyndns.org/MMC.jpg and http://amiconn.dyndns.org/MMC_klein.jpg 22.55.37 # preglow: music player daemon 22.55.48 # ..the libflac stuff is the important bit :) 22.55.58 # <[IDC]Dragon> I like the bigger one better 22.56.21 # <[IDC]Dragon> looks funny on a "real" screen 22.57.28 # <[IDC]Dragon> we should mirror it, to better match the orientation 22.58.44 # Hmm. Then the lightning should also be mirrored, otherwise it won't fit cleanly 22.58.50 # <[IDC]Dragon> for external, this icon is intuitive, but also for internal? 22.59.22 # Well, it's mainly a "flash" symbol, just also symbolising MMC 22.59.48 # <[IDC]Dragon> ah, ok, didn't think of the flash 22.59.58 # <[IDC]Dragon> as in lightning 23.00.02 # yup 23.01.32 # <[IDC]Dragon> flash - ah - saviour of the universe 23.02.05 # spooky 23.02.10 # queen - flsh just cam eon my shuffled playlist :< 23.02.46 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk) 23.02.47 # that klein version really is klein 23.02.48 *** Saving seen data "./dancer.seen" 23.02.51 # ello 23.03.06 # guess i was kicked off sometime while eating dinner 23.04.46 # preglow: It's 7x8 pixel, the same size as most of the other status bar icons 23.06.44 # <[IDC]Dragon> is the OndioFM build working again? 23.07.54 # Doesn't seem so. Linus thinks this might be caused by the "region flash is full" error, but then I wonder why it worked until Feb-18 23.08.18 # The region flash is full for quite some more time.... 23.08.21 # <[IDC]Dragon> rombox has almovst ever been full 23.08.44 # amiconn: got a fast way for me to link two files to one plugin? 23.09.03 # preglow: I'm still working on that Makefile... 23.09.09 # <[IDC]Dragon> it worked only during the very first days, w/o tuner and keypad 23.09.13 # amiconn: ahh, i thought it wasn't due for some time yet 23.09.50 # [IDC]Dragon: Iirc the philips tuner support pushed it over the edge 23.10.04 Join webguest18 [0] (~50ca634f@labb.contactor.se) 23.10.15 # <[IDC]Dragon> something early like that 23.10.36 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 23.10.36 # * [IDC]Dragon is testing Jerry's new charging 23.11.01 # frank: I was looking at the irc log. I get the same error as you compiling the normal build 23.11.45 # using gcc 3.3.4 23.14.13 # webguest18: i admit i did the same. i'm just building a gcc 3.4.3... 23.15.09 # frank: ahh, ok. That may work better 23.16.23 # <[IDC]Dragon> amiconn, I'll put that MMC flash icon in? 23.16.38 # frank: I check the logs later on to see if you get it working 23.16.48 # ok 23.16.50 # bye 23.16.54 Part webguest18 23.17.29 # does anyone remember where the silent make setting is? i want full details of what's happening 23.17.49 Join Sucka [0] (~NNSCRIPT@host81-129-1-216.range81-129.btcentralplus.com) 23.20.38 # [IDC]Dragon: Of course, if you want to. There's the flipped icon: http://amiconn.dyndns.org/MMC_flipped.jpg 23.26.01 # how i hate makefiles 23.32.07 # so plugins are just plain bin images? 23.32.09 # <[IDC]Dragon> amiconn: your icon is 8 pixels tall :-( 23.32.27 # Yes. Why is that a problem? 23.32.37 # preglow: They are on the target 23.32.54 # amiconn: any plans to use a more flexible format? :P 23.32.55 # <[IDC]Dragon> all other status icons are 7 to leave a space 23.33.21 # Ooops... didn't notice 23.33.28 # it would simplify stuff like having certain code and data in iram without having to copy it manually 23.33.31 Join uncledrax [0] (~uncledrax@133-154-222-203.rev.techex.net.au) 23.33.33 # but i guess that isn't too big a bother 23.34.36 # amiconn: could you tell me how i can go about merging two object files to one plugin? objcopy only takes one input file argument 23.35.10 # You first need to link the two .o's to an .elf, like with the other plugins 23.35.22 # ahh, bah 23.35.25 # disregard me 23.35.45 Part pillo ("Kopete 0.9.2 : http://kopete.kde.org") 23.39.02 Quit webguest86 ("CGI:IRC") 23.42.32 # just for the records rockbox for the iriver builds with gcc 3.4.3. i was confused and used gcc 3.3.4 in my earlier attempts. 23.42.57 Join Dicko [0] (~chatzilla@spc1-bexl2-5-0-cust208.asfd.broadband.ntl.com) 23.42.58 # frank: ok, i still can't understand why it'd crash, though, but i guess it's irrelevant 23.43.55 # is the bootloader target expected to built out of the box? 23.45.26 # frank: well, yes 23.45.33 # frank: but i'd advice against building it yourself 23.46.01 # <[FlaT]Heidel> huh? 23.46.11 # ok, i was just test driving my enviroment 23.46.11 # <[FlaT]Heidel> sorry, wrong window 23.46.40 # frank: it will probably work just fine, but the code base changes a lot these days, and the bootloader relies heavily on the other code 23.48.14 # ok, thanks for the help. 23.49.04 # [IDC]Dragon: I changed the image to 11 pixel width, and leaving the bottom pixel row free 23.49.24 Quit frank ("Leaving") 23.51.53 Join LinusN [0] (~linus@labb.contactor.se) 23.52.46 Quit chuck (Read error: 110 (Connection timed out)) 23.53.44 # <[IDC]Dragon> amiconn, too late 23.57.25 Quit stripwax (Read error: 110 (Connection timed out)) 23.57.45 # <[IDC]Dragon> (already commited)