--- Log for 22.11.104  Server: niven.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 12 days and 2 hours ago

00.03.39 #       <s0cks> Hi midk
00.03.42 #       <s0cks> How goes?
00.05.56 #       * Bagder heard Linus now has the FAT code working on the iriver
00.06.13 #       <s0cks> FAT is good.
00.06.23 #       <s0cks> Why is he trying to partition a flash player?
00.06.32 #       <Bagder> ?
00.06.44 #       <s0cks> File Allocation Table?
00.07.01 #       <Bagder> FAT32 == file system
00.07.50 ***     Saving seen data "./dancer.seen"
00.08.15 #       <s0cks> fat = file system also.
00.08.59 #       <Bagder> well, we use the flavour of fat often called fat32
00.09.31 #       <Bagder> except on the ondio where we use fat16 (too?)
00.10.09 #       <amiconn> Bagder: yes.
00.10.25 #       <Bagder> ok
00.10.33 #       <amiconn> (Actually MMCs are usually FAT16, but FAT32 is also supported)
00.11.32 #       <s0cks> Sweet. Are they coming out with fat64? or has everyone left fat for something else?
00.15.39 #       <Bagder> we don't have to care about that
00.16.46 #       <s0cks> Meg.
00.16.49 #       <s0cks> h*
00.16.52 #       <s0cks> Just wondering
00.27.45 Join    kurzhaarrocker [0] (~none@c-134-124-218.d.dial.de.ignite.net)
00.38.34 Quit    _aLF ("Leaving")
00.38.35 Quit    kurzhaarrocker (Read error: 104 (Connection reset by peer))
00.48.29 Quit    midk ("just STOP it arspy")
00.50.05 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
00.50.41 Nick    AciD is now known as AciD` (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
00.51.09 Nick    AciD` is now known as AciD (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
00.52.40 Nick    AciD is now known as AciD` (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
00.52.49 Part    s0cks ("Leaving")
00.52.52 Nick    AciD` is now known as AciD (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
00.54.10 Quit    adi|ems (Read error: 110 (Connection timed out))
00.59.24 Quit    AciD (Read error: 104 (Connection reset by peer))
01.46.37 Quit    midk ("just STOP it arspy")
01.51.42 Join    gromit`grosse`MA [0] (~gromit@m117.net81-65-8.noos.fr)
01.51.42 Quit    gromit (Read error: 54 (Connection reset by peer))
01.51.43 Quit    gromit`grosse`MA (Remote closed the connection)
01.52.03 Join    gromit [0] (~gromit@m117.net81-65-8.noos.fr)
01.52.13 Part    gromit
02.07.51 ***     Saving seen data "./dancer.seen"
02.38.30 Join    amiconn_ [0] (~jens@pD9E7F5B7.dip.t-dialin.net)
02.43.03 Quit    amiconn (Nick collision from services.)
02.43.03 Nick    amiconn_ is now known as amiconn (~jens@pD9E7F5B7.dip.t-dialin.net)
02.52.39 Join    adi|ems [0] (~chatzilla@ool-43544fe0.dyn.optonline.net)
02.53.00 Quit    adi|ems (Client Quit)
03.03.51 Part    amiconn
03.50.32 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
04.07.52 ***     Saving seen data "./dancer.seen"
05.55.54 Quit    Stryke` ("Friends don't let friends listen to Anti-Flag")
06.07.55 ***     Saving seen data "./dancer.seen"
06.46.16 Quit    midk ("just STOP it arspy")
07.13.29 Join    AciD [0] (~gni@acid.user)
07.28.28 Join    gromit`_ [0] (augej@ulysse.iiens.net)
07.31.31 Join    midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
07.31.33 Join    LinusN [0] (~linus@labb.contactor.se)
07.38.18 #       <dwihno> Welcome \o/
07.38.26 #       <dwihno> I hope you did enjoy your weekend.
07.41.48 #       <LinusN> oh yes
07.45.02 Quit    gromit` (Read error: 110 (Connection timed out))
07.48.45 Join    oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net)
07.50.03 #       <dwihno> \o/
08.00.52 Part    oxygen77 ("Cho")
08.07.56 ***     Saving seen data "./dancer.seen"
08.26.25 Join    Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
08.30.01 #       <LinusN> morning Bagder
08.30.04 #       <LinusN> morning Bagder_
08.30.06 #       <LinusN> bla
08.30.09 #       <Bagder_> good morning
08.30.27 #       <LinusN> what's the deal with your nicks?
08.30.29 #       <Bagder_> the non underscore me is my upstairs computer
08.30.32 #       <LinusN> aha
08.30.50 Join    amiconn [0] (~jens@pD9E7F5B7.dip.t-dialin.net)
08.31.01 #       <amiconn> god morgon
08.31.14 #       <Bagder_> wow
08.31.19 #       <Bagder_> :-)
08.31.21 #       <LinusN> Bagder_: i found out the ATA power/reset connections
08.31.31 #       <Bagder_> rock!
08.31.43 #       <LinusN> amiconn: guten morgen (?)
08.32.03 #       <amiconn> correct :)
08.32.12 #       <LinusN> Bagder_: we were sooo wrong :-)
08.32.19 #       <Bagder_> hehe
08.32.32 #       <LinusN> amiconn: i learnt german from the 64'er magazine
08.32.48 #       <LinusN> but guten morgen was a seldom used phrase there :-)
08.32.54 #       <amiconn> LinusN: Maybe there was a reset-finding day? (If you noticed my finding on the player...)
08.33.02 #       <LinusN> amiconn: :-)
08.33.38 #       <LinusN> good work on the player, btw. my hat is off
08.34.12 #       <LinusN> time to replace my flash chip
08.34.23 #       <amiconn> A propos player: It would be very kind if you could do some tests on your old player
08.34.26 #       <LinusN> Bagder_ i could do yours as well
08.34.41 #       <Bagder_> it'd be great
08.34.47 #       <LinusN> amiconn: will do. any special things you'd want me to test?
08.35.08 #       <amiconn> Mainly 2 things (if you don't change the flash chip yet):
08.35.40 #       <amiconn> (1) Try to uart-boot a current archos image (5.08) to see if this works with the old hardware
08.36.20 #       <amiconn> (2) Try to uart-boot current rockbox mainy to check the lcd init
08.36.33 #       <amiconn> Furthermore I would be interested in a ROM dump
08.36.59 #       <amiconn> Btw: Which ROM version does it have?
08.37.36 #       <LinusN> hmmm, 3.xx something, don't remember
08.40.05 #       <amiconn> If you want to solder in a flash chip, this would be probably the best test, but it may be that you would still need the uart boot mod, in case neither the archos image nor rockbox do work
08.42.31 #       <LinusN> absolutely
08.43.05 #       <amiconn> I currently have a test running: a rockbox build with ata power off on the player. It's already running for ~6 hours now, continually playing music. No crash yet :)
08.43.48 #       <amiconn> Do you roughly remember when you did those tests (as you reported occasional crashes)?
08.46.00 #       <LinusN> back when jesus had diapers, i guess :-)
08.46.27 #       <amiconn> Btw: This is even with a Hitachi DK23DA-10 disk
08.46.33 #       <Bagder_> I knew you are old LinusN, but not _that_ old ;*)
08.48.03 #       <amiconn> LinusN: You fixed the init after reapplying ata power for the recorder back in February. Maybe the same problem was also the cause for the crashes on the player, if your tests were done before that
08.48.44 #       <LinusN> it was long before that, so that may be it
08.49.02 #       <LinusN> those test were made back in 2002 methinks
08.49.31 #       * LinusN will try it on his newplayer immediately
08.50.17 #       <amiconn> If you want to test, you merely have to set a #define in config-player.h now. Everything else is already prepared :)
08.50.20 #       <LinusN> btw, the old player doesn't have ATA power control
08.50.47 #       <amiconn> I know, enabling this for everyone would need to dynamically show/ hide the menu entry
08.51.58 #       <LinusN> and not touch PB4 on old players
08.52.04 #       <amiconn> ..and set the global settings entry to "no" for old players, although setting it to "yes" does no harm, the power functions check for new/ old
08.52.33 #       <amiconn> See my power.c/ power.h commits :)
08.54.58 #       <LinusN> ah, an alias...
08.55.20 #       <amiconn> Yes, saving some code...
08.55.29 #       <LinusN> instead of a macro...?
08.56.43 #       <amiconn> A macro would save the same amount of code... only it gives the original function name instead of the aliased one compiler in warnings/ error
08.57.15 #       <amiconn> We could also rename this function to is_new_player() or such, and get rid of aliasing
08.59.13 #       <LinusN> much better
09.03.05 #       <LinusN> tested disk poweroff on my newplayer
09.03.11 #       <LinusN> same problems as last time :-(
09.03.35 Quit    Bagder_ ("Leaving")
09.03.40 #       <LinusN> player shuts off when trying to power on the hard drive
09.05.03 #       <LinusN> maybe this is a problem specific to my player?
09.05.28 #       <LinusN> someone else should try it
09.05.48 #       <amiconn> Hmm, maybe. It can't do that always, otherwise it would switch off right after poweron...
09.07.43 #       <amiconn> What ROM version/ PCB version(s) does your new player have? Maybe this is hw version dependent
09.09.15 #       <LinusN> fw 4.52
09.09.20 #       <LinusN> 4.53 sorry
09.09.24 #       <amiconn> Did you reset the settings after loading your test build? The settings structure changes, and some settings may have gotten weird values
09.10.35 #       <LinusN> i did
09.11.31 #       <amiconn> (away now)
10.07.57 ***     Saving seen data "./dancer.seen"
10.14.26 Join    Zagor [242] (~bjst@labb.contactor.se)
10.14.47 #       <Bagder> morning Z
10.17.15 #       <Zagor> hi
10.27.40 Quit    AciD (Read error: 104 (Connection reset by peer))
10.28.15 #       <amiconn> LinusN: The fw version on your newplayer - is that the ROM version, or the version of the archos image (they may be different)?
10.28.16 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
10.29.02 #       <LinusN> amiconn: of course it is the ROM version, i have no archos image as i run rockbox
10.29.55 #       <LinusN> or have i missed something?
10.30.36 #       <amiconn> Of course your ROM contains an archos image.
10.30.40 #       <amiconn> (only)
10.31.15 #       <amiconn> The ROM version is what rockbox displays under debug->view HW info, versus the archos image version is what it displays at boot
10.31.27 #       <amiconn> My ROM is 5.06, versus the archos image is 5.08
10.31.41 #       <LinusN> now i get it
10.31.44 #       <LinusN> lemme see
10.32.23 #       <LinusN> 4.53
10.34.39 #       <amiconn> Which one?
10.34.52 #       <LinusN> both
10.36.56 #       <amiconn> Hmm. I still wonder what may cause those weird shutdowns with ata power off/ on. At least your newplayer is one of the early newplayers. Maybe there are some hw problems that were solved later
10.37.06 #       <LinusN> maybe
10.37.29 Join    MooMaunder [0] (~me@194.152.87.150)
10.39.08 #       <amiconn> LinusN: Do you have access to any other newplayers, were you could test on?
10.40.44 #       <LinusN> matsl has one, as well as kjer
10.47.22 Join    kurzhaarrocker [0] (~knoppix@p508773AB.dip0.t-ipconnect.de)
11.04.06 Join    bobTHC [0] (~foo@l03m-37-240.d1.club-internet.fr)
11.04.10 #       <bobTHC> hi all!
11.09.50 #       <LinusN> hi
11.10.37 #       <bobTHC> always under the snow ??
11.10.39 #       <bobTHC> ;)
11.11.16 #       <LinusN> today's forecast says that it will melt away today... :-(
11.11.35 #       <Zagor> finally we'll get traditional swedish winter ;)
11.12.56 #       <bobTHC> the winter god retakes his right, good news for north ppl ;)
11.13.25 #       * kurzhaarrocker wants a plugin to ffwd / rewind seasons
11.13.33 #       <bobTHC> :)
11.14.31 #       <LinusN> i *want* snow and cold
11.15.33 #       <kurzhaarrocker> I don't mind you having snow and cold as long as you're far away with that.
11.20.41 Join    Digital007 [0] (~acbd1e57@labb.contactor.se)
11.20.47 #       <Digital007> morning
11.20.59 #       <LinusN> hi
11.21.03 #       <Digital007> hi
11.21.19 #       <Digital007> i don't think iriver are gonna make new firmwares for the H1xx series
11.21.26 #       <Digital007> they want to concentrate on the H3xx series
11.22.30 #       <Digital007> :=(
11.23.29 #       <LinusN> and you realize that *now*? :-)
11.23.36 #       <Digital007> from misticriver
11.23.47 #       <Digital007> I hope rockbox is introuduced on iriver soon
11.24.01 #       <Digital007> i really do
11.24.35 #       <Digital007> despite its shuffle foibles i still think its a far better machine than the Archos
11.26.03 #       <Digital007> :P
11.26.21 #       <kurzhaarrocker> better than the archos recorders? That's not difficult :)
11.26.36 #       <Digital007> heehee
11.26.41 #       <Digital007> ive got an H120
11.27.00 #       <Digital007> well i suppose the Archos has those snazzy blue corners which the iriver lacks :-)
11.27.29 #       <amiconn> LinusN: Do you have the original hi-res scans of the archos models somewhere?
11.28.27 #       <Digital007> Linus when is the approximate release period for iriver rockbox?
11.28.48 #       <LinusN> amiconn: we don't have any other scans that those on the site
11.29.15 #       <kurzhaarrocker> Digital007: I prefer the black corners - I think they make the sound a bit more smooth
11.30.01 #       <LinusN> amiconn: ah, you mean the ones i did for the model overview?
11.30.06 #       <amiconn> LinusN: I presume the scans on the site to be scaled down
11.30.12 #       <Digital007> lol
11.30.33 #       <Digital007> Are colour screens on an MP3 player really necessary?
11.30.48 #       <bobTHC> imho not
11.30.57 #       <Digital007> i hate colour screens on MP3 players
11.31.04 #       <LinusN> Digital007: i thought we have made it very clear that we don't have a release schedule
11.31.15 #       <Digital007> well i don't think u did linusn
11.31.18 #       <Digital007> sorry
11.32.24 #       <Digital007> like that photo ipod (not)
11.34.48 #       <LinusN> Digital007: 23.53.01 #       <Digital007> when u think the first release will be?
11.34.48 #       <LinusN> 23.53.23 #       <LinusN> when it's ready
11.34.48 #       <LinusN> 23.53.32 #       <LinusN> not this year
11.35.14 #       <Digital007> sorry i forgot
11.35.56 #       <LinusN> i agree that my reply wasn't clear about not having a schedule at all
11.36.29 #       <LinusN> but since you frequent misticriver i thought you would have followed the "Rockbox progress" thread
11.36.39 #       <Digital007> i didn't know there was one
11.36.51 #       <LinusN> oh
11.37.16 #       <Digital007> too busy hammering iriver for a fix to the shuffle prob
11.37.23 #       <LinusN> i always select "New Posts" in the menu
11.37.57 #       <LinusN> damn Freescale for their sucky data sheets
11.46.16 #       <chendo> wow, this channel is finally active
11.46.27 #       <LinusN> "finally"?
11.46.36 #       <chendo> well, active enough by my standards
11.46.50 #       <LinusN> it's been active since march 2002 :-)
11.46.50 #       <chendo> how do you guys reflash the firmware if you happen to screw it up?
11.46.58 #       <chendo> well, not since i was in here :P
11.47.03 #       <LinusN> how did you screw it up?
11.47.12 #       <chendo> well, i didn't (yet)
11.47.16 #       <chendo> just wondering how you guys do it
11.47.27 #       <chendo> since you can only flash from a working firmware on the iRiver
11.47.45 #       <LinusN> ah, you're talking about iriver...
11.48.00 #       <chendo> yeah... interested in seeing what you guys will make :)
11.48.20 #       <LinusN> none of us has flashed anything yet
11.48.20 #       <chendo> although, are you just gonna leave it monochrome like on the archos or are you gonna prettify the GUI?
11.48.42 #       <LinusN> we will probably "prettify" it eventually
11.49.38 #       <chendo> better video playback? ;o
11.49.48 #       <LinusN> than the archos?
11.50.18 #       <chendo> well, than what iRiver has now
11.50.42 #       <LinusN> i didn't know that iriver had video playback on the H1xx
11.51.28 #       <chendo> well, on the H3xx...
11.51.57 #       <bobTHC> making rockbox "as it" working on the iriver devices is already a big challenge
11.52.19 #       <chendo> yeah well, i consider myself an optimist :)
11.52.26 Quit    Digital007 ("CGI:IRC (Ping timeout)")
11.53.13 #       <chendo> there's a CGI:IRC? o.o
11.53.15 #       <LinusN> as you probably know, we have few real plans for the iriver port, except porting it
11.53.24 #       <chendo> aw :(
11.54.17 #       <LinusN> once it's ported, we'll see what happens next
11.54.47 #       <chendo> alrighty
11.55.45 #       <kurzhaarrocker> "real plans"? Seems I missed something.
11.56.27 #       <bobTHC> :)
11.56.37 #       <LinusN> "few real plans" really means "no real plans"
11.56.51 #       <bobTHC> :]
11.57.35 #       <LinusN> lunch time
11.59.33 #       <bobTHC> but "no real plans" not really means "no ideas "
11.59.38 #       <bobTHC> ;)
12.00.50 #       <kurzhaarrocker> <- must learn reading. I read "we have _a_ few plans" instead of "we have few plans" 
12.07.59 ***     Saving seen data "./dancer.seen"
12.30.29 Join    midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
12.30.30 Part    LinusN
12.30.34 Part    Zagor
12.31.19 Join    LinusN [0] (~linus@labb.contactor.se)
12.31.19 Join    Zagor [242] (~bjst@labb.contactor.se)
12.33.36 Quit    MooMaunder (Read error: 54 (Connection reset by peer))
12.46.43 Quit    midk (Read error: 110 (Connection timed out))
13.17.08 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
13.18.14 #       <[IDC]Dragon> 'morning!
13.20.41 #       <amiconn> Morning? ;)
13.21.24 #       <[IDC]Dragon> ;-)
13.21.38 #       <[IDC]Dragon> meetings all morning
13.25.40 Join    starmanager [0] (~d419040b@labb.contactor.se)
13.28.32 Quit    starmanager (Client Quit)
13.55.54 #       <Zagor> "DMC Xclef 500 137GB Portable - Made in the USA" -- http://www.mp3newswire.net/stories/2004/xmasplayers3.html
13.56.49 #       <Zagor> amazing how some companies choose to lie about their products
13.57.53 #       <[IDC]Dragon> 137GB?
13.58.22 #       <Zagor> they "plan to release one". right. as soon as someone makes a disk that size...
13.58.38 #       <[IDC]Dragon> I should wait with my HD upgrade
14.00.39 #       <kurzhaarrocker> 137 GB? No way with my USB1.1 recorder.
14.08.01 ***     Saving seen data "./dancer.seen"
14.59.15 Join    casualtie [0] (~are@ti500710a080-2537.bb.online.no)
15.26.22 Join    Headie [0] (~Headie@h103n2fls32o873.telia.com)
15.53.21 Part    LinusN
15.56.39 Join    gromit` [0] (~gromit@m117.net81-65-8.noos.fr)
16.08.05 ***     Saving seen data "./dancer.seen"
16.11.02 Quit    casualtie (Read error: 110 (Connection timed out))
16.16.39 Join    Tang [0] (~chatzilla@29.126.119-80.rev.gaoland.net)
16.17.42 Join    pfavr [0] (~Peter_Fav@213.237.46.232.adsl.ron.worldonline.dk)
16.22.26 #       <pfavr> hi! I just replaced the drive in my recorder 20 with a 40GB hitachi, and installed rockbox 2.3. I did the partitioning using linux fdisk and chose partition type 'C' (fat32, lba). Then I formatted the drive using mkdosfs on linux. It seems to work fine - but "Rockbox Info" says the disk is only 3.10GB with 3.7GB free. Any ideas?
16.22.50 #       <Bagder> weird
16.22.57 #       <Bagder> run that update disk space thing
16.23.12 #       <pfavr> ?
16.23.20 #       <pfavr> a plugin?
16.23.21 #       <Zagor> press play in the disk space screen
16.23.29 #       <Zagor> ...and wait
16.24.06 #       <pfavr> ok, now I just need to find the disk space screen?
16.24.35 #       <pfavr> (feeling a bit stupid)
16.24.42 #       <Zagor> debug/disk info
16.25.11 #       <pfavr> got it
16.25.29 #       <pfavr> well, still 3846MB free
16.25.51 #       <Zagor> strange
16.26.17 #       <pfavr> But it says size is 38154MB
16.26.22 #       <pfavr> (which is fine)
16.26.39 #       <pfavr> Cluster size 4096 bytes
16.27.26 #       <pfavr> In the partition screen it shows one partition: 38154MB
16.27.48 #       <Bagder> well, 40GB formatted fat is likely to be just that
16.28.36 #       <pfavr> yes, it is fine - just wonder if the rockbox info is ok
16.28.50 #       <pfavr> (or if I did something bad to the disk;-)
16.29.22 #       <Bagder> so what is wrong do you say?
16.29.28 #       <Zagor> if linux says the disk is fine, it is. sounds like rockbox gets confused for some reason.
16.29.34 #       <pfavr> yes
16.29.51 #       <pfavr> just wondered if this was known/normal behaviour
16.30.04 #       <pfavr> when using a 40GB disk
16.30.16 #       <Zagor> usually it is fixed by recalculating as you did
16.30.18 #       <pfavr> or maybe I overlooked something
16.30.43 #       <Bagder> 40*1000*1000*1000/1024/1024 = 38146
16.31.19 #       <pfavr> uh oh, this is embarrasing - I seem to have made a too small filesystem
16.31.30 #       <pfavr> should have checked first before asking
16.31.52 #       <Zagor> don't specify size, just let it use the defaults values
16.31.55 #       <pfavr> df -h says: /dev/sda1             4,0G  241M  3,8G   6% /mnt/archos
16.32.08 #       <Zagor> sounds kinda small, yes :)
16.32.10 #       <pfavr> I did use the defaults
16.32.30 #       <pfavr> sounds like rockbox is reporting the accurate sizes
16.33.00 #       <pfavr> thanks anyway
16.34.55 Quit    bobTHC ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )")
16.35.31 #       <pfavr> now it works - it was probably because I didn't unplug and reconnect after doing fdisk - then it used the old partition size for mkdosfs
16.35.51 #       <Zagor> aha
16.36.02 #       <pfavr> df -h now says: dev/sda1              38G   16K   38G   1% /mnt/archos
16.41.32 #       <pfavr> Rockbox info: Disk 37.2GB :-)
16.43.44 Join    mecraw_ [0] (~lmarlow@69.2.235.2)
16.44.42 Part    Zagor
17.25.06 Join    atdj [0] (ju_@82.251.167.150)
17.26.58 Join    casualtie [0] (~are@ti500710a080-2537.bb.online.no)
17.27.24 Quit    pfavr ("ChatZilla 0.9.61 [Mozilla rv:1.7.3/20041007]")
18.03.21 Quit    kurzhaarrocker (Read error: 104 (Connection reset by peer))
18.07.53 Join    methangas [0] (methangas@0x50a461d5.virnxx10.adsl-dhcp.tele.dk)
18.08.09 ***     Saving seen data "./dancer.seen"
18.17.11 #       <amiconn> [IDC]Dragon: r u there?
18.18.41 #       <Tang> Hi folk!
18.18.42 #       <Tang> :)
18.19.04 #       <Tang> I have a question about lace LinusM progress
18.19.21 #       <Tang> last (not lace, sorry)
18.42.50 #       <[IDC]Dragon> amiconn: now I am
18.46.10 Join    _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
18.49.37 #       <Tang> But he is not, lol$
18.49.54 #       <[IDC]Dragon> seems so
18.50.37 #       <Tang> I would ask something about the iriverport
18.50.54 #       <Tang> not sure you could answer me...
18.51.36 #       <[IDC]Dragon> neither do I, unless you ask...
18.51.51 #       <Tang> ok si i'll do
18.51.58 #       <Tang> the recent CVS report
18.52.09 #       <Tang> say that:
18.52.14 #       <Tang> "iRiver: attempt to set up the SDRAM correctly"
18.52.32 #       <Tang> I was wondering if this SDRAMwere the "buffer" memory
18.52.50 #       <Tang> or the firmware mmory
18.52.53 #       <[IDC]Dragon> it's the main memory
18.53.25 #       <Tang> main memory means where is the firmware?
18.53.51 #       <[IDC]Dragon> unless that runs directly from flash, yes
18.54.07 #       <Tang> ah okay i see
18.54.22 #       <Tang> it's the SDRAM used by the processor
18.54.43 #       <[IDC]Dragon> like the RAM in your PC
18.54.47 #       <Tang> but not were is stocked the firmware when you upgrade
18.54.53 #       <Tang> ok i see
18.55.09 #       <Tang> thanks a lot
18.55.48 #       <Tang> in fact i was hesitating if it was the RAM opening access to alternative firmware
18.55.50 #       <Tang> ;)
18.56.18 #       <Tang> Anyway any progress is good to hear ;)
18.56.34 #       <[IDC]Dragon> no, just setting up the hardware to use the RAM (init, refresh, etc.)
18.57.47 #       <Tang> okay it insat done just working on it
18.58.10 #       <Tang> it isn't done yet just working on it
18.58.14 #       <Tang> (correction)
18.59.22 #       <[IDC]Dragon> I don't know, and it's most likely not your concern
19.01.14 #       <[IDC]Dragon> the iriver port is like a newborn baby moving it's legs for the first time, and people come in here and ask when it will b a dancer
19.01.43 #       <Tang> No sorry it wasn't what i wanted to say
19.02.03 #       <Tang> i meant
19.02.26 #       <Tang> LinusM is just working on the SDRAM
19.03.00 #       <Tang> the CVS notice dosent seem to indicate he suceeded on this point
19.03.10 #       <Tang> (setting STDRAM)
19.03.32 #       <Tang> (sorry i don't speak english very well)
19.04.25 #       <Tang> I wasn't asking any feature or something like that on the contrary
19.04.47 #       <[IDC]Dragon> ok ;-)
19.04.54 #       <[IDC]Dragon> never mind
19.05.14 #       <Tang> ok sorry for misundertsanding
19.07.15 Join    matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se)
19.09.30 Join    Bruno [0] (~chatzilla@ca-sqy-1-124.w80-8.abo.wanadoo.fr)
19.10.10 #       <Bruno> wow see even accesing ram is difficult on iriver!
19.10.37 #       <[IDC]Dragon> the Archos also needs a RAM init
19.10.54 #       <Bruno> ram init is ok
19.11.03 #       <[IDC]Dragon> but this is done by the boot code, not part of Rockbox
19.11.15 #       <Bruno> but i've read linus code and you must use a workaround becasue of a bug!
19.13.13 #       <Bruno> i must say :keep going linus!!
19.18.30 Quit    Bruno ("Chatzilla 0.9.66c [Mozilla rv:1.7.5/20041108]")
19.23.47 Quit    AciD (Read error: 104 (Connection reset by peer))
19.24.21 Join    AciD [0] (~gni@acid.user)
19.25.07 Quit    [IDC]Dragon ("CGI:IRC")
19.42.13 Quit    gromit` (Read error: 104 (Connection reset by peer))
19.42.57 Join    gromit` [0] (~gromit@m117.net81-65-8.noos.fr)
19.44.31 #       <Tang> Another thing but don't take in cosideration if it's kinda "confidential"
19.45.16 #       <Tang> I've seen on the board that a guy own aBDM and an iHP too
19.45.38 #       <Tang> he wasn't memeber of rockbox anyway...
19.46.07 #       <Tang> is there any contact with him?
19.46.43 #       <Tang> (fireblade20772 on your board)
19.47.50 #       <Tang> ( http://forums.rockbox.org/index.php?topic=134.0 )
20.08.12 ***     Saving seen data "./dancer.seen"
20.17.50 Join    void [0] (~void@ool-18b87f55.dyn.optonline.net)
20.17.57 Nick    void is now known as void_ (~void@ool-18b87f55.dyn.optonline.net)
20.18.03 Quit    atdj (Client Quit)
20.18.09 #       <void_> anyone around?
20.18.45 #       <webmind> ?
20.19.16 #       <void_> I'm having a bit of trouble with my archos jukebox recorder 15, I've noticed that the battery indicator shows a question mark for a while after being fully charged and then after some use of it I get read access errors
20.19.50 #       <void_> running  rockbox-2.3
20.20.49 Quit    casualtie (Read error: 110 (Connection timed out))
20.23.38 #       <amiconn> void_: reg. the question mark: see http://www.rockbox.org/twiki/bin/view/Main/BatteryFAQ#Q18_Why_does_rockbox_show_a_ques
20.24.48 #       <amiconn> read access errors might be caused by bad battery contacts (a common problem on the NiMH powered archos devices, though I didn't experience it myself yet)
20.27.56 #       <void_> how can I tell?
20.31.15 #       <amiconn> It is reported that broken battery contacts sometimes also cause the recorder to crash/ reboot if the corners are squeezed. See http://www.rockbox.org/docs/repairbattery.html for a short description/ repair guide
20.31.16 Join    Stryke` [0] (~Chairman8@resnet-241-86.resnet.UMBC.EDU)
20.59.39 Quit    AciD (Read error: 104 (Connection reset by peer))
21.06.27 #       <void_> hrm
21.06.30 #       <void_> ok I have it open 
21.06.39 #       <void_> is there supposed to be a lead connector on both sides?
21.06.46 #       <void_> I see one side has it
21.18.35 Quit    Tang ("Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041108]")
21.21.09 Join    AciD [0] (~gni@acid.user)
21.25.52 #       <amiconn> void_: From what it looks to me, both springs should be firmly soldered to their respective pads. The spring to the upper left (when the unit is in front of you in the normal position) has a wire running across it.
21.26.18 #       <amiconn> This wire is wrapped around the edge of the pcb, and should be soldered at both ends
21.27.15 #       <amiconn> (sorry didn't notice earlier)
21.38.12 Join    lImbus [0] (lImbus@186.194-136-217.adsl.skynet.be)
21.38.16 #       <lImbus> hi all
21.38.22 #       <amiconn> hi
21.38.33 #       <lImbus> amiconn: I forgot to test usb with the external mmc...
21.39.58 #       <amiconn> I think if rockbox access to both internal and external mmc works, and usb works for internal, then usb will work for external too.
21.40.31 #       <lImbus> ok, I was not sure, but if YOU say... :)
21.41.23 #       <amiconn> Btw, there is a hardware limitation in the Ondio: If you connect the Ondio to usb with an MMC inserted, you can't access it. You first have to remove it (or connect with no card). Then you can insert and access a card
21.42.14 #       <amiconn> Both archos fw and rockbox will tell you :)
21.42.27 #       <lImbus> why ? sound strange. don't think it's fixeable in rockbox, eh ?
21.42.33 #       <amiconn> Nope, sorry
21.42.46 #       <lImbus> np
21.42.59 #       <amiconn> The thing is, there are 2 protocols to access an MMC, MMC mode and SPI mode.
21.43.57 #       <amiconn> The USB bridge uses MMC mode, while rockbox (has to) use SPI mode. You can switch a card from MMC mode to SPI mode with a command, but you cannot switch back wihout power cycling the card
21.44.44 #       <lImbus> lol
21.44.58 #       <amiconn> There would have been a simple solution - a transistor to switch MMC power off & on. Unfortunately that is not part of the archos hw design...
21.45.12 #       <lImbus> I didn't like mmc/sd-cards from the beginning
21.45.29 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
21.48.33 Join    casualtie [0] (~are@ti500710a080-2537.bb.online.no)
22.08.14 ***     Saving seen data "./dancer.seen"
22.38.41 Join    [IDC]Dragon [0] (~idc-drago@p50861F2F.dip.t-dialin.net)
22.38.52 #       <amiconn> hi again
22.39.06 #       <[IDC]Dragon> hi there
22.39.07 #       <lImbus> hi
22.39.25 #       <[IDC]Dragon> the Ondio crowd? ;-)
22.39.56 #       <lImbus> hehe
22.40.03 #       <lImbus> no other owners yet ?
22.40.16 #       <[IDC]Dragon> a handful
22.40.42 #       <[IDC]Dragon> and the "dark owners"
22.40.52 #       <amiconn> [IDC]Dragon: I have a question and probably suggestion(s) for solving the ata init problem when returning from the archos charging screen. (This problem also hits on the player)
22.40.55 #       <lImbus> that's not much, compared to the size of my hands :-)
22.42.46 #       <amiconn> The question first: What would be the problem with always issuing ata_hard_reset()? Increased boot time? Wearing the hd? Possible data loss?
22.43.12 #       <[IDC]Dragon> boot time, probably
22.44.28 #       <[IDC]Dragon> I remember once we (unnecessarily) resetted bot master and slave, costing significant time
22.44.41 #       <[IDC]Dragon> s/bot/both
22.44.54 #       <amiconn> Imho there are 2 possible solutions. The coldstart isn't detected by rockbox because the archos firmware initializes all ports at once.
22.45.05 #       <[IDC]Dragon> the reset works for both, so it was unnecessary
22.46.36 #       <amiconn> The first option involves changing the bootloader to deliberately *deinitialize* the ata port. This would work because the archos fw has to jump to the coldstart address to start rockbox from flash after leaving the charging screen, so the bootloader is executed again
22.46.57 Quit    casualtie ("www.bareare.net")
22.47.57 #       <[IDC]Dragon> I don't think the bootloader is executed again, why should it?
22.47.58 #       <amiconn> The second option would be to do a retry in ata_init() in case the first init sequence doesn't work, issuing ata_hard_reset() before the 2nd try
22.48.18 #       <[IDC]Dragon> sounds better
22.48.51 #       <amiconn> (bootloader) How else should the archos firmware restart rockbox *from flash*? It doesn't know anything about the flash structure you established...
22.49.51 #       <[IDC]Dragon> Archos firmware restarts Rockbox? I'm a bit confused
22.50.44 #       <[IDC]Dragon> ah, yes
22.51.16 #       <amiconn> If you start the box by inserting the charger while holding F1/-, the archos firmware starts and displays its charging screen. If you then press On, it leaves the charging screen, and if you don't also hold F1/- while doing this, rockbox is started from flash...
22.51.31 #       <amiconn> ...which then panics with ata -31
22.52.16 #       <[IDC]Dragon> yes, yes, that's the problem
22.52.47 #       <[IDC]Dragon> so the de-init is not a bad idea
22.53.37 #       <[IDC]Dragon> very nice of the Archod firmware, how convenient
22.54.39 Quit    methangas (" HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it")
22.55.08 #       <amiconn> It's a quite rare situation to get this panic because of the many steps involved, but it is somewhat likely that at least recorder users get this, when they use archos charging for whatever reason
22.56.36 #       <amiconn> The bootloader solution probably needs less code, but on the downside requires a full reflash to work
22.57.10 #       <[IDC]Dragon> yes, that's the downside
22.59.40 #       <[IDC]Dragon> an ATA reset retry might be a good idea, independently
23.06.38 Join    mattzz [0] (~mattzz@d048063.adsl.hansenet.de)
23.08.29 #       <amiconn> [IDC]Dragon: I wonder why the io_address_detect() return code is also for error. As it is implemented now, it never returns an error, as it simply checks the hw mask. Plus, it could be done earlier, independently of the rest of the init sequence
23.08.38 #       <amiconn> *is also checked for error
23.12.06 #       <[IDC]Dragon> ah, I once changed that
23.12.47 #       <[IDC]Dragon> before determined by the mask, the address was determined by a rather complex probing
23.13.37 #       <[IDC]Dragon> which probably had failue conditions, too
23.14.08 #       <amiconn> Ah. So this could be moved towards the top, leaving 4 function calls to be put in a separate function, and then doing like this:
23.15.05 #       <amiconn> if (!coldstart)   rc = init_and_check(false);
23.15.33 #       <amiconn> if (rc != 0)   rc = init_and_check(true);
23.15.44 #       <amiconn> if (rc != 0)   return rc;
23.15.58 #       <amiconn> with
23.16.13 #       <amiconn> int init_and_check(bool hard_reset)
23.16.20 #       <[IDC]Dragon> yes, looks good
23.17.05 #       <[IDC]Dragon> or:  if (!coldstart)   rc = init;
23.17.33 #       <[IDC]Dragon>  if (rc != 0)  hard_reset(); init();
23.17.55 #       <[IDC]Dragon> missing braces above
23.18.07 #       <amiconn> Not quite. The init function needs the fact whether to do hard reset or not in 2 places.
23.18.15 #       <[IDC]Dragon> ah, ok
23.19.50 #       <amiconn> I found some more things about the old vs. new player: (1) From the disasm, I got that our new_player check is slightly off.
23.20.43 #       <amiconn> We do if (rom_version > 451). Correct is if (rom_version > 449 || rom_version == 116)  Yes, strange!
23.21.15 #       <[IDC]Dragon> different subject: for the Ondio, we can remove the ? in the battery symbol
23.21.28 #       <[IDC]Dragon> (just appeared to me)
23.22.14 #       <amiconn> Probably, yes. The initial consumption (influencing the battery reading) is not that much higher as on the hd players
23.22.59 #       <lImbus> good luck guys, gotta go to bed
23.23.01 #       <amiconn> Then I tested ata power off. It ran without problems for 20 hours on my box, powering from psu, and currently almost 1 hour from batteries
23.23.09 #       <amiconn> lImbus:Nite
23.23.13 #       <[IDC]Dragon> old vs. new player influenced LCD, ATA power pin, any more?
23.23.23 Quit    lImbus (" WOW! This IRC Client ownz! HydraIRC -> http://www.hydrairc.com <-")
23.23.30 #       <amiconn> Nothing more that we know of
23.24.14 #       <[IDC]Dragon> saw you mentioning that to Linus, yes. He immediately had problems?
23.24.36 #       <amiconn> yes
23.24.49 #       <[IDC]Dragon> strange
23.24.57 #       <amiconn> Box switches off as soon as it tries to power the hd.
23.25.17 #       <[IDC]Dragon> maybe the power surge
23.25.22 #       <amiconn> It cannot do this always, because otherwise it would always immediately power down.
23.25.45 #       <[IDC]Dragon> ?
23.25.47 #       <amiconn> Either there are some bad connections, or maybe it's a hardware revision thing
23.26.26 #       <amiconn> His newplayer is one of the early ones, both ROM & archos image version 4.53
23.26.40 #       <[IDC]Dragon> or recorders, we can switch if the HD should be truely insulated or just sleep (default)
23.26.47 #       <[IDC]Dragon> on
23.27.15 #       <[IDC]Dragon> why not do the same thing for players?
23.27.27 #       <amiconn> I know. I *can* do the same on my player now
23.27.44 #       <[IDC]Dragon> the choice, I mean
23.28.03 #       <amiconn> yup
23.28.13 #       <[IDC]Dragon> with the default being the "classic" way
23.28.32 #       <amiconn> ...which it is anyway, also on recorder
23.29.40 #       <amiconn> I just would want to dynamically hide the menu option for old players. Although it wouldn't hurt (the power function checks the rom version before doing its work)
23.30.17 #       <[IDC]Dragon> that means to un-const it
23.30.41 #       <amiconn> Yes, unfortunately. Would only be needed on the player though
23.31.10 #       <[IDC]Dragon> looks even worse
23.31.18 #       <[IDC]Dragon> with #if
23.31.28 #       <amiconn> Some more #ifdef'ing, yes :-/
23.31.57 #       <[IDC]Dragon> we introduced a lot already, one more is nothing
23.32.02 Join    LinusN [0] (~linus@labb.contactor.se)
23.32.03 #       <amiconn> ;-)
23.32.09 #       <[IDC]Dragon> hey
23.32.14 #       <LinusN> amiconn: it does *always* power down
23.32.15 #       <amiconn> hi LinusN
23.32.45 #       <amiconn> Well, not the very first time. Otherwise you wouldn't be able to use it at all ;-)
23.32.47 #       <LinusN> as soon as i set the Disk Poweroff setting
23.33.05 #       <LinusN> it is unable to save the setting on disk
23.33.08 #       <amiconn> It powers down as soon as the disk power is cut??
23.33.36 #       <LinusN> i enable the setting when the disk has spun down
23.33.51 #       <LinusN> then it reboots when it tries to spin up
23.34.03 #       <LinusN> and it can't save the setting
23.34.11 #       <[IDC]Dragon> natural protection against an unsuitable setting ;-)
23.34.22 #       <amiconn> Ah. What happens if you set the setting while the disk is not yet spun down?
23.34.25 #       <LinusN> lucky for me, otherwise it would never be able to boot :-)
23.34.57 #       <amiconn> Ah. Probably better don't try.
23.35.14 #       <LinusN> yup :-)
23.35.23 #       * [IDC]Dragon proposes the "default setting" boot key combo again
23.35.49 #       <LinusN> [IDC]Dragon: good idea
23.35.49 #       <[IDC]Dragon> in german, we call it the grandma key
23.36.00 #       <amiconn> LinusN: However, you should be able to start again, you merely have to be fast enough to reset the setting before the first spindown
23.36.18 #       <amiconn> If you set a large spindown delay, it should be manageable
23.36.31 #       <[IDC]Dragon> some TV sets have such a key on the remote, if you're lost in messing everything
23.37.41 #       <amiconn> LinusN: Any chance to try this on more newplayers, preferably with different rom versions, and ideally one more with your version? I vaguely remember that you once talked about a hardware survey...
23.38.11 #       <LinusN> well, kjer has one, and matsl has one
23.38.21 #       <LinusN> both work at contactor
23.38.44 #       <Bagder> matsl is even joined here atm
23.38.52 #       <Bagder> matsl: present?
23.38.54 #       <LinusN> matsl: ho ho
23.39.42 #       <[IDC]Dragon> where in the code is that battery status question mark? I can't find it.
23.40.34 Quit    gromit` (Read error: 104 (Connection reset by peer))
23.40.49 Join    gromit [0] (~gromit@m117.net81-65-8.noos.fr)
23.41.27 #       <amiconn> [IDC]Dragon: I think it's sufficient to not suppress the first battery reading. The question mark is displayed as long as the battery state is -1
23.41.58 #       <[IDC]Dragon> yes, I wanted to backtrack how it's handled
23.42.44 #       <amiconn> The battery reading or the battery symbol display?
23.43.28 #       <[IDC]Dragon> found it, never mind
23.45.37 #       <matsl> LinusN: here!
23.46.17 #       <LinusN> matsl: which ROM version is your Player?
23.46.51 #       <matsl> LinusN: huh, don't know.
23.47.19 Quit    mattzz ("Client exiting")
23.47.25 #       <[IDC]Dragon> perhaps your player knows?  ;-)
23.48.12 #       <matsl> i'm asking it now.. w8
23.57.04 #       <matsl> version 5.03
23.57.57 #       <amiconn> Is that the version rockbox displays under debug, or what archos displays on boot? They may be different (mine are)