--- Log for 28.02.105  Server: zelazny.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 24 days and 15 hours ago

00.00.31 #       * nobbynobbs jabs pin in reset hole AGAIN
00.00.43 #       <killalot> hello
00.00.51 #       <nobbynobbs> hi
00.01.26 #       <killalot> so what will this work on 
00.02.20 #       <preglow> well
00.02.21 #       <preglow> mario?
00.02.28 #       <preglow> be prepared that it's very slow, please
00.02.35 #       <preglow> it will take some time before something shows up on the screen
00.02.44 #       <nobbynobbs> over a minute?
00.02.48 #       <preglow> nope
00.02.55 #       <preglow> and it should respond to key presses anywa
00.02.55 #       <preglow> y
00.03.01 #       <nobbynobbs> could you send me a copy of mario
00.03.14 #       <preglow> haven't got it currently
00.03.18 #       <nobbynobbs> or give me a link to a decent rom site that doesnt ask for 9999votes first
00.03.19 #       <preglow> a google search should get it for you
00.03.40 #       <nobbynobbs> what filename extentions does rockboy assosiate with?
00.03.50 Quit    methangas (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference")
00.03.54 #       <preglow> .gb
00.03.58 #       <nobbynobbs> thanks
00.04.13 #       <nobbynobbs> i had a copy of mario land years ago
00.04.17 #       <nobbynobbs> played it for hours
00.04.26 #       <preglow> haha
00.04.28 #       <preglow> never dug it that much
00.04.33 #       <nobbynobbs> never finished it, but spent more time on it than any game since
00.04.33 #       <preglow> i played loads of zelda, though
00.04.35 #       <preglow> and super wario land
00.04.57 #       <nobbynobbs> i had warioland! 
00.05.05 Quit    willkill4food (Read error: 110 (Connection timed out))
00.05.14 Part    killalot
00.05.47 Quit    nobby (Read error: 110 (Connection timed out))
00.05.47 #       <nobbynobbs> whats the keymapping for rockboy?
00.06.44 #       <preglow> well, direction pad is as you expect, the rest i can't remember :PP
00.06.56 #       <nobbynobbs> fair nuff
00.07.04 #       <nobbynobbs> whats the exit button?
00.07.08 #       <preglow> stop, i thinks
00.07.12 #       <nobbynobbs> k
00.07.23 #       <nobbynobbs> ooh, playing BGlander
00.07.25 #       <nobbynobbs> *GB
00.07.26 #       <preglow> can't remember
00.08.07 #       <nobbynobbs> i gtg
00.08.11 #       <nobbynobbs> thanks for all the help
00.09.16 Quit    nobbynobbs ("HCl is god! preglow is jesus!")
00.09.43 Quit    muesli- (Read error: 110 (Connection timed out))
00.09.46 Join    amiconn_ [0] (~jens@pD95D1467.dip.t-dialin.net)
00.10.50 #       <HCl> o.o.
00.11.45 Quit    Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )")
00.12.31 #       <HCl> prpplague: because gcc is *not* giving me a correct assembly of it.
00.12.43 #       <HCl> cause that was what i was doing, but gcc is messing up.
00.14.19 #       <preglow> HCl: have you tried it out?
00.14.43 #       <mst> OH SWEET
00.14.52 #       <HCl> preglow: the code it was generating was: flags = 0;
00.14.55 #       <mst> the firmware is in ia32 format!
00.15.28 Quit    Zagor (Read error: 110 (Connection timed out))
00.15.52 Quit    amiconn (Nick collision from services.)
00.15.53 Nick    amiconn_ is now known as amiconn (~jens@pD95D1467.dip.t-dialin.net)
00.16.26 #       <prpplague> HCl: ahhh
00.16.47 Quit    ripnetUK ()
00.17.41 #       <mst> okay this gets more and more interesting.. the bios itself contains -another- filesystem
00.17.57 #       <HCl> whatcha doing/
00.17.57 #       <HCl> ?
00.19.23 #       <mst> hacking this thing: http://usboem.en.alibaba.com/product/50043844/50202973/MP3_Players/MP3_Player.html
00.19.30 #       <HCl> ah.
00.19.57 #       <HCl> looks odd.
00.19.59 #       <HCl> but ok
00.20.11 #       <mst> its ubercool. Smallest mp3 player i've ever seen. 
00.20.32 #       <prpplague> that looks cool
00.20.39 #       <prpplague> you got jtag working?
00.21.59 #       <mst> me?
00.22.25 #       <prpplague> mst: yea
00.25.58 #       <mst> i dont even have an idea what that is :)
00.26.06 #       <mst> hmmm.. raw i8086 code
00.26.10 #       <mst> IDA time :P
00.27.20 #       <prpplague> mst: how are you getting the firmware off the device?
00.29.59 #       <mst> prpplague, I didn't. I took a similar firmware off the 'net - I bet I would be able to get the real one off the device the moment I bring the USB cable from work
00.32.49 #       <mst> HAH
00.32.59 #       <mst> these people do have the gall. I get int10 calls and shit.
00.35.33 #       <preglow> can anyone think of a reason why descramble and scramble shouldn't work in windows?
00.35.55 #       <HCl> nop.
00.37.40 #       <preglow> well, it doesn't :///
00.37.48 Join    lImbus_ [0] (lImbus@134-43.244.81.adsl.skynet.be)
00.39.13 #       <amiconn> preglow: It should. It does here (didn't test the iriver part though)
00.39.30 Join    skav [0] (skav@67-138-74-184.dsl1.merch.roc.ny.frontiernet.net)
00.39.35 #       <preglow> i've got a tool up that patches a firmware and md5sums it for you, but the iriver_decode makes a smaller file than it should
00.40.05 #       <preglow> these functions are in no way meant to be called from anything else than the command line tools, though
00.40.15 #       <preglow> but i just can't be bothered to rewrite them
00.40.49 #       <preglow> but that shouldn't matter unless something goes wrong
00.40.58 #       <preglow> and if something goes wrong, the exit() call should exit my entire program
00.41.00 #       <preglow> which doesn't happen
00.42.43 Join    Renko [0] (~i_dont_wa@host217-43-59-47.range217-43.btcentralplus.com)
00.45.14 #       <prpplague> mst: http://www.elinux.org/wiki/JTAG
00.46.13 Quit    lImbus (Read error: 60 (Operation timed out))
00.46.13 Nick    lImbus_ is now known as lImbus (lImbus@134-43.244.81.adsl.skynet.be)
00.47.13 #       <preglow> it's lacking a wooping two kilobytes :/
00.47.55 Quit    _aLF ("Leaving")
00.49.31 #       <preglow> what the hell....
00.49.41 #       <preglow> suddenly it's not lacking two kilobytes
00.50.53 #       <preglow> and now suddenly it is..........
00.51.24 #       <preglow> haahhah
00.51.26 #       <preglow> bloody marvelous
00.51.38 #       <preglow> i have to flaming _EXIT_ my patcher before the files end up like they should
00.51.58 #       <preglow> now isn't that something
00.52.18 #       <mst> file pointer on the loose?
00.52.55 #       <mst> prpplague, the device doesnt have a visible JTAG connector - havent opened it yet though
00.54.26 Quit    cYmen ("zZz")
00.55.20 #       <preglow> mst: thanks a lot, i know see that these bloody patcher routines in iriver.c don't actually close their files
00.56.19 #       <preglow> now, even
00.56.56 #       <preglow> they rely heavily on just being able to exit() if something's wrong...
00.58.22 #       <mst> preglow, "buffering"? :P
00.59.29 #       <amiconn> Huh? Now that is strange. I'm chasing multiple problems for quite some time, and at least one of them turns out to be veery trivial. Grmpf. :-///
01.01.32 Join    rob- [0] (~robbie@haylott.plus.com)
01.01.42 ***     Saving seen data "./dancer.seen"
01.01.51 #       <preglow> amiconn: nothing on the different plugin sizes yet?
01.01.59 #       <amiconn> Nope :(
01.02.16 #       <amiconn> X11 sim  still has the problem of non-working lseek()
01.02.33 #       <amiconn> This also happens in the core btw, so not plugin related
01.02.59 #       <amiconn> However, I just found the Win32 sim problem with the codec test plugins.
01.03.04 #       <preglow> have you tried debuggin the lseek function?
01.03.23 #       <amiconn> I have no idea how to do this. I tried, but failed
01.03.28 #       <preglow> hmmm
01.03.33 #       <preglow> i know how to do it with visual studio
01.03.36 #       <preglow> but not with gdb
01.04.18 #       <amiconn> I don't have visual studio, apart from that it wouldn't help here. The pure win32 sim works perfectly
01.04.50 #       <amiconn> The Win32 sim problem with the codec tests is simply that the plugins detect a stray keypress, and exit because of that
01.05.16 #       <amiconn> When I comment out this check, they run just fine.
01.05.17 #       <preglow> gdb should be able to trace into functions it doesn't have source to as well
01.05.20 #       <preglow> hmm, or perhaps not
01.05.46 #       <amiconn> And btw, the codec test run at least one order of magnitude faster on the win32 sim
01.06.33 #       <preglow> than x11?
01.06.38 #       <amiconn> yep
01.06.45 #       <preglow> ahh, wouldn't know much about that
01.07.54 #       <amiconn> mpa2wav runs at about 6000% here in win32 sim, converting a 10 minute mp3 in around 10 seconds
01.08.07 #       <preglow> sounds reasonable
01.12.22 Quit    Renko ("cheerio")
01.14.46 Join    sevenapple [0] (sevenapple@pcp08873970pcs.glstrt01.nj.comcast.net)
01.15.42 Join    Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au)
01.15.59 #       <prpplague> mst: yea, they rarely have jtag on an external connector, but if the cpu supports jtag, they will usually have pads or a header
01.18.10 #       <amiconn> Ahahahah! The win32 button driver still has a bug that was fixed waaayyy back for the target driver :-/
01.19.04 Quit    lImbus (" HydraIRC rocks! -> http://www.hydrairc.com <-")
01.19.45 #       <amiconn> It tries to use queue_empty() to empty the button queue. However, queue_empty() is just a status function, returning a boolean...
01.22.14 Quit    sevenapple ()
01.27.41 #       <preglow> someone up for trying my patching tool?
01.27.48 Join    Camilo [0] (~chatzilla@userca029.dsl.pipex.com)
01.27.56 #       <HCl> in a bit...
01.27.57 #       <preglow> windows required
01.30.48 #       <preglow> http://glow.m0f0.net/rockbox/patcher.exe
01.31.07 #       <Sucka> whats it do
01.31.35 #       <preglow> it patches a firmware file with the rockbox bootloader
01.31.47 #       <Sucka> hmmm
01.31.54 #       <Sucka> i might give it a go tomorrow perhaps
01.32.00 #       <Sucka> gotta go now though
01.32.01 #       <Sucka> ;)
01.32.02 #       <Sucka> cya
01.32.05 Quit    Sucka ("a bird in the bush is worth two in your house")
01.32.17 #       <preglow> not for distribution yet, but i wanted to be done with it
01.34.36 Join    pabs [0] (~pabs@xor.pablotron.org)
01.35.35 #       <pabs> hi all, i'm about to flash my h120 with rockbox, i've been goign over the docs
01.35.48 #       <pabs> was wondering if there's anyone around to answer questions if i've got them
01.36.28 #       <preglow> shoot
01.36.46 #       <pabs> no questions yet, still getting up to speed
01.36.50 #       <preglow> ahh
01.36.52 #       <preglow> you're a programmer?
01.37.28 #       <pabs> yeah, why?
01.37.42 #       <preglow> just wanted to know you know what you're doing ;)
01.37.51 #       <pabs> i hope so!
01.38.26 #       <pabs> i've mucked around with my h120 before, it's got modded graphics and everything, but i haven't flashed with it anything other than modded iriver firmware before
01.38.48 #       <preglow> well, with the track record of the rockbox bootloader, you shouldn't see any surprises
01.38.51 #       <preglow> no dead units thus far
01.39.06 #       <pabs> k, that's reassuring
01.41.07 #       <pabs> do i need to rename rockbox.iriver to ihp_120.hex to flash it initially?
01.41.18 #       <preglow> that's not the bootloader
01.41.28 #       <preglow> rockbox.iriver is rockbox itself, it's what the bootloader loads
01.41.41 #       <pabs> k
01.41.56 #       <preglow> the bootloader is bootloader.bin, and needs to be patched into ihp_120.hex
01.41.56 Join    Aison [0] (~hans@zux166-181.adsl.green.ch)
01.42.10 #       <pabs> gotcha
01.46.37 #       <pabs> found it, just double-checking the firmware veresion here
01.46.40 #       <asdsd> WOW preglow
01.46.49 #       <asdsd> so thats it?
01.47.01 #       <preglow> asdsd: what's what?
01.47.09 #       <asdsd> now that u made patcher.exe does this mean the new iriver firmware is publicly released?
01.47.14 #       <preglow> asdsd: no
01.47.18 #       <asdsd> oh
01.47.18 #       <preglow> asdsd: not by any means
01.47.33 #       <asdsd> well i figured since its so easy to do so now that u got it with a program
01.47.34 #       <pabs> fuck, i have to go pick up my roommate's nephew
01.47.38 #       <preglow> asdsd: don't even think of spreading it, i just want to see if it works ;)
01.47.41 #       <asdsd> i remember reading that before u had to compile it urself
01.47.43 #       <pabs> preglow: think you'll be around in like 20 minutes?
01.47.47 #       <asdsd> im not
01.47.50 #       <preglow> pabs: odds are good, at least
01.47.56 #       <preglow> asdsd: we don't want it to be easy yet
01.48.00 #       <pabs> preglow: alrigth
01.48.07 #       <asdsd> yeah i understand, its for their own good
01.48.12 #       <pabs> preglow: either way it looks like i've got enough to go on right here, but just in case :-D
01.48.19 #       <Camilo> hi, has anyone run any code on a H3xx yet?
01.48.27 #       <asdsd> too bad i don't have an h120, i wud love to flash it just so i can find some bugs on it
01.48.43 #       <pabs> preglow: install patched firmware, flash, copy rockbox.iriver and .rockbox over, boot up holding down record and enjoy
01.48.50 #       <pabs> preglow: correct?
01.49.04 #       <pabs> i'm going to miss my awesome transformer logo
01.49.06 #       <pabs> :(
01.49.07 #       <preglow> pabs: indeed, though i'd copy the files first, so you can go straight to rockbox, heh
01.49.15 #       <pabs> preglow: k
01.49.27 #       <preglow> pressing record will boot iriver firmware as it is, btw
01.49.28 #       <pabs> preglow: unfortunately i need my iriver right now for drving, so it'll hvae to wait until i get back
01.49.43 #       <pabs> preglow: right
01.49.50 #       <preglow> default is rockbox
01.49.54 #       <pabs> cool
01.49.58 #       <pabs> well stay tuned, i'll be back in a bit
01.49.59 #       <pabs> :)
01.50.02 #       <preglow> ait
01.50.34 #       <preglow> has anyone actually tried flashing with american firmware?
01.50.39 #       <preglow> or korean?
01.50.43 #       <preglow> flashing rockbox with, i mean
01.50.52 #       <asdsd> lol
01.51.29 #       <asdsd> hey u preglow i can seriously mess up my h3xx if i flash it with h1xx firmware right?
01.51.34 #       <preglow> asdsd: indeed
01.51.40 #       <asdsd> i figured...
01.51.41 #       <preglow> asdsd: i doubt it would ever start again
01.51.52 #       <asdsd> yup
01.52.02 #       <Camilo> preglow,  have you run any code on H3xx?
01.52.17 #       <asdsd> so in the future when the firmware for the h1xx is released is it gonna be in the form of a patch to w/e firmware u want to use
01.52.24 #       <asdsd> or is it gonna be an actual hex file?
01.52.37 #       <preglow> Camilo: mno
01.52.44 #       <preglow> asdsd: patch
01.52.54 #       <preglow> asdsd: it's illegal to redistribute irivers firmware, afaik
01.53.03 #       <Stryke`> how can you pad an integer with 0's in a specific field width in c++
01.53.22 #       <preglow> Stryke`: you mean with printf and pals?
01.53.29 #       <preglow> or iostream?
01.53.30 #       <Stryke`> cout << setw(2) <<
01.53.37 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
01.53.51 #       <Stryke`> i have an integer anywhere from 0 to 99999
01.53.56 #       <Stryke`> and i need it formatted as xx-xxxx
01.54.28 #       <asdsd> oh ok
01.54.46 #       <Camilo> homework Stryke` ?
01.54.48 #       <Stryke`> yes
01.54.49 #       <Stryke`> ;-)
01.55.35 #       <Stryke`> i know printf("%05d" but i'm not to use it
01.55.42 #       <preglow> to be honest i have no idea how to do it with iostream
01.56.05 #       <prpplague> Stryke`: modulus?
01.56.12 #       <Camilo> http://www.arachnoid.com/cpptutor/student3.html
01.56.18 #       <preglow> hmm
01.56.22 #       <prpplague> Stryke`: there are about 100 ways of doing that
01.56.22 #       <Camilo> google is your friend
01.56.30 #       <preglow> you could use a combination of fill() and width()
01.56.47 #       <Stryke`> thanks
01.57.04 #       <Camilo> setfill('0')
01.57.21 #       <preglow> just cout.fill('0');
01.57.34 #       <Camilo> I hate C++
01.57.41 #       <Stryke`> will it only affect the next output or all
01.57.45 #       <preglow> i'm not very fond of it either, but it's ok enough
01.57.50 #       <preglow> Stryke`: all
01.57.51 #       <Camilo> :)
01.58.02 #       <preglow> it's fast and it's oo
01.58.06 #       <Stryke`> preglow: then to turn it back cout.fill(' '); ?
01.58.18 #       <Camilo> preglow,  about the bootloader, how did it come into being? What would it take to have a h3xx one?
01.58.42 #       <preglow> Stryke`: you can store the old fill char with 'char prev = cout.fill();'
01.58.56 #       <preglow> Camilo: research and some new drivers
01.59.01 #       <Stryke`> im sure it defaults to ' '
01.59.04 #       <preglow> Stryke`: it does
01.59.25 #       <Camilo> research as in reverse engineering the firmware?
01.59.30 #       <preglow> no
01.59.38 #       <preglow> research the hardware directly
01.59.40 #       <preglow> find datasheets, etc
01.59.50 #       <Camilo> has anyone compared the 3xx with 1xx firmwares?
01.59.54 #       <preglow> perhaps some reverse engineering if things are too impractical with other means
02.00.16 #       <preglow> Camilo: i don't see the point, you can pretty much tell they're not alike by comparing features
02.00.40 #       <Camilo> but they are likely to have some similarities at a low level surely?
02.00.50 #       <preglow> Camilo: yes, but why should that matter?
02.01.01 #       <Stryke`> only problem is it right pads in fill, not very good for ints
02.01.11 #       <preglow> Stryke`: it does?
02.01.12 #       <Camilo> the 1xx would give you a hypothetical jump start 
02.01.16 #       <preglow> Stryke`: that's braindead
02.01.19 #       <preglow> Camilo: it will
02.01.20 #       <Stryke`> i know
02.01.24 #       <preglow> Camilo: the hardware is pretty similar
02.01.28 #       <Stryke`> 123 showed up as 00-1230
02.01.32 #       <preglow> Camilo: we don't need to analyze the firmware to see that
02.01.48 #       <Camilo> what help do you most need to get the 1xx stuff done?
02.02.10 #       <preglow> Stryke`: that's right out stupid, who the hell needs right padding?
02.02.21 #       <Stryke`> im trying to understand myself
02.02.30 #       <Stryke`> to test i left alligned the text, but i still get right padding
02.02.31 #       <preglow> Camilo: we need faster codecs, and codec framework the most right now
02.02.38 #       <Camilo> preglow,  right to left writing language users maybe?
02.02.48 #       <Stryke`> Camilo: by default, though?
02.03.09 #       <preglow> padding is almost always used with numbers, and padding numbers is mostly always done on the left hand side
02.03.13 #       <Camilo> I'm not an internationalisation expert but I've come across it
02.05.37 #       <Camilo> preglow,  is there a DSP chip for the codecs?
02.08.04 #       <preglow> Camilo: the main chip in the h1x0 also has some dsp capabilities
02.11.44 #       <Camilo> can you compile the stuff to run on a PC?
02.12.04 #       <preglow> what stuff?
02.12.22 #       <preglow> if you mean rockbox, yes, that's what the simulators are for
02.13.11 #       <Camilo> how do you measure the performance of the codecs? You say they are too slow.
02.13.49 #       <preglow> we measure them by decoding a file on the player and seeing how fast they do it
02.14.34 #       <amiconn> Speaking about the codec - could someone please test something for me?
02.14.35 #       <Camilo> what fraction of realtime is it?
02.14.57 #       <preglow> amiconn: sure, if i can
02.14.59 #       <amiconn> I've prepared a patch that allows proper linking on cygwin, and maybe others
02.15.11 #       <preglow> i, don't do cygwin :P
02.15.17 Join    pill [0] (dearth@ip-130.net-82-216-140.issy4.rev.numericable.fr)
02.15.26 #       <preglow> ahh, i don't do cygwin <- what i meant
02.15.41 #       <preglow> Camilo: on rockbox as it is, very slow, mp3 runs at around 4% of realtime
02.15.54 #       <preglow> Camilo: linus has mp3 running at nearly 100% realtime on his player
02.16.06 #       <preglow> Camilo: and i'm working on speeding it up, there's a lot more we can do
02.16.16 #       <amiconn> I know. I want it to be tested whether it still works correct on the target, and on a plain Linux X11 simulator
02.16.39 #       <Camilo> ok I will try to get the linux sim working and see what I can learn
02.16.39 #       <preglow> amiconn: well, as you've seen, i haven't got much luck on the linus fron either :)
02.16.45 #       <amiconn> Grab it here: http://amiconn.dyndns.org/malloc.diff This also needs http://amiconn.dyndns.org/codec.h in apps/codecs
02.16.48 #       <preglow> LINUX FRONT, arghh
02.17.04 #       * preglow switches lights on again
02.17.26 #       <amiconn> Probably the most important is the actual target
02.17.35 #       <amiconn> I don't have such...
02.17.58 #       <preglow> ok, i'll try compiling it for h120
02.18.04 #       * amiconn should also start apache...
02.18.20 Join    ghode|afk [0] (dude@host217-137-6-17.no-dns-yet.ntli.net)
02.18.33 #       <amiconn> ...done
02.18.48 #       <preglow> ok, latest cvs with those changes?
02.18.53 #       <amiconn> yup
02.20.27 #       <amiconn> Please check whether it compiles, preferably without warnings, and also whether the codec test plugins run correctly (one or two should be sufficient, one of the should be vorbis2wav)
02.20.28 #       <ghode|afk> preglow: still need someone to test your patcher?
02.21.05 #       <preglow> patching file apps/codecs/libwavpack/wavpack.h
02.21.05 #       <preglow> Hunk #1 FAILED at 8.
02.21.05 #       <preglow> 1 out of 1 hunk FAILED -- saving rejects to file apps/codecs/libwavpack/wavpack.h.rej
02.21.08 #       <preglow> patching file apps/plugins/lib/xxx2wav.c
02.21.09 #       <preglow> ghode|afk: sure
02.21.17 #       <ghode|afk> ok
02.21.51 #       <amiconn> preglow: You're patching against current cvs?
02.21.58 #       <preglow> amiconn: indeed, i just did an update
02.22.18 #       <amiconn> Hmm, strange. The diff *is* against current cvs....
02.22.19 #       <ghode|afk> will you put cvs version numbers in future patchers?
02.22.42 #       <amiconn> (created with cvs diff -u)
02.22.48 #       <preglow> ghode|afk: how?
02.23.03 #       <ghode|afk> hmm
02.23.13 #       <ghode|afk> nm me :p
02.23.16 #       <preglow> amiconn: well, i haven't touched that specific header anyway
02.23.35 #       <amiconn> Any other failures?
02.23.52 #       <ghode|afk> preglow: "checksum does not match good patched firmware! download another firmware imgae, then try again" with 1.63K
02.23.59 #       <preglow> amiconn: no, really stupid reject anyway, i've done it by hand
02.24.07 #       <preglow> ghode|afk: good, you need to try the eu one
02.24.14 #       <amiconn> It's only the one added #include...
02.24.16 #       <preglow> ghode|afk: that's the only one i've supplied an md5 for now
02.24.21 #       <ghode|afk> ok
02.24.27 #       <preglow> amiconn: i know, i can't imagine why patch didn't manage that
02.24.46 #       <ghode|afk> eu is quite bad because of volume limitations. btw which eu 1.60 or 1.63?
02.25.05 #       <preglow> ghode|afk: newest you can find
02.25.19 #       <preglow> ghode|afk: and as far as i know, there are no volume limitations in h1x0 firmware yet
02.25.40 #       <preglow> ghode|afk: i'll supply md5s for all firmwares soon anyway
02.26.34 #       <preglow> amiconn: mpa2wav.rock linking vomits quite copiously
02.26.55 #       <preglow> amiconn: i'll spam the details to you in query
02.26.56 #       <amiconn> Huh?
02.27.11 #       <asdsd> hey preglow is it also illegal to distribute archos firmware or do u gotta supply the patches for those too
02.27.51 #       <preglow> asdsd: the archos doesn't have that particular problem as it needs no bootloader
02.27.55 #       <ghode|afk> preglow: dumb question, what does the "download" button do?
02.28.18 #       <ghode|afk> or what is it supposed to do?
02.28.19 #       <preglow> ghode|afk: as i said, nothing yet :P
02.28.32 #       <preglow> ghode|afk: it will download the firmware if that's a feature people want
02.28.40 #       <ghode|afk> k,  i missed that ;p
02.29.21 #       <preglow> ghode|afk: but did it patch the firmware? could you make an md5sum for me if you're capable?
02.30.04 #       <ghode|afk> downloading it on 56k atm, and no idea how to do a md5sum
02.33.50 #       <elinenbe> preglow: linus has mp3 running at 100% on his iriver?
02.34.14 #       <preglow> elinenbe: he had 95% realtime after using a synth_full opt i made
02.36.53 #       <pabs> back
02.37.11 #       <ghode|afk> grrr
02.38.21 #       <ghode|afk> preglow: file patched ok with 1.63eu md5sum: 627d5195b56ebca3b3b431cccb535c3bfa hand typed ><
02.39.05 #       <elinenbe> preglow: nice...
02.39.09 #       <preglow> ghode|afk: splendid, that's just right, thanks
02.39.19 #       <ghode|afk> np
02.39.54 #       <preglow> then we've got a tool ready for release, at least
02.40.25 #       <ghode|afk> lol 
02.40.53 #       <ghode|afk> btw, which release of rockbox did i just patch?
02.41.03 #       <elinenbe> preglow: is that running the mp3 (madlib?) codec, and if so, what is the interface?
02.41.14 #       <HCl> the bootloader on the wiki
02.41.41 #       <preglow> elinenbe: that's running a lightly customized libmad, yes, interface is mpa2wav plugin
02.42.02 #       <elinenbe> preglow: that's great!
02.42.08 #       <preglow> elinenbe: i agree :)
02.42.14 #       <preglow> but still not great enough
02.42.18 #       <elinenbe> preglow: and is it producing sound on the target?
02.42.30 #       <preglow> elinenbe: not directly, no, but but we'll get around to that
02.42.37 #       <preglow> with any luck sound will make it to cvs during this week
02.42.48 #       <elinenbe> still... i mean rockbox/iriver is in it's infancy
02.42.57 #       <preglow> yup
02.43.05 #       <preglow> progress has been really quick
02.43.13 #       <elinenbe> brb
02.43.15 Quit    elinenbe (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new IRC era")
02.44.07 Quit    ghode|afk ()
02.45.52 #       <preglow> wee, i've used a goto statement in a c program for my first time!
02.46.05 #       <HCl> ew
02.46.07 #       <HCl> gotos bad
02.46.10 #       <preglow> haha, yes
02.46.16 #       <preglow> but they're nice for error handlinmg
02.46.24 #       <HCl> mrf.
02.46.26 #       <HCl> well.
02.46.33 #       <HCl> i'm gonna go sleep
02.46.35 #       <HCl> nightnight
02.46.47 #       <HCl> oh
02.46.56 #       <HCl> and update the todo thing about the patcher
02.47.03 #       <Camilo> gotos are fine in firmware
02.47.33 #       <preglow> ok
02.56.11 Quit    skav ()
02.58.29 #       <Camilo> hmmm the daily rockox doesn't build for me (iriver/simulated/x11)
02.58.53 #       <preglow> there are problems with the sims right now
02.59.40 #       <Camilo> it seems more of a makefile problem than a c problem... any hints?
03.00.31 #       <preglow> well, error message?
03.00.34 #       <amiconn> What system?
03.00.46 #       <Camilo> Entering directory `/home/cxm/rockbox-daily-20050227/uisimulator/common
03.00.56 #       <Camilo> *** No targets specified and no makefile found.  Stop.
03.01.13 #       <Camilo> It's like it's done a make -C that directory but there was no makefile there
03.01.23 #       <amiconn> You need a build directory, and then use configure
03.01.44 ***     Saving seen data "./dancer.seen"
03.01.46 #       <amiconn> ..to create the customised "master" Makefile there
03.02.08 #       <Camilo> amiconn,  I did mkdir /home/cxm/rockbox-daily-20050227/cxmbuild
03.02.23 #       <Camilo> and in there did the ../tools/configure
03.02.32 #       <Camilo> then make all
03.02.43 #       <asdsd> hey preglow how many hits have u gotten today offa that slashdotted link
03.03.06 #       <preglow> asdsd: around ten thousand, i'm disappointed :/
03.03.22 #       <amiconn> Camilo: Hmm. This should work...
03.03.26 #       <Camilo> (the system is linux 2.6, gcc 3.4.2)
03.03.35 #       <HCl> well, preglows site wasn't directly linked
03.03.36 #       <Camilo> shall I try again?
03.03.42 #       <HCl> the article linked to that one article
03.03.47 #       <HCl> which linked to another article
03.03.54 #       <HCl> and neither really linked to preglow
03.04.01 #       <HCl> so the only ones that found preglow site used the wiki
03.04.02 #       <preglow> nah, it was indirectly indirectly linked
03.04.35 #       <preglow> if you clicked on the picture in the article and clicked another pictures link, you got me
03.05.41 #       <Camilo> amiconn,  do you have a build tree handy? tell me is there a Makefile in the uisimulator/common dir?
03.05.50 #       <asdsd> why r u dissapointed dude, thats a lot
03.06.23 #       <preglow> asdsd: yes, i know, i'm just joking around
03.06.24 #       <amiconn> Camilo: Yes, there is. Is there no makefile in the daily tarball?
03.06.39 #       <preglow> amiconn: look in query for "good" news
03.06.41 #       <Camilo> yes there is no makefile there
03.06.52 #       <Camilo> I'll get an older taball and steal one from there
03.07.16 #       <amiconn> No... chances are there is none either
03.07.32 #       <amiconn> It seems someone forgot to add it to the FILES list
03.08.26 #       <Camilo> serves me right for being too lazy to get it from cvs
03.11.59 #       <Camilo> ok it's better now (got the file from CVS browse )
03.12.15 #       <Camilo> someone put that makefile in the manifest pls?
03.12.22 #       <amiconn> I already did.
03.13.27 #       <Camilo> Cool. I think I'll make this my lunchtime project
03.15.28 #       <preglow> i'm off
03.15.29 #       <preglow> nite
03.15.37 #       <amiconn> Night
03.15.38 Quit    preglow ("dud")
03.17.25 Join    ze__ [0] (ze@adsl-69-231-238-2.dsl.irvnca.pacbell.net)
03.17.55 Part    amiconn
03.20.24 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
03.21.39 Join    bnewhouse [0] (~bnewhouse@cpe-24-94-54-216.stny.res.rr.com)
03.22.21 #       <bnewhouse> hey... so im trying to compile rockbox... and i keep getting an error about the calculator...
03.22.34 #       <bnewhouse> and im using current cvs.....
03.23.14 Quit    midk ("Leaving")
03.24.55 Quit    XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference")
03.25.46 #       * pabs searches around for m68k toolchain debs
03.29.31 Quit    Camilo ("Chatzilla 0.9.67 [Mozilla rv:1.8a6/20050111]")
03.30.55 #       <bnewhouse> is anyone live?
03.31.25 Quit    ze (Read error: 110 (Connection timed out))
03.31.25 Nick    ze__ is now known as ze (ze@adsl-69-231-238-2.dsl.irvnca.pacbell.net)
03.41.07 Join    webguest63 [0] (~4328884a@labb.contactor.se)
03.42.00 Quit    webguest63 (Client Quit)
03.45.15 Quit    Aison ("( www.nnscript.de :: NoNameScript 3.72 :: www.XLhost.de )")
03.48.21 #       <asdsd> most of the guys already went to bed
03.48.31 #       <asdsd> they've had a long night working on the iriver
03.48.57 #       <asdsd> if only someone were nice enough to just release the iriver firmware source code
03.54.55 #       <bnewhouse> haha
03.54.56 #       <bnewhouse> pft
03.55.19 #       <bnewhouse> well then thered be no fun to it all...
04.03.17 #       <hile> I guess there would be, why are you expecting it would be such quality that we actually could use it ;)
04.04.39 #       <bnewhouse> haha im confused...
04.04.43 #       <bnewhouse> well anyway
04.04.58 #       <bnewhouse> i think my problem is cus i dont have the lastest version of gcc....
04.05.05 #       <bnewhouse> so, for the record, try that...
04.05.54 #       <hile> I haven't done anything on the sw, I'm just hanging here to see how the port is going on -> can't help
04.05.57 Join    QT_ [0] (as@area51.users.madwifi)
04.20.06 Quit    QT (Read error: 113 (No route to host))
04.20.27 #       <bnewhouse> yeah...
04.20.34 #       <bnewhouse> im trying to get something done
04.20.42 #       <bnewhouse> but first i have to get a successfull compile
04.29.53 #       <pabs> alright
04.29.55 #       <pabs> momento f truth
04.29.59 #       <pabs> i'm about to flash my iriver 
04.33.03 #       <pabs> so uh
04.33.15 #       <pabs> it works, but i'm kind of missing a play interface
04.33.48 #       <bnewhouse> arr
04.33.49 #       <bnewhouse> we
04.33.49 #       <bnewhouse> ll
04.33.52 #       <bnewhouse> that didnt work
04.34.02 #       <bnewhouse> cus i still cant get it all to compile...
04.36.43 Join    chuck [0] (something@61-23-62-13.rev.home.ne.jp)
04.42.31 #       <bnewhouse> but i am trying switching versions for 3.35 to 3.4.3
04.42.46 #       <bnewhouse> *3.3.5
04.55.20 #       <pabs> so uh, i have no audio here
04.55.31 #       <pabs> other than that it works great :)
05.01.45 ***     Saving seen data "./dancer.seen"
05.20.35 Quit    prpplague ("Client Exiting")
05.26.37 #       <bnewhouse> there isnt supposed to be i dont think...
05.26.44 #       <bnewhouse> i know theyve got wav working
05.26.56 #       <bnewhouse> but im not sure if they've patched it to the CVS
05.28.37 Join    webguest11 [0] (~18163f8e@labb.contactor.se)
05.29.24 Quit    webguest11 (Client Quit)
05.34.02 #       <pabs> bnewhouse: cool, then i feel better
05.34.06 #       <pabs> in that case
05.34.12 #       <pabs> this is awesome :)
05.52.32 Join    kramerica [0] (~lkd@hsdbsk142-165-191-185.sasknet.sk.ca)
06.11.53 Quit    kramerica ()
06.34.33 Join    ashridah [0] (ashridah@220-253-120-84.VIC.netspace.net.au)
06.56.55 Join    DMJC [0] (~James@220-245-162-47-sa-nt.tpgi.com.au)
06.59.34 #       <ashridah> fuck. HCl just acheived slashdot fame :)
06.59.40 #       <ashridah> (well. a while ago)
07.00.32 #       <DMJC> heh
07.00.37 #       <DMJC> I saw
07.01.25 #       <ashridah> nevermind that it doesn't even run fast enough to be playable yet.
07.01.47 ***     Saving seen data "./dancer.seen"
07.01.56 #       <DMJC> it's slashdot
07.02.03 #       <DMJC> all you need is a theory and you get famous
07.05.17 Quit    bnewhouse (Remote closed the connection)
07.18.02 Join    Strath [0] (~mike@dgvlwinas01pool0-a239.wi.tds.net)
07.18.46 Quit    ashridah ("Leaving")
07.27.27 #       <mst> s/theory/a combination of words/
07.35.19 Join    webguest72 [0] (~0cd866cf@labb.contactor.se)
07.35.33 Quit    webguest72 (Client Quit)
07.35.35 Join    webguest01 [0] (~0cd866cf@labb.contactor.se)
07.35.55 Quit    webguest01 (Client Quit)
07.36.10 Join    LinusN [0] (~linus@labb.contactor.se)
07.40.41 Quit    StrathAFK (Read error: 110 (Connection timed out))
07.48.54 #       <LinusN> HCl: u there?
07.50.25 Join    ashridah [0] (ashridah@220-253-121-1.VIC.netspace.net.au)
07.54.18 #       <ashridah> well. i've countered my three bits of semi-fud on slashdot today. have you? :)
07.58.18 #       <LinusN> :-)
07.58.50 #       <ashridah> i was wondering how long that'd take to hit slashdot.
07.59.37 #       <LinusN> hehe
08.00.13 #       <ashridah> i particularly like how vague the article slashdot linked to was :)
08.01.26 #       <LinusN> engadget?
08.04.07 #       <ashridah> yeah.
08.04.19 #       <ashridah> no mention of how slow it is atm, or that it's specifically only for the archos, etc.
08.07.53 #       <LinusN> you mean iriver
08.10.12 #       <dwihno> yay! mondaY!
08.10.24 #       <dwihno> This is the day I envy Zagor :)
08.12.50 #       <LinusN> hehe
08.25.32 #       <webmind> morning
08.25.54 #       <LinusN> mooning
08.36.07 #       <ashridah> what's zagor getting that's enviable?
08.36.30 #       <ashridah> LinusN: and yeah. it's like 35 degrees atm. i'm not thinking straight.
08.37.15 #       <LinusN> zagor is on leave
08.37.36 #       <LinusN> and it's -10 celcius here :-)
08.38.08 #       <ashridah> heh
08.38.30 #       <ashridah> wish it snowed here. then i see shots of people shovelling snow and having a totally iced over car, and i don't.
08.39.03 #       <ashridah> :)
08.49.45 #       <LinusN> i love snow
08.49.51 #       <dwihno> me too
08.49.53 #       <ashridah> as do i
08.50.04 #       <ashridah> love skiing. although it's on the icy side here
08.50.20 #       <dwihno> I rather have -20c and no clouds in the sky instead of 0-ish and graymulet
08.50.21 #       <dwihno> ;)
09.01.50 ***     Saving seen data "./dancer.seen"
09.02.02 #       <ashridah> sadly, australia's southernmost point is still well above the antarctic regions/
09.08.58 Nick    kergoth is now known as kergoth`zzz (~kergoth@li11-226.members.linode.com)
09.13.24 Nick    Lynx_awy is now known as Lynx_ (HydraIRC@134.95.189.59)
09.22.12 Join    jyp [0] (~jp@128.139-200-80.adsl.skynet.be)
09.48.32 Join    shx [0] (~a4810127@labb.contactor.se)
09.50.16 Nick    Strath is now known as StrathAFK (~mike@dgvlwinas01pool0-a239.wi.tds.net)
09.51.58 Join    Schnueff [0] (~mah@134.96.247.233)
10.00.32 Join    amiconn [0] (~jens@pD95D1467.dip.t-dialin.net)
10.18.30 Join    bobTHC [0] (~foo@l03v-36-58.d1.club-internet.fr)
10.19.42 #       <bobTHC> hi folks!
10.19.47 #       <LinusN> hey ho
10.20.05 #       <jyp> Hey
10.20.17 #       <jyp> some core devs back ;)
10.21.19 #       <jyp> A question probably for amiconn ...
10.21.57 Quit    shx ("CGI:IRC (EOF)")
10.22.31 #       <jyp> I'd like to tag the proto of panicf with ATTRIBUTE_PRINTF(1, 2)
10.23.52 #       <jyp> the question is should I include sprintf.h in panicf.h, or more the definition of ATTRIBUTE_PRINTF somewhere else?
10.27.52 #       <LinusN> you mean if you should #define ATTRIBUTE_PRINTF in sprintf.h?
10.32.52 Join    Tang [0] (~chatzilla@ARennes-252-1-33-137.w83-195.abo.wanadoo.fr)
10.33.45 #       <jyp> LinusN: yes; where is it best placed ?
10.40.23 #       <LinusN> stdio.h could be a good place
10.40.51 #       <LinusN> or _ansi.h
10.41.32 #       <LinusN> as long as it works for the simulators as well
10.42.10 #       <jyp> ok; it doe.s
10.44.35 #       <amiconn> I have a rather complex change pending that's still not complete. It will probably change more files at once than each of the initial codec checkins...
10.44.57 #       <jyp> whoa ;)
10.47.11 #       <LinusN> amiconn: sounds wonderful, what is it?
10.49.07 #       <amiconn> It enables compiling the codecs and codec plugins on cygwin.
10.49.27 #       <amiconn> The problem is that xxx2wav.c defines malloc() and friends
10.49.37 #       <LinusN> oki
10.49.59 #       <LinusN> what's your solution?
10.50.01 #       <amiconn> The cygwin linker is mislead by this. It seems like it tries to use these for the dll startup...
10.50.15 #       <amiconn> ...leading to numerous crashing plugins
10.51.17 #       <amiconn> I now have a header for all codecs (apps/codecs/codec.h) that defines a number of macros to get these functions out of the way
10.51.44 #       <amiconn> #define malloc(x) codec_malloc(x)   etc
10.51.45 #       <LinusN> nice
10.52.04 #       <LinusN> btw, maybe it's time to abandon rombox for ondio fm?
10.52.22 #       <amiconn> This requires to add a central .h file for those codecs that don't already have one
10.52.34 #       <amiconn> (Tremor, flac)
10.52.49 #       <LinusN> ok
10.52.55 #       <amiconn> The codecs must not include stdlib.h ....
10.53.41 Quit    Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]")
10.53.42 #       <amiconn> rombox for Ondio FM didn't fit for a long time now... but the build worked until feb-18
10.54.35 #       <LinusN> odd
10.55.36 #       <amiconn> I need a way to test my modifications for a target compile... I just came up with the idea to compile them for archos
10.56.20 #       <LinusN> you should get yourself an iriver
10.57.05 #       <amiconn> I should get some things done before I get myself another toy...
10.57.16 #       <amiconn> ...e.g. the oldplayer lcd test...
10.57.48 #       <amiconn> Btw, I still have a strange issue with the X11 sim on cygwin.
10.57.54 #       <LinusN> has jörg got his pile of junk from ebay?
10.58.23 #       <amiconn> Don't know... he didn't come here since last week
10.59.06 #       <amiconn> In a cygwin built X11 simulator, lseek() doesn't work. However, it works in a cygwin built win32 simulator...
10.59.43 #       <amiconn> ...as well as in an X11 simulator built on Linux
11.00.04 #       <amiconn> However, lseek() works on cygwin X11 when built with the old build system...
11.00.38 #       <amiconn> I'm running out of ideas what to check
11.01.54 ***     Saving seen data "./dancer.seen"
11.02.31 #       <LinusN> in what mode was the file opened?
11.05.05 Join    preglow [0] (thomj@s183a.studby.ntnu.no)
11.05.25 #       <amiconn> I made up a special test plugin, to avoid possible side effects. It opens the file with  O_RDWR | O_CREAT | O_TRUNC
11.06.54 #       <LinusN> and lseek fails how?
11.07.04 #       <LinusN> lseek beyond the end, or?
11.07.10 #       <amiconn> This very same plugin works for cygwin/win32, Linux/x11 and old cygwin/x11. It doesn't work for new cygwin/x11
11.07.20 #       <amiconn> lseek() returns with -1
11.07.26 #       <LinusN> errno?
11.07.28 #       <amiconn> No out-of-range seek
11.07.39 #       <amiconn> errno seems to be uncheckable in rockbox
11.08.15 #       <preglow> LinusN: i eventually got that imdct_s opt working
11.08.20 #       <LinusN> amiconn: email me the plugin
11.08.25 #       <LinusN> preglow: nice!
11.08.35 #       <preglow> LinusN: how safe is it to reference symbols directly in inline asm?
11.08.39 #       <amiconn> http://amiconn.dyndns.org/test_file.c
11.08.54 #       <preglow> LinusN: is there any danger of them having underscores in front of them on some platforms?
11.09.29 #       <amiconn> LinusN: The same problem occurs with the codec test plugins. They work almost correctly, but since lseek() doesn't work, they write the correct .wav header at the end...
11.09.42 #       <LinusN> preglow: the underscores ate platform specific
11.09.45 #       <LinusN> are
11.10.21 #       <LinusN> preglow: but the asm is too, so it's generally safe
11.10.29 #       <preglow> LinusN: hah, true enough
11.10.51 #       <amiconn> preglow: I do that too in the grayscale lib... I even rely on a certain libgcc routine...
11.11.21 #       <preglow> elf doesn't use _ at the start, but coff is pretty widespread as well
11.11.28 #       <preglow> amiconn: pretty
11.27.15 #       <preglow> LinusN: but yes, libmad has two c imdct_l variants, one that does decomposing into smaller, different imdcts, and one that's the ordinary mac based monster
11.27.32 #       <preglow> the mac instructions is very fast, so i think i'll give the latter one a go
11.27.44 #       <LinusN> great
11.28.23 #       <preglow> the mac with shift scheme i used in imdct_s worked great, so should here as well
11.31.33 Join    UlfJack [0] (~Ulf@139.30.201.19)
11.31.53 #       <UlfJack> hiho
11.33.31 Join    Aison [0] (~hans@zux166-181.adsl.green.ch)
11.35.40 #       <LinusN> amiconn: the X11 simulator uses a different open() function than the win32 sim
11.36.30 #       <LinusN> looks like WIN32 isn't defined in the cygwin x11 build
11.39.32 #       <LinusN> perhaps the NOCYGWIN is a problem?
11.40.15 #       <LinusN> or rather, lack of
11.47.50 #       <amiconn> No, all of these are in fact correct.
11.48.15 #       <LinusN> the fact remains, WIN32 is not defined, and it uses a different open()
11.48.37 #       <amiconn> Yes... because it isn't a win32 sim, but an X11 sim
11.48.53 #       <amiconn> This worked the same way with tthe old build system
11.49.43 #       <amiconn> The NOCYGWIN isn't used for the X11 builds, at least after I corrected that
11.50.21 #       <preglow> arm asm certainly seems to be pretty nice
11.50.32 Join    linuxstb [0] (~linuxstb@213.86.218.27)
11.51.24 #       <amiconn> LinusN: If I use the other open() syntax for x11, I get a 'wrong number of arguments' error
11.58.46 #       <amiconn> jyp: Your fat.c changes cause warnings if fat16 support is enabled, i.e. Ondio
12.01.55 #       <amiconn> s/fat.c/panicf/
12.04.19 #       <preglow> how do we feel about our patcher tool not handling directory names with fancy characters in them? :)
12.05.15 #       <jyp> amiconn: I already comitted a fix
12.25.31 #       <preglow> how i love windows programming
12.36.23 #       <LinusN> make
12.36.29 #       <LinusN> oops
12.36.44 #       <ashridah> make: *** No targets specified and no makefile found.  Stop.
12.36.52 #       <LinusN> :-)
12.37.27 #       <LinusN> bash: oops: command not found
12.37.48 #       <ashridah> bash: syntax error near unexpected token `)'
12.37.58 #       <preglow> haha
12.38.06 #       <LinusN> amiconn: i have found the sim problem
12.38.09 #       <preglow> LinusN: how close are we to seeing speedups in cvs, btw?
12.38.55 #       <LinusN> preglow: i am a bit reluctant, but i guess i could commit the changes and let people run them on their own risk
12.40.02 #       <preglow> what can go wrong?
12.40.52 #       <LinusN> i don't know what the overheating does to the cpu in the long run
12.40.59 #       <preglow> there's no particular hurry if you feel there's parts you're unsure of, we'll need a codec api before we can do interesting things
12.41.08 #       <ashridah> disk corruption, longterm accelerated failure due to excessive heat? 
12.41.26 #       <preglow> LinusN: well, you don't _have_ to run it at full speed?
12.41.34 #       <preglow> LinusN: will it overheat at 90ish mhz as well?
12.41.37 #       <LinusN> no i don't
12.41.48 #       <LinusN> haven't tested 90MHz yet
12.43.44 #       <preglow> it sucks that you can't get h1x0 anymore
12.44.46 #       <preglow> i'd like a new one if i kill this one ;)
12.46.09 #       <DMJC> hehehe
12.58.19 #       <amiconn> LinusN: What is the sim problem?
12.58.42 #       <dwihno> Hey, I just read about the gnuboy posts on engadget and slashdot
12.58.45 #       <LinusN> the x11 cygwin unix layer uses a 64-bit off_t
12.59.01 #       <dwihno> feels like the firmware is losing the focus
12.59.07 #       <LinusN> and the sims include our own types.h instead of the system one
12.59.55 #       <amiconn> Ah, interesting. The sims should use our own includes, except for the parts under uisimulator/
12.59.59 Join    cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de)
13.00.39 #       <LinusN> in fact, the sims shouldn't use firmware/include at all
13.00.43 #       <amiconn> Then we need a sim_lseek() the same way as the other sim_* functions that does the translation
13.01.28 #       <amiconn> If the sims shouldn't use firmware/iclude, then some stuff must be moved somewhere else
13.01.55 ***     No seen item changed, no save performed.
13.02.04 #       <amiconn> Bagder wants (and I agree that this is good), that the sims use as much rockbox code as possible
13.02.46 #       <amiconn> E.g. all the string functions can be used in the simulator
13.02.58 #       <LinusN> yes, but the (initial) whole point of the firmware/include dir was to be target only
13.03.19 #       <amiconn> Yeah.. so the string stuff belongs somewhere else, right?
13.03.26 #       <LinusN> since the host has its own implementation of those functions
13.03.52 #       <LinusN> amiconn: the firmware/include dir has only .h files
13.04.01 #       <amiconn> Yes.. and some of them must be simulated for various reasons
13.04.22 #       <LinusN> yes, but the implementations are not in the .h files
13.04.53 #       <amiconn> Yes.. but e.g. string.h is in firmware/include
13.05.25 #       <amiconn> The simulator builds should use our own string.h as well when they're going to use our own string function implementatipn
13.06.12 #       <LinusN> yes, and that wasn't the initial idea
13.06.33 #       <LinusN> the initial idea was to use the host functions for posix stuff
13.07.04 #       <amiconn> But do you agree that it is good to use our own string functions? Imho this has at least 2 advantages
13.07.05 #       <LinusN> types.h is a typical example of why that is a good idea
13.07.12 #       <LinusN> i agree
13.07.32 #       <LinusN> but how does that affect string.h?
13.08.16 #       <amiconn> (1) We can find bugs in our implementation when using the sims also (2) It implements functions that may be missing on some target systems. strcasestr() is one example...
13.08.36 #       <LinusN> okidoki
13.09.42 #       <amiconn> Well, string.h holds the prototypes of the string functions, and if we want to use our own implementation, the sims also have to use the correct prototypes
13.09.54 #       <LinusN> i have a dirty fix for the cygwin x11 problem
13.10.06 #       <amiconn> Dirty in what way?
13.10.27 #       <LinusN> it adds a check for __CYGWIN_USE_BIG_TYPES__ in our types.h
13.10.50 #       <amiconn> Hmm. That sounds a bit ugly...
13.10.58 #       <LinusN> instead of (correctly) using the system types.h
13.11.35 #       <amiconn> Imho the rockbox part should also use firmware/include for simulator builds, only the uisimulator/ part must not.
13.12.07 #       <amiconn> Then lseek() must be implemented as simulated function, with uisimulator/common/io.c using the system's types.h
13.12.25 #       <LinusN> it does use firmware/include for sim builds today
13.12.42 #       <amiconn> ...and the argument of course *not* using off_t, but our own datatype (iirc long)
13.13.15 #       <amiconn> I already tried adding a simulated lseek, only that I used off_t for the argument and return type ...
13.13.28 #       <LinusN> amiconn: can you fix that, i don't have the time
13.13.31 #       <LinusN> ?
13.13.54 #       <LinusN> btw, perror() works just fine in the plugins
13.13.56 #       <amiconn> Okay, I'll try that this evening. I think that it'll work.
13.14.19 #       <LinusN> helped me find this error
13.14.30 #       <LinusN> strace is another nice tool
13.14.43 #       <amiconn> I didn't think about the possibility that cygwin may use 64 bit dataypes...
13.15.57 #       <LinusN> neither did i
13.17.30 #       <LinusN> but perror() and strace told me so :-)
13.22.09 Quit    Sando (Read error: 104 (Connection reset by peer))
13.22.14 #       <LinusN> lunch
13.33.44 Join    R3nTiL [0] (~zorroz@83.69.98.124)
13.44.58 Part    LinusN
13.48.29 Quit    ashridah ("Leaving")
13.59.49 #       <preglow> hrmf, the funny imdct is what's used by defaykt
13.59.52 #       <preglow> default, even
14.01.49 Join    muesli- [0] (muesli_tv@c-180-220-208.cvx-h.dial.de.ignite.net)
14.02.52 Quit    muesli- (Client Quit)
14.02.56 Join    muesli- [0] (muesli_tv@c-180-220-208.cvx-h.dial.de.ignite.net)
14.17.13 Quit    bobTHC (Read error: 110 (Connection timed out))
14.23.34 Join    Supabaka [0] (~kipperik@ip51cc4ee4.adsl-surfen.hetnet.nl)
14.23.39 #       <Supabaka> !list
14.23.55 #       <preglow> Supabaka: wrong channel
14.24.06 #       <Supabaka> yep, sorry
14.24.20 Part    Supabaka
14.25.00 Quit    jyp (Read error: 104 (Connection reset by peer))
14.25.18 Quit    R3nTiL ()
14.25.34 Join    bobTHC [0] (~foo@l03v-36-58.d1.club-internet.fr)
14.26.59 Join    jyp [0] (~jp@128.139-200-80.adsl.skynet.be)
14.32.21 Quit    lostlogic ("Going to the moon")
14.33.53 Join    Sando [0] (kekekek@CPE-147-10-21-132.vic.bigpond.net.au)
14.49.37 Quit    edx ()
14.56.02 Quit    muesli- (Read error: 54 (Connection reset by peer))
15.01.58 ***     Saving seen data "./dancer.seen"
15.07.14 Join    edx [0] (edx@pD9EAA65B.dip.t-dialin.net)
15.10.04 #       <CoCoLUS> mornin
15.21.20 Join    lolo-laptop [0] (~lostlogic@68.251.84.226)
15.34.55 Join    AC [0] (~5078751e@labb.contactor.se)
15.35.13 #       <AC> hi
15.35.48 #       <AC> when will irivers lcd support gray mode?
15.42.26 #       <AC> i want to start a new graphical project with rockbox
15.44.28 Join    Renko [0] (~Renko@host217-43-59-246.range217-43.btcentralplus.com)
15.45.35 #       <chuck> gay mode?
15.46.00 #       <AC> gray
15.46.02 #       <AC> soory
15.46.10 #       <chuck> grey?
15.46.50 #       <AC> GRAY SCALE
15.47.29 #       <AC> white, black and 2 colors between
15.48.14 #       <chuck> oh
15.48.28 #       <fuzzie> someone was showing http://130.89.160.166/rockbox/iriver-grayscale.jpg yesterday
15.48.33 #       <fuzzie> so i assume 'soon', at least
15.48.50 #       <AC> ah fine
15.48.59 #       <preglow> soonish, yes, we need to convert everything to use it first :V
15.49.18 #       <preglow> AC: what kind of project?
15.49.23 #       <AC> i see
15.49.39 #       <AC> preglow: i want to try to get opengl es 1.0 running
15.50.39 #       <preglow> ahahahha
15.50.42 #       <preglow> cool
15.51.20 #       <pabs> preglow: hey, thanks for the help last night, i'm up and running with rockbox on my h120
15.51.21 #       <AC> yeah.. i have done many years opengl programming and i think it would be cool to get it also running on the iriver.. 
15.51.43 #       * AC makes a break
15.51.43 #       <preglow> pabs: you're welcome
15.51.59 #       <preglow> i've done some opengl programming myself
15.52.06 #       <preglow> but not very experienced
15.54.30 #       <preglow> AC: it would be extremely cool as a matter of fact,heh
15.55.54 #       <dwihno> AC: A GUI project?
15.56.01 #       <dwihno> AC: I want to join you in that venture!
15.58.42 #       <preglow> AC: what are the major differences between opengl es and ordinary opengl?
15.59.26 #       <bobTHC> AC : have u seen the feature request whi deals with GUI ?? >>https://sourceforge.net/tracker/?func=detail&aid=772181&group_id=44306&atid=439121
15.59.53 #       <fuzzie> opengl es is just a simpler subset, designed for software implementation, with a standard glx/wgl replacement for binding it to the display
16.00.12 #       <preglow> fuzzie: well, what has been left out?
16.01.38 #       <fuzzie> good question, i don't know, i just know what's been left in .. which is pretty much 'the minimum you need for simple games' .. a lot of it is optional anyway, meaning you can strip it down to real simplicity
16.03.03 #       <fuzzie> eg, it doesn't require zbuffer/stencil support, which would kill a lot of low-end unaccelerated cpus
16.03.22 Join    markun [0] (~markun@bastards.student.utwente.nl)
16.05.02 #       <markun> AC: I'm the grayscale guy.
16.08.04 #       <dwihno> markun: you got grayscale up'n'running?
16.08.39 #       <markun> Well, a bit. The picture was from my iriver.
16.08.57 #       <dwihno> markun: congrats!
16.09.28 Join    shx [0] (~a4810127@labb.contactor.se)
16.09.29 #       <markun> I turned grayscale on and then made all the changes to get everything to display as before.
16.10.06 #       <markun> Now I need to make a iriver-gray.c so we can watch jpg files etc.
16.10.57 #       <dwihno> really great!
16.11.04 #       <dwihno> looking forward to it
16.11.14 #       <markun> drawing 2 color bitmaps is very slow now at the moment..
16.11.29 #       <markun> But it can be optimized later.
16.22.11 #       <markun> If the lcd controller would use bitplanes everything would be a lot simpler.. now it uses 2 consecutive bits to define the color of a pixel..
16.23.39 #       <preglow> it might have a mode for that
16.23.47 #       <preglow> but probably not ;)
16.24.23 #       <markun> I couldn't find it anywhere.
16.30.16 Join    XShocK [0] (~XShocK@pcp09492659pcs.nrockv01.md.comcast.net)
16.37.19 Join    stripwax [0] (~stripwax@213-228-241-36.dsl.prodigynet.co.uk)
16.37.21 #       <stripwax> ello
16.38.17 #       <XShocK> hi
16.38.17 #       <stripwax> How's iRiver coming along?  Last time I was on #rockbox we were talking about trying to get DMA working from SRAM
16.39.00 #       <preglow> stripwax: hey, i've been meaning to ask you, how the hell did you manage the figure out the firmware encryption? ;)
16.39.49 Join    methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk)
16.40.14 #       <stripwax> preglow: some hard work, some educated guesswork, some late nights, a copy of ISE, and a smidgeon of luck ;-) 
16.40.41 #       <preglow> ise?
16.40.57 #       <stripwax> had no luck on cracking the Rio Chiba firmware yet though :-(      Image Searching Engine
16.41.03 #       <preglow> ahh
16.45.16 #       <preglow> nicely done anyway, i wouldn't even have known where to start
16.49.19 #       <stripwax> heh, thanks!
16.49.39 #       <stripwax> so what's up, how's audio looking (sounding?) on iriver port?
16.50.05 #       <XShocK> done audio output, working on input.
16.50.28 #       <XShocK> no SPDIF since does not have any equipment. :)
16.50.57 #       <stripwax> what was the problem with dma from a static buffer?  how was that fixed?  was it just  alignment
16.52.04 Join    stevenm [0] (~steve@stevenm-router.student.umd.edu)
16.52.14 #       <stevenm> Hello.
16.52.32 #       <XShocK> yes, it works perfectly without SRAM, one config made it sound glitching, but after change works fine.
16.52.54 #       <stevenm> How fast is the iRiver compared to a modern PC, and when writing codecs, what codec 'speed' should one aim for?
16.52.59 #       <stripwax> cool
16.53.22 #       <XShocK> i didn't experience any fixed buffer problems.
16.53.46 #       <XShocK> it worked both on fixed and dynamic
16.54.39 #       <XShocK> it might have been alignment issue tho
16.54.58 #       <stripwax> stevenm it's a 200MHz processor.   but you can't really compare the chip to a modern 'PC'.   but if you did, I guess you'd be aiming for about 20x speed on a PC translating into approx realtime on the iRiver.     that's just an arbitrary number though
16.55.11 #       <AC> re
16.55.23 #       <stripwax> XShocK - thanks.   so buffer can just be in SDRAM, no need to use SRAM for it?
16.55.35 #       <XShocK> yes
16.55.53 #       <preglow> stripwax: more like 140mhz
16.56.01 #       <stripwax> neat!   any  ideas why iRiver had their buffer in SRaM?
16.56.24 #       <AC> markun: can i see the source of the gray sacle stuff?
16.56.29 #       <stevenm> stripwax, I got my codec running just barely realtime on a Pentium M clocked down to 600Mhz, and then slowed down by 75% on top of that. This is Linux, with just a minimal environment running. Is that still too much processing used?
16.56.30 #       <stripwax> preglow - oh, ok !
16.56.47 #       <XShocK> no, have no idea, the SRAM buffer was only 256 bytes.
16.56.54 #       <markun> AC: you can look at it later. I'm rewriting it a bit right now.
16.57.03 #       <AC> ok
16.57.25 #       <stripwax> stevenm - depends really , does the codec use a lot of floating point math?  can it easily be vectorised (e.g. does it/could it use SSE or MMX instructions on the Pentium)
16.57.44 #       <stevenm> stripwax, no floating point math at all. a lot of integer math, though
16.57.49 #       <stripwax> stevenm but yeah, I think that sounds too much
16.58.17 #       <preglow> stripwax: and to top it of, it doesn't look like we can run it at 140mhz, it gets too hot 
16.58.35 #       <stevenm> woah.. how fast does it run ?
16.58.38 #       <stripwax> preglow wowzer, so what speed does iRiver run it at?
16.58.39 #       <stevenm> normally that is
16.58.51 #       <preglow> stripwax: what kind of math does it do?
16.59.03 #       <preglow> stripwax: rumours say about ninetyish
16.59.14 #       <preglow> stripwax: what kind of math does it do?
16.59.16 #       <preglow> argh!
16.59.25 #       <stripwax> someone reboot preglow please ;-)
16.59.27 #       <preglow> two nicks starting with st is havoc for me
16.59.32 #       <stevenm> Haha
16.59.35 #       <stripwax> hehehe
16.59.42 #       <preglow> i depend on tab completion!
16.59.47 #       <stevenm> preglow, this thing does a lot of multiplication and division
16.59.56 #       <preglow> stevenm: division is a no no
17.00.05 #       <stevenm> preglow, hmm ? 
17.00.06 #       <preglow> stevenm: multiplication and addition we can do fast
17.00.29 #       <stripwax> preglow - well, depends.  simple division is fast (combining shifts and multiplies)
17.00.56 Nick    kergoth`zzz is now known as kergoth (~kergoth@li11-226.members.linode.com)
17.01.04 #       <stevenm> preglow, for the volume stuff, I could probably get away with shifting. But interpolating the notes... that takes some division
17.01.21 #       <preglow> stevenm: what kind of codec is this?
17.01.30 #       <stripwax> Seem to remember GCC was pretty smart when compiling for 680x0 code to convert divisions into shifts or shifts+multiplies, anyway.  dunno if that applies to coldfire too
17.01.32 #       <stevenm> preglow, GUS MIDI
17.01.54 #       <stripwax> Woah, that should be pretty low CPU, no?
17.01.58 #       <AC> dwihno: Opengl es was designed for embedded systems like handys
17.01.58 #       <preglow> interpolation is easy
17.01.59 ***     No seen item changed, no save performed.
17.02.00 #       <stripwax> What kind of interpolation are you doing?
17.02.04 #       <preglow> does not require div
17.02.10 #       <stevenm> preglow, well, not really interpolation.. Here
17.02.12 #       <stripwax> (I mean, what are you interpolating)
17.02.42 #       <stevenm> preglow, to calculate which sample should be played at a current tick, the current position has to be multiplied by the sampling rate and then divided by the PC's sampling rate, etc
17.02.55 #       <stripwax> ????
17.03.03 #       <stripwax> Isn't that just an add?
17.03.09 #       <preglow> stevenm: yes, but that doesn't happen per sample
17.03.23 #       <stevenm> it's like, 4 operations right there. I'm thinking, would it be quicker to precompute this and store it in a table of floating point values?
17.03.39 #       <preglow> you just calculate a delta and then add that for every sample
17.03.56 #       <preglow> stevenm: you must be doing something wildly inefficient
17.04.00 #       <stevenm> preglow, hmm.. that is a good idea
17.04.14 #       <stevenm> preglow, only problem I am running into, it's going from very small to very big numbers
17.04.19 #       <stripwax> stevenm as I said, it's just an add.   samplerate doesn't change
17.04.33 #       <preglow> unless you've got portamento going on, it should do nicely with just an add
17.05.06 #       <stevenm> hmm.. I could try that
17.05.08 #       <stripwax> what's the problem with small numbers and big numbers?
17.05.15 #       <preglow> there is no problem with that
17.05.21 #       <preglow> we've got more than enough precision
17.05.35 #       <stevenm> well, you lose a lot of percision, even when declaring everything as long long
17.05.38 #       <preglow> stevenm: but yes, worry not, we'll get this working realtime, no problem
17.05.45 #       <stripwax> yeah, that's what I would have thought..     stevenm, how are you handling interpolation of samples, or are you not doing that?
17.05.50 #       <stevenm> because say, it is 48000 / 46100
17.05.56 #       <preglow> but i haven't got time to look at it right now
17.06.28 #       <stevenm> preglow, can some of the simpler functions be written in ASM ?
17.06.37 #       <preglow> stevenm: yes
17.06.49 #       <stripwax> it could all be in ASM ;-)
17.07.08 #       <stevenm> preglow, like, the function that adds up all the voices and sends it to the DSP. That could be done in ASM
17.07.09 #       <preglow> but i've done stuff exactly like this with plain 32 bit ints
17.07.13 #       <preglow> stevenm: indeed
17.07.30 #       <preglow> if you need extra precision for calculating the delta, then that's what the mac instruction is for
17.08.18 #       <stevenm> guys.. now, what about the sound buffer. On a PC, the thing literally stops execution until there's room in the sound buffer. Is iriver the same way? I'm only using about 10MB of the buffer, tops
17.08.35 #       <preglow> we don't know yet :P
17.08.38 #       <stevenm> So I have 20 megs sitting pretty much unused
17.08.44 #       <preglow> the sound buffer is going to be faaar smaller 
17.09.26 #       <XShocK> i think sound buffer should around 300 kb.
17.09.38 #       <stevenm> I figure, instead of stopping it to wait for the sound buffer to fill up, I could have it generating more samples and shoving them into the unused RAM. then write that to the sound buffer later
17.09.50 #       <stevenm> I mean, the cpu usage with midi varies a lot.
17.10.06 #       <preglow> yep
17.10.29 #       <preglow> but we'll figure that out
17.11.08 #       <stevenm> preglow, other than that.. I have the MIDI codec mostly finished. Just need to add some more looping stuff, envelope, as well as code to load/play the drum set
17.11.25 #       <stevenm> other than that, it plays very nicely
17.11.44 #       <stripwax> what are you using for a set of patches?  how much RAM do the samples take up?
17.13.14 #       <stevenm> stripwax, using Gravis Ultrasound patches, agerage about 44100 sampling rate. It only loads the ones that it needs. I think 5-10 megs, plus the drum set
17.14.02 #       <stripwax> how does it know which samples to load?   does it scan the entire midi file and then load the samples it needs, or does it load the samples while it's playing?
17.14.15 #       <stevenm> stripwax, on a typical file, I'd say 6 megs
17.14.34 #       <stevenm> stripwax, it scans the file first, then loads what it needs
17.14.38 Join    Zavatta [0] (~siavush@yggdrasil.spin.it)
17.14.58 #       <stripwax> stevenm- neat!  so would the math be easier if all of the samples were at the same samplerate?
17.15.21 #       <preglow> it would be the same
17.15.21 #       <stevenm> stripwax, probably. if we could convert them all to 48000...
17.15.29 #       <preglow> no, don't bother about that
17.15.29 #       <stevenm> it would save maybe one operation
17.15.31 #       <preglow> it doesn't matter
17.15.40 #       <preglow> it would save one operation _per note_
17.15.52 #       <preglow> savings per sample is more important
17.16.06 #       <stevenm> preglow, right now it _is_ per sample.. but I have to implement that delta thing
17.16.25 #       <preglow> stevenm: yes, but it's not supposed to be like that, the delta method is what you must use if you want it realtime
17.17.03 #       <stripwax> thinking about something like cubic interpolation - wouldn't that be easier (per sample) if the samples were at the same rate?   or would that be infeasible anyway on hte iRiver?
17.17.08 #       <stevenm> preglow, all right.. So can iriver technically do floating point then ?
17.17.30 #       <preglow> stevenm: no, but floating point or fixed point, it's all the same math, you just need to code it slightly differently
17.18.01 #       <preglow> stripwax: linear at least should be easy
17.18.05 #       <stevenm> The result is an int, but you go thru a double operation to get it. If I have one double operation per note, and only miltiplication per sample, is this acceptable?
17.18.06 Quit    bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )")
17.18.09 #       <preglow> some kind of interpolation has to be done
17.18.29 Nick    Lynx_ is now known as Lynx_awy (HydraIRC@134.95.189.59)
17.18.31 #       <preglow> stevenm: even that is too much, addition per sample should be more than enough
17.18.39 #       <preglow> stevenm: and perhaps a mul to control volume
17.18.52 #       <preglow> stevenm: and some more for interpolation
17.19.38 #       <stevenm> preglow, I see what you are saying, for the delta.. but how do you handle volume, then? Note volume, that is.
17.19.54 #       <stevenm> preglow, it has both channel and note volume. How to go about this?
17.20.12 #       <stevenm> preglow, multiplication, or somehow do an approximation using shifting ?
17.20.30 #       <preglow> stevenm: multiply is perfectly feasible on coldfire
17.20.45 #       <stevenm> preglow, oh, all right. that's good
17.20.55 #       <preglow> stevenm: codecs do little but multiply and add
17.21.21 #       <stevenm> preglow, I could always have it going at 22Khz instead of 48
17.21.40 #       <preglow> stevenm: go for 44.1khz first
17.21.41 #       <stripwax> having it at 48 would be a big win imho
17.21.50 #       <stripwax> or 44.1
17.23.21 #       <stevenm> Do any compiler optimizations help? Like, -O3 or whatever ?
17.23.33 #       <stripwax> Yes (see my earlier post)
17.23.51 #       <stripwax> GCC is pretty good at motorola optimizations (iirc).
17.24.13 #       <preglow> 12 lines of c became 44 lines of asm
17.24.22 #       <preglow> 200 lines of c to go...
17.24.33 #       <preglow> stripwax: -O2 should help heaps
17.24.35 #       <stripwax> preglow - what are you rewriting atm?
17.24.51 #       <preglow> stripwax: imdct_l in libmad
17.25.26 #       <stripwax> cool.   lots and lots of opportunities for MAC code there I hope?
17.25.31 #       <preglow> yes
17.25.35 #       <preglow> very much so
17.25.48 #       <preglow> mdct36 is one bloody long MAC invocation
17.26.06 #       <stripwax> heh
17.26.21 #       <stevenm> preglow, what is the MAC instruction ?
17.26.38 #       <stripwax> stevenm - like SSE or MMX on a PC..
17.27.19 #       <preglow> not really
17.27.40 #       <preglow> stevenm: it multiplies two numbers, and then adds the result to another register
17.27.46 #       <preglow> stevenm: and does it fast
17.28.14 #       <stevenm> preglow, Is ee
17.28.15 #       <preglow> and to top it of, it can do a parallel load, so i have to write asm by hand to utilize it properly
17.28.38 #       <preglow> http://glow.m0f0.net/rockbox/layer3.c
17.28.40 #       <preglow> line 1770
17.28.43 #       <preglow> from there on begins the fun
17.29.09 #       <markun> grayscale is coming along nicely. I added 'lcd_set_bgcolor' and 'lcd_set_fgcolor' which set the colors to use when drawing things.
17.29.35 #       <preglow> grep for III_imdct_s, and you'll see what stuff looks like after assembler optimization, not exactly a pretty piece
17.31.59 #       <stripwax> what I meant was the MAC unit supports more than just one instruction, e.g. MSAC, all of the EMAC stuff
17.32.20 #       <preglow> ahh, yes, but there's not many
17.32.36 #       <preglow> you have mac, msac, and movclr, plus some status/mask registers
17.32.50 #       <preglow> shop, brb
17.34.24 #       <stripwax> mm, true
17.35.04 #       <stevenm> preglow, running into a problem... the delta value per sample ranges from 0.222 to 1.9ish....
17.35.57 #       <stripwax> stevenm - what's the actual problem?
17.36.36 #       <stevenm> stripwax, I did the math to find the delta value, to add, per sample
17.36.48 #       <stevenm> and it's in the floating point range
17.37.23 #       <stevenm> I thought it would be a whole number of samples, but no... it's like, 0.2 in some places, 0.4, 1.03, etc
17.37.57 #       <stripwax> well, yes, it would be, right?    if it was a whole number of samples, then all you could ever do is play octave notes, and not the notes in between ...
17.38.00 #       <stevenm> and if you round it off, then it does not work. Sounds completely horrific, can't even tell what note it is
17.38.17 #       <stevenm> well, sort of
17.38.19 #       <stripwax> don't round it.  
17.38.29 #       <stevenm> but then it's double math, and we can't have that ... ?
17.38.45 Quit    AC ("CGI:IRC")
17.39.06 #       <stevenm> If I can leave it in double form, I can then have one floating point addition per sample, and one per note
17.39.08 #       <stripwax> store the sample position to a greater precision.  e.g. store the sample position multipled by 65536.
17.39.50 #       <stevenm> but then you need to divide it to get the actual sample, no?
17.39.54 #       <stripwax> so adding "1.03" to the sample position, you really add "1.03*65536".   Which you can round to 67502 and be reasonably confident it will sound just as good
17.40.00 #       <stripwax> Don't need to divide.  just need to shift.
17.42.11 #       <stevenm> hmm.. that's a good idea. thank you
17.42.15 #       <stripwax> Sure
17.42.24 #       <stevenm> Yea, I just got out of bed. "snow", campus is closed
17.42.31 #       <stevenm> not fully thinking straight
17.42.47 #       <stripwax> stevenm - heh.    i'm hideously hung over right now
17.43.03 #       <stevenm> haha. party night?
17.43.15 #       <stripwax> btw if any of your samples aer longer than 64K then you'll need to reduce the precision if you want to get everything to fit into a 32bit int
17.43.45 #       <stripwax> nah, music festival, all weekend long.   don't think i spent more than an hour without a drink in my hand
17.43.53 #       <XShocK> stevenm: snowing here too. everything is closed. :)
17.43.59 #       <stevenm> XShocK, where is here /
17.44.00 #       <stevenm> ?
17.44.15 #       <XShocK> Germantown, Maryland, US
17.45.06 #       <stevenm> XShocK, that's pretty close to us. I'm in College Park, MD
17.45.24 #       <XShocK> I thought so. :)
17.45.30 #       <stevenm> heh
17.45.31 #       <stripwax> Explains why I'm not seeing any of this snow from my window in London ;-)
17.45.41 #       <stevenm> :)
17.47.13 #       <XShocK> stevenm: your ip .student.umd.edu. :)
17.48.11 #       <XShocK> here schools were closed since last thursday, same in CP?
17.48.36 #       <stevenm> yea
17.48.49 #       <stevenm> possibly tomorrow, too. but there's hardly any snow at all
17.48.55 #       <preglow> stevenm: that there's the fixed point part
17.49.02 #       <preglow> stevenm: you don't need floats to be able to encode 1.35435
17.49.16 #       <stevenm> professors are just too lazy to come probably. gets me outta physics exam
17.49.26 #       <XShocK> :))
17.49.32 #       <stevenm> preglow, yea about to try that
17.49.58 #       <stevenm> preglow, I accidentally just rm'd some code I needed, getting it offa my ftp first
18.02.14 Join    mecraw [0] (~mecraw@69.2.235.2)
18.02.36 #       <stevenm> okay.. getting there.. the multiplying by a large number seems to work
18.03.04 #       <preglow> how large can the samples be max?
18.03.42 #       <stevenm> preglow, what do you mean?
18.04.41 #       <stripwax> e.g. is the biggest sound file 64KB, or is it smaller?
18.04.55 #       <stevenm> Hmm.. I think the largest patch here is 2.3 MEGS
18.05.14 #       <stevenm> But I am about to go and check how many waveforms it contains
18.05.30 #       <stripwax> stevenm i really meant one individual waveform
18.05.40 Quit    UlfJack ("Verlassend")
18.05.52 #       <stevenm> Yea. I see.. the only program that will load a GUS patch and tell me EVERYTHING about it happens to run on windows
18.06.04 #       <stevenm> just have to wait for my desktop to boot up
18.06.18 #       <preglow> stevenm: i meant a single waveform
18.06.27 #       <stripwax> er... i thought you were writing a midi codec?!  don't you already have that information in your code somewhere?
18.06.41 #       <stripwax> otherwise how do you know which waveform to play?
18.06.45 #       <stevenm> stripwax, I do, I do, don't worry
18.07.16 #       <stevenm> I just thought this way would be faster than digging through it and seeing how big
18.07.44 #       <stripwax> ah ;-)
18.08.32 #       <stevenm> but all right.. I put some printfs into the loader. lets see here
18.08.48 #       <stevenm> It looks like 248kb
18.09.21 #       <stevenm> but that is just the largest patch, 2.3mb. there could, theoretically, be 1 meg patch with only one waveform in it...
18.09.28 #       <stripwax> ok so you can use 14bits 
18.09.31 Quit    Zavatta ("Leaving")
18.09.56 #       <stripwax> stevenm - er, ok, so what is the largest waveform?  :-S
18.10.18 #       <stevenm> I have no way of easily knowing
18.10.35 #       <stripwax> hhmmmm...
18.11.18 #       <stevenm> stripwax, do you think it would work if I multiplied everything by 1024 ?
18.11.55 #       <preglow> stevenm: that factor depends on how large your waveform can be, that's why i ask
18.13.15 #       <stevenm> preglow, I guess that wouldn't be too hard.. take the largest few patches, look at the largest waveform in each, etc
18.13.48 #       <stripwax> we seem to be asking the same questions over and over here...  i already asked about the 64kb waveform size a while ago.   stevenm - that sounds like a plan.  look at all the patches > 248KB
18.14.26 #       <stevenm> stripwax, on it. I figure, 248kb - 18 bits. an 11 bit shift on top of that should fit nicely
18.15.06 #       <stripwax> stevenm hmmm...  248Kb is 18 bits, so the shift should be 14 bits, no?  (like I already said)
18.16.22 #       <stripwax> You should go for as much resolution as possible, I can't think of any performance penalty for using 14 bits vs 11 bits
18.16.39 #       <stevenm> stripwax, yes.. I was just saying 11 because I have 11 bits coded in right now. But yes, the maximum would be the best
18.17.03 #       <stevenm> That's 28 patches I have to check. this won't take too too long
18.17.30 #       <stripwax> stevenm ok cool.   hey, snowing in London :-D
18.20.18 Join    nobby [0] (nobby@ACD505B4.ipt.aol.com)
18.20.32 #       <stevenm> stripwax, coo, snow! Yeah.. Harpsicord just has to be 550KB
18.20.58 Join    Stryke` [0] (~Chairman8@resnet-241-86.resnet.umbc.edu)
18.21.37 #       <stevenm> That means, 20 bits for addressing samples, and 12 bits on top of that for multiplying
18.21.43 #       <preglow> it's been snowing here for days
18.21.51 #       <stevenm> preglow, where is here ?
18.21.55 #       <preglow> norway :P
18.22.01 #       <stevenm> preglow, cool
18.22.19 #       <nobby> more like snoreway :P
18.22.27 #       <stevenm> preglow, so this thing will do 32-bit ints ?
18.22.30 #       <nobby> kenya kenya kenyaaaaaaaaaaaaaaa
18.22.33 #       <stripwax> 12 bits sounds good.
18.22.55 Part    nobby
18.22.57 Join    nobby [0] (nobby@ACD505B4.ipt.aol.com)
18.24.49 #       <stripwax> stevenm - unsigned int should be 32 bits for the coldfire target, I'm pretty sure
18.25.33 #       <stripwax> but I thought there was a portable datatype that you should use ( called I think int_32 ? )
18.25.37 #       <stevenm> stripwax, I'm missing a bit somewhere.. it's annoying. 12 bit shift cuts off half the notes. 11 bit shift works. must be a signed value *somewhere*
18.27.03 #       <stripwax> yeah, sounds like it.
18.27.06 Join    Ancient_F [0] (no@ppp10-adsl-151.ath.forthnet.gr)
18.27.34 Nick    Ancient_F is now known as XavierGr (no@ppp10-adsl-151.ath.forthnet.gr)
18.27.41 #       <stripwax> or just use 11 bits until you track it down
18.27.45 #       <stevenm> hey guys.. Do you think it is reasonable to use up 81KB for precomputed delta tables? And that is a generous estimate too
18.27.51 #       <preglow> delta should be notefrequency/(sample_duration*sampling_rate)
18.28.03 #       <preglow> stevenm: why would you need that?
18.28.21 #       <stevenm> preglow, speed. That way I don't have to do any math per note
18.28.33 #       <preglow> stevenm: ram is really slow in the h1x0
18.28.39 #       <stripwax> you should only need tables for at most 13 notes.  The other octaves are just shifts.
18.28.43 #       <preglow> per note math is not a problem
18.29.10 #       <stevenm> stripwax, yes, but the waveforms per patch aren't spread out evenly, and have varying sampling rates
18.29.35 #       <stevenm> preglow, all right. That makes 2 divisions, one multiply, and one shift per note
18.29.58 #       <stevenm> and an add per sample, plus a few shifts
18.30.10 #       <stevenm> plus the volume junk
18.30.20 #       <preglow> yep
18.30.28 #       <preglow> but note on doesn't happen _THAT_ often
18.30.52 Quit    asdsd (Read error: 60 (Operation timed out))
18.31.25 Quit    linuxstb (Read error: 113 (No route to host))
18.31.28 #       <stevenm> preglow, okay. and turns out, the per sample division for volume is just a 14 bit shift too
18.31.30 #       <stripwax> for effects like tremolo (if you're implementing that?) you can save cpu per sample by only recomputing volume levels every few samples or so, rather than every sample
18.31.45 #       <XavierGr> Hello all! Can I ask a small question?
18.31.52 #       <preglow> stevenm: i do not believe you can make the volume a simple shift
18.31.54 #       <stripwax> XavierGr - of course!
18.31.55 #       <XavierGr> I have rockbox running in my iHP. I see that there is a .rockbox folder. I have seen that there are everyday builds. Can I just replace the .rockbox folder with a new build or I will have to flash again?
18.32.00 #       <preglow> stevenm: but that's not problem, muls are pretty quick
18.32.13 #       <preglow> XavierGr: just replace
18.32.19 #       <preglow> XavierGr: you need to replace rockbox.iriver as well
18.32.20 #       <XavierGr> thanks
18.32.26 #       <preglow> XavierGr: don't mention it
18.32.31 #       <XavierGr> oh yeah ok! :)
18.32.41 #       <nobby> when will daily builds start containing rockboy?
18.32.54 #       <preglow> nobby: when it's usable, i'd guess
18.32.58 #       <nobby> k
18.33.03 #       <nobby> ages away then...
18.33.08 #       <preglow> no, not really
18.33.18 #       <preglow> it is usable as it is, just need to find out where to optimize it
18.33.23 #       <stripwax> anyone want to buy my P&E wiggler?  I bought it but I'm thinking I really don't need it now..    unused.. :-(
18.33.30 #       <stevenm> okay people.. I'm going to go ear breakfast. Then come back, and hopefully continue on this
18.33.38 #       <stevenm> er eat. that didnt sound right
18.33.40 #       <nobby> and stop it crashing on every rom ive tried (all freeware demos so far)
18.33.41 #       <stripwax> hehe
18.33.48 #       <preglow> stevenm: i'm tempted, but no dice
18.33.56 #       <preglow> arghh!!!
18.33.57 #       <stripwax> stevenm - is there example code I could play with?
18.33.58 #       <preglow> stripwax: see above
18.34.21 #       <stripwax> preglow - hehe .   ok, thx anyway.    i can probably return it to the supplier
18.34.24 #       <stevenm> stripwax, you want the code to this thing ?
18.34.33 #       <XavierGr> Hello nobby, I was inspired by your move towards HCl to give you a modded firmware.(read it in logs) Now I can run Rockbox too. :)
18.34.39 #       <stripwax> yeah, why not
18.35.06 #       <stevenm> stripwax, hmm... let me clean up some of this delta junk, then I'll upload the patch set and ?the code. Are you on Linux
18.35.41 #       <stripwax> stevenm - sure, thanks!   linux is not a problem, i'm just going to look over the code, probably not run/compile it
18.36.20 #       <nobby> xavier: isnt it useful(!) :P sound quality is awesome ;)
18.36.58 #       <XavierGr> Well I can play snake2 and create,rename or delete folders on the fly!
18.37.09 #       <stevenm> stripwax, here, let me get it to a buildable state
18.37.19 #       <nobby> true
18.37.30 #       <nobby> and the playlist converter will be useful
18.37.34 #       <stevenm> stripwax, it's really ugly, esp. the gus loader. need to fix junk like skipping the reserved areas instead of loading them, etc
18.37.57 #       <XavierGr> nobby:Not to mention that it connects faster in USB mode
18.38.00 #       <stripwax> stevenm - sure ok, no rush
18.38.29 #       <preglow> oh my god, i certainly hope i manage to introduce a bug in thise code
18.38.33 #       <preglow> i'll never be able to find it
18.39.27 #       <nobby> xavier:agreed, its better, but i like music too :P
18.40.22 #       <XavierGr> Well I use the remote so if I press play on the remote original firmware comes in! :P
18.41.21 #       <stevenm> stripwax, all right. it builds and runs, and it uses the delta stuff. not everything has been adapted for delta, like looping. but it will build and play right
18.43.17 #       <stevenm> stripwax, http://wam.umd.edu/~stevenm/irivermidi_new.tbz2
18.44.21 #       <stevenm> stripwax, the functions in question are synth.c / synthVoice() and sequencer.c / pressNote()
18.44.22 #       <stripwax> stevenm - fab, tx
18.44.36 #       <stevenm> and with that, breakfast at 12:45 pm. back later
18.46.05 #       <nobby> my remote died...
18.48.09 #       <XavierGr> opps sorry
18.50.45 #       <stripwax> stevenm - not sure what's going on at the end of synthSample.   Is that supposed to be a lowpass filter?
18.51.33 #       <stevenm> stripwax, I suppose so. it eliminates the high pitched hissing sampling noise, especially with string instruments
18.51.49 #       <stevenm> stripwax, I suppose that can be done with a circular array, and a shift instead of division
18.52.24 #       <stripwax> Yeah probably - but better would be to use interpolation during sample generation, rather than post processing with a filter to remove the hiss that shouldn't be  there in the first place ;-)
18.54.08 #       <stripwax> Hmm, rockbox might not have an fscanf function..   (anyone confirm/deny?)
18.54.10 #       <stevenm> stripwax, yea I guess you are right. But.. I don't know how to do interpolation.. and my main concern was getting the basics working, then slowly working up. It won't even loop properly yet
18.54.14 #       <XavierGr> bye all
18.54.14 Quit    XavierGr ()
18.54.41 #       <stevenm> stripwax, the fscanf is just a hacked together config loader. that's like, the last thing I'll do, make a normal config parser
18.55.33 #       <stevenm> stripwax, but... I just clocked this thing to 600Mhz, then throttled it 87%, so effectively a 78Mhz Pentium M I suppose.. and it ran realtime as long as you didn't move the mouse
18.56.04 #       <stevenm> and this is all with the rest of my programs running alongside it
18.56.30 #       <stevenm> now, breakfast for real
18.58.05 #       <stripwax> heh :-)   cool.  well I'm thinking that getSample is a bit inefficient since you're building the address each time, rather than just doing that once and then just incrementing/decrementing it.   i'll take a look and see if I can't rearrange that a bit
19.02.03 ***     Saving seen data "./dancer.seen"
19.05.03 Quit    Schnueff (Read error: 60 (Operation timed out))
19.06.50 #       <stripwax> stevenm - by the way, by 'interpolation' i mean, instead of just getting ONE sample out of the waveform for each sampleoffset, we actually get two, and average the two values in some way.   That will remove the 'high pitched sampling noise' at the source, since it's caused by the non-smooth movement of the sample offset e.g. if delta is 1.01 then 99% of the time the sample offset moves by 1 sample, and 1% of the time it moves by 2 s
19.09.23 #       <stripwax> can i download the patches from anywhere?   builds fine under cygwin on windows
19.18.24 #       <HCl> helloooooo
19.18.28 #       <HCl> how goes o.o
19.20.05 #       <amiconn> Yeehah! lseek() working in the cygwin x11 simulator. :)
19.20.10 #       <HCl> yay!
19.20.12 #       <HCl> grats :)
19.20.14 #       <HCl> what was it?
19.20.38 #       <amiconn> Linus found the cause - cygwin uses a 64 bit off_t datatype..
19.20.54 #       <amiconn> ...while rockbox defines it 32 bit
19.21.59 #       <preglow> how are 64 bit values passed? by reference?
19.22.12 #       <preglow> well, of course not
19.22.23 #       <amiconn> On the stack, methinks
19.22.39 #       <preglow> yes, but not strange it broke things
19.22.53 #       <preglow> it got 32 bits when it expected 64
19.23.05 #       <amiconn> The fix is simple when you know the problem.
19.23.08 #       <preglow> looked like you tried to seek out of bounds all ther time
19.23.18 #       <preglow> sometimes ;)
19.23.45 #       <amiconn> I added a tiny sim_lseek() with 32 bit parameters & return value, which simply calls the system's lseek()
19.24.57 #       <HCl>  :)
19.25.14 #       <stevenm> stripwax, I am back
19.25.44 #       <stripwax> hiya!   which gus patch files are you using, could you send me them/link them pls?
19.25.44 #       <stevenm> stripwax, yes, getsample needs to be cleaned up.. Here, let me put the samples up
19.25.59 #       <stevenm> er patches
19.26.04 #       <stripwax> I'm currently downloading a 1MB patch set but it might not be the same as yours.
19.26.07 #       <HCl> amiconn: any luck with rockboy?
19.26.09 #       <stripwax> Yes please
19.26.46 #       <stevenm> stripwax, you'll need to make your own config file for that. it doesn't parse the configs properly yet
19.27.09 #       <amiconn> HCl: Didn't try yet. Next thing is to complete & commit the malloc() fix.
19.27.29 #       <stevenm> stripwax, are you on broadband ?
19.27.30 #       <HCl> ok
19.27.31 #       <markun> I have mandelbrot on iriver!!
19.27.32 #       <stripwax> yep
19.27.43 #       <markun> Sorry, am just very happy :)
19.27.48 #       <stripwax> mandlebrot, hehe.   is it zoomable?
19.27.52 #       <markun> yes
19.27.53 #       <HCl> amiconn: i got a new version of rockboy by now, it has a nice ifdef DYNAREC everywhere
19.27.55 #       <stevenm> stripwax, oh okay then. I'm gonna host it on my dorm machine
19.27.56 #       <stripwax> and is it greyscale?
19.27.59 #       <markun> I will send a picture
19.28.00 #       <HCl> markun: nice
19.28.03 #       <stripwax> stevenm - cool, thanks
19.28.05 #       <markun> Yes, grayscale.
19.28.11 #       * HCl wants grayscale for rockboy
19.28.14 #       <stripwax> markun schweet
19.28.37 #       <amiconn> markun: 4 scales isn't that much - porting the grayscale lib to simulate even more would be great.
19.28.48 #       <HCl> yes, but. i'd like both o.o;
19.28.51 #       <stripwax> Does the greyscale lib do native 2-bit on iRiver or does it always use 1-bit time dithering?
19.28.55 #       <HCl> since rockboy won't have cpu to do grayscale lib
19.29.14 #       <amiconn> stripwax: The grayscale lib is not yet ported to iriver.
19.30.04 #       <stripwax> amiconn ok, wasn't sure
19.30.06 #       <amiconn> If it still isn't by the time I will have an iriver, I'd try to use 2-bit in addition to temporal dithering
19.30.25 #       <stripwax> yep - makes sense
19.30.45 #       <amiconn> Should allow for some 49 graycsales with a similar approach as on the archos
19.30.55 #       <markun> I ported the grayscale api, but without temporal dithering.
19.31.03 Join    stevenm_1 [0] (~steve@181-109.mam.umd.edu)
19.31.35 #       <stripwax> stevenm_1 - let me know where the patches are when they're up
19.31.49 #       <amiconn> Maybe the 2-bit mode of the lcd uses temporal dithering internally. In this case it may interfere with further temporal dithering
19.32.15 #       <stevenm_1> stripwax, yes.. I have to make an account on my desktop for ftp access.. one moment
19.32.15 #       <preglow> don't think it does
19.32.16 #       <stripwax> amiconn - maybe
19.32.30 #       <stevenm_1> stripwax, you said it was Cygwin? Does that actually support sound? /dev/dsp that is
19.32.49 #       <stripwax> stevenm_1 dunno, i'll find out I guess.
19.33.00 #       <stevenm_1> stripwax, all right..
19.33.15 #       <markun> http://130.89.160.166/rockbox/iriver-mandelbrot.jpg
19.33.24 #       <stripwax> Apparently it should just work, but there's some things that Cygwin's /dev/dsp doesn't support
19.33.56 #       <stripwax> markun - nice!   so that's native greyscale but no temporal dither?  lovely
19.34.00 Join    Sucka [0] (~NNSCRIPT@host81-129-2-158.range81-129.btcentralplus.com)
19.35.18 #       <amiconn> markun: Your 2-bit mode implementation uses a similar api as the grayscale lib?
19.35.47 #       <markun> It's quite slow, but then I don't know how fast it is on player.
19.36.01 #       <markun> amiconn: It uses the same api. gray.h.
19.36.12 #       <markun> But not everything is implemented.
19.36.18 #       <markun> No scrolling.
19.36.23 #       <amiconn> Nice :)
19.36.54 #       <amiconn> I think this same api would be useful for b&w too (of course some functions are unnecessary then)
19.36.55 #       <stevenm_1> stripwax, http://wam.umd.edu/~stevenm/patchset.tbz2   30 megs :) 
19.37.10 #       <amiconn> I suspect the code will get smaller if we do this...
19.37.13 #       <XShocK> markun: really nice
19.37.26 #       <markun> I added lcd_set_bgcolor and lcd_set_fgcolor to lcd.[ch] for the iriver, they can be used to give everything in rockbox a nice color.
19.37.29 #       <stripwax> stevenm- woah, so in theory running the midi plugin on iRiver could run out of memory???
19.37.39 #       <stevenm_1> stripwax, and it will want it as, ./irivermidi and ./patchset..
19.37.49 #       <markun> amiconn: That was also your idea, right?
19.37.55 #       <amiconn> yup
19.37.58 #       <stevenm_1> stripwax, in theory, if you used all 128 instruments in your MIDI file, then yes
19.38.05 #       <stripwax> hmm...
19.38.12 #       <amiconn> Additionally, lcd_set_drawmode should also be implemented
19.38.13 #       <stevenm_1> stripwax, well actually it'll be less than that
19.38.33 #       <stevenm_1> stripwax, that patchset contains more than you need. like 4 drum banks I think
19.38.42 #       <stripwax> oh ok!  :-)
19.38.44 #       <markun> Yes, it should.
19.38.57 #       <stripwax> stevenm_1  -  that link doesn't work for me
19.39.10 #       <stevenm_1> stripwax, hmm..
19.39.31 #       <amiconn> This would allow to remove all those duplicate functions that are there now, and be more flexible at the same time
19.40.01 #       <stevenm_1> stripwax, now try
19.40.48 #       <markun> amiconn: the duplicate functions in grey.h and lcd.h?
19.41.09 #       <amiconn> No, I mean the duplicate functions in lcd_recorder.c / lcd_h100.c (cvs)
19.41.22 #       <amiconn> Like lcd_drawline() / lcd_clearline() etc.
19.41.40 #       <stevenm_1> stripwax, yea, try that link again. I uploaded it to wrong dir
19.41.49 #       <stripwax> stevenm yup works now
19.42.12 #       <stripwax> downloading nicely
19.43.28 Join    rovragge [0] (rr@mima.x.se)
19.44.01 #       <amiconn> markun: There would be only one function for each graphics primitive, like it is now in the grayscale lib
19.44.12 #       <rovragge> a friend of is anxious to try out rockbox because 'it will probably not work after flashing and then I lose 300 euro"
19.44.31 Quit    stevenm (Read error: 110 (Connection timed out))
19.44.32 #       <rovragge> heh not anxious, I meant scared
19.45.15 #       <stripwax> rovragge - you gotta take risks to be on the cutting edge
19.45.27 #       <rovragge> well help me measure the risk
19.47.00 #       <stripwax> I don't know how many people have flashed rockbox and ended up breaking their player.  I know of no such cases but some of the older hands might know of some.
19.47.30 #       <stripwax> if it doesn't work, he can just reflash the original firmware
19.47.37 #       <rovragge> how does he do that?
19.47.59 #       <HCl> by sending it back to linus
19.48.07 #       <rovragge> for how much $$?
19.48.07 #       <HCl> and have him with his bdm wiggler reflash it
19.48.13 #       <HCl> shipping?
19.48.20 #       <HCl> where does linus live again... norway?
19.48.35 #       <amiconn> Sweden
19.48.38 #       <HCl> sweden
19.48.51 #       <HCl> so, the money for shipping an iriver to sweden, and back from sweden
19.48.53 #       <rovragge> well does linus just do such things on request?
19.49.10 #       <rovragge> thats nice
19.49.14 #       <HCl> well, thats a question for him, really, but i don't see why not personally, as long as it doesn't happen too often.
19.49.16 Nick    stevenm_1 is now known as stevenm (~steve@181-109.mam.umd.edu)
19.49.31 #       <stevenm> Ah there, finally
19.49.31 #       <HCl> i don't guarantee that he will, i'm just saying he could.
19.49.38 #       <mst> what cpu does this iriver thing run on?
19.49.43 #       <HCl> coldfire.
19.49.50 #       <mst> whoah
19.49.57 #       <mst> are there emulators?
19.50.08 #       <HCl> coldfire emulators? not any that are usable
19.50.26 #       <preglow> starting out good again: locked up player
19.50.34 #       <stevenm> stripwax, aaaaand we have working forward looping. for the most part
19.50.35 #       <HCl> what'd you do?
19.50.52 #       <stripwax> stevenm - woohoo!
19.51.05 #       <mst> shit I shouldve bought one of the rockbox supporting devices
19.51.10 #       <rovragge> but rockbox can't play mp3
19.51.45 #       <preglow> HCl: try my optimization..
19.51.53 #       <HCl> ah.
19.51.55 #       <HCl> ok
19.52.03 #       <HCl> for a moment you made it sound like you bricked your player, heh
19.52.06 #       <preglow> this is exactly what i hoped for, i hate debugging asm
19.52.16 #       <HCl> i lock up my player all the time with rockboy
19.52.25 #       <preglow> no brick, no
19.52.59 #       <mst> i got this strange fascination with microassemblers and gadget devices
19.53.17 #       <mst> gonna be fun
19.53.36 #       <HCl> well, you can help with dynarec if you want :P
19.53.46 #       <mst> what's that and does it require hardware?
19.53.59 #       <HCl> its going to be the new cpu core for rockboy
19.53.59 #       <preglow> it requires you getting intimate with the cpu
19.54.06 #       <HCl> hopefully, it'll make things faster
19.54.08 #       <mst> I dont -have- the CPU
19.55.04 #       <HCl> i'll just have to bitchslap gcc some more and make it produce usable assembly
19.57.41 Quit    nobby (Read error: 110 (Connection timed out))
19.58.23 #       <mst> no other compilers for coldfire?
19.58.30 #       <preglow> none that are free
19.58.31 #       <mst> the only coldfire I have is an old palm
19.59.57 #       <CoCoLUS> if a non free compiler is used, is that visible in the final assembly?
20.00.04 #       <HCl> no.
20.00.10 #       <CoCoLUS> well...
20.00.25 #       <CoCoLUS> did you buy your windows? :P
20.00.32 #       <HCl> no
20.00.36 #       <HCl> but i didn't need to.
20.00.46 #       <HCl> i get mine for free through msdn academic alliance
20.00.54 #       <CoCoLUS> nice
20.02.03 #       <mst> I don't believe in intellectual property, hence I don't have moral issues with using warezed software.
20.02.50 #       <HCl> i just believe that companys like microsoft are seriously acting like criminals when it comes to competitor companys. hence i'll do everything to work against them.
20.04.13 #       <mst> HCl, so what do you say, can I do anything with rockbox without a hardware to play?
20.04.30 #       <HCl> simulators get a long way
20.04.42 #       <HCl> but yea.
20.04.54 #       <stevenm> stripwax, did the thing run on cygwin ?
20.05.04 #       <HCl> you can check the todo list, some of them can just be designed on the sim
20.05.18 #       <mst> which platform does the sim run on?
20.05.24 #       <HCl> win32, x11
20.05.29 #       <mst> ah, great.
20.05.38 #       <mst> I'll check with it later on.
20.05.41 #       <HCl> :)
20.06.31 #       <preglow> seems referring to non-existing addresses hangs the player
20.06.33 #       <preglow> what gives
20.06.36 #       <preglow> :)
20.07.04 #       <preglow> this is really depressing, it looks like my changes don't do shit
20.07.08 #       <HCl>  :/
20.07.09 #       <mst> thatd be reasonable.. the bus is trying to address a non-existing piece of memory, and nothing happens, the memory doesnt respond
20.07.11 #       <jyp> preglow: I just discovered that on the Gmini too ;)
20.07.15 #       <preglow> HCl: it does, i just can't measure it myself
20.07.24 #       <preglow> HCl: need a higher speed coldfire
20.07.25 #       <HCl> i'm kind of assuming that dynarec will be slower in the end :p
20.07.25 #       <mst> coldfire does have an exception mechanism doesn't it?
20.07.32 #       <mst> preglow, you can overclock it
20.07.33 #       <HCl> ah.
20.07.44 #       <preglow> mst: i'll wait for linus' changes
20.07.45 #       <HCl> mst: we don't have linus' changer
20.07.47 #       <HCl> changes
20.07.58 #       <mst> it doesn't tell me anything
20.08.15 #       <HCl> linus is working on cpu speed scaling.
20.08.18 #       <mst> I can overclock my palm in softare
20.08.27 #       <HCl> he's the only one who's able to run at higher speeds at the moment.
20.08.28 #       <preglow> mst: you can't just overclock the cpu and be done with it
20.08.44 #       <preglow> mst: the peripherals need to tag along with the timing changes as well
20.08.50 #       <mst> is this a hardware issue of software timing issue?
20.08.55 #       <preglow> hardware
20.08.58 #       <jyp> software
20.09.00 #       <jyp> :P
20.09.03 #       <mst> then how's Linus related to it?
20.09.04 #       <preglow> hardware/software :P
20.09.22 #       <markun> jpeg.c does not decode the pictures right..
20.09.36 #       <preglow> mst: because he's the only one capable of measuring hardware timing issues at the moment
20.10.39 #       <stevenm> brb, gonna test midi plugin with nothing else running
20.10.44 Quit    stevenm ("Leaving")
20.10.47 #       <mst> never realised Linus had anything to do with hardware
20.11.06 #       <HCl> hah.
20.11.19 #       <HCl> he's the only person with a bdm wiggler - actually able to debug anything.
20.11.24 #       <preglow> mst: what makes you think that? he's the one who wrote the bootloader
20.11.26 #       <HCl> he wrote the bootloader
20.11.53 #       <preglow> mst: sure you're not confusing him with someone else?
20.12.02 #       <mst> preglow, pretty much ;)
20.12.10 #       <mst> then again theres always something new to learn
20.12.13 Join    zezayer [0] (~zezayer@host81-152-218-69.range81-152.btcentralplus.com)
20.12.26 #       <preglow> indeed
20.13.49 Join    frank [0] (~frank@p54A16165.dip.t-dialin.net)
20.15.06 Nick    kergoth is now known as kergoth`food (~kergoth@li11-226.members.linode.com)
20.19.47 #       <mst> hmm.. rockbox is written in C?!
20.19.58 #       <HCl> nah, we liked javascript bettre :P
20.20.03 #       <HCl> betterrrr*
20.20.13 Join    stevenm [0] (~steve@181-109.mam.umd.edu)
20.20.18 #       <mst> i sort of thought it'd be macroassembler
20.20.31 #       <HCl> code doesn't stay managable when written in assembly
20.20.39 #       <stevenm> back.. With -O2 it runs realtime on a Pentium-M at 78Mhz
20.20.42 #       <HCl> thats why programming languages have been invented in the first place
20.20.54 #       <stevenm> and that's as low as this thing goes
20.21.03 #       <preglow> mst: pure c with asm for very low level or performance critical stuff
20.21.05 #       <mst> HCl, that's why macroassembler and Best Code Practices (TM) were invented in first place ;)
20.21.11 #       <preglow> stevenm: i bet i can bring it lower
20.21.19 #       <mst> preglow, I'm a fascist. I consider everything critical. Heh.
20.21.38 #       <stevenm> preglow, I bet you could.. esp. with that 'lowpass filter' with for loop, etc
20.22.03 Quit    mecraw (Read error: 54 (Connection reset by peer))
20.22.04 #       <preglow> stevenm: i've done stuff like that tons of times, i'll see if i can get my opt to work, and then have a look at your thing
20.22.06 #       <mst> ok, I'll go RTFM now.
20.22.54 #       <stevenm> preglow, Another annoying thing about this. Before playback, the thing loads 7 megs of waveform from HD to RAM. With my PC clocked down, that takes an annoyingly long time
20.23.10 #       <mst> stevenm, mmap?
20.23.17 #       <preglow> just wait 'till you see how long it will take on the iriver
20.23.20 #       <stevenm> mst, what is that ?
20.23.54 Join    asdsd [0] (~asdsd@h-67-100-34-237.miatflad.dynamic.covad.net)
20.23.57 #       <mst> stevenm, memory mapping.
20.24.06 #       <stevenm> preglow, I am sure SOME of that time is used up printing output.. radeonfb doens't like me. 
20.24.14 #       <mst> though on an underclocked machine I'm not sure how efficient that'd be
20.24.37 #       <stevenm> preglow, It's very straightforward.. just take X bytes from file and load them [here]. Maybe it would be faster thru ASM?
20.24.37 Join    muesli- [0] (muesli_tv@c-180-220-160.cvx-h.dial.de.ignite.net)
20.24.46 #       <preglow> stevenm: no, i sincerely doubt that
20.24.59 #       <stevenm> preglow, well, how long would it take to load that much?
20.25.44 #       <stevenm> preglow, I mean, on archos, filling the MP3 buffer takes surprisingly a short time.. and that's two megs. Is there a reason it would take so much longer here?
20.26.18 #       <preglow> stevenm: no, not really, i was just guessing
20.26.22 #       <preglow> stevenm: it has to be done anyway
20.26.33 #       <preglow> brb, food
20.26.55 #       <stevenm> preglow, ok
20.31.00 #       <mst> Does anyone here have any experience with Sigmatel chips?
20.32.43 Quit    Nibbler ("blubber")
20.33.39 #       <stripwax> back again.   I still have my BDM wiggler for sale, noticed a convo above about that
20.35.03 #       <mst> what's a BDM wiggler? ;)
20.35.10 #       * mst googles
20.35.23 #       * Renko giggles
20.35.25 #       <mst> ah I see
20.36.32 #       <stripwax> a hardware interface that lets you access the built-in "background debug module" on the coldfire cpu.   i bought one intending to do the same kinda thing as Linus but then realised that there's not much I would be able to do usefully that Linus hasn't already got under control.
20.36.59 Join    Nibbler [0] (~sven@port-195-158-163-29.dynamic.qsc.de)
20.37.47 #       <Renko> did anyone do anything about a gdb stub for the serial port yet?
20.38.06 #       <HCl> nope.
20.38.10 #       <HCl> but its on the todolist
20.38.32 #       <Renko> yeh, there's one for the archos right?
20.38.36 #       <HCl> yup.
20.38.45 #       <HCl> though i'm not sure what interface the archos one uses
20.38.52 #       <amiconn> serial.
20.38.54 #       <HCl> kay.
20.40.09 #       <Renko> so should be poss to use that as a base for the iriver?
20.41.45 #       <HCl> it might, i'm not sure exactly
20.41.48 #       <HCl> i think it'll give a nice outline
20.41.52 #       <HCl> to what commands you need to implement
20.42.53 Quit    asdsd (Read error: 110 (Connection timed out))
20.42.55 Join    mecraw [0] (~mecraw@69.2.235.2)
20.43.13 #       <amiconn> stripwax: Well, most probably someone needs a wiggler for working on H3xx support
20.45.39 #       <stevenm> stripwax, is there going to be a H3XX port ??
20.48.02 Quit    zezayer ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040804]")
20.48.57 #       <jyp> While you're on this subject, I'll need a wiggler-like think for the Gmini ...
20.49.12 #       <stevenm> jyp, how fast is the gmini ?
20.49.13 #       <jyp> If anyone has info, I'm eager to hear
20.49.44 #       <jyp> stevenm: It can decode mp3 in realtime ;)
20.49.56 #       <jyp> What do you mean exactly ?
20.50.13 #       <stevenm> jyp, but can it.. potentially play MIDI in real time ? :)
20.50.46 #       <jyp> it looks like easier than mp3, doesn't it ?
20.50.58 #       <stevenm> jyp, I guess I'm saying, is it about as fast iRiver?
20.51.38 #       <jyp> I guess both archs have the same power.
20.51.46 #       <jyp> -- roughly
20.52.01 #       <stevenm> jyp, there's a not of annoying math involved
20.52.16 #       <jyp> There must be tricks.
20.52.16 #       <stevenm> jyp, okay then.. then I guess this thing ain't just going to be for iriver\
20.52.27 #       <stevenm> jyp, there are.. but it is still annoying math
20.52.49 #       <amiconn> I think midi would even be possible on the old archos, if we ever get hold of that wav 'codec' for the mas...
20.52.55 #       <jyp> Ok, I guess there are effects and such
20.53.38 #       <jyp> which make the thing hard
20.53.48 #       <stevenm> amiconn, I don't think so. there is no way it will run on a 12Mhz CPU
20.54.10 #       <stevenm> amiconn, well, maybe with a lot of help from Linus, maybe...
20.54.51 #       <stevenm> amiconn, I've got a P-M down to 78Mhz barely handling it.. but thats without hand optimization
20.54.59 #       <stevenm> and at the highest sample rate
20.56.48 #       <amiconn> Well, imho it all depends on the precision, sample rate etc. It may be possible on a 12 MHz cpu at a lower quality.
20.57.38 #       <stevenm> amiconn, maybe. but how do you get a hardware MP3 decoder to play raw samples?
20.57.56 #       <amiconn> [20:52:22] <amiconn>... if we ever get hold of that wav 'codec' for the mas...
20.58.19 #       <stevenm> amiconn, what do you mean by 'get hold of' ?  One exists?
20.58.31 #       <stevenm> amiconn, can that chip even do that?
20.58.33 #       <amiconn> Actually there are at least 2
20.59.00 #       <stevenm> amiconn, then what is stopping us from getting our hands on one of them?
20.59.04 #       <amiconn> One very simple, doing 44.1 kHz 16 bit stereo only, without buffering & demand transfer
20.59.52 #       <amiconn> This one also does parallel transfer only, so we can't use it
21.00.19 #       * HCl finally gets gcc to spit out some working assembly.
21.00.25 #       <HCl> i swear, gameboy flags are nasty.
21.00.38 #       <stevenm> HCl, gameboy?
21.00.40 #       <amiconn> Then there are rumours that another one exists, much more sophisticated and also capable of serial transfer
21.00.54 #       <HCl> i hope that i'll be able to optimize them out some far day in the future
21.01.01 #       <HCl> some day in the far future*
21.01.04 #       <HCl> stevenm: yes.
21.01.16 #       <HCl> stevenm: working on dynarec for rockboy
21.01.26 #       <stevenm> HCl, dynarec ?
21.02.06 ***     Saving seen data "./dancer.seen"
21.02.19 #       <HCl> dynamic recompilation
21.03.43 #       <stevenm> HCl, woah, cool
21.04.07 #       <stevenm> HCl, I know a little tiny bit about gameboy.. about as far as the C compiler takes you
21.05.12 #       <XShocK> someone unsoldered everything and scanned the iriver player. who has that unsoldered sheet?
21.10.36 #       <XShocK> i want to know for sure, which port is used for sound input since there are 3 possibilities.
21.15.21 #       <markun> jpegs are working on iriver
21.15.29 #       <HCl> nice.
21.15.47 #       <XShocK> good
21.15.53 #       <markun> I will post a picture later.
21.15.59 #       <markun> Don't have a camera now.
21.18.09 #       <amiconn> preglow: Could you please test my next shot at the malloc() problem, by compiling for iriver?
21.20.26 #       <stevenm> stripwax, I put an MP3 of the MIDI synth on the internet
21.20.36 #       <stevenm> its on the soundcodecs page
21.25.32 #       <preglow> amiconn: sure
21.25.45 Nick    StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a239.wi.tds.net)
21.26.37 #       <amiconn> preglow: http://amiconn.dyndns.org/malloc-2.diff  codec.h did also change: http://amiconn.dyndns.org/codec.h
21.27.00 #       <amiconn> All against current cvs, as usual. You'll need to undo malloc.diff first
21.27.06 Nick    kergoth`food is now known as kergoth (~kergoth@li11-226.members.linode.com)
21.28.07 #       <mst> Yeah!
21.28.18 #       <mst> I identified my player's CPU. It's ATJ2085
21.28.48 #       <Renko> stevenm, lol, that midi is great! well done!
21.29.39 #       <mst> now I am going to haquor that biotch :P
21.30.31 #       <stevenm> Renko, thanks
21.30.57 #       <stevenm> Renko, it uses the Timitidy patch set.. EAWPatches I think
21.31.03 #       <preglow> ahahah
21.31.05 #       <preglow> this sounds familiar!
21.31.18 #       <stevenm> preglow, hm?
21.31.24 #       <preglow> midi mp3
21.31.27 #       <stevenm> :)
21.31.48 #       <preglow> it took me about 1 second of the first note to be sure
21.31.54 #       <amiconn> The x11 sim really has a strange notion of realtime...
21.31.57 #       <stevenm> hahaha
21.32.34 #       <preglow> amiconn: you use diff -u ?
21.32.41 #       <amiconn> cvs diff -u
21.32.58 #       <preglow> i wonder why the bloody hell it fails on these trivial cases
21.33.15 #       <amiconn> Yeah.. I don't understandthis too
21.35.03 #       <mst> amiconn, 'for an arbitrary definition of real... your mileage may vary'
21.35.16 #       <preglow> amiconn: libflac/bitbuffer.c can't find global.h
21.35.27 #       <amiconn> Btw, could anyone check whether wv2wav also gives crc errors on the target when decoding the example .wv AC posted?
21.35.40 Quit    muesli- (Read error: 60 (Operation timed out))
21.35.41 #       <amiconn> preglow: Hrmpf.
21.35.45 #       <preglow> sigh...
21.36.21 #       <amiconn> I forgot to add global.h ... ouch+
21.38.21 #       <amiconn> preglow: http://amiconn.dyndns.org/global.h  This goes in apps/codecs/libFLAC/include (directly)
21.40.17 #       <preglow> amiconn: it builds now, shall i test it as well?
21.41.06 #       <amiconn> That would be ideal :) It works on both sims (except wv2wav, as mentioned)
21.42.23 #       <mst> WHOAH
21.42.30 #       <mst> I have a Z80-based player!
21.43.03 #       <preglow> that's not much to be happy about...
21.43.03 #       <preglow> heh
21.43.09 #       <Strath> heh
21.43.27 #       <Strath> ti-86 baby! ;)
21.44.40 #       <stevenm> mst, what kind of player is it? Archos?
21.45.07 #       <stevenm> preglow, is it possible to actually test codecs on simulators before testing them on target ?
21.45.14 #       <preglow> stevenm: sure
21.45.26 #       <mst> stevenm, no. A nameless OEM branded USB flash/mp3/FM/DVR player, known on the market under the common name of "S1 Mp3 Wilson Co. LTD" and branded under about 300 different nicknames
21.45.55 #       <stevenm> mst, hahaha
21.46.03 #       <preglow> amiconn: well, certainly seems to run fine
21.46.10 #       <amiconn> Good :)
21.46.33 #       <mst> stevenm, dont get me wrong, it's cheapass *and* ubercool. The damn firmware allows to read ebooks on it, and the player is sized a little bigger than a match box
21.46.45 #       <stevenm> preglow, How would you test codecs on a sim? More importantly, where to you get the sim? I tried to build a sim target form rockbox source.. fails on the 3rd file
21.48.02 #       <amiconn> preglow:
21.48.08 #       <amiconn> Thanks for testing
21.48.22 #       <amiconn> @all: Attention, huge commit ahead...
21.48.25 #       <mst> oh sweet.. IDA is picking the BIOS apart. OH SWEET.
21.48.40 #       <preglow> amiconn: no problem
21.49.22 #       <preglow> stevenm: i actually don't know, i haven't coded anything that would work on the sim yet, so i haven't tried building it
21.49.41 #       <preglow> i dabble mostly with coldfire asm, and that won't run on the sim
21.49.53 #       <mst> HMPF
21.50.18 #       <preglow> mst: if you just check out uisimulator and select Simulator when you run configure, that should be it, afaik
21.50.58 #       <preglow> mst: that is, check out 'uisimulator' from cvs, in addition to the usual rockbox files
21.51.22 Quit    YouCeyE (Read error: 110 (Connection timed out))
21.55.06 #       <mst> me?
21.55.15 #       <mst> I'm not even playing with rockbox yet 
21.56.28 #       <preglow> yes, sorry, me talking to the wrong persons again
21.56.57 #       <mst> heh
21.57.10 #       <mst> This is going to be very interesting. Verry interesting.
21.57.19 #       <amiconn> Phew, 43 files changed... hopefully I didn't break something non-obvious
21.58.26 #       <stevenm> Well.. I've been at this for 5 hours or so now. Thanks to people's help, this thing is optimized a LOT. Now, I better go study some math
21.58.26 Quit    jyp (Read error: 104 (Connection reset by peer))
21.58.39 #       <stevenm> and then, add support for drum sounds
21.58.45 #       <stevenm> good bye people
21.58.57 Join    jyp [0] (~jp@128.139-200-80.adsl.skynet.be)
22.00.18 Quit    stevenm ("Leaving")
22.01.40 Join    nozomiyume [0] (~vthakkar@ip-133-194.station.sony.com)
22.03.57 Join    nobby [0] (nobby@ACD54364.ipt.aol.com)
22.06.48 Join    muesli- [0] (muesli_tv@c-180-220-19.cvx-h.dial.de.ignite.net)
22.10.01 #       <mst> hmm
22.10.06 #       <mst> now this is disturbing
22.10.34 #       <mst> what the HELL does a x86 PC boot record do in a Z80-based firmware
22.10.48 #       <HCl> ?
22.11.01 #       <mst> HCl, I'm hacking my player.
22.11.09 #       <HCl> z80 based ? O.o
22.11.14 #       <HCl> aren't z80's incredibly slow...?
22.11.22 #       <preglow> mst: it's hiding?
22.11.42 #       <mst> http://www.jesstech.com/new/english/jes.HTML_Product.phtml?id=13# <- ATJ2085 is my CPU
22.11.53 #       <mst> apparently it's not TOO slow.. 24bit DSP
22.12.30 #       <mst> where the hell is the entry point on Z80 processors cold boot
22.12.31 #       <mst> grrrr
22.14.07 #       <jyp> Mmmm... Yet another obsure chinese chi
22.14.08 #       <jyp> p
22.14.23 #       <mst> yeah. a 32 bit Z80. This is wrong on SO many levels.
22.14.49 #       <jyp> I'd like you to succeed in porting Rockbox...
22.15.00 #       <jyp> since the gmini has a 24 bits dsp too ;)
22.15.18 #       <jyp> we might build up on each other's work
22.15.30 #       * HCl ponders writing an gcc-output-to-dyna-code tool.
22.15.31 #       <mst> first I need to decrypt the damn firmware.
22.15.33 #       <mst> heh.
22.15.44 #       <mst> jyp, what chip does gmini run on?
22.15.50 #       <HCl> cause i get the feeling i gotta do this more often....
22.16.57 #       <jyp> mst: TCC730, which is a S3CC410 in disguise
22.17.02 #       <jyp> http://www.mculand.com/sub1/mcu/calmrisc16_device/S3cc410.pdf
22.17.15 #       <jyp> CalmRisc16 core
22.19.47 #       <mst> RISC. I doubt my and your player have anything in common. heh.
22.19.59 #       <amiconn> HCl: You said your malloc() implementation had a small bug?
22.22.22 #       <jyp> RISC... doesn't mean much these days
22.22.39 Quit    chuck (Read error: 110 (Connection timed out))
22.23.59 #       <HCl> amiconn: well, it was my usage of malloc, not my implementation
22.24.07 #       <HCl> my implementation is fine, aside from not having free()
22.24.10 #       <amiconn> Okay...
22.25.51 #       <HCl> why?
22.26.06 #       <amiconn> 'cause I'm trying to make this work in the sim now
22.26.11 #       <HCl> ah :)
22.26.12 #       <HCl> ok.
22.26.18 #       <HCl> my malloc was only with dynarec anyways...
22.26.34 #       <amiconn> rockbox front page looks a bit funny with the latest commit....
22.28.07 #       <mst> Ahhh tits!!! I am disassembling the wrong firmware!!
22.28.15 #       <nobby> ROFL
22.28.21 #       <HCl> xd
22.29.02 #       <mst> hmmm... this gets even more interesting. I just found the word ``police'' in the dump.
22.29.22 #       <amiconn> HCl: rockmacros.h now clashes with the simulator #defines in file.h :(
22.29.30 #       <HCl> ick.
22.29.33 #       <HCl> why...?
22.30.08 #       <HCl> its only to reroute functions to the plugin api
22.30.19 #       <amiconn> Well, the file functions that need simulation (open(), opendir(), ....) are redefined for the sim to sim_open() etc
22.30.40 #       <HCl> you can just add an ifdef simulator in the rockmacros.h ...
22.30.47 #       <mst> man... don't you just love the chinese firmware.. comes with windows bootdisk, a warezed copy of minilyrics -and- a keygen to it
22.30.55 #       <HCl> lmao.
22.31.09 #       <amiconn> HCl: The problem is that your redefines are still needed as well.
22.31.16 #       <HCl> o.o
22.31.18 #       <HCl> hm..?
22.31.43 #       <amiconn> file.h defines open() -> sim_open() etc.
22.31.58 #       <amiconn> These functions are also exposed on the plugin api that way
22.32.15 #       <amiconn> rockboy needs open() -> rb->open() on the target
22.32.31 #       <amiconn> On the sim, it needs open() -> rb->sim_open() instead...
22.34.10 #       <amiconn> Hmm. It seems I need a longish workaround
22.34.42 #       <mst> "Patience.... The musical bottom spends a little more than one ½ minute to be taken care"
22.34.47 #       * mst kicks Google Translate
22.34.48 Quit    muesli- (Read error: 110 (Connection timed out))
22.35.07 #       <amiconn> #ifdef SIMULATOR / #undef <all sim_ functions> / #define <all sim_ functions> / #else / #define <target functions> / #endif
22.35.53 #       <HCl> o.o
22.36.46 #       <mst> oh now THAT's a discovery. Sigmatel, whom I initially suspected to be the vendor of my CPU, sued Action Semiconductor, who turns out to be the real vendor
22.38.03 #       <mst> And now I know why. Because ATJ2xxx is a ripoff of ST34xx. Which brings me back to square one.
22.39.03 Quit    nobby ()
22.39.10 #       <HCl> lol.
22.39.13 #       <HCl> good luck :P
22.39.17 Quit    preglow (Read error: 104 (Connection reset by peer))
22.39.37 #       <HCl> might i be able to hire anyone for a cookie to do my rewrite-gcc-to-dyna code work? :P
22.42.47 Quit    pill (Read error: 104 (Connection reset by peer))
22.43.12 Join    preglow [0] (thomj@s183a.studby.ntnu.no)
22.43.18 #       * preglow kicks his server
22.46.03 #       <HCl> blergh.
22.46.25 #       <HCl> 26 instructions just to calculate the gameboy flags
22.46.40 #       <HCl> thats not pretty :(
22.48.36 Join    muesli- [0] (muesli_tv@c-180-220-63.cvx-h.dial.de.ignite.net)
22.50.43 Quit    muesli- (Client Quit)
22.51.13 Join    jpburton5150 [0] (knoppix@cpe-24-94-54-216.stny.res.rr.com)
22.51.49 #       <CoCoLUS> hows rockboy progressing? :)
22.52.36 #       <jpburton5150> ok...so im having trouble compiling because there is a bug in gcc that for some reason wont let me compile calculator.c... ive tried updaiting gcc but to no avail... how might i remove calculator.c from the compile?
22.52.52 #       <preglow> jpburton5150: how do you know it's a gcc bug?
22.53.30 #       <jpburton5150> it says a little message like "internal compiler overflow" and then tells me to report it to the gcc bug center
22.53.51 #       <HCl> CoCoLUS: okish, i got gcc to spit out the assembly i need, i'm trying to analyse it to see how i'll encode it into the dynarec
22.54.03 #       <HCl> jpburton5150: i had that.. it went away on its own o.o
22.54.06 #       <amiconn> Hrmpf, bug in plugin.h ...
22.54.11 #       <Renko> jpburton5150, what version of gcc are you using?
22.54.26 #       <jpburton5150> ive tried 3.3.5 and 3.4.3
22.54.39 #       <jpburton5150> but neither work...
22.55.32 #       <jpburton5150> looking at the makefile it seems that it compiles everything in the apps/plugins folder...
22.55.46 #       <jpburton5150> so i assumed that if i just deleated calculator.c it would work
22.55.52 #       <jpburton5150> but it gave me errors
22.55.57 #       <HCl> the problem is, the code gcc outputs uses 4 regs, while i really only have one available to me.
22.55.59 #       <Renko> i got it with the latest gcc but went to 3.4.1 cos that's what the autobuild uses and it works
22.56.09 #       <jpburton5150> hmm alrighty
22.56.18 #       <jpburton5150> well i'll try updating to that version then in a little bit...
22.56.54 #       <Renko> i also tried deleting the code in calc... but it produced unusable code on the iriver
22.57.03 #       <CoCoLUS> you have to remove the filename from the SOURCES file
22.57.05 #       <CoCoLUS> in that dir
22.57.09 #       <CoCoLUS> than it will be left out
22.57.48 #       <Renko> CoCoLUS, it should compile cleanly tho..
22.58.20 #       <jpburton5150> alrighty thanks
22.58.35 #       <jpburton5150> thats what i was looking for...
22.58.51 #       <jpburton5150> Renko: did you get the same problem?
22.59.03 #       <Renko> yeah
22.59.29 #       <Renko> or simmilar but certainly in calculator.c
22.59.48 #       <jpburton5150> hmm i see...
22.59.58 #       <CoCoLUS> i had the same problem with an old version of gcc
23.00.12 #       <jpburton5150> well thats interesting as calculator.c i thought was for the calculator plugin...
23.01.06 #       <CoCoLUS> it is?
23.01.23 #       <jpburton5150> it's in the plugin folder...
23.01.27 #       <Renko> yeah it is
23.02.10 ***     Saving seen data "./dancer.seen"
23.02.47 #       <markun> I made a picture of the jpeg viewer on iriver: http://130.89.160.166/rockbox/rockbox-grayscale.jpg
23.03.59 #       <CoCoLUS> nice
23.04.23 #       <jpburton5150> woah thats awesome...
23.04.35 #       <jpburton5150> i didnt know we got grayscale working...
23.05.06 #       <markun> well, it's not in cvs yet.
23.05.37 #       <jpburton5150> i see...
23.05.48 #       <jpburton5150> does iriver have 4 or 16 shades?
23.05.54 #       <markun> only 4
23.08.04 #       <stripwax> markun - that's truly cool!  
23.08.21 #       <markun> Yes, that's what I thought :)
23.09.04 #       <markun> I also tried a picture of the iriver itself, but that didn't look as good as einstein.
23.09.52 #       <Renko> dmesg
23.09.57 #       <Renko> :x
23.12.02 #       <stripwax> Stevenm -  I'm just listening to the output of the midi codec right now, built under cygwin.    seems a-ok!
23.13.22 #       <CoCoLUS> ? we have a working sound codec? :D
23.13.36 #       <stripwax> Volume changes seem kinda abrubt though - they should have a couple of milliseconds of interpolation applied imho
23.13.59 Join    Camilo [0] (~chatzilla@userca029.dsl.pipex.com)
23.14.02 #       <stripwax> CoCoLUS - this is a midi plugin, and I was running the code under Windows :-S
23.14.12 #       <CoCoLUS> midi sounds like sound to me :P
23.15.18 #       <stripwax> Yeah, volume level changes are waaaaay too abrubt.     Does anyone have a contact for stevenm?
23.18.24 #       <jyp> good night folks
23.18.28 Quit    jyp ("poof!")
23.19.06 #       <HCl> nice work, can't wait to hook 2 bits grayscale into rockboy
23.19.24 #       <preglow> stripwax: do you mean at note start and end?
23.20.27 Quit    jpburton5150 (Read error: 54 (Connection reset by peer))
23.20.29 #       <stripwax> yes but particularly note end.   iirc 'note off' is often implemented in a midi file as 'volume 0' rather than a real note off event, and it sounds like it's switching volume level to zero immediately rather than over a few milliseconds
23.20.56 #       <markun> HCl: I'm a bit afraid to commit before I made it faster. Everything is a bit slow right now.
23.21.05 #       <HCl> sure.
23.21.07 #       <stripwax> i could be wrong of course.  i guess this would be handled better if the envelope table is read/used
23.21.10 #       <HCl> i'm not in a hurry
23.23.28 #       <HCl> james bond is kinda corny sometimes...
23.23.42 Join    TexJoachim [0] (~TexJoachi@p508BB121.dip.t-dialin.net)
23.23.53 #       <preglow> stripwax: i don't think he has implemented envelopes yet
23.24.05 #       <preglow> stripwax: so note on/off will be abrupt
23.24.48 #       <stripwax> yes
23.25.35 #       <preglow> the docs don't say squat about how to interpret that data
23.25.40 #       <preglow> but i guess timidity parses it
23.26.32 Join    hubble [0] (hubble@h41n2fls302o1033.telia.com)
23.27.40 Quit    frank ("Leaving")
23.29.52 Join    bnewhouse [0] (~bnewhouse@cpe-24-94-54-216.stny.res.rr.com)
23.30.00 Part    stripwax
23.33.57 Quit    hubble ()
23.36.31 Quit    markun ()
23.39.05 #       <amiconn> Grr. Proper linking of rockboy for the sim is really tricky.
23.43.05 #       <HCl> mm? :/
23.43.11 #       <HCl> whats going wrong now?
23.44.46 #       <amiconn> I don't get rockboy to link on a simulator build (win32)
23.45.35 #       <amiconn> Same on x11 simulator
23.48.01 #       <amiconn> Ahahah! I need -nostdlib for the intermediate .o
23.49.51 #       <preglow> ????
23.49.58 #       <preglow> why?
23.50.05 #       <preglow> i thought -nostdlib was a linker option only
23.50.26 #       <amiconn> Yes it is.
23.50.52 Part    TexJoachim ("Bye!")
23.50.54 #       <amiconn> I link several individual objects into one intermediate .o before building the final plugin
23.51.12 #       <amiconn> For this to work, I need -r -nostdlib
23.51.52 #       <preglow> ahh
23.52.14 #       <HCl> aha.
23.52.20 #       <HCl> its a good idea to add that anyways
23.52.26 #       <HCl> is it working?
23.52.28 #       <preglow> someone fix libmad makefile ://
23.52.43 #       <amiconn> HCl: It starts, loads the rom, the crashes the simulator.
23.52.50 #       <HCl>  xI
23.52.56 #       <HCl> kay :3
23.53.11 #       <amiconn> I suppose it is the same malloc() clash that prevented the codec plugins from working. Adding workaround...
23.55.30 Join    webguest44 [0] (~86ae1502@labb.contactor.se)
23.56.40 Quit    webguest44 (Client Quit)
23.56.52 Join    webguest69 [0] (~86ae1502@labb.contactor.se)
23.57.23 Quit    webguest69 (Client Quit)
23.58.09 #       * HCl grins.
23.58.20 #       <HCl>                     DYNA_MOVE_l_r_to_r(3,2,1);
23.58.24 #       <HCl> i actually have a line that goes 3 2 1 :P
23.58.55 #       <amiconn> Hmm. Now it crashes a bit later, at emu_run