Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2005-03-01

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:35HClhrm..
00:06:55HClwhere can i find the amount of cycles a swap instruction takes
00:06:55HCl?
00:08:10amiconnSegfault, hrmpf
00:08:47Camilohci which architecture?
00:09:17preglowHCl: coldfire2um.pdf
00:09:37preglowHCl: it uses one
00:10:49HClokay.
00:10:51HClthanks
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:37HCl1 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:56HClagainst 1 at the moment
00:12:29preglowthat's going to be valuable
00:12:47amiconnI saw that you have macros for byte/short/long immediate load operations.
00:13:25amiconnThat'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:47HClpreglow: you think..?
00:13:48amiconnI have to come up with some clever workaround
00:13:54preglowHCl: yes
00:13:57 Quit cYmen ("leaving")
00:14:14HClmore than moving registers temporarily to the address regs and back?
00:14:17preglowespecially with the slow ram of the h1x0
00:14:25HClhuh? o.o;
00:14:28preglowahhh
00:14:35preglowif you've got free address regs, then nevermind
00:14:48HClthe swap swaps two words in the dataregister back and forth
00:14:51HClit doesn't do anything with memory
00:15:12*HCl is confused...
00:15:25HClwhat do you mean nevermind if i have free address regs...?
00:17:19HCli 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:00preglowi 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:21HClwell, its mostly to free them for calculation
00:20:35HCli stored 1 gameboy reg in 1 m68k reg
00:20:43HCli think that with the swap, i might be able to make it more efficient
00:25:22HClnow i can store half of them, 2 in 1 reg
00:25:36preglowyes, that's what i meant
00:26:08HClwhat?
00:26:09HClo.o
00:26:17HClso is it more efficient or not? x.x
00:27:34HCl :(
00:27:49*HCl prods preglow
00:27:53preglowdepends
00:28:09preglowif you need both parts of the register simultaneously, you'll have to do some magic
00:28:31HClshouldn't be much of a problem, just move them to one of the other data registers..
00:29:05HClmeh, i'll just continue with how i was doing it before, and add it to the list of possible optimizations
00:30:11amiconnLovely, rockboy segfaults in mem_read() ...
00:31:21amiconnHmm, maybe it's my fault after all...
00:33:02amiconnIt doesn't crash anymore :)
00:33:10HCldoes it work? :)
00:33:27amiconnWell, gfx doesn't work correctly yet
00:33:33HClkay...
00:34:00amiconnIt seems that only every 8th pixel line gets refreshed
00:34:13HClyes, thats true.
00:34:19HClrockboy does that as an optimization
00:34:24HClif you'd ask me, thats a flaw in the simulator
00:34:38HClcause rockbox refreshes 8 pixel lines either way due to the internal bit format
00:35:06amiconnYes... rockboy could however just use the 8-line refresh. It's in no way slower on the target.
00:35:14HCluh?
00:35:17HClhow so?
00:35:20HClits a function call
00:35:24HClhence its obsolete instructions
00:36:12amiconnYes. 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:41HCloh. right.
00:36:44HClyea.
00:37:15amiconnBtw, guess what my mistake was that caused it to crash?
00:37:22HCli suck at guessing.
00:37:24HCl :P
00:37:30amiconnI forgot to cater for the different endianess....
00:37:38HClhm... how so...?
00:37:47HClx86 is big endian. isn't it?
00:37:52amiconnnope
00:37:54HCloh.
00:37:55HClokay.
00:38:01HClwell, it has a nice define in the makefile..
00:38:10amiconnYes.
00:38:35amiconnI'll also check x11 sim and iriver sims, then try the 8-pixel rectangle
00:38:42HClyea.
00:38:51HClcan you like, build a diff against what you sent me last time?
00:38:53amiconnIf all this works, I need to work a bit on the makefile conditionals
00:38:59HClthen i'll apply it to my dynarec version
00:39:02HCland send it back to you
00:39:20amiconnNo, sorry. I don't have a copy of what I sent you last time
00:39:25HClno problem, i do.
00:39:40amiconnI updated my rockboy path to current cvs....
00:39:48HClpath..?
00:40:09amiconnYes, I have several cvs paths... 'working copies'
00:40:20HClso? o.o
00:40:55HClcd /tmp; tar xvfz youroldversion.tgz; diff -c (-r?) apps/plugins/rockboy <your version>
00:41:00HClo.o
00:41:37amiconnBtw, you're right that my Makefile doesn't clean properly
00:41:46amiconnI don't know why that is yet
00:42:23HClyea, i couldn't find it either
00:55:53HClbleh, 30 m68k instructions for a sub()
00:56:03preglowyes
00:56:11preglowthere are quite a few
00:56:21HCl? o.o.
00:56:51preglowmove beats them all, though
00:56:59preglowa zillion encodings
00:57:05amiconnOkay, lcd_update_rect() fix is working, X11 sim too.
00:57:10HClamiconn: nice
00:57:14preglowamiconn: does it display?
00:57:19amiconnyup
00:57:22preglowamiconn: is it playable? :P
00:57:28HClpreglow: oh, i meant that i need 30 m68k instruction to emulate a z80 sub instruction :x
00:57:35HClinstructions*
00:57:35 Quit Nibbler (Remote closed the connection)
00:57:45amiconnYeah... sort of. I tried recorder sim first (guess why)
00:57:52preglowHCl: what the hell? how?
00:58:05HClpreglow: calculating the gameboy flags is *EXPENSIVE*
00:58:10HCl :(
00:58:42amiconnThe flags shouldn't be *that* expensive, methinks
00:59:12preglowi think it sounds a bit over the top myself
00:59:42HClamiconn: the halfcarry calculation gnuboy provides is expensive..
00:59:42HClhere
00:59:43preglowHCl: can't you use the 68k flags?
00:59:43HCllet me paste
00:59:54preglowfor like zero and carry
00:59:59HClpreglow: thats a future optimization i hope to have, m68k does not have halfcarry
01:00
01:00:05HClit already uses zero and carry
01:00:16HClhere's the c code to calculate gameboy flags:
01:00:25amiconnThe sh1 only has carry (called t bit there)
01:00:28HClW(acc) = (un16)A - (un16)(n); \
01:00:29HClF = FN \
01:00:29HCl| (ZFLAG(LB(acc))) \
01:00:29HCl| (FH & ((A ^ (n) ^ LB(acc)) << 1)) \
01:00:29HCl| ((un8)(-(n8)HB(acc)) << 4); }
01:01:17HClamiconn: surely its able to calculate whether something is zero or not?
01:01:25 Quit methangas (" HydraIRC -> http://www.hydrairc.com <-")
01:01:48amiconnThat requires an extra test operation to set the t bit accordingly
01:01:56HClah.
01:01:57HClok
01:02:03HClanyways.
01:02:09HClthats the code for compare / subtract
01:02:13***Saving seen data "./dancer.seen"
01:02:28preglowamiconn: queer
01:02:35preglowamiconn: all platforms i've seen have zero flag
01:03:05HClif 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:15amiconnThe 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:43preglowamiconn: sure, but most risc platforms i've seen have zero flag as well
01:05:43preglowheh
01:05:50preglowi really can't see the savings in not having one
01:06:08preglowyou have a smaller instruction set, ok
01:06:20preglowbut going to those extremes are just annoying, imho
01:06:59preglowmy god, i'm tired of asm
01:07:03amiconnAs 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:21preglowahahah
01:07:34amiconnThe 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:12preglowamiconn: sounds like it's a pain to do asm in, though
01:09:28amiconnActually 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:28preglowphew, 1/3 done with opt, and it still makes nice sound
01:09:39preglowif this opt does not help, i will jump out the window
01:09:54preglowx86 isn't particularily intuitive
01:09:58preglowthe lack of registers is plain horrible
01:10:02 Quit lolo-laptop ("Client exiting")
01:10:19amiconnHCl: Mario is ~20 fps on my win32 (iRiver) simulator. Looks good.
01:10:26HClnice
01:10:53preglowamiconn: cpu specs?
01:11:06amiconnPentium M 1.5 GHz
01:11:08preglow~20 fps isn't particularily impressive
01:11:20preglowamiconn: could i have the simulator exe and try it here?
01:11:34amiconnNo... but then it uses several layers of bit shuffling
01:12:02amiconnSure... you'll need the exe and the plugins. I'll make up a zip, hang on
01:12:07preglowexcellent
01:12:25 Quit Sucka ("a bird in the bush is worth two in your house")
01:12:27preglowi'm on a 3400+ athlon64, should improve the fps some
01:14:47amiconnamiconn.dyndns.org/rockboy-win32.zip">http://amiconn.dyndns.org/rockboy-win32.zip
01:16:07amiconnIn addition to the several layers of bitshuffling, the win32 simulator also uses a bitmap drawing function that isn't designed for animation.
01:20:57preglowhmm
01:20:58preglowi get no files
01:21:12amiconn?
01:21:19preglowin the simulator browser
01:21:23preglowdo i need to pass it some flags?
01:21:27 Quit xen` (Read error: 113 (No route to host))
01:21:44amiconnYou need to set show files to 'supported' or 'all', like on the target
01:21:50preglow:-)
01:22:06amiconnWell, this *is* a simulator, isn't it?
01:22:14preglowyes, i just plain forgot about it
01:22:31preglowi just did that once on my player and them promptly forgot about it
01:23:37preglowhahah
01:23:41preglowit's perfectly playable
01:23:57HClnice.
01:24:14preglowbuttons are a bit glitchy, but works just fine
01:24:29HClhere ami, can you make a diff against that...?
01:25:05amiconnX11 sim (iriver) also working, a bit slower as expected
01:25:38 Join YouCeyE [0] (foobar@youceye.user)
01:25:45preglowi certainly hope the buttons wont handle like this on the player
01:25:52HClhow so?
01:25:59preglowthey stick a lot
01:26:07HClah.
01:26:21HCldynarec will probably just make that worse :P
01:26:27HClmaybe, anyways
01:26:50amiconnI think that this is caused by a combination of 2 things
01:27:17amiconn(1) rockboy uses the button queue, instead of reading the button status directly.
01:27:32amiconn(2) For the simulator, there is also the system's button queue
01:27:34preglowwhich it should stop doing immediatly :)
01:28:01HClmmm, also, i'd like a direct interface to the iriver lcd framebuffer... it'd save a lot, i think
01:28:05preglowoptimizing with this cpu speed is not very rewarding
01:28:10preglowthere's never a measurable difference
01:28:22amiconnHCl: Not much, I guess
01:28:35HClamiconn: every instruction is one
01:30:02amiconnYes of course. However, you cannot access the lcd buffer directly, this is to be done with lcd commands.
01:30:34HCli'm still pretty much using a setpixel() command, it'd save a lot if i could do that directly
01:30:42HClwell, not a lot
01:30:44HClbut at least some.
01:31:16amiconnThe 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:28amiconnYOu'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:18amiconnThis won't change with the introduction of 2 bit greyscale, btw. It will even get a bit uglier
01:33:34HClless.. it requires less bitshifts/ors
01:34:01amiconnImho the amount of shifts/ors per frame will be the same, or even a bit more
01:34:47amiconnIn 2-bit mode, one lcd byte "line" consists of 4 pixel rows instead of 8. Each byte represents 4 pixels.
01:35:02HClyes.
01:35:11HClthen i can just cache 4 scanlines
01:35:14HCland do like
01:35:39HClbyte&0x2<<0/2/4/6
01:35:41HCl |
01:35:45HCl0x3
01:35:48HClnot 2, my bad
01:36:03HClat the moment its byte&0x1<<0/1/2/3/4/5/6/7
01:36:07HCl|
01:36:19HClor no, even worse actually
01:36:32HClbyte&0x2>>1 / << 2 3 4 5 6 7
01:36:57amiconnYes. 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:11HClyea, i guess you're right with that.
01:37:12HClo.o
01:37:27amiconnThe current implementation doesn't do all those shifts, remember?
01:37:49HCloh. darn.
01:37:50HClyou're right.
01:37:52HClthat was my old version
01:43:45 Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net)
01:48:21amiconnHCl: amiconn.dyndns.org/rockboy-new.diff">http://amiconn.dyndns.org/rockboy-new.diff
01:48:33HClgreat, thanks
01:49:55preglowhalfway done...
01:50:09 Quit mecraw ()
01:50:14HClquite some rejects
01:50:44HClamiconn: can you send me your plugin.h / plugin.c / plugins/Makefile / plugins/SOURCES ?
01:50:51preglowhas anyone had a look at the iriver battery indicator, btw?
01:51:16HClnop.
01:51:31HClit should be added to the not working section of the iriverport rather than "inaccurate"
01:51:51preglowshouldn't be too hard to rectify
01:51:57HCli wouldn't know
01:52:45preglowi think you read the battery level as a plain byte
01:52:51preglowonly have to interpret it correctly
01:53:55amiconnHCl: amiconn.dyndns.org/rockboy-new-extra.zip">http://amiconn.dyndns.org/rockboy-new-extra.zip
01:54:14HClthanks
01:55:27HClok, thats everything, most of it patched cleanly
01:57:48amiconnThe 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:12amiconnI 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
02:00:37HClkay.
02:01:53HCllet 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:34coobthere 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:48amiconnAnyway, nite.
02:09:08 Part amiconn
02:10:02 Part pear
02:11:22preglowcoob: not much, there's docs/API
02:12:02coobagh i'm blind
02:12:19preglowwell, it isn't much
02:17:35HCltoo bad amiconn left.
02:17:37preglowi 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:53HCltime for a cvs commit
02:17:58 Quit Camilo ("Chatzilla 0.9.67 [Mozilla rv:1.8a6/20050111]")
02:18:06HCl(to my local repository) >.>
02:18:23preglownahah
02:18:36preglowi've been able to shave four seconds off the decode!
02:18:51HClnice :)
02:18:52preglowi hope to god it performs better on linus' player
02:18:59preglowor i'll be severaly depressed
02:19:02HClaww.
02:19:09*HCl hands preglow a stuffed animal :x
02:19:12preglowhahaha
02:19:20*preglow cuddles
02:19:25HCl :p
02:20:05preglowit needed to be done anywa
02:20:05preglowy
02:20:05preglowbut my god, it is boring
02:20:57HCltell me about it.
02:21:04HCldynarec isn't very fun at the moment either.
02:21:10coobwhich codec are you talking about?
02:21:37HClmostly 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:46HCland gnuboy is designed in such a way that thats impossible to do
02:22:45HClnot only is that gonna give me a terrible debugging time when it finally runs, its also less fun during development :/
02:23:02preglowcoob: mp3
02:23:21cooblibmad? these coldfire optimisations or generic C ones?
02:23:29preglowcoob: coldfire
02:23:34coobdarn :)
02:23:35preglowcoob: it's pure asm...
02:23:43preglowabout ten screens of it
02:23:49HClis that with sacrificed quality or without?
02:23:56HClick, assembly coding sucks :x
02:24:00coobwe need someone to optimise libmsd for arm
02:24:07coob*libmad
02:24:15preglowwhy? it already is pretty optimized for arm
02:24:24coobwell, once the dual cores are working sufficiently well enough
02:24:44preglowHCl: full quality
02:24:46coobit is?
02:24:54*coob not actually looked at it,
02:25:02preglowcoob: sure, you've got optimized multipliers and an imdct written in pure asm
02:25:40HClgood :)
02:25:53cooboptimised multipliers using lookup tables?
02:26:34preglowcoob: no, arm has pretty good multiplier support
02:26:40coobbleh
02:26:46preglowcoob: libmad needs 32x32 bit muls, and arm's got just that
02:26:52preglowcoob: in a way that integrates perfectly with libmad
02:26:54coobi mean division using multiplication tables
02:27:07preglowthere is very little division needed
02:27:18preglow\o/
02:27:21preglowjust two screens of code left
02:27:30coobstill, multiplicaiton - few cycles, division = 10x that
02:27:50preglowcoob: indeed, so good thing libmad almost never uses it
02:30:43preglowstandard operation that's used a lot is mac, and arm supports that directly
02:35:29 Quit rovragge ("Lost terminal")
02:37:23preglowi 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:56HClsounds good
02:38:49preglowi 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:10HClmrf...
02:48:17preglowhaha
02:48:27preglowthis exceeds all expectations
02:48:31preglownearly done, and it still sounds good
02:51:49HClmmm?
02:55:54preglowi've got like 500 lines of assembly, there not being a mistake some place in there is... unusual... :)
02:56:52HClheheheh.
02:57:01HClyea, i know what you mean :x
03:00
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:01preglowok, ok
03:29:12preglowthe mistakes i'm making now are unbelievable
03:29:14preglowbed for me
03:29:33 Quit preglow ("leaving")
04:00
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:00
05:02:20***Saving seen data "./dancer.seen"
05:12:12 Join rickst131 [0] (UPP@resnet-51-215.dorm.utexas.edu)
07:00
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:00
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:00
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:58ashridahlinusn
09:46:04LinusNhi
09:52:00pabsahoy
09:53:16pabsLinusN: less talking, more getting the sound on my iriver working :-D
09:53:50pabsif you do that, i'll contribute some code to rockbox
09:58:44ashridahdidn't someone have sound working already? :)
10:00
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:52stripwaxello
10:06:35 Join bobTHC [0] (~foo@l03v-35-190.d1.club-internet.fr)
10:08:01rickst131ello back
10:08:49bobTHChi all
10:08:55Strathhey amiconn
10:09:06amiconnhi
10:09:27Strathhows the iriver lcd driver coming?
10:10:04amiconnErm, why do you ask me? I have no iriver (yet)
10:10:19Strathcvs commit log
10:10:54ashridahhe's been cleanign up general bugs in the simulator.
10:10:56Strathor you just accepting the patches from another?
10:11:03LinusNi don't see any lcd commits from amiconn
10:11:17Strathlinus working on it then?
10:11:33Strath"Fri Feb 11 01:06:14 2005 UTC (2 weeks, 4 days ago) by amiconn "
10:12:41ashridahthat's still stuff for the simulator.
10:12:59stripwaxSrath- 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:06stripwax^irc logs that is
10:13:29Strathk thx
10:14:02stripwaxStrath - some screenshots of a mandlebrot generator and a jpeg viewer using 4-color greyscale on iriver
10:14:18ashridahthat's a misnomer.
10:14:23ashridahgrey isn't a colour ;)
10:14:25stripwaxhehe, you know what i mean
10:14:35 Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59)
10:14:36stripwax4-level greyscale
10:14:50Strathso the greyscale isn't tied directly to the iriver lcd driver and is in a lib? thats good :)
10:14:54ashridah2bit greyscale
10:15:22ashridahStrath: it makes sense to abstract it out, other players may have 2bit or more greyscale or even colour later.
10:16:04Strathya... i'm just starting work on the gmini 220 lcd driver, 4bpp lcd
10:16:05stripwaxStrath - 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:14stripwaxStrath - neat-o!
10:16:59Strathwhat about linear screen buffer vs. "line of columns" ordering?
10:17:47stripwaxStrath - should be possible to store the screen buffer in whatever way suits your hardware best
10:18:01LinusNstripwax: if rockbox used the grayscale lib on the archos, the ui would slow down to a crawl
10:18:26LinusNand possibly eat a little more battery
10:18:41stripwaxLinusN - really? that's a shame. I wasn't suggesting using the greyscale functionality on the ui, just the api
10:18:42Strathk, didn't know how much of that was throughout the code
10:19:30stripwaxLinusN i.e. set color, draw pixel, as opposed to draw pixel/clear pixel/invert pixel
10:19:48amiconnheh, that's my suggestion ;)
10:20:04stripwaxamiconn - I agree with it ;-)
10:21:55LinusNwe will need to add multicolor to the core lcd api
10:22:19Strathany tips on getting started on that driver? minimal api function needing to be implemented? getting make to use it, etc? :)
10:23:03amiconnLinusN: Did you have a look at the grayscale lib api?
10:23:14LinusNno
10:25:56jypStrath: duplicate and existing lcd-....c, change SOURCES to use it; then hack ;)
10:26:25Strath:P
10:28:51amiconnI think the lcd drivers should share most of the code.
10:29:07LinusNyes
10:29:08amiconnOnly the low level stuff needs to be lcd controller specific
10:29:26*jyp fully agrees
10:29:49LinusNthe tricky part would be that the frame buffer format could differ between the platforms
10:30:27amiconnYes, but e.g. the line drawing algorithm, the range checking etc is identical for all platforms
10:30:52amiconnI consider most graphics primitives rather high-level
10:32:02Strathassuming your drawing algorithms are wholely pixel based
10:32:14LinusNmost of them are
10:32:48stripwaxI'm assuming vertical line drawing is optimised for the byte layout on archos/iriver?
10:32:56LinusNnope
10:33:23amiconnWell, the routines that actually change larger pixel blocks (like fillrect() and bitmap drawing) profit from knowing the pixel format
10:33:25stripwaxoh. is text printing pixel based too?
10:33:37LinusNno
10:33:46stripwaxok that's good
10:33:50Straththat'd be slow ;)
10:34:24stripwaxquite
10:35:00amiconnThe problem for other display might be that our font format is currently tailored for the archos lcd data format
10:35:10stripwaxbitmaps too i'd imagine?
10:35:32Strathnot all archos devices use that format amiconn :)
10:36:48LinusNamiconn: the iriver lcd has the same format
10:36:49amiconnstripwax: yes.
10:36:49Strathwould the font bitmaps need to be regenerated then for linear mapped devices?
10:37:01LinusNyes
10:37:15amiconnLinusN: Only when using 1-bit mode. In 2-bit mode it is similar, but not identical
10:37:30LinusNtrue
10:37:33amiconnThe question is whether we should keep that format for b&w graphics
10:37:42amiconnI'd vote with yes.
10:38:34Strathi'd vote for linear mapped files converted at compile/link time, but then i'm biased :)
10:38:48amiconnDrawing 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:42Strathwe could just have the bitmaps chew up huge gobs of memmory...
10:40:01amiconnStrath: Now exactly that is not possible
10:40:01stripwaxamiconn - 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:27Stratha joke, sheesh :P
10:40:35amiconnstripwax: Then he would have to change the drawing function call as well
10:41:06LinusNthe fonts should be converted to the native format for each platform
10:41:13stripwaxamiconn - 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:24LinusNthe same goes for the other bitmaps
10:41:34amiconnMy suggestion is, the drawing functions should support 1-bit, 8-bit (and leaving open the option for 24-bit)
10:42:02amiconn1-bit could use plain old archos format, 8-bit and 24-bit linear mapped
10:42:24LinusNthat would slow down the lcd drawing on the iriver
10:43:55amiconnI 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:37amiconnI.e. old archos has 1-bit, iriver h1xx 2-bit, gmini 2xx 4-bit, iriver h3xx colour...
10:44:39LinusNstill, the hardware is limited when it comes to cpu power and memory bandwidth
10:44:40Strathwell, 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:55LinusNStrath: exactly
10:45:31amiconnThe problem is that plugin authors would then have to supply a bitmap for each architecture in case they want to use bitmapss
10:46:03LinusNor we develop a tool for that
10:46:07Strathor limit plugin targets
10:46:20jypThe bitmaps really need to be compile-time generated per device anyway imho
10:46:26amiconnStrath: That's not exactly the idea with rockbox
10:47:17Strathi know... be easier than getting all plugin authors to generate bitmaps for each platform...
10:47:41amiconnLinusN: 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:04Strath(especialy for existing plugins)
10:48:17LinusNor they are converted in runtime, when loading
10:48:37amiconnurgs....
10:49:09LinusN:-)
10:49:11Strathbig 'ol' can of worms :)
10:49:13jyp... or both
10:49:52amiconnRuntime conversion would imho add too much code, keeping in mind the limited memory
10:50:23amiconnThe custom bitmap approach will then make the fonts platform specific
10:50:52ashridahunless you devise a platform neutral format and convert on compile...
10:51:00ashridahor make zip or whatever
10:51:29LinusNashridah: exactly
10:51:40amiconnI'm talking about the target format for distribution.
10:52:26amiconnI.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:35LinusNyup
10:52:45Strathattach a format tag to assets? if there isn't one in the native format for that device it uses a convertion function?
10:52:54LinusNnah
10:52:55amiconnIn addition, having >1 bit fonts leads to additional problems
10:53:50amiconnWith 1-bit, you have the notion of foreground & background, so you can draw e.g. foreground only, leaving the background transparent
10:54:22amiconnA similar approach is possible with the standard greyscale format (1 byte/pixel linear), using it as an alpha value
10:54:41amiconnThis will get *very* hard to do in the target format....
10:55:08LinusNin the fonts, value 0 would be the background
10:55:34amiconnYes... still, how do you handle the other 3 values?
10:55:51amiconnWith 1 byte/pixel, doing alpha, i.e. anti-aliasing, is easy.
10:55:53LinusNyou want more transparent colors?
10:56:02Strathblending.... uhg :)
10:56:25amiconnWith the target format, this will turn out to be way slower
10:56:44LinusNwhy would we do antialiasing in runtime?
10:57:26amiconnBecause you simply cannot do this at compile time
10:57:36LinusNno, but when you design the font
10:57:56amiconnThis won't work either
10:57:59stripwaxLinusN - that would only work if you *assume* the background is white, no?
10:58:10LinusNstripwax: of coyrse
10:58:10Zagorantialiasing != transparence
10:58:23amiconnLinusN: ..and white background _only_
10:58:31LinusNamiconn: yes, and why is that a problem?
10:58:32amiconnImho this is not what we want
10:58:48stripwaxLinusN - it would fail if the background is grey, for example..
10:58:54jypis transparency used in rockbox as it stands ?
10:59:00amiconnE.g. it will look veeery ugly with the selection set to 'bar (inverse)'...
10:59:23Strathjyp, i think only draw the '1's
10:59:59jypStrath: I know, but it is really taken advantage of at the application level
11:00
11:00:00jyp?
11:00:07Zagorjyp: there can be no transparency in a 1-bit display
11:00:37jypZagor: "drawing black only" ...
11:00:43stripwaxZagor - sure there can
11:01:04Zagorok right, if that's your definition. then yes, we support and use it.
11:01:05stripwaxZagor - no trans*lucency* but transparency is just a case of masking..
11:01:05amiconnZagor: There can.... and even is implemented. Just that you only have 0% or 100% transparency
11:01:44Zagorstripwax: aha, i'm mixing it up
11:02:30***Saving seen data "./dancer.seen"
11:04:09jypAlright, so we have 3 possible features to support: transparency; translucency; reverse-video
11:10:09Strathin various formats
11:12:13LinusNimho, antialiased fonts is very unnecessary
11:12:42Strathonly 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:50amiconnRe-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:36LinusNi can live with that
11:14:44LinusNas long as font rendering is fast enough
11:15:28amiconnThe current 11 MHz iriver is a good testbed...
11:15:33HClsounds ok with me.
11:15:36Strathamiconn, i can agree with that
11:15:47HCllower 2 bits of a byte?
11:16:30 Join preglow [0] (thomj@s183a.studby.ntnu.no)
11:16:45HClhere ami, your version, with my dynarec added
11:17:32amiconnHCl: No, always using the full range i.e. 0== black, 255 == white
11:17:43Strathbut 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:50HCldarn..
11:18:09Strathamiconn, correct
11:18:30LinusNamiconn: for the file format, right?
11:18:41LinusNnot runtime, i hope
11:18:53amiconnStrath: 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:13amiconnLinusN: I'm talking about runtime format as well as file format
11:19:31preglowwasn't someone working on a more precise timer?
11:19:45LinusNso the lcd_bitmap() function would have to translate the gray values in runtime?
11:20:04Strathyes, but i think we might actually be talking about seperate issues then
11:21:21dwihnoHCl: how is dynarec going?
11:22:02 Join Patr3ck [0] (~patr3ck@pD9ECFC0E.dip.t-dialin.net)
11:22:03amiconnLinusN: Please have a look at the grayscale lib api. It supports 1-bit bitmaps as well as 8-bit bitmaps
11:22:10HCldwihno: slowly, not too efficient cause of z80 flags. building some opcodes from gcc, its a pain, really
11:22:24amiconnFor 1-bit, there is selectable foreground colour, background colour, and draw mode
11:22:43Strathok... 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:34Strath(maybe lower even...)
11:23:38dwihnoHCl: I wish you the best of luck! :)
11:23:47amiconnThere are 4 draw modes. Draw foreground pixels only, background pixels only, draw all pixels, and invert foreground pixels
11:24:08LinusNamiconn: 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:43Strathdraw all is the only one that would really gain from having native font format
11:25:29amiconnStrath: Exactly, and all other operations would be slower...
11:25:54Strathwell, xor with read value maybe...
11:26:02amiconn...probably way slower
11:27:04Strathxor, and, or, actually, it could speed up, i was thinking per pixel calculations
11:27:27preglowHCl: a shift isn't very expensive...
11:27:47preglowHCl: one cycle on coldfire, unless i remember incorrectly
11:27:48amiconnLinusN: 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:51HClpreglow: every instruction is one too many
11:29:04preglowHCl: 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:10HClwell, i'm only planning it for where i actually need speed - rockboy
11:30:38LinusNamiconn: how would the grayscale value translation be done?
11:30:52Strathare there various fonts already in use or just the single system font?
11:31:13preglowStrath: fonts are user selectable
11:31:59Strathso, preglow, there are several to choose from..
11:32:05preglowStrath: a ton
11:32:09Strathk ;)
11:32:20preglowthey all differ inn appearance and size
11:32:40HClhm, actually, nm, if 0 = black, i don't need any bitshifts *isn't awake yet*
11:33:19amiconnLinusN: 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:28preglowLinusN: 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:42LinusNpreglow: sure
11:33:51HClhm, nm :x
11:33:59*HCl goes back to sleep before he says more stupid stuff >.>
11:34:13preglowLinusN: did your previous 95% realtime result have any code placed in sram, btw?
11:34:32LinusNpreglow: lots of code in sram
11:35:31LinusNamiconn: and those transparency operations, shifts and inversions would be added to the lcd_bitmap() function?
11:35:56LinusNand it wouldn't be much slower?
11:36:24LinusNi can imagine at least double execution time
11:38:08Strath'read, transform, write' vs 'write'
11:39:17amiconnLinusN: My point is that it is not different from using the native format *except* for when you draw solid
11:39:59amiconnI..e with 8-bit linear format you need transform-write for solid, while with native format you only need write
11:40:26Strath(yes, i think i am arguing both sides of the issue, sorry ;)
11:41:13amiconnHowever, for other drawing modes you need readback-transform, transform, combine, transform,write with native format
11:41:34amiconnWith 8-bit linear you only need readback, combine, transform, write in this case
11:42:25amiconnIn fact, it would be even better if the framebuffer is also in 8-bit linear format for grayscale
11:42:50amiconnThis way, only lcd_update() and lcd_update_rect() need to know about the internal format
11:42:54Strath220 and xs200 use a 4bit linear format
11:43:16jypno
11:43:28jypxs200 is unknown
11:43:29jyp;?
11:43:30jyp;)
11:43:37Strathso an operation using a native format could handle two pixels at once
11:43:37LinusNamiconn: then the frame buffer would eat a lot more precious IRAM, and lcd_update() will suffer a lot
11:44:14Strathjyp, it's 2bit/pixel stored in 2pixel per byte format
11:44:34Strathat least in the frame buffer or the archos firmware
11:44:41Straths/or/of/
11:45:02jypYup, but framebuffer is linear for the 120/SP too
11:45:08jypdoesn't tell you much
11:45:15amiconnLinusN: 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:19Strathjyp :P
11:45:19amiconn*at once
11:45:38LinusNamiconn: true
11:46:24amiconnI 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:35amiconnActually, 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:36Strathami, your talking about transfering the data to the lcd controler, not the frame buffer?
11:48:10amiconnStrath: Exactly. My suggestion is to have the framebuffer in 8-bit linear format, and doing the transformation during transfer to the controller
11:48:13Strathi2c writes and what not
11:48:33Strathwhat if your lcd controler uses dma? :)
11:49:00amiconnThen you would need an additional dma buffer
11:49:45amiconnLinusN: 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:36LinusNstill, lcd_update() would be 5-6 times slower
11:51:43LinusNeven more
11:52:37amiconnThe transfer itself is going to take much longer than the conversion anyway, or am I wrong?
11:53:18LinusNthe transfer is parallel
11:53:50amiconnOkay.
11:54:00LinusNa simple move.w
11:54:26 Join Aison [0] (~hans@zux166-181.adsl.green.ch)
11:54:42amiconnI agree that this would make lcd_update() slower, but all other graphics operations should be faster.
11:55:23amiconnDo you have a clue what the overall performance change would be? I guess it will go faster overall...
11:55:28Strathtoo many variables ;)
11:56:32Strathbit depth, storage format, controler transfer method, pixel effects, aaaah!
11:56:32amiconn...and you get the possibility for font anti-aliasing, transparency etc almost for free.
12:00
12:01:55 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk)
12:03:19stripwaxello
12:03:49stripwaxSo, power cuts across a bunch of internet routers, i just got kicked right out of cyberspace
12:03:55Strathami, 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:16Straths/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:40amiconnStrath: I agree that anti-aliasing and translucency isn't top priority, however, we certainly will see numerous requests for that.
12:44:24amiconnPlus, I doubt that transparency and inversion is faster & easier in the native format.
12:47:04Strathbut would it ever be worth implementing anti-aliasing and translucency on such a low powered device? even if requested...
12:48:31preglowhahah
12:48:47preglowi 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:16Lynx_i'd love a transparent mp3 player ;)
12:53:23Strathlol
12:54:16amiconnpreglow: Transparency (as 1-bit) is already implemented. Strath etc. use the term 'transparency' for 1-bit, and 'translucency' for multi-bit transparency
13:00
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:10jypGotcha!
13:07:25[Unseen]heh?
13:07:41jypYour nick ... Nevermind :P
13:08:00[Unseen]lol
13:09:45Strathsilly jyp, nick are for ...
13:10:35 Nick [Unseen] is now known as SeenByJyp (~e@pc2996.gsf.de)
13:12:19Strathok, 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:00
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:44LinusNpreglow: i have now committed a fix for the codec dependencies
14:36:44LinusNbut i'm not yet sure how to make the plugins depend on the codec libs
14:37:03preglowgreat nonetheless
14:37:22LinusNyou only want the *2wav plugins rebuilt, not all of them
14:37:40preglowyes, but it beats having to make clean every time
14:37:43 Quit SeenByJyp ()
14:38:02LinusNi also moved the main stack to iram
14:39:50preglowi think i'll make a separate asm file of this imdct_l business, it's quite ugly
14:40:23preglowis it easy to place certain variables in iram?
14:44:48LinusNint myarray[1024] __attribute__ ((section(".idata")));
14:45:03preglowthe 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:46LinusNthere's of course the penalty of moving it there
14:48:14preglowwhy does it have to be moved there?
14:48:31preglowiram is in the same address space as sdram?
14:49:48LinusNi 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:51preglowahh
14:51:01preglowwell, no, not exactly
14:51:10 Join Renko [0] (~Renko@host81-152-87-182.range81-152.btcentralplus.com)
14:51:18preglowit has to be handled by the huffman decoder first
14:51:33preglowand that might require less memory bandwidth that way
14:51:39elinenbepreglow, LinusN: what's the current speed of the mp3 codec on the target?
14:51:59preglowthere are several layers before the mdct sees it
14:52:28LinusNelinenbe: we have reached 95%, but that's in 140MHz and with non-CVS hacks
14:52:38LinusNpreglow: ok
14:52:44preglowit should be realtime with my latest opt
14:52:55preglowat least, i'll be severely disappointed if it's not
14:53:37LinusNi have lowered the max freq to 96MHz in my soon-to-be committed cpu frequency fix
14:54:01LinusNso you'll just have to optimize some more :-)
14:54:46LinusNcan you send me a patch?
14:55:42preglowwell, yes, but it's a bloody mess and has to be kept from the public :)
14:56:14LinusNhehe
14:56:24preglowit would be easier if i could just send you the entire file, it's going to be a messy patch
14:56:29LinusNsure
14:56:38 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk)
14:56:52ripnetukis it stable at 96MHz?
14:57:05preglowhttp://glow.m0f0.net/rockbox/layer3.c
14:57:42preglowyou'll still need the emac.h
14:58:20LinusNok
14:59:56LinusNnon-optimized mpa2wav is 40% with only my latest stack fix
14:59:59LinusNin 96MHz
15:00
15:00:06preglownot too shabby
15:01:29LinusNripnetuk: i don't know yet if it is stable
15:02:03ripnetukbut no nasty ata issues like we had at full speed yet?
15:02:33***Saving seen data "./dancer.seen"
15:02:35LinusNnot yet, but i'll have to run it a while to heat up the hard drive
15:02:47ripnetukyeah... intermittent problems are the worst
15:04:44LinusNpreglow: quite a disappointment...46%
15:04:51preglow.......
15:05:04preglowLinusN: is that with synth.c opt as well?
15:05:12LinusNno
15:05:15preglowarhghh
15:05:34preglowmaybe i should try optimizing the other imdct
15:06:00LinusNforgot the synth.c, hang on...
15:06:14preglowsynth.c helped more, if i don't remember incorrectly
15:06:19LinusNyes
15:06:37LinusNbut moving code and tables to iram helps a *lot*
15:07:01LinusNi moved plenty of constants and tables to iram last time
15:07:08LinusNbut not now
15:07:25preglowyes
15:07:56preglowwe'll have to find the hotspots and put that in iram
15:08:00preglowi don't think we have a choice in that matter
15:08:15LinusNno we don't
15:10:04 Quit edx (Read error: 110 (Connection timed out))
15:10:10LinusN54% with synth.c
15:11:06preglowi read somewhere that the huffman decoder is pretty demanding as well
15:11:19preglowbut that looks like its just a huge lookup table in libmad
15:11:42LinusNi moved those to iram last time, made a noticeable difference
15:13:40stripwax.. sorry for the dumb question, but what is "iram"?
15:14:03preglowram that's internal to the coldfire
15:14:07preglowsingle cycle acces
15:14:20preglow_very_ fast compared to the sdram, but there's only 96kb of it
15:14:28stripwaxi thought that would be called sram... why are you calling it iram?
15:14:40LinusN(I)nternal RAM
15:14:44preglowdunno, because everyone else is calling it iram? :P
15:14:49preglowsram/iram, i don't care
15:15:49stripwaxwe 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:06preglowbut 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:21preglowi'll clean my opts up a bit
15:16:28preglowso people can use them
15:16:43preglowstripwax: it'll have to be used dynamically
15:16:49preglowstripwax: as i said, there's only 96kb of it
15:17:14stripwaxpreglow thanks, didn't know how big the tables would be
15:17:45 Quit HCl ("Lost terminal")
15:18:06amiconnLinusN: You could run test_fs for a while to see if it is stable at 96 MHz
15:18:13LinusNyes
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:48amiconnJust choose the number of passes so that the file size is just below 2 GB, and let it run....
15:19:12HClwhats up?
15:21:06LinusNnot much
15:21:32 Quit jyp (Read error: 110 (Connection timed out))
15:21:41LinusNthe usual optimization discussions
15:22:06preglowHCl: my opt turned out to be of little signifigance...
15:22:31 Join webguest90 [0] (~c0a5d512@labb.contactor.se)
15:22:33LinusNpreglow: are the dct constants in iram?
15:22:37preglowquite luckily the weather is excellent, so i'm hard to depress
15:22:41preglowLinusN: they're code
15:22:59preglowLinusN: i do move.l #const, %%reg _all_ the time
15:22:59amiconnLinusN: I would even suggest to increase the clock gradually, and check when it starts to produce errors
15:23:15HClpreglow: :( how so?
15:23:23LinusNamiconn: that's an idea
15:23:40preglowHCl: it gained 6%, from 40% at 96mhz
15:23:51HClwell, at least its something
15:23:54preglowHCl: which is a bit less than i hoped for
15:23:56preglowbut yes
15:23:58preglowi had to try
15:24:04amiconnpreglow: from 40% to 46% realtime is a 15% speed increase
15:24:09HClclearly we'll get it to work some how, we can resort to reverse engineering the original firmware if all fails
15:24:20preglowHCl: it won't come to that
15:24:28preglowthere are a lot of clever people around
15:24:28HClhm
15:24:31HClif you say so
15:25:10LinusNsynth_full() should be in iram
15:25:14preglowLinusN: indeed
15:25:41preglowi don't know how often synth_half will be used
15:25:50preglowi think that's used for half sampling rate synthesis
15:25:53amiconnpreglow: 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:55preglowwhich no one in their right mind does
15:26:36preglowamiconn: that's an idct, not an imdct :P
15:27:23preglowamiconn: sh1 has mac?
15:27:32LinusNyes
15:28:08amiconnpreglow: It has mac. 16x16bit -> 42 bit
15:29:08preglowamiconn: cool
15:29:29preglowamiconn: i'd love to have a look, but haven't got time right now
15:29:55elinenbequick question... does the target produce any sound right now? for anyone?
15:30:38HClthere's a wav play thing on the wiki.
15:36:03preglowLinusN: 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:29LinusNyes
15:36:48LinusNbut i haven't enabled the page mode yet
15:36:56preglowwhat does that do?
15:37:20LinusNfaster access time for sequential fetches
15:37:38preglowahh
15:37:39preglowgoodie
15:37:40LinusNright now you have only burst access, very rare
15:37:46preglowyes, movem only, i guess
15:39:12 Join webguest00 [0] (~81b1111b@labb.contactor.se)
15:40:35LinusNpreglow: cpu boost committed
15:40:43preglowLinusN: excellent, will test it out right now
15:40:55LinusNit is not enabled by default
15:41:02LinusNyou do like this:
15:41:12LinusNenter debug->view i/o ports
15:41:28webguest00hi, I was reading the logs. Do you know that there is a demo mp3-decoder for coldfire MCF5249L
15:41:38LinusNthen UP for max frequency (96MHz), DOWN for normal (which is 48MHz)
15:41:45LinusNwebguest00: yes
15:41:53webguest00ok, hehe, guessed that
15:41:57LinusNor SELECT for 11MHz
15:42:05preglowLinusN: great, a lot easier to time my own code now
15:42:12LinusNyes
15:42:26preglowi'd have to perform miracles to see a difference at 11mhz
15:43:08LinusNpretty impressive assembler blobs in layer3.c :-)
15:43:09 Join lolo-laptop [0] (~lostlogic@68.251.84.226)
15:43:13preglowLinusN: i agree
15:43:33preglowi completed it at 04:00, haha
15:43:35preglowmy brain was fried
15:43:57preglowi'll have to finish it fast, before i forget what's what
15:44:13LinusNpreglow: the idea behind the cpu boost stuff is this:
15:44:37LinusNwhen you need extra power, call cpu_boost(), it will set the cpu frequency to maximum
15:44:48preglowLinusN: hah! extremely cool
15:44:54LinusNwhen you're done, call cpu_boost(false)
15:45:01HClnice
15:45:03preglowand it'll clock it at 140mhz ?
15:45:07LinusN96
15:45:24LinusNseveral threads may call cpu_boost(true)
15:45:29preglowahh, yes, but using 140mhz might be viable there?
15:45:37 Part webguest00
15:45:42preglowwill have to test to determine that, i guess
15:45:44LinusNbut the frequency will not be lowered until all threads have called cpu_boost(false)
15:46:01LinusNboosting the cpu takes up to 10ms
15:46:05preglowoh
15:46:08ripnetukis there much advantage in running in slow mode? less power usage? less overheating?
15:46:12preglowpll probably needs to readjust
15:46:14ripnetukwhen I say slow, i mean normal
15:46:15LinusNless power usage
15:46:27LinusNpreglow: yes, it's the max locking time
15:46:46ripnetukbut wont 99% of usage be urm, playing mp3's, which seems to require the full power
15:46:52LinusNso you shouldn't call cpu_boost() often
15:47:12preglowwtf? freq selector is locked at 11mhz
15:47:33LinusNthe what?
15:47:43preglowio ports stuff wouldn't let me choose 96mhz
15:48:13LinusNup for 96, down for 48, select for 11
15:48:18preglowit's a veritable greased ligtning
15:48:19preglowhahahaha
15:48:24preglowdecoded my test file like lightning
15:48:28preglow50% realtime
15:48:44LinusNfeels nice, doesn't it? :-)
15:48:48preglowit indeed does
15:49:06LinusNhave to run, cu around
15:49:10preglowyep
15:49:13 Part LinusN
15:49:20preglowi'll go enjoy the sun and my h120, later
16:00
16:04:28CoCoLUSHe 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:30CoCoLUSnow THATS creative
16:05:06stripwaxwot?
16:05:30CoCoLUShttp://www.engadget.com/entry/1234000907033676/
16:05:34CoCoLUSfreaky, somewhat
16:07:18coobold news
16:07:25coobthat happened in like december
16:07:38cooband they used the screenshot of all 0's where it didn't work :/
16:07:46coobjournalists = slow and lousy!
16:07:50 Quit webguest90 ("CGI:IRC (Ping timeout)")
16:09:06CoCoLUSwell it was news for me :)
16:09:35stripwaxi preferred my method :-)
16:09:55coobhe wanted to do it without cracking open his ipod...
16:10:13CoCoLUShaving sex with an iriver employee? :)
16:10:23CoCoLUSsocial engineering, i think its called :P
16:10:32stripwaxcoob - I didn't have to open my iriver, or have sec with any employees
16:10:59ripnetukjects/rockbox/cvs/rockbox/build/sim/rockbox_flash.o
16:11:05ripnetuksorry...
16:11:06stripwax?
16:11:12ripnetukaccedential paste
16:23:57ripnetukhi, 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:13ripnetuki 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:48ripnetukfor 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:05stevenmHello 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:41stevenmRight 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:00
17:02:05 Join webguest90 [0] (~c0a5d512@labb.contactor.se)
17:02:22stripwaxHi, i'm writing a cubic spline interpolation for yuor MIDI codec :-)
17:02:34stripwaxI'm also making a bunch of changes in general
17:02:36***Saving seen data "./dancer.seen"
17:02:52stripwaxDid you say you got looping working?
17:04:32 Join mecraw [0] (~mecraw@69.2.235.2)
17:05:08stripwaxah, i think i've kinda got looping working on my version here, ... kinda ...
17:11:12stevenmhi
17:11:28stevenmI did a whole bunch of work on looping last night
17:11:53stripwaxcool, did you update your tarball?
17:11:58stevenmforward, reverse, and pingpong
17:11:59stevenmoh no
17:12:03stevenmI will in a second
17:12:11stevenmhere
17:12:14stripwaxthx!
17:13:01stevenmthere it's up
17:13:42stevenmI 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:57stripwaxthanks! what was the link again?
17:14:06stevenmstevenm/irivermidi.tbz2">http://wam.umd.edu/~stevenm/irivermidi.tbz2
17:14:07 Quit ripnetuk ("Leaving")
17:14:19stevenmthank you for the interpolation stuff... how would I go about coding it?
17:14:25stevenmand, does the thing actually make sound on Cygwin ?
17:14:25stripwaxI've added a cubic spline interpolation, I like the way it sounds but it still uses way too much cpu.
17:14:33stripwaxstevenm yes, that's how i'm testing it
17:14:38stevenmah.. sweet
17:14:41 Quit bobTHC (Read error: 110 (Connection timed out))
17:14:50stevenmcubic spline?
17:14:58stevenmwhat about linear or something ?
17:15:54stevenmby 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:25stevenmdrums seem fairly straightforward.. envelope will reqiore a hex editor and some trial and error
17:16:42stripwaxgoogle
17:16:42amiconnstripwax: Wouldn't a simple linear interpolation be sufficient
17:16:42amiconn?
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:21stevenmHow 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:21slowdowncadetgrrrrrRRRRRRRR
17:18:37slowdowncadetany particular reason I keep getting booted out of rockbox today?
17:20:11slowdowncadet(i'd love to change my name back to stripwax)
17:20:31stevenmah.. hello
17:20:36 Quit methangas (Read error: 104 (Connection reset by peer))
17:20:40slowdowncadetdid i miss much?/
17:20:58stevenmjust me asking how to even do interpolation
17:21:10amiconn[17:16:16] <amiconn> stripwax: Wouldn't a simple linear interpolation be sufficient
17:21:10amiconn[17:16:16] <amiconn> ?
17:21:20slowdowncadetamiconn - i tried that, it sounded crap
17:21:25stevenmand me contemplating the 'fun' of hexediting random envelope bytes and seeing how that effects the waveform
17:21:40slowdowncadetstevenm - hehe, yeah, i was thinking of trying that too
17:22:03stevenmslowdowncadet, I have a program that displays all the stats.. only graphically, and in terms of percent and milliseconds
17:22:20stevenmtonight... if no EE homework, then I might jump on that.
17:23:22stevenmI know Timidity uses envelopes... and personally I think that makes some things sound like crap
17:23:23slowdowncadetstevenm - 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:53stevenmslowdowncadet, ah, I sort of see
17:24:08stevenmslowdowncadet, by the way, sorry if the code and stuff is a little cryptic
17:25:26slowdowncadetcubic 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:39stevenmslowdowncadet, hmm.. that seems CPU intensive.. could it be done in ASM maybe?
17:26:47slowdowncadetstevenm of course
17:26:52stevenmer, would that work fast enough if it were in ASM
17:27:59stevenmby the way, the new code with the looping, there's some shifts by 9 in there
17:28:08slowdowncadetwhy 9
17:28:15stevenmthat's just because it's divided by 2 and then shifted by 10 the other way
17:29:16stevenmbecause the loop positions are in terms of bytes, and you have to divide by 2 of you want it in samples
17:29:33stevenmthen multiply by 1024 to get the rest of it
17:29:49stevenmor 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:23slowdowncadethm, the new version coredumps on startup for me. i'll see if i can figure out what's up
17:31:25stevenmcore dump??? that's not good.....
17:31:34slowdowncadetquite
17:31:51stevenmahh
17:31:53stevenmstupid stupid
17:31:59stevenmcomment out the gusload in main
17:32:15 Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )")
17:32:32stevenm3rd 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:34bnewhousehey... 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:49slowdowncadetstevenm ok thx
17:33:08slowdowncadetyeah that works
17:33:12 Quit stripwax (Read error: 110 (Connection timed out))
17:33:14stevenmall right, cool
17:33:24stevenmhey 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:39stripwaxfab
17:33:42stevenm:)
17:35:26bnewhousecan anyone help? :(
17:35:43stripwaxoh you changed shifts to 10 bits instead of 11 bits?
17:36:38stevenmstripwax, yea
17:36:43Renkobnewhouse, did you run 'make zip'?
17:36:59stevenmstripwax, 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:20stripwaxstevenm hm ok
17:37:26stevenmlike, it would play them at a low frequency, and it sounds just plain BIZZARE
17:37:33stevenmstripwax, 10 bit solved that
17:37:45bnewhousehm, 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:16stevenmstripwax, I'm going to go eat.. then grab bike and go to class
17:44:26stripwaxok i'll be here later
17:44:27stevenmand see if I can manage to not get hit by a car this time :)
17:44:38stevenmlater
17:44:56 Quit stevenm ("Leaving")
17:45:51stripwaxok 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:36bnewhouseactually... 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:20bnewhousek, ill take that as a yes...
17:50:48Renkobnewhouse, it's a no ;)
17:51:15Renkoyou have to do make zip and then copy the rockbox.zip to the iriver and unzip it there
17:51:36bnewhousehaha, k thanks a lot...
17:51:41Renkothat should create .rockbox and rockbox.iriver
17:51:48bnewhousealrighty
18:00
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:23preglownow, where's a fireplace when you need one
18:19:53 Quit bnewhouse ("Leaving")
18:21:34stripwaxstevenm - 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:51soxbnewhouse: 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:14soxbnewhouse: 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:24TangHello
18:58:26Tang:)
18:58:35TangNice progresses :)
18:58:51 Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU)
18:58:55preglowidneed
19:00
19:00:33Tang:)
19:00:38TangHi Preglow
19:00:43Tang:)
19:01:17TangCongrtulate Linus from my part when you see him :)
19:02:39***Saving seen data "./dancer.seen"
19:03:48preglowi'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:04zeekoepreglow: neat!
19:28:08zeekoeat what speed?
19:28:12zeekoe(MHz)
19:29:16preglowzeekoe: 96 mhyz
19:30:48zeekoedo you have an idea at what speed it will run eventually?
19:31:05preglowno, depends on how much we want to work on it
19:31:28preglowthus far, i'm the only one working on optimizing it for speed
19:31:53preglowbut that'll probably change as codecs become the primary focus
19:33:52zeekoearen't there already optimized mp3 decoders?
19:34:26preglowno, not for coldfire
19:34:37zeekoehm
19:34:41zeekoeask iRiver :-P
19:34:44preglowhahaha
19:34:46preglow"yes"
19:34:55preglowbut we're doing the work ourselves
19:36:45zeekoe:)
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:02preglowlooks like gcc outputs pretty sub optimal indexing code
20:00
20:00:08stripwaxlooks 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:57preglowstripwax: well, yes, that's an envelope for you
20:01:27stripwaxpreglow - 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:14preglowobvious 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:31preglowgcc 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:58preglowas far as i can see, it's actually slower
20:47:36stripwaxpreglow - by 'obvious' I meant that the GUS SDK contains code to do the mapping; ...
20:47:44preglowthen hooray!
20:48:38 Join thedude02 [0] ([U2FsdGVkX@pm476-01.dialip.mich.net)
20:48:52stripwaxi'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:15amiconnpreglow: 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:24preglowamiconn: i thought i did
20:52:27preglowi'll look it up
20:53:19amiconnErrata 4 is relevant for doing EMAC stuff
20:53:54preglowyes, i see
20:54:59preglownothing i need to worry about right now
20:55:09preglowi use one accumulator the whole time, more or less
20:55:42preglowa24 not working is pretty nasty
21:00
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:58amiconnHCl: r u there?
21:43:04pillohi all
21:43:32pilloany reasons why the menu_* functions aren't exported via the plugin api?
21:43:54amiconnErm, because they were not needed yet?
21:44:03 Join xen` [0] (~xen@planoise-2-82-227-196-9.fbx.proxad.net)
21:44:11pillothat's a good answer :)
21:44:17amiconnThere is no point in exporting unused functions, it only makes the main binary larger
21:45:03pilloi wanted to add a simple menu to the viewer plugin... and found it strange nobody had used them before...
21:45:10amiconnFunctions are added to the api as new plugins need them
21:45:24pilloso that's ok if i go on and add them?
21:45:36amiconnYes.
21:46:00pillobtw, did someone test my viewer patch on archos players/recorders?
21:46:28amiconnBtw, the case of the menu functions is really a bit strange. There are several games that define their own menu functions.
21:47:23pillothat'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:00
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:11HClamiconn: i am now
22:09:17 Quit Renko ("Leaving")
22:09:36amiconnHCl: I'm working on a completely new Makefile approach for building rockboy
22:09:42HClokay
22:09:51HCli sent you a copy of my version merged with yours earlier today
22:10:04amiconnYes, saw that.
22:10:06HClok :)
22:10:36amiconnStill, I think the first version committed to cvs should be one without dynarec.
22:10:47HClyou can easily disable it
22:10:48amiconnIt's unfinished work
22:10:51HClby taking out the -DDYNAREC
22:10:55HClin the makefile
22:10:57preglowHCl: you tried rockboy on the faster rockbox?
22:11:02HClnot yet.
22:11:05HCli haven't had time
22:11:07HClhad a car accident
22:11:14preglowouch
22:11:14HCland i finally heard that my sis has cancer today
22:11:27preglowsorry to hear that
22:11:36HClyea. well. blah.
22:11:44coobnot the best of days eh :<
22:11:44HClno point in worrying or feeling bad about it.
22:11:50preglowwell, of course not
22:11:51HClwe'll do the what we can, and we can't do more.
22:11:56preglowif you're able to
22:12:02preglownot all people are
22:12:02preglowheh
22:12:37preglowi'm teaching myself to write whole functions in 68k asm
22:13:41preglowis it possible to have a plugin be several files?
22:13:48HCllook at rockboy
22:13:50preglowi guess that won't work with the SOURCES scheme
22:14:09HCland ask amiconn since he's working on the makefile for it :x
22:14:10preglowand i can't just include them, the other file is an asm file
22:14:13HClbrb
22:15:12amiconnpreglow: 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:11amiconnThose 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:31preglowamiconn: sounds great
22:16:57preglowusing the frame pointer in asm is ok, yes?
22:17:00amiconnFor each of these dirs, the Makefile therein gets called (by the directory being a .PHONY target)
22:17:21preglowwell, i'm saving it anyway
22:17:50amiconnpreglow: 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:02amiconnIf 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:43preglowd0-d1 and a0-a1
22:19:55preglowcan be clobbered
22:20:10amiconnFor SH1, r0-r7, macl and mach are considered scratch, r8-r15 and pr must be saved
22:26:18preglowhahah
22:26:21preglowi actually ran out of registers
22:26:36preglowregisters are like disk space, i swear
22:26:52preglowi complain i've never get enough, and when i get more, i squander it
22:27:40franki 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:59preglowfrank: you're the second person i've heard talk about this, on which file does it happen?
22:28:33frankcalculator.c
22:28:43preglowfrank: you aren't the one who mentioned this the other day?
22:29:17franknope, it tried to built the toolchain yesterday but the binutils-cvs wasn't in a clean state
22:29:50frankwould you like a copy of the compiler output?
22:29:54preglowbut ok, you're the second person to get an internal error on calculator.c
22:29:57preglowfrank: sure, msg it to me
22:30:04preglowso we don't spam the channel full
22:30:58frankLD /home/frank/rockbox/rockbox/build-normal/viewer.elf
22:30:58frankOBJCOPY /home/frank/rockbox/rockbox/build-normal/viewer.elf
22:30:58frankCC bounce.c
22:30:58DBUGEnqueued KICK frank
22:30:58frankLD /home/frank/rockbox/rockbox/build-normal/bounce.elf
22:30:59frankOBJCOPY /home/frank/rockbox/rockbox/build-normal/bounce.elf
22:31:03frankCC calculator.c
22:31:05frankcalculator.c: In function `typingProcess':
22:31:09frankcalculator.c:1072: error: insn does not satisfy its constraints:
22:31:11frank(insn 356 138 140 24 (nil) (set (reg:QI 9 %a1)
22:31:13frank (mem/f:QI (const:SI (plus:SI (symbol_ref:SI ("n"))
22:31:15frank (const_int 3 [0x3]))) [0 n+3 S1 A8])) 37 {*m68k.md:1060} (nil)
22:31:17frank (nil))
22:31:19frankcalculator.c:1072: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8365
22:31:21frankPlease submit a full bug report,
22:31:23frankwith preprocessed source if appropriate.
22:31:25frankSee <URL:http://gcc.gnu.org/bugs.html> for instructions.
22:31:27frankmake[2]: *** [/home/frank/rockbox/rockbox/build-normal/calculator.o] Error 1
22:31:29frankrm /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:36preglowyes, and this would be the channel :PP
22:31:36frankrank/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:41frankmake[2]: Leaving directory `/home/frank/rockbox/rockbox/apps/plugins' make[1]: *** [rocks] Error 2
22:31:43franksorry
22:31:45frankmy fault
22:31:47franki missed these "
22:31:49frankboth of them
22:31:59preglowwe'll survive
22:32:16preglowthis is gcc 3.4.3?
22:32:33frankdid anyone query the gcc-bugzilla concerning this problem?
22:33:03preglowfrank: 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:08frankyes
22:33:21preglowfrank: linux?
22:33:27franki will have a look
22:33:32frankyes
22:33:47preglowwell, that works fine for me
22:33:50frankare newer gcc versions useable?
22:33:57preglowthere are no newer
22:34:30franki thought 3.5 was allready released
22:34:46kergothyou mean 4.0? there is no 3.5
22:34:51kergothand no, it isnt
22:35:08 Join webguest86 [0] (~5002dcd0@labb.contactor.se)
22:35:32preglowwill be real fun to see how gcc4 performs
22:36:09frankyou're right. i most probably confused it with 3.3.5
22:36:12kergothgcc4 is looking really good already, from what i've seen
22:36:33preglowyup
22:47:30preglowhohoh
22:47:44preglowlibflac is about to get a super optimized lpc-reconstruction routine
22:50:07HClnice.
22:50:52coobpreglow: /msg normalperson about his flac optimisations
22:51:18coobhe did some stuff for mpd/libflac
22:53:03 Join [IDC]Dragon [0] (~Joerg@pD9512BB1.dip.t-dialin.net)
22:53:51preglowmpd?
22:54:01amiconnhi Jörg :)
22:54:08amiconnltnirc
22:54:10[IDC]DragonHi Jens
22:54:33amiconnThere are 2 proposals for a flash icon now :)
22:54:41[IDC]Dragonaha?
22:55:22amiconnamiconn.dyndns.org/MMC.jpg">http://amiconn.dyndns.org/MMC.jpg and http://amiconn.dyndns.org/MMC_klein.jpg
22:55:37coobpreglow: music player daemon
22:55:48coob..the libflac stuff is the important bit :)
22:55:58[IDC]DragonI like the bigger one better
22:56:21[IDC]Dragonlooks funny on a "real" screen
22:57:28[IDC]Dragonwe should mirror it, to better match the orientation
22:58:44amiconnHmm. Then the lightning should also be mirrored, otherwise it won't fit cleanly
22:58:50[IDC]Dragonfor external, this icon is intuitive, but also for internal?
22:59:22amiconnWell, it's mainly a "flash" symbol, just also symbolising MMC
22:59:48[IDC]Dragonah, ok, didn't think of the flash
22:59:58[IDC]Dragonas in lightning
23:00
23:00:02amiconnyup
23:01:32[IDC]Dragonflash - ah - saviour of the universe
23:02:05coobspooky
23:02:10coobqueen - flsh just cam eon my shuffled playlist :<
23:02:46 Join stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk)
23:02:47preglowthat klein version really is klein
23:02:48***Saving seen data "./dancer.seen"
23:02:51stripwaxello
23:03:06stripwaxguess i was kicked off sometime while eating dinner
23:04:46amiconnpreglow: It's 7x8 pixel, the same size as most of the other status bar icons
23:06:44[IDC]Dragonis the OndioFM build working again?
23:07:54amiconnDoesn'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:18amiconnThe region flash is full for quite some more time....
23:08:21[IDC]Dragonrombox has almovst ever been full
23:08:44preglowamiconn: got a fast way for me to link two files to one plugin?
23:09:03amiconnpreglow: I'm still working on that Makefile...
23:09:09[IDC]Dragonit worked only during the very first days, w/o tuner and keypad
23:09:13preglowamiconn: ahh, i thought it wasn't due for some time yet
23:09:50amiconn[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]Dragonsomething early like that
23:10:36CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
23:10:36*[IDC]Dragon is testing Jerry's new charging
23:11:01webguest18frank: I was looking at the irc log. I get the same error as you compiling the normal build
23:11:45webguest18using gcc 3.3.4
23:14:13frankwebguest18: i admit i did the same. i'm just building a gcc 3.4.3...
23:15:09webguest18frank: ahh, ok. That may work better
23:16:23[IDC]Dragonamiconn, I'll put that MMC flash icon in?
23:16:38webguest18frank: I check the logs later on to see if you get it working
23:16:48frankok
23:16:50webguest18bye
23:16:54 Part webguest18
23:17:29preglowdoes 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:38amiconn[IDC]Dragon: Of course, if you want to. There's the flipped icon: amiconn.dyndns.org/MMC_flipped.jpg">http://amiconn.dyndns.org/MMC_flipped.jpg
23:26:01preglowhow i hate makefiles
23:32:07preglowso plugins are just plain bin images?
23:32:09[IDC]Dragonamiconn: your icon is 8 pixels tall :-(
23:32:27amiconnYes. Why is that a problem?
23:32:37amiconnpreglow: They are on the target
23:32:54preglowamiconn: any plans to use a more flexible format? :P
23:32:55[IDC]Dragonall other status icons are 7 to leave a space
23:33:21amiconnOoops... didn't notice
23:33:28preglowit 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:33preglowbut i guess that isn't too big a bother
23:34:36preglowamiconn: 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:10amiconnYou first need to link the two .o's to an .elf, like with the other plugins
23:35:22preglowahh, bah
23:35:25preglowdisregard me
23:35:45 Part pillo ("Kopete 0.9.2 : http://kopete.kde.org")
23:39:02 Quit webguest86 ("CGI:IRC")
23:42:32frankjust 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:58preglowfrank: ok, i still can't understand why it'd crash, though, but i guess it's irrelevant
23:43:55frankis the bootloader target expected to built out of the box?
23:45:26preglowfrank: well, yes
23:45:33preglowfrank: but i'd advice against building it yourself
23:46:01[FlaT]Heidelhuh?
23:46:11frankok, i was just test driving my enviroment
23:46:11[FlaT]Heidelsorry, wrong window
23:46:40preglowfrank: 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:14frankok, thanks for the help.
23:49:04amiconn[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]Dragonamiconn, too late
23:57:25 Quit stripwax (Read error: 110 (Connection timed out))
23:57:45[IDC]Dragon(already commited)

Previous day | Next day