Bible with 8-bit feel interface

Here is my third iteration of an eBible interface -- browsing the Bible (KJV) by electronic means.  First was a tiny 8x2 text screen on mbed NXP LPC1768 (ARM M3), second was a Nokia cell phone screen on mbed NXP LPC1114 (ARM M0 through hole package), and this third one looks very similar to a familiar 8-bit system, running in the browser.  

The third revision required no soldering, and works with desktop, tablet, mobile phone devices, anything with a modern web browser.  This current iteration builds on cbmish-script, providing the Commodore-like look and feel.  

History

Back 35+ years ago I brainstormed on how to put the Bible on a Commodore computer.  For example, with the Bible containing 66 books, I had planned to combine I John, II John, III John as one book, saving two so the book number would be 0..63 fitting in 6 bits.  Nah, that's probably silly, one byte is proper to fit the book number. But I never got that far on the Commodore.

With my first mbed based eBible iteration, I focused on being able to navigate book to book, chapter to chapter, and verse to verse.  So I built an index that was stored on the SD card, FAT filesystem.

The second eBible iteration had a different screen and used simpler block flash memory device (no filesystem whatsoever), with text, indexes, and bookmarks stored at different offsets.

Just prior to the third iteration, I restored the indexing code, porting from its original state working with mbed and linux, now to Microsoft Visual C++ on Windows.  With indexing working, I was playing around and output the Bible text to a flat JSON format now shared on github.

Then I created a few JavaScript routines to navigate the text and perform basic operations required for navigation.  I hosted the solution on StackBlitz to begin with as it is a good solution for shared web development with no local tools needed.  I just wrote some JavaScript that output very simple HTML, and it was doing something useful very quickly.  With some additional polish, it switched from outputting fixed results to populating drop down controls for the books, chapter numbers, and verse numbers, resulting in rudimentary navigation.  This solution was shared back to a GitHub repository as well, and has since been revised to work more standalone from a local file system folder in addition to being hosted on the web.

All along the way I had planned to revive my Bible on Commodore project, and the idea was to leverage my existing cbmish-script solution, which provides a Commodore look while programming in modern TypeScript.

So I set out on that journey, and saw results right away.  Almost all the bitmapped text on the screen is a link.   First the navigation was limited to book/chapter/verse, allowing selection of book, book by book selection of chapter numbers, chapter by chapter selection of verse numbers, and navigation of the text verse by verse, with back links to book, chapter, and verse selections.

Added on was an about page, stats page, link to cbmish samples, and search for words.

Links are almost everywhere

Virtually every word and number on the screen is a link.  Clicking on text will perform a search of that word showing other references to it.  One of the latest features added is being able to replace the word (or phrase) searched for, to truly make this solution interactive.

How information is accessed, efficiency

How is the latest incarnation indexed?  It is not.  Each entry has book name, chapter number, verse number, and verse text.  It is one long array of verses with this context in order.

To retrieve a specific verse, code scans the entire array for that data, returning a match.

How much data?  About 4 megabytes.  Or 6 megabytes with references per entry.  Almost 32,000 records/verses in this flat file format.

The operations involved include retrieving the book names, counting the chapters in a book, counting the verses in a specific book/chapter, retrieving the text of a verse, retrieving all the verse records for a chapter, and finding the verse records containing a specific word or word portion.

Is it slow?  No.  It just works.  Scanning the 6 megabytes of data is fine on a modern desktop computer or mobile device.  Even retrieving a list of all verses containing an "e" or "the" seems instantaneous.

I was not used to this kind of performance or memory or storage capability when originally coding Commodore or embedded development platforms.  But fast processors with lots of resources handle these tasks with ease.  It's almost like they were designed to handle big 3D virtual games and a few megabytes of text is no big deal.

Is it a waste?  Is it inefficient?  Sure, but today megabytes are measly, and cycles are cheap too.  When should we optimize for speed and energy?  Of course the answer is that it depends.  As this is an interactive application used by a single user occasionally, and performance is absolutely fine, no optimizations are necessary.  We are done!

If you are developing a multi-user system in a VM process in a server farm where you are paying for resources, you may need to prioritize your optimizations for cost, energy use (be a good steward!), and performance.

