--- Log for 09.10.104  Server: burroughs.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 4 days and 23 hours ago

00.08.39 #       * [IDC]Dragon says goodnight
00.08.55 Quit    [IDC]Dragon ()
00.11.49 Quit    gromit` (Read error: 110 (Connection timed out))
00.18.29 Quit    methangas (" Try HydraIRC -> http://www.hydrairc.com <-")
00.41.33 #       <JoeBorn> goodnight all, thanks for letting me hang out and listen
00.41.59 Part    JoeBorn
00.54.07 ***     Saving seen data "./dancer.seen"
01.06.37 Join    iRiverMan [0] (~acb9b3b3@labb.contactor.se)
01.06.41 #       <iRiverMan> hi
01.08.08 #       <iRiverMan> how is iriverbox coming on?
01.09.18 #       <midk> 'coming on'?
01.16.34 #       <iRiverMan> well has someone made it boot on the iriver yet?
01.16.45 #       <iRiverMan> midk u have a karma righ?
01.16.48 #       <iRiverMan> right?
01.16.58 #       <midk> it's not *quite* that simple. the backlight flashes, that's about it, as far as i know
01.17.01 #       <midk> and no, of course not
01.17.13 #       <iRiverMan> i thought u said u had a rio karma
01.17.30 #       <midk> u throught wrong
01.17.35 #       <midk> thought*
01.21.30 #       <iRiverMan> ok so i thought wrong
01.21.33 #       <iRiverMan> so what DO you have?
01.22.25 #       <iRiverMan>  u have an ipod
01.25.57 Quit    _aLF ("Leaving")
01.27.29 #       <iRiverMan> perhaps not then
01.31.15 #       <amiconn> midk: How is breakout coming?
01.34.39 #       <iRiverMan> he's asleep
01.36.09 #       <midk> amiconn, it's mostly done, i haven't messed with it recently
01.36.25 #       <midk> the collision detection (written by strath) is good but not perfect
01.36.39 #       <amiconn> The button repeat rate should no longer be a problem
01.37.06 #       <midk> it's not
01.42.08 #       <midk> if you'd like to give collision detection a try, i can send it over..
01.42.32 #       <iRiverMan> miss my archos
01.42.35 #       <iRiverMan> still got the hd for it
01.43.51 #       <iRiverMan> is the old hd worth keeping?
01.43.57 #       <iRiverMan> its a hitachi 10gb laptop drive
01.44.10 #       <amiconn> midk: I would like to, but unfortunately I will be busy for some more time with Ondio hacking.
01.44.41 #       <midk> i understand... if/when you want it, just let me know
02.01.17 Part    amiconn
02.05.52 #       <Sebulba02> how are you doing the collision?
02.06.27 #       <midk> it's pretty simple, you just check the position of the ball in comparison to the center of the nearest block
02.07.56 #       <Sebulba02> sounds easy enough
02.08.38 #       <midk> 'tis
02.50.00 Quit    klaxon (Read error: 110 (Connection timed out))
02.54.11 ***     Saving seen data "./dancer.seen"
03.00.30 Quit    AciD (Read error: 232 (Connection reset by peer))
03.09.53 Quit    mecraw ("Trillian (http://www.ceruleanstudios.com)")
03.22.51 Quit    iRiverMan ("CGI:IRC (Ping timeout)")
04.54.12 ***     Saving seen data "./dancer.seen"
04.56.41 Part    scott666_
05.28.33 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
05.28.42 Part    scott666_
06.34.13 Join    kramerica [0] (~lkd@hsdbsk142-165-191-20.sasknet.sk.ca)
06.41.06 Join    ashridah [0] (ashridah@220.253.119.43)
06.54.13 ***     Saving seen data "./dancer.seen"
07.57.26 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
07.57.30 Part    scott666_
08.54.14 ***     Saving seen data "./dancer.seen"
09.17.52 Join    methangas [0] (methangas@0x50a476ab.virnxx10.adsl-dhcp.tele.dk)
09.28.33 Join    [IDC]Dragon [0] (~idc-drago@pD9FF8236.dip.t-dialin.net)
09.37.05 Join    amiconn [0] (~jens@pD9E7FAB9.dip.t-dialin.net)
09.38.05 #       <amiconn> Morning all
09.38.27 #       <[IDC]Dragon> Morning logpeeker!
09.38.34 #       <[IDC]Dragon> or?
09.38.53 #       <amiconn> Nah, not logpeeking
09.38.57 #       <[IDC]Dragon> congrats to your driver!
09.39.07 #       <[IDC]Dragon> mission accomplished, I'd say
09.39.07 #       <amiconn> Already tried it?
09.39.10 #       <[IDC]Dragon> yes
09.39.23 #       <[IDC]Dragon> (briefly, I admit)
09.39.48 #       <[IDC]Dragon> but I just had to flash a ROMbox build of it
09.40.00 #       <[IDC]Dragon> to see how it starts up
09.40.05 #       <amiconn> The only thing left to do is consistent error handling. As it is now it may return the same error code for different failures
09.40.38 #       <[IDC]Dragon> I still get the 50 sec pause with the high bitrate file I tried
09.40.54 #       <[IDC]Dragon> but that may be an issue in mpeg.c
09.41.05 #       <amiconn> I did a total of 3 runs of my fs test plugin, testing with 100 MB.
09.42.22 #       <amiconn> One test (with the internal flash) produced a bad fat sector, but the 2 other tests (external MMC with fat16 and fat32) ran without problems
09.42.33 #       <[IDC]Dragon> oops
09.43.29 #       <amiconn> Have to test again with the internal and dump an image for analysis in case it happens again
09.44.26 #       <amiconn> I can't imagine that it was caused by the driver though
09.45.34 #       <[IDC]Dragon> how was the bad sector produced? Rockbox does not verify nor mark bad sectors.
09.46.34 #       <amiconn> No, I checked with window's chkdsk afterwards. It complained about a number of cross-linked cluster chains
09.46.58 #       <[IDC]Dragon> that sounds like a file system bug
09.47.49 #       <amiconn> There were ~20 of them, cluster range 14080..14196. These are all handled within one fat sector (no. 55 if I calculated right)
09.49.26 #       <amiconn> Maybe the bad sector was caused by the flash chip itself, and it would have told the driver if the driver would check the status register
09.50.06 #       <[IDC]Dragon> there's a status for each sector?
09.51.26 #       <amiconn> No. You can check status after a write operation by explicitly requesting it (CMD_SEND_STATUS)
09.52.04 #       <[IDC]Dragon> hmm, might be a good idea
09.52.42 #       <[IDC]Dragon> but requires an architecture change in the file system if we want to really mark it as bad
09.53.48 #       <amiconn> Iiuc MMC handles bad sectors internally, but maybe some cards need the data to be re-send if they find such a sector
09.58.01 Join    amiconn_ [0] (~jens@pD9E7DF7A.dip.t-dialin.net)
09.58.56 #       <amiconn_> msg nickserv ghost amiconn x14zpt23!
09.59.07 Quit    amiconn (Nick collision from services.)
09.59.07 Nick    amiconn_ is now known as amiconn (~jens@pD9E7DF7A.dip.t-dialin.net)
09.59.10 #       <amiconn> ooops
10.01.30 #       <amiconn> password changed
10.03.48 #       <amiconn> [IDC]Dragon: Worst case for playback would be 384 kbps MP2, or even video with such an MP2 as audio part if you adapt the video plugin
10.04.43 #       <[IDC]Dragon> have you tried high bitrate?
10.05.13 #       <[IDC]Dragon> I played a 224 kBit/s mp3
10.05.21 #       <amiconn> I just started another test run on the internal flash
10.06.30 #       <[IDC]Dragon> this 50 sec pause is a mytery to me, you can't possibly take so long to load <2 MB
10.11.49 #       <amiconn> No. I think might caused by the mmc driver starving the bitswap when loading the first big chunk (mpeg.c loads small chunk as long as the buffer level is low, then switches to big chunks)
10.12.10 #       <amiconn> The mas is then fed with unswapped data, so it produces silence
10.13.43 #       <amiconn> The beast just switched off, and lost the settings again, grr
10.14.13 #       <amiconn> May be due to battery level though
10.17.47 #       <[IDC]Dragon> it can feed *unswapped* data? sounds like a bad design, missing check, or such
10.24.38 #       <amiconn> I dunno if it may do that, we should ask Linus
10.40.58 #       <amiconn> [IDC]Dragon: Interesting finding - my last test (that one that stopped and switched off the player) produced a bad fat sector again
10.41.24 #       <amiconn> What is really weird about that - it's *exactly* the same sector!
10.46.34 Quit    kramerica ()
10.53.32 Join    marc77 [0] (~marc@pub212004076150.hfc.datazug.ch)
10.54.18 ***     Saving seen data "./dancer.seen"
10.58.53 #       <amiconn> Ah, I just found why rockbox doesn't keep settings with the internal flash. I accidentally reformatted it in large-floppy mode...
11.02.41 Join    Schoki2 [0] (minuth@DSL01.212.114.239.39.NEFkom.net)
11.10.51 Join    edx [0] (edx@p54879739.dip.t-dialin.net)
11.14.00 #       <amiconn> Argh! I found what happened to the file system. There seems to be a bug in the config sector handling. In super-floppy mode, it wrote the config sector right into the fat area!
11.14.42 #       <amiconn> Guess what! This is sector 61
11.17.07 #       <[IDC]Dragon> uh, ha
11.17.51 #       <amiconn> At least it's neither the driver nor the file system
11.18.13 #       * [IDC]Dragon says phew!
11.18.57 #       <amiconn> A nice little "Roc..." within the fat area
11.19.29 #       <[IDC]Dragon> yes, that's striking
11.19.43 #       <[IDC]Dragon> this is how you found it?
11.21.19 #       <amiconn> Yes, although it was by accident that I reformatted my internal flash in superfloppy mode. Still looking how to revert this (WinXP doesn't allow me to do that)
11.22.35 Join    [1]marc77 [0] (~marc@pub212004076150.hfc.datazug.ch)
11.22.35 Quit    marc77 (Read error: 104 (Connection reset by peer))
11.22.36 #       <amiconn> It seems there is a bug in the MBR detection in Rockbox. Although the Partiton boot sector is not an MBR, it seems to get detected as such
11.22.38 Nick    [1]marc77 is now known as marc77 (~marc@pub212004076150.hfc.datazug.ch)
11.23.28 #       <amiconn> So rockbox thinks there is a partition table, but does not find a partition. This sets the config sector number to 61.
11.24.13 #       <amiconn> Afterwards it tries to mount in superfloppy mode anyway, and succeeds. Now the config sector is located within the fat...
11.24.23 #       <[IDC]Dragon> -(
11.24.27 #       <[IDC]Dragon> :-(
11.24.27 #       <amiconn> [IDC]Dragon: Do you know about MBR docs?
11.24.40 #       * [IDC]Dragon looks
11.26.33 #       <[IDC]Dragon> do you read the c't?
11.26.58 #       <amiconn> Sometimes... I have no c't issues at home :(
11.29.41 #       <[IDC]Dragon> issue 6/2000 had background articles
11.30.16 #       <amiconn> We need a proper method to distinguish an MBR from a partition boot sector
11.32.56 #       <[IDC]Dragon> I can email you the article
11.33.07 #       <[IDC]Dragon> have it on CD
11.34.26 #       <amiconn> Please do so, this could be interesting
11.35.27 #       <[IDC]Dragon> or DCC?
11.35.29 #       <amiconn> However, from what I found on google, distinguishing a boot sector from the mbr is not easily possible, because the only fixed marking of an mbr seems to be the 0x55aa at the end
11.36.01 #       <amiconn> The fat boot sector of my image does have the same marking...
11.36.06 #       <amiconn> DCC is fine
11.37.12 #       <[IDC]Dragon> let's try, it rarely worked for me
11.37.23 #       <[IDC]Dragon> maybe firewall,router, etc.
11.37.40 #       <[IDC]Dragon> coming in?
11.37.46 #       <amiconn> Connect failed...
11.38.30 #       <amiconn> My router is configured for dcc, and it already worked with some people
11.41.34 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
11.42.41 #       <[IDC]Dragon> email then (upload takes a while, 1.5 MB)
11.42.42 #       <amiconn> [IDC]Dragon: The mbr check is not necessary. I found the bug in my config sector calculation... really stupid one
11.43.05 #       <[IDC]Dragon> too late, on the way...
11.43.16 #       <[IDC]Dragon> but perhaps worth keeping
11.43.39 #       <amiconn> I wonder why the compiler did not complain... I wrote if(fat_startsector != 0) instead of if(fat_startsector() != 0)  Argh!
11.44.04 #       <[IDC]Dragon> you compared the function pointer
11.44.12 #       <amiconn> Yes.
11.49.22 #       <amiconn> Testing again...
11.53.10 Quit    marc77 (" WOW! This IRC Client ownz! HydraIRC -> http://www.hydrairc.com <-")
12.14.04 Quit    Schoki2 ("Client Exiting")
12.14.44 Join    webguest99 [0] (~acb24539@labb.contactor.se)
12.16.35 #       <webguest99> I connected my Jukebox to the computer and played musik from it. Suddenly it turned off. Now it doesn`t react, no matter which buttons I try.
12.17.12 #       <webguest99> I connected it to the wallcharger because I thought of a Batterie problem but that doesn`t help.
12.17.19 #       <webguest99> Who can help me???
12.22.23 Quit    webguest99 ("CGI:IRC (EOF)")
12.24.06 #       <[IDC]Dragon> F1+plugin?
12.24.17 #       <[IDC]Dragon> oh, he left
12.30.08 Join    webguest91 [0] (~539da98f@labb.contactor.se)
12.30.55 Quit    webguest91 (Client Quit)
12.42.03 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
12.45.31 Join    Toni [0] (~d5062e11@labb.contactor.se)
12.45.42 #       <Toni> Hi there.
12.46.03 #       <Toni> Big progress in Ondio development. :-)
12.47.08 #       <Toni> Today I got a new SD card 1GB which shows at startup "No partition found Insert USB cable to fix it"
12.47.32 #       <[IDC]Dragon> Hi Tony
12.47.38 #       <Toni> After doing it, playing works fine
12.47.54 #       <[IDC]Dragon> you got an Ondio, obviously?
12.48.07 #       <Toni> Seems that this disk has no 55aa at the end of boot sector
12.48.38 #       <Toni> Yes the one with 1GB MMC> problems
12.49.06 #       <[IDC]Dragon> ah
12.49.13 #       <[IDC]Dragon> our 1st user
12.49.20 #       <Toni> Now MMC works fine except USB connection on WinXP
12.49.41 #       <Toni> Is there any timeout?
12.50.10 #       <Toni> because Win tries to read the card, but gives up after e few second
12.51.15 #       <Toni> After that I can select the new Drive, but the Message says "Please insert disc"
12.52.51 Quit    AciD (Read error: 104 (Connection reset by peer))
12.53.50 Join    R3nTiL [0] (~zorroz@182-250-30-217.kgts.ru)
12.54.15 #       <Toni> The original archos firmware refuses the USB connection with inserted MMC by saying: "Please remove MMC card first"
12.54.20 ***     Saving seen data "./dancer.seen"
12.54.50 #       <Toni> Currently the only way to load the MMC is to use a card reader
12.55.55 #       <[IDC]Dragon> there's nothing we can do for USB mode
12.56.22 #       <Toni> ooh :-(
12.58.32 #       <Toni> Bye.
12.58.37 Part    Toni
13.07.03 Join    tron_ [0] (~tron@c181092.adsl.hansenet.de)
13.10.16 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
13.19.50 Quit    R3nTiL ()
13.21.48 #       <[IDC]Dragon> amiconn: recording works
13.22.05 #       <[IDC]Dragon> no changes, just adapting the screen
13.26.03 #       <amiconn> Argh, missed Toni
13.26.22 #       <[IDC]Dragon> any news for him?
13.26.37 #       <amiconn> My test ran ok, no corrupted fat
13.26.56 #       <[IDC]Dragon> as expected
13.27.55 #       <amiconn> Yes, I know what causes the "no partition", because now that I fixed the config sector calc I get this too. His new MMC is obviously formatted in superfloppy mode
13.29.38 #       <amiconn> There seems to be no way with WinXP to create a partition table on such a card.
13.31.25 #       <[IDC]Dragon> nbo void space on superfloppy, right?
13.31.28 #       <[IDC]Dragon> no
13.32.06 #       <amiconn> Yes, superfloppy means no partition table, file system starts at sector 0
13.39.36 #       <amiconn> I know what causes the non-working usb access to an inserted mmc from Windows. I'm going to implement mmc change handling while on usb, and the "Please remove..." message thing
13.40.16 #       <[IDC]Dragon> the transition from SPI to MMC mode, I guess
13.40.24 #       <[IDC]Dragon> or, the lack of
13.41.09 #       <amiconn> Yes, partially. You have to extract the inserted mmc first, because that transition is not possible without power cycling.
13.41.38 #       <[IDC]Dragon> I wish they've spent a transistor for that...
13.42.12 #       <amiconn> Then USB connects to the internal flash of course. If you insert a card while on USB, the bridge gets deactivated and reactivated by the archos fw, causing the PC to detect the change
13.42.25 #       <amiconn> We have to implement this too
13.42.59 #       <amiconn> Yes a transistor would have solved the problem, the same way as the reset pin does for the internal flash
13.43.13 #       <[IDC]Dragon> other topic: recording from mic sounds crappy
13.43.26 #       <amiconn> Uh?
13.43.30 #       <[IDC]Dragon> a buzzing noise
13.47.29 #       <amiconn> Try if it gets better when you change mp3_playback.c, line 556 to  val = 0x2d;  This should disable spdif out from the mas
13.54.05 #       <[IDC]Dragon> hmm, still noisy, I'm not sure if this is better
13.55.08 #       <amiconn> So it's likely caused by something else you have to find. I presume with the original fw recording from mic is ok?
13.55.34 #       <[IDC]Dragon> guess not
13.57.34 #       <[IDC]Dragon> problem: without RTC, all recordings get the same filename
13.58.08 #       <[IDC]Dragon> I'll have to make a counter or such
13.58.56 #       <amiconn> They should not. Isn't there a pseudo-time calculation for the fs that gradually increments for each file written?
14.00.01 #       <[IDC]Dragon> no, get_time() returns a constant
14.00.35 Join    _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
14.00.39 #       <_aLF> hi
14.00.39 #       <amiconn> Ah, then it's used for the file system only, unavailable from get_time()
14.01.34 #       <[IDC]Dragon> I need to do something like the default name for .cfg saving
14.02.03 #       <amiconn> Yup
14.02.37 #       <amiconn> Tested high bitrate, it goes silent for me too, and returns after ~50 s
14.03.42 #       <[IDC]Dragon> you could use your scope to see if there's any MMC activity meanwhile
14.04.07 #       <amiconn> Otherwise playback works fine even for the highest possible itrate (384 kbps mp2)
14.04.32 #       <[IDC]Dragon> wit 3 MBit we're way ahead of this
14.08.57 #       <amiconn> It also happens when you skip to a high-bitrate track
14.10.17 Join    Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc)
14.10.49 Quit    Sebulba02 ("++")
14.14.29 #       <[IDC]Dragon> gotta leave now
14.14.36 Quit    [IDC]Dragon ()
14.37.43 Join    Toni [0] (~d5062b84@labb.contactor.se)
14.37.56 #       <Toni> amiconn, r u there?
14.38.26 #       <amiconn> Yup
14.38.42 #       <Toni> I donīt think, my SD-card is super-floppy formatted.
14.39.43 #       <Toni> When I do system_reboot() right after first time disk_init() the next time disk_init() is ok.
14.39.49 #       <Toni> Strange, or?
14.40.31 #       <amiconn> Hmm. What does the debug info tell about that problematic MMC?
14.40.50 #       <Toni> * just checking
14.42.36 Join    _Schoki [0] (minuth@DSL01.212.114.233.144.NEFkom.net)
14.42.56 #       <Toni> 25MBit/s, 1.5ms, 0clk, *16
14.43.33 #       <amiconn> It's really 25 MBit/s ?? That value
14.43.47 #       <Toni> Itīs a SD-card.
14.44.08 #       <amiconn> ..is not specified for MMC, at least for 3.x standard
14.44.21 #       <amiconn> How do you fit an SD card into the slot?
14.44.45 #       <Toni> hard, but its fit somewhat
14.45.30 #       <amiconn> Urgs. SD is thicker than MMC, I tried it, doesn't fit without forcing it
14.46.08 #       <amiconn> I wonder if the SD init is sligtly different, and if I could adapt the driver to that
14.46.29 #       <amiconn> OT: I just fixed the high-bitrate playback probs in cvs
14.46.58 #       <Toni> Yes, thatīs true. My sister (another Ondio user) got that SD-card by accident and is happy with herīs.
14.47.30 #       <amiconn> Did you try rockbox on her Ondio too?
14.47.37 #       <Toni> I just wanted to know, wether archos firmware prefers SD-card rather than MMCs, but it doesnīt seem so.
14.48.19 #       <Toni> Not yet, because she is no technician, but I can ask her to try.
14.48.24 #       <amiconn> Archos says only MMC is supported, but the SPI protocol is almost identical for SD and MMC, so it works if you can make the card fit
14.49.02 #       <amiconn> I would be interested in the debug data of her Ondio (Type, hw mask etc)
14.49.23 #       <Toni> OK, I will ask.
14.50.38 #       <Toni> Bye.
14.50.42 Part    Toni
14.54.24 ***     Saving seen data "./dancer.seen"
14.56.25 Quit    AciD (Read error: 104 (Connection reset by peer))
14.59.29 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
15.20.45 Quit    Sebulba03 ("brb")
15.24.05 Join    Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc)
15.35.39 Quit    _Schoki ("Client Exiting")
15.37.34 Quit    AciD (Read error: 104 (Connection reset by peer))
15.47.49 Join    Sebulba02 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc)
15.50.17 Part    Sebulba03
15.58.01 Join    webguest32 [0] (~d95d93d0@labb.contactor.se)
16.00.12 Join    AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
16.08.46 Quit    webguest32 ("CGI:IRC")
16.54.25 ***     Saving seen data "./dancer.seen"
17.28.10 Join    thegeek [0] (no@195.159.168.25)
17.33.20 Quit    AciD (Read error: 232 (Connection reset by peer))
17.36.53 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
17.38.28 Part    thegeek
18.19.59 Quit    ashridah (Read error: 110 (Connection timed out))
18.54.28 ***     Saving seen data "./dancer.seen"
19.14.14 Join    midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
19.14.44 Quit    midk (Nick collision from services.)
19.14.45 Nick    midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com)
19.21.33 Join    webguest73 [0] (~8446db8d@labb.contactor.se)
19.31.14 Quit    webguest73 ("CGI:IRC")
19.34.51 Quit    midk ("just STOP it arspy")
20.54.30 ***     Saving seen data "./dancer.seen"
21.37.37 Quit    tron_ (Remote closed the connection)
21.41.33 Join    [IDC]Dragon [0] (~idc-drago@pD9FF8A2C.dip.t-dialin.net)
21.42.12 #       <amiconn> Good evening Jörg
21.42.22 #       <[IDC]Dragon> hello again
21.42.38 #       <[IDC]Dragon> back from shopping, etc.
21.42.56 #       <amiconn> I just extracted the remainders of backlight (menu entries, settings bits). Commit pending
21.43.18 #       <[IDC]Dragon> oh, I was about to revive that
21.43.25 #       <amiconn> Uh? Why?
21.43.40 #       <[IDC]Dragon> because the Ondio has a preparation for backlight
21.43.54 #       <[IDC]Dragon> maybe the earlier model have it
21.44.40 #       <amiconn> Hmm. It's a config option anyway, so it's simply changing a #define to reenable it
21.44.40 #       <[IDC]Dragon> the Archos s/w uses that pin like such
21.44.45 #       <amiconn> Ah
21.45.00 #       <[IDC]Dragon> after keypress, it stays on for a while
21.45.45 #       <amiconn> Could the backlight presence be runtime detected? Perhaps switching the pin to input and check level?
21.45.51 #       <[IDC]Dragon> we just have a different kind of backlight (different port bit)
21.46.18 #       <[IDC]Dragon> it doesn't hurt to just drive it
21.46.48 #       <[IDC]Dragon> dunno if we could detect, perhaps not
21.46.57 #       <amiconn> Of course driving it doesn't hurt, but I think it'd be a bit confusing to a user to find settings for a non-existing backlight
21.47.49 #       <amiconn> We should add that to our "help needed" question: "Does your Ondio have a backlight?"
21.48.25 #       <[IDC]Dragon> backlight should be a multi-value config entry, too
21.48.32 #       <amiconn> So what should I do now with my changes?
21.49.13 #       <[IDC]Dragon> the player has it on a port, Recorders on I2C, Ondio on another port, iriver again different
21.49.43 #       <[IDC]Dragon> commit them, I'd say, as you mentioned it's a switch
21.50.48 #       <amiconn> The switch was already there, I only #ifdef'ed out some sections in wps-display.c, settings_menu.c, settings.c
21.51.19 #       <[IDC]Dragon> yes, currently it's HAVE_BACKLIGHT
21.51.46 #       <amiconn> Ok, so I should commit before you change it to a multi-value option
21.52.04 #       <[IDC]Dragon> yes, please.
21.52.07 #       <amiconn> Don't forget to account for no beacklight in your choices
21.52.31 #       <amiconn> Just checking if it works for recorder (i.e. does remove nothing)
21.52.33 #       <[IDC]Dragon> like some multi-values, not defined means absent
21.52.51 #       <[IDC]Dragon> I need to reboot
21.52.53 #       <amiconn> Ah ok. The config options should be documented somewhere
21.53.08 #       <[IDC]Dragon> config.h?
21.53.15 Quit    [IDC]Dragon ()
22.00.48 Join    [IDC]Dragon [0] (~idc-drago@pD9FF8A2C.dip.t-dialin.net)
22.00.54 #       <amiconn> Hi again
22.01.02 #       <[IDC]Dragon> ;-)
22.01.08 #       <amiconn> Backlight changes committed.
22.01.08 #       <[IDC]Dragon> that was 2 reboots
22.01.24 #       <[IDC]Dragon> thanks
22.01.53 #       <amiconn> I plan to do the same with the disk settings (only setting here is disk spindown, which has no meaning on Ondio)
22.02.38 #       <[IDC]Dragon> makes sense, yes
22.02.58 #       <amiconn> The keyboard needs to be adapted. I wanted to save a .cfg in order to avoid re-setting all my settings every time the config block changes...
22.03.16 #       <[IDC]Dragon> you can, just have to wait
22.03.23 #       <amiconn> ?
22.03.31 #       <[IDC]Dragon> it creates one
22.03.50 #       <amiconn> Ah. Still the keyboard would be handy.
22.04.00 #       <[IDC]Dragon> of course.
22.04.21 #       <[IDC]Dragon> if only we had keys... ;-)
22.04.29 #       <amiconn> Before you are going to implement your file count for recording, please note that this could be handy in other places too
22.04.43 #       <[IDC]Dragon> like what?
22.04.59 #       <amiconn> Screenshot
22.05.16 #       <[IDC]Dragon> how is it done now?
22.05.24 #       <amiconn> ?
22.05.28 #       <[IDC]Dragon> like .cfg?
22.05.40 #       <[IDC]Dragon> the name generation, I mean
22.05.52 #       <amiconn> Screenshot works the same way as recording now (prefix + time stamp)
22.06.29 #       <[IDC]Dragon> ah
22.06.48 #       <amiconn> There is already some code that does the check-and-increment for .cfg, so I think you could just try to make this generic and globally reusable
22.07.15 #       <[IDC]Dragon> the .cfg counts and tries to open to check for existence
22.07.28 #       <amiconn> Yes, that's what I thought
22.07.38 #       <[IDC]Dragon> if it finds a nonexisting, this will be the name to use
22.07.59 #       <amiconn> Screenshot is a debug menu function anyway, but it would be handy to be able to take several screenshot without overwriting the old ones
22.08.06 #       <[IDC]Dragon> so it "fills holes", if there should be any
22.08.19 #       <[IDC]Dragon> for recording, I plan to do different
22.08.32 #       <amiconn> Why/ how?
22.08.41 #       <[IDC]Dragon> I'd like to iterate the directory and determine the highest number
22.08.55 #       <[IDC]Dragon> then increment and create that
22.09.15 #       <amiconn> Ah ok. Could be used for .cfg and screenshots too
22.09.27 #       <[IDC]Dragon> this way, later recordings will always have higher numbers, even if you erased some inbetween
22.09.49 #       <[IDC]Dragon> makes it easier to find it
22.10.12 Quit    scott666_ ("i'll be back...eventually...")
22.10.58 #       <amiconn> I'd suggest to create 2 functions: One that creates these incremental-numbered files with a prefix, and one that creates these prefix + timestamp variant (for platforms with an RTC)
22.11.38 #       <amiconn> For recording and screenshot, decide via #define which one to use. Config should always use the incremented version
22.11.40 #       <[IDC]Dragon> if the latter is worth the outsourcing, yes
22.13.09 #       <[IDC]Dragon> OT: bought a new toy today, a DVD writer
22.13.52 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.15.36 #       <amiconn> [IDC]Dragon: More settings to remove: Car adapter mode, Button bar
22.15.58 #       <[IDC]Dragon> yes, how to define that?
22.16.21 #       <[IDC]Dragon> car adapter mode should depend on HAVE_BATTERIES
22.16.28 #       <scott666_> does the ondio have an RTC?
22.16.33 #       <amiconn> scott666_: no
22.16.33 Nick    scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.16.45 #       <[IDC]Dragon> which should better be renamed to HAVE_CHARGING
22.17.03 #       <[IDC]Dragon> button bar can depend on the recorder keypad
22.17.13 #       <amiconn> Button bar is obvious, yes
22.18.32 #       <amiconn> The HAVE_BATTERIES had a slightly different meaning when there was neo support. We have to check if undefing it has no unwanted side effects.
22.18.49 #       <amiconn> Then it could be renamed to HAVE_CHARGING
22.20.20 #       <amiconn> The defaults for max. files per dir and max. playlist size should be changed for Ondio too.
22.20.35 #       <amiconn> (Ok, at least the latter)
22.22.24 #       <[IDC]Dragon> who knows what people will do with their GB cards
22.22.58 #       <[IDC]Dragon> no real need to save RAM, we're not afraid of spinups
22.23.13 #       <amiconn> I'm merely talking about defaults here.
22.23.52 #       <amiconn> I noticed that the config struct members are mostly unconditionally defined, so they are there for non-existing features. Dunno if it's worth to make them conditional
22.24.39 #       <[IDC]Dragon> I chatted with LinusN or Zagor about it, they said they intentionally didn't bother
22.25.03 #       <amiconn> Ah ok.
22.26.21 #       <amiconn> There is still no #define for ordinary ATA, so I have to use that strange #ifndef HAVE_MMC to get rid of the harddsik menu
22.27.49 #       <[IDC]Dragon> another mutivalue item: CONFIG_STORAGE or such
22.28.10 #       <amiconn> [IDC]Dragon the multivalue guy ;)
22.28.40 #       <[IDC]Dragon> #ifndef HAVE_MMC is proably fine for now, I don't expect a large variety soon
22.29.01 #       * [IDC]Dragon feels so multivalent
22.31.40 #       <amiconn> OT: Do you still have some spare flash chips?
22.31.49 #       <[IDC]Dragon> ye
22.31.56 #       <[IDC]Dragon> yes
22.36.45 #       <amiconn> May I send you my Studio for some soldering?
22.37.17 #       <[IDC]Dragon> please do the uart boot first
22.37.32 #       <amiconn> Okay, I'll try that first.
22.37.34 #       <[IDC]Dragon> but yes, you may ;-)
22.38.06 #       <[IDC]Dragon> mobile phone cables are good for level converters
22.42.48 #       <amiconn> What do you mean?
22.43.24 #       <[IDC]Dragon> they contain the +/- 12V to 3V level converter which we need
22.43.53 #       <[IDC]Dragon> RS232 adapters
22.44.08 #       <amiconn> Ah. Maybe a self-made converter is cheaper
22.44.31 #       <amiconn> First I need a serial interface anyway
22.45.01 #       <[IDC]Dragon> sometimes those are found for cheap on a "Grabbeltisch"
22.45.48 #       <[IDC]Dragon> I have a USB to serial adapter, should check itf that works
22.46.54 #       <amiconn> Yes, that would be nice to know before I buy one. I am restricted to use such a beast
22.47.37 #       <[IDC]Dragon> hang on...
22.54.34 ***     Saving seen data "./dancer.seen"
22.56.18 #       <[IDC]Dragon> hmm, not exactly working right away
22.58.37 #       <amiconn> What does it do (or not)?
23.00.48 #       <[IDC]Dragon> it doesn't move at all
23.03.55 #       <amiconn> Hmm, I wonder why. If the serial port is available in windows, everything that doesn't directly bang the hardware should work. Gdb (in turn cygwin) certainly uses system calls, so I wonder what prevents it from working
23.05.05 #       <[IDC]Dragon> this is not gdb
23.05.26 #       <[IDC]Dragon> I tried my uart boot, but meanwhile a terminal
23.05.37 #       <[IDC]Dragon> no go even with that
23.05.53 #       <amiconn> Hmm, Hyperterminal should definitely work
23.06.09 #       <[IDC]Dragon> so I'd say there's something wrong with the USB -> RS232 cable
23.07.01 #       <amiconn> I can get one for € 19,-. Do you think the price is okay?
23.07.22 #       <[IDC]Dragon> I think so
23.07.38 #       <amiconn> Buttonbar is gone...
23.07.46 #       <[IDC]Dragon> hehe
23.10.18 #       <[IDC]Dragon> would I bug you if I ask for flashing again?
23.10.47 #       <[IDC]Dragon> you can write the Archos s/w in the second flash half
23.11.12 #       <[IDC]Dragon> giving you back the classic behaviour, even without holding a button
23.11.13 #       <amiconn> What's the first (alternate) image then? I thought it is the archos fw?
23.11.19 #       <amiconn> Ah ok
23.11.23 #       <[IDC]Dragon> as well, yes
23.11.34 #       <[IDC]Dragon> you decide on the second
23.11.41 #       <amiconn> What Rockbox image is in the second image? Does it contain my new driver?
23.12.00 #       <[IDC]Dragon> not yet, but I canprepare that
23.12.11 #       <[IDC]Dragon> or, you flash it afterwards
23.12.19 #       <amiconn> Is it empty then , or does it contain an older rockbox?
23.12.35 #       <[IDC]Dragon> from 2 days ago, working filesystem
23.13.24 #       <amiconn> I'd suggest you prepare a new image (although I'll use the current one now), e.g. because of the bugs fixed
23.13.50 #       <amiconn> Let's hope that I don't mis-flash, with no serial port...
23.13.56 #       <[IDC]Dragon> for "real" distribution, I will leave the 2nd empty
23.14.17 #       <[IDC]Dragon> so it's the user's choice
23.14.44 #       <[IDC]Dragon> for now, I have the second in to improve chances that at least one works
23.15.23 #       <amiconn> What are the keys for the bootloader to select the image?
23.15.50 #       <[IDC]Dragon> back is F1, up F2, right F3
23.16.14 #       <[IDC]Dragon> so hold back to force image #1
23.16.22 #       <amiconn> So you can go "back" to the archos fw - lol
23.16.24 #       <[IDC]Dragon> back=left
23.16.40 #       <[IDC]Dragon> yea, that came to me, too
23.17.51 #       <[IDC]Dragon> when you did firmware_flash, you can play your favourite .ucl right after that
23.18.26 #       <amiconn> So, now let's hope for the best...
23.19.34 #       <amiconn> Phew, all went well
23.20.04 #       <[IDC]Dragon> played your latest ucl?
23.20.31 #       <amiconn> Yes
23.20.48 #       <[IDC]Dragon> do both images start as desired?
23.20.51 #       <amiconn> Archos fw boots ok as well
23.21.34 #       <[IDC]Dragon> ok, so I can shrink the image to just Archos
23.21.45 #       <amiconn> Rombox hangs...
23.22.00 #       <[IDC]Dragon> oh, works for me
23.22.29 #       <[IDC]Dragon> ordinary rockbox ucl works?
23.23.15 #       <amiconn> Yes
23.23.46 #       <amiconn> Rombox is not completely hung, it is stuck on the boot logo, but the button poweroff is captured
23.23.52 #       <[IDC]Dragon> maybe ROMbox got a wrong start address?
23.24.18 #       <amiconn> I think you figured the start address from the image I sent you?
23.24.31 #       <[IDC]Dragon> yes, but I'm human
23.25.06 #       <[IDC]Dragon> please compare what the flash plugin tells with the config value
23.25.34 #       <amiconn> Where does the flash plugin tell that?
23.25.48 #       <[IDC]Dragon> when you play a ucl
23.26.07 #       <[IDC]Dragon> it says found image at xx KB or so
23.26.10 #       <amiconn> Ah. It says at 72 KB
23.26.52 #       <amiconn> so 0x12010 should be correct
23.27.56 #       <[IDC]Dragon> then I don't know
23.28.39 #       <[IDC]Dragon> try flashing the Archos ucl, to get back "classic boot"
23.29.04 #       <amiconn> I have to create one first
23.29.15 #       <[IDC]Dragon> no, it's in my webspace
23.29.48 #       <[IDC]Dragon> http://joerg.hohensohn.bei.t-online.de/archos/flash/archos_ondiosp132.ucl
23.30.26 Quit    methangas (" HydraIRC -> http://www.hydrairc.com <- :P")
23.31.26 #       <amiconn> Works, and loads rockbox from disk.
23.31.39 #       <amiconn> I wonder what is wrong with rombox...
23.32.26 #       <[IDC]Dragon> this new "classic" boot should be a bit faster then it used to
23.32.57 #       <[IDC]Dragon> because my decompressing bootloader is faster than the Archos' descrambling one
23.33.00 #       <amiconn> Yes it is. The progress bar is no longer there
23.33.33 #       <amiconn> The archos bootloader takes *that* long for just descrambling?
23.34.19 #       <[IDC]Dragon> probably it's that monitor again, they had a 2 stage boot on recorders
23.35.02 #       <[IDC]Dragon> the boot rom descrambles not the image, but a monitor
23.35.38 #       <[IDC]Dragon> the monitor waits very briefly for a RS232 command, then descrambles the real image
23.36.24 #       <[IDC]Dragon> ths monitor can in fact be used for download, flashing, and a few other tricks
23.36.28 #       <[IDC]Dragon> this
23.36.39 #       <amiconn> I think you approach (selecting the monitor via a button) is way better. I hate devices that take long to initialize. Best is instant-on
23.36.53 #       <[IDC]Dragon> yep
23.37.13 Join    methangas [0] (methangas@0x50a476ab.virnxx10.adsl-dhcp.tele.dk)
23.37.15 Quit    methangas (Client Quit)
23.43.24 #       <amiconn> What do you think which thread should monitor the MMC button and generate the SYS_ events? I vote for the mmc thread...
23.43.47 #       <[IDC]Dragon> or USB?
23.44.30 #       <amiconn> Imho this has nothing to do with USB, although the USB needs those events. Later the filesystem will need them too
23.44.34 #       <[IDC]Dragon> USB already monitors a switch
23.44.59 #       <[IDC]Dragon> MMC can only do this if it doesn't block anywhere
23.45.17 #       <[IDC]Dragon> dunno i that's the case
23.45.21 #       <[IDC]Dragon> if
23.46.21 #       <amiconn> The mmc thread currently blocks on usb, but that could  be changed
23.46.50 #       <amiconn> The mmc thread currently does nothing useful
23.48.24 #       <amiconn> For real ata, the thread blocks on usb in order to generate no unwanted accesses while usb is connected. This is a non-issue with mmc (no idle timeout)
23.50.26 #       <[IDC]Dragon> if it fits, better place it in the MMC thread
23.53.25 Join    gromit``` [0] (~gromit@ALagny-151-2-10-25.w82-121.abo.wanadoo.fr)
23.56.33 #       <amiconn> [IDC]Dragon: Did you already do something to the backlight config options? I found a place that is missing an #ifdef - plugin.[ch]
23.57.18 #       <amiconn> Ah no, you provided dummy functions
23.57.18 #       <[IDC]Dragon> ?