1 files changed, 547 insertions, 0 deletions

diff --git a/www/irc/rockbox-20020419.log b/www/irc/rockbox-20020419.log
new file mode 100644
index 0000000000..d31e3942af
--- /dev/null
+++ b/www/irc/rockbox-20020419.log
@@ -0,0 +1,547 @@
+--- You are now known as Bagder
+--> Zagor2 (~bjst@labb.contactor.se) has joined #rockbox
+--- Zagor2 is now known as Zagor
+<Zagor> aloha!
+<Bagder> hey ho
+--- Bagder gives channel operator status to Zagor
+<Bagder> uh
+<Bagder> y%8 should be y&7 in lcd.c
+<Bagder> for the pixel functionss
+<Bagder> I'll fix
+<Zagor> yes, i realized that too. but it turns out as the same thing
+<Bagder> when compiled?
+<Zagor> i don't know about the code, but the logic is the same
+<Bagder> yes, logic is the same but % is generally a much slower operation
+<Zagor> ok
+* Bagder does an "Alan"
+<Zagor> hehe, don't be mean
+* Bagder chuckles
+<Bagder> woo new mozilla to get
+--> wavey (~wavey@dlan1431.dircon.co.uk) has joined #rockbox
+<wavey> morn
+<Bagder> it is a sunny and fine morning here
+<wavey> overcast and cool here
+--> alkorr (jbcoax@srs04m-8-117.n.club-internet.fr) has joined #rockbox
+<alkorr> for the CVS $Id, what must i put it in a source, so CVS fills it
+<alkorr> ?
+<alkorr> hi btw
+<Zagor> $Id$
+<Zagor> hi :)
+<alkorr> oky
+<alkorr> :)
+<wavey> do we have a standard file header to include at the top?
+<Bagder> yes
+<wavey> i.e the rockbox copyright and logo?
+<alkorr> yeep
+<wavey> so rather than specifying the Id tag
+<wavey> specify the header :)
+<wavey> and put the tag in the herder
+<wavey> header
+<Zagor> yes, that's how it is
+<wavey> so
+<wavey> why
+<wavey> did
+<wavey> alan
+<wavey> ask about the id tag?
+<Zagor> ask
+<Zagor> alan
+<Zagor> :)
+* wavey lol
+<alkorr> because i didn't know that :)
+<wavey> because it isn't stated anywhere :)
+<Zagor> alan: you changed the license for your FAT code. was that intentional?
+<alkorr> nope at all
+<alkorr> they were my old headers
+<Zagor> ok, so I should change it back to GPL?
+<alkorr> just forget to change them
+<alkorr> if you are tempted :)
+<Zagor> i am :)
+<alkorr> okay
+<Zagor> i looked at it a bit yesterday. what did you mean when you said the code is "obsolete"?
+<alkorr> which code ?
+<Zagor> the fat code
+<Zagor> that you mailed me
+<alkorr> ah yes... hum because i plan to split it and maybe a little bit more generic for PC test
+<Zagor> ok, because I started working on it... :)
+<alkorr> is that so ?
+<Zagor> yes
+<Zagor> i plan to have an image of a FAT32 disk in a file to do testing on
+<alkorr> for your purpose ?
+<Zagor> ?
+<wavey> zag: how will the main program body service user events while keeping the dsp full of data? will we just set up some sort of dma to allow the dsp to read data until complete, leaving the program thread to manipulate memory etc?
+<wavey> or is there some other way?
+<Zagor> that's a good question, which among other things we will be discussing tonight :)
+<Zagor> i need to switch tunnels, brb
+<-- Zagor (~bjst@labb.contactor.se) has left #rockbox
+<wavey> bag: we = .se?
+<alkorr> european people ;)
+<Bagder> yes
+<Bagder> me, Linus, Björn and a forth friend
+--> Zagor2 (~bjst@labb.contactor.se) has joined #rockbox
+<wavey> ok
+--- Zagor2 is now known as Zagor
+<wavey> cool
+<alkorr> oh you mean off-irc, Bagder ?
+<Bagder> we're gonna gather tonight 
+<Bagder> right
+<Bagder> in real life
+<wavey> wow
+<wavey> there's an outside?
+* wavey is scared
+* Zagor is now in a clean, nice, pure ssl tunnel
+<Bagder> you worked out the CONNECT part?
+<Zagor> yup. found a perl script
+<Bagder> coolio
+<Zagor> i'll write up a twiki page
+<Bagder> knowing http pays off B-P
+<alkorr> seriously i see Zagor has change PAIOR and PBIOR to be ((volatile ...)
+<alkorr> i would try to avoid such a thing
+<Zagor> why?
+<alkorr> sometimes to have a byte access is better than a word access
+<wavey> these are registers, yes?
+<Zagor> yes but byte access is a special case
+<alkorr> or a 32-bit access better than a 16-bit access
+<Zagor> also a special case
+<Zagor> this is the normal case
+--> Linus (~linus@labb.contactor.se) has joined #rockbox
+<alkorr> du to the fact, we write them in C, i don't see objections to leave them as address ant programmer to use the word access he wants
+<alkorr> ... and let ...
+<Zagor> it makes a mess in the code to always typecast them. this way, the registers are registers, as defined in the data sheet
+<alkorr> register ???
+<Zagor> if you want to access them in a non-standard way, *then* you do special typecasts
+<alkorr> manual says we can access such registers as well byte as word, so there is no real non-standard way
+<Zagor> well the manual says the register is 16 bits wide, so that's how I define "standard"
+<Linus> I define the "standard size" to be the register size.
+<Linus> I would guess the the size the programmer wants would be the register size in 99% of all cases.
+<alkorr> i try to use a homogene way to access those register, and having SI,HI or QI remove the necessity to guess what size the register is. But due to the fact i'm in minority, i suppose i can only approve your changes unwillingly 
+<Zagor> i really don't like the SI/HI/QI thing
+<alkorr> by the way i could need the addresses of  those register (DMA with SCI0 for example)
+<Linus> Except that noone can guess what QI, SI and HI means without searching in the header files.
+<Zagor> yes, we probably need double macros. one with the address and one for register access
+<alkorr> yes but i find more ugly explicit typecasting anyway
+<Linus> Absolutely. We will probably still nedd both ways of doing it.
+<Zagor> explicit typecasting is good in special cases
+<Zagor> because then it shows that it's a special case
+<alkorr> i use GCC convention which has in internal the modes SI, HI and QI
+<alkorr> if you could find something else, i could be okay
+* Zagor has never seen SI/HI/QI in his 15 years of programming...
+<Linus> Yes. But I have yet to see any C source code using that convention.
+<alkorr> but must be short anyway
+<Linus> Absolutely.
+<alkorr> look at the gcc source
+--> Bagder2 (~chatzilla@as3-3-2.ras.s.bonet.se) has joined #rockbox
+<Linus> I have looked at the GCC source code. The QI/HI/SI stuff is not C it is a pseudo language.
+* Bagder2 tries chatzilla
+<Zagor> Bagder2: good?
+<Bagder2> nah, I think I prefer X-chat
+<alkorr> yes, your defines is not much more standard than mine anyway
+<Zagor> actually, they are
+<-- Bagder2 has quit (Remote closed the connection)
+<Zagor> look at any microcontroller C compiler
+<Zagor> registers are reserved uppercase symbols
+<alkorr> i don't call them 'standard'
+<Zagor> well no, but it's the most common way to represent registers
+<alkorr> it is not that kind of stuff i will call standard
+<alkorr> for me, they are libs like stdlib or stdio, no our own source
+<Zagor> I agree, it's not a standard. but it's a style that many people have seen before
+<adi|sleep> yeah.. yeah.. well.. well.. your momma!
+* Zagor twitches. Adi - awake?
+<adi|sleep> not really... 
+<adi|sleep> for what its worth.. and i know its not much... but to me... SI HI QI makes no sense...
+<Linus> BTW, the Archos guys have really made an odd I2C bus connection between the 7034 and the MAS... :-(
+<adi|sleep> because to anyone who doesn't immediatly recognize it.. well.. they are clueless to what it means..
+<adi|sleep> but thats just my opin...
+<alkorr> so change them for another convention
+<Zagor> that's my point exactly
+<Linus> and the MAS uses a really odd I2C protocol variant...
+<Bagder> Linus: will it set any limitations or just make it difficult?
+* adi|sleep also points out he isn't attacking anyone...
+<Linus> A little tricky...and perhaps slower that necessary.
+<alkorr> anyway, for me they are not really register since SH7034 use a memory map to access peripheral registers => not a register for SH, register for peripheral on-chip.
+* Linus agrees with adi|sleep
+<alkorr> Linus: what about the trouble ?
+<Zagor> alan: it's the same thing. many controllers use memory-mapped registers
+<Linus> For example the PIC
+<Zagor> and the PowerPC
+<Linus> Well, not the POowerPC core, but all PowerPC-microcontrollers
+<Zagor> yes
+* adi|sleep points out that your reality is nothing but lies and baldardash and he is happy to say he has know understand of it.
+<Linus> And the 8051, IIRC
+* adi|sleep goes back to sleep
+<Zagor> adi seems a bit... off ?
+<Linus> Zombie?
+<adi|sleep> me? no no no....
+<Bagder> so, he's talking in his sleep ;-)
+<adi|sleep> im on 'nuetrel'
+<Zagor> a victim of the Umbrella Corporation?
+<alkorr> i make a difference between cpu register and port registers that all. The way to access them is different
+<adi|sleep> which is latin for "its way to fucking hot and humid outside for 0430
+<adi|sleep> "
+<alkorr> one use direct opcode, the other use peek/poke
+<alkorr> that's all
+<Linus> Agreed. You dont access the CPU registers at all in C source code.
+<Bagder> poke 53280, 0
+<Linus> Black border
+<alkorr> a reset ?
+<alkorr> Linus: about I²C ?
+<adi|sleep> then what did the old "register" thing in C do?
+* Bagder hands the award to Linus
+<alkorr> what's the trouble
+adi|atWork adi|sleep adi|atWork adi|sleep <Zagor> adi|sleep: it tries to allocate a variable to a register
+<adi|sleep> nods
+<Zagor> instead of putting it on the stack
+<adi|sleep> okay.. now i remember.
+<alkorr> no one uses anymore register, because a lot of C compiler implicily uses registers as possible
+<Linus> They have used a diode to simulate an open collector bus. That makes it tricky to communicate in both directions.
+* Zagor agrees
+<alkorr> so register is a void attribute in gcc
+<Zagor> yup
+<Bagder> yes
+<Bagder> but then gcc is a mighty fine compiler
+<Bagder> there are a bazillioin of worse ones out there
+* Bagder has been hit by a few
+<Linus> GCC is good on some processors, worse on others.
+<Bagder> true
+<Bagder> but it has a good general engine
+<Linus> Generally, GCC wants CPU's with a lot of registers
+<adi|sleep> well don't we all?
+<alkorr> for IA32 or SH, humm
+<adi|sleep> i mean.. come on.. cpus with lotsa registers are just so much more sexy
+<adi|sleep> not to mention better in bed.
+<adi|sleep> speaking of bed
+<alkorr> IA64 you mean
+<Linus> ADI. Are you drunk? :-)
+<adi|sleep> only with powerlessness
+* adi|sleep cackles evilly
+<Bagder> I bet its the heat
+<alkorr> Linus: i'm not sure to understand, what do you mean by "communicate in both directions" ?
+<adi|sleep> nods
+<adi|sleep> and the lack of decent sleep.
+* adi|sleep giggles furiously as he missreads sleep with sheep...
+<adi|sleep> no wouldn't _that_ have been a freudian slip.
+<Zagor> hehe
+<Linus> I mean that the data (and the clock in the case of the MAS) is bidirectional. Both read and write. And the diode makes that difficult.
+<Linus> But not impossible. Just tricky.
+<Zagor> what's the australian definition of "safe sex"?
+* wavey pats adi|sleep on the head
+<Zagor> you X-mark the sheep that kicks
+* wavey -so- needs to learn some electronics
+<wavey> is there a beginners bible?
+<Linus> I don't know
+<Linus> It's really simple. Just have a father that explains it to you. :-)
+<alkorr> yes but you can read, cannot you ?
+<wavey> er
+<alkorr> i'm talking to Linus :)
+<wavey> ah
+<alkorr> read MAS
+<wavey> good :)
+<Linus> hahaha!
+<alkorr> :)
+<Linus> Yes I can read. Ti is working. But it is slow at the moment. I will add another trick from my bag to make it faster.
+<alkorr> it is the code or the electronic part which is really slow ?
+* Bagder likes bags with tricks
+<Linus> Tha MAS is really nasty, as it drives the clock even when it is slave. :-(
+<Linus> The data line takes a lot of time to go from 1 to 0 when reading, since the line is unconnected because of the diode. I will have to discharge it explicitly to make it faster.
+<alkorr> the MAS manual says it can held the clock to let it handle some things before reading further data
+<alkorr> okay
+<Linus> Yup. And that is really nasty.
+<Linus> Especially since the clock is also connected via a diode.
+<alkorr> in fact, you're telling us that MAS could run faster if the data line can discharge more rapidly
+<Linus> Only the I2C line. That is only used for settings and configuration.
+<alkorr> but it only regards the I²C line
+<Linus> A pull-down would really help.
+<alkorr> okay, not a real problem, just a nasty design
+<Linus> Exactly.
+<alkorr> lines I²C shouldn't have pull-ups ? 
+<Linus> Yes. On the bus side. I was talkin about the CPU side of the diode.
+<alkorr> okay
+<alkorr> just a note
+<alkorr> if you disassembly the I²C part of the player firmware, they don't use the common way to set/clear the I²C lines
+<alkorr> instead of using IN direction to set line at 1, they use OUT direction and set to 1
+<alkorr> that is, when setting port, always in OUT direction from the CPU
+<alkorr> when reading (checking line status), in IN direction 
+<wavey> daniel - you still capturing the logs?
+<Bagder> I do
+<alkorr> I suppose you don't use the same way to communicate with MAS (when setting 0, OUT dir.; when setting 1, IN dir.)
+<wavey> cool
+<wavey> can we automate it?
+<wavey> stick a bot on and pipe it to the website?
+<Bagder> it is certainly possible
+<wavey> and add a search engine? :)
+<wavey> this is a wealth of info
+<Zagor> i added a search form yesterday
+<Zagor> it uses google
+<wavey> especially to newcomers that will come along
+<wavey> cool
+<wavey> uses google's cache or realtime search?
+<Zagor> the cache
+<wavey> ok
+<Zagor> but they index the site pretty regularly
+<wavey> lovely
+<wavey> regularly or frequently? ;)
+<Zagor> frequently :)
+<wavey> i've nearly got the C++ XML library ready for inclusion
+<wavey> just getting the CORBA interfaces ready first
+<wavey> this firmware will kick ass
+<Zagor> haha
+<Bagder> hihi
+<Bagder> what about the web browser? ;-)
+<wavey> :)
+<alkorr> bad you will need to convert it to plain C ;)
+<wavey> now, this might be a ridiculous idea...
+<wavey> but can we use more of the limited memory buffer for audio 
+<Zagor> more?
+<alkorr> ???
+<wavey> hang on
+<wavey> by using the disk to store our program data?
+<wavey> and load it back when needed?
+<alkorr> we have a 2 MB DRAM, whatever we can have in
+<wavey> or is that silly
+<Zagor> that is silly :)
+<alkorr> depending what you want to do
+<alkorr> i think to understand what Wavey means
+<alkorr> yes it could be a cool idea but not the priority
+<Linus> alkorr: That is why they have the diode. They don't want to set it ton IN to drive a 1 on the bus.
+<Linus> For some reason.
+<alkorr> the possibility to load a game when you want to play, instead always having them in memory 
+<wavey> yeah, keep a nucleus of program in memory, and demand load the bits we need
+<wavey> how large is the footprint of archos firmware?
+<alkorr> archos apparently has no real dynamic memory
+<alkorr> it seems to use a lot of tables
+<Linus> What is "real dynamic memory"?
+<Zagor> malloc
+<Linus> Ah.
+<alkorr> so their size should be fixed
+<Zagor> i guess :)
+<alkorr> malloc is a dynamic memory
+<alkorr> a true dynamic memory, if you like
+<wavey> do i misremember malloc's free not shrinking the process memory usage?
+<wavey> not that it matters
+<Zagor> that's OS dependent
+<Bagder> wavey: that's a unix thing
+<wavey> with only 1 process
+<wavey> ok
+<alkorr> what i mean is if we want to have the ability to load specific code at a ponctual time
+<alkorr> you surely need a dynamic memory
+<alkorr> so when we only use the player (or recorder)
+<alkorr> we can use all the memory
+<alkorr> and to prevent us to work with fixed address (so binary code not reusable with new firmware)
+<alkorr> but you still need a code addresses relocator :) well, not the first thing rockbox will have
+<wavey> no one knows how large the archos firmware is in memory?
+<Zagor> nope :)
+<Linus> I xould guess about 100K.
+<wavey> interesting :)
+<Linus> But I might be wrong
+<wavey> their firmware decompresses the mod, yes?
+<wavey> .ajz
+<alkorr> in fact we can export some data in harddisk
+<alkorr> for exemple if we have messages in different language
+<Linus> I guess the recorder decompreses the firmware. That would explain the long start time.
+<wavey> i can't see the benefit of a compressed mod
+<wavey> except to piss people off :)
+<Linus> Neither can I.
+<Bagder> save disk space? hehehe
+<wavey> hehe
+<wavey> ooh, 60GB in your palm. 
+<Linus> Download time on the internet? I mean if you can save 1 second... :-)
+<alkorr> Wav. scrambling maybe
+<PsycoXul> so like yeah
+<PsycoXul> i remember all the things my c64 could do with 1mhz
+<wavey> 1mhz? or 1mb?
+<PsycoXul> what interesting things can be done with a whole 12mhz of processing power
+<PsycoXul> heh
+<wavey> ah
+<wavey> yes :)
+<PsycoXul> i just with the player's LCD was even just a tiny bit better
+<PsycoXul> like to be able to draw the blocks between characters
+<PsycoXul> heh
+<Bagder> yup, all the fun games will only be for the recorder :*)
+<PsycoXul> nah
+<PsycoXul> i did a rather nice little thing where you run around a map overhead
+<PsycoXul> and it scrolls through the 2 lines quite nicely
+<alkorr> i think the messages inf the firmware must take a lot of space, it could be interesting to see when removed how many it saves space in memory to have just the messages of the right langage
+<PsycoXul> it's pointless till i can read levels in files and such but i just wanted to find out if it was possible to make a game playable in 2 lines
+<PsycoXul> and it is
+<PsycoXul> just be cooler with a little more capabilities
+<PsycoXul> heh
+<Bagder> that's might cool
+<Bagder> +y
+<alkorr> to have a < 64 KB code should be a good point 
+<Zagor> alkorr: yes
+<Zagor> we have a very big advantage in that we can always compile in just the features and data that we need
+<Linus> Hehe. The libc code is about 30k...
+<Bagder> ick
+<Zagor> libc? who needs libc?
+<alkorr> for div
+<alkorr> or shift operations
+<alkorr> when the shifter is not an immediate
+<Linus> I use it for sprintf at the moment. The string functions are there too
+<Bagder> there's a diet libc we could check out
+<Zagor> we can use a simpler sprintf
+<Linus> We have the source. We remove what we don't want.
+<Zagor> precisely
+* Bagder agrees
+<Linus> Actually, I think newlib ha a diet sprintf.
+<Linus> s/a/has/
+<Bagder> "ha has" ? 
+<alkorr> but due to the fact you use a library, you only integrate functions from libc you really use in your source*
+<Bagder> heheh
+* Linus has thick fingers today
+<Linus> Not functions, modules
+<Linus> Unfortunately, many finctions are located in the same .o file in the library, and they often call each other.
+<alkorr> ah bad
+<Linus> But correctable.
+<alkorr> i thought they used a .c file for each functions
+<Linus> Often they do.
+<Linus> And sprintf() is a mighty beast.
+<alkorr> shure
+<Linus> I use it for debugging output at the moment.
+<alkorr> using sprintf from linux?
+<Linus> Nope. In the firmware. On the GDB console.
+<Bagder> a less capable sprintf() could of course be much smaller and still do just about what you'd want
+* Linus thinks of Trio
+<Bagder> that is not less
+<alkorr> Linus: i know but i'm speaking about what version sprintf is
+<Linus> But you know how to strip it.
+<Bagder> true ;-)
+<Linus> I don't know of any versions of sprintf. It's just Newlib.
+<Linus> Version 10.0.1, IIRC
+<Bagder> we probably want a sprinf() for screen text formatting too
+<Zagor> yup
+<alkorr> one possibility
+<wavey> i saw a tiny sprintf for gameboy advance
+<Linus> Go get it.
+* wavey looks
+<alkorr> is to use a generic printf which call a function for a character
+<alkorr> not fast
+<Bagder> well that's how they all work
+<alkorr> but you can directly display without have a buffer
+<Bagder> more or less
+<alkorr> so ?
+<Bagder> so that is probably what we'll get
+<Bagder> but
+<alkorr> so when you use this function, just call this function with a callback ?
+<Bagder> I doubt that anyway will printf() to the display
+<Bagder> anyone
+<alkorr> ah yeah, it is another thing for the LCD recorder
+<alkorr> story
+<Bagder> right
+--- Zagor is now known as Zagor|lunch
+--- Linus is now known as Linus|lunch
+<alkorr> c u
+<Bagder> bye Alan
+<-- alkorr has quit (Read error: 110 (Connection timed out))
+<wavey> http://www.frotz.net/gbadev/remote/printf.c
+<wavey> pretty tiny
+<Bagder|food> yes
+--- Zagor|lunch is now known as Zagor
+--- Linus|lunch is now known as Linus
+<wavey> http://yugop.com/ver3/stuff/03/fla.html
+<wavey> cute
+<wavey> (and work safe)
+<Zagor> cool!
+<Bagder> http://www.oqo.com/ <= seen this?
+<Zagor> bleh, flash
+<Bagder> yeah
+<Bagder> annoying site, cool box
+<-- Linus (~linus@labb.contactor.se) has left #rockbox
+<Zagor> do you know why uisimulator has a garbled window title?
+<Bagder> no
+<Zagor> what's the variable in emacs that says to only indent with spaces?
+<Bagder> (setq-default indent-tabs-mode nil)
+<Bagder> I think
+<Zagor> ok
+<Zagor> closing tunnel, brb
+--> Linus (~linus@labb.contactor.se) has joined #rockbox
+<Zagor> lcd_update in lcd-x11.c doesn't ever clear pixels, does it?
+<Bagder> uh, no ;-)
+<Zagor> i noticed :)
+<Bagder> oops
+* Zagor has been scratching his head a while over this :)
+<Bagder> I'm not sure how to do that the best possible way though
+<Bagder> I mean to avoid flickering
+<Zagor> how about just redrawing the whole screen. performance is not really an issue on X
+<Zagor> flickering only happens if you do it very frequently
+<Zagor> or maybe have an "old" array which you compare against
+<Bagder> well, we would need to fill the whole rect first, then draw all pixels
+<Zagor> and then draw all new and clear all old
+<Bagder> that's what I had in mind
+<Zagor> so do it :)
+<Bagder> can't do it right now
+<Zagor> k
+<Bagder> it'll have to wait a bit
+<Linus> The I2C is rocking like HELL! And fast too!
+* Zagor wonders just how much hell is rocking
+<Bagder> any sounds from the MAS yet?
+<Linus> Wait. There's a bunch of commands to be sent to it to configure it.
+* Bagder caaaan't wait ;-)
+* Linus wants to please Bagder
+* Zagor can't wait for a working lcd_update...
+<Bagder> so just clear the screen first
+<Zagor> hmm, what does this "X11" mean? ;)
+* Linus thinks Bagder is lazy
+* Bagder reminds you about who wrote the uisim in the first place ;-)
+<Zagor> so tell me, how do I clear the screen?
+<Bagder> XDrawRect() or XFillRect() or something
+<Zagor> ok
+<Bagder> find a page about one of the other X* functions and click some links
+<Bagder> that's how I've made it this far ;-)
+--> alkorr (jbcoax@srs05v-2-184.n.club-internet.fr) has joined #rockbox
+<Linus> Hi alan!
+<Linus> The I2C is rocking like HELL! And fast too!
+<alkorr> hi again
+<alkorr> how do you do ? :)
+* Zagor has a little surprise for you all...
+<Linus> I drive the data and clock lines low right before switching from output to input. That way I don't have to wait for the slow transition.
+<alkorr> uh ? i mean how do you get it ? :)
+<alkorr> okay
+* Linus is waiting for Zagor
+<alkorr> so you force discharge by this way
+<Zagor> soon
+<Zagor> soooooon...
+<Linus> Yup. Works like a charm.
+<alkorr> hum some news from Dragan ?
+<Zagor> uh, i haven't mailed him yet. i forgot...
+* Bagder pokes Zagor with a large stick
+* Linus hits him hard
+<Zagor> alan: are you working on the fat code?
+<Zagor> then i shouldn't be poking on it yet... :)
+* Linus sees a major commit from Alan
+<alkorr> a lot of things to add in fact
+<alkorr> so don't rush
+<Bagder> lots of c++ comments ;-)
+* Bagder hides
+<Zagor> hehe
+<alkorr> sorry but there were here before you ;P
+<Linus> You'll be surprised how little code you need to screw up your hard drive... :-)
+<Zagor> lol
+<alkorr> to screew up ? you mean to destroy ?
+<Linus> Yup.
+<Linus> No, not destroy. Just screw up.
+<alkorr> well my code never destroys or screws up ;P
+<Linus> Of course. Not _your_ code. :-)
+<alkorr> but you're right. Just a lock command and you are bad under windows
+<alkorr> hopefully i can unlock with your modified drive *relief*
+<alkorr> driver
+<Zagor> we need to fix something like that for the recorder too
+<alkorr> ah yes USB 2.0
+<alkorr> just a precision about my fat.c, i think the main thing that will stir you is probably the ata callback mechanism
+* Linus is still waiting for Zagors surprise
+* alkorr too
+<Zagor> paitence, children... :)
+<Zagor> patience, even
+<Zagor> alkorr: you mean except for the 1-byte arrays? ;)
+<alkorr> to understand what is it : it is way to handle, compute, swap or format data during a read or write operation in a atomic way (we cannot have simultanous readings sectors)
+<alkorr> yes
+<alkorr> because BPB is a real mess : all the fields are unaligned
+<alkorr> and using callback will create a too large function whereas I just need some fields in fact
+<alkorr> normally i don't keep in memory any boot sectors (like MBR, BPB or FSINFO)
+<wavey> what's the history of the disk code we're cutting?
+<wavey> has it been tried and tested elsewhere?
+<wavey> or is it all new
+<alkorr> yes in the obsolete fat.c i gave to Zagor 
+<alkorr> and the ones I lost during a harddisk crash
+<alkorr> SH really dislikes misunligned accesses
+<Bagder> I gotta go, see ya guys later
+**** ENDING LOGGING AT Fri Apr 19 14:34:13 2002
+