It would be easy enough to adapt the flat file into a hierarchical structure, and add indexing for words and text.  Handling this complexity is a useful skill even if the performance/processing optimizations are not at all necessary.  For now it's just useful enough to consider what effort would be necessary rather than actually performing the extra work.

Comparison with Commodore

It looks like a Commodore 64 because the resolution, fonts, colors, and behaviors are the same or similar.  

Though a port to a Commodore would require some special work including the indexing.

Storage - original Commodores didn't have megabytes of storage.  Using an SDIEC or similar may be possible, or another hard disk solution.  Another choice would be to offload to an add-on board such as ESP32 and optionally a web service.

Most Commodores didn't have a mouse back in the day, and mouse handling would require extra work too.  Additional software and hardware is required, or use of emulation.

All in all, developing the cbmish-script environment alleviates much of the resource limitations of the original Commodore microcomputer and while it may not be a technically accurate representation, it provides much of the look and feel of the original system.

Cbimsh-script technical details

cbmish-script uses multiple canvases to provide the border, background, foreground, and sprite layers which are drawn independently, and combined by the browser software.  Commodore fonts are drawn pixel by pixel with both character sets available to be displayed simultaneously.  Transparent pixels allow a lower level behind to show through (like background).

Mouse support is provided with click, mousemove, mouseleave window event handlers for the sprite (highest visible) layer.  Clickable regions and buttons are drawn highlighted (or unhighlighted) when hovered to demonstrate they may be interacted with the mouse.  Similarly they animate when clicked on a touchscreen device.  The cbmish-script system keeps track of a list of active buttons and is able to compute which ones are being interacted with.

This Bible software leverages these regions to also act as a text input field.  When the region is clicked on, it activates a bounding box for the region to limit screen updates and cursor movement to that region, exited when Enter or Escape keys are pressed, or the mouse clicks outside the region.  An onexit handler regains control and is able to grab the modified text from the screen.

Before these changes, cbmish-script had limited input capabilities.  It had operated in a display only and echo only capacity, displaying what is typed, not intelligently responding to input.

What could be added next? 

Next I should add more input and graphical capabilities to cbmish-script.  And/or a responsive mode that changes resolution and orientation with the mobile device or browser window.  Maybe add a Bible reading plan/tracker, bookmarks, multiple search terms, and a master word list.  Add another Commodore emulator to my repos?  Just ideas for now.

Links

• Open source: cbmish-bible, cbmish-script, eBible(M3), eBible(M0), bible-json, js-bible
• Hosted solution: cbmish-bible

What is Cbmish?

 

Is this Commodore?

If it looks like a Commodore, acts like a Commodore, and feels like a Commodore, is it a Commodore?  Not always.  This cbmish is not a Commodore, and not made by Commodore Business Machines (CBM).  But it is like a Commodore, thus the "-ish" (means like).  

Cbmish is like a Commodore.  This web software solution provides the feel of a Commodore in a web browser.  There's a retro look and feel.  But with a more modern programming language.

READY.

But it says "READY."  Is that BASIC?  No, it is lying to you.  It is not ready for commands.  It won't PRINT or GOTO.  It is only ready for typing at this point.   You can navigate the screen with cursor keys and typing letters, numbers, punctuation, and other symbols.  You can change colors, type PETSCII, change to upper/lowercase, switch to reverse characters. It does feel like a Commodore.

Mouse

It also responds to mouse motion and clicks.  That's not a Commodore I ever owned.  Those rounded corners and text are buttons, and there are links too.  Clicking on a rounded button will present the user with a relevant sample screen, or navigate to another web page.  Colors may change, graphics may be drawn, text will display, and sprites may move.  

Why?

