Inspirated

If there has been a closed-source software which I have enjoyed using at my university, it’s Emu8086. The shareware, as the name suggests, emulates the 8086 processor down to the minutest detail. Since 8086/8088 processors form a significant part of my Microprocessor Interfacing & Programming course, I have grown rather fond of the software’s workings.

Recently, I needed to generate hardware interrupts on the emulator. Not only that, but I wanted to use my own service routines for the interrupts so that I could try to understand what happens behind-the-scenes in such scenarios. Reading through the Emu8086 documentation, I figured out that two files are responsible for accomplishing the required tasks:

1. INT_VECT: A 1024-byte interrupt vector containing 256 entries, with each entry being a 4-byte offset:segment pair.
2. emu8086.hw: A 256-byte file with each byte representing a corresponding interrupt. A non-zero byte signifies that particular interrupt being active. The byte is set to zero again after the interrupt is serviced.

As manually editing these files became cumbersome, I had to code two PyGTK apps for editing these files in a pretty interface:

(Click on the thumbnail for larger version.)

The intvecteditor.py file lets the user load/edit/save an 8086 interrupt vector. Similarly, the hwintgen.py allows the user to load an emu8086.hw and then generate/monitor interrupts in it. The utilities require PyGTK to run, but I find it infinitely easier now to analyze interrupt behavior of the emulator. This also lead to an interesting observation, as the emulator checked for interrupts at the beginning of an instruction instead of at its end — something which didn’t confirm with the actual 8086 working model.

x86 is fun. After all,

“Do you program in assembly?”
“NOP”

Tags: 8086, 8088, Assembly, Code, Emu8086, Emu8086 Hardware Interrupt Editor & Generator, Intel, Interrupt, Open Source, PyGTK, Python, Vector, x86

Recent X.org drivers for Intel chipsets have introduced a new acceleration method called UXA which is supposed to provide “simpler, faster” code. However, for whatever reason, this bleeding-edge feature actually results in a loss of performance and reliability for particular chipsets (e.g. 915 family) on most distributions (Fedora and Ubuntu to name the foremost). In order to work around these issues, two solutions can be used:

1. Enable Tiling in xorg.conf.

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   This fix does help the low framerate issue encountered on most distros, but it introduces screen tearing on some installations and worse, can happen in occasional X crashes as well.

2. Use “greedy” MigrationHeuristic with EXA instead:

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   While this completely bypasses the UXA acceleration, it seems to work well for most users.

For the time being, I’m sticking with the second workaround since I have no issues with using the older acceleration architecture until the new one achieves some decent stability.

Tags: Desktop, EXA, Eye-candy, Graphics, Intel, Open Source, Technology, UXA, Workaround, X.org

“Two heads are better than one.”

Not everything is going perfect (I’ll get to that later), but it is an awesome feeling to be able to manage different windows on a 2048-pixels wide workspace.

(Click on the thumbnails for larger versions.)

The laptop is providing the VGA output using the Intel driver that’s included in X.org. However, to get the thing working, I had to edit my xorg.conf by hand. Here’s a list of things that work:

• The workspace “stretches” across the two displays by using xrandr commands outlined on this page.
• Applications get sliced across the display using Xinerama and as seen in the first two screenshots, even MPlayer’s x11 video output is perfectly happy with it.

And a list of things that don’t:

• For some unknown reason (which I’m too chuffed right now to be bothered about), if I specify the display modes explicitly for my laptop LCD screen on line 49 of the xorg.conf linked above, my VGA stops getting a display. Nevertheless, even without specifying display modes, the LCD resolution gets set as expected (1280×800 and 1024×768 for single and dual heads respectively).
• Xfce’s panel insists on sitting in the right-hand VGA only. Other people are reporting the same behavior for Gnome’s panel and AFAIK, there’s no workaround available at the time being.

I have yet to try a 2560×800 (1280×800+1280×800) configuration but the current resolution is still more than sufficient for some kickass photo/video editing. Also, debugging on one display while vim-ing in the other is a programmer’s paradise. Size does matter, after all.

Tags: Dual-Head, Intel, Linux, Open Source, Technology, X, X.org, Xinerama, XRandR

Anyone who has ever tried to run Beryl using AIGLX must’ve heard about the infamous white cube issue. While facing this problem, the screen goes totally white and while you can rotate the cube, you can’t do pretty much anything else. As I had also spent about a week trying various methods to solve the problem, I thought to publish on my blog the combination that did work on my Intel G965 motherboard.

Apparently, the whole thing is messed up because of the opcode changes in glproto-1.4.8 and although I don’t have any idea why, downgrading glproto and recompiling Mesa and X.Org did not solve the problem for me. Nevertheless, the following setup worked like a charm:

• Git clone of glproto

git clone git://anongit.freedesktop.org/git/xorg/proto/glproto

• Git clone of mesa

git clone git://anongit.freedesktop.org/git/mesa/mesa

• Git clone of xorg-server

git clone git://anongit.freedesktop.org/git/xorg/xserver

• xorg-server-1.1.99.901-GetDrawableAttributes.patch and xorg-server-1.1.99.901-glXDRIbindTexImage-target.patch applied to the xorg-server. These patches are listed at Bug 8991 on freedesktop.org

Compiling these components might require you to install other ones (such as inputproto, damageproto etc.), but this page is not meant to be a HOWTO. I’m just confirming that the above mentioned things work for me on my Intel graphics card. There is even a new patch created for xorg-server but I haven’t tried it out myself yet (I’m away form my PC for at least another week). If anyone else can confirm some other combination to be working, I’ll be glad to list it here. Just leave a comment using the form below.

Tags: AIGLX, Beryl, G965, Intel, Mesa, Technology, X, X.org