Close
0%
0%

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 http://heroinewarrior.com/utils/rpn2.c 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 freshmeat.net 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.

catnums.c

Cat files in numerical order

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

Download

segments2.c

Download segmented files with format code

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

Download

tube.py

Wrapper for youtube-dl

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

Download

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

Download

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

Download

View all 20 files

  • 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.

    https://hackaday.io/project/138050-silly-software-wishlist/log/179072-web-based-file-manager-for-android

    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. 

  • 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. 

    https://www.arrl.org/files/file/18JT65.pdf

    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.

    https://dac.siggraph.org/pioneers-digital-art/

    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.

  • Particle simulation on C64

    lion mclionhead09/27/2023 at 21:50 0 comments

    Had the idea after seeing some demos which looked it but didn't really do it. 

    These galaxy collision type graphics required a superconfuser during the C64's days, computing F=MA millions of times, recursively.  The hope would be to somehow simplify it to achieve a lower res particle effect on a commodore.  It would use fewer particles, 2D only, entirely lookup tables, 320x200 bitmap mode, possibly only 0-256 X.

    The number of calculations possible for a single particle are bugger all on a 6502.  The hope would be to hard code some kind of motion vector table for each particle to achieve a swirling effect.  Maybe there could be an XY to polar conversion.  For short animations, the solution is normally a color palette change rather than a redrawing of every pixel.  To prove it's not a color palette animation, it would have to be long.

  • list & pull

    lion mclionhead09/14/2023 at 22:08 0 comments

    Lions wrote push a long time ago & it works bloody well at moving files to a phone.

    https://hackaday.io/project/138050-silly-software-wishlist/log/160353-move-mutiple-files-to-an-android-phone

    Recently, there's a new desire to list directories & get files from a phone.  list & pull would be desirable entries.  To this day, list is not a standard Linux command despite ls existing for decades.  Maybe in honor of commodore heritage, it should be

    lI

    A lot of commands could use a lowercase uppercase abbreviation in honor of commodore heritage.  push came from ADB lingo, but the original FTP commands were ls, get, put which in C64 lingo would be

    lI, gE, pU

     To this day, list, get, put are not standard Linux commands.

    Lions wrote webphone a long time ago, but wifi is too slow to transfer large files.

    https://hackaday.io/project/138050-silly-software-wishlist/log/179072-web-based-file-manager-for-android


    list, pull, & a text file viewer might be better off consolidated in an interactive file browser that communicates over ADB.  There is an Android commander for windows.

    ------------------------------------------------------------------------------------------------------------------------

    A big piece of the puzzle is tab completion for an ADB wrapper.  It would have to run ls on the phone. 

    As described in

    https://opensource.com/article/18/3/creating-bash-completion-script

    You have to run the complete, compgen commands in the .bashrc to create completion commands. 

  • Tile caching system... on a C64

    lion mclionhead06/17/2023 at 02:22 0 comments

    Another dream besides mastering the bitmapped graphics model was creating a caching tile system.  To laylion eyes, games to this day load the entire world map in RAM.  Can't remember 8 bit guy ever mentioning tile caching.  They might separate levels into different files, but the entire map for a level has to fit in RAM. 

    Young lion dreamed about dynamically loading tiles from disk as needed, to create an unlimited map size.  Seem to remember 1 trick with the commodore was it could load from disk without interrupting a program.  It might have been restricted to the native slow loader.  The disk size was 170kb.  RAM was lucky to hold 48k of map data.

    It would be a simple demo where a player could joystick around a 2D map.  The algorithms of caching & prefetching were far beyond young lion. The general idea is to keep all tiles within a certain distance of the player position in RAM.  Keep other tiles around based on age.  The radius would extend beyond the screen borders.  That way the player can hit the screen edge usually without waiting.

    Goog maps was the 1st widespread use of cached tiles, but to this day it has a relatively easy job of only loading what's currently visible & making the user wait. 

    Like most games it would use character set mode.  Another problem afflicting young lion was creating the most optimum character set for the tiles.  The PETSCII set was the most versatile but looked the worst.  Make it too specialized & the world size becomes limited by the character set.  Bitmap mode was seen as too slow & limited to just wireframes.  Even after all the modern optimizations, glxgears was damn slow on a C64.  Forget about a fully shaded polygon world.

    There might be general purpose characters for edges of objects & specialized characters for textures of an object.  Landscape characters could be more general purpose than structures.

    Young lion's original idea just involved an aircraft carrier, buildings, water, & maybe a forest.  The aircraft carrier was a big investment for something which only appeared once.  Another idea might have been to dynamically load character sets based on position.  That would have slowed down gameplay & been a nasty algorithm.

    The most optimum system might have defined a map of tile ID's in 1 part of the disk, & the bitmap data for each tile ID in another part of the disk.  The bitmap data would be a 8x8, 16x16, or 32x32 bitmap assigned to each tile.  The program would dynamically fill regions of character memory with the tile bitmaps, using the same caching rule as the map, but it might have to also flush essential tiles by age.  There would be times when a visible tile was resident but its bitmap wasn't so it would have to go to disk to draw that tile. 

    The sector size was 254 bytes, so the tiles would have to be loaded in groups.  The caching would have to be done by groups of tiles.  Bitmap caching would be similarly coarse.

    There was also the need for collision boundaries, maybe defined by a bit in the map data.  Collisions would need some kind of direction rules so the player could cross bridges from only 2 points & skip regions to cross under bridges.  A flying game would need a Z value for each tile.  Finally, the tile loads have to be sorted to optimize the seeking.  It's a pretty complicated problem to this day.

  • Simulated monochrome

    lion mclionhead05/01/2023 at 08:19 0 comments

    Usagi's footage of greyscale green brings back a warm & fuzzy memory. Most gootubers just show color monitors because color monitors are free compared to what they were in the day. Greyscale green is a rarely seen color scheme, but it briefly appeared in lion history during an overall simpler time. All we had in those days were different shades of green for different colors. A greyscale green interface today would be quite difficult. The xgamma command can only adjust gamma. The 4K LG can adjust color balance but not turn off a channel. It took some doing just to make X11 draw B&W for outdoor use. It would almost be easier to capture HDMI & translate it to green in a raspberry pi for display.

View all 113 project logs

Enjoy this project?

Share

Discussions

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