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:
INT_VECT: A 1024-byte interrupt vector containing 256 entries, with each entry being a 4-byte
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.)
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?”
, Emu8086 Hardware Interrupt Editor & Generator
, Open Source
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:
Option "Tiling" "False"
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.
Option "AccelMethod" "EXA"
Option "MigrationHeuristic" "greedy"
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.
, Open Source
“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.
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.
, Open Source
Anyone who has ever tried to run Beryl using AIGLX must’ve heard about the infamous white cube issue. (more…)