| 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 | HCl | hrm.. |
| 00:06:55 | HCl | where can i find the amount of cycles a swap instruction takes |
| 00:06:55 | HCl | ? |
| 00:08:10 | amiconn | Segfault, hrmpf |
| 00:08:47 | Camilo | hci which architecture? |
| 00:09:17 | preglow | HCl: coldfire2um.pdf |
| 00:09:37 | preglow | HCl: it uses one |
| 00:10:49 | HCl | okay. |
| 00:10:51 | HCl | 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 | HCl | 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 | HCl | against 1 at the moment |
| 00:12:29 | preglow | that's going to be valuable |
| 00:12:47 | amiconn | I saw that you have macros for byte/short/long immediate load operations. |
| 00:13:25 | amiconn | 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 | HCl | preglow: you think..? |
| 00:13:48 | amiconn | I have to come up with some clever workaround |
| 00:13:54 | preglow | HCl: yes |
| 00:13:57 | | Quit cYmen ("leaving") |
| 00:14:14 | HCl | more than moving registers temporarily to the address regs and back? |
| 00:14:17 | preglow | especially with the slow ram of the h1x0 |
| 00:14:25 | HCl | huh? o.o; |
| 00:14:28 | preglow | ahhh |
| 00:14:35 | preglow | if you've got free address regs, then nevermind |
| 00:14:48 | HCl | the swap swaps two words in the dataregister back and forth |
| 00:14:51 | HCl | it doesn't do anything with memory |
| 00:15:12 | * | HCl is confused... |
| 00:15:25 | HCl | what do you mean nevermind if i have free address regs...? |
| 00:17:19 | HCl | 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 | preglow | 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 | HCl | well, its mostly to free them for calculation |
| 00:20:35 | HCl | i stored 1 gameboy reg in 1 m68k reg |
| 00:20:43 | HCl | i think that with the swap, i might be able to make it more efficient |
| 00:25:22 | HCl | now i can store half of them, 2 in 1 reg |
| 00:25:36 | preglow | yes, that's what i meant |
| 00:26:08 | HCl | what? |
| 00:26:09 | HCl | o.o |
| 00:26:17 | HCl | so is it more efficient or not? x.x |
| 00:27:34 | HCl | :( |
| 00:27:49 | * | HCl prods preglow |
| 00:27:53 | preglow | depends |
| 00:28:09 | preglow | if you need both parts of the register simultaneously, you'll have to do some magic |
| 00:28:31 | HCl | shouldn't be much of a problem, just move them to one of the other data registers.. |
| 00:29:05 | HCl | meh, i'll just continue with how i was doing it before, and add it to the list of possible optimizations |
| 00:30:11 | amiconn | Lovely, rockboy segfaults in mem_read() ... |
| 00:31:21 | amiconn | Hmm, maybe it's my fault after all... |
| 00:33:02 | amiconn | It doesn't crash anymore :) |
| 00:33:10 | HCl | does it work? :) |
| 00:33:27 | amiconn | Well, gfx doesn't work correctly yet |
| 00:33:33 | HCl | kay... |
| 00:34:00 | amiconn | It seems that only every 8th pixel line gets refreshed |
| 00:34:13 | HCl | yes, thats true. |
| 00:34:19 | HCl | rockboy does that as an optimization |
| 00:34:24 | HCl | if you'd ask me, thats a flaw in the simulator |
| 00:34:38 | HCl | cause rockbox refreshes 8 pixel lines either way due to the internal bit format |
| 00:35:06 | amiconn | Yes... rockboy could however just use the 8-line refresh. It's in no way slower on the target. |
| 00:35:14 | HCl | uh? |
| 00:35:17 | HCl | how so? |
| 00:35:20 | HCl | its a function call |
| 00:35:24 | HCl | hence its obsolete instructions |
| 00:36:12 | amiconn | 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 | HCl | oh. right. |
| 00:36:44 | HCl | yea. |
| 00:37:15 | amiconn | Btw, guess what my mistake was that caused it to crash? |
| 00:37:22 | HCl | i suck at guessing. |
| 00:37:24 | HCl | :P |
| 00:37:30 | amiconn | I forgot to cater for the different endianess.... |
| 00:37:38 | HCl | hm... how so...? |
| 00:37:47 | HCl | x86 is big endian. isn't it? |
| 00:37:52 | amiconn | nope |
| 00:37:54 | HCl | oh. |
| 00:37:55 | HCl | okay. |
| 00:38:01 | HCl | well, it has a nice define in the makefile.. |
| 00:38:10 | amiconn | Yes. |
| 00:38:35 | amiconn | I'll also check x11 sim and iriver sims, then try the 8-pixel rectangle |
| 00:38:42 | HCl | yea. |
| 00:38:51 | HCl | can you like, build a diff against what you sent me last time? |
| 00:38:53 | amiconn | If all this works, I need to work a bit on the makefile conditionals |
| 00:38:59 | HCl | then i'll apply it to my dynarec version |
| 00:39:02 | HCl | and send it back to you |
| 00:39:20 | amiconn | No, sorry. I don't have a copy of what I sent you last time |
| 00:39:25 | HCl | no problem, i do. |
| 00:39:40 | amiconn | I updated my rockboy path to current cvs.... |
| 00:39:48 | HCl | path..? |
| 00:40:09 | amiconn | Yes, I have several cvs paths... 'working copies' |
| 00:40:20 | HCl | so? o.o |
| 00:40:55 | HCl | cd /tmp; tar xvfz youroldversion.tgz; diff -c (-r?) apps/plugins/rockboy <your version> |
| 00:41:00 | HCl | o.o |
| 00:41:37 | amiconn | Btw, you're right that my Makefile doesn't clean properly |
| 00:41:46 | amiconn | I don't know why that is yet |
| 00:42:23 | HCl | yea, i couldn't find it either |
| 00:55:53 | HCl | bleh, 30 m68k instructions for a sub() |
| 00:56:03 | preglow | yes |
| 00:56:11 | preglow | there are quite a few |
| 00:56:21 | HCl | ? o.o. |
| 00:56:51 | preglow | move beats them all, though |
| 00:56:59 | preglow | a zillion encodings |
| 00:57:05 | amiconn | Okay, lcd_update_rect() fix is working, X11 sim too. |
| 00:57:10 | HCl | amiconn: nice |
| 00:57:14 | preglow | amiconn: does it display? |
| 00:57:19 | amiconn | yup |
| 00:57:22 | preglow | amiconn: is it playable? :P |
| 00:57:28 | HCl | preglow: oh, i meant that i need 30 m68k instruction to emulate a z80 sub instruction :x |
| 00:57:35 | HCl | instructions* |
| 00:57:35 | | Quit Nibbler (Remote closed the connection) |
| 00:57:45 | amiconn | Yeah... sort of. I tried recorder sim first (guess why) |
| 00:57:52 | preglow | HCl: what the hell? how? |
| 00:58:05 | HCl | preglow: calculating the gameboy flags is *EXPENSIVE* |
| 00:58:10 | HCl | :( |
| 00:58:42 | amiconn | The flags shouldn't be *that* expensive, methinks |
| 00:59:12 | preglow | i think it sounds a bit over the top myself |
| 00:59:42 | HCl | amiconn: the halfcarry calculation gnuboy provides is expensive.. |
| 00:59:42 | HCl | here |
| 00:59:43 | preglow | HCl: can't you use the 68k flags? |
| 00:59:43 | HCl | let me paste |
| 00:59:54 | preglow | for like zero and carry |
| 00:59:59 | HCl | preglow: thats a future optimization i hope to have, m68k does not have halfcarry |
| 01:00 |
| 01:00:05 | HCl | it already uses zero and carry |
| 01:00:16 | HCl | here's the c code to calculate gameboy flags: |
| 01:00:25 | amiconn | The sh1 only has carry (called t bit there) |
| 01:00:28 | HCl | W(acc) = (un16)A - (un16)(n); \ |
| 01:00:29 | HCl | F = FN \ |
| 01:00:29 | HCl | | (ZFLAG(LB(acc))) \ |
| 01:00:29 | HCl | | (FH & ((A ^ (n) ^ LB(acc)) << 1)) \ |
| 01:00:29 | HCl | | ((un8)(-(n8)HB(acc)) << 4); } |
| 01:01:17 | HCl | 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 | amiconn | That requires an extra test operation to set the t bit accordingly |
| 01:01:56 | HCl | ah. |
| 01:01:57 | HCl | ok |
| 01:02:03 | HCl | anyways. |
| 01:02:09 | HCl | thats the code for compare / subtract |
| 01:02:13 | *** | Saving seen data "./dancer.seen" |
| 01:02:28 | preglow | amiconn: queer |
| 01:02:35 | preglow | amiconn: all platforms i've seen have zero flag |
| 01:03:05 | HCl | 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 | amiconn | 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 | preglow | amiconn: sure, but most risc platforms i've seen have zero flag as well |
| 01:05:43 | preglow | heh |
| 01:05:50 | preglow | i really can't see the savings in not having one |
| 01:06:08 | preglow | you have a smaller instruction set, ok |
| 01:06:20 | preglow | but going to those extremes are just annoying, imho |
| 01:06:59 | preglow | my god, i'm tired of asm |
| 01:07:03 | amiconn | 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 | preglow | ahahah |
| 01:07:34 | amiconn | 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 | preglow | amiconn: sounds like it's a pain to do asm in, though |
| 01:09:28 | amiconn | 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 | preglow | phew, 1/3 done with opt, and it still makes nice sound |
| 01:09:39 | preglow | if this opt does not help, i will jump out the window |
| 01:09:54 | preglow | x86 isn't particularily intuitive |
| 01:09:58 | preglow | the lack of registers is plain horrible |
| 01:10:02 | | Quit lolo-laptop ("Client exiting") |
| 01:10:19 | amiconn | HCl: Mario is ~20 fps on my win32 (iRiver) simulator. Looks good. |
| 01:10:26 | HCl | nice |
| 01:10:53 | preglow | amiconn: cpu specs? |
| 01:11:06 | amiconn | Pentium M 1.5 GHz |
| 01:11:08 | preglow | ~20 fps isn't particularily impressive |
| 01:11:20 | preglow | amiconn: could i have the simulator exe and try it here? |
| 01:11:34 | amiconn | No... but then it uses several layers of bit shuffling |
| 01:12:02 | amiconn | Sure... you'll need the exe and the plugins. I'll make up a zip, hang on |
| 01:12:07 | preglow | excellent |
| 01:12:25 | | Quit Sucka ("a bird in the bush is worth two in your house") |
| 01:12:27 | preglow | i'm on a 3400+ athlon64, should improve the fps some |
| 01:14:47 | amiconn | amiconn.dyndns.org/rockboy-win32.zip">http://amiconn.dyndns.org/rockboy-win32.zip |
| 01:16:07 | amiconn | 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 | preglow | hmm |
| 01:20:58 | preglow | i get no files |
| 01:21:12 | amiconn | ? |
| 01:21:19 | preglow | in the simulator browser |
| 01:21:23 | preglow | do i need to pass it some flags? |
| 01:21:27 | | Quit xen` (Read error: 113 (No route to host)) |
| 01:21:44 | amiconn | You need to set show files to 'supported' or 'all', like on the target |
| 01:21:50 | preglow | :-) |
| 01:22:06 | amiconn | Well, this *is* a simulator, isn't it? |
| 01:22:14 | preglow | yes, i just plain forgot about it |
| 01:22:31 | preglow | i just did that once on my player and them promptly forgot about it |
| 01:23:37 | preglow | hahah |
| 01:23:41 | preglow | it's perfectly playable |
| 01:23:57 | HCl | nice. |
| 01:24:14 | preglow | buttons are a bit glitchy, but works just fine |
| 01:24:29 | HCl | here ami, can you make a diff against that...? |
| 01:25:05 | amiconn | X11 sim (iriver) also working, a bit slower as expected |
| 01:25:38 | | Join YouCeyE [0] (foobar@youceye.user) |
| 01:25:45 | preglow | i certainly hope the buttons wont handle like this on the player |
| 01:25:52 | HCl | how so? |
| 01:25:59 | preglow | they stick a lot |
| 01:26:07 | HCl | ah. |
| 01:26:21 | HCl | dynarec will probably just make that worse :P |
| 01:26:27 | HCl | maybe, anyways |
| 01:26:50 | amiconn | I think that this is caused by a combination of 2 things |
| 01:27:17 | amiconn | (1) rockboy uses the button queue, instead of reading the button status directly. |
| 01:27:32 | amiconn | (2) For the simulator, there is also the system's button queue |
| 01:27:34 | preglow | which it should stop doing immediatly :) |
| 01:28:01 | HCl | mmm, also, i'd like a direct interface to the iriver lcd framebuffer... it'd save a lot, i think |
| 01:28:05 | preglow | optimizing with this cpu speed is not very rewarding |
| 01:28:10 | preglow | there's never a measurable difference |
| 01:28:22 | amiconn | HCl: Not much, I guess |
| 01:28:35 | HCl | amiconn: every instruction is one |
| 01:30:02 | amiconn | Yes of course. However, you cannot access the lcd buffer directly, this is to be done with lcd commands. |
| 01:30:34 | HCl | i'm still pretty much using a setpixel() command, it'd save a lot if i could do that directly |
| 01:30:42 | HCl | well, not a lot |
| 01:30:44 | HCl | but at least some. |
| 01:31:16 | amiconn | 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 | amiconn | 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 | amiconn | This won't change with the introduction of 2 bit greyscale, btw. It will even get a bit uglier |
| 01:33:34 | HCl | less.. it requires less bitshifts/ors |
| 01:34:01 | amiconn | Imho the amount of shifts/ors per frame will be the same, or even a bit more |
| 01:34:47 | amiconn | In 2-bit mode, one lcd byte "line" consists of 4 pixel rows instead of 8. Each byte represents 4 pixels. |
| 01:35:02 | HCl | yes. |
| 01:35:11 | HCl | then i can just cache 4 scanlines |
| 01:35:14 | HCl | and do like |
| 01:35:39 | HCl | byte&0x2<<0/2/4/6 |
| 01:35:41 | HCl | | |
| 01:35:45 | HCl | 0x3 |
| 01:35:48 | HCl | not 2, my bad |
| 01:36:03 | HCl | at the moment its byte&0x1<<0/1/2/3/4/5/6/7 |
| 01:36:07 | HCl | | |
| 01:36:19 | HCl | or no, even worse actually |
| 01:36:32 | HCl | byte&0x2>>1 / << 2 3 4 5 6 7 |
| 01:36:57 | amiconn | 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 | HCl | yea, i guess you're right with that. |
| 01:37:12 | HCl | o.o |
| 01:37:27 | amiconn | The current implementation doesn't do all those shifts, remember? |
| 01:37:49 | HCl | oh. darn. |
| 01:37:50 | HCl | you're right. |
| 01:37:52 | HCl | that was my old version |
| 01:43:45 | | Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) |
| 01:48:21 | amiconn | HCl: amiconn.dyndns.org/rockboy-new.diff">http://amiconn.dyndns.org/rockboy-new.diff |
| 01:48:33 | HCl | great, thanks |
| 01:49:55 | preglow | halfway done... |
| 01:50:09 | | Quit mecraw () |
| 01:50:14 | HCl | quite some rejects |
| 01:50:44 | HCl | amiconn: can you send me your plugin.h / plugin.c / plugins/Makefile / plugins/SOURCES ? |
| 01:50:51 | preglow | has anyone had a look at the iriver battery indicator, btw? |
| 01:51:16 | HCl | nop. |
| 01:51:31 | HCl | it should be added to the not working section of the iriverport rather than "inaccurate" |
| 01:51:51 | preglow | shouldn't be too hard to rectify |
| 01:51:57 | HCl | i wouldn't know |
| 01:52:45 | preglow | i think you read the battery level as a plain byte |
| 01:52:51 | preglow | only have to interpret it correctly |
| 01:53:55 | amiconn | HCl: amiconn.dyndns.org/rockboy-new-extra.zip">http://amiconn.dyndns.org/rockboy-new-extra.zip |
| 01:54:14 | HCl | thanks |
| 01:55:27 | HCl | ok, thats everything, most of it patched cleanly |
| 01:57:48 | amiconn | 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 | amiconn | 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 |
| 02:00:37 | HCl | kay. |
| 02:01:53 | HCl | 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 | coob | 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 | amiconn | Anyway, nite. |
| 02:09:08 | | Part amiconn |
| 02:10:02 | | Part pear |
| 02:11:22 | preglow | coob: not much, there's docs/API |
| 02:12:02 | coob | agh i'm blind |
| 02:12:19 | preglow | well, it isn't much |
| 02:17:35 | HCl | too bad amiconn left. |
| 02:17:37 | preglow | 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 | HCl | time for a cvs commit |
| 02:17:58 | | Quit Camilo ("Chatzilla 0.9.67 [Mozilla rv:1.8a6/20050111]") |
| 02:18:06 | HCl | (to my local repository) >.> |
| 02:18:23 | preglow | nahah |
| 02:18:36 | preglow | i've been able to shave four seconds off the decode! |
| 02:18:51 | HCl | nice :) |
| 02:18:52 | preglow | i hope to god it performs better on linus' player |
| 02:18:59 | preglow | or i'll be severaly depressed |
| 02:19:02 | HCl | aww. |
| 02:19:09 | * | HCl hands preglow a stuffed animal :x |
| 02:19:12 | preglow | hahaha |
| 02:19:20 | * | preglow cuddles |
| 02:19:25 | HCl | :p |
| 02:20:05 | preglow | it needed to be done anywa |
| 02:20:05 | preglow | y |
| 02:20:05 | preglow | but my god, it is boring |
| 02:20:57 | HCl | tell me about it. |
| 02:21:04 | HCl | dynarec isn't very fun at the moment either. |
| 02:21:10 | coob | which codec are you talking about? |
| 02:21:37 | HCl | 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 | HCl | and gnuboy is designed in such a way that thats impossible to do |
| 02:22:45 | HCl | not only is that gonna give me a terrible debugging time when it finally runs, its also less fun during development :/ |
| 02:23:02 | preglow | coob: mp3 |
| 02:23:21 | coob | libmad? these coldfire optimisations or generic C ones? |
| 02:23:29 | preglow | coob: coldfire |
| 02:23:34 | coob | darn :) |
| 02:23:35 | preglow | coob: it's pure asm... |
| 02:23:43 | preglow | about ten screens of it |
| 02:23:49 | HCl | is that with sacrificed quality or without? |
| 02:23:56 | HCl | ick, assembly coding sucks :x |
| 02:24:00 | coob | we need someone to optimise libmsd for arm |
| 02:24:07 | coob | *libmad |
| 02:24:15 | preglow | why? it already is pretty optimized for arm |
| 02:24:24 | coob | well, once the dual cores are working sufficiently well enough |
| 02:24:44 | preglow | HCl: full quality |
| 02:24:46 | coob | it is? |
| 02:24:54 | * | coob not actually looked at it, |
| 02:25:02 | preglow | coob: sure, you've got optimized multipliers and an imdct written in pure asm |
| 02:25:40 | HCl | good :) |
| 02:25:53 | coob | optimised multipliers using lookup tables? |
| 02:26:34 | preglow | coob: no, arm has pretty good multiplier support |
| 02:26:40 | coob | bleh |
| 02:26:46 | preglow | coob: libmad needs 32x32 bit muls, and arm's got just that |
| 02:26:52 | preglow | coob: in a way that integrates perfectly with libmad |
| 02:26:54 | coob | i mean division using multiplication tables |
| 02:27:07 | preglow | there is very little division needed |
| 02:27:18 | preglow | \o/ |
| 02:27:21 | preglow | just two screens of code left |
| 02:27:30 | coob | still, multiplicaiton - few cycles, division = 10x that |
| 02:27:50 | preglow | coob: indeed, so good thing libmad almost never uses it |
| 02:30:43 | preglow | standard operation that's used a lot is mac, and arm supports that directly |
| 02:35:29 | | Quit rovragge ("Lost terminal") |
| 02:37:23 | preglow | 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 | HCl | sounds good |
| 02:38:49 | preglow | 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 | HCl | mrf... |
| 02:48:17 | preglow | haha |
| 02:48:27 | preglow | this exceeds all expectations |
| 02:48:31 | preglow | nearly done, and it still sounds good |
| 02:51:49 | HCl | mmm? |
| 02:55:54 | preglow | i've got like 500 lines of assembly, there not being a mistake some place in there is... unusual... :) |
| 02:56:52 | HCl | heheheh. |
| 02:57:01 | HCl | yea, 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:01 | preglow | ok, ok |
| 03:29:12 | preglow | the mistakes i'm making now are unbelievable |
| 03:29:14 | preglow | bed 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:58 | ashridah | linusn |
| 09:46:04 | LinusN | hi |
| 09:52:00 | pabs | ahoy |
| 09:53:16 | pabs | LinusN: less talking, more getting the sound on my iriver working :-D |
| 09:53:50 | pabs | if you do that, i'll contribute some code to rockbox |
| 09:58:44 | ashridah | didn'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:52 | stripwax | ello |
| 10:06:35 | | Join bobTHC [0] (~foo@l03v-35-190.d1.club-internet.fr) |
| 10:08:01 | rickst131 | ello back |
| 10:08:49 | bobTHC | hi all |
| 10:08:55 | Strath | hey amiconn |
| 10:09:06 | amiconn | hi |
| 10:09:27 | Strath | hows the iriver lcd driver coming? |
| 10:10:04 | amiconn | Erm, why do you ask me? I have no iriver (yet) |
| 10:10:19 | Strath | cvs commit log |
| 10:10:54 | ashridah | he's been cleanign up general bugs in the simulator. |
| 10:10:56 | Strath | or you just accepting the patches from another? |
| 10:11:03 | LinusN | i don't see any lcd commits from amiconn |
| 10:11:17 | Strath | linus working on it then? |
| 10:11:33 | Strath | "Fri Feb 11 01:06:14 2005 UTC (2 weeks, 4 days ago) by amiconn " |
| 10:12:41 | ashridah | that's still stuff for the simulator. |
| 10:12:59 | stripwax | 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 | stripwax | ^irc logs that is |
| 10:13:29 | Strath | k thx |
| 10:14:02 | stripwax | Strath - some screenshots of a mandlebrot generator and a jpeg viewer using 4-color greyscale on iriver |
| 10:14:18 | ashridah | that's a misnomer. |
| 10:14:23 | ashridah | grey isn't a colour ;) |
| 10:14:25 | stripwax | 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 | stripwax | 4-level greyscale |
| 10:14:50 | Strath | so the greyscale isn't tied directly to the iriver lcd driver and is in a lib? thats good :) |
| 10:14:54 | ashridah | 2bit greyscale |
| 10:15:22 | ashridah | Strath: it makes sense to abstract it out, other players may have 2bit or more greyscale or even colour later. |
| 10:16:04 | Strath | ya... i'm just starting work on the gmini 220 lcd driver, 4bpp lcd |
| 10:16:05 | stripwax | 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 | stripwax | Strath - neat-o! |
| 10:16:59 | Strath | what about linear screen buffer vs. "line of columns" ordering? |
| 10:17:47 | stripwax | Strath - should be possible to store the screen buffer in whatever way suits your hardware best |
| 10:18:01 | LinusN | stripwax: if rockbox used the grayscale lib on the archos, the ui would slow down to a crawl |
| 10:18:26 | LinusN | and possibly eat a little more battery |
| 10:18:41 | stripwax | LinusN - really? that's a shame. I wasn't suggesting using the greyscale functionality on the ui, just the api |
| 10:18:42 | Strath | k, didn't know how much of that was throughout the code |
| 10:19:30 | stripwax | LinusN i.e. set color, draw pixel, as opposed to draw pixel/clear pixel/invert pixel |
| 10:19:48 | amiconn | heh, that's my suggestion ;) |
| 10:20:04 | stripwax | amiconn - I agree with it ;-) |
| 10:21:55 | LinusN | we will need to add multicolor to the core lcd api |
| 10:22:19 | Strath | any tips on getting started on that driver? minimal api function needing to be implemented? getting make to use it, etc? :) |
| 10:23:03 | amiconn | LinusN: Did you have a look at the grayscale lib api? |
| 10:23:14 | LinusN | no |
| 10:25:56 | jyp | Strath: duplicate and existing lcd-....c, change SOURCES to use it; then hack ;) |
| 10:26:25 | Strath | :P |
| 10:28:51 | amiconn | I think the lcd drivers should share most of the code. |
| 10:29:07 | LinusN | yes |
| 10:29:08 | amiconn | Only the low level stuff needs to be lcd controller specific |
| 10:29:26 | * | jyp fully agrees |
| 10:29:49 | LinusN | the tricky part would be that the frame buffer format could differ between the platforms |
| 10:30:27 | amiconn | Yes, but e.g. the line drawing algorithm, the range checking etc is identical for all platforms |
| 10:30:52 | amiconn | I consider most graphics primitives rather high-level |
| 10:32:02 | Strath | assuming your drawing algorithms are wholely pixel based |
| 10:32:14 | LinusN | most of them are |
| 10:32:48 | stripwax | I'm assuming vertical line drawing is optimised for the byte layout on archos/iriver? |
| 10:32:56 | LinusN | nope |
| 10:33:23 | amiconn | Well, the routines that actually change larger pixel blocks (like fillrect() and bitmap drawing) profit from knowing the pixel format |
| 10:33:25 | stripwax | oh. is text printing pixel based too? |
| 10:33:37 | LinusN | no |
| 10:33:46 | stripwax | ok that's good |
| 10:33:50 | Strath | that'd be slow ;) |
| 10:34:24 | stripwax | quite |
| 10:35:00 | amiconn | The problem for other display might be that our font format is currently tailored for the archos lcd data format |
| 10:35:10 | stripwax | bitmaps too i'd imagine? |
| 10:35:32 | Strath | not all archos devices use that format amiconn :) |
| 10:36:48 | LinusN | amiconn: the iriver lcd has the same format |
| 10:36:49 | amiconn | stripwax: yes. |
| 10:36:49 | Strath | would the font bitmaps need to be regenerated then for linear mapped devices? |
| 10:37:01 | LinusN | yes |
| 10:37:15 | amiconn | LinusN: Only when using 1-bit mode. In 2-bit mode it is similar, but not identical |
| 10:37:30 | LinusN | true |
| 10:37:33 | amiconn | The question is whether we should keep that format for b&w graphics |
| 10:37:42 | amiconn | I'd vote with yes. |
| 10:38:34 | Strath | i'd vote for linear mapped files converted at compile/link time, but then i'm biased :) |
| 10:38:48 | amiconn | 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 | Strath | we could just have the bitmaps chew up huge gobs of memmory... |
| 10:40:01 | amiconn | Strath: Now exactly that is not possible |
| 10:40:01 | stripwax | 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 | Strath | a joke, sheesh :P |
| 10:40:35 | amiconn | stripwax: Then he would have to change the drawing function call as well |
| 10:41:06 | LinusN | the fonts should be converted to the native format for each platform |
| 10:41:13 | stripwax | 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 | LinusN | the same goes for the other bitmaps |
| 10:41:34 | amiconn | My suggestion is, the drawing functions should support 1-bit, 8-bit (and leaving open the option for 24-bit) |
| 10:42:02 | amiconn | 1-bit could use plain old archos format, 8-bit and 24-bit linear mapped |
| 10:42:24 | LinusN | that would slow down the lcd drawing on the iriver |
| 10:43:55 | amiconn | 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 | amiconn | I.e. old archos has 1-bit, iriver h1xx 2-bit, gmini 2xx 4-bit, iriver h3xx colour... |
| 10:44:39 | LinusN | still, the hardware is limited when it comes to cpu power and memory bandwidth |
| 10:44:40 | Strath | 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 | LinusN | Strath: exactly |
| 10:45:31 | amiconn | 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 | LinusN | or we develop a tool for that |
| 10:46:07 | Strath | or limit plugin targets |
| 10:46:20 | jyp | The bitmaps really need to be compile-time generated per device anyway imho |
| 10:46:26 | amiconn | Strath: That's not exactly the idea with rockbox |
| 10:47:17 | Strath | i know... be easier than getting all plugin authors to generate bitmaps for each platform... |
| 10:47:41 | amiconn | 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 | Strath | (especialy for existing plugins) |
| 10:48:17 | LinusN | or they are converted in runtime, when loading |
| 10:48:37 | amiconn | urgs.... |
| 10:49:09 | LinusN | :-) |
| 10:49:11 | Strath | big 'ol' can of worms :) |
| 10:49:13 | jyp | ... or both |
| 10:49:52 | amiconn | Runtime conversion would imho add too much code, keeping in mind the limited memory |
| 10:50:23 | amiconn | The custom bitmap approach will then make the fonts platform specific |
| 10:50:52 | ashridah | unless you devise a platform neutral format and convert on compile... |
| 10:51:00 | ashridah | or make zip or whatever |
| 10:51:29 | LinusN | ashridah: exactly |
| 10:51:40 | amiconn | I'm talking about the target format for distribution. |
| 10:52:26 | amiconn | 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 | LinusN | yup |
| 10:52:45 | Strath | 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 | LinusN | nah |
| 10:52:55 | amiconn | In addition, having >1 bit fonts leads to additional problems |
| 10:53:50 | amiconn | 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 | amiconn | A similar approach is possible with the standard greyscale format (1 byte/pixel linear), using it as an alpha value |
| 10:54:41 | amiconn | This will get *very* hard to do in the target format.... |
| 10:55:08 | LinusN | in the fonts, value 0 would be the background |
| 10:55:34 | amiconn | Yes... still, how do you handle the other 3 values? |
| 10:55:51 | amiconn | With 1 byte/pixel, doing alpha, i.e. anti-aliasing, is easy. |
| 10:55:53 | LinusN | you want more transparent colors? |
| 10:56:02 | Strath | blending.... uhg :) |
| 10:56:25 | amiconn | With the target format, this will turn out to be way slower |
| 10:56:44 | LinusN | why would we do antialiasing in runtime? |
| 10:57:26 | amiconn | Because you simply cannot do this at compile time |
| 10:57:36 | LinusN | no, but when you design the font |
| 10:57:56 | amiconn | This won't work either |
| 10:57:59 | stripwax | LinusN - that would only work if you *assume* the background is white, no? |
| 10:58:10 | LinusN | stripwax: of coyrse |
| 10:58:10 | Zagor | antialiasing != transparence |
| 10:58:23 | amiconn | LinusN: ..and white background _only_ |
| 10:58:31 | LinusN | amiconn: yes, and why is that a problem? |
| 10:58:32 | amiconn | Imho this is not what we want |
| 10:58:48 | stripwax | LinusN - it would fail if the background is grey, for example.. |
| 10:58:54 | jyp | is transparency used in rockbox as it stands ? |
| 10:59:00 | amiconn | E.g. it will look veeery ugly with the selection set to 'bar (inverse)'... |
| 10:59:23 | Strath | jyp, i think only draw the '1's |
| 10:59:59 | jyp | Strath: I know, but it is really taken advantage of at the application level |
| 11:00 |
| 11:00:00 | jyp | ? |
| 11:00:07 | Zagor | jyp: there can be no transparency in a 1-bit display |
| 11:00:37 | jyp | Zagor: "drawing black only" ... |
| 11:00:43 | stripwax | Zagor - sure there can |
| 11:01:04 | Zagor | ok right, if that's your definition. then yes, we support and use it. |
| 11:01:05 | stripwax | Zagor - no trans*lucency* but transparency is just a case of masking.. |
| 11:01:05 | amiconn | Zagor: There can.... and even is implemented. Just that you only have 0% or 100% transparency |
| 11:01:44 | Zagor | stripwax: aha, i'm mixing it up |
| 11:02:30 | *** | Saving seen data "./dancer.seen" |
| 11:04:09 | jyp | Alright, so we have 3 possible features to support: transparency; translucency; reverse-video |
| 11:10:09 | Strath | in various formats |
| 11:12:13 | LinusN | imho, antialiased fonts is very unnecessary |
| 11:12:42 | Strath | 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 | amiconn | 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 | LinusN | i can live with that |
| 11:14:44 | LinusN | as long as font rendering is fast enough |
| 11:15:28 | amiconn | The current 11 MHz iriver is a good testbed... |
| 11:15:33 | HCl | sounds ok with me. |
| 11:15:36 | Strath | amiconn, i can agree with that |
| 11:15:47 | HCl | lower 2 bits of a byte? |
| 11:16:30 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 11:16:45 | HCl | here ami, your version, with my dynarec added |
| 11:17:32 | amiconn | HCl: No, always using the full range i.e. 0== black, 255 == white |
| 11:17:43 | Strath | 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 | HCl | darn.. |
| 11:18:09 | Strath | amiconn, correct |
| 11:18:30 | LinusN | amiconn: for the file format, right? |
| 11:18:41 | LinusN | not runtime, i hope |
| 11:18:53 | amiconn | 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 | amiconn | LinusN: I'm talking about runtime format as well as file format |
| 11:19:31 | preglow | wasn't someone working on a more precise timer? |
| 11:19:45 | LinusN | so the lcd_bitmap() function would have to translate the gray values in runtime? |
| 11:20:04 | Strath | yes, but i think we might actually be talking about seperate issues then |
| 11:21:21 | dwihno | HCl: how is dynarec going? |
| 11:22:02 | | Join Patr3ck [0] (~patr3ck@pD9ECFC0E.dip.t-dialin.net) |
| 11:22:03 | amiconn | LinusN: Please have a look at the grayscale lib api. It supports 1-bit bitmaps as well as 8-bit bitmaps |
| 11:22:10 | HCl | dwihno: slowly, not too efficient cause of z80 flags. building some opcodes from gcc, its a pain, really |
| 11:22:24 | amiconn | For 1-bit, there is selectable foreground colour, background colour, and draw mode |
| 11:22:43 | Strath | 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 | Strath | (maybe lower even...) |
| 11:23:38 | dwihno | HCl: I wish you the best of luck! :) |
| 11:23:47 | amiconn | There are 4 draw modes. Draw foreground pixels only, background pixels only, draw all pixels, and invert foreground pixels |
| 11:24:08 | LinusN | 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 | Strath | draw all is the only one that would really gain from having native font format |
| 11:25:29 | amiconn | Strath: Exactly, and all other operations would be slower... |
| 11:25:54 | Strath | well, xor with read value maybe... |
| 11:26:02 | amiconn | ...probably way slower |
| 11:27:04 | Strath | xor, and, or, actually, it could speed up, i was thinking per pixel calculations |
| 11:27:27 | preglow | HCl: a shift isn't very expensive... |
| 11:27:47 | preglow | HCl: one cycle on coldfire, unless i remember incorrectly |
| 11:27:48 | amiconn | 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 | HCl | preglow: every instruction is one too many |
| 11:29:04 | preglow | 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 | HCl | well, i'm only planning it for where i actually need speed - rockboy |
| 11:30:38 | LinusN | amiconn: how would the grayscale value translation be done? |
| 11:30:52 | Strath | are there various fonts already in use or just the single system font? |
| 11:31:13 | preglow | Strath: fonts are user selectable |
| 11:31:59 | Strath | so, preglow, there are several to choose from.. |
| 11:32:05 | preglow | Strath: a ton |
| 11:32:09 | Strath | k ;) |
| 11:32:20 | preglow | they all differ inn appearance and size |
| 11:32:40 | HCl | hm, actually, nm, if 0 = black, i don't need any bitshifts *isn't awake yet* |
| 11:33:19 | amiconn | 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 | preglow | 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 | LinusN | preglow: sure |
| 11:33:51 | HCl | hm, nm :x |
| 11:33:59 | * | HCl goes back to sleep before he says more stupid stuff >.> |
| 11:34:13 | preglow | LinusN: did your previous 95% realtime result have any code placed in sram, btw? |
| 11:34:32 | LinusN | preglow: lots of code in sram |
| 11:35:31 | LinusN | amiconn: and those transparency operations, shifts and inversions would be added to the lcd_bitmap() function? |
| 11:35:56 | LinusN | and it wouldn't be much slower? |
| 11:36:24 | LinusN | i can imagine at least double execution time |
| 11:38:08 | Strath | 'read, transform, write' vs 'write' |
| 11:39:17 | amiconn | LinusN: My point is that it is not different from using the native format *except* for when you draw solid |
| 11:39:59 | amiconn | I..e with 8-bit linear format you need transform-write for solid, while with native format you only need write |
| 11:40:26 | Strath | (yes, i think i am arguing both sides of the issue, sorry ;) |
| 11:41:13 | amiconn | However, for other drawing modes you need readback-transform, transform, combine, transform,write with native format |
| 11:41:34 | amiconn | With 8-bit linear you only need readback, combine, transform, write in this case |
| 11:42:25 | amiconn | In fact, it would be even better if the framebuffer is also in 8-bit linear format for grayscale |
| 11:42:50 | amiconn | This way, only lcd_update() and lcd_update_rect() need to know about the internal format |
| 11:42:54 | Strath | 220 and xs200 use a 4bit linear format |
| 11:43:16 | jyp | no |
| 11:43:28 | jyp | xs200 is unknown |
| 11:43:29 | jyp | ;? |
| 11:43:30 | jyp | ;) |
| 11:43:37 | Strath | so an operation using a native format could handle two pixels at once |
| 11:43:37 | LinusN | amiconn: then the frame buffer would eat a lot more precious IRAM, and lcd_update() will suffer a lot |
| 11:44:14 | Strath | jyp, it's 2bit/pixel stored in 2pixel per byte format |
| 11:44:34 | Strath | at least in the frame buffer or the archos firmware |
| 11:44:41 | Strath | s/or/of/ |
| 11:45:02 | jyp | Yup, but framebuffer is linear for the 120/SP too |
| 11:45:08 | jyp | doesn't tell you much |
| 11:45:15 | amiconn | 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 | Strath | jyp :P |
| 11:45:19 | amiconn | *at once |
| 11:45:38 | LinusN | amiconn: true |
| 11:46:24 | amiconn | 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 | amiconn | 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 | Strath | ami, your talking about transfering the data to the lcd controler, not the frame buffer? |
| 11:48:10 | amiconn | 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 | Strath | i2c writes and what not |
| 11:48:33 | Strath | what if your lcd controler uses dma? :) |
| 11:49:00 | amiconn | Then you would need an additional dma buffer |
| 11:49:45 | amiconn | 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 | LinusN | still, lcd_update() would be 5-6 times slower |
| 11:51:43 | LinusN | even more |
| 11:52:37 | amiconn | The transfer itself is going to take much longer than the conversion anyway, or am I wrong? |
| 11:53:18 | LinusN | the transfer is parallel |
| 11:53:50 | amiconn | Okay. |
| 11:54:00 | LinusN | a simple move.w |
| 11:54:26 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 11:54:42 | amiconn | I agree that this would make lcd_update() slower, but all other graphics operations should be faster. |
| 11:55:23 | amiconn | Do you have a clue what the overall performance change would be? I guess it will go faster overall... |
| 11:55:28 | Strath | too many variables ;) |
| 11:56:32 | Strath | bit depth, storage format, controler transfer method, pixel effects, aaaah! |
| 11:56:32 | amiconn | ...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:19 | stripwax | ello |
| 12:03:49 | stripwax | So, power cuts across a bunch of internet routers, i just got kicked right out of cyberspace |
| 12:03:55 | Strath | 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 | Strath | 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 | amiconn | Strath: I agree that anti-aliasing and translucency isn't top priority, however, we certainly will see numerous requests for that. |
| 12:44:24 | amiconn | Plus, I doubt that transparency and inversion is faster & easier in the native format. |
| 12:47:04 | Strath | but would it ever be worth implementing anti-aliasing and translucency on such a low powered device? even if requested... |
| 12:48:31 | preglow | hahah |
| 12:48:47 | preglow | 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 | Lynx_ | i'd love a transparent mp3 player ;) |
| 12:53:23 | Strath | lol |
| 12:54:16 | amiconn | 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 |
| 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 | jyp | Gotcha! |
| 13:07:25 | [Unseen] | heh? |
| 13:07:41 | jyp | Your nick ... Nevermind :P |
| 13:08:00 | [Unseen] | lol |
| 13:09:45 | Strath | silly jyp, nick are for ... |
| 13:10:35 | | Nick [Unseen] is now known as SeenByJyp (~e@pc2996.gsf.de) |
| 13:12:19 | Strath | 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: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:44 | LinusN | preglow: i have now committed a fix for the codec dependencies |
| 14:36:44 | LinusN | but i'm not yet sure how to make the plugins depend on the codec libs |
| 14:37:03 | preglow | great nonetheless |
| 14:37:22 | LinusN | you only want the *2wav plugins rebuilt, not all of them |
| 14:37:40 | preglow | yes, but it beats having to make clean every time |
| 14:37:43 | | Quit SeenByJyp () |
| 14:38:02 | LinusN | i also moved the main stack to iram |
| 14:39:50 | preglow | i think i'll make a separate asm file of this imdct_l business, it's quite ugly |
| 14:40:23 | preglow | is it easy to place certain variables in iram? |
| 14:44:48 | LinusN | int myarray[1024] __attribute__ ((section(".idata"))); |
| 14:45:03 | preglow | 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 | LinusN | there's of course the penalty of moving it there |
| 14:48:14 | preglow | why does it have to be moved there? |
| 14:48:31 | preglow | iram is in the same address space as sdram? |
| 14:49:48 | LinusN | 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 | preglow | ahh |
| 14:51:01 | preglow | well, no, not exactly |
| 14:51:10 | | Join Renko [0] (~Renko@host81-152-87-182.range81-152.btcentralplus.com) |
| 14:51:18 | preglow | it has to be handled by the huffman decoder first |
| 14:51:33 | preglow | and that might require less memory bandwidth that way |
| 14:51:39 | elinenbe | preglow, LinusN: what's the current speed of the mp3 codec on the target? |
| 14:51:59 | preglow | there are several layers before the mdct sees it |
| 14:52:28 | LinusN | elinenbe: we have reached 95%, but that's in 140MHz and with non-CVS hacks |
| 14:52:38 | LinusN | preglow: ok |
| 14:52:44 | preglow | it should be realtime with my latest opt |
| 14:52:55 | preglow | at least, i'll be severely disappointed if it's not |
| 14:53:37 | LinusN | i have lowered the max freq to 96MHz in my soon-to-be committed cpu frequency fix |
| 14:54:01 | LinusN | so you'll just have to optimize some more :-) |
| 14:54:46 | LinusN | can you send me a patch? |
| 14:55:42 | preglow | well, yes, but it's a bloody mess and has to be kept from the public :) |
| 14:56:14 | LinusN | hehe |
| 14:56:24 | preglow | it would be easier if i could just send you the entire file, it's going to be a messy patch |
| 14:56:29 | LinusN | sure |
| 14:56:38 | | Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 14:56:52 | ripnetuk | is it stable at 96MHz? |
| 14:57:05 | preglow | http://glow.m0f0.net/rockbox/layer3.c |
| 14:57:42 | preglow | you'll still need the emac.h |
| 14:58:20 | LinusN | ok |
| 14:59:56 | LinusN | non-optimized mpa2wav is 40% with only my latest stack fix |
| 14:59:59 | LinusN | in 96MHz |
| 15:00 |
| 15:00:06 | preglow | not too shabby |
| 15:01:29 | LinusN | ripnetuk: i don't know yet if it is stable |
| 15:02:03 | ripnetuk | but no nasty ata issues like we had at full speed yet? |
| 15:02:33 | *** | Saving seen data "./dancer.seen" |
| 15:02:35 | LinusN | not yet, but i'll have to run it a while to heat up the hard drive |
| 15:02:47 | ripnetuk | yeah... intermittent problems are the worst |
| 15:04:44 | LinusN | preglow: quite a disappointment...46% |
| 15:04:51 | preglow | ....... |
| 15:05:04 | preglow | LinusN: is that with synth.c opt as well? |
| 15:05:12 | LinusN | no |
| 15:05:15 | preglow | arhghh |
| 15:05:34 | preglow | maybe i should try optimizing the other imdct |
| 15:06:00 | LinusN | forgot the synth.c, hang on... |
| 15:06:14 | preglow | synth.c helped more, if i don't remember incorrectly |
| 15:06:19 | LinusN | yes |
| 15:06:37 | LinusN | but moving code and tables to iram helps a *lot* |
| 15:07:01 | LinusN | i moved plenty of constants and tables to iram last time |
| 15:07:08 | LinusN | but not now |
| 15:07:25 | preglow | yes |
| 15:07:56 | preglow | we'll have to find the hotspots and put that in iram |
| 15:08:00 | preglow | i don't think we have a choice in that matter |
| 15:08:15 | LinusN | no we don't |
| 15:10:04 | | Quit edx (Read error: 110 (Connection timed out)) |
| 15:10:10 | LinusN | 54% with synth.c |
| 15:11:06 | preglow | i read somewhere that the huffman decoder is pretty demanding as well |
| 15:11:19 | preglow | but that looks like its just a huge lookup table in libmad |
| 15:11:42 | LinusN | i moved those to iram last time, made a noticeable difference |
| 15:13:40 | stripwax | .. sorry for the dumb question, but what is "iram"? |
| 15:14:03 | preglow | ram that's internal to the coldfire |
| 15:14:07 | preglow | single cycle acces |
| 15:14:20 | preglow | _very_ fast compared to the sdram, but there's only 96kb of it |
| 15:14:28 | stripwax | i thought that would be called sram... why are you calling it iram? |
| 15:14:40 | LinusN | (I)nternal RAM |
| 15:14:44 | preglow | dunno, because everyone else is calling it iram? :P |
| 15:14:49 | preglow | sram/iram, i don't care |
| 15:15:49 | stripwax | 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 | preglow | 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 | preglow | i'll clean my opts up a bit |
| 15:16:28 | preglow | so people can use them |
| 15:16:43 | preglow | stripwax: it'll have to be used dynamically |
| 15:16:49 | preglow | stripwax: as i said, there's only 96kb of it |
| 15:17:14 | stripwax | preglow thanks, didn't know how big the tables would be |
| 15:17:45 | | Quit HCl ("Lost terminal") |
| 15:18:06 | amiconn | LinusN: You could run test_fs for a while to see if it is stable at 96 MHz |
| 15:18:13 | LinusN | 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 | amiconn | Just choose the number of passes so that the file size is just below 2 GB, and let it run.... |
| 15:19:12 | HCl | whats up? |
| 15:21:06 | LinusN | not much |
| 15:21:32 | | Quit jyp (Read error: 110 (Connection timed out)) |
| 15:21:41 | LinusN | the usual optimization discussions |
| 15:22:06 | preglow | HCl: my opt turned out to be of little signifigance... |
| 15:22:31 | | Join webguest90 [0] (~c0a5d512@labb.contactor.se) |
| 15:22:33 | LinusN | preglow: are the dct constants in iram? |
| 15:22:37 | preglow | quite luckily the weather is excellent, so i'm hard to depress |
| 15:22:41 | preglow | LinusN: they're code |
| 15:22:59 | preglow | LinusN: i do move.l #const, %%reg _all_ the time |
| 15:22:59 | amiconn | LinusN: I would even suggest to increase the clock gradually, and check when it starts to produce errors |
| 15:23:15 | HCl | preglow: :( how so? |
| 15:23:23 | LinusN | amiconn: that's an idea |
| 15:23:40 | preglow | HCl: it gained 6%, from 40% at 96mhz |
| 15:23:51 | HCl | well, at least its something |
| 15:23:54 | preglow | HCl: which is a bit less than i hoped for |
| 15:23:56 | preglow | but yes |
| 15:23:58 | preglow | i had to try |
| 15:24:04 | amiconn | preglow: from 40% to 46% realtime is a 15% speed increase |
| 15:24:09 | HCl | clearly we'll get it to work some how, we can resort to reverse engineering the original firmware if all fails |
| 15:24:20 | preglow | HCl: it won't come to that |
| 15:24:28 | preglow | there are a lot of clever people around |
| 15:24:28 | HCl | hm |
| 15:24:31 | HCl | if you say so |
| 15:25:10 | LinusN | synth_full() should be in iram |
| 15:25:14 | preglow | LinusN: indeed |
| 15:25:41 | preglow | i don't know how often synth_half will be used |
| 15:25:50 | preglow | i think that's used for half sampling rate synthesis |
| 15:25:53 | amiconn | 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 | preglow | which no one in their right mind does |
| 15:26:36 | preglow | amiconn: that's an idct, not an imdct :P |
| 15:27:23 | preglow | amiconn: sh1 has mac? |
| 15:27:32 | LinusN | yes |
| 15:28:08 | amiconn | preglow: It has mac. 16x16bit -> 42 bit |
| 15:29:08 | preglow | amiconn: cool |
| 15:29:29 | preglow | amiconn: i'd love to have a look, but haven't got time right now |
| 15:29:55 | elinenbe | quick question... does the target produce any sound right now? for anyone? |
| 15:30:38 | HCl | there's a wav play thing on the wiki. |
| 15:36:03 | preglow | 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 | LinusN | yes |
| 15:36:48 | LinusN | but i haven't enabled the page mode yet |
| 15:36:56 | preglow | what does that do? |
| 15:37:20 | LinusN | faster access time for sequential fetches |
| 15:37:38 | preglow | ahh |
| 15:37:39 | preglow | goodie |
| 15:37:40 | LinusN | right now you have only burst access, very rare |
| 15:37:46 | preglow | yes, movem only, i guess |
| 15:39:12 | | Join webguest00 [0] (~81b1111b@labb.contactor.se) |
| 15:40:35 | LinusN | preglow: cpu boost committed |
| 15:40:43 | preglow | LinusN: excellent, will test it out right now |
| 15:40:55 | LinusN | it is not enabled by default |
| 15:41:02 | LinusN | you do like this: |
| 15:41:12 | LinusN | enter debug->view i/o ports |
| 15:41:28 | webguest00 | hi, I was reading the logs. Do you know that there is a demo mp3-decoder for coldfire MCF5249L |
| 15:41:38 | LinusN | then UP for max frequency (96MHz), DOWN for normal (which is 48MHz) |
| 15:41:45 | LinusN | webguest00: yes |
| 15:41:53 | webguest00 | ok, hehe, guessed that |
| 15:41:57 | LinusN | or SELECT for 11MHz |
| 15:42:05 | preglow | LinusN: great, a lot easier to time my own code now |
| 15:42:12 | LinusN | yes |
| 15:42:26 | preglow | i'd have to perform miracles to see a difference at 11mhz |
| 15:43:08 | LinusN | pretty impressive assembler blobs in layer3.c :-) |
| 15:43:09 | | Join lolo-laptop [0] (~lostlogic@68.251.84.226) |
| 15:43:13 | preglow | LinusN: i agree |
| 15:43:33 | preglow | i completed it at 04:00, haha |
| 15:43:35 | preglow | my brain was fried |
| 15:43:57 | preglow | i'll have to finish it fast, before i forget what's what |
| 15:44:13 | LinusN | preglow: the idea behind the cpu boost stuff is this: |
| 15:44:37 | LinusN | when you need extra power, call cpu_boost(), it will set the cpu frequency to maximum |
| 15:44:48 | preglow | LinusN: hah! extremely cool |
| 15:44:54 | LinusN | when you're done, call cpu_boost(false) |
| 15:45:01 | HCl | nice |
| 15:45:03 | preglow | and it'll clock it at 140mhz ? |
| 15:45:07 | LinusN | 96 |
| 15:45:24 | LinusN | several threads may call cpu_boost(true) |
| 15:45:29 | preglow | ahh, yes, but using 140mhz might be viable there? |
| 15:45:37 | | Part webguest00 |
| 15:45:42 | preglow | will have to test to determine that, i guess |
| 15:45:44 | LinusN | but the frequency will not be lowered until all threads have called cpu_boost(false) |
| 15:46:01 | LinusN | boosting the cpu takes up to 10ms |
| 15:46:05 | preglow | oh |
| 15:46:08 | ripnetuk | is there much advantage in running in slow mode? less power usage? less overheating? |
| 15:46:12 | preglow | pll probably needs to readjust |
| 15:46:14 | ripnetuk | when I say slow, i mean normal |
| 15:46:15 | LinusN | less power usage |
| 15:46:27 | LinusN | preglow: yes, it's the max locking time |
| 15:46:46 | ripnetuk | but wont 99% of usage be urm, playing mp3's, which seems to require the full power |
| 15:46:52 | LinusN | so you shouldn't call cpu_boost() often |
| 15:47:12 | preglow | wtf? freq selector is locked at 11mhz |
| 15:47:33 | LinusN | the what? |
| 15:47:43 | preglow | io ports stuff wouldn't let me choose 96mhz |
| 15:48:13 | LinusN | up for 96, down for 48, select for 11 |
| 15:48:18 | preglow | it's a veritable greased ligtning |
| 15:48:19 | preglow | hahahaha |
| 15:48:24 | preglow | decoded my test file like lightning |
| 15:48:28 | preglow | 50% realtime |
| 15:48:44 | LinusN | feels nice, doesn't it? :-) |
| 15:48:48 | preglow | it indeed does |
| 15:49:06 | LinusN | have to run, cu around |
| 15:49:10 | preglow | yep |
| 15:49:13 | | Part LinusN |
| 15:49:20 | preglow | i'll go enjoy the sun and my h120, later |
| 16:00 |
| 16:04:28 | CoCoLUS | 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 | CoCoLUS | now THATS creative |
| 16:05:06 | stripwax | wot? |
| 16:05:30 | CoCoLUS | http://www.engadget.com/entry/1234000907033676/ |
| 16:05:34 | CoCoLUS | freaky, somewhat |
| 16:07:18 | coob | old news |
| 16:07:25 | coob | that happened in like december |
| 16:07:38 | coob | and they used the screenshot of all 0's where it didn't work :/ |
| 16:07:46 | coob | journalists = slow and lousy! |
| 16:07:50 | | Quit webguest90 ("CGI:IRC (Ping timeout)") |
| 16:09:06 | CoCoLUS | well it was news for me :) |
| 16:09:35 | stripwax | i preferred my method :-) |
| 16:09:55 | coob | he wanted to do it without cracking open his ipod... |
| 16:10:13 | CoCoLUS | having sex with an iriver employee? :) |
| 16:10:23 | CoCoLUS | social engineering, i think its called :P |
| 16:10:32 | stripwax | coob - I didn't have to open my iriver, or have sec with any employees |
| 16:10:59 | ripnetuk | jects/rockbox/cvs/rockbox/build/sim/rockbox_flash.o |
| 16:11:05 | ripnetuk | sorry... |
| 16:11:06 | stripwax | ? |
| 16:11:12 | ripnetuk | accedential paste |
| 16:23:57 | ripnetuk | 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 | ripnetuk | 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 | ripnetuk | 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 | stevenm | 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 | stevenm | 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:00 |
| 17:02:05 | | Join webguest90 [0] (~c0a5d512@labb.contactor.se) |
| 17:02:22 | stripwax | Hi, i'm writing a cubic spline interpolation for yuor MIDI codec :-) |
| 17:02:34 | stripwax | I'm also making a bunch of changes in general |
| 17:02:36 | *** | Saving seen data "./dancer.seen" |
| 17:02:52 | stripwax | Did you say you got looping working? |
| 17:04:32 | | Join mecraw [0] (~mecraw@69.2.235.2) |
| 17:05:08 | stripwax | ah, i think i've kinda got looping working on my version here, ... kinda ... |
| 17:11:12 | stevenm | hi |
| 17:11:28 | stevenm | I did a whole bunch of work on looping last night |
| 17:11:53 | stripwax | cool, did you update your tarball? |
| 17:11:58 | stevenm | forward, reverse, and pingpong |
| 17:11:59 | stevenm | oh no |
| 17:12:03 | stevenm | I will in a second |
| 17:12:11 | stevenm | here |
| 17:12:14 | stripwax | thx! |
| 17:13:01 | stevenm | there it's up |
| 17:13:42 | stevenm | 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 | stripwax | thanks! what was the link again? |
| 17:14:06 | stevenm | stevenm/irivermidi.tbz2">http://wam.umd.edu/~stevenm/irivermidi.tbz2 |
| 17:14:07 | | Quit ripnetuk ("Leaving") |
| 17:14:19 | stevenm | thank you for the interpolation stuff... how would I go about coding it? |
| 17:14:25 | stevenm | and, does the thing actually make sound on Cygwin ? |
| 17:14:25 | stripwax | I've added a cubic spline interpolation, I like the way it sounds but it still uses way too much cpu. |
| 17:14:33 | stripwax | stevenm yes, that's how i'm testing it |
| 17:14:38 | stevenm | ah.. sweet |
| 17:14:41 | | Quit bobTHC (Read error: 110 (Connection timed out)) |
| 17:14:50 | stevenm | cubic spline? |
| 17:14:58 | stevenm | what about linear or something ? |
| 17:15:54 | stevenm | 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 | stevenm | drums seem fairly straightforward.. envelope will reqiore a hex editor and some trial and error |
| 17:16:42 | stripwax | google |
| 17:16:42 | amiconn | stripwax: Wouldn't a simple linear interpolation be sufficient |
| 17:16:42 | amiconn | ? |
| 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 | stevenm | 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 | slowdowncadet | grrrrrRRRRRRRR |
| 17:18:37 | slowdowncadet | any particular reason I keep getting booted out of rockbox today? |
| 17:20:11 | slowdowncadet | (i'd love to change my name back to stripwax) |
| 17:20:31 | stevenm | ah.. hello |
| 17:20:36 | | Quit methangas (Read error: 104 (Connection reset by peer)) |
| 17:20:40 | slowdowncadet | did i miss much?/ |
| 17:20:58 | stevenm | just me asking how to even do interpolation |
| 17:21:10 | amiconn | [17:16:16] <amiconn> stripwax: Wouldn't a simple linear interpolation be sufficient |
| 17:21:10 | amiconn | [17:16:16] <amiconn> ? |
| 17:21:20 | slowdowncadet | amiconn - i tried that, it sounded crap |
| 17:21:25 | stevenm | and me contemplating the 'fun' of hexediting random envelope bytes and seeing how that effects the waveform |
| 17:21:40 | slowdowncadet | stevenm - hehe, yeah, i was thinking of trying that too |
| 17:22:03 | stevenm | slowdowncadet, I have a program that displays all the stats.. only graphically, and in terms of percent and milliseconds |
| 17:22:20 | stevenm | tonight... if no EE homework, then I might jump on that. |
| 17:23:22 | stevenm | I know Timidity uses envelopes... and personally I think that makes some things sound like crap |
| 17:23:23 | slowdowncadet | 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 | stevenm | slowdowncadet, ah, I sort of see |
| 17:24:08 | stevenm | slowdowncadet, by the way, sorry if the code and stuff is a little cryptic |
| 17:25:26 | slowdowncadet | 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 | stevenm | slowdowncadet, hmm.. that seems CPU intensive.. could it be done in ASM maybe? |
| 17:26:47 | slowdowncadet | stevenm of course |
| 17:26:52 | stevenm | er, would that work fast enough if it were in ASM |
| 17:27:59 | stevenm | by the way, the new code with the looping, there's some shifts by 9 in there |
| 17:28:08 | slowdowncadet | why 9 |
| 17:28:15 | stevenm | that's just because it's divided by 2 and then shifted by 10 the other way |
| 17:29:16 | stevenm | 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 | stevenm | then multiply by 1024 to get the rest of it |
| 17:29:49 | stevenm | 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 | slowdowncadet | hm, the new version coredumps on startup for me. i'll see if i can figure out what's up |
| 17:31:25 | stevenm | core dump??? that's not good..... |
| 17:31:34 | slowdowncadet | quite |
| 17:31:51 | stevenm | ahh |
| 17:31:53 | stevenm | stupid stupid |
| 17:31:59 | stevenm | comment out the gusload in main |
| 17:32:15 | | Quit Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )") |
| 17:32:32 | stevenm | 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 | bnewhouse | 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 | slowdowncadet | stevenm ok thx |
| 17:33:08 | slowdowncadet | yeah that works |
| 17:33:12 | | Quit stripwax (Read error: 110 (Connection timed out)) |
| 17:33:14 | stevenm | all right, cool |
| 17:33:24 | stevenm | 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 | stripwax | fab |
| 17:33:42 | stevenm | :) |
| 17:35:26 | bnewhouse | can anyone help? :( |
| 17:35:43 | stripwax | oh you changed shifts to 10 bits instead of 11 bits? |
| 17:36:38 | stevenm | stripwax, yea |
| 17:36:43 | Renko | bnewhouse, did you run 'make zip'? |
| 17:36:59 | stevenm | 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 | stripwax | stevenm hm ok |
| 17:37:26 | stevenm | like, it would play them at a low frequency, and it sounds just plain BIZZARE |
| 17:37:33 | stevenm | stripwax, 10 bit solved that |
| 17:37:45 | bnewhouse | 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 | stevenm | stripwax, I'm going to go eat.. then grab bike and go to class |
| 17:44:26 | stripwax | ok i'll be here later |
| 17:44:27 | stevenm | and see if I can manage to not get hit by a car this time :) |
| 17:44:38 | stevenm | later |
| 17:44:56 | | Quit stevenm ("Leaving") |
| 17:45:51 | stripwax | 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 | bnewhouse | 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 | bnewhouse | k, ill take that as a yes... |
| 17:50:48 | Renko | bnewhouse, it's a no ;) |
| 17:51:15 | Renko | you have to do make zip and then copy the rockbox.zip to the iriver and unzip it there |
| 17:51:36 | bnewhouse | haha, k thanks a lot... |
| 17:51:41 | Renko | that should create .rockbox and rockbox.iriver |
| 17:51:48 | bnewhouse | alrighty |
| 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:23 | preglow | now, where's a fireplace when you need one |
| 18:19:53 | | Quit bnewhouse ("Leaving") |
| 18:21:34 | stripwax | 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 | sox | 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 | sox | 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 | Tang | Hello |
| 18:58:26 | Tang | :) |
| 18:58:35 | Tang | Nice progresses :) |
| 18:58:51 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU) |
| 18:58:55 | preglow | idneed |
| 19:00 |
| 19:00:33 | Tang | :) |
| 19:00:38 | Tang | Hi Preglow |
| 19:00:43 | Tang | :) |
| 19:01:17 | Tang | Congrtulate Linus from my part when you see him :) |
| 19:02:39 | *** | Saving seen data "./dancer.seen" |
| 19:03:48 | preglow | 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 | zeekoe | preglow: neat! |
| 19:28:08 | zeekoe | at what speed? |
| 19:28:12 | zeekoe | (MHz) |
| 19:29:16 | preglow | zeekoe: 96 mhyz |
| 19:30:48 | zeekoe | do you have an idea at what speed it will run eventually? |
| 19:31:05 | preglow | no, depends on how much we want to work on it |
| 19:31:28 | preglow | thus far, i'm the only one working on optimizing it for speed |
| 19:31:53 | preglow | but that'll probably change as codecs become the primary focus |
| 19:33:52 | zeekoe | aren't there already optimized mp3 decoders? |
| 19:34:26 | preglow | no, not for coldfire |
| 19:34:37 | zeekoe | hm |
| 19:34:41 | zeekoe | ask iRiver :-P |
| 19:34:44 | preglow | hahaha |
| 19:34:46 | preglow | "yes" |
| 19:34:55 | preglow | but we're doing the work ourselves |
| 19:36:45 | zeekoe | :) |
| 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 | preglow | looks like gcc outputs pretty sub optimal indexing code |
| 20:00 |
| 20:00:08 | stripwax | 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 | preglow | stripwax: well, yes, that's an envelope for you |
| 20:01:27 | stripwax | 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 | preglow | 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 | preglow | 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 | preglow | as far as i can see, it's actually slower |
| 20:47:36 | stripwax | preglow - by 'obvious' I meant that the GUS SDK contains code to do the mapping; ... |
| 20:47:44 | preglow | then hooray! |
| 20:48:38 | | Join thedude02 [0] ([U2FsdGVkX@pm476-01.dialip.mich.net) |
| 20:48:52 | stripwax | 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 | amiconn | 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 | preglow | amiconn: i thought i did |
| 20:52:27 | preglow | i'll look it up |
| 20:53:19 | amiconn | Errata 4 is relevant for doing EMAC stuff |
| 20:53:54 | preglow | yes, i see |
| 20:54:59 | preglow | nothing i need to worry about right now |
| 20:55:09 | preglow | i use one accumulator the whole time, more or less |
| 20:55:42 | preglow | a24 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:58 | amiconn | HCl: r u there? |
| 21:43:04 | pillo | hi all |
| 21:43:32 | pillo | any reasons why the menu_* functions aren't exported via the plugin api? |
| 21:43:54 | amiconn | 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 | pillo | that's a good answer :) |
| 21:44:17 | amiconn | There is no point in exporting unused functions, it only makes the main binary larger |
| 21:45:03 | pillo | i wanted to add a simple menu to the viewer plugin... and found it strange nobody had used them before... |
| 21:45:10 | amiconn | Functions are added to the api as new plugins need them |
| 21:45:24 | pillo | so that's ok if i go on and add them? |
| 21:45:36 | amiconn | Yes. |
| 21:46:00 | pillo | btw, did someone test my viewer patch on archos players/recorders? |
| 21:46:28 | amiconn | 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 | pillo | 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: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:11 | HCl | amiconn: i am now |
| 22:09:17 | | Quit Renko ("Leaving") |
| 22:09:36 | amiconn | HCl: I'm working on a completely new Makefile approach for building rockboy |
| 22:09:42 | HCl | okay |
| 22:09:51 | HCl | i sent you a copy of my version merged with yours earlier today |
| 22:10:04 | amiconn | Yes, saw that. |
| 22:10:06 | HCl | ok :) |
| 22:10:36 | amiconn | Still, I think the first version committed to cvs should be one without dynarec. |
| 22:10:47 | HCl | you can easily disable it |
| 22:10:48 | amiconn | It's unfinished work |
| 22:10:51 | HCl | by taking out the -DDYNAREC |
| 22:10:55 | HCl | in the makefile |
| 22:10:57 | preglow | HCl: you tried rockboy on the faster rockbox? |
| 22:11:02 | HCl | not yet. |
| 22:11:05 | HCl | i haven't had time |
| 22:11:07 | HCl | had a car accident |
| 22:11:14 | preglow | ouch |
| 22:11:14 | HCl | and i finally heard that my sis has cancer today |
| 22:11:27 | preglow | sorry to hear that |
| 22:11:36 | HCl | yea. well. blah. |
| 22:11:44 | coob | not the best of days eh :< |
| 22:11:44 | HCl | no point in worrying or feeling bad about it. |
| 22:11:50 | preglow | well, of course not |
| 22:11:51 | HCl | we'll do the what we can, and we can't do more. |
| 22:11:56 | preglow | if you're able to |
| 22:12:02 | preglow | not all people are |
| 22:12:02 | preglow | heh |
| 22:12:37 | preglow | i'm teaching myself to write whole functions in 68k asm |
| 22:13:41 | preglow | is it possible to have a plugin be several files? |
| 22:13:48 | HCl | look at rockboy |
| 22:13:50 | preglow | i guess that won't work with the SOURCES scheme |
| 22:14:09 | HCl | and ask amiconn since he's working on the makefile for it :x |
| 22:14:10 | preglow | and i can't just include them, the other file is an asm file |
| 22:14:13 | HCl | brb |
| 22:15:12 | amiconn | 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 | amiconn | 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 | preglow | amiconn: sounds great |
| 22:16:57 | preglow | using the frame pointer in asm is ok, yes? |
| 22:17:00 | amiconn | For each of these dirs, the Makefile therein gets called (by the directory being a .PHONY target) |
| 22:17:21 | preglow | well, i'm saving it anyway |
| 22:17:50 | amiconn | 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 | amiconn | 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 | preglow | d0-d1 and a0-a1 |
| 22:19:55 | preglow | can be clobbered |
| 22:20:10 | amiconn | For SH1, r0-r7, macl and mach are considered scratch, r8-r15 and pr must be saved |
| 22:26:18 | preglow | hahah |
| 22:26:21 | preglow | i actually ran out of registers |
| 22:26:36 | preglow | registers are like disk space, i swear |
| 22:26:52 | preglow | i complain i've never get enough, and when i get more, i squander it |
| 22:27:40 | frank | 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 | preglow | frank: you're the second person i've heard talk about this, on which file does it happen? |
| 22:28:33 | frank | calculator.c |
| 22:28:43 | preglow | frank: you aren't the one who mentioned this the other day? |
| 22:29:17 | frank | nope, it tried to built the toolchain yesterday but the binutils-cvs wasn't in a clean state |
| 22:29:50 | frank | would you like a copy of the compiler output? |
| 22:29:54 | preglow | but ok, you're the second person to get an internal error on calculator.c |
| 22:29:57 | preglow | frank: sure, msg it to me |
| 22:30:04 | preglow | so we don't spam the channel full |
| 22:30:58 | frank | LD /home/frank/rockbox/rockbox/build-normal/viewer.elf |
| 22:30:58 | frank | OBJCOPY /home/frank/rockbox/rockbox/build-normal/viewer.elf |
| 22:30:58 | frank | CC bounce.c |
| 22:30:58 | DBUG | Enqueued KICK frank |
| 22:30:58 | frank | LD /home/frank/rockbox/rockbox/build-normal/bounce.elf |
| 22:30:59 | frank | OBJCOPY /home/frank/rockbox/rockbox/build-normal/bounce.elf |
| 22:31:03 | frank | CC calculator.c |
| 22:31:05 | frank | calculator.c: In function `typingProcess': |
| 22:31:09 | frank | calculator.c:1072: error: insn does not satisfy its constraints: |
| 22:31:11 | frank | (insn 356 138 140 24 (nil) (set (reg:QI 9 %a1) |
| 22:31:13 | frank | (mem/f:QI (const:SI (plus:SI (symbol_ref:SI ("n")) |
| 22:31:15 | frank | (const_int 3 [0x3]))) [0 n+3 S1 A8])) 37 {*m68k.md:1060} (nil) |
| 22:31:17 | frank | (nil)) |
| 22:31:19 | frank | calculator.c:1072: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8365 |
| 22:31:21 | frank | Please submit a full bug report, |
| 22:31:23 | frank | with preprocessed source if appropriate. |
| 22:31:25 | frank | See <URL:http://gcc.gnu.org/bugs.html> for instructions. |
| 22:31:27 | frank | make[2]: *** [/home/frank/rockbox/rockbox/build-normal/calculator.o] Error 1 |
| 22:31:29 | frank | 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 | preglow | yes, and this would be the channel :PP |
| 22:31:36 | frank | 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 | frank | make[2]: Leaving directory `/home/frank/rockbox/rockbox/apps/plugins' make[1]: *** [rocks] Error 2 |
| 22:31:43 | frank | sorry |
| 22:31:45 | frank | my fault |
| 22:31:47 | frank | i missed these " |
| 22:31:49 | frank | both of them |
| 22:31:59 | preglow | we'll survive |
| 22:32:16 | preglow | this is gcc 3.4.3? |
| 22:32:33 | frank | did anyone query the gcc-bugzilla concerning this problem? |
| 22:33:03 | preglow | 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 | frank | yes |
| 22:33:21 | preglow | frank: linux? |
| 22:33:27 | frank | i will have a look |
| 22:33:32 | frank | yes |
| 22:33:47 | preglow | well, that works fine for me |
| 22:33:50 | frank | are newer gcc versions useable? |
| 22:33:57 | preglow | there are no newer |
| 22:34:30 | frank | i thought 3.5 was allready released |
| 22:34:46 | kergoth | you mean 4.0? there is no 3.5 |
| 22:34:51 | kergoth | and no, it isnt |
| 22:35:08 | | Join webguest86 [0] (~5002dcd0@labb.contactor.se) |
| 22:35:32 | preglow | will be real fun to see how gcc4 performs |
| 22:36:09 | frank | you're right. i most probably confused it with 3.3.5 |
| 22:36:12 | kergoth | gcc4 is looking really good already, from what i've seen |
| 22:36:33 | preglow | yup |
| 22:47:30 | preglow | hohoh |
| 22:47:44 | preglow | libflac is about to get a super optimized lpc-reconstruction routine |
| 22:50:07 | HCl | nice. |
| 22:50:52 | coob | preglow: /msg normalperson about his flac optimisations |
| 22:51:18 | coob | he did some stuff for mpd/libflac |
| 22:53:03 | | Join [IDC]Dragon [0] (~Joerg@pD9512BB1.dip.t-dialin.net) |
| 22:53:51 | preglow | mpd? |
| 22:54:01 | amiconn | hi Jörg :) |
| 22:54:08 | amiconn | ltnirc |
| 22:54:10 | [IDC]Dragon | Hi Jens |
| 22:54:33 | amiconn | There are 2 proposals for a flash icon now :) |
| 22:54:41 | [IDC]Dragon | aha? |
| 22:55:22 | amiconn | amiconn.dyndns.org/MMC.jpg">http://amiconn.dyndns.org/MMC.jpg and http://amiconn.dyndns.org/MMC_klein.jpg |
| 22:55:37 | coob | preglow: music player daemon |
| 22:55:48 | coob | ..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 | amiconn | 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 | amiconn | 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 |
| 23:00:02 | amiconn | yup |
| 23:01:32 | [IDC]Dragon | flash - ah - saviour of the universe |
| 23:02:05 | coob | spooky |
| 23:02:10 | coob | 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 | preglow | that klein version really is klein |
| 23:02:48 | *** | Saving seen data "./dancer.seen" |
| 23:02:51 | stripwax | ello |
| 23:03:06 | stripwax | guess i was kicked off sometime while eating dinner |
| 23:04:46 | amiconn | 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 | amiconn | 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 | amiconn | The region flash is full for quite some more time.... |
| 23:08:21 | [IDC]Dragon | rombox has almovst ever been full |
| 23:08:44 | preglow | amiconn: got a fast way for me to link two files to one plugin? |
| 23:09:03 | amiconn | 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 | preglow | amiconn: ahh, i thought it wasn't due for some time yet |
| 23:09:50 | amiconn | [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 | webguest18 | frank: I was looking at the irc log. I get the same error as you compiling the normal build |
| 23:11:45 | webguest18 | using gcc 3.3.4 |
| 23:14:13 | frank | webguest18: i admit i did the same. i'm just building a gcc 3.4.3... |
| 23:15:09 | webguest18 | frank: ahh, ok. That may work better |
| 23:16:23 | [IDC]Dragon | amiconn, I'll put that MMC flash icon in? |
| 23:16:38 | webguest18 | frank: I check the logs later on to see if you get it working |
| 23:16:48 | frank | ok |
| 23:16:50 | webguest18 | bye |
| 23:16:54 | | Part webguest18 |
| 23:17:29 | preglow | 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 | amiconn | [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:01 | preglow | how i hate makefiles |
| 23:32:07 | preglow | so plugins are just plain bin images? |
| 23:32:09 | [IDC]Dragon | amiconn: your icon is 8 pixels tall :-( |
| 23:32:27 | amiconn | Yes. Why is that a problem? |
| 23:32:37 | amiconn | preglow: They are on the target |
| 23:32:54 | preglow | 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 | amiconn | Ooops... didn't notice |
| 23:33:28 | preglow | 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 | preglow | but i guess that isn't too big a bother |
| 23:34:36 | preglow | 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 | amiconn | You first need to link the two .o's to an .elf, like with the other plugins |
| 23:35:22 | preglow | ahh, bah |
| 23:35:25 | preglow | 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 | frank | 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 | preglow | frank: ok, i still can't understand why it'd crash, though, but i guess it's irrelevant |
| 23:43:55 | frank | is the bootloader target expected to built out of the box? |
| 23:45:26 | preglow | frank: well, yes |
| 23:45:33 | preglow | frank: but i'd advice against building it yourself |
| 23:46:01 | [FlaT]Heidel | huh? |
| 23:46:11 | frank | ok, i was just test driving my enviroment |
| 23:46:11 | [FlaT]Heidel | sorry, wrong window |
| 23:46:40 | preglow | 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 | frank | ok, thanks for the help. |
| 23:49:04 | amiconn | [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) |
icon identifies that the person is a core developer (has commit access).