The lion kingdom actually remembered typing this one in, 40 years ago. It was a real tour de force of basic programming. It would be a good one to convert to C on the C64, but not assembly. It would be even better in javascript for a web browser. It had kind of an enjoyable game play.
The other big one lions typed in was laser chess.
There's a case for porting the slowest games from BASIC to javascript. Not so much assembly games which were already fast enough, unless it also included an improvement in graphics.
Continuing with the 8 bit fascination, the Sierra game engine from those days was quite impressive. It had static bitmaps for rooms, collision objects, Z buffering, & player animation. It used vector graphics.
Young lion envisioned some mix of scrolling world & static rooms for his Robotech game. A scrolling world would have been quite unplayable, in the end. Truth be known, the signature graphical Sierra adventure games never supported the C64. They were all on x86 & apple II, using plain bitmap writes. Kiwipedia clearly shows the C64 wasn't supported. https://en.wikipedia.org/wiki/Adventure_Game_Interpreter
Their most advanced games for C64 just had non interactive, procedurally drawn graphics as illustrations. Their most advanced C64 adventure game was Mickey's Space Adventure.
They made a formal game engine for x86 & apple II starting with King's quest. It had a very small player & very few occluded zones. The mane mystery is why they didn't do the same on the C64.
They all drew the graphics in place. It was a 160x150 graphical area with a 30 pixel tall text area below. It seems to have dropped 20 pixels from the top & bottom.
This room is using an alpha mask to draw the chain on top of the player. A C64 would have to use sprites for the foreground or just draw the whole thing in bitmap RAM.
As usual, the hardest part would be creating the assets & plot.
Lions have used their own serial terminal program for at least 20 years now, after living with the limitations of minicom for 10 years. This is a note to consider finally adding an interactive configuration menu, persistent settings, in addition to the historic command line options. There are so many options now, it's almost minicom-like. Lions would keep out the delays, status bars, line wrapping, nested menus, & confirmations.
The bonuses have been compilation with no dependencies so it can easily be built on bare metal systems, easily reproducible configurations with command line options.
The big problem is getting into the menu without a ctrl key. ctrl-a is used by screen. It's a pain point with minicom. It could just display during startup with another command line option.
LGR's last museum vijeo was the 1st moment lions seriously pondered porting Cinelerra to a vintage SGI, given enough money & space to store something like that. The goal would be to discover if they really could have replaced Macs, if suitable software existed on UNIX of the time, or if their dream of UNIX filling the PC space was hopeless. SGI was circling the multimedia space during Apple's rotten years. Adobe had expensive ports of photoshop & premier for SGI. That was the end of their UNIX efforts.
It would have been pretty degraded. Uncompressed audio & uncompressed 320x240 video was the limit lions remember for an early SGI grade 133Mhz processor. Video editing in those days meant remotely controlling tape decks or overlaying graphics on a video passthrough. There was no such thing as recording & playing full 720x480 on a hard drive. What lions saw of 720x480 video editing on early 2000's SGI's was really slick. We never saw video look that good on a PC in those days.
The biggest need would be getting the threading support of the time working. The X11 routines would all have to be single threaded. The other difficulties would be disabling all the 3rd party libraries which only work on x86, like ffmpeg. All the changes would have to be kept alive in the mane Cinelerra source code, for a certain amount of time. It could still handle uncompressed video.
The tube had been recommending an SGI series from Phintage Collector. There is somewhat of an SGI emulator, but it's very slow compared to the real thing.
Watching SGI videos through the years has exposed lots of bugs & limitations of mid 90's UNIX which young lion didn't appreciate. He knew about the buggy sound driver in HPUX but not much about IRIX bugs.
Once the novelty of being able to write programs by feeding natural language prompts in 1 end & getting high level python out the other end wore off, lions started pondering the next evolution for language models. The ideal language model converts a better language than english straight to assembly language.
Describing gen AI prompts in a medeival natural language is exhausting. They desperately need a more precise language with modern programming features from the last 100 years. A plus is a library of prompts that are called by function prototypes instead of complete paragraphs. Functions are essential for any reuse. Commenting is essential for any prompts to be readable. We would be so lucky if prompts had common data structures like a stack & some form of memory management.
The easiest way might be a preprocessor that tokenizes keywords into medeival english, strips out comments, unwraps loops, expands variables, links libraries. It's not practical to train the model to ingest a modernized prompt language because the cheapest training data is all using medeival labels.
Gen AI is basically a compiler for an ancient, imprecise programming language & it's another step in the history of creating new compilers for new languages.
Transferring large files over a serial port & console using base64 has proven difficult. It's too prone to errors to get beyond a few MB. It's prone to spurrious keypresses, framing errors, syslog printouts. Past lion had good results with sz & rz in the days of dialup, but they require 2 way communication. The trick with Linux is multiple programs can write to the serial device, but only 1 can read at a time. Any file transfer over console requires the user to observe if the transfer was successful, then rerun the sender over & over with a way to specify what packets to resend.
The normal base64 transfer involves having a terminal in xterm with a 2 way connection while simultaneously catting to the serial port in another xterm. The user could copy some kind of result code from the terminal to another cat command to resend the lost packets. The trick is the terminal is going to contaminate the result code with all the base64 data & a lot of syslog junk. It would take some fiddling or formatting magic to isolate the result code.
This base64 replacement should also use compression.
Late in the text editor game to be sure, but lions have been using nedit for 30 years now. It has limitations & bugs, manely a tendency to open multiple instances of itself to edit the same file. Then there's no way to copy the filename to the clipboard. It's always a pain to make it apply C++ style comments. It's a pain to switch between tabs & emulated tabs.
The mane thing lions need is a way to invoke an editor inside lxc-attach, ssh, xterm, serial terminal, adb, & automatically detect if it already has an editor instance for the file. The editor would then have 1 instance for each file, no matter where the file was opened. If the file wasn't on a local filesystem, the editor would communicate with the client through the terminal it was invoked on. For a serial terminal & ADB it would need a special terminal program & ADB hack which could multiplex messages with console characters. Ssh has ways of tunneling sidechannel data. Everything inside LXC is in a /var/lib/lxc directory.
Maybe it would rely on a table of mount points to detect equivalent files, then always assume ssh, serial terminal, & ADB were not accessing any local mount points.
The VIC 1525 has long been a fascination for lions. It might be because it was 1 of the marvels which did the most with the least. Just 1 motor & 1 solenoid fed the paper, moved the ribbon, & moved the head both ways through a clutch, spring, & gearbox. Just 1 pin banged against a 7 position drum. The hard rows on the drum were all plastic so those pixels started to get fat over the years. It was also the smallest dot matrix printer. In those days, the printer was still very much the primary output device as it was in maneframe days. The final product of most software was a printout rather than a screen.
It was shocking to realize the VIC 1525 wasn't designed for the commodore 64 but dated back to the VIC 20. Jack sure liked the word VIC.
The only thing it might be useful for now is creating posters by printing long strips of paper. Quite difficult 40 years ago because it was real hard to get data into the computer. Today, it could run off any serial port with the right glue logic & print photos. The mane task would be converting an arbitrary bitmap source to the right serial codes.
It had a text mode & graphics mode. The text font had only 7 rows & terrible lowercase. It was not possible to print screenshots of any quality because there wasn't a modern frame buffer, just a realtime fusion of raster interrupts, bit maps, sprites, character maps, color maps. Software did print out just the raw bitmap memory or just 1 sprite, but couldn't scale it to fill an entire page. Bitmap printouts were just thumbnails. The lion kingdom has actually only regained most of is commodore knowledge in the last 5 years. Some bits of the memory map are still forgotten.
The tractor feed might allow multiple passes with different color ribbons. 4 printers with different ribbon colors could be daisychained to the same paper feed. Tractor paper would be a lot easier to assemble into posters than separate sheets. The ribbons might have been easier to recharge than toner & inkjet cartridges. Low resolution isn't a problem for posters.
Lions wouldn't know where to store tractor paper now or where to put posters. Maybe they could be replaced routinely.
Some leading posters are a large starship launch, supermodels. Some other directions involve getting the printer to print from the most ridiculous device, an FX-7700, a watch, making a cheap calculator print every line.
Printing from a browser has never worked. Lions historically saved every page as a PNG, loaded it in the Gimp, cropped it, printed it to a .ps file, then wrote the .ps file to the ghostscript filter.
Gimp no longer has any persistent settings for printing & no longer allows dragging the output in the print preview, which has made this quite ponderous. A better solution has long been a way to automatically crop to the black areas straight from a .ps file from the browser & send it to ghostscript.
lion mclionhead
