As a pure useless demo, lions still think a hard coded, single direction scrolling bitmap with concurrent disk reads feeding the scrolling would be damn impressive looking.  Don't think it can ever be detailed or fast enough for any kind of game but it could be an interesting visual if the detail was maxed out & it moved at the maximum IO speed.  Thinking the demo would pan over valles marinares.  It would need more than 25 row tiles & a script specifying all the tile locations, scrolling keyframes to support diagonal scrolling.  For a 2D race track game, it could work.

In reality, it would have worn down a real disk pretty fast.  Nowadays, 5.25" disks are irreplaceable so it might not be very practical except as a thought experiment.  The drive head & worm gear could probably last forever.  It could store the map in multiple locations to level the wear.

Some example photo conversions from https://www.digartroks.be/img2c64mc/index.php show what it would look like.  The undithered version seems more playable in a game since the players show up more.  Not sure what the yellow on the canyon floor is.  The converter almost needs some kind of color balance sliders to try to aid the color mapping.

A simple map compressed into 5 tiles with 9500 bytes compressing down to 7526 bytes in the worst case.  A test load of the worst case took 13 seconds or 3 columns/sec maximum scrolling speed.

Still somewhat readable with the colors converted to commodore.

As far as contiguous memory for offscreen bitmap tiles, there's a 9500 byte block at $dae0 & $35e0 which leaves 11744 at 0x0800 for the program & a few bits elsewhere.

Much hacking yielded a 3fps, 1 cell at a time scroller that concurrently read tiles from disk.  Definitely potato cam in the emulator.  This was 3k of program memory & 29440 bytes of world memory on disk to store 5 tiles.  Another 20 tiles could probably fit.  It doesn't support underruns but hard codes ping pong buffer swaps 3 times per second.  The tricky part is getting it started, where the disk needs to temporarily get 2 buffers ahead & then fall back to 1 buffer of lead time.

It gets within 2 frames of underrunning the largest tile.  In reality, the disk speed was quite non deterministic.  The seeks were fixed stepper motor times but the sector reads weren't guaranteed.  The problem is much easier when scrolling always goes 1 way at a fixed speed.

Making smooth scrolling would be the tricky bit.  It needs to scroll a single pixel in an interrupt handler.  Every 8 pixels, it needs to switch VIC banks in the interrupt handler, then make the mane loop scroll the color RAM 1 cell & then scroll the next bitmap & screen RAM 1 cell.  Since there's no VIC bank for color RAM, the color RAM scroll for the current position needs to be done after switching banks while the bitmap & screen RAM for the next position is done before switching banks.  There's an unavoidable color glitch when switching banks which is still visible on the gootubes.

A few hours later, it was smooth scrolling.  The mane problem with smooth scrolling was page flipping inside the raster interrupt.  All the disk I/O uses the same CIA register $dd00 as the VIC bank switching so all the disk I/O needed to selectively disable interrupts to be concurrent.  The glitches from copying color RAM were definitely pronounced.  Confirmed the glitches were not from debug prints.

The mane disappointment now is world map looking like a turd & being only 5 tiles.  Only 3 tiles actually have to be spooled from disk.  Text would be the most visible art but wouldn't justify bitmap mode. 

It is pretty much what young lion imagined building a game around.  It took lightyears more effort & tools than he could have ever mustered. Not sure how exciting a jupiter lander it would be without some opponents.  It would be too slow for the world map alone to be an obstacle course.

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

Any tiled game idea was far fetched at best.

The mane problem is the faster it scrolls, the less detail it can load.  The more detail it loads, the slower it has to scroll.  There is no happy outcome.

It needs to be limited to scrolling 1 way horizontally & have only 1 offscreen tile.  This would allow it to read 40 columns ahead & have at least 5 seconds to load a new tile at 8fps.  The tiles could be expanded to 35 rows to allow some vertical movement or diagonal movement but it would have to be a rail shooter.  Many games were horizontal side scrollers but none had unlimited tiles.  A starship jupiter lander with a Mars canyon comes to mind.  The reduce the speed, it could have opponents, targets on the ground, or a race  course inside the background image.

A reasonable amount of detail would probably need full bitmaps so you'd need the 2 page flips (20,000 bytes) + 1 offscreen bitmap (10,000 bytes) for 25 rows.  35 rows would require 2 offscreen bitmaps & not fit.  It would have to store just the 10 hidden rows of the visible tile & swap them with visible rows.  That would need 18000 offscreen + 20000 onscreen bytes.

Compression remanes a real problem.  For a minimum viable game speed, 2560 bytes of IO are likely the limit for each tile or 1/4 of a visible bitmap.   Large areas of flat colors, a flat area like a canyon floor or a sky could be a big win.  The next step might be doubling the pixel height or scaling individual cells. There's not much on the internet about compressing bitmaps.  The C64 was not fast enough for any kind of JPEG decompression.

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

After some more ideas, there was still no way a 2D scrolling sandbox would have been possible with a useful amount of detail or speed.  The macross demo showed moving around such a low detail world with the keyboard was pretty unbearable under 5 columns per second.  It wouldn't be practical for a flying game.

A vector line art system would probably rely on a character set but with character based line segments procedurally drawn 1 cell at a time, filled areas procedurally filled 1 cell at a time.  It would escalate in computational complexity about as much as it de-escelated in IO & probably be equally slow.  It wouldn't be able to store more detail.

A sandbox world would have to move 1 page at a time.  Art would have to be aligned to the tiles.  There could be a progress bar.  Each page could then have its own character set & more detail.  It's pretty much what all sandbox games already did.  Not sure what benefit it would have.  A bitmap defined by a unique character set is 4600 bytes.  It's kind of a novel design which combines the compression of a character set with the colors of a bitmap.

An object oriented world might work.  The tiles would be much larger but defined in much less memory.  An SDF-1 object, carrier object, building object, tree object could be memory resident.  Instead of memory resident tiles, it would render the screen on demand.  Tile memory would go to object storage.

Buffering 9 tiles is probably useless.  It has to be constantly loading from disk & the player has to be moving across those tiles instantly.  Blue Max, zaxxon obviously used object oriented worlds.  Young lion didn't appreciate what a triumph in linear world design Blue Max was. 

A robotech game like what was envisioned would have to be made like Blue Max, a rail shooter from the carrier horizontally across key points on Macross island, all memory resident. Another alternative would an FPV flier like Buck Rogers but with more objects.  The carrier takeoff from the TV show could be replicated in high fidelity & be the basis of the game  It definitely wasn't what 10 year old lion envisioned.