Gen 2 update: So many colors.

For the longest time, color was the domain of SBTCVM's old plotters and later, SBTGA. now the TTY has returned with a vengeance, in the pygame frontend.

View the dazzling 27-color 3-trit RGB color settings.

Yes! The packed art system has its own colors.  Nice isn't it?

Also, the default packed art colors have lost the blue tint, falling back to white grey and black.





More information: tty colors documentation

Gen 2 Update: ternary-packed-art encoding

You may be wondering what ternary has to do with art? or what those two have to do with encoding things?

Well, take a look at the screenshot to the right. Notice anything... odd?

That's right! its a curses/log-friendly scheme for terminal block art. its only 3 shades but its 9x more efficient than text art.  The catch is: it can only output chunks of pixels 9 characters wide, and 1 character high. 

However, an automated, pygame-based conversion tool has been added to the newly created gfxcon.py utility.


To learn more, see: ternary-packed-art documentation on GitHub.

Gen 2 update: pygame frontend

Overview

SBTCVM, for the longest time, used pygame for its frontend.  From the first prototype, all the way to Gen 1's last major version: SBTCVM Mark 2

Gen 2, however, has taken a more flexible approach. Already having a curses frontend, with a second, tk-based, frontend in planning.

Now, pygame has returned with the recent completion of the TTY emulation, and the basic structure of the pygame frontend's code.

PYG_SBTCVM.py SBTCVM's Pygame frontend.

UI

Its UI is sparse, similar to other VM's and emulators with an SDL-based display, i.e. DOSBox.

In the window title, we see that 3 eared mascot again *1, along with the trom name, and of course, "SBTCVM Gen2-9".

At the moment, only SBTGA v2 mode 0 is supported. If your wondering what that is, its the same TTY the curses frontend emulates.  

When SBTGA does start getting implemented though, expect the window to adjust its size periodically.

Footnotes:

1. You can find that icon, in its assorted sizes in VMSYSTEM/GFX

SSTNPL: tables and iterators

SSTNPL is already a handy language for basic mathematics, and with these 2 new features, it just got a whole lot more capable.

Tables:

SSTNPL now features a 2-axis static-size table system with data read-write.
The actual algorithms used are based on work of a nifty new SSTNPL-based maze engine now available in 'APPS' directory in SBTCVM Gen 2's repository.

• read and write values with ease. (especially when paired with the other new SSTNPL feature mentioned below.)
• special macro read instructions for printing characters, ternary and decimal values.
• both raw-string and general data value table rows.

https://github.com/SBTCVM/SBTCVM-Gen2-9/blob/master/textdocs/SSTNPL/tables.txt

Iterators:

two handy iterator instructions. The main inspiration here is wanting an easy way to work with the new tables linearly, without winding up with insanely complex iterator code like what happened with that maze engine i mentioned above.

uiter & diter can iterate over a given range of integers (uiter going up from start to end,  and diter going down from start to end)

https://github.com/SBTCVM/SBTCVM-Gen2-9/blob/master/textdocs/SSTNPL/iterate.txt

Gen 2 update: stacks n keyboards.

SBTCVM's CPU makes some progress, as the cpu is now equipped with a whopping 2 stacks. 

Along with the cpu, SBTCVM Gen 2-9 is now capable of interactive programs, thanks to a new TTY Input device, that allows for a basic serial text interface.

Aside from the usual assembly enhancements, SSTNPL has gotten its share of changes too:

•  you can now create variables based on character code values.
•  you can read from the tty input buffer into a variable for easy parsing of keystrokes.
• return is now stackable.
• separate subroutine gotos are required to use return.
• conditional returns are now available.

SSTNPL

SBTCVM for the longest time, only had one programming language: SBTCVM Assembly. However, with Gen 2, that's going to change. In fact, it already has.

Presenting SSTNPL:

SBTCVM Simplified Ternary Numeric Programming Language.

Overall SSTNPL isn't ultra-high-level. For example: it supports in-line assembler and its loop and branching capacity is provided by several goto instructions. 

