| [00:00] | <may1937> | yeah it'll interrupt when it reaches TACCR0 |
| [00:00] | <crazy6> | well then that doesnt really make a PWM signal, does it? I need to toggle something when the timer reaches an intermedia value, say, 256 |
| [00:00] | <crazy6> | (if it is counting to 512) |
| [00:01] | <may1937> | well either change the TACCR0 value between interrupts, or use a counter in your interrupt handler |
| [00:01] | <crazy6> | aha, ok, I shouldn't use the Capture/Compare function? |
| [00:02] | <may1937> | that is for capturing external signals right? or am i reading this wrong |
| [00:03] | <may1937> | oh i am wrong |
| [00:03] | <crazy6> | I think in capture mode it is for timing external signals |
| [00:03] | <crazy6> | but I think it can run as compare |
| [00:04] | <crazy6> | if I set CM0 , somehow |
| [00:04] | <crazy6> | I think TACCTL0 or TACCTL1 = CM0 |
| [00:05] | <may1937> | hmmm what is CM0? |
| [00:06] | <crazy6> | Caputre Mode 0, I think, pg 179 at the bottom |
| [00:06] | <may1937> | oh there it is |
| [00:06] | <may1937> | CM0 is no capture |
| [00:06] | <crazy6> | so I guess I don't want it on for TACCR0, because that sets what value the timer resets at |
| [00:08] | <may1937> | yeah so you want compare mode |
| [00:08] | <may1937> | with the appropriate output mode |
| [00:10] | <may1937> | probably set TACCTL = (SCS | OUTMOD4 | CCIE) or so? |
| [00:11] | <crazy6> | uh, yeah? |
| [00:11] | <crazy6> | you'd know better than me |
| [00:11] | <may1937> | look on page 189 |
| [00:12] | <crazy6> | and _EINT(); at some point? |
| [00:12] | <crazy6> | is ther ejust a single Timer_A interrupt, and I have to check which flags are active? or are there sep. interrupts for the compare triggering and the timer resetting? |
| [00:12] | <may1937> | woah what compiler is that |
| [00:13] | <crazy6> | the IAR Kickstart demo |
| [00:13] | <may1937> | you know there is a gcc port? |
| [00:14] | <crazy6> | yeah but I havent installed it |
| [00:14] | <crazy6> | and this one is nice becasue it has config files for all the chips |
| [00:15] | <may1937> | gcc does too |
| [00:15] | <may1937> | it is high qualit |
| [00:15] | <crazy6> | oh really |
| [00:15] | <may1937> | y |
| [00:15] | <crazy6> | with all the registers mapped out? |
| [00:15] | <may1937> | yup |
| [00:15] | <crazy6> | hrm ok |
| [00:15] | <crazy6> | I dont know if I'd have a way to program the code in over Spy-Bi-Wire, though |
| [00:15] | <may1937> | yeah not sure about that |
| [00:15] | <may1937> | i used to work on a multithreaded os that supported msp4301611 |
| [00:16] | <crazy6> | wow |
| [00:16] | <may1937> | you could check it out if you want but it's kind of big |
| [00:16] | <may1937> | mantis.cs.colorado.edu |
| [00:16] | <crazy6> | yeah my chip only has 2KB of program flash |
| [00:17] | <crazy6> | and the compiler only does 4KB code max |
| [00:17] | <crazy6> | all I want to do it control brushless DC motors. Maybe AC servo motors. |
| [00:17] | <crazy6> | and read encoders and such |
| [00:18] | <crazy6> | maybe some fun stuff with Nordic wireless or Zigbee or something |
| [00:18] | <may1937> | do the timers all share an interrupt vector? i thought i saw that somewhere but i can't find it now |
| [00:18] | <may1937> | woah no way you'd get zigby in 2K flash is there?? |
| [00:19] | <crazy6> | yeah |
| [00:19] | <crazy6> | I think the Nordic wireless is supposed to be super easy |
| [00:19] | <may1937> | we had cc2420 (802.15.4) support over SPI |
| [00:20] | <crazy6> | wow, not bad. yeah, I think sparkfun.com sells a nordic on a littel breakoutboard tha tI could do SPI or I2c over. maybe. |
| [00:20] | <crazy6> | if I knew what I was doing |
| [00:21] | <may1937> | this is the platform we were using for msp430: moteiv.com |
| [00:21] | <may1937> | they are cheap |
| [00:21] | <may1937> | $130, includes a break-out section |
| [00:21] | <crazy6> | thats a little pricey |
| [00:21] | <may1937> | for a manufactured board? radio and all? |
| [00:21] | <crazy6> | although I dropped $150 on a Xilinx FPGA starter board. but it had lots of stuff on it. |
| [00:22] | <may1937> | we looked at building our own, they would have been $200+ |
| [00:23] | <may1937> | shit i need to get going now can i answer anything else real quick for you? |
| [00:23] | <crazy6> | nah thats ok for now |
| [00:23] | <crazy6> | I'll be back some other time maybe |
| [00:23] | <may1937> | ok good luck with your project |
| [00:23] | <crazy6> | thanks for hte help |
| [00:23] | <may1937> | np, see ya |
| [00:44] | <sourcerror> | crazy6: I have one of those mps430 USB kits. has nothing to do with this room which is about the OSD which uses DM320 platform |
| [00:47] | <sourcerror> | s/mps430/msp430/ |
| [01:23] | <eigma> | anyone around who can help with a "hardware FP, software FP" problem? |
| [01:24] | <crweb> | whats a FP? |
| [01:24] | <eigma> | :P |
| [01:24] | <crweb> | no seriously... |
| [01:24] | <eigma> | floating-point? |
| [01:24] | <crweb> | maybe i'm just having a brain fart, but i can't figure out what FP would be other than frame pointer |
| [01:25] | <crweb> | ah |
| [01:25] | <eigma> | I'm talking about ld's "X.o uses hardware FP, whereas Y uses software FP" |
| [01:25] | <eigma> | never heard of it, I assume? |
| [01:25] | <crweb> | well, normally without any context FP could mean anything |
| [01:26] | <crweb> | floating-point i have heard of yes. |
| [01:26] | <crweb> | OSD uses a software FP, as the DM320CS54x is an integer only unit. |
| [01:27] | <eigma> | I'm aware |
| [01:27] | <eigma> | apparently the toolchain was compiled with hardware FP.. at least from userland's perspective |
| [01:27] | <eigma> | "libpthread.so.0 uses hardware FP, whereas sdltest uses software FP" |
| [01:27] | <eigma> | ^^^ ld spits that out at me |
| [01:28] | <crweb> | ld where? |
| [01:28] | <crweb> | theres no ld on the osd firmware |
| [01:28] | <eigma> | in the toolchain??????? |
| [01:28] | <crweb> | running the toolchain, and the OSD are 2 different things |
| [01:28] | <crweb> | the toolchain is compiled to run on x86 |
| [01:28] | <eigma> | I never said I was running this on the OSD |
| [01:29] | <eigma> | I am cross-compiling on a PC, for the OSD (well.. the m:robe, but close enough) |
| [01:29] | <eigma> | point is, it's a DM320 |
| [01:29] | <crweb> | no, the OSD is a DM320 |
| [01:29] | <crweb> | the toolchain is x86 |
| [01:30] | <crweb> | anyway. it uses nwfpe |
| [01:32] | <crweb> | eigma: are you using scratchbox to compile sdl? |
| [01:32] | <eigma> | sdl is already compiled |
| [01:32] | <crweb> | its an sdl problem |
| [01:33] | <eigma> | I don't see how that can be |
| [01:33] | <eigma> | none of the sdl filenames appear in the error messges |
| [01:33] | <crweb> | libpthread.so.0 uses hardware FP, whereas sdltest uses software FP |
| [01:33] | <crweb> | sdltest is an sdl file name isn't it? |
| [01:34] | <eigma> | I wrote it.. it could just as well contain just "printf" |
| [01:34] | <crweb> | ? |
| [01:34] | <crweb> | you wrote ld? |
| [01:34] | * crweb is very confused | |
| [01:35] | <crweb> | are you or are you not trying to link to sdl? |
| [01:35] | <eigma> | I will show you my files so there is no confusion ,ok? |
| [01:36] | <crweb> | ok |
| [01:36] | <crweb> | did you build sdl? |
| [01:36] | <eigma> | no |
| [01:36] | <crweb> | who did? |
| [01:36] | <eigma> | someone else. I have a binary (libsdl.so) compiled for the ARM and headers |
| [01:37] | <crweb> | there are many different arm's |
| [01:37] | <eigma> | it's an ARM5, compatible with the one I'm using |
| [01:37] | <crweb> | obviously not |
| [01:37] | <eigma> | you have got to be fucking kidding me |
| [01:37] | <crweb> | some arms have FP, some don't |
| [01:37] | <eigma> | are you seriously telling me you think a binary compiled with -marmv4 won't run on a -marm926ejs ?? HAHA |
| [01:38] | <crweb> | when you have something that uses a software or hardware fp unit, and it doesn't exist. yes. |
| [01:38] | <eigma> | haha |
| [01:39] | <crweb> | how can something run with a FP unit, if it doesn't exist and needs FP? |
| [01:39] | <eigma> | I have no idea how you pulled off that scratchbox development kit, but honestly, every time I've asked for your help, you've done nothing but waste my time |
| [01:39] | <crweb> | whatever |
| [01:39] | <eigma> | forget I said anything; sorry for the bother. |
| [01:39] | <crweb> | can't use hardware taht doesn't exist |
| [01:39] | <crweb> | would you like me to build you an sdl that works? |
| [01:40] | <eigma> | if it means I can link against it without installing scratchbox, then go for it |
| [01:40] | <crweb> | scratchbox has nothing to do with being linking to sdl |
| [01:40] | <eigma> | good |
| [01:40] | <crweb> | i asked if you used scratchbox because i thought you build sdl with the wrong options |
| [01:41] | <crweb> | but you didn't build sdl, so it didn't matter |
| [01:41] | <crweb> | so as you can see, i didn't persue scratchbox questions anymore |
| [01:41] | <eigma> | I said that I didn't want to have to use scratchbox because I know you would immediately try to shove scratchbox down my throat |
| [01:42] | <crweb> | all i did was ask you if you did |
| [01:42] | <eigma> | anyway. sorry for that comment. |
| [01:42] | <crweb> | if it's wrong to get bearings on a situation before exploring answers then f'ing sue me. |
| [01:43] | <crweb> | I'll see if i can get it built |
| [01:43] | <eigma> | thank you |
| [01:43] | <crweb> | the toolkit for the arm5 version might have used a different type of FP |
| [01:43] | <crweb> | its hard to tell |
| [01:44] | <eigma> | Makefile: #include <SDL.h> |
| [01:44] | <eigma> | #include <stdio.h> |
| [01:44] | <eigma> | int main(void) { |
| [01:44] | <eigma> | printf("fdsa"); |
| [01:44] | <eigma> | return 0; |
| [01:44] | <eigma> | } |
| [01:44] | <eigma> | argh |
| [01:44] | <eigma> | sorry |
| [01:44] | <eigma> | Makefile: paste.scesoc.ca |
| [01:44] | <eigma> | sdltest.c: paste.scesoc.ca |
| [01:46] | <crweb> | btw, a non-scratvhbox toolchain package is available from deb www.limesg.com ./ for ubuntu/debian. Pretty useful if you don't want the whole svn distro on your station |
| [01:46] | <crweb> | could use testers |
| [01:46] | <eigma> | it's okay.. I just need something that works |
| [01:47] | <crweb> | i personally can't stand scratchbox, but its what everyone wanted |
| [01:47] | <eigma> | oh good |
| [01:48] | <crweb> | not really sure the best way to go about this. what if i give you the .so and .h's |
| [01:48] | <eigma> | sure |
| [01:49] | <crweb> | looks like you already have a setup that would be pretty quick to build with |
| [01:49] | <eigma> | haha |
| [01:49] | <crweb> | wait |
| [01:49] | <crweb> | $(shell sdl-config --libs) |
| [01:50] | <eigma> | that's just -lSDL -lpthread |
| [01:50] | <crweb> | ok good |
| [01:50] | <crweb> | and --clags? |
| [01:51] | <crweb> | odd that sdl-config doesn't have the -L paths |
| [01:51] | <eigma> | -I/usr/include/SDL -D_REENTRANT |
| [01:51] | <crweb> | see, its using your desktop's sdl-config |
| [01:51] | <crweb> | probably should hard code those instead of using sdl-config |
| [01:51] | <eigma> | tried, with no change |
| [01:51] | <eigma> | besides, what do headers have to do with link erros |
| [01:51] | <crweb> | right, just sayin |
| [01:51] | <eigma> | *errors |
| [01:52] | <crweb> | if sdl-config --libs gave a -L/usr/lib/SDL -lSDL then it could be pulling from your x86, but you said its not |
| [01:52] | <eigma> | correct |
| [01:53] | <crweb> | what version do you want? |
| [01:53] | <crweb> | 1.2.11? |
| [01:53] | <eigma> | whatever |
| [01:53] | <eigma> | can you make it a static build then? |
| [01:53] | <eigma> | actually no |
| [01:53] | <eigma> | shared works better |
| [01:53] | <crweb> | i can try. sometimes oss doesn't setup nice make files for that though |
| [01:54] | <crweb> | ok |
| [01:56] | <crweb> | ah, sdl uses rpath |
| [01:56] | <crweb> | fun fun |
| [01:57] | <eigma> | AHA! |
| [01:57] | <eigma> | oh, how I love making the toolchain let me do dangerous things.. "-Wl,--no-warn-mismatch" |
| [01:57] | <crweb> | heh |
| [01:58] | <crweb> | the official fix is to recompile sdl with both FP types |
| [01:58] | <eigma> | yuck |
| [01:58] | <crweb> | --msoftfp |
| [01:58] | <eigma> | let's see if the binary runs now.. |
| [01:59] | <eigma> | yeeeep! |
| [01:59] | <crweb> | good |
| [01:59] | <crweb> | i'd test FP just to be sure |
| [02:00] | <eigma> | ah, excellent! SDL calls work too.. |
| [02:00] | <crweb> | let me know if you get NWFPE errors |
| [02:00] | <eigma> | I don't use FP anyway, so I don't really care :) |
| [02:00] | <crweb> | lots of window/drawing stuff does use fp |
| [02:00] | <crweb> | automatically |
| [02:01] | <eigma> | but.. I don't use that :) this program's only purpose is to debug the SDL support for my fb driver.. :) |
| [02:01] | <crweb> | qt gives us a large number of NWFPE errors on the FB |
| [02:01] | <eigma> | "FB"? framebuffer? |
| [02:01] | <crweb> | yes |
| [02:02] | <eigma> | hm.. my qt runs fine |
| [02:02] | <crweb> | I've been collecting the data |
| [02:02] | <crweb> | opie? or qtopia4 ? |
| [02:03] | <eigma> | opie |
| [02:03] | <crweb> | I'm using qt4 |
| [02:03] | <eigma> | this image exactly --> familiar.handhelds.org |
| [02:04] | <crweb> | what version of opie is that? |
| [02:04] | <eigma> | some really ghetto one |
| [02:04] | <crweb> | pretty sure it still uses qtopia 2 |
| [02:04] | <crweb> | 2.11 or something like that |
| [02:08] | <crweb> | www.limesg.com |
| [02:08] | <eigma> | damn, I know I saw an an about tab somewhere.. can't find it now |
| [02:11] | <eigma> | anyway, there's libqte.so.2.3.10, libqpe.so.1.5.0, libopiecore2.so.1.9.4... |
| [02:12] | <crweb> | yeah, those might work ok |
| [02:12] | <crweb> | teh FP errors seem to be version to version |
| [02:12] | <crweb> | and 2.3 is way old |
| [02:13] | <crweb> | www.limesg.com |
| [02:13] | <crweb> | sdl 1.2.11 |
| [02:13] | <crweb> | just a quick build, not much thought put into it |
| [02:13] | <eigma> | uh, it's okay.. I got it working with the binaries that are already in the distro |
| [02:14] | <eigma> | thanks though |
| [02:14] | <crweb> | if you ever get a chance to test it, give it a go |
| [02:14] | <eigma> | mmkay |
| [02:14] | <eigma> | I'd appreciate some help with debugging the FB driver now if you feel like it :P |
| [02:14] | <crweb> | I really can't |
| [02:14] | <nerochiaro> | crweb: i have a more recent sdl built if you want it |
| [02:14] | <crweb> | in like +8 maybe ? |
| [02:14] | <eigma> | lol whatever |
| [02:14] | <eigma> | was mostly a joke anyway |
| [02:27] | <nerochiaro> | eigma: you've got problems with the fb driver ? which problems ? |
| [02:28] | <nerochiaro> | sdl tries to change resolutions when it starts up and fails ? |
| [02:28] | <eigma> | nero: not the IT fb driver fyi |
| [02:28] | <eigma> | modification of cowonfb |
| [02:29] | <nerochiaro> | eigma: oh, you got that working ? when i tried that, it lacked the parts that actually activate the fb layer in hardware |
| [02:30] | <nerochiaro> | can i see these modifications ? |
| [02:30] | <eigma> | yep, I have opie (an ancient version) running on it |
| [02:31] | <eigma> | btw, is IT planning on migrating to beyond 2.6.15 anytime soon? |
| [02:31] | <nerochiaro> | hmm, i'm not sure about opie, but that fb driver might come in very handy. can you share these mods ? |
| [02:31] | <eigma> | svn.devjavu.com |
| [02:31] | <nerochiaro> | and about the kernel, i don't know |
| [02:32] | <crweb> | opie has its own FB system |
| [02:32] | <crweb> | not nano-x or anything |
| [02:32] | <crweb> | well, it uses qtopia's fb |
| [02:32] | <crweb> | or an x11 if you have it |
| [02:32] | <eigma> | that, in turn, piggybacks on fbdev |
| [02:32] | <eigma> | it all comes down to /dev/fb0 either way |
| [02:33] | <nerochiaro> | crweb: but qtopia uses the fb driver on linux |
| [02:33] | <crweb> | right |
| [02:33] | <crweb> | it all uses /dev/fb0 |
| [02:34] | <eigma> | sdl is currently broken on this driver though |
| [02:34] | <crweb> | just a matter of does qtopia draw to x, or does it draw directly |
| [02:34] | <eigma> | trying to fix it |
| [02:34] | <eigma> | qtopia doesn't use x11.. afaik it has its own IPC for graphics |
| [02:34] | <crweb> | eigma: no, it uses both |
| [02:34] | <crweb> | err, either |
| [02:34] | <crweb> | it will use either |
| [02:34] | <eigma> | right |
| [02:35] | <eigma> | you're probably right |
| [02:35] | <eigma> | on my system, it's configured to go direct to the fb |
| [02:35] | <crweb> | yeah, ipaq uses pure qtopia |
| [02:35] | <eigma> | I just realized I have no idea why this driver works.. smem_start is set to an insane value |
| [02:36] | <eigma> | ah, no, nvm, it's fine :) |
| [02:36] | <eigma> | (obviously..) |
| [02:36] | <nerochiaro> | hey folks, totally unrelated, but is there some worm around these days that generate a lot of fake delivery messages ? |
| [02:37] | <eigma> | nero: find anything interesting? |
| [02:37] | <crweb> | nerochiaro: i get about 10-15 a day like that. most of them say they come from myself |
| [02:37] | <crweb> | theres all sorts of stuff going around |
| [02:38] | <crweb> | i do see something interesting |
| [02:38] | <crweb> | trasp.offset transp.length |
| [02:38] | <nerochiaro> | eigma: yeah, that fb driver you linked is definitely a step forward in respect to the one i saw some time ago. the other didn't do any of these outw calls to set hardware |
| [02:39] | <crweb> | eigma: did you download that, or are these your changes? |
| [02:39] | <eigma> | some are my changes |
| [02:39] | <crweb> | nerochiaro: i might have sent you the wrong driver |
| [02:39] | <eigma> | I didn't do much though |
| [02:39] | <eigma> | added the HW init, reformatted some stuff, modified for the mem set up of my device |
| [02:40] | <nerochiaro> | eigma: where did you make these changes from ? |
| [02:40] | <eigma> | I forget.. some cowonfb.c on a forum |
| [02:40] | <crweb> | yeah, nerochiaro i think i sent you the wrong one |
| [02:40] | <crweb> | i meant to send you the one from the forum |
| [02:41] | <crweb> | iAudiophile |
| [02:41] | <eigma> | yep |
| [02:41] | <eigma> | that's the one |
| [02:41] | <nerochiaro> | crweb: way to waste my time :[=] |
| [02:41] | <nerochiaro> | crweb: ;) |
| [02:41] | <crweb> | i must have labeled it wrong |
| [02:42] | <nerochiaro> | no problem, i was just joking |
| [02:44] | <crweb> | eigma: can you grab us the original and email it to tom@limesg.com |
| [02:44] | <crweb> | i can't find my login to iaudiophile |
| [02:44] | <eigma> | it's not on iaudiophile anymore? |
| [02:44] | <eigma> | www.bugmenot.com |
| [02:45] | <nerochiaro> | the weird thing is there's a third cowon fb i've seen floating around that it's not the one eigma linked right now, neither the "empty" one that crweb sent me. it had some extra ioctls too, but i can't recall where i did see it either |
| [02:46] | <nerochiaro> | i was getting fed up with this fb thing some time ago so i kinda threw it in a corner and forgot |
| [02:46] | <crweb> | it says "see attached" but its not attached |
| [02:47] | <crweb> | ah, think i might have it now |
| [02:47] | <crweb> | I was in the archive |
| [02:47] | <crweb> | you have to be on the real site |
| [02:48] | <eigma> | you got cowonfb.c or you still need the original iaudiophile version? |
| [02:48] | <nerochiaro> | if you have it, i'd like to see that too |
| [02:50] | <eigma> | sure, 1 sec |
| [02:50] | <crweb> | got it |
| [02:50] | <crweb> | nerochiaro: looks like they might have a real usb driver too |
| [02:51] | <eigma> | who? me? |
| [02:51] | <crweb> | no, that forum |
| [02:51] | <nerochiaro> | interesting |
| [02:52] | <nerochiaro> | maybe it handles that missing piece that blocks us to do hid |
| [02:54] | <crweb> | nope |
| [02:54] | <crweb> | usb is still storage only. Hub support just adds more ports |
| [02:55] | <nerochiaro> | which is not bad |
| [02:55] | <crweb> | they do have USB-Ethernet, and USB-Wireless working though |
| [02:56] | <eigma> | the original driver I started from is on your server crweb.. www.limesg.com |
| [02:56] | <nerochiaro> | eigma: crweb: so anyone of you can send me the iaudiophile driver ? |
| [02:56] | <blackBench> | hi guys |
| [02:57] | <nerochiaro> | hey blackBench |
| [02:57] | <blackBench> | hi nero |
| [02:57] | <blackBench> | i have a qustion concerning the blackfin bf561 proc |
| [02:57] | <blackBench> | are you familiar with that |
| [02:57] | <nerochiaro> | i know noting about it |
| [02:58] | <eigma> | nero: I'm trying to DCC you the file |
| [02:58] | <blackBench> | do you know someone who does? |
| [02:58] | <nerochiaro> | eigma: thanks |
| [02:58] | <eigma> | np |
| [02:58] | <crweb> | nerochiaro: i think its the same |
| [02:58] | <crweb> | he is right www.limesg.com |
| [02:58] | <crweb> | its the one i gave you already |
| [02:58] | <nerochiaro> | blackBench: the only one who i've heard talk about blackfin is user "suma" or "sumasuma" |
| [02:58] | <blackBench> | oh oke |
| [02:59] | <blackBench> | well thnx anyway |
| [02:59] | <nerochiaro> | blackBench: no problem |
| [02:59] | <crweb> | eigma: nice work on getting it to work |
| [02:59] | <nerochiaro> | eigma: which problems does it still have ? |
| [02:59] | <eigma> | the one I sent you? I don't even remember.. bad memory setup at the very least |
| [03:00] | <eigma> | the one in SVN? sdl is broken on it; haven't tested X |
| [03:00] | <nerochiaro> | no, the one you have fixed and running now (the one in svn) |
| [03:00] | <nerochiaro> | broken how ? |
| [03:00] | <crweb> | possibly an sdl problem no the fb? |
| [03:01] | <eigma> | I'm actually debugging that *right now* |
| [03:01] | <eigma> | so hopefully if you ask me in an hour there will be a fixed version |
| [03:02] | <nerochiaro> | eigma: all right. i just wanted to know which kind of errors or problems it had with sdl. "broken" is a bit, hmm, generic |
| [03:02] | <eigma> | well.. trying to fill half the screen with white results in interlaced white/black lines |
| [03:02] | <nerochiaro> | thanks |
| [03:03] | <eigma> | sorry.. just been trying to get to work on it for about an hour now and getting sidetracked.. just want to get it working |
| [03:03] | <crweb> | bed will now become my friend |
| [03:03] | * crweb passes out | |
| [03:03] | <crweb> | night |
| [03:03] | <eigma> | cya |
| [03:04] | <nerochiaro> | eigma: i understand that. maybe it has something to do with ntsc v/s pal mode ? |
| [03:04] | <eigma> | yes, that was my first thought as well.. the frame vs field mode |
| [03:04] | <eigma> | but haven't had a minute to investigate yet |
| [03:05] | <nerochiaro> | ok, i'll leave you to that then. later |
| [03:05] | <eigma> | sorry!! |
| [03:05] | <nerochiaro> | hey, don't worry, you don't need to apologize |
| [03:38] | <eigma> | aha.. "FIXME: this only works correctly for 240x320 displays" |
| [03:39] | <nerochiaro> | in opie ? |
| [03:39] | <eigma> | in SDL 1.2.7 |
| [03:39] | <eigma> | the qtopia video driver |
| [03:39] | <eigma> | |