| 00:00:03 | solaris | daily build? |
| 00:00:11 | | Join [1]c0utta [0] (~c0utta@158.cust44.nsw.dsl.ozemail.com.au) |
| 00:00:13 | LinusN | sure |
| 00:00:55 | [IDC]Dragon | solaris: in your post, your said the PR polarity was changed after flashing? |
| 00:01:16 | [IDC]Dragon | This would indicate the h/w mask was altered. |
| 00:01:49 | solaris | yes, from positive to negative |
| 00:01:54 | | Quit lImbus (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") |
| 00:01:57 | LinusN | solaris: badness |
| 00:02:14 | solaris | hmmm |
| 00:02:25 | [IDC]Dragon | this should not happen. |
| 00:02:32 | solaris | ok... |
| 00:02:40 | solaris | stop scaring me |
| 00:02:45 | [IDC]Dragon | the value is kept while flashing |
| 00:03:03 | | Quit c0utta (Read error: 60 (Operation timed out)) |
| 00:03:07 | [IDC]Dragon | do you still have your original flash dump? |
| 00:03:11 | solaris | yes |
| 00:03:28 | [IDC]Dragon | can you zip&email it to me? |
| 00:03:31 | solaris | i think i have b4 and after |
| 00:03:34 | solaris | sure |
| 00:04:01 | | Join c0utta [0] (~c0utta@158.cust44.nsw.dsl.ozemail.com.au) |
| 00:04:26 | | Quit Unknown (Read error: 60 (Operation timed out)) |
| 00:05:18 | solaris | e-mail or dcc?? |
| 00:06:01 | [IDC]Dragon | dcc worked, for a change. |
| 00:06:28 | [IDC]Dragon | My firewall seems to have taken the rest of the day off. |
| 00:06:35 | solaris | xinternal is after the 2.1 and internal is b4, i think |
| 00:06:49 | solaris | and xinternal was working, i think |
| 00:08:29 | [IDC]Dragon | both are identical |
| 00:09:04 | solaris | than it must be back up b4 the flash |
| 00:09:41 | amansinger | Sorry to disturb once again, IDC, but do you happen to recall what you did to the username_ta.txt file to get Textaloud to read it for your German voice? Did you just open te text file, and what options did you select, if you remember? |
| 00:10:12 | [IDC]Dragon | solaris: the content is no news, I have that variant. |
| 00:10:46 | amiconn | [IDC]Dragon: I did have another look at mp3_play_pause() and the SH hw manual. Now I think I know what may cause the problem. |
| 00:10:48 | [IDC]Dragon | amansinger: you need to place it int the TA program dir. |
| 00:10:58 | [IDC]Dragon | int=into |
| 00:11:13 | amansinger | Yes? |
| 00:11:17 | [IDC]Dragon | but name it like the existing file you find there. |
| 00:11:47 | amansinger | You've already taken care of that. Your cmd file does that quite nicely. |
| 00:11:58 | LinusN | amiconn: i'm all ears |
| 00:12:09 | [IDC]Dragon | not really, it doesn't know the username. |
| 00:12:43 | amansinger | It uses your user name and your program files dir, yes. I've edited it to mine. |
| 00:12:48 | | Quit [1]c0utta (Read error: 60 (Operation timed out)) |
| 00:13:04 | LinusN | solaris: any luck booting ajbrec.ajz |
| 00:13:18 | LinusN | ? |
| 00:13:25 | [IDC]Dragon | amansinger: then you need to set TA to mulpti-article, multi-file wav output. |
| 00:13:37 | amansinger | c:\progra~1\tta\amsing_tta.txt |
| 00:13:51 | solaris | well, i created/formated fat32 and copied the daily build and it's acting same thing |
| 00:13:57 | amansinger | Perfect, multiarticle, multi file. |
| 00:14:07 | LinusN | solaris: it doesn't boot? |
| 00:14:26 | [IDC]Dragon | amansinger: not user_TAExport.txt ? |
| 00:14:27 | solaris | it boots only with F1 |
| 00:14:35 | solaris | and only in archo's firmware |
| 00:14:42 | LinusN | weird |
| 00:14:59 | solaris | yeap |
| 00:15:22 | solaris | if i press ON, the green led comes on and stays for about 15-20 sec |
| 00:15:24 | amansinger | Yes, I was doing it from memory. I just copied the path and username. |
| 00:15:26 | * | Laurent_ prays the god of the fiscal administration for mercy |
| 00:15:26 | solaris | and shuts off |
| 00:15:35 | LinusN | did you try with the fm build? |
| 00:15:49 | solaris | yes, i tried with every build |
| 00:16:07 | [IDC]Dragon | also with Archos original .ajz? |
| 00:16:12 | solaris | so i'm convinced something went wrong when flashing?? |
| 00:16:18 | solaris | hmmm |
| 00:16:22 | LinusN | solaris: i am too |
| 00:16:28 | solaris | original .ajz? |
| 00:16:34 | solaris | i haven't |
| 00:16:40 | LinusN | but if we can make it boot the ajbrec.ajz, we won't have to do the boot mod |
| 00:16:43 | [IDC]Dragon | to be downloaded from Archos website |
| 00:17:28 | solaris | ok |
| 00:17:34 | solaris | i think i have back up |
| 00:17:37 | solaris | some where |
| 00:17:50 | [IDC]Dragon | it won't do a difference except taking longer to boot, but would prove only Rockbox is unable to load |
| 00:18:00 | [IDC]Dragon | or nothing is able to load at all |
| 00:18:34 | [IDC]Dragon | could this be a side effect of a wrong h/w mask? |
| 00:18:41 | LinusN | maybe |
| 00:18:43 | solaris | hmmm |
| 00:19:02 | solaris | it's same with ON |
| 00:19:15 | LinusN | you need F1+ON |
| 00:19:19 | solaris | let's see.... F1 +ON.... |
| 00:19:26 | solaris | same |
| 00:19:32 | [IDC]Dragon | another thing: does it freeze with F3+On ? |
| 00:19:44 | solaris | when?? |
| 00:19:50 | solaris | after it starts? |
| 00:19:53 | | Join ricflair [0] (~ricflaira@dsl-217-155-202-181.zen.co.uk) |
| 00:20:05 | solaris | F1+ON and than f1+F3?? |
| 00:20:06 | [IDC]Dragon | power it off, then do F3+On |
| 00:20:13 | ricflair | hi all. i plugged my jukebox in and it doesnt charge :( nothing happens |
| 00:20:22 | LinusN | ricflair: how do you know? |
| 00:20:33 | solaris | ok, shutting down...... got it takes forever... archos firmware sucks |
| 00:20:53 | ricflair | linus, well i plug in the adapter and nothing happens |
| 00:21:08 | ricflair | if i press the on buton it flashes green for half a second or less |
| 00:21:09 | solaris | f3+on seems to at as just ON button |
| 00:21:20 | LinusN | ricflair: model type? |
| 00:21:28 | ricflair | jukebox recorder 20 |
| 00:21:44 | solaris | hmmm, it's not shutting off automatically |
| 00:21:46 | [IDC]Dragon | solaris: then you have the older bootloader? |
| 00:22:37 | LinusN | ricflair: and it used to work? |
| 00:22:40 | solaris | i don't know what u talking about. older bootloader? |
| 00:22:47 | ricflair | linus, i dont know, ive never ever used one before |
| 00:23:11 | amiconn | [IDC]Dragon, LinusN: My previous though was bullshit, but now I wonder if the MAS doesn't like to be interrupted while being halfway through a 30 byte burst? |
| 00:23:20 | LinusN | ricflair: sounds like it's broken |
| 00:23:28 | ricflair | shit |
| 00:23:32 | [IDC]Dragon | solaris: Once I urged people to reflash, to avoid a flat battery problem (which ricflair may have). |
| 00:23:41 | LinusN | amiconn: perhaps |
| 00:23:46 | ricflair | is there no way around it? |
| 00:23:55 | ricflair | can i use normal aa batterys in it to test? |
| 00:23:56 | solaris | with F3+ON from off, the green light comes on, i hear disk spinning but no red light indicating any reading. It does not auto. shut off. |
| 00:24:42 | [IDC]Dragon | solaris: then you may have the newer bootloader, which has my "Minimon" on F3+On. |
| 00:25:02 | LinusN | ricflair: i am not sure, the normal AA's have higher voltage |
| 00:25:28 | solaris | in other words??? |
| 00:25:29 | amiconn | So perhaps mp3_play_pause() shouldn't stop the transfer immediately by disabling TIE, but should stop the demand irq instead. |
| 00:25:34 | LinusN | [IDC]Dragon: but the drive shouldn't spin |
| 00:25:47 | ricflair | is there anything i can try at the moment |
| 00:26:13 | LinusN | ricflair: plugging in the charger should start the recorder |
| 00:26:30 | | Quit c0utta (Read error: 60 (Operation timed out)) |
| 00:26:40 | ricflair | do you think that mabey i have the charger in the wrong polaroty and thats why nothing happens? |
| 00:26:43 | [IDC]Dragon | solaris: this means you don't have to dothe UART boot mod, only the serial mod. |
| 00:26:50 | LinusN | ricflair: could be |
| 00:27:15 | LinusN | how dod you verify the polaroty? |
| 00:27:17 | ricflair | YEAH BABY YEAH |
| 00:27:21 | LinusN | ricflair: oh? |
| 00:27:23 | solaris | great!!, now point me to the right direction |
| 00:27:24 | ricflair | works, well starts up anyway |
| 00:27:38 | ricflair | HD register error |
| 00:27:45 | [IDC]Dragon | Minimon is sitting there and waiting for commands from the serial. This is why it seems to be frozen. |
| 00:28:10 | solaris | hmmm |
| 00:28:16 | LinusN | ricflair: ok, so it is broke, or you need to replace the batteries |
| 00:28:20 | LinusN | broken |
| 00:28:36 | [IDC]Dragon | Theoretically, you could even go without opening it, by just the remote pin. |
| 00:28:37 | | Join jkerman [0] (Dudewin32@jkhouse2.jvlnet.com) |
| 00:28:44 | ricflair | but turns on, i just get a hd register error, cant that be fixed? |
| 00:28:45 | solaris | lol |
| 00:28:48 | solaris | oh, yeah?? |
| 00:28:55 | LinusN | ricflair: that can be fixed |
| 00:29:04 | [IDC]Dragon | But this would mean "flashing in the dark", without feedback. |
| 00:29:14 | ricflair | Great, can i fix it now or do i need my usb cable(that i dont have yet) |
| 00:29:25 | LinusN | ricflair: try to squeeze the bumpers together |
| 00:29:44 | LinusN | in the direction of the batteries |
| 00:29:57 | | Quit AciD (Remote closed the connection) |
| 00:30:29 | ricflair | well that done somthing |
| 00:30:42 | ricflair | now says archos jukebox recorder - shutting down .... |
| 00:31:45 | LinusN | ricflair: ok, you need to open it up and resolder a few solder joints |
| 00:31:57 | LinusN | very common problem |
| 00:32:14 | LinusN | happens when you drop it, or if you change batteries often |
| 00:32:19 | ricflair | cool, as long as it can be fixed. How small are the solder joints |
| 00:32:20 | LinusN | a design flaw |
| 00:32:22 | [IDC]Dragon | amiconn: what was that with the 30 byte burst? |
| 00:32:29 | ricflair | just restarted it and it says battery charging |
| 00:32:59 | ricflair | should i just leave it charging? |
| 00:33:00 | amansinger | OK, IDC, I've made the text file. The issue is that it mentions the mary voice in all its articles. That is, it says "LANG_SOUND_SETTINGS|Mary|1 |
| 00:33:00 | amansinger | Sound Settings |
| 00:33:20 | LinusN | ricflair: http://www.gofurygo.de/webpost/pcb_ground.jpg |
| 00:33:22 | amansinger | " Will this effect the voice and, if so, what's the format to change the voice's name? |
| 00:33:34 | LinusN | ricflair: the green ones |
| 00:33:44 | ricflair | looks easy enough |
| 00:33:47 | ricflair | thanks for the help man |
| 00:33:54 | amiconn | [IDC]Dragon: The mas data transfers (both reading while recording and writing while playback) take place in 30 byte bursts, because that is the size of the dma buffers within the mas. |
| 00:33:55 | LinusN | you're welcome |
| 00:34:03 | [IDC]Dragon | amansinger: TA can do that, it even suggest this is you change the voice |
| 00:34:15 | [IDC]Dragon | is/if |
| 00:34:31 | [IDC]Dragon | amiconn; I know |
| 00:34:35 | ricflair | should i leave it as it is, plugged in and with the state "battery recharging" with 0:04 (just turned to 0:05) above the f5 and nothing else on the screen exept for the archos jukebox writing |
| 00:34:48 | ricflair | oh and a little battery in the top corner |
| 00:34:54 | LinusN | ricflair: do so |
| 00:34:58 | ricflair | as long as it is a common fault im not to upset |
| 00:35:02 | solaris | so, how can i get start on "flashing in the dark'??? |
| 00:35:02 | amansinger | Do you do that by a search and replace in the txt file or by the way through the TTA UI itself? |
| 00:35:04 | ricflair | how long should i leave it on charge for. |
| 00:35:16 | LinusN | ricflair: takes several hours |
| 00:35:20 | LinusN | leave it over night |
| 00:35:51 | [IDC]Dragon | solaris: I don't recommend it, and it would require canging my uart_boot program. |
| 00:35:53 | LinusN | i suggest you buy a set of NiMH batteries |
| 00:35:59 | amiconn | [IDC]Dragon: mp3_play_pause stops the transfer immediately (by disabling the transfer end interrupt of the serial i/f), so this may happen half-way through a 30 byte burst. Maybe the mas doesn't like that. |
| 00:36:01 | solaris | hmmm |
| 00:36:26 | [IDC]Dragon | amiconn: this would be very picky. |
| 00:36:38 | LinusN | amiconn: i think that sounds like a good theory |
| 00:36:45 | ricflair | linus i will, its just that i go on holiday this week and was hoping i could take it with me. Going to pick up a usb cable tomorrow from a store |
| 00:36:54 | ricflair | again, thanks very much for you genius advice :) |
| 00:37:01 | LinusN | but it wouldn't solve the glitch problem |
| 00:37:11 | [IDC]Dragon | how could we know the 30 byte are over? |
| 00:37:12 | ricflair | what glitch? |
| 00:37:28 | LinusN | ricflair: sorry, was talking to [IDC]Dragon and amiconn |
| 00:37:36 | ricflair | lol, sorry |
| 00:37:39 | solaris | ok, so.... can i return it to amazon? I don't have the original box |
| 00:37:45 | ricflair | im just really panicy. i hope can use this on holiday |
| 00:37:45 | | Quit silencer ("leaving") |
| 00:37:47 | [IDC]Dragon | I suggest we try the DMA pause/play first |
| 00:37:57 | | Join silencer [0] (~silencer@zen.via.ecp.fr) |
| 00:38:00 | amiconn | So, mp3_play_pause() should disable the demand interrupt only. The code then has to wait until the burst is over. |
| 00:38:39 | LinusN | amiconn: it won't solve the audio glitch prob easily |
| 00:39:41 | amiconn | Why? |
| 00:41:04 | LinusN | because you need to find the next frame boundary and queue the next clip very fast |
| 00:41:47 | amiconn | Maybe this is the point: If we try to do that within a 30 byte burst, we are too slow. |
| 00:42:08 | LinusN | hmmm |
| 00:42:23 | [IDC]Dragon | the DMA buffer can't be the only buffer the MAS has |
| 00:43:39 | amiconn | No, of course it has to buffer at least one complete frame. |
| 00:44:03 | amiconn | ..as well as decoded values from previous frames. |
| 00:44:40 | [IDC]Dragon | I just swapped CHCR3 and SCR0 usage |
| 00:44:54 | [IDC]Dragon | doesn't recover from pause |
| 00:45:03 | ricflair | does the lcd light stay on whilst its on charge? |
| 00:45:05 | LinusN | figured so |
| 00:45:13 | LinusN | ricflair: yes |
| 00:50:12 | [IDC]Dragon | the voice clipswitching however works, but no better than before. |
| 00:50:37 | LinusN | gotta sleep now |
| 00:50:45 | LinusN | cu around |
| 00:50:52 | [IDC]Dragon | probably it works because it start a new DMA |
| 00:50:53 | LinusN | ricflair: good luck |
| 00:50:55 | [IDC]Dragon | cu |
| 00:51:04 | amiconn | cu |
| 00:51:07 | [IDC]Dragon | versus the play code doesn't |
| 00:51:17 | | Part LinusN |
| 00:52:53 | [IDC]Dragon | disappointing |
| 00:54:23 | [IDC]Dragon | mattzz: how is your grayscale mandelbrot? |
| 00:58:02 | mattzz | I had a gray set already but than I changed code and now I dont get the buffer allocated any more. IllInstr .... |
| 00:58:03 | amansinger | IDC, what happens once I select the multi article multi file modes? I now have this text file and these modes selected. How do I make TTA speak these articles, if I may ask? |
| 01:00 |
| 01:02:04 | [IDC]Dragon | amansinger: there is a button to speak it all into files. |
| 01:02:17 | | Join c0utta [0] (~c0utta@158.cust44.nsw.dsl.ozemail.com.au) |
| 01:03:22 | [IDC]Dragon | under file options, you can specify the destination directory, set the speed to maximum, select wav. |
| 01:03:25 | amansinger | Ok, these will be wav files, correct? Do I then run wavtrim on them and then voicefont.exe? |
| 01:03:52 | amansinger | or rather, lame encode them and then run voicefont |
| 01:04:21 | [IDC]Dragon | many wav files, yes, My cmd file then does wavtrim them all, then Lame encode, finally voicefont. |
| 01:04:22 | amiconn | [IDC]Dragon: Try to insert the following line in mp3_play_pause as first line into the block after "else if (!paused && !play)": |
| 01:04:33 | amiconn | while(!(*((volatile unsigned char *)PBDR_ADDR) & 0x40)) ; |
| 01:05:04 | amiconn | this makes it work a little better imo, but please compare yourself. |
| 01:05:30 | [IDC]Dragon | have you tried? |
| 01:05:43 | amansinger | Right. Thanks. Anyhow, I'm off. It's been a very interesting two hours, watching the project take shape, so to speak. I have no doubt you'll be solving the swallowing problem with the clips. |
| 01:06:06 | amiconn | Yes, I have, but I cannot tell for sure if it helps. The problem doesn't disappear completely. |
| 01:06:30 | | Quit amansinger () |
| 01:07:27 | amiconn | perhaps the search for the next frame is simply too slow. |
| 01:08:25 | amiconn | (Although I think there should be enough time, since one frame is several milliseconds long. |
| 01:08:37 | Laurent_ | does anyone know about token packing here ? |
| 01:08:50 | Laurent_ | google was no help |
| 01:09:22 | Laurent_ | (almost no help) |
| 01:09:41 | [IDC]Dragon | amiconn: this works very well for me, no hickup yet |
| 01:10:37 | amiconn | I got some hiccups while testing. Basically this loops waits until the mas deactivates the EOD pin before stopping. |
| 01:10:41 | Laurent_ | no one ? ok, then time to bed ;) |
| 01:10:55 | Laurent_ | goodbye everyone |
| 01:11:12 | | Quit Laurent_ ("Download Gaim: http://gaim.sourceforge.net/") |
| 01:12:46 | [IDC]Dragon | amiconn: it seems to have the side effect that clips get barely aborted |
| 01:13:08 | amiconn | [IDC]Dragon: This loop is taken from the recording code; it should definitely be checked if it works on the player. |
| 01:14:14 | [IDC]Dragon | I should try a voice file with bit reservoir now. |
| 01:14:28 | amiconn | ? You get aborted clips where you shouldn't? |
| 01:14:49 | [IDC]Dragon | Rather the opposite |
| 01:15:13 | [IDC]Dragon | Most of the entries are now completely spoken, not aborted. |
| 01:15:52 | amiconn | My main "test case" is to alternate between "Sound settings" and "General settings". These get aborted if you switch over, although not always immediately. |
| 01:20:01 | [IDC]Dragon | we're on the right track, I'd say |
| 01:20:52 | mattzz | ok, we have a graubrot. |
| 01:21:00 | [IDC]Dragon | ;-) |
| 01:21:21 | [IDC]Dragon | or Grünbrot? |
| 01:22:03 | mattzz | how do you pronounce that? [g:m-bro:t]? |
| 01:22:25 | solaris | i just noticed, when i press either F3+on or ON, LCD light does not come on, only the green light and the disk spins but no red light indicating any reading |
| 01:22:45 | solaris | my room is getting dark with sun going down |
| 01:22:53 | [IDC]Dragon | solaris: that's good, yes |
| 01:23:09 | amiconn | [IDC]Dragon: Can you test on the player? |
| 01:23:17 | [IDC]Dragon | amiconn: no |
| 01:25:05 | [IDC]Dragon | the port pin should be the same according to the docs |
| 01:25:14 | amiconn | I guess it should work on the player since PB14 is EOD as well, but I would not count on it without testing. |
| 01:25:45 | amiconn | Too bad, Linus could test on the player... |
| 01:26:02 | [IDC]Dragon | he will, no hurry |
| 01:26:14 | solaris | is there anyway to force the archos to read ajz files? |
| 01:27:03 | [IDC]Dragon | solaris: you tried the Archos one now? |
| 01:27:09 | amiconn | mattzz: How fast is Graubrot? |
| 01:27:15 | solaris | yes, but it's same thing |
| 01:27:36 | [IDC]Dragon | does it take longer to boot? |
| 01:27:42 | solaris | hmmm |
| 01:27:58 | solaris | i thought it was about the same |
| 01:28:01 | mattzz | amiconn: pretty fast if you take into acount that every pixel is drawn now |
| 01:28:02 | [IDC]Dragon | (indicating the second one gets read from disk) |
| 01:28:36 | mattzz | amiconn: there is no stopwatch function included any more |
| 01:28:40 | [IDC]Dragon | mattzz: can we try it? |
| 01:28:57 | mattzz | uh, this is bad, bad code ;-) |
| 01:29:06 | mattzz | but - sure, yes |
| 01:29:10 | mattzz | mompls |
| 01:29:18 | [IDC]Dragon | no review today, I 'm too tired |
| 01:30:22 | mattzz | http://mattzz.dyndns.org/archos/graubrot.c |
| 01:30:51 | mattzz | this is my first shot - have mercy ;-) |
| 01:31:55 | mattzz | I haven't found a really nice colorset yet |
| 01:32:25 | [IDC]Dragon | I'd prefer green |
| 01:32:39 | mattzz | I _knew_ you would optimize it ;-) |
| 01:34:03 | [IDC]Dragon | looks interesting, yes |
| 01:34:14 | mattzz | still way too dark |
| 01:35:14 | mattzz | I want a screenshot of this in the manual!!!! |
| 01:35:47 | [IDC]Dragon | gotta go now |
| 01:35:58 | amiconn | cu Jörg. |
| 01:36:00 | | Quit [IDC]Dragon () |
| 01:39:15 | amiconn | mattzz: graubrot looks really nice. |
| 01:39:55 | mattzz | amiconn: thanks for your grayscale framework! |
| 01:40:48 | amiconn | Just some things I noticed: |
| 01:41:57 | amiconn | (1) Either alter or take out the comment at lines 724..725. The values are wrong. |
| 01:42:31 | amiconn | (2) You can take out gray_black_display() and gray_deferred_update() as well, since you don't use it. |
| 01:43:00 | mattzz | yup, agreed on both. |
| 01:43:24 | amiconn | (3) I would suggest that you try the following for choosing the brightness: |
| 01:44:08 | amiconn | if(n_iter > max_iter) |
| 01:44:16 | amiconn | brightness = 0; |
| 01:44:18 | amiconn | else |
| 01:45:31 | amiconn | brightness = 32 + 31 * (n_iter % 8); |
| 01:47:20 | mattzz | much better |
| 01:47:33 | amiconn | (just trying myself) |
| 01:47:58 | mattzz | though some contrast is missing where n_iter==max_iter |
| 01:48:04 | | Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)") |
| 01:50:18 | mattzz | brightness = 256 - (31 * (n_iter % 8)); |
| 01:50:50 | amiconn | should use 255... |
| 01:51:37 | amiconn | ...since 256 does return... but it works here, because the pixel is white anyway. |
| 01:52:10 | *** | Saving seen data "./dancer.seen" |
| 01:56:04 | solaris | now, i'm definetly sure it's not reading .ajz from F1+ON, i formatted the HD and i didn't put anything in. Still archos firmware |
| 01:57:30 | scott666 | i thought the point was to find out whether or not it would read it when there was actually something to read |
| 01:58:19 | amiconn | mattzz: Apparently using 28 bits for the fraction causes overflows in a few spots that make it look weird. I changed it locally to use 24 bits for the fraction and a baildout value of 9 (instead of 4). This looks really nice! |
| 01:58:57 | | Quit jkerman (Read error: 104 (Connection reset by peer)) |
| 01:58:58 | mattzz | why the bailout value of 9? |
| 01:59:25 | solaris | hmmm.... I'm just totally lost here... |
| 01:59:53 | solaris | in anycase, with original archos, it took 14 sec |
| 02:00 |
| 02:00:05 | solaris | and with rockbox it also took 14 sec |
| 02:00:22 | solaris | and without any .ajz, takes 14 sec |
| 02:01:42 | amiconn | mattzz: You have Xmin = -2.5. The first squaring operation already yields 6.25, so if you use 4, you are above it in the very first iteration. And, although using 9 is a bit slower, it is nearer to the default value other fractal generators use (16 iirc). |
| 02:02:07 | amiconn | Just try it, you will see what I mean. |
| 02:06:27 | mattzz | amiconn: you are definitively right with the overflow. stupid me. |
| 02:08:26 | mattzz | now, _that_ looks much nicer. I will try the other bailout value now. |
| 02:08:52 | amiconn | If you had a free button left, it would be possible to use it as a "status toggle" to display rendering time and max_iter at the top. |
| 02:10:39 | mattzz | yup, we need more keys! |
| 02:11:24 | amiconn | First keypress: place the grayscale overlay down one line (with gray_position_display() ), put out the data with snprintf() / lcd_puts() to line 0, then do gray_deferred_update() |
| 02:11:47 | amiconn | Second keypress: replace the grayscale overlay to (0, 0) |
| 02:12:13 | amiconn | The last line is not lost in the process, only hidden. |
| 02:12:26 | mattzz | who needs F3 anyway? we could use that one |
| 02:12:53 | * | mattzz thinks about a 24bit patch for mandelbrot.c |
| 02:14:41 | mattzz | we should stay with r_max=2 (i.e. bailout 4) |
| 02:14:53 | mattzz | http://mathworld.wolfram.com/MandelbrotSet.html |
| 02:15:08 | mattzz | Where did you see 16? |
| 02:15:24 | solaris | well, i'll catch you'ol tomo, good nite and thx |
| 02:15:38 | mattzz | night solaris |
| 02:15:44 | amiconn | Night. |
| 02:15:54 | solaris | ;) |
| 02:15:54 | | Quit solaris ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") |
| 02:20:38 | mattzz | amiconn: do you think I should put graubrot in the pathtracker? |
| 02:20:59 | mattzz | patchtracker |
| 02:21:06 | amiconn | mattzz: Most fractal generator programs I used had a default bailout of 16. |
| 02:21:19 | amiconn | (Just lkooked up some documentation) |
| 02:21:25 | amiconn | *looked |
| 02:22:34 | mattzz | Do you see a difference in the resulting image? I wasn't quite sure. |
| 02:26:02 | amiconn | Hmm. It looks quite different to me, even the first image. |
| 02:27:22 | mattzz | with 24 bit fraction we can use 16 as a bailout |
| 02:30:26 | amiconn | Just tried it - this gives overflow artefacts again. I guess that if we use a bailout of r, we have to reserve an integer part capable of holding up to R*R (signed) without overflow. 8 bit integer part is not enough is bailout = 16. |
| 02:30:54 | amiconn | *if |
| 02:32:42 | amiconn | This may be because if in one iteration it reaches a value just below the bailout, it becomes squared in the next, and this should not produce an overflow, otherwise you cannot reliably detect that it is above the bailout. |
| 02:33:33 | amiconn | If bailout = 9, integer values up to 81 should be possible, this just fits into 8 bit (+127 / -128) |
| 02:35:13 | mattzz | you convinced me ;-) |
| 02:38:04 | amiconn | Just tested bailout = 4 and a 6/26 split for integer/fraction, this is also artefact-free, which almost proves my theory. |
| 02:38:30 | amiconn | bailout = 4 looks not as good in the outer area of the starting image though |
| 02:38:36 | ze | you can't prove a theory, only gain support for it or disprove it |
| 02:38:37 | ze | heh |
| 02:39:13 | mattzz | amiconn: ok, that should be it |
| 02:39:34 | amiconn | What should be what? |
| 02:39:54 | mattzz | 6/26 and 9 |
| 02:40:25 | amiconn | No, either 8/24 and 9, or 6/26 and 4, otherwise -> overflow artefacts. |
| 02:40:38 | mattzz | argh - ignore me ;-) |
| 02:40:45 | ricflair | hi all. just getting this going, is it normal that the jukebox recorder makes a rattle stylenoise from the hd when it plays a song or when it browses? |
| 02:40:49 | mattzz | 2 tired |
| 02:43:46 | amiconn | mattzz: btw, I learned something from your code - it is sufficient to comment out a prototype to prevent the function from being compiled in if it is not used. I didn't know that. |
| 02:44:23 | mattzz | ;-) |
| 02:47:21 | amiconn | If someone has generated a nice looking mandelbrot picture, we would need a way to save it to disk. Perhaps it could generate a .rvf video from a mandelbrot zoom sequence ;-) |
| 02:48:35 | mattzz | yep, there's a lot of work left to do... |
| 02:49:05 | mattzz | guess, I will have to sleep a bit... |
| 02:49:09 | mattzz | c u amiconn |
| 02:49:25 | amiconn | cu and good night. |
| 02:49:34 | | Quit mattzz ("Client exiting") |
| 02:50:00 | | Part amiconn |
| 03:00 |
| 03:16:19 | | Join diddystar5 [0] (lee@IC87.library.oregonstate.edu) |
| 03:16:29 | scott666 | hey diddy |
| 03:16:39 | diddystar5 | hey |
| 03:23:12 | | Join jkerman [0] (~jkerman@jkhouse2.jvlnet.com) |
| 03:26:27 | diddystar5 | brb |
| 03:26:28 | | Quit diddystar5 ("Leaving") |
| 03:30:44 | | Join diddystar5 [0] (~lee@IC87.library.oregonstate.edu) |
| 03:52:12 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:27:20 | | Join monkey [0] (monkey@1Cust172.tnt2.mount-vernon.wa.da.uu.net) |
| 04:28:58 | monkey | can anyone here tell me a n00b definition of what the "mandelbrot" and "grey scale" projects are about? |
| 04:29:29 | scott666 | have you seen the video plugin? |
| 04:29:44 | scott666 | .rvfs and all that |
| 04:29:54 | monkey | i used it |
| 04:30:01 | monkey | ? |
| 04:30:14 | scott666 | what |
| 04:30:15 | scott666 | ? |
| 04:31:07 | monkey | oh i just yah i've used rvf but how does it relaste to mandelbrot and greyscale |
| 04:31:15 | monkey | i just meant* |
| 04:32:01 | | Join lostuser [0] (~jirc@cpe-24-165-61-18.hawaii.rr.com) |
| 04:32:08 | lostuser | hello |
| 04:32:27 | diddystar5 | hi |
| 04:33:04 | lostuser | does any1 kno anything about converting avi to rvf? |
| 04:33:30 | scott666 | http://rockbox.haxx.se/docs/ |
| 04:34:11 | scott666 | monkey: theyre working on a way to use the same greyscale as in the video plugin in regular rockbox |
| 04:34:23 | lostuser | no the thing is that when i convert my avi's the video is crap, it is only a bunch of lines |
| 04:34:37 | scott666 | or other plugins−−like games |
| 04:35:00 | scott666 | do you re-size them to 112x64? |
| 04:35:07 | lostuser | yes |
| 04:35:12 | scott666 | uncompressed? |
| 04:35:17 | lostuser | of course |
| 04:35:33 | scott666 | then i dunno what to tell you |
| 04:35:44 | monkey | scott666: and mandelbrot? |
| 04:35:52 | lostuser | do you know anyone who might be able to help me? |
| 04:35:52 | scott666 | i have no idea |
| 04:36:00 | scott666 | its something on the same topic, but damned if i know what |
| 04:36:08 | scott666 | and ive sat in on half the discussions about it |
| 04:36:24 | scott666 | lostuser: what do you make videos with? the UI? |
| 04:36:33 | monkey | yah i've lurked while its on but dont know what its for |
| 04:36:33 | scott666 | *GUI |
| 04:37:06 | scott666 | i get the feeling its something german, as i know at least 2 of them are |
| 04:37:12 | | Quit facted (Read error: 54 (Connection reset by peer)) |
| 04:37:13 | scott666 | but im not sure at all |
| 04:37:36 | lostuser | yes |
| 04:37:56 | lostuser | i use the GUI |
| 04:38:08 | scott666 | i dunno |
| 04:38:21 | scott666 | ask on the mailing list? read the mailing list archives of the past month or so? |
| 04:38:58 | scott666 | trasnlator doesnt like mandlebrot, there goes that idea |
| 04:38:58 | scott666 | lol |
| 04:39:08 | monkey | scott666: ever heard anything about "color" images from b&w images? |
| 04:39:43 | scott666 | we have green... |
| 04:39:49 | diddystar5 | i have only used the command line |
| 04:40:05 | monkey | you mean green from the LEDs? |
| 04:40:12 | diddystar5 | i have to go |
| 04:40:15 | diddystar5 | see you guys |
| 04:40:51 | | Quit diddystar5 ("Leaving") |
| 04:41:03 | scott666 | yes |
| 04:41:05 | scott666 | lol |
| 04:43:00 | monkey | nah i was thinking it might be possible to convey color by manipulating b&w images |
| 04:46:14 | scott666 | well...if anyone can do it, jörg can |
| 04:48:23 | monkey | i will study it some more and then maybe i will bring to him |
| 04:48:34 | monkey | bring it up* |
| 04:51:24 | lostuser | HEY GUESS WHAT GUYS, I SOLVED MY VIDEO PROBLEM!!! YAY !!!!!! |
| 04:56:06 | scott666 | lol |
| 04:56:09 | lostuser | now i won't be botherin y'all. i'll see ya later. thanks fo all the help again...kinda. btw my problem was the FPS rate, it was too high, so iowered it to 10... until we meet again. err um or until i get another problem. later |
| 04:56:27 | scott666 | 10? |
| 04:56:39 | lostuser | frames per sec |
| 04:56:56 | scott666 | FPS rates should be rate of the video youre feeding it, and ~70 output |
| 04:57:27 | lostuser | err well i changed that thingy and my videos worked. |
| 04:57:49 | scott666 | hmmm |
| 04:57:51 | scott666 | no audio? |
| 05:00 |
| 05:00:41 | | Join Unknown [0] (~c0utta@158.cust44.nsw.dsl.ozemail.com.au) |
| 05:01:10 | lostuser | no i have audio |
| 05:01:43 | scott666 | and it's snyced right? |
| 05:02:02 | | Quit c0utta (Read error: 60 (Operation timed out)) |
| 05:02:03 | | Nick Unknown is now known as c0utta (~c0utta@158.cust44.nsw.dsl.ozemail.com.au) |
| 05:52:16 | *** | Saving seen data "./dancer.seen" |
| 05:54:54 | | Quit scott666 ("i'll be back...eventually...") |
| 05:54:54 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
| 05:56:55 | | Quit lostuser (Read error: 60 (Operation timed out)) |
| 06:00 |
| 06:23:50 | | Quit monkey () |
| 06:29:59 | | Join monkey [0] (monkey@1Cust172.tnt2.mount-vernon.wa.da.uu.net) |
| 06:43:13 | | Quit monkey () |
| 07:00 |
| 07:14:49 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 07:18:13 | | Join elinenbe [0] (trilluser@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 07:23:52 | | Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) |
| 07:52:19 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:04:22 | | Join LinusN [200] (~linus@labb.contactor.se) |
| 08:27:15 | | Join amiconn [0] (~jens@pD95D1ABC.dip.t-dialin.net) |
| 08:33:35 | | Join [IDC]Dragon [0] (~idc-drago@pD9E34A37.dip.t-dialin.net) |
| 08:33:55 | [IDC]Dragon | Hey, everybody is up so early! |
| 08:34:08 | dwihno | Way! |
| 08:41:23 | amiconn | Hi |
| 08:50:17 | LinusN | any clues about the mp3 playback issues? |
| 08:50:48 | [IDC]Dragon | have you read the log? |
| 08:50:52 | LinusN | yup |
| 08:51:08 | [IDC]Dragon | no more than that, so far |
| 08:51:44 | LinusN | ok |
| 08:51:48 | [IDC]Dragon | the wait loop fixes it pretty well, but makes most clips run completely |
| 08:52:04 | LinusN | weird |
| 08:54:58 | amiconn | [IDC]Dragon: The loop may not catch every gap where EOD is inactive, because it is relatively slow. I will try an asm version that will react faster. |
| 08:55:26 | | Join mattzz [0] (~c2af7556@c231002.adsl.hansenet.de) |
| 08:58:35 | amiconn | (To be more preice, the loop may not be too slow, but _if_ the loop detects a gap, the serial has to be stopped very fast) |
| 08:58:40 | amiconn | *precise |
| 09:00 |
| 09:00:04 | * | dwihno sighs... No stores in town are carrying MDR EX71's :( |
| 09:00:10 | LinusN | amiconn: couldn't it be done in the irq? |
| 09:04:42 | [IDC]Dragon | afk |
| 09:05:24 | LinusN | with a pause_pending flag |
| 09:05:33 | amiconn | Good point - this would be a much cleaner implementation. |
| 09:07:23 | amiconn | I think it had to be placed in the stop demand irq, but I wonder if this is possible. I know that the 3587 uses irqs for both start and stop, but the 3507 only for one of these actions. |
| 09:07:36 | LinusN | exactly |
| 09:07:48 | LinusN | however, the start irq knows if the dma is stopped |
| 09:08:08 | LinusN | if pause_pending and dma is stopped, then never start it |
| 09:08:46 | amiconn | Another thing has to be taken care of - if mp3_play_pause only sets the flag, it becomes an asynchronous operation. |
| 09:09:12 | LinusN | yes, so the wait loop has to stay, in a different shape |
| 09:09:26 | LinusN | like waiting for pause_pending to be false again |
| 09:09:38 | LinusN | and the irq sets it to false |
| 09:11:27 | amiconn | Yes, and it has to be done in the stop demand irq, so we have more time to have the new data ready when the mas starts demanding again. |
| 09:12:38 | | Quit AciD (Read error: 54 (Connection reset by peer)) |
| 09:13:15 | LinusN | amiconn: good point |
| 09:14:29 | mattzz | cygwin compile of the W32 simulator woes (good morning, folx) |
| 09:14:40 | LinusN | mattzz: morn |
| 09:14:42 | amiconn | One thing I would like to know: Does the start/stop demand irq occur once for every 30 byte burst, or once for every frame? |
| 09:15:04 | LinusN | amiconn: don't know, i guess i'll have to measure |
| 09:15:46 | amiconn | (I suppose it is the former) |
| 09:15:53 | LinusN | me too |
| 09:16:55 | mattzz | ../../firmware/include/dir.h:77: error: conflicting types for `rmdir' |
| 09:16:55 | mattzz | /usr/i686-pc-mingw32/include/io.h:153: error: previous declaration of `rmdir' |
| 09:17:16 | LinusN | mattzz: are you using the latest cvs? |
| 09:17:26 | mattzz | latest tarball |
| 09:17:32 | LinusN | ah, sorry |
| 09:17:44 | LinusN | yes, the win32 sim is unable to compile atm |
| 09:18:19 | mattzz | ok, no prob. the normal build is the important one ;-) |
| 09:18:21 | LinusN | i have added the rmdir() function, and i'm waiting for someone to fix the win32 sim version |
| 09:19:16 | LinusN | mattzz: that person may be you :-) |
| 09:19:22 | mattzz | LinusN: yeah, rmdir is part of io.h, too |
| 09:19:29 | * | mattzz is _no_ w32 wizzard |
| 09:20:04 | LinusN | actually, since it's cygwin, rmdir() is posix iirc |
| 09:20:20 | LinusN | so it should be relatively simple to fix |
| 09:20:21 | * | mattzz is _no_ wizzard at all |
| 09:20:44 | mattzz | I will give it a try |
| 09:24:15 | | Nick amiconn is now known as amiconn|away (~jens@pD95D1ABC.dip.t-dialin.net) |
| 09:24:16 | dwihno | Are there any standard ways to truncate a file? |
| 09:24:22 | dwihno | speaking of standards... :) |
| 09:24:50 | LinusN | open("name", O_WRONLY|O_TRUNC); |
| 09:25:27 | dwihno | Sorry. I ment truncating a file, let's say I want to cut a file from 700 bytes to 500. |
| 09:28:06 | LinusN | programmatically or using a ready-made tool? |
| 09:28:33 | LinusN | in linux/unix, dd is your friend |
| 09:31:26 | dwihno | programmatically :) dd is everybodys friend \o/ |
| 09:33:50 | | Join amiconn [0] (~jens@pD9E7DF9E.dip.t-dialin.net) |
| 09:39:14 | LinusN | dwihno: truncate() or ftruncate() will do what you want |
| 09:39:41 | dwihno | ah |
| 09:39:44 | dwihno | it's standard? |
| 09:39:57 | LinusN | posix methinks |
| 09:40:43 | LinusN | ftruncate is the safest bet |
| 09:40:52 | dwihno | hm |
| 09:40:59 | * | dwihno checks the mingw include stuff |
| 09:41:25 | dwihno | nah |
| 09:41:26 | dwihno | not there. |
| 09:41:50 | dwihno | I guess I have to do a windows hack as well. |
| 09:42:40 | LinusN | booh |
| 09:43:17 | dwihno | Yeah. Booh! |
| 09:44:10 | dwihno | djgpp has ftruncate though |
| 09:44:17 | LinusN | you could try #define ftruncate chsize |
| 09:45:08 | dwihno | hmm |
| 09:45:12 | dwihno | uses file descriptors |
| 09:45:20 | dwihno | chsize (int, long ); |
| 09:45:27 | LinusN | the cygwin docs claims that ftruncate is supported |
| 09:46:24 | dwihno | ah |
| 09:46:31 | dwihno | well, mingw and cygwin are not friends then ;) |
| 09:46:41 | LinusN | #include <unistd.h> |
| 09:51:50 | | Quit amiconn|away (Read error: 110 (Connection timed out)) |
| 09:51:50 | | Nick amiconn is now known as amiconn|away (~jens@pD9E7DF9E.dip.t-dialin.net) |
| 09:52:20 | *** | Saving seen data "./dancer.seen" |
| 09:56:35 | | Nick mattzz is now known as mattzz|meeting (~c2af7556@c231002.adsl.hansenet.de) |
| 09:57:35 | | Quit [IDC]Dragon () |
| 10:00 |
| 10:28:21 | | Nick amiconn|away is now known as amiconn|work (~jens@pD9E7DF9E.dip.t-dialin.net) |
| 10:39:44 | BC | mornin' |
| 10:49:45 | | Join AEnertia [0] (~aenertia@202.0.41.163) |
| 10:50:39 | AEnertia | Hi people, I have read the faq, but I'm going to ask a question about the av320 (which I know is unsupported). |
| 10:51:45 | * | dwihno holds his breath |
| 10:51:45 | | Nick AEnertia is now known as `Nert (~aenertia@202.0.41.163) |
| 10:52:29 | | Nick `Nert is now known as AEnertia (~aenertia@202.0.41.163) |
| 10:53:17 | AEnertia | are there any projects to alter/add functionality to it? (the av3x0 series) |
| 10:54:47 | AEnertia | I have googled but come up blank. |
| 10:54:55 | BC | I'm lost with all the different units now - what is AVOS(.sourceofrge) for? |
| 10:56:09 | AEnertia | thanx... that's just what I was looking for |
| 10:56:18 | AEnertia | It's not ranked on any of the google searches I tried? |
| 10:56:42 | AEnertia | perhaps someone should add that to the faq on the rockbox site |
| 10:59:12 | c0utta | AEnertia: /join avos |
| 11:00 |
| 11:12:37 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 11:27:25 | ricflair | hi all |
| 11:28:03 | ricflair | is it normal that the jukebox recorder makes a ticking or rattle style noise evry now and again (the unit itself, not sound throug the eaphones) |
| 11:28:08 | BC | hi 2u2 |
| 11:28:28 | BC | it's the hdd - mine does it a fair amount |
| 11:28:43 | ricflair | cool, i was worried mine is broken |
| 11:28:58 | BC | panic over :) |
| 11:29:04 | ricflair | im getting my usb cable today, is it easy to transfer music accross and instal rockbox? |
| 11:29:15 | LinusN | very easy |
| 11:29:17 | dwihno | simple as pie \o/ |
| 11:29:18 | BC | yes drag'n'drop |
| 11:29:33 | BC | 3.141527errrrrrr |
| 11:30:17 | ricflair | excellent |
| 11:30:18 | ricflair | cant wait |
| 11:30:51 | ricflair | i had it on charge since 12 last night and my wife unplugged it :( about an hour ago, do you think it will have charged ok? |
| 11:31:16 | BC | yeah :) |
| 11:31:41 | BC | best bet is pop the batteries out CAREFULLY and give them two or three cycles in a proper recharger |
| 11:33:04 | ricflair | i dont have a propper recharger, should i buy one? how much. and is it not voiding my warranty if i take em out |
| 11:33:53 | BC | warranty? |
| 11:34:03 | BC | you got a new unit with no usb cable? |
| 11:34:29 | ricflair | no, its not new , but its still under warranty |
| 11:34:36 | BC | also thinks ...what unit JBR v1, v2, fmr??? |
| 11:34:53 | ricflair | jukebox recorder 20 |
| 11:35:14 | ricflair | with firmware 1.26 on |
| 11:35:25 | BC | v1 or v2? |
| 11:36:12 | LinusN | 1.26 sounds like a v1 to me |
| 11:36:21 | BC | good point |
| 11:36:35 | BC | then you're safe with replacing the batteries :) |
| 11:36:52 | ricflair | ok, cool. |
| 11:36:53 | BC | just BE GENTLE because of a design fault |
| 11:37:00 | dwihno | The v1 is so good. |
| 11:37:02 | dwihno | Yum. |
| 11:37:48 | ricflair | whats the design fault. |
| 11:37:53 | ricflair | should i have not baught it? |
| 11:38:10 | BC | v1's are by far and away the best units |
| 11:38:21 | ricflair | seriously? |
| 11:38:25 | BC | imho |
| 11:38:49 | amiconn|work | I agree. |
| 11:38:49 | BC | my only complaint is that I struck unlucky and cannot flash |
| 11:39:01 | ricflair | oooh, i hope i can |
| 11:39:12 | ricflair | what is the deisgn fault |
| 11:39:23 | BC | the battery spring is held on with solder |
| 11:39:39 | dwihno | BC: the boot time with a flashed unit is so goddamn fast! :D |
| 11:39:45 | BC | :P |
| 11:40:02 | ricflair | bc, is that the problem that you can fix easilly? |
| 11:40:15 | ricflair | i think linus told me about tha tyesterday |
| 11:40:23 | BC | if the need ever arises Linus did a page on it |
| 11:40:49 | ricflair | well evry now and again, when i plug it in, it says shutting down |
| 11:41:23 | BC | remember you CANNOT run the unit from the mains - it ONLY runs from batteries |
| 11:41:52 | BC | god knows why they did that! |
| 11:41:59 | ricflair | yeah, i mean when i plugged it in to charge it up |
| 11:43:13 | BC | but even when plugged it is still dependant on the battery connections |
| 11:43:26 | ricflair | right, so i could have that problem then |
| 11:43:29 | BC | charger->batteries->jukebox |
| 11:43:57 | BC | there is no 'usual' "when plugged the batteries are bypassed" thing going on |
| 11:44:55 | BC | also note that when the batteries are totally dead, it take about 20-30mins of charging before the unit will have enough power to fire up the hdd |
| 11:45:35 | dwihno | indeed |
| 11:48:08 | BC | s/unit/batteries/ |
| 11:52:24 | *** | Saving seen data "./dancer.seen" |
| 11:56:44 | ricflair | cool, thank sofr the info |
| 11:57:00 | ricflair | are they ok to use as usb harddisks aswell |
| 12:00 |
| 12:00:14 | ricflair | i hope i can install rockbox later on tonight when i get my cable |
| 12:01:50 | LinusN | yes, it's essentially a usb hard disk with mp3 playback capability |
| 12:04:48 | ricflair | so i can store anything on the drive? thats cool. |
| 12:11:23 | | Quit c0utta (Read error: 60 (Operation timed out)) |
| 12:14:31 | | Join monkey [0] (monkey@1Cust93.tnt1.mount-vernon.wa.da.uu.net) |
| 12:16:37 | | Join c0utta [0] (~c0utta@92.cust45.nsw.dsl.ozemail.com.au) |
| 12:29:52 | | Join Laurent1 [0] (~laurent@dyn-83-152-147-175.ppp.tiscali.fr) |
| 12:30:19 | Laurent1 | Hi |
| 12:33:34 | | Join pfavr [0] (pfavr@t3o61p102.telia.com) |
| 12:33:38 | BC | ho |
| 12:34:08 | | Quit Laurent1 ("Download Gaim: http://gaim.sourceforge.net/") |
| 12:34:29 | | Join LaurentG [0] (~laurent@dyn-83-152-147-175.ppp.tiscali.fr) |
| 12:34:34 | dwihno | Anyone tested the koss "plug" earbuds? |
| 12:34:38 | LaurentG | back |
| 12:34:55 | BC | I must stop typing "ho" - one day someone is going to miss the reference |
| 12:35:05 | BC | koss headphones are nice |
| 12:35:10 | c0utta | dwihno: yes, i've got a set |
| 12:35:48 | c0utta | they're good |
| 12:36:37 | LaurentG | BC: I missed the reference indeed ;) |
| 12:36:46 | BC | 7-Dwarves |
| 12:36:53 | LaurentG | ah.... |
| 12:36:55 | LaurentG | :) |
| 12:37:11 | BC | as opposed to american slang |
| 12:37:30 | BC | as in "geddin' it on wid mi ho's" |
| 12:38:06 | LaurentG | BC: "getting it on with my ??" |
| 12:38:23 | BC | ladies-of-ill-repute |
| 12:38:35 | LaurentG | huhuh |
| 12:38:41 | BC | LOL |
| 12:39:52 | dwihno | c0utta: Just _how_ good are they then?: ) |
| 12:40:12 | BC | I feel a monty python joke approaching... |
| 12:40:29 | BC | "how much do you hate the romans?" |
| 12:40:33 | LaurentG | so, let's get back on technical tracks |
| 12:40:42 | c0utta | a lot |
| 12:40:44 | LaurentG | does anyone here know about token packing ? |
| 12:40:47 | c0utta | right, you're in |
| 12:40:48 | BC | you're in then |
| 12:40:53 | BC | LOL |
| 12:41:02 | c0utta | the only people we ate more than the romans.. |
| 12:41:19 | c0utta | dwihno: they've got good base response |
| 12:41:24 | * | BC shuts up in fear of picking the wrong group |
| 12:41:51 | BC | LaurentG: I know of tokens and of packing but never heard the two together before |
| 12:42:40 | c0utta | dwihno: i like the fact the "the plug" blocks out surrounding noise |
| 12:45:17 | LinusN | LaurentG: i haven't heard of anything called "token packing" before |
| 12:46:12 | BC | surely the point of a token is that it is so small it does not need packing |
| 12:48:22 | dwihno | c0utta: I'm in the need of new plugs. I'm considering the Sony EX71 (had the EX70 earlier, but lost them) and perhaps the Koss plug might be a viable choice. |
| 12:49:18 | c0utta | the koss are cheaper than the sony's, correct ? |
| 12:49:53 | dwihno | Yes. |
| 12:55:48 | ricflair | is the archos multimedia player better or worse than the jukebox recorder |
| 12:56:04 | pfavr | dwihno, I have a pair of closed headphones (not plugs), the Sennheiser HD-25 - although not that comfortable (hot ears) I'll recommend them because of the exceptional sound, but be sure to get the 70ohms version (they have a semi-prof version at half the price but it sounds bad). |
| 12:57:16 | BC | ric: based on what - it is more "different" than better or worse |
| 12:57:40 | ricflair | i just read that the battery life isnt that good on it# |
| 12:58:13 | BC | if that is your point of comparison, then you kinda have your answer :) |
| 12:58:36 | BC | but you're not going to be playing mpeg-4 video in colour on your jukebox |
| 12:59:03 | ricflair | sure |
| 12:59:07 | LaurentG | LinusN: i've found two pages about it on google but they contain only source code, no explanation of any kind... I wonder where Bjorn got this term |
| 13:00 |
| 13:00:08 | BC | as Enlish is not his first language maybe the term was descriptive rather than technical? |
| 13:00:54 | LaurentG | BC: that's possible |
| 13:01:14 | | Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net) |
| 13:01:19 | BC | What is it in reference to? |
| 13:02:08 | LaurentG | BC : about the multimedia models, he said that he found the firmware was compressed with "token packing" |
| 13:02:28 | BC | mmmmmm |
| 13:02:52 | LaurentG | BC: it seems a simple mechanism, since most plain text in the decrypted firmware appears nearly undisturbed |
| 13:03:09 | LaurentG | which Bjorn confirms in his post about the multimedia models firmware |
| 13:03:48 | BC | "most" ...what IS "disturbed"? |
| 13:03:58 | BC | recurrent words? |
| 13:05:50 | LaurentG | BC: wait til I get a sample |
| 13:05:57 | BC | ok |
| 13:06:21 | BC | " a custom token packing algorithm" |
| 13:06:42 | BC | i think that is descriptive |
| 13:08:28 | mattzz|meeting | hm, anybody here who can explain firmware/include/dir.h ? |
| 13:08:35 | | Nick mattzz|meeting is now known as mattzz (~c2af7556@c231002.adsl.hansenet.de) |
| 13:08:35 | LinusN | i can |
| 13:09:31 | BC | LOL |
| 13:09:34 | BC | ouch! |
| 13:09:36 | mattzz | argh, plugin compile with cygwin woes also... |
| 13:09:55 | mattzz | duucc.s: Assembler messages: |
| 13:09:55 | mattzz | duucc.s:2: Warning: Line numbers must be positive; line number 0 rejected. |
| 13:10:26 | mattzz | using the toolchain from rockbox.haxx.se |
| 13:10:40 | mattzz | but that seems to be another prob |
| 13:10:45 | BC | Matzz, what OS do you have? |
| 13:10:49 | mattzz | w2k |
| 13:11:02 | BC | I have a more updated dev-kit for that os |
| 13:11:27 | mattzz | worth a new release? |
| 13:11:53 | BC | mmmm, not an "official" one because there is still an issue with 98 that I can't solve :( |
| 13:11:56 | LaurentG | damn, I have no decrypted firmware anymore ? |
| 13:12:03 | BC | oop |
| 13:13:41 | [IDC]Dragon | LinusN: I made an experiment for the mp3 clips: I don't search for frame boundary, just throw the whol rest back in. |
| 13:13:58 | LinusN | huh? |
| 13:14:00 | LaurentG | ok, can build one |
| 13:14:11 | [IDC]Dragon | So the data should be undisturbed. |
| 13:14:30 | [IDC]Dragon | (just to test is we have a performance problem or else) |
| 13:14:39 | [IDC]Dragon | is/if |
| 13:15:22 | [IDC]Dragon | are you with me? |
| 13:15:28 | LaurentG | Here's a sample of the "packed" data : |
| 13:15:32 | LinusN | throw back in? performance problem? |
| 13:15:41 | LaurentG | ff20 5570 6772 6164 65ff 2050 726f 7465 . Upgrade. Prote |
| 13:15:50 | LaurentG | 6374 ff65 6420 4a75 6b65 42ff 6f78 2020 ct.ed JukeB.ox |
| 13:16:03 | [IDC]Dragon | (seems not) |
| 13:16:11 | LaurentG | as you see, the text bits are almost "plain" |
| 13:16:31 | LaurentG | but every few bytes, there's a code byte probably |
| 13:16:32 | BC | what a weiirrdd text format |
| 13:16:37 | [IDC]Dragon | ompl |
| 13:16:44 | | Quit [IDC]Dragon ("no fate but what we make (EOF)") |
| 13:17:15 | BC | 8bytes+FF, repeat |
| 13:17:41 | BC | a NINE byte cycle!!?? |
| 13:18:07 | BC | that has GOT to be a clue - who would want their data constantly moving off-boundry |
| 13:18:27 | BC | maybe that FF is a PREfix |
| 13:18:35 | LaurentG | BC: it's not text, it's the text parts of the firmware code |
| 13:19:08 | BC | lol - yes |
| 13:19:26 | BC | I've a pretty solid background in hex-dump world :) |
| 13:22:41 | BC | Maybe I do not get what it is that you are trying to ascertain? |
| 13:26:02 | | Quit monkey () |
| 13:26:03 | LaurentG | huh ? |
| 13:26:18 | BC | what are you trying to do? |
| 13:26:50 | LaurentG | BC: i'm looking forward to understand the packing algorithm for the firmware ;) |
| 13:27:19 | LaurentG | BC: and I do not doubt your skills ;) |
| 13:27:37 | BC | my first guess is that it reads 9 bytes at a time, the first byte will indicate the packet type, the latter 8 will be the data |
| 13:27:42 | BC | ff means, raw data |
| 13:28:04 | LaurentG | I think it's a good guess |
| 13:28:14 | * | BC overstates the GUESSwork nature of his words |
| 13:29:09 | LaurentG | e43c 03ff 87e6 3031 3233 3435 ff36 3738 .<....012345.678 |
| 13:29:19 | LaurentG | 3941 4243 44ff 4546 4e6f 2063 6865 df63 9ABCD.EFNo che.c |
| 13:29:26 | LaurentG | 6b73 756d a813 2e2e ff2e 0000 5352 4c00 ksum........SRL. |
| 13:29:54 | LaurentG | the token + 8 data bytes seems to fit that part too |
| 13:30:00 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 13:30:10 | LaurentG | insert "pattern" after "bytes" ;) |
| 13:30:42 | BC | :) |
| 13:30:54 | BC | now to start following it back |
| 13:31:00 | BC | can you get a RAM dump? |
| 13:31:33 | LaurentG | RAM ? straight from the gmini ? i'm affraid not |
| 13:32:51 | BC | okay |
| 13:33:20 | LaurentG | but there's a lot of text within the firmware, so this should help guessing all possible "packing" codes |
| 13:34:24 | BC | are there any garbage packets in amongst the text? |
| 13:34:29 | LaurentG | at the end of the 2nd line above, you can see a "df" instead of a "ff" |
| 13:35:13 | LaurentG | BC: do you mean "large parts of non text" ? |
| 13:35:18 | BC | whats the next line? |
| 13:35:19 | BC | no |
| 13:35:40 | BC | small bits of data in amongst the text |
| 13:36:00 | LaurentG | ok, that's what I meant ;) there are a lot of them |
| 13:36:08 | LaurentG | let me flood this channel and show you ;) |
| 13:36:37 | LaurentG | 00001bb0: d123 3a20 7374 6172 749f 2073 6f66 748a .#: start. soft. |
| 13:36:37 | LaurentG | 00001bc0: 232c 3564 ff69 7370 6c61 7920 6fcb 7074 #,5d.isplay o.pt |
| 13:36:37 | LaurentG | 00001bd0: ad20 7385 2244 3675 6dff 7020 6d65 6d6f . s."D6um.p memo |
| 13:36:37 | DBUG | Enqueued KICK LaurentG |
| 13:36:37 | LaurentG | 00001be0: 7279 af00 4572 7211 2055 c411 69ff 6e67 ry..Err. U..i.ng |
| 13:36:37 | LaurentG | 00001bf0: 0000 4461 7461 bf20 4f4b 0066 64a8 106b ..Data. OK.fd..k |
| 13:36:54 | BC | feel free to dcc or im me if it is appropriate |
| 13:37:06 | LaurentG | (BTW I can send the file to anyone wants it) |
| 13:37:10 | LaurentG | :) |
| 13:37:22 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 13:37:22 | * | LaurentG wonders if gaim supports dcc ? |
| 13:38:30 | | Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net) |
| 13:38:50 | LaurentG | BC: are you receiving anything ? |
| 13:38:56 | BC | nope |
| 13:39:02 | [IDC]Dragon | LinusN: sorry |
| 13:39:31 | LaurentG | BC : now ? |
| 13:39:37 | BC | no |
| 13:39:53 | LaurentG | success rate : 0/2 -> plain success |
| 13:40:03 | LaurentG | ok, I'll put this on the web instead |
| 13:40:12 | [IDC]Dragon | in my shutup() function, I pause and search forward for the frame end. The missing part is re-scheduled. |
| 13:40:50 | [IDC]Dragon | For a test, I did not search, just re-scheduled the whole rest, to test if it's seamless. |
| 13:41:10 | [IDC]Dragon | Turns out it isn't. |
| 13:41:31 | [IDC]Dragon | So I need to revise that part first. |
| 13:43:59 | | Quit [IDC]Dragon ("no fate but what we make (EOF)") |
| 13:44:14 | BC | [12:39] *** Malformed DCC SEND request from laurentg, ignoring. |
| 13:44:24 | BC | sorry missed that |
| 13:44:33 | LaurentG | BC : no prob |
| 13:44:50 | LaurentG | If I can remember what my home page URL is you'll get it on the web soon ;) |
| 13:46:26 | LaurentG | here it is : http://lgiroud.chez.tiscali.fr/gmini/1.20_ccod.unxored |
| 13:49:48 | BC | offset a9a0 |
| 13:49:49 | BC | LOL |
| 13:50:22 | LaurentG | huh ? |
| 13:50:45 | | Quit AEnertia (Remote closed the connection) |
| 13:50:51 | BC | maybe it is my font |
| 13:51:18 | BC | the third character on my screen is a mathematical "n" |
| 13:51:52 | BC | just made me laugh |
| 13:51:52 | LaurentG | angel's are trying to communicate with you ;) |
| 13:51:56 | BC | LOL |
| 13:52:08 | LaurentG | s/l's/ls |
| 13:52:26 | *** | Saving seen data "./dancer.seen" |
| 13:52:36 | BC | ARGH the apostrophe police |
| 13:53:34 | BC | A8F8 |
| 13:53:39 | BC | that's interesting |
| 13:54:34 | LaurentG | ok, the 8 bytes is not a constant |
| 13:54:41 | LaurentG | or rather, it's not always 8 bytes |
| 13:55:01 | BC | why/? |
| 13:55:36 | BC | s/\/// |
| 13:56:27 | LaurentG | U p g r a d e . |
| 13:56:27 | LaurentG | P r o t e c t . |
| 13:56:27 | LaurentG | e d J u k e B . |
| 13:56:27 | LaurentG | o x B a c . |
| 13:56:27 | LaurentG | k d o o r c l . |
| 13:56:28 | *** | Alert Mode level 1 |
| 13:56:28 | LaurentG | o s . . . . . . . |
| 13:56:30 | LaurentG | . . . . & . a c t |
| 13:56:32 | LaurentG | i v . . . * . . B |
| 13:56:57 | LaurentG | after dumping with a width of 9 bytes -> the "code" byte is not always at the end, it shifts |
| 13:57:53 | LaurentG | as you said, when it's ff it's 8 plain bytes, and otherwise the length of data is variable |
| 13:58:22 | BC | so FF is "8 uncompressed bytes" |
| 13:58:37 | BC | ? |
| 13:58:42 | LaurentG | yes |
| 13:59:35 | | Nick mattzz is now known as mattzz|work (~c2af7556@c231002.adsl.hansenet.de) |
| 13:59:46 | BC | so for other codes is the length IN or AFTER the token |
| 13:59:57 | BC | i suggest that it is 1+8 NOT 8+1 |
| 14:00 |
| 14:02:08 | BC | Is there a reason (other than "cos its there") that we are repeating this work? |
| 14:02:43 | | Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") |
| 14:04:24 | mattzz|work | BC: how do we procede with the not-working w2k toolchain? Can you provide documentation or a link for what you fixed for w2k? |
| 14:05:20 | BC | I have recenlt ybeen offered web space, but have been too busy to upload it yet, I wish to apply the update patches and rebuild the installer with them included |
| 14:05:46 | BC | if you want my dev kit, just say how and I will send it your way |
| 14:05:57 | BC | "my" - it is NOT all "my" work |
| 14:06:11 | BC | roland did most of the donkey work |
| 14:06:29 | *** | Alert Mode OFF |
| 14:06:49 | BC | (that was meant to be a compliment) |
| 14:11:03 | LaurentG | back (was on the phone) |
| 14:11:18 | BC | ;) |
| 14:11:22 | LaurentG | BC : ok with your deductions |
| 14:11:44 | LaurentG | BC : i'm working on the gmini's firmware |
| 14:12:10 | LaurentG | that's why I'm repeating this work ;) |
| 14:12:11 | BC | but why not ask Bjo"rn |
| 14:12:19 | BC | ? |
| 14:12:19 | LaurentG | I did, I'm waiting for his reply |
| 14:12:20 | mattzz|work | BC: I will get back to you when I am @ home. I will provide you with an ftp-account for my server @ home. |
| 14:12:40 | BC | email if u like? |
| 14:13:16 | mattzz|work | BC: how big is it? |
| 14:13:34 | BC | 7.5MB before mime - i also have it split in 2 with rar |
| 14:14:20 | mattzz|work | BC: that should be ok. send it to "mattzz at mattzz.dyndns.org" |
| 14:14:52 | mattzz|work | BC: smaller chunks might be safer, dunno what exim accepts as max size at the moment.... |
| 14:15:11 | mattzz|work | gotta go... meeting. |
| 14:15:18 | | Nick mattzz|work is now known as mattzz|meeting (~c2af7556@c231002.adsl.hansenet.de) |
| 14:28:05 | | Part LinusN |
| 14:32:46 | | Join deathsc0ut|Delir [0] (none@pD9E2AD1D.dip.t-dialin.net) |
| 14:34:29 | DBUG | Enqueued KICK deathsc0ut|Delir |
| 14:34:29 | deathsc0ut|Delir | Hello could somebody tell me some hard disks which work good with the AJBR. Or could somebody tell me whats most important for chosing a hard disk for the jukebox? |
| 14:42:26 | BC | power consumption |
| 14:42:29 | BC | slow speed |
| 14:42:40 | BC | *low* power consumption |
| 14:42:56 | deathsc0ut|Delir | One question .. if the speed isnt that good do i access my data slower |
| 14:42:57 | BC | ?Quiet? |
| 14:43:16 | deathsc0ut|Delir | as if it would be faster..? Or does it depend on the buffer of the ram in the jb? |
| 14:43:22 | BC | you need to read up to 320Kb per second to play the worst case MP3 |
| 14:43:36 | BC | on drive cache is not used |
| 14:44:06 | BC | that's 40KB/S |
| 14:44:25 | deathsc0ut|Delir | Okay Could you give me a hint of a good Happy Day because I dont know which one I should take |
| 14:44:29 | deathsc0ut|Delir | hrm |
| 14:44:35 | deathsc0ut|Delir | hard disk not happy day |
| 14:44:37 | deathsc0ut|Delir | *g* |
| 14:45:12 | BC | should I do it with embedded commands |
| 14:45:14 | BC | lol |
| 14:45:24 | *** | Alert Mode level 1 |
| 14:45:24 | deathsc0ut|Delir | He He He |
| 14:46:20 | | Nick mattzz|meeting is now known as mattzz|work (~c2af7556@c231002.adsl.hansenet.de) |
| 14:46:32 | BC | if you think that my advice is valuable you will review the power consumption ratings |
| 14:47:14 | deathsc0ut|Delir | Do they say them in the hard disk information? |
| 14:48:09 | BC | <shrugs> |
| 14:51:12 | *** | Alert Mode level 2 |
| 14:51:12 | deathsc0ut|Delir | Ah Okay I found a site where I can find most of this stuf |
| 14:51:14 | deathsc0ut|Delir | thx |
| 14:52:08 | BC | yw |
| 15:00 |
| 15:01:13 | *** | Alert Mode OFF |
| 15:06:21 | | Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net) |
| 15:11:22 | LaurentG | oops got an answer from Bjorn |
| 15:11:38 | LaurentG | basically it says : "if it's the same you should find it" ;) |
| 15:12:25 | BC | hmmm |
| 15:13:09 | LaurentG | ok, first a tea, then let's try ;) |
| 15:13:16 | BC | tea |
| 15:13:20 | BC | yes, good idea |
| 15:13:24 | BC | (kettle) brb |
| 15:20:09 | | Quit deathsc0ut|Delir ("« Ë×Çü®§îöñ » Info-[v9.4.22]- Released-[August 19, 2002]- Channel-[#Excurs") |
| 15:20:35 | BC | bk |
| 15:23:54 | LaurentG | bk too |
| 15:24:20 | LaurentG | Darjeeling anyone ? ;) |
| 15:24:46 | BC | "brown" today |
| 15:25:33 | BC | "Tesco Premium" a choice, not a default |
| 15:25:35 | LaurentG | actually, I let it infuse all along while I drink, so it's light at the beginning, and brown in the end ;) |
| 15:25:46 | BC | LOL |
| 15:25:48 | BC | likewise :) |
| 15:26:08 | LaurentG | all great minds do the same I guess |
| 15:26:23 | LaurentG | :p |
| 15:26:38 | BC | gotta get every milliounce of caffeine out if it :) |
| 15:26:47 | LaurentG | teine ;) |
| 15:29:50 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 15:36:40 | | Quit [IDC]Dragon ("no fate but what we make (EOF)") |
| 15:36:57 | | Join deathsc0ut|Delir [0] (none@pD9E2AD1D.dip.t-dialin.net) |
| 15:39:12 | DBUG | Enqueued KICK deathsc0ut|Delir |
| 15:39:12 | deathsc0ut|Delir | Hello another question just came into my mind before I will order a new hard disk.. I want to be sure that I can format the new hard disk while it is connected via usb to the pc - is that correct? |
| 15:41:37 | BC | yes |
| 15:41:46 | LaurentG | huh ? |
| 15:42:07 | LaurentG | should'nt it be ok as long as the HD is connected to the Archos ? |
| 15:42:57 | BC | i guess death meant via the usb in the jokebox |
| 15:43:40 | LaurentG | sure, that makes sens |
| 15:43:43 | LaurentG | e |
| 15:43:50 | deathsc0ut|Delir | Okay |
| 15:44:35 | BC | I'm glad we have served you well in a way tailored to what is right for you :) |
| 15:44:39 | BC | (be happy) |
| 15:44:44 | deathsc0ut|Delir | jep you have |
| 15:45:18 | LaurentG | now, please consider making a donation to our headquarters ;) |
| 15:45:22 | LaurentG | (joking !) |
| 15:45:36 | *** | Alert Mode level 1 |
| 15:45:36 | deathsc0ut|Delir | {{ £åügHîñg Øüt £öüÐ }} |
| 15:47:07 | deathsc0ut|Delir | Alright ... I think I dunno another question at the moment and if i will need your help again i will be back :p |
| 15:47:09 | *** | Alert Mode level 2 |
| 15:47:09 | deathsc0ut|Delir | thx and See Ya! |
| 15:47:24 | | Quit deathsc0ut|Delir ("« Ë×Çü®§îöñ » Info-[v9.4.22]- Released-[August 19, 2002]- Channel-[#Excurs") |
| 15:49:45 | | Join mecraw__ [0] (~mecraw@69.2.235.2) |
| 15:52:29 | *** | Saving seen data "./dancer.seen" |
| 15:52:57 | mattzz|work | BC: toolchain on its way? |
| 15:53:06 | BC | should be there |
| 15:53:46 | BC | went 48mins ago |
| 15:54:27 | mattzz|work | not yet5 |
| 15:54:29 | mattzz|work | -5 |
| 15:57:10 | *** | Alert Mode OFF |
| 15:58:38 | mattzz|work | BC: it is there |
| 15:59:06 | mattzz|work | BC: mailfilter was smarter than me - again.... |
| 15:59:21 | BC | lol |
| 16:00 |
| 16:00:28 | LaurentG | GOTCHA ! |
| 16:00:48 | BC | done it |
| 16:00:49 | BC | ? |
| 16:00:59 | LaurentG | I got the unpacking stuff |
| 16:01:04 | LaurentG | (part of it actually) |
| 16:01:10 | BC | well done |
| 16:02:30 | LaurentG | hum, no |
| 16:02:34 | LaurentG | dumbass me |
| 16:02:44 | BC | poo |
| 16:02:52 | LaurentG | you said it |
| 16:03:13 | LaurentG | I need to learn that "turn your tongue ..." stuff |
| 16:04:08 | LaurentG | actually it would have been a pretty dumb scheme if it was that |
| 16:04:45 | BC | are these tokens pointers to data blocks? |
| 16:04:58 | LaurentG | I had : "FF" -> 8 ue, 0 ce ; "FE" -> 1 ce, 7 ue ; "7F" -> 7 ue, 1 ce ; "9F" -> 6 ue, 1 ce |
| 16:05:12 | LaurentG | ue = uncompressed elt, ce = compressed elt |
| 16:05:51 | BC | elt? |
| 16:05:56 | LaurentG | yes, it looks like every "non ff" token means "there are two bytes pointers to data blocks within the next 8 elements |
| 16:06:14 | LaurentG | elt = element, because pointers seem to be two bytes |
| 16:06:22 | BC | ok |
| 16:07:19 | | Nick BC is now known as bc|brb (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 16:07:19 | DBUG | Enqueued KICK bc|brb |
| 16:07:19 | LaurentG | I need to get more examples to figure the coding, but as Bjorn sais, it's probably not very difficult |
| 16:38:39 | | Nick bc|brb is now known as BC (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 16:38:39 | DBUG | Enqueued KICK BC |
| 16:39:12 | BC | if you can find a pointer in the MIDDLE of a block of text you can find the missing text elsewhere in ROM and match it up with the point? |
| 16:39:13 | BC | er |
| 16:39:56 | LaurentG | I'm not sure I understood, what do you mean by "ROM" ? |
| 16:40:15 | BC | scrub that -the ROMs encrypted |
| 16:40:28 | BC | AFTER encryption |
| 16:40:37 | BC | decryption |
| 16:40:38 | BC | ARGH |
| 16:40:50 | Ctcp | Ignored 4 channel CTCP requests in 2 hours and 4 minutes at the last flood |
| 16:40:50 | * | BC has a brain fart |
| 16:41:16 | LaurentG | ok, but I haven't access to the ROM, my gimi is hardware opaque to me |
| 16:41:32 | BC | what is this rom dump then? |
| 16:42:00 | LaurentG | it's the archos firmware after unxoring |
| 16:42:16 | BC | archos!=gmini?? |
| 16:42:24 | LaurentG | gmini firmware sorry |
| 16:43:03 | BC | okay ROM==gmini firmware dump |
| 16:43:10 | LaurentG | hum, ok I just understood what you said |
| 16:43:24 | LaurentG | neurons take some time to heat ;) |
| 16:43:44 | BC | more tea? |
| 16:43:45 | BC | lol |
| 16:44:49 | LaurentG | I haven't searched yet, I was focusing on identifying all "codes" and their relation with packed/unpacked elements following them |
| 16:45:16 | LaurentG | but you're right, this might explain how pointers work |
| 16:45:37 | LaurentG | hum, wait I already have such an example, see : |
| 16:45:55 | LaurentG | 00001a90: 54ff 6f20 7570 6461 7465 ff2c 2070 6c65 T.o update., ple |
| 16:45:55 | LaurentG | 00001aa0: 6173 65fe ca10 7567 2044 4320 49ff 6e00 ase...ug DC I.n. |
| 16:45:55 | LaurentG | 00001ab0: 0023 5345 5249 7f41 4c23 0000 2023 e911 .#SERI.AL#.. #.. |
| 16:46:57 | LaurentG | one can assume that the "<space>pl" from ",<space> please" is used to produce "<space>plug DC" |
| 16:47:55 | LaurentG | so the code here is "FE" which means 1 ce (pointer to " pl"), then 7 ue |
| 16:48:13 | LaurentG | and the pointer to " pl" is $ca10 |
| 16:49:28 | BC | i would need to see some onscreen messages to be convinced by that |
| 16:49:33 | LaurentG | I think the pointer is in fact one byte long only otherwise the text would be less readable |
| 16:49:58 | BC | is it a pointer - or is it a token - if it is a token then there are only 255 of them!? |
| 16:50:17 | LaurentG | BC : that's an easy one, it's the message displayed when updating the firmware, I did it thrice and it says to just that |
| 16:50:20 | BC | if it is a pointer then it can only address 255bytes of memory space |
| 16:50:22 | BC | 256 |
| 16:50:24 | BC | * |
| 16:50:55 | LaurentG | "says just that" (where did this "to" come from ??) |
| 16:52:37 | BC | When the gmini is running what is the full message "To update, please ********ug DC In |
| 16:52:56 | BC | "JukeBox Backdoor closed" ????? |
| 16:53:13 | LaurentG | from memory, it's "To update, please plug DC in" |
| 16:53:22 | LaurentG | BC : interesting one no ? ;) |
| 16:53:45 | LaurentG | I noticed it too, wonder how to use it ;) |
| 16:54:03 | BC | something will print it - trace it back like that |
| 16:54:27 | LaurentG | BC : yes, but that means we can disassemble it, it's not the case yet :( |
| 16:54:38 | * | LaurentG curses Samsung |
| 17:00 |
| 17:04:21 | LaurentG | good, there's a new version of the firmware so I'll be able to check if the message is correct |
| 17:04:39 | LaurentG | lots of bugfixes, good thing ;) |
| 17:06:05 | BC | :) |
| 17:07:49 | | Join Ka__ [0] (~tkirk@65.216.194.2) |
| 17:08:25 | | Join methangas [0] (methangas@0x50c61c07.virnxx10.adsl-dhcp.tele.dk) |
| 17:13:16 | mattzz|work | cu l8er |
| 17:13:42 | | Quit mattzz|work ("CGI:IRC") |
| 17:26:35 | LaurentG | Ok, here's the update string : "Update file found Please plug DC-IN to proceed" |
| 17:27:00 | LaurentG | which demonstrates one thing -> I have unxored the wrong firmware :) |
| 17:27:15 | BC | LMAO |
| 17:27:29 | LaurentG | which means ? |
| 17:27:38 | BC | laughinh my arse off |
| 17:27:42 | BC | laughing |
| 17:27:45 | LaurentG | LOL |
| 17:28:22 | LaurentG | hum, confirmation : i'm working on the 1.20 while my last one was the 1.50 |
| 17:28:23 | BC | In trillian (and others) you get a little smiley with tears rolling down his face |
| 17:28:44 | LaurentG | I think I disabled smileys in gaim |
| 17:28:59 | BC | often wise when sending code |
| 17:29:23 | LaurentG | sure :) |
| 17:29:31 | LaurentG | but I'm not that wise ! |
| 17:29:47 | LaurentG | so, let's see how LMAO appears |
| 17:29:52 | LaurentG | plain text :) |
| 17:30:15 | LaurentG | now I know why I disabled smileys :) |
| 17:52:31 | *** | Saving seen data "./dancer.seen" |
| 17:53:41 | | Quit Nibbler (Read error: 54 (Connection reset by peer)) |
| 17:58:06 | | Nick amiconn|work is now known as amiconn|away (~jens@pD9E7DF9E.dip.t-dialin.net) |
| 17:58:25 | | Part BC |
| 18:00 |
| 18:03:38 | | Quit AciD (Read error: 54 (Connection reset by peer)) |
| 18:05:19 | | Join BC [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 18:26:08 | | Join pfavr [0] (pfavr@dyna218-105.nada.kth.se) |
| 18:56:37 | | Nick amiconn|away is now known as amiconn (~jens@pD9E7DF9E.dip.t-dialin.net) |
| 18:58:22 | | Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") |
| 19:00 |
| 19:07:33 | | Join Ka___ [0] (~tkirk@65.216.194.2) |
| 19:10:45 | | Nick BC is now known as BC|bbl (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 19:13:24 | | Join CpuMan2001 [0] (~jirc@167.206.174.13) |
| 19:15:37 | | Quit CpuMan2001 (Client Quit) |
| 19:16:05 | | Quit Ka__ (Read error: 60 (Operation timed out)) |
| 19:17:54 | | Join mattzz [0] (~mattzz@c231002.adsl.hansenet.de) |
| 19:18:45 | amiconn | Hi mattzz |
| 19:18:51 | mattzz | hi amiconn |
| 19:19:55 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
| 19:22:39 | amiconn | mattzz: Just an idea for a minor speedup: Instead of (n_iter % 8) you can use (n_iter & 7) |
| 19:23:28 | LaurentG | i'd call that a major speedup ;) |
| 19:23:50 | amiconn | Another one: for implementing the idea "incremental recalculation when moving" the gray_scroll_xxx() functions are suited perfectly. |
| 19:24:34 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 19:24:38 | mattzz | amiconn: I will check. Perhaps using only 6 rows for graphics would be also a good idea? |
| 19:25:22 | amiconn | LaurentG: It is not so minor if called often, because the % operator uses a subroutine, while the & is included directly as a machine instruction. |
| 19:26:02 | mattzz | amiconn: a major drawback is that I can't simulate the grayscale stuff (yet?!).... The usb-plug becomes kind of worn out.... |
| 19:26:27 | amiconn | mattzz: You could do that, but I think it looks better with 8 rows. |
| 19:26:28 | LaurentG | amiconn: youre 100% right |
| 19:26:36 | mattzz | LaurentG: dont you mess with Mr. 3% ;-) |
| 19:26:49 | mattzz | LaurentG: or he will speed you up |
| 19:26:50 | LaurentG | mattzz: ;) |
| 19:27:20 | amiconn | I did also have to plug the usb in & out a number of times; meanwhile I do it at the PC end when developing. |
| 19:29:00 | amiconn | The problem with simulation grayscale - how do you simulate something that is only implemented as a plugin and hence not part of the core? |
| 19:29:07 | amiconn | *simulating |
| 19:30:03 | mattzz | amiconn: regarding the r_max discussion (4 vs. 9): Maybe the 2 bits increased accuracy for the fractional part are worth a r_max of 4? (Sorry for me starting that topic again;-) |
| 19:30:37 | mattzz | amiconn: 26 bit with r_max of 4 looks fine @ 17 levels of gray |
| 19:30:57 | mattzz | amiconn: and is _waaaay_ faster ;-) |
| 19:32:09 | mattzz | make |
| 19:32:15 | mattzz | argh, wrong window |
| 19:33:14 | amiconn | Accuracy - maybe getting 2 extra bits is good; I did hit the precision barrier already while zooming in (looks very blocky then). |
| 19:33:55 | amiconn | mattzz: Is it something like 3% faster? ;-) |
| 19:34:23 | mattzz | amiconn: definitively |
| 19:35:25 | amiconn | To make the default image look a bit better when using r_max = 4, you should crop it a little, especially at the left (maybe using Xmin = -2.2) |
| 19:37:43 | | Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) |
| 19:37:46 | amiconn | Btw: While tweaking the X and Y boundaries, a check of the aspect ratio would be good - the default mandelbrot looks a bit distorted. Maybe you didn't take into account that the pixels are not square. |
| 19:39:30 | mattzz | x_min = -2 is fine (I want integers in init_mandelbrot_set() ...) |
| 19:39:51 | mattzz | what is the aspect ratio of a pixel? |
| 19:40:32 | mattzz | brb |
| 19:41:05 | amiconn | The pixels are taller than wide; width/height = 0.8 |
| 19:41:51 | amiconn | mattzz: Do you want an extra 3% speedup? ;) |
| 19:42:00 | mattzz | shoot! |
| 19:43:26 | amiconn | I could send you my 3% accelerated (average) pixel setting routine (that I didn't post), but beware that the asm looks really strange. |
| 19:43:47 | amiconn | (The thing that caused you to call me Mr. 3%) |
| 19:43:50 | mattzz | asm always looks strange (to me) |
| 19:44:39 | mattzz | amiconn: btw, remember that email you sent me the other day? t-online kept it for nearly 7 hours... finally I got it. |
| 19:45:33 | amiconn | Hmm, most of the time the t-online servers aren't _that_ lazy... |
| 19:49:52 | | Join nelliep [0] (jirc@212.116.216.229) |
| 19:50:19 | BC|bbl | % is horribly expensive in comparison to & |
| 19:50:25 | | Nick BC|bbl is now known as bc (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 19:52:32 | *** | Saving seen data "./dancer.seen" |
| 19:53:45 | amiconn | BC: yes, because it uses a lib call which even does division (slow on SH). |
| 19:54:09 | bc | correct |
| 19:54:16 | | Nick bc is now known as BC (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 19:55:05 | LaurentG | bbl |
| 19:56:31 | | Join deadite66 [0] (~Miranda@cpc1-yarm1-5-0-cust53.pete.cable.ntl.com) |
| 19:59:55 | | Quit nelliep ("Leaving") |
| 20:00 |
| 20:00:50 | LaurentG | be back |
| 20:00:52 | | Quit LaurentG ("Download Gaim: http://gaim.sourceforge.net/") |
| 20:03:04 | mattzz | amiconn: I made a screenshot of the grayscale mandelbrot |
| 20:03:19 | mattzz | amiconn: I did it the old school way... |
| 20:03:39 | mattzz | amiconn: http://mattzz.dyndns.org/archos/graubrot.png |
| 20:04:25 | BC | cool - how long to generate? |
| 20:05:05 | mattzz | BC: about 4 secs |
| 20:05:20 | BC | zoom? |
| 20:05:45 | mattzz | BC: how long to zoom? depends on how much "black" there is. |
| 20:05:54 | BC | it does zoom though? |
| 20:06:21 | mattzz | BC: sure |
| 20:06:53 | mattzz | boy, this plugin is so much pointless ;-) |
| 20:07:22 | BC | aren't they all? |
| 20:07:42 | BC | testing my card game framework by writing solitarie atm |
| 20:08:35 | mattzz | BC: I was addicted to solitaire on my windoze 3.11 notebook once. vegas points, 3 cards - a nightmare |
| 20:11:26 | mattzz | BC: btw: the devkit installer rules! nice package. Unfortunately we have some policies installed on our company's PCs that allows me to run it as localadmin only. |
| 20:11:57 | mattzz | BC: regedit is blocked |
| 20:12:12 | mattzz | BC: when logged into the domain |
| 20:12:59 | BC | hmmmmmm - not sure what the workaround for that is |
| 20:13:06 | BC | thanks for the compliment :) |
| 20:31:07 | | Nick BC is now known as bc|busy (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) |
| 20:42:07 | | Nick mattzz is now known as mattzz|away (~mattzz@c231002.adsl.hansenet.de) |
| 20:49:25 | | Quit deadite66 (Read error: 110 (Connection timed out)) |
| 20:51:14 | | Quit AciD (Connection timed out) |
| 20:59:22 | | Join pfavr [0] (pfavr@t1o61p368.telia.com) |
| 21:00 |
| 21:06:51 | | Join LaurentG [0] (~laurent@dyn-83-152-147-175.ppp.tiscali.fr) |
| 21:10:00 | | Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") |
| 21:10:20 | LaurentG | back |
| 21:17:19 | | Join ricflaira [0] (ricflair@modem-rack10-196.netkonect.net) |
| 21:17:26 | ricflaira | hello all |
| 21:17:55 | LaurentG | hi |
| 21:18:14 | ricflaira | all is fine with my archos recorder jukebox now aside from one problem, if i plug it in to charge, somtimes if i slightly touch the cable of the adapter or the archos itself it says "shutting down" |
| 21:19:58 | LaurentG | I see two possibilities : either a bad contact which causes the firmware to think you asked him to shutdown, either a bug in the firmware. Are you using the original firmware or Rockbox ? |
| 21:21:26 | ricflaira | just installed rockbox now, but in flash is original firmware. Should i flash with rockbox? |
| 21:21:41 | LaurentG | no, wait until it suits you before flashing |
| 21:21:46 | ricflaira | ok |
| 21:22:05 | LaurentG | it's hard to get back in case of mistake so better take care first ;) |
| 21:22:31 | LaurentG | so does the shutdown occurs when you are using rockbox ? |
| 21:23:28 | ricflaira | no, only when it is turned off and i plug in the charger and either touch the charger wire or knock the jukebox(charger is fine as i have tried 2 diff ones) |
| 21:25:01 | LaurentG | ok, i'm no rockbox expert, but I guess it's the original firmware which handles this part. but the cause definitely looks like there's a bad electrical contact within your recorder's case. |
| 21:25:47 | ricflaira | hmm, i hope not. i cant afford to post it to usa to get it fixed |
| 21:25:49 | LaurentG | I suggest either mailing to the list or waiting for an expert ;) |
| 21:26:03 | ricflaira | how do i know when it is fully charged |
| 21:26:04 | LaurentG | did you open the case ? |
| 21:26:08 | ricflaira | nope |
| 21:26:22 | LaurentG | is it new ? |
| 21:26:31 | ricflaira | no |
| 21:26:32 | ricflaira | 2nd hand |
| 21:27:21 | LaurentG | ok, so you're on your own. as for battery charge, I think there's an indicator of it within rockbox (a percentage I think) |
| 21:27:41 | ricflaira | where abouts is that? because the battery in the top corner has a ? in it |
| 21:28:22 | LaurentG | once again, i'm not sure of it since I do not have any rockbox able player/recorder, but I seem to recall that it shows on the top menu |
| 21:29:03 | LaurentG | a "?" ? well, you should definitely see with someone else than me ;) |
| 21:29:16 | LaurentG | I've reached the limits of my rockbox knowledge ;) |
| 21:30:18 | ricflaira | :) thanks anyway |
| 21:30:59 | LaurentG | is it the first time you charged it ? |
| 21:31:26 | amiconn | ricflair: See http://rockbox.haxx.se/docs/battery-faq.html, last question. |
| 21:33:28 | ricflaira | thanks |
| 21:33:43 | ricflaira | just wondering if when it gets to 100 percent it will say full or somthing |
| 21:36:34 | LaurentG | no idea |
| 21:42:43 | amiconn | ricflaira: It doesn't say "full", but if you have rockbox running you can look under Info->Rockbox Info. The third text line tells you the battery state. |
| 21:43:05 | ricflaira | ok, thanks, ill check that |
| 21:44:12 | ricflaira | just checked that and all it tells me is the free hd space and also buffer |
| 21:45:00 | amiconn | The battery state is given below the Buffer size |
| 21:45:14 | ricflaira | says (na) |
| 21:45:38 | ricflaira | now says 100 percent |
| 21:45:42 | amiconn | Yes, you have to wait at least 1 minute, see battery faq. |
| 21:45:44 | ricflaira | but ive only had it on charge for about 3 hours |
| 21:46:44 | | Join scott666 [0] (scott666@c-24-245-58-245.mn.client2.attbi.com) |
| 21:46:58 | amiconn | So maybe either the batteries weren't completely empty when you started charging, or the batteries have lost some capacity. |
| 21:47:38 | amiconn | (Or the batteries have a lower capacity rating than the original ones) |
| 21:48:55 | * | LaurentG misses Visual C++'s IDE, and notices that he never thought he'd say such a thing about a Microsoft product.... |
| 21:49:19 | ricflaira | they are the original ones. |
| 21:49:30 | ricflaira | its now down to 97 percent after just about 2 or 3 mins of play |
| 21:51:48 | amiconn | This is perfectly ok as the battery state is (and only can be) a rough estimate. I recommend you to have a look at the manual (http://rockbox.haxx.se/manual/manual.pdf) as well as the faqs. |
| 21:52:19 | ricflaira | ok thank you. |
| 21:52:31 | ricflaira | from empty to full, how long od yuou reckon it will take |
| 21:52:35 | *** | Saving seen data "./dancer.seen" |
| 21:53:59 | amiconn | If the batteries are completely empty, the original one (1500 mAh) and the original charger is used (assuming you have a recorder v1), it should take about 6 hours. |
| 21:54:24 | ricflaira | cool, i have the recorder 20 v1 yeah. and a new charger |
| 21:57:30 | amiconn | If you use a different charger, the charging time depends on the output voltage of the charger, the maximum current it can deliver and whether the voltage is regulated or not. |
| 21:59:11 | ricflaira | right. Ive got a feeling my batteries might be diying , ill buy some new ones soon |
| 22:00 |
| 22:00:10 | amiconn | However, you cannot charge faster than with the original faster, and if the charging voltage goes above 12V the charging circuit within the archos is at risk. |
| 22:00:24 | amiconn | s/original faster/original charger/ |
| 22:01:19 | ricflaira | im charging at 9v. |
| 22:01:38 | ricflaira | ill get some new batteries and use an external charger, is it easy to take the batteries out? |
| 22:03:36 | amiconn | It is not too complicated (it is described in the original manual), but you should do it with a little caution, because the construction of the battery contacts is a bit fragile. |
| 22:03:54 | ricflaira | would you reccomend getting new batteries then?? |
| 22:04:11 | ricflaira | and if i get some, and charge at 9v, will the archos charge the new batteries ok? |
| 22:06:14 | ricflaira | my battery life has gone from 97 percent to 83 percent within about 6 songs |
| 22:06:14 | | Quit mecraw__ (Read error: 104 (Connection reset by peer)) |
| 22:06:23 | | Join mecraw__ [0] (~mecraw@69.2.235.2) |
| 22:07:04 | amiconn | If your batteries are worn out (that is, you don't get the runtime you could normally expect even after a full charge), I would definitely recommend new ones. |
| 22:08:06 | LaurentG | but you should try the deep discharge mode first, to see if they can recover |
| 22:08:13 | amiconn | If the batteries are worn out chances are they may start to leak (just discovered that with mine). |
| 22:09:51 | amiconn | (LaurentG), ricflaira: Yes, first try to run down the batteries until the unit stops, then recharge until they are full. Repeat this several times to get rid of any possible memory effect. |
| 22:10:34 | ricflaira | will do, thanks. |
| 22:10:37 | amiconn | ricflaira: If your 9V charger is regulated (stabilized) it may take more than 6 hours for a full recharge. |
| 22:10:49 | ricflaira | ok. |
| 22:11:00 | ricflaira | would formatting the drive effect it? |
| 22:11:25 | amiconn | ? |
| 22:11:47 | ricflaira | i guess not |
| 22:14:00 | LaurentG | ricflaira: if you want to drain your batteries as fast as possible, then connect the unit to a PC and keep reading from the disk, this is the highest power drain you can get |
| 22:14:27 | LaurentG | (beware not to write to the disk, as a power failure during such an operation might cause harm to it) |
| 22:14:37 | | Join pfavr [0] (pfavr@t1o61p11.telia.com) |
| 22:14:57 | LaurentG | but there's no reason to hurry, normal usage is fine too ;) |
| 22:16:15 | ricflaira | ok, cool. Ill drain it right down and then recharge and see how that goes. Failing that ill go and buy some new ones from maplin |
| 22:16:46 | LaurentG | ricflaira : do it several times to be sure |
| 22:17:30 | ricflaira | ok |
| 22:17:34 | ricflaira | is this a common faukt |
| 22:17:36 | ricflaira | fault |
| 22:20:19 | ricflaira | would these be ok http://www.maplin.co.uk/products/module.asp?CartID=04042021085076&moduleno=- |
| 22:21:04 | scott666 | VBscript runtime error... |
| 22:21:08 | | Nick mattzz|away is now known as mattzz (~mattzz@c231002.adsl.hansenet.de) |
| 22:22:16 | mattzz | amiconn: I reverted x_min to -2.5 again. I need an aspect ration of 1.75, otherwise there will be stretching while zooming |
| 22:23:28 | mattzz | amiconn: And I put some nicer screenshots on http://mattzz.dyndns.org/twiki/bin/view/Projects/RockBox |
| 22:24:20 | scott666 | ooooh! |
| 22:24:22 | scott666 | crazy looking |
| 22:28:54 | | Quit Ka___ ("Leaving") |
| 22:29:16 | | Join lurwas [0] (~user@c85388a.vta.bostream.se) |
| 22:29:22 | lurwas | Hello |
| 22:29:23 | LaurentG | nice grayscale levels |
| 22:29:41 | amiconn | The sections are looking really nice. Btw, I did also get various nice pictures. Too bad there is no save function yet ;-) |
| 22:30:09 | lurwas | Does anyone know if it's possible to upgrade the Archos 6000 with a 20GB HD instead? |
| 22:30:58 | amiconn | mattzz: Concerning the aspect ratio: Either you can change the aspect ration as well if you change the initial aspect, or better still, you could use separate delta values for x and y. |
| 22:31:04 | amiconn | lurwas: yes |
| 22:31:46 | lurwas | amiconn: Ok, great :) Have you done it yourself? Anything special you have to do to get it open etc? |
| 22:33:03 | | Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 22:33:09 | mattzz | amiconn: that would make -3% I guess |
| 22:33:20 | mattzz | amiconn: using a delta |
| 22:33:36 | amiconn | No, I haven't done it myself, since I happen to have a recorder (and didn't upgrade the hd yet). But there is a link at the rockbox docs page: http://www2.funmp3players.com/reviews/modify/ |
| 22:34:13 | lurwas | amiconn: Thanks man :) |
| 22:34:59 | amiconn | mattzz: Why? You use a delta atm and would replace it with, say deltax and deltay. These are only recalculated when the zoom factor changes. |
| 22:35:49 | lurwas | Does anyone know of any case mods for the Archos Jukebox? I find it to be rather ugly, and want ti make a casemod for it.... |
| 22:35:59 | lurwas | to even |
| 22:36:04 | amiconn | mattzz: It would ensure that the initial aspect will be kept regardless of the starting value. |
| 22:36:46 | mattzz | amiconn: you are right |
| 22:37:09 | amiconn | :) |
| 22:37:27 | | Quit ricflaira (Read error: 60 (Operation timed out)) |
| 22:40:18 | mattzz | I am too tired to do this tonight (last night was short enough). I will put mandelbrot.c and graubrot.c into the patchtracker for now - maybe some of the allmighty CVS gods have mercy with me ;-) |
| 22:40:41 | LaurentG | lurwas: all case mods are listed on the web site |
| 22:41:09 | LaurentG | but I don't recall anyone replacing the case |
| 22:41:11 | lurwas | LaurentG: Ok, I need to surf around a bit more there then, thanks :) |
| 22:41:41 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!") |
| 22:42:00 | LaurentG | CVS god are nice ones, the ugliest ones are those of the fiscal administration ;) |
| 22:42:46 | amiconn | mattzz: Do you put it up with or without deltax-deltay? |
| 22:43:04 | mattzz | amiconn: without, should I wait? |
| 22:43:41 | amiconn | Hmm, I really don't know, but I _could_ be temted to commit it... |
| 22:44:04 | amiconn | *tempted even |
| 22:44:51 | mattzz | amiconn: feel free to do so. If you want, I put both .rocks in the usual place and you can modify and commit them to the patchtracker |
| 22:45:11 | mattzz | s/.rocks/.c/ |
| 22:48:04 | | Quit pfavr ("ChatZilla 0.9.52B [Mozilla rv:1.6/1]") |
| 23:00 |
| 23:01:03 | mattzz | amiconn: coding? ;-) |
| 23:07:44 | | Join hardeep [0] (1098@208.247.65.237) |
| 23:08:01 | | Quit matsl (Remote closed the connection) |
| 23:50:27 | mattzz | night folx |
| 23:50:53 | | Quit mattzz ("Client exiting") |
| 23:52:38 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).