Older blog entries for jim (starting at number 8)

The DMA video frame copier is showing great promise. It correctly copies all the words without the 75% droppage that cacheline flushes cause. I'm still doing something stupid in the DMA descriptor link fields. I can't get them to work so I would have to repeatedly reissue the DMA requests. I'd much rather just make a DMA descriptor chain that is a loop so it runs forever.

Initial calculations show that 30fps update should take about half of the PCI bandwidth. If all the other devices are running at full speed that can account for another 25% so it shouldn't have a negative performance impact. We'll see.

It sped the framebuffer code up by a factor of 10, but it no longer works. I enabled caching and write buffering to get the speed up, but now only 1 out of every four 32bit words makes it to the screen when a cache line dumps. I'm trying to use a DMA channel to continuously move a RAM framebuffer device into the video chip. Not my first choice, but if it works it will be a significant speed up.

No progress getting any docs from the vendor. They still have not returned any of my calls or e-mails. I've resorted to contacting people I know who have used the vendor's products and trying to get an introduction to the vendor.

Trying desperately to get technical docs on a chip so I can fix the Linux support. The vendor's web page requires authentication to get to them. I have requested (via the web page) access several times with no response whatsoerver. I tried their sales e-mail address, its an unknown address and is undeliverable. I tried their published phone numbers. As near as I can tell all paths through the automated response unit end up ringing a phone 4 times and then dumping me into a voice mailbox.

I find this one of the most irritating aspects of programming. How can people use your product if you don't tell them how? Publish the interface!

Maybe someone in Santa Clara would nail my request on their door?

On a less stressful note I finally got a 1024x768 color display on one of the Netwinders. 9" B&W gnome is a bit rough. This is much nicer.

Got the Netwinder to change resolutions and run the xserver-fbdev without core dumping. Thats progress. (fbset -rgba 8,8,8,8)

Now if I could just find a decent monitor. My choices thus far are a fixed frequency 640x480 9" monochrome, a focus blown 13" color, and a NEC 3FGe which doesn't want to sync above 800x600 and loses the red gun sporadically.

I'm testing Debian ARM boot-floppies today. While watching the disks spin and the cursors blink I'm counting all the lines of code in Debian.

Good news! I found a flaw in the gcc code generation on the ARM port. There was a subtle bug significant interaction between the instruction and data cache references and the on chip buffers of the SDRAM. The ARM code has now sped up to the point that compiling code on the Netwinders is faster than on my K6-350.

The Debian RiscPC installer has slain its first tester. I've added new keymaps so they can use their keyboards without learning a new random layout. Wimps.

RiscPC people are coming out ot the woodwork! I'm building RiscPC installation images today. Heck, they may even WORK!

Babysitting three ARM machines building Debian. Seemed like a good time to sign up on advogato.org.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!