So why do this?  The about screen goes into some detail.  I'm ready to move on from BASIC (gasp!) and 6502 Assembly (gasp!) and I don't really want to program on my Commodore (gasp!), but I do want to continue the look and feel of Commodore.  My current efforts are web based and I have been using TypeScript from some years now.  My skill is mostly is C languages (C, C++, C#) and while I had shunned web development for sometime, my professional and hobby efforts have collided with doing full-stack development including C# and also TypeScript.

While interpreted languages aren't usually my thing (though I love me some AWK) I have seen features of JavaScirpt and functional programming influencing C#, and of course there are underpinnings of C in TypeScript too, and similar functional programming in JavaScript/TypeScript too.  While they are all quite distinct languages, there is enough familiarity between them, also also gotchas that keep them interesting when they are different.  It's fun to know multiple languages!

This is stuff you could do with your real Commodore, but it's done here using TypeScript written code.  TypeScript that is transpiled to JavaScript so it runs in the user's web browser.  A combination of HTML, CSS, and TypeScript results in code to provide the cbmish interfaces to present things like one of the favorite 80s retro systems.

You can code interactively using the browser developer tools, or you can launch Visual Code (or similar) with typescript compiler dependency to have code transpiled as soon as you save.  Instructions for both are on github in the README (see link below). 

10 PRINT "Hello ";: GOTO 10

So do you really want the equivalent of PRINT/GOTO? Well this will have to do, see immediate mode JavaScript entered into the console of the development tools of Google Chrome web browser.

PRINT/GOTO equivalent

Conclusion

So long story short, it's a fine time to do Commodore like programming on the web, in a modern language.  Take the best of modern languages and pair that with the look and feel of a great retro computer.   Are you keeping up with the Commodore?  Because cbmish is keeping up with the web.

Links

    open source (MIT License) at github.com

    live demo (try it now!)

Samples

mouse over button

Colors

petscii

chr$()s

Maze

Keyboard

lores

sine wave

dissolve

knight vs. dragon
sprite animation

about

HIRES for Vic-20 (BASIC 2.0 extension) is READY.

 

The BASIC commands are implemented, small font created, and demonstrations implemented.   Please enjoy this Space War and Omega Race inspired flying ship.

Source, disk image, and more details are on github for Commodore Vic-20 with memory expansion.

BASIC extension command syntax is:

COLOR [foreground[+8][,[background][,[border][,auxillary[,inverse]]]]]

COLOR [foreground[+8]] @ x1,y1 [TO x2,y2]

TEXT

HIRES xresolution, yresolution [,fillbyte]

DELAY jiffies

PLOT COLOR ON|OFF

PLOT [NOT|CLR] (@ x1,y1)|(TO x2,y2)...    **

PLOT 0|1|2|3 (@ x1,y1)|(TO x2,y2)...

PLOT "ABC" @ x,y [,addr [,width,height [,bytes]]]

RECT [NOT|CLR] [@] x1,y1 TO x2,y2

RECT 0|1|2|3 @ x1,y1 TO x2,y2

SHAPE GET|PUT|OR|XOR|AND|NOT|CLR addr @ x1, y1 TO x2, y2

** only first @ optional, when not multi-color

Vic-20 Hi-Res BASIC extension progress

 

Shape operations are functional, and work has begun on leveraging BASIC keyword extensions (borrowing from my own HIRES for C64).

4UPART program listing

While the SYS syntax is implemented, the BASIC keyword work has just begun.

Current vs. Proposed Syntaxes

Source and disk image are on github

Knight vs. Dragon prototype on Commodore 128

My son Ben (age 9) designed all the graphics, background and colors.  He edited the background screen strictly with inverse spaces.  Sprites were edited on the Commodore 128 with SPRDEF.  The programming manual has instructions on saving the sprite memory to disk.  And I was able to save both the text screen and colors to disk also using the dual screen capability of the Commodore 128 to enter the commands via the 80 column screen (ESC+X).  My memory is that I used MONITOR to save using hex addresses, whereas I'm showing BSAVE commands here for more symmetry with the program listing.

BSAVE "SPRITES",B0,P3584 TO P4096

BSAVE "BACKGROUND",B0,P1024 TO P2048

BSAVE "COLORS",B15,P55296 TO P56320

I wrote the BASIC demo to randomly move the characters, and flash the border red when the sprites collide.

My son and I made a great team on this project.   Thanks to his art and I am very pleased to have introduced him to the Commodore 128 and have him involved in computer animation.

Links: 

dragon.d64 disk image

Commodore 128 Programmer's Reference Guide 

Left hand keyboard template and AutoHotKey

  

Back in the day (decades ago), I purchased a Matias Half Keyboard (USB) at a computer show because it was so cool.   My plan was to mouse with my right and type with my left.   There was a bit of a learning curve, and the keyboard was so tiny.  Every key was overloaded so much, I found that using function keys, hotkeys, numbers, cursor keys, etc. was too tricky.  So I ended up putting it in a drawer.   Years later I resold it on Amazon for the same price I paid.

Then years later I missed the half keyboard, want to use it occasionally.  So I looked for an alternative, and while there are other hardware half keyboard solutions out there, often they are expensive.  Even the Matias one is now listed at $595.  I paid a sixth of that long ago, but it's a niche product that only a few will need, so that figures.

A few more searches and I found that someone had created an AutoHotKey script to do the basic trick in software to make the spacebar a key modifier.   The script is straightforward and well written!

In case you don't know AutoHotKey, it is software for Windows that allows you to remap keyboard and mouse events (and other similar things) for macros, and other automation operations.  It has its own scripting language for capturing key events and performing key sends, etc.   Like you could use it to disable the Caps Lock, launch, close, and reposition your Windows on the screen, copy and paste text on the screen, and all sorts of things.

To help me learn to use this simple one-handed keyboard script, I've drawn a keyboard with Microsoft Paint, printed it out, and taped to my monitor for easy reference.   While the script supports left or right hand operation, I only drew the left hand.

Skimming the script thread, it appears others have discussed displaying a reference on the screen, so that exercise is left to the reader.

Hope this is also useful to someone else.

Vic-20 HI-RES in progress - Memory Layout

Vic-20 Graphics Memory Layout

The Vic-20 doesn't have a native graphics mode.  But it can use a character set from onboard RAM, and double the size of character cells from 8x8 to 8x16 pixels.

A solution puts video memory at address 4096 ($1000), and character RAM at ($1000).  Notice they are the same?  Yes, there's only 5K onboard RAM in addition to color RAM.   The first 1K starts at address 0 ($0000), and the other 4K starts at address 4096 ($1000).   Regardless of any other RAM present in the system (can add 35K), only that latter 4K is accessible as video/character RAM to the video chip.  (Even if the earlier 1K is available, there's too many conflicts with BASIC and KERNAL use).