Yea i know, the 'dreaded' goto. But SSTNPL isn't meant to be super abstracted. Its mainly meant as a lower-level language, that abstracts much of the VM's more detailed behaviors, while letting people experiment with them if they wish, and aren't ready to tackle the assembler head-on. It can also be handy for quick math algorithms.

Features:

• built upon a named-integer variable system
• both static, and equals, greater, and less than gotos. (goto, if, ifmore, ifless)
• addresses and memory are handled automatically, using the assembler's builtin variable system.
• simple, easy to follow, syntax.
• quick formatting commands like 'space' and 'newline' paired with the new print, and dumpd/dumpt integer dump commands, make outputting algorithm results a breeze. 

For more information, check out the included example *.stnp programs and the shiny new stnpcom.py compiler, in SBTCVM gen2-9's repository:
https://github.com/SBTCVM/SBTCVM-Gen2-9

Gen 2 update: 3 new additions to the assembler.

The assembler has grown a bit. Specifically, it has a header variable system, the new nsp framework, as well as the new xas framework. So... Whats all that mean?

Header Variables.

source files traditionally had no say in how they were assembled in the past, thats where header variables come in. What they do does vary, however:
assembler mode

head-mode=trom, head-mode=vars

head-mode refers to the mode of the assembler. currently there are two possible values:

• trom: normal assembly (this mode will be chosen if head-mode is omitted.)
• vars: don't assemble a trom, but do handle nsp if enabled. (nsp is explained later in this post.)

Rom Name

head-rname=<rom name>: override the trom output name. (excluding extension)

SBTCVM Assembly Namespace (.nsp) files:

.nsp files allow you to use the namespace variables from one assembler source file (.tasm file) in another. here are the needed header variables to use them.

