Did you ever read a LIDAR sensor from a microcontroller & wish there was a way to directly plot the points over the serial port?  The lion kingdom did.  The lion kingdom also has an arsenal of high powered single board confusers with only a serial port for output.  What if they could display graphics over the serial port without writing a custom displayer from scratch?

In the movie Sneakers, graphics magically appeared when Dan Aykroyd probed a serial port.  The lion kingdom always wondered if such a thing was really possible.

The part about cracking AES256 was fiction, but getting vector graphics over a serial port was real.  Some dumb terminals in the 1980's could draw vector graphics from the serial port, using the REGIS protocol.  Sadly, cheap library terminals didn't support this.

Good old xterm supports the REGIS protocol, but it requires recompiling.  The lion kingdom recompiled xterm with the --enable-regis-graphics flag.

./configure --enable-regis-graphics

There are a few limitations in the xterm implementation.  Macrographs don't work.  It doesn't draw graphics in realtime, but only when exiting REGIS mode.  The graphics resolution doesn't default to the window size, but has to be manually set.  By default, it's a 480x480 window inside the xterm.  It doesn't work inside screen or minicom.

The REGIS protocol is a bunch of ASCII commands.  Your biggest ally in this part of the battle is the REGIS reference manual:  https://vt100.net/docs/vt3xx-gp/contents.html

\eP0p enters REGIS mode.

S(E) clears the graphics area

P[x,y] positions the turtle

V[x,y] moves the turtle to a new position, drawing a line

\e\\ exits REGIS mode & blits the graphics area

Setting colors is based on setting palette entries to either an HSV value or a single character code.

S(M1(AR))  Sets color palette entry 1 to red

S(M1(AG))  Sets color palette entry 1 to green

S(M1(AH60L80S60)  Sets palette entry 1 to an HSV color.

Then, you have to select the palette entry for drawing.

W(I1) Selects palette entry 1 for drawing.

There are other commands for drawing circles, drawing bitmaps, drawing text, drawing on different layers, but your mileage will vary in the xterm implementation.

While the lion kingdom currently has no need for pushing graphics over a serial port, it was curious to see how far a lowly Arduino could go.  The ultimate test would be sending 3D animated graphics from an Arduino to a serial port.

The lion kingdom has had a sick fascination with paw coded 3D graphics, the way it was done 40 years ago, before any acceleration hardware or OpenGL existed.  The mane step is to calculate a projection matrix which when multiplied by a 3D coordinate, transforms it into a 2D point on the screen.  The farther Z is from the screen, the more it shrinks X & Y.

A few more matrixes are multiplied in to rotate & scale the models, but the mane thing all 3D graphics cards do is multiply coordinates by a projection matrix.  

The github demo can animate some simple geometric shapes on either an Arduino or natively.

No arduino would be complete without the venerable glxgears in wireframe.

The lowly arduino rapidly slows down when the vertex count gets above 200.  There's no double buffering, so it can't animate polygons right on top of the text.  You can animate graphics & text side by side, as shown in the movie.

The arduino doesn't have enough memory for a Z buffer or to even store the entire model in memory.  Wireframe is as good as it gets.

The lion kingdom verified that it does work over ADB.  The speed on a 1.3Ghz phone is limited by ADB's bandwidth.

How to crack AES256.