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

00.01.24 #       <amiconn> I wonder why PA13 is set to be /irq1 though. The global archos init doesn't do this, the transfer routines set it to GP in while transferring, and there is no handler for it (interrupt vector is zero)
00.02.03 #       <[IDC]Dragon> then it's not set to /IRQ1, just polled
00.02.42 #       <amiconn> It is set to /irq 1: When rockbock is started, PACR1 reads 0x4402
00.03.42 Join    maikeul [0] (~gromit@ALagny-151-1-2-126.w82-121.abo.wanadoo.fr)
00.08.01 #       <amiconn> It seems there is something in rockbox that fiddles with PA12...
00.08.50 #       * amiconn is digging...
00.09.35 #       <[IDC]Dragon> that's always been an input, ata irq
00.10.57 #       <amiconn> I'm on to something: *when* is the adc initialized, and hence the values in adc_read[] valid?
00.11.34 #       <amiconn> ata_init uses that to determine whether a card is inserted, but chances are that there is no valid value yet...
00.12.02 #       <[IDC]Dragon> it may be set to /irq0 instead of GP in
00.12.11 #       <amiconn> So your select code does always select external, and internal can't work...
00.12.25 #       <[IDC]Dragon> perhaps, yes
00.12.26 #       * amiconn checks
00.14.44 #       <amiconn> That's it! The card doesn't answer because it is not selected. That doesn't explain the 0x05 though...
00.14.59 #       <[IDC]Dragon> ahh
00.16.53 #       <amiconn> Hmm. Dunno how to handle this. adc_init() is called before ata_init(), so it's a race...
00.17.31 #       <amiconn> Will test with Linus' new conversion code...
00.17.41 #       * amiconn hasn't updated cvs today
00.18.18 #       <[IDC]Dragon> what's the ADC got to do with that?
00.18.42 #       <amiconn> if(adc_read(ADC_MMC_SWITCH) < 0x200) ...
00.19.04 Quit    gromit`` (Read error: 110 (Connection timed out))
00.19.52 #       <amiconn> Hmm, adc.c didn't change. I thought that it did...
00.20.46 #       <[IDC]Dragon> it used to be that all adc readings are valid after adc_init(). dunno if that's still the case
00.21.12 #       <[IDC]Dragon> it waited for the first conversions
00.21.33 #       <[IDC]Dragon> which was only 1 bank, heh
00.23.41 #       <amiconn> There is an unused variable warning in button.c that Linus overlooked when changing the button handling...
00.24.29 #       <[IDC]Dragon> something serious?
00.25.07 #       <amiconn> The debouncing has to be adapted for the Ondio (this has nothing to do with the mmc problems, just found it while compiling)
00.27.09 #       <[IDC]Dragon> Zagor: FAT16 for all (without #ifdef) has a code size penalty of 752 bytes
00.28.06 #       <Zagor> that's well within acceptable
00.28.14 #       <[IDC]Dragon> with the routines you mentioned pulled together, if(is_fat16) in the innermost loop
00.28.35 #       <[IDC]Dragon> which is some performance penalty
00.28.56 #       <Zagor> is it really? aren't most of those waiting for disk i/o anyway? (can't remember, and am not looking :)
00.29.30 #       <[IDC]Dragon> perhaps not really, compared to the disk I/O
00.32.55 Quit    GhUl ("Leaving")
00.33.13 #       <amiconn> Added Linus' debouncing to the ondio button driver - now the behaviour is even more erratically than without :-(
00.33.34 #       <Zagor> the button behaviour or the mmc behaviour?
00.33.42 #       <amiconn> Argh! Obviously I'm silly
00.34.04 #       <[IDC]Dragon> perhaps do a sleep(8) before using adc values
00.34.31 #       <amiconn> I should rather do a sleep(/me) more often...
00.34.36 #       <Zagor> :)
00.35.02 #       <[IDC]Dragon> lol
00.37.08 #       <amiconn> With sleep(10) before the internal/external selection, the select now works. However, I still get response 0x05 (idle state | illegal command)  :(
00.37.56 #       <amiconn> The debouncing works nicely now, fix committed
00.38.40 #       <[IDC]Dragon> did yours bounc before?
00.38.47 #       <amiconn> yup
00.38.55 #       <amiconn> (Ondio)
00.52.36 #       <Zagor> new nude board scans up
00.52.43 ***     Saving seen data "./dancer.seen"
00.52.58 #       <[IDC]Dragon> uh, dirty
00.53.12 #       <Zagor> very :)
00.54.28 #       <amiconn> [IDC]Dragon: sleep(1) is sufficient (conversion of all 8 adc channels needs ~90 µs)
00.54.59 #       <[IDC]Dragon> but only one is done per tick?
00.55.01 #       <Zagor> btw, we found the extra eeprom chip (for isd300 config data)
00.55.17 #       <[IDC]Dragon> "found"?
00.55.42 #       <Zagor> yeah it was hidden between the motherboard and the usb daughterboard
00.55.58 #       <amiconn> [IDC]Dragon: No, the tick now starts the conversion for the first bank. The end of conversion for the first bank triggers an irq that starts the second bank.
00.56.53 #       <[IDC]Dragon> that daughterboard looks plugged
00.57.01 #       <[IDC]Dragon> not soldered
00.57.12 #       <Zagor> correct
00.57.33 #       <Zagor> it's held in place by solder, but not connected by it
01.00.28 #       <[IDC]Dragon> well, I'll do a sleep(6) now
01.00.35 #       <amiconn> ;)
01.00.39 #       <Zagor> good night
01.00.43 #       <amiconn> good night
01.00.50 #       <[IDC]Dragon> nighty
01.00.55 Quit    [IDC]Dragon ()
01.14.09 Quit    AciD (".L")
01.14.17 Quit    Zagor ("Client exiting")
01.19.03 Quit    Sebulba02 ("restarting X")
01.20.35 Quit    amiconn (" sleep(6);")
01.39.19 Quit    kaboofa ("leaving")
01.50.43 Join    bagawk [0] (Lee@bagawk.user)
02.27.31 Quit    mecraw_ ("Trillian (http://www.ceruleanstudios.com)")
02.38.19 #       <bagawk> Bagder: you will not believe what i have strted    lol
02.38.50 #       <bagawk> (maybe you will...)
02.47.20 #       <scott666_> bagawk: what?
02.47.26 Nick    scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com)
02.47.44 Join    [av]bani [0] (~goemon@washuu.anime.net)
02.47.50 #       <[av]bani> http://rockbox.haxx.se/iriver/ata_front_medium.jpg
02.48.00 #       <[av]bani> hah, i was right. another eeprom, properly sized
02.48.30 #       <[av]bani> 256x8
02.52.04 Join    watchminister [0] (Anne@a20104.upc-a.chello.nl)
02.52.12 Part    [av]bani
02.52.45 ***     Saving seen data "./dancer.seen"
02.52.56 Quit    midk (Read error: 104 (Connection reset by peer))
02.53.09 Join    midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com)
03.01.49 Part    kaouete
03.06.54 Quit    watchminister ("Those who would give up essential Liberty, to obtain a little temporary Safety, deserve neither Liberty nor Safety.")
04.34.04 Quit    bagawk ("umount /dev/brain")
04.52.49 ***     Saving seen data "./dancer.seen"
06.25.51 Part    scott666
06.41.19 Join    LinusN [0] (~linus@labb.contactor.se)
06.48.09 #       <dwihno> Dr. L!
06.52.50 ***     Saving seen data "./dancer.seen"
06.57.43 #       <LinusN> :-)
06.59.52 #       <dwihno> When merging postscript level 2 objects with a postscript level 3 object, will the levels still be separated or will they both become level 3?
07.10.36 Join    methangas [0] (methangas@0x50a476f8.virnxx10.adsl-dhcp.tele.dk)
07.11.19 #       <LinusN> dwihno: i have absolutely no clue, it must have been 10 years since i wrote postscript scripts
07.15.13 #       <dwihno> Whoa
07.15.27 #       <dwihno> Back in the days when I was still fooling around with transformers and he-man action figures :)
07.22.19 #       <LinusN> transformers? never worked with transformers, too analog for me :-)
07.24.41 #       <pyros> heh
07.30.37 #       <dwihno> :-)
07.37.05 Join    amiconn [0] (~jens@pD95D135A.dip.t-dialin.net)
07.48.15 #       <amiconn> morning all
07.48.36 #       <pyros> hi
07.49.03 #       <LinusN> hi
07.49.54 #       <amiconn> LinusN: Would it be possible to restore the old behaviour of the adc driver, that there are valid values after adc_init() ended?
07.50.49 #       <LinusN> why?
07.52.57 #       <amiconn> I had to sort out a race condition caused by the new behaviour of the adc driver on Ondio. Correct adc values are needed at ata_init() to decide whether internal flash or mmc should be initialized
07.53.54 #       <amiconn> Currently I'm doing a sleep(1), but imho it would be more logical that the adc driver ensures correct readings
07.53.55 Join    [IDC]Dragon [0] (~idc-drago@pD9512780.dip.t-dialin.net)
07.55.03 #       <[IDC]Dragon> hi amiconn, it looks like you barely did a sleep(6) tonight
07.55.07 #       <LinusN> then put the sleep() in adc_init
07.55.41 #       <LinusN> i think it's unnecessary to have two ADC read functions just to save a few milliseconds
07.55.48 #       <amiconn> LinusN: Ok
07.56.01 #       <amiconn> [IDC]Dragon: It was more like a sleep(5) ...
07.56.25 #       <LinusN> i have an average of about sleep(4) the last 2 weeks ...
07.57.09 #       * [IDC]Dragon needs sleep(7) for correct operation
07.57.39 #       <[IDC]Dragon> but have no kids, that'll train
08.00.22 #       <[IDC]Dragon> amiconn: somebody here recently tried compiling with /Os, gained about 1.5 KB
08.00.52 #       <amiconn> Hmm, so it's not enough to fit rombox on fm
08.02.04 #       <amiconn> It looked at lots of disassembler listings last time. From these I found that rockbox code (compiled with -O) is often rather inefficient. When compiling with -O2, it does look much better
08.02.13 #       <amiconn> s/It/I/
08.02.44 #       <[IDC]Dragon> but -O makes it easier to read ;)
08.03.45 #       <amiconn> Not necessarily.
08.04.06 #       <[IDC]Dragon> LinusN: saw the stripped ihp, poor little guy
08.06.50 #       <LinusN> i am a cruel person after all
08.08.41 #       <[IDC]Dragon> now playing "solder a wire to a pad, beep against all other pads"?
08.10.29 #       <dwihno> Have YOU beeped today? :)
08.11.04 #       <LinusN> no soldering, just beeping
08.11.29 #       <[IDC]Dragon> soldering helps holding ;-)
08.11.55 #       <LinusN> yeah, but it takes time...
08.12.11 #       <LinusN> and those pads are so damn small
08.12.36 #       <LinusN> plus, i don't have a soldering iron at hand right now
08.17.44 #       <dwihno> soldering helps beeping?
08.18.53 #       <[IDC]Dragon> then you don't hav to hold one end all the time
08.20.06 #       <LinusN> yeah, i know
08.20.25 #       <LinusN> but it means a lot of soldering/desoldering
08.42.18 Join    Zagor [242] (~bjst@labb.contactor.se)
08.45.03 #       <amiconn> [IDC]Dragon: I got a mail from an Ondio owner...
08.47.42 #       <Zagor> ooh, there are more of you? ;)
08.48.56 Quit    Headie (Read error: 54 (Connection reset by peer))
08.50.43 #       <[IDC]Dragon> Zagor: no bad jokes, please
08.51.10 #       <Zagor> ? something bad happened?
08.51.24 #       <[IDC]Dragon> not working yet...
08.51.50 #       <[IDC]Dragon> and not too much demand
08.52.19 #       <[IDC]Dragon> amiconn: what did he/she say?
08.52.54 ***     Saving seen data "./dancer.seen"
08.53.20 #       <amiconn> A german user that obviously tried the current daily on an Ondio FM, realized that it doesn't play music yet, and asks if it should.
08.53.37 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
08.53.54 #       <amiconn> I replied that this cannot work yet, but that he might be so kind and tell us some values from debug->view hw info
08.55.28 #       <Zagor> have you found some user forum or mailing lists for the ondio?
08.59.46 #       <amiconn> nope
09.02.29 #       <[IDC]Dragon> amiconn: the tuner hookup is indeed different
09.04.23 #       <[IDC]Dragon> PB0 (LCD data) is wired to the tuner board, but not connected there
09.05.22 #       <amiconn> Strange.
09.06.26 #       <amiconn> Although there seems to be more than one useless wiring...
09.07.19 #       <[IDC]Dragon> maybe they have an option to alternatively use the Samsung tuner like in the JBFM
09.21.03 #       <[IDC]Dragon> too bad BP0 already has a use, else it could become the new remote control pin, if I'd modify for a 4-pin jack
09.40.45 Join    amiconn_ [0] (~jens@pD95D1A7F.dip.t-dialin.net)
09.58.45 Quit    amiconn (Read error: 110 (Connection timed out))
09.58.46 Nick    amiconn_ is now known as amiconn (~jens@pD95D1A7F.dip.t-dialin.net)
10.08.51 #       <Zagor> "I do know that the H300's released in the states will NOT have USB on the go capability. They will support DRM but only through the USB 1.1 connection and only via WinXP and WMP 10 and above, NOT the USB 2.0 connection."
10.09.07 #       <Zagor> that's why they are released later in the US than the rest of the world
10.11.06 #       <[IDC]Dragon> bbl
10.11.09 Quit    [IDC]Dragon ()
10.18.30 Quit    Bagder ("Off to search for that connect-resetting peer guy!")
10.20.20 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
10.20.56 #       <Bagder> weird
10.21.08 #       <Bagder> had to reboot to get my CD drive to find CDs again
10.21.46 Join    webguest30 [0] (~c130220e@labb.contactor.se)
10.23.03 Quit    webguest30 (Client Quit)
10.23.30 #       <Zagor> wow
10.36.12 #       <Bagder> the windows install files aren't working atm
10.36.27 #       <Bagder> zero bytes
10.37.03 #       * dwihno is having a revelation. I just realized 95% of my computer knowledge has passed the "best before" date.
10.37.18 #       <Bagder> hehe
10.37.38 #       <dwihno> I'm serious :(
10.51.13 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
10.52.57 ***     Saving seen data "./dancer.seen"
10.54.19 #       <Bagder> I like how the configure output is now visible in the build logs
10.54.48 #       * [IDC]Dragon looks
10.55.47 #       <[IDC]Dragon> heh, it's like me can see the script typing the choices
10.56.01 #       <Bagder> yeps
10.57.46 Join    MooMaunder [0] (~me@194.152.87.150)
11.14.36 Quit    [IDC]Dragon ("CGI:IRC (EOF)")
11.15.00 #       <LinusN> Zagor: so how does the H300 USB connection work then?
11.15.24 #       <Zagor> I don't know, that was what misticjeff told me
11.19.12 #       <Bagder> www.rockbox.org
11.20.07 #       <Zagor> a thousand thanks to misticjeff for donating it
11.20.18 #       * Bagder bows to misticjeff
11.23.26 #       <dwihno> Way!
11.23.27 #       <LinusN> Zagor: put it up in the news on the main page
11.23.28 #       <dwihno> rockbox.org \o/
11.23.32 #       <Zagor> yup, i will
11.25.02 #       * Bagder runs off
11.30.28 #       <Zagor> lunch
11.39.11 Join    Cheekychops [0] (~me@194.152.87.150)
11.56.21 Quit    MooMaunder (Read error: 110 (Connection timed out))
12.20.17 Join    ashridah [0] (ashridah@dialup-a1-157.Melbourne.netspace.net.au)
12.21.13 Join    kurzhaarrocker [0] (~knoppix@p50876B30.dip0.t-ipconnect.de)
12.22.08 #       <kurzhaarrocker> LinusN: are you interestet in a rather huge recording with interesting recording bugs (stuttering recording)
12.24.02 #       <kurzhaarrocker> recorded with rockbox of 2004-08-25
12.28.31 #       <plok> Someone has started a thread on the iRiver user forums to try and drum up enough money for you guys to buy a H300.. they seem to have volunteered you into developing the H300 at the same time and prioritising their feature requests?
12.28.39 #       <plok> maybe someone should say something to them...
12.30.21 #       * Zagor looks
12.35.51 #       <LinusN> kurzhaarrocker: sure, put it up for download somewhere
12.36.55 #       * kurzhaarrocker scratches his head
12.36.55 #       <kurzhaarrocker> I don't have 325 MB webspace...
12.37.11 #       <amiconn> I have lots of test recordings... almost 5 GB
12.46.49 #       <kurzhaarrocker> LinusN: can you receive a mail that large?
12.48.20 #       <amiconn> kurzhaarrocker: Is it possible to dcc such a large file?
12.48.46 #       <kurzhaarrocker> No, the firewall prevents that :(
12.53.00 ***     Saving seen data "./dancer.seen"
12.56.58 #       <LinusN> no, i can't receive mails that large
12.58.10 #       <kurzhaarrocker> no horrible music for LinusN then :)
13.40.52 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
13.41.31 #       <[IDC]Dragon> I was wondering why the channel is so quiet today
13.41.44 #       <[IDC]Dragon> then I realizes my client is stuck
13.41.54 #       <Zagor> oops :)
13.43.33 #       <[IDC]Dragon> LinusN: do you read?
13.51.56 Join    R3nTiL [0] (~zorroz@167-250-30-217.kgts.ru)
14.01.12 Join    R3nTiL1 [0] (~zorroz@201-250-30-217.kgts.ru)
14.05.27 Quit    ze (Read error: 110 (Connection timed out))
14.06.29 #       <LinusN> [IDC]Dragon: yup
14.16.25 Quit    R3nTiL (Read error: 104 (Connection reset by peer))
14.26.52 Quit    R3nTiL1 ()
14.27.17 Part    kurzhaarrocker
14.36.16 #       <LinusN> the iriver buttons are read with the external A/D converted via SPI
14.36.19 #       <[IDC]Dragon> LinusN: now my response time was bad
14.36.33 #       <LinusN> :-)
14.36.54 #       <[IDC]Dragon> what a complicated way to poll buttons
14.37.08 #       <LinusN> especially when you have an internal ADC...!
14.40.21 #       <Zagor> LinusN: have you confirmed all buttons are connected to the same adc?
14.40.33 #       <Zagor> same channel
14.42.00 #       <LinusN> they are not
14.42.50 #       <[IDC]Dragon> I had a look at the tuner
14.43.06 #       <[IDC]Dragon> (same for Ondio   Iriver)
14.43.26 #       <[IDC]Dragon> but different to our Samsung
14.43.32 #       <Zagor> LinusN: ah, excellent
14.43.40 #       <LinusN> Zagor: and the Hold switch is connected to the adc!
14.44.36 #       <[IDC]Dragon> the FM part of Rockbox is not exactly nice
14.44.54 #       <Zagor> i must confess I've never looked at it...
14.45.30 Nick    midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com)
14.45.52 #       <LinusN> [IDC]Dragon: in what respect?
14.46.36 #       <[IDC]Dragon> exchanging the driver is not enough
14.47.11 #       <LinusN> no, that needs better abstraction
14.47.12 #       <[IDC]Dragon> the application code also has hardware magic numbers
14.47.23 #       <LinusN> hardware isn't magic :-)
14.47.53 #       <LinusN> but yes, we should move lots of that code doen to the driver
14.47.58 #       <LinusN> down
14.49.33 #       <[IDC]Dragon> viewed positive, the app code contains the "middle layer" as well
14.49.54 #       <[IDC]Dragon> versus the driver does only the physical
14.50.27 #       <[IDC]Dragon> the hookup of the tuner is a bit strange
14.50.41 #       <[IDC]Dragon> they use I2C mode
14.50.55 #       <[IDC]Dragon> but on a new pair of pins
14.52.05 #       <[IDC]Dragon> clock is shared with LCD
14.52.24 #       <[IDC]Dragon> I2C enable is the same as LCD /CS
14.52.42 #       <[IDC]Dragon> data has an independent pin (PB4)
14.52.56 #       <LinusN> it's not i2c, it's spi
14.53.01 ***     Saving seen data "./dancer.seen"
14.53.29 #       <LinusN> ah, you mean the ondio?
14.53.46 #       <[IDC]Dragon> I2C enable and LCD /CS have the _same_ polarity this time, I wonder how that works
14.53.58 #       <LinusN> wow
14.54.01 #       <[IDC]Dragon> bot are low active
14.54.04 #       <[IDC]Dragon> both
14.55.00 #       <[IDC]Dragon> i2c on the ondio, yes
14.55.11 #       <LinusN> so the lcd will see a CS without data transfer
14.55.23 #       <LinusN> funny, why CS when you are doing I2C?
14.55.27 #       <[IDC]Dragon> CS and clock
14.55.28 #       <LinusN> i2c has no cs
14.55.38 #       <[IDC]Dragon> this one has :-)
14.55.53 #       <[IDC]Dragon> it's a line waking it up
14.57.33 #       <LinusN> but the fm chip has basically the same interface?
14.57.45 #       <LinusN> i mean, an IM frequency counter etc?
14.58.02 #       <[IDC]Dragon> it has a PLL value, yes
14.58.45 #       <[IDC]Dragon> in general, it has more features
14.58.48 #       <LinusN> no, i mean IM frequency count for evaluating the channel
14.58.57 #       <[IDC]Dragon> e.g., it can scan for itself
14.59.01 #       <LinusN> aha
14.59.50 #       <[IDC]Dragon> but there is an IF readback
14.59.58 #       <LinusN> ok
15.00.27 #       <LinusN> s/IM/IF/ (silly me)
15.01.18 #       <LinusN> Zagor: it looks like the iriver disk LED control is only enabling the LED for the hard drive
15.01.59 #       <LinusN> so the cpu can't blink it :-(
15.02.46 #       <Zagor> ok
15.04.50 #       <elinenbe> LinusN: good luck with the wiggler and the ihp!
15.05.30 #       <ashridah> you guys got pics of your broken iriver around?
15.06.43 #       <[IDC]Dragon> ashridah: yes, see twiki
15.08.27 #       <ashridah> aha. found it
15.09.17 #       <[IDC]Dragon> this half-shared I2C is far from elegant
15.09.42 #       <[IDC]Dragon> always both the LCD and the tuner will feel enabled, get clocked
15.10.03 #       <[IDC]Dragon> only the data can be controlled seperately
15.10.32 #       <[IDC]Dragon> so we'd need to have data for the other which does no harm
15.11.32 #       <[IDC]Dragon> but I2C has a 9th bit, the ack
15.11.46 #       <[IDC]Dragon> so they will run out of byte sync?
15.12.03 #       * [IDC]Dragon finds this too confusing to be true
15.12.30 #       <amiconn> [IDC]Dragon: Maybe this needs some disassembling too...
15.12.37 #       <[IDC]Dragon> ;-)
15.15.13 #       <amiconn> I already read about your findings in the wiki and found it confusing too...
15.15.40 #       <amiconn> But then there is that MMC problem... maybe we need some voodoo magic ;)
15.16.05 #       <[IDC]Dragon> MMC in general, or a specific problem?
15.19.07 #       <amiconn> You already know that: the internal mmc answers to all commands (except go_idle_state) with "illegal command"
15.19.51 #       <amiconn> Next thing is that my external MMC seems to work ok, but your does not want to wake up from idle state
15.20.02 #       <amiconn> s/your/yours/
15.20.34 #       <[IDC]Dragon> it may be broken, I have problems with it
15.20.52 #       <[IDC]Dragon> no USB mode on it recently
15.21.30 #       <[IDC]Dragon> you remembered to bitswap your commands and responses?
15.21.48 #       <[IDC]Dragon> just asking stupid questions
15.24.10 #       <amiconn> Of course I do bitswap, and as I told, it works with my external card.
15.25.14 #       <[IDC]Dragon> sorry, just doublechecking
15.25.57 #       <[IDC]Dragon> all pins configured to their correct functions?
15.27.09 #       <amiconn> yup
15.35.00 #       <[IDC]Dragon> the internal card is already in SPI mode when we start, versus the external doesn't have to
15.35.13 #       <[IDC]Dragon> maybe that's a difference
15.40.16 Part    LinusN
15.42.10 #       <amiconn> [IDC]Dragon: I know, but repeated initialization works for the external card too.
15.44.26 #       <[IDC]Dragon> what about taking that bitbanging AVR code, porting that for a first start?
15.44.40 #       <[IDC]Dragon> AVR=Atmel
15.46.45 #       <amiconn> I'll try to decipher some more asm in the evening
15.46.52 Join    pike [0] (amiga@h234n1fls22o1064.bredband.comhem.se)
15.47.38 #       <amiconn> I don't think bitbanging will help here, since accessing the external mmc works. I suspect that the internal flash, which is accessed at boot, is left in some special state
15.51.09 #       <[IDC]Dragon> is there a timing to the reset? did you try opposite reset polarity?
15.56.28 #       <amiconn> There is no timing given in the datasheet. I tried to reset the flash before accessing it, with no effect. The reset timing I use (2 times sleep(5)) is derived from the timing of the archos fw. Archos timer does 200 ticks/s
15.56.58 #       <amiconn> I did not check with different polarity yet
16.10.04 #       <amiconn> Fortunately deciphering SH1 assembler isn't that hard, since it's a risc CPU. CISC would be much harder (iRiver coldfire comes to mind, as iirc this is (a bit cut-down) m68k)
16.11.24 #       <amiconn> Zagor: You could now remove the Neo35 column from the daily build table. It's empty..
16.12.39 #       <Zagor> yup
16.13.51 #       <Zagor> strangely slow mail day
16.25.19 Nick    maikeul is now known as maikeul`aw (~gromit@ALagny-151-1-2-126.w82-121.abo.wanadoo.fr)
16.31.46 #       <Bagder> the column will go away on its own
16.32.07 #       <Bagder> its only there because there are still build logs around for neo
16.32.33 #       <Zagor> right, i thought it would go away by itself
16.47.29 Join    mecraw_ [0] (~lmarlow@69.2.235.2)
16.52.58 Join    R3nTiL1 [0] (~zorroz@135-248-30-217.kgts.ru)
16.53.02 ***     Saving seen data "./dancer.seen"
17.14.56 Quit    mecraw_ (Read error: 104 (Connection reset by peer))
17.15.03 Join    mecraw_ [0] (~lmarlow@69.2.235.2)
17.17.11 Part    R3nTiL1
17.19.48 Part    Zagor
17.24.01 Quit    ashridah ("sleepz0r")
17.36.35 Join    ze [0] (psyco@adsl-64-161-172-211.dsl.lsan03.pacbell.net)
18.32.43 Join    _Schoki2 [0] (~Schoki@DSL01.212.114.235.47.NEFkom.net)
18.49.57 Join    R3nTiL1 [0] (~zorroz@152-248-30-217.kgts.ru)
18.53.05 ***     Saving seen data "./dancer.seen"
19.05.38 Quit    AciD (Read error: 60 (Operation timed out))
19.05.52 Quit    [IDC]Dragon ("CGI:IRC")
19.16.32 Quit    Bagder ("Off to search for that connect-resetting peer guy!")
19.21.45 Nick    maikeul`aw is now known as maikeul (~gromit@ALagny-151-1-2-126.w82-121.abo.wanadoo.fr)
19.26.59 Quit    R3nTiL1 ()
19.28.12 Join    quelsaruk [0] (unholiest@cbernal.ugr.es)
19.28.15 #       <quelsaruk> hi
19.33.30 #       <amiconn> hi quelsaruk
19.34.17 #       <quelsaruk> hi amiconn :)
19.34.57 #       <quelsaruk> after nearly 4 months without internet access, i've downloaded lattest rockbox and.. amazing! 
19.35.24 #       <amiconn> Are there still places on earth without internet access? ;)
19.35.35 #       <quelsaruk> portugal
19.35.36 #       <quelsaruk> ;)
19.36.31 #       <quelsaruk> but don't tell to portuguese people :D
19.37.13 #       <amiconn> In summer I stayed in Lisbon for a week...
19.37.44 #       <amiconn> There are loads of patches assigned to you waiting in the sourceforge patch tracker... I wonder if language related stuff is auto-assigned to you
19.39.05 #       <quelsaruk> yes
19.39.14 #       <quelsaruk> they were auto-assigned
19.39.36 #       <quelsaruk> long time ago i had i-net access at home (Spain) so i was up-to-date
19.40.04 #       <quelsaruk> so i suppose i'll have to work hard now
19.40.33 #       <quelsaruk> afaik we moved to rockbox own server instead of sourceforge one.. so i have to investigate that too.
19.41.13 #       <amiconn> Yes, cvs has moved, but patch/bug/rfe tracker is still on sourceforge
19.42.08 #       <quelsaruk> yups
19.46.32 #       <quelsaruk> hmmm, do you know anything about thompson lyra?
19.48.10 #       <amiconn> nope
19.48.30 #       <amiconn> (other than it exists ;) )
19.48.59 #       <quelsaruk> :)
19.49.16 #       <quelsaruk> i've seen it, and seems to be similar to archos recorder v2
19.49.25 #       <quelsaruk> but don't trust me too much
19.50.09 #       <quelsaruk> anyway, i prefer archos button structure, it's easier as we have less buttons
19.55.05 Join    PaulS [0] (~0d0274bd@labb.contactor.se)
20.01.03 #       <quelsaruk> time to go
20.01.04 #       <quelsaruk> cu!
20.01.11 #       <quelsaruk> have a nice weekend
20.01.12 #       <PaulS> Later!
20.02.03 Part    quelsaruk
20.38.15 Join    mecraw__ [0] (~lmarlow@69.2.235.2)
20.51.23 Part    _Schoki2 ("Leaving")
20.53.06 ***     Saving seen data "./dancer.seen"
20.56.15 Quit    mecraw_ (Read error: 110 (Connection timed out))
20.57.21 Join    AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
21.02.57 #       <PaulS> part
21.03.00 Part    PaulS
21.55.17 Join    scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.35.53 Join    [IDC]Dragon [0] (~idc-drago@pD9512780.dip.t-dialin.net)
22.37.50 #       <amiconn> Hi again, Jörg
22.38.15 #       <[IDC]Dragon> hi there
22.38.55 #       <amiconn> Got an answer from that other German Ondio user. Same debug data as yours (mask, flash etc)
22.39.06 #       <[IDC]Dragon> ah, ok
22.39.19 #       <amiconn> However, he reports a strange effect with the original firmware.
22.39.45 #       <amiconn> With an 1 GB ExtremeMemory MMC, he can't play music, although recording works ?!?
22.40.11 #       <[IDC]Dragon> I hope we can do better some day
22.40.21 #       <amiconn> Grr, yes
22.41.05 #       <[IDC]Dragon> no rush
22.41.50 #       <[IDC]Dragon> I'm double-checking the tuner hookup
22.42.00 #       <amiconn> I found something that depends on the mask from current hardcore-asm-deciphering: First byte, bit 2 tells what kind of clock gate circuit is there
22.42.03 #       <[IDC]Dragon> then I probably put the board back on
22.42.32 #       <[IDC]Dragon> what kinds are there?
22.43.19 #       <[IDC]Dragon> ours differ by just one bit, correct?
22.43.23 #       <amiconn> Obviously, there exists a circuit that, contrary to our version, needs SCK1 to be low for USB bypass
22.43.36 #       <[IDC]Dragon> (the tuner bit, presumably)
22.44.53 #       <[IDC]Dragon> worth noting in twiki
22.45.44 #       <amiconn> Hmm. I will gather more info and then update the wiki
22.51.29 #       <amiconn> A quick search through the listing yields that only the first mask byte, bits 0..2 are used
22.51.29 #       <amiconn> (on Ondio SP)
22.53.09 ***     Saving seen data "./dancer.seen"
22.53.54 #       <amiconn> On Ondio FM, bit 3 is used too, so most probably this tells what tuner type is in
22.55.02 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
22.55.24 #       <[IDC]Dragon> what were or values, again?
22.56.21 #       <[IDC]Dragon> 0f08 and 0708
22.56.23 #       <amiconn> Ondio FM (you): 0x0F08, Ondio SP (me) 0x0708. The second byte (0x08) is completely irrelevant
22.57.24 #       <[IDC]Dragon> so you were right about bit 3
22.58.04 #       <amiconn> bit 3 tells that your FM has a philips tuner. I wonder what tuner is in an Ondio FM with bit 3 == 0
22.59.13 #       <amiconn> The FM firmware actually checks bit 3, while the SP firmware does not
22.59.20 #       <[IDC]Dragon> don't you think this tells about tuner presence in general?
22.59.43 #       <amiconn> I don't think so. Why should it?
23.00.01 #       <[IDC]Dragon> to determine the model?
23.00.18 #       <amiconn> FM and SP firmwares are different binaries
23.09.07 #       <[IDC]Dragon> tuner board is back on
23.09.15 #       <amiconn> Funny: The text strings for radio and recording etc. are all present in the Ondio SP firmware...
23.10.09 #       <amiconn> But the binaries are definitely different: FM is 149 KB, SP is 117 KB
23.10.45 #       <[IDC]Dragon> significantly, yes
23.11.25 #       <[IDC]Dragon> probably the text array is unconditional
23.11.39 #       <amiconn> less #ifdef ;)
23.13.07 Quit    scott666 (Read error: 110 (Connection timed out))
23.13.56 #       <amiconn> There are some weird string in. Did you see them anywhere when operating the original firmware? E.g. "High side injection"
23.15.50 #       <[IDC]Dragon> that's a tuner feature
23.16.09 #       <[IDC]Dragon> which side of the IF to use
23.16.15 #       <amiconn> There are also some strings concerning "hard disk" and "battery charging" ?!?
23.16.22 #       <[IDC]Dragon> probably a debug output
23.16.48 #       * [IDC]Dragon unwraps the headphones for the first time
23.17.24 Quit    mecraw__ ("Trillian (http://www.ceruleanstudios.com)")
23.30.32 #       <amiconn> Ouch! Just found that leaving the debug menu triggers a zero area hit on the player...
23.31.28 #       <amiconn> ...and on recorder too
23.31.46 #       <amiconn> This was not the case when I developed that feature.
23.32.33 #       <amiconn> Ah ok, forget it.
23.32.56 #       <amiconn> I have speaking menus enabled, and mpeg.c causes this.
23.58.13 #       <amiconn> Hehe, I was looking for re-enable after usb routine: There is none, since the archos fw reboots after usb!