--- Log for 07.01.105  Server: niven.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 month and 28 days ago

00.00.41 #       <zeekoe> yup, and unneccessary i think now... if a user want a config-load-only option, he can have the resume screen for free, and it won't harm
00.01.16 #       <zeekoe> the only different thing would be that he shouldn't press Play
00.01.47 #       <zeekoe> ..so changing the 'show resume screen' option can change in 'show resume and config load screen', right?
00.01.51 #       <Zagor> right. how about adding the config option, and if the resume screen isn't used but the config loader option is set, you prompt separately from the resume
00.02.14 #       <Zagor> also only show the button bar in the resume screen if the option is set
00.02.25 #       <zeekoe> okay
00.03.26 Quit    gromit` (Remote closed the connection)
00.04.40 Join    gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net)
00.05.14 #       <Zagor> also i'd like a splash(HZ,true,str(LANG_READ_FAILED),filename) if the config file chosen does not exist
00.05.58 #       <zeekoe> that would break the backwards compatibility to 'the old system'
00.06.05 #       <Zagor> ...and use the ROCKBOX_DIR define instead of hardcoding "/.rockbox"
00.06.14 #       <zeekoe> uh, ok :)
00.06.32 #       <Zagor> well since we are adding a config option, we don't need to maintain compatibility imho
00.06.39 #       <zeekoe> if a user normally exits the menu with f1, he now has to wait 1 second
00.07.05 #       <zeekoe> ok, you got a point
00.07.17 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
00.07.32 #       <Zagor> since the option is disabled by default, the user won't be surprised by the change
00.07.43 #       <zeekoe> ok
00.10.37 #       <Zagor> my suggestion for non-recorder keypads is to give two options: left/right. all devices have left/right, and it doesn't interfer with resume (even player users can still press play/stop)
00.11.14 #       <zeekoe> yup, i'll do that
00.12.05 #       <zeekoe> can i use buttonbar_set("left","","right") for that? or is that bad
00.13.31 Quit    midk (Read error: 104 (Connection reset by peer))
00.16.17 #       <Zagor> actually, you can't display anything for players in the resume screen. their display is full...
00.17.07 #       <Zagor> the buttonbar* functions only exist on recorders, so you can't use them for other models
00.18.48 #       <Zagor> however i still think players should have the option available, just no text if resume screen is showing.
00.22.00 Join    zeekoe2 [0] (~me@ip51cc69f6.adsl-surfen.hetnet.nl)
00.22.07 #       <zeekoe2> i agree on that (about the players). But the *buttonbar thing doesnt work on ondios? ondios do have the right screen.
00.22.16 #       <zeekoe2> is there another easy way to get text at the bottom of the screen?
00.22.31 #       <zeekoe2> other than copypaste the buttonbar thing?
00.22.31 #       <Zagor> they have the screen, but not the buttons so a bar would be useless
00.22.46 #       <zeekoe2> bottom of screen is hard, i found out
00.22.53 #       <zeekoe2> harder than top
00.23.20 Quit    zeekoe (Nick collision from services.)
00.23.24 Nick    zeekoe2 is now known as zeekoe (~me@ip51cc69f6.adsl-surfen.hetnet.nl)
00.24.28 #       <Zagor> yes, you need to know the font height
00.24.46 #       <zeekoe> indeed
00.24.57 #       <zeekoe> or use a known to be good font
00.25.43 #       <zeekoe> ah well, i should get some sleep now
00.26.08 #       <zeekoe> need to do some rockbox digging tomorrow, like how to add config options and stuff :)
00.26.09 #       <Zagor> sorry to give you a load of work :)
00.26.25 #       <zeekoe> you're not really sorry, are you ;-)
00.26.46 #       <zeekoe> it's good for me... i might learn some C :)
00.30.06 Quit    zeekoe ()
00.31.01 ***     Saving seen data "./dancer.seen"
00.42.00 #       <crash_> jyp: hi
00.50.54 #       <jyp> yup.
00.51.04 #       <jyp> ?
00.51.39 #       <crash_> i had an highlight from you ;)
00.51.50 #       <crash_> i think it was about the gmin 220 xs
00.52.00 #       <jyp> ah?
00.54.03 #       <crash_> so u got a question?
00.54.37 #       <crash_>                function too?
00.54.37 #       <crash_> 23:22 < jyp> no, I don't
00.54.37 #       <crash_> 23:22 < jyp> sorry
00.54.37 DBUG    Enqueued KICK crash_
00.54.37 #       <crash_> 23:22 < jyp> crash_?
00.55.06 #       <Zagor> <Zagor> jyp: do you know if the navigation knob on the xs200 has a push function too?
00.55.27 #       <jyp> maybe you know?
00.55.31 #       <crash_> i hink i should exercise a bit with this irc client ;)
00.55.37 #       <crash_> i can test
00.55.54 #       <crash_> but as i said i dont have a gmini xs 220, only a friend of mine has one
00.56.13 #       <jyp> ok
00.56.19 #       <crash_> u mean the round button in the middle, which functions this one has right ?
00.56.31 #       <crash_> or if it is a joystick like
00.56.39 #       <jyp> Zagor means :P
00.57.04 #       <Zagor> exactly. i assume it can be moved in four directions. but can it be pushed/clicked too? i would guess so.
00.57.29 #       <crash_> i just asked my friend
00.57.33 #       <crash_> waiting for response
01.03.12 #       <crash_> ok Zagor is right it's a joystick and you can push it in 4 directions
01.03.50 #       <Zagor> but not in?
01.05.02 #       <crash_> aehm sorry
01.05.09 #       <crash_> sure u can push him
01.05.10 #       <crash_> ;)
01.08.04 #       <gromit`> jyp
01.08.10 #       <gromit`> lafouine has a xs hasn't he ?
01.09.01 #       <jyp> iirc
01.09.04 #       <jyp> yes
01.10.19 #       <jyp> nite!
01.10.22 Quit    jyp ("Leaving")
01.18.53 Join    BBub [0] (~belzebub1@dsl-213-023-068-136.arcor-ip.net)
01.23.31 #       <Zagor> aha, the pma400 (ex av500) is officially linux based. that's nice.
01.25.43 Quit    _aLF ("Leaving")
01.26.42 #       <Zagor> ooh, keyboard and ethernet available. nice little machine!
01.27.47 #       <crash_> url ?
01.27.56 #       <Zagor> http://www.archos.com/products/prw_500594_specs.html
01.28.03 #       <crash_> thx
01.28.18 #       <Zagor> http://www.archos.com/pma400_mws/pma400_mws_accessories.html
01.29.42 #       <crash_> thats really nice
01.29.59 #       <crash_> seems like coming all portable devices togehter
01.30.09 #       <Zagor> yeah. surprisingly low screen resolution though. and very expensive!
01.31.08 #       <crash_> 3,5" and 320x240 ? uh
01.33.09 #       <Zagor> it's not bad, but the palms are up to 320x480
01.34.23 #       <crash_> its the question how each of these companies understands "linux-based"
01.37.04 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
01.47.28 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
01.47.28 #       * crash_ is just formating his archos 6k jukebox cause he sold it for 100euro on ebay ;)
01.57.21 Quit    Zagor ("Client exiting")
02.00.53 Quit    mecraw__ ("Trillian (http://www.ceruleanstudios.com)")
02.31.05 ***     Saving seen data "./dancer.seen"
04.31.08 ***     No seen item changed, no save performed.
05.03.12 Quit    Nibbler ("¿")
05.11.45 Quit    einhirn (Read error: 60 (Operation timed out))
05.25.54 Quit    DMJC (Read error: 110 (Connection timed out))
05.41.46 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
06.31.09 ***     Saving seen data "./dancer.seen"
06.49.20 Join    methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk)
07.03.33 Part    amiconn
07.06.28 Quit    midk (Read error: 110 (Connection timed out))
07.51.14 Join    esc [0] (~esc@d47-69-188-130.nap.wideopenwest.com)
07.53.02 #       <esc> hi
07.53.12 Part    esc ("Leaving")
08.31.13 ***     Saving seen data "./dancer.seen"
08.59.16 Join    LePoulpe [0] (~lpos@AMontpellier-251-1-31-176.w83-113.abo.wanadoo.fr)
08.59.46 #       <LePoulpe> hi all
09.06.37 Join    SoulEata [0] (faccess@68.113.221.198.ts46v-02.mhe2.ftwrth.tx.charter.com)
09.07.10 #       <SoulEata> sup
09.17.06 Join    Vetinari [0] (~happycake@c-67-170-176-227.client.comcast.net)
09.17.13 Part    Vetinari
09.32.10 Quit    courtc (Read error: 60 (Operation timed out))
09.40.20 Join    courtc [0] (~court@adsl-33-164-40.asm.bellsouth.net)
10.06.27 Join    MooMaunder [0] (~me@194.152.87.150)
10.10.22 Join    bobTHC [0] (~foo@l03v-34-115.d1.club-internet.fr)
10.10.25 #       <bobTHC> hi all
10.11.44 #       <bobTHC> have u seen the last announce of Archos
10.12.24 #       <bobTHC> a pda based on the AV400
10.12.41 #       <bobTHC> on linux
10.12.44 #       <bobTHC> http://www.archos.com/products/prw_500594_specs.html
10.13.05 #       <bobTHC> nice stuff
10.15.14 #       <bobTHC> a bit expensive and surely a bad battery autonomy
10.16.57 #       <bobTHC> french ppl can have more info @ http://www.jbmm.net/forum/sujet-3040.html
10.23.09 Quit    Bagder (Read error: 110 (Connection timed out))
10.23.26 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
10.27.05 Join    amiconn [0] (~jens@pD9E7EA15.dip.t-dialin.net)
10.31.16 ***     Saving seen data "./dancer.seen"
10.31.32 Join    einhirn [0] (~Miranda@carlsberg.heim2.tu-clausthal.de)
10.33.07 #       <bobTHC> a rockbox for gmini 120 is on the way ??
10.41.53 Quit    LePoulpe (Read error: 104 (Connection reset by peer))
10.43.38 Join    LePoulpe [0] (~lpos@AMontpellier-251-1-31-176.w83-113.abo.wanadoo.fr)
10.50.00 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
10.56.34 Join    jyp [0] (~jp@30.213-136-217.adsl.skynet.be)
11.07.37 #       <Bagder> bobTHC: hopefully, yes
11.10.10 #       <Lynx_> i have the artist name in the filenames first. so if the artist name is rather long, i have to wait for the song name to scroll by when searching for something. Do you guys think it would make sense to include a "shorten" feature which for example takes out all the vowels from the names?
11.11.07 #       <Bagder> Lynx_: its been discussed many times in the past, but I don't think any approach has gotten concensus as "they way" yet
11.11.27 #       * Bagder takes off
11.11.31 #       <Lynx_> ah. would it be a lot of work to include that?
11.12.13 #       <Bagder> probably not
11.12.26 #       <Bagder> the big deal is to find the approach many ppl favour
11.12.43 #       <Lynx_> what are the other options?
11.13.09 #       <Bagder> there have been many alternatives suggested
11.13.16 #       <Bagder> I don't remember all of them right now
11.13.29 #       <Bagder> gotta go
11.13.56 #       <Lynx_> cu
11.22.41 #       <bobTHC> Bagder: thx, new devices are good news for spreading the rockbox
11.30.52 Quit    LePoulpe (Read error: 104 (Connection reset by peer))
12.09.35 Join    Lynx0 [0] (HydraIRC@134.95.189.59)
12.22.31 Quit    Lynx_ (Nick collision from services.)
12.22.53 Nick    Lynx0 is now known as Lynx_ (HydraIRC@134.95.189.59)
12.29.15 #       <amiconn> Bagder: Regarding the "scroll wait" - imho it would help a lot if the recorders also get a jump scroll feature like the players.
12.31.20 ***     Saving seen data "./dancer.seen"
12.38.28 #       <Lynx_> does jump scroll mean the text is displayed in two alternating parts?
12.43.23 #       <amiconn> Jump scroll means that the text scrolls in steps equal to the display width, showing each display-width part a configurable time
12.44.08 #       <amiconn> This is implemented on the player. If activated, the text scrolls <n> times with jump scroll, then switches over to regular scroll.
12.47.14 #       <Lynx_> ok, i see. that would be nice, instead the of the shorten function for example.
14.10.00 Join    webguest36 [0] (~d5712586@labb.contactor.se)
14.10.59 Quit    webguest36 (Client Quit)
14.22.50 Join    lImbus [0] (~manuel@kernel.cycos.net)
14.24.58 Quit    MooMaunder (Read error: 110 (Connection timed out))
14.31.22 ***     Saving seen data "./dancer.seen"
14.38.10 Join    sosh [0] (~3e9e4d6f@labb.contactor.se)
14.38.41 #       <sosh> hi everyone !
14.42.34 #       <lImbus> hi
14.43.59 #       <sosh> first off all, i wanna say, i love rockbox and a big thanx too all ppl behind rockbox!
14.46.09 #       <sosh> i've got an technical question on my ajb recorder. may i ask it in here ?!
14.46.42 Quit    bobTHC (Read error: 60 (Operation timed out))
14.47.30 Quit    Lynx_ (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!")
14.55.12 Join    omri02 [0] (~blabla@bzq-218-212-17.red.bezeqint.net)
14.55.15 #       <omri02> hey everyone
14.55.17 #       <omri02> whos here?
14.55.28 #       <lImbus> sosh: you may try. I am quite busy, but I can try to respond
14.55.37 #       <lImbus> hi omri02
14.55.41 #       <omri02> hi
14.56.06 #       <omri02> are you active in the iriver rockbox port?
14.57.26 #       <omri02> ?
14.57.38 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
14.57.57 #       * omri02 drives over lImbus
14.58.03 #       <omri02> :P
14.58.25 #       * omri02 slaps lImbus around with Windows Me
14.59.22 #       <BBub> omri02: take a look on the homepage
14.59.29 #       <BBub> it should answer all your questions
15.00.22 #       <sosh> thnx lImbus!  i got two AJB Recorders 20 wich i thought, thy are identically. but on one Recorder the remote works, on the other the remote dosn't. :-(
15.01.36 #       <sosh> i got the CDC Simulator from Matthias Klumpp in my car. wich works fine with the one, the other one dosnt.
15.01.53 #       <sosh> both recorders with Rockbox 2.3
15.02.19 #       <sosh> are there different Hardware Versions ?
15.03.03 Join    MooMaunder [0] (~me@194.152.87.150)
15.04.16 #       <omri02> hey
15.04.48 #       <omri02> well, it actualy didnt
15.05.00 #       <omri02> one thing is, i wanted to know how the port is going
15.05.14 #       <omri02> and thay say in the forums that the wiki isnt updated
15.05.31 #       <omri02> and the other was wanting to know if you need any hardware contributions
15.05.43 #       <omri02> since i spend alot of time in the conexant labs
15.05.51 #       <omri02> i might be able to get some stuff....
15.06.23 #       * lImbus wakes up
15.06.34 #       <omri02> morning
15.06.36 #       <omri02> :P
15.07.17 #       <lImbus> omri02: only a few people are working on the iRiver port. Namely LinusN
15.07.31 #       <lImbus> Zagor and Bagder see him daily, so they are on track as well
15.07.52 #       <omri02> well, you know when thay might be here?
15.07.55 #       <lImbus> That hardware-contribution-thingy may be VERY intresting. Try to bug them :-)
15.08.03 #       <lImbus> no, I don't know anything.
15.08.22 #       <omri02> allso, do you know if there is anyone here in israel?
15.08.31 #       <omri02> that is a part of the project that is
15.08.34 #       <lImbus> mhmm. not that I know
15.08.37 #       <omri02> i whold love to contribute...
15.08.57 #       <lImbus> yeah
15.09.07 #       <omri02> am a programer with some knolidge in asm but never programed embedded, sounds perty intrasting
15.09.31 #       <lImbus> it actually is
15.09.55 #       <omri02> are you an embedded programer
15.09.56 #       <omri02> ?
15.10.00 #       <lImbus> sosh: http://www.rockbox.org/docs/devicechart.html
15.10.01 #       <omri02> where are you from?
15.10.07 #       <lImbus> this shows all devices
15.10.16 #       <lImbus> omri02: belgium/germany
15.10.29 #       <omri02> ok
15.10.37 #       <lImbus> sosh: if the devices look the same, it should work on both
15.10.37 #       <omri02> are you a programer?
15.10.58 #       <lImbus> yup, but I did not yet contribute actively to rockbox-code
15.12.09 #       <lImbus> omri02: see this for a progress-indicator: http://www.rockbox.org/twiki/bin/view/Main/IriverPort
15.12.13 #       <sosh> Thnx  lImbus !!
15.12.29 #       <lImbus> sosh: what ? thats all ? problem solved ?
15.12.39 #       <omri02> yea, i sow that but its kinda out of date...
15.12.56 #       <sosh> hm . now i know that i need to search some bended pin or such ..
15.13.01 #       <omri02> i sow a post in the forums with a more advanced screenshot
15.13.10 #       <lImbus> oh, yeah, of course
15.13.28 #       * lImbus gets to get some cookies, as there is a coworker celebrating his birthday.
15.13.29 #       <sosh> lImbus: you speak german ?
15.13.47 #       <omri02> http://bjorn.haxx.se/iriver_display.jpg
15.13.49 Join    LePoulpe [0] (~lpos@AMontpellier-251-1-31-32.w83-113.abo.wanadoo.fr)
15.21.22 Join    sosh_ [0] (~sosh@p3E9E4D6F.dip.t-dialin.net)
15.22.02 Quit    sosh ("CGI:IRC (EOF)")
15.22.08 Nick    sosh_ is now known as sosh (~sosh@p3E9E4D6F.dip.t-dialin.net)
15.23.34 #       <amiconn> [IDC]Dragon: r u there?
15.24.13 #       <[IDC]Dragon> yes
15.26.38 Join    elinenbe [0] (~elinenbe_@65.115.46.225)
15.27.05 #       <elinenbe> bonjour
15.28.00 #       <jyp> Guten tag
15.30.38 #       <lImbus> sosh: yes, I speak german
15.30.58 Quit    LePoulpe ()
15.33.10 #       <sosh> nice ;) so i dont need to gon on with my bad english 
15.38.58 #       <amiconn> [IDC]Dragon: I took a  look at the alternative boot rom from this odd player. It did not yet analyze the details, but it seems this is a newer rom
15.39.33 #       <amiconn> It contains some more code, but the crucial routines (descramble, uart boot etc) look like they are the same
15.40.19 #       <amiconn> Only the first ~6000 bytes are used, and the unused area is zeroed (not 0xFF as with the old rom)
15.42.40 #       <[IDC]Dragon> did  you see a uart boot?
15.42.50 #       <[IDC]Dragon> ah, sorry
15.42.59 #       <elinenbe> which player is this?
15.43.02 #       <[IDC]Dragon> overlooked that
15.43.25 #       <[IDC]Dragon> so we can emable that CRC
15.44.32 #       <[IDC]Dragon> what tells you it's newer?
15.50.18 #       <sosh> hm. can anybody definitly say, that there no different Hardware versions on the Jukebox Recorder 20 sold ?
15.51.48 #       <sosh> are there schematics  for the recorder 20 v1 available ?
15.53.18 #       <amiconn> [IDC]Dragon: I only guess it's newer because there is more code
15.53.59 #       <amiconn> I plan to do a more thorough analysis in the evening
16.02.06 #       <[IDC]Dragon> the fact that the Ondio also has our "classic" bootloader leads me to believe the exotic one is older
16.02.18 #       <[IDC]Dragon> but, it doesn't matter at all
16.06.48 #       <lImbus> sosh: no, nobody can say. from what we know, any recorder v1 has remote-support. self-made shematics would be in the wiki, if we had.
16.07.33 #       <lImbus> sosh: http://www.rockbox.org/schematics/
16.07.51 Part    omri02
16.09.33 #       <sosh> IImbus: i found out, that the serial remote is connectet to the Port B 10 / RxD1, i'll check this , when i found the Port b  ;)
16.10.02 Join    adi|hotel [0] (~chatzilla@12.109.187.2)
16.19.05 Quit    adi|hotel ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]")
16.20.03 #       <lImbus> sosh: good luck
16.21.04 #       <sosh> thnx ;) 
16.25.02 #       <amiconn> [IDC]Dragon: If this is an old boot rom, I wonder why the flash of this box is rather new (5.06/5.08, same as mine)
16.26.22 #       <sosh>  lImbus: refering to the doc its pin109 of the SH-1 beast ...
16.27.21 #       <lImbus> dunno, never had a look at that
16.31.25 ***     Saving seen data "./dancer.seen"
16.44.55 #       <elinenbe> amiconn, [IDC]Dragon: do either of you have the iriver player?
16.53.05 #       <amiconn> Not me
16.56.14 Join    mecraw__ [0] (~lmarlow@69.2.235.2)
17.02.11 #       <[IDC]Dragon> nope
17.39.20 Join    Spida [0] (Spida@pD952C152.dip.t-dialin.net)
17.46.44 Join    zeekoe [0] (me@vpn007085.vpn.utwente.nl)
17.51.37 Quit    Spida_ (Read error: 110 (Connection timed out))
18.20.35 Quit    jyp ("Leaving")
18.26.19 Part    lImbus
18.26.58 Join    Nibbler [0] (~andrer@port-212-202-73-11.dynamic.qsc.de)
18.31.26 ***     Saving seen data "./dancer.seen"
18.40.50 #       <sosh> ok. i did some measurement.
18.41.25 #       <sosh> the remote must be connectet to pin 116   (, not 109, was my fault)
18.42.24 #       <sosh> the recorder, wich remote dosnt work got a resistence of 2k ohm between the ear phone serial remote pin and the Pin 116
18.42.57 #       <sosh> and the workin recorder got a resistence oh 0 (zero) ohm
18.45.03 #       <sosh> and there layout is a little different different..
18.47.25 #       <sosh> lImbus: what do you think? 
18.57.39 Join    pfavr [0] (~Peter_Fav@213.237.46.232.adsl.ron.worldonline.dk)
19.05.58 #       <[IDC]Dragon> sosh: I think you can fix it  :-)
19.09.38 #       <sosh> i'am only a litte bit confused.  theres seem to be no restitor between the SH-1 Pin and the *outside world* , isnt that a little bit unsecure ?
19.10.42 #       <sosh> my electronic skills arn't that good, but in most cases there are resistors to the outside world to prevent to much current ?!
19.18.19 #       <[IDC]Dragon> you won't find resistors on the outher interface pins, neiter
19.18.54 #       <[IDC]Dragon> sometimes inductors, to prevent EMC to travel in and out
19.19.32 #       <sosh> hm ok. but even an inductor must have some ohms ?
19.19.56 #       <[IDC]Dragon> many of the FM models have no remote option, but only lack a zero ohm resistor, everything else is prepared
19.21.01 #       <[IDC]Dragon> so I suggest tracing from jack to PB10, maybe you find an empty footprint
19.21.42 #       <sosh> pardon my bad english, what means *lack ?
19.21.57 #       <[IDC]Dragon> missing
19.22.13 #       <sosh> thnx 
19.23.00 #       <sosh> i'll try to solde a direct cable between PB10 and the ear jack
19.23.12 #       <[IDC]Dragon> that'll do
19.24.16 #       <sosh> thnx. i'll let you know what happend ;)
19.30.56 #       <amiconn> [IDC]Dragon, Bagder: I just had an idea how to prevent unnecessary disk spinups on shutdown.
19.31.20 #       <[IDC]Dragon> yes?
19.31.37 #       <amiconn> The spinup is there to save the config, but we only need to save if something really changed.
19.32.31 #       <amiconn> So we could calculate a checksum across the config block (or global settings structure, doesn't matter which one) directly after loading the settings.
19.33.10 #       <[IDC]Dragon> ah, ok, I'm glad you didn't want to back it up
19.33.42 #       <amiconn> This checksum will only be updated if the configuration gets saved.
19.33.56 #       <[IDC]Dragon> that CRC routine should be exported into a module, it's useful at various places
19.34.14 #       <[IDC]Dragon> I already regret doing only a CRC16
19.34.20 #       <amiconn> On shutdown, we calculate the checksum again and compare with the stored one. The config gets only saved when there is a difference
19.35.17 #       <amiconn> You do have a crc32 routine, don't you? (Iirc it's in the flash plugin(s))
19.35.46 #       <[IDC]Dragon> yes
19.35.58 #       <amiconn> Rather than doing the calculate and compare on shutdown only, this could be done in the config save itself, only saving if something changed
19.36.14 #       <[IDC]Dragon> but the boot rom CRC is already popular in 16 bit
19.36.30 #       <[IDC]Dragon> btw, the settings already have a checksum
19.36.38 #       <[IDC]Dragon> a primitive one
19.36.45 #       <amiconn> Yes it is, but there is nothing that prevents us to calculate a crc32 and switch over
19.36.56 #       <[IDC]Dragon> we could change that into a CRC
19.38.06 #       <amiconn> I vaguely remember that the config block is pretty much filled up, but when I checked my disk images while searching for the fat16 problems, I found it isn't.
19.38.34 #       <amiconn> The config block is defined to be 256 bytes, but one sector has twice the space...
19.38.38 #       <[IDC]Dragon> the RTC is, not the sector
19.38.59 #       <amiconn> RTC is much smaller, I know
19.41.02 #       <amiconn> The config block checksum is 16 bit
19.41.31 #       <[IDC]Dragon> so we could change this into a CRC16
19.41.54 Quit    Nibbler ("reboot")
19.42.07 #       <[IDC]Dragon> ah, no
19.42.27 #       <[IDC]Dragon> it's the checksum across the RTC part only (I guess)
19.42.30 #       <amiconn> ...and is calculated across the RTC block only, which is the opposite of what we need for the HD settings.
19.43.10 #       <amiconn> We would need 2 checksums, one across the RTC part, and one across the HD part (resp. across both parts for units without RTC)
19.43.35 Quit    pfavr ("ChatZilla 0.9.61 [Mozilla rv:1.7.5/20050105]")
19.44.26 #       <[IDC]Dragon> the RTC part is on the HD, too
19.44.39 #       <[IDC]Dragon> so you only need that
19.45.44 #       <amiconn> That would be sub-optimal, because if (on units with RTC) only RTC settings are changed, we wouldn't need to save the HD settings
19.46.23 Join    sosh__ [0] (~sosh@p3E9E4B30.dip.t-dialin.net)
19.46.45 #       <[IDC]Dragon> we do, because on boot the RTC part gets overloaded by the HD sector, iirc
19.47.14 #       <[IDC]Dragon> sorry, can't be
19.47.33 #       <[IDC]Dragon> else the resume info, etc, would be useless
19.48.28 #       <amiconn> Btw, in order to implement my idea the checksum does not need to be stored on disk, or within the RTC.
19.49.10 #       <amiconn> The RTC-stored checksum is there only to detect invalid config blocks (because either the block format changed, or the RTC is cleared from power loss etc)
19.49.21 #       <[IDC]Dragon> yes, that's true
19.50.01 #       <[IDC]Dragon> still, a CRC16 there would be better than a plain 16 bit checksum
19.50.02 #       <amiconn> But the checksum(s) could be used for both purposes...
19.51.21 #       <amiconn> Of course.
19.52.15 #       <[IDC]Dragon> except for speed
19.52.37 #       <[IDC]Dragon> this checksum must get written with every RTC update?!
19.52.54 #       <[IDC]Dragon> which is every second during playback, iirc
19.53.29 #       <[IDC]Dragon> btw, there are more configs in other sectors
19.53.38 #       <amiconn> Yes, but I don't think this is a problem.
19.53.52 #       <[IDC]Dragon> e.g. the pathname of the current file
19.54.09 #       <amiconn> ???
19.54.25 #       <[IDC]Dragon> all which requires a full path and is not of fixed, short length
19.54.39 #       <[IDC]Dragon> but I never looked into that
19.55.08 #       <[IDC]Dragon> I only remember Linus saying so
19.55.32 #       <amiconn> I do only know exactly one config sector, which has the delayed write. The currently playing playlist is controlled by the playlist control file, and the resume position is *not* stored as a path
19.55.43 #       <amiconn> ...but only as an index into the playlist
19.56.02 #       <[IDC]Dragon> maybe that has changed meanwhile
19.56.19 #       <[IDC]Dragon> my knowledge is older than the playlist control file
19.57.03 #       <[IDC]Dragon> in general, the "trend" was to move away from this special sector, in favour of a plain config file
19.57.31 Quit    mecraw__ (Read error: 104 (Connection reset by peer))
19.57.42 #       <[IDC]Dragon> has the advantage that you can delete it from USB to get rid of malicious settings
19.57.48 Join    mecraw__ [0] (~lmarlow@69.2.235.2)
19.58.25 #       <[IDC]Dragon> I still want to implement that "use only default settings" boot hotkey
19.58.49 #       <[IDC]Dragon> like a safe mode, but we have no F4  ;-)
20.00.05 #       <amiconn> As long as I code for rockbox, the playlist and resume mechanism has always been the same.
20.00.13 #       * [IDC]Dragon needs to leave
20.00.30 #       <amiconn> I just checked cvs; the resume index was there since August 2002 or so
20.00.49 #       <[IDC]Dragon> and the control file?
20.01.56 #       <amiconn> Need to check, but I believe this is even older
20.02.36 #       <amiconn> The control file does only need updating when you change the playlist itself (add, delete etc), not while just playing
20.02.36 #       <[IDC]Dragon> I really gotta go, cu
20.02.41 #       <amiconn> l8er
20.02.47 Quit    [IDC]Dragon ("CGI:IRC")
20.04.28 Quit    sosh (Read error: 110 (Connection timed out))
20.09.02 Join    Nibbler [0] (~andrer@port-212-202-73-11.dynamic.qsc.de)
20.19.00 Join    markuman [0] (~markuman@pD9E4C996.dip.t-dialin.net)
20.21.48 #       <markuman> sry. what is rockbox?
20.22.06 #       <webmind> opensource firmware
20.22.15 #       <webmind> made originally for the archos jukebox
20.22.55 #       <markuman> oh...ok. thx
20.23.23 #       <webmind> np
20.24.19 Part    markuman ("Verlassend")
20.27.11 Nick    sosh__ is now known as sosh (~sosh@p3E9E4B30.dip.t-dialin.net)
20.31.30 ***     Saving seen data "./dancer.seen"
20.31.33 Join    jyp [0] (~jp@30.213-136-217.adsl.skynet.be)
20.33.26 Join    Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com)
20.36.53 #       <zeekoe> help! :-/
20.37.07 #       <zeekoe> i get a I09: CPUAdrEr
20.37.12 #       <zeekoe> what do i do wrong?
20.38.18 #       <zeekoe> i added an extra setting in the menu, but when i enter the menu item, i get this
20.49.12 #       <amiconn> Do you get a warning when you compile this?
20.49.34 #       <amiconn> The settings functions make extensive use of pointers.
20.50.10 #       <amiconn> Perhaps you hand one such function a value where it expects a pointer.
20.52.31 Quit    einhirn (Read error: 104 (Connection reset by peer))
20.59.01 #       <zeekoe> no warnings at all
21.01.13 #       <zeekoe> so it's something with pointers?
21.01.30 #       <zeekoe> hmm.. my mommy says i need to drink tea...
21.01.34 #       <zeekoe> btw, here's the diff
21.01.37 #       <zeekoe> http://home.student.utwente.nl/r.teune/autoloadconfig.diff
21.02.00 #       <amiconn> I think so. Pointers are 32 bit (long) values, and the SH1 CPU doesn't like it if long values are not 32 bit aligned.
21.02.36 Part    Bluechip
21.02.36 #       <zeekoe> ok
21.05.40 #       <amiconn> zeekoe: The problems is most likely in static bool autoloadconfig(void)
21.06.01 #       <amiconn> Your new setting is a boolean setting (yes/no), and has to be handled as such
21.06.35 #       <amiconn> This is even much simpler, look at e.g. static bool status_bar(void)  how this is done
21.07.37 #       <amiconn> In your implementation, you hand the settings function a pointer to a bool, but tell it that this is an int pointer...
21.08.05 #       <amiconn> static bool autoloadconfig(void)
21.08.06 #       <amiconn> {
21.08.55 Quit    Nibbler (Read error: 54 (Connection reset by peer))
21.08.58 #       <amiconn>     return set_bool( str(LANG_AUTOLOADCONFIG), &global_settings.autoloadconfig );
21.09.01 #       <amiconn> }
21.10.49 #       <zeekoe> that's easy...
21.12.19 Join    Nibbler [0] (~andrer@port-212-202-73-11.dynamic.qsc.de)
21.12.24 #       <zeekoe> the compiler likes it, for a start
21.16.20 #       <zeekoe> it works :)
21.16.24 #       <zeekoe> thanks!
21.24.58 Join    Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com)
21.45.23 Join    mecraw_ [0] (~lmarlow@69.2.235.2)
21.45.23 Quit    mecraw__ (Read error: 104 (Connection reset by peer))
21.57.03 Quit    BBub (""Fange nie an aufzuhören. Höre nie auf anzufangen." - Tiki")
22.14.34 Join    [IDC]Dragon [0] (~d95128d4@labb.contactor.se)
22.14.46 #       <[IDC]Dragon> hi again
22.14.57 #       <amiconn> re
22.15.03 #       <[IDC]Dragon> I should install an IRC client on this notebook
22.15.28 #       <[IDC]Dragon> on the desktop, I have mirc, but don't like it too much
22.15.37 #       <[IDC]Dragon> any recommendations?
22.15.49 #       * Bagder uses xchat, even on windows
22.15.52 #       <amiconn> I'm using HydraIRC. Imho it's quite good
22.16.54 #       <amiconn> I was slightly wrong concerning the playlist control file. This was added with dynamic playlists, on 1 Jul 2003
22.20.53 #       <amiconn> I tried Xchat before; I didn't like it...
22.22.45 #       <[IDC]Dragon> me neither
22.28.06 Join    [IDC]Dragon2 [0] (~Joerg@pD95128D4.dip.t-dialin.net)
22.28.50 #       <[IDC]Dragon2> lots of stuff on screen here in HydraIRC
22.29.58 #       <amiconn> Yup. But you can group, fold or disable any of these additional windows - very flexible
22.30.00 #       <[IDC]Dragon2> better now,  I clicked most of it away
22.30.17 #       <[IDC]Dragon> bye CGIIRC
22.30.21 Part    [IDC]Dragon
22.31.31 #       <elinenbe> amiconn: HydraIRC is VERY nice.... tight, clean, and quick
22.31.35 ***     Saving seen data "./dancer.seen"
22.32.17 #       <[IDC]Dragon2> how do I change my nick? set |away?
22.34.50 Nick    [IDC]Dragon2 is now known as [IDC]Dragon (~Joerg@pD95128D4.dip.t-dialin.net)
22.35.20 #       <[IDC]Dragon> ... that was a plain /nick command
22.39.03 #       <elinenbe> [IDC]Dragon: you are on windows/
22.40.06 #       <[IDC]Dragon> ?
22.48.29 Join    zeekoe_ [0] (HydraIRC@vpn007085.vpn.utwente.nl)
22.48.59 Quit    zeekoe ()
22.49.37 Nick    zeekoe_ is now known as zeekoe (HydraIRC@vpn007085.vpn.utwente.nl)
22.51.05 #       <amiconn> [IDC]Dragon: There are no strings in either bootrom :-/
22.51.34 #       <[IDC]Dragon> you mean, like a version?
22.51.40 #       <amiconn> Yes
22.51.45 #       <[IDC]Dragon> for ours, I know
22.52.01 #       <amiconn> Really?
22.52.09 #       <[IDC]Dragon> don't worry too much
22.52.39 #       <[IDC]Dragon> if it does the same, we should just enable the CRC
22.53.24 #       <amiconn> The alternate boot rom seems to have garbage where the 0xFF spaces are in the known one, except after ~6000 bytes it is zeroed out
22.53.53 #       <amiconn> The main() routine is a little longer
23.01.37 Quit    mecraw_ ("Trillian (http://www.ceruleanstudios.com)")
23.09.25 Quit    zeekoe (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool")
23.12.49 Join    quelsaruk [0] (~506781ee@labb.contactor.se)
23.12.54 #       <quelsaruk> hi
23.12.56 #       <quelsaruk> good night
23.13.22 #       <[IDC]Dragon> hi
23.13.38 #       <amiconn> [IDC]Dragon: There is more code *before* the main() routine...
23.14.27 #       <[IDC]Dragon> (no idea how to do highlighting in hydrairc)
23.15.39 #       <amiconn> Options->Prefs..., then Buddy Groups->Notifications
23.16.06 #       <amiconn> This takes regexps, can colour the highlight text or the line, play a sound...
23.21.54 #       <SoulEata> so is rockbox looking into the h3xx series at all?
23.22.43 #       <Bagder> SoulEata: rockbox is many independent humans
23.23.13 #       <Bagder> we focus on the h1xx to start with
23.23.14 #       <SoulEata> right but as a group I'm sure they decide what to work on next
23.23.38 #       <Bagder> you can affect when the work on the h3xx starts
23.23.41 #       <Bagder> everyone can
23.24.15 #       <SoulEata> and hows that
23.24.16 #       <Bagder> there's another group of people working with the gmini
23.24.27 #       <Bagder> SoulEata: research it
23.24.50 #       <Bagder> do the same work on the 3xx that is being done on the 1xx
23.25.26 #       <Bagder> we are but all volounteers and spare time hackers
23.25.56 #       <SoulEata> yeah I know. Do you plan on working on the h3xx after the h1xx though?
23.26.19 #       <Bagder> perhaps
23.26.27 #       <Bagder> if we get enough help
23.26.40 #       <Bagder> we've bought 1xx players to work on
23.26.44 #       <SoulEata> yeah
23.26.46 #       <amiconn> [IDC]Dragon: The InitMem/CopyMem routines are strange...
23.27.12 #       <SoulEata> hows the 1xx work going?
23.27.23 #       <Bagder> slow, but progressing
23.27.40 #       <SoulEata> whats the largest progression you think has been made thus far
23.28.01 #       <quelsaruk> amiconn: sorry to bother you again with the HOWTO question, but... do you have some kind of .voice file howto? :D i'll never give up :P
23.28.07 #       <Bagder> SoulEata: you mean that is irivier-specific?
23.28.25 #       <SoulEata> yeah
23.28.32 #       <amiconn> quelsaruk: Hrrrrmmm, still nothing :(
23.28.37 #       <Bagder> just the fact that we can boot, flash and run on the unit
23.28.53 #       <Bagder> all thanks to Linus' hard work
23.29.41 #       <quelsaruk> amiconn: do you have some notes or anything that could help me? i could try to make the howto if you give me some indications and a start point on how to make a .voice file :)
23.31.08 #       <amiconn> There is the old rough readme on [IDC]Dragon's web space. However, I refined the process quite a bit (plus some special case that is unhandled in the old description).
23.31.23 #       <amiconn> I also refined the tools, and made a VBScript
23.32.24 #       <quelsaruk> maybe with your refined tools and [IDC]Dragon old readme i can mess a bit and make it work :)
23.32.25 #       <amiconn> [IDC]Dragon: Your CopyMem disassembly is slightly wrong
23.33.13 #       <[IDC]Dragon> highlight still not working
23.34.30 #       <[IDC]Dragon> amiconn: I don't care any more, boot ROM chapter on the "classic" one is closed  ;-)
23.35.18 #       <quelsaruk> ( [IDC]Dragon i use kvirc, just in case you want to test. It has highlight and a small pop-up screen that appears when someones calls you or query you)
23.35.29 Quit    [IDC]Dragon (Read error: 54 (Connection reset by peer))
23.37.22 Join    [IDC]Dragon [0] (~Joerg@pD95128D4.dip.t-dialin.net)
23.37.49 #       <[IDC]Dragon> hydrairc crashed on me
23.38.11 #       <[IDC]Dragon> but good night anyway
23.38.18 Quit    [IDC]Dragon (Client Quit)
23.38.34 #       <amiconn> I never managed to crash Hydra, strange...
23.39.06 Quit    jyp (Read error: 104 (Connection reset by peer))
23.40.17 Join    jyp [0] (~jp@79.20-136-217.adsl.skynet.be)
23.41.18 Join    jyp_ [0] (~jp@79.20-136-217.adsl.skynet.be)
23.42.59 Quit    sosh ("------ EOF ------")
23.45.25 #       <quelsaruk> amiconn: what's your answer?
23.49.25 #       <amiconn> I hope to get a wiki article done asap. Currently I'm busy analyzing that alternate boot rom :(
23.50.07 #       <quelsaruk> ok, don´t worry :)
23.51.12 #       <quelsaruk> then, going to sleep! cu another day!
23.51.16 Part    quelsaruk