head-nspout=1: enables .nsp output for that source file. (excludes variables from other nsp files, as well as any builtin variables.

head-nspname=<nsp name>: override the nsp output name. (excluding extension)

head-nspin=<nsp name>: Import an nsp into an assembler file's namespace. you can use this namespace variable multiple times to import multiple .nsp files.

If all this .nsp nonsense sounds complicated, rest assured that one of its main purposes is to make some things easier.

SBTCVM Assembly Script (XAS)

XAS is an assembly automation script system, that makes multi-source-file projects easy to assemble.

Its main purpose isn't so very useful yet, but once Gen 2 gets a bit further along, its going to come in very handy.

Currently it has 4 commands:

• asm: takes name of tasm source file as argument. same as g2asm.py [source file]
• print: print argument to standard output.
• xas: run a xas script from within another xas script. takes script name as argument.
• exit: exit. takes no arguments

to run a XAS script, just pass it as an argument to the assembler just like you would a .tasm file.

SBTCVM Gen 2-9 repository:
https://github.com/SBTCVM/SBTCVM-Gen2-9

tutorials: balanced ternary basics

If you happened across SBTCVM and/or Balanced Ternary someplace, and you are wondering what the heck a trit or tryte is, you are at the right place.

Lets start with the very basics:

balanced ternary, like regular ternary (base 3), has 3 digits.

Several notations exist for balanced ternary. the one you use often is best chosen for the circumstance. For example: +0- is supported by all versions of SBTCVM, while p0n is only supported by the newer SBTCVM Gen 2-9 VM, thats still in development. 
Here is the number '8' in a few forms of balanced ternary notation:
+0-
p0n

• Positive: (+,p) your familiar positive digit.
• Ground: (0) ground, or zero, is in the middle. but that's not even the most confusing bit.
• Negative: (-,n) this is the curve ball, and why 2 in balanced ternary is '+-'

still dont get it? lets count from -4 to +4

-- (nn) -4
-0 (n0) -3
-+ (np) -2
0- (0n) -1
00 (00)  0
0+ (0p)  1
+- (pn)  2
+0 (p0)  3
++ (pp)  4

here are some key terms:

• trit: a balanced ternary digit
• tryte: 6 balanced ternary digits

 Special note: 1093 is based on the MPI of 7 trits.

• KiloTryte (KT): 1093 trytes.
• Kilotrit (Kt): 1093 trits.

 Helpful equations. (SBTCVM's libbaltcalc has functions for these)

• MPI: Max positive integer: maximum positive value a length of trits can represent. ((3^n)-1)/2=MPI where n=length of trits
• MNI: Max negative integer: lowest value a length of trits can represent. is the opposite of MPI. 
• MCV: Max combinations value: number of combinations in a length of trits. 3^n=MCV where n=length of trits

why is MPI, MNI, and MCV, relevant now?

 Well. thats a good question! this brings me to another point:

Balanced ternary, like other balanced base numbers, have many subtle differences form bases like binary and decimal. for example: lets compare 8 trits & 8 bits
    8 trits | 8 bits
MPI: 3280   | 255
MCV: 6561   | 256

Aside from balanced ternary knocking binary out of the park numerically, notice how with binary, the MPI and MCV equivalents are only 1 off, while in balanced ternary its 3281 off. why is this? 

ok but why are MPI and MCV so different?

well. balanced ternary, like other balanced base numbers, is inherently signed. lets look at the combinations of 1 trit:

- (n) accounts for one MPI
0 (0) zero accounts for 1
+ (p) accounts for one MPI

this can be summed up into this formula:

n=length of trits
x=MPI(n)
y=MCV(n)

and then:
x+1+x=y

i.e.

x=MPI(3)=13
y=MCV(3)=27
x+1+x=y
13+1+13=y=27
 

Gen 2 update: a look at the new assembler.

SBTCVM's assembler has been with it for a long time. Since the prototype era actually. Gen 2's ground-up rebuild of the VM also brings a similar treatment to good old SBTCVM tasm.

Syntax checks:

no less than 2 syntax check passes and 1 validation pass before writing to a trom file, along with a new trom format, ensure problems with corrupt roms are unheard of in Gen 2. saving coders time and energy.

simple numeric data tweaks:
first, decimal support has been added:

setreg1;10x32
setreg1;10x-12

second, ternary support has been overhauled:

two representations are supported:
+0-
p0n

Also, ternary values can be any arbitrary length from 1 to 9 trits.


Unified namespace:

the goto reference label, iobus address macro, and other namespaces accessed via '>' have been merged into a singular namespace, with custom variable support:

the v> prefix keyword supports all the numeric representations supported by most keywords:
v>myvar;10x1
They can even point to namespace entries to duplicate their value.
v>myvar2;>myvar

normal keywords can do this too:
setreg1;>myvar

dual data ahoy: 

Gen 2's new dual-packing concepts and the mirrored data/instruction size have been complimented by a new raw instruction:
raw;10x56,pn00pn'

They, of course, can be mixed numeric syntaxes.

Overall: 
This rock solid, modular, base of features will prove to be very useful in the coming months, as the Gen 2 instruction set and CPU development enter full swing.

Gen 1: a retrospective

SBTCVM. Its hard to believe that mark 2 was first committed to GitHub over a year ago, but its true. In fact, SBTCVM has been in development for over 2 years. So, in light of Gen 1's codebase being retired, lets take a look at its history.


Just a quick look at Wikipedia.
The origin of mark 2 actually traces back to me going to look up something on Wikipedia, and getting lost in the maze of related articles until i stumbled across "balanced ternary".

calculations operational, sir.
On June 3rd 2016, A curious little python program poped up on github.
Its name, was BalTCalc of course. and as you might guess, its a calculator, that works in balanced ternary. This calculator needed some backend code, so i wrote libbaltcalc to go along with it. Little did i know, that one library would lead me to starting a certain project.

Demo ahoy!
September 24th 2016. I had been coding away at a rather alien project for myself, a virtual computer of sorts. TDA was just as its acronym suggests, Ternary, and a Demonstration of a computer Architecture. The code was buggy, slow, and didn't even have memory writes. but It did one thing: Show that i actually could simulate a balanced ternary computer in python, and prove libbaltcalc was indeed capable of such. Its worth noting, that what is now SBTCVM's assembler was begun partway through TDA's development because of me growing sick and tired of base 3 machine code programming.

Specs:
x6 729 word (6trit) memory banks (roughly 4KT)
x1 729 word IObus
4trit instruction set

SBTCVM is born
March 9th, 2017. SBTCVM Mark 1.1 didn't change too much of TDA's code, but it did have some important improvements, most notably address calculation in SBTCVM's assembler. Mark 1.1 was also a stepping stone for a much more capable VM.

19,683. 
March 17, 2017. SBTCVM Mark 2 makes its presence known.
with a whopping 162 KT of combined memory. (108KT of unbroken trytes) Mark 2 is vastly superior to the Mark 1.x machines, and a worthy holder of Gen 1's final form. It introduced features that made SBTCVM vastly more useful in studying balanced ternary computing.

For one, it was the first to include a graphical calculator, the first to include framebuffered graphics, and even the first to reproduce digital sampled audio. Mark 2's set of utilities did balloon out of control in hindsight, but now we know better what tools are actually needed. and what aren't. the calculator is always handy for a quick bit of calculation after all. and yes i still have 19,683 stuck in my head. :)

Specs:
162 KT of combined memory. (108KT of unbroken trytes)
27 KT of memory per bank (18KT of unbroken trytes per bank)
6 memory banks
1-trit mono and 3-trit RGB framebuffer graphics at 114x81 and 54x38
2 text modes
1-trit digital samples at 2 and 4 KHZ
3 voice square wave sound chip
hardware-thread-based multitasking
various conversion tools relating to the internal data formats.

In conclusion: 
I hope you enjoyed that short look back on SBTCVM's first generation codebase, as the SBTCVM project moves on to bigger and better things. 

SBTCVM Gen 2: on the road to alpha.

End of an era:
SBTCVM Mark 2 has been been in development for a while, and while Mark 2 has served the project well, and has taught the dev team some important things, its come to the point where Mark 2 has become too complex under the hood to make the jump to python 3 reasonably, and continue development in a orderly fashion.

Its with this, that I announce the official end-of-development for SBTCVM Mark 2, and its underlying "gen 1" codebase. Its replacement is currently being developed.

The future:
SBTCVM Generation 2 is slated to drasticly change not only how the VM works under the hood, and how its CPU works, but also how its used. With advanced features like SBTVDI, a virtual disk system and psudo-filesystem implementation that will work in tandem with a new subproject: SBTCVM DOS.

Some other features being explored are more advanced sound (like the digital sample system that was added to Mark 2 at the last minute), more interactive vm programs, and less cluttered, streamlined user interfaces. Thanks to the new modular codebase, plans exist for terminal-only, pygame, and a TK version when time allows. with the terminal version slated to be a subset of the more fleshed out TK and pygame versions.

Gen 2 is currently VERY early in development, so again, its hard to say what the exact details will be, or when it will be announced. That said, a "gen 2" status page can now be found on the blog (see the link bar above), and blog updates will be posted on major developments.

Documentation: new and improved helpview.

Helpview. v2.0.3's fast and easy help system just got a bit more helpful with a new search feature & glossary.

The search feature is accessed by entering keywords (separated by spaces) into the search box in the hud, then clicking the "search" button.

Helpview will search its pages and present a list of matching pages, and the number of matches on each.

But what about the glossary? well, you can read through it like a normal page, but you will probably find the integrated glossary results included in the search feature to be much more helpful.

Utilities - New Development aids: GUIasm & memory map views

GUIasm

For the longest time, the only way to run the assembler was by typing in a string of commands into a terminal.

Now when you open tasm files in fileview2 and fileman in run mode, GUIasm will open up and easily allow for repeat assembling with a mouse click, an automatically opening a log of assembler output upon errors. It can also be run from codeview as well.

Codeview enhancement: memory view.

When Opening troms and .dmp memory and iobus dumps in codeview, users will see a handy new memory view.

This view can be scrolled independently from the main view with w & s (or e & d for faster scrolling), or by scrolling over it with the mouse wheel. It even highlights faulty trits in red for easily knowing when somethings not quite right.