| 00:29.44 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-135-251.netcologne.de) |
| 00:31.54 | *** join/#qi-hardware phirsch_ (~smuxi@xdsl-89-0-135-251.netcologne.de) |
| 00:44.37 | *** join/#qi-hardware panda|x201 (~hzhang@123.112.96.237) |
| 01:25.24 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1400:a::7d) |
| 01:52.50 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-135-251.netcologne.de) |
| 02:16.16 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1400:a::83) |
| 03:25.56 | *** join/#qi-hardware jluis (~jluis@32.Red-79-152-171.dynamicIP.rima-tde.net) |
| 03:43.25 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 04:55.16 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.191.67) |
| 05:14.11 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:55.25 | *** join/#qi-hardware pabs3 (~pabs@d122-111-252-61.per801.wa.optusnet.com.au) |
| 05:56.03 | wpwrak | hehe, non sequitur is good today: http://www.gocomics.com/nonsequitur/ |
| 05:57.53 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 06:19.04 | *** join/#qi-hardware Maroni (~user@94.245.254.183) |
| 09:06.08 | *** join/#qi-hardware jurting (~jommpa90_@host-95-193-44-61.mobileonline.telia.com) |
| 09:23.46 | *** join/#qi-hardware kristoffer (~kristoffe@host-78-79-189-161.mobileonline.telia.com) |
| 09:24.39 | *** join/#qi-hardware Ayla (~paul@250.215.70.86.rev.sfr.net) |
| 09:28.29 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120526-0339 |
| 10:28.31 | *** join/#qi-hardware viric (~viric@84.98.77.188.dynamic.jazztel.es) |
| 10:28.33 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 10:41.58 | *** join/#qi-hardware rejon (~rejon@221.221.179.94) |
| 11:52.01 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 11:53.29 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 11:53.46 | *** join/#qi-hardware panda|x201 (~hzhang@123.112.96.237) |
| 11:56.26 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-135-251.netcologne.de) |
| 11:57.52 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host171-91-dynamic.54-79-r.retail.telecomitalia.it) |
| 11:59.43 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.191.67) |
| 12:02.26 | *** join/#qi-hardware phirsch_ (~phirsch@xdsl-89-0-177-94.netcologne.de) |
| 12:06.30 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 12:19.22 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 12:44.14 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.229) |
| 13:25.14 | viric | hm I'm trying to get a serial port to the gp2x and I fail... |
| 13:56.41 | viric | ok got it |
| 13:58.03 | *** join/#qi-hardware phirsch__ (~smuxi@xdsl-89-0-177-94.netcologne.de) |
| 14:14.20 | viric | anyone good on yaffs? |
| 14:14.43 | viric | how can I dump a yaffs into a file so I can mount it with a loop device? |
| 14:18.47 | GNUtoo-desktop | viric, hmmm you need a fake MTD on RAM |
| 14:19.05 | GNUtoo-desktop | to be able to mount a yaffs |
| 14:19.12 | GNUtoo-desktop | else you can just exrtact from it |
| 14:19.15 | GNUtoo-desktop | with some tools |
| 14:19.28 | GNUtoo-desktop | but usually you dump the flash partition with mtd-utils |
| 14:20.25 | viric | ah ok |
| 14:24.08 | viric | thank you |
| 14:33.33 | viric | I've lots of <7>**>>ecc error unfixed on chunk 3844:0 |
| 14:35.19 | mth | is the OOM area configuration correct? |
| 14:35.28 | mth | you have to tell Linux where the ECC bytes are |
| 14:35.41 | viric | hm no idea |
| 14:35.42 | mth | and some devices use different layout than others |
| 14:35.52 | viric | it's the stock firmware in the gp2x |
| 14:35.56 | viric | I expect them to have it right |
| 14:36.14 | mth | and you're running their kernel as well? |
| 14:36.19 | viric | yes |
| 14:36.53 | mth | ok, then this should not be the issue |
| 14:38.29 | *** join/#qi-hardware rejon (~rejon@221.221.179.94) |
| 14:39.00 | viric | mth: do you use as a serial port terminal emulator? |
| 14:40.23 | mth | minicom |
| 14:40.30 | viric | hm quite horrible. |
| 14:40.47 | mth | if there is something better, please let me know :) |
| 14:40.50 | viric | I'm used to 'cu' |
| 14:40.56 | viric | from uucp |
| 14:41.02 | viric | "cu -l /dev/ttyS1" |
| 14:41.19 | viric | it's very simple, and does not any terminal emulation |
| 14:41.33 | viric | but with this serial port, it gives me: cu: write: Input/output error |
| 14:41.46 | viric | and minicom looks like not able to write now. I don't know what I touched. |
| 14:45.21 | viric | why would a PC UART return 'input/output error' on write? |
| 14:47.27 | viric | ha. it was the hw flow control enabled. |
| 14:48.46 | viric | mth: about 'flashing a nand'... usually the image contents are the 'mtdblock' contents, isn't it? |
| 14:49.21 | viric | which is somewhat less bits than raw a mtd access would give. |
| 14:49.31 | mth | you can have images with and without OOB data |
| 14:49.34 | viric | hm ok |
| 14:49.50 | mth | (I wrote OOM before, but that's something different) |
| 14:49.58 | viric | yes, that confused me. |
| 14:49.59 | viric | :) |
| 14:50.09 | viric | you meant OOB area? |
| 14:50.17 | viric | for me OOM means out of memory |
| 14:54.01 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 14:56.16 | viric | mth: writing to a mtdblock... it says: Writing data without ECC to NAND-FLASH is not recommended |
| 14:56.48 | viric | wa, got rid of the boot sound of gp2x! mtdblock2 was a RIFF |
| 14:57.25 | mth | replacing the data and not the ECC would be a bad idea |
| 14:57.44 | mth | but I'd expect it to recompute the ECC as part of the write operaton |
| 14:57.51 | mth | not sure if it actually does though |
| 14:57.57 | mth | AwAyla has more experience with this |
| 14:58.59 | viric | ok |
| 14:59.15 | viric | for what I tried with other mtd devices, the write operation did all. |
| 15:12.47 | *** join/#qi-hardware jeremybrown82 (~jeremybro@c-68-62-245-80.hsd1.fl.comcast.net) |
| 15:14.46 | jeremybrown82 | i have a question about cpu design |
| 15:16.09 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 15:16.37 | LunaVorax | Hey everyone |
| 15:16.45 | mth | jeremybrown82: go ahead and ask the question |
| 15:16.54 | jeremybrown82 | can Alternating current of its own form be applied to registers in cpu ad direct currnet voltage by desin there by expanding the capicities of the hardware platform |
| 15:17.31 | jeremybrown82 | like multiplexing at the cpu level |
| 15:18.02 | viric | anyone ever programmed an arm920t with arm940t coprocessor? |
| 15:18.35 | jeremybrown82 | im thinking about buying an arm laptop and using it for testing software on |
| 15:19.08 | viric | I wonder how to use the coprocessor |
| 15:19.34 | mth | I've never heard of CPUs running on alternating current |
| 15:20.02 | jeremybrown82 | not exactly ac persay just a algorythim |
| 15:20.50 | mth | viric: afaik it's mostly used for blitting |
| 15:21.23 | viric | mth: as if it were a clever dma controller? |
| 15:21.26 | *** join/#qi-hardware rejon (~rejon@221.221.179.94) |
| 15:21.42 | viric | knowing how to blit. |
| 15:22.02 | jeremybrown82 | viric dont swear..lol |
| 15:22.36 | viric | I know the gp2x software have the coprocessor used mostly in its libSDL for that |
| 15:22.59 | mth | there is also this, but apparently it's not related to the copro: http://wiki.gp2x.org/wiki/Using_the_upper_32MB_of_memory |
| 15:23.20 | viric | nice |
| 15:23.57 | mth | I might be mistaken about blitting, it might be the hw blitter that wiki talks of, not the copro |
| 15:24.14 | mth | usually weird coprocessors and up being unused |
| 15:24.22 | mth | it seems hw people like them more than sw people ;) |
| 15:25.14 | jeremybrown82 | somthing like this i guess |
| 15:25.15 | jeremybrown82 | http://pubs.acs.org/doi/abs/10.1021/ac00246a027 |
| 15:25.41 | viric | it has a '2d graphics processor', a 'video processor', and the arm940t |
| 15:26.06 | viric | the usual yuv=>rgb and scaling. |
| 15:26.14 | viric | some idct... |
| 15:26.19 | viric | quite a lot. |
| 15:26.37 | viric | mth: http://mudiweb.com/gp2x/MP2520F_Manual_Eng_V1.0.pdf |
| 15:27.32 | viric | mth: can the ingenic do some idct, to accelerate jpeg decoding? |
| 15:29.31 | mth | there is an IPU component that can do some image operations, like YUV decoding |
| 15:29.41 | viric | and scaling, iirc |
| 15:30.00 | viric | well, I've always been interested in displaying huge jpegs |
| 15:30.04 | viric | using low memory |
| 15:30.32 | viric | a low amount of memory I mean |
| 15:31.23 | mth | in the 4740 it only does YUV conversion and scaling |
| 15:31.29 | viric | ok |
| 15:31.30 | mth | in later procs it can do more |
| 15:32.11 | mth | I guess the trick is to make a decoder that doesn't decode the entire image, but only the sections that actually end up on the screen |
| 15:32.13 | viric | it's a pity all this does not have a unified user-kernel interface |
| 15:32.26 | mth | hw accel won't solve the memory issue |
| 15:32.37 | viric | mth: yes, I did that partly. But libjpeg does not allow enough constraints |
| 15:33.03 | mth | then you'll have to write your own lib or modify libjpeg, I think |
| 15:33.06 | viric | :) |
| 15:33.10 | viric | or do nothing |
| 15:33.22 | mth | ...that's always an option |
| 15:33.29 | viric | attractive. |
| 15:34.14 | mth | I guess a specialize decoder that scales down is useful for generating thumbnails |
| 15:34.15 | viric | mth: isn't there any user-kernel interface about those things? like dri or so |
| 15:34.36 | mth | but that would work very different from a decoder that decodes 1:1 but only part of the image |
| 15:34.50 | viric | mth: libjpeg allows decoding only the baseline (1/64 of resolution, 1/8 for each coordiante) |
| 15:34.53 | viric | coordinate |
| 15:34.56 | mth | I think v4l2 would be the best match for the IPU |
| 15:35.02 | mth | but there is no driver yet |
| 15:35.09 | viric | hm recently I wrote some v4l2 code... |
| 15:35.22 | mth | dvdk accelerated mplayer using the IPU but via /dev/mem poking iirc |
| 15:35.27 | viric | yes I know |
| 15:35.38 | mth | which is fine for a prototype, but not the right way to do it |
| 15:35.47 | viric | right. |
| 15:36.02 | viric | I only used v4l2 for capturing from a webcam |
| 15:36.12 | mth | what I'd like to have is an SDL driver that rotates buffers through v4l2 |
| 15:36.18 | viric | I'm not sure it can handle rescaling |
| 15:36.19 | mth | to allow triple buffering |
| 15:36.33 | viric | rotates 90°? |
| 15:36.42 | viric | ahb |
| 15:36.44 | mth | so you acquire a buffer from the kernel, fill it with a video frame, push it back into the kernel |
| 15:36.47 | viric | ok |
| 15:36.47 | jeremybrown82 | then fold |
| 15:36.56 | mth | and the kernel displays it at the next vsync |
| 15:36.58 | jeremybrown82 | like an overlay |
| 15:37.00 | viric | v4l2 works with enqueuing and dequeuing |
| 15:37.09 | mth | that way, user space doesn't have to mess with vsync at all anymore |
| 15:37.19 | viric | hm treating the screen as a v4l2 output device... |
| 15:37.30 | mth | SDL api allows it |
| 15:37.40 | mth | just call SDL_Flip() when you're done with a frame |
| 15:37.59 | mth | SDL doesn't require there to be just 2 pages for double buffering |
| 15:38.14 | viric | why would triple buffering be better than double buffering? |
| 15:39.35 | viric | mth: v4l2 looks quite good for an IPU. But how to manage when the screen shows /dev/fb0 contents or v4l2 contents? :) |
| 15:41.40 | mth | stop displaying /dev/fb0 when the v4l2 surface is active? |
| 15:41.53 | viric | 'active'.. could be. |
| 15:42.12 | viric | I see mplayer supports v4l2 as output device too |
| 15:42.12 | mth | I don't know the video part of v4l2 well enough to know how 'active' should be defined |
| 15:42.28 | viric | ok |
| 15:42.35 | mth | in theory you could even display multiple surfaces at the same time, vertically aligned |
| 15:42.58 | mth | we want to have an overlay of 20 lines for the power slider daemon at some point |
| 15:43.09 | viric | :) |
| 15:43.11 | mth | to provide visual feedback when changing volume for example |
| 15:43.24 | mth | it can be implemented using chained DMA descriptors |
| 15:43.36 | mth | we're already doing that to add black lines at the top and bottom for TV-out |
| 15:43.47 | viric | brave |
| 15:43.52 | mth | otherwise the last pixel of the screen determines border color |
| 15:44.19 | mth | it's not that hard if you have a static chain |
| 15:44.22 | viric | border color... reminds of old tv-connected computers |
| 15:44.33 | viric | I don't understand that about dma and the overlay |
| 15:44.33 | mth | might be more tricky if you manage the chain dynamically |
| 15:44.54 | viric | 'chained dma descriptors' is linux terminology? |
| 15:45.15 | mth | it's just one DMA descriptor pointing to the next |
| 15:45.30 | mth | it's a feature of Ingenic's DMA controller, but I think many DMA controllers have it |
| 15:46.12 | mth | the daemon can't write in fb0, because an application is already writing there and would overwrite the daemon's gfx |
| 15:46.19 | viric | then it goes on a next dma transfer without the cpu having to schedule a new one? |
| 15:46.26 | mth | so it needs a separate buffer that can still be visible on the screen |
| 15:46.31 | mth | correct |
| 15:46.50 | mth | actually the descriptors are set up in a loop, so the CPU never has the intervene |
| 15:46.50 | viric | but does the cpu get notified of the end of the 1st transfer? |
| 15:47.03 | viric | ah |
| 15:47.15 | mth | you can set a start or end interrupt flag in the descriptor if you have to know where DMA is |
| 15:47.16 | viric | and how do you synchronize this? |
| 15:47.55 | mth | you don't have to synchronize it, you only have to ensure the number of lines DMA-ed matches the number of lines per frame |
| 15:48.25 | viric | but the cpu should not write to the memory the ipu or lcd is reading |
| 15:48.44 | viric | hm maybe I miss details |
| 15:48.49 | mth | ah yes |
| 15:49.04 | mth | the CPU can write there, but the changes will not be picked up until the cache is flushed |
| 15:49.20 | mth | so either you can make the framebuffer uncached, or you flush the cache regularly |
| 15:49.27 | mth | for example on the start of frame interrupt |
| 15:49.43 | mth | and with double buffering, you flush the cache on the flip |
| 15:50.10 | mth | this is also easier with the v4l2 interface, there you would flush the cache when the kernel takes the buffer back from user space |
| 15:50.25 | mth | which immediately frees up the cache for more useful data |
| 15:50.33 | viric | yes |
| 15:50.47 | mth | it's superior in every way |
| 15:50.51 | mth | but it's not written yet |
| 15:50.54 | viric | :) |
| 15:51.32 | mth | currently double buffering uses vertical panning, which is a good match for ancient hardware, but a poor match for today's hardware |
| 15:51.44 | viric | 'panning'? |
| 15:51.54 | mth | scrolling of the view window |
| 15:52.09 | mth | the fb is 320x480 and the view is either at (0, 0) or (0, 240) |
| 15:52.19 | viric | ah I didn't know |
| 15:52.22 | viric | what's bad in that? |
| 15:52.34 | mth | because the entire fb is memmapped by user space |
| 15:52.50 | mth | so the kernel driver anticipates on the typical usage pattern from SDL |
| 15:53.04 | mth | but still has to support random access too |
| 15:53.11 | mth | it's a bit of a mess |
| 15:53.27 | viric | aha |
| 15:53.28 | viric | ok |
| 15:53.31 | mth | for example, on the Dingoo there is a separate LCD controller and the JZ is in SLCD mode |
| 15:53.48 | mth | we can upload a frame whenever we want, there is no fixed refresh rate |
| 15:54.06 | viric | I don't know SLCD |
| 15:54.09 | mth | so ideally we upload immediately after a flip and not at any other time |
| 15:54.20 | viric | the 'upload' is fast? |
| 15:54.30 | mth | it's "smart LCD", meaning the panel is not an actual bare LCD panel, but something with its own controller and RAM |
| 15:54.51 | mth | no, it takes a significant amount of time, since the memory bandwidth of the Dingoo is quite poor |
| 15:55.13 | mth | AwAyla did some experiments with this and the maximum theoretical frame rate you could get |
| 15:55.22 | viric | and what piece does the upload? |
| 15:55.23 | mth | but I don't remember the result |
| 15:55.39 | mth | the SLCD framebuffer driver |
| 15:55.47 | viric | it's in the ram bus? |
| 15:56.01 | mth | it's done via DMA |
| 15:56.10 | mth | the SLCD FIFO is a special DMA target |
| 15:56.13 | viric | ok |
| 15:56.23 | mth | similar to how audio is streamed, for example |
| 15:56.39 | viric | hm so much fun |
| 15:57.00 | mth | in any case, we now have double buffering detection in the fb driver |
| 15:57.18 | mth | that determines whether the calls it gets match the pattern from double buffering |
| 15:57.33 | mth | if they do, we upload only on flips, otherwise we upload at a fixed timing (60 Hz) |
| 15:57.43 | viric | ahhh |
| 15:57.53 | viric | nice. |
| 15:58.07 | mth | so if an emulator is running at 40 fps, we refresh only 40 times per second, saving some memory bandwidth |
| 15:58.10 | viric | quite a lot, 60Hz |
| 15:58.20 | viric | why so much? |
| 15:58.32 | mth | historical reasons :) |
| 15:58.33 | viric | you could do 25Hz fixed. |
| 15:58.42 | viric | even faster than this flip trick |
| 15:58.43 | mth | many games are written for 60 Hz |
| 15:58.49 | mth | because of TVs |
| 15:59.01 | viric | well, the games will think it's refreshed at 60Hz |
| 15:59.08 | viric | they do their own counting |
| 15:59.22 | mth | animations look best if you stick to their native freq |
| 15:59.32 | viric | or some multiple... |
| 15:59.36 | viric | ok, 30hz |
| 15:59.36 | viric | :) |
| 15:59.43 | mth | old games use flickering sprites to simulate transparency |
| 15:59.51 | viric | oh good one |
| 16:00.01 | viric | you win. |
| 16:00.03 | mth | so if you drop half the frames consistently, you either see the sprite full or not at all |
| 16:00.23 | mth | I've worked on openMSX for many years, you get nasty surprised like that :) |
| 16:00.43 | mth | s/surprised/surprises |
| 16:00.45 | qi-bot | mth meant: "I've worked on openMSX for many years, you get nasty surprises like that :)" |
| 16:01.23 | viric | but... aren't there enough games that could run just fine uploading to screen at 30fps? |
| 16:01.34 | viric | 'run' in the sense of pleasant playing |
| 16:01.38 | mth | probably |
| 16:01.41 | viric | Isn't it an option of emulators? |
| 16:01.59 | viric | some emulators have so much options... |
| 16:02.02 | mth | you could change the game code to run at a fixed 30 fps double buffered and we'd refresh at 30 fps then |
| 16:02.12 | viric | ok nice |
| 16:02.20 | mth | fixed frame skip is a typical feature for emulators |
| 16:02.25 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 16:02.28 | mth | in openMSX we have a min and max frameskip setting |
| 16:03.07 | jeremybrown82 | mth have you heard of open pandora? |
| 16:03.28 | jeremybrown82 | or the handheld pandora |
| 16:03.55 | mth | jeremybrown82: I even ordered one, but I'm still waiting for it |
| 16:04.08 | mth | so I got a Dingoo A320 to play around with in the mean time |
| 16:04.27 | jeremybrown82 | teheh nice i want one but there so pricy for the specs |
| 16:05.05 | jeremybrown82 | dingo is cool but gpwiz is top notch these days no? |
| 16:05.38 | mth | hw wise wiz is better, but Dingoo has an active scene |
| 16:05.41 | mth | and it's cheaper |
| 16:05.52 | jeremybrown82 | mth dingoo is open? |
| 16:06.11 | jeremybrown82 | for some reason i thought otherwise |
| 16:06.14 | mth | not as you get it from the manufacturer, but we've replaced all the software with open stuff |
| 16:06.38 | jeremybrown82 | haha nice does it require any modding |
| 16:06.58 | mth | no, everything can be replaced via USB |
| 16:07.20 | jeremybrown82 | sweet soo like... whats good websites to key in on |
| 16:07.23 | mth | although using the internal memory is still very tricky, so the easiest way is to do it via a mini SD card |
| 16:07.35 | mth | dingoonity.org is the main scene site |
| 16:07.45 | jeremybrown82 | nice thanks man |
| 16:07.47 | mth | and we've got the #dingoonity channel here on freenode as well |
| 16:08.24 | jeremybrown82 | so you recommend the d380? |
| 16:09.03 | mth | not really, the manufacturer doesn't release sources and few developers are interested in it |
| 16:09.21 | jeremybrown82 | ohh ok |
| 16:09.34 | mth | and the screen res is not very useful, being larger than 320x240 but not large enough to allow 1.5x or 2x scaling |
| 16:09.44 | jeremybrown82 | right |
| 16:09.46 | mth | the A320 is still the best device imo |
| 16:10.01 | mth | the GCW Zero might replace it, but that's still very much in a prototype stage |
| 16:10.10 | jeremybrown82 | a320e is any different? |
| 16:10.18 | jeremybrown82 | gcw zero hmm.. |
| 16:10.37 | mth | A320e is an entirely different machine iirc |
| 16:10.42 | jeremybrown82 | oh |
| 16:12.36 | mth | ah no, I'm confused with the models now |
| 16:12.40 | mth | A320e is like the A380 |
| 16:12.54 | mth | the Gemei A330 is an entirely different machine (ARM based) |
| 16:13.00 | jeremybrown82 | oh |
| 16:13.28 | jeremybrown82 | so you recommend which on again? |
| 16:13.43 | viric | mth: understanding those 60Hz requirements for emulators... no wonder some of these machines run duke3d just fine, and can't emulate snes :) |
| 16:15.53 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 16:16.30 | mth | snes is quite hard to emulate accurately |
| 16:16.58 | mth | an emulator author wrote a nice piece about that for Ars Technica a while back |
| 16:17.14 | viric | what is ars technica? |
| 16:17.17 | viric | in this context |
| 16:17.17 | mth | titles something like "why it takes a 3 GHz CPU to emulate SNES" |
| 16:17.24 | mth | a tech news site |
| 16:17.43 | viric | ah thank you, I'll read it |
| 16:18.03 | mth | http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ |
| 16:19.48 | viric | yes I found it |
| 16:20.12 | viric | (I just also tried pocketsnes, and runs amazingly well in the gp2x compared to the other emulators I saw |
| 16:20.15 | viric | ) |
| 16:20.37 | mth | you don't need high accuracy for most games |
| 16:21.01 | viric | ahga |
| 16:21.02 | viric | aha |
| 16:21.02 | mth | and in some cases you'll only notice accuracy problems if you're very familiar with the game on real hw |
| 16:22.04 | mth | I fixed a bug in overscan emulation in openMSX a few weeks ago which fixed exactly 1 game |
| 16:22.10 | mth | since most games don't use overscan on MSX |
| 16:22.42 | viric | ok |
| 17:13.50 | viric | mth: thank you for that ars technica article, very nice! |
| 17:14.41 | *** join/#qi-hardware Maroni (~user@046-220-009-005.dyn.orange.at) |
| 17:45.01 | *** join/#qi-hardware jurting (~jommpa90_@ip-58-223-241-92.dialup.ice.net) |
| 17:52.40 | *** join/#qi-hardware AwAyla (~paul@233.188.103.84.rev.sfr.net) |
| 18:23.34 | viric | mth: did you try uucp 'cu' for serial? (Reminder: Type ~. to close 'cu'.) |
| 18:27.05 | mth | no, I don't have a serial port on my Dingoo |
| 18:27.11 | viric | ah ok :) |
| 18:27.32 | mth | I've used minicom in the past to connect to the Wii, I think, but I don't really want to set that all up just to test |
| 18:28.00 | viric | sure sure. |
| 18:28.06 | mth | ah, and the very first Dingux kernel, which used serial over USB instead of ethernet over USB |
| 18:32.46 | kristianpaul | jow_laptop: hi |
| 18:33.11 | kristianpaul | do you know some device tinier than the tplink 703n than runs owrt of course and have usb host port? |
| 18:35.11 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 19:40.58 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 20:18.12 | *** join/#qi-hardware wolfspraul (~wolfsprau@222.129.19.165) |
| 20:20.31 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 20:27.15 | *** join/#qi-hardware jurting_ (~jommpa90_@ip-222-60-179-93.dialup.ice.net) |
| 21:04.36 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-135.ozonline.com.au) |
| 21:05.20 | *** join/#qi-hardware wej (~j@95.211.10.3) |
| 21:34.36 | viric | mth: I don't think there are many gaming devices with a v4l2 interface for their image processing units :) |
| 21:37.58 | mth | probably not, but I don't think there are many gaming devices running Linux 3.4 yet either |
| 21:38.14 | viric | ah :) yes |
| 22:47.12 | jow_laptop | kristianpaul: sorry nope, the 703n is currently the smallest one I know personally |
| 22:48.09 | jow_laptop | hm actually, there is one slightly smaller board I recall |
| 22:48.26 | jow_laptop | http://www.8devices.com/product/3/carambola |
| 23:50.18 | *** join/#qi-hardware cxadams (~cxadams@li155-180.members.linode.com) |