BASIC816 Update and a Request for Feedback

Description of your first forum.
Post Reply
User avatar
Posts: 43
Joined: Wed Apr 24, 2019 12:44 am

BASIC816 Update and a Request for Feedback

Post by PJW » Sun Sep 01, 2019 8:26 pm

I wanted to give a little update on the state of BASIC816 for the C256 and to present a proposal on how it might connect to machine language code so I can get your feedback.

I haven't posted any videos about BASIC lately, mainly because nothing has really been video worthy there. I've been doing a lot of stuff on the internals that don't really show for now but which will be necessary later (for instance changing how the interpreter allocates variables and adding a garbage collector). Arrays are the new big addition to the interpreter at this point.

My next goal is to add some simple file commands (LOAD, DIR, and SAVE), and then I hope it will be ready to bring up on the RevC board.

Once the RevC board is out, that is when I will start adding more features to the language: floating point math, structured statements, and some graphics and maybe sound commands. One of the things I'd like to add at that point is a mechanism for extending the language, so I wanted to write down a little proposal for how I think that could work. I would love to get feedback or questions on the mechanism. You should take the following as tentative at best.

BASIC816 Accessing Assembly Code

There will be two approaches to access machine code from BASIC. The first is a simple method to call out to an assembly language routine in any section of the system's memory. The other is a method for extending BASIC's set of statements, functions, and commands using custom machine code.

With both methods of providing machine code, the machine code to run might have a need to use some of BASIC816's internal routines to communicate with BASIC itself or with the BASIC program that is running. BASIC816 will provide a jump table to access critical subroutines. For example, if an extension needs to evaluate an expression to provide a parameter to a statement, it could call the EVALEXPR subroutine through the jump table. This jump table might be useful for other purposes as well, like running the BASIC interpreter within a windowing GUI.

The CALL Statement

Code: Select all

CALL <address> [, <A register> [, <X register> [, <Y register>]]]
The CALL statement performs a JSL instruction to the address provided to execute the machine code at that location. The machine code can return to the BASIC program by executing an RTL instruction.

The program may optionally provide values for the A, X, and Y registers. If the program wants to provide a value for X, a value for A must be provided. Likewise, if a value for Y is provided, values for A and X must be provided as well. The registers will be treated as 16-bit registers, so values may be provided up to 16-bits in width. If a value wider than 16 bits is provided, only the least significant 16 bits will be used.

No value is returned by the CALL statement.

Extension Framework

For more complex integration of machine language and BASIC, the interpreter will allow for the program to load a binary file containing code for extending the commands, statements, and functions of the interpreter. An extension may be loaded with the statement:

Code: Select all

Executing this statement will load the extension file off the storage device, given its path. The statement will also implicitly execute a CLR statement, removing all variable definitions and heap storage objects. The reason for this is that the extensions will be loaded into what would be the top of the heap, and the heap will need to be moved down to accommodate the extension. Therefore, if a program needs to use an extension, the first thing it should do is to load the extension.

Note that multiple extensions can be loaded at one time. The interpreter will assign an extension token sequence to each keyword defined by the extensions. Since multiple extensions can be used, the token sequence can vary from program to program. That means that if an extension provides a statement PLAY, it might have the token $F1 in one program, but in another program, it might have the token $F8.

Coding an Extension

An extension will be a binary file on a storage device (SD Card, floppy disk, hard drive). Each extension will be loaded into its own memory bank of 64KB. The extension will have free use of all memory within that bank for whatever purpose it desires. The beginning of that memory bank must be laid out in a particular structure, however (see below). While the extension will always be loaded so that the first byte of the file corresponds to the first byte of the bank, the particular bank the extension will be loaded into will be determined at run-time by the interpreter. The memory size of the computer and the load order of other extensions the program may use can affect the particular bank used. All addresses used by the extension for accessing its own memory should therefore be 16-bit addresses (e.g. bank relative, PC relative, etc.).

Format (Tentative!)

The following is a simple map of the first section of an extension, starting with byte 0. I've written it in a pseudo-C notation that allows for variable sized arrays within the structure.

