Project Logs

Collapse

• Modern prompt language

  lion mclionhead • 02/27/2025 at 22:05 • 0 comments

  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. 
  

• More robust base64

  lion mclionhead • 09/11/2024 at 01:19 • 0 comments

  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.
  

• Ultimate text editor

  lion mclionhead • 05/25/2024 at 01:47 • 1 comment

  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.
  

• VIC 1525 poster printing

  lion mclionhead • 04/21/2024 at 02:02 • 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 mclionhead • 04/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 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.

View all 120 project logs