I wish I knew me some J … I bet it could give your APL a tight race.
I have just found the forum and the challenge this week and thought it would be a nice puzzle to see how much BASIC I remember. However, on the “machine” of choice (Sharp PC-1246) there is one significant limitation: the display consists of one line of 16 characters. However, the CE-125 printer has 24 columns so that might work.
But! It’s not that easy, since one LPRINT statement results in one line on paper (it’s not possible to finish with ; and continue the line with another statement). Well, the computer has string variables, I could build a string… No, strings are limited to 8 characters at most! Luckily, one can LPRINT multiple string variables on the same line.
Thus, the following contraption was born: a routine that takes an argument X and builds 4 string variables (imaginatively named A$ to D$) that are LPRINTed with a star in the middle, like so:
LPRINT A$;B$;“*”;C$;D$
The argument represents the number of stars on the left side of the center column, taking advantage of the fact that this healthy tree is symmetric ![]()
Lovely! I did wonder about bringing this challenge to the HP calculator community - there too, printer output would probably be the way to do it.
There were at least two video options for hp-il, as well.
There should be an equivalent challenge for hardware guys as well. Instead of simplest solution, it should be the most elaborate, but actually implemented, hardware. Maybe next year.
Thank you for the image of the print out, this triggered some memories, like instantly.
Nearly a year late but this is a MINT program of 132 characters running on a Z80 RC2014 with serial output to Teraterm.
Not quite as tight as Michael Barry’s excellent 6502 assembly language version, but actually fewer characters to enter. MINT is a 16-bit integer, interpreted, stack-based language loosely based on a very cut down Forth.
:S(32\E);
:P(42\E)M;
:A29S1P;
:B16S3P;
:C15S5P;
:D14S7P;
:G12S11P;
:H10S15P;
:K9S17P;
:L6S23P;
:M\N12S;
:ZABCDBDGHCGKLBB;
Every MINT statement starts with a colon followed by a single uppercase letter to identify it. A semicolon and CRLF terminates the statement.
MINT code is very terse and needs no whitespace to separate function calls. Most humans will include these spaces (and comments) to make it more readable.
S emits a space ascii 32 in decimal
P emits an asterix ascii 42.
However the function within S is contained within parentheses, so this will form a loop if preceded by a decimal number.
The function identified by P is also within parentheses and can also be looped in the same manner.
Each line of the tree printout is assigned an identifier A to L. Some lines are duplicates so do not need to be redefined.
Looking at the largest line L, this is 6 spaces followed by 23 asterisks.
The P definition also includes tailend M, which sends a newline character \N and then indents the next line by a fixed amount of 12 spaces.
Finally Z puts the whole construct together.
Hitting Z will print as many trees as you wish.
The MINT interpreter on the Z80 is approximately 1700 bytes long.
Nice! I don’t recall ever hearing of MINT before, but I find its terseness to be oddly satisfying. An “algorithmic” VTL-2 version weighs in at 214 bytes, and its interpreter/IDE is typically lighter than 1KB:
Stock VTL-2 can only loop with the equivalent of a conditional GOTO, and VTL-2 makes no distinction between a simple branch and a subroutine call, so subroutines that loop require some manual housekeeping for the return address.
The “table driven” version clocks in a bit lighter, at 184 bytes:
VTL-2 doesn’t have a DATA or a READ statement, but out-of-bounds array accesses are legal (actually anything is legal in VTL-2) and can be used to peek into the program text if done carefully. Also, this method is not portable between big-endian and little-endian hosts without slight modification (this example is little-endian). An either-endian version is only one byte larger, but I’ll leave that as an exercise for the reader …
Michael,
MINT only appeared this time last year - that’s probably why you haven’t heard of it!
It’s possibly best decribed as the Tiny Basic equivalent of Forth. All primitives, functions and variables are single ascii characters, making the language very terse.
It was inspired by Peter Grogono’s MOUSE language, and also a tiny Forth called STABLE, written in 60 lines of C, by Sandor Schneider of Hungary.
It has all the usual arithmetic and logic operators, stack operations, loops, arrays, strings and decimal/hex input output routines.
It is entirely interpreted, there is no dictionary and no parsing of multi-character words. Like Forth, it has a data stack and a return stack.
It relies on an ascii character input into a look-up table that provides a jump address to the function. The look-up table is only 8-bits which avoids the overhead of 16-bit look up, on an 8-bit micro.
The idea was to write a minimal interpreter (m-int) which could be easily ported to any of the classic, resource limited, 8-bit microprocessors. All that is needed is serial I/O, either by UART or bit-banged.
Once a micro has a MINT interpreter, source code should be 100% portable between different systems.
So far we have Z80 and are working on 6502, 6800 and 1802.
On the Z80, the interpreter is just under 1700 bytes.
MINT is a joint project beween John Hardy, Craig Jones and myself.
There is a github repository GitHub - orgMINT/MINT
MINT sounds great @monsonite !
Ed,
When we first met in Cambridge in 2017, I had the first thoughts of a lightweight language that would provide a minimal layer of support infrastructure for programming resource limited devices.
In 2020 I met some like minded people and we collaborated to create MINT - a minimal interpreter. Our first version for the Z80 came alive almost exactly a year ago.
I was inspired by the OPC project, and I thought about a simple interpreter that was 1 level above raw machine code. If it can be done for the Z80 it can be done for any other machine.
Forth is cool, but who wants to type in 6K or 8K bytes of asm code for a new processor?
MINT provides a workable environment, in about a quarter of the code size.
The first step was to get it running on the Z80, but we are making good progress on other classic processors, 6800, 6502, 1802 - generally using the asm80.com tool.
Our goals are brevity, simplicity and portability. Any cpu with a MINT interpreter will produce the same output for a MINT source code routine. If I can print a Christmas tree in 132 bytes of source code, imagine what could be done with a 160 character SMS, between 2 totally disparate systems, that only share a MINT interpreter?
This month we are thinking about an even smaller version of MINT that just implements a 16-bit VM with a human readable, bytecode language, in keeping with the OPC project. We might even get it down to just 1K bytes of code, on par with VTL-02.
MINT is a simple lightweight tool to assist in the exploration of unfamilliar machines.





