Silly software wishlist

Motivation to do some software projects by writing them down.

Similar projects worth following
Most of these will never be done. Some have been done. The screenshot is RPN a command line calculator which has proved essential, over the decades.

It might feel like every software project has to be bigger than the last software project, or they're not worth doing.  In reality, before Cinelerra, there were a lot of smaller software projects that just edited audio.  You get to a big software project by doing smaller ones that eventually have something in common & appear to be better served if they were all combined.  

We might be in a downward trend in the size of software projects people consider desirable, with mobile computing & retro computing, but the size required to get discovered is definitely growing.  20 years ago, a silly command line program on a personal web page that extracted emails from pine would have gotten thousands of downloads & been enough to start a foundation.  People used to read through just to discover new software projects.  

Nowadays, you have to look like a corporation, employ every marketing gimmick in the latest developer conference to get discovered in an app store & forget about any personal web page getting discovered. No-one reads through an app store digest just to discover new software projects.

ATC to tablet: Something that automatically captures instructions from air traffic control on a tablet.  Lions will never have enough money to fly airplanes, but based on goo tube videos, it's manely an arcane task of constantly listening to the radio for your call sign & memorizing verbal instructions they give.  The more cryptic ones are the METAR readouts.  It gets real crazy during landings, when ATC blasts out thousands of things & the pilots are shown writing them down, all while the airplane heads towards the ground at 300mph.  

Ideally, ATC would fly planes directly instead of bothering with radio dialog, but lions are keenly aware the reason general aviation is 100 years behind modern quad copters in its level of automation is because of the number of ancient hand flown airplanes around, where the only means of remote control is relaying voice commands through a human.

Based on digital assistant valuations, it should be trivial for a computer to listen for your call sign, do something to get your attention, translate the spoken commands into drawings on a map.  Despite having no flying budget, such a thing could start life as a toy program that listened to internet streams of ATC.

GRAPHER: something that polls text files & constantly updates a simple line graph with the data in the file would be useful. Graphing serial port output in line graphs has been the #1 task for lions for 15 years, but copying from a text editor to star/open/libra office is extremely tedious. It needs a way for the user to specify a range of lines in the file to constantly graph, with text values, wildcards, & by pointing & clicking on the graph. The range needs to be relative to the start or the end of the file.

An X11 program in C would take only a few hours to write, but lions would rather spend forever contemplating using web browser javascript so someone else could use it.

Big Falcon Simulator, a very high fidelity simulation of a very large rocket, with the highest quality models & sounds possible. It would accurately simulate flights or have a racing mode with knockdowns.  Probably similar gameplay to Asphalt Extreme, but using flight controls.  Previous simulators have horrible graphics. They especially suffer in their renderings of fire.  This is the most ridiculous thing lions can imagine.


Cat files in numerical order

x-csrc - 1.67 kB - 06/14/2021 at 19:55



Download segmented files with format code

x-csrc - 1.63 kB - 06/14/2021 at 19:55


Wrapper for youtube-dl

text/x-python - 6.50 kB - 02/28/2021 at 22:08


x-csrc - 7.53 kB - 07/08/2020 at 19:08


x-xz - 9.04 kB - 07/04/2020 at 22:35


