Project Logs

Collapse

• Starship variant of jupiter lander

  lion mclionhead • 04/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 amazon.com store

  lion mclionhead • 03/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 mclionhead • 02/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. 
  

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

  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 mclionhead • 01/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 mclionhead • 01/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 mclionhead • 11/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 mclionhead • 11/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 mclionhead • 10/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 mclionhead • 09/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 mclionhead • 09/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. 
  

View all 115 project logs