Silly software wishlist

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.

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.

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.

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. 

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

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

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.

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.

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.