SBTCVM's SSTNPL Part 2: cards on the table
Tags: sbtcvm, ternary, sstnpl, tutorial
Published: 2018-10-19 01:34:46

---
title: SBTCVM's SSTNPL Part 2: cards on the table
published: true
description: Part 2 on a tutorial series on SSTNPL, a ternary programming language for the balanced ternary VM, SBTCVM.
tags: sbtcvm,ternary,sstnpl,tutorial
---

Welcome back to part 2 of my tutorial series on SSTNPL, a programming language for the 9-trit balanced ternary Virtual machine known as SBTCVM. In [part 1](https://dev.to/thomasthespacefox/sbtcvms-sstnpl-part-1-basics-3a7h), we discussed basic menus and did some basic variable setting.

In this part, we will take a look at how to work with SSTNPL's tables, and look at how they can be quite useful.

# Getting started

like before, copy the tutorial_example_2.stnp file into your VMUSER directory located where you installed SBTCVM.


Now, you may be asking, whats a table in SSTNPL? to put it simply a table is a 2D array of 'cells' that can be accessed via x and y coordinates.

{% gist https://gist.github.com/ThomasTheSpaceFox/d095563edb8340d2793e361842905e69 %}

# the 3 table types:
- **self-printing single-cell** (name in example: **sam**, labeled: 'prline-based')
- **basic single-cell** (name in example: **sam2**, labeled: 'tstr-based')
- **double-cell** (name in example: **bob**, labeled: 'Double-cell table')

you will see at the top, both single-cell types are within subroutines, but only the self-printing table actually prints itself, while the other doesn't do much of anything. 

table structure:
```
table name,[width],[height]
tstr abcx
tdat @1;@2;@3;@4
prline ABC
```

Note that self-printing tables need to be specified as 1 column wider than they appear, due to `prline` always appending a newline. (That's why they print correctly formatted.) (notice that `prline` has 3 characters visible, while `tstr` and `tdat` have 4 values shown.)

All three of these are technically the same type, and aside from the double-cell tables having an extra value in each cell, there's not much difference.

# Reading and writing tables:
looking at the section commented with the same name, we see tabr, tabw and tabcd all referencing our self-printing single-cell table 'sam', and making liberal use of decimal and character literals, of which part 1 discusses in more detail.

tabr, tabdd, and tabcd's arguments:
```
tabr table,x,y
tabcd table,x,y
tabdd table,x,y
```

looking at the code, we see 0,0 is our x,y location, and that the coordinates start at 0,0. `tabr` is a basic read operation, while `tabdd` and `tabcd` print the read value as decimal or a character respectively, but still provide the value to our old friend `set`.

tabw's arguments are similar:
```
tabw table,x,y,value
```
the only difference is `value`, yet another variable, that contains the value we wish to write to the given table coordinates. or we could just throw a literal at it and call it a day.

# working with double-cell tables:
As we delve into our third and final table type, i must first explain the warning at the top of the associated code section: the second value is stored in the instruction word, that means, anything put there can cause any opcodes that happen to match to be triggered, if the CPU tries to execute it.

The table itself, *bob*, uses tdat, which has 2 modes:

singe-cell mode:
```
tdat @1;@2;@3
```
double-cell mode:
```
tdat @1 :a;@2 :b;@3 :c
```

A few things to note here:
- Do not place semicolons at either end!
- DO NOT try to use integer variables. the tables are statically compiled, and REQUIRE use of any of the 3 literal types (decimal, ternary, and character).
- the left value in tdat double-cell mode is accessed using the methods below, while the right value is accessed like in any of the other table types.

### reading the extra value.

as you might deduce, reading the extra value is as simple as suffixing the tab* operations with '2':
```
tabr2 table,x,y
tabw2 table,x,y,value
tabcd2 table,x,y
```
As you can see, syntax is identical, and its fairly simple to actually use.

# Compiling & running
just as in part 1:

compile: `./stnpcom.py tutorial_example_2`

run: `/SBTCVM_G2_9.py tutorial_example_2`

# so how are tables useful in SSTNPL? How did they come about?

Well, the whole table system was inspired by the data lookup algorithm of a prototype of a [maze engine](https://github.com/SBTCVM/SBTCVM-Gen2-9/blob/master/apps/maze/auto_main.stnp) i wrote in SSTNPL (that actually works by the way), and so far has gone on to power [a card-matching game](https://github.com/SBTCVM/SBTCVM-Gen2-9/blob/master/apps/match/auto_main.stnp).

As far as what could be done with them, that's a question only time, and a bit of experimentation, will really answer.

# Where can i read more?
well you can find SSTNPL's full documentation [here](https://github.com/SBTCVM/SBTCVM-Gen2-9/tree/master/textdocs/SSTNPL)

# Whats next?
In part 3, we will look at how SSTNPL's single and double iterators work, and how they can be used to iterate over tables, and even help populate them.