--- Log for 17.09.104 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 13 hours ago 00.00.51 Join PaulS [0] (~0d0274bd@labb.contactor.se) 00.03.21 # I'm not sure I understand the "Hardware Address Info" section of the IriverMemoryMap wiki page. There's really not all that much to say about how the system is setup at reset time. It's clear from the docs that most of this stuff needs to be setup in code. The SDRAM, for example, is completely dormant and unmapped until it's set up. 00.04.45 # I know noooothing 00.05.45 # As I understand it there are utilities published for the Coldfire for generating the startup code for putting everything where you want it. It seems to me that the more interesting table would be where we want everthing to be mapped, or where the iRiver currently has things mapped (in the spirit of the function map in the earlier table). 00.06.38 # i agree 00.06.44 # I'll probably just edit the table and add the memory map as I understand the iRiver firmware, and leave the "Hardware Address Info" table alone. 00.07.21 # Whoa, that didn't come out write. "I'll probably edit the page to add a new table with the memory map as I understand the iRiver firmware..." 00.09.36 Quit Bagder ("Leaving") 00.13.53 Quit methangas (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") 00.22.17 # hydra irc, the only irc client with enough toolbar buttons to strangle a camel 00.28.03 Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) 00.28.09 # i have never understood those big-screen pc irc clients. irc is a small window in the lower right corner of my screen. 00.28.39 # who needs five windows and three dozen buttons? 00.29.44 Join bagawk [0] (Lee@ACC171F6.ipt.aol.com) 00.32.08 Join srn [0] (~82e13707@labb.contactor.se) 00.35.42 # Hi PaulS. I created the hardware address table. I know it is not as useful as the function map, since the hardware addresses are already in the manuals, but it will give an easy overview for 'outsiders' who might join us later. 00.46.45 Join bagawk_ [0] (Lee@ACC171F6.ipt.aol.com) 00.49.08 *** Saving seen data "./dancer.seen" 00.51.00 Quit srn ("CGI:IRC (EOF)") 01.02.01 Join bagawk__ [0] (Lee@ACC47750.ipt.aol.com) 01.02.27 Quit bagawk (Nick collision from services.) 01.02.45 Join dreed75 [0] (~45912877@labb.contactor.se) 01.02.49 # hi 01.02.53 # hello 01.02.53 # hi 01.03.23 Nick bagawk__ is now known as bagawk (Lee@ACC47750.ipt.aol.com) 01.03.23 # has anyone ever used any batteries besides niMH like alkalines (without hooking up the charger of course) 01.03.43 # cause i just got an archos and i dont want to charge it for 6 hours, i want to play 01.03.47 # dreed75: don't do that, they pruduce more voltage than nimh 01.03.53 # okay thanks 01.03.58 # just chacking 01.04.03 # (nimh=1.2v, alkaline=1.5) 01.04.06 # i am getting impatient to try rockbox 01.04.09 # thatcould be bad for the HD 01.04.20 # dreed75: you ordered an archos? 01.04.31 # i bought it off ebay 01.04.34 # brand new 01.04.39 # neat :) 01.04.43 # what unit? 01.04.44 # the 20 GB recorder 01.04.48 # nice 01.05.02 # do you have rockbox installed? 01.05.12 Quit bagawk_ (Read error: 104 (Connection reset by peer)) 01.05.16 # yes, i do not know anyone that wouldn't after they tried it 01.05.29 # yeah i know, it sounds cool 01.05.36 # and looks cool 01.05.47 # :) 01.05.52 # did you flash the firmware with rockbox's firmware without any problems? 01.06.01 # cause i am kinda nervous about that 01.06.11 # yes 01.06.25 # you do not have to do it if you do not want 01.06.29 # Zagor, is there a theory yet on how we'll be able to rollback a buggy firmware on the iRiver? 01.06.43 # and you box may not be flashable any way 01.06.46 # *your 01.06.57 # also, i've got a question, I tried the simulator after editing the code and recompiling it and there aren't any menus for recording...is that just the simulator or does rockbox not record 01.07.17 # that is just because it is a simulator 01.07.21 # it is faster with the rockbox firmware isnt it 01.07.23 # how could it recorde? :) 01.07.32 # its a recorder 01.08.10 # oh yeah, i thought that it would at least have a menu even if it didnt work 01.08.15 # everything is fast with rockbox 01.08.38 # playlists is where it is much faster 01.08.57 # boot time is faster isnt it 01.09.19 # it would take 5 inutes are so to load a playlist in archos firmware (and a limit of just 100 songs), and rocksbox can load a playlist in just 2 seconds 01.09.36 # If your unit is flashed it can boot in about 3-4 seconds 01.09.42 # do you know how to use a custom bmp on the screen cause i can tell it is somehow embedded in the code but I can't figure out how it is done and i heard it was possible 01.09.51 # with rockbox firmware flashed, about 10 or so 01.10.17 # are you talking about the logo? 01.10.22 # yeah 01.10.35 # yes, it is in apps/recorder/icons.c 01.11.50 # you make a 112x37 bmp (in monochrome) 01.12.01 # oh so i just have to make my own bmp, grayscale, the same size and open it in a hex editor and paste it into the code? 01.12.07 # use the tool bmp2rb, and it will give you the array as you see in the icons.c 01.12.14 # oh sweet, thanks 01.12.15 # not grayscale 01.12.34 # although with some work, you could now since greyscale has been developed 01.13.27 # the logo is rockbox112x37 btw if you did not know which one 01.13.35 # (in icons.c 01.13.37 # ) 01.13.41 # plok: yes, we'll do something like what we have on the archos: a two-stage flash with a fallback loader in case of a problem 01.14.32 # thanks dude, you've been a big help..also killing time so i don't go crazy waiting to install rockbox 01.15.08 # :) 01.15.14 # dreed75: i assume oyu can write code? 01.15.18 Quit ripnetUK () 01.15.42 # i am new with C but I learn fast 01.15.50 # i can edit very well :) 01.15.55 # cool 01.16.37 # ugh 01.16.41 # my eyes are thirsty as hell 01.16.50 # if i have to look at another line of java i'm going to destory someone 01.16.55 # and destroy them 01.17.17 # dreed75: you could get starting writting yourself some plugins you can see a good simple example of how to write in apps/plugins/helloworld.c 01.17.33 # ok thanks 01.18.23 # Zagor: But what about in the development process. The archos would just load a firmware from the HDD, but the iRiver doesn't seem to do that 01.19.17 # same thing: we'll write a loader to load from disk, then flash that. 01.19.43 # the loader will be debugged using the bdm, which can run with even an empty flash 01.20.46 # Aah I'm with you now. So the loader will work the first time it's flashed to the iRiver :) 01.21.56 # well no, but we will be able to debug it using the bdm. so when it works people without bdm can use it. 01.23.23 # during development a simple rolo boot is best 01.23.44 # Cool. Is the plan to get iHP-100 series working first, then possibly look at the H300 series if it's close enough, or parallel development? 01.23.56 # h100 first 01.24.40 # we'll see where we go from there when/if we get there :) 01.24.55 # :) 01.26.21 # Oh, the blue navi button on the h300 is an actual button ctw 01.26.43 # ok 01.26.50 # bagawk: is monochrome the same as black and white in paint? 01.26.59 # i hate it when they label the buttons... 01.27.09 # dreed75: yes 01.27.30 # thanks 01.28.12 Quit AciD (Connection timed out) 01.29.50 # They also have a button labelled "A-B" for some reason known only to them :) 01.30.29 # those labels are easier, simply because they don't mean something specific. but "navi" doesn't give a lot of leeway... 01.31.49 # for example, we use the ON button on the archos for various things. it's not so confusing because nobody expects it to mean "ON" when the unit is already turned on 01.32.45 # with "navi" we're pretty much forced to put the file navigator on it 01.35.04 # Ahaaa! Now I finally get clock pulses! 01.35.29 # Really silly mistake, btw 01.35.54 # most are, in hindsight :) 01.37.40 # Note to self: if you ever change some &= NN; into and_b(NN, ); , put an "&" in front of the macro name. Doh! 01.38.39 # i'm off to bed 01.38.41 Quit Zagor ("Client exiting") 01.39.01 # Probably a good idea. I'm off now too 01.39.33 Part amiconn 01.44.03 Quit dreed75 ("CGI:IRC (EOF)") 02.08.50 Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)") 02.14.43 Quit _aLF (Remote closed the connection) 02.19.55 # bye!!! 02.20.33 Quit bagawk ("umount /dev/brain") 02.22.11 Quit elinenbe (Read error: 104 (Connection reset by peer)) 02.22.42 Join elinenbe [0] (elinenbe_@207-237-224-49.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.49.09 *** Saving seen data "./dancer.seen" 02.50.39 Join joshp [0] (~45912877@labb.contactor.se) 02.51.01 # where do i get autostart.rock and how do i use it 02.55.43 Quit joshp ("CGI:IRC (EOF)") 03.19.02 Part scott666_ 04.02.07 Quit PaulS ("CGI:IRC (EOF)") 04.22.31 Part plok 04.22.39 Join plok [0] (s336156@student.uq.edu.au) 04.23.26 Join macgyver2 [0] (~45912877@labb.contactor.se) 04.23.50 # does anybody know where to get the autostart plugin 04.26.24 # is anyone here 04.34.51 # sleeping. 04.44.48 Quit macgyver2 ("CGI:IRC") 04.49.12 *** Saving seen data "./dancer.seen" 05.16.34 Join dreed75 [0] (~45912877@labb.contactor.se) 05.26.40 Quit dreed75 ("CGI:IRC") 05.33.59 Join maikeul [0] (~gromit@ALagny-151-1-26-112.w83-114.abo.wanadoo.fr) 05.50.48 Quit gromit`` (Read error: 110 (Connection timed out)) 06.49.16 *** Saving seen data "./dancer.seen" 06.50.35 Join LinusN [0] (~linus@labb.contactor.se) 07.08.30 Join PaulS [0] (~437e19f6@labb.contactor.se) 07.13.01 # Linus, have you attempted to play .m3u playlists on your iRiver? 07.21.20 # I filled in a bit of the memory map. Hows the logic analyzer doing for you, Linus? 07.27.15 # plok: no, i haven't 07.27.29 # PaulS: fell asleep yesterday :-) 07.27.56 # 3hrs of sleep per night takes its tribute... 07.28.22 # That's ok, just solved my problem. On the H340 at least the playlist files don't appear when browsing. You have to press the A-B button to get a list of playlists.. 07.28.24 # yuck 07.29.51 # how silly 07.34.08 # LinusN: I was starting to get curious about the hours you were keeping. :-) 07.38.40 # LinusN: I left a couple of suggestions in the logs anyways, as to how to identify the A0. I also said something along the lines of "since we know which GPIO signal strobes A0, it kinda doesn't matter that we know where it lives on the connector." 07.39.17 # you haven't mentioned which gpio it is 07.39.43 # would be nice to see in the wiki 07.40.15 # It's GPIO1-35. 07.40.36 # wiki wiki wiki :-) 07.42.46 # Coming up! I didn't put it in the description since I'm still not entirely convinced of the bit ordering on the register (datasheet doesn't make it plainly obvious). I can tell you for sure the address and bit though. 07.43.01 # good 07.44.08 # have to reboot, bbs 07.44.12 Part LinusN 07.49.47 Join LinusN [0] (~linus@labb.contactor.se) 07.55.14 Join ashridah [0] (ashridah@dialup-a2-372.Melbourne.netspace.net.au) 08.01.41 # I put it in IriverPort in the LCD driver section, where I'd mentioned the GPIO pin before. 08.04.54 # i wonder why they didn't use an address pin for command/data selection 08.06.02 # Seems kinda bogus to me too. Maybe the LCD chip doesn't want to see the address pin wiggle between acesses while doing data bursts. 08.07.51 # LinusN: Tonight is the night when I'll pull my keyboard completely apart! It will be an interesting ride! 08.07.57 # Good morning everyone, btw! :) 08.08.52 Join methangas [0] (methangas@0x50c61c48.virnxx10.adsl-dhcp.tele.dk) 08.09.07 # It's only 11pm for me. 08.09.21 # (But good morning to you!) 08.11.29 # Ohayo! :D 08.15.36 # Oyasu! 08.22.15 Join amiconn [0] (~jens@pD9E7F596.dip.t-dialin.net) 08.25.01 # G' morning 08.26.05 # Hallo. (Not quite the 17th here yet.) 08.26.33 # :) 08.27.10 # Nearly time to go home for the weekend here :) 08.27.32 # :) 08.29.03 # No worries. My weekend will still be going strong while you guys start toiling away. 08.37.00 # 8) 08.38.44 # dwihno: completely apart? wasn't it just the shift key? 08.40.00 Join Zagor [242] (~bjst@labb.contactor.se) 08.42.32 Join [IDC]Dragon [0] (~idc-drago@pD9512E52.dip.t-dialin.net) 08.43.10 # <[IDC]Dragon> hi amiconn, sorry for the "&" yesterday 08.43.39 # Morning Jörg. 08.43.42 Join Lynx_ [0] (lynx@134.95.189.59) 08.44.16 # [IDC]Dragon: At least I finally found it. Now I get nice clock pulses both for reading and writing 08.45.15 # Next step will be trying to initialize the card to spi mode and get identification data 08.45.30 # <[IDC]Dragon> yes, that'll be nice 08.45.57 # <[IDC]Dragon> we didn't really celebrate the full portmap ;) 08.46.08 # ;) 08.46.17 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 08.46.39 # LinusN: Well, I might as well clean the keyboard when I'm pulling it apart 08.47.51 # [IDC]Dragon: Btw: I found that we won't have to set TxD to high-z every time we enter usb mode, because the sh datasheet says TxD switches to the GPIO state that was active before setting up SCI everytime the transmitter is disabled (TE = 0) 08.48.10 # dwihno: tip: take a photo of the keys before taking it apart 08.48.33 # <[IDC]Dragon> amiconn: yes, we can save a bit on port access, I didn't optimize that 08.49.13 # Ok. I only mention that to keep in mind. I don't bother doing that for now too 08.49.18 *** Saving seen data "./dancer.seen" 08.49.34 # <[IDC]Dragon> amiconn: how do we read from SPI? transmitting a stream of 0xFFs? that won't be so good for DMA 08.50.15 # <[IDC]Dragon> but wait, I think we can tell the DMA not to increment the source address, needing only one 0xFF 08.50.33 # PaulS: "external termination" on the LCD CS, does that mean that the LCD glue has to generate TA? 08.50.37 # No, we read by simply reading. If the receiver is enabled and RDR1 is empty, the sh outputs clock pulses on SCK1 08.51.26 # One problem is waiting for the card to get ready for the next transfer. As it looks to me we need read-polling there 08.51.36 # <[IDC]Dragon> how do we tell data apart from idle then? 08.51.47 # ? 08.51.50 # LinusN: Aaaaaah. Smart. I was going to simply make notes 08.52.07 # LinusN: Perhaps I would paint all keys yellow or something 08.52.11 # <[IDC]Dragon> if I just clock, will the cars _always_ send something? 08.52.13 # That would be really neato 08.52.17 # a digital camera is a blessing in those cases 08.52.20 # <[IDC]Dragon> s/cars/card 08.52.32 # LinusN: good idea indeed! 08.54.08 # [IDC]Dragon: No. The card only (and always) responds to commands, and the response format is well defined 08.54.46 # <[IDC]Dragon> ah, so we read n bytes, known in advance, logical 08.55.02 # <[IDC]Dragon> for the ready, we have the interrupt 08.55.12 # <[IDC]Dragon> but only at the internal card 08.57.43 # LinusN: I didn't mean "external termination" there in the TA sense, but from reading the CS1 control register, yes that's true. 08.57.44 # I think we need a variable in the driver holding the card status (internal or external). We should also measure power consumption with and without CS asserted 09.01.22 # Speaking of pictures, I'd like LinusN to take a shot of the IHP with the display off. 09.01.33 # PaulS: so the AA bit is 0? 09.02.01 # PaulS: as soon as i find out how to disconnect the display without breaking the connector :-) 09.02.16 # <[IDC]Dragon> amiconn: yes. do you have a MMC? 09.02.52 # Yeep! No! AA is 1. TA is internal evil naughty Paul! 09.03.59 # you scared me there :-) 09.04.18 # Thanks for probing patiently until I realized my folly. 09.04.25 Quit ashridah ("Client exiting") 09.04.36 # [IDC]Dragon: No. I wanted to buy one, but at the local electronics stores they are rather expensive, so I'm currently experimenting with the internal flash only 09.04.59 # I'll try to get one of course 09.05.16 # PaulS: it really seemed fishy with external TA generation, it is very uncommon 09.05.26 # I'll go fix the Wiki. 09.05.31 # good 09.05.52 # why not fill in the CS register values? 09.06.09 # so we have the waitstates etc 09.06.34 # It'll get wordy, but I'll do it. 09.07.05 # Hex values okay for you? You don't want me to break out the values and make more silly errors, do you? :-) 09.07.10 # it's not *that* important, but the ws is kind of interesting 09.07.17 # hex is ok 09.08.30 # <[IDC]Dragon> amiconn: the smallest, obsolete card will do. 09.08.52 # <[IDC]Dragon> (the kind you'll get with a digicam) 09.09.23 # <[IDC]Dragon> unless you want a real fancy 1GB card for true useage 09.09.57 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 09.10.16 # hi Bagder 09.10.22 # morning 09.10.24 # [IDC]Dragon: Yup. Unfortunately my digicam, as well as those owned by other people I know, all use other card types than MMC 09.10.33 # Bagder: i have the wiggler 09.10.41 # * [IDC]Dragon relocates to work, cu 09.10.46 # any progress with it yet? 09.10.46 Quit [IDC]Dragon () 09.10.53 # (away too) 09.11.31 # sleeping daughter and a mug with fresh steaming coffee 09.11.41 # life is good :) 09.11.48 # yeps 09.12.08 # Bagder: fell asleep yesterday, so no progress :-) 09.12.16 # hehe 09.12.24 # except on the sleeping department then! 09.13.08 # woo, got almost 5hrs of sleep, much better than the usual 3 :-) 09.13.24 # luxury! ;P 09.13.37 # let's not make it a habit :-) 09.14.26 Join amiconn_ [0] (~jens@pD9E7E941.dip.t-dialin.net) 09.18.28 # LinusN: Yay! Did you wiggle last night? 09.18.46 # yeah, in his sleep :) 09.22.46 # :) 09.30.49 Quit amiconn (Read error: 110 (Connection timed out)) 09.30.49 Nick amiconn_ is now known as amiconn (~jens@pD9E7E941.dip.t-dialin.net) 09.30.51 # Okay. Hex values are in the MemoryMap Wiki. The SDRAM register values are the final state -- there's a dance you need to do to get everything started. That's documented in the datasheet. 09.31.11 # * Bagder tapdances just in case 09.31.58 # * dwihno does the salsa 09.35.24 # * Does the Macarena, which causes his IHP to execute an HCF! 09.37.52 # * PaulS opens a window to let out the smoke. 09.42.43 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 09.43.28 # Enter the Dragon! Morning. 09.43.40 # <[IDC]Dragon> hi again! 09.43.44 Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) 09.46.19 # PaulS: are you still editing IriverMemoryMap? 09.46.59 # Nope. All done. 09.57.02 # ok, i take the lock then 09.58.38 # PaulS: since you didn't mean TA generation, what exactly did you mean with "Set up for external termination"? 09.59.21 # Zagor: have you looked at the daily build table? 09.59.38 # yes, and i've fixed the non-sim ones 09.59.45 # non-win32 i mean 09.59.50 # ok 10.00.03 # for some reason i can't compile the win32 in my shell 10.00.21 # do you have the path setup for the mingw cross-compiler? 10.00.34 # yes, but I get other weird errors 10.00.46 # strange 10.00.50 # very 10.02.17 # lcd-win32.h:42: error: `LCD_HEIGHT' undeclared here (not in a function) 10.02.21 # LinusN: this could be interesting. "patch to properly assemble/disassemble coldfire mac/emac instructions". http://sources.redhat.com/ml/binutils/2004-04/msg00465.html 10.02.40 # ah silly me i haven't converted the win32 makefile 10.02.55 # * Zagor hits forehead 10.02.57 # "converted"? 10.03.19 # yeah, from using defines to using config.h 10.07.44 # <[IDC]Dragon> amiconn: listening? 10.17.23 # Okay, it's bedtime. NIght guys. 10.17.30 # night! 10.17.44 # PaulS: please answer my question 10.19.26 # Which was that, LinusN? 10.19.46 # PaulS: since you didn't mean TA generation, what exactly did you mean with "Set up for external termination"? 10.22.02 # Oh, "external termination" -- I made a lazy assumption while reading the summary in the CS section of the datasheet that "termination" was talking about onboard vs offboard peripherals. And of course I distracted myself from removing the mention of termination from the wiki.. Thought I got rid of that. 10.22.21 # Wiki thinks you're still editing that page. Is this true? 10.23.51 # yes, i am removing that sentence 10.24.28 # so you can go to sleep now :-) 10.24.43 # Good. I strongly approve. We agreed it was wrong earlier. I don't know what distracted me from actually getting rid of it. 10.25.05 # PaulS: one last thing, does the lcd routine write to the high or low byte? 10.25.14 # * PaulS . o O ( ZZZZZZ ) 10.27.30 # It uses MOVE.B , (address register containing 0xF0000000), so I assume big-endian would write to the "high" or MSB byte. 10.27.51 # thx 10.29.02 # <[IDC]Dragon> LinusN: about some old, boring SH hardware: 10.29.11 # :-) 10.29.35 # --However--, if the CS1 memory space was configure to be byte-wide, it would access the LSB. Let me check that. 10.29.40 # <[IDC]Dragon> I heared the file system came from you, and was originally FAT16? 10.29.57 # PaulS: nm, i can find that out myself 10.30.03 # [IDC]Dragon: yes 10.30.08 # that's not entirely true. 10.30.24 # most of it is actually rewritten from scratch 10.30.27 # but it was far from finished 10.30.28 # <[IDC]Dragon> however, from some nice people 10.30.34 # <[IDC]Dragon> ;-) 10.31.15 # <[IDC]Dragon> the Ondio could seriously need a HAVE_FAT16SUPPORT 10.31.31 # [IDC]Dragon: forget it :-) 10.31.39 # <[IDC]Dragon> :( 10.32.06 # if we want fat16 support, we'd be better off adding it to the current driver than trying to backport my stuff 10.32.26 # <[IDC]Dragon> yes, that's what I mean 10.32.27 # my stuff wasn't finished, and probably didn't work at all :-) 10.32.54 # but it shouldn't be *that* hard to add 10.33.20 # fat16 isn't too bad. fat12 is hell. 10.33.34 # <[IDC]Dragon> yes, we had that. 10.33.38 # :) 10.33.48 # <[IDC]Dragon> I think FAT16 should suffice 10.35.11 # <[IDC]Dragon> but if I understand you right, FAT16 is not as easy as tossing some old lines back into the code? 10.35.18 # correct 10.35.26 # the code is 90% my mess 10.35.26 # <[IDC]Dragon> so nothing I can dare ask you to do? 10.35.48 # Well, that's interesting. It's set up for 8-bit wide port size (0x2140 in the chip select control register) although the datasheet swears "Port size should always be programmed to 16 bits". 10.36.23 # <[IDC]Dragon> PaulS is sleepwalking, err sleephacking 10.36.50 # It doesn't consider setting the Port Size bits to 8 bit as reserved though... There's also the note "Note: A0 is not available on the external bus" -- which might explain why they're using a GPIO to run A0. A little silly though; they could have just used A1. :-) 10.37.22 # indeed 10.37.35 # * PaulS can't leave a good mystery alone. 10.38.40 # [IDC]Dragon: well it's not a small task, so it would obviously take time away from other things. on the other hand I agree with you that the ondio needs it. it's not reasonably to demand users to fat32-format their 128MB card... 10.38.59 # With the information we've compiled before, I'm willing to go back on my initial guess and say the LCD is attached to D0-7 instead, in a not-fully-supported mode of the Coldfire. 10.39.54 # rather D31-D24 10.40.14 # <[IDC]Dragon> Zagor: ok, I'll step away with that from you guys 10.40.33 # btw, i'll set it to 16-bit port size in my code 10.40.55 # It's probably only unsupported from the standpoint that there's no A0 though. 10.41.58 # <[IDC]Dragon> just wanted to avoid spending much effort on something that's a breeze for the insider 10.42.33 # right 10.42.51 # I don't see how that would hurt anything unless they're using the other D lines for something else. Compared to the iRiver code you'll have to do a 16 bit wide assignment so things show up on D0-7. 10.43.34 # Bagder: do you remember any particular reason why the win32 sims aren't called rockboxui like the x11 ones? 10.43.54 # it wasn't my decision, I believe that's just how edx named it 10.44.13 # ok. i'm renaming it. 10.49.19 *** Saving seen data "./dancer.seen" 10.49.45 Quit Bagder ("Leaving") 10.50.08 # personally, i like the uixxxxxxx name better 10.50.20 # too late :) 10.50.29 # only because the command line completion doesn't find any ambiguities 10.50.48 # it doesn't now either. i'm removing the -x flag on all rocks 10.56.08 Part PaulS ("I will not drool on my keyboard.") 11.05.51 # morning 11.06.00 # any news on how LinusN's wiggeling went? 11.06.07 # how silly, the zip file has the executable flag set 11.06.17 # ripnetUK: no news, fell asleep yesterday 11.07.01 # LinusN: really? doesn 11.07.03 # 't for me 11.07.50 # ok :) 11.08.28 # Zagor: what's your umask? 11.08.34 # 22 11.08.44 # mine too 11.09.01 # and "make zip" gives me a rockbox.zip with x flags set 11.09.14 # did you remove it first? 11.09.37 Join ashridah [0] (ashridah@dialup-a1-423.Melbourne.netspace.net.au) 11.09.42 # Zagor: yes 11.09.47 # strange 11.10.45 # in cygwin of course, i assume you understand that 11.11.11 # ah, no i didn't. 11.11.46 # i assumed that since you were working with the win32 sim 11.12.04 # or were you? 11.12.20 # i was, but in linux using mingw 11.12.29 # ah 11.16.43 # Neato! 11.16.52 # you cross compiled mingw? 11.17.23 # yup 11.23.51 # neato! was it hard? 11.39.26 Join pillo [0] (~trillian@navlab03.dei.unipd.it) 11.43.44 Quit ashridah ("Client exiting") 11.44.08 Join ashridah [0] (ashridah@dialup-a1-423.Melbourne.netspace.net.au) 12.15.19 Part pillo 12.17.47 Join [av]bani [0] (~goemon@washuu.anime.net) 12.17.48 Quit ripnetUK (Read error: 104 (Connection reset by peer)) 12.26.39 # dwihno: i don't remember who did it. i think it was bagder 12.35.45 Part [av]bani 12.49.22 *** Saving seen data "./dancer.seen" 13.23.16 # [IDC]Dragon: is it ok with you if I change the ondio key mapping to my ButtonAssignments scheme? 13.34.02 # amiconn, [IDC]Dragon: is the HAVE_POWEROFF_ON_PB5 define true for ondio? 13.35.19 # <[IDC]Dragon> Zagor: yes and yes 13.35.32 # good, thanks 13.35.47 # <[IDC]Dragon> how do you do the button assignment? 13.36.24 # using defines. i.e. #define TREE_NEXT BUTTON_DOWN 13.41.27 # <[IDC]Dragon> an indirection won't solve the duplicate case's, if any 13.41.56 # i know. i'm removing the duplicates, leaving only one define per value in button.h 13.42.20 # the double definitions were not really well used anyway, and added confusion 13.42.39 # <[IDC]Dragon> that will probably disable some feature for the Ondio, for now 13.43.05 # <[IDC]Dragon> in screens which react to On, others to Off, but not both 13.45.25 # i'm fixing those cases too 13.46.02 # <[IDC]Dragon> giving them a mapping? Excellent! 13.46.08 # yes 13.46.21 # maybe not all plugins right now, but the base code anyway 13.46.55 # <[IDC]Dragon> in the ideal, protable world, we should never check for a button code, but for a mapped action 13.47.13 # <[IDC]Dragon> s/protable/portable 13.47.23 # right, that's my aim. 13.48.26 # <[IDC]Dragon> :-) 13.56.02 # <[IDC]Dragon> where do you keep all these key mappings? 13.56.30 # one set in tree, one in menu, one in settings and one in wps 13.56.40 # basically one for each major button switch 13.57.25 # <[IDC]Dragon> I was just considering a central header, but thats not such a good idea 14.01.58 # i think having them close to the code is good, at least for now 14.06.05 # <[IDC]Dragon> yes, easier to maintain 14.07.47 # <[IDC]Dragon> How do you handle if certain actions are not possible (mapable) for that hardware, you give it som bogus define? 14.08.19 # no, i simply don't give it a define. then #ifdef FUNCTION in the switch 14.08.39 # <[IDC]Dragon> I was about to suggest that, too 14.10.17 # <[IDC]Dragon> are you aready taking out the preliminary Player key scheme for the Ondio? 14.10.25 # yes 14.10.32 # <[IDC]Dragon> goodie 14.11.02 # [IDC]Dragon: I have some general questions about the ondio .. 14.11.24 # is the radio reception really that worse? 14.11.34 # some reviews claim that .. 14.11.58 # <[IDC]Dragon> I had to make a whole bunch of #if defined(HAVE_PLAYER_KEYPAD) || defined(HAVE_ONDIO_KEYPAD) to make this work 14.12.18 # <[IDC]Dragon> mbr: to be honest, I haven't tested 14.12.25 # :)) 14.12.33 # <[IDC]Dragon> took it apart 10 min after I got it 14.12.48 # lets try another question 14.13.12 # do you see any chance to support internal and external memory at the same time? 14.13.20 # or is there a hw limitation? 14.13.37 # <[IDC]Dragon> a slim chance 14.13.56 # <[IDC]Dragon> no hardware limitation, but then we need to work with 2 disks 14.14.09 # Ah, OK 14.14.25 # <[IDC]Dragon> it makes no sense to RAID them together 14.15.12 # I'm thinking about buying one, but FM should be good 14.15.28 # <[IDC]Dragon> in the near future, there may be an option to toggle which storage to use 14.15.41 # That would be nice also 14.16.06 # I just dont want to plug and unplug the card for switching. 14.16.25 # <[IDC]Dragon> probably much quicker than a menu option 14.16.25 # so a SW switch would be sufficient 14.16.58 # but where to keep the card when yo are somewhere 14.17.28 # <[IDC]Dragon> yes, this big, bulky card :-/ 14.17.31 # keeping it in the ondio would make sense to me 14.17.59 # <[IDC]Dragon> you could extract it just a little bit, or turn it around 14.18.14 # <[IDC]Dragon> anyway, no major problem 14.18.14 # Ah, haven't known that 14.19.24 # ok, thanks for the answers, I think I order one :)) 14.20.56 # and try the FM on my own :)) 14.43.33 # another archos sale thanks to rockbox :-) 14.44.17 # like my recorder too :) 14.48.55 # ouch. the keyboard is difficult. it uses every button on the recorders... 14.49.11 # the Freescale coldfire docs are really sad compared to the standard Motorola docs for other cpus 14.49.24 *** No seen item changed, no save performed. 14.56.27 # Does anyone here use TDT? 14.56.37 # tdt? 14.56.51 # Tag Database Tool (iRiver) 14.57.10 Quit midk_ ("just STOP it arspy") 14.59.21 # nah. i use one written for linux. although i'm not sure if it works with the most recent firmware. hm. 14.59.46 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 15.08.07 # <[IDC]Dragon> Zagor: (keyboard) even the combos are exploited? 15.08.25 # yes 15.08.39 # it's not 100% graceful, but a good start imho 15.08.45 Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 15.08.47 # <[IDC]Dragon> I may do the direction key test different 15.08.56 # <[IDC]Dragon> to allow combos there 15.09.16 # <[IDC]Dragon> the resistors form a R2R network 15.09.21 Quit midk (Nick collision from services.) 15.09.23 # I use menu+up/down for things. is that ok with the button decoder? 15.09.23 Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) 15.09.36 # <[IDC]Dragon> meaning, every key has its magnitude 15.10.07 # <[IDC]Dragon> Zagor: yes, if the first menu depress does not bring you elsewhere 15.10.15 # of course 15.10.49 # <[IDC]Dragon> if the tolerances allow, I could check the direction keys independently, allowing combos of them 15.11.08 # <[IDC]Dragon> but then we better debounce 15.11.24 # I don't need direction combos 15.11.37 # <[IDC]Dragon> yet... ;) 15.11.40 # debounce when polling? 15.12.07 # <[IDC]Dragon> yet, to check for stable level 15.12.18 # <[IDC]Dragon> s/yet/yes 15.12.45 # ah, for combos you mean 15.12.52 # no, sorry 15.13.00 # i remember our early discussion now :) 15.13.22 # i'd like to call it something else than debounce though. it's not quite accurate. 15.13.31 # I get confused ever time :) 15.13.32 # <[IDC]Dragon> filtering 15.13.42 # or just stabilising 15.14.04 # whatever :) 15.14.07 # <[IDC]Dragon> jeminds me of camcorders 15.14.14 # <[IDC]Dragon> reminds 15.14.37 # hehe, yeah it's a bad name since we're not actually *doing* it. just waiting for it. 15.15.54 # <[IDC]Dragon> it's called marketing 15.16.13 # no swearing please :) 15.16.25 # <[IDC]Dragon> Rockbox with TruButton Stabilizer technology 15.16.35 # haha 15.16.36 # Patent Pending 15.16.52 # <[IDC]Dragon> (TM) 15.17.21 # actually, i think the problem might be the A/D driver itself 15.17.37 # to begin with, we read the A/D very seldom 15.17.41 # ah, so it's YOUR fault? ;) 15.17.46 # yes 15.17.46 # <[IDC]Dragon> oops, why? 15.17.55 # we read one channel per tick 15.18.12 # so each channel takes 8 ticks to update 15.18.17 # <[IDC]Dragon> isn't it 4 now? 15.18.29 # i did that, but was forced to revert it 15.18.43 # because we got other weird errors because of it 15.18.57 # <[IDC]Dragon> forced by whom? 15.19.20 # the users who experienced problems? 15.19.48 # i didn't have the time back then to debug it, so i just reverted it 15.19.52 # <[IDC]Dragon> another way would be to measure in adc_read() 15.20.17 # that would be slow 15.20.19 # yes, but the conversion takes 10us 15.20.29 # <[IDC]Dragon> it doesn't take that long 15.20.41 # not 10us? 15.21.11 # <[IDC]Dragon> that wasn't related to the 10 us 15.21.30 Join kurzhaarrocker [0] (~knoppix@p50876FE9.dip0.t-ipconnect.de) 15.21.40 # <[IDC]Dragon> or the high speed solution: use the ADC interrupt 15.21.50 # BTW: What is a wiggler? Bait? 15.22.01 # <[IDC]Dragon> insomnia 15.22.04 # the interrupt handling eats up a lot of cycles 15.22.17 # kurzhaarrocker: a bdm debugger interface 15.23.00 # A piece of hardware I assume? 15.23.25 # kurzhaarrocker: yes 15.23.55 # thx, LinusN 15.30.07 # <[IDC]Dragon> Zagor: these HAVE_xxx defines are mostly binary 15.30.23 # yes 15.30.24 # <[IDC]Dragon> which looks a bit funny for multiple choice 15.30.47 # <[IDC]Dragon> why not a CPU define with a value? 15.31.00 # you mean we should have #if CPU == SFC5249 15.31.10 # <[IDC]Dragon> or MAS define 15.31.12 # looks better imho 15.31.14 # <[IDC]Dragon> yes 15.31.28 # not a bad idea. same with keypad. 15.31.36 # <[IDC]Dragon> but let's keep a prefix 15.31.37 # bbl 15.31.40 # #if DECODER == LIBMAD 15.31.41 # yes 15.31.53 # <[IDC]Dragon> so we know this is platform configuration 15.31.56 # #if DECODER == MAS3507D 15.32.30 # a CONFIG_ prefix ok? 15.32.43 # we might also want a generic macro, like PLATFORM == ARCHOS_JUKEBOX 15.32.45 # <[IDC]Dragon> shorter, CFG_ ? 15.33.08 # well the files are all called config.h and config-xxx so I think calling the defines CONFIG_xx makes sense 15.33.44 # I'll look into it 15.33.51 # i don't mind CONFIG_, the "#if" lines are quite short anyway 15.34.13 # <[IDC]Dragon> not if its a bunch of || 15.34.50 # we shouldn't need a bunch of ||. if we do we're most likely missing a variable. 15.35.04 # *define 15.35.49 # the DECODER thing won't work quite as smoothly though, since we will probably want more than one software codec 15.37.16 # <[IDC]Dragon> for PLATFORM we currently have multiple exclusive ARCHOS_RECORDER, ARCHOS_FMRECORDER, etc. defines 15.37.40 # <[IDC]Dragon> the ones we should not use, but the derived flags 15.37.51 # exactly 15.38.18 # <[IDC]Dragon> makes sense to have one define with a value 15.38.39 # <[IDC]Dragon> saves namespace for the compiler ;-) 15.40.59 # <[IDC]Dragon> uh, ata.c looks #ifsef cluttered now 15.41.08 # <[IDC]Dragon> #ifdef 15.42.14 # of course, it now supports two cpus with different register maps and io pins 15.42.35 # #ifdef is not intrinsically bad 15.42.50 Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) 15.42.54 # * [IDC]Dragon prefers upfront definitions 15.43.08 # explain 15.43.15 # how would you have done it? 15.43.38 # <[IDC]Dragon> I haven't look deeper in ata.c 15.44.03 # <[IDC]Dragon> but define some macros, inline functions, etc. to do the "ditrty" work 15.44.34 # <[IDC]Dragon> such that the code itself reads linear 15.44.40 # i don't see how that makes things less cluttered. you just move it to someplace else which will be even more cluttered instead 15.45.08 # <[IDC]Dragon> perhaps it's personal taste 15.45.24 # probably :) 15.45.34 # <[IDC]Dragon> but if you re-use these parts, it really becomes nicer 15.45.44 # * [IDC]Dragon thinks 15.45.59 # I do reuse them, that's why both ata drivers are in a single file 15.46.41 # <[IDC]Dragon> the little ugly harware bangers, I meant 15.47.11 # hiding things in macros isn't necessarily a good thing either, it makes it harder to read the "hardware banging" code 15.47.53 # I will probably agree with you when/if we get more different platforms and thus more code variants. but currently I think moving the code away from sight does more harm than good. 15.48.45 # <[IDC]Dragon> OK, sorry for style discussion 15.49.06 # no problem, it's good to discuss that too sometimes 15.50.35 # * [IDC]Dragon feels he did that some time too often recently 15.50.57 # well I don't mind anyway 15.53.28 # don't we have an option for voice menus? 15.53.40 # <[IDC]Dragon> we do 15.53.57 # hmm, where? 15.53.58 # <[IDC]Dragon> settings -> voice (at the bottom) 15.54.10 # <[IDC]Dragon> general settings, I mean 15.54.25 # <[IDC]Dragon> unless you optimized it away ;-) 15.54.49 # my bottom item in general settings is language 15.55.10 # * [IDC]Dragon doesn't have a box at hand 15.55.29 # <[IDC]Dragon> are you running 2.2? 15.55.47 # my voice entry is below "language" 15.55.59 #