Inspirated

 
 

October 5, 2009

Emu8086 Hardware Interrupt Editor & Generator

Filed under: Blog — krkhan @ 7:41 pm

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:

Emu8086 Hardware Interrupt Editor & Generator Screenshot
(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: , , , , , , , , , , , ,

August 23, 2009

Workaround for fixing X.org acceleration issues on Intel chipsets

Filed under: Blog — krkhan @ 1:39 pm

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

    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 “greedyMigrationHeuristic with EXA instead:

    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: , , , , , , , , ,

January 24, 2008

Finally, we’re two!

Filed under: Blog — krkhan @ 7:51 pm

“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.

Dual-Head Setup Photo #1 Dual-Head Setup Photo #2
Dual-Head Screenshot

(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: , , , , , , , ,

February 1, 2007

Beryl/AIGLX white cube issue

Filed under: Blog — krkhan @ 8:41 pm

Anyone who has ever tried to run Beryl using AIGLX must’ve heard about the infamous white cube issue. (more…)

Tags: , , , , , , ,