Paraprogramming Dispatches

MS1201.02 single-board PDP-11 clone

Hadrware Vintage PDP
Eugene Zaikonnikov

Among the first computer related-books I read was a PDP-11 programmer’s manual, borrowed in a library. It was a bit too dense for someone who never seen a computer in their life. Save for the random bits like bus arbitrage or advantages of magnetic domain memory over core, nothing stuck really. A bit later came my first real programming experience, a few simple BASIC programs on DVK, a DEC PDP-11 clone, under RT-11.

Then this winter, browsing eBay junkyards, I came across an MS-1201.02: a Q-Bus board at heart of DVK. A couple weeks later, it was on my desk:


Looks like a finest specimen of Soviet electronic manufacture, but robbed of its KM type platinum/palladium capacitors by precious metal scavengers. It’s a wonder that the processor (16-bit K1801VM2) in gold-plated contact CERDIP package wasn’t removed. The CPU has a crack in the package however, which might prevent it’s function.

The board has three jumper blocks for configuration. Or at least it had in theory.. in reality, communist DIP jumpers were so bad the factories stopped installing them after a while. So if you wanted to change a serial port speed or boot address, you had to do it like Real Men do: with bare hands and soldering iron.

Jumper block

The board has 64Kb physical memory, only 56Kb (28 Kwords) of which are however addressable - the upper 8Kb are I/O mappings in PDP-11 architecture.

So as you see, some work to be done here. Immediate plan is:

  • Order all the missing caps and repopulate them
  • Find a replacement CPU chip and replace if necessary
  • Install less manly, capitalist DIP piano switch blocks
  • Build a backplane to install the card in
  • Build a current loop serial interface to RS-232c converter
  • As the board uses two “power good” signals in startup sequence, build a small flip circuit for start-up
  • Boot the board to the built in serial monitor prompt

Out of that, the caps, CPU and backplane components already ordered. Schematics are fortunately available on the net.

To be continued.

Announcing CL-VIDEO

Eugene Zaikonnikov

I’m happy to announce CL-VIDEO, a basic AVI/MJPEG video decoder written in Common Lisp. The library leverages CL-JPEG for frame processing and CL-RIFF for container format handling.

The code has only been lightly tested on SBCL 13.x/Linux x86-64. Some sample files can be found here (the toy plane AVI) and here.

To run it, CL-JPEG version 2.7 is required. Since it’s not in Quicklisp yet as of time of writing, it must be cloned into your local-projects. Then you can load cl-video-player system and run (cl-video::play <your filename.avi>).

The implementation is still very much naive, as expected from a weekend project. There is no support for indexing, and a number of edge cases of legit AVI encodings might fail. The library will decode video frames in the order they occur. No parsing of BITMAPINFOHEADER structures; the assumption is they are MJPG DIB. No audio playback, although the stream is being read and adding at least PCM/WAV playback shouldn’t be too big an effort.The decoder is factored out into independent implementation in cl-video.lisp. A primitive CLX media player is included in player.lisp. Each AVI instance contains one or more (audio or video) stream record objects, which hold ring buffers of frames with read and write cursors. The interaction between the decoder and player frontend runnning in separate threads is done via mutexed access to this ring buffer. The player thread can be kicked off a callback supplied to decode method: it will be called once the header part is parsed.

Since CL-JPEG doesn’t use any SIMD extensions, the performance is modest. On my 6 year old 3GHz i5 (running one core of course) it decodes 480p 25fps file without hiccups, but going beyond that would require implementing multicore support in decode. Still it might be useful as is in applications not requiring real-time decoding performance.

New in CL-JPEG

Eugene Zaikonnikov

In course of last few months there were numerous small changes introduced to CL-JPEG. None substantial enough to warrant own announcement, but taken together perhaps it’s due for an update. So here we go, as of version 2.6:

  • Pre-allocated buffers in DECODE-IMAGE and DECODE-STREAM are now supported. This should help reduce consing in bulk-processing applications. The buffer can be pre-allocated based on dimensions via JPEG:ALLOCATE-BUFFER.
  • CMYK JPEG support. YCCK to CMYK conversion is now performed by decoder. To convert into 3-component RGB, use JPEG:CONVERT-CMYK-TO-RGB convenience function.
  • An option to disable colorspace conversion via :COLORSPACE-CONVERSION NIL supplied to decode functions has been added. Can be useful e.g. if one needs the luminance component. Support of the corresponding option for encoder to improve performance in transcoding applications is in the plans.
  • Small bugfixes and performance tweaks.

PJSUA support in CL-PJSIP

Eugene Zaikonnikov

After a bit of tweaking, CL-PJSIP now supports basic PJSUA API. PJSUA aggregates much of PJSIP functionality in a handful of structures and protocol methods. This simplifies application side a lot: one can get by with just a few lines of setup code and a couple callbacks. From Lisp perspective it also reduces the used FFI surface to a stable, generic interface. This ought to improve long term compatibility with PJSIP own revisions.

I refer to cl-pjsua-demo.lisp in the library for a short sample. Load the demo system and try (cl-pjsip::run-pjsua "") for a quick test against a voice menu directory. It was tested on Linux x86_64 with CCL 11.1 and Allegro 10.1 beta. It however eventually crashes with floating point exception on SBCL.

« Older Posts