--- Log for 09.05.106 Server: clarke.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 1 month and 14 days ago 00.00.22 Join MagusG [0] (i=MagusG@68-186-217-111.dhcp.cdtw.ga.charter.com) 00.00.40 # ...and perhaps even feed analog input signals to s/pdif out 00.00.57 # amiconn: echo spdif in to spdif out? 00.01.02 # yes 00.01.11 # where would we get a proper clock? 00.01.21 # Erm, from input? 00.01.33 # right, sclk1-4 00.01.36 Quit dpro (Connection timed out) 00.01.37 # i thought those were the iis clocks 00.01.44 # but they're not, obviously 00.02.00 # well, sure, not a bad idea 00.02.05 Join Rincewind_12 [0] (i=Miranda@Ec8be.e.pppool.de) 00.02.34 # i'd actually say it's a good one, so agreed 00.02.41 # i can't test it, though 00.03.12 # I can't test it as I would need a second toslink cable + a second toslink->mini adapter 00.03.32 # i'd need another spdif input capable device 00.03.34 # which i haven't got 00.03.43 # Then I could feed dvd player -> h140, and h140 -> opt/coax converter -> archos recorder 00.03.45 # i have the extra cable 00.04.31 # but no 00.04.35 # I'll try your s/pdif recording next 00.04.45 # go on 00.04.51 # i'll try to update the patch tomorrow 00.04.55 # i don't have my player here now 00.05.03 # so can't test 00.05.11 Join Genre9mp3 [0] (n=Yngwiejo@88.218.17.158) 00.05.23 # The analyzer shows symbol error with no signal attached, an when pulling the plug half-way I also get parity error (of course) 00.05.38 # yep 00.06.09 # if you discover why dma suddenly stops when unplugging several times, i'll be very happy 00.06.12 # i have no idea 00.08.52 Join m0nk_ [0] (n=m0nk@dialup-4.245.77.6.Dial1.StLouis1.Level3.net) 00.08.58 # hey guys 00.09.32 Quit Genre9mp3 (Client Quit) 00.09.47 # m0nk_: welcome back 00.09.54 # thank you mark 00.10.11 # m0nk_: we have a #gigabeat btw.. 00.10.35 Join Genre9mp3 [0] (n=Yngwiejo@88.218.17.158) 00.10.41 # awesome i will check it out laterish 00.10.42 # preglow: This is somewhat strange. (1) I get no monitoring although I think I should? 00.10.55 # i wanna see whats going down here for now 00.11.05 # amiconn: indeed you should 00.11.17 # (2) When unplugging, the size counter keeps running. After repeated plug/unplug, recording stops 00.11.32 # yep, that's what i get too 00.11.36 # I think this is normal behaviour, as the recording dma isr checks for dma errors 00.11.37 # but the monitoring should work, afaik 00.11.54 # grr i need a hot chik to goto the movies with:| 00.12.02 # But: if I then start recording again, it hangs after 8KB (1 dma block) 00.12.04 # I havent been out with a girl in too long 00.12.15 # amiconn: exactly 00.12.23 # amiconn: you need to exit, then reenter the recording screen 00.12.25 # then it'll work again 00.12.25 Quit egtrippen ("CGI:IRC (EOF)") 00.12.33 # so something in the init code fixes the situation 00.13.08 # I can't, rockbox hangs 00.13.21 # yes, before you try to record again 00.13.27 # at that point, it's too late 00.14.07 # I'm still puzzled by the fact that the transfer keeps going with no signal 00.14.14 # yes, it's weird 00.15.46 Quit BHSPitMonkey__ (Read error: 104 (Connection reset by peer)) 00.16.49 Join Daishi [0] (n=daishi@pool-71-246-116-36.nycmny.east.verizon.net) 00.17.15 # Hmm, now monitoring works??? 00.17.25 # haha 00.17.26 # hooray! 00.17.35 # did you just rolo the new firmware? 00.17.48 # the first time, that is 00.17.48 Part m0nk_ ("Leaving") 00.19.07 # myes 00.19.10 # then that explains it, probably 00.19.14 # why? 00.19.46 # hardware regs not being left in the state i expect them to be, i guess 00.20.07 # Btw, DMA only drops out on parity error. When pulling s/pdif fast, it keeps going, but when pulling slow, causing parity errors, it drops 00.20.29 # you sure? i thought i noticed parity errors when the dma didn't drop as well 00.20.39 # i've hardwired the status display to show me the interrupt status flag 00.20.46 # If so, that needs investigation. There should be no difference between rolo and boot 00.21.28 # not much work has been done with spdif init 00.21.49 # so some regs might be left in some weird state 00.22.15 Quit MagusG (Connection timed out) 00.22.28 Quit midkay (Read error: 104 (Connection reset by peer)) 00.22.44 Quit petur () 00.22.45 Join midkay [0] (n=midkay@rockbox/developer/midkay) 00.27.14 # When you have status bar set to off...the expected behavior for the menu/browser text is to go on top of the screen right? 00.27.21 Join MagusG [0] (i=MagusG@68-186-217-111.dhcp.cdtw.ga.charter.com) 00.29.20 Join Thus0 [0] (n=Thus0@86.73.49.22) 00.29.21 # Hello 00.29.25 # hi 00.29.41 # I've just installed rockbox on my iriver :) 00.30.03 # Genre9mp3: yes 00.30.45 Join Paul_The_Ner1 [0] (n=Paul_The@cpe-66-68-93-2.austin.res.rr.com) 00.31.08 # Well, at least this happens in the main LCD.....but in my H300LCD Remote this doesn't happen. When the status bar is off, the text remain at its initial position, and in the area where the status bar is you can see part of the WPS 00.31.16 # this is a bug, right? 00.31.34 Part Paul_The_Ner1 00.32.17 # Thus0: then your life just took a turn for the better 00.32.53 # Genre9mp3: Fill a bug report on the bug tracker. I will try to look at this tomorrow 00.33.21 # I suppose this happens for both the H100 and H300 Remotes 00.33.37 Join TCK [0] (i=TCK@85-210-57-164.dsl.pipex.com) 00.33.57 # more probably 00.34.43 # Also, when I start the player, the staus bar area in the remote is blank.... 00.36.18 # Genre: In my H100 when I turn of the status bar the text moves up 00.38.12 Quit gursikh (Read error: 110 (Connection timed out)) 00.38.22 Join sockerteze [0] (n=sockerte@pool-71-251-185-218.nrflva.east.verizon.net) 00.41.30 Join Dinomight [0] (n=42ec452a@labb.contactor.se) 00.43.39 # does anyone have a link to some eq presets (i'm not an audiophile and am not really certian how to make good ones for standard music types (ie rock, classical, pop, metal) 00.43.48 # we haven't made any 00.43.55 # perhaps the mistic creq has 00.43.58 # crew 00.44.15 Join RoC_MM [0] (i=dragon@dsl-29-8.cofs.net) 00.44.48 # and I think that you should try making on your own....because these things are subjective 00.44.55 # also it would depend on your headphones and such anyway 00.45.37 # Note to all who didn't hear last night: iPod 4G Grey 5/7 build is not functional and does not get beyond boot logo. 5/5 build works. 00.46.13 # of course your should make them on your own, but it's still fun to have presets 00.46.46 # I know that someone made 5 presetes in the MR 00.47.06 # Genre on my H100 your WPS fits perfectly on both screens (remote, main) with and without the status bar. 00.47.24 # pilot's experimental build for h100 has some eq presets too 00.47.35 # Gah, this is weirdo 00.47.40 # what? 00.47.57 # I think I know where the 8KB come from 00.48.02 Join gtkspert [0] (n=gtkspert@124-168-66-103.dyn.iinet.net.au) 00.48.18 # XavierGr: The problem is not in the WPS screen....just set the status bar off and the go to the WPS and then back to menu... 00.48.36 # amiconn: hwere? 00.48.53 # The pcm recording is simplistic. A bit too simplistic. It _assumes_ the transfer succeeded when receiving the DMA interrupt 00.48.57 # first person to make fun of my lousy typing gets killed 00.49.03 # Genre9: I just did 00.49.07 # XavierGr: Do you get the text in the first line there? I don't 00.49.11 # and nothing seems wrong 00.49.18 # I will try on H300 too 00.49.20 # ...but the interrupt doesn't necessarily mean it did. It can also mean 'error' 00.49.27 Join scott666 [0] (n=scott666@c-24-245-75-109.hsd1.mn.comcast.net) 00.49.32 # sure 00.49.37 # that's worth checking for sure 00.49.43 # but why would it fail? 00.49.52 # XavierGr: maybe this is only for the H300 LCD Remotes?? 00.50.22 # It looks like the recording dma is supposed to run all the time while in recording screen, even if no recording is going on 00.50.49 # it is 00.50.51 # for the peak meter 00.51.09 # which is always on 00.51.38 # A stop-from-error posts PCMREC_STOP, and pcmrec_stop() in turn calls pcmrec_dma_start(); 00.52.24 # I think it's already this restart which fails, but due to the simplistic logic the recording code thinks one full block was transferred 00.52.35 Quit Rincewind_12 (Read error: 104 (Connection reset by peer)) 00.52.37 # makes sense 00.52.59 Quit sockerteze (Read error: 131 (Connection reset by peer)) 00.53.08 # I added INTERRUPTCLEAR = 0x03c00000; to pcmrec_dma_start() for a test, but to no avail 00.54.15 Quit ender` (" Be wary of strong drink. It can make you shoot at tax collectors and miss.") 00.54.55 # Genre: Are you sure? I just checked with my H300 and all seems to be fine 00.56.51 Join Paul_The_Nerd [0] (n=Paul_The@cpe-66-68-93-2.austin.res.rr.com) 00.58.03 Quit Dinomight ("CGI:IRC") 01.00.40 # preglow: Did you test with logf? 01.00.40 # isn't the cpu supposed to stay boosted all the time when the codec-buffer gets refilled? 01.00.58 # It's supposed to boost while filling, yeah. 01.01.18 # amiconn: i have, but it depends for what you mean 01.01.19 # At least it *used* to be supposed to. 01.02.24 # on my device it changes between 124 and 45Mhz. but i will check again with a cvs build. 01.03.45 # Well it's also possible the buffering behaviour's changed recently. I wouldn't really be even close to an authority. ;-) 01.04.39 # i just wanted to mention it, in case this isn' right 01.05.21 # preglow: As I suspected: dma error fires twice in a row, effectively disabling dma 01.05.52 # amiconn: and again, only on parity error? 01.06.27 # Not sure, it happens when pulling/plugging 01.06.42 # The weird thing is that it says DMA error 0x41 01.06.51 # set the sample rate: display in recording.c to display the interrupt status register 01.06.54 # it helps 01.06.59 # at least you can see just what triggers it 01.10.03 # with a cvs build it also unboosts while filling the buffer. 01.11.20 Quit MagusG (Connection timed out) 01.11.32 # How the heck can the interrupt fire twice in a row with dma error?? 01.12.40 Join BHSPitLappy2 [0] (i=Steve-O@adsl-66-141-169-130.dsl.rcsntx.swbell.net) 01.13.12 Quit BHSPitLappy (Nick collision from services.) 01.13.22 Nick BHSPitLappy2 is now known as BHSPitLappy (i=Steve-O@adsl-66-141-169-130.dsl.rcsntx.swbell.net) 01.13.26 Join Farpenoodle [0] (n=solo84@cm155.sigma240.maxonline.com.sg) 01.13.39 # Hmm I think the DMA1 isr has a timing problem.... 01.13.57 # It clears the error flags before determining whether to stop dma 01.14.14 # ...so dma continues running 01.14.19 Join MagusG [0] (i=MagusG@68-186-217-111.dhcp.cdtw.ga.charter.com) 01.19.54 Quit scottder (Read error: 110 (Connection timed out)) 01.20.26 Join ashridah [0] (i=ashridah@220-253-120-228.VIC.netspace.net.au) 01.21.24 Join qwm [0] (n=qwm@h147n2fls32o1010.telia.com) 01.24.20 Quit Kohlrabi ("Fast alle Menschen sind Regenwürmer") 01.25.24 # What is tentative date for 3.0? 01.25.40 # 15. or 29. i thiunk 01.30.19 # preglow: What's irritating me is that the doubled dma_stop doesn't trigger a dma_start, even though it should 01.30.21 Quit Thus0 (Client Quit) 01.30.31 # No "dma1 started" in the log 01.30.42 # why is it stopped in the first place? 01.31.11 # because of the DMA error... 01.31.18 # why is there one? 01.31.35 # dma should just read from PDIR2, no? why does it care it's filled with invalid data? 01.31.55 Part Paul_The_Nerd 01.32.14 # Not 100% sure. My guess is that PDIR2 does report something wrong when there's an error 01.32.22 Quit Gargamale ("poop") 01.32.26 Quit mikearthur (Read error: 104 (Connection reset by peer)) 01.33.18 # Ahahaha, it can't! 01.33.26 # oh? 01.33.55 # pcmrec_stop() checks whether recording is already stopped: if (!is_recording) ... 01.34.03 *** Saving seen data "./dancer.seen" 01.34.06 # oh, right, that 01.34.10 # ...but the isr sets is_recording to false in case of error 01.34.32 Quit qwx (Read error: 110 (Connection timed out)) 01.35.29 # DMA overrun will cause similar behaviour 01.39.03 Join mirak [0] (n=mirak@AAubervilliers-152-1-32-172.w83-114.abo.wanadoo.fr) 01.40.15 Join BHSPitLappy2 [0] (i=steve-o@adsl-66-141-169-130.dsl.rcsntx.swbell.net) 01.43.42 Join jbauman [0] (i=Johnq@JBAUMAN.RES.cmu.edu) 01.45.08 Quit BHSPitLappy (Nick collision from services.) 01.45.24 # Both cases (DMA error and DMA overrun) will cause the DMA not to be restarted, leading to a hang next time recording should strat 01.45.28 # *start 01.45.29 Quit _Lucretia_ (Read error: 110 (Connection timed out)) 01.45.51 # This is clearly visible by the non-working peakmeter 01.45.55 # yup 01.45.58 # but yes 01.46.09 # if we notice an error this way, we should just stop recording 01.46.26 # which way? 01.46.27 # and use that as the error condition instead of spdif parity/symbol error 01.46.32 Quit dpassen1 () 01.46.36 # dma being stopped 01.46.51 Join _Lucretia_ [0] (n=munkee@dyn-62-56-59-235.dslaccess.co.uk) 01.46.51 # I'd rather restart dma 01.47.03 # can you be sure the error condition isn't still valid? 01.47.09 # it gets stopped for a reason 01.47.32 # In case of overrun: yes, there is a real reason: data not flused fast enough 01.47.46 # In case of DMA error: No real reason, imho 01.47.59 # it's real enough, apparently 01.48.05 # even though i don't know what triggers it 01.48.18 # On archos, I can fiddle with the signal no matter what, it sometimes records garbage, but it neither stops nor hangs 01.48.34 # well, sounds good enough 01.48.43 # if you're yanking the cable in and out, you get what you want 01.48.45 # It just halts transfer with no signal, but that's all 01.48.50 Quit XavierGr () 01.49.18 # It's handled by the mas - it simply doesn't encode without a signal in s/pdif mode 01.49.28 Quit Moos ("Glory to Rockbox !!!") 01.49.35 # btw, i just remembered i actually do have another spdif in 01.49.42 # my old minidisc player 01.49.48 # i just need another tos/jack adapter 01.49.57 # i'll see if i can find a shop that carries them around here 01.50.26 # I know a shop here, maybe I'll visit it a second time tomorrow (for a cable + adapter) 01.50.28 # no, two tos/jack adapters... 01.51.33 # The archos recording engine doesn't even stop on buffer overrun. It's debatable whether this is good or not 01.51.44 # why not? 01.51.50 # it should signal an error, but also keep recodring 01.51.53 # recording, even 01.52.32 # The recording transfer happens in an isr. It doesn't care whether the thread flushes in time or not 01.52.49 Quit webmind (Read error: 104 (Connection reset by peer)) 01.53.26 Join akaidiota [0] (n=not@84-217-7-152.tn.glocalnet.net) 01.53.27 # That lead to strange effects, like the second buffer round overwriting the beginning of the first, in case the first flush was delayed for too long 01.53.38 # but yeah, i can't think of any reason why we wouldn't want to echo the spdif in signal 01.53.41 # so we should do that 01.53.45 Quit Benacool () 01.54.37 Join webmind [0] (i=webmind@feather.perl6.nl) 01.54.46 # There was a combination of conditions where that would happen: (1) the peakmeter drawing cpu power by running in high-perf mode and (2) the fat driver needing to search for the next free block, in case the nextfree hint was erased 01.55.05 Quit tucoz ("Leaving") 01.55.13 # I solved it by avoiding (1) - switching peakmeter to low-perf while flushing to disk 01.55.49 # Stopping (or waiting) for the flush to finish would require a framewalker, which we still don't have 01.58.44 Join dpassen1 [0] (n=dpassen1@resnet-236-163.resnet.UMBC.EDU) 01.59.13 # but yeah, what about recording with no spdif in, then? 01.59.23 # Hm? 01.59.33 # i can see no reason it shouldn't be allowed if we do proper dma restarting all the time 01.59.52 # currently recording hangs sometimes if you record with no spdif source connected 02.00.04 # and the iriver fw doesn't let you record if you do that 02.00.05 # should we allow it? 02.00.14 # Perfect silence... 02.01.12 Quit tvelocity ("Ex-Chat") 02.02.07 # Hmm, for some reason the DMA doesn't like just resetting the error flag 02.03.12 Quit Seed (Nick collision from services.) 02.03.18 Join Seed [0] (i=ben@85-64-200-85.barak-online.net) 02.04.57 Join whatboutbob_ [0] (n=cb1ab102@labb.contactor.se) 02.05.11 # is recording through line-out/in a secondary priority or what is the gist of that? 02.05.12 Join JdGordon [0] (i=jonno@c211-28-95-208.smelb1.vic.optusnet.com.au) 02.09.11 Join mikearthur [0] (i=mike@82-41-205-190.cable.ubr11.edin.blueyonder.co.uk) 02.10.54 Quit akaidiot (Read error: 110 (Connection timed out)) 02.11.03 # recording through line-out ??? 02.11.50 # the eighth inch jack 02.11.53 # that headphones go in 02.11.58 # recording in through that 02.11.58 # what target? 02.12.04 # iPod in general. 02.12.04 Quit mikearthur (Client Quit) 02.12.14 Quit MagusG (Connection timed out) 02.12.21 # it's "line-out" if it's a headphone plugged in, and "line-in" if a mic is plugged in 02.12.30 # or so I would assume the language goes 02.13.03 # recording on ipod isn't much priority for me, at least 02.13.08 # don't know about the other ipod coders 02.13.15 # that's what I'm looking for. 02.13.18 # hell, it's no priority at all 02.13.23 # don't even know if it's possible on my nano 02.13.31 # sorta as a "neat feature" 02.13.41 # I have a use for it if it comes too 02.14.01 # what would be the problem on the nano? 02.14.19 Join MagusG [0] (i=MagusG@68-186-217-111.dhcp.cdtw.ga.charter.com) 02.14.40 # preglow/amiconn: sounds like you've found why spdif recording hangs? 02.16.05 # sounds more like amiconn has 02.16.10 # i don't even have my h120 here 02.17.05 # There's a strange thing: The DMA error reports as 0x41, which means 'configuration error', i.e. the transfer size and/or addresses don't match the data size 02.17.29 # (not integer multiple of bytes, or not aligned) 02.17.50 # But I displayed, SAR1, DAR1 and BCR1. 02.18.23 # They look fine, but BCR1 is zero (apart from the upper 8 bit which are reserved) 02.19.11 # So it seems the DMA error is delayed until the actual end-of-transfer (unless the controller fiddles with these values on error, which I don't think it does) 02.21.02 # sounds unlikely 02.22.08 # I just hard-crashed the unit... 02.22.39 # It switched off and started to reboot into iriver - which hung at the start screen, ata led on 02.23.27 # not bad... 02.23.36 # Reproducable... 02.23.45 # how'd you manage that? 02.24.05 # I just tried to start the next chunk in case of DMA error... 02.24.18 Quit jaebird ("Ex-Chat") 02.25.16 Quit ashridah ("Leaving") 02.26.30 Quit Acksaw ("I'm off, see ya later!") 02.27.03 Quit Farpenoodle (Read error: 110 (Connection timed out)) 02.27.29 Quit PaulJam (".") 02.27.35 # Hmm, something overflows if the interrupt fires too often (but I had it working for quite a while with heavy errors) 02.27.48 # Then got: Panic: No Font 02.28.04 Quit Genre9mp3 ("Leaving") 02.28.15 # ... 02.28.59 # probably due to logf()ing in the isr 02.29.07 # hahaha 02.29.36 # yeah, I'm giving it a hard time... 02.29.56 # it does number among the things one should not do in an isr, yes 02.30.02 # but hell, i need to sleep 02.30.13 # i'll be reading the logs if you discover anything more 02.30.16 # good night 02.30.18 # Final test, w/o logf 02.30.26 # nite 02.31.40 Quit Seed (Nick collision from services.) 02.31.47 # Yay! 02.31.47 Join Seed [0] (i=ben@85-64-200-85.barak-online.net) 02.31.59 # It works! It's teh hack, but it works :) 02.36.47 # nice one! 02.37.46 Part synth7 02.38.27 # It currently forces the DMA to run again. We'll need proper handling, but now we know what happens, and how to recover 02.39.03 # Of course such a recording won't be glitch-free, 02.39.37 # but in fact I think we should continue recording when there is an error. Better a slight glitch than a stopped recording... 02.42.20 # Of course it would be better to trigger on the symbol error/ parity error interrupts, and stop DMA until the errors go away 02.48.21 # amiconn: i agree. better an errored something than nothing. 02.48.42 Join qwx [0] (n=qwm@h147n2fls32o1010.telia.com) 02.50.58 Nick BHSPitLappy2 is now known as BHSPitLappy (i=steve-o@adsl-66-141-169-130.dsl.rcsntx.swbell.net) 02.51.15 Join XavierGr [0] (n=XavierGr@ppp121-54.adsl.forthnet.gr) 02.51.47 Join perl|wtf [0] (n=say@cpe-68-173-42-25.nyc.res.rr.com) 02.58.14 Quit qwm (Read error: 110 (Connection timed out)) 03.02.00 # ahh 03.02.02 # i shake. 03.02.24 # freezing period? 03.02.39 # nope... 03.04.52 Join sockerteze [0] (n=sockerte@pool-71-251-185-218.nrflva.east.verizon.net) 03.06.19 Quit pixelma (" HydraIRC -> http://www.hydrairc.com <- Get hot chicks here!") 03.06.36 # hmm... 03.07.29 # you know, it may be due to the amount of caffeine i usually consume... 03.09.39 # amiconn: let me know if there's a new patch you'd like me to test. 03.09.54 # okay, i'll get to work on the emulator this weekend. 03.11.45 Quit sockerteze (Read error: 131 (Connection reset by peer)) 03.13.51 Quit jbauman (Read error: 104 (Connection reset by peer)) 03.15.58 Join sockerteze [0] (n=sockerte@pool-71-251-185-218.nrflva.east.verizon.net) 03.22.38 Join dsh-1 [0] (n=daishi@pool-71-246-109-198.nycmny.east.verizon.net) 03.24.00 # Can I get a different OS to boot by default? 03.24.21 # you have more than two? 03.24.58 Quit sockerteze ("Chatzilla 0.9.73 [Firefox 1.0.7/20050915]") 03.25.13 # I would have liked to have three but I had to delete one. 03.25.25 # Can I set the iPod firmware as the default OS to boot? 03.26.06 # I wrote a patch for this, which is surprisingly popular until people realize that they'll have to compile it themselves because I won't do it for them 03.26.19 # http://efnet-math.org/~djao/apple-default.diff 03.26.29 # No problem for me. ;-) 03.26.39 # Will it interfere with a CODEC patch I use? 03.26.41 Quit Daishi (Nick collision from services.) 03.26.44 Nick dsh-1 is now known as Daishi (n=daishi@pool-71-246-109-198.nycmny.east.verizon.net) 03.26.56 # no, it's one line and it's in the bootloader file which has nothing to do with codecs 03.27.21 # Okay, I'll run it when tonight's source is released. 03.27.23 # Thanks. 03.29.20 # What button do I hold in yours to boot Rockbox? 03.29.42 # Menu? 03.29.43 # menu 03.29.51 # Alright, I just read the C. 03.30.34 # I would have preferred not to have to compile Rockbox at all but this is no problem because I already have to recompile for the CODEC I want. 03.30.51 # oh and there's no reason to wait for tonight's source, this patch is in the bootloader, and the bootloader is different from the usual rockbox.zip 03.31.16 # you have to reinstall the bootloader to use the patch (see, it gets complicated already) 03.31.23 # that means ipodpatcher blah blah 03.31.30 # ipod_fw etc. 03.31.40 # Oh, that. 03.31.48 # the bootloader hasn't changed in like a month 03.31.53 # Alright, I'll find the source to that. 03.32.32 # ../tools/configure ;