| 00:00:00 | Digital007 | i just wondered how the sound progress for iriverbox is coming on |
| 00:00:00 | LinusN | yup |
| 00:00:07 | hubble | oki.. great |
| 00:00:14 | XShocK | LinusN: where did you get that 54? |
| 00:00:30 | LinusN | dma0 is the 54th vector in system.c |
| 00:00:32 | ashridah | Digital007: we gave up because someone forgot to bring cookies |
| 00:00:40 | Digital007 | what? |
| 00:00:46 | Digital007 | why do u need cookiues for? |
| 00:00:57 | Bagder | to munch! |
| 00:01:00 | hubble | Digital007: he was not answering your question with 54 =) |
| 00:01:12 | Digital007 | i thhought u meant cookies as web code cookies |
| 00:01:35 | ashridah | what would http cookies have to do with embedded development/ |
| 00:01:37 | ashridah | ? |
| 00:01:44 | LinusN | omg |
| 00:01:46 | Digital007 | would be great to have MP3Pro as a codec as well |
| 00:02:35 | hubble | hehe |
| 00:02:48 | LinusN | gotta sleep, happy dma:ing |
| 00:02:54 | Digital007 | MP3Pro sounds much better than WMA and almost as good as normal MP3 |
| 00:02:55 | HCl | whats the dma for? |
| 00:03:02 | LinusN | feeding the dac |
| 00:03:05 | HCl | ok |
| 00:03:09 | | Part LinusN |
| 00:03:23 | | Join Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de) |
| 00:03:37 | HCl | amiconn: any progress? |
| 00:03:37 | XShocK | hubble: did you understand where this 54 came from? I don't see anything like that in system.c |
| 00:03:52 | amiconn | HCl: Currently rewriting makefile... |
| 00:03:54 | Digital007 | i thought the sound was 54% doen |
| 00:03:55 | Digital007 | done |
| 00:03:55 | HCl | okies.. |
| 00:04:10 | preglow | what does flac require 64 bit numbers for? 32x32 muls? |
| 00:04:34 | Bagder | preglow: he mentioned something more in that forum thread, I closed that tab ;-) |
| 00:05:16 | hubble | XShocK: if you count the index in irqname[] to DMA0 i guess that's 54 |
| 00:06:07 | | Quit skav (Read error: 54 (Connection reset by peer)) |
| 00:06:14 | hubble | XShocK: but i'm not sure where DMA0 is defined |
| 00:06:27 | XShocK | ok. |
| 00:06:43 | XShocK | i guess this: default_interrupt (DMA0); /* DMA 0 */ |
| 00:06:57 | XShocK | and then i think you shoud put you own implementation |
| 00:07:34 | preglow | we probably should use the emac for as much as possible anyway, so we might not be affected by all the 64 bit stuff |
| 00:07:44 | hubble | XShocK: aa.. default_interrupt macro expands it into a function definition |
| 00:08:07 | | Join fubar [0] (alan@moonfish.org.uk) |
| 00:08:14 | hubble | XShocK: and then the .vectors array contains the function call |
| 00:08:22 | hubble | s/call/pointer |
| 00:09:03 | XShocK | .vectors array? |
| 00:09:26 | preglow | Bagder: i can't imagine why they'd need 64 bit variables other than to do 32x32 muls |
| 00:09:26 | preglow | Bagder: and the emac does that for us |
| 00:10:05 | XShocK | hmmm |
| 00:10:20 | Bagder | he said this "FLAC supports up to 32-bits per sample losslessly which means there are a lot of 64-bit datapaths. and the seeking and metadata interfaces that work with 64-bit sample number are numerous." |
| 00:10:35 | | Join mrmags [0] (~stryfe@ool-4351b9f0.dyn.optonline.net) |
| 00:10:53 | Digital007 | support WMA Lossless!!!!!! |
| 00:11:29 | ashridah | why? |
| 00:11:54 | | Quit Digital007 ("CGI:IRC (EOF)") |
| 00:12:11 | HCl | oh, and get rockbox to make coffee!! ;p |
| 00:12:15 | | Join Digital007 [0] (~acd5e828@labb.contactor.se) |
| 00:12:18 | preglow | Bagder: the latter part shouldn't be that much of a problem, i think |
| 00:12:23 | Digital007 | WMA Lossless - WAV quality at half the file size |
| 00:12:34 | preglow | Digital007: Flac - WAV quality at half the file size |
| 00:12:49 | preglow | Digital007: there's no way for us to support wma lossless, afaik ms has not released specs |
| 00:13:02 | Digital007 | ok |
| 00:13:38 | preglow | hrmf |
| 00:16:43 | fubar | I know xine supports wma, but I'm not sure if it uses the win32 codec |
| 00:17:51 | preglow | wma, yes, but does it support wma lossless? |
| 00:18:08 | preglow | ffmpeg has a wma decoder, but there are quite a lot of wma versions around |
| 00:21:04 | rasher | it probably uses the win32 codec anyway |
| 00:21:20 | rasher | also, there's not that much lost in not supporting lossless formats |
| 00:21:25 | rasher | people can always convert :) |
| 00:21:33 | Bagder | very true |
| 00:22:11 | Digital007 | Aren't there licencing issues to worry about if ur writing software codecs? |
| 00:22:36 | Bagder | not worry, but we need to adhere |
| 00:22:41 | Digital007 | ok |
| 00:22:42 | coob | ffmpeg has a fpoint wma decoder |
| 00:22:54 | Digital007 | I've noticed that the battery meter always flashes empty even on a fully charged iRiver |
| 00:23:18 | amiconn | Bah, obviously I don't fully understand 'make' yet |
| 00:23:32 | amiconn | make[3]: *** No rule to make target `/home/Administrator/rb-gameboy/build/recorder/rockboy/cpu.o', n |
| 00:23:32 | amiconn | eeded by `/home/Administrator/rb-gameboy/build/recorder/rockboy/rockboy.elf'. Stop. |
| 00:23:37 | rasher | Digital007: that's "covered" in the wiki |
| 00:23:42 | Digital007 | k |
| 00:24:00 | rasher | battery level detection isn't done yet |
| 00:24:14 | amiconn | The rule should be covered by including make.inc ... |
| 00:25:16 | | Quit ashridah (Read error: 60 (Operation timed out)) |
| 00:25:33 | Bagder | check the depfile |
| 00:26:00 | amiconn | Hmm. It didn't build one. |
| 00:26:03 | Bagder | but I agree, it should be covered by that rule |
| 00:26:36 | amiconn | In fact, this should be in builddir/rockboy/ or may this not work, i.e. the dir not yet created (??) |
| 00:27:22 | amiconn | Hmm. Still not created... How is the depfile supposed to be created? |
| 00:27:43 | Bagder | SOURCES must contain all C sources |
| 00:27:56 | Bagder | C and asm actually |
| 00:28:15 | amiconn | This variable must be called exactly SOURCES ? |
| 00:28:18 | Bagder | yes |
| 00:28:21 | Bagder | make.inc uses that |
| 00:28:30 | amiconn | Ah, then this is the problem... |
| 00:29:38 | Bagder | the include line makes make check the depfile dependency and thus rebuild |
| 00:29:58 | amiconn | Now the depfile is there, but I still get the same error... |
| 00:30:08 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
| 00:31:32 | amiconn | Hmm, the depfile lists cpu.o in the wrong dir |
| 00:32:01 | amiconn | It wants it in builddir/ while I intend to have it in builddir/rockboy/ |
| 00:32:09 | amiconn | Is that possible? |
| 00:32:40 | Bagder | it is, the recorder/ and driver/ etc are treated that way |
| 00:33:06 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") |
| 00:33:29 | amiconn | Yeah... but in these directories there is no separate Makefile. These are handled in the Makefile of the parent dir |
| 00:33:48 | Bagder | yes |
| 00:33:55 | Bagder | that's true |
| 00:34:48 | Bagder | ... its not very easily done atm, I think |
| 00:34:57 | | Quit CoCoLUS () |
| 00:36:30 | amiconn | Hmm. if I redefine $(OBJDIR) within the Makefile, would this work? |
| 00:37:01 | Bagder | yes, that should work |
| 00:37:54 | Bagder | I've been planning to move all object files into subdirs better |
| 00:38:19 | Bagder | like you do now |
| 00:39:02 | HCl | yea, every plugin should have its own subdir, really.. imho.. |
| 00:39:06 | HCl | but ok, i'm gonna go sleep.. |
| 00:39:32 | Bagder | one subdir for each would be overkill |
| 00:39:57 | Bagder | having the ability to have one, yes |
| 00:40:06 | HCl | yea, ok. |
| 00:42:14 | | Join ashridah [0] (ashridah@220-253-118-175.VIC.netspace.net.au) |
| 00:47:14 | * | HCl suddenly discovers the existence of a rockbox forum |
| 00:47:26 | | Join bagawk [0] (~Lee@bagawk.user) |
| 00:47:45 | coob | heh you don't want to go near those things :X |
| 00:47:53 | amiconn | Bagder: Redefining the variable doesn't work... |
| 00:48:01 | coob | noob support city :< |
| 00:48:38 | HCl | lol |
| 00:48:59 | | Quit DMJC ("Leaving") |
| 00:49:38 | rasher | it's not that bad really |
| 00:49:49 | rasher | just not of much use either |
| 00:49:55 | Bagder | I need to sleep. If you don't get any further amiconn, I'll help you sort that out tomorrow |
| 00:50:02 | coob | heh maybe not on rockbox ones... don't look in the ipl ones :< |
| 00:50:28 | amiconn | Bagder: Np, thanks for your help. Good night |
| 00:50:46 | rasher | Well these are people who bought ipods, what did you expect? :) |
| 00:53:08 | | Join linuxstb [0] (~linuxstb@dsl-212-23-31-215.zen.co.uk) |
| 00:53:21 | coob | are you saying all ipod users are thick? |
| 00:53:56 | HCl | ipl? |
| 00:54:02 | coob | ipod linux... |
| 00:54:07 | HCl | oh |
| 00:54:10 | HCl | :p |
| 00:54:12 | rasher | nope, but I'm rather guessing a lot are |
| 00:54:18 | coob | yeah well you'd be right :( |
| 00:54:29 | | Quit bagawk ("Leaving") |
| 00:55:50 | coob | (about a lot.. not all heh) |
| 00:56:51 | *** | Saving seen data "./dancer.seen" |
| 00:57:56 | rasher | Well it was a generalization - those rarely fit everyone :) |
| 00:58:20 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 00:58:28 | HCl | yea, you can't make a generalization without allowing room for exeptions |
| 00:59:02 | | Join DrRick [0] (DrRick@81-86-80-158.dsl.pipex.com) |
| 01:00 |
| 01:03:37 | | Join Quelsaruk [0] (~kvirc@80.103.134.240) |
| 01:03:42 | Quelsaruk | i'm back |
| 01:03:43 | Quelsaruk | :) |
| 01:13:32 | HCl | ohno! :p |
| 01:13:37 | HCl | hi :p |
| 01:13:42 | Quelsaruk | :P |
| 01:14:49 | * | HCl goes to sleep :p |
| 01:14:54 | Quelsaruk | nite |
| 01:15:50 | | Quit DrRick () |
| 01:22:22 | | Part mrmags |
| 01:25:12 | | Quit lolo-laptop ("Client exiting") |
| 01:25:52 | | Quit _aLF ("Leaving") |
| 01:26:22 | | Join kramerica [0] (~lkd@hsdbsk142-165-191-185.sasknet.sk.ca) |
| 01:29:38 | | Quit preglow ("off") |
| 01:32:36 | | Quit Patr3ck (Read error: 54 (Connection reset by peer)) |
| 01:36:59 | | Quit hubble () |
| 01:39:21 | Quelsaruk | night! |
| 01:39:41 | | Quit Quelsaruk ("KVIrc 3.0.1.99 'Realia'") |
| 01:52:04 | amiconn | yay! Makefile is working! |
| 01:52:04 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
| 01:57:51 | HCl | :) |
| 01:57:57 | HCl | but i'm asleep *nods* |
| 02:00 |
| 02:00:55 | | Quit Sucka ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 02:06:43 | * | HCl tries amiconn 's lcd driver for iriver |
| 02:06:51 | HCl | amiconn: do you have an iriver? |
| 02:06:58 | HCl | amiconn: made any pics of rockboy on archos yet? |
| 02:07:00 | amiconn | nope |
| 02:07:17 | amiconn | I tried making pics, but my batteries died again :( |
| 02:07:33 | amiconn | Does the lcd driver work? |
| 02:10:22 | amiconn | Btw, I renamed iriver.c to sys_rockbox.c |
| 02:10:25 | HCl | it works |
| 02:10:33 | HCl | it doesn't seem to be that much faster |
| 02:10:37 | HCl | still about 1 fps |
| 02:10:48 | HCl | but every bit helps, really |
| 02:10:51 | | Join muz [0] (~54091287@labb.contactor.se) |
| 02:11:13 | muz | hey is it possible to play files from the tag database right now? |
| 02:11:47 | | Quit Digital007 ("CGI:IRC (Ping timeout)") |
| 02:14:23 | amiconn | muz: On ajb it is. |
| 02:14:34 | muz | archos jukebox? |
| 02:14:45 | amiconn | yup |
| 02:14:55 | muz | it says on the wiki that u can only browse |
| 02:15:10 | amiconn | Then the wiki is out of date |
| 02:15:22 | muz | oh right |
| 02:15:46 | muz | is there any disadvantage in using the tag database (ie longer boot time as on iriver firmwar) |
| 02:16:39 | amiconn | I didn't test much, because my mp3 collection is well organised, but from the few tests I did I had the impresion it is slightly slower than file browsing |
| 02:17:19 | muz | but it still does things like accelerated scrolling, so one can navigate through lists quickly |
| 02:17:29 | muz | right? |
| 02:17:38 | amiconn | yup |
| 02:17:52 | muz | thats so cool |
| 02:19:11 | muz | how is linus getting along with the clock speed of the iriver? |
| 02:19:45 | amiconn | I have no idea. |
| 02:20:11 | muz | anyway thanks im gonna head off now |
| 02:20:28 | | Quit muz ("CGI:IRC") |
| 02:20:36 | HCl | well. at least interrupts seem easyish on z80 |
| 02:20:59 | amiconn | Did you have a look at the cpu core emu? |
| 02:21:39 | HCl | well, yea, but thats mostly gobbilygook, with gotos and too many defines, so i'm reading technical data |
| 02:21:44 | HCl | http://www.work.de/nocash/pandocs.htm#gameboytechnicaldata |
| 02:21:57 | HCl | apparently, there are only 5 interrupts |
| 02:22:06 | HCl | video, lcd stat thingy, timer, serial and joypad |
| 02:22:52 | HCl | and with dynarec, the biggest trouble is timing the interrupts right, really |
| 02:22:59 | HCl | cause you get blocks of code |
| 02:23:10 | HCl | that can't really stop execution |
| 02:23:14 | HCl | in the middle |
| 02:23:17 | HCl | to allow for an interrupt |
| 02:24:03 | amiconn | Hmm. I don't really know about how dynarec is implemented, and don't have the time to also deal with that, at least not atm. |
| 02:24:10 | HCl | its fine :) |
| 02:24:17 | HCl | i'm mostly waiting for linus to get it to 140mhz |
| 02:24:19 | HCl | see how it runs then |
| 02:24:23 | HCl | then start on dynarec |
| 02:24:40 | amiconn | Dynarec might be helpful on archos.... but it's a different cpu |
| 02:24:48 | HCl | yea. |
| 02:24:56 | HCl | but dynarec is fairly easy to port |
| 02:25:11 | HCl | you just get things like void Z80_ADD_OPCODE() { } |
| 02:25:25 | HCl | and you have to fill in the proper m68k assembly for it |
| 02:25:46 | HCl | i'm not really gonna do any advanced optimalization. |
| 02:25:54 | HCl | just chaining them together should provide more than enough speed |
| 02:26:08 | HCl | but ok |
| 02:26:09 | HCl | sleeeep. |
| 02:26:11 | HCl | darnit |
| 02:26:12 | HCl | >.< |
| 02:26:14 | amiconn | The makefile seems to work properly now. The next things I'l do are |
| 02:26:22 | HCl | i promised my gf i'd go to sleep early, and again i haven't yet :( |
| 02:26:26 | HCl | mm? |
| 02:26:34 | | Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) |
| 02:26:57 | coob | heh gnuboy runs better on os x than the normal os x emulators |
| 02:27:01 | coob | well, that's without sound |
| 02:27:01 | amiconn | (1) Write that loader plugin to allow rockboy for archos to run on unmodified rockbox (32 KB 'normal' plugin ram) |
| 02:27:10 | HCl | mhm |
| 02:27:20 | amiconn | (2) Trash those darn warnings |
| 02:27:24 | HCl | heheh |
| 02:27:25 | amiconn | (3) Commit to cvs |
| 02:27:28 | HCl | yay. |
| 02:27:46 | amiconn | ..but all that has to wait due to sleep needed. |
| 02:28:10 | amiconn | Nite. |
| 02:28:14 | HCl | night |
| 02:28:30 | | Part amiconn |
| 02:28:31 | | Quit edx (Read error: 110 (Connection timed out)) |
| 02:42:00 | | Quit toolmanwv (Read error: 54 (Connection reset by peer)) |
| 02:42:18 | | Join toolmanwv [0] (~aaa@pool-70-18-122-238.buff.east.verizon.net) |
| 02:49:32 | | Quit coob (Read error: 60 (Operation timed out)) |
| 02:56:53 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:01:28 | | Quit toolmanwv ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") |
| 03:03:58 | | Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 03:05:08 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
| 03:30:26 | | Quit skav () |
| 03:36:46 | | Quit Aison (Read error: 104 (Connection reset by peer)) |
| 04:00 |
| 04:05:42 | | Join QT_ [0] (as@area51.users.madwifi) |
| 04:07:45 | | Join edx [0] (edx@p54879BA1.dip.t-dialin.net) |
| 04:09:01 | | Quit QT (Read error: 60 (Operation timed out)) |
| 04:15:59 | | Join mrmags [0] (~stryfe@ool-4351b9f0.dyn.optonline.net) |
| 04:21:48 | | Quit cYmen_ ("leaving") |
| 04:30:00 | | Part mrmags |
| 04:46:40 | | Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- Leading Edge IRC") |
| 04:56:57 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:56:59 | *** | No seen item changed, no save performed. |
| 07:00 |
| 07:23:33 | | Join pilled [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 07:30:03 | | Quit mecraw () |
| 07:39:35 | | Join kramerica [0] (~lkd@hsdbsk142-165-191-185.sasknet.sk.ca) |
| 07:42:57 | | Quit pill (Read error: 110 (Connection timed out)) |
| 07:42:58 | | Nick pilled is now known as pill (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr) |
| 07:57:04 | | Join Patr3ck [0] (~patr3ck@pD9ECFF37.dip.t-dialin.net) |
| 07:57:05 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
| 08:00 |
| 08:02:22 | | Quit Hohoman ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 08:09:10 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 08:47:27 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 08:56:08 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
| 08:57:01 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:04:05 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 09:04:38 | Bagder | LinusN: no M3 yet? |
| 09:04:48 | LinusN | nope |
| 09:05:16 | Bagder | strange, its supposed to be in stores the 22nd |
| 09:05:24 | LinusN | yup |
| 09:10:04 | | Nick Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59) |
| 09:13:01 | LinusN | man, calculating all this clock timing is tedious... |
| 09:13:44 | Bagder | I figure that |
| 09:15:48 | ashridah | m3? you mean the other coldfire based mp3/ogg/flac player? |
| 09:15:58 | Bagder | no, its a swedish magazine |
| 09:16:01 | Bagder | paper version |
| 09:16:06 | ashridah | ah |
| 09:16:28 | Bagder | there just might be something about Rockbox is this upcoming issue |
| 09:18:23 | dwihno | :O |
| 09:18:44 | ashridah | nice |
| 09:18:59 | ashridah | is it in english or swedish? |
| 09:19:04 | Bagder | swedish |
| 09:19:55 | Bagder | we were interviewed for the article before xmas |
| 09:20:27 | dwihno | what did you say? |
| 09:21:05 | Bagder | we talked about Rockbox, what it is, how it started, what we do, who we are and what we are doing atm |
| 09:21:11 | dwihno | What if, the JoS players would use rockbox? ;) |
| 09:21:46 | Bagder | then of course, atm == late dec, which meant no working iRiver version |
| 09:21:49 | ashridah | JoS? |
| 09:21:57 | | Join markun [0] (~markun@bastards.student.utwente.nl) |
| 09:22:05 | markun | good morning |
| 09:22:16 | Bagder | ashridah: "Jens of Sweden" I guess |
| 09:22:26 | Bagder | a brand of flash-based players |
| 09:22:33 | ashridah | ah |
| 09:22:41 | markun | I'm working on vorbis2wav but I have some problems.. |
| 09:23:29 | ashridah | markun: such as? |
| 09:23:43 | markun | I want to use the vorbisfile interface to decode a file, but when I link the plugin to libTremor I get this: |
| 09:23:46 | markun | /usr/home/karl/tmp/src/rockbox/rockbox-commit/apps/codecs/Tremor/vorbisfile.c:772: undefined reference to `read' |
| 09:25:14 | markun | Is there a way libTremor can read the file? |
| 09:25:59 | Zagor | you need to use the plugin api |
| 09:27:43 | Bagder | check Dave's plugins for the other codecs |
| 09:28:02 | markun | I got some inspiration from his code. |
| 09:30:13 | | Quit ashridah (Nick collision from services.) |
| 09:30:28 | | Join ashridah [0] (ashridah@220-253-120-220.VIC.netspace.net.au) |
| 09:30:40 | ashridah | @#$%^@$%^@!@#$%@%^#%^&* ! damned power just flickered :/ |
| 09:34:16 | | Join bobTHC [0] (~foo@l03m-38-210.d1.club-internet.fr) |
| 09:35:20 | bobTHC | morning all! |
| 09:35:27 | Bagder | morning |
| 09:38:06 | | Quit ashridah ("ircII EPIC4-2.0 -- Are we there yet?") |
| 09:38:29 | | Join ashridah [0] (ashridah@220-253-120-220.VIC.netspace.net.au) |
| 09:38:43 | ashridah | oops. |
| 09:42:11 | | Join webguest34 [0] (~c31ce021@labb.contactor.se) |
| 09:44:38 | markun | I tried to pass the plugin_api struct to the codec so it can user rb->open, when I include <plugin.h> in vorbisfile.c I get these errors: |
| 09:44:49 | markun | firmware/export/system.h:161: error: parse error before "unsigned" |
| 09:45:19 | markun | The plugins which also have <plugin.h> compile fine. |
| 09:55:47 | LinusN | i don't think the codecs will have the same plugin api as the regular plugins |
| 09:56:22 | Zagor | no, but it's a start |
| 09:56:27 | LinusN | and i also don't think they should need file access |
| 09:59:17 | markun | I agree, but I just wanted to do a quick test to see if decoding worked. |
| 10:00 |
| 10:00:28 | LinusN | isn't that supposed to be done by the xxx2wav.rock plugins? |
| 10:00:54 | * | LinusN hasn't been involved in the codec stuff |
| 10:01:27 | Bagder | markun is working on such a xxx2wav.rock |
| 10:01:34 | LinusN | aha |
| 10:01:35 | Bagder | xxx being vorbis |
| 10:01:35 | markun | yes, I'm working on vorbis2wav.rock |
| 10:05:50 | LinusN | but then only the .rock file should include plugin.h, and the file i/o should be done there |
| 10:06:47 | LinusN | and then use memory buffers to pass data to and from the codec |
| 10:07:14 | LinusN | or am i out in the blue here? |
| 10:07:35 | Bagder | no, I agree with you |
| 10:08:14 | * | Bagder tries to build a h100 sim with gcc 3.3 |
| 10:08:19 | Bagder | no work |
| 10:08:25 | Bagder | cc1: error: invalid parameter `large-function-insns' |
| 10:08:56 | Bagder | not sure what the best approach to this is |
| 10:11:36 | LinusN | no sim-specific makefile defines? |
| 10:12:00 | Bagder | I guess I could do that, but this isn't sim-specific |
| 10:12:11 | Bagder | this is gcc 3.3 vs 3.4 |
| 10:12:26 | LinusN | no, someone might use a 3.3 cross compiler as well |
| 10:12:48 | Bagder | I'll do some magic in configure and set a variable |
| 10:13:01 | LinusN | gcc −−version |
| 10:13:05 | Bagder | yes |
| 10:14:00 | | Nick QT_ is now known as QT (as@area51.users.madwifi) |
| 10:14:15 | Bagder | configure is changed a lot in my new build stuff anyway |
| 10:15:03 | | Join amiconn [0] (~jens@pD9E7F6F9.dip.t-dialin.net) |
| 10:18:24 | | Quit ashridah ("Reconnecting") |
| 10:18:40 | | Join ashridah [0] (ashridah@220-253-120-220.VIC.netspace.net.au) |
| 10:19:35 | ashridah | i am so over these power flickers |
| 10:22:47 | Bagder | amiconn: any success with your build? |
| 10:26:29 | amiconn | yup |
| 10:26:39 | Bagder | goodie |
| 10:26:50 | amiconn | I had to use 'override' to redefine the variable within the Makefile |
| 10:27:43 | | Join Quelsaruk [0] (~kvirc@80.103.134.240) |
| 10:27:48 | Quelsaruk | morning to all |
| 10:28:24 | markun | morning |
| 10:30:23 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 10:31:54 | amiconn | HCl: there? |
| 10:32:21 | Bagder | amiconn: aha |
| 10:34:58 | [IDC]Dragon | 2 days ago I saw the idea of treating the playback bitswap as a "codec", I like that |
| 10:35:11 | Zagor | i don't |
| 10:35:15 | Bagder | I like that |
| 10:35:45 | Zagor | it will cause more complex code and less battery life. for what? |
| 10:35:46 | [IDC]Dragon | makes the bitswap indepent of the buffer handling |
| 10:36:07 | Bagder | Zagor: one playing system regardless of target |
| 10:36:12 | [IDC]Dragon | and opens the door to "trick modes" |
| 10:36:31 | Bagder | I don't think it'll be more complex |
| 10:36:49 | Bagder | I think it'll in fact be simpler |
| 10:36:52 | [IDC]Dragon | I don't think it will affect battery life |
| 10:37:07 | [IDC]Dragon | we have to bitswap anyway |
| 10:37:49 | Zagor | splitting the buffer means we cannot load as big part of the file in ram |
| 10:38:05 | [IDC]Dragon | plus, with the new approach we bitswap on demand, just what's really played |
| 10:38:33 | [IDC]Dragon | the swapped buffer can be very small |
| 10:38:44 | [IDC]Dragon | just covering for our latencies |
| 10:38:44 | amiconn | Zagor: I think that will be neglectible. Imho the hw format playback buffer should be <64 KB |
| 10:39:07 | Bagder | I think the benefits outweighs the downsides |
| 10:39:26 | Zagor | the only benefit is aesthetical, as far as i see |
| 10:39:31 | amiconn | LinusN: Regarding your concern that searching for mp3 frame headers on archos will affect battery life because of cpu usage: If done efficiently, it should be possible to search the whole buffer in less than 2 secs cpu time |
| 10:39:46 | amiconn | Zagor: There are more benefits |
| 10:40:09 | [IDC]Dragon | we don't have to track headers all the time, only when pausing/skipping |
| 10:40:36 | Zagor | amiconn: such as? |
| 10:41:05 | | Quit MO-Pantsu (Read error: 110 (Connection timed out)) |
| 10:41:07 | Bagder | grr, there's no 'if > variable' in makefiles |
| 10:42:02 | ashridah | Bagder: use the result from /bin/[ ? |
| 10:42:05 | [IDC]Dragon | 1) uniform architecture 2) no swap thread 3) probably simpler code 4) trick modes feasible (FF/FR, etc.) |
| 10:42:06 | LinusN | counting frames has the obvious benefit of displaying the correct playtime |
| 10:42:17 | ashridah | assuming you can test success/fail of a command |
| 10:42:24 | LinusN | "probably simpler code"? |
| 10:42:46 | [IDC]Dragon | I don't consider the current mpeg code simple |
| 10:42:49 | Bagder | ashridah: yes, possibly. I'll try... |
| 10:42:51 | Zagor | "no swap thread" no, because we call it "codec thread" instaed |
| 10:43:06 | [IDC]Dragon | but that's negotiable ;-) |
| 10:43:26 | | Quit markun () |
| 10:43:28 | [IDC]Dragon | currently we have mpeg and swap thread |
| 10:43:41 | Bagder | LinusN: simpler since it would be one way of playing instead of two, as we would need this system anyway for non-MAS players |
| 10:43:49 | amiconn | [IDC]Dragon: ??? Iirc the mpeg thread also handles swapping |
| 10:43:51 | Zagor | what are these "trick modes"? |
| 10:44:01 | [IDC]Dragon | it does? sorry then |
| 10:44:02 | amiconn | FF/FR with sound |
| 10:44:12 | Zagor | why would that be easier with unswapped data? |
| 10:44:40 | [IDC]Dragon | there's no mixture of swapped and unswapped in the buffer |
| 10:44:43 | amiconn | No because of being unswapped, but because of having those 2 buffers |
| 10:44:45 | LinusN | Bagder: the iriver will not have swapping |
| 10:44:55 | Bagder | no, but codecs |
| 10:45:00 | Zagor | amiconn: why is that easier? |
| 10:45:35 | [IDC]Dragon | currently, trick modes would need to take swapped/unswapped into account |
| 10:45:44 | amiconn | My idea was to always give whole frames to the codec on all architectures, with 'codec' on archos being the swap |
| 10:46:05 | amiconn | So this allows for easy skipping of frames |
| 10:46:16 | LinusN | at least forward |
| 10:46:19 | [IDC]Dragon | I don't think we need to go that far |
| 10:46:25 | LinusN | backwards is another matter |
| 10:46:30 | [IDC]Dragon | but it's an option |
| 10:46:48 | * | LinusN is switching between 40MHz and 140MHz on his iriver |
| 10:46:51 | amiconn | Backwards would need a bit more cpu power, because in needs to search by brute force |
| 10:47:08 | Bagder | LinusN: cool! |
| 10:47:33 | amiconn | Forward can use the calculated frame length, as long as there is no sync error |
| 10:47:51 | Zagor | vbr? |
| 10:47:59 | [IDC]Dragon | for FF/FR in mp3, we need to modify the frames a bit, to strip the bit reservoir |
| 10:48:55 | amiconn | Zagor: What's the problem with vbr? You read the farme header, and calculate the frame length from the bitrate & padding etc. Then you know where the next frame should start |
| 10:48:59 | [IDC]Dragon | the Archos guys did that, with the SH |
| 10:49:15 | [IDC]Dragon | for the Oskar |
| 10:49:40 | [IDC]Dragon | (anchestor of the the JBR) |
| 10:49:50 | amiconn | [IDC]Dragon: ??? Modify the frame? I can't imagine how this is supposed to work... |
| 10:49:51 | dwihno | there were archoses before jbr? |
| 10:50:09 | LinusN | dwihno: oskar was a project for an electronics magazine iirc |
| 10:50:32 | LinusN | an mp3 player very similar to the jb |
| 10:50:46 | [IDC]Dragon | insert a dummy frame which contains just the bit reservoir, iirc |
| 10:50:47 | LinusN | or rather, jb is very similar to oskar |
| 10:50:54 | dwihno | aah |
| 10:50:55 | dwihno | okay |
| 10:51:18 | [IDC]Dragon | LinusN: almost, it appeared in a magazin (I have that issue), but existed before |
| 10:51:38 | [IDC]Dragon | do you want to hear the JBR history? |
| 10:52:32 | [IDC]Dragon | it started as a diploma thesis of 2 students at the TU Darmstadt |
| 10:53:05 | [IDC]Dragon | they build a box with a CD rom drive, the SH CPU and the MAS decoder |
| 10:53:37 | amiconn | [IDC]Dragon: How? Iiuc the bit reservoir is backward refence, i.e. a frame that needs some more bits can use unused bits from the previous frame. Such a frame cannot be decoded properly without that previous frame. |
| 10:54:21 | [IDC]Dragon | amiconn: the idea is to insert an extra frame to resolve this |
| 10:54:38 | [IDC]Dragon | then you have a clean cut point |
| 10:55:10 | amiconn | You would have to insert a frame containing the reservoir bits *before* the first frame. |
| 10:55:34 | LinusN | why is this even necessary? |
| 10:55:50 | [IDC]Dragon | because else it sound bad |
| 10:55:58 | LinusN | "bad"? |
| 10:56:15 | LinusN | when will it sound bad? |
| 10:56:20 | [IDC]Dragon | clicks from stream errors |
| 10:56:29 | LinusN | dropouts, yes |
| 10:56:33 | amiconn | [IDC]Dragon: The question is: where do you get the reservoir bits from? They are unknown as long as you don't have acces to the previous frame. |
| 10:57:05 | *** | Saving seen data "./dancer.seen" |
| 10:57:10 | [IDC]Dragon | amiconn: yes, if you want to skip, you'll have to start paing attention to the bit reservoir |
| 10:57:55 | amiconn | Yeah.. I mean, how? |
| 10:58:04 | amiconn | Iirc mp3 is huffman coded... |
| 10:58:29 | [IDC]Dragon | I forgot the details, but the bit reservoir info is right after the header |
| 10:59:03 | amiconn | Plus, I don't think the audio glitches would decrease significantly with the bit reservoir correction. The stream ends don't match anyway |
| 10:59:19 | [IDC]Dragon | why not? |
| 10:59:47 | [IDC]Dragon | they used it even to accelerate/decelerate playback |
| 10:59:55 | amiconn | You play a chunk to the end, skip some frames, and start a new chunk. How are these 2 chunks supposed to match? |
| 11:00 |
| 11:00:19 | [IDC]Dragon | you make a new "seam" |
| 11:00:24 | LinusN | amiconn: the point is to make sure that the decoded frames are complete |
| 11:00:38 | LinusN | else the mas inserts silence for the duration of the frame |
| 11:00:51 | [IDC]Dragon | Archos used this even to modify playback speed |
| 11:01:12 | [IDC]Dragon | like, drop/duplicate every n frames |
| 11:01:22 | amiconn | LinusN: Yes, but the most would be that the first frame of the new chunk is silenced. Something I wouldn't really care... |
| 11:01:39 | LinusN | amiconn: for voice playback, you do |
| 11:01:57 | [IDC]Dragon | away now |
| 11:02:25 | amiconn | Nope. I don't mean to throw away the synchronisation to frame boundaries. |
| 11:02:47 | amiconn | Otherwise the mas needs to resync, which takes several frames |
| 11:03:13 | amiconn | I only mean to not care about the bit reservoir |
| 11:03:34 | LinusN | i know |
| 11:04:24 | amiconn | The current voice ui implementationdoes exactly that. |
| 11:05:26 | Bagder | NEWGCC=$(shell expr $(GCCNUM) ">" 303) |
| 11:05:39 | Bagder | then I can make a ifeq on that |
| 11:05:50 | Bagder | seems to work |
| 11:07:55 | | Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 11:08:17 | Bagder | new sim build patch uploaded |
| 11:08:19 | [IDC]Dragon | amiconn: and that's why we need to insert the silence clip, right? |
| 11:11:13 | amiconn | No, it isn't. We have to *append* the silence clip, because the mas obviously doesn't play a stream to its very end. |
| 11:11:36 | amiconn | When we switch clips (via shutup()), we do not insert it. |
| 11:12:20 | [IDC]Dragon | yes, ok |
| 11:13:05 | [IDC]Dragon | mabe one day I'll make a little test command line app to massage an mp3 stream |
| 11:13:16 | [IDC]Dragon | to test ff/fr |
| 11:13:47 | | Join R3nTiL_ [0] (~zorroz@83.69.98.220) |
| 11:13:47 | [IDC]Dragon | with bit reservoir resolving |
| 11:14:21 | amiconn | The frame search would benefit from a fast memchr() (and something like memrchr() ) |
| 11:14:36 | amiconn | Shouldn't be hard with a little SH asm... |
| 11:14:40 | [IDC]Dragon | memrchr(), haha |
| 11:15:02 | amiconn | For the backwards search... |
| 11:15:19 | [IDC]Dragon | I thought you did memchr already, or was that strlen? |
| 11:15:39 | amiconn | I did strlen, but memchr() would be similar |
| 11:16:01 | amiconn | We don't use memchr() currently |
| 11:16:14 | [IDC]Dragon | ok |
| 11:17:24 | [IDC]Dragon | yesterday I've tries rockboy a bit |
| 11:17:32 | [IDC]Dragon | tried |
| 11:17:52 | [IDC]Dragon | cool, but sadly somehow hopeless |
| 11:18:03 | HCl | ? |
| 11:18:06 | [IDC]Dragon | on the SH and the 112*64 |
| 11:18:21 | dwihno | :) |
| 11:18:34 | HCl | H |
| 11:18:36 | HCl | ah |
| 11:18:37 | | Quit Cassandra_ (Read error: 110 (Connection timed out)) |
| 11:18:49 | [IDC]Dragon | we'd need the pseudo-grayscale if we want to have chance to recognize anything |
| 11:19:13 | HCl | hoh |
| 11:19:15 | HCl | heh |
| 11:19:15 | | Join Cassandra_ [0] (~christi@213.78.163.225) |
| 11:19:17 | HCl | forget it |
| 11:19:23 | HCl | and why? cause of the scaling? |
| 11:19:26 | [IDC]Dragon | like antialiasing compensating for a lack of resolution |
| 11:19:55 | amiconn | Now _that_ would be a slowdown... |
| 11:20:05 | [IDC]Dragon | sure |
| 11:20:51 | [IDC]Dragon | does a gameboy have a ROM, OS, or such? |
| 11:20:51 | | Quit webguest34 ("CGI:IRC (EOF)") |
| 11:20:52 | amiconn | Perhaps we could halve the update frequency to 33 Hz when using only few grayscales |
| 11:21:40 | [IDC]Dragon | if yes, that could be mapped to native SH code |
| 11:21:43 | | Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 11:22:02 | amiconn | [IDC]Dragon: HCl is thinking about a dynarec implementation... |
| 11:22:26 | [IDC]Dragon | abybody remembering the N64 emu with it's high level emulation? |
| 11:22:26 | | Join Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au) |
| 11:22:35 | [IDC]Dragon | what's dynarec? |
| 11:22:43 | amiconn | dynamic recompilation |
| 11:22:58 | [IDC]Dragon | sounds good |
| 11:23:00 | dwihno | [IDC]Dragon: ultrahle? |
| 11:23:12 | dwihno | I think it was the first |
| 11:23:12 | [IDC]Dragon | yes, that's the one |
| 11:23:12 | ashridah | if it can cache the recompiled stuff, that'd be awesome |
| 11:23:47 | amiconn | ashridah: Iiuc thats the point of dynarec. Without it, it wouldn't make sense... |
| 11:23:59 | [IDC]Dragon | and we need the wav codec, sigh |
| 11:24:19 | [IDC]Dragon | no progress yet |
| 11:24:29 | | Quit Quelsaruk ("rebooting") |
| 11:25:11 | amiconn | I already had a look at the pattern update function. That's one of the parts available in asm for i386 |
| 11:25:33 | [IDC]Dragon | pattern update? |
| 11:25:41 | [IDC]Dragon | is that the screen update? |
| 11:25:50 | amiconn | The C implementation is a real cpu sucker; 3 nested loops across a 4096x8x8 byte array... |
| 11:25:54 | [IDC]Dragon | or sprites? |
| 11:26:20 | amiconn | lcd.c: updatepatpix() |
| 11:27:31 | HCl | no |
| 11:27:33 | HCl | not ultrahle |
| 11:27:39 | HCl | ultrahle is an entirely different concept |
| 11:27:44 | HCl | than dynarec |
| 11:27:44 | ripnetuk | i thought hle was not dynarec - |
| 11:28:03 | ripnetuk | hle == catching api calls to nintendos library and re-implementing them (like wine) |
| 11:28:12 | HCl | hle = recognising native library functions used to compile games and mapping them onto native library functions |
| 11:28:48 | * | HCl resumes sleeping, keeps getting nightmares u.u |
| 11:28:51 | | Join Quelsaruk [0] (~kvirc@80.103.134.240) |
| 11:28:55 | Quelsaruk | back |
| 11:29:08 | ripnetuk | i think it worked because nintendo had a standard dev library which almost all games linked into |
| 11:29:26 | amiconn | [IDC]Dragon: updatepatpix() should be easily made flying with SH1 asm... |
| 11:29:45 | [IDC]Dragon | is there a gameboy builtin library? |
| 11:36:44 | Bagder | lunch |
| 11:36:59 | [IDC]Dragon | what about an offline dynarec, convering the gamebay roms to something native? |
| 11:37:10 | [IDC]Dragon | converting |
| 11:37:28 | * | [IDC]Dragon is aware of his wild ideas |
| 11:37:56 | [IDC]Dragon | and wild spelling ;) |
| 11:38:23 | dwihno | That's a great idea! |
| 11:38:43 | Quelsaruk | like rvf? a rgr? |
| 11:39:43 | dwihno | If it wasn't you who said it, I would say that person was bonkers :) |
| 11:40:58 | amiconn | [IDC]Dragon: Dynarec (or offline recompilation) will only speed up cpu emulation. Other parts need more speed too, as e.g. the mentioned updatepatpix() |
| 11:41:27 | [IDC]Dragon | I know, but the CPU emu doesn't come for free, too |
| 11:41:49 | [IDC]Dragon | I've seen that switch-case from hell |
| 11:42:00 | | Join |Quelsar| [0] (~kvirc@80.103.134.240) |
| 11:42:07 | | Quit Quelsaruk (Read error: 104 (Connection reset by peer)) |
| 11:44:02 | | Quit R3nTiL_ () |
| 11:44:12 | | Nick |Quelsar| is now known as quelsaruk (~kvirc@80.103.134.240) |
| 11:48:47 | dwihno | a switch for every instruction? |
| 11:48:51 | dwihno | (a case) |
| 11:50:03 | quelsaruk | re |
| 11:50:05 | ashridah | don't compilers attempt to reduce that to a simple indexed lookup table these days? |
| 11:57:30 | [IDC]Dragon | they try to make a jump table, yes |
| 11:57:52 | [IDC]Dragon | if the values are not too sparse |
| 11:58:15 | LinusN | easy on simple enums, but not when the case values are very large and very different |
| 11:58:26 | LinusN | like for opcides |
| 11:58:29 | LinusN | opcode |
| 11:58:39 | [IDC]Dragon | the opcode is 8 bit |
| 11:58:47 | [IDC]Dragon | so it could work out |
| 11:59:53 | LinusN | hmmm |
| 12:00 |
| 12:01:01 | [IDC]Dragon | it could even multiply the opcode with the worst-case op handler size, and do a staight jump |
| 12:01:14 | [IDC]Dragon | saving the table lookup |
| 12:04:07 | LinusN | mpa2wav.rock runs at 40% realtime in 140MHz :-( |
| 12:04:28 | linuxstb | :-( I was expecting something like that. |
| 12:04:43 | LinusN | and crashes after a while |
| 12:04:48 | linuxstb | What about FLAC? |
| 12:05:01 | LinusN | i have no flac files to try |
| 12:05:23 | linuxstb | madplay -o wav:file.wav file.mp3 ; flac file.wav |
| 12:05:53 | LinusN | no madplay or flac here |
| 12:06:29 | ripnetuk | alt.binaries.mp3.lossless??? |
| 12:07:21 | dwihno | LinusN: is disk writing CPU intensive? |
| 12:07:29 | LinusN | not really |
| 12:07:39 | dwihno | Then this is bad news. |
| 12:08:02 | LinusN | yes it is, it means that we have to work a little on the optimizations |
| 12:08:05 | dwihno | wasn't there a guy who did a 68k asm port? |
| 12:08:39 | LinusN | there are quite a few optimizations to be done |
| 12:09:06 | LinusN | like putting the major number crunching code in internal ram |
| 12:09:15 | LinusN | using the EMAC |
| 12:09:16 | LinusN | etc |
| 12:09:55 | LinusN | still, i'd like it to be like 200% real time, at least |
| 12:10:12 | dwihno | yeah :( |
| 12:10:29 | linuxstb | LinusN: If you're interested, I've uploaded a small (3.5MB) test flac file here: linuxstb.org/linus.zip">http://linuxstb.org/linus.zip |
| 12:11:08 | dwihno | do you know the stock firmware playback frequency? |
| 12:13:21 | LinusN | LinusN: hmmm, flac2wav just exits |
| 12:13:47 | linuxstb | LinusN: Does your firmware have the increased stack size I added to CVS? |
| 12:15:54 | LinusN | i have the latest cvs |
| 12:16:09 | LinusN | maybe my inline commit yesterday broke it... |
| 12:16:49 | linuxstb | No, I tried flac after your change (to see if the speed changed - it did't). |
| 12:16:59 | LinusN | :-) |
| 12:17:10 | * | LinusN did make clean;make |
| 12:21:20 | | Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) |
| 12:27:17 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 12:27:36 | LinusN | something is really odd with the flac decoder |
| 12:28:53 | linuxstb | What do you mean? |
| 12:29:34 | LinusN | the speed calculations are wrong |
| 12:29:42 | linuxstb | That's possible. |
| 12:29:54 | linuxstb | But is it working? |
| 12:30:23 | LinusN | yes, it works when i play the file, but not with "open with" |
| 12:30:43 | LinusN | "samples decoded" stops at 9216 |
| 12:30:57 | LinusN | "frames decoded" keeps running |
| 12:31:59 | linuxstb | Is that when you do "open with" ? |
| 12:32:21 | | Join webguest01 [0] (~c31ce021@labb.contactor.se) |
| 12:32:31 | LinusN | it just exits when i try open with |
| 12:32:47 | linuxstb | Yes, I've just tried open with, and it exits immediately. |
| 12:33:10 | linuxstb | However, just playing the file seems to work fine (correct speed displayed) |
| 12:33:33 | LinusN | what's the speed for you? |
| 12:33:42 | linuxstb | About 8% |
| 12:34:03 | LinusN | 27% in 40MHz |
| 12:34:53 | linuxstb | No, the speed seems to be dropping the more it decodes - now about 7.13% |
| 12:35:24 | linuxstb | now a little higher... |
| 12:35:48 | LinusN | really weird |
| 12:35:49 | | Quit xen` (Read error: 60 (Operation timed out)) |
| 12:36:40 | linuxstb | It's now stabilised around 7.36% |
| 12:38:00 | | Join Sucka [0] (~NNSCRIPT@host81-156-215-25.range81-156.btcentralplus.com) |
| 12:41:44 | webguest01 | I'm trying to build the bootloader, and have a error in "backlight.c". -> unrecognized architecture specification '5249'. what's wrong? |
| 12:43:19 | LinusN | you have the wrong binutils |
| 12:43:38 | webguest01 | ok, thanks, I'll check my installation |
| 12:43:52 | LinusN | did you build it yourself? |
| 12:43:58 | webguest01 | yes |
| 12:45:28 | LinusN | ok |
| 12:47:37 | LinusN | hmm, flac2wav doesn't behave in full speed |
| 12:47:47 | LinusN | i wonder if my clock settings are too aggressive... |
| 12:50:24 | ripnetuk | have you measured the speed the coldfire runs at with the original firmware? maybe using the bdm? |
| 12:50:32 | LinusN | nope |
| 12:50:58 | ripnetuk | is is not possible to get the pll settings from that? |
| 12:51:15 | LinusN | why would i want that? |
| 12:51:29 | ripnetuk | i thought you said it was tricky to get them right |
| 12:51:43 | ripnetuk | (maybe tricky == fun) |
| 12:52:12 | LinusN | pll is easy |
| 12:52:21 | | Join jyp [0] (~jp@184-229.244.81.adsl.skynet.be) |
| 12:52:36 | LinusN | adjusting wait states is the hard part |
| 12:53:07 | ripnetuk | is that basically a measure of how much 'dummy' time is needed for the rest of the circuit to catch up with the faster processor? |
| 12:53:29 | LinusN | sort of |
| 12:57:03 | linuxstb | I've fixed the flac2wav "open with" problem - I've added a call to rb->button_clear_queue() before the main decoding loop starts. |
| 12:57:06 | *** | Saving seen data "./dancer.seen" |
| 12:58:04 | Bagder | and I fixed the gcc option when building flac with older gccs |
| 12:59:09 | Bagder | I'm considering committing this build stuff without having it confirmed from any cygwin user |
| 12:59:15 | Bagder | and work out the flaws post-commit |
| 13:00 |
| 13:00:02 | amiconn | Bagder: I really wanted to test yday... |
| 13:00:12 | linuxstb | If it works for the automated builds, then why not? |
| 13:01:06 | amiconn | linuxstb: The automated build all run on linux. |
| 13:01:53 | Bagder | and I haven't tested *all* those combos |
| 13:02:59 | | Join DeadMan [0] (Rori@deadman3000.plus.com) |
| 13:05:33 | linuxstb | LinusN: If you want to try a52towav, I've copied a short (1.3MB) AC-3 test file here: linuxstb.org/linus2.zip">http://linuxstb.org/linus2.zip |
| 13:11:20 | ashridah | gah. |
| 13:11:41 | ashridah | i just accidentally nuked my firmware directory thinking it was my firmware's build directory :) |
| 13:11:57 | Bagder | hehe |
| 13:12:40 | | Join Patr3ck_ [0] (~patr3ck@pD9ECFD04.dip.t-dialin.net) |
| 13:21:46 | | Quit ripnetuk ("Leaving") |
| 13:24:29 | | Join pappou [0] (~Bjoern@p50804F7D.dip0.t-ipconnect.de) |
| 13:29:01 | | Quit Patr3ck (Read error: 110 (Connection timed out)) |
| 13:29:34 | | Part pappou |
| 13:29:43 | ashridah | hrm. |
| 13:29:54 | ashridah | shouldn't make zip depend on having an up to date rockbox.iriver ? |
| 13:30:10 | ashridah | (which, in turn, depends on having up to date .o/.a files or whatever |
| 13:30:37 | Bagder | it would need to depend on all files in the zip file |
| 13:30:57 | ashridah | well, make expansions can handle that. |
| 13:31:17 | Bagder | no |
| 13:31:31 | Bagder | or rather, yes if you write additional rules |
| 13:31:57 | ashridah | well, at least, if make zip depended on the default make rule, then the point would be moot |
| 13:32:00 | Bagder | personally, I don't find that important |
| 13:32:11 | ashridah | well, no. it's only one extra command |
| 13:32:23 | ashridah | so yeah, its not overly important |
| 13:32:55 | ashridah | there we go |
| 13:33:00 | ashridah | add 'all' after zip: |
| 13:33:04 | ashridah | and it builds all before zip |
| 13:33:33 | Bagder | that's a fair addition, yes |
| 13:34:11 | ashridah | then, if i touch snow.c |
| 13:34:17 | ashridah | and run make zip |
| 13:34:27 | ashridah | it rebuilds snow.c. if i touch something in the lib, it rebuilds the lib, then relinks everything against it |
| 13:34:39 | Bagder | yes, but if you update a font, it doesn't work |
| 13:34:43 | ashridah | hrm. |
| 13:35:05 | ashridah | that's not impossible to fix tho |
| 13:35:15 | Bagder | nothing is impossible ;) |
| 13:35:39 | ashridah | if you add the fonts to an extra export using a make wildcard, then have make zip depend on them too. |
| 13:36:15 | ashridah | hang on. aren't the fonts solely the domain of buildzip.pl? |
| 13:36:40 | ashridah | yeah. zip just needs to depend on those files. then make will know if they get modified |
| 13:36:55 | ashridah | (although it tends to run commands it doesn't understand anyway) |
| 13:37:32 | Bagder | yes, the zip file should depend on all the bdf files |
| 13:37:38 | Bagder | I guess |
| 13:38:41 | ashridah | hrm. |
| 13:38:46 | ashridah | i'm not so sure it'll matter |
| 13:38:56 | ashridah | make'll run the command to rebuild the zipfile no matter what anyway |
| 13:39:06 | ashridah | so it should pick them up any time make zip gets run |
| 13:39:39 | ashridah | (since make doesn't know how to tell if rockbox.zip is the file that needs to be up to date for it to not do anything) |
| 13:41:24 | | Join DrRick [0] (DrRick@81-86-81-232.dsl.pipex.com) |
| 13:44:58 | Bagder | darn, broke my build... no commit yet |
| 13:46:37 | | Quit lostlogic (Remote closed the connection) |
| 13:47:03 | | Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) |
| 13:50:06 | Bagder | Zagor: you should fix the syntax colouring when browsing cvs files |
| 13:52:28 | Bagder | LinusN: is the -g option wanted for iRiver builds? |
| 13:52:35 | Bagder | I noticed it gets set by configure |
| 13:52:51 | Bagder | for gcc |
| 13:54:17 | LinusN | Bagder: it really doesn't matter much, but i'd like it that way for the time being |
| 13:54:26 | LinusN | makes it easier for me |
| 13:54:29 | Bagder | ok |
| 13:55:10 | LinusN | looks like i have to measure the ata timing with my logic analyzer |
| 14:00 |
| 14:04:28 | Bagder | /usr/local/m68k/lib/gcc/m68k-elf/3.4.3/../../../../m68k-elf/bin/ld: cannot find crt0.o |
| 14:04:33 | Bagder | is certainly annoying |
| 14:05:49 | | Join CoCoLUS [0] (~coco@h081217139221.dyn.cm.kabsi.at) |
| 14:05:56 | CoCoLUS | mornin |
| 14:07:08 | LinusN | after setting a lot more conservative ATA timing settings, the flac decoder finally works in 140MHz |
| 14:07:24 | * | Bagder scratches his head |
| 14:07:47 | DeadMan | :)) |
| 14:08:12 | Sucka | real time? |
| 14:08:14 | | Quit jyp ("poof!") |
| 14:08:23 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 14:09:09 | amiconn | Bagder: I wonder about the odd path specification to 'lcd'. Why does it descend first, the trace back up? (../../../../) |
| 14:09:19 | amiconn | Erm, I mean 'ld' |
| 14:09:30 | | Quit lostlogic ("Going to the moon") |
| 14:09:48 | Bagder | well, it does that |
| 14:09:53 | linuxstb | LinusN:: at what speed? |
| 14:09:53 | Bagder | ;-) |
| 14:09:58 | Bagder | it does the same on sh etc |
| 14:10:05 | LinusN | 93% something |
| 14:10:33 | DeadMan | :( |
| 14:10:51 | DeadMan | needs tweaking to get realtime then |
| 14:11:29 | linuxstb | I think that looking at the int64 usage of FLAC will get us an easy improvement. I'll try and look into that. I'll leave libmad to others. |
| 14:13:31 | DeadMan | libmad is what I am waiting on anyhow |
| 14:13:40 | DeadMan | MP3 is my most used format |
| 14:14:03 | LinusN | hmm, ata access is still shaky in 140MHz |
| 14:14:24 | DeadMan | crashing out? |
| 14:15:12 | LinusN | looks like read errors |
| 14:15:38 | ashridah | wtf |
| 14:15:45 | ashridah | just got a server error out of google! |
| 14:15:48 | ashridah | my world's come to an end |
| 14:16:27 | amiconn | LinusN: Does the iRiver have a hd activity led? |
| 14:16:34 | ashridah | amiconn: yeah |
| 14:17:14 | LinusN | multisector reads fail |
| 14:17:44 | amiconn | I wonder whether there'll be rld on iRiver then... |
| 14:18:09 | ashridah | rld... red light death? |
| 14:18:49 | amiconn | red lead death, an (in)famous problem on archos with certain harddsik brands |
| 14:19:00 | amiconn | ..namely the Hitach DK23DA.. series |
| 14:19:12 | amiconn | s/lead/led/ |
| 14:21:39 | Bagder | diffing two diffs is tricky stuff :-) |
| 14:21:58 | LinusN | the iriver hardware is neat, but they made a huge mistake when they didn't connect the IORDY signal |
| 14:26:53 | Bagder | blah, had to revert back to an older patch to get it working again |
| 14:27:02 | Bagder | I'll commit this and continue from here |
| 14:27:32 | Bagder | or does anyone object? |
| 14:27:44 | Bagder | it may be some shaky builds |
| 14:37:33 | | Join Lynx0 [0] (HydraIRC@134.95.189.59) |
| 14:37:46 | ashridah | LinusN: odd. can you tell if it was due to space constraints or just laziness? |
| 14:38:28 | LinusN | ashridah: what? |
| 14:38:38 | ashridah | IORDY |
| 14:38:43 | Patr3ck_ | regarding optimizing the codecs, is it possible to profile the libraries to find the places were optimizing would have greatest effect? |
| 14:38:52 | LinusN | ashridah: i have no idea |
| 14:39:13 | LinusN | Patr3ck_: sure, using timers |
| 14:41:15 | Patr3ck_ | timers would have to be added to the codecs library code? |
| 14:41:28 | | Quit Lynx_ (Nick collision from services.) |
| 14:41:43 | | Nick Lynx0 is now known as Lynx_ (HydraIRC@134.95.189.59) |
| 14:41:46 | LinusN | yeah, instrument the code with checkpoints, storing timestamps |
| 14:42:14 | ashridah | Patr3ck_: sadly, gprof doesn't exist for the target platform :) |
| 14:42:25 | Patr3ck_ | Would profiling on the linux or win32 plattform using existing tools help? |
| 14:42:35 | LinusN | not really |
| 14:42:47 | ashridah | Patr3ck_: i doubt it, since the code generated will be wildly different |
| 14:42:56 | Patr3ck_ | I see, too bad :-( |
| 14:43:15 | | Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 14:43:38 | ripnetuk | there is a law that 99% of the time is spent in 1% of the code and its never the 1% you expected :) |
| 14:43:50 | Patr3ck_ | exactly :-) |
| 14:46:03 | Bagder | ok, stand by for impact, commit coming up |
| 14:46:41 | Patr3ck_ | If timers would be added, where should the results be shown? A log file? |
| 14:47:01 | ripnetuk | i would say build it in memory - we dont want to affect the results by wroiting to disk |
| 14:47:35 | Patr3ck_ | After processing has finished, write it to a log file? |
| 14:47:36 | ripnetuk | imho you need to build a tree of timings, like task a takes 10 ticks, and task a consists of task a1 and task a2 which take 1 and 9 ticks (etc) until you find the slow bit |
| 14:47:48 | ripnetuk | thats how I do it on Windows |
| 14:48:14 | Patr3ck_ | top down aproach... |
| 14:48:30 | ripnetuk | i then wrote a util to show it graphically - makes it real easy to see where the time is going |
| 14:49:17 | ripnetuk | and easier to demonstrate to boss :) |
| 14:49:43 | Patr3ck_ | He gives you time to optimize? Lucky you ;-) |
| 14:49:57 | ripnetuk | only when the customers are jumping up and down |
| 14:50:04 | Patr3ck_ | :-) |
| 14:50:10 | | Join einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de) |
| 14:50:20 | ripnetuk | what is Badger committing? |
| 14:50:36 | ripnetuk | sorry, Bagder |
| 14:50:47 | linuxstb | Not sure how useful this information is, but if you encode a FLAC file with the "−−l 0" option (disabling the "linear predictive coding"), then you get a slightly larger filesize, but a quick test showed that 1000000 samples encoded with -l 0 took 237 seconds, compared with 286 seconds normally (almost a 20% increase in speed) |
| 14:50:47 | | Join lolo-laptop [0] (~lostlogic@68.251.84.226) |
| 14:52:11 | Bagder | ripnetuk: build system fix |
| 14:52:33 | Bagder | well, fixES actually |
| 14:53:29 | Bagder | now the sims are built more similar to the targets |
| 14:53:33 | ashridah | linuxstb: that sounds about right. given that FLAC can't vary the content of the compressed audio, it stands to reason that it'd result in size VS time optimisation options |
| 14:53:58 | ashridah | it's along the lines of multi-pass video encoding |
| 14:54:12 | ripnetuk | cool... this whole c build stuff seems very primitive to me (coming from compilers that have projects that handle all that) |
| 14:54:29 | Bagder | bah |
| 14:54:31 | ripnetuk | aka. I dont understand build files very well :) |
| 14:54:41 | Bagder | those things never work |
| 14:54:44 | Bagder | for things like this |
| 14:55:26 | ashridah | ripnetuk: you can get IDE's that'll build configure/makefiles for you under unixalikes. but that more or less commits you to using their version of the horror that is autoconf/automake :) |
| 14:55:57 | ripnetuk | yes |
| 14:56:18 | ripnetuk | im sure its my lack of understanding thats putting meoff |
| 14:57:09 | *** | Saving seen data "./dancer.seen" |
| 14:57:12 | Bagder | if you just think for a while how you'd do the build, for linux and cygwin and multiple targets |
| 14:57:17 | ashridah | in my case it's entirely likely that it'd be better than MY versions of the config of the horror that is autoconf/automake |
| 14:58:11 | ashridah | thats right |
| 15:00 |
| 15:00:38 | Bagder | actually, autoconf/automake wouldn't help us very much |
| 15:08:13 | | Quit webguest01 ("CGI:IRC") |
| 15:13:23 | Bagder | the build takes a long time now |
| 15:14:08 | Bagder | 14 minutes now |
| 15:17:28 | linuxstb | Bagder: I think I've got your first bug report. there is a CODECLIBS variable defined in apps/plugins/Makefile, but you are not using it for the X11 sim build. So the ???2wav plugins aren't being linked against the codec libs |
| 15:17:51 | Bagder | ok |
| 15:17:54 | LinusN | Bagder: red player sim build |
| 15:18:03 | Bagder | yes, taking that one first |
| 15:20:37 | Bagder | quite a few warnings too, but they're not as harmful |
| 15:22:27 | Bagder | linuxstb: you fix that? |
| 15:23:30 | linuxstb | Bagder: I'm still looking at it. The obvioius fix didn't seem to work |
| 15:24:30 | Bagder | remember to re-configure |
| 15:24:46 | Bagder | (not directed to anyone specific but to everyone) |
| 15:25:55 | amiconn | Bagder: Your new make system changes a lot. I hope I'll get my rockboy makefile working with that :-/ |
| 15:26:33 | Bagder | well, I think it is an improvement |
| 15:26:51 | Bagder | but of course it causes troubles to those who have local changes |
| 15:27:09 | amiconn | I have, in apps/plugins/Makefile :-( |
| 15:29:10 | Bagder | I also have a pending fix for putting object files in a dir tree as in the source dirs |
| 15:29:48 | amiconn | How did you do that? |
| 15:29:59 | Bagder | magic ;-) |
| 15:30:07 | amiconn | make.inc expects OBDIR, so I used the following construct: |
| 15:30:18 | Bagder | I modified make.inc too |
| 15:30:41 | amiconn | (example: rockboy) |
| 15:30:42 | amiconn | override OBJDIR := $(OBJDIR)/rockboy |
| 15:30:43 | amiconn | PARENTDIR = $(dir $(OBJDIR)) |
| 15:31:20 | amiconn | Then I can use PARENTDIR to access stuff above. This is slightly ugly, because PARENTDIR keeps the trailing slash |
| 15:31:30 | Bagder | I think I'll use dir=$(strip, $(ROOTDIR),,$@) |
| 15:31:40 | linuxstb | Bagder: I can't get my *2wav.rock files to compiler properly on the X11 sim. Adding $(CODECLIBS) to the X11 part of apps/plugins/Makefile doesn't seem to make a difference. The .rockx still don't appear to contain the library code. I then get an "invalid entry point" when trying to run them. All the other plugins work. |
| 15:32:03 | Bagder | ok, I'll check too |
| 15:32:34 | amiconn | Some of the warnings look like they might cause problems |
| 15:37:07 | Bagder | amiconn: any particular you think of? |
| 15:37:57 | | Join zioben [0] (~93a202de@labb.contactor.se) |
| 15:38:12 | Bagder | since the sims now build with the same -I setup as the targets, many standard include files are "shadowed" by the Rockbox versions |
| 15:38:52 | amiconn | common/timefuncs.c:81: warning: return makes pointer from integer without a cast |
| 15:39:19 | Bagder | that's just due to lack of prototype |
| 15:40:27 | Bagder | I'll fix |
| 15:41:58 | | Join jyp [0] (~jp@184-229.244.81.adsl.skynet.be) |
| 15:42:42 | amiconn | Bagder: Did you include the cygwin LITTLE_ENDIAN workaround in a more central place? |
| 15:42:50 | Bagder | no |
| 15:42:56 | | Join R3nTiL [0] (~zorroz@83.69.98.230) |
| 15:43:02 | | Part LinusN |
| 15:45:06 | amiconn | Bagder: Doing that might be quite useful. Rockboy definitely needs endian info. |
| 15:45:48 | Bagder | it should probably be put in some header file like system.h or so |
| 15:45:50 | Bagder | or cpu.h |
| 15:46:27 | amiconn | Hmm. The fix only applies to the simulators. I think a suitable place would be config.h |
| 15:47:03 | Bagder | my thinking was that including "cpu.h" should get you info about the cpu |
| 15:47:10 | Bagder | including endianess |
| 15:47:55 | * | jyp seconds |
| 15:47:56 | amiconn | Theoretically yes, but so far cpu.h only includes info about target cpus |
| 15:48:55 | Bagder | well, if you want to write code that does it right, for both sim and targets, wouldn't it still make sense? |
| 15:49:18 | Bagder | then again, for cpu.h to do right, you need to include config.h as well |
| 15:49:20 | Bagder | ;-) |
| 15:49:24 | amiconn | Changing that will certainly break a number of places. Plus, currently we define id numbers per cpu. |
| 15:49:50 | Bagder | why would it break anything? you'd only add a definition, right? |
| 15:50:03 | amiconn | How could that be done for the simulators? We cannot know in advance, the sims may run on virtually any cpu |
| 15:50:36 | Bagder | so let the configure figure it out |
| 15:50:53 | zioben | Hi! I am newbie to this IRC. A friend of mine tells me that HCL (if i remember right) realized a Gameboy Emulator. It is right? |
| 15:51:10 | Bagder | zioben: he works on that, yes |
| 15:51:58 | zioben | Right!But i heard it is slow |
| 15:52:13 | Bagder | it is not complete |
| 15:52:16 | Bagder | nor is Rockbox |
| 15:54:13 | amiconn | Bagder: Even if configure manages to find the cpu info, this wouldn't help much. As we don't know in advance whatever cpu we will run on, how could we set conditionals depending on it? |
| 15:54:21 | zioben | If it can be useful at http://www.arrakis.es/~joanant/ there is a assembly source code of vary emulators (master system, gameboy, MSX) realized for Amiga which uses the same processor family (Rockbox uses coldfire isn't it?)... |
| 15:54:36 | Bagder | amiconn: then I'm lost. What is the problem? |
| 15:54:52 | ashridah | zioben: it might be useful, what're the licensing terms? do you know? |
| 15:55:13 | linuxstb | Regarding endianness, on Linux (and maybe elsewhere) there's /usr/include/endian.h which is part of the GNU C Library. |
| 15:55:59 | Zagor | linuxstb: cygwin is the problem. it doesn't define it. |
| 15:56:10 | linuxstb | But cygwin only runs on Intel. |
| 15:56:28 | Bagder | true |
| 15:56:45 | zioben | Originally they are shareware, but two years go became freeware and source code should be free... on the web page there is the email of the author |
| 15:57:47 | Zagor | zioben: the problem is these are massive amounts of amiga-specific assembly code. not very fun porting to a new system. |
| 15:58:07 | HCl | hmmm. |
| 15:58:16 | HCl | yea. |
| 15:59:09 | jyp | Bagder, amiconn; you could go the autoconf way |
| 15:59:31 | amiconn | linuxstb: I just checked, cygwin also provides that file (only it is /usr/include/machine/endian.h), but afaics LITTLE_ENDIAN and BIG_ENDIAN as defined there are different from the usage I know. |
| 15:59:31 | Bagder | you mean for endian? |
| 16:00 |
| 16:00:00 | HCl | heh. |
| 16:00:22 | HCl | unfortunately, that sourcecode is horrid - one big assembly file thats barely readable with no comments |
| 16:00:29 | amiconn | It always defines both. BIG_ENDIAN = 4321 and LITTLE_ENDIAN = 1234. Then it sets BYTE_ORDER according to the machine |
| 16:00:31 | linuxstb | Why don't we just have a simple C program that is compiled and run as part of configure? i.e. x=0x12345678 and see what the memory contains? |
| 16:00:37 | jyp | yup, I mean running a little testing program at configure time, that sets a conditional |
| 16:03:38 | Zagor | linuxstb: we can't run the code. it's cross-compiled... |
| 16:04:04 | HCl | annoying that the top hits for "z80 dynarec" is rockbox irc log files ;/ |
| 16:04:13 | jyp | ... for the sim targets |
| 16:04:34 | zioben | Oh! i thinked it was a good idea... |
| 16:04:38 | linuxstb | Zagor: I thought the only problem was the sims - we know the endianness of the targets |
| 16:05:48 | jyp | Question, is there standalone program to test usb somewhere? |
| 16:06:03 | ripnetuk | cant it just be a new configure option? like we have debug, target, sim, couldt we just have sim (LE) and sim (BE)? |
| 16:06:38 | amiconn | linuxstb: Yes. The problem first occured with Zagor's id3 browser, which also needs to know endianess. Zagor uses a simple check to define a byte swap macro depending on LITTLE_ENDIAN being defined |
| 16:06:44 | Zagor | linuxstb: right, but then we're back to custom makefiles for sims again |
| 16:07:26 | amiconn | Unfortunately cygwin doesn't define it, so id3 browsing didn't work on all cygwin built sims (both x11 and win32) |
| 16:07:37 | linuxstb | We can just add an endian variable to configure - for the targets it's hard-coded, and for the sims, we run a little C program which is called from tools/configure |
| 16:08:00 | amiconn | I added a simple workaround for that to dbtree.c. Imho the easiest solution would be to add that to config.h |
| 16:08:49 | amiconn | #if !defined(LITTLE_ENDIAN) && !defined(BIG_ENDIAN) && defined(_X86_) |
| 16:08:49 | amiconn | #define LITTLE_ENDIAN |
| 16:08:49 | amiconn | #endif |
| 16:12:10 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
| 16:12:24 | preglow | so, i see there are bad news afoot regarding the codecs and cpu usage :/ |
| 16:12:52 | HCl | hey |
| 16:13:16 | linuxstb | preglow: Not unsurprising, given the performance at 11MHz. |
| 16:13:44 | preglow | linuxstb: no, not surprising at all |
| 16:13:58 | preglow | it's more or less what i thought it'd be |
| 16:14:17 | HCl | doesnt not unsurprising actually mean surprising? |
| 16:14:58 | preglow | 'not unsurprising' means that it is surprising, yes :) |
| 16:15:14 | preglow | but i got his meaning, heh |
| 16:15:51 | jyp | semantics at work |
| 16:15:52 | * | linuxstb goes to study grammar... |
| 16:16:28 | linuxstb | preglow: any progress with your emac activities? |
| 16:16:52 | ripnetuk | im guessing that libmad is already quite well optimized, and we are looking for things that the coldfire does (badly|slowly) to replace with more efficient code? |
| 16:17:15 | preglow | linuxstb: well, yes, i've got it working well |
| 16:17:28 | preglow | i've used it to make a linearly interpolated sine routine and an iir filter |
| 16:17:31 | preglow | so i think i've got it |
| 16:18:12 | linuxstb | My thought about libmad is that it probably trades speed for accuracy. So if we compromised the accuracy (i.e. not maintaining the full 24-bit precision), then that may bring big speed improvements. |
| 16:19:10 | linuxstb | But I'm assuming lots of people will be interested in libmad, so I'm going to try and concentrate on FLAC. |
| 16:19:30 | ripnetuk | FLAC is 90 something percent yes? |
| 16:19:38 | linuxstb | yes. |
| 16:19:53 | preglow | linuxstb: i'll try to have a look at libmad |
| 16:20:13 | jyp | preglow: I'm interested in your code |
| 16:20:29 | preglow | jyp: no problem, don't think you'll benefit much from it |
| 16:20:32 | preglow | gimme a sec |
| 16:21:31 | | Quit R3nTiL () |
| 16:21:36 | jyp | My goal is to get a better understanding of the emac... |
| 16:21:41 | linuxstb | preglow: Do you know any good resources for info about the emac? Or are they already in the Wiki? |
| 16:22:44 | ashridah | linuxstb: i think the programmers guide has a chapter on the emac doesn't it? |
| 16:22:52 | zioben | i thank everybody for the attention. Bye! |
| 16:23:01 | | Quit zioben ("CGI:IRC") |
| 16:23:39 | preglow | linuxstb: all i've been able to find is the motorola manuals |
| 16:24:09 | preglow | linuxstb: in particular the coldfire family programmer's reference manual |
| 16:24:20 | preglow | jyp: http://glow.m0f0.net/rockbox/dsptest.c |
| 16:24:57 | Sucka | hehe, that gave me a rather entertaining mental image of "the family programmer" |
| 16:25:23 | jyp | preglow: thanks |
| 16:25:28 | ashridah | sucka: yeah. it's a little ambiguous. |
| 16:25:47 | ashridah | sucka: obviously, it means 'the [coldfire] family programmer reference' |
| 16:26:40 | preglow | jyp: all that code does is write a sawtooth filtered by a very resonant iir filter |
| 16:26:47 | preglow | jyp: but it's done using the emac :) |
| 16:26:50 | Bagder | check the daily build table now |
| 16:27:18 | Bagder | its not true, but it'll look like that from now on |
| 16:27:31 | jyp | preglow: I don't know what a iir filter is |
| 16:28:40 | jyp | Bagder: cool ;) |
| 16:29:10 | Bagder | I'll try to add an estimated time of completion as well |
| 16:29:14 | jyp | "Build to in ..." ;) |
| 16:29:19 | jyp | great :) |
| 16:29:31 | amiconn | Bagder: Looks a bit ugly, imho |
| 16:29:38 | Bagder | hehe |
| 16:30:05 | Bagder | any suggestions? |
| 16:30:14 | amiconn | "How many warnings do you get today?" |
| 16:30:18 | DeadMan | Oh this is wonderful. A small batch of Cross & Blackwell worcester sauce have cancer causing dye in them. I've been using that sauce for ages. |
| 16:30:45 | jyp | make "Build in progress" scroll as in markee :P |
| 16:31:02 | Lynx_ | doesn't worcester sauce generally cause cancer? ;) |
| 16:31:09 | DeadMan | :P |
| 16:31:16 | HCl | doesn't breathing air cause cancer ? :p |
| 16:31:47 | bobTHC | smoke weed cause cancer ? ;) |
| 16:32:01 | Lynx_ | HCl: only in places where large amounts of worcester sauce are used or consumed ;) |
| 16:32:57 | Lynx_ | It's the worcester aerosols you have to worry about ;) |
| 16:33:07 | DeadMan | heh |
| 16:33:34 | ashridah | preglow: bah. where's sinetab.h? :) |
| 16:33:46 | preglow | ashridah: hhaha, gimme a sec |
| 16:33:52 | preglow | ashridah: that part isn't called anyway |
| 16:34:07 | preglow | ashridah: it's there now |
| 16:37:53 | ashridah | preglow: hmm. just exited immediately here |
| 16:38:05 | preglow | ashridah: look in your root |
| 16:38:09 | preglow | there should be a test.raw there |
| 16:38:53 | ashridah | aah, right |
| 16:39:33 | preglow | it's 32 bit, big endian, 44100hz samplerate and mono |
| 16:39:35 | preglow | if you want to load it |
| 16:39:36 | preglow | heh |
| 16:39:47 | preglow | it's just a testing tool |
| 16:40:23 | HCl | http://glow.m0f0.net/rockbox/dsptest.c |
| 16:40:44 | ashridah | assuming i can even remember what i've got that'll play headerless files. |
| 16:40:50 | HCl | o.o |
| 16:40:51 | HCl | sorry |
| 16:40:53 | preglow | ashridah: i use sound forge |
| 16:40:54 | HCl | pasted by accident |
| 16:41:22 | | Join XShocK [0] (~cddef002@labb.contactor.se) |
| 16:42:00 | ashridah | so what's in cvs currently has 140MHz enabled? |
| 16:42:05 | ashridah | because it seemed a lot quicker |
| 16:42:28 | preglow | don't think so |
| 16:43:03 | preglow | no commits from linus |
| 16:43:08 | DeadMan | phoned the people who make the sauce and checked the expiry date against the batches and it's fine. but apparently other foodstuffs may also contain this illegal dye. how nice. |
| 16:43:14 | HCl | i say, don't be so paranoid and just live. |
| 16:43:19 | HCl | we're all gonna die. |
| 16:43:23 | HCl | its just a matter of when. |
| 16:43:24 | DeadMan | heh. damned news |
| 16:43:40 | | Quit XShocK (Client Quit) |
| 16:44:02 | preglow | DeadMan: you can rest assured that for every thing you eat you know there's dangerous shit in, there are twenty more you don't know of |
| 16:44:04 | ashridah | well. i'm hitting the sack. |
| 16:44:05 | | Quit ashridah ("sleep") |
| 16:44:15 | ripnetuk | "life is a sexually transmitted terminal disease" |
| 16:44:23 | preglow | ripnetuk: ahahahahah |
| 16:44:37 | * | DeadMan lifes is full of risks |
| 16:44:41 | DeadMan | -s |
| 16:45:27 | preglow | i've just got bought myself a couple of tasty beers for tonight, and i know they're not good for my health |
| 16:45:33 | preglow | hell, i even smoke occasionally :/// |
| 16:45:41 | DeadMan | Some dude on TV the other day pee'd on an electrified fence as a stunt. What an idiot. |
| 16:45:49 | preglow | hahaha |
| 16:46:00 | preglow | i've seen that as well |
| 16:46:10 | DeadMan | Compared it to being kicked in the nads with needled boots. |
| 16:46:19 | Sucka | :S |
| 16:46:22 | preglow | i've peed on an electrified fence myself |
| 16:46:23 | Sucka | ouch |
| 16:46:33 | DeadMan | preglow for real? |
| 16:46:34 | preglow | i was very young, though |
| 16:46:37 | DeadMan | lol |
| 16:46:38 | preglow | DeadMan: yes |
| 16:46:43 | DeadMan | and look how you turned out :) |
| 16:46:48 | preglow | i used to live right by some horses |
| 16:46:50 | preglow | hahaha |
| 16:47:13 | DeadMan | what were you doing with your wizzer out around horses? nevermind. forget I asked. ;) |
| 16:47:21 | ripnetuk | preglow - is it true that it really burns your 'old man'? |
| 16:47:26 | DeadMan | get back on-topic |
| 16:47:41 | preglow | ripnetuk: nah, just hurts |
| 16:47:48 | preglow | ripnetuk: can't remeber that well, thoguh |
| 16:47:52 | HCl | nah, they did it on mythbusters the other day. |
| 16:47:57 | HCl | he just got shocked |
| 16:48:56 | preglow | well, mine is in perfect condition, i don't think i permanently harmed it |
| 16:49:16 | HCl | too much information. |
| 16:49:40 | preglow | glad to be of assistance |
| 16:49:50 | preglow | i even touched the very same electrical fence with an iron rod once |
| 16:49:58 | preglow | but hey, i've never claimed i'm very smart :) |
| 16:50:09 | preglow | as a matter of fact, i've repeatedly stated the opposite |
| 16:50:18 | DeadMan | stick your tongue on it |
| 16:50:45 | preglow | DeadMan: no electrical fences nearby anymore, hehe |
| 16:53:53 | rasher | Probably for the better. |
| 16:54:59 | HCl | :P |
| 16:55:30 | jyp | Whoops my neighbor got a heart attack |
| 16:55:39 | HCl | o.o |
| 16:55:42 | HCl | did he die? :( |
| 16:55:48 | HCl | or she |
| 16:57:10 | *** | Saving seen data "./dancer.seen" |
| 16:58:08 | jyp | Mm fortunately it was the hospital bringing him back, not taking him |
| 17:00 |
| 17:02:57 | Bagder | not that many warnings left now |
| 17:03:14 | HCl | :) |
| 17:04:55 | Bagder | build complete time estimation should show up next build, I think |
| 17:05:28 | bobTHC | less than 14 min i hope |
| 17:05:57 | | Join mecraw [0] (~mecraw@69.2.235.2) |
| 17:06:18 | Bagder | there haven't been any commits yet to trigger another build |
| 17:07:59 | Bagder | time to go |
| 17:08:50 | | Nick quelsaruk is now known as quel|out (~kvirc@80.103.134.240) |
| 17:09:57 | preglow | jyp: http://glow.m0f0.net/rockbox/filteredsaw.wav <- what dsptest.c sounds like, left channel is original signal, right is filtered |
| 17:10:34 | preglow | jyp: it's the process that's used for making equalizers |
| 17:10:37 | | Join G [0] (~tscript24@g-001.osl255.netcom.no) |
| 17:10:45 | G | hehe |
| 17:10:48 | | Nick G is now known as thegeek (~tscript24@g-001.osl255.netcom.no) |
| 17:10:51 | thegeek | just reading the log |
| 17:10:58 | thegeek | had to comment |
| 17:11:14 | thegeek | I've peed on an electrified fence too;) |
| 17:11:20 | preglow | haven't we all, heh |
| 17:11:25 | thegeek | hehe |
| 17:11:31 | ripnetuk | i feel left out having never peed on a electric fence :) |
| 17:11:37 | preglow | ripnetuk: not too late to remedy it |
| 17:11:42 | ripnetuk | :) |
| 17:11:45 | thegeek | humhum |
| 17:11:46 | * | ripnetuk shudders |
| 17:12:06 | DeadMan | My neighbour died of a heart attacklast week |
| 17:12:56 | bobTHC | abad luck |
| 17:13:14 | bobTHC | s/abad/bad |
| 17:13:25 | bobTHC | :( |
| 17:13:30 | * | DeadMan wonders how easy it would be to do ac3 passthru on optical out on the iRiver |
| 17:14:15 | preglow | i don't know |
| 17:14:37 | rasher | Wasn't there something that made this impossible? |
| 17:15:43 | DeadMan | maybe the player can't pass raw |
| 17:15:53 | DeadMan | all goes via the DAC |
| 17:16:04 | preglow | the chip it self is capable of it |
| 17:16:10 | preglow | depends on how it's hooked up |
| 17:16:21 | DeadMan | indeed |
| 17:16:23 | preglow | i don't see the point of having something already digital go through the codec |
| 17:17:01 | DeadMan | easier to make a straight path for all codecs I guess |
| 17:17:09 | DeadMan | rather than re-route for raw |
| 17:17:19 | DeadMan | well anyhow I don't know Linus might know |
| 17:19:19 | | Join muesli_ [0] (muesli_tv@1Cust191.tnt1.hnr2.deu.da.uu.net) |
| 17:19:34 | muesli_ | hi |
| 17:21:04 | | Quit Cassandra_ (Read error: 110 (Connection timed out)) |
| 17:21:23 | | Join Cassandra_ [0] (~christi@213.78.122.37) |
| 17:22:10 | * | DeadMan drinks the tea of captains. Well bald captains of starships that is ;) |
| 17:23:02 | preglow | haha |
| 17:23:11 | preglow | tea, earl grey, hot |
| 17:23:34 | DeadMan | :) |
| 17:23:40 | preglow | gray, i mean |
| 17:23:50 | * | DeadMan pulls his tunic down |
| 17:24:02 | DeadMan | Make it so |
| 17:24:34 | preglow | think i'll brew myself a cuppa as well |
| 17:25:10 | DeadMan | Tea Hee |
| 17:25:17 | preglow | DeadMan: http://glow.m0f0.net/music/darkmateria_the_picard_song.mp3 |
| 17:25:18 | preglow | :) |
| 17:25:24 | DeadMan | yeah got it ;) |
| 17:25:42 | DeadMan | Do you know the show Little Britain? |
| 17:25:49 | preglow | nope |
| 17:25:55 | DeadMan | ok |
| 17:26:02 | DeadMan | won't be relevant then |
| 17:26:26 | | Quit thegeek (Read error: 113 (No route to host)) |
| 17:28:49 | | Join G [0] (~tscript24@g-001.osl255.netcom.no) |
| 17:36:32 | | Join XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net) |
| 17:38:11 | | Quit DrRick () |
| 17:38:36 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 17:38:41 | AC | hi |
| 17:38:50 | AC | is the iriver little endian? |
| 17:40:21 | | Quit Patr3ck_ ("User pushed the X - because it's Xtra, baby") |
| 17:40:42 | linuxstb | AC: No. |
| 17:41:30 | AC | ok |
| 17:41:51 | linuxstb | It's Motorola 68000 based. |
| 17:41:56 | preglow | most things are big endian, i think |
| 17:42:01 | preglow | apart from intel and vax |
| 17:42:09 | preglow | some correct me if they know of more |
| 17:42:20 | AC | hmmm |
| 17:42:32 | AC | LD /home/austriancoder/rockbox/build/wv2wav.elf/home/austriancoder/rockbox/build/libwavpack.a(bits.o): In function `little_endian_to_native':/home/austriancoder/rockbox/apps/codecs/libwavpack/bits.c:100: undefined reference to `_ctype_'/home/austriancoder/rockbox/build/libwavpack.a(bits.o): In function `native_to_little_endian':/home/austriancoder/rockbox/apps/codecs/libwavpack/bits.c:132: undefined reference to `_ctype_'/home/austriancoder/rockbox/build/l |
| 17:43:21 | AC | i dont know what i am doing wrong |
| 17:44:29 | linuxstb | AC: I'm happy to have a look at it if you want me to. |
| 17:45:02 | AC | i think it is the makefile |
| 17:45:24 | AC | i will upload it.. mom |
| 17:45:50 | | Part fubar |
| 17:47:07 | linuxstb | AC: I think I know what the problem is. |
| 17:48:03 | linuxstb | _ctype_ is a variable defined in firmware/common/ctype.c, but the firmware library isn't linked against the plugins. |
| 17:49:30 | linuxstb | A quick fix would be to simply copy the _ctype_ variable from common/ctype.c into wv2wav.c |
| 17:51:15 | * | DeadMan listens to Moby's new album |
| 17:52:00 | AC | linuxstb: will try it |
| 17:52:06 | AC | here is my makefile: x-factor.dyndns.org/rockbox/Makefile |
| 17:53:44 | linuxstb | AC: The "isdigit" function is a macro that makes use of _ctype_ - that's where the dependency is. I don't think you can fix it with the Makefile. |
| 17:54:45 | AC | how should i fix it? |
| 17:55:03 | | Quit bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 17:56:12 | preglow | how many bands do a portable mp3 player equalizer usually have? |
| 17:56:26 | preglow | those that don't just have high cut and low cut, that is |
| 17:56:36 | linuxstb | AC: For now, just copy _ctype_ from firmware/common/ctype.c into wv2wav.c We can try and think of a better fix later. |
| 17:57:28 | linuxstb | AC: I think that native_to_little_endian function is only used by the metadata parser anyway, so we can probably strip it out (or rewrite it). |
| 17:57:35 | DeadMan | usualy 5 or 5 bands |
| 17:57:41 | DeadMan | or 6 rather |
| 17:58:03 | | Quit ripnetuk ("Leaving") |
| 17:58:05 | DeadMan | I'd like a parametric eq myself :) |
| 17:58:58 | DeadMan | actually a basic player has low mid and top or just low and top |
| 17:59:00 | preglow | yes, i'll be trying to make one |
| 17:59:09 | preglow | five bands'll be nice |
| 17:59:29 | preglow | thought i'd just get the boring math out of the way now |
| 17:59:33 | AC | linuxstb: why to wv2wav? the symbol is not found in the codec |
| 17:59:45 | DeadMan | I usually only push the top right up. I like my music to cut through |
| 18:00 |
| 18:00:08 | DeadMan | and I like to hear the hi-hats and understand the vocals |
| 18:00:35 | DeadMan | I dislike too much midrange |
| 18:00:55 | linuxstb | AC: It's used by the codec, but not found in the plugin. I think that libwavpack.a is being generated OK, the error is only when it is being linked to wv2wav |
| 18:01:09 | AC | yep |
| 18:01:10 | DeadMan | or bass end that is a dull thud or rumble rather than a solid kick in the chest ;) |
| 18:01:28 | linuxstb | AC: we also don't want to change the codec .c files if we can avoid it. |
| 18:02:22 | AC | in wv2wav i got errors |
| 18:02:24 | AC | like |
| 18:02:43 | AC | CC wv2wav.cwv2wav.c:32: error: `_C' undeclared here (not in a function)wv2wav.c:32: error: initializer element is not constant |
| 18:02:51 | AC | so we must fix it in the codec, i think |
| 18:03:01 | AC | also symbol abs is unkown in the codec |
| 18:04:17 | AC | ctype stuff fixed |
| 18:05:14 | AC | added const char _ctype_[257]={ to bits.c in the codec |
| 18:05:51 | preglow | DeadMan: i never use the equalizer, but i'd like making one |
| 18:07:50 | AC | linuxstb: compiles now fine |
| 18:08:22 | linuxstb | AC: Good news. Is your wv2wav program working? |
| 18:09:22 | AC | i must add the decoding loop and then i will try it |
| 18:09:23 | AC | :) |
| 18:13:33 | | Join muesli- [0] (muesli_tv@c-180-220-75.cvx-h.dial.de.ignite.net) |
| 18:16:21 | | Quit muesli- (Client Quit) |
| 18:16:40 | | Join muesli- [0] (muesli_tv@c-180-220-75.cvx-h.dial.de.ignite.net) |
| 18:17:43 | | Quit muesli_ (Read error: 113 (No route to host)) |
| 18:18:18 | DeadMan | preglow the only thing I turn up is the treble boost and nothing else |
| 18:18:24 | lolo-laptop | hmm, for gapless playback, is it not possible to do processing on the PCM audio buffer before sending it to the DAC at the track boundaries? |
| 18:20:03 | preglow | lolo-laptop: what processing? |
| 18:20:28 | linuxstb | lolo-laptop: I think that part of the gapless playback belongs iin the codecs - i.e. the codec code will be responsible for stripping off any padding samples from the final frame. |
| 18:20:40 | linuxstb | So they will never be copied into the PCM buffer |
| 18:21:10 | lolo-laptop | linuxstb: that would work too −− my point was that the gapless howto on the wiki implies that it can _only_ be done at encode time... but if the PCM data is processed by either the PCM buffer or the codec... |
| 18:21:53 | linuxstb | That howto only really applies to the Archos. |
| 18:21:55 | preglow | yes |
| 18:22:01 | lolo-laptop | ahh |
| 18:22:06 | preglow | that does not apply when we can code our own codecs |
| 18:22:11 | lolo-laptop | because there isn't a codec in the archos. |
| 18:22:15 | lolo-laptop | gotcha |
| 18:22:15 | lolo-laptop | thanks |
| 18:22:23 | preglow | we might do some stripping code for mp3s that don't support accurate track length |
| 18:22:52 | linuxstb | It is still a good idea to follow that advice and make gapless MP3s in the first place. It's just that with software decoding, we have the opportunity to repair broken encodings. |
| 18:23:56 | lolo-laptop | linuxstb: well vorbis is by it's nature not as gap inducing as mp3 right? |
| 18:24:05 | preglow | lolo-laptop: vorbis supports no gaps at all |
| 18:24:15 | preglow | lolo-laptop: vorbis store the exact tract length |
| 18:24:18 | linuxstb | I don't know vorbis at all, but I assume it has a "track length" field in the header. |
| 18:24:24 | lolo-laptop | preglow: cool. |
| 18:24:27 | preglow | track length, not tract... |
| 18:24:29 | DeadMan | but the player needs to be able to playback with 0 gaps :) |
| 18:24:35 | preglow | no problem |
| 18:24:46 | DeadMan | coz at present it still puts gaps between Ogg tracks |
| 18:25:04 | preglow | yes, but that's the iriver firmware |
| 18:25:26 | DeadMan | aye |
| 18:25:45 | linuxstb | There's two different issues for gapless playback - 1) (only applicable to stupid codecs like MP3) remove padding from final frame and 2) Ensure the PCM buffer is never empty. |
| 18:26:44 | linuxstb | (actually, it's not MP3's fault, it's just that there is no container format used). |
| 18:27:02 | | Quit G (Read error: 54 (Connection reset by peer)) |
| 18:27:20 | preglow | so it's ogg that stores the track length for vorbis? |
| 18:27:30 | lolo-laptop | the iRiver firmware is just stupid about loading oggs −− it doesn't start loading the next one _at all_ until the prior one is completely decoded and sent to the DAC... −− all it would have to do is pre-read the header of the next song to be played and it owuldn't gap (at least not so much) |
| 18:27:37 | lolo-laptop | preglow: yes. |
| 18:28:03 | preglow | lolo-laptop: it's really stupid, yes, the firmware is able to preload, it does it for mp3s that are bigger than the buffer |
| 18:28:10 | preglow | lolo-laptop: they just don't utilize it the right way |
| 18:28:41 | lolo-laptop | nod |
| 18:28:51 | preglow | unless the track is too long to fit the whole buffer at once, the firmware just loads whole tracks, it seems |
| 18:28:55 | preglow | that's a real waste of mp3 buffer |
| 18:29:00 | lolo-laptop | heh |
| 18:29:13 | preglow | i've never seen it buffer in the middle of a short track |
| 18:29:14 | preglow | not once |
| 18:29:19 | preglow | it always buffers at the start of the next one |
| 18:29:40 | lolo-laptop | yeah, they do only -very- basic battery saving buffering, nothing smart. |
| 18:29:40 | | Quit AC ("CGI:IRC (EOF)") |
| 18:30:05 | lolo-laptop | actually what's funny is that my iRiver slimx350 I think did prebuffering of the next track and but the H340 doesn't. |
| 18:34:11 | | Join Hohoman [0] (~inte@hohoman.olf.sgsnet.se) |
| 18:36:41 | preglow | the h1x0 series is discontuned, yes? |
| 18:36:41 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
| 18:37:37 | | Join AC [0] (~5078751e@labb.contactor.se) |
| 18:38:29 | AC | linuxtb: who must i use the codec on a wv file? |
| 18:39:10 | Bagder | wavpack |
| 18:39:16 | AC | sure |
| 18:39:36 | AC | but how do i start the codec? |
| 18:39:46 | AC | i want to test, if it works or not |
| 18:40:22 | AC | in "open with" there are now codecs listed |
| 18:40:29 | linuxstb | You need to modify "viewers.config" in the plugins directory to add a line to link ".wv" files to wv2wav, then you can simply "play" the wv file whilst browsing in Rockbox. |
| 18:40:47 | AC | ah ok |
| 18:41:21 | linuxstb | You need to do a full install on your iRiver - i.e. "make zip" and then unzip the rockbox.zip on your iRiver. Remember to reboot to make Rockbox re-read viewers.config |
| 18:42:23 | AC | make zip i have done... restarting rockbox |
| 18:43:12 | AC | rebooting to linux |
| 18:43:52 | | Quit AC ("CGI:IRC (EOF)") |
| 18:44:23 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 18:45:47 | * | LinusN has a theory why 140MHz screws up the ATA timing |
| 18:46:05 | LinusN | and i'm afraid it's bad news |
| 18:46:29 | lolo-laptop | *cry*? |
| 18:46:42 | preglow | the suspense! |
| 18:46:46 | preglow | pray tell |
| 18:46:55 | linuxstb | You're supposed to tell us good news at the same time. |
| 18:47:10 | LinusN | if i'm right about this, there are no good news |
| 18:47:37 | LinusN | the ata signal buffering is not designed correctly in the hardware |
| 18:48:20 | preglow | great |
| 18:48:37 | preglow | well, what does it do apart from buffering that's screwing up the timing? |
| 18:48:46 | preglow | and: is it modable? :) |
| 18:49:25 | LinusN | so it violates the ata specification regarding the DIOR setup time |
| 18:49:48 | LinusN | i'll have to hook up the logic analyzer to verify |
| 18:50:08 | LinusN | this may mean that we have to reduce the cpu frequency when doing disk operation |
| 18:50:11 | preglow | ooohh, you've got one of those |
| 18:50:23 | amiconn | LinusN: I thought your conclusions were from doing logic analysis |
| 18:50:30 | LinusN | (which could explain the horrible disk performance in the original firmware) |
| 18:50:42 | LinusN | no, from reading my schematics |
| 18:50:50 | linuxstb | And I'm assuming that changing cpu frequency would interrupt audio playback? |
| 18:50:58 | LinusN | no |
| 18:51:09 | LinusN | the audio clocks are separate |
| 18:51:33 | [IDC]Dragon | the CPU has no means for different timing on different address ranges? |
| 18:51:44 | LinusN | oh yes |
| 18:51:49 | linuxstb | So could we work around it and only slow down the CPIU for disk accesses? |
| 18:51:52 | LinusN | but it's not a matter of waitstates |
| 18:52:00 | linuxstb | ^CPU |
| 18:52:03 | LinusN | linuxstb: yes |
| 18:52:47 | LinusN | it's too early to say how bad it is, i'll have to analyze it |
| 18:53:15 | linuxstb | Sounds like a mess. |
| 18:53:26 | LinusN | so far it's just a theory |
| 18:53:53 | linuxstb | Do you think it's different in H120/H140 or in different revisions (were there different revisions?) |
| 18:54:00 | preglow | i was hoping the horrible disk performance in the iriver firmware was due to bad programming |
| 18:54:06 | LinusN | me too |
| 18:54:21 | LinusN | i don't know about more than one revision |
| 18:54:33 | LinusN | haven't seen many open irivers yet |
| 18:54:44 | LinusN | (well, the H110 is different) |
| 18:54:48 | preglow | i haven't seen a rev number on mine, at least |
| 18:54:55 | preglow | _in_ mine |
| 18:54:59 | LinusN | anyway, i have to go, maybe i'll pop in here later |
| 18:55:04 | preglow | ait, have fun |
| 18:55:05 | amiconn | If your theory is correct, I wonder whether there are mp3 player hw designs that don't need ugly workarounds... |
| 18:55:17 | preglow | amiconn: lots of them in the archos? |
| 18:55:24 | LinusN | several |
| 18:55:28 | LinusN | cu guys! |
| 18:55:30 | | Part LinusN |
| 18:55:38 | amiconn | preglow: Quite a number |
| 18:56:04 | amiconn | (1) Necessity for bitswap, because SPI bit order of the MAS doesn't match that of the CPU |
| 18:56:21 | | Join acathla [0] (~acathla@acathla.dyndns.org) |
| 18:56:22 | preglow | hahah |
| 18:56:26 | amiconn | Same on Ondio, only worse. MAS bitswap plus MMC bitswap |
| 18:57:11 | *** | Saving seen data "./dancer.seen" |
| 18:57:23 | preglow | have we even checked that the coldfire in the original firmware runs at 140 mhz? |
| 18:59:00 | amiconn | (2) Shortcoming in the player that was fixed later for the recorder: The MAS has a demand pin. It is useful to get an interrupt for both start & stop demand, however, the SH interrupt only triggers on hogh->low. So you need to invert the signal and put it on 2 different port pins. |
| 18:59:19 | amiconn | The player doesn't have that, so start_demand has to be polled... |
| 18:59:27 | preglow | haha |
| 18:59:50 | amiconn | There are more... |
| 19:00 |
| 19:00:25 | preglow | what endianess is the sh? |
| 19:00:34 | amiconn | Big endian, as the coldfire |
| 19:02:07 | | Join sox [0] (~sox@c-813ee255.733-1-64736c10.cust.bredbandsbolaget.se) |
| 19:04:20 | jyp | Note for linus when he'll read the logs ... |
| 19:04:53 | jyp | Reversing the Archos' firmware shows a cpu-frequency reduce as well |
| 19:05:03 | jyp | upon some disk accesses |
| 19:05:14 | preglow | haha |
| 19:05:17 | jyp | (or something that looks very much like it) |
| 19:05:33 | [IDC]Dragon | down to how much? |
| 19:05:49 | jyp | Let me have a look |
| 19:05:59 | [IDC]Dragon | they must still be able to play while doing so |
| 19:06:26 | [IDC]Dragon | this hardware quirk tightens the codec requirements |
| 19:06:36 | amiconn | preglow: Speaking about ata: (3) 16 bit ATA data is little endian, so it has to be swapped on a big endian machine. There could have been a buffer that does this... |
| 19:06:47 | preglow | amiconn: ahahahha |
| 19:06:57 | preglow | there are simple parts for doing that |
| 19:07:05 | rasher | amiconn: sounds like a bucket of fun |
| 19:07:10 | [IDC]Dragon | amiconn: or just crossing the wires |
| 19:07:24 | preglow | which would be even simpler, yes |
| 19:07:27 | preglow | hahah |
| 19:07:31 | jyp | [IDC]Dragon: it's very difficult to tell by reading the code, because the frequency depends on a global |
| 19:07:32 | preglow | it's REMARKABLE they didn't think of that |
| 19:07:34 | amiconn | You must still be able to read byte data.. |
| 19:07:58 | [IDC]Dragon | yes, but this is less |
| 19:08:08 | amiconn | Am, hum, of course, simple |
| 19:08:26 | amiconn | You just need to read the other half of the 16 bit port... |
| 19:08:49 | amiconn | SO crossing the wires would have done the trick.... |
| 19:11:20 | amiconn | Bagder: r u there? |
| 19:11:50 | preglow | crossing the wires would be everything required, yes |
| 19:11:55 | preglow | it's amazing they didn't think of that |
| 19:11:55 | sox | hoy all, just ran cvs update and tried to build, got this weird error |
| 19:11:56 | sox | c-813ee255:~/rockbox/build svante$ make -nw |
| 19:11:56 | sox | make: Entering directory `/Users/svante/rockbox/build' |
| 19:11:58 | sox | make -C /Users/svante/rockbox/firmware |
| 19:11:58 | sox | make[1]: Entering directory `/Users/svante/rockbox/firmware' |
| 19:11:58 | sox | make[1]: *** No rule to make target `#pragma', needed by `/Users/svante/rockbox/build/dep-firmware'. Stop. |
| 19:11:58 | DBUG | Enqueued KICK sox |
| 19:11:58 | sox | make[1]: Leaving directory `/Users/svante/rockbox/firmware' |
| 19:12:00 | sox | make: *** [all] Error 2 |
| 19:12:02 | sox | make: Leaving directory `/Users/svante/rockbox/build' |
| 19:12:04 | sox | whats this about? |
| 19:12:05 | preglow | 'cause that's data you have when you design the hardware as well |
| 19:12:11 | sox | sorry for floodin'... |
| 19:12:16 | preglow | i've heard pastebins are nice |
| 19:12:36 | preglow | why -nw ? |
| 19:12:41 | sox | to get more info |
| 19:12:45 | amiconn | sox: YOu'll probably need to reconfigure |
| 19:12:49 | linuxstb | sox: Bagder committed some big build changes today - did you update everything, and also re-run configure? |
| 19:12:50 | sox | i did that... |
| 19:13:06 | linuxstb | Are you on cygwin? |
| 19:13:10 | sox | ill wipe the whole build dir again |
| 19:13:18 | sox | nope, mac os x-darwin |
| 19:13:29 | amiconn | No sims build on cygwin now... the build bails out really early: |
| 19:13:37 | preglow | ahh, darwin |
| 19:13:50 | preglow | as long as it uses gnu tools, it should really be ok, but i don't think very many have tried that |
| 19:13:51 | linuxstb | What are you trying to build? |
| 19:14:12 | amiconn | CC common/disk.c |
| 19:14:13 | amiconn | In file included from /home/Administrator/rb-patched/uisimulator/common/file.h:62, |
| 19:14:13 | amiconn | from common/disk.c:26: |
| 19:14:13 | DBUG | Enqueued KICK amiconn |
| 19:14:13 | amiconn | /home/Administrator/rb-patched/firmware/include/file.h:49: error: conflicting types for `ssize_t' |
| 19:14:13 | amiconn | /usr/include/sys/types.h:170: error: previous declaration of `ssize_t' |
| 19:14:13 | *** | Alert Mode level 1 |
| 19:14:13 | amiconn | make[1]: *** [/home/Administrator/rb-patched/simulator-build/w11-ondiofm/common/disk.o] Error 1 |
| 19:14:17 | amiconn | make[1]: Leaving directory `/home/Administrator/rb-patched/firmware' |
| 19:14:17 | amiconn | make: *** [all] Error 2 |
| 19:14:35 | preglow | hmm |
| 19:15:13 | | Join R3nTiL [0] (~zorroz@83.69.98.178) |
| 19:20:43 | amiconn | Hmm. I don't have an idea how this can be solved easily. The problem is jyp's long policy. |
| 19:21:13 | amiconn | sys/types.h defines ssize_t as int for 32 bit machines, and as long for 16 bit machines. |
| 19:21:30 | preglow | what? |
| 19:21:34 | preglow | that can't be right |
| 19:21:41 | amiconn | Rockbox' file.h now unconditionally defines it as long |
| 19:21:42 | preglow | unless it's got a 32 bit address space |
| 19:21:55 | | Part acathla ("Byebye") |
| 19:22:12 | amiconn | ..so there is a conflict on a 32 bit platform :( |
| 19:22:25 | amiconn | #if defined(__INT_MAX__) && __INT_MAX__ == 2147483647 |
| 19:22:25 | amiconn | typedef int _ssize_t; |
| 19:22:25 | amiconn | #else |
| 19:22:25 | *** | Alert Mode level 2 |
| 19:22:25 | amiconn | typedef long _ssize_t; |
| 19:22:25 | *** | Alert Mode level 3 |
| 19:22:25 | amiconn | #endif |
| 19:22:51 | amiconn | This is actually in _types.h, which gets included by types.h |
| 19:25:10 | [IDC]Dragon | gotta go |
| 19:25:13 | | Quit [IDC]Dragon ("CGI:IRC") |
| 19:32:26 | *** | Alert Mode OFF |
| 19:38:21 | | Join Stryke` [0] (~Chairman8@resnet-241-86.resnet.umbc.edu) |
| 19:40:06 | | Quit R3nTiL () |
| 19:48:55 | Ctcp | Ignored 2 channel CTCP requests in 2 minutes and 15 seconds at the last flood |
| 19:48:55 | * | jyp is back |
| 19:49:45 | jyp | amiconn, preglow |
| 19:49:58 | jyp | Something I need to do ? |
| 19:57:18 | amiconn | I don't think so. The problem now occurs because the definition of ssize_t in rockbox and in the system are different for 32 bit machines, and with the new build system both definitions are included. |
| 19:57:53 | amiconn | We need a way to disable the definition in file.h for the simulator builds. |
| 19:58:11 | jyp | Shouldn't file.h include the sys |
| 19:58:16 | preglow | why ssize_t? isn't size_t good enough? |
| 19:58:29 | jyp | tem include instead of defining size_t by itself ? |
| 19:59:43 | amiconn | Yes. uisimulator/common/file.h does that, but with the new build system firmware/file.h gets included too |
| 20:00 |
| 20:01:39 | amiconn | Ah no, uisimulator/common/file.h does *not* include the system include, but firmware/file.h instead |
| 20:02:40 | jyp | I mean, can't firmware/file.h behave like uisimulator/common/file.h ? |
| 20:02:43 | amiconn | Hmm. There is a check in include/file.h that should prevent duplicate definition |
| 20:03:04 | amiconn | However, this doesn't seem to work on cygwin. Gah! |
| 20:03:32 | * | amiconn digs in cygwin's system includes |
| 20:04:30 | | Nick Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59) |
| 20:06:21 | | Join bg_ [0] (~chatzilla@adsl-68-78-228-166.dsl.mdsnwi.ameritech.net) |
| 20:21:04 | DeadMan | any uk folk here? |
| 20:21:28 | DeadMan | if so you may enjoy this http://eclectech.co.uk/veritasparty.php |
| 20:24:57 | amiconn | Grr, I am still unable to compile a simulator on cygwin :( |
| 20:29:40 | HCl | o.o. |
| 20:29:44 | HCl | hi hi |
| 20:29:52 | HCl | any luck with the makefile for rockboy ami? |
| 20:30:20 | amiconn | It works... for the target, but needs afjustment for the new build system. |
| 20:30:56 | amiconn | Since I cannot test simulator builds, I have to hold this back until the cygwin sim build issues are fixed. |
| 20:31:42 | amiconn | I have no idea how to fix that yet.... maybe I need Bagder's help |
| 20:43:59 | HCl | okies |
| 20:45:27 | amiconn | Btw, did you check the .map file? |
| 20:46:05 | amiconn | Adding .code, .data and .rodata gives only ~65 KB, the rest is .bss space. |
| 20:46:54 | amiconn | The biggest part (256KB) is the patpix array |
| 20:48:26 | HCl | hmmm. |
| 20:48:41 | HCl | i haven't seen the patpix array, i'll take a look at it |
| 20:48:55 | bg_ | are there any other GB emulators released under GPL? |
| 20:49:04 | bg_ | besides gnuboy that is |
| 20:49:08 | HCl | ah. |
| 20:49:19 | HCl | bg_: one... don't remember what it was called. |
| 20:49:23 | HCl | it was windows only |
| 20:49:28 | HCl | didn't seem very portable |
| 20:49:30 | amiconn | Another interesting fact: The routine that updates the patpix array is a real CPU hog - in C. |
| 20:49:32 | bg_ | ahh |
| 20:49:49 | HCl | amiconn: kay, do you happen to know what patpix is used for? |
| 20:50:05 | amiconn | It is one of the routines that gnuboy provides i386 asm routines for. |
| 20:50:22 | HCl | mmmm. |
| 20:50:25 | amiconn | I think I can speed it up by at least factor 5 on SH1 |
| 20:50:33 | HCl | we should probably write asm versions for it |
| 20:50:39 | amiconn | ...by using asm of course |
| 20:51:16 | amiconn | I don't know exactly what this array is used for, but it certainly has to do with gfx output. |
| 20:52:35 | amiconn | updatepatpix() looks like it puts 8x8 pixel tiles into the array, in various orientations |
| 20:53:28 | amiconn | I *guess* this is why pokemon is so slow when the background changes a lot |
| 20:53:36 | HCl | patpix... |
| 20:53:39 | HCl | tile pattern cache |
| 20:53:47 | HCl | according to the HACKING doc |
| 20:53:56 | HCl | updatepatpix() - updates tile pattern cache. |
| 20:55:40 | HCl | it sounds as if its supposed to be a speed optimization |
| 20:56:51 | HCl | mhm. |
| 20:57:03 | HCl | there's a bit of a description to why they do what they do at the beginning of the lcd section |
| 20:57:15 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:10:56 | XShocK | i spotted the link to a MPEG decoder at page http://www.uclinux.org/ports/coldfire/nettelmp3.html |
| 21:11:01 | XShocK | http://www.uclinux.org/ports/coldfire/cf-mpegdec_19991021.tar.gz |
| 21:11:30 | XShocK | did someone looked at it? it says at 90 MHZ on 5307 it is close to real-time |
| 21:12:53 | XShocK | support all three layers, 1,2, and 3 |
| 21:13:29 | XShocK | this one is a bit old though.. year 1999 |
| 21:18:39 | | Join necrogl [0] (~522bbf09@labb.contactor.se) |
| 21:18:42 | necrogl | hey |
| 21:19:14 | | Join DrRick [0] (DrRick@81-86-81-232.dsl.pipex.com) |
| 21:19:46 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 21:19:52 | | Quit necrogl (Client Quit) |
| 21:20:02 | LinusN | amiconn: the iriver hardware swaps the ata bytes |
| 21:20:10 | amiconn | Nice :) |
| 21:20:30 | LinusN | at least they tried to do it right :-) |
| 21:20:46 | amiconn | Did you read about the cygwin build issues? |
| 21:21:03 | amiconn | I can't build *any* simulator :( |
| 21:22:27 | linuxstb | XShock: That decoder definitely looks like it's worth investigating. I've had a quick look, but don't have time to try to get it running on the iRiver at the moment. |
| 21:22:39 | XShocK | http://members.aol.com/xanathus/mpegdec/download.htm the new version of |
| 21:23:28 | preglow | no emac :/ |
| 21:24:36 | preglow | 5307 has mac only, seems |
| 21:24:40 | amiconn | preglow: So adding emac support would lower the cpu requirements further (?) |
| 21:24:43 | preglow | but i couldn't see the code using it |
| 21:24:45 | preglow | amiconn: it should |
| 21:24:50 | XShocK | I found out that it was discussed before on Jan 6 2005, and decided that MAD as being full C implementation will e better, but since it is working only 40% of realtime on 140mhz, why not use this for m68k, and MAD for other players |
| 21:25:49 | LinusN | XShocK: is there a coldfire version of it? |
| 21:25:53 | XShocK | I would say "50Mhz recommended for realtime " is pretty cool |
| 21:26:37 | XShocK | it works on 5307 |
| 21:27:01 | preglow | LinusN: 5307 is a coldfire version |
| 21:27:06 | XShocK | so, i guess it will work on 5249 with minimum(if at all) changes. |
| 21:28:12 | preglow | coldfire model, whatever |
| 21:28:16 | LinusN | ah, was looking at that mac download page... |
| 21:29:38 | preglow | but hell, if we actually need to clock down the cpu while reading from the disk, requirements are starting to get hairy indeed |
| 21:29:49 | | Join G [0] (~tscript24@g-001.osl255.netcom.no) |
| 21:30:07 | preglow | might as well just not clock it at 140mhz at all |
| 21:30:14 | XShocK | Linus: sorry, put wrong link. :) |
| 21:30:43 | | Nick G is now known as thegeek (~tscript24@g-001.osl255.netcom.no) |
| 21:34:08 | LinusN | preglow: we'll see about that... |
| 21:34:11 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 21:34:21 | preglow | lots of lovely assembler |
| 21:35:40 | | Join hubble [0] (~hubble@0043a.umehus18.ac.se) |
| 21:39:37 | | Join skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net) |
| 21:42:17 | | Join arogan [0] (~a19f0414@labb.contactor.se) |
| 21:42:56 | arogan | hello, I've got a quick question on bookmarks |
| 21:43:01 | | Part LinusN |
| 21:43:05 | arogan | this is jukebox recorder 20 |
| 21:43:21 | arogan | I have it to automatically create a bookmark on stop |
| 21:43:40 | arogan | is there a way to NOT create a bookmark when stopping on the one off case that I don't want a book mark |
| 21:44:34 | arogan | like maybe some sort of key combination to stop without bookmarking? |
| 21:44:38 | amiconn | Nope. |
| 21:44:59 | arogan | ok. didn't think so since I couldn't find it int he docs |
| 21:45:09 | amiconn | You would have to set "create bookmark", to "ask", but then it would ask every time |
| 21:45:27 | arogan | yeah which I don't want since 90% I want to to go ahead and create a bookmark |
| 21:47:31 | | Join necrogl [0] (~bobakkama@82-43-191-9.cable.ubr07.newm.blueyonder.co.uk) |
| 21:47:42 | necrogl | hello |
| 21:47:48 | necrogl | anyone home? |
| 21:48:31 | necrogl | all these people online |
| 21:48:39 | necrogl | and no one wants to speak :( |
| 21:48:59 | necrogl | anyone? |
| 21:49:00 | preglow | if you'd not jump to conclusion after being here a mere minute, you'd find that we do indeed speak |
| 21:49:04 | preglow | when we have something to say |
| 21:49:11 | preglow | if you want to ask something, just ask it |
| 21:49:13 | necrogl | sorry |
| 21:49:22 | necrogl | ok |
| 21:49:25 | necrogl | i will |
| 21:49:27 | preglow | goodie |
| 21:49:34 | necrogl | that is better :D |
| 21:49:59 | necrogl | you lot make firmware for the archo jukebox righjt |
| 21:50:08 | preglow | yes |
| 21:50:10 | necrogl | ok |
| 21:50:16 | necrogl | i had a Archod JMB20 |
| 21:50:21 | necrogl | until is broke :( |
| 21:50:32 | necrogl | is that supported ? |
| 21:51:40 | necrogl | ok |
| 21:51:41 | preglow | wouldn't know, i'm in for the iriver players |
| 21:51:47 | necrogl | oh |
| 21:51:56 | necrogl | i played with a irirver once |
| 21:51:59 | preglow | give the guys a sec and someone'll answer |
| 21:52:02 | necrogl | they are weak |
| 21:52:11 | arogan | just curious what is the status of the bleeding edge builds for iriver (my brother has one)? |
| 21:52:18 | arogan | are they more or less functional? |
| 21:52:32 | amiconn | necrogl: No. See http://www.rockbox.org/twiki/bin/view/Main/NoDo#7_Archos_Multimedia_Gmini_suppor and http://www.rockbox.org/twiki/bin/view/Main/NonArchos |
| 21:52:40 | | Quit Aison (Read error: 104 (Connection reset by peer)) |
| 21:53:03 | bg_ | ive messed around with a few different HD players, iriver was by far the best |
| 21:53:04 | preglow | arogan: if you don't want sound, then yes, they do function |
| 21:53:06 | bg_ | ihp series |
| 21:53:18 | necrogl | i will admit |
| 21:53:22 | preglow | arogan: more or less only usable by developers right now, but it does function |
| 21:53:27 | necrogl | the iriver player have bad firmware |
| 21:53:34 | arogan | heh ok |
| 21:53:39 | necrogl | but |
| 21:53:49 | necrogl | i am interested in getting a ipod photto |
| 21:53:55 | necrogl | what firmware is there for that |
| 21:54:04 | necrogl | ? |
| 21:54:04 | | Join Aison [0] (~hans@zux166-181.adsl.green.ch) |
| 21:54:11 | preglow | well, apple's firmware, obviously |
| 21:54:14 | preglow | and that's that |
| 21:54:24 | preglow | afaik |
| 21:54:25 | necrogl | is apple firmware any good? |
| 21:54:30 | preglow | i wouldn't know |
| 21:54:37 | necrogl | does anyone? |
| 21:54:38 | bg_ | ive played with one, its simple |
| 21:54:42 | bg_ | easy to learn |
| 21:54:45 | bg_ | like most apple stuff |
| 21:54:49 | necrogl | ok |
| 21:54:51 | bg_ | even had some games |
| 21:54:55 | necrogl | cool |
| 21:54:56 | necrogl | games |
| 21:54:59 | bg_ | dont know about its advanced functionality |
| 21:55:04 | necrogl | ok |
| 21:55:05 | bg_ | but i still prefer i 140 |
| 21:55:16 | necrogl | that is the iriver one right |
| 21:55:17 | arogan | my guess I don't think you'll find any other mp3 player with the breadth of functionality that rockbox provides |
| 21:55:42 | necrogl | i jsut found this on your site |
| 21:55:43 | necrogl | http://www.rockbox.org/twiki/bin/view/Main/IpodLinux |
| 21:55:50 | bg_ | im patiently waiting for rockbox to work in my 140 |
| 21:56:02 | necrogl | do they stilll sell the irives anyone |
| 21:56:03 | necrogl | ? |
| 21:56:09 | bg_ | one day out of curiosity i googled "opensource iriver firmware" and came up with this site |
| 21:56:15 | bg_ | only to find it was in early development |
| 21:56:18 | rasher | preglow: there's ipodlinux surely |
| 21:56:27 | rasher | oh, photo |
| 21:56:29 | rasher | nevermind |
| 21:56:30 | necrogl | is ipodlinux like thsi |
| 21:56:34 | necrogl | ? |
| 21:57:03 | preglow | this really isn't the best channel to be asking ipod questions, most of us have rockbox supported players |
| 21:57:10 | necrogl | ok |
| 21:57:18 | necrogl | i just looked on the ipodlinux site |
| 21:57:24 | necrogl | they ipod photo is not supported |
| 21:57:26 | preglow | ipod linux is more or less at a stand still |
| 21:57:52 | necrogl | cool |
| 21:57:56 | necrogl | http://www.ipodlinux.org/4g |
| 21:58:03 | necrogl | they are working on it |
| 21:58:29 | bg_ | any plans to port rockbox to the ipod? |
| 21:58:42 | bg_ | or is the ipod looked down upon here... |
| 21:59:11 | preglow | well, no, but there exists no info on the ipod hardware, more or less |
| 21:59:45 | rasher | Wouldn't ipl be a good starting point for hardware info? |
| 22:00 |
| 22:00:12 | preglow | probably |
| 22:00:23 | necrogl | both ipodlinux and you are open soruc |
| 22:00:27 | bg_ | you'd think it would be pretty widely know, as it is the most popular portable mp3 player by far |
| 22:00:40 | preglow | not many are interested in it |
| 22:00:49 | HCl | it can't do radio, says enough for me :p |
| 22:00:52 | preglow | but some docs probably exist, just not comprehinsive official ones |
| 22:01:03 | preglow | but i don't care anyway |
| 22:01:07 | bg_ | a lot of people get the ipod almost as a fashion statement it seems |
| 22:01:10 | preglow | i like my h120 |
| 22:01:14 | bg_ | ditto |
| 22:01:18 | preglow | bg_: no shit |
| 22:01:34 | necrogl | but wouldnt i make more sense to make rockbox for the ipod? |
| 22:01:35 | bg_ | and bono endorses it..... |
| 22:01:37 | HCl | lol. |
| 22:01:45 | HCl | definately. |
| 22:02:19 | necrogl | lol |
| 22:02:19 | necrogl | u2 |
| 22:02:31 | HCl | i meant the fashion statement bit >.o |
| 22:02:47 | necrogl | but ipods are quiet cool |
| 22:03:26 | bg_ | meh |
| 22:03:26 | necrogl | wouldnt more people be interested in ipod rockbox? |
| 22:03:40 | Zagor | necrogl: we do this because it's fun. that's all. |
| 22:03:41 | * | HCl doesn't really think that matters o.o; |
| 22:03:43 | HCl | yea. |
| 22:03:45 | bg_ | most people with ipods are technically challenged |
| 22:03:53 | arogan | heh |
| 22:03:58 | necrogl | hey |
| 22:04:04 | necrogl | a lot of my mates have ipods |
| 22:04:10 | necrogl | they aitn dumb |
| 22:04:18 | preglow | he said 'a lot', not 'all' |
| 22:04:21 | HCl | personally, i'm not really enthusiastic about ipod |
| 22:04:23 | Zagor | the ipod would be a good target if there was documentation available |
| 22:04:47 | necrogl | ipod linux is just about as tech savvy as your porject |
| 22:04:52 | arogan | should make rockbox for the ishuffle (5000 blinking light combinations to tell what the player is doing) |
| 22:05:01 | necrogl | lol |
| 22:05:04 | Zagor | necrogl: "tech savvy"? |
| 22:05:04 | | Part hubble |
| 22:05:06 | bg_ | yeah, im kinda confused by the shuffle concept |
| 22:05:10 | jyp | How bout rockbox for the gmini ? :P |
| 22:05:14 | bg_ | can you like, not choose what song you want to listen to? |
| 22:05:18 | rasher | jyp: no way! |
| 22:05:19 | HCl | ohh! gmini is a great idea! |
| 22:05:21 | HCl | :D |
| 22:05:21 | HCl | :P |
| 22:05:24 | rasher | jyp: that can't be done :D |
| 22:05:25 | necrogl | i used a shuffle |
| 22:05:34 | necrogl | it aint my thing |
| 22:05:39 | necrogl | it weight nothing |
| 22:05:42 | bg_ | can you pick the song you listen to? |
| 22:05:55 | jyp | I think we can still lower the signal noise ratio on this channel, huh ? |
| 22:05:56 | bg_ | it is flash based isnt it... |
| 22:06:03 | necrogl | you can press a button to go the the first song of the playlist |
| 22:06:05 | preglow | jyp: would be great, yes |
| 22:06:13 | necrogl | what you could do |
| 22:06:18 | necrogl | is make morse code |
| 22:06:25 | necrogl | to say what song it is playing |
| 22:06:25 | jyp | preglow: Thanks for the support ;) |
| 22:06:59 | necrogl | what do you lot thing about morse code? |
| 22:07:19 | rasher | Not much. |
| 22:07:23 | necrogl | i mean |
| 22:07:31 | necrogl | see the shuffle has those light |
| 22:07:38 | jyp | Would apple zealots commit the heresy to use non-apple software ? |
| 22:07:39 | necrogl | you use use morse code to say the song is it playing |
| 22:07:59 | preglow | we're not porting to the shuffle, this is pretty irrelevant |
| 22:08:03 | necrogl | there is 10 millionm ipods users |
| 22:08:11 | necrogl | most of them dont even know what a mac is |
| 22:08:39 | Zagor | but all of them know morse? |
| 22:08:57 | necrogl | lol |
| 22:09:01 | necrogl | i dont even know morse |
| 22:09:03 | necrogl | lol |
| 22:09:03 | linuxstb | I've been looking at the ipodlinux optimisations to libFLAC - the only thing I can find that they've done to achieve real-time decoding on a 64MHz ipod is this asm function: linuxstb.org/lpc_asm.s">http://linuxstb.org/lpc_asm.s Does anyone fancy doing the same for the coldfire? |
| 22:09:20 | rasher | It'd be fine if this ipod lobby could either a) take their discussion elsewhere or b) do the work to start a port |
| 22:09:43 | Zagor | rasher: amen |
| 22:09:54 | necrogl | this is a rockbox lobby |
| 22:09:56 | arogan | any chance of having bookmark capabilities when viewing text files? |
| 22:10:00 | | Join [IDC]Dragon [0] (~idc-drago@pD9E341EB.dip.t-dialin.net) |
| 22:10:09 | necrogl | dont the ipdo already do that |
| 22:10:20 | amiconn | hi Jörg |
| 22:10:26 | [IDC]Dragon | hi again |
| 22:10:41 | Zagor | arogan: anything is possible |
| 22:10:51 | [IDC]Dragon | believe it or not, I have a liitle time for rockbox |
| 22:10:53 | amiconn | [IDC]Dragon: Did you try building a sim on cygwin? It is badly broken :( |
| 22:11:00 | preglow | linuxstb: i'll have a look |
| 22:11:01 | [IDC]Dragon | no |
| 22:11:02 | necrogl | did those guys get the ipod to play flac? |
| 22:11:07 | preglow | necrogl: go ask them |
| 22:11:15 | necrogl | do they have irc? |
| 22:11:19 | [IDC]Dragon | I rarely ever did |
| 22:11:32 | preglow | i don't know, as i said, i gave a rats ass about the ipod |
| 22:11:32 | rasher | necrogl: I suggest you look at their webpage: http://www.ipodlinux.org/ |
| 22:11:45 | Zagor | necrogl: #ipodlinux |
| 22:11:50 | necrogl | lol |
| 22:11:56 | rasher | And now kindly stop all this talk about the iPod. Clearly none of the devs are interested in it. |
| 22:11:58 | necrogl | iit is on the same server as you lot |
| 22:11:59 | rasher | (afaics) |
| 22:12:10 | necrogl | freenode |
| 22:12:23 | HCl | mmmm. |
| 22:12:30 | Zagor | many projects have channels on freenode |
| 22:12:30 | HCl | i should start getting into m86k assembly |
| 22:12:40 | necrogl | so |
| 22:12:46 | necrogl | you lot wont be making rockbox for ipod |
| 22:12:59 | HCl | i think its safe to say that, yes. |
| 22:13:02 | necrogl | ok |
| 22:13:10 | necrogl | i will look into the linux thing |
| 22:13:12 | Zagor | necrogl: "we" is not a group. if someone wants to port rockbox to ipod, he is free to do it. |
| 22:13:15 | [IDC]Dragon | anybody is free to do so |
| 22:13:20 | HCl | yup. |
| 22:13:22 | necrogl | they seen to have it working on the mini |
| 22:13:25 | necrogl | and the 4g |
| 22:13:30 | necrogl | anyway |
| 22:13:30 | Zagor | just because none of us here want to do it now doesn't mean it can't ever happen |
| 22:13:33 | HCl | its just that nobody here seems to be interested in porting it |
| 22:13:34 | necrogl | nice talking |
| 22:13:49 | necrogl | does that mean |
| 22:13:53 | linuxstb | preglow: Thanks. An alternative (also optimised from the standard libFLAC) C version of that function is here: linuxstb.org/lpc_ipod.c">http://linuxstb.org/lpc_ipod.c - look at the FLAC__lpc_restore_signal() function. |
| 22:13:54 | necrogl | it could be done? |
| 22:14:24 | Zagor | yes, with hard work |
| 22:14:29 | necrogl | ok |
| 22:14:39 | necrogl | the linix porjct look good |
| 22:14:57 | necrogl | no point of having tow different alternative firmware is there |
| 22:16:13 | amiconn | Grr, I don't get it. My Makefile changes for rockboy suddenly don't work anymore as they should. |
| 22:16:16 | Zagor | necrogl: you are not a programmer, are you? |
| 22:16:43 | necrogl | i have played with interface builder |
| 22:16:46 | necrogl | xcode |
| 22:16:55 | necrogl | and a few lines of cocoa |
| 22:17:31 | necrogl | it is not real porgramming |
| 22:18:42 | preglow | linuxstb: this just might be a good test to see how good the emac unit is as well |
| 22:19:19 | linuxstb | Yep, it looks a relatively simple function to write. |
| 22:19:44 | necrogl | emacs is such a lame text editor |
| 22:19:52 | preglow | the major hurdle is that i don't know arm or m68k assembly very well, but i've got to start somewhere |
| 22:19:55 | preglow | necrogl: don't mention it |
| 22:20:33 | jyp | emacs rulz!!!!!!11 |
| 22:21:03 | necrogl | i have nothing aginst it |
| 22:21:25 | necrogl | but it is painful using terminal for text editing |
| 22:21:39 | jyp | I might also add that it's the only program deserving the name of an editor |
| 22:22:03 | preglow | prefer vim myself |
| 22:22:26 | jyp | besides, what's a non-programmer opinion on editors ?!!!111 |
| 22:22:28 | preglow | haha, went to see richard stallman the other day |
| 22:22:38 | preglow | he donned his church of emacs saint costume at the end of the talk :P |
| 22:22:50 | jyp | He always does ;) |
| 22:23:20 | * | jyp switches to rational mode |
| 22:23:25 | jyp | phew |
| 22:23:31 | jyp | That was refreshing. :P |
| 22:23:48 | necrogl | i use xocde |
| 22:23:53 | necrogl | xcode |
| 22:23:59 | [IDC]Dragon | sh-elf-ranlib: Command not found |
| 22:24:02 | preglow | but i'll go eat some |
| 22:24:08 | [IDC]Dragon | what does that tell me? |
| 22:24:28 | amiconn | [IDC]Dragon: Doing what? |
| 22:24:33 | jyp | Path correct ? |
| 22:24:56 | necrogl | well |
| 22:24:59 | [IDC]Dragon | I'm plain trying to compile fresh |
| 22:25:01 | necrogl | i am going nice |
| 22:25:07 | necrogl | now |
| 22:25:09 | necrogl | fora bit |
| 22:25:15 | necrogl | i might be back later |
| 22:25:18 | necrogl | hell |
| 22:25:21 | [IDC]Dragon | compiling works, so the path is there |
| 22:25:24 | necrogl | why is irc is dam slow |
| 22:25:46 | amiconn | [IDC]Dragon: Seems you don't have that command. Cygwin, I guess? |
| 22:26:04 | XShocK | haha... DMA works... almost. :) |
| 22:26:15 | amiconn | [IDC]Dragon: It is working perfectly here for the target |
| 22:26:23 | | Quit necrogl () |
| 22:26:28 | [IDC]Dragon | I tried cygwin, for the target |
| 22:26:33 | jyp | XShocK: what are you working on? |
| 22:26:40 | XShocK | DMA sound. |
| 22:26:42 | * | [IDC]Dragon moves over to the notebook |
| 22:27:01 | jyp | Cool |
| 22:27:07 | XShocK | the sound is coming out, i would try to load some normal WAV PCM file to see how it would do |
| 22:27:07 | amiconn | [IDC]Dragon: Maybe your sh-binutils are too old, and don't include ranlib |
| 22:27:25 | [IDC]Dragon | the notebook has it |
| 22:27:35 | jyp | XShocK: What are you playing ? |
| 22:27:38 | preglow | i can feel the snr going down already |
| 22:27:40 | [IDC]Dragon | is this new, using ranlib? |
| 22:27:42 | jyp | right now ? |
| 22:28:07 | amiconn | [IDC]Dragon: yes, seems so from looking at the new make stuff |
| 22:28:19 | rasher | preglow: totally.. what a guy.. |
| 22:28:20 | amiconn | However, ranlib isn't strictly required |
| 22:28:32 | amiconn | $ sh-elf-ranlib |
| 22:28:33 | amiconn | Usage: sh-elf-ranlib [options] archive |
| 22:28:33 | amiconn | Generate an index to speed access to archives |
| 22:29:15 | [IDC]Dragon | archives, strange |
| 22:29:32 | XShocK | tried to load RAW wav, but i guess i should change little-endian to big-endian first, since there is a noise.... |
| 22:29:44 | amiconn | It's not strange. This means the .a archives, i.e. libraries |
| 22:29:55 | * | [IDC]Dragon switches machine, cu |
| 22:30:02 | | Quit [IDC]Dragon () |
| 22:30:23 | | Join [IDC]Dragon2 [0] (~Joerg@pD9E341EB.dip.t-dialin.net) |
| 22:30:23 | | Quit [IDC]Dragon2 (Remote closed the connection) |
| 22:31:52 | | Join [IDC]Dragon [0] (~Joerg@pD9E341EB.dip.t-dialin.net) |
| 22:32:08 | [IDC]Dragon | hi again |
| 22:33:46 | jyp | XShocK: be sure to notify me when your work goes in CVS, so I can integrate gmini support |
| 22:33:52 | jyp | as seamlessly as possible |
| 22:34:18 | jyp | ... please ;) |
| 22:35:27 | XShocK | I will flood this channel if I get good sound from this DMA, don't worry. :) |
| 22:35:42 | bg_ | on iriver? |
| 22:35:58 | HCl | :P |
| 22:36:08 | * | rasher cheers XShocK on |
| 22:37:04 | jyp | Personnaly I used a simpler method than load from file |
| 22:37:18 | jyp | in order to test sound from the gmini |
| 22:37:29 | jyp | ... hardcoded buffer ;) |
| 22:37:45 | jyp | jyp/test-sound2.c">http://users.skynet.be/jyp/test-sound2.c |
| 22:38:07 | jyp | Maybe test this before ? |
| 22:40:12 | XShocK | ok |
| 22:46:35 | XShocK | is it sine wave? |
| 22:46:42 | XShocK | that 256 element array |
| 22:47:35 | [IDC]Dragon | hooray, the newer cygwin compiles |
| 22:47:54 | [IDC]Dragon | but "make zip" didn't work |
| 22:47:59 | Bagder | what happened? |
| 22:48:22 | [IDC]Dragon | it tried to build the failing rombox again, but no more |
| 22:48:31 | preglow | does the m68k/coldfire have a hardware tick counter than anyone is aware of? |
| 22:48:58 | XShocK | it makes sound, but i am not sure if it is a perfect sine however |
| 22:49:05 | [IDC]Dragon | (I'm compiling Ondio FM target) |
| 22:50:11 | Bagder | aha |
| 22:50:22 | * | amiconn notices Bagder around |
| 22:50:30 | Bagder | I missed a piece of my patch in the zip parts |
| 22:50:48 | Bagder | or did I... |
| 22:51:10 | amiconn | I can't build any sim on cygwin :( |
| 22:51:23 | amiconn | There are multiple problems I don't know how to solve |
| 22:51:46 | Bagder | mail me some outputs |
| 22:52:29 | amiconn | The first one is rather early, and short. |
| 22:56:30 | Bagder | amiconn: does the cygwin header contain some kind of protection mechanism against multiple typedefs of those types? |
| 22:56:50 | Bagder | like checking for a magic define or something |
| 22:57:00 | amiconn | I already checked, it doesn't, but this problem _only_ occurs with ssize_t |
| 22:57:19 | *** | Saving seen data "./dancer.seen" |
| 22:57:51 | amiconn | I found that there are safety mechanisms in firmware/include/file.h, but none of these work for cygwin. |
| 22:58:22 | Bagder | ok, I think we can #ifndef SIMULATOR that typedef |
| 22:58:34 | amiconn | I could try a kludge (checking for __CYGWIN__ as well), but I don't know if this would be good... |
| 22:59:55 | amiconn | If I use #ifndef SIMULATOR, should the magic defines stay there? |
| 23:00 |
| 23:00:09 | Bagder | hang on, checking the win32 cross-compile |
| 23:00:47 | Bagder | hehe, it errors if removed |
| 23:01:48 | amiconn | I'll add && !defined(__CYGWIN__) for now and retry... |
| 23:01:53 | Bagder | yes, do that |
| 23:01:59 | [IDC]Dragon | excuse a dumb question, it's been a while, do I select Win32 or X11 for cygwin sim? |
| 23:02:10 | amiconn | You can build both |
| 23:02:23 | amiconn | I'm currently trying win32 |
| 23:02:26 | Bagder | or should at least ;-) |
| 23:02:30 | [IDC]Dragon | with the difference being what? |
| 23:02:57 | Bagder | win32 is the fancy one with images and things, the x11 one uses X windows and requires you to run X |
| 23:03:14 | [IDC]Dragon | win32 then |
| 23:04:29 | | Join Tang [0] (~chatzilla@ARennes-252-1-48-67.w83-195.abo.wanadoo.fr) |
| 23:04:30 | amiconn | Bagder: Now it goes somewhat further, gives numerous warnings about file function, then errors at plugin.c |
| 23:04:46 | Tang | hello :) |
| 23:04:56 | Bagder | ok, let's ignore warnings for now |
| 23:05:07 | Bagder | what's the error? |
| 23:06:47 | Bagder | ok, you miss the read() prototype |
| 23:07:21 | amiconn | Not only read(), but also write(), fprintf(), lseek() |
| 23:07:36 | Bagder | in the bottom of include/file.h |
| 23:07:47 | Bagder | try removing the #ifndef SIMULATOR |
| 23:07:56 | Bagder | for that list of protos |
| 23:08:06 | amiconn | retrying... |
| 23:09:20 | amiconn | ... "conflicting types" :( |
| 23:09:41 | amiconn | ...and a warning about printf() |
| 23:10:05 | Bagder | what's the conflicting one? |
| 23:10:26 | amiconn | read() and write() |
| 23:10:42 | | Quit Cassandra_ (Read error: 60 (Operation timed out)) |
| 23:10:46 | Bagder | I think we might need a set of protos for the cygwin sim there |
| 23:11:01 | Tang | I'm reading the "GaplessHowtoWiki" |
| 23:11:16 | Bagder | the win32 cross-compile failed too |
| 23:11:19 | Bagder | very similar |
| 23:11:25 | * | HCl doesn't understand whats so important about gapless music |
| 23:11:41 | rasher | Well if music is made gapless, I want to listen to it without gaps |
| 23:11:54 | rasher | I get UPSET when things have gaps, that shouldn't be there |
| 23:11:59 | HCl | okay o.o |
| 23:12:11 | rasher | Then I get ANGRY |
| 23:12:14 | amiconn | Bagder: I wonder why/ how it worked before the new build system... |
| 23:12:17 | rasher | and we all know what anger leads to |
| 23:12:21 | Tang | HCI |
| 23:12:22 | HCl | that means you need to control your anger :P |
| 23:12:25 | HCl | hcL |
| 23:12:35 | Tang | try listnening "pink floyd" album |
| 23:12:36 | Bagder | amiconn: because previously the sim did not use the Rockbox headers as aggressively as now |
| 23:12:49 | HCl | i don't like pink floyd. the only live album i have is nirvana |
| 23:12:54 | HCl | and i couldn't care less about gaps in it |
| 23:12:55 | HCl | o.o |
| 23:12:57 | Tang | You'll undertsand what's cool with gapless playback |
| 23:13:05 | amiconn | Ah. So what if the rockbox headers include the system headers for sim builds? |
| 23:13:08 | HCl | i know the difference, one has pauses, the other doesn't |
| 23:13:16 | Tang | Okay was just for exemple |
| 23:13:18 | Tang | ;) |
| 23:13:25 | HCl | meh. |
| 23:13:28 | HCl | anyways. |
| 23:13:44 | Bagder | amiconn: that can only be done if the system header has a different name, since <stdio.h> etc will find the Rockbox one |
| 23:14:03 | amiconn | Umm, of course |
| 23:14:20 | Bagder | that's why we need to add some info from the system headers into the Rockbox ones for sim use |
| 23:14:48 | Tang | I wonder about the gapless howto |
| 23:15:08 | Tang | is this the only way to get gapless playback for even Rbx future? |
| 23:15:28 | Bagder | Tang: no |
| 23:15:30 | Tang | cause the "foobar" method is much cooler |
| 23:15:38 | Tang | Ah ok badger thanks |
| 23:15:52 | Tang | :) |
| 23:15:53 | rasher | No, when doing decoding in software, there are easier (for the user) ways |
| 23:16:02 | amiconn | Hmm. That doesn't sound like a clean solution to me. We can only select one (or some) particular variants. What if someone tries to build the simulator on a system with different headers? |
| 23:16:09 | Bagder | Tang: you should know that Rockbox isn't done for iriver yet |
| 23:16:21 | Tang | Okay was wondering cause i didn't see nothing about these on the section |
| 23:16:31 | preglow | which 68k registers can one clobber in a function? |
| 23:16:32 | Tang | i know no mistake |
| 23:16:38 | preglow | a0, a1, d0 and d1? |
| 23:16:41 | Bagder | amiconn: why would that break anything? |
| 23:16:53 | Tang | it's just that i saw the GaplessHowto was edited recently |
| 23:16:59 | Bagder | the problem we have now is because cygwin/win32 use different protos than Rockbox |
| 23:17:05 | Tang | so i thought it was about iRiverport |
| 23:17:14 | Tang | that's why i was surprised |
| 23:17:29 | Bagder | Tang: don't be until someone claims Rockbox works for iRiver |
| 23:17:43 | Bagder | that'll be several months ahead |
| 23:17:47 | amiconn | Bagder: Possibly it would not build for the same reason cygwin fails when using the rockbox definitions: conflicting types. |
| 23:17:59 | Tang | Okay no matter Badger |
| 23:18:19 | Bagder | amiconn: if I could, I would prevent the compiler to find the "original" protos in the system headers, but that's hard |
| 23:18:21 | Tang | wasn't thinking about working iriverport before some months personnaly |
| 23:18:45 | amiconn | The sim (well, at least the X11 version) could be built on Linux, *bsd, Solaris, MacOS, HPUX.... |
| 23:18:58 | Bagder | yes |
| 23:19:06 | Bagder | but I don't think they will cause problems |
| 23:19:12 | Bagder | they are all posix |
| 23:19:16 | Bagder | win32 is not |
| 23:19:30 | Bagder | and Rockbox is, partly at least |
| 23:19:44 | Tang | (but i think it's a good thing to make some publicity about the rockbox iriverport project that's why i relay the informations on some boards) |
| 23:20:07 | | Join Cassandra_ [0] (~christi@213.78.126.170) |
| 23:20:51 | Bagder | amiconn: system functions are generally not different between OSes |
| 23:20:58 | amiconn | Bagder: The problem is often long vs. int, since jyp long-policed a number of places |
| 23:21:08 | Bagder | like where? |
| 23:21:15 | amiconn | ssize_t |
| 23:21:21 | Bagder | then they're not posix |
| 23:21:23 | Bagder | like win32 |
| 23:21:44 | amiconn | Rockbox: typedef ssize_t long; |
| 23:22:09 | Bagder | why is that bad? |
| 23:22:12 | amiconn | Cygwin: |
| 23:22:13 | amiconn | #if defined(__INT_MAX__) && __INT_MAX__ == 2147483647 |
| 23:22:13 | amiconn | typedef int _ssize_t; |
| 23:22:13 | amiconn | #else |
| 23:22:13 | amiconn | typedef long _ssize_t; |
| 23:22:13 | *** | Alert Mode level 1 |
| 23:22:13 | amiconn | #endif |
| 23:22:13 | * | HCl scratches his head |
| 23:22:43 | | Join [IDC]Dragon2 [0] (~Joerg@pD9E341EB.dip.t-dialin.net) |
| 23:22:46 | amiconn | ..and the rockbox one is of course typedef long ssize_t; |
| 23:22:47 | Bagder | amiconn: that's a Rockbox bug then, not a sim build problem |
| 23:22:48 | HCl | i must say the documentation of mips was a lot more straightforward than the documentation of the coldfire... |
| 23:23:26 | amiconn | Bagder: The same probably applies to the read() etc prototypes |
| 23:23:44 | Bagder | no, since read() should return a ssize_t |
| 23:24:01 | Bagder | it would adapt to the tpe |
| 23:24:02 | HCl | anyone around experienced with mips assembly who could explain what they mean? |
| 23:24:02 | Bagder | type |
| 23:24:05 | * | amiconn checks rockbox vs. cygwin prototype for read... |
| 23:24:06 | HCl | er |
| 23:24:09 | HCl | m68k |
| 23:25:08 | | Nick gromit` is now known as gromitovitch (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
| 23:25:15 | preglow | what what means? |
| 23:25:50 | preglow | i think cfrpm.pdf is pretty straightforward |
| 23:25:50 | HCl | i'm looking at http://www.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf |
| 23:25:53 | HCl | chapter 9 |
| 23:26:11 | HCl | i don't understand what they mean with the bits since some have multiple lines |
| 23:26:19 | HCl | take btst |
| 23:26:28 | HCl | what do mode/register do? |
| 23:26:28 | | Nick gromitovitch is now known as gromit`` (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
| 23:26:46 | preglow | you really should look up the individual instruction docs |
| 23:26:53 | HCl | where? |
| 23:26:55 | preglow | chapter three |
| 23:27:05 | | Quit DrRick () |
| 23:27:06 | Bagder | m68k is actually rather easy-to-read assembler in my view |
| 23:27:09 | preglow | every one of them is described in detail |
| 23:27:14 | preglow | m68k assembler is very nice |
| 23:27:17 | HCl | chapter 3 doesn't enlist bit encodings. |
| 23:27:22 | preglow | yes it does |
| 23:27:27 | preglow | four, i mean |
| 23:27:30 | preglow | chapter four |
| 23:27:39 | HCl | integer user instructions? O.o |
| 23:27:42 | preglow | yes |
| 23:27:50 | HCl | ahh. |
| 23:27:54 | preglow | those are the one's you'll need, pretty much |
| 23:27:54 | HCl | it doesn't have any subsections |
| 23:27:57 | HCl | yea. |
| 23:28:00 | preglow | bah, who cares :P |
| 23:28:00 | HCl | thats what i was looking for |
| 23:28:39 | HCl | ok |
| 23:28:40 | HCl | thanks |
| 23:28:41 | HCl | :) |
| 23:28:50 | preglow | np |
| 23:29:38 | preglow | why does gas _never_ conform to the asm syntax that's most common? |
| 23:30:01 | preglow | even 68k assembly is slightly tweaked |
| 23:30:12 | Bagder | because they are evil? ;-) |
| 23:30:48 | preglow | especially addressing modes are never the same |
| 23:31:09 | | Join rjamorim [0] (me@200.103.132.16) |
| 23:31:59 | amiconn | Bagder: cygwin (iiuc): int read(int, void*, unsigned int) |
| 23:32:14 | *** | Alert Mode OFF |
| 23:32:15 | amiconn | rockbox: ssize_t read(int, void*, size_t) |
| 23:32:22 | | Quit sox ("Snak 4.13 IRC For Mac - http://www.snak.com") |
| 23:32:36 | Bagder | yes, and that is the problem in a nutshell |
| 23:32:45 | Bagder | how do you suggest we deal with it? |
| 23:33:05 | Bagder | rockbox uses the posix protos in these cases |
| 23:33:47 | Bagder | I've tried to prevent the compiler to find the system's native protos |
| 23:33:53 | amiconn | Well, in this particular case using the system include may work, because these fns are defined in io.h |
| 23:34:16 | amiconn | How do you prevent that? |
| 23:34:26 | Bagder | in linux there is no io.h |
| 23:34:37 | | Quit bg_ ("Chatzilla 0.9.67 [Firefox 1.0+/20050201]") |
| 23:34:47 | Bagder | rockbox shadows pretty much all the headers with that info |
| 23:35:52 | amiconn | I dont understand I'm afraid. |
| 23:35:53 | * | Bagder tests |
| 23:36:16 | Bagder | try removing the inclusion of io.h |
| 23:36:23 | Bagder | in include/dir.h |
| 23:38:10 | Bagder | it seems to include it anyway somehow |
| 23:38:27 | amiconn | Exactly the same error. |
| 23:39:14 | | Quit [IDC]Dragon (Read error: 110 (Connection timed out)) |
| 23:39:25 | XShocK | mmmmm.... sound if coming. it is sine.. but i also hear a gap. I guess it is when DMA restarts the copy progress. |
| 23:39:35 | XShocK | *sound is coming |
| 23:40:44 | Bagder | amiconn: try creating an empty file uisimulator/common/io.h |
| 23:41:04 | Bagder | as an experiment, its not a complete fix |
| 23:41:07 | XShocK | i can't really understand why it is som since when interrupt is fired when DMA copy is finished, so FIFO shouldn't be empty by then |
| 23:41:09 | amiconn | I'll try asap. |
| 23:41:40 | amiconn | Another observation: Trying to build the X11 sim on cygwin now gives a heapload of warnings, then fails to link. |
| 23:42:04 | Bagder | amiconn: I might've failed to setup the proper set of libs to link with or something |
| 23:42:33 | preglow | XShocK: not bad anyway |
| 23:43:32 | amiconn | Bagder: Now the error is different. |
| 23:43:54 | Bagder | amiconn: does it reach further? |
| 23:44:17 | amiconn | No, errors in the same file: |
| 23:44:28 | amiconn | (hmm, better not paste that) |
| 23:45:38 | Bagder | that is further |
| 23:45:44 | Bagder | even if just slightly |
| 23:46:04 | Bagder | this prevented it from including the system's io.h for the rockbox parts |
| 23:46:25 | Bagder | now, when the simulator parts are to be built, it must find the real io.h... |
| 23:48:04 | Bagder | hmmm |
| 23:49:03 | | Part rjamorim |
| 23:49:56 | | Join [IDC]Dragon [0] (~Joerg@pD9E341EB.dip.t-dialin.net) |
| 23:50:52 | HCl | i think i'm kind of gonna need a proper malloc/free implementation for a dynarec... |
| 23:53:38 | [IDC]Dragon | many people need such nowadays |
| 23:53:59 | HCl | well, i might be able to do without by simply not providing an implementation for free. |
| 23:54:10 | HCl | but it'll be extremely memory leaky and eventually it might run out of ram.. |
| 23:54:11 | DeadMan | M$ teaches you l33t sp34k |
| 23:54:14 | DeadMan | http://www.microsoft.com/athome/security/children/kidtalk.mspx |
| 23:54:18 | [IDC]Dragon | you can't just continue walking th buffer? |
| 23:54:25 | HCl | [IDC]Dragon: i might run out of memory |
| 23:54:42 | preglow | linuxstb: i think i'll be able to translate the asm optimized function, just give me some time :P |
| 23:55:09 | linuxstb | preglow: Have fun! |
| 23:55:29 | HCl | the good news is that the gameboy only has a 16 bit program counter |
| 23:56:39 | preglow | linuxstb: no problem, i've got beer! |
| 23:57:11 | preglow | HCl: isn't most things in z80 sixteen bit? |
| 23:58:23 | HCl | apparently, i don't know much about m68k / z80 yet |
| 23:58:24 | preglow | HCl: or eigth bit, even |
| 23:58:26 | HCl | but i'm about to. |
| 23:58:27 | | Join amiconn_ [0] (~jens@pD95D1FE0.dip.t-dialin.net) |
| 23:58:28 | HCl | no. |
| 23:58:36 | preglow | HCl: but registers are eight bit, right? |
| 23:58:42 | HCl | yea |
| 23:58:46 | HCl | sortof |
| 23:58:52 | | Quit amiconn (Nick collision from services.) |
| 23:58:53 | | Nick amiconn_ is now known as amiconn (~jens@pD95D1FE0.dip.t-dialin.net) |
| 23:58:54 | HCl | theres actually 6 registers |
| 23:58:57 | HCl | of 16 bits |
icon identifies that the person is a core developer (has commit access).