Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2004-07-19

00:06:52***No seen item changed, no save performed.
00:17:16 Quit Nibbler (Read error: 104 (Connection reset by peer))
00:25:42 Join leprezaun [0] (zazz@076-066.dialup.sunysb.edu)
00:34:15 Quit zeekoe (Read error: 60 (Operation timed out))
00:39:12scott666kaboofa: whats so illegal about the remixes?
00:39:39scott666is it anything like the grey album/double black album thing?
00:42:51kaboofai don't know ;P
00:42:54kaboofawait
00:42:54kaboofawhat?
00:43:04kaboofagrey album?
00:43:06scott666yeah
00:43:10kaboofaby whom?
00:43:19scott666i cant remember the guy that mixed it
00:43:22kaboofa(please explain this concept)
00:43:43scott666he remixed the beatles white album with jay z's black album
00:43:50kaboofaweird
00:43:54kaboofawhy would you do that :X
00:44:02scott666and someone else did the same thing but with jay z and metallicas black album
00:44:07kaboofahaha
00:44:08scott666because they could
00:44:33scott666apparently jay z released an acappella (sp?) version of his cd
00:46:11scott666so theyre totally illegal because they dont have lisencing rights from either
00:47:00 Quit uski_ ("Leaving")
00:47:57scott666download both here: http://www.bannedmusic.org/
01:00
01:10:41 Join tpelliott [0] (telliott@208-251-255-120.res.evv.cable.sigecom.net)
01:19:00 Quit midk|gone (Read error: 60 (Operation timed out))
01:19:14 Join midk|gone [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com)
01:26:31 Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de)
01:37:49 Quit lImbus (" WOW! This IRC Client ownz! HydraIRC -> http://www.hydrairc.com <-")
01:42:33 Part tpelliott
01:54:53kaboofaugh
01:54:57kaboofahydrairc
02:00
02:06:53***Saving seen data "./dancer.seen"
02:19:30AciD:)
02:27:51 Join BC [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com)
02:33:30 Quit AciD (Read error: 104 (Connection reset by peer))
02:34:16 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
02:53:05kaboofamoo
02:57:40BCkwak
02:58:13kaboofammm
02:58:21kaboofarape of bandwidth
03:00
03:11:18 Quit scott666 (Read error: 110 (Connection timed out))
03:20:24 Quit BC (Read error: 54 (Connection reset by peer))
03:21:44 Join BC [0] (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com)
03:25:27 Join thirdworld [0] (~huszcak@161.115.209.37)
03:25:41thirdworldi fried my jukebox
03:27:26BCbummer
03:27:26 Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
03:27:42scott666hey BC
03:27:50BCHey Satan
03:28:00scott666heh
03:28:10scott666my reciever is dying
03:28:18scott666i cant watch requiem for a dream
03:28:30*scott666 is pissed
03:29:27scott666do you have any idea why the center channel would output sound very quietly, when the rest of the speakers dont?
03:30:40BCwired up badly?
03:30:45scott666nope
03:30:51scott666well
03:30:53scott666possibly
03:30:56BCamp crashed?
03:30:57scott666define badly
03:31:17BCwrong
03:31:24scott666then no
03:31:38scott666because it worked yesterday and i hadnt chagned anything
03:31:49scott666and i double checked
03:31:51scott666repeatedly.
03:32:17scott666i tested the speaker, the dvd player, and all the wires in between
03:32:19BCamp crashed?
03:32:28scott666how can i test
03:32:33BCreboot
03:32:42scott666then yes
03:32:47scott666lol
03:33:31scott666is it fixable?
03:33:43BCeverything is fixable
03:34:01scott666is it easily fixable?
03:34:24BCcouldn't tell from here
03:34:49scott666i could take a picture of the inside of the reciever
03:34:53scott666lol
03:35:09BCno thanks
03:35:10BClol
03:35:17BCcoding atm
03:35:33scott666ok
03:35:36 Nick BC is now known as BC|coding (~bluechip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com)
03:35:36scott666ill google for a minute
03:38:24 Quit leprezaun (Read error: 110 (Connection timed out))
03:48:59 Quit thirdworld ()
03:49:11scott666no results
03:49:16scott666damnit
03:54:54 Quit midk|gone (Read error: 104 (Connection reset by peer))
03:55:12 Join midk|gone [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com)
04:00
04:06:57***Saving seen data "./dancer.seen"
04:21:15 Join dstar5 [0] (lee@ACC57F20.ipt.aol.com)
04:21:15 Quit Nibbler (Read error: 54 (Connection reset by peer))
04:24:33 Quit dstar5 (Client Quit)
04:31:43 Join leprezaun [0] (zazz@076-045.dialup.sunysb.edu)
04:39:36 Quit leprezaun ("Disconnecting")
04:49:51 Part scott666
04:51:35 Quit AciD (Read error: 104 (Connection reset by peer))
04:57:34 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
05:00
05:29:55 Quit AciD ("resistance is futile. you will be ass-stimulated")
05:39:08 Join midknight2k3 [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com)
05:39:55 Quit midk|gone (Read error: 54 (Connection reset by peer))
05:47:22 Part BC|coding
06:00
06:04:45 Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de)
06:06:58***Saving seen data "./dancer.seen"
06:10:53 Nick kaboofa is now known as tomsleep (~kaboofa@pcp03462569pcs.indpnd01.mo.comcast.net)
06:40:58 Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
06:40:58 Quit Nibbler (Read error: 104 (Connection reset by peer))
06:44:28 Join LinusN [200] (~linus@labb.contactor.se)
07:00
07:09:06 Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net)
07:09:54 Quit midk (Client Quit)
07:11:04 Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net)
07:11:26 Part scott666
07:20:58 Join Strath [0] (~mike@dgvlwinas01pool0-a207.wi.tds.net)
07:21:12 Part Strath
08:00
08:07:01***Saving seen data "./dancer.seen"
08:11:39 Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de)
08:46:49 Quit midk ("just STOP it arspy")
08:46:49 Quit Nibbler (Read error: 104 (Connection reset by peer))
08:57:12 Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net)
09:00
09:08:53 Quit midk ("just STOP it arspy")
09:12:44 Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net)
09:15:39 Quit midk (Client Quit)
09:19:27 Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net)
09:20:54 Join midk2k3 [0] (~Zakk@c-24-18-39-204.client.comcast.net)
09:21:16 Nick midk2k3 is now known as idk (~Zakk@c-24-18-39-204.client.comcast.net)
09:21:18 Quit midk (Nick collision from services.)
09:21:20 Quit midknight2k3 (Nick collision from services.)
09:21:22 Nick idk is now known as midk (~Zakk@c-24-18-39-204.client.comcast.net)
09:21:36 Join midknight2k3 [0] (~Zakk@c66-235-14-120.sea2.cablespeed.com)
09:27:12LinusNmidknight2k3: problems?
09:27:30midkno problems here :]
09:32:03 Join amiconn [0] (~jens@pD9E7F944.dip.t-dialin.net)
09:32:26amiconnhi all
09:32:39midkhi amiconn
09:33:58amiconnLinusN: As midk now did his first commits, I wanted to add him to the nick->firstname conversion list. I checked out the whole www module, but couldn't find the "responsible" script...
09:34:46midkas in, i'd appear as "Zakk" isntead of "midk"?
09:34:58amiconnyup
09:35:07midkfine by me
09:38:58LinusNme fix
09:40:06*midk is happy he didn't break the sims at all
09:40:48 Join uK|uD-alpha`omeg [0] (~treffmeis@203.214.2.115)
09:41:05 Nick uK|uD-alpha`omeg is now known as alpha`omega (~treffmeis@203.214.2.115)
09:41:10alpha`omegahey guys
09:41:17midkhey
09:41:30alpha`omegaumm i just made a post in the 'general' newsgroup
09:41:47alpha`omegaabout the feasibility of creating alternate firmware for another dap
09:41:50alpha`omegathe iAudio M3
09:42:27midkdid you have any plans, or were you just suggesting the platform?
09:43:30alpha`omegaplans
09:43:32alpha`omegaas in, ideas
09:43:36alpha`omegaoh yeah :P
09:44:25alpha`omegaany of you guys interested?
09:44:46DBUGEnqueued KICK alpha`omega
09:44:46alpha`omegaBy The Way the iAudio is one of the best players out there in terms of features and capability
09:44:56midkso.. why does rockbox need to run on it?
09:45:08midki've never heard of it - can it be that good? ;)
09:45:20alpha`omegaThere are a number of ways in which this potential could be improved
09:45:26alpha`omegaill quote a few off the top of my ehad
09:46:36alpha`omega1. Instant resume function, like the iPod or iRiver. Eg. The iAudio turns on much quicker when plugged into the wall charger. A certain player – I forget its name – has this function, HOWEVER, it turns completely off after 1 hour, in a similar, power-saving state as the iAudio. This feature would be WELL received – quicker startups during periods of frequent use, BUT still saving power.
09:46:36alpha`omega2. Option to sort files by ID3 tag – for example, tracks could be sorted by artist, album, track, genre – you name it. The option to turn this off for those who do not like it, however, would be great.
09:46:36alpha`omega3. “DJ” feature a la Rio Karma – the option to create playlists on the device itself – or at least listings – based on a number of criteria such as: favourites, not played in X days, favourites not played in X days, etc. (See * below for further info)
09:46:38alpha`omega4. Ability to rate tracks on the device. For example, by holding record, a rating screen could be brought up, or maybe in the form of a pop-up
09:46:41alpha`omega5. Option to have a smaller font size; the iAudio’s screen is great (4 greys, same width as iPod) and in many opinions, underutilised. On this point, maybe an option to scroll through directories quicker?
09:46:44alpha`omega6. Is it possible to remove the “Wait” popup which appears when HDD is being accessed? The little [H] icon would do fine by itself. If this popup was not there, other things could be done during periods of access. On this point, is it possible to adjust the read speed of the HDD in the options, like the iRiver? Eg. Quick reading for frequent song changing; slow reading and more battery life when listening to whole tracks.
09:46:49alpha`omega7. Support for “lossless” audio formats has a smaller, yet still devoted following. Eg. WMA9 Lossless; FLAC; Monkeys Audio
09:46:52alpha`omega8. I don’t believe it’s important, but lossless playback seems to be followed.
09:46:56alpha`omegaand also Musepack (.mpc)
09:46:58alpha`omegaand Bookmarking
09:47:04alpha`omegaand pretty much all of Rockbox as well
09:47:13midkum, you said it *does* have good features - it sounds as if it needs lots lots lots of things..
09:47:14alpha`omegahttp://www.jetaudio.com/forums/showthread.php?t=1785 I am treffmeister
09:47:34alpha`omegasoz i meant to say, "it has many good features, but there is potential for more"
09:47:46midktell me about some current good features..?
09:48:33LinusNalpha`omega: which CPU does iaudio use?
09:49:13alpha`omegathrow the name up of the most common one i have a mind blank
09:49:20alpha`omegasomething 3500 i think
09:49:27alpha`omega3520
09:49:44alpha`omegahttp://www.jetaudio.com/products/iaudio/m3/ and it cops some reviews http://www.jetaudio.com/products/iaudio/m3/reviews.html
09:49:53alpha`omegaand there are many people willing to help with the firmware
09:50:04alpha`omegawe just need some professionals
09:50:09alpha`omegaso i decided to take it to you
09:51:20LinusNalpha`omega: the thing is this:
09:51:27alpha`omegaand www.iaudio.com
09:51:28alpha`omegashoot
09:51:40LinusNnon of the rockbox developers has an iaudio player
09:51:46LinusNnone
09:52:05LinusNand we can't develop on a platform we don't have
09:52:06alpha`omegais that a certain?
09:52:37alpha`omegaeven so, is it possible for youi guys to even have a days' experimentation?
09:52:40alpha`omegaor an hour
09:52:52LinusNwe need hands-on dissection
09:53:53LinusNwe need lots of hardware information, like schematics, data sheets etc
09:54:26LinusNwe need hardware
09:54:27alpha`omegai'm sure iAudio will provide it I will contact them now
09:54:33alpha`omegaI have the hardware
09:54:40LinusNyes, you have it, i don't
09:54:46alpha`omegaif you ask you may get a test unit
09:54:58CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
09:54:58*midk doubts iAudio would *support* the hacking of it
09:56:39LinusNalpha`omega: but most of all, i need a reason to do it
09:56:56alpha`omegawell why did you create the RockBox firmware?
09:57:16alpha`omegaCould you at least help us out in terms of deciphering and modifying the firmware?
10:00
10:00:02LinusNalpha`omega: i created rockbox because i had an archos jukebox
10:00:25LinusNalpha`omega: i can't decipher the firmware if i know nothing about the hardware
10:01:10LinusNat least i need to know which CPU it is
10:01:21midk<alpha`omega> something 3500 i think
10:01:22midk<alpha`omega> 3520
10:01:29LinusNyou seem to think that this is easy
10:03:14*midk likes the fact that he could put a jumping carrot as his boot logo on the iAudio
10:03:16midk:)
10:05:20LinusNsigmatel 3420
10:06:54LinusNthey use different sigmatel chips for the different models
10:07:02***Saving seen data "./dancer.seen"
10:08:33midkOH
10:08:38midk*rediscovers breakout-4.c
10:10:26LinusNsigmatel has a quite closed architecture, no public data sheets
10:10:45midkhm, LinusN were you ever going to look into that button_repeat_rate function? i recall you saying that it was complicated..
10:11:35LinusNsort of, yes
10:11:53midkany chance of it being implemented soon?
10:12:36LinusNi think we should export the button_read() function instead
10:12:57LinusNthen you can implement thew repeat yourself
10:13:17midkah, yes, you mentioned that
10:14:09midkso.. would this become something like switch(button_read()) { case BUTTON_LEFT: x−−; break; } ?
10:14:23midki'll have to see how it's used
10:19:43LinusNall buton_read() does is return the current button status
10:19:58midkwhat exactly would it return if i pressed F1?
10:20:07LinusNthe rest is up to you, using current_tick and TIME_AFTER() etc
10:20:23LinusNit would return BUTTON_F1
10:21:25LinusNit returns the same values as button_get(), except that it wouldn't set the BUTTON_REL and BUTTON_REPEAT flags
10:22:13 Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de)
10:23:54midkhm
10:23:58*midk needs an example
10:24:11midkbut so
10:24:24midkswitch(button_read()) { case BUTTON_LEFT: x−−; break; }
10:24:26 Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net)
10:24:31midkthat would work even if it were repeating right?
10:24:32midkhi idc
10:24:49[IDC]DragonHi guys and gals
10:25:11LinusNmidk: there is no "repeat" since you are reading the buttons directly
10:25:16LinusN[IDC]Dragon: hi
10:25:31amiconnhi [IDC]Dragon
10:25:42LinusNeither the button is pushed or it's not
10:26:24midklinusn: but it would work if you did hold the buttons
10:26:35midkinstead of returning button_repeat it would keep returning button_left, no?
10:26:49LinusN(sigh)
10:26:50alpha`omegaso is there ANY chance whatsoever of you creating some 3rd party stuff for the iAudio if I could obtain the necessary data?
10:26:55midkokay, never mind
10:27:03LinusNit returns the current status of the buttons. period.
10:27:14midkokay
10:27:47LinusNalpha`omega: if i owned an iaudio player, all i can say is "maybe"
10:28:25alpha`omegaOkay
10:28:31alpha`omegaill see what they say about a test unit
10:31:20amiconnLinusN, midk: Iiuc, if you use button_read() directly, the button events still queue up in the button queue.
10:31:46midkall i need is a faster repeat rate.
10:33:00alpha`omegaOkay i've dispatched an email and the replies are usually pretty speedy.
10:33:28amiconnSo the button queue has to be emptied at least before exiting the plugin, otherwise you would get a funny sequence of queued button events after that
10:33:51amiconnLinusN: What happens if the button queue gets full?
10:34:38midkamiconn: by the way.. this occurs in tetris.
10:34:50midk->funny queued button sequence
10:35:17midki am coding a rockblox update.. i can fix it there
10:36:59[IDC]DragonI saw an Xclef 800 at Saturn Hansa
10:37:20[IDC]DragonI can't say I like it
10:37:49[IDC]Dragonmechanics don't give a quality appeal
10:40:50[IDC]Dragonthe "up" button of the pad touched the case when pressed, and this button had no tactile feedback any more
10:41:03alpha`omegaI have to agree having used the Xclef myself
10:41:41[IDC]Dragon(same badness with my AJB, the button have an uneven feedback)
10:43:19[IDC]Dragonand the top faceplate of the Xclef is transparent, the kind which gets fingerprints all over
10:44:24alpha`omegalike the iPod grrr
10:44:50[IDC]Dragon(the last?) AJB Recorders V2 are sold there for €199
10:44:57alpha`omegaIn fact if one exposes the ipod to air, scratches automatically appear on its underside
10:45:08alpha`omegaand the iRiver puts the 'box' in Jukebox
10:47:23alpha`omegaOkay they can't 'open the source', but is it possible to decompile the firmware?
10:49:21[IDC]Dragonalpha`omega: you seem to underestimate how much effort reverse engineering is
10:49:37alpha`omegaenlighten me
10:50:02[IDC]Dragonthis would be a very long enumeration
10:50:39[IDC]Dragonis sum, it's probably a year of work
10:51:26[IDC]Dragonin sum
10:52:03alpha`omegacan you tell me how to do it and i will do it.
10:52:04*alpha`omega is Back (From:Auto IdleAway after 15 minute(s)) (Gone for:1802wks 4days 8hrs 52mins 6secs) - Invincible
10:52:32alpha`omegathank you
10:52:43[IDC]Dragonalpha`omega: if I need to tell you, you can't do it
10:53:13midkalpha`omega, reverse engineer the firmware.
10:53:28alpha`omegahung?
10:53:37alpha`omegahunh*?
10:53:47alpha`omegacan you give me a program, even
10:53:53midkreverse engineer the firmware is what you need to do.
10:54:00midkyou have to write one
10:54:02alpha`omegaOkay
10:54:14alpha`omegacan you please, aven briefly, outline what i need to do?
10:54:22midknot really, no..
10:54:59LinusNalpha`omega: like [IDC]Dragon said, if we need to tell you how to do it, then you don't have what it takes
10:55:11***Alert Mode level 1
10:55:11alpha`omegaOkay
10:55:19[IDC]Dragonyou need to be into low-level programming and electronics
10:55:50alpha`omegainto both
10:56:04alpha`omegaC for Palm. and know MUCH about electronics
10:56:26LinusNthen open it up, fire up your multimeter, and start drawing schematics
10:56:34*alpha`omega is Away (Reason:Eating...) (Since:18:56:37) (Pager:on) (Logger:off) - Invincible
10:56:34 Nick alpha`omega is now known as alpha`omega[away (~treffmeis@203.214.2.115)
10:56:34DBUGEnqueued KICK alpha`omega[away
10:56:34***Alert Mode level 2
10:56:41alpha`omega[away(eating
10:56:41 Nick alpha`omega[away is now known as alpha`omega (~treffmeis@203.214.2.115)
10:56:41DBUGEnqueued KICK alpha`omega
10:56:41***Alert Mode level 3
10:56:41LinusNget the data sheets for the CPU and other chips
10:56:53alpha`omegawell that's an unreasonable ask
10:57:06alpha`omegaso i can see you guys aren't going to help make the firmware?
10:57:15CtcpIgnored 3 channel CTCP requests in 7 seconds at the last flood
10:57:15*alpha`omega is Away (Reason:Away) (Since:18:57:18) (Pager:on) (Logger:on) - Invincible
10:57:15 Nick alpha`omega is now known as alpha`omega[away (~treffmeis@203.214.2.115)
10:57:15DBUGEnqueued KICK alpha`omega[away
10:57:15***Alert Mode level 4
10:57:26midkit's mroe than just making the firmware
10:57:52LinusNwhy is it unreasonable to take it apart and draw schematics?
10:58:03LinusNthat's what we did for the archos
10:58:05midki think he was referring to the datasheets...
10:58:34LinusNif the data sheets are unavailable, then we are pretty much out of luck
10:59:18LinusNany company that chooses such a closed/secret chipset don't deserve rockbox, imho
11:00
11:07:16***Alert Mode OFF
11:17:43 Quit alpha`omega[away ("The wheel's spinning but the hamster's gone...")
11:17:43 Quit Nibbler (Read error: 54 (Connection reset by peer))
11:18:37 Nick midk is now known as midk|sleepy (~Zakk@c-24-18-39-204.client.comcast.net)
11:18:50midk|sleepysleep as in 'sleepy-ing'
11:18:56midk|sleepy:]
11:28:47[IDC]Dragonamiconn: are you there?
11:28:52amiconnyup
11:29:06[IDC]Dragonhow's ROMbox?
11:29:35amiconnI did not yet look into it (was on a holiday trip for a week)
11:29:40[IDC]Dragonbtw, long tim no see, I thought you're on holidays or so
11:29:44[IDC]Dragonah
11:30:25amiconnDo you have a collection of bugs/ strange behaviours that occur with rombox?
11:30:36[IDC]Dragonnot really
11:30:54[IDC]Dragonthe one I encountered is that it refuses to load plugins
11:31:16LinusNamiconn: queue overflow is not handled, so the ring buffer will just wrap around
11:31:38[IDC]Dragoniirc, the open() call failed, to load the plugin as a file
11:31:56amiconnLinusN: Ok, as long as this doesn't overwrite innocent memory
11:32:05LinusNno worries
11:32:30amiconn[IDC]Dragon: I'll look into it, but as you may know I can't use gdb, so it may take a while
11:32:32LinusNwe could add a button_clear_queue()
11:33:12[IDC]Dragonamiconn: gdb is useless for debugging within ROM
11:33:25amiconnLinusN: Imho this is unnecessary, since it is as easy as writing: while(rb->button_get(false)) ;
11:33:59amiconn[IDC]Dragon: Ok, so I have no disadvantage from being unable to use it at all ;-)
11:35:07amiconnLinusN: Perhaps it would be useful if the button queue could be switched on and off
11:35:23[IDC]Dragonthe plugin version of get_button() could empty the queue in additition, courtesy to the user
11:36:08[IDC]Dragonbecause if you hable buttons like this, by polling, you're not interested in queue events
11:36:22[IDC]Dragons/hable/handle
11:38:07[IDC]Dragonbutton_read(), I mean
11:42:04LinusN[IDC]Dragon: good idea
11:42:29LinusNyou must still empty the queue on exit...
11:42:54LinusNthat could be done by the plugin framework though
11:43:33[IDC]DragonI don't remember having seen a plugin emptying the queue on exit
11:44:04[IDC]Dragonif this is mandatory cleanup, the framework should do it
11:44:09LinusNno, but it could be done by the framework
11:44:30LinusN:-)
11:44:45LinusNlunch time
11:50:48 Join lImbus [0] (~manuel@kernel.cycos.net)
12:00
12:07:03***Saving seen data "./dancer.seen"
12:14:07amiconn[IDC]Dragon: How is your linkage_flash.lds supposed to be used? If I interpret the Makefile correctly, linkage.lds is generated from app.lds. So I have to take out that step, and put linkage_flash.lds into the build dir as linkage.lds?
12:15:17amiconnBtw: linkage_flash.lds is adjusted for the 8 MB mod if I read it correctly
12:26:57LinusNamiconn: i think we have found a victim of the new asm ATA code
12:27:18LinusNhttps://sourceforge.net/tracker/?func=detail&atid=439118&aid=624697&group_id=44306
12:36:00amiconnLinusN: This looks like "classic" rld to me
12:38:05LinusNyes, at first glance
12:38:50LinusNbut since it has gotten worse, i suspect the optimizations as well, i have sent him a test build with C loops
12:41:02amiconnI'm very interested in the result of this test, since (1) fs corruption wasn't observed on the player so far, (2) this is a Hitachi DK23DA, which is "famous" for rld
12:42:38LinusNabsolutely
12:43:05amiconn[IDC]Dragon: Are you around?
12:55:01[IDC]Dragonjust got back
12:55:13amiconn[12:14:15] <amiconn> [IDC]Dragon: How is your linkage_flash.lds supposed to be used? If I interpret the Makefile correctly, linkage.lds is generated from app.lds. So I have to take out that step, and put linkage_flash.lds into the build dir as linkage.lds?
12:55:13amiconn[12:15:25] <amiconn> Btw: linkage_flash.lds is adjusted for the 8 MB mod if I read it correctly
12:55:36[IDC]Dragonyes, I have 8 MB
12:56:23amiconnIn the meantime I adjusted it to 2 MB and just tried it. Then I have to take rockbox.bin, and uclpack −−none it, right?
12:56:37[IDC]Dragonyes
12:58:28[IDC]Dragonthe main issue in making a nice ROM version is to decorate many arrays/structs/etc with "const"
12:58:52[IDC]DragonRockbox is almost completely neglecting const
12:59:57[IDC]Dragonbecause it makes no difference for a RAM version, but if you run from ROM you want to avoid the data being copied to RAM
13:00
13:00:04amiconnImho this is the next step after making it work without bugs
13:00:28amiconnMaybe there are some variables declared "const" that are not really const
13:00:37[IDC]Dragonagreed, first we need to find the opposite cases
13:01:07amiconnBtw, tight fit: There are only 9896 bytes of ROM left...
13:01:25[IDC]Dragonnot too bad
13:01:40 Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de)
13:02:03[IDC]Dragonif this looks promising in general, i'd replace the Archos s/w with a .ajz loader
13:02:16amiconnDifferent topic: I wonder what the rom-less versions are about - as they have no boot rom, perhaps this is the sh1 variant having 8K of IRAM instead?
13:02:40[IDC]Dragonunfortunately not
13:02:46[IDC]DragonI tried that
13:04:53amiconnI just flashed my 182K .ucl - it boots correctly. Leaves 1793 KB of buffer
13:05:25[IDC]Dragonit can be more when "const"ing the font, menu, etc.
13:05:54[IDC]Dragonhow much was it before?
13:05:58amiconnyup. At first I'll play aroud a bit to see what doesn't work as expected
13:06:16[IDC]Dragonhave you tried a plugin?
13:06:21amiconnIirc the ram version leaves ~1630 KB of buffer
13:06:44[IDC]Dragon160 kB saved, hmm
13:07:37amiconn(1) Trying to use "View HW info" from the debug menu hangs the box
13:08:04[IDC]Dragonbecause it queries the flash ID
13:08:23amiconnI suspected that; this has to be skipped when running from flash
13:08:40[IDC]Dragonyes, we need a #define
13:09:17[IDC]Dragonor a runtime flag
13:09:32LinusNor run the code in RAM
13:09:54[IDC]Dragonhmm, and disable the interrupts meanwhile?
13:09:57LinusNyes
13:10:32LinusNstill, the flash plugin will be a tough one
13:10:40[IDC]Dragon;-)
13:11:02[IDC]DragonI woudn't mind to run the .ajz first
13:11:03amiconn[IDC]Dragon: Good news - plugins can be started without problems
13:11:52[IDC]Dragonmaybe I was const'ing too much then
13:12:27[IDC]Dragonwhen I played with that variant, I plastered "const" all over the place, to see how much I can get
13:13:27amiconnI just took current cvs (only deviation being my "geek mode" bitswap) and linked with linkage_flash.lds
13:14:42[IDC]Dragonyou can make an IRAM function out of dbg_flash_id()
13:15:09[IDC]Dragonadd the interrupt disable to it, take out the sleep()'s
13:15:49[IDC]Dragon(only Atmel requires them, and no box has Atmel flash)
13:17:13amiconnPlayback seems to work correctly as well
13:19:32[IDC]Dragonyou can make a test build for a wider audience
13:19:54[IDC]Dragonso you don't have to do all the testing yourself
13:19:58amiconnCurrent ram based rockbox leaves 1.630 MB of buffer, so the gain is 0.163 MB or almost 167 KB
13:20:18[IDC]Dragonit's a nice start, I'd say
13:20:34amiconnHow much more free ram did you get with const'ing everything?
13:20:58[IDC]Dragonembarrasing, but I don't remember
13:21:11amiconnnp
13:21:44[IDC]DragonLinusN: what larger data structures do we have?
13:22:01LinusNwhat do you guys say, is there enough reason to be able to select the priority of ID3v1 and ID3v2 tags?
13:22:03[IDC]Dragonto my mind comes font, menus, plugin table
13:22:18LinusNid3 tag table
13:22:52amiconnIt seems that rockbox runs a bit slower from ROM
13:23:23[IDC]Dragonthat's understandable, the flash is 8 bit wide
13:23:36[IDC]Dragonbut I didn't notice a difference
13:23:50[IDC]Dragonsince the action code is mostly in IRAM
13:24:55amiconnThe difference is actually small, and not noticeable with normal usage. The grayscale.rock runs ~0.81s with rockbox in ram, and 0.82..0.83s with rockbox in rom
13:25:41[IDC]DragonI was talking about the feel of the box
13:26:21[IDC]Dragonthat was even below your 3% ;-)
13:27:47amiconnTalking menus and talkbox works as well
13:27:52amiconn*work
13:29:11[IDC]Dragonand the voice file can be 167 KB larger
13:33:52[IDC]Dragonit is left to be tested if the ROM version actually improves runtime
13:34:07amiconnyup
13:34:56amiconnplaying the same dir over and over again, measuring runtime
13:35:11amiconnSame would go for video playback
13:36:19[IDC]Dragonvideo playback doesn't run much ROM code
13:36:31[IDC]Dragonbut benefits from larger buffer
13:36:54[IDC]DragonLinusN: the credits should be const
13:37:38[IDC]Dragonthe settings tables
13:37:56amiconnI'll look into const'ing after doing some runtime test (just started charging my box)
13:38:07amiconn*tests
13:38:33amiconnPerhaps I should use low capacity cells for the runtime tests...
13:38:56[IDC]Dragonor an ampere meter
13:39:09[IDC]Dragonwith PC readout
13:40:16[IDC]Dragonmore const: mp3 sound setting tables (not that big)
13:40:54[IDC]Dragonsearching for [] finds many initialized arrays
13:41:42amiconnI prefer real world data - using an amp meter, I'd have to measure with a high time resolution
13:42:02[IDC]DragonLinusN: are the language strings overloaded by .lng file content?
13:42:30 Quit midk|sleepy (Read error: 104 (Connection reset by peer))
13:42:47LinusNyes
13:42:59LinusN(i think)
13:43:06[IDC]Dragonthen this is no const
13:43:34amiconnJust found a 4-set of 1200 mAh NiMH cells - will use that for measurement, and charge them in an external charger
13:44:01[IDC]Dragonthat test will take a while...
13:44:46[IDC]Dragonhow do you determine when it shut down?
13:45:01[IDC]Dragonyou're not watching it, right?
13:45:07amiconndebug->view runtime
13:45:31[IDC]Dragonah, that's what this is for
13:45:34amiconnBtw, is there a way to reset the top runtime?
13:45:44[IDC]Dragonreset the settings
13:45:51amiconnAh ok
13:52:25amiconn"Monsters" in .data (data blocks larger thatn 256 bytes):
13:54:28amiconn(difficult to find, since not all of them have a public symbol)
13:54:57[IDC]Dragonthe menus are many small ones, but still worth it
13:55:38amiconnlanguage_strings, credits, rockbox logo, icons, sysfont
13:56:20[IDC]Dragonthe logo, ah, yes
13:56:24amiconnThe quoted strings should be const automatically
13:57:10[IDC]Dragonas discussed, the language strings are probably overloaded
13:57:23[IDC]Dragonhave you tried a .lng file?
13:57:38[IDC]Dragonor are you running german anyway?
13:57:53amiconnI'm running German, yes
13:58:32amiconnCurrently the language strings are not declared const (I looked into rockbox.map what ended up in the data section)
14:00
14:02:03amiconnI wonder if it is possible to declare an array in such a way that the array data itself is considered const, while the array variable itself (= the pointer) is not
14:04:53amiconn(without declaring an extra variable, that is)
14:05:35LinusNthe array "variable" is not a pointer, it's a symbol
14:07:04***Saving seen data "./dancer.seen"
14:08:54amiconnLinusN: If I declare char blah[] = "foobar"; blah[0] is equivalent to *blah , so blah is a pointer, or did I miss something?
14:09:32LinusNit is not equivalent
14:09:55LinusNif blah was a pointer, you could do this:
14:10:06LinusNbla = 0;
14:10:11LinusNbut you can't
14:10:37LinusNa common mistake in C is to confuse arrays for pointers
14:11:50amiconnOk. How come the compiler warns me if I do the following:
14:12:32amiconnconst char blah[] = "foobar"; char *ptr; ......... ; ptr = blah;
14:12:52amiconnwhile if I leave out the "const", it doesn't warn?
14:13:21amiconn(iirc)
14:14:16LinusNmaybe because blah[] is an array of constant chars, while ptr is a pointer to non-constant chars?
14:15:14amiconnThat may be the point, but if I declare const char *ptr; the pointer itself might end up in .rodata?
14:15:49LinusNprobably not
14:16:08LinusNif you declare it char * const ptr, it will
14:16:12amiconnIt should be possible to do this if we want to gain some more ram space when running from rom
14:16:39LinusNor maybe char const * ptr...
14:17:38amiconnI think I'll have to try it out.
14:17:56LinusNare you trying to put the lang strings in ROM?
14:18:26amiconnThis goes for the default lang strings as well as for the rockbox logo, the sysfont...
14:19:51LinusNis the logo a problem?
14:19:52 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
14:21:20amiconnI'll look into it after doing some runtime tests, but I remember that you once changed convbdf to declare the sysfont const
14:21:29amiconnThis lead to a number of warnings...
14:23:24LinusNyeah, the sysfont is rotated at boot
14:24:39amiconnArgh, then either it can't be declared const, or it has to be rotated at compile time
14:26:11amiconn(Should have remembered that, since I fiddled with font.c when changing lcd_bitmap() )
14:27:24[IDC]Dragonaargh, rotation is no good
14:29:24[IDC]Dragon(for const)
14:31:41amiconnIirc the fonts are in a somewhat standard (miniwin?) format on disk, while they have to be in the rockbox native bitmap format in ram
14:32:26[IDC]Dragonfrom disk to RAM is a different story
14:33:05[IDC]Dragonbut it would be good if the system font, which we never kick out, can be directly used from ROM.
14:33:13amiconnconvbdf delivers the same format as a source code array when converting the sysfont at compile time
14:33:43amiconnI think this could be changed to deliver an already rotated array
14:42:19LinusNsure
14:52:18lImbusamiconn: I just read you are using debug->runtime. I remember having seen the setting in the past with a short unsigned => wrap at 9 hours. has it changed in the meantime ?
14:52:18 Quit AciD` (Read error: 104 (Connection reset by peer))
14:52:31 Join AciD` [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net)
14:53:34LinusNlImbus: should be 18 bits
14:53:54amiconnlImbus: [IDC]Dragon reported that while writing the new settings code; I always wondered what this was about, since I couldn't observe a wrap
14:54:06[IDC]Dragonnow it is 18
14:54:18lImbus18 ought to be enough ;-)
14:54:51[IDC]Dragon3 days
14:54:51lImbus72 hours.
14:55:02CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
14:55:02*lImbus wants to see these batteries
14:55:03amiconnThe thing is that I didn't observe a wrap even with the old settings code, and I did get runtimes >10 h. Weird
14:56:18amiconn(Perhaps not, since unsigned short is sufficient for >18 h)
15:00
15:03:13[IDC]Dragonamiconn: did you notice how fast the logo appears if you run from ROM? :-)
15:03:38[IDC]Dragon(and maybe even faster once it's const)
15:04:10amiconnYeah... no decompression necessary
15:08:13elinenbeamiconn, [IDC]Dragon, LinusN: is the benefit or rombox just to increase the MP3 buffer, or could the plugin/voicebox/JPEG/movie buffer be increased as well? Also, what happens if the firmware outgrows the ROM on the system?
15:09:10amiconnelinenbe: The mp3 buffer is used for the voice file and video playback as well, so these do benefit from rombox
15:09:40amiconnThe plugin buffer is declared fixed, so it doesn't make a difference for plugins
15:09:59[IDC]Dragonand if we're out of ROM space, we have to either save or kick out the Archos s/w
15:11:11[IDC]Dragonfor the FM, we're out of space for this kind already
15:13:47lImbusthere could be an emergency rockbox where the archos s/w is at the moment
15:14:26amiconn...or an .ajz loader, as [IDC]Dragon suggested
15:15:42[IDC]Dragonbut we need to fix the charging for such
15:16:02lImbusdoes everybody understand the need of that file then ? (i've seen many people deleting files not needed until they reach msdos.sys)
15:16:07amiconndeclaring the logo const saves 560 bytes, but leads to a warning when compiling main_menu.c:
15:16:30[IDC]Dragoncurrently, F1+Plugin is the workaround for starting with flat batteries
15:16:32lImbusif it's gone, there is no way (for noobs) to get it there when they NEED it.
15:16:50amiconnmain_menu.c:72: warning: passing arg 1 of `lcd_bitmap' discards qualifiers from pointer target type
15:17:17amiconnlImbus: Of course the .ajz loader should be able to handle usb detection as well
15:17:27[IDC]Dragonamiconn: you will find lots of these when const'ing stuff
15:18:09[IDC]Dragonsome follow-up work on the pointers using const arrays
15:18:12amiconn[IDC]Dragon: I know that these come up, so I have to find a way to avoid them.
15:18:23[IDC]Dragonthey also need to be const
15:19:42amiconnI always wondered why some pointer arguments to functions are declared const ... it seems that I just understood the reason
15:20:06[IDC]Dragonyou will be themaster of const very soon
15:20:13 Join Strath [0] (~mike@dgvlwinas01pool0-a207.wi.tds.net)
15:20:13amiconn;-)
15:20:56[IDC]Dragonnotice the difference between a constant pointer versus a pointer to contant data
15:21:54[IDC]Dragonreading the declaration in reverse is a good way to understand it
15:22:22Strathjust uploaded a little bit of an update to http://www.donat.org/archos/
15:22:26[IDC]Dragonhi Strath, how's the Gmini?
15:23:15amiconn[IDC]Dragon: So a pointer to constant data (that's what I need most of the time) is declared "const char *ptr", while a constant pointer is declared how?
15:24:51Strathnot too bad dragon, there is now three people working on it, and we're moving forward again
15:25:14[IDC]DragonI think: char * const ptr
15:25:48Strathbut i've only had 2 * 3 hours of sleep in the last 72 hours... it's *really* time for bed
15:25:50[IDC]Dragonread it in reverse: ptr is a constant pointer to a char
15:26:21 Quit Strath ("Client closed")
15:26:44[IDC]Dragonversus in your first example ptr is a pointer to a char which is constant
15:33:42amiconnSo I think all pointer arguments to functions which do not change the data the pointer points to should be changed into pointers to const data
15:33:56amiconnFirst one will be lcd_bitmap()
15:41:53amiconnGrr, this involves changes in 6 files
15:48:17amiconnIt works! :))
15:48:36[IDC]Dragoncongratulations!
15:49:20[IDC]Dragonyou may need to touch many files, this is true
15:49:25amiconnI face the job of wading through the source, looking for pointer arguments that should be const'ed
15:49:48[IDC]Dragontrue, my friend
15:50:06LinusNhave a nice evening :-)
15:50:32*[IDC]Dragon calls the const police
15:51:05amiconnI think I'll take the challenge... expect me to gradually commit my changes
15:51:27[IDC]Dragonyou're most welcome
15:51:39amiconn(actually const'ing the logo "only" requires changing 5 files)
15:52:25amiconnicons.c, icons.h, lcd-recorder.c, plugin.h and lcd.h
15:53:13[IDC]DragonI did this in a sloppy way before, but discarded my changes
15:53:52LinusNgotta go, cu around
15:53:59amiconnbye lImbus
15:54:04amiconnoops I mean LinusN
15:54:05[IDC]Dragoncu LinusN
15:54:05LinusN:-)
15:54:11 Part LinusN
15:54:20[IDC]Dragontoo early tab completion
15:54:25amiconnyup
15:54:49[IDC]DragonI'm "angry" about lImbus' nick, too
15:55:55[IDC]Dragonamiconn: we're prepared for some colorful builds ;-)
15:56:31amiconnUsually I test my changes locally before committing (at least player/recorder and the respective sims)
15:56:49[IDC]Dragonthe sims usually kill me
15:57:14[IDC]Dragonand a warning is easily overlooked
15:57:19amiconnAnother challenge will be extending the configure script and Makefile to easily allow for rombox builds
15:57:33[IDC]Dragon(no color in my bash console)
15:58:03[IDC]Dragonsounds like a job for Daniel
15:58:06amiconnI usually compile with make >make.log, so all informative output will go to that file. Only warnings and errors show up in the console
15:58:26[IDC]Dragonah, good hint
15:58:59amiconnYou could also use make >/dev/null (didn't try that within cygwin though)
16:00
16:00:06amiconn1.794 MB buffer :)
16:00:20[IDC]Dragonthe start address for the build is currently hard-coded, as you know
16:01:00[IDC]Dragon1KB gained, hoorray!
16:01:05amiconnYes... we'll have to find a way how to change that (or make it really constant)
16:03:06amiconnThe total size of the .data segment is ~11 KB, so that's the upper limit of possible gain
16:03:15[IDC]Dragonoooh
16:03:25[IDC]Dragonno more?
16:03:42[IDC]Dragonhave you done the credits?
16:04:09amiconnNot yet, only the logo (as first exercise)
16:04:59[IDC]Dragoncredits are >1KB
16:06:12amiconnCode is ~150 KB, rodata ~17 KB
16:07:06***Saving seen data "./dancer.seen"
16:08:25[IDC]DragonI'm not sure which parts get into ROM without being const
16:08:45[IDC]Dragonmaybe the credits do
16:09:22[IDC]Dragonthe plugin API table has >100 entries, so >400 bytes
16:11:53[IDC]Dragonthe ID3 genres are already const, for a change
16:12:10amiconnThe credit strings seem to go into rom by default, since credits take up 324 bytes in the data sections, which equals to 81 pointers
16:12:23amiconn*section
16:12:34[IDC]Dragonthe pointers don't, aha
16:15:33amiconngrr, another function that needs a const * argument: lcd_putsxy()
16:22:05amiconnCredits pointers now in rom; credits still work...
16:26:42amiconnIn fact, I had to write const char* const credits[] = ... to get the pointer array into rom
16:36:02amiconnsysfont is almost 4 KB
16:45:00[IDC]Dragonsorry, I was afk
16:46:23[IDC]Dragonfont needs to be rotated, hmm, this doesn't come so easy
16:46:44amiconnI know, just fiddling with the icons
16:47:08[IDC]Dragonthe menus are another candidate
16:47:23amiconnplaylist_viewer.c doesn't use icons.h but declares bitmap_icons_6x8 by itself, urgs
16:48:07[IDC]Dragononce you const the menu function argument, the compiler will tell you where to change the menu struct arrays
16:48:17amiconnIn fact, it does include icons.h
16:48:55 Join dstar5 [0] (lee@ACC751AA.ipt.aol.com)
16:48:57amiconn(why it does declare bitmap_icons_6x8 again is beyond me)
16:49:23[IDC]Dragonsorry, I'm not following (and not trying to)
16:54:20amiconnbitmap_icons_6x8 is declared in icons.h. Both playlist_viewer.c and tree.c did include icons.h, and the declared bitmap_icons_6x8 again
17:00
17:06:51 Nick lImbus is now known as _lImbus (~manuel@kernel.cycos.net)
17:08:19[IDC]Dragonhave to leave now, cu later
17:08:33 Quit [IDC]Dragon ("no fate but what we make")
17:11:18 Join mecraw__ [0] (~lmarlow@69.2.235.2)
17:14:42 Nick tomsleep is now known as kaboofa (~kaboofa@pcp03462569pcs.indpnd01.mo.comcast.net)
17:18:44dstar5hey kaboof!
17:18:56kaboofawhat's up :)
17:20:26kaboofayeah, i am convinced i have the best keyboard in the history of keyboards :)
17:20:33kaboofaOld old IBM model from 1984
17:20:36kaboofano windows
17:20:37kaboofakey
17:20:39kaboofa:D :D :D
17:20:49kaboofaand it's mechanical, so I can hold down like 18 keys all at the same time
17:20:53kaboofaand they all get registered
17:26:50 Join Lee_ [0] (lee@ACC31159.ipt.aol.com)
17:27:18 Quit dstar5 (Nick collision from services.)
17:27:29 Nick Lee_ is now known as dstar5 (lee@ACC31159.ipt.aol.com)
17:38:59dstar5kaboofa cool keyboard :) i missed your text, my internet conection failed
17:39:25kaboofaheh
17:39:48*dstar5 hates AOL very very much
17:39:51kaboofaheh
17:39:55*kaboofa <3s speakeasy dsl
17:40:30dstar5heh the local university (OSU) has way faster than a dsl
17:40:40dstar5i have been downlading at 100mbits
17:40:47dstar5:)
17:40:57dstar5the fastest the nic can handle
17:49:04kaboofaheh
17:49:12kaboofai have a server on a oc 48 :D
17:49:15kaboofaan
17:51:54dstar52.488 Gbps
17:51:56dstar5nice
17:52:12dstar5to bd you can not download at that speed anywhere :(
17:52:39dstar5unless you are downloading right next to the server
17:52:39dstar5lol
17:56:41dstar5how much do those lines cost a month?
17:56:52amiconnGrr, I don't understand why the filetypes mechanism doesn't work when running from ROM
18:00
18:07:09***Saving seen data "./dancer.seen"
18:22:09 Join midk [0] (~Zakk@c-24-18-39-204.client.comcast.net)
18:22:09 Quit Nibbler (Read error: 104 (Connection reset by peer))
18:30:43_lImbushi midk
18:31:02midkhi _lImbus
18:32:59_lImbusuhm. can't link the new alternate nick to the primary one...
18:33:19midkalternate nick?
18:33:24_lImbus_lImbus:
18:33:29midklink?
18:34:10dstar5you want to be lImbus?
18:34:21_lImbushttp://freenode.net/faq.shtml
18:34:28_lImbusI am lImbus
18:34:31midkdo /nick lImbus
18:34:47_lImbus[IDC]-Dragon has some problems with that nick, too similar to LinusN
18:35:01midkahh
18:35:10_lImbuslImbus is registered, I want to link _lImbus to lImbus
18:35:17midkjust re-register.
18:35:18_lImbuslike described in faq
18:36:28_lImbusahh tnx, worked
18:36:53_lImbusreregistering before linking was not logical to me, and was not explained in faq
18:36:56_lImbustnx
18:37:05midkyou don't have to link it...
18:37:08midkbut np.
18:37:45_lImbusI linked them together, so I suppose there is only one memo-account e.g.
18:38:03midkgood job.
18:38:19midkbut if you usually come in as _lImbus then people will just memo that one.
18:38:32midk:D
18:39:41_lImbusto how did you send that memo ? I got a query from memoserv, so the correlation is set up
18:39:50midk:D
18:39:54midki send it to you..
18:39:55midkoh sec
18:40:18midksent one to lImbus
18:40:28midkyay
18:42:23_lImbusdon't you use opera as irc-client too ?
18:42:44dstar5me use xchat
18:42:47midkno no
18:42:48midkxchat
18:42:52midkxchat good.
18:43:26_lImbusok. must have been either zeekoe or kaboofa (kaboofa_) then
18:43:57midkprobably zeekoe.:p
18:51:50 Join Bazi [0] (~Baz@80.229.144.229)
19:00
19:24:32 Quit Ka_ (sterling.freenode.net irc.freenode.net)
19:24:32NSplitsterling.freenode.net irc.freenode.net
19:24:32 Quit elinenbe (sterling.freenode.net irc.freenode.net)
19:25:05dstar5netsplit :(
19:25:11midkooh, really?
19:25:52dstar5yes actauly
19:25:56NHealsterling.freenode.net irc.freenode.net
19:25:56NJoinKa_ [0] (~tkirk@pcp04776551pcs.howard01.md.comcast.net)
19:25:56NJoinelinenbe [0] (trilluser@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
19:26:10dstar5yay
19:26:10dstar5:)
19:38:59 Join zeekoe [0] (~zeekoe@ip51cc69f6.adsl-surfen.hetnet.nl)
19:46:40 Join mexi` [0] (Tommy@ip94.130.1511G-CUD12K-03.ish.de)
19:46:49mexi`hallo? anybody there?
19:47:06midkhi.
19:47:27mexi`i have a problem with my jukebox... it always says "HD error" when i try to start it
19:47:40mexi`do you know any help?
19:48:01midkis your hd dead?
19:48:15mexi`i hope it's not, but i can't tell...
19:48:43midkfunny noises?
19:48:44midklack of noises?
19:49:11mexi`these clicks, when i put the usb in it
19:49:21midkodd clicks?
19:49:28midksounds like a mechanical problem..
19:49:28mexi`yes
19:49:35midkas in, hard drive failure..
19:50:18mexi`i had the same noises when the batteries where empty. after loading them, the noises where gone
19:51:25mexi`is there anything there that would help if it was a hard drive failure?
19:51:33midkdoubtful...
19:51:39midkbe back soo
19:51:41midkn
19:51:44 Quit midk (Read error: 104 (Connection reset by peer))
19:51:45mexi`hmm...
19:52:46dstar5can yo plug in USB?
19:53:02 Quit Bazi (Remote closed the connection)
19:53:06dstar5ahh clicks...
19:53:15dstar5is this a player/studio unit?
19:54:14kaboofauh oh
19:54:17kaboofaclicks
19:54:32dstar5it may be dead batteries...
19:54:39kaboofaWHOO!! MY DRAGON LEVELD UP!!!
19:54:46kaboofaYEAH!!!
19:54:50kaboofa<3 <3 <3
19:54:59kaboofayes kids, drakengard = addiction
19:55:15 Join Nibbler [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de)
19:55:25kaboofachapter 4: betrayal
19:55:36zeekoeayreon?
19:55:56kaboofaeh?
19:56:08zeekoe:P
19:56:15dstar5mexi`: are you there?
19:56:22kaboofaoh
19:56:25zeekoenah... that's day15-betrayal
19:56:29kaboofai hope i get this chaos dragon thingie
20:00
20:01:58 Join scott666 [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
20:06:41dstar5yo scott666
20:07:13***Saving seen data "./dancer.seen"
20:18:09 Part mexi`
20:27:18 Quit zeekoe (Read error: 110 (Connection timed out))
20:28:50scott666hey diddy
20:45:37dstar5bye
20:45:39 Quit dstar5 ("Leaving")
20:59:23 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net)
21:00
21:03:19kaboofabah
21:03:29kaboofajust burned the hell out of my finger because of my sodering iron
21:05:41midkgood work!
21:06:30elinenbeamiconn: how is rombox going?
21:07:05amiconnThe dynamic filetypes mechanism doesn't work when romboxed - I'm just splash-debugging it
21:09:31amiconnIf I get that bug squashed, I'll provide a test version for those who are willing to help me finding the remaining bugs
21:09:53amiconnUnfortunately this is currently only possible with the recorder v1
21:16:51 Join OPP89 [0] (~dshier89@adsl-68-255-21-48.dsl.emhril.ameritech.net)
21:16:55OPP89hello
21:18:28 Join [IDC]Dragon [0] (~idc-drago@pD95120CC.dip.t-dialin.net)
21:18:33amiconnhi Jörg
21:18:50[IDC]Dragonhi Jens
21:19:00amiconnDid you read the logs?
21:19:23[IDC]Dragona bit
21:19:59 Quit AciD` (Remote closed the connection)
21:20:32amiconnI wonder why the filetypes mechanism doesn't work when romboxed. Just found that the file open for the viewers.config fails (-4)
21:21:07[IDC]Dragonmaybe this is like the file open I was remembering?
21:21:37amiconnYes, maybe. I have to find out why this open fails, while others seem to work
21:23:02[IDC]Dragonback in time we didn't have the dynamic file types
21:23:35 Quit midk ("just STOP it arspy")
21:23:35[IDC]Dragonmaybe some path/name is tried to modify, while being in ROM
21:23:54[IDC]Dragonis that all you've found?
21:25:23amiconnUntil now, yes. I stopped const'ing things when I found that, suspecting my changes causing it. However, this occurs with plain cvs too.
21:25:37 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
21:26:20[IDC]Dragonthen I guess you can commit what you've done so far
21:29:19 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net)
21:29:20amiconn-4 means open() couldn't open the dir, and the open function tampers with the path/filename strings, while declaring it const char * (!) Argh!!!!
21:32:50amiconnI wonder if the argument declaration for open() is an ANSI requirement - if yes, the open function would need an internal buffer for copying the string, what in turn would impose a length limit
21:37:44[IDC]Dragonopen() is POSIX, not ANSI
21:39:53amiconnStill I need to know if the "const" in open(const char *pathname, int flags); is a standards requirement
21:40:04[IDC]Dragonhang on
21:41:04amiconnSame goes for creat(), remove() and rename()
21:41:59amiconnAll these use open(), and open tampers with the string in a way that it temporarily replaces the last "/" with a "\0" to separate path and filename
21:42:34[IDC]Dragonfor walking the dirs, I remember
21:42:51amiconnFor the opendir() call, yes
21:42:52 Part _lImbus
21:43:18[IDC]Dragonsee this: http://cplus.kompf.de/posixlist.html#ToC1
21:43:53[IDC]Dragonopen takes a const argument
21:44:34amiconnSo if we want to retain posix compatibility (and I guess we want to do that), the open function has to copy the pathname internally
21:45:05[IDC]Dragonand only the open() calls with a fixed neme file, correct?
21:45:30[IDC]Dragonmp3 playback works because the names are dynamically composed?
21:45:43amiconnYes, as well as the plugin loading.
21:46:04[IDC]Dragonwith a fixed name fail, I mean
21:46:26 Quit OPP89 (Read error: 104 (Connection reset by peer))
21:47:11[IDC]Dragonwe can peek at OpenNeo, if and how they changed it
21:47:25[IDC]Dragonthe Neo runs from ROM
21:47:25 Quit AciD (Read error: 54 (Connection reset by peer))
21:49:08[IDC]Dragonwhich code are you looking at?
21:49:18amiconnFunny enough, opendir(), which does need to separate the path components further, does copy the string internally.
21:49:34amiconnfirmware/common/file.c
21:49:40amiconnand dir.c
21:50:11amiconnThe problematic call comes from apps/filetypes.c, line 446
21:50:38amiconnfd == -4 after that
21:50:57amiconn(when running from ROM of course)
21:51:29[IDC]Dragonquite obvious, yes
21:51:56[IDC]Dragonnice dagnosis, wee done!
21:52:00[IDC]Dragonwell
21:52:16[IDC]DragonI type like drunk today
21:52:18amiconnSplash debugging :-|
21:52:40[IDC]Dragonflash debugging
21:52:47amiconnhttp://www.ssiamerica.com/open/ ==> DB Error: unknown error :(
21:53:50[IDC]Dragonis this the official location?
21:55:27amiconnAt least it seems to be. http://www.ssiamerica.com/ talks about the neo itself; if you click on "Open neo" this dir gets called. http://www.ssiamerica.com/open/binaries/ works, but these are only the binaries.
21:55:45amiconnIt seems that OpenNeo isn't that open :-/
21:55:56[IDC]Dragondefinitely not
21:56:16[IDC]Dragonthat was subject of many discussions
21:58:15[IDC]Dragonamiconn: I think an extra buffer for open(), etc. is no problem
21:58:27[IDC]Dragonwe have a length limit anyway
21:58:55amiconnYes, MAX_PATH. I already found that
21:59:38[IDC]Dragonor we make sure that a filename never comes from ROM
22:00
22:00:14amiconnI wonder if a simple declaration of a string of that length may overflow the stack (however, this is done within opendir() so it may not be a problem)
22:00:39 Join Smooth [0] (909510b8@ACB9E508.ipt.aol.com)
22:00:58[IDC]Dragonthe directory delete has a resursion
22:01:03[IDC]Dragonrecursion
22:01:13*[IDC]Dragon checks
22:01:25SmoothHi
22:02:59[IDC]Dragonah, you already said that opendir() copies it already
22:07:16***Saving seen data "./dancer.seen"
22:11:12[IDC]Dragonamiconn: only the open() function does this patching?
22:12:28amiconnI only found it there so far. This should only be a problem if the argument is declared const anyway.
22:13:22[IDC]Dragonwhich it is
22:13:38[IDC]Dragonthe clean solution would be a copy, I'd suggest that
22:13:42amiconnI'm the const police ;)
22:13:55[IDC]Dragonyes sir yes
22:14:37[IDC]Dragonfor one project, I made a circuit to detect write access to the ROM region
22:14:48[IDC]Dragonto find bug like this
22:15:16amiconnAn MMU would be of great use here too
22:15:41[IDC]Dragonfor deluxe controllers, yes
22:15:58[IDC]Dragonin my case it was a Siemens C161
22:16:03[IDC]Dragon(16 bit)
22:16:47[IDC]Dragondid you do anything to the flash ID code?
22:16:54amiconnIn fact, rockbox is my first project to deal with controller programming.
22:17:38amiconnSo far I only dealt with "real" computers, although even back in the 8 bit era. This is why I know "a bit" about asm
22:18:03[IDC]Dragonor a byte ;-)
22:23:21 Quit Smooth ("leafChat IRC client: http://www.leafdigital.com/Software/leafChat/")
22:25:57[IDC]DragonI now remember the "old" failures from ROM: back then the viewers were hard coded
22:26:15[IDC]Dragonso it was unable to load those plugins
22:28:32[IDC]Dragonin general, it looks like Rockbox can relatively easy be fixed to run from ROM
22:29:54amiconnGrr, the MIN() macro isn't available within file.c
22:30:38[IDC]Dragonyou don't want to dynamically allocate, do you?
22:30:49[IDC]Dragonwhat do you need it for?
22:31:03amiconnNo, but I want to make sure the path part of the argument doesn't overflow my buffer
22:31:45[IDC]Dragonthen you can take the difference of the position and the start
22:32:23amiconnYes, I do that, but I have to check if this is < MAX_PATH. That's what I wanted to use the MIN() macro for
22:32:59amiconnLine 105..109 read now:
22:33:00[IDC]Dragonor use strncpy()
22:33:00amiconnpathlen = MIN(name - pathname, MAX_PATH - 1);
22:33:00amiconnmemcpy(path, pathname, pathlen);
22:33:00DBUGEnqueued KICK amiconn
22:33:00amiconnpath[pathlen] = '\0';
22:33:00amiconndir = opendir(path);
22:33:59[IDC]Dragonwhy not copy the whole pathname right at the start, then work with the copy?
22:34:03amiconnstrncpy() doesn't append a \0 byte if the source string length == n.
22:34:41[IDC]Dragondo a name[MAX_PATH] = '\0' to be sure
22:35:03[IDC]DragonMAX_PATH-1, actually
22:35:46[IDC]Dragonbut you way is more efficient
22:35:50[IDC]Dragonyour
22:36:02amiconnI f I copy the whole string, the maximum allowed length would be a bit smaller (by the filename part)
22:36:34amiconnFurthermore, memcpy() is more efficient that strncpy(). I should know that one ;-)
22:36:54[IDC]Dragonthat's what I meant.
22:37:29[IDC]Dragonopendir is just using strncpy+forced termination.
22:37:52 Quit midk (Read error: 104 (Connection reset by peer))
22:37:53[IDC]Dragon strncpy(namecopy,name,sizeof(namecopy));
22:37:53[IDC]Dragon namecopy[sizeof(namecopy)-1] = 0;
22:37:59amiconnMaybe the next thing to do after romboxing is optimizing the other string functions (at least those that are used often)
22:38:28[IDC]DragonI don't think they are used in tight code
22:38:58[IDC]Dragonand optimized implementations tend to get lengthy
22:39:21 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net)
22:39:25amiconnRemember that memchr() / strchr() & co can be done much more effiecient with a special asm instruction that is never used by gcc?
22:39:59amiconncmp/str compares 4 bytes in one clock cycle
22:45:04amiconnOf course the straight copy thing is the easier solution
22:48:04[IDC]Dragoninteresting instruction, no, I don't remember that one
22:48:23 Join Smooth [0] (909510b8@ACB9E508.ipt.aol.com)
22:48:26 Quit Smooth (Client Quit)
22:48:53amiconnYou once asked for a fast memchr() which I offered to do. I would have used this very instruction for it.
22:49:12[IDC]Dragon:-)
22:50:21 Join lImbus [0] (lImbus@185.107-200-80.adsl.skynet.be)
22:50:32amiconnWith the modified open() function it works (I took the simple approach for now)
22:50:40 Nick lImbus is now known as _lImbus (lImbus@185.107-200-80.adsl.skynet.be)
22:50:42[IDC]Dragongreat
22:50:59[IDC]Dragonhow often have you flashed today?
22:51:27amiconnErr ... umm ... I didn't really count. Perhaps 10..20 times
22:52:09[IDC]Dragondo you want me to fix the flash ID code?
22:52:21[IDC]Dragon(placing it in IRAM)
22:53:14amiconnThis would have been my next step - if you would do that - great.
22:53:31amiconn(Just checking the builds for warnings)
22:54:01_lImbus[IDC]Dragon, is my new nick ok ? I would really appreciate keepin something with 'lImbus' in.
22:54:24[IDC]Dragon_lImbus: don't change it, I wasn't serious
22:54:36_lImbusmhmm. das sah aber nicht danach aus.
22:54:56[IDC]Dragondu hast mich gar nicht gesehen ;-)
22:55:17_lImbusmaybe it fed up somebody else (amiconn?) too, so this may be a good solution.
22:56:48amiconn_lImbus: I should look at tab-completed nicks before hitting return, so it was my fault anyway
22:58:34amiconn<[IDC]Dragon> too early tab completion
22:58:34amiconn[15:54:33] <amiconn> yup
22:58:34amiconn[15:54:57] <[IDC]Dragon> I'm "angry" about lImbus' nick, too
22:58:50_lImbusyeah, that was it ;-)
22:59:04amiconnIt was not me that was angry...
22:59:12[IDC]Dragonsee, it was in quotes
22:59:32_lImbusyup, I see. I tought idc was angry too, so must have been ami.
22:59:41_lImbuswell. I changed it on two clients now. We remember it' s no odds, so we take the easy solution: keeping as it is atm
22:59:51[IDC]Dragon_lImbus is very sensitive...
23:00
23:00:14CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
23:00:14*[IDC]Dragon feels sorry
23:00:24_lImbusthat means ? better or worse ? (english is my fourth language98
23:00:26_lImbus)
23:01:12_lImbusshould I go back ? this would be for good then (i hope)
23:02:01[IDC]Dragonyou're most welcome to freely pick your nick
23:02:22amiconn_lImbus: I preferred your former nick. Nicks with special chars in front are not so easy to enter, even with tab completion, as they require finger acrobatics on the keyboard ;)
23:02:23[IDC]Dragonmake it LinusM if you like
23:04:08_lImbusnoooo
23:04:34_lImbusLimbus (with lImbus) is my nick since a few years, this is why I want to keep it.
23:04:50_lImbusso I'll go back to lImbus for good.
23:05:00 Nick _lImbus is now known as lImbus (lImbus@185.107-200-80.adsl.skynet.be)
23:06:36midkyyyyyaaaaaaaaaaaaaay
23:09:37scott666long live lImbus
23:17:59 Quit midk (Remote closed the connection)
23:18:45 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net)
23:22:10[IDC]Dragonamiconn: fix to debug_menu.c committed, can you try it out?
23:23:10amiconnyup
23:23:28[IDC]Dragongotta leave now
23:23:38[IDC]Dragonthanks and bye
23:23:46 Quit [IDC]Dragon ()
23:48:03 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net)
23:49:29elinenbeamiconn: nice commits −− how long until rombox is a reality?
23:51:36 Quit midk (Read error: 104 (Connection reset by peer))
23:52:36amiconnIt depends - hunting for other bugs is necessary, and in order to work for the v2/fm, the flash image has to be changed to only contain a .ajz loader, otherwise it won't fit
23:52:40 Join midk [0] (~midk@c-24-18-39-204.client.comcast.net)
23:53:23amiconnRemember that flashing doesn't currently work when running from flash (for obvious reasons)
23:54:07amiconnSo if you want to update rombox, you first have to rolo into ram-based rockbox

Previous day | Next day