One kilobyte Tiny BASIC for the 8080 and Z80

The Z80 version is now ready to be tested. Programs can be pasted directly into the console window of Altair32, which makes testing easier. There are currently 34 bytes free in the Z80 version. Here’s a screenshot of what it looks like running on Altair32 (with the CPU option set to Z80).

Now that I’m working on a Z80 version, I need to find a suitable Z80 emulator to run it on. For the 8080 version I used my own emu8080.py emulator, which I had tested using a range of 8080 test suites. I was also able to run it on Stefan Tramm’s 8080 emulator.

I tried running the Z80 version on Sydney Smith’s Z80 emulator, which is derived from Stefan Tramm’s, but it seemed to me that JR NZ didn’t work correctly. So I searched for other emulators and hit on Altair32. This is an emulator that runs under Windows. It is self-contained and doesn’t need much installation. It supports both the 8080 and Z80, and is already configured to have console I/O on ports 0 and 1.

I’ve started work on a Z80 version. It will be at least 24 bytes shorter than the 8080 version due to the Z80s two-byte relative jump instructions. There will probably be a few other places where space can be saved due two differences between the 8080 and Z80. For example, the LDIR and LDDR instructions might end up making memory move subroutines that are shorter than the memory rotation subroutine used for program editing. 

It would be good to be able to implement PEEK, POKE, IN and OUT instructions. 17 bytes will be needed just for the keywords, and maybe 25 bytes to implement all of these, so it probably will be possible to fit them in.

I’ve made a change to the 8080 version so that it should also run on a Z80. In PrintSub I found a way to avoid using the parity bit without using any more space. This change is committed to GitHub, and when time permits I will rerun all tests and make release v1.0.1 with this fix.

The current version of 1K Tiny BASIC passes all tests and runs all example programs. I’ve released it in GitHub as v1.0.0

I was recently able to reclaim 2 bytes in the integer parsing subroutine. With these two bytes I’ve added support for colon as a statement separator. Multi-statement lines were already allowed with no separator between statements. Adding the optional colon makes this slightly more compatible with existing programs.

I’ve also added the file errorcodes.txt to the GitHub project, to explain the code and meaning of the 16 different error codes that can occur.

During testing I came across an error where -32768/2 was being interpreted as -(32768/2) rather than (-32768)/2. Since I had hit the 1K limit, some significant work was required to free up enough memory to fix this. The changes were:

• Make all calls to ExpEvaluateNum happen from pages 0,2 or 3, and place all operator subroutines on page 1. So that ‘empty operator stack’ can be detected using that distinction.
• Also place ABS, USR, RND on page 1, and all other token subroutines on page 2. This makes more space available for implementing token subroutines and reduces the out of page jumps required when all had to start in page 2.
• Change the way that end-of-TokenList is detected when searching for Tokens, saving 1 byte. This requires the last byte of  TokenList to be at address 03FFh. This fits in well with the other changes listed above.

These changes made it possible to effectively add a Negation operator and give it highest precedence.

Several bugs were introduced and subsequently fixed during the course of doing this.

During testing I came across an error where -32768/2 was being interpreted as -(32768/2) rather than (-32768)/2. Since I had hit the 1K limit, some significant work was required to free up enough memory to fix this. The changes were:

• Make all calls to ExpEvaluateNum happen from pages 0,2 or 3, and place all operator subroutines on page 1. So that ‘empty operator stack’ can be detected using that distinction.
• Also place ABS, USR, RND on page 1, and all other token subroutines on page 2. This makes more space available for implementing token subroutines and reduces the out of page jumps required when all had to start in page 2.
• Change the way that end-of-TokenList is detected when searching for Tokens, saving 1 byte. This requires the last byte of  TokenList to be at address 03FFh. This fits in well with the other changes listed above.

These changes made it possible to effectively add a Negation operator and give it highest precedence.

Several bugs were introduced and subsequently fixed during the course of doing this.

Since version 1.0 of the 8080 version is likely to be ready for release soon, I have been thinking about future avenues of work. The following things seem interesting to me at the present time:

1. A Z80 version. This will be smaller and faster than the 8080 version, primarily because the Z80 has 2-byte relative jump instructions. I think that this will save a few dozen bytes, which could be used to implement extra functionality and remain under 1K.
2. A minimalistic Z80 version. By removing FOR/NEXT and some other features, and changing how lines are stored in memory, the code size could be reduced by several hundred bytes. I’m interested in seeing whether I can get down below 512 bytes, since the current smallest minimalist BASIC (Oscar Toledo’s bootBASIC) is 512 bytes long.
3. A 6502 version. It is not likely that 1K Tiny BASIC will fit in 1K when ported to the 6502, but it will probably fit in less than 2K, and there is currently no other 6502 Tiny BASIC that fits in less than 2K.
4. Tiny BASIC with constant strings. By ‘constant strings’, I mean strings that are defined in the BASIC program code. They can be assigned to variables, be part of expressions involving comparison and substring operations, and printed, but new strings can’t be created at run time and there is no concatenation operator. No string memory management is needed, but lots of useful things can be done with constant strings. (Compared with most Tiny BASICs which usually only allow constant strings in PRINT statements).

I fixed the operator precedence issue, so that * and / have equal precedence. I also changed to using an LCG pseudo-random number generator because it was shorter. A consequence is that the RND function only uses the high order byte of the RNG state, because the low order bits have a small period. So RND should not be given a parameter larger than 256.

I fixed an issue with the expression evaluator where an incomplete expression would cause it to try to RET without a return address on the  stack. 

I’ve listed the meaning of all error codes in errorcodes.txt

The current version passes all tests and runs all example programs. If no other errors are found it will become version 1.0

I’ve also found a way of simulating keyboard input in Stefan Tramm’s emulator using a short JavaScript program that sends key events to the emulator - I’ll make this available when it’s finished. This will be a good way of scripting tests cases that test error handling and error codes.

I recently came across a nice online 8080 emulator written by Stefan Tramm on which I can run 1K Tiny BASIC. Up until now, I have only run it on my phone, on my own emulator written in python. It’s good to see it running on a different emulator. The emulator is here: https://st.sdf-eu.org/i8080/index.html

I could not get all of the features of this comprehensive emulator running in my browser, but I did find out how to load a hex file from my PC into the emulator by dragging and dropping into the browser window, then reading it with ‘r ptr:’

I need to make a change to 1K Tiny BASIC : currently I have used CR as newline, but this emulator requires the sequence CRLF. This change will cost 3 bytes.

Stefan Tramm has included a version of Palo Alto Tiny BASIC with his emulator.