--- Log for 04.10.104 Server: burroughs.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 16 hours ago 00.51.22 DEBUG Lost contact with server (snapshot: netstuff.c line 597) 00.51.22 *** Saving seen data "./dancer.seen" 00.51.22 *** Cleanup 00.51.22 *** Cleanup 00.51.22 *** No seen item changed, no save performed. 00.51.22 *** Exit 00.51.22 *** Started Dancer V4.16 00.51.22 *** Connected to irc.freenode.net on port 6667 00.51.22 *** Logfile for #rockbox started 00.51.23 *** Server message 501: 'logbot :Unknown MODE flag' 00.51.23 Mode "logbot :+i" by logbot 00.51.23 Join logbot [242] (~bjst@labb.contactor.se) 00.51.23 Join gromit`` [0] (~gromit@ALagny-151-1-41-197.w83-114.abo.wanadoo.fr) 00.51.23 Join bagawk [0] (Lee@bagawk.user) 00.51.23 Join amiconn [0] (~jens@pD9E7F9E4.dip.t-dialin.net) 00.51.23 Join mattzz [0] (~mattzz@c227123.adsl.hansenet.de) 00.51.23 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 00.51.23 Join DeepB [0] (~x@107.Red-217-127-93.pooles.rima-tde.net) 00.51.23 Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) 00.51.23 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 00.51.23 Join Ka_ [0] (~tkirk@pcp261180pcs.howard01.md.comcast.net) 00.51.23 Join Hadaka [0] (naked@naked.iki.fi) 00.51.23 Join mbr [0] (~mb@stz-softwaretechnik.com) 00.51.23 Join plok [0] (s336156@student.uq.edu.au) 00.51.23 Join dwihno [0] (~dw@81.8.224.89) 00.51.23 Join elinenbe [0] (~elinenbe_@65.115.46.225) 00.51.23 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 00.51.23 Join ze [0] (psyco@adsl-63-205-44-84.dsl.lsan03.pacbell.net) 00.51.23 Join silencer- [0] (~silencer@zen.via.ecp.fr) 00.51.23 Join webmind [0] (~random@217-195-236-172.dsl.esined.net) 01.00.03 # hi logbot :) 01.00.23 Quit bagawk ("umount /dev/brain") 01.00.38 Quit _aLF ("bye") 01.07.42 # :)) mmc driver is now faster for writing as well: 17..80 % 01.18.57 Quit plok ("Leaving") 02.05.58 Quit mattzz ("Client exiting") 02.09.16 Part amiconn 02.51.24 *** Saving seen data "./dancer.seen" 02.59.45 Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc) 03.02.36 Join iRiverMan [0] (~acbfbf7f@labb.contactor.se) 03.02.43 # hi 03.28.35 Quit iRiverMan ("CGI:IRC (Ping timeout)") 03.33.41 Quit silencer- (Read error: 104 (Connection reset by peer)) 04.25.06 Part DeepB 04.51.27 *** Saving seen data "./dancer.seen" 05.01.19 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) 06.23.50 Quit scott666_ ("i'll be back...eventually...") 06.23.50 Quit kramerica (Read error: 104 (Connection reset by peer)) 06.51.31 *** Saving seen data "./dancer.seen" 06.53.39 Join LinusN [0] (~linus@labb.contactor.se) 07.12.58 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) 07.16.11 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 07.55.50 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 07.57.33 Quit AciD (Read error: 110 (Connection timed out)) 08.00.04 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 08.02.08 Join webguest28 [0] (~401829cb@labb.contactor.se) 08.03.26 # test 08.03.58 Quit webguest28 (Client Quit) 08.20.46 Join amiconn [0] (~jens@pD9E7F9E4.dip.t-dialin.net) 08.20.48 Quit kramerica (Read error: 232 (Connection reset by peer)) 08.38.34 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 08.41.02 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) 08.49.48 Join webguest80 [0] (~d996a082@labb.contactor.se) 08.50.27 Part webguest80 08.51.34 *** Saving seen data "./dancer.seen" 08.58.22 Join [IDC]Dragon [0] (~idc-drago@p50861B66.dip.t-dialin.net) 08.58.58 # <[IDC]Dragon> Hello Jens, do you read? 09.07.33 # [IDC]Dragon: better call for "amiconn", as his IRC client might call for his attention when seeing his nick 09.07.42 # at least mine does 09.08.11 # <[IDC]Dragon> just trying to be nice at first ;-) 09.09.02 # <[IDC]Dragon> LinusN: did you read about the interrupted playback from MMC? 09.09.57 Join Zagor [242] (~bjst@labb.contactor.se) 09.10.03 # <[IDC]Dragon> perhaps the mpeg thread needs some fine-tuning wrt initial load, chunksize, etc. 09.10.18 # <[IDC]Dragon> Hi Zagor! 09.10.26 # ih 09.10.28 # hi 09.10.59 # <[IDC]Dragon> how was the Rockbox-free weekend? (I also had one) 09.11.32 # very good, thanks. i went up north and spent the weekend outdoors. 09.13.24 # [IDC]Dragon: no, i haven' 09.13.31 # t heard about iinterrupted playback 09.13.48 # i also had a rb free weekend :-) 09.14.21 # [IDC]Dragon: i think it might have to do with the dynamic watermark levels 09.14.29 # <[IDC]Dragon> playback works now (I goofed), a bit jerky 09.14.53 # <[IDC]Dragon> but we better discuss that when amiconn is alert 09.14.57 # they are calculated from the disk spinup time, doesn't really apply to mmc 09.15.26 # <[IDC]Dragon> spinup is fast, transfer is slow ;-) 09.15.41 # <[IDC]Dragon> thanks to our SH 09.15.52 # so we need to revise the watermark handling 09.16.19 # we need to do that anyway, since the spinup time measurement bugs 09.16.37 # <[IDC]Dragon> do you think so? what would happen if spinup time measures very fast? 09.17.23 # the watermark level will be set quite low 09.17.30 # <[IDC]Dragon> so? 09.17.56 # and there is increased risk of buffer underrun 09.20.36 # * [IDC]Dragon loads some songs on the ondio 09.23.08 # <[IDC]Dragon> USB1 is slooow 09.25.32 Quit Nibbler (Read error: 238 (Connection timed out)) 09.49.58 # [IDC]Dragon: Now I'm around. And: My client alerts me if either my realname or my nick is mentioned. Of course this only helps when I'm around ;) 09.49.59 Quit kramerica (Read error: 54 (Connection reset by peer)) 09.52.41 Join MisticJeff [0] (~MisticJef@lv-65-173-87-243.dyn.sprint-hsd.net) 09.53.08 # Zagor, LinusN... good morning 09.53.13 # morning 09.53.24 # did you get my email 09.55.20 # yes 09.56.26 # MisticJeff: morning 09.56.43 # good morning 09.57.14 # don't know whether that will work for you or not but thought i'd throw it out there 09.57.35 Join amiconn_ [0] (~jens@pD9E7E4F2.dip.t-dialin.net) 10.02.45 Join ashridah [0] (ashridah@220.253.120.65) 10.03.24 # Zagor: I and LinusN discussed how to deal with the wildcard sources concept now when iriver enters 10.04.00 # I suggest we introduce a concept with a special file like 'SOURCES' that is preprocessed that mention what source files to build 10.04.21 # i think that's the way to go 10.04.26 # sounds good 10.04.33 # (so LinusN's weekend wasn't _entirely_ rb-free :-) 10.04.40 # :-) 10.05.08 # ok, so I'll start working on setting up such a concept 10.05.33 Join kramerica [0] (~lkd@207.195.113.154) 10.05.38 # it'll be easier to build for iriver target once we have that fixed 10.05.40 # funny, the iriver has separate i2c busses for each i2c slave... 10.05.49 # Bagder: great 10.09.31 Quit amiconn (Nick collision from services.) 10.09.32 Nick amiconn_ is now known as amiconn (~jens@pD9E7E4F2.dip.t-dialin.net) 10.10.58 Quit [IDC]Dragon (Read error: 110 (Connection timed out)) 10.11.58 # -m1 is a sh-specific gcc option, isn't it? 10.12.06 # yes 10.12.16 # needs to be moved to configure then 10.12.37 # it's supposed to be -m5349, but the gcc docs are lying 10.13.26 # so what is it? 10.14.18 # lemme check 10.15.31 # -m5200 might do 10.16.34 # ok 10.17.15 # -fomit-frame-pointer -fschedule-insns is only used in the apps makefile 10.17.19 # is that on purpose? 10.17.31 # i don't think so 10.18.58 # ok, making them global 10.19.13 # oh 10.19.25 # they're added in the firmware as well, but only if non-debug 10.19.32 # of course 10.19.45 # we'll need to set them up conditionally in the configure script instead 10.28.56 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 10.30.16 Join methangas [0] (methangas@0x50c61ce6.virnxx10.adsl-dhcp.tele.dk) 10.42.47 # hi Jörg 10.42.48 Quit kramerica (Read error: 104 (Connection reset by peer)) 10.46.45 # <[IDC]Dragon> Hello Jens 10.47.07 # <[IDC]Dragon> concgratulations to your latest achievements 10.47.29 # [IDC]Dragon and amiconn: are you really sure that you are supposed to speak i2c with the tuner on the ondio? 10.47.54 # <[IDC]Dragon> pretty much, yes (why?) 10.47.57 # i mean, then busenable wouldn't have been present in the 10-pin header 10.49.13 # <[IDC]Dragon> ? 10.49.34 # <[IDC]Dragon> the bus enable is necessary because the pins are shared with the LCD 10.49.52 # <[IDC]Dragon> well, at least the clock 10.50.00 # ah 10.50.29 # funny, why didn't they connect it to the i2c bus instead? 10.50.58 # <[IDC]Dragon> I guess this is because they have the option to mount the Samsung tuner instead 10.51.08 # perhaps 10.51.10 # <[IDC]Dragon> with the classic hookup 10.51.38 # <[IDC]Dragon> one pin is unused, which before was with SPI 10.51.39 *** Saving seen data "./dancer.seen" 10.51.56 # i see now 10.52.54 # <[IDC]Dragon> on the iriver, you are also facing multiple I2Cs, I read above? 10.54.26 # <[IDC]Dragon> so you'd also benefit from a multi-instance capable driver, if worth the effort 10.56.23 # [IDC]Dragon: I thought for a while that you may be right and the mask bit 3 does tell whether there is a tuner or not, because from the Archos site I learned that there is an "original Ondio 128", which shares firmware with the "Ondio 128 FM recorder". However, the Ondio 128 also features a radio 10.56.24 Part oxygen77 ("Cho") 10.57.22 # * [IDC]Dragon waits for the wide user base to tell us 10.57.57 # <[IDC]Dragon> maybe the original one has a backlight 10.58.22 # or maybe the original one has a Samsung tuner 10.58.49 # Did you try to dig for the FAT16 bug? 11.01.10 # <[IDC]Dragon> afk, meeting 11.01.24 # <[IDC]Dragon> yes, I did, no success yet 11.01.35 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 11.06.19 # yes, a multi-instance i2c driver is a must 11.07.03 # those koreans must have a bad dictionary entry for "bus" 11.09.09 Join wizzzard [0] (~merlin@dsl-082-082-234-199.arcor-ip.net) 11.21.27 # heh 11.22.23 # bus: A long motor vehicle for carrying passengers, usually along a fixed route. 11.22.40 # what's that got to do with i2c? ;) 11.23.54 # :-) 11.24.25 # see? even your dictionary is wrong! ;-) 11.24.38 Quit Nibbler (Read error: 238 (Connection timed out)) 11.28.42 # Zagor: (merriam-webster) bus: (3) a set of parallel conductors in a computer system that forms a main transmission path 11.30.05 Join Chronic007 [0] (~Miranda@24.30.163.142) 11.30.37 Join iRiverMan [0] (~acbefb5d@labb.contactor.se) 11.30.48 # mornign 11.35.55 # shhhhhhh.....we don't want to interrupt the technical discussions of the rockbox team.....they may fleet away into private discussions...then I'll have no break from the manotony of my homework.....hahahahahha 11.36.01 # can't wit to see rockbox on the iriver 11.38.00 # ; - ) 11.38.18 # it's not going to happen overnight. 11.38.40 # will it happen eventually 11.38.52 # i got an ihp-120 to replace my busted Archos Recorder 10 11.39.08 # they've gotten the debugger working. things progress. 11.39.11 # :) 11.39.34 # the iriver can record to wav or mp3, has a radio tuner and supports wav, mp3, wma, asf and ogg 11.39.35 # yeaaaa Linus!!!! 11.40.21 # Wonder if PaulS has had any luck with his unit 11.40.54 # will rockbox on the iriver be the same as rockbox on the archos? 11.41.22 # iRiverMan: yes 11.41.41 # more or less, of course 11.41.51 # and if you wanted to, could u revert back to the iriver firmware from rockbox if u wish? 11.41.51 # the platforms are different 11.41.55 # yes 11.42.14 # cool 11.42.24 # the iriver firmware is good, but playlist handling is a bit poor 11.43.20 # so far the only way to shuffle playlists is to manually shuffle them in Winamp 11.43.32 # but at least it can shuffle the hard drive without a playlist 11.43.35 # the iriver fw annoys the hell out of me 11.43.40 # why linus? 11.43.47 # i have an iriver ihp-120 11.43.53 # one keypress too many, and i'm back in the Playing screen 11.44.05 # well nothing practice wouldn't fix 11.44.19 # after all it is much more advanced than the Archos 11.44.21 # Linus: I agree...and scrolling soooo slow 11.44.40 # and the silly joystick is too slippery 11.44.51 # linus the joystick is not slippery 11.45.08 # i can't hold it for long until it slides under my finger 11.45.11 # man 5 gigabites transferred in 5 minutes over the USB2.0 port! 11.45.23 # i use my thumb on the joystic 11.45.33 # i'll have to put some hot glue or something on it 11.45.44 # i use the thumb as well 11.45.46 # I still think its a better machine than the archos 11.45.52 # absolutely 11.46.04 # lightyears ahead, imho 11.46.06 # :) 11.46.14 # i've got the hitachi HD for my old archos lying around 11.46.29 # i decided to save the HD from the Archos 11.46.32 # 10gb Hitachi 11.46.55 # the iriver uses the 20gb Toshiba drive 11.47.12 # i want at least 40... 11.47.22 # i don't like the look of the 40gb iriver 11.47.28 # the 20gb one looks better 11.47.34 # perhaps 11.47.57 # linus u may kill me if i say this but i very nearly bought an ipod before choosing the iriver 11.48.03 # I can't wait till somone figures out how to upgrage the h140 to 80gig 11.48.27 # : -) 11.48.27 # Chronic007: you'll have to wait till someone crams the 80g into the 40g drive's formfactor. 11.48.39 # already been done 11.48.47 # if they can add more "pixie dust" 11.48.57 # faerie dust! :) 11.49.03 # ok faerie dust then 11.49.18 # Does anyone know any ogg rippers around 11.49.19 # Chronic007: yeah? where/how/who/howmuch? :) 11.49.53 # i wonder if the iriver can be reprogrammed to play atrac3 or aac 11.49.58 # someone was posting about it at the irver@lounge forums lemme see if I can find the thread......BRB 11.50.36 # or mp3pro eveb 11.50.38 # even 11.51.50 # iRiverMan: yes, yes and yes 11.52.19 # however, there are patent and license issues 11.52.55 # so we might not be able to do it because of that 11.52.56 # lol 11.52.57 # ok 11.53.07 # well mp3pro is not protected 11.53.50 # then again i wonder why anyone would want mp3pro 11.54.26 # because a 64kbs mp3pro sounds as good as 128kbs mp3 in half the file size 11.54.54 # so u can squeeze more music on a device 11.55.44 # i've compared a 64kbs mp3pro to its original 40mb wav file and the quality is almost as good 11.56.38 # :-) 11.57.02 # and the quality is certainly better than wma 11.58.00 # lunch time 11.58.55 # don't eat too much 11.59.06 # :D 12.00.26 # Ashridah: Ok back with report, Buckaroo Banzai posted in the @lounge forums "Toshiba announced the start of the production of 30GB and 60GB 1.8" harddisks at the end of august or september" - well it was 60g not 80g sorry didn;t mean to get your hopes up. 12.00.50 # lol 12.01.05 # whaever happened to those dataplay disks? 12.02.14 Join webguest60 [0] (~82ec60fd@labb.contactor.se) 12.02.41 # Anybody here? 12.03.04 # webguest60: yes 12.03.38 # hi 12.03.49 # I am looking for information about the mas3587f which is built into some of the rockbox.... 12.06.14 # what do you want to know? 12.06.14 # Where can I buy the mas3587f circuit? Small order, 2 or 3 circuits.... 12.06.32 # Preferably in Sweden... 12.06.36 # no idea. tried the usual places? 12.06.59 # yepp, no go... 12.07.23 # just a place in easterneurope... 12.08.17 Quit iRiverMan ("CGI:IRC (EOF)") 12.08.21 # it's a very specialized circuit, not many companies carry it. eastern europe is probably as close as you will get. 12.09.43 # Arrow Electronics sell them in sweden, but only for industries, which probably mean at least 500 circuits a batch :) crap 12.10.56 # you can always ask for a few samples 12.12.28 # yeah, or contact their customers (sometimes works), 12.17.35 Part MisticJeff 12.18.33 Join R3nTiL [0] (~zorroz@227-250-30-217.kgts.ru) 12.24.44 # thanks anyway! bye 12.24.47 Quit webguest60 ("CGI:IRC") 12.31.34 # SRC := $(shell cat SOURCES | $(CC) -DMEMORYSIZE=$(MEMORYSIZE) $(INCLUDES) $(TARGET) $(DEFINES) -E -P -include "config.h" -) 12.31.38 # kinda nice ;-) 12.32.02 # even better than include since this "takes" immediately 12.32.11 # skip 'cat' and it will work on windows too 12.32.43 # cat works on cygwin 12.32.52 # we already use cat like that for the link files 12.34.15 # why pipe at all? 12.34.18 Part wizzzard ("Kopete 0.9.0 : http://kopete.kde.org") 12.36.49 # gcc has issues with the file naming 12.37.16 # it doesn't accept all file extensions for preprocessing, iirc 12.37.53 # right, but I probably use < SOURCES 12.37.58 # or rather, it tries to be smart, behaving differently for different file types 12.38.30 # "I can" even 12.41.08 # [IDC]Dragon: r u there? 12.51.43 *** Saving seen data "./dancer.seen" 13.02.18 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 13.10.10 Quit R3nTiL () 13.13.29 # this is a wonderful optical illusion: http://web.mit.edu/persci/people/adelson/checkershadow_illusion.html 13.17.45 # yeah i love that one, i didnt believe it until i edited everything else out and putted them next to each other 13.25.10 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 13.28.22 Quit Nibbler (Read error: 238 (Connection timed out)) 13.30.49 # <[IDC]Dragon> back again 13.31.12 # <[IDC]Dragon> triggering Jens amiconn 13.31.17 # [IDC]Dragon: Perhaps the following may give you a hint what's going wrong with fat 16: 13.32.13 # (1) At the point the panic occurs, the code tries to write 96 sectors before the first allowed sector. Maybe a coincidence, but the size of the root dir is 32 sectors... 13.33.04 # (2) The panic does not occur when the FAT16 partition is located at the beginning of the disk, because the 96 sectors then wrap around (unsigned) to a very high sector number 13.33.35 # <[IDC]Dragon> oh, so I should panic for that, too 13.34.37 # The FAT code in general (both FAT16 and FAT32) should panic if it tries to access areas outside the partition 13.35.31 # Furthermore, you assign the root dir "virtual" cluster numbers < 0. I wonder how you handle the case that the root dir size is not an integer number of clusters 13.36.54 # <[IDC]Dragon> I do 13.37.18 # <[IDC]Dragon> then the start sector of the "file" is not zero 13.38.26 # <[IDC]Dragon> look into fat_open_root() 13.39.31 # Ah ok. 13.42.19 # <[IDC]Dragon> amiconn: the -96 sector, is that the very first one to be written? 13.46.53 # hello, anybody here with some knowledge in XLIB? 13.48.14 # oxygen77: a bit 13.50.53 # cool 13.51.16 # I'm doing a X simulator for the graphical lib of linav 13.51.29 # I can draw in black and white 13.51.44 # but now I'm trying to use colors 13.52.18 # is there a way to use directly RGB? 13.53.23 # <[IDC]Dragon> Zagor: what am I missing in that optical illusion? 13.53.44 # A and B is the same color 13.54.07 # <[IDC]Dragon> aha? nice 13.55.22 # [IDC]Dragon: Dunno which write causes that; it's the first write that tries to write in the forbidden area and hence causes the panic 13.56.02 # <[IDC]Dragon> really strange that it doesn't happen in the test suite 13.56.40 # <[IDC]Dragon> I stared at the code for endianess or other porting problems, but found none 14.00.55 # [IDC]Dragon: We would need a way to backtrace the call. However, I have no idea how to do this 14.05.05 # <[IDC]Dragon> that's possible, but the worst part is that the player display is so small 14.05.42 # There is lcd_puts_scroll() ... 14.05.51 # <[IDC]Dragon> I was thinking about how I can set something up 14.06.03 # <[IDC]Dragon> on my gdb-capable recorder 14.06.37 # <[IDC]Dragon> I need to install another disk 14.08.17 # I could try to display a part of the stack frame, the figure out what's going on with a disassembler listing 14.08.36 # s/the/then 14.08.55 # [IDC]Dragon: you can always repartition the disk you have, and make a small fat16 partition on it 14.09.02 # <[IDC]Dragon> but before I do that, I wait for my USB2 card, which is on order 14.09.19 # <[IDC]Dragon> the USB2 on my mainboard is unreliable 14.09.31 # [IDC]Dragon: I could do that with my recorder as well, my old 20 GB disk is still laying around... 14.10.25 # <[IDC]Dragon> Zagor: I thought about shrinking my partition, to create a little FAT16 one at the end 14.10.43 # <[IDC]Dragon> but I prefer not to endanger the data on it 14.11.21 # <[IDC]Dragon> I have a "spare" (=empty) 20 GB disk 14.15.31 # <[IDC]Dragon> amiconn: in your new code, I noticed that the delayed write is mapped to the normal write 14.16.15 # <[IDC]Dragon> I don't think that's such a good idea, iirc the WPS calls this once per second to save the resume position 14.16.19 # stand clear for yet another Makefile commit 14.16.31 # <[IDC]Dragon> so we'll have a lot of flash wear 14.17.01 # <[IDC]Dragon> Bagder: uh oh :-/ 14.17.19 # this is just another step forward towards easier life 14.17.37 # like less fixed recorder <=> bitmap <=> FM associations 14.23.53 # [IDC]Dragon: I mapped the delayed write to the normal write because there is no spinup. This was already there with my first version supporting writing. I didn't know that this is accessed *that* often... 14.24.36 # LinusN: here? 14.25.12 # yup 14.25.26 # is it really intended to use -O for debug builds? 14.25.39 # yes 14.25.43 # ok 14.25.45 # [IDC]Dragon: Now that I though about it a bit, I think the backtracing won't be hard. 14.26.07 # Bagder: otherwise the inlining doesn't work, and the scheduler messes up 14.26.13 # <[IDC]Dragon> no, we can just store an array of the params 14.26.14 # iirc 14.26.15 # ah, right 14.26.55 # <[IDC]Dragon> we could even log to fixed sectors 14.27.58 # [IDC]Dragon: I think the idea of displaying the stack frame on panic and the backtracing by hand with disassembled rockbox isn't hard 14.28.30 # <[IDC]Dragon> this is very low 14.29.16 # <[IDC]Dragon> but we couldeven write the stack to disk, for more comfy handling 14.29.56 # <[IDC]Dragon> I once have made a little memory scroll screen (for recorder) 14.30.59 Join Yokalosh [0] (~3efec181@labb.contactor.se) 14.31.01 # <[IDC]Dragon> LinusN: how would you like the idea to be able to scroll back through the stack on panic? 14.31.28 # sounds really nice 14.31.28 Quit Yokalosh (Client Quit) 14.31.59 # still, our panic numbers help a lot today 14.32.19 # i haven't felt much need for a more detailed trace 14.33.08 # <[IDC]Dragon> you had gdb... 14.33.45 # yes, but the panic numbers have often been enough for traceback 14.34.24 # with the panic numbers i can see the exact call chain 14.34.40 # well, not always exact, but close 14.35.29 # still, if you can produce a stack dump, i won't protest 14.35.44 # unless it bloates the code, of course 14.37.46 # <[IDC]Dragon> probably not, a key loop and a printf 14.38.57 # then go for it 14.39.37 # i still want the panic codes 14.40.57 # <[IDC]Dragon> probably the keys don't work any more... 14.41.35 # <[IDC]Dragon> ... without interrupts ticking 14.43.37 # true 14.51.46 *** Saving seen data "./dancer.seen" 14.55.23 # [IDC]Dragon: How would you write the stack to disk? Obviously we can't use the file system, because that's what we try to debug 15.01.15 # <[IDC]Dragon> amiconn: raw sector writing is OK 15.03.04 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 15.03.42 # committed 15.07.29 # Hi 15.07.36 # One question regarding the new button handling. 15.07.46 # I think it inverted old UP/DOWN behaviour on recorder in some places 15.08.18 # Zagor did the changes, right? 15.08.42 # yes 15.08.48 # Hi 15.09.07 # for example Recent and List Bookmarks changed 15.09.15 # Previously DOWN got the next older entry, now it is UP 15.09.22 # is this intended? 15.09.50 # Another example is Debug -> View battery UP/DOWN 15.10.10 # Now I need to use UP to get the next page 15.10.26 # In fact most debug screens are inverted. 15.10.36 # please cvs update and try the new make 15.10.45 # yes, there was a lot of mixups in the debug screens 15.11.05 # down is now INC in all screens 15.11.21 # uh, pposite :) 15.12.11 # Zagor: Any new button code in the pipe? The problem with the double-left exists in many places.. 15.12.30 # yes, i'll fix it. 15.12.31 # * [IDC]Dragon barely dares to ask about the Ondio menu button 15.13.07 # I find the Bookmark behaviour a little bit confusing 15.13.26 # I think DOWN should get the next older 15.14.08 # possibly, yes 15.15.49 # Zagor: If we have buttons that react both on short & long press, we have to trigger on the release for short presses. However, for long presses we have to trigger on the repeat (already), so the (trailing) release has to be "eaten". Otherwise it triggers another item 15.16.54 # Same goes for buttons with a single function only, that trigger on the keypress itself. 15.17.20 # amiconn: we might want it a little more sophisticated 15.17.49 # LinusN: In what respect? 15.17.51 # like providing some feedback on the down event, but performing the action on release 15.18.12 # to make the interface appear more "snappy" 15.20.18 # LinusN: Another topic, concerning interrupts, yield() and the mmc driver: 15.21.19 # I would make the mmc driver yield() between transfers, because otherwise the ui appears locked for several seconds. 15.22.01 # In order to do this, I'd have to do many things within ISRs, otherwise the performance would drop significantly 15.23.03 # explain 15.23.15 # There would be ISRs (well, one) that may run a bit long, and in order to not block other interrupts, I'd have to enable interrupts within that ISR 15.23.49 # * oxygen77 is away: chui pas là 15.24.00 # While this is fine with my ISR, this may screw the set_irq_level() logic in other code (?) 15.25.19 Quit Nibbler (Read error: 238 (Connection timed out)) 15.25.39 # Explanation: With ata, there is one, possibly, long, wait before the start of data transfer. Once the transfer starts, it is done at once. 15.26.36 # With MMC, there is a wait before each block transfer, where the start of block mark has to be polled for. The block transfer itself can be done with dma. 15.27.09 # The wait itself is _relatively_ short, so yielding there would significantly drop performance 15.27.40 # Furthermore, if doing block transfers with dma, the bitswap has to be done afterwards. 15.28.43 # ok, last chance for makefile comments until tonight 15.29.21 # So my idea was to let an isr capture the end-of-block interrupt, then wait for the next block by polling (with interrupts enabled) 15.30.30 # The bitswap is done in the mmc thread, on demand by the isr 15.32.14 # Both the mmc thread and the thread calling the mmc driver could then yield, and while a block transfer is running, other threads could run. (typically for 512*8*4 = 16384 clock cycles) 15.32.40 # Bagder: New configure necessary to test that? 15.32.45 # yes 15.32.54 # Bagder: hang on 15.33.03 # gcc opts moved out from the makefiles to the root makefile 15.33.17 # another coldfire prep 15.33.50 # ls 15.34.22 # oops 15.34.23 # check apps/SOURCES for an example of how this works 15.35.07 # this is great, now we can exclude the grayscale stuff for the player 15.35.30 # yes, very easily 15.35.46 # and lcd-player... driver stuff for the recorder etc 15.36.00 # me likes it 15.36.05 # it should make it easier for your early iriver builds too 15.36.14 # absolutely 15.39.29 # Bagder: YOur new make logic seems to work. Unrelated to this, I get a linker error for the fmr linking rombox "region FLASH is full" 15.39.59 # I noticed that one too 15.40.05 # I don't know why though 15.41.06 # I think it's clear. Rombox doesn't fit into flash, so the linker errors out 15.41.27 # but why doesn't it fit all of a sudden= 15.41.28 # ? 15.41.39 # or didn't it before either? 15.42.18 # fm never fit afair 15.43.14 # the bleeding edge builds fail too 15.43.58 # btw, I bet the daily build will need attention due to the configure needing to be re-run 15.45.14 # you'll have to reconfigure manually 15.45.36 # or fix the scripts 15.45.42 # Zagor? 15.46.17 # I have no time now, the scripts should be fixed to do it every time 15.46.25 # * Bagder runs off 15.46.27 # we don't reconfigure anymore, remember? 15.46.34 # it's all from the scratch all the time 15.46.40 # not the daily builds 15.46.44 # only the bleeding edge 15.46.56 # separate scripts 15.47.04 # !?? 15.47.10 # well I did them that way 15.47.30 # last time i checked, only the bleeding edge builds were fixed 15.47.53 # i had to run configure manually 15.48.05 # that's why there were no daily builds for a few days 15.49.11 # ah, found and fixed. a trailing "update" was left. 15.49.41 # goodie 15.49.57 # bleeding works though 15.52.23 # gotta go, cu guys 15.52.41 Part LinusN 16.24.02 # * oxygen77 is back (gone 01:00:12) 16.24.28 Part oxygen77 ("Cho") 16.33.46 Quit ashridah ("sleep") 16.41.12 Part Zagor 16.43.30 Join WhiteStar [0] (mithrandir@pD9E1EA4A.dip.t-dialin.net) 16.43.35 # Hi 16.44.23 # Does somebody want to buy a new JB Car Kit? 16.44.47 # <[IDC]Dragon> what's that? 16.45.19 # Er, sorry, it's the Travel kit 16.45.22 # http://archos.com/products/prw_500179.html 16.45.59 # <[IDC]Dragon> no, thanks 16.46.34 # i had to send my jbr back in and got the money back, but i still have the travel kit... 16.48.18 # Is the Gmini 20 any good, besides being unable to run rockbox? 16.51.12 # <[IDC]Dragon> the 220 is definitely cute 16.51.21 # <[IDC]Dragon> besides, I don't know 16.51.49 *** Saving seen data "./dancer.seen" 16.53.50 # okay thanks 16.54.28 Join mecraw [0] (~lmarlow@69.2.235.2) 16.56.04 Join mattzz [0] (~mattzz@c159207.adsl.hansenet.de) 17.01.01 Join webguest42 [0] (~3f7cde02@labb.contactor.se) 17.01.47 Quit webguest42 (Client Quit) 17.04.19 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 17.08.52 # <[IDC]Dragon> amiconn: r u there? 17.11.07 # yeps 17.11.45 # <[IDC]Dragon> I suggest using sleep_thread() in the driver 17.12.05 # <[IDC]Dragon> far less overhead than yield() 17.12.35 # <[IDC]Dragon> even the I2C driver uses that while waiting for ack 17.14.30 # <[IDC]Dragon> yield() wakes up all threads 17.15.24 # yes, but does sleep_thread() allow other threads to run? 17.15.42 # <[IDC]Dragon> sleep_thread() will directly enter CPU sleep mode if all other threads are sleeping 17.16.03 # <[IDC]Dragon> but then walk around 17.17.32 # <[IDC]Dragon> causing n context switches 17.18.00 # how much would a JB Studio 10 be worth today? 17.18.24 # <[IDC]Dragon> and n-1 threads calling sleep_thread() again, in their wait loop 17.18.39 # WhiteStar: I bought one from eBay for ~90 € 17.19.32 # [IDC]Dragon: I wonder if one walk-around is done in less than ~1.3 ms. Otherwise, performance would drop significantly 17.21.41 # hum. well i need a mobile HDD and it should be with mp3-player, so archos seems to be the best choice... 17.21.53 # although i had to retourn the JBR0 17.21.56 # *20 17.22.33 # <[IDC]Dragon> amiconn: 1.3 ms is 1000 cycles! 17.24.26 # <[IDC]Dragon> but you can easily measure it, to check 17.25.07 # 1.3 ms is 16384 cycles (transfer of 512 bytes over SCI @ 3 MBit/s) 17.26.19 # <[IDC]Dragon> ah, sorry, I had it reciproc and all mesed up 17.26.32 # <[IDC]Dragon> messed 17.26.36 # <[IDC]Dragon> see? 17.27.05 Quit Nibbler (Read error: 238 (Connection timed out)) 17.27.27 # <[IDC]Dragon> well, but definitely enough to walk around our ~5 threads 17.28.15 Join gromit``` [0] (~gromit@ALagny-151-1-27-41.w83-114.abo.wanadoo.fr) 17.28.28 # <[IDC]Dragon> if we sleep the CPU, it needs an interrupt to wake it up again 17.29.02 # <[IDC]Dragon> so you can't do that in a pure polling environment, I'd say 17.36.02 # Yes. I can't do that while polling for start of data, hence I wanted to do it while the sector transfer is running. Then I capture the end-of-dma-transfer interrupt 17.36.46 # (That needs dma implemented first, of course) 17.38.24 # <[IDC]Dragon> will that be any faster than now? (or: are you transmitting/receiving back to back currently?) 17.39.14 # byebye ^^ 17.40.29 # [IDC]Dragon: (1) What do you mean with back to back? (2) I think it wil be faster than the current implementation, because with the polling approach, there are short pauses between the individual bytes 17.40.59 # <[IDC]Dragon> that's what I meant with back-to-back, yes 17.41.13 # <[IDC]Dragon> if the clock is continuous 17.42.17 Quit gromit`` (Read error: 110 (Connection timed out)) 17.42.46 # <[IDC]Dragon> I'd guess you're just a little bit slower now (haven't checked with the scope) 17.43.07 Quit WhiteStar ("( www.nnscript.de :: NoNameScript 3.79 :: www.XLhost.de )") 17.43.59 # <[IDC]Dragon> I'd like to correct me: yield() is no more expensive, and it returns the control to you without interrupt 17.45.58 # <[IDC]Dragon> so perhaps do this in your polling loop, at least once 17.46.44 # <[IDC]Dragon> (I know, with polling we don't have the whole sector worth of time) 17.51.08 # The problem is that the polling time can vastly differ: from a few 100 clocks to several 10000's 17.51.40 # <[IDC]Dragon> if some other thread has something to do, yes 17.51.58 # <[IDC]Dragon> but that's why we yield, isn't it? 17.52.31 # <[IDC]Dragon> or, you mean the MMC time? 17.58.13 # I mean mmc time 17.58.29 # <[IDC]Dragon> ok 17.58.46 # <[IDC]Dragon> still it more or less matches 18.01.02 # The problem here is that while polling, the mmc has to be clocked, and this can't be done via dma, because we need to catch the first data byte != 0xFF 18.03.13 # (away) 18.06.34 # <[IDC]Dragon> then how about: 1) send command, 2) yield, 3) poll 18.07.39 Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) 18.07.40 # <_aLF> hi 18.11.40 # <[IDC]Dragon> amiconn: I'm getting some wild ideas: 18.11.56 # <[IDC]Dragon> byte != FF means falling edge 18.12.38 # <[IDC]Dragon> infortunately, RxD1 has no dual function as an interrupt 18.14.35 # <[IDC]Dragon> perhaps we can clock SCK1 using the Programmable Timing Pattern Controller 18.15.20 # <[IDC]Dragon> and have the serial in an async mode which gives an interrupt when falling 18.20.09 # <[IDC]Dragon> like, setting it to highest baudrate, falling is the start bit, it will give an interrupt somewhat late 18.30.14 # <[IDC]Dragon> either the TPC clock has to be much slower than the async baudrate, such that a framing error interrupt occurs within one TPC cycle, 18.30.49 # <[IDC]Dragon> or the rates have to match and the information in the async receive is recycled 18.31.24 # <[IDC]Dragon> either case would require a fast stop of the TPG 18.38.35 Quit AciD (Connection timed out) 18.39.21 # <[IDC]Dragon> I'm off 18.39.30 Quit [IDC]Dragon ("CGI:IRC") 18.45.10 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 18.49.42 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") 18.51.50 *** Saving seen data "./dancer.seen" 18.53.16 Join salimfadhley [0] (~sal@host-83-146-34-206.bulldogdsl.com) 19.04.02 Quit mattzz ("Client exiting") 19.22.56 Join [IDC]Dragon [0] (~idc-drago@pD9FF886E.dip.t-dialin.net) 19.23.07 # <[IDC]Dragon> hi again 19.23.17 # Ka_: 19.23.26 # erh, I mean: hi 19.23.56 # Found your wild ideas. Unfortunately, this won't work, for several reasons 19.24.01 # <[IDC]Dragon> guess my wild ideas are not too practical :-/ 19.24.38 # <[IDC]Dragon> I was just thinking aloud 19.24.56 # (1) We have to maintain byte sync as long as /CS is low. /CS has to stay low during the whole transfer. Hence no async mode or single clocks possible 19.25.44 # (2) The first bit of the byte we have to catch is _not_ 0, only the last one is. Furthermore, we need the correct value of that byte 19.27.05 # I had some similar wild ideas, that also wouldn't work, like receiving into a TPC register and compare-matching the byte 19.28.34 # The problem with that is that the dma has to be stopped *immediately* after receiving the first byte 19.34.18 # I just made MMC writing another 15% faster (still polling). Same thing for reading is on its way... 20.13.21 Part salimfadhley ("I am slowly drifting away from you....") 20.23.36 Join webguest89 [0] (~8446da7f@labb.contactor.se) 20.25.08 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) 20.30.45 # [IDC]Dragon: r u there 20.30.47 # ? 20.44.58 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 20.44.58 Quit kramerica (Read error: 104 (Connection reset by peer)) 20.45.07 Quit webguest89 ("CGI:IRC (EOF)") 20.47.01 Quit Sebulba03 (Read error: 104 (Connection reset by peer)) 20.51.54 *** Saving seen data "./dancer.seen" 20.59.23 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) 21.11.18 Quit Nibbler ("¿") 21.11.18 Quit kramerica (Read error: 104 (Connection reset by peer)) 21.11.52 Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) 21.29.37 # [IDC]Dragon: knock knock! 21.35.10 Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) 21.47.17 Join scott666_ [0] (~scott666@24.245.58.48) 21.47.18 Quit kramerica (Read error: 104 (Connection reset by peer)) 22.06.43 Nick scott666_ is now known as scott666 (~scott666@24.245.58.48) 22.07.03 Join Paco_ [0] (~Miranda@80.119.248.127) 22.09.40 Quit Nibbler ("¿") 22.27.02 # <[IDC]Dragon> amiconn: I'm here 22.27.16 # <[IDC]Dragon> girlfriend took over the PC 22.27.16 # Ah, finally ;) 22.27.41 # I traced back the call to transfer() which causes the panic. 22.27.51 # <[IDC]Dragon> and? 22.28.14 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- Get hot chicks here!") 22.29.21 # It happens when I go to info->debug->dump rom contents in the write call for the first file (boot rom). Call sequence is as follows: 22.32.29 Join webguest33 [0] (~c7e73180@labb.contactor.se) 22.33.19 # (file.c) write(fd, 0, 0x1000); --> readwrite(fd, 0, 0x1000, true) 22.33.24 # fd is unknown from the backtrace, but shouldn't be too interesting 22.33.40 # hi all 22.34.12 # I have a UI question/comment 22.34.34 # [IDC]Dragon: From readwrite(), the first call to (fat.c) fat_readwrite(&file->fatfile, 128, 0, true) 22.34.49 # If you're listening to music loud to stay awake driving late at night, 22.34.59 # and resume is set to YES 22.35.32 # You can be VERY startled the following morning :) 22.36.06 # [IDC]Dragon: Then the _last_ call to transfer(168, 112, 8182, true) causes the panic. 22.36.08 # would it make sense to resume at some less loud volume, at least if some time has passed? 22.36.57 # [IDC]Dragon: This is of course correct, since the first valid sector is 264 (== 168 + 96) 22.42.03 # Summary: (file.c) write(fd, 0, 0x1000) (line 565) --> readwrite(fd, 0, 0x1000, true) (line 471) --> (fat.c) fat_readwrite(&file->fatfile, 128, 0, true) (line 1969) --> transfer(168, 112, 8192, true) --> panic 22.42.44 # <[IDC]Dragon> why the panic then? 22.43.37 # It seems like the code writes the beginning of the file into a sigle cluster, and tries to write the whole remainder into a single cluster chain. Somehow it gets the start sector wrong 22.44.10 # Why panic? Because sector 168 is forbidden, first valid sector is 264 22.44.57 # <[IDC]Dragon> ah, the panic is correct, see above 22.45.17 # <[IDC]Dragon> is this with the image you gave me? 22.46.22 # Yes, although not precisely, since this would require to put back the image first. 22.47.13 Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc) 22.49.19 # <[IDC]Dragon> btw, how did you trace? 22.51.06 # I defined a static array of 32 longs. Then I put a copy loop at the start of transfer(), which copied 32 values from the stack into the array. Within the if() that detects the panic condition, I put an output loop that shows me the 32 values, 2 at a time. 22.51.09 # <[IDC]Dragon> tracing the sim: first, I get a lot of single sector transfers, the FAT entries 22.51.57 *** Saving seen data "./dancer.seen" 22.52.24 # <[IDC]Dragon> then 16 sectors, a cluster 22.52.24 # This revealed that the call came from fat_readwrite, and the parameters as well. Then I moved that copy loop to the start of fat_readwrite(), which revealed the call from readwrite() and the parameters as well 22.53.35 # <[IDC]Dragon> poor Jens 22.53.42 # Huh? 22.54.04 # <[IDC]Dragon> tedious work, I mean 22.54.39 # Well, it wasn't that hard, althoguh it required a bit of disassembling 22.55.27 # <[IDC]Dragon> do you have the image from before this action? 22.56.29 # One thing I discovered: You extended cluster2sec() (precisely: first_sector_of_cluster() for the cluster < 0 case (fat16 root dir). However, you did not do that for the reverse function, sec2cluster() 22.58.30 # <[IDC]Dragon> it's not used fot FAT16 22.58.38 # Maybe that it's not necessary, since this is only used within fat_opendir(), which is not used for fat16 root 22.59.07 # AH 22.59.41 # <[IDC]Dragon> how about the image before? 23.00.10 # Yes, I still have the image as I sent it to you 23.00.46 # <[IDC]Dragon> you said your state was different 23.02.07 # Yes because in order to use the exact state again, I would have to put the image back on the box before every experiment. 23.02.43 # This is an USB1.1 box.... 23.02.48 # <[IDC]Dragon> or, just the fat and the root dir 23.02.57 # Hmm. 23.03.12 Join Zagor [0] (foobar@h254n2fls31o265.telia.com) 23.03.29 # <[IDC]Dragon> evening Björn 23.03.33 # hi 23.03.49 # Zagor: evening 23.03.55 # [IDC]Dragon: Have to figure out the exact location, and split the image file accordingly 23.04.33 # And I have to do that twice (once for each function trace) 23.05.25 # <[IDC]Dragon> ? 23.06.01 # Not the "figure out and split file", but the write back to the box 23.06.31 # Zagor: How would you split a large file at a given position, on the unix command line? 23.09.29 # with dd 23.10.43 # Ah, probably using the "seek" option? 23.11.38 # yes, seek or skip 23.12.19 # (they do the same thing, only using different block sizes) 23.12.21 Quit AciD (Read error: 110 (Connection timed out)) 23.12.58 # <[IDC]Dragon> with your image, I get 8 single cluster writes 23.13.02 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 23.13.24 # <[IDC]Dragon> plus the fat+dir sectors interspersed 23.13.40 # Ah, seek is for output, skip is for input. Nice, so I can use both, and don't have to split the file beforehand (and one possible error source less) 23.14.36 # <[IDC]Dragon> I have to leave soon, but try to dump my transfer() parameters 23.19.37 Join erik____ [0] (~erik@foxtail.org) 23.20.41 Part Paco_ 23.20.48 # [IDC]Dragon: The offending call to transfer() looks exactly the same as I told above with the original image 23.22.45 # <[IDC]Dragon> with that manysectors? 23.23.15 # yes. The stack frame looks identical 23.23.21 # <[IDC]Dragon> I get no more than a cluster each time 23.23.35 # <[IDC]Dragon> do you see the single sectors as well? 23.24.02 # No. I catch only the call that causes the panic 23.24.27 # <[IDC]Dragon> just in case you would: 23.24.44 # <[IDC]Dragon> I get sigle sector writes like the following: 23.24.51 # <[IDC]Dragon> twice to 264 23.25.09 Quit erik____ ("Leaving") 23.25.14 # <[IDC]Dragon> then 265 to 279 all in single sectors 23.25.46 # <[IDC]Dragon> (16 calls to transfer() ) 23.26.02 # The fat_readwrite() call looks identical too 23.26.11 # <[IDC]Dragon> then 8 cluster-size calls for the payload 23.26.52 # <[IDC]Dragon> to 680, 696, 712, 728, 744, 760, 776, 792 23.27.03 # That is the output from the LDEBUGF() macros I guess? 23.27.10 # <[IDC]Dragon> then 2 single sectors, 801 and 264 23.27.50 # <[IDC]Dragon> that's my breakpoint at transfer() 23.28.00 # * [IDC]Dragon sees something 23.28.10 # Telling you just the transfer() calling parameters? 23.28.21 # <[IDC]Dragon> this test code does not combine consecutive access 23.28.31 # Ahhah!! 23.28.41 # <[IDC]Dragon> probably because the max transfer size is faked low 23.29.08 # <[IDC]Dragon> Zagor: do you remember how this is handled? 23.30.41 # Btw: There is an _ugly_ _hard coded_ dependency to ata behaviour in fat.c: It tries to combine consecutive sectors into one ata call, but max. 256 because this is the maximum ata can handle. However, this is not true with MMC 23.31.30 Quit webguest33 ("CGI:IRC") 23.31.33 # <[IDC]Dragon> where it the combining? I can't find it 23.32.15 # fat.c, lines 1912ff 23.32.34 # amiconn: well I wouldn't call it terribly ugly, but yeah there is a limit 23.32.43 # The ata dependency is in line 1955 23.33.05 # <[IDC]Dragon> the hard coded 256? 23.33.11 # yes 23.33.26 # <[IDC]Dragon> why does it not combine here, then? 23.34.10 # I dunno. 23.34.25 # <[IDC]Dragon> perhaps the test code feeds small chunks 23.34.56 # I'll put a parameter output at the start of transfer(), and retry. Then we can compare the sector numbers & counts 23.35.42 # <[IDC]Dragon> yes, there is an 8 K chunk size 23.36.07 # <[IDC]Dragon> amiconn: you can save that effort 23.36.14 # Okay. 23.43.19 # <[IDC]Dragon> I increased the size to 64K, but this still went smooth 23.43.44 # Hmm. 23.43.55 # <[IDC]Dragon> what a pity, I was really hoping for the problem to show up 23.44.54 # <[IDC]Dragon> it's writing the payload in one swoop, from sector 680 on 23.45.30 # <[IDC]Dragon> the fat+dir traffic looks similar 23.48.05 # I wonder why the target code tries to write 112 of the 128 sectors starting at sector 168 then 23.49.00 # Do you display write accesses only? I'm asking because if I would display read accesses too, it would be tedious to click through at box startup 23.49.27 Quit mecraw ("Trillian (http://www.ceruleanstudios.com)") 23.49.47 Join mecraw [0] (~lmarlow@69.2.235.2) 23.51.07 # <[IDC]Dragon> I broke on read, too,but skipped those 23.52.55 # <[IDC]Dragon> I really gotta go now 23.53.07 # <[IDC]Dragon> maybe we'll nail it tomorrow! 23.53.13 Quit [IDC]Dragon ()