View all 20 files

  • VIC 1525 poster printing

    lion mclionhead3 days ago 0 comments

    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. 

  • Better printing workflow

    lion mclionhead04/14/2024 at 19:28 0 comments

    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.

  • Starship variant of jupiter lander

    lion mclionhead04/05/2024 at 23:36 0 comments

    Jupiter lander was either the lion kingdom's 1st or 2nd C64 game.  It was horrible, but it's time for a starship variant  with more forgiving rules.  Instead of outright blowing up on contact, it could have a damage accumulator, fuel penalty, or a time penalty.  It would have multiple maps & possibly maps larger than a single screen.  It would have fuel recharge hotspots & damage repair hotspots.  It could be a C64 game in an emulator.

    It would be a more attainable project than a full clone of Asphalt 9.  It could be a 2D Asphalt 9 complete with multiple players, knockdowns, large maps.  The hot spots would replace the tricks.  It would still be a lander game with landing in a catching tower as the goal.  

    The mane thing lions need before another retro confusing project is a way to print debugging somewhere besides the screen.  There is a serial port.  We didn't have serial port debugging in the day because a serial console would have entailed a 2nd complete commodore.

  • Customizable store

    lion mclionhead03/01/2024 at 06:27 0 comments

    The lion kingdom now has 26 items saved for later. 

    But lions suspect the save for later feature wasn't designed for what it's being used for.  What they really need is a store within a store where users can stock everything they could need in the future, organize it by popularity & price, & the items stay around after they're bought.  The biggest problem with the current design is the items disappearing after they're bought & a cumbersome search through past orders being required to find them again.

    Sometimes there are things you never intend to buy but want to study quickly, like VR goggles.

  • Edit a text file on a phone in a browser

    lion mclionhead02/13/2024 at 20:11 0 comments

    There is a desire to edit config files & notes on a phone without shuffling files around, typing on the phone screen, or using busybox on ADB.

    Webphone needs an editor which shows the file contents in a text box, has a save button, revert button.  Browser text editing is horrendous but better than nothing.  It would be the absolute minimum way of changing a text file.

    After some heroic HTML POST handling, it was done.  Need undo or revert?  Just hit the back button.

    There is 1 kaboom case.  If a text editor on the phone changes it & the user resends the POST in the browser, it'll overwrite the phone changes.    The post could contain an md5sum of the previous save & it could reject the post if the md5 doesn't match what's on the phone. 


    This became kind of a pain after a while.  It needs to retain the size of the text box in a cookie. 

  • JT65 decoding on a C64

    lion mclionhead01/24/2024 at 02:58 0 comments

    Retro guy says the C64 can't do it.  The lion kingdom says with enough time & the right software, it could.  It would have to use sin/cos transforms instead of a fast fourier transform.  It would take a few disk swaps.  The moon bounce aspect is just a facade for the real ham radio application.  The audio file is 620000 samples, 13 bits per sample.

    The lion kingdom's vague understanding is JT65 sends a sine wave on 1 of 65 frequencies to encode 65 possible symbols.  Each symbol is 1/3 of a second.  1 symbol is a sync code.  Every other symbol is a sync code.  The mane problem is detecting the pseudo random sync vector.  They call for a 2048 sample FFT.

  • Integrating C64 programs with a modern desktop

    lion mclionhead01/05/2024 at 23:07 0 comments

    The lion kingdom started wondering how commodore 64 programs could be seamlessly integrated in a modern desktop.  The mane need is to make the emulator behave like a native windowed program.  It needs a way to trap mouse events when the pointer is over it without having to think about alt-m.  It needs to exit without a prompt & when the program exits.  It needs a way to access files on the host filesystem instead of on a disk image.  It needs to just show an optimized display without all the other widgets or borders. 

    It needs to be resizable & have persistent settings like a normal program.  There was once a horrendous CRT emulator for vice, but it still had size limitations.  Arbitrary resizing would most certainly require opengl/vulcan/opencl/CUDA.

     Command line arguments passed to the emulator need to go to the program being run.  Then, conceivably, C64 programs could be indistinguishable from host programs.  They could be wrapped in a .sh file & run just like host programs.  The easiest way might be overwriting the disk image.

    There should be a headless mode which just runs a program with access to the host filesystem.  Possibly, it could access a serial port on the host or a /dev file for I/O.  Maybe JSR FFD2 & JSR FFCF could be indirected to the console.

    Seamless C64 integration is a key amount of value lions need to do any significant programming for it.  Then, it would be a lot closer to a useful tool to create vintage looking art, play C64 games as if they were native host programs, or running utilities on host files.  It would be stripped down to just the programming model.  The I/O wouldn't be a very accurate replica of the time.  There would be file name translation.  Host filesystem access would be a game changer for just writing file utilities.

  • Replicate Images Paint System on a C64

    lion mclionhead11/10/2023 at 23:03 0 comments

    A much higher quality reading rainbow copy was uploaded recently, so the lion kingdom was caught up again in the paint  program.  Helas, there were no watermarks in those days.  That has remaned an enigma since lions 1st saw it in 1983.  It was a 1 off program written in the New York Institute of Technology computer graphics lab called Images Paint System.

    Then there's 1 hit for a siggraph presentation.

    After some heroic network capture scraping & transcoding, a live stream was on the hard drive.  Helas, it was more about the art & the artist rather than the tool or what it ran on.  At 47:00 she revealed the program only achieved animation by cycling the color palette, hence why the oars looked like they did.  There's a video of clearly palette based animation in realtime.

    The higher resolution reading rainbow footage showed a full screen text menu mode with a barely visible pointer over it.  It might have been a text cursor. 

    The presenter selects "get brush" from 1 page of options.  This shows multiple pages of brush titles but no images of the brushes.  It looks like he started with "/brushes/dot9 solid" selected & changed it to "/brushes/cluster solid" from this screen.  

    The next footage flips back to the graphics screen where he does a paint operation & then fills by similar color.  Young lion was amazed by the number of colors.  There's a choice between drawing patterns & solid colors.  It's possible that the pattern was actually selected from the brushes menu & it was hard coded to be those colors. 

    There's a zoom function.  It's all the same as any modern program, but with a much more spartan interface.  It shows how PC paint & Mac paint in the day were really incremental updates to previously devised tools.

    The common motif in those days was a 100% zoom & a magnifying rectangle.  Zoom mode was entered by moving a fixed size rectangle over an area to magnify.  We thought that was how it was always going to be.  There was no concept of the mane window having multiple zoom levels with the same tools.

    Some enhancement shows the text menus were always on a VT100 in the back while the foreground monitor always showed graphics.  Both had to be accessed from the same tablet.  He actually said VT100 on a kid show. The tablet might have been multiplexed with the serial port.

    Given all the fuss about replicating vintage programs lost to time, this might be a good one to replicate either on a C64 emulator to discover how close a C64 could have gotten or in javascript.  Lions wouldn't invest any more than javascript but the real discovery would be from replicating it on a C64.

    The XOR triangle cursor would have been tricky on a C64.   Sprites didn't have XOR.  They only had transparency.  It would entail XORing the bitmap itself. Pinball construction set used exclusively XORed bitmap operations & they were still fast.

    To get the palette overlay & zoom would have taken a double buffer.  There's a history menu option but no obvious undo.  He uses fill rather than undo to undo an operation.

    The 2 oar positions had the same colors so they were using 2 palette entries to draw 1 output color. The commodore couldn't map all 16 palette entries to all 16 colors.  It had 2 global palette entries it could map to all 16 colors.  Every 8x8 block had 2 more palette entries to map to all 16 colors.  It would have to back up the 8x8 palettes to change those.

    A practical drawing program would have to fix the global palette to some user settings.  That leaves only 2 palette entries per 8x8 block for a drawing command, hardly the experience on the tube.

  • Line drawing animation on the C64

    lion mclionhead11/10/2023 at 22:47 0 comments

    Reviewing how Aegis animator worked, young lion could have had a kick ass line drawing animation program on the C64.  At minimum, it could have just interpolated (tweened) polygon vertices between keyframes.  At most, it could have supported objects, grouping, translate, scale, rotate, mirror, perspective modifiers, all with their own keyframes on some kind of timeline.  That could have replaced all the pen & paper drawing lions did.  

    While technically within the C64's limits, the concepts were just too far beyond young lion & the bitmap routines were definitely inaccessible to young lion.  An object oriented drawing program would definitely have been a noble cause & it could have been done in Logo.  Lions didn't discover object oriented line drawing until 1993.  Graphs of modifiers didn't come until the 2000's.  Even today it would be difficult to represent a graph that changed over time.

    While Blender can do it all now, it has somehow managed to make line drawings impossibly hard.  That could be a rationale for making a simple line animation program in Javascript today.

    The mane reason for retro computing today is to discover if something was ever possible in a certain time & to inform future decisions on declaring something impossible.  A big question was if a line drawing animator was ever available for the C64.  Aegis animator was only for Amiga.  All lions remember were pixel by pixel sprite editors.  The most advanced C64 program was super slow Gigacad on account of 3D support.  Practical use of line drawing animation today would be quite limited.

    It seems like maybe it could find a place between full 3D character animation & static 2D drawings.  Young lion saw story boarding as a practical output for someone without the resources for full 3D animation or live action.


    A C64 implementation would probably be in C using CC65's graphics library.  The database from that could be reused in a Linux version.  The heart of it is a graph of line art objects, some of which are empty & only placeholders for modifiers.  Some of them are links to others.  Each object has a sequence of polygons for tweening, a database of curves for translation, rotation, scaling, flipping, show, hide.  Other modifiers might create opacity for closed polygons, transitions.  There's recursive application of the modifiers to child objects.  Show & hide eliminate the need for the graph to change over time.  The portable section has all the graph editing operations.

    Then the C64 specific part is just the user input & display.  Finding a mouse input for a C64 emulator is the great task.  Lions didn't have a 1351 until summer 1988 so young lion would really have used a joystick.  Young lion would have had a much harder time capturing line art with a joystick than drawing it by paw, so that might explain why the idea never happened. 

    Maybe there could have been a tool to convert freepaw drawings to line art by manually specifying keypoints in a freepawed image.   Maybe RLE compression & a reduced resolution could have allowed it to page flip just freepaw drawings.  Like a modern 3D program, you would draw objects in a scene. There would be a way to export & import individual objects. 


    There's an example of a timeline editor on a commodore 64 which stood the test of time.

    It was all character based with a sprite mouse pointer.  There was much page flipping since they couldn't fit much information in 40x25.  That was written in the early 2000's & it's still for sale.  Lions just can't imagine any productivity being done on a C64 now except...

    Read more »

  • Spreadsheet to form filler

    lion mclionhead10/10/2023 at 18:47 0 comments

    The general idea is to import a PDF which is not a fillable form & specify arbitrary locations to draw hundreds of individual spreadsheet cells on the form.  Lions have only seen solutions that require the PDF to be a fillable form.  In more general terms, it would be a spreadsheet to image overlay.  The PDF would be converted to a set of generic images & the spreadsheet cells would be drawn using a table of X, Y, SIZE entries.

    It most certainly would require a GUI.  The 1st idea was to just export an open/libre office spreadsheet to a CSV file & read cells from that in a native program, but how tedious it would be to export a new CSV file for every change. 

    It might be a good fit for a web app that ingested data from a goog sheet.  There are ways to import an image in a goog doc, then enter text on top of it.  There's a floating option for the image called "behind text".  As usual nowadays, the only way to see any of the options is to click on it or mouse over it.  Positioning text over it requires spacing, carriage returning over, & it's not very precise.  There might be a way to paste ranges of cells from a spreadsheet in a goog doc, but it doesn't work for lions.  This used to be a basic word processor function.

    There is a javascript library which accesses goog sheet data.  At this point, any web app that ingests hundreds of individual cells from a goog sheet seems incredibly slow.  It would have to cache the data & only update it when the user hit reload.  It couldn't be done with a pure cookie database.   It seems best suited to a server focused workload with the browser as a very dumb GUI.  The browser would just query the server for text & images to draw while just doing the drawing.

     It would need a server based database of PDF files, decoded images from the PDF files, spreadsheet links, cached spreadsheet data, text locations.  Maybe all the goog doc interfacing & PDF decoding could be done on the server.  It would not decode the PDF in the browser.  Lions are pretty sure the goog PDF viewer outputs images.  The text overlays would be drawn in the browser.

    The web app would just show the PDF with the text overlays.  There would be a cropping tool & a text insert tool.  The text boxes would have popups with a font size & decimal format.  There might be an export option to generate a set of PNG images but it might be easiest to use the browser's print to PDF function.  A PNG export would require 2 different rendering routines.

    Lions still get a bad taste from using a goog spreadsheet, but it's easier to access the data than open/libre office.  

    There's long been a need for a general apartment server to serve programs like this.  Other tasks for it are formatting weather station data, controlling desks, formatting hackaday data.  It might have to run on the router & that means stepping up the router speed, increasing the router storage, improving the enclosure.  A lot of programs these days create their own web server & require a browser as the GUI, so it's not that ridiculous even thought it's a lot more complicated than the old days.

View all 117 project logs

Enjoy this project?



Ken Yap wrote 05/07/2020 at 23:55 point

I'm using Free42, a program which is a reimplementation of the HP42S scientific calculator. It exists in both desktop and smartphone versions. Quite indispensable and small, just under 3MB on Linux.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates