The pungent smell of Myrrh incense revived a memory of a friend's boat we visited several times, 40 years ago.  It had a pungent lived in, myrrh smell.  This memory is all but gone, except the smell.  The lion of the time thought this was what an old boat that's been lived in always smells like.

The lion kingdom continued pondering what attracts animals to programming games for vintage computers.  It could be the challenge of getting the most out of the least transistors.  It could be the low level programming model being more flexible.  It's definitely not easier to get good results from a C64 than it is from godot, as hard as godot is.  

The mane attraction lions believe is a much higher chance of a game for a vintage computer getting played.  If petscii robots & planet X3 were written for android, it would have been just another android programming channel no-one watched.  They would have been just more android programming examples no-one played.  It has nothing to do with the programming model.  It's because the C64 was a very popular computer that not a lot of software is still written for.

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

Sitting on the edge of yet another major commitment to C64 development, lions previously invested a lot of effort in the macross island demo, 3D demos, & side scrolling demo but the next step might be the biggest investment in a single thing.

The C64 was the very 1st which had a reasonable amount of graphics & sound support.  There were others, but it kind of represents the least amount of technology required to just begin to become useful.  That's what makes it enduring.

A commodore game is a lot easier to run than any modern game.  Just run a d64 image in a browser emulator, but lions believe the chance of a commodore game getting played is not as high as the chance of someone watching a commodore game getting played.  This is the age of the spectator society.  No-one is willing to do anything anymore when they can watch someone else do it. 

It's not a sure thing like writing a piece of shareware 30 years ago.  Not only is everyone a spectator, but they don't discover anything through searches or databases anymore. Most of their content is discovered by an algorithm.  There's a very narrow straw between what's created & what's ever seen.  The chance of getting picked by the straw is very remote.  Once picked, it has a very short lifespan.

A game has to stand on its own as a game, rather than as a novel vintage computing experience.  Once the vintage computing aspect is seen, it's not viewed again.

Lions definitely couldn't invest what 8 bit guy did.  It's unlikely his game was ever played except once by a few gootubers to collect revenue.  All the physical copies went on collector shelves.  It was watched by a lot of spectators for a while.  

It's kind of encouraging to see animals playing games & going beyond spectating at vintage computing festivals.  They're just not playing petscii robots & who knows how long they stick around.

If lions do anything, it has to be simple enough to finish quickly.  It can be divided into high value & low value parts.  The high value part is the demo of concurrent bitmap scrolling & disk streaming.  That's something nothing else does.  The low value part is the player fighting.  More time can be spent on the high value part than the low value part.  The player graphics just have to be watered down to the minimum.

It would be fascinating to see it run on period hardware, with a physical floppy disk.  This is never going to happen & it would only happen once if it did.  The floppy disks are no longer made.  Once you see it, you get it & it's done.

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

 

Watching an animal trying to draw bitmap circles in C64 BASIC reminded lions of why they never gravitated to programming an 8Mhz 8086.  We never had the programming tools for the 8086 that we had for the 6510.  There was no assembler or programming examples like Compute magazine & Hesmon.  We just had gwbasic for the 8086.  It was much slower at drawing than assembly language on the C64.  It had canned drawing routines, but these were not very optimized.  Part of the problem was the 640x400 resolution having a lot more pixels to draw.

Reviewing the old green manual, it really was intended for entering small assembly language programs.  

Lions remember it overprinting the line & prompting for the next line.  Then the disassembly command was often used for editing programs in memory.  It disassembled in realtime by cursoring up & down, but sometimes it became misaligned.

Unknown to young lions, it had commands to convert between hex & decimal.  There was a "new locator" command for relocating code with absolute addresses.  There was an "output divert" command which could save a disassembled program to disk in a format that could be edited in a text editor.  The trick is there wasn't an "input divert" command which loaded keyboard input from disk.  That would have allowed it to be used as an assembler.  That would have competed with their separate assembler product.

It has a command to exit to BASIC, but there's no way to enter a Hesmon command from BASIC.  There were keyboard phantom programs which poked keypresses into the keyboard buffer, but hesmon had total control when it was running.  Nothing could be running in an interrupt service routine when hesmon was running.

It would have been unthinkable at the time, but the only way to program a C64 today is to build a disk image with cross tools & just load the disk image.  It boggles the mind why so many C64 programmers still use period tools.