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.
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.
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.
- Open source: cbmish-bible, cbmish-script, eBible(M3), eBible(M0), bible-json, js-bible
- Hosted solution: cbmish-bible