| 00:04:52 | amiconn | Found my mistake with the mmc... |
| 00:06:59 | | Quit AciD (Read error: 232 (Connection reset by peer)) |
| 00:10:07 | PaulS | elinebe: Thanks! |
| 00:10:37 | bagawk | ouchhhhhhhh |
| 00:10:51 | bagawk | is it just me are does the player w32 simulator not build? |
| 00:11:02 | bagawk | i have tons of errors on tree.c |
| 00:11:27 | amiconn | maybe you didn't recpompile convbdf? |
| 00:11:32 | amiconn | *recompile |
| 00:11:36 | bagawk | no, convbdf is new |
| 00:11:43 | bagawk | hold on, i try x11 version |
| 00:11:46 | amiconn | hrrm |
| 00:11:58 | elinenbe | PaulS: you didn't answer my question yet... have you gotten anything of substance to run yet? |
| 00:12:07 | PaulS | elinenbe: As I said in the wiki, I used something very similar to patch the ID3 tag processing code so that it called a function that spit the tags out the UART port. I'm fairly confident about the hex file output of the script in the Wiki, but I'm too chicken to try it out without a backout strategy. B) |
| 00:12:22 | bagawk | this source is a little modified, but i have done nothing to tree.c |
| 00:12:32 | bagawk | ill grab new source off cvs brb |
| 00:13:21 | amiconn | bagawk: wfm |
| 00:14:17 | bagawk | amiconn: wfm? |
| 00:14:22 | amiconn | works for me |
| 00:14:32 | bagawk | ok |
| 00:19:03 | bagawk | humm works this time... |
| 00:19:30 | bagawk | i must have made a bad change in a file that broke the player |
| 00:23:15 | | Join gromit`` [0] (~gromit@ALagny-151-1-11-33.w82-121.abo.wanadoo.fr) |
| 00:24:50 | bagawk | arghh it is hard to find a bug when you have lots of #ifdef's |
| 00:25:33 | | Quit gromit` (Read error: 110 (Connection timed out)) |
| 00:47:05 | | Join MisticJeff [0] (~MisticJef@lv-65-40-117-97.dyn.sprint-hsd.net) |
| 00:53:14 | | Join man|e [0] (man-e@bzq-179-178-229.pop.bezeqint.net) |
| 00:53:16 | man|e | hello |
| 00:53:31 | bagawk | hi |
| 00:54:13 | man|e | can someone help me, plz ? :/ |
| 00:54:56 | *** | Saving seen data "./dancer.seen" |
| 00:55:26 | man|e | I have a problem with my av320 joystick :( |
| 00:57:36 | PaulS | Sounds like a hardware problem.. It's for hardware that RockBox hasn't even started to write code for. Are there specifics for the problem? |
| 00:58:23 | man|e | well, the joystick doesn't respond to right and down movements, only up and left |
| 00:58:42 | man|e | I assume its hardware problem, but I don't know where to fix it :( |
| 00:58:43 | bagawk | man|e: oyu can ask in another channle |
| 00:58:49 | bagawk | either #linav, or #avos |
| 00:59:04 | bagawk | i would not know about how to fix it |
| 00:59:04 | man|e | no one is in #linav nor #avos right now :( |
| 01:00 |
| 01:15:00 | bagawk | time to go bye |
| 01:15:15 | bagawk | Zagor: or adjö to you :) |
| 01:15:22 | amiconn | The MMC manufacturers do the same cheating as the hd manufacturers :( |
| 01:15:41 | Zagor | :) |
| 01:16:05 | | Quit bagawk ("umount /dev/brain") |
| 01:16:19 | amiconn | My 256 MB card has exactly 256835584 bytes, which equals a little less than 245 MB |
| 01:16:53 | amiconn | Btw: The values is read from the card by my code :) :) :) |
| 01:45:54 | | Quit Zagor ("Client exiting") |
| 01:46:30 | | Part man|e ("Leaving") |
| 02:00 |
| 02:04:26 | | Quit MisticJeff (Read error: 238 (Connection timed out)) |
| 02:04:31 | | Quit mecraw ("Trillian (http://www.ceruleanstudios.com)") |
| 02:32:55 | | Join plok [0] (s336156@student.uq.edu.au) |
| 02:37:59 | * | plok is away - Automatically set away. - messages will be saved. |
| 02:39:28 | | Part PaulS ("Off I go") |
| 02:45:53 | amiconn | First real MMC file system access on Ondio! |
| 02:49:30 | amiconn | amiconn.dyndns.org/Ondio_FileSystem.jpg">http://amiconn.dyndns.org/Ondio_FileSystem.jpg |
| 02:54:59 | *** | Saving seen data "./dancer.seen" |
| 02:56:49 | | Part amiconn |
| 03:00 |
| 03:12:33 | | Quit plok ("I'm outta here!") |
| 04:00 |
| 04:49:23 | | Join Byron [0] (byron@208005060030.logonix.net) |
| 04:53:49 | Byron | can someone tell me what CVS is, I wanted a talking clock on my archos but I can't find it, I installed a Daily Build but I don't see a clock in the info menu |
| 04:55:00 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:15:22 | | Join darryl-upstairs [0] (byron@208005060030.logonix.net) |
| 05:15:44 | darryl-upstairs | Does anyone have instructions on upgrading the hard drive on the FM Recorder |
| 05:16:11 | | Nick darryl-upstairs is now known as Byron-2 (byron@208005060030.logonix.net) |
| 05:16:21 | Byron-2 | oops, stupid ghost |
| 05:16:41 | Byron-2 | friend used my computer and it still had his nick on it |
| 05:21:52 | | Join ashridah [0] (ashridah@dialup-a2-340.Melbourne.netspace.net.au) |
| 05:35:35 | | Quit Byron (Read error: 110 (Connection timed out)) |
| 06:00 |
| 06:49:46 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 06:55:02 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:10:28 | | Quit Byron-2 (Read error: 238 (Connection timed out)) |
| 07:15:43 | | Join PaulS [0] (~437e19f6@labb.contactor.se) |
| 07:16:23 | PaulS | Well, I got too cocky, and now I need a wiggler to dig myself out of a jam I got myself in... |
| 07:20:22 | LinusN | saw tat :-) |
| 07:20:38 | LinusN | and i haven't even got the wiggler to work yet ... |
| 07:21:47 | PaulS | Them's the breaks. There aren't any bad short-term side effects. The sad part is that the code I have now isn't the one with my ID3 hack, so I can't continue with the other stuff I was thinking of messing with. |
| 07:22:07 | LinusN | :-( |
| 07:22:39 | LinusN | another sad thing is that the bdm connection process is rather involved |
| 07:22:48 | PaulS | I'm considering seeing if the chip works in JTAG boundary scan mode. If it does, I can bit-bang a flash programming routine. |
| 07:23:03 | LinusN | :-) |
| 07:23:48 | PaulS | (I did this sort of thing with the StrongARM a couple years ago.) |
| 07:24:02 | LinusN | so you haven't seen any evidence in the original firmware of a boot monitor of any kind |
| 07:24:29 | LinusN | like waiting for a character on the serial port while booting |
| 07:24:46 | PaulS | The chances of that are pretty dismal. |
| 07:25:35 | LinusN | so your firmware can't load ram images either? |
| 07:26:37 | PaulS | Not as far as I can tell. I'm hard pressed to say why. I got hung out to dry when I put some debug "putc" calls in my wrapper routine. |
| 07:27:40 | PaulS | I know that there's code that makes sure the file size is > 0x200, but padding the RAM image didn't change its behavior significantly. |
| 07:28:16 | PaulS | (But that could have been after I messed up the wrapper function with the putc calls...) |
| 07:28:45 | LinusN | really annoying |
| 07:29:10 | PaulS | It's possible that the original image would have worked if I'd padded the RAM image, now that I think of it. The putc themselves could be killing me for some reason.\ |
| 07:31:16 | PaulS | What sort of troubles are you having with the BDM drivers? |
| 07:31:42 | LinusN | there is a kernel driver and a userspace library to communicate with it |
| 07:32:20 | LinusN | and the user space lib is not behaving correctly, it doesn't talk to the driver at all, it thinks it connects but it doesn't |
| 07:32:41 | | Quit midk (Read error: 104 (Connection reset by peer)) |
| 07:32:54 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 07:35:25 | uski | LinusN: u there ? (i don't think so :D) |
| 07:35:38 | PaulS | Hmm.. I'll hold off ordering the wiggler until you get a little further. It might be better for me to work on the boundary scan in parallel. |
| 07:36:46 | LinusN | uski: i'm here |
| 07:37:21 | LinusN | PaulS: indeed, that might be a better way of salvaging a bad flash, since there are fewer wires to solder |
| 07:39:22 | PaulS | Looks like all the JTAG pins are there, as long as you can match the silkscreen up with the right pads. |
| 07:40:13 | LinusN | it's not trivial, but i know which one is which |
| 07:45:58 | PaulS | Hmm.. Any chance you could mark-up a JPEG with nice pointy arrows? B) |
| 07:46:08 | LinusN | i could do that |
| 07:46:20 | LinusN | but not until tonight :-( |
| 07:47:28 | PaulS | I think that if I stare at it hard enough I can argue that there's only one set of assignments that make sense. |
| 07:47:54 | PaulS | I prolly won't be opening my iRiver until tomorrow, if then anyway. |
| 07:50:24 | LinusN | i can tell that the staring method won't work |
| 07:50:34 | LinusN | been there, tried that :-) |
| 07:51:08 | LinusN | when i later checked with the multimeter on the naked iriver pcb, i had to move quite a few wires |
| 07:54:07 | PaulS | Hm. Well, just bear in mind that inquiring minds want to know the correct pin assignments. When you can, of course. I'm not sitting here with a non-functional unit. |
| 07:54:19 | PaulS | Moreover my own hubris got me here. :-) |
| 07:55:54 | LinusN | hehe |
| 07:56:06 | LinusN | don't worry, i'm on the case |
| 07:58:51 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34BAC.dip.t-dialin.net) |
| 07:59:53 | [IDC]Dragon | logpeeker asks: what did PaulS do? |
| 08:00 |
| 08:00:44 | LinusN | patched the original firmware to run images directly from disk |
| 08:01:11 | [IDC]Dragon | oh, wow |
| 08:01:12 | LinusN | s/patched/tried to patch/ :-) |
| 08:01:29 | [IDC]Dragon | oh, and now it's dead? |
| 08:01:45 | LinusN | no, it just can't reflash anymore :-( |
| 08:01:58 | [IDC]Dragon | almost the same |
| 08:02:28 | [IDC]Dragon | is there a check in the firmware? |
| 08:02:54 | | Join amiconn [0] (~jens@pD95D188F.dip.t-dialin.net) |
| 08:03:06 | [IDC]Dragon | hey, Jens is the man!!! |
| 08:03:24 | amiconn | Morning. |
| 08:03:34 | PaulS | Ah.. Here, a first clue: TRST == DSTCLK. That's not a typo −− those pins are the same thing. |
| 08:03:39 | amiconn | [IDC]Dragon: Seen my lo entry/ photo link ;-) |
| 08:03:49 | [IDC]Dragon | yes, terrific! |
| 08:03:57 | [IDC]Dragon | commit, commit |
| 08:04:32 | amiconn | [IDC]Dragon: (1) It is very preliminary: rudimentary error checking, and currently read-only |
| 08:05:00 | [IDC]Dragon | better than cvs, still |
| 08:05:01 | amiconn | (2) You have to disable _a whole lot_ of inits to prevent rockbox from hanging |
| 08:05:13 | PaulS | [IDC]Dragon: To be clear, my iRiver is completely functional except for the ability to reflash. |
| 08:05:32 | [IDC]Dragon | PaulS: strange |
| 08:05:52 | PaulS | No, not too strange, considering the bits of code I was toying with. |
| 08:06:27 | amiconn | LinusN: We do indeed have a problem: The MMCs (at least the internal one) don't use the (logical) 63 sectors/tracks, but only 32. So if I would have enabled writing, I would have trashed the fat... |
| 08:06:41 | [IDC]Dragon | very couragous, to flash some firmware you don't know if it could work |
| 08:06:44 | amiconn | ...with the config sector |
| 08:07:35 | [IDC]Dragon | amiconn: per track? Don't we do LBA? |
| 08:08:43 | amiconn | [IDC]Dragon: Yes we do LBA, but there is still that virtual track blocking. Partitions can only start/ end at multiples of sectors_per_track |
| 08:09:09 | amiconn | The card uses 32 sectors/track, so the first partition starts at sector 32... |
| 08:09:39 | amiconn | LinusN: Am I correct that the only used sector on track 0 is sector 1 (MBR)? |
| 08:09:47 | [IDC]Dragon | and the config sector is where? |
| 08:09:54 | PaulS | [IDC]Dragon: "courageous" −− some would use less flattering words. :-) |
| 08:10:14 | [IDC]Dragon | we can easily move it somewhere else |
| 08:10:31 | amiconn | [IDC]Dragon: config sector is 61 (HDs usually use 63 sectors/track) |
| 08:11:03 | amiconn | LinusN: In that case we should make the config sector dynamic, calculating first_partition_start -2 |
| 08:11:20 | [IDC]Dragon | PaulS: when I did the Archos flash thing, I've spent most of the effort into the UART boot |
| 08:11:26 | LinusN | amiconn: it depends on how you have partitioned |
| 08:11:47 | LinusN | if you have no logical partitions, only the MBR is used |
| 08:12:21 | amiconn | And logical partitions use one additional sector per partition? |
| 08:12:30 | LinusN | don't remember |
| 08:12:40 | amiconn | Hmm, ok |
| 08:12:58 | LinusN | but we can find out the best location for the config sector |
| 08:13:06 | LinusN | by reading the partition tables |
| 08:13:26 | amiconn | LinusN: <amiconn> LinusN: In that case we should make the config sector dynamic, calculating first_partition_start -2 |
| 08:16:38 | [IDC]Dragon | amiconn: did your Ondio play? |
| 08:16:50 | [IDC]Dragon | or is the MAS too diffderent? |
| 08:17:14 | amiconn | No, and this can't work. As I said: [08:05:02] <amiconn> (2) You have to disable _a whole lot_ of inits to prevent rockbox from hanging |
| 08:18:25 | [IDC]Dragon | ok, I didn't know _that_ lot |
| 08:18:26 | LinusN | amiconn: yes |
| 08:19:24 | amiconn | [IDC]Dragon: I didn't figure out exactly which inits do hang (at 3 a.m.), but I disabled settings_apply() through playlist_init() and mp3_init() through talk_init() in main.c to take the photo. |
| 08:20:21 | amiconn | settings_apply() definitely does hang |
| 08:23:29 | [IDC]Dragon | more than fair, at 3 am :-/ |
| 08:24:53 | amiconn | Committed. |
| 08:25:12 | [IDC]Dragon | oh, thanks |
| 08:25:50 | amiconn | You'd have to do the adaptions of main.c yourself for now. Beware: if you do this, the menu doesn't work anymore. Dunno why yet... |
| 08:26:33 | [IDC]Dragon | very rough and strange, indeed |
| 08:27:37 | amiconn | Maybe there's a bug in the new button handling on the Ondio (menu key in browser not catched?) |
| 08:30:17 | amiconn | Btw: We can't do an early return from writing. After transmitting the (last) data block to the card, we have to wait until the block got written. Then there is a "data response" from the card, indicating whether the block got written correctly. |
| 08:30:51 | amiconn | The timeouts are _very_ long with some cards |
| 08:31:57 | [IDC]Dragon | which timeouts? |
| 08:32:00 | amiconn | Perhaps this is the reason why Antonius' 1 GB card doesn't work for playback - the archos fw uses a fixed timeout, which is too short for the worst case even with my 256 MB card |
| 08:32:54 | amiconn | (1) Read timeout: After sending the read command, you'll have to wait for the data block to arrive |
| 08:33:33 | amiconn | (2) Write timeout: After sending the write command and the data block, you'll have to wait until the data got written, and the card tells you the status |
| 08:34:10 | [IDC]Dragon | ah, ok, so this is not done "on the fly" |
| 08:34:38 | [IDC]Dragon | I naively thought this transmission is slow enough |
| 08:35:38 | amiconn | Read timeout with the internal flash is 37,500*8 clocks, and write timeout is 150,000*8 clocks (worst case). |
| 08:36:17 | [IDC]Dragon | is it written on the card? |
| 08:36:27 | [IDC]Dragon | or just the datasheet? |
| 08:36:38 | amiconn | Yes, you have to calculate this from the CSD register data |
| 08:37:24 | amiconn | The archos fw does not do this, but uses a fixed timeout of 150,000*8 clocks. Some cards may want more... |
| 08:37:33 | amiconn | Using the multi-block read and write commands is really useful with mmc |
| 08:39:42 | amiconn | There is also a operating voltage range coded into the OCR register (for accessing the flash core, accessing the logic works with anything 2.0...3.6 V) |
| 08:40:09 | amiconn | If we want to be cautious, we'd have to evaluate this too. (Not done yet) |
| 08:42:25 | [IDC]Dragon | isn't it too late then, the card is already plugged? |
| 08:43:07 | amiconn | No, as long as you don't access the flash core (read/ write data blocks) |
| 08:43:25 | [IDC]Dragon | OK, then we should do so |
| 08:43:54 | amiconn | Maybe the archos fw does not do this though, so it accesses the card regardless while booting |
| 08:44:24 | [IDC]Dragon | but only the internal, I'd reckon |
| 08:44:34 | amiconn | Yup. |
| 08:45:03 | amiconn | (As long as it finds an ajbrec.ajz there) |
| 08:45:29 | dwihno | Do you guys know if it's a bad idea to remove a flash cart while a unit (disregarding flash type) is powered on? |
| 08:45:39 | LinusN | YES! |
| 08:45:48 | LinusN | the BDM driver is working |
| 08:46:02 | dwihno | \o/ |
| 08:46:11 | dwihno | Hooray! |
| 08:46:11 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 08:46:18 | LinusN | too bad the target system is 50km away, so i can't turn it on :-) |
| 08:46:57 | LinusN | coffee time |
| 08:46:59 | dwihno | LinusN: well, use the remote debugging feature(?) :) |
| 08:47:09 | amiconn | Gotta run. |
| 08:47:31 | PaulS | LinusN: Awesome! Teach that thing some manners. :-) |
| 08:47:51 | [IDC]Dragon | amiconn: cu |
| 08:49:28 | [IDC]Dragon | Zagor: I'm reaching the point where multi-choice config definitions are useful |
| 08:49:47 | [IDC]Dragon | for tuner, hardware codec, battery, etc. |
| 08:51:57 | Zagor | i'm fine with that |
| 08:52:23 | [IDC]Dragon | how would you like the "none" case? |
| 08:52:33 | [IDC]Dragon | take the tuner, for example |
| 08:52:54 | Zagor | #ifndef TUNER |
| 08:53:02 | [IDC]Dragon | say, we have CONFIGURATION_TUNER |
| 08:53:17 | [IDC]Dragon | we set it to samsung, philips, etc. |
| 08:53:32 | [IDC]Dragon | or to NONE, or not define it at all? |
| 08:53:35 | Zagor | I prefer CONFIG_TUNER, since the header files are called config.h |
| 08:53:51 | [IDC]Dragon | I like shorter, too |
| 08:53:51 | Zagor | then all targets need all defines, which is bad |
| 08:54:51 | [IDC]Dragon | will #if (CONFIG_TUNER == TEAxx) not complain if undefined? |
| 08:55:05 | *** | Saving seen data "./dancer.seen" |
| 08:55:14 | [IDC]Dragon | (simple preprocessor question, soory for rtfm) |
| 08:56:44 | Zagor | it will complain, but we just put an #ifdef TUNER around the whole file |
| 08:56:44 | [IDC]Dragon | in other words, would we need a #ifdef CONFIG_TUNER around the whole thing, too? |
| 08:56:51 | Zagor | yes |
| 08:57:06 | [IDC]Dragon | hmm, doesn't look nice |
| 08:57:22 | Zagor | adding all (future) config options to all targets isn't very nice either |
| 08:57:34 | [IDC]Dragon | definitely |
| 08:58:26 | [IDC]Dragon | so we could do #if defined(CONFIG_TUNER) && (CONFIG_TUNER==TEAxx) |
| 08:58:26 | LinusN | dwihno: i am debugging remotely from work, but i need to connect and turn on the iriver... |
| 08:59:02 | dwihno | LinusN: aah. snibaaz! :/ |
| 08:59:21 | LinusN | [IDC]Dragon: so your tuner configured as I2C? |
| 09:00 |
| 09:00:02 | Zagor | yes we could. but after all fmradio.c depends on the presence of a tuner in the first place and so a single #ifdef around the file is sufficient |
| 09:00:21 | [IDC]Dragon | LinusN: haven't tried it yet, but will soon |
| 09:00:36 | LinusN | but are you sure it's i2c and not 3-wire? |
| 09:00:54 | [IDC]Dragon | Zagor: for that place, yes, but there may be others. |
| 09:01:07 | [IDC]Dragon | LinusN: pretty much, yes. |
| 09:01:22 | LinusN | ok |
| 09:02:04 | [IDC]Dragon | but it's good to be unspecific in the app (#ifdef CONFIG_TUNER) and more specific in the driver (#if CONFIG_TUNER == xx) |
| 09:02:26 | Zagor | i agree |
| 09:03:31 | [IDC]Dragon | one catch: I suspect the Ondio may have the Samsung tuner on some models, versus I have Philips |
| 09:03:52 | [IDC]Dragon | so we'd have to runtime decide |
| 09:04:01 | LinusN | i think the tuner code shouldn't be compiled at all if there is no tuner |
| 09:04:06 | Zagor | ouch. let's solve it when we encounter it. |
| 09:04:13 | Zagor | LinusN: yes, that is the next step. |
| 09:04:16 | [IDC]Dragon | Zagor: yes, definitely |
| 09:04:50 | [IDC]Dragon | the OndioSP build is different anyway, it has no tuner defined. |
| 09:09:33 | Zagor | yes but that is already covered by the configure script |
| 09:10:17 | [IDC]Dragon | yes, I know |
| 09:15:26 | LinusN | now i know how people must feel when they send patches to this project, and they never get applied |
| 09:15:46 | [IDC]Dragon | why now? |
| 09:15:56 | LinusN | i've sent my second patch to the binutils project, and i'm completely ignored |
| 09:16:27 | [IDC]Dragon | perhaps you haven't waited 6 month yet |
| 09:16:35 | Bagder_ | well, we usually at least comment the patch |
| 09:16:37 | LinusN | i guess i'll have to :-) |
| 09:16:41 | | Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 09:20:42 | LinusN | PaulS: have you disassembled the startup code to any extent? |
| 09:22:06 | LinusN | i'm interested in what it does to stay on when it is started with the Play button |
| 09:23:55 | PaulS | LinusN: I'm not quite sure about what you mean by "what it does to stay on" |
| 09:25:12 | LinusN | i haven't investigated the power supply yet, but i assume that the firmware has to do something (set a port bit) to make the regulator continue feeding power to the cpu when the user releases the button |
| 09:26:30 | [IDC]Dragon | cu later |
| 09:26:33 | LinusN | cu |
| 09:26:38 | | Quit [IDC]Dragon () |
| 09:27:03 | PaulS | Well, there's a bunch of port accesses in the code in flash. If you have a guess as to which GPIO ports are attached to the power supply, I can tell you more about what the state of those pins are. |
| 09:27:12 | LinusN | sure |
| 09:31:55 | Zagor | LinusN: can you commit the recording buffer change we discussed? |
| 09:32:17 | Bagder | http://www.rockbox.org/twiki/bin/view/Main/RockboxOrgEmail |
| 09:32:42 | Zagor | Bagder: excellent |
| 09:33:15 | Bagder | the email@ reaches all three of us |
| 09:33:22 | Zagor | ok |
| 09:33:52 | Bagder | the /etc/mail/virtusertable file is what needs editing to add people |
| 09:40:30 | LinusN | Zagor: sure, but are you sure that it will solve anything for anyone? |
| 09:54:36 | LinusN | does the 1.8" hd run with 3.3 or 5 volts? |
| 09:56:58 | LinusN | btw, it looks like GPIO51 is the one i'm looking for |
| 09:57:14 | LinusN | goes to what looks like a voltage regulator |
| 09:57:18 | | Join amiconn_ [0] (~jens@pD9E7E1A0.dip.t-dialin.net) |
| 09:58:07 | PaulS | Okay, let me take a look. |
| 09:58:31 | LinusN | your wiki table says that it is set to 0 at power off |
| 10:00 |
| 10:01:15 | | Join [ [0] (~d90a3255@labb.contactor.se) |
| 10:01:37 | | Part [ |
| 10:01:52 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 10:02:53 | [IDC]Dragon | I didn't notice until yesterday that rockbox has a domain |
| 10:03:09 | Zagor | LinusN: of course i'm not sure. feel free to make a special build and send to whoever had the problem. i just want to release 2.3. |
| 10:03:34 | LinusN | Zagor: it is unlikely that it solves Paul's problem, since it works with 2.2 |
| 10:04:42 | Zagor | can we please test it before rejecting it? |
| 10:05:12 | PaulS | LinusN: A 1 gets written to GPIO51 pretty early on in the flash. |
| 10:06:47 | [IDC]Dragon | are those new forums replacing the mailing list? |
| 10:06:58 | Zagor | [IDC]Dragon: only for user issues |
| 10:07:23 | [IDC]Dragon | which is 90% |
| 10:08:42 | Zagor | the forum is a complement for those who are afraid of mailing lists. mostly that means non-technical users. |
| 10:09:11 | Zagor | the mailing list has always been about development, not user issues. we've been referring to other sites for pure user interaction. |
| 10:11:54 | Bagder | yeps, the MLA (Mailing List Afraid) people have been using the yahoo group and newmp3 tech instead |
| 10:12:02 | Bagder | this is just Yet Another User Forum |
| 10:12:04 | [IDC]Dragon | it is very diversed, are you sure this is helpful? |
| 10:12:25 | [IDC]Dragon | who should read all forums, or people need to cross.post |
| 10:12:42 | Bagder | yeps |
| 10:12:51 | [IDC]Dragon | e.g. the V2 recorder has its own forum |
| 10:12:52 | Bagder | I surely will never read any of the forums close enough |
| 10:13:48 | [IDC]Dragon | I'd merge recorder, FM, V2 |
| 10:14:05 | PaulS | LinusN: It really doesn't look like they're in a big rush to assert GPIO51, though. It's not like the first thing it does. It's the 4th or so function call in the block of initialization calls. There must be something lofting that signal afloat during the interim. |
| 10:14:09 | [IDC]Dragon | but miss the Ondio forum ;-) |
| 10:14:22 | Bagder | haha |
| 10:15:24 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 10:15:25 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7E1A0.dip.t-dialin.net) |
| 10:15:26 | [IDC]Dragon | I haven't found any Ondio forum anywhere, so it would be a premiere |
| 10:15:54 | | Join Chronic007 [0] (~Miranda@24.30.163.142) |
| 10:23:08 | Zagor | send all feedback to jeff. the forum is his creation. |
| 10:25:18 | [IDC]Dragon | ok |
| 10:28:19 | LinusN | PaulS: they aren't in a hurry, in fact, they should wait so that a tiny glitch doesn't start the device |
| 10:32:21 | PaulS | Oh, so the play button holds the power supply on long enough for us to get to this code, or the machine goes back to sleep.. |
| 10:33:08 | | Join webguest74 [0] (~d5e40056@labb.contactor.se) |
| 10:33:14 | webguest74 | wow ! |
| 10:33:20 | PaulS | This should imply that I can keep the machine on by holding down the play button? I'll try that.. |
| 10:33:22 | webguest74 | didn't excpected to see such a crowd |
| 10:33:26 | webguest74 | hello :) |
| 10:33:34 | Zagor | hi there |
| 10:33:51 | webguest74 | I've just discovered your project |
| 10:33:52 | * | Bagder waves |
| 10:34:07 | webguest74 | and I've got a very very very important question to ask you |
| 10:34:14 | Bagder | welcome to our merry corner of the world |
| 10:34:29 | webguest74 | u can actually see it on http://www.atari-forum.com/ftopic4812.html |
| 10:34:38 | PaulS | Hmm.. The box can turn itself off even with the play button held down. |
| 10:34:39 | webguest74 | I'm the one who started the topic |
| 10:35:23 | Bagder | and what exactly is the question? |
| 10:36:00 | webguest74 | the questio was about playing ym or sndh files (atari St sound processor) or sid ones on Iriver IFP players ? |
| 10:36:29 | | Join pillo [0] (~trillian@navlab03.dei.unipd.it) |
| 10:36:30 | Bagder | is it very CPU intensive? |
| 10:36:55 | webguest74 | i asked for it and a friend (DMA/Sector one ) told me about your rockbox project |
| 10:37:12 | PaulS | Badger: Prolly not −− I think an iRiver outclasses an Atari ST in CPU power, unless there were some serious ASICs involved. |
| 10:37:36 | Bagder | right, I don't think the ST had much extra power than the CPU itself |
| 10:37:40 | Zagor | webguest74: if you are referring to tracker "mod" files, yes it is possible to make a player for them on the iriver |
| 10:38:26 | webguest74 | so i wanted to invite you to discuss this topic on the atari-forum, as everyone seems to be pretty much interested in such a player |
| 10:38:53 | webguest74 | we'd love to hear from the rockbox programmers about that question |
| 10:39:02 | Bagder | eh |
| 10:39:07 | Zagor | thanks, but we're still in the infant stages of the port and haven't got any running code yet |
| 10:39:10 | Bagder | we don't even have it running on the iriver yet |
| 10:39:28 | Bagder | and the Archos is too weak to do it |
| 10:40:09 | webguest74 | ok, badger... I saw you were talking about iriver with Hdds but do u think it would be possible on models without Hdd like the IFP series ? |
| 10:40:10 | Bagder | webguest74: it seems more reasonable to rever the invite: you join a suitable rockbox forum/list and help us develop |
| 10:40:49 | Zagor | webguest74: that depends on the hardware. if it's coldfire-based, it is not impossible. but we're focusing on harddisk-based players. |
| 10:40:58 | webguest74 | it is coldfire based |
| 10:41:26 | Bagder | then it depends on how helpful people with such players are |
| 10:42:04 | webguest74 | ok badger and zagor, i just wanted to ask... it's true that i'd LOVe to see a port for my iriver, so i think if it could be opssible i could help |
| 10:42:14 | Bagder | we don't get any help from any manifacturer, we have ONLY volounteers |
| 10:42:19 | webguest74 | i'm no programmer but, i don't know |
| 10:42:32 | webguest74 | about YM format, everything is on http://leonard.oxg.free.fr/ymformat.html |
| 10:42:32 | Zagor | all platforms anyone wants rockbox on must be thoroughly documented first (and that is *thoroughly*, as in every single chip and even the board schematics) |
| 10:42:58 | webguest74 | yes i've seen the huge work on the site, it's impressive |
| 10:45:11 | Zagor | what I mean is that we are only a few people, we cannot do all work for all platforms. if you want rockbox on a specific platform, doing the research is the best way to increase the chances of that happening |
| 10:46:23 | amiconn | Bagder: Iirc the Atari ST features a DSP in addition to its m68k CPU |
| 10:47:02 | Zagor | hmm, ym is YM2149, a dedicated sound chip. this must be emulated, which means it will require a lot more cpu power than mod files. |
| 10:47:12 | Bagder | ugh |
| 10:48:27 | Zagor | that puts it on par with sidplay, in the "maybe" area. |
| 10:48:37 | webguest74 | yes, it's quite similar to sid |
| 10:49:24 | webguest74 | but as for the harddisk issue only, nothing would prevent rockbox to run on iriver iFp series rather than Ihd ones ? |
| 10:49:53 | Zagor | lots of things would prevent it, since the hardware is different. code must be written to support the hardware. |
| 10:50:16 | webguest74 | :/ ok ok |
| 10:50:41 | webguest74 | thanks a lot for the time you spend answering my questions |
| 10:51:00 | Zagor | np |
| 10:55:06 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:00:14 | PaulS | YM2149 datasheet: http://www.funet.fi/pub/msx/mirrors/msx2.com/vortexion/YM2149.pdf We're talking about tone generators and envelope registers. I wouldn't want to simulate the DSP, but even that probably wouldn't sink the iRiver. |
| 11:01:22 | webguest74 | that's a pretty precise documentation! :-) |
| 11:03:52 | [IDC]Dragon | there is no DSP, those weren't invented |
| 11:04:03 | [IDC]Dragon | it is FM synthesis |
| 11:04:15 | [IDC]Dragon | (analogue, iirc) |
| 11:05:07 | amiconn | I remember having read something about a 56000 DSP in conjunction with the Atari. Maybe this was about an extension board... |
| 11:06:32 | webguest74 | i think the first ataris ST only had the YM |
| 11:06:41 | webguest74 | and then the STE series had a dsp |
| 11:06:52 | webguest74 | but it was not used by anyone |
| 11:06:59 | webguest74 | i dont ' know |
| 11:07:08 | webguest74 | if this page could help : http://www.preromanbritain.com/ymvst/index.html |
| 11:07:49 | PaulS | I think the 56000 came a lot later. |
| 11:10:04 | webguest74 | but in fact, the good format to play atari music is the sndh one |
| 11:10:18 | | Join MooMaunder [0] (~me@194.152.87.150) |
| 11:10:25 | webguest74 | http://sndplayer.atari.org/ |
| 11:10:27 | | Join kurzhaarrocker [0] (~knoppix@p5087736E.dip0.t-ipconnect.de) |
| 11:11:05 | | Join MisticJeff [0] (~MisticJef@lv-65-40-117-97.dyn.sprint-hsd.net) |
| 11:11:47 | MisticJeff | [IDC]Dragon: you now have your Ondio Forum ;) |
| 11:11:58 | webguest74 | The SNDH files can include any kind of YM-2149 playing |
| 11:11:59 | webguest74 | routine. Including SIDvoices, Syncbuzzers and Digidrums. |
| 11:19:43 | | Join tester [0] (~8b020103@vs151108.vserver.de) |
| 11:20:17 | | Quit tester (Client Quit) |
| 11:21:21 | | Join CGI713 [0] (~8b020103@vs151108.vserver.de) |
| 11:21:41 | amiconn | MisticJeff: On the forum pages, the side menu does look a bit odd. Perhaps a css problem. |
| 11:22:04 | | Part CGI713 |
| 11:22:16 | MisticJeff | yes, me messing around this evening and not paying attention. i'll fix in the morning |
| 11:22:19 | kurzhaarrocker | I read something about a recording buffer change by LinusN. What is it supposed to fix? |
| 11:23:41 | | Quit webguest74 ("CGI:IRC (EOF)") |
| 11:23:42 | Zagor | kurzhaarrocker: i want to test lowering the recording buffer watermark so we write out to disk long before the buffer is full, and see if that makes any difference on the reported problems. some have said there are more problems with full disks and/or long files. |
| 11:24:02 | Zagor | lunch |
| 11:24:14 | kurzhaarrocker | Hm. Might even be related to a problem I recently had: stuttering recordings. |
| 11:26:57 | | Part Chronic007 |
| 11:27:11 | | Join ripnet [0] (~3e317522@labb.contactor.se) |
| 11:33:47 | [IDC]Dragon | MisticJeff: thanks! |
| 11:38:09 | PaulS | LinusN: I'm guessing the iRiver uses the 160 pin version of the 5249 part? |
| 11:38:32 | [IDC]Dragon | amiconn: did you commit bitswap.h, too? |
| 11:42:57 | ripnet | are you going with what PaulS is trying to do, ie moding the iRiver firmware (maybe via a .ips patch) to include a boot loader? im guessing the idea is that if a certain file exists and/or a key is pressed during boot, it loads the file into memory and executes it? |
| 11:48:11 | amiconn | [IDC]Dragon: Ahem, 2 days ago, yes. |
| 11:48:53 | PaulS | Nobody's going with anything yet. Essentially all my efforts are premature, and I'm now paying for it. :-) The "keypress during boot" option, while attractive, isn't an option we know how to do yet with the iRiver firmware. I was trying to override the functionality of the "Firmware Upgrade" menu option to support RAM-loaded files. |
| 11:52:22 | PaulS | It's sleepytime over here in PST. Goodnight. |
| 11:53:00 | | Part PaulS ("ZzzzzZzzzz...") |
| 12:00 |
| 12:00:22 | [IDC]Dragon | amiconn: ah, that's why I didn't see it there. sorry. |
| 12:02:12 | MisticJeff | Goodnight everyone... |
| 12:02:15 | | Quit MisticJeff () |
| 12:07:03 | | Quit pillo (Read error: 54 (Connection reset by peer)) |
| 12:07:36 | amiconn | [IDC]Dragon: It's still on the rockbox front page... |
| 12:19:30 | | Quit ripnet ("CGI:IRC") |
| 12:55:10 | *** | Saving seen data "./dancer.seen" |
| 12:57:15 | [IDC]Dragon | amiconn: yes, yes, I was only looking at the commit of this morning :-/ |
| 13:00 |
| 13:02:47 | amiconn | Your swapbyte macro idea is not yet implemented |
| 13:05:13 | | Join Schoki2_ [0] (Schoki@DSL01.212.114.230.1.NEFkom.net) |
| 13:33:41 | [IDC]Dragon | how ironic, I found a wiggler here! |
| 13:33:57 | [IDC]Dragon | McCraigor or so, is that the one? |
| 13:42:13 | LinusN | unfortunately not |
| 13:42:41 | | Part Schoki2_ |
| 13:42:57 | LinusN | the macraigor wiggler has too few i/o:s, and lacks logic for clock synchronization |
| 13:43:08 | LinusN | i have two macraigor wigglers here too :-) |
| 13:45:14 | amiconn | [IDC]Dragon: Are you preparing to do the same thing with the iRiver flash players that we are doing with the Ondio now? ;-) |
| 14:00 |
| 14:10:26 | | Join elinenbe_ [0] (~elinenbe_@65.115.46.225) |
| 14:23:49 | kurzhaarrocker | Is there special software for those wigglers? |
| 14:26:14 | LinusN | kurzhaarrocker: yes |
| 14:28:56 | kurzhaarrocker | Is that a dedicated program with a fancy gui or more something like a api? |
| 14:37:44 | LinusN | it's gdb |
| 14:37:58 | LinusN | with a dedicated wiggler driver |
| 14:38:33 | LinusN | the wiggler driver is a kernel driver and a user space library |
| 14:38:53 | LinusN | and the library can be used for more "general" wiggling, like programing flash etc |
| 14:43:15 | | Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) |
| 14:43:40 | kurzhaarrocker | Ok, now I get the idea. So the wriggler is specialized for communicating with digital hardware. Not just a bunch of general purpose i/o pins. |
| 14:45:13 | LinusN | yup |
| 14:45:23 | LinusN | it's mostly general purpose pins |
| 14:45:36 | LinusN | the macraigor wiggler is only general purpose pins |
| 14:45:55 | LinusN | but the p&e wiggler contains some extra logic |
| 14:46:39 | LinusN | the macraigor wiggler is nothing more than a buffered parallel port |
| 14:49:45 | kurzhaarrocker | Can you debug systems only if they provide some single-step-capabilities? Otherwise I'd be rather surprised if the speed of a parallel port would be fast enough to trace/control the signals in the real world. |
| 14:50:07 | midk | wee! forums! :) |
| 14:50:16 | LinusN | the wiggler is designed for BDM, Background Debug Mode |
| 14:50:41 | LinusN | i.e you stop the CPU and communicate via a bit-banged serial interface |
| 14:52:16 | kurzhaarrocker | Does that include modifying the hardware? For example disconnecting some clock signal generators or handshake lines? |
| 14:54:17 | LinusN | the coldfire has a dedicated bdm port |
| 14:55:12 | *** | Saving seen data "./dancer.seen" |
| 14:55:41 | kurzhaarrocker | ok. |
| 14:55:50 | kurzhaarrocker | Thx |
| 15:00 |
| 15:00:43 | kurzhaarrocker | btw: www.rockbox.org is fine but just http://rockbox.org results in "Hepp" :) |
| 15:01:05 | Zagor | yup, no server there :) |
| 15:01:44 | kurzhaarrocker | Is that a bug or a feature? |
| 15:01:48 | Bagder | let's fix that |
| 15:01:57 | * | Bagder will fix |
| 15:02:03 | midk | people: rockbox.org doesn't work, you have to have "www." in front of it?\ |
| 15:02:27 | midk | is that changeable? |
| 15:02:32 | * | Bagder will fix |
| 15:02:37 | Zagor | use the www address |
| 15:03:02 | kurzhaarrocker | Maybe we should replace "Hepp" with "use the www adress" :) |
| 15:03:21 | midk | zagor: i will if i have to, i'd just continue using 'rockbox.haxx.se' in that case since i'm used to it :) |
| 15:03:32 | | Quit [IDC]Dragon ("CGI:IRC (EOF)") |
| 15:03:45 | Bagder | midk: try now |
| 15:03:56 | Zagor | midk: well it redirects you to www.rockbox.org anyway |
| 15:04:01 | midk | there it goes |
| 15:04:12 | Bagder | Zagor: you mind if I change how that is done? |
| 15:04:15 | kurzhaarrocker | cool :) |
| 15:04:16 | midk | Zagor, yeah, i realized that :) |
| 15:04:27 | Zagor | Bagder: sure, as long as the result is the same |
| 15:05:18 | Bagder | Zagor: I think its nicer to use RedirectPermanent from a separate virtualhost |
| 15:05:25 | Bagder | done now |
| 15:06:05 | Zagor | you forgot a slash somewhere: http://www.rockbox.orghistory.shtml/ |
| 15:06:43 | Bagder | retry |
| 15:06:54 | Zagor | yup, works |
| 15:07:00 | kurzhaarrocker | acknowledged |
| 15:10:47 | | Part LinusN |
| 15:10:50 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 15:11:01 | | Part Zagor |
| 15:11:09 | | Part kurzhaarrocker |
| 15:14:35 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 15:27:19 | | Nick ashridah is now known as Lost-tv (ashridah@dialup-a2-340.Melbourne.netspace.net.au) |
| 15:44:51 | | Join R3nTiL [0] (~zorroz@190-250-30-217.kgts.ru) |
| 15:51:50 | | Quit ze (Read error: 110 (Connection timed out)) |
| 16:00 |
| 16:00:04 | LinusN | time to go |
| 16:00:06 | | Part LinusN |
| 16:03:27 | | Join Hellish [0] (~d4db5e92@labb.contactor.se) |
| 16:03:37 | Hellish | Hi everyone |
| 16:03:43 | Bagder | hi |
| 16:04:14 | Hellish | does anyone know the current development process of the new rockbox firmware for the ihp-120 |
| 16:04:25 | Hellish | ive been reading loads about it and im getting excited |
| 16:04:33 | Bagder | _http://www.rockbox.org/twiki/bin/view/Main/IriverPort |
| 16:05:35 | Hellish | O_O |
| 16:13:09 | | Join methangas [0] (methangas@0x50a432c7.virnxx10.adsl-dhcp.tele.dk) |
| 16:14:19 | | Quit Hellish ("CGI:IRC (EOF)") |
| 16:21:23 | | Nick Lost-tv is now known as ashridah (ashridah@dialup-a2-340.Melbourne.netspace.net.au) |
| 16:29:09 | | Part Zagor |
| 16:29:51 | ashridah | yeah. so. is the iriver port going to be finished tomorrow? |
| 16:29:54 | ashridah | no? |
| 16:29:56 | ashridah | what about the next day? :) |
| 16:32:44 | | Quit R3nTiL () |
| 16:55:16 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:00:23 | | Join ze [0] (psyco@adsl-63-205-44-57.dsl.lsan03.pacbell.net) |
| 17:00:41 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
| 17:08:15 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 17:09:01 | [IDC]Dragon | server fiddling kills cgiirc, I guess |
| 17:14:33 | | Quit ze (Read error: 60 (Operation timed out)) |
| 17:43:02 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 17:52:16 | | Quit ashridah ("sleep") |
| 17:54:44 | | Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) |
| 17:54:55 | | Part oxygen77 ("Cho") |
| 18:00 |
| 18:01:16 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 18:03:53 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 18:19:47 | | Join ze [0] (psyco@adsl-63-205-41-10.dsl.lsan03.pacbell.net) |
| 18:44:23 | | Quit [IDC]Dragon ("CGI:IRC") |
| 18:55:19 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:01:24 | | Join R3nTiL [0] (~zorroz@189-250-30-217.kgts.ru) |
| 19:02:36 | | Quit R3nTiL (Client Quit) |
| 19:05:13 | | Join webguest35 [0] (~c7e73180@labb.contactor.se) |
| 19:05:32 | webguest35 | hi all |
| 19:05:42 | Bagder | hi |
| 19:05:59 | webguest35 | stupid question: where are the .bin files (for flashing) located? |
| 19:06:21 | webguest35 | I've got rockbox loaded |
| 19:06:31 | webguest35 | but I want to flash the rom |
| 19:06:46 | amiconn | Bagder: I'm looking for a place to put the config-block sector calculation into without creating too much cross dependency. |
| 19:06:47 | webguest35 | the files aren't in the .zip (or I missed them) |
| 19:07:05 | Bagder | webguest35: you flash .ucl, not .bin |
| 19:07:28 | webguest35 | maybe I misread the howto. |
| 19:07:31 | amiconn | webguest35: First-time flash, or flash a newer build? |
| 19:07:36 | webguest35 | first time |
| 19:08:02 | webguest35 | if i try the flash util, it says the file is not found |
| 19:08:51 | webguest35 | firmware_rec_norom.bin |
| 19:09:18 | webguest35 | am i VERY lost? |
| 19:09:30 | amiconn | Following the http://www.rockbox.org/twiki/bin/view/Main/FlashingRockbox howto, there are links way down where the first-time flash packages can be downloaded |
| 19:10:01 | webguest35 | aha |
| 19:10:04 | webguest35 | thanks |
| 19:10:19 | webguest35 | I was thinking it'd be part of the main download. |
| 19:11:17 | amiconn | Bagder: Got my question? |
| 19:12:45 | Bagder | yes, but I have no time to give a good answer now |
| 19:13:24 | amiconn | Okay, so I'll have to find it myself. I need this before I write-enable the flash driver... |
| 19:13:39 | Bagder | I trust your ability ;-) |
| 19:21:51 | webguest35 | Looks like all went well. much faster boot. thanks |
| 19:22:22 | | Quit webguest35 ("CGI:IRC (EOF)") |
| 19:48:51 | | Quit pike (Read error: 232 (Connection reset by peer)) |
| 19:49:04 | | Join pike [0] (amiga@h234n1fls22o1064.bredband.comhem.se) |
| 19:59:30 | amiconn | Urgs, more #ifdefing |
| 20:00 |
| 20:55:23 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:48:39 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 21:56:42 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34BAC.dip.t-dialin.net) |
| 22:00 |
| 22:03:56 | amiconn | hi again Jörg |
| 22:04:10 | [IDC]Dragon | good evening |
| 22:04:31 | [IDC]Dragon | I'm starting the multiple choice config |
| 22:04:44 | [IDC]Dragon | *lots* of file to touch |
| 22:04:58 | [IDC]Dragon | expect a major, colorful commit |
| 22:06:45 | amiconn | Hmm. I'm currently trying to figure out why the mmc driver works for a number of tries and then suddenly locks up. This does happen with the internal card only; with the external it will simply fail at some point, but not lock up. |
| 22:06:55 | | Quit Nibbler (Read error: 110 (Connection timed out)) |
| 22:07:17 | amiconn | I hesitate to add writing until I get it running stable... |
| 22:07:30 | [IDC]Dragon | I understand |
| 22:08:23 | dwihno | You guys got MMC reading working already? |
| 22:08:27 | amiconn | Btw, did I say I hate that internal flash chip? |
| 22:09:33 | [IDC]Dragon | no, you didn't |
| 22:10:54 | amiconn | dwihno: Yes, although read-only for now and obviously a bit unstable. See today's cvs activity log |
| 22:11:54 | amiconn | [IDC]Dragon: I do know now why the menu isn't callable from the browser, but have currently no idea how to solve this. |
| 22:12:11 | dwihno | You guys rock! |
| 22:12:41 | [IDC]Dragon | why is it not? |
| 22:13:32 | amiconn | With Zagor's new button code, the menu key alone is defined to be shift, with repeat it should call the menu. However, this can't work, because triggering shift jumps away into a separate function, so menu+repeat is never caught in the main loop... |
| 22:14:35 | [IDC]Dragon | with shift you mean like On+Up/Down for the recorder? |
| 22:14:48 | amiconn | A similar problem exists with the onplay (on Ondio == menuright) menu |
| 22:14:58 | amiconn | yes |
| 22:15:35 | amiconn | Plus, on its own (without using up/down) this is the browser<->wps toggle |
| 22:16:03 | amiconn | There are definitely too few keys... |
| 22:16:49 | [IDC]Dragon | sigh, yes |
| 22:17:03 | [IDC]Dragon | or, Rockbox is overpowered |
| 22:17:24 | [IDC]Dragon | we should not assign shift for now |
| 22:17:45 | amiconn | I would like to switch the browser display to "supported" in order to use RoLo, but obviously can't do so with the menu unavailable... |
| 22:17:50 | [IDC]Dragon | menu is more important |
| 22:18:45 | [IDC]Dragon | you can hard-coded "supported" as default, for your local build |
| 22:33:47 | [IDC]Dragon | amiconn: how is your MAS called again? |
| 22:34:05 | amiconn | MAS3539F, see wiki ;) |
| 22:34:21 | [IDC]Dragon | ah, I forgot wiki :-( |
| 22:34:37 | amiconn | This is controlled the same way as the 3587F, with 2 differences: |
| 22:34:45 | amiconn | (1) There is no recording |
| 22:35:05 | amiconn | (2) The memory cells have different addresses |
| 22:35:12 | amiconn | The registers are all the same |
| 22:35:57 | [IDC]Dragon | we'll have to differentiate that |
| 22:36:09 | amiconn | It offers an additional, more efficient transfer mode, but we are not forced to use this... |
| 22:36:24 | [IDC]Dragon | I'm introducing CONFIG_HWCODEC |
| 22:36:48 | [IDC]Dragon | with the MAS types as values |
| 22:36:58 | amiconn | I intended to handle the different memory cells via #defines, so the access code itself can be shared |
| 22:37:22 | [IDC]Dragon | yes, makes sense |
| 22:39:40 | amiconn | For instance, there is a cell called AppSelect in both MAS's, which is D0:7F6 for 3587 and D0:34B for 3539 |
| 22:40:27 | [IDC]Dragon | later, later ;-) |
| 22:41:22 | | Quit uski () |
| 22:41:36 | amiconn | Imho this will be the next thing I'll have to do as soon as MMC is working. I want to listen to some music at last. Of course you don't need this... |
| 22:42:26 | [IDC]Dragon | the debug menu also doesn't show the MAS in good shape for me |
| 22:42:57 | amiconn | Perhaps you have to init the SIBI pin properly... |
| 22:43:00 | [IDC]Dragon | perhaps some port init problem |
| 22:43:24 | amiconn | Other than that, the MAS control looks identical to the recorders |
| 22:43:49 | [IDC]Dragon | I need to fix the polarity |
| 22:44:07 | [IDC]Dragon | I'm not sure which one is for directly connected |
| 22:44:24 | amiconn | ? |
| 22:44:49 | [IDC]Dragon | that was a mask bit setting for recorders |
| 22:44:59 | amiconn | Ah ok. |
| 22:45:08 | [IDC]Dragon | whether there's an inverter or not |
| 22:45:27 | amiconn | Set PB8 to GP out & low. |
| 22:46:06 | amiconn | We need a mas_init() ... |
| 22:47:47 | amiconn | Grr, this simply gets stuck without showing even one of the splash()es I added all over... |
| 22:55:26 | *** | Saving seen data "./dancer.seen" |
| 22:56:04 | | Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc) |
| 22:58:45 | amiconn | [IDC]Dragon: For your config method change, that the current HAVE_BATTERIES is not the best solution, since it means there are both batteries and a charger. The latter is obviously wrong for the Ondio. So this should be split into something like HAVE_BATTERIES and HAVE_CHARGING. |
| 22:59:00 | amiconn | *keep in mind, that |
| 22:59:24 | [IDC]Dragon | yes, that's on my list, too |
| 22:59:40 | [IDC]Dragon | I also want to specify what kind of batteries |
| 23:00 |
| 23:00:00 | [IDC]Dragon | to avoid #ifdef HAVE_LIION |
| 23:00:01 | amiconn | Then there is that cross-dependency between recording and bitmap display.... |
| 23:00:12 | [IDC]Dragon | lots of them |
| 23:00:24 | [IDC]Dragon | I'm not starting there :( |
| 23:00:55 | amiconn | There is even a cross-dependency between bitmap display and the firmware file name/ extension |
| 23:01:54 | amiconn | We need a typical alkaline discharge curve to get the battery display right on the Ondio |
| 23:02:59 | amiconn | Don't forget the F buttons - certainly we don't want the button bar on the Ondio |
| 23:08:25 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- The dawn of a new age") |
| 23:18:56 | | Join Bagder_ [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 23:19:11 | | Quit Bagder (Read error: 104 (Connection reset by peer)) |
| 23:20:22 | | Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) |
| 23:28:57 | | Join NibbIer [0] (~andrer@port-212-202-77-253.dynamic.qsc.de) |
| 23:33:39 | amiconn | Does somebody know whether the ata functions are called from more than one thread? It seems that the ata_mutex causes the sporadic hangs... |
| 23:34:37 | * | Bagder has no clue |
| 23:35:29 | [IDC]Dragon | I think they are, else a mutex makes no sense |
| 23:36:06 | | Quit Sebulba03 ("brb") |
| 23:37:02 | | Join Sebulba03 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) |
| 23:37:21 | amiconn | Hmm, this leaves the questions (1) which threads could do this on bootup and (2) why there is no such race with the hd models. The bad thing is that now that I have splash()es both before and after the mutex_lock(), the hang does no longer happen... |
| 23:38:03 | amiconn | A splash is slow, of course. A led on a port pin would come in handy... |
| 23:39:12 | | Quit Sebulba03 (Client Quit) |
| 23:40:16 | [IDC]Dragon | if you don't mind some soldering... |
| 23:41:39 | amiconn | Isn't PB4 available at the tuner board header? It does have no function on the Ondio SP... I could simply set/reset it,and measure the voltage in case of a hang |
| 23:42:46 | | Join Sebulba03 [0] (~Sebulba02@Darth-Sebulba04.active.supporter.pdpc) |
| 23:43:34 | amiconn | RoLo hangs... :( |
| 23:45:15 | [IDC]Dragon | yes, PB4 on the tuner board is free |
| 23:45:38 | [IDC]Dragon | rolo maybe does pad port inits |
| 23:46:10 | [IDC]Dragon | s/pad/bad |
| 23:46:35 | [IDC]Dragon | the backlight pin is free as well |
| 23:53:19 | amiconn | It's not the mutex... |
| 23:53:30 | [IDC]Dragon | :( |
| 23:57:24 | amiconn | The flash is specified for 100.000 writes per sector. I wonder how many of them I did already use up ;-/ |
| 23:57:57 | [IDC]Dragon | don't worry, it has replacement sectors |
| 23:58:16 | [IDC]Dragon | rolo would really help... |
| 23:58:18 | amiconn | Yes I know. It has very sophisticated error handling |
| 23:58:43 | amiconn | Yes, especially as the archos usb mode is really sloow compared to rockbox usb mode |
icon identifies that the person is a core developer (has commit access).