--- Log for 16.09.104  Server: leguin.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 20 days and 13 hours ago

00.00.40 #       <LinusN> hola
00.00.43 Quit    silencer_ (Remote closed the connection)
00.02.16 #       <amiconn> Seems I was a bit confused last night.
00.02.28 #       <LinusN> ?
00.02.53 #       <amiconn> Yes, I confused PA and PB (RTW and EOD).
00.03.10 #       <amiconn> Rockbox used indeed PB14
00.04.21 #       <amiconn> Anyway, I implemented my modifications into the recording transfer (first version is not asm, but plain C)
00.04.41 #       <amiconn> Currently doing a longer test recording
00.05.54 #       <amiconn> I also implemented (quick hack) displaying the spdif crc status in the recording screen
00.06.34 #       <amiconn> The 2 data sheets disagreed on the correct register number, but I found the right one
00.08.02 #       <amiconn> With several short test recordings I was able to trigger the spdif synchronization bug. This gives totally distorted recordings, but not more bad frames than usual
00.09.00 #       <amiconn> However, I found another rockbox bug :(
00.09.31 #       <amiconn> You can call the recording menu from the recording screen via F1, even when currently recording
00.09.44 #       <amiconn> If you go back, the recording is stopped!
00.10.01 #       <midk> amiconn, actually stopped or just shows the stopped icon?
00.10.50 #       <amiconn> It's actually stopped, the recording size displays as 0 bytes. "Play" will start a new recording
00.11.18 #       <amiconn> (At least this happens when source == spdif)
00.11.52 #       <LinusN> bad
00.12.01 #       <midk> s/bad/bad Linus.
00.12.02 #       <midk> :)
00.12.07 #       <LinusN> the lcd on the iriver is parallel
00.12.25 #       <LinusN> i have identified d0-d7
00.12.32 #       <LinusN> and the cs
00.12.57 #       <LinusN> LA hhokup is next
00.13.00 #       <LinusN> hookup
00.25.33 Join    ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk)
00.27.35 Join    mecraw_ [0] (~lmarlow@69.2.235.2)
00.28.13 Join    silencer [0] (~silencer@zen.via.ecp.fr)
00.34.55 #       <LinusN> the bdm wiggler is now in Paris, coming closer... :-)
00.35.52 #       <bagawk> whats what?
00.35.58 #       <ripnetUK> where does it have to get to??
00.36.05 #       <ripnetUK> the wiggler that is :)
00.36.35 #       <LinusN> it's a debugger interface for the coldfire cpu, and it's on its way to me in stockholm
00.36.47 #       <bagawk> neato
00.36.54 #       <bagawk> time to go do school work
00.36.56 #       <bagawk> see you :)
00.36.59 #       <LinusN> cu
00.37.09 Quit    bagawk ("Leaving")
00.38.10 #       <ripnetUK> its 2008km by road from Paris to Stockholm :)
00.40.34 Quit    zeekoe ("bed time")
00.41.42 #       <amiconn> LinusN: Why does usb_slave_mode(true) call ata_init() before handing over control to the usb bridge? Thinking about the mmc driver...
00.43.59 Quit    mecraw (Read error: 110 (Connection timed out))
00.48.35 ***     Saving seen data "./dancer.seen"
00.49.17 Join    webguest93 [0] (~c7e73180@labb.contactor.se)
00.50.46 Join    PaulS [0] (~0d0274bd@labb.contactor.se)
00.51.42 #       <PaulS> Is Dave Hooper around?
00.53.30 Quit    webguest93 (Client Quit)
00.54.12 #       <LinusN> amiconn: i din't remember
00.54.15 #       <LinusN> don't
00.54.42 #       <LinusN> it may not even be necessary...
00.54.55 #       <amiconn> The only purpose I can imagine is switching on the ata power...
00.54.58 #       <LinusN> could be some old obsolete workaround
00.55.49 #       <amiconn> Although I don't know if it may happen that ata is not yet initialized when entering usb mode
00.56.23 #       <amiconn> In that case, ata_standby(15) wouldn't work without ata_init()
01.04.15 #       <LinusN> ata_standby(15) should be removed and replaced with changing the powersave mode instead
01.05.06 #       <LinusN> since ata_standby attempts to spin down immediately
01.05.15 #       <LinusN> gotta reboot
01.05.17 #       <LinusN> cu soon
01.05.20 Part    LinusN
01.08.06 Join    LinusN [0] (~linus@labb.contactor.se)
01.08.32 #       <PaulS> I'm having all sorts of troubles getting my attachment in IriverPort up... It claims to have attached the file but browsing to it returns "Internal Error" from the server.
01.08.33 #       <amiconn> hi again
01.09.15 #       <PaulS> (Oo.. Hi LinusN!  How's the River hangin'? :-)
01.10.13 #       <LinusN> PaulS: i think the web server is confused, and tries to run the script as a cgi
01.10.22 #       <LinusN> cool exploit!
01.10.37 #       <LinusN> change the extension
01.11.41 #       <PaulS> Oh, BTW, LinusN, you need an A0 pin on that LCD display pinout, basically the Command/Data switch.
01.14.30 #       <PaulS> Shweet.. Now I'll fixeup the links
01.16.49 Join    webguest00 [0] (~524664e6@labb.contactor.se)
01.17.00 Quit    _aLF (".")
01.17.53 Quit    webguest00 (Client Quit)
01.22.43 Quit    Headie (Read error: 54 (Connection reset by peer))
01.23.14 Join    Headie [0] (~hehe@fsto6.sto.sema.se)
01.23.39 #       <LinusN> PaulS: i know, i just don't know which yet
01.25.04 Quit    mecraw_ ("Trillian (http://www.ceruleanstudios.com)")
01.28.17 #       <PaulS> (More about A0) If you're using a scope to look at it, you'll find that the A0 signal goes active (high) for multple CS cycles during long data bursts.
01.28.45 #       <PaulS> ...at least that's my assessment from looking at the code.
01.31.49 #       <PaulS> The CS is driven by the ColdFire internals, and the A0 is driven by GPIO, and they just leave A0 high during the course of a data burst.
01.37.58 #       <LinusN> hmmm, tracing with a logic analyzer, and it doesn't make any sense...
01.46.29 #       <LinusN> anyway, i gotta sleep now, cu around
01.46.36 #       <midk> nite LinusN 
01.46.41 Part    LinusN
01.48.12 #       <PaulS> Awww... He left, and I had more suggestions..  Aie well.
01.48.26 #       <midk> suggest them now, there are logs
01.50.44 #       <PaulS> Well, if he's using a analyzer, he should just trigger on one of the control words like 0xB1, and follow the trace forward.  The B1 byte should have A0 inactive.  The next byte should have A0 active, and the next byte will be a 0x13 with A0 inactive again.'
01.52.30 #       <PaulS> From a software point of view, though, I'm not sure this is very important, since we already know where (which GPIO pin, what register address) A0 is and what it does.
02.06.27 Join    _Headie [0] (~hehe@fsto6.sto.sema.se)
02.06.28 Quit    Headie (Read error: 54 (Connection reset by peer))
02.09.55 #       <PaulS> Anyways, I'm off as well.  Later, folks.
02.10.47 #       <midk> later
02.11.39 Quit    PaulS ("CGI:IRC")
02.27.49 Join    Headie [0] (~hehe@fsto6.sto.sema.se)
02.27.49 Quit    _Headie (Read error: 54 (Connection reset by peer))
02.41.53 Join    bagawk [0] (Lee@ACC71881.ipt.aol.com)
02.45.50 Quit    amiconn (" pow")
02.48.37 ***     Saving seen data "./dancer.seen"
03.25.24 Quit    gromit` (Remote closed the connection)
03.38.06 Join    gromit`` [0] (~gromit@ALagny-151-1-22-167.w83-114.abo.wanadoo.fr)
03.38.06 Quit    bagawk (Read error: 104 (Connection reset by peer))
03.41.46 Join    BC [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com)
04.05.15 Part    BC
04.48.38 ***     Saving seen data "./dancer.seen"
05.38.19 Quit    MrMoo (Read error: 110 (Connection timed out))
05.51.58 Join    maikeul [0] (~gromit@ALagny-151-1-27-251.w83-114.abo.wanadoo.fr)
05.57.54 #       <dwihno> bonjour
05.58.14 #       <dwihno> baguette avec saucisson et fromage pour moi, s'il vous plait
06.02.14 Quit    gromit`` (Read error: 110 (Connection timed out))
06.12.39 Quit    scott666_ ("i'll be back...eventually...")
06.13.18 Join    flabat [0] (~f@pcp09993805pcs.narlington.nj.comcast.net)
06.13.44 #       <flabat> i just want to say : thank you!
06.14.36 #       <flabat> any developers online?
06.15.57 #       <midk> me.. somewhat
06.16.50 #       <flabat> i just installed rockbox in my studio20, upgrade the hdd to 80gb
06.17.02 #       <flabat> this is awesome software
06.17.54 #       <midk> :)
06.19.40 #       <dwihno> 80gb? nice
06.20.24 #       <dwihno> does the studio have a 2 line charcell or a lcd?
06.20.29 #       <dwihno> I never got the hang of that
06.21.16 #       <midk> charcells
06.21.25 #       <dwihno> :/
06.21.38 #       <dwihno> then flabat is missing the lcd ride :(
06.23.07 #       <midk> :\ yeah
06.23.17 #       <dwihno> the best improvement, imho
06.23.26 #       <flabat> yes
06.23.31 #       <flabat> 2 lcd lines
06.23.58 #       <flabat> whats the lcd ride?
06.24.27 #       <midk> bitmap lcd: ~8 lines, depending on font you're using
06.24.31 #       <midk> graphics, etc
06.24.38 #       <midk> jpeg viewer, video player
06.24.53 #       <flabat> no, just text on the studio 20
06.24.59 #       <midk> right
06.25.06 #       <midk> the bitmap lcd on the recorders does the above
06.25.09 #       <flabat> no money for that
06.25.23 #       <dwihno> but you have money for a 80 gbyte disk ;)
06.25.32 #       <midk> i recall they were about the same price
06.25.49 #       <flabat> this was a unit with bad hard drive and the hard drive i got it for free
06.25.54 #       <dwihno> ah, okay
06.25.59 #       <dwihno> freebies for all! :)
06.26.03 #       <midk> cool cool :)
06.26.04 #       <flabat> so is a 80gb mp3 player for free
06.27.28 #       <midk> both the player and hard drive were free
06.27.30 #       <midk> ?
06.27.33 #       <flabat> yes
06.27.46 #       <midk> certainly not bad
06.28.56 #       <flabat> and with the firmware update even better, the original firmware is really bad
06.29.37 #       <dwihno> flashing the firmware is also great
06.29.51 #       <dwihno> decreasing from a 15 sec boot time to ~1 sec
06.30.00 #       <flabat> is not dangerous
06.30.17 #       <dwihno> Should not be if you know what you are doing
06.30.49 #       <dwihno> Also, flashing the so-called rombox frees an additional ~160 kbyte for the mpeg buffer
06.31.03 #       <flabat> mmm, i can wait 15 secs i guess
06.31.40 #       <flabat> so whats the benefits with thw buffer
06.32.09 #       <dwihno> I've read something about a 4% runtime increase
06.32.47 #       <midk> erm
06.32.49 #       <flabat> with the old player also
06.32.52 #       <midk> can't do rombox/flashing on player
06.32.58 #       <dwihno> midk: oh.
06.33.01 #       <flabat> ah
06.33.05 #       <dwihno> midk: Well, didn't know that :)
06.33.07 #       <midk> :)
06.33.11 #       <dwihno> midk: Another reason for getting the recorder ;)
06.33.37 #       <midk> dwihno, high five :]
06.33.40 #       * midk high fives
06.33.47 #       * dwihno high fives
06.33.50 #       <dwihno> \o/
06.34.09 #       <midk>   o
06.34.11 #       <midk>  / \
06.34.13 #       <midk> :)
06.34.40 #       <dwihno> So, what do you think about rockbox on ihp?
06.34.49 #       <dwihno> will it see the light of day?
06.34.54 #       <midk> sounds very interesting actually
06.35.02 #       <midk> hmm. it will take a while but i think they can do it
06.36.37 #       <dwihno> I will never doubt any project with the team members Zag/Bag/Lin
06.37.10 #       <midk> same reasoning here :)
06.37.27 #       <midk> i definitely don't doubt that if they want to they could do it.. and i think it would be very cool to have that running
06.37.38 #       <dwihno> true
06.37.39 #       <midk> instead of it dying out with the old archos series it could live on in the newer ihp models
06.38.13 #       <dwihno> A successful port on the ihp will open the doors, I think
06.38.53 #       <dwihno> and perhaps make the iriver guys uncomfortable
06.39.13 #       <dwihno> I guess it's not all sugar and cake
06.39.22 #       <dwihno> it's salt and vinegar too
06.39.27 #       <midk> they're cool imo.. they replace units basically no matter how they broke down
06.39.29 #       <flabat> ok guys, thanks again and good night
06.39.35 #       <dwihno> nightie
06.39.40 #       <midk> their firmware/support isn't bad compared to most companies
06.39.41 #       <midk> night
06.39.49 Part    flabat
06.41.10 #       <dwihno> It's a tough market, so I guess their high prices perhaps increases the support and software divisions of the company
06.41.36 #       <midk> they are relatively high priced, true
06.41.44 #       <midk> but nice hardware/abilities make up for it
06.41.57 #       <dwihno> yup
06.42.00 #       <midk> fm tuner, 320kbps cbr recording, optical in/out, nice large lcd, etc
06.42.04 #       <dwihno> they use 2.5" or 1.8"? Can't remember
06.42.27 #       <dwihno> Did you see the screenshot Zagor showed yesterday?
06.42.28 #       <midk> 1.8 i believe
06.42.32 #       <midk> yeah, of the sim?
06.42.34 #       <midk> that was really cool
06.42.35 #       <dwihno> yeah
06.42.38 #       <midk> and my clock was in it of course :)
06.42.44 #       <dwihno> it was?
06.42.44 #       <dwihno> hm
06.42.45 #       <midk> advertisement is good
06.42.48 #       <dwihno> Didn't see that :)
06.42.49 #       <midk> the filename at least
06.42.52 #       <midk> :)
06.42.58 #       <dwihno> heh
06.43.19 #       <dwihno> Using the prop font, most titles will fit the screen
06.44.35 #       <midk> yeah, that is really cool
06.45.54 #       <dwihno> My first archos' disk died a couple of weeks ago
06.46.10 #       <dwihno> Do you think rapid cold and heat changes can damage the disk?
06.46.16 #       <midk> :\ sorry about that. hopefully it's backed up?
06.46.22 #       <midk> it's possible, but doubtful...
06.46.28 #       <midk> if you keep it cool you may be able to boot it
06.46.49 #       <dwihno> I mean, swedish winters can be quite cold
06.46.53 #       <dwihno> (which sucks, btw)
06.47.04 #       <midk> i bet
06.47.17 #       <plok> iRiver has a 1.8 drive
06.47.23 #       <midk> so.. it was in the snow then you grabbed it and put it in the oven to dethaw it? :)
06.47.32 #       <dwihno> haha :)
06.47.39 #       <dwihno> thanks plok
06.47.56 #       <dwihno> I always keep backups
06.48.06 #       <midk> good
06.48.06 #       <dwihno> since I had a disk failure a couple of years ago
06.48.09 #       <midk> good boy.
06.48.17 #       <dwihno> Lost a ton of pre-2k sourcecode
06.48.20 #       <midk> yeah, i had a disk failure. no, i don't back up.
06.48.22 #       <midk> :)
06.48.40 ***     Saving seen data "./dancer.seen"
06.48.50 #       <dwihno> Including a rather nice VESA2 engine (first time I ever read docs to accomplish anything) :)
06.49.16 #       <midk> hmm. well, that sucks, but i guess you learned a lesson
06.49.22 #       <dwihno> yup
06.49.30 #       <midk> and just remember, it was destined to happen.
06.49.40 #       <midk> well, no, if you would have backed up it would have been avoided. ;)
06.50.20 #       <dwihno> The great giant fork in the sky has already foreseen my future :)
06.50.37 #       <midk> you sure that's not a spork? ;p
06.50.58 #       <dwihno> :)
06.53.44 #       <dwihno> yum
06.53.46 #       <dwihno> chocolate candy
06.54.07 #       <midk> yum, chocolate covered raisins.
06.54.29 #       <dwihno> yuck :P
06.54.29 #       <dwihno> :)
06.54.35 #       <dwihno> those taste like...
06.54.40 #       <dwihno> chocolate covered raisins :P
06.54.43 #       <midk> haha. :)
06.59.11 Join    LinusN [0] (~linus@labb.contactor.se)
06.59.20 #       <dwihno> Welcome back!
06.59.24 #       <LinusN> thx
06.59.31 #       <dwihno> We were busy praising the project ;D
07.00.56 #       <LinusN> :-)
07.01.05 #       <midk> haha! yeah. :)
07.01.24 #       <midk> i recall something about a spork too.
07.01.35 #       <dwihno> it was a FORK goddamnit! :)
07.02.01 #       <dwihno> I actually wrote an ultra light encryption thingie which I named "sporkel"
07.02.02 #       <midk> spork? fork? fillet knife? what's the difference.
07.02.05 #       <midk> :]
07.02.28 #       <midk> when i was trying to save tetris high score to disk i had to have an encrypted number to make sure it was unmodified..
07.02.44 #       <midk> the algorithm was something like "level*rows/blocks"
07.02.56 #       <midk> i just sort of scrapped the idea.
07.03.07 #       <dwihno> doesn't really matter
07.03.14 #       <dwihno> people who cheat sucks anyhow :)
07.03.23 #       <midk> yeah, that's it
07.04.02 #       <dwihno> hmmm
07.04.13 #       <dwihno> It would be really swell if I could make windows start my processes a bit different
07.04.30 #       <midk> hm? how?
07.04.39 #       <dwihno> disk i/o intense applications would've been given lower priority
07.04.50 #       <midk> bootvis, if it works, is great.
07.05.02 #       <midk> i used it once a while back.. it shaved ~15s off my booting time
07.05.03 #       <dwihno> bootvis?
07.05.24 #       <midk> it analyzes which drivers are loaded when, how long etc, then rearranges the order and stuff to make it quicker
07.05.32 #       <midk> yeah.. google for it, ms took it off their site
07.05.33 #       <dwihno> aaah... cool stuff!
07.06.17 #       <dwihno> wonder why
07.06.23 #       <dwihno> xp still boots quite fast
07.06.53 #       <midk> yeah, it just went faster for me :)
07.06.59 #       <midk> it overlaps some and stuff
07.07.03 #       <midk> loading earlier
07.07.05 #       <midk> not really sure.
07.10.09 #       <dwihno> I read something about being able to replace some files on win2k with the winxp equivalents to increase boot time
07.11.07 #       <midk> hmm
07.11.10 #       <midk> wiat, to increase?
07.11.11 #       <midk> wait*
07.11.55 #       <dwihno> wups
07.11.59 #       <dwihno> decrease ;)
07.12.01 #       <dwihno> hehe
07.12.10 #       <dwihno> "I think my computer runs too fast! I need to slow it down!" :)
07.12.17 #       <midk> :)
07.12.22 #       <dwihno> That reminds me of the turbo buttons on those old 486 machines
07.12.32 #       <midk> i never understood the purpose.
07.15.54 #       <LinusN> easy, many programs couldn't handle the extra speed, like Tetris for example
07.16.10 #       <LinusN> so you had an option to run at a compatible speed
07.16.12 #       <midk> tetris?!
07.16.15 #       <midk> TETRIS?!
07.16.26 #       <dwihno> what's with your tetris obsession, midk? :)
07.16.35 #       <midk> tetris obsession?!
07.16.38 #       <midk> TETRIS obsession?~
07.16.40 #       <midk> :)
07.16.55 #       <LinusN> ever tried to run the original PC version of tetris on a modern pc?
07.17.14 #       <midk> i imagine it would occur such like that as... er... no.
07.17.33 #       <LinusN> the timing is done with delay loops
07.17.47 #       <LinusN> so it runs faster on faster pc:s
07.18.06 #       <midk> hmm.
07.18.07 #       <midk> well....
07.18.10 #       <midk> hmm.
07.18.42 #       <dwihno> Yay! Firefox 0.10 is out!
07.18.50 #       <dwihno> I like Firefox and Thunderbirds.
07.18.51 #       <dwihno> s-
07.18.52 #       <dwihno> -s
07.19.17 #       <midk> 1.0 you mean.
07.19.38 #       <midk> and it's a preview release, not official 1.0,
07.19.43 #       <midk> and it's been out for about 2 days. :)
07.21.59 #       <dwihno> wuups
07.22.06 #       <dwihno> Well, I'm living under a rock, okay?! :)
07.24.32 #       <midk> yeah, i know.
07.24.33 #       <midk> ;)
07.25.35 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
07.26.31 #       <dwihno> time to test this stuff
07.26.44 #       <midk> WHICH STUFF?!
07.30.09 #       <dwihno> Just a plain reboot
07.30.47 #       <midk> hm, ok.
07.30.55 #       <midk> permission granted.
07.30.56 #       <midk> :)
07.31.49 #       <midk> bedtime anyways, nite
07.33.03 #       <dwihno> nite
08.41.56 Quit    Hadaka (Read error: 60 (Operation timed out))
08.48.41 ***     Saving seen data "./dancer.seen"
08.54.14 Join    [av]bani [0] (~goemon@washuu.anime.net)
08.55.40 Part    LePoulpe303
08.57.35 #       <[av]bani> no dead ihp's yet?
08.59.57 #       <[av]bani> re: rng
09.00.18 #       <[av]bani> you can collect entropy from user button presses and ide interrupt timing
09.00.27 #       <[av]bani> save it when you shutdown and restore when you boot back up
09.00.32 Join    Zagor [242] (~bjst@labb.contactor.se)
09.03.44 #       <[av]bani> http://forum.iriverlounge.de/viewtopic.php?t=196
09.03.50 #       <[av]bani> any idea wtf that whine is about?
09.07.56 #       <Zagor> they got sour when we quoted information from their forum in our wiki
09.07.56 #       <Zagor> we gave proper credit and references, but they still didn't like it
09.07.57 #       <Zagor> so I removed the information again
09.08.04 Join    Fusen [0] (~Fusen@fusen.user)
09.08.08 #       <Zagor> but that wasn't enough either!
09.08.18 #       <Zagor> so I gave up and ignored them
09.08.54 Part    Fusen
09.10.50 #       <LinusN> [av]bani: we have no rng entropy problems in rockbox
09.21.38 #       <[av]bani> re: an ihp to mangle
09.22.00 #       <[av]bani> maybe start a donation pool colecting funds for a sacrificial ihp-120
09.22.15 #       <[av]bani> anyone who donates >$10 wil get early access to rockbox beta testing
09.22.17 #       <[av]bani> etc
09.22.21 #       <LinusN> we can use the regular donation fund
09.22.25 #       <Zagor> we have a donation fund already. it just feels bad to buy a brand new box and destroy it...
09.22.44 #       <[av]bani> cool
09.22.59 #       <[av]bani> well, did you have to destroy any archos'en ?
09.23.13 #       <Zagor> no, since they didn't use bga
09.24.37 #       <Zagor> that was fast :)
09.24.40 #       <[av]bani> ah, did bdm wiggler come out of the fund?
09.24.44 #       <Zagor> yes
09.24.48 #       <[av]bani> yey
09.25.13 #       <[av]bani> that works :)
09.25.21 #       <Zagor> :)
09.25.39 Join    webguest46 [0] (~a9cfc25d@labb.contactor.se)
09.26.14 Join    Naked [0] (naked@naked.iki.fi)
09.26.24 Nick    Naked is now known as Hadaka (naked@naked.iki.fi)
09.27.43 Quit    webguest46 (Client Quit)
09.29.23 #       <[av]bani> ah so lcd is parallel after all
09.29.25 #       <[av]bani> that is good :)
09.29.27 #       <LinusN> yup
09.29.56 #       <LinusN> i hooked up my logic analyzer yesterday, but didn't get any wiser, will work some more on it
09.30.14 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
09.30.39 #       <[av]bani> i imagine many lcds even from different vendors share similar command sets
09.31.07 #       <[av]bani> since companies may want to multiple source parts
09.33.04 Join    pillo [0] (~trillian@navlab03.dei.unipd.it)
09.33.54 Join    PaulS [0] (~437e19f6@labb.contactor.se)
09.35.33 #       <PaulS> Hullo guys.
09.35.37 #       <Bagder> 'lo
09.35.38 #       <[av]bani> When I hit track-forward it sends any of a few strings: "1134-1", "1279", "134-2A", "13589". None of the strings are terminated by whitespace/cr/nl. I haven't yet figured out the rhyme or reason for each, although I think one of these means "went to next album". At startup I got a "674".
09.35.54 #       <[av]bani> if they code like me, each digit probably indicates a function/routine
09.36.20 #       <Zagor> [av]bani: are you talking about the remote?
09.36.32 #       <[av]bani> no, thats re: the rs232 output
09.36.41 #       <Zagor> on the rx/tx pads?
09.36.44 #       <[av]bani> yes
09.37.01 #       <Zagor> ok. free debug output :)
09.37.08 #       <PaulS> [av]bani -- that's correct.  I've seen where in the code that lives, and I know where the "putc" routine is.
09.37.10 #       <[av]bani> you havent kept up with the wiki?
09.37.21 #       <Zagor> apparently not :)
09.37.30 #       <[av]bani> pauls, my guesses have been good so far :)
09.37.57 #       <[av]bani> 1 is probably "main"
09.38.01 #       <[av]bani> the rest, shrug
09.38.22 #       <[av]bani> A maybe ata :)
09.40.24 #       <LinusN> maybe it's similar to rockbox's panic error codes
09.40.33 #       <PaulS> "1 is probably 'main'" -- not quite.  It's debugging different spots in the track access routines.  The numbers are pretty much linear 0-9 in the code, and depending on the path through the branches different digits get triggered.
09.41.45 #       <[av]bani> probably something which gave them a lot of trouble
09.41.52 #       <[av]bani> so they put in debug for it
09.41.58 #       <[av]bani> though they never took it out, interesting
09.45.09 #       <plok> Is there anything wrong with rockbox.haxx.se, or is it just my web proxy?
09.45.21 #       <[av]bani> just you
09.45.34 #       <PaulS> In the 1.40 image, putc is 0x2CBE0.  The byte pushed on the stack before the JSR is the ASCII byte that'll spit out the TX.
09.45.34 #       <[av]bani> :)
09.47.18 #       <PaulS> The site has been slow for me, but I don't have a lot of context.
09.48.27 #       <LinusN> it should be faster now
09.51.41 #       <PaulS> The other thing they failed to take out was all the calls to debug prints.  They ifdeffed out the actual content of the debug print, but the strings are there and the call to the prints are there.  There are different kinds of debug print functions -- each takes a string arg, but some act like printf("%s %d"), while others are string-only.
09.53.17 #       <[av]bani> sounds like someone forgot to remove -DDEBUG :)
09.53.26 #       <[av]bani> or theyre too noobish to have #ifdef'd it
09.53.52 #       <PaulS> Don't complain. :-)
09.54.06 #       <[av]bani> tbh the iriver firmware is pretty bad, i suspect most of their code is purchased 3rd party that they threw together
09.54.25 #       <[av]bani> well i complain when _I_ know i do better
09.54.27 #       <[av]bani> :P
09.54.42 #       <dwihno> [av]bani: from what I've heard, the iriver firmware is supposed to be quiote good
09.55.07 #       <plok> hmm, I just tried building the cross compiler GCC again (with --enable-languages=c only!) and I'm getting the same error again
09.55.26 #       <PaulS> But... but... those debug strings are going to tell me how the whole thing works!
09.55.26 #       <plok> dwihno: The iRiver firmware could be a LOT better, so easily!
09.55.33 #       <Zagor> plok: you need to use the same --prefix for binutils and gcc
09.55.54 #       <plok> Zagor I'm sure that I did. I get this error
09.56.07 #       <dwihno> If there was rockbox for iriver, I would have to buy one just for the cause of it :)
09.56.32 #       <plok> insn-emit.c:8549: Internal compiler error in simplify_subreg, at simplify-rtx.c:2452
09.56.48 #       <Zagor> wow. I haven't seen that problem before.
09.57.01 #       <Zagor> what version is your native compiler?
09.57.08 #       <plok> gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
09.57.15 #       <Zagor> should be fine
09.57.31 #       <dwihno> have red hat stopped their custom gcc patching?
09.57.46 #       <Zagor> no idea. don't they patch everything?
09.57.50 Join    MrMoo [0] (~me@194.152.87.150)
09.58.00 #       <plok> I'll blow it all away and start from scratch again just to make sure
09.58.00 #       * Zagor uses debian
09.58.08 #       <[av]bani> redhat hacks everything
09.58.22 #       <[av]bani> tbh what they patch was generally broken to begin with though
09.58.37 #       <[av]bani> so its generally not worse :)
09.59.20 #       <Bagder> I disagree with that description 
09.59.26 #       <dwihno> Zagor: probably... I guess you should use one of the "vanilla" distrubitions... (are there any left?)
09.59.31 #       <Bagder> but nevermind
10.00.35 #       <[av]bani> gentoo
10.00.38 #       <[av]bani> is the closest
10.00.52 #       <Bagder> debian is the coolest ;-)
10.01.04 #       * Bagder joins the distro wat
10.01.08 #       <Bagder> war
10.02.20 #       <plok> Maybe I should try building on windows instead...
10.02.25 #       <plok> </flame>
10.03.28 #       <pillo> I use gentoo too ;)
10.03.43 #       <pillo> hi all, sorry to say hello this way but couldn't resist ^_^
10.04.03 #       <Zagor> :)
10.04.22 #       <Zagor> plok: write a doc if you succeed ;)
10.04.28 Part    [av]bani
10.04.46 #       <pillo> I'm watching this channel these days as I'm interested in the iriver port too, and hope to start contributing soon. 
10.05.37 Quit    ripnetUK ()
10.05.39 Join    webguest72 [0] (~a9cfc25d@labb.contactor.se)
10.06.22 #       <plok> Zagor: Sure :) Before or after I manage to build it with a c++ compiler?
10.06.42 #       <plok> I've rebuilt binutils from scratch and am rebuilding gcc now
10.08.38 #       <LinusN> plok: don't bother, we don't need a c++ compiler
10.10.47 #       <plok> I was joking, I got the messgae yesterday :)
10.11.21 #       * dwihno uses slackware
10.11.29 #       <dwihno> Until I get my 250 gig disk working under FreeBSD ;D
10.11.47 #       <dwihno> It's some kind of fat32 file system issue
10.12.28 Quit    Bagder ("Leaving")
10.12.43 #       <plok> grr... same error again :(
10.13.55 #       <Zagor> weird
10.14.11 #       <Zagor> maybe we should tar up our build
10.15.12 #       <plok> I have another linux box with an earlier version of redhat. I could try that one first
10.15.20 #       <LinusN> dwihno: 250gig disk, are you sure that your ATA controller can handle that?
10.15.27 #       <plok> All we have at work are redhat machines
10.16.02 #       <Zagor> the rockbox build server is currently an old redhat too
10.16.16 Quit    webguest72 ("CGI:IRC (EOF)")
10.17.09 #       <Zagor> http://rockbox.haxx.se/sh-gcc-3.3.4.tar.bz2  (22MB)
10.17.53 #       <plok> thx!
10.18.07 Quit    PaulS ("CGI:IRC (EOF)")
10.18.39 #       <Zagor> uh, bad idea to restart apache right now. sorry :)
10.19.06 #       <plok> I was going to say, I only got 19k?!
10.19.13 #       <plok> :)
10.28.18 #       <plok> This other machine is so slow :(
10.42.08 #       <dwihno> LinusN: I connect it using USB...
10.42.36 #       <dwihno> LinusN: Works flawlessly using Wintendo and Linux... The fat32 driver for FreeBSD has some limits.
10.42.57 #       <Zagor> boo :)
10.43.09 #       <dwihno> Perhaps you should patch it, Zagor? ;)
10.43.19 #       <dwihno> my co-worker brought senap!
10.43.27 #       <dwihno> Guess who's gonna have ärtsoppa deluxe for lunch?
10.48.42 ***     Saving seen data "./dancer.seen"
10.53.29 Part    pillo
10.54.58 #       <plok> Cool, I have the archive. Thanks Zagor!
10.55.03 #       <plok> later
11.36.18 Join    ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk)
11.37.39 Join    amiconn [0] (~jens@pD9E7F596.dip.t-dialin.net)
11.45.46 #       <Headie> Ärtsoppa and pannkaka.. Yummie
11.57.29 Join    Lynx_ [0] (lynx@134.95.189.59)
12.11.30 Join    ashridah [0] (ashridah@dialup-a1-180.Melbourne.netspace.net.au)
12.23.44 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
12.32.20 #       <Bagder> Zagor: http://rockbox.haxx.se/dl.cgi?bin=install is brokeb
12.32.24 #       <Bagder> broken
12.32.38 #       <Bagder> and the source one too
12.32.47 #       <Bagder> I bet you've removed my symlinks
12.33.04 #       <Bagder> or something
12.34.21 #       <Zagor> checking...
12.35.23 #       <Bagder> the script checks in the dir named as the 'bin' parts says
12.35.48 #       <Zagor> hmm, those dirs don't exist
12.35.52 #       <Bagder> no
12.35.55 #       <Bagder> I hade them as symlinks
12.36.00 #       <Bagder> made
12.36.05 #       <Bagder> ln -s . install
12.36.09 #       <Zagor> i haven't removed them afaik
12.36.15 #       <Bagder> weird
12.36.17 #       <Bagder> or
12.36.25 #       <Bagder> perhaps the auto-remover removes them...
12.36.29 #       <Bagder> I'll check
12.37.21 #       <Bagder> oh yes it does! 
12.37.22 #       <Bagder> hehe
12.37.24 #       <Bagder> how silly
12.38.16 #       <Bagder> btw, should we keep files longer now when they're no longer fill the daily-build page?
12.38.40 #       <LinusN> sure
12.38.45 #       <Zagor> why not
12.38.54 #       <Zagor> a month perhaps
12.39.02 #       <Bagder> ok, increasing to 30 days
12.40.13 #       <Bagder> currently the files use 29MB for 6 days
12.41.34 #       <Zagor> currently we have 7.5G free :)
12.41.46 #       <Bagder> and the auto-cvs-build dir takes 110MB
12.42.14 #       <Bagder> room to grow indeed! ;-)
12.48.44 ***     Saving seen data "./dancer.seen"
12.55.08 Join    dwihno_ [0] (~dw@81.8.224.89)
12.55.08 Quit    dwihno (Read error: 104 (Connection reset by peer))
13.22.04 Quit    AciD (Read error: 60 (Operation timed out))
13.25.23 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
13.28.49 #       <amiconn> hi Jörg!
13.30.21 #       <amiconn> [IDC]Dragon: Yesterday I digged a bit into the beginnings of an mmc driver. However, I have some questions you could help me to solve.
13.31.52 #       <[IDC]Dragon> hi jens
13.32.01 #       <[IDC]Dragon> standby, I'm busy
13.33.15 #       <amiconn> Anyway, here are the questions. No need to hurry though.
13.34.03 #       <amiconn> (1) When not in usb mode, does the SCK1 output continuously output the clock (~1.5 MHz) or bursts?
13.34.27 #       <amiconn> (2) I suspect that there is actually something connected to PA13. Could you check this?
13.42.14 Quit    ashridah ("Client exiting")
14.03.02 Join    ashridah [0] (ashridah@dialup-a1-180.Melbourne.netspace.net.au)
14.10.40 Join    R3nTiL [0] (~zorroz@197-250-30-217.kgts.ru)
14.23.37 Join    lImbus [0] (~manuel@kernel.cycos.net)
14.31.07 #       <[IDC]Dragon> Jens: now is better
14.31.38 #       <[IDC]Dragon> (1) The Archos firmware generates burst, longer than 1 byte
14.32.24 #       <[IDC]Dragon> (2) I don't know about PA13, haven't found a connection yet. In which context is this used?
14.33.20 #       <[IDC]Dragon> Bagder: I've pushed some OndioFM pictures in your upload area, since my email wasn't working this morning.
14.34.09 #       <Bagder> thanks
14.36.45 #       <[IDC]Dragon> conveniently made them the size used on your page
14.36.52 #       <Bagder> I noticed
14.36.58 #       <[IDC]Dragon> :)
14.37.20 #       <[IDC]Dragon> except for the big one, of course
14.37.22 #       <Bagder> I'll make use of them when we start providing daily builds
14.37.35 #       <[IDC]Dragon> yes, no hurry
14.38.14 #       <Bagder> there here now: http://rockbox.haxx.se/ondio/
14.38.18 #       <Bagder> they're
14.38.43 #       <[IDC]Dragon> maybe rename them to OndioFM_xxx
14.38.51 #       <[IDC]Dragon> I forgot to do so
14.39.02 #       <[IDC]Dragon> or whatever the naming convention is
14.39.05 #       <Bagder> that whole dir is only temporary
14.39.19 #       <Bagder> I'll rename and fix when the time comes
14.39.32 Join    JoeBorn [0] (~41d6673c@labb.contactor.se)
14.39.42 #       <[IDC]Dragon> oh, they seem to be progressive jpeg
14.39.48 #       <[IDC]Dragon> did I do that?
14.40.00 #       <Bagder> yes
14.40.31 #       <[IDC]Dragon> sorry
14.40.37 #       <Bagder> it doesn't matter
14.44.23 Join    webguest88 [0] (~da458715@labb.contactor.se)
14.48.48 ***     Saving seen data "./dancer.seen"
14.50.07 #       <[IDC]Dragon> amiconn: have to reboot, see you
14.50.16 #       <[IDC]Dragon> (and see above)
14.50.22 Part    [IDC]Dragon
14.51.13 Quit    Bagder ("Leaving")
14.51.57 #       <JoeBorn> hello everyone, does anyone mind talking about hardward generally for a bit?
14.52.12 #       <Zagor> not a bit
14.52.42 #       <JoeBorn> well, I guess as most of you probably know, we've made some mistakes in some of our choices along the way :(
14.53.03 #       <webguest88> is it possible that I use my JukeBox 20 with the Jukebox 5000-6000 software?
14.53.12 #       <JoeBorn> in going forward, I'm just looking to make sure that we don't keep repeating those
14.53.57 #       <Zagor> webguest88: yes
14.54.21 #       <webguest88> okay, thanks
14.54.43 #       <Zagor> JoeBorn: we'd like that too :)
14.55.15 #       <JoeBorn> I guess I'll start with a couple questions.  It's obvious that the ARM cores have the Gcc tools and the benefit of good support generally
14.55.24 #       <LinusN> yup
14.55.26 #       <Zagor> (for those who don't know, JoeBorn is talking about the Neuros player)
14.56.02 #       <JoeBorn> but it's also obvious that the DSP side is of great interest to developers and it seems that these have often been less open, 
14.56.19 #       <JoeBorn> what's your take on availability of tools for the DSPs?
14.56.22 #       <Zagor> yes, that has been a problem
14.56.40 #       <JoeBorn> what processor does the iRiver use?
14.56.43 #       <Zagor> well gcc supports some dsps, not sure exactly which though
14.56.46 #       <Zagor> coldfire 5249
14.57.05 #       <Zagor> with an EMAC, so not a full DSP but still enough for fast signal processing
14.57.43 #       <JoeBorn> and those have complete support tool-wise?
14.57.49 #       <LinusN> nope
14.58.01 #       <LinusN> not that i know of
14.58.13 #       <Zagor> the EMAC needs to be assembly-programmed, but being very restricted (just a few instructions) it's not a problem
14.58.33 #       <JoeBorn> ahh!
14.58.47 #       <Zagor> the coldfire core itself is quite well supported though, since it builds on the m68k core
14.59.39 #       <JoeBorn> so have you guys researched processors much or you pretty much just looked at the handful of players out there and then looked at the processors for those?
14.59.57 #       <Zagor> the latter
15.00.14 #       <Zagor> although we work with stuff like this for a living, so we know a lot of different cpus
15.00.20 #       <JoeBorn> have you looked at any of the TI products?
15.00.27 #       <LinusN> we have of course worked on quite a few cpu's, but not in the scope of the rockbox project
15.00.42 #       <LinusN> no, not ti
15.00.51 #       <Zagor> yes, when I was looking at the archos multimedia players. TI is notorious about hiding documentation though so it quickly gets boring.
15.01.37 #       <JoeBorn> TI is appealing for us, because we have so much code written for it already.
15.02.03 #       <Zagor> I can understand that
15.02.13 #       <JoeBorn> FM stereo algorithms, etc, etc.
15.02.20 #       <Zagor> but their attitude to non-commercial development is rather hostile
15.02.33 #       <LinusN> i'd stay away from the ti stuff
15.02.36 #       <JoeBorn> so how much of an impediment is that "hostility"?
15.02.48 #       <LinusN> the lack of docs is a real problem
15.02.51 #       <Zagor> a rather big one. we simply cannot get docs.
15.02.52 #       <JoeBorn> where does that hostility stem from?  what form?
15.03.14 #       <JoeBorn> oh, and the docs are all protected so we can't distribute them either, I assume?
15.03.31 #       <Zagor> if I ask for docs, I get the response "how many chips are you planning to buy?"
15.03.34 #       <Zagor> yes, generally
15.03.50 #       <JoeBorn> funny you say that, we get that too.
15.04.12 #       <Zagor> yeah, but you can answer :)
15.04.25 #       <LinusN> that's the first signal that tells you to stay away
15.04.27 #       <JoeBorn> what about the gcc project to port to TI
15.04.37 #       <LinusN> don't hold your breath
15.04.55 #       <Zagor> i've only seen the sourceforge project page, but no content
15.04.55 #       <JoeBorn> you think it's just too difficult and big a project?
15.05.14 #       <JoeBorn> right, it clearly needs a push.
15.05.19 #       <LinusN> i think the TI secrecy will be a problem for that project as well
15.06.03 #       <JoeBorn> have any silicon manufacturers been particuliarly supportive?
15.06.06 #       <LinusN> as i see it, they don't deserve the gcc port
15.06.13 #       <JoeBorn> or open?
15.06.40 #       <Zagor> motorola is pretty open in that all their docs are available on their website
15.06.49 #       <Zagor> that's all we ask
15.06.55 #       <JoeBorn> sure.
15.07.10 #       <LinusN> and one should also choose a common architecture
15.07.13 #       <Zagor> i think others do that too, I just can't think of any names right now
15.07.30 #       <JoeBorn> what do you mean "common architecture?"
15.07.39 #       <LinusN> 68k, ppc, arm etc are very popular
15.07.48 #       <JoeBorn> oh, right.
15.07.53 #       <LinusN> so there are good tools for those
15.08.21 #       <Zagor> yes. the more popular a platform is, the better the tools are
15.09.04 #       <JoeBorn> so in a nutshell, on the DSP side, although there may not be an available compiler, you'd probably use assembly anyway.
15.09.14 #       <LinusN> and if you want to benefit from opening the source, virtually everyone should be able to compile and link the firmware
15.09.30 #       <Zagor> it depends. for the coldfire we use DSP since it's only a few instructions.
15.09.46 #       <Zagor> but for a case like yours where the entire system runs on a DSP I'd want C
15.09.53 #       <LinusN> s/dsp/assembler/
15.09.56 Quit    midk (Read error: 54 (Connection reset by peer))
15.09.59 #       <JoeBorn> sure, that makes sense
15.10.06 #       <Zagor> LinusN: right
15.10.13 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
15.11.06 #       <JoeBorn> but looking at some of your discussions, it seems clear that you were facing resource issues with the Archos and that's one of the big reasons for the move?
15.11.47 #       <JoeBorn> obviously some of these issues would still be there with a processor like we're currently using, perhaps not quite as severe, but still there.
15.11.58 #       <Zagor> well the archos is an old platform that is becoming obsolete. we wanted to follow the times and not stay lock in to a dying product.
15.12.02 #       <LinusN> well, they don't manufacture the archor jukebox anymore
15.12.15 #       <JoeBorn> right
15.12.28 #       <ashridah> Zagor: you do realise they don't manufacture the 1xx series anymore either, iirc.
15.12.30 #       <LinusN> and it's nice to have the codec in s/w
15.12.41 #       <ashridah> (iriver H1xx series i mean)
15.12.43 #       <Zagor> ashridah: really? interesting...
15.12.49 #       <LinusN> ashridah: :-)
15.12.53 #       <ashridah> Zagor: yeah, they're pretty much pushing the 3xx
15.12.59 #       <LinusN> of course
15.13.40 #       <Zagor> well the h100 isn't exactly hard to get yet anyway. the archos is.
15.13.46 #       <ashridah> true
15.14.09 #       <Zagor> but sure, we won't be able to stay with the h100 forever either
15.14.42 #       <LinusN> and it shouldn't be *that* hard to port to the 300, afaics
15.14.57 #       * ashridah nods
15.14.57 #       <JoeBorn> 3xx uses the same 5249?
15.14.59 #       <Zagor> if joe makes a good platform we can use, at least we'd know when it stopped being manufactured ;)
15.15.27 #       <Zagor> JoeBorn: as far as I know, yes
15.15.28 #       <LinusN> i believe the cpu is the same, yes
15.16.02 #       <JoeBorn> so what about the rest of the hardware.  I'm absolutely amazed that you guys can do so much without support from teh mfg.
15.16.19 #       <LinusN> lots of experience
15.16.23 #       <JoeBorn> you might have specs on the CPLD, but no information on the code, etc
15.16.36 #       <JoeBorn> how much of an impediment is that?
15.16.39 #       <Zagor> well one thing we've found useful is the separate usb/ata bridge. it means we don't have to write and debug a complex usb-storage driver.
15.16.52 #       <LinusN> well, all hardware must have public data sheets
15.16.56 #       <Zagor> it also means the disk always works, even if we fubar the firmware
15.16.58 #       <JoeBorn> right.
15.16.58 Quit    webguest88 ("CGI:IRC (EOF)")
15.17.02 #       <Zagor> (nearly always... ;)
15.17.58 #       <Zagor> make sure you line up the MSBs and LSBs on your serial connections... :) (internal joke, archos players needs a lot of byte swapping)
15.18.40 #       <Zagor> parallell connection to the display, preferrably, for fast access
15.19.10 #       <JoeBorn> I'm not really a hardware engineer, I just play one on TV, inside Hw jokes will surely go over my head :(
15.19.43 #       <Zagor> brb
15.19.47 #       <JoeBorn> fast access for video? animation?
15.20.21 #       <LinusN> well, a fast lcd connection leaves more power for the codec
15.20.33 #       <JoeBorn> oh!  I get it
15.20.36 #       <LinusN> same goes for all peripherals
15.21.13 #       <LinusN> connecting the hard drive correctly, so you can use the internal DMA in the cpu (if any)
15.21.21 #       <LinusN> etc
15.22.09 #       <JoeBorn> no those are good tips. 
15.22.31 #       <LinusN> there are so many small details that can make a huge difference
15.22.40 #       <JoeBorn>  so, it's clear that you guys have been able to figure out most everything without manufacturer support, so besides just designing good HW, what else do you need from us?
15.23.01 #       <JoeBorn> (us meaning the manufacturer generally)
15.23.27 #       <LinusN> a dialog, and hardware to develop on
15.23.31 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
15.24.10 #       <JoeBorn> what about hardware tools, emulators and such?
15.24.39 #       <LinusN> if you choose your platform wisely, you may not need emulators
15.25.06 #       <LinusN> only a cheap BDM/JTAG wiggler
15.25.57 #       <LinusN> and the gnu debugger
15.26.53 #       <JoeBorn> what platforms support that?
15.27.24 #       <LinusN> at least arm and coldfire
15.27.27 #       <JoeBorn> what about the mp3 codec?  Do you have a source for that?
15.27.28 #       <LinusN> ppc
15.27.44 #       <LinusN> libmad is gpl
15.27.59 #       <LinusN> we will probably use it for the iriver
15.28.14 Join    Lynx [0] (lynx@134.95.189.59)
15.28.33 #       <LinusN> i don't know much about free realtime encoders though
15.28.56 #       <LinusN> we will probably have to do some "inhouse" developing for that
15.29.08 #       <JoeBorn> it seems like writing one is quiet an effort.
15.29.13 #       <Zagor> not the entire codec, just optimising an existing
15.29.56 #       <JoeBorn> when we asked monty about writing an Ogg encoder for our machine, he said he heard it took TI 3 man years to write their mp3 encoder
15.30.13 #       <Zagor> i can imagine
15.30.47 #       <Zagor> btw can I ask if the ogg codec he wrote for you is (or will be) released?
15.30.59 #       <JoeBorn> yes.
15.31.05 #       <Zagor> nice
15.31.26 #       <JoeBorn> I just haven't looked the contract, but I'm 99% sure from my recollection that it's fine.
15.31.36 #       <Zagor> ok
15.31.45 #       <JoeBorn> xiph wrote our codec for us.
15.32.07 #       <Zagor> i guessed that :)
15.32.31 #       <JoeBorn> but I'm 99% sure its actually just a BSD license and there's no problem.
15.33.04 #       <Zagor> yeah but it depends on the terms of the contract, as you say. with bsd you can choose to make the result proprietary.
15.33.26 #       <JoeBorn> so Zagor, what do you think you need from the manufacturer?
15.33.41 #       <JoeBorn> what are the impediments that you see?
15.33.43 #       <LinusN> loadza cash!
15.34.04 #       <Zagor> docs, mostly. and as linus said, a dialog with someone we can ask about stuff we can't figure out
15.34.11 Join    R3nTiL1 [0] (~zorroz@185-248-30-217.kgts.ru)
15.34.16 #       <Zagor> some development hardware, of course
15.34.17 #       <JoeBorn> well, you know we are a for profit company (at least trying to be) 
15.34.52 #       <LinusN> when i said "dialog", i also meant regarding the hardware design
15.35.00 #       <JoeBorn> but honestly supporting open source with some hardware is obviously a lot cheaper than hiring internal developers
15.35.43 #       <JoeBorn> well, this is that start of that dialog.
15.36.09 #       <Zagor> I just need to raise a warning flag here: you cannot depend 100% on us writing the firmware for you for free. we may not do it in the speed you want it, or with the features you'd like.
15.36.25 #       <JoeBorn> what about installed base?  I know that's an issue for you guys, and would be a disadvantage of anything we do, at least for the time being
15.36.46 #       <LinusN> relying on programmers that do it for free on their spare time isn't all that good
15.37.15 #       <JoeBorn> of course, what I'm imagining is doing our development with internal developers in an open environment
15.37.38 #       <Zagor> JoeBorn: ok, good. just wanted to avoid any misunderstandings
15.37.39 #       <JoeBorn> with support from outsiders as a bonus
15.37.46 #       <LinusN> sounds good
15.38.12 #       <JoeBorn> we've seen that in our own experience those issues.
15.38.22 #       <LinusN> basically, make the hardware like we want it, and we port rockbox to it -)
15.38.24 #       <JoeBorn> it's impossible to control.
15.38.38 #       <Zagor> installed base is obviously an issue, since we as a project are always looking for contributors and testers. if only a dozen people have the hardware it's not going to be as much fun.
15.39.15 #       <LinusN> on the other hand, if the hw is sexy, and the publicity is right, it could very well be a hit
15.39.21 #       <Zagor> absolutely
15.39.26 #       <JoeBorn> well, it won't be a dozen people (or we've got some other big issues)
15.39.54 #       <JoeBorn> yes, I think it could be a big hit and it's obvious that the things you want are the same things that other folks want too.
15.40.09 #       <JoeBorn> but it's going to be a new product from a small brand
15.40.11 #       <LinusN> not the ipod herd...
15.40.26 #       <Zagor> i think the xclef model of having both an 1.8" and a 2.5" player with similar hardware is a good idea to consider.
15.40.55 #       <Zagor> one small&sexy for the pocket and one which can fit huge 100gig drives, for the car or bag
15.40.58 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
15.41.00 #       <JoeBorn> just so you can have an 80GB  if you want?
15.41.03 Quit    R3nTiL (Read error: 110 (Connection timed out))
15.41.05 #       <Zagor> exactly
15.41.33 #       <JoeBorn> what about wireless?  does anyone care?
15.41.42 #       <LinusN> i dont
15.41.59 #       <JoeBorn> I'm referring to WiFi etc, not FM broadcasting
15.42.03 #       <LinusN> i know
15.42.22 #       <JoeBorn> anyone else have an opinion on that?
15.42.25 #       <Zagor> i don't think it's worth it having it built-in. those things are easy to add with external hardware.
15.42.53 #       <LinusN> btw, S/PDIF is a must imho
15.42.55 #       <Zagor> but I'm not pretending to "know the market"
15.43.02 #       <JoeBorn> now that's a very interesting point, what's the interface for external hardware?
15.43.25 #       <LinusN> actually, an ethernet connection might be c00l
15.43.57 #       <JoeBorn> CF is big
15.43.58 #       <LinusN> but i think usb2.0 is good enough
15.44.01 #       <Zagor> rio karma apparently has it
15.44.15 #       <Zagor> CF is a good interface
15.44.23 Quit    Lynx_ (Read error: 110 (Connection timed out))
15.44.24 Nick    Lynx is now known as Lynx_ (lynx@134.95.189.59)
15.44.31 #       <JoeBorn> but it adds considerable size
15.44.44 #       <LinusN> compared to what?
15.44.44 #       <Zagor> yes. i'm not sure the tradeoff is worth it.
15.45.44 #       <LinusN> the 2.5" version could have more "advanced" connectivity features, while the 1.8" version could have only USB
15.46.00 #       <Zagor> LinusN: sounds good
15.46.23 #       <Zagor> bluetooth!
15.46.25 #       * Zagor ducks
15.46.26 Quit    MrMoo (Read error: 104 (Connection reset by peer))
15.46.32 #       * Bagder swings for Zagor
15.46.34 #       <LinusN> the 2.5" version would be more like a portable music collection, much like i use my archos today
15.46.49 #       <JoeBorn> I take it you've already had the wireless conversation many times?
15.46.58 #       <LinusN> not really
15.47.24 #       <JoeBorn> oh it sounded like an inside joke
15.47.35 #       <LinusN> rockbox is not that much about developing hardware, we have to settle with what the player has
15.47.41 #       <Zagor> well bluetooth *is* an inside joke, isn't it? ;)
15.47.45 #       <LinusN> haha
15.48.07 #       <JoeBorn> I'm sorry to dominate the discussion, but one final question about licensing
15.48.20 #       <Zagor> don't worry, this is a very interesting discussion
15.48.30 #       <JoeBorn> good, thanks.
15.48.47 #       <LinusN> we'll kick you out when we find something else to talk about :-)
15.49.07 #       <JoeBorn> you've never been shy
15.49.09 Join    MrMoo [0] (~me@194.152.87.150)
15.49.36 #       <JoeBorn> so let's say we do what we're talking about and release a piece of hardware and do the development in an open environment
15.50.10 #       <JoeBorn> sourceforge or hosted internally, but with open version control, bugzilla, etc.
15.50.47 #       <JoeBorn> one part of our business model would be to ultimately license or OEM to other manufacturers
15.51.03 #       <JoeBorn> I know this is a pretty sensitive subject, but I have to bring it up.
15.51.16 #       <JoeBorn> so there are a couple ways for us to deal with this.
15.51.51 #       <JoeBorn> we can fork the code into a version where we're the copyright holder or we can do a dual license, etc.
15.52.07 #       <JoeBorn> any particular thoughts on this?  Does it make sense what I'm asking?
15.52.33 #       <LinusN> i see two issues, one about copyright and one about money
15.52.39 Quit    R3nTiL1 ()
15.53.25 #       <JoeBorn> I'd say that's right.
15.54.21 #       <Zagor> the question is how would you prevent other manufacturers from using the code unlicensed?
15.54.22 #       <JoeBorn> if money were no issue, then we could just release the code under BSD and contributors could contribute under that license 
15.54.40 #       <JoeBorn> but then why would anyone pay us?
15.55.15 #       <LinusN> i also see an issue with fellow developers contributing to the project
15.55.16 #       <JoeBorn> and essentially we'll be paying developers to develop code for all manufacturers to use for free.
15.55.39 #       <JoeBorn> and of course the same issue you've faced.
15.55.44 #       <LinusN> basically, "why should i contribute, what's in it for me?"
15.55.50 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
15.56.12 #       <JoeBorn> right, that's a great question.
15.56.15 #       <[IDC]Dragon> Hi again! (took a bit more than a reboot)
15.56.41 #       <Zagor> JoeBorn: there is an ethical dilemma in selling contributed code
15.56.51 #       <JoeBorn> yes.
15.57.04 #       <JoeBorn> so what's the solution?
15.57.38 #       <Zagor> I'm afraid I don't see one. Open Source and exclusive licensing doesn't mix well.
15.57.55 #       <Bagder> I don't think there's any shortcut. The source need to be "free enough" to attract hackers to it.
15.58.20 #       <LinusN> and then anyone can clone the hardware and run the code on it
15.58.23 #       <JoeBorn> well, that solution means forking the code into a plain old GPL
15.58.39 #       <Bagder> yes, if someone makes a clone of the hw, they get code for free
15.58.47 #       <Zagor> would licensing only the hardware design not be enough, you think?
15.58.59 #       <JoeBorn> I don't have any issue with anyone cloneing the hardware and running the code on it.
15.59.26 #       <JoeBorn> remember they'd have to adhere to the GPL themselves.  not many manufacturers would be willing to do that.
15.59.36 #       <Zagor> excellent point
15.59.37 #       <LinusN> true
16.00.00 #       <Bagder> and if they'd do, they'd cooperate on improving the code
16.00.10 #       <Zagor> everybody wins
16.00.37 #       <LinusN> except the company who has the most manufacturing costs, losing sales
16.00.38 #       <JoeBorn> eventually there will be a lot of hardware companies that will do that, but it will take time
16.00.55 #       <Zagor> LinusN: why?
16.01.05 #       <Zagor> oh, ok i get it
16.01.27 #       <Zagor> however cost is only one variable. marketing is a powerful thing.
16.01.29 #       <Bagder> ... and there's money to be made by the people who know the sw to write adaptions for new hw
16.01.50 #       <LinusN> ...and who might that be? :-)
16.02.24 #       <JoeBorn> Zagor: licensing HW might be enough, it depends how clever and unique or even *gasp* proprietary it is
16.02.59 #       <Zagor> JoeBorn: yeah and we (rockbox) of course don't want it to be proprietary at all...
16.03.11 #       <JoeBorn> I know
16.03.35 #       <Zagor> however do you see any problem with using the GPL, thus avoiding the "free clones" problem?
16.04.03 #       <JoeBorn> but if it's completely a commodity, just a version based off the reference design then obviously it's not going to be worth much.
16.04.31 #       <JoeBorn> if you have a clever patentented wheel, etc. with a cool design, then maybe
16.05.06 #       <Zagor> yes, design is very important. two devices with identical schematics can differ substantially in attractiveness.
16.05.09 #       <JoeBorn> I don't see a problem with the GPM and free clones problem
16.05.23 #       <JoeBorn> GPL I mean, 
16.05.59 #       <JoeBorn> what I beleive will happen eventually is that the asian manufacturers will eventually realize the "free clones" opportunity and start making them.
16.06.16 #       <LinusN> yup
16.06.18 Join    Nibbler [0] (~andrer@port-212-202-73-41.dynamic.qsc.de)
16.06.36 #       <JoeBorn> although, it's an interesting question because will a "free clone" really work perfectly?
16.07.01 #       <JoeBorn> I mean the schematics are copyrighted themselves so you can't just copy them.
16.07.25 #       <JoeBorn> so how do you get them perfect when all the debugging has been done on the original device?
16.07.31 #       <Zagor> even "clones" would most likely have small differences tthat need code changes
16.07.47 #       <Bagder> like PCs running linux
16.07.53 #       <JoeBorn> Right, and that's an impdediment.
16.08.01 #       <JoeBorn> exactly.
16.08.03 #       <Zagor> not if the code is GPL
16.08.32 #       <JoeBorn> well, it's still an impediment because you can't just drop the existing code into the device.
16.08.51 #       <LinusN> you would at least change the startup logo :-)
16.09.17 #       <JoeBorn> in our example, the manufacturer, whose english is not that good would have to contact you to have changes incorporated 
16.09.18 #       <Zagor> right, but the manufacturer would probably spend a month or however much it takes to adapt the software. rather than commission a complete 5 man-year rewrite .
16.09.33 #       <Zagor> ...or you
16.10.01 #       <JoeBorn> sure, but now they fork the code and when the official rockbox releases a cool new feature, they don't have it.
16.10.20 #       <Zagor> if they want rockbox to work, they will submit their changes to us
16.10.27 #       <JoeBorn> as a user, now my clone just bit me, and I'd sure rather have "the real thing"
16.10.46 #       <Zagor> ...and thus they buy "the original", the neuros
16.11.20 #       <JoeBorn> right, wouldn't you?
16.11.23 #       <LinusN> yes, so neuros can be proactive and contribute a lot
16.11.38 #       <Zagor> i probably would
16.11.47 #       <JoeBorn> exactly.  that's why I'm not worried about the free clone issue.
16.11.56 #       <LinusN> good thought
16.12.20 #       <JoeBorn> the issue is that we'd like to preserve the ability to license to someone else.
16.12.42 #       <JoeBorn> I wouldn't say it's a must have, but it would sure be nice.
16.13.11 #       <Bagder> you mean selling the code without GPL stamped on it?
16.13.19 #       <JoeBorn> right.
16.13.23 #       <Zagor> Perhaps, but I think it would be a hard sell to contributors.
16.13.46 #       <Bagder> it would require a TrollTech/MySQL setup
16.13.58 #       <JoeBorn> I think if you say it would be a hard sell to contributors, then we can be pretty confident it's true:)
16.14.03 #       <LinusN> a norwegian web site picked up on the latest slashdot news about rockbox being ported to iriver, saying thet rockbox coule "very well be the linux of media players"
16.14.14 #       <Zagor> LinusN: link?
16.14.16 #       <JoeBorn> Badger:  that's exactly right
16.14.19 #       <LinusN> hang on
16.14.38 #       <Bagder> JoeBorn: it would "only" require that you are the copyright owner of all the code...
16.14.55 #       <Zagor> yes, but I know a lot of people who won't contribute to qt for precisely that reason
16.15.03 #       <Bagder> or have an agreement with the copyright holders
16.16.18 #       <Zagor> I would suggest to drop the dual-licensing. I'd say the risk (of alienating contributors) is greater than the chance (of licensing the code for profit).
16.16.30 #       <ripnetUK> how the pan-european wiggler journey going ;-)
16.16.37 #       <LinusN> my mistake, it wasn't the norwegian web mag, it was a blog:
16.16.41 #       <JoeBorn> have you guys considered making an "official organization" out of rockbox?
16.16.41 #       <LinusN> http://dev.null.org/blog/archive.cgi/2004/07/13
16.17.05 #       <Zagor> JoeBorn: no :)
16.17.44 #       <LinusN> ripnetUK: holy moses, it's in Stockholm!!!
16.17.51 #       <Zagor> yay
16.17.52 #       <JoeBorn> that's one possible solution
16.18.00 #       <Zagor> JoeBorn: how do you mean?
16.18.18 #       <LinusN> status: "On FedEx vehicle for delivery"
16.18.26 #       <LinusN> and i'm not at home :-(
16.18.33 #       <Zagor> LinusN: call them
16.18.34 #       <JoeBorn> well then the organization can own the code
16.18.47 #       <ripnetUK> :) wiggler hits home :)
16.19.41 #       <LinusN> my wife has received the package! :-)
16.19.46 #       <JoeBorn> "I wonder how long until companies stop making (and maintaining) their own firmware and start building players around Rockbox" :)
16.20.00 #       <Zagor> JoeBorn: sure, but it's not a legal problem. it's an ethic/trust/goodwill issue
16.20.15 #       <ripnetUK> nice... uk couriers have a habbit of sending deliveries to a depot MILES away 
16.20.22 #       <Zagor> making rockbox a formal organisation won't help with that
16.20.45 #       <Zagor> LinusN: excellent!
16.21.06 #       <LinusN> Zagor: that means i won't get any sleep this night either :-)
16.21.22 #       <JoeBorn> well, it relies on teh continued  trust and ethics and goodwill of Rockbox
16.21.38 #       <JoeBorn> it would just provide a mechanism for you to officially hold resources.
16.21.53 #       <LinusN> i have to go now
16.21.57 #       <Zagor> LinusN: go go go!
16.22.10 #       <LinusN> JoeBorn: nice talking to you, keep in touch
16.22.14 #       <LinusN> cu all!
16.22.19 #       <Zagor> JoeBorn: ok I see what you mean
16.22.21 #       <JoeBorn> nice talking to you
16.22.24 Part    LinusN
16.22.26 Join    kurzhaarrocker [0] (~knoppix@p50877CBC.dip0.t-ipconnect.de)
16.22.45 #       <JoeBorn> It might be a horrible idea for all I know, I was just curious.
16.22.46 #       <Zagor> we don't have anything against formalizing rockbox, there just hasn't been any reason to
16.22.59 #       <Zagor> and we hate paperwork :)
16.23.19 #       <JoeBorn> I understand that.
16.23.57 #       <kurzhaarrocker> (completely ot) Zagor: I want to request a web page with a form and parse it. Is curl the way to go?
16.24.19 #       <JoeBorn> I need to run myself, thanks for your time everyone.
16.24.21 #       <Zagor> curl can do anything :)
16.24.38 #       <kurzhaarrocker> Ok, Ill try to make it make coffee.
16.24.45 #       <Zagor> JoeBorn: ok, thanks for the discussion
16.26.33 #       <dwihno_> Yay for the wiggler!
16.26.35 Nick    dwihno_ is now known as dwihno (~dw@81.8.224.89)
16.27.18 #       <ripnetUK> lets hope it wiggles ok with the iRiver
16.36.13 #       <Zagor> brace for commit
16.37.41 #       <kurzhaarrocker> )
16.39.41 Quit    ashridah ("crash")
16.40.13 #       * dwihno bucles his safety belt
16.40.19 #       * dwihno braces for impact
16.40.22 #       <dwihno> IIIIIIIIHHHH!
16.40.55 #       * kurzhaarrocker tries to curl up :)
16.41.33 #       <Zagor> now you can all build iriver simulators and play with :)
16.42.32 Join    methangas [0] (methangas@0x50c61c48.virnxx10.adsl-dhcp.tele.dk)
16.42.49 #       <Bagder> finally! :-P
16.43.32 #       <Bagder> want that in the build table?
16.43.59 #       <kurzhaarrocker> I wonder when the ideas about supporting other platforms than the recorder/player became serious.
16.44.32 #       <Bagder> kurzhaarrocker: when they discovered enough details on the iRiver
16.44.43 Quit    Nibbler (Read error: 110 (Connection timed out))
16.45.11 #       <Zagor> actually the *idea* came earlier than that
16.45.20 #       <Bagder> true
16.45.27 #       <kurzhaarrocker> Bagder soon a table won't be sufficiant any more, prepare to build a build cube :)
16.45.39 #       <Bagder> hehe
16.46.05 #       <kurzhaarrocker> Yes but usually the idea was considered as a topic of the nodo.
16.46.29 Quit    JoeBorn ("CGI:IRC (EOF)")
16.47.50 #       <kurzhaarrocker> :( my web hoster doesn't support curl.
16.48.22 #       <Bagder> build it yourself
16.48.52 ***     Saving seen data "./dancer.seen"
16.49.11 Join    Nibbler [0] (~andrer@port-212-202-78-96.dynamic.qsc.de)
16.51.07 #       <kurzhaarrocker> I'm not sure but I believe that if php says it was configured with "--without-curl" I'm in a dead end  - no matter how many curl libs I build...
16.51.35 #       <Bagder> right, but you can use the command line tool
16.51.36 #       <Zagor> yes, if you must use it inside php. but you can always use the command-line program
16.52.13 #       * kurzhaarrocker considers that
16.53.08 #       <Bagder> it might have the tool installed
16.58.02 Join    midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
16.58.12 #       * [IDC]Dragon missed the interesting-looking discussion with Joe
16.58.30 #       <[IDC]Dragon> (and had not enough time yet to read it)
16.59.01 Join    mecraw_ [0] (~lmarlow@69.2.235.2)
17.07.42 #       <[IDC]Dragon> amiconn: do you read?
17.07.50 #       <Zagor> yeah it was a nice chat
17.08.07 #       <[IDC]Dragon> how do you know that guy?
17.08.28 #       <[IDC]Dragon> he's from Neuros s/w development?
17.08.31 #       <Zagor> we've mailed a bit about their open source effort
17.08.36 #       <Zagor> he's their ceo
17.08.42 #       <[IDC]Dragon> oh
17.09.45 #       <Zagor> sorry, "only" chairman and cto
17.09.51 #       <[IDC]Dragon> well
17.10.15 #       <[IDC]Dragon> poen source witout open development tools :(
17.10.19 #       <[IDC]Dragon> open
17.10.47 #       <Zagor> yeah. that's why he was here talking to us today, to avoid doing such a mistake next time
17.11.01 #       <[IDC]Dragon> mistake? ;-)
17.11.46 #       <Zagor> well what else would you call it? if they wanted it proprietary, they wouldn't have opened the source would they?
17.13.10 #       <[IDC]Dragon> no, I mean because it has that accidental touch, ironically
17.13.36 #       <[IDC]Dragon> by mistake practically nobody can build it, sorry
17.14.25 Quit    midk (Read error: 110 (Connection timed out))
17.18.30 #       <[IDC]Dragon> "Added Iriver H100 to tools/configure", hehe
17.18.55 #       <Zagor> yeah, so we can build the h100 simulator
17.20.41 #       <[IDC]Dragon> apart from that, it's early and optimistic :-)
17.21.27 #       <Zagor> yup :)
17.28.19 #       <ripnetUK> just built the UI sim for iRiver - looking kinda cool
17.28.33 #       <ripnetUK> although still green :)
17.28.42 #       <Zagor> :)
17.31.28 #       <Zagor> gotta go
17.31.30 Part    Zagor
17.36.18 Quit    AciD ("how much wood would a wood chuck chuck if a wood chuck could chuck wood ?")
17.40.41 Quit    [IDC]Dragon ("CGI:IRC")
17.48.10 Part    kurzhaarrocker
17.55.43 Quit    Bagder ("Leaving")
17.58.41 #       <ripnetUK> --- uisimulator/x11/uibasic.c   20 Jan 2003 09:39:37 -0000      1.13
17.58.41 #       <ripnetUK> +++ uisimulator/x11/uibasic.c   16 Sep 2004 15:58:16 -0000
17.58.41 #       <ripnetUK> @@ -61,7 +61,7 @@
17.58.41 DBUG    Enqueued KICK ripnetUK
17.58.41 #       <ripnetUK>  char *progclass = "rockboxui";
17.58.41 #       <ripnetUK>  char *defaults [] = {
17.58.41 ***     Alert Mode level 1
17.58.41 #       <ripnetUK> -  ".background:        lightgreen",
17.58.43 #       <ripnetUK> +  ".background:        lightblue",
17.58.45 #       <ripnetUK>    ".foreground:        black",
17.58.47 #       <ripnetUK>    "*help:       false",
17.58.49 #       <ripnetUK>    0
17.58.51 #       <ripnetUK> :)
17.58.53 #       <ripnetUK> much more iRiver
18.08.24 Join    LinusN [0] (~linus@labb.contactor.se)
18.08.42 ***     Alert Mode OFF
18.09.41 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
18.11.35 Part    LinusN
18.22.51 Join    _aLF [0] (~alex@mutualite-3-82-67-66-128.fbx.proxad.net)
18.22.54 #       <_aLF> hi
18.37.22 Join    webguest07 [0] (~d4b93602@labb.contactor.se)
18.38.05 Quit    webguest07 (Client Quit)
18.48.56 ***     Saving seen data "./dancer.seen"
19.03.41 Quit    AciD (Read error: 104 (Connection reset by peer))
19.06.55 Quit    Lynx_ (" WOW! This IRC Client ownz! HydraIRC -> http://www.hydrairc.com <-")
19.11.45 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
19.14.50 Join    srn [0] (~82e13707@labb.contactor.se)
19.16.49 #       <srn> i just added some pages to the iriver wiki. unfortunately, i positioned a page at the wrong level.  IriverPort > IriverBDM > IriverMemoryMap -- should have been -->   IriverPort > IriverMemoryMap. can any one fix this?
19.17.16 Join    [IDC]Dragon [0] (~idc-drago@pD9E34188.dip.t-dialin.net)
19.17.46 #       <[IDC]Dragon> amiconn?
19.18.03 #       <amiconn> hi. Now I'm around
19.18.09 #       <[IDC]Dragon> :)
19.18.20 #       <[IDC]Dragon> seen my "answers"?
19.18.21 #       <amiconn> (Sometimes I even have to work at work ;) )
19.18.31 #       <[IDC]Dragon> that sucks :(
19.22.12 #       <amiconn> Yes, found your answers
19.22.39 #       <[IDC]Dragon> they seem to "burst" a sector or so
19.23.11 #       <[IDC]Dragon> I didn't measure it, but could do so for an estimate, if that helps
19.23.16 #       <amiconn> On PA13: It is used both in the serial transmit and receive, switched between GPIO and IRQ1
19.23.45 #       <[IDC]Dragon> with serial you mean SPI for MMC?
19.23.52 #       <amiconn> yup
19.24.10 #       <[IDC]Dragon> I will go hunting for that signal
19.28.08 Join    R3nTiL [0] (~zorroz@249-248-30-217.kgts.ru)
19.30.47 #       <amiconn> [IDC]Dragon: before transmit/ receive: PACR1 &= 0xF3FF (PA13->GPIO). After transmit/receive: PACR1 |= 0x0400  (PA13->IRQ1)
19.31.03 #       <dwihno> are you fiddling with the ondio?
19.31.08 #       <amiconn> yup
19.31.51 #       <dwihno> Are you trying MMC communication with the on-board chip?
19.33.25 #       <amiconn> Not for real yet.
19.34.10 #       <amiconn> Currently looking into various data sheets and at the disassembled archos fw to get a clue how this is supposed to work
19.35.14 Join    webguest08 [0] (~d5dff649@labb.contactor.se)
19.36.17 Quit    webguest08 (Client Quit)
19.36.43 #       <amiconn> The SH1 hardware manual is not very precise about the serial communication. E.g. with synchronous mode, what could cause a receive overrun error? Iiuc, synchronous mode does only output the clock signal if it is ready to receive, so in theory overrun shouldn't be possible.
19.37.15 #       <[IDC]Dragon> with exteral clock, I think
19.39.49 #       <amiconn> I already have a serial init, and will try to check if enabling serial causes continuous clock output. It's a bit difficult for me though (neither a LA nor a digital scope, only a simple analog scope)
19.40.10 #       <[IDC]Dragon> analog is fine
19.40.16 #       <[IDC]Dragon> I do most with it
19.40.39 #       <amiconn> A logic analyzer could actually prove valuable here
19.41.37 #       <[IDC]Dragon> c'mon, you only want to check for your piulses, nothing complx
19.41.59 #       <[IDC]Dragon> ...pulses, nothing complex
19.42.19 #       <amiconn> Not for this very job, but for capturing e.g. a data transfer burst
19.42.59 #       <[IDC]Dragon> I can do that, if necessary
19.43.10 #       <[IDC]Dragon> (but mostly, it isn't)
19.43.35 #       <[IDC]Dragon> the SCI itself should not need debugging
19.44.34 #       <amiconn> Yes, like the recording data transfer. Still no luck :(
19.44.47 #       <[IDC]Dragon> we got out LCD working, too, where every transition is done "by hand"
19.45.34 #       <amiconn> Yes. In fact I think that's easier than dealing with the SH1 SCI
19.45.56 #       <amiconn> It may even prove to be faster
19.46.03 #       <[IDC]Dragon> for a first shot, you could do so as well
19.46.31 #       <[IDC]Dragon> no, it won't be faster, methinks
19.47.11 #       <[IDC]Dragon> with the LCD, we got an overall ~900kBit/s
19.47.18 #       <amiconn> The highest serial speed we can set for continuous transfer is 1.5 MBit/s, which equals 8 cpu cycles per bit.
19.47.29 #       <[IDC]Dragon> 112*64*130 fps
19.47.50 #       <[IDC]Dragon> and the carry trick won't work here
19.48.05 #       <[IDC]Dragon> for bad data bit position
19.48.18 #       <[IDC]Dragon> (I already checked this mentally)
19.49.37 #       <amiconn> Ah ok. I didn't take into account that each data access to the ports needs 2 wait states
19.50.25 #       <amiconn> Where do I have to measure the clo
19.50.57 #       <amiconn> ck?
19.51.01 #       <amiconn> Is it possible at the 74AC08?
19.51.01 #       <[IDC]Dragon> yes
19.51.17 #       <amiconn> So it's not that difficult
19.51.43 #       <[IDC]Dragon> see twiki table
19.52.16 #       <[IDC]Dragon> btw, did you see my new photo of the "naked" board?
19.52.47 #       <amiconn> yup
19.53.00 Quit    R3nTiL ()
19.56.24 Quit    maikeul (Remote closed the connection)
20.01.29 #       <amiconn> [IDC]Dragon: I have seen the bursts of the original fw on my scope now.
20.02.13 #       <amiconn> The bridge clock is too high for my scope though
20.02.48 #       <[IDC]Dragon> I found PC6 instead
20.02.58 #       <[IDC]Dragon> more later, cu
20.03.03 #       <[IDC]Dragon> (away)
20.03.11 Quit    [IDC]Dragon ()
20.04.53 Join    gromit`` [0] (~gromit@ALagny-151-1-27-251.w83-114.abo.wanadoo.fr)
20.49.00 ***     Saving seen data "./dancer.seen"
20.50.17 Quit    Nibbler (Read error: 60 (Operation timed out))
20.56.24 Join    RyanA [0] (~RyanA_191@pool-68-160-0-36.bos.east.verizon.net)
20.56.49 #       <RyanA> does anyone know where to get a replacement AC adapter cord real cheap?
20.58.39 Quit    RyanA (Client Quit)
21.30.35 Join    mecraw__ [0] (~lmarlow@69.2.235.2)
21.41.03 Quit    srn ("CGI:IRC (EOF)")
21.48.32 Quit    mecraw_ (Read error: 110 (Connection timed out))
21.56.48 Join    [IDC]Dragon [0] (~idc-drago@pD9512E52.dip.t-dialin.net)
21.57.13 #       <[IDC]Dragon> hi again
21.57.23 #       <[IDC]Dragon> amiconn: I found PA13
21.57.25 #       <amiconn> hi
21.57.33 #       <amiconn> What is it?
21.57.36 #       <[IDC]Dragon> it disappears under the flash
21.57.44 #       <amiconn> Huh?
21.57.50 #       <[IDC]Dragon> and goes to a test pad
21.58.09 #       <[IDC]Dragon> the flash is BGA, I can't beep that
21.58.16 #       <amiconn> I know.
22.00.49 Join    Zagor [0] (foobar@h254n2fls31o265.telia.com)
22.01.56 #       <amiconn> [IDC]Dragon: Maybe it is connected to the RDY/BSY interrupt signal
22.02.32 #       <amiconn> PA13 is always input
22.02.56 #       <amiconn> We won't need that for now
22.03.10 #       <Zagor> ripnetUK: committed
22.03.15 #       <amiconn> [IDC]Dragon: What about PC6?
22.03.42 #       <amiconn> Ah, found it.
22.03.58 #       <amiconn> Needed to reload the wiki page :)
22.04.22 #       <[IDC]Dragon> didn't you say it switches direction?
22.04.59 #       <amiconn> No, it switches function: GP in <> IRQ1
22.05.39 #       <[IDC]Dragon> ah, never mind.
22.06.25 #       <amiconn> I tried to output some clocks (writing 0xFF == dummies). No luck yet :(
22.06.35 #       <[IDC]Dragon> maybe it's the ready/busy signal
22.09.08 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.14.57 #       <[IDC]Dragon> that's the only thing which makes sense
22.16.32 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
22.27.21 #       <amiconn> I don't seem to get that dreaded SCI setup right. Both transmit and receive don't output any clocks; transmit ends much faster than it should, receive hangs :((
22.28.10 #       <[IDC]Dragon> have you set the pin functions correct?
22.28.20 #       <amiconn> Yup (at least I think so)
22.28.56 #       <[IDC]Dragon> peeking at the MAS code doesn't help?
22.29.08 #       <amiconn> I did peek there
22.29.19 #       <[IDC]Dragon> our MAS code, I mean
22.29.25 #       <amiconn> Yups
22.30.17 Join    [av]bani [0] (~goemon@washuu.anime.net)
22.30.30 #       <[av]bani> Re: JoeBorn
22.30.38 #       <[av]bani> they should either focus on the hardware, or the software
22.30.42 #       <[av]bani> but not both
22.30.52 #       <[av]bani> eg, make killer hw and make it easy to code for
22.30.53 #       <[av]bani> or...
22.31.11 #       <[av]bani> make a generic clonable/licensable open hw, and sell killer sw for it
22.31.21 #       <Zagor> well even if they make killer hardware, they have to make decent firmware too.
22.31.28 #       <[av]bani> well
22.31.32 #       <[av]bani> if they pull a zaurus, it will flop
22.31.33 #       <[av]bani> eg
22.31.40 #       <[av]bani> nice hw, but poorly supported
22.31.53 #       <Zagor> yes, but you also can't bet the company that an open source project will do everything
22.32.26 #       <[av]bani> well, take rockbox for an example, the opensource fw turned out much nicer than stock, because you were able to hack it
22.32.38 #       <[av]bani> but imagine how much ebtter it would have been had it been openly supported from the start
22.32.45 #       <[av]bani> instead of making you jump through hoops
22.33.00 #       <[av]bani> its like the pc market
22.33.08 #       <[av]bani> you either focus on the hw, or focus on the sw
22.33.13 #       <[av]bani> youre either dell or microsoft
22.33.19 #       <[av]bani> dont try to do both
22.33.21 #       <Zagor> pcs are commodities. mp3 players aren't (yet)
22.33.33 #       <[av]bani> sure they are, mp3 players are definitely commodities
22.33.43 #       <[av]bani> apple made sure of that
22.34.04 #       <[av]bani> only a few companies can really pull off both, and it takes a lot of effort
22.34.07 #       <Zagor> mp3 player hardware is not as interchangeable as pc hardware, is what I mean
22.34.10 #       <[av]bani> apple ipod, rio
22.34.20 #       <Zagor> each hardware manufacturer has to also make the software to run on it
22.34.24 #       <[av]bani> look at how many companies flopped because either the hw was inadequate or the firmware was
22.34.29 #       <Zagor> much like the pc business in the early 80s
22.34.47 #       <[av]bani> well in the case of being open
22.34.52 #       <[av]bani> either focus on the hw or focus on the sw
22.35.03 #       <[av]bani> one or the other
22.35.12 #       <Zagor> you are right in principle, but we aren't there yet
22.35.15 #       <[av]bani> if youre totally closed/proprietary, you dont really have a choice
22.35.24 #       <[av]bani> well, i'm just saying what Joe should do
22.35.26 #       <Zagor> just making good hw will, as you say, risk a zaurus flop
22.35.30 #       <[av]bani> if they want an open player
22.35.49 #       <[av]bani> decide which side they will take
22.36.06 #       <[av]bani> make killer hw and work closely with rockbox for good support
22.36.29 #       <[av]bani> both sides win - they get nice fw and you get a nice player
22.36.45 #       <Bagder> but that _is_ making good hw and good sw
22.36.58 #       <Bagder> only open sw
22.37.02 #       <[av]bani> they wouldnt be writing the sw though
22.37.09 #       <[av]bani> theyd be making it easy for you to do so
22.37.42 #       <amiconn> [IDC]Dragon: Many of your &= / |= settings for the PFC change only either the upper or lower half of the word, so could be replaced with and_b() / or_b(). Not done yet.
22.37.49 #       <Zagor> too risky. they have to write some software themselves too.
22.37.53 #       <amiconn> And it seems I found a mistake
22.38.01 #       <Zagor> maybe the next company doesn't, but Joe definitely has to
22.38.32 #       <[av]bani> rockbox already works, if they make it easy for you to poke the hw then a port should be easy
22.38.39 #       <[av]bani> and faster than them writing their own
22.38.41 #       <Zagor> at least I wouldn't want to bet my company on an bunch of volunteers who are under no obligation to do anything
22.38.48 #       <[av]bani> plus, they can plug it that way, opensource player
22.38.56 #       <[av]bani> get all the /.'ers drooling etc
22.38.57 #       <Zagor> yes, we all agree about that
22.39.01 #       <Zagor> even joe
22.39.12 #       <[av]bani> because writing fw from scratch would likely take longer and cost more
22.39.19 #       <[av]bani> so they can focus more on investing in hw
22.39.23 #       <[av]bani> = better player
22.39.36 #       <[av]bani> besides
22.39.45 #       <[IDC]Dragon> amiconn: yes, I know. didn't bother for now, it reads nicer while experimenting.
22.39.47 #       <[av]bani> few vendors actually _sell_ the firmware
22.39.55 Join    Nibbler [0] (~andrer@port-212-202-78-96.dynamic.qsc.de)
22.40.20 #       <[av]bani> in the sense that most players are built with off the shelf parts
22.40.26 #       <[av]bani> well, rockbox is one of those parts :)
22.40.36 #       <Zagor> [av]bani: you don't need to sell *us* on the benefits of open source :)
22.40.52 #       <[av]bani> did he say when he would be back?
22.40.57 #       <[av]bani> so i can pitch to him :)
22.41.14 #       <[av]bani> i just think that an openly clonable hw platform is the wrong way to go for them
22.41.25 #       <[av]bani> which was what he was proposing
22.41.26 #       <Zagor> you don't need to pitch to him either. the sole reason he was here was to find out how he could make their next product more rockbox-friendly
22.41.57 #       <[av]bani> schematics and devkits with bdm support would be the best way :)
22.42.40 #       <[av]bani> retail box, and dev sdk
22.42.43 #       <[av]bani> :)
22.47.16 #       <[av]bani> wiggler@home ?
22.47.48 #       <Bagder> @linus' home
22.49.04 ***     Saving seen data "./dancer.seen"
22.49.07 #       <amiconn> [IDC]Dragon: Although I made SCK1 an output now, still no clock pulses :(
22.50.15 #       <[IDC]Dragon> I once got pulses, a steady frequency
22.50.24 #       <[av]bani> pulses are good
22.50.46 #       <[IDC]Dragon> (even without outputting data)
22.50.53 #       <[IDC]Dragon> do you writedata?
22.50.58 #       <amiconn> Yes.
22.51.20 #       <[IDC]Dragon> transmit enabled, and everything?
22.51.36 #       <amiconn> I try to write 15625*16 bytes @400 kBit/s. Should take around 5 secs
22.53.38 #       <amiconn> @375 kBit/s to be exact
22.54.38 #       <[IDC]Dragon> how do you init SCI1?
22.54.49 #       <amiconn> void setup_sci1(int rate) /* in bit/s, rounds down to the next possible value */
22.54.50 #       <amiconn> {
22.54.50 #       <amiconn>     int i;
22.54.50 DBUG    Enqueued KICK amiconn
22.54.50 #       <amiconn>     int divider = (FREQ/4 - 1) / rate;
22.54.50 #       <amiconn>     
22.54.50 ***     Alert Mode level 1
22.54.50 #       <amiconn>     SCR1 = 0x00;       /* disable serial port */
22.54.52 #       <amiconn>     SMR1 = 0x80;       /* Synchronous, no prescale */
22.54.54 #       <amiconn>     BRR1 = divider;
22.54.56 #       <amiconn>     SCR1 = 0x01;       /* clock output */
22.54.58 #       <amiconn>     and_b(0xC7, SSR1); /* clear ORER, FER and PER */
22.55.02 #       <amiconn>     for (i = 0; i < divider; i++);  /* wait at least 1 bit time */
22.55.02 #       <amiconn>     or_b(0x30, SCR1);  /* enable TxD and RxD */
22.55.04 #       <amiconn> }
22.56.06 #       <amiconn> This is called from ata_enable(true) with setup_sci1(400000); after setting SCK1, TxD1 and RxD1 pin functions, and making SCK1 and TxD1 outputs
22.56.38 #       <[IDC]Dragon> the output part is only relevant if GPIO
22.56.58 #       <amiconn> The divider evaluates to 7 for rate = 400000, verified with readback
22.57.58 #       <amiconn> The output part is done in the mas serial setup (at least for SCK0). It shouldn't hurt anyway
23.01.11 Part    [av]bani
23.01.33 #       <[IDC]Dragon> how do you wait for your output?
23.01.53 #       <amiconn>     for (i = 0; i < len; i++)
23.01.53 #       <amiconn>     {
23.01.53 #       <amiconn>         while (!(SSR1 & 0x80));  /* wait for TDRE = 1 */
23.01.53 ***     Alert Mode level 2
23.01.53 #       <amiconn>         TDR1 = buf[i];           /* write byte */
23.01.54 ***     Alert Mode level 3
23.01.54 #       <amiconn>         and_b(~0x80, SSR1);      /* start transmitting */
23.01.54 ***     Alert Mode level 4
23.01.54 #       <amiconn>     }
23.01.56 #       <amiconn>     while (!(SSR1 & 0x04));      /* wait for TEND = 1 */
23.02.13 #       <amiconn> This is part of my mmc_write_transfer function
23.02.41 #       <amiconn> (Well, most of it for now. I don't bother trying DMA for now)
23.02.57 #       <[IDC]Dragon> you have to clear TDRE, i think
23.03.21 #       <amiconn> I do this: and_b(~0x80, SSR1);      /* start transmitting */
23.04.02 #       <[IDC]Dragon> ah, yes
23.04.34 #       <[IDC]Dragon> have you tried the reverse order?
23.04.53 #       <[IDC]Dragon> clear TDRE first, then write new data
23.05.44 #       <amiconn> This would transmit the data that was in TDR1 before. The sequence is from the sh datasheet. I can't see what I am doing wrong here, maybe I'm blind.
23.07.59 #       <[IDC]Dragon> I don't see it either
23.08.44 #       <[IDC]Dragon> how about a close comparison withthe MAS play code?
23.09.09 #       <amiconn> The MAS play code uses dma & interrupts...
23.10.30 #       <Bagder> Zagor: I can't build the iriver sim
23.11.11 #       <Bagder> oh never mind
23.11.15 Quit    silencer (Nick collision from services.)
23.11.18 Join    silencer [0] (~silencer@zen.via.ecp.fr)
23.11.19 #       <Zagor> ok :)
23.11.27 Quit    silencer (Nick collision from services.)
23.11.55 ***     Alert Mode OFF
23.11.56 #       <Bagder> biiig display ;-)
23.12.02 #       <Zagor> yeah
23.12.38 #       <Zagor> the text reader becomes very nice on this display
23.13.26 #       <Zagor> hmm, did I break something? "make install" does not install the fonts
23.14.10 #       <[IDC]Dragon> gotta sleep, c u
23.15.20 Quit    [IDC]Dragon ()
23.15.41 #       <Bagder> Zagor: I think the buildzip needs a little pat on the shoulder
23.16.17 Join    silencer_ [0] (~silencer@zen.via.ecp.fr)
23.16.43 #       <Bagder> check the last 5 lines of it
23.17.49 #       <Zagor> ah
23.20.07 #       <Bagder> you fix or I?
23.20.24 #       <Zagor> fixed
23.21.25 #       <Zagor> we should remove all line wraps from the docs when we add it to the zip. they are ugly to read like this.
23.22.01 #       <elinenbe> hi!
23.22.18 #       <elinenbe> what's the status with the iriver?  has much/any progress been made since last week?
23.22.41 #       <Zagor> lots of new information, no code ran yet
23.23.19 #       <Zagor> but our bdm pod arrived to linus today so things will hopefully take off a little soon
23.23.53 #       <elinenbe> is everything in the wiki?
23.24.01 #       <elinenbe> what is the bdm pod used for?
23.24.55 #       <Zagor> it's for interfacing with the cpu's debug module. that way we can run gdb against it without running code. also it will help us flash it.
23.27.17 #       <elinenbe> wow... nice!  how much did that cost?
23.27.24 #       <Zagor> $150
23.32.14 Ctcp    Ignored 2 channel CTCP requests in 4 hours and 56 minutes at the last flood
23.32.14 #       * Zagor got a mail with a link for a broken iriver on ebay
23.32.46 #       <Bagder> lemme guess!
23.32.53 #       <Bagder> "deliver in US only" ;-)
23.33.01 #       <Zagor> nope, located in ireland
23.33.09 #       <Bagder> how much?
23.33.18 #       <Zagor> $15 so far
23.33.35 Nick    silencer_ is now known as silencer- (~silencer@zen.via.ecp.fr)
23.33.36 #       <Bagder> and long time time is it left?
23.33.40 #       <Zagor> 3 days
23.34.02 #       <Zagor> 4 days have passed, 3 bidders (started at $5)
23.34.24 #       <Bagder> ok, so it could be worth making a bid in a few days
23.34.33 #       <Zagor> definitely
23.38.45 Quit    ripnetUK ()
23.51.07 Quit    scott666_ (Read error: 110 (Connection timed out))
23.51.42 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)