So bitmapped characters (graphics) and video RAM (characters on the screen) have to share the same section of memory.  The way bytes work, at most 256 characters could be displayed on the screen, but that would require a full 4K of RAM for their bitmaps (16*256), so something has to give.   By using only 240 characters on the screen, that reserves 16*16 = 256 bytes for video memory, and the remaining memory can be used for graphics.  For the bitmap to skip over screen memory and avoiding any overlap, the characters used on the screen are indexed starting at 16 ($10).

$1000-$10EF screen (240 bytes), values $10-$FF (16 to 255)

$10F0-$10FF unused (16 bytes)

$1100-$1FFF bitmap (3840 bytes)

BASIC RAM can be moved to either 3K expansion RAM ($400-$FFF) or 8K or greater expansion RAM ($2000 and later).

One layout that is possible is 20 characters wide by 12 characters tall = 240 characters = 160x192 resolution.

The easiest layout of characters is to store them consecutively in memory as shown above.   Character layout for the screen is left to right, then wraps to the next row.   This scheme matches color memory layout as well.   An additional advantage is that time sensitive updates to graphics can be more aligned with the raster line.

Another layout of characters is to line them up vertically as shown below.  This has the advantage that memory is contiguous vertically until advancing to the next column of 8 pixels.   This allows for optimizations in managing graphics memory at the disadvantage of working vertically instead of horizontally, thus fighting the raster line.  But color memory is still horizontally oriented, so the address calculation is different, the same as the earlier layout.

 
As the Vic-20 allows for configuring the number of character columns, character rows, and adjusting top and left margins, a variety of resolutions are possible.

Some notable resolutions include

160x192, 192x160, 200x144, 144x208, 160x160

The last is mentioned as it is the resolution used by the Super Expander cartridge.  But note it only requires 200 bytes of screen memory, so using that resolution leaves 696 bytes of onboard memory unused for graphics/screen that could be available for another use, maybe 506 bytes is still text screen memory. 

Links

Vic-20 open source hi-res support (github)

Built D64 disk image for Vic-20 is here and see Usage in README.md