00:00:51 | | Join PaulS [0] (~0d0274bd@labb.contactor.se) |
00:03:21 | PaulS | 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 | Zagor | I know noooothing |
00:05:45 | PaulS | 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 | Zagor | i agree |
00:06:44 | PaulS | 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 | PaulS | 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 | kaboofa | 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 | Zagor | 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 | Zagor | 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 | srn | 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:00 |
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 | dreed75 | hi |
01:02:53 | bagawk__ | hello |
01:02:53 | Zagor | hi |
01:03:23 | | Nick bagawk__ is now known as bagawk (Lee@ACC47750.ipt.aol.com) |
01:03:23 | dreed75 | has anyone ever used any batteries besides niMH like alkalines (without hooking up the charger of course) |
01:03:43 | dreed75 | cause i just got an archos and i dont want to charge it for 6 hours, i want to play |
01:03:47 | bagawk | dreed75: don't do that, they pruduce more voltage than nimh |
01:03:53 | dreed75 | okay thanks |
01:03:58 | dreed75 | just chacking |
01:04:03 | bagawk | (nimh=1.2v, alkaline=1.5) |
01:04:06 | dreed75 | i am getting impatient to try rockbox |
01:04:09 | bagawk | thatcould be bad for the HD |
01:04:20 | bagawk | dreed75: you ordered an archos? |
01:04:31 | dreed75 | i bought it off ebay |
01:04:34 | dreed75 | brand new |
01:04:39 | bagawk | neat :) |
01:04:43 | bagawk | what unit? |
01:04:44 | dreed75 | the 20 GB recorder |
01:04:48 | bagawk | nice |
01:05:02 | dreed75 | do you have rockbox installed? |
01:05:12 | | Quit bagawk_ (Read error: 104 (Connection reset by peer)) |
01:05:16 | bagawk | yes, i do not know anyone that wouldn't after they tried it |
01:05:29 | dreed75 | yeah i know, it sounds cool |
01:05:36 | dreed75 | and looks cool |
01:05:47 | bagawk | :) |
01:05:52 | dreed75 | did you flash the firmware with rockbox's firmware without any problems? |
01:06:01 | dreed75 | cause i am kinda nervous about that |
01:06:11 | bagawk | yes |
01:06:25 | bagawk | you do not have to do it if you do not want |
01:06:29 | plok | Zagor, is there a theory yet on how we'll be able to rollback a buggy firmware on the iRiver? |
01:06:43 | bagawk | and you box may not be flashable any way |
01:06:46 | bagawk | *your |
01:06:57 | dreed75 | 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 | bagawk | that is just because it is a simulator |
01:07:21 | dreed75 | it is faster with the rockbox firmware isnt it |
01:07:23 | bagawk | how could it recorde? :) |
01:07:32 | dreed75 | its a recorder |
01:08:10 | dreed75 | oh yeah, i thought that it would at least have a menu even if it didnt work |
01:08:15 | bagawk | everything is fast with rockbox |
01:08:38 | bagawk | playlists is where it is much faster |
01:08:57 | dreed75 | boot time is faster isnt it |
01:09:19 | bagawk | 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 | bagawk | If your unit is flashed it can boot in about 3-4 seconds |
01:09:42 | dreed75 | 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 | bagawk | with rockbox firmware flashed, about 10 or so |
01:10:17 | bagawk | are you talking about the logo? |
01:10:22 | dreed75 | yeah |
01:10:35 | bagawk | yes, it is in apps/recorder/icons.c |
01:11:50 | bagawk | you make a 112x37 bmp (in monochrome) |
01:12:01 | dreed75 | 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 | bagawk | use the tool bmp2rb, and it will give you the array as you see in the icons.c |
01:12:14 | dreed75 | oh sweet, thanks |
01:12:15 | bagawk | not grayscale |
01:12:34 | bagawk | although with some work, you could now since greyscale has been developed |
01:13:27 | bagawk | the logo is rockbox112x37 btw if you did not know which one |
01:13:35 | bagawk | (in icons.c |
01:13:37 | bagawk | ) |
01:13:41 | Zagor | 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 | dreed75 | thanks dude, you've been a big help..also killing time so i don't go crazy waiting to install rockbox |
01:15:08 | bagawk | :) |
01:15:14 | bagawk | dreed75: i assume oyu can write code? |
01:15:18 | | Quit ripnetUK () |
01:15:42 | dreed75 | i am new with C but I learn fast |
01:15:50 | dreed75 | i can edit very well :) |
01:15:55 | bagawk | cool |
01:16:37 | kaboofa | ugh |
01:16:41 | kaboofa | my eyes are thirsty as hell |
01:16:50 | kaboofa | if i have to look at another line of java i'm going to destory someone |
01:16:55 | kaboofa | and destroy them |
01:17:17 | bagawk | 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 | dreed75 | ok thanks |
01:18:23 | plok | 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 | Zagor | same thing: we'll write a loader to load from disk, then flash that. |
01:19:43 | Zagor | the loader will be debugged using the bdm, which can run with even an empty flash |
01:20:46 | plok | Aah I'm with you now. So the loader will work the first time it's flashed to the iRiver :) |
01:21:56 | Zagor | 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 | Zagor | during development a simple rolo boot is best |
01:23:44 | plok | 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 | Zagor | h100 first |
01:24:40 | Zagor | we'll see where we go from there when/if we get there :) |
01:24:55 | plok | :) |
01:26:21 | plok | Oh, the blue navi button on the h300 is an actual button ctw |
01:26:43 | Zagor | ok |
01:26:50 | dreed75 | bagawk: is monochrome the same as black and white in paint? |
01:26:59 | Zagor | i hate it when they label the buttons... |
01:27:09 | bagawk | dreed75: yes |
01:27:30 | dreed75 | thanks |
01:28:12 | | Quit AciD (Connection timed out) |
01:29:50 | plok | They also have a button labelled "A-B" for some reason known only to them :) |
01:30:29 | Zagor | those labels are easier, simply because they don't mean something specific. but "navi" doesn't give a lot of leeway... |
01:31:49 | Zagor | 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 | Zagor | with "navi" we're pretty much forced to put the file navigator on it |
01:35:04 | amiconn | Ahaaa! Now I finally get clock pulses! |
01:35:29 | amiconn | Really silly mistake, btw |
01:35:54 | Zagor | most are, in hindsight :) |
01:37:40 | amiconn | Note to self: if you ever change some <REG_MACRO> &= NN; into and_b(NN, <REG_MACRO>); , put an "&" in front of the macro name. Doh! |
01:38:39 | Zagor | i'm off to bed |
01:38:41 | | Quit Zagor ("Client exiting") |
01:39:01 | amiconn | Probably a good idea. I'm off now too |
01:39:33 | | Part amiconn |
01:44:03 | | Quit dreed75 ("CGI:IRC (EOF)") |
02:00 |
02:08:50 | | Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)") |
02:14:43 | | Quit _aLF (Remote closed the connection) |
02:19:55 | bagawk | 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 | joshp | where do i get autostart.rock and how do i use it |
02:55:43 | | Quit joshp ("CGI:IRC (EOF)") |
03:00 |
03:19:02 | | Part scott666_ |
04:00 |
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 | macgyver2 | does anybody know where to get the autostart plugin |
04:26:24 | macgyver2 | is anyone here |
04:34:51 | kaboofa | sleeping. |
04:44:48 | | Quit macgyver2 ("CGI:IRC") |
04:49:12 | *** | Saving seen data "./dancer.seen" |
05:00 |
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:00 |
06:49:16 | *** | Saving seen data "./dancer.seen" |
06:50:35 | | Join LinusN [0] (~linus@labb.contactor.se) |
07:00 |
07:08:30 | | Join PaulS [0] (~437e19f6@labb.contactor.se) |
07:13:01 | plok | Linus, have you attempted to play .m3u playlists on your iRiver? |
07:21:20 | PaulS | I filled in a bit of the memory map. Hows the logic analyzer doing for you, Linus? |
07:27:15 | LinusN | plok: no, i haven't |
07:27:29 | LinusN | PaulS: fell asleep yesterday :-) |
07:27:56 | LinusN | 3hrs of sleep per night takes its tribute... |
07:28:22 | plok | 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 | plok | yuck |
07:29:51 | LinusN | how silly |
07:34:08 | PaulS | LinusN: I was starting to get curious about the hours you were keeping. :-) |
07:38:40 | PaulS | 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 | LinusN | you haven't mentioned which gpio it is |
07:39:43 | LinusN | would be nice to see in the wiki |
07:40:15 | PaulS | It's GPIO1-35. |
07:40:36 | LinusN | wiki wiki wiki :-) |
07:42:46 | PaulS | 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 | LinusN | good |
07:44:08 | LinusN | 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:00 |
08:01:41 | PaulS | I put it in IriverPort in the LCD driver section, where I'd mentioned the GPIO pin before. |
08:04:54 | LinusN | i wonder why they didn't use an address pin for command/data selection |
08:06:02 | PaulS | 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 | dwihno | LinusN: Tonight is the night when I'll pull my keyboard completely apart! It will be an interesting ride! |
08:07:57 | dwihno | Good morning everyone, btw! :) |
08:08:52 | | Join methangas [0] (methangas@0x50c61c48.virnxx10.adsl-dhcp.tele.dk) |
08:09:07 | PaulS | It's only 11pm for me. |
08:09:21 | PaulS | (But good morning to you!) |
08:11:29 | dwihno | Ohayo! :D |
08:15:36 | PaulS | Oyasu! |
08:22:15 | | Join amiconn [0] (~jens@pD9E7F596.dip.t-dialin.net) |
08:25:01 | amiconn | G' morning |
08:26:05 | PaulS | Hallo. (Not quite the 17th here yet.) |
08:26:33 | amiconn | :) |
08:27:10 | plok | Nearly time to go home for the weekend here :) |
08:27:32 | dwihno | :) |
08:29:03 | PaulS | No worries. My weekend will still be going strong while you guys start toiling away. |
08:37:00 | plok | 8) |
08:38:44 | LinusN | 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 | amiconn | Morning Jörg. |
08:43:42 | | Join Lynx_ [0] (lynx@134.95.189.59) |
08:44:16 | amiconn | [IDC]Dragon: At least I finally found it. Now I get nice clock pulses both for reading and writing |
08:45:15 | amiconn | 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 | amiconn | ;) |
08:46:17 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
08:46:39 | dwihno | LinusN: Well, I might as well clean the keyboard when I'm pulling it apart |
08:47:51 | amiconn | [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 | LinusN | 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 | amiconn | 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 | LinusN | PaulS: "external termination" on the LCD CS, does that mean that the LCD glue has to generate TA? |
08:50:37 | amiconn | 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 | amiconn | 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 | amiconn | ? |
08:51:50 | dwihno | LinusN: Aaaaaah. Smart. I was going to simply make notes |
08:52:07 | dwihno | 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 | dwihno | That would be really neato |
08:52:17 | LinusN | a digital camera is a blessing in those cases |
08:52:20 | [IDC]Dragon | s/cars/card |
08:52:32 | dwihno | LinusN: good idea indeed! |
08:54:08 | amiconn | [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 | PaulS | 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 | amiconn | 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:00 |
09:01:22 | PaulS | Speaking of pictures, I'd like LinusN to take a shot of the IHP with the display off. |
09:01:33 | LinusN | PaulS: so the AA bit is 0? |
09:02:01 | LinusN | 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 | PaulS | Yeep! No! AA is 1. TA is internal evil naughty Paul! |
09:03:59 | LinusN | you scared me there :-) |
09:04:18 | PaulS | Thanks for probing patiently until I realized my folly. |
09:04:25 | | Quit ashridah ("Client exiting") |
09:04:36 | amiconn | [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 | amiconn | I'll try to get one of course |
09:05:16 | LinusN | PaulS: it really seemed fishy with external TA generation, it is very uncommon |
09:05:26 | PaulS | I'll go fix the Wiki. |
09:05:31 | LinusN | good |
09:05:52 | LinusN | why not fill in the CS register values? |
09:06:09 | LinusN | so we have the waitstates etc |
09:06:34 | PaulS | It'll get wordy, but I'll do it. |
09:07:05 | PaulS | 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 | LinusN | it's not *that* important, but the ws is kind of interesting |
09:07:17 | LinusN | 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 | LinusN | hi Bagder |
09:10:22 | Bagder | morning |
09:10:24 | amiconn | [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 | LinusN | Bagder: i have the wiggler |
09:10:41 | * | [IDC]Dragon relocates to work, cu |
09:10:46 | Bagder | any progress with it yet? |
09:10:46 | | Quit [IDC]Dragon () |
09:10:53 | amiconn | (away too) |
09:11:31 | Bagder | sleeping daughter and a mug with fresh steaming coffee |
09:11:41 | Zagor | life is good :) |
09:11:48 | Bagder | yeps |
09:12:08 | LinusN | Bagder: fell asleep yesterday, so no progress :-) |
09:12:16 | Bagder | hehe |
09:12:24 | Bagder | except on the sleeping department then! |
09:13:08 | LinusN | woo, got almost 5hrs of sleep, much better than the usual 3 :-) |
09:13:24 | Bagder | luxury! ;P |
09:13:37 | LinusN | let's not make it a habit :-) |
09:14:26 | | Join amiconn_ [0] (~jens@pD9E7E941.dip.t-dialin.net) |
09:18:28 | dwihno | LinusN: Yay! Did you wiggle last night? |
09:18:46 | Zagor | yeah, in his sleep :) |
09:22:46 | dwihno | :) |
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 | PaulS | 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 | PaulS | * 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 | PaulS | 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 | LinusN | PaulS: are you still editing IriverMemoryMap? |
09:46:59 | PaulS | Nope. All done. |
09:57:02 | LinusN | ok, i take the lock then |
09:58:38 | LinusN | PaulS: since you didn't mean TA generation, what exactly did you mean with "Set up for external termination"? |
09:59:21 | Bagder | Zagor: have you looked at the daily build table? |
09:59:38 | Zagor | yes, and i've fixed the non-sim ones |
09:59:45 | Zagor | non-win32 i mean |
09:59:50 | Bagder | ok |
10:00 |
10:00:03 | Zagor | for some reason i can't compile the win32 in my shell |
10:00:21 | Bagder | do you have the path setup for the mingw cross-compiler? |
10:00:34 | Zagor | yes, but I get other weird errors |
10:00:46 | Bagder | strange |
10:00:50 | Zagor | very |
10:02:17 | LinusN | lcd-win32.h:42: error: `LCD_HEIGHT' undeclared here (not in a function) |
10:02:21 | Zagor | 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 | Zagor | ah silly me i haven't converted the win32 makefile |
10:02:55 | * | Zagor hits forehead |
10:02:57 | LinusN | "converted"? |
10:03:19 | Zagor | yeah, from using defines to using config.h |
10:07:44 | [IDC]Dragon | amiconn: listening? |
10:17:23 | PaulS | Okay, it's bedtime. NIght guys. |
10:17:30 | Bagder | night! |
10:17:44 | LinusN | PaulS: please answer my question |
10:19:26 | PaulS | Which was that, LinusN? |
10:19:46 | LinusN | PaulS: since you didn't mean TA generation, what exactly did you mean with "Set up for external termination"? |
10:22:02 | PaulS | 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 | PaulS | Wiki thinks you're still editing that page. Is this true? |
10:23:51 | LinusN | yes, i am removing that sentence |
10:24:28 | LinusN | so you can go to sleep now :-) |
10:24:43 | PaulS | 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 | LinusN | 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 | PaulS | It uses MOVE.B <byte>, (address register containing 0xF0000000), so I assume big-endian would write to the "high" or MSB byte. |
10:27:51 | LinusN | thx |
10:29:02 | [IDC]Dragon | LinusN: about some old, boring SH hardware: |
10:29:11 | LinusN | :-) |
10:29:35 | PaulS | −−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 | LinusN | PaulS: nm, i can find that out myself |
10:30:03 | LinusN | [IDC]Dragon: yes |
10:30:08 | Zagor | that's not entirely true. |
10:30:24 | Zagor | most of it is actually rewritten from scratch |
10:30:27 | LinusN | 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 | LinusN | [IDC]Dragon: forget it :-) |
10:31:39 | [IDC]Dragon | :( |
10:32:06 | LinusN | 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 | LinusN | my stuff wasn't finished, and probably didn't work at all :-) |
10:32:54 | LinusN | but it shouldn't be *that* hard to add |
10:33:20 | Zagor | fat16 isn't too bad. fat12 is hell. |
10:33:34 | [IDC]Dragon | yes, we had that. |
10:33:38 | Zagor | :) |
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 | Zagor | correct |
10:35:26 | Zagor | the code is 90% my mess |
10:35:26 | [IDC]Dragon | so nothing I can dare ask you to do? |
10:35:48 | PaulS | 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 | PaulS | 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 | LinusN | indeed |
10:37:35 | * | PaulS can't leave a good mystery alone. |
10:38:40 | Zagor | [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 | PaulS | 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 | LinusN | rather D31-D24 |
10:40:14 | [IDC]Dragon | Zagor: ok, I'll step away with that from you guys |
10:40:33 | LinusN | btw, i'll set it to 16-bit port size in my code |
10:40:55 | PaulS | 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 | Zagor | right |
10:42:51 | PaulS | 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 | Zagor | Bagder: do you remember any particular reason why the win32 sims aren't called rockboxui like the x11 ones? |
10:43:54 | Bagder | it wasn't my decision, I believe that's just how edx named it |
10:44:13 | Zagor | ok. i'm renaming it. |
10:49:19 | *** | Saving seen data "./dancer.seen" |
10:49:45 | | Quit Bagder ("Leaving") |
10:50:08 | LinusN | personally, i like the uixxxxxxx name better |
10:50:20 | Zagor | too late :) |
10:50:29 | LinusN | only because the command line completion doesn't find any ambiguities |
10:50:48 | Zagor | 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:00 |
11:05:51 | ripnetUK | morning |
11:06:00 | ripnetUK | any news on how LinusN's wiggeling went? |
11:06:07 | LinusN | how silly, the zip file has the executable flag set |
11:06:17 | LinusN | ripnetUK: no news, fell asleep yesterday |
11:07:01 | Zagor | LinusN: really? doesn |
11:07:03 | Zagor | 't for me |
11:07:50 | ripnetUK | ok :) |
11:08:28 | LinusN | Zagor: what's your umask? |
11:08:34 | Zagor | 22 |
11:08:44 | LinusN | mine too |
11:09:01 | LinusN | and "make zip" gives me a rockbox.zip with x flags set |
11:09:14 | Zagor | did you remove it first? |
11:09:37 | | Join ashridah [0] (ashridah@dialup-a1-423.Melbourne.netspace.net.au) |
11:09:42 | LinusN | Zagor: yes |
11:09:47 | Zagor | strange |
11:10:45 | LinusN | in cygwin of course, i assume you understand that |
11:11:11 | Zagor | ah, no i didn't. |
11:11:46 | LinusN | i assumed that since you were working with the win32 sim |
11:12:04 | LinusN | or were you? |
11:12:20 | Zagor | i was, but in linux using mingw |
11:12:29 | LinusN | ah |
11:16:43 | dwihno | Neato! |
11:16:52 | dwihno | you cross compiled mingw? |
11:17:23 | Zagor | yup |
11:23:51 | dwihno | 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:00 |
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 | Zagor | 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:00 |
13:23:16 | Zagor | [IDC]Dragon: is it ok with you if I change the ondio key mapping to my ButtonAssignments scheme? |
13:34:02 | Zagor | 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 | Zagor | good, thanks |
13:35:47 | [IDC]Dragon | how do you do the button assignment? |
13:36:24 | Zagor | 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 | Zagor | i know. i'm removing the duplicates, leaving only one define per value in button.h |
13:42:20 | Zagor | 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 | Zagor | i'm fixing those cases too |
13:46:02 | [IDC]Dragon | giving them a mapping? Excellent! |
13:46:08 | Zagor | yes |
13:46:21 | Zagor | 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 | Zagor | 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 | Zagor | one set in tree, one in menu, one in settings and one in wps |
13:56:40 | Zagor | 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:00 |
14:01:58 | Zagor | 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 | Zagor | 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 | Zagor | yes |
14:10:32 | [IDC]Dragon | goodie |
14:11:02 | mbr | [IDC]Dragon: I have some general questions about the ondio .. |
14:11:24 | mbr | is the radio reception really that worse? |
14:11:34 | mbr | 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 | mbr | :)) |
14:12:33 | [IDC]Dragon | took it apart 10 min after I got it |
14:12:48 | mbr | lets try another question |
14:13:12 | mbr | do you see any chance to support internal and external memory at the same time? |
14:13:20 | mbr | 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 | mbr | Ah, OK |
14:14:25 | [IDC]Dragon | it makes no sense to RAID them together |
14:15:12 | mbr | 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 | mbr | That would be nice also |
14:16:06 | mbr | 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 | mbr | so a SW switch would be sufficient |
14:16:58 | mbr | but where to keep the card when yo are somewhere |
14:17:28 | [IDC]Dragon | yes, this big, bulky card :-/ |
14:17:31 | mbr | 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 | mbr | Ah, haven't known that |
14:19:24 | mbr | ok, thanks for the answers, I think I order one :)) |
14:20:56 | mbr | and try the FM on my own :)) |
14:43:33 | LinusN | another archos sale thanks to rockbox :-) |
14:44:17 | mbr | like my recorder too :) |
14:48:55 | Zagor | ouch. the keyboard is difficult. it uses every button on the recorders... |
14:49:11 | LinusN | 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 | MrMoo | Does anyone here use TDT? |
14:56:37 | Zagor | tdt? |
14:56:51 | MrMoo | Tag Database Tool (iRiver) |
14:57:10 | | Quit midk_ ("just STOP it arspy") |
14:59:21 | ashridah | 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:00 |
15:08:07 | [IDC]Dragon | Zagor: (keyboard) even the combos are exploited? |
15:08:25 | Zagor | yes |
15:08:39 | Zagor | 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 | Zagor | 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 | Zagor | 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 | Zagor | I don't need direction combos |
15:11:37 | [IDC]Dragon | yet... ;) |
15:11:40 | Zagor | 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 | Zagor | ah, for combos you mean |
15:12:52 | Zagor | no, sorry |
15:13:00 | Zagor | i remember our early discussion now :) |
15:13:22 | Zagor | i'd like to call it something else than debounce though. it's not quite accurate. |
15:13:31 | Zagor | I get confused ever time :) |
15:13:32 | [IDC]Dragon | filtering |
15:13:42 | Zagor | or just stabilising |
15:14:04 | Zagor | whatever :) |
15:14:07 | [IDC]Dragon | jeminds me of camcorders |
15:14:14 | [IDC]Dragon | reminds |
15:14:37 | Zagor | 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 | Zagor | no swearing please :) |
15:16:25 | [IDC]Dragon | Rockbox with TruButton Stabilizer technology |
15:16:35 | Zagor | haha |
15:16:36 | LinusN | Patent Pending |
15:16:52 | [IDC]Dragon | (TM) |
15:17:21 | LinusN | actually, i think the problem might be the A/D driver itself |
15:17:37 | LinusN | to begin with, we read the A/D very seldom |
15:17:41 | Zagor | ah, so it's YOUR fault? ;) |
15:17:46 | LinusN | yes |
15:17:46 | [IDC]Dragon | oops, why? |
15:17:55 | LinusN | we read one channel per tick |
15:18:12 | LinusN | so each channel takes 8 ticks to update |
15:18:17 | [IDC]Dragon | isn't it 4 now? |
15:18:29 | LinusN | i did that, but was forced to revert it |
15:18:43 | LinusN | because we got other weird errors because of it |
15:18:57 | [IDC]Dragon | forced by whom? |
15:19:20 | LinusN | the users who experienced problems? |
15:19:48 | LinusN | 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 | Zagor | that would be slow |
15:20:19 | LinusN | yes, but the conversion takes 10us |
15:20:29 | [IDC]Dragon | it doesn't take that long |
15:20:41 | LinusN | 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 | kurzhaarrocker | BTW: What is a wiggler? Bait? |
15:22:01 | [IDC]Dragon | insomnia |
15:22:04 | LinusN | the interrupt handling eats up a lot of cycles |
15:22:17 | LinusN | kurzhaarrocker: a bdm debugger interface |
15:23:00 | kurzhaarrocker | A piece of hardware I assume? |
15:23:25 | LinusN | kurzhaarrocker: yes |
15:23:55 | kurzhaarrocker | thx, LinusN |
15:30:07 | [IDC]Dragon | Zagor: these HAVE_xxx defines are mostly binary |
15:30:23 | Zagor | 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 | Zagor | you mean we should have #if CPU == SFC5249 |
15:31:10 | [IDC]Dragon | or MAS define |
15:31:12 | LinusN | looks better imho |
15:31:14 | [IDC]Dragon | yes |
15:31:28 | Zagor | not a bad idea. same with keypad. |
15:31:36 | [IDC]Dragon | but let's keep a prefix |
15:31:37 | midk | bbl |
15:31:40 | LinusN | #if DECODER == LIBMAD |
15:31:41 | Zagor | yes |
15:31:53 | [IDC]Dragon | so we know this is platform configuration |
15:31:56 | LinusN | #if DECODER == MAS3507D |
15:32:30 | Zagor | a CONFIG_ prefix ok? |
15:32:43 | LinusN | we might also want a generic macro, like PLATFORM == ARCHOS_JUKEBOX |
15:32:45 | [IDC]Dragon | shorter, CFG_ ? |
15:33:08 | Zagor | well the files are all called config.h and config-xxx so I think calling the defines CONFIG_xx makes sense |
15:33:44 | Zagor | I'll look into it |
15:33:51 | LinusN | 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 | Zagor | we shouldn't need a bunch of ||. if we do we're most likely missing a variable. |
15:35:04 | Zagor | *define |
15:35:49 | Zagor | 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 | Zagor | 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 | Zagor | of course, it now supports two cpus with different register maps and io pins |
15:42:35 | Zagor | #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 | Zagor | explain |
15:43:15 | Zagor | 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 | Zagor | 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 | Zagor | 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 | Zagor | 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 | LinusN | hiding things in macros isn't necessarily a good thing either, it makes it harder to read the "hardware banging" code |
15:47:53 | Zagor | 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 | Zagor | 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 | Zagor | well I don't mind anyway |
15:53:28 | Zagor | don't we have an option for voice menus? |
15:53:40 | [IDC]Dragon | we do |
15:53:57 | Zagor | 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 | Zagor | 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 | LinusN | my voice entry is below "language" |
15:55:59 | Zagor | i must have ran the wrong version |
15:56:15 | Zagor | and it seems I broke the ata driver! :( |
15:56:36 | [IDC]Dragon | maybe you ran the wrong CPU? |
15:58:14 | [IDC]Dragon | you swapped freeze_lock() and identfy(), is there a reason? |
15:58:28 | Zagor | yes, I need the identify information to know if I can run freeze_lock |
15:58:46 | Zagor | i'm not sure the 1.8" disks support Secure Mode |
16:00 |
16:00:21 | [IDC]Dragon | so that didn't break it, hopefully |
16:00:41 | Zagor | no, the bleeding edge build works. phew! |
16:00:49 | Zagor | so it's something I broke in my local build |
16:01:41 | LinusN | gotta fly, cu guys |
16:01:45 | Zagor | bye |
16:01:53 | | Part LinusN |
16:01:53 | [IDC]Dragon | happy wiggling |
16:03:04 | [IDC]Dragon | too late |
16:04:11 | amiconn | [IDC]Dragon: Now I'm around |
16:04:20 | [IDC]Dragon | hey Jens! |
16:04:54 | [IDC]Dragon | I forgot what I wanted 6 hours ago |
16:05:09 | amiconn | ;) |
16:06:28 | | Join R3nTiL [0] (~zorroz@161-250-30-217.kgts.ru) |
16:07:47 | [IDC]Dragon | maybe about MMC cards |
16:07:58 | [IDC]Dragon | the mode change is a PITA |
16:08:27 | [IDC]Dragon | the Archos firmware at some points instructs the user to replug the card |
16:10:03 | [IDC]Dragon | a workaround, because unfortunately they can't switch to card's power |
16:10:17 | [IDC]Dragon | s/to/the |
16:10:26 | amiconn | Maybe when switching to usb mode when the card was used by the Ondio before. Then the card is in SPI mode and can only put back into MMC mode by power cycling |
16:10:49 | amiconn | Luckily the internal flash does have a reset pin... |
16:10:59 | [IDC]Dragon | I haven't taken enough care, when this happens |
16:11:32 | [IDC]Dragon | but the docs say only power cycle can bring it back, don't mention the reset |
16:11:55 | [IDC]Dragon | but it seems to work |
16:12:52 | amiconn | Unfortunately the real MMC cards don't have a reset pin |
16:13:38 | amiconn | I wonder why the MMC specs don't include a "soft" switch back |
16:15:24 | [IDC]Dragon | me too |
16:31:30 | Zagor | i'm away. see you guys. |
16:31:32 | | Part Zagor |
16:39:06 | * | [IDC]Dragon leaves, too |
16:39:19 | | Quit [IDC]Dragon ("CGI:IRC") |
16:41:44 | | Quit R3nTiL (Read error: 104 (Connection reset by peer)) |
16:49:28 | *** | Saving seen data "./dancer.seen" |
16:52:06 | | Join R3nTiL [0] (~zorroz@210-250-30-217.kgts.ru) |
16:52:24 | | Join mrka [0] (~d0b217dc@labb.contactor.se) |
16:54:56 | | Quit ashridah ("sleep") |
16:58:13 | mrka | hello |
16:58:42 | mrka | does anyone know of a different firmware for the av120???????????? |
17:00 |
17:00:21 | mrka | anyone?? |
17:02:41 | methangas | haven't heard of one |
17:05:01 | mrka | dammit |
17:16:40 | | Part kurzhaarrocker |
17:16:54 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
17:25:37 | mrka | anybody know of an alternate firmware for the av120/140???????????????/ |
17:29:18 | webmind | nope |
17:32:57 | | Part mrka |
17:43:36 | | Quit R3nTiL (Read error: 104 (Connection reset by peer)) |
17:45:52 | | Part lImbus |
17:50:01 | | Quit ripnetUK () |
18:00 |
18:49:30 | | Join mecraw_ [0] (~lmarlow@69.2.235.2) |
18:49:33 | *** | Saving seen data "./dancer.seen" |
18:51:57 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
18:51:59 | _aLF | hi |
18:52:48 | | Quit methangas (Read error: 104 (Connection reset by peer)) |
18:57:28 | | Join methangas [0] (methangas@0x50c61c48.virnxx10.adsl-dhcp.tele.dk) |
19:00 |
19:07:22 | | Quit mecraw__ (Read error: 110 (Connection timed out)) |
19:08:08 | | Join webguest33 [0] (~c7e73180@labb.contactor.se) |
19:08:44 | webguest33 | Hello |
19:09:05 | webguest33 | Any developers here? |
19:09:41 | | Quit webguest33 (Client Quit) |
19:10:11 | | Join webguest09 [0] (~c7e73180@labb.contactor.se) |
19:10:34 | webguest09 | Hello |
19:11:40 | dwihno | hola |
19:12:01 | webguest09 | I have a jukebox recorder 10, which I'd like to use at work. I don't have admin, and Windoze says I need drivers and admin to access it. |
19:12:13 | dwihno | hmm |
19:12:23 | webguest09 | Yet my cf reader is fine.. |
19:12:35 | webguest09 | what's different? |
19:12:37 | dwihno | when I connect the unit to a windows 2000 or xp machine, it automatically runs |
19:13:05 | webguest09 | I just loaded rockbox |
19:13:20 | webguest09 | same as with the orig. software |
19:13:28 | dwihno | ask your admin kindly then... might be some admin privilege required in order to install the drivers |
19:13:36 | webguest09 | yes. |
19:13:40 | webguest09 | exactly. |
19:13:53 | webguest09 | Big company security... |
19:14:09 | webguest09 | but my cf reader is mounted w/o any drivers |
19:14:27 | dwihno | strange |
19:14:39 | webguest09 | is there some difference in how devices identify themselves via usb? |
19:15:01 | webguest09 | is the jukebox not "just a mass storage device"? |
19:15:06 | amiconn | dwihno: Do you have recorder 20? |
19:15:09 | dwihno | should be |
19:15:14 | webguest09 | recorder 10 |
19:15:17 | dwihno | amiconn: yup, and I love it! :) |
19:15:26 | amiconn | That's the reason! |
19:15:30 | webguest09 | btw rockbox looks awesome. |
19:15:47 | dwihno | amiconn: the rec10 utilizes isd200? |
19:15:55 | dwihno | naaah? |
19:15:55 | amiconn | Recorder 10 is USB1.1 and not completely mass storage compliant, hence needs special drivers |
19:16:02 | dwihno | aha |
19:16:02 | dwihno | it is |
19:16:05 | webguest09 | wahhh |
19:16:07 | dwihno | it IS ISD200 then |
19:16:14 | amiconn | yup |
19:16:22 | dwihno | I thought all recorders had ISD300 |
19:16:22 | webguest09 | is that a hardware limitation, i take it? |
19:16:25 | | Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new age") |
19:16:35 | dwihno | webguest09: the ISD200 needs additional drivers :/ |
19:17:07 | webguest09 | so i can't use it at work except standalone. |
19:17:14 | amiconn | dwihno: Recorders <= 10 GB have ISD200, Recorder 20 has ISD300. Recorder 15 does exist in both versions afaik |
19:17:41 | dwihno | webguest09: unless you coax your admin to install the ISD200 drviers... |
19:17:58 | webguest09 | we don't have "AN" admin. |
19:18:06 | dwihno | amiconn: aha. well, as far as I have ISD300... :) I've used this to backup my friends' systems more than once |
19:18:15 | webguest09 | We have to call in a ticket to helpdesk, and justify need. |
19:18:40 | amiconn | dwihno: Yes, USB2.0 is really nice to have. I have that too :) |
19:18:42 | webguest09 | I have control over bios boot sequence :) |
19:19:00 | webguest09 | maybe a lightweight linux distro booted via cd? |
19:19:16 | webguest09 | just to copy files to/from cdrom |
19:19:25 | dwihno | webguest09: would work - just make sure isd200 kernel module is loaded |
19:19:37 | dwihno | björn, of the rockbox fame, is the author of that driver :) |
19:19:38 | * | webguest09 makes notes |
19:20:17 | dwihno | amiconn: yeah... I connect it everywhere :) |
19:20:55 | webguest09 | i'm sufficiently impressed with rockbox so far to consider buying another device to run it on. |
19:21:08 | webguest09 | I work in CT, and live in NH |
19:21:15 | dwihno | CT? NH? |
19:21:39 | webguest09 | connecticut and new hampshire (USA) |
19:21:54 | dwihno | okay |
19:22:22 | webguest09 | I drive 2-3 hours every sunday night and friday night |
19:22:25 | dwihno | amiconn: I guess the batteries wear out faster when connected, but batteries are quite cheap |
19:22:46 | dwihno | I ride my bike for 20 minutes in the morning and 15 in the evening... That's suitable for me :) |
19:23:07 | amiconn | I always connect the charger when I copy large amounts of data. Didn't have any problems with running out of battery so far |
19:23:52 | dwihno | true, true |
19:24:02 | webguest09 | I'm going to load the audio prompt stuff so I don't end up in a ditch. |
19:24:05 | amiconn | And yes, it is a really nice backup storage, especially with that 80 GB hd :) |
19:24:36 | dwihno | hehe |
19:25:17 | webguest09 | I was thinking of a hd upgrade, but maybe I should get a jukebox 20 first. |
19:25:18 | dwihno | btw, do you think it will be possible to save the files from my old disk when connected to regular IDE? USB is a no-go |
19:25:29 | dwihno | webguest09: get a recorder 20... |
19:25:50 | amiconn | The players do all have ISD200 |
19:26:34 | webguest09 | I like the record function. I've been playing around saving streams at work. |
19:26:35 | amiconn | dwihno: Yes, IDE should be definitely possible. I did it via USB, was rather fast & easy |
19:26:54 | webguest09 | thats why I wanted to copy files off to cdrom. |
19:27:47 | webguest09 | oh well. gotta get back to work. thanks for the info. |
19:27:57 | | Quit webguest09 ("CGI:IRC") |
19:29:15 | dwihno | amiconn: I tried dd'ing the disk directly without any success.... will a 2.5" adapter be a waste of cash? |
19:30:44 | amiconn | I have no idea. I did copy all data over to my laptop first, swapped the hd, formatted, and then copied all data back. The copying took ~30 min each direction (~20 GB) |
19:31:08 | dwihno | iiiiih |
19:31:10 | dwihno | this lasagna is HOT |
19:50:44 | | Join [IDC]Dragon [0] (~idc-drago@pD9512E52.dip.t-dialin.net) |
19:56:48 | amiconn | [IDC]Dragon: I though about the necessity for bitswapping and the write operation. If we want to write whole blocks with DMA, we have to copy the data into a sector buffer first, then swap, then write. |
19:56:52 | amiconn | *thought |
19:57:17 | [IDC]Dragon | yes |
19:57:19 | amiconn | The copy & swap could be unified to a swap-copy routine though |
19:57:57 | [IDC]Dragon | current swap is in-place only, I presume? |
19:57:57 | amiconn | For reading this problem doesn't exist, as we can swap the data in-place |
19:58:07 | amiconn | yes |
19:58:40 | [IDC]Dragon | and since that is faster, we need a 2nd fn for copy&swap |
19:59:02 | amiconn | It could even be done without being slower |
19:59:14 | | Join webguest74 [0] (~c7e73180@labb.contactor.se) |
19:59:21 | [IDC]Dragon | really? then we need only one function |
19:59:37 | amiconn | [IDC]Dragon: Though that's not possible with the table swap, since the table lookup already takes r0 |
20:00 |
20:00:21 | [IDC]Dragon | I know, you want your geek swap |
20:00:27 | [IDC]Dragon | ;-) |
20:00:53 | amiconn | Argh! I just remembered that this approach to swap-copy would require both source & dest to be long aligned! :( |
20:01:25 | [IDC]Dragon | let's do it simple, for a start |
20:01:37 | [IDC]Dragon | memcpy and swap is fine |
20:02:11 | amiconn | Yes of course. First we need a working version, optimization is the next step |
20:02:25 | amiconn | And memcpy is faast ;) |
20:02:48 | [IDC]Dragon | yes, both have been Jensified |
20:02:55 | amiconn | lol |
20:03:09 | [IDC]Dragon | or, amiconned |
20:03:42 | dwihno | since you guys joined the project, it has been jensified and jörgilized :) |
20:04:25 | [IDC]Dragon | lol, ok, enough |
20:04:59 | dwihno | okay :) |
20:05:04 | amiconn | [IDC]Dragon: For sending commands, the data block size is rather small. I wonder if DMA will increase performance here, or if the DMA setup overhead makes it slower even |
20:05:53 | [IDC]Dragon | right now it's probably all easier without DMA |
20:06:05 | amiconn | I think we should add bitswap.h |
20:06:11 | [IDC]Dragon | on the long run, I'd prefer to have only one set of functions |
20:06:19 | amiconn | Yes. |
20:06:39 | amiconn | Rockbox is already quite large compared to the original firmwares |
20:07:09 | [IDC]Dragon | and it even keeps the localization outside |
20:07:27 | [IDC]Dragon | the Archos f/w has all the strings inside |
20:07:27 | amiconn | Btw: Why did you call the mmc driver ata_mmc.c and not simply mmc.c ? |
20:07:54 | [IDC]Dragon | not too much reason |
20:08:09 | [IDC]Dragon | just to indicate it implements the same functions |
20:08:44 | [IDC]Dragon | we'd still have to use the ata_xxx() names |
20:11:09 | dwihno | what do you guys think about the ondio btw? |
20:11:21 | | Quit webguest74 ("CGI:IRC (EOF)") |
20:11:36 | [IDC]Dragon | haven't used it much |
20:11:51 | [IDC]Dragon | but I like it being small |
20:12:21 | [IDC]Dragon | people say, it eats a lot of batteries |
20:13:20 | dwihno | a new will fix that ;) |
20:16:20 | [IDC]Dragon | ? |
20:17:34 | amiconn | [IDC]Dragon: As you talked about FAT16 support today - FAT16 support is a requirement on the Ondio. If I read the archos docs correctly, the archos firmware does only support FAT16 for the builtin flash. |
20:18:27 | [IDC]Dragon | oh, really? That's bad. |
20:18:36 | amiconn | Btw: I wonder how the original fw boots when there is a mmc inserted already. Does it load ajbrec.ajz from there? |
20:18:59 | [IDC]Dragon | no, it always boots from the internal "card". |
20:20:10 | [IDC]Dragon | hmm, how can we get out of this for a start? Maybe a 2nd partition? |
20:20:53 | amiconn | [IDC]Dragon: read http://www.archos.com/download/firmware/README_ONDIO_FM_history.txt |
20:21:30 | [IDC]Dragon | which part? |
20:21:56 | amiconn | Version 1.31f |
20:24:40 | amiconn | [IDC]Dragon: You could try 2 things: (1) delete ajbrec.ajz from internal flash, and put a rockbox one on an mmc. Then insert the card and try to boot. If rockbox is loading, we know that it also boots from external mmc if inserted |
20:24:46 | [IDC]Dragon | do you read from this that it doesn't support FAT32 boot or that an older version got stuck? |
20:25:01 | [IDC]Dragon | I already did that |
20:25:46 | amiconn | I read from this that an older version got stuck completely, but also newer versions don't read FAT32. The will merely no longer hang, allowing USB access to reformat with FAT16 |
20:25:56 | amiconn | Result? |
20:27:49 | amiconn | If it boots from external MMC, you could try to format one with FAT32, put rockbox on it, then try to boot again |
20:27:58 | [IDC]Dragon | as I told, it only boots from the internal |
20:28:13 | [IDC]Dragon | but I can retry |
20:29:46 | amiconn | If it only boots from the internal flash, it needs to switch disks at some point. |
20:35:19 | | Quit mecraw_ (Read error: 104 (Connection reset by peer)) |
20:36:09 | | Join mecraw_ [0] (~lmarlow@69.2.235.2) |
20:49:34 | *** | Saving seen data "./dancer.seen" |
21:00 |
21:23:00 | | Join elinenbe_work [0] (~elinenbe_@65.115.46.225) |
21:23:11 | elinenbe_work | hello from work! |
21:24:23 | elinenbe_work | hey, can anyone tell me the latest on the iriver front? |
21:26:34 | dwihno | linus is wiggling it |
21:32:34 | elinenbe_work | that's what it looks like −− I was just wondering if he got his BDM Wiggler yet? |
21:32:43 | | Quit mecraw_ (Read error: 104 (Connection reset by peer)) |
21:33:15 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
21:40:57 | dwihno | dunno |
21:41:02 | dwihno | I don't know jack about wiggler |
21:41:09 | dwihno | Heck, I don't even know Jack :) |
21:41:19 | | Quit [IDC]Dragon (Read error: 110 (Connection timed out)) |
22:00 |
22:06:20 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34571.dip.t-dialin.net) |
22:31:50 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
22:34:41 | [IDC]Dragon | amiconn: (FAT16 dilemma) I think we should first make Rockbox work with the external MMC, which can thenbe FAT32-formatted |
22:35:18 | amiconn | Hrm |
22:35:41 | [IDC]Dragon | the only way out I could think of |
22:37:25 | amiconn | I thought Zagor or Bagder already implemented FAT16 support once, and simply took it out. Sadly, I had to read today that this is not true. |
22:38:09 | [IDC]Dragon | yes, me too :( |
22:38:41 | [IDC]Dragon | I started reading about the subject, it doesn't look difficult |
22:39:00 | [IDC]Dragon | but the question is how to test this |
22:39:36 | amiconn | Erm, on a Jukebox with a FAT16 partition perhaps? |
22:40:30 | [IDC]Dragon | no, Archos (and Rockbox) can't boot there |
22:40:57 | amiconn | There can be more than one partition |
22:41:03 | amiconn | There is also some test code for the FAT driver in the test/ subdir. (I have to admit that I couldn't figure how to use this) |
22:41:28 | [IDC]Dragon | haven't looked, but remember having seen it |
22:42:26 | amiconn | There could be 2 partitions, the first being FAT32 and the second FAT16. Then, in a test build, you tell (or change) fat_mount to explicitly mount the 2nd partition |
22:42:43 | [IDC]Dragon | yes, that's good |
22:43:07 | [IDC]Dragon | but with a PC simulation, it would be easier |
22:43:09 | amiconn | I started reading about the DMAC, and digged which timers and DMA channels are already taken in rockbox |
22:43:34 | amiconn | Fortunately, we still have enough of these resources available |
22:43:35 | [IDC]Dragon | yes, there should be enough resources left |
22:43:41 | [IDC]Dragon | ;) |
22:44:07 | amiconn | Timers taken: 0, 1 and 4. DMA channel taken: 3 |
22:44:30 | [IDC]Dragon | you need a timer? |
22:44:43 | amiconn | This leaves us with timers 2, 3, and DMA 0..2. I don't think I'll need a timer though |
22:45:52 | amiconn | I'd like to "reserve" DMA2 for MMC |
22:46:03 | [IDC]Dragon | feel free |
22:46:51 | amiconn | I think I'll go for a 2-buffer approach. While one buffer is transferring, the other will be copied (for writing only) and bitswapped |
22:47:41 | amiconn | Of course, the first version won't use DMA |
22:48:15 | amiconn | I wonder if we could/should fit the write buffer(s) into IRAM |
22:48:16 | [IDC]Dragon | I was thinking on how the CPU could sleep meanwhile |
22:48:48 | amiconn | The CPU could sleep if DMA is introduced |
22:49:06 | [IDC]Dragon | because yield() may be inefficient, walks through all the threads, iirc |
22:49:37 | *** | Saving seen data "./dancer.seen" |
22:49:37 | amiconn | The real ata driver uses yield() |
22:50:02 | [IDC]Dragon | but it copies the data "by hand" |
22:50:29 | amiconn | Yes, and while waiting for busy/ready it yields |
22:51:06 | [IDC]Dragon | which is less frequent |
22:51:52 | [IDC]Dragon | I'm a bit worried if a high-frequency yield (like for each sector) is efficient |
22:52:07 | [IDC]Dragon | but this is later worry |
22:52:14 | [IDC]Dragon | we can ask Linus |
22:53:04 | [IDC]Dragon | how are your commands? |
22:53:21 | amiconn | ? |
22:53:39 | [IDC]Dragon | any like fromthe MMC, or what are you doing? |
22:53:58 | [IDC]Dragon | any life |
22:54:18 | amiconn | Not yet. |
22:55:08 | amiconn | Btw: you really did measure 1.5 MHz bursts with archos fw? I ask because if I don't read my scope wrong, I get 3 MHz?? |
22:55:44 | [IDC]Dragon | I thought so, but may of course be subject to human error |
23:00 |
23:00:03 | amiconn | It looks like we can transfer 3 MBit/s |
23:00:26 | [IDC]Dragon | that's good |
23:09:32 | | Join PaulS [0] (~0d0274bd@labb.contactor.se) |
23:10:30 | PaulS | elinenbe_work: Linus got his wiggler, but last night he didn't quite get his wiggle on, because he fell asleep. He'll presumably be back for some wiggle action tonight. |
23:12:00 | PaulS | (Assuming that's his idea of fun on a Friday night.) |
23:15:40 | amiconn | [IDC]Dragon: Just found that I need to poll for the first response byte from the card. Preparing routine. |
23:16:20 | [IDC]Dragon | why poll? |
23:17:20 | amiconn | It's unknown when the card will send its answer. When the first byte is received, data blocks can be transferred without further polling |
23:17:31 | elinenbe_work | PaulS: sounds good. |
23:17:40 | [IDC]Dragon | ah |
23:22:07 | [IDC]Dragon | amiconn: are you utilizing the Ulrich Radig routines? |
23:23:03 | [IDC]Dragon | I mean, the wheel should be invented there |
23:23:28 | amiconn | For reference only. These routines send every byte individually |
23:23:57 | [IDC]Dragon | reference is a good thing to have :) |
23:25:01 | amiconn | I enable/disable the transmitter/receiver before/after every send/receive, because the full duplex setting (both TE and RE = 1) are tricky to handle, and we don't need this, since SPI mode is half duplex |
23:32:33 | [IDC]Dragon | bedtime, cu |
23:32:39 | | Quit [IDC]Dragon () |
23:45:25 | | Join ripnetUK [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) |
23:45:46 | ripnetUK | any news on the wiggling? |
23:50:09 | | Quit ripnetUK (Client Quit) |
23:57:56 | | Join webguest82 [0] (~c7e73180@labb.contactor.se) |
23:58:04 | webguest82 | hi |