Code: Select all

struct {
    char magic[3];              // A three-character magic code indicating this is an extension
    uint8_t version;            // A single byte version code for the extension format
    uint16_t init_ptr;          // A 16-bit offset to any initialization code (0 if none)
    struct {
        uint8_t type;           // A byte indicating the type of the token (statement, comment, function, operator, punctuation)
        uint8_t precedence;	// A byte indicating the precedence (if token is an operator)
        uint16_t name_ptr;      // A 16-bit offset to an ASCIIZ string for the keyword of the token
        uint16_t exec_ptr;      // A 16-bit offset to the code to call to evaluate the token
    } tokens[];
    uint8_t eot;                // Always equal to $FF
    uint8_t code[];             // The code for the extension
The first three bytes are the required magic number (TBD), identifying the file as a BASIC816 extension. The fourth byte is a binary version number. It will be $00 for the first version. If there are any changes to the extension layout, they can be flagged here.

Next comes an offset pointer (16-bits) to an initialization routine that will be called when the extension has been loaded but before the EXTENSION statement completes execution. This can be used for any sort of set up housekeeping the extension needs to do. If there is nothing to do here, the offset should be set to $0000.

Next comes a token record, one per keyword provided by the extension. The record contains a byte indicating what type of keyword is being defined (statement, function, command, operator, or even punctuation). The next byte indicates the evaluation precedence (relevant for operators). Then there is a 16-bit offset pointer to the name of the keyword (an upper-case ASCIIZ string). Then there is a 16-bit offset pointer to the code to execute when executing the keyword. The subroutine at that location should return with an RTL instruction.

After all the token records have been provided, the next byte should be $FF to indicate there are no more records to process. All other bytes in the file after that point are left for the extension's use. They may be arranged however the extension author desires.
Posts: 3
Joined: Sat Aug 31, 2019 11:24 am

Re: BASIC816 Update and a Request for Feedback

Post by Antoon » Mon Sep 02, 2019 7:13 am

Hi, just joined the C256 project a few days ago. Would like to make a contribution, e.g. helping with coding the BASIC interpreter.

What's the best way for me to get started? Total newbie here, but I do know about 6052 assembly programming.

Kind Regards, Antoon
User avatar
Posts: 43
Joined: Wed Apr 24, 2019 12:44 am

Re: BASIC816 Update and a Request for Feedback

Post by PJW » Mon Sep 02, 2019 3:07 pm

Main thing I would suggest at the moment is to pick up a copy of the emulator/IDE and your development system of choice (I am using 64TASS) and start familiarizing yourself with the system. As for BASIC, I'm keeping that closed for the moment. I do intend to open the source code up before very much longer, but I still need to figure out what license I want to put on it. Also, my intention was to get the core of it working on the RevC board first. Once it's kind-of-sort-of working there, I'll be more comfortable with having others getting into the code and telling me all the stupid things I did. :D

Some other areas where I think contributions will be needed (and maybe Stefany will come along and correct me or add to this):
  • File system---Currently, the SD card is managed by a chip that provides the FAT32 support, but only for the SD card. There's been work done on a floppy disk interface (FAT12, I think), but the RevC board will also have an IDE interface that will need file system support.
  • Kernel development---once the RevC board is out, I think there will be more focus on developing the kernel. Currently it's quite basic, initializing the settings and providing some essential functions (e.g. printing to the screen). It will need someone to give it some love and pull it all together. As an example, referring back to the file system point, there are stubs for file I/O in the kernel, but there isn't anything behind them. So there is no one call to read from a file regardless of where it's stored. That will need to be implemented at some point.
  • Demos and games---The system (especially the FMX version) is going to have fantastic graphics and sound capabilities. Demos... especially ones that can be used as samples or tutorials... would be very handy. Right now, there are only a handful of people with the actual board (well, the RevB), so if someone has a question about how to set up sprites, for instance, there are only a couple of people who can answer that. As more people find out about and get interested in the C256, there will need to be sample code to show people how to do stuff.
These are just a couple of things off the top of my head.
Post Reply