Contents:

Project Spec.
22-Jul-2007
06-Sept-2007
03-Oct-2007 •

- Feedback on this blog
- TNTBasic homepage
- BLOG homepage
- E-mail the author

The planning is virtually done now and I'm getting ready to start on the first draft pseudo code for the engine. The project file format (v0.1) is defined and I will be publishing this on these pages as soon as I get a presentable version onto silicon, it's currently on several pieces of A4 scattered around an overly cluttered desk. The basic principle though is a two part file, with a header consisting of a series of vector tables followed by a single block of binary data. I am standardising all the project data down to single file types, not PICT and SND by the way, it's currently PNG for images (due to support for alpha channels) and WAV for sounds (as it's a very common format with lots of available content), and I'm rewriting the map data structure to extend its functionality.

One of the main reasons this project is taking so long is the need to generate a complete new compiler model. The 'compiled' output from the existing editor is of no use to me at all, just trying to decipher it took ages, and I decided to bite the bullet and start again. Trust me, this is no small task. The plan is to break the source down into single, usable functions supported by the engine, and assign each an OPCODE in much the same way as an assembler would (which is why I've been using the VM analogy). The engine then fires off the function by using pointers held in an array, with the OPCODE being the index. Data moves around via the use of pseudo registers, an internal stack and heap all maintained by the system, again strengthening the VM model. I've used assembler before, so thought that conversion from Basic Source code to usable byte code would be pretty straight forward, and to be fair it's not that tricky, the real pain is the lexical stuff! I'm really going back to school with the semantic and syntactic analysis. The requirement to use the existing syntax is also a burden, I don't know if you've even thought about it, but the language is a real mess, there are calls where the parameters are in brackets, others where there are no brackets, some where there are additional words in the argument list, and loads where the meaning of the call is purely dependant on the number and type of the arguments. All of this makes defining a parse state a bit of a hit and miss affair. I also want to enable the system to handle plug-in modules, and this obviously impacts on the parser engine. The solution I've come up with is a language database file and a simple pattern matching / string comp setup. Not exactly state of the art I know, but I'm extending this database to include syntax hints for auto complete, and contextual help data. As the user is typing the source code it allows me to throw up a list of options and also give the format of the parameter string and a general description. It also solved my "syntax for external modules" problem, so was quite a productive day's work all in all. The parser is one of those 'issues to iron out' I mentioned earlier, but it will get a lot easier when I get around to rewriting the editor.

Currently I'm working on the language database and parser back end. I need to be able to create a TNT2 project file from an existing tbproj file to progress further. I'm planning to generate an intermediate state using '4char' codes for the parser testing, I need an input file to throw at the engine as I develop it, but I need to know that the input file is correct so that I don't try and fix engine bugs that are actually parser bugs, and 4char seems to be the logical step. It would also allow another little thing I've been toying with, I've thought about allowing the user to actually edit the 4char. I know that manually optimising what is basically assembler source code is possibly a little extreme, but it does throw up some interesting posibilities if that assembler gives low level access to the workings of the engine, and could be embedded directly into the BASIC source.

This has been a really interesting time for me - I've been wrestling with Bakus-Naur (before realising that I didn't need it), reading the manuals for various parser grammar generators, reading theory on LALR - Parsing and generally immersing myself in the crazy world of techno babbling computer lingo. The upshot of all this? A serious headache and an urge to dabble in Photoshop for a while... Stress busting the graphic way. The upshot of 'that' though was quite beneficial, as you can see...

The First draft of the new TNT2 Logo (subject to change). I think it's kind of cool though...

Any road, back on the farm. I've had 'a few' kids around for the last six weeks and actual progress has been pretty slow, but the theory stuff (and general notes) have been coming along nicely. The main engine theory is decided, I know exactly how this thing will work, and if all goes according to plan then there should be minimal overhead and it should all run pretty damn quick. I've also done most of the leg work on the parser and it's pretty much sorted, on paper, but needs finalising, things that work on paper tend to screw up when applied to silicon. Give me a couple more days on this and I'll know a bit more... I've started work on the interface for the new editor (again as a distraction from real work) and this is coming along well. To be fair I've done this before, so it's sort of reworking stuff I've already got, I'm playing with the sprite editor at the moment and I've actually got a bit of functionality going on! It's in RB at the moment, it may stay that way or I might go for an XCode project later, to be decided...

To finish this admittedly brief update, I've done some basic functionality work, it's only quick, two line function stuff to do with maths and memory management, not terribly exciting but it needs to be done at some point. We will have the ability to play around with memory now (a real bugbear of mine for a while), we will be able to allocate space and get / set / alter its contents. This will be available in different data sizes as well, with the smallest being an 8 bit byte (but it may change to word for speed reasons). There are currently no plans to limit the number of memory blocks (as was the case with both AMOS and STOS), I'm just introducing a new variable type, 'pointer' (or 'ptr' for short). You declare a new pointer, just as you would a new integer or string, and you 'Reserve' some space for it (in words, or two bytes) with the 'Reserve As' call. You can then get and set the data using the traditional BASIC functions Peek / Poke, Deek / Doke and Leek / Loke. Yes, they're dumb arsed names, but computerese is full of them... Did you know for example that half a byte (or 4 bits) is called a 'nibble'? I rest my case.

I'm going to continue to play with this stuff over the next couple of weeks while I psyche myself up for my next big adventure... I'm going to tackle the graphics! Wish me luck...

'Till next time...

TNT2 is expected to reach a Pre-Alpha / Alpha build by December!

You know when you have one of those days when everything seems to fall into place? Well I've had a few of them recently, and progress is coming along in leaps and bounds. Now don't get too excited, the proposed build is basically a feasibility test of the final engine, a proof of theory build if you like. Let me explain, I came up with the idea of introducing some sort of 'pre-flighting' interface into the IDE, so rather than just syntax checking the code, it ran it, it allows interactive debugging and so on. In order to do this I'd need to implement a version of the engine in RB and bolt it in to the back of the editor, I'd already have the code and the resources sitting there so there would be no need to build an intermediate file, and I could get instant feedback on errors and such. So, my slightly dis-interested audience, this is what I've done. Because it is in RB I can test my ideas a lot faster than I could in XCode, as it removes most of the compile / link cycle and hides a lot of the behind the scenes, low level stuff that I would need to hard code in Obj-C. It also lets me do quick tests on the whole structure of the engine and the underlying theory behind it, I can put my theories to the test and make sure the concept is sound before moving on to the C engine to get the speed up to scratch. It has allowed me to change the way things work in both the editor and the engine at the same time, which is really speeding things along. If I need a slightly different storage method, or wish to introduce a new command type for instance (both of which have happened) I can modify both the IDE and runner code and instantly check the impact on the system without switching apps. It's been a real (excuse the pun) plus.

In a bit of 'Aagghhh! Get out of my head!' time, I've started work on the design of a TNT2 website. There's little benefit to this, it's just one of those things I do when the whole code / debug cycle starts to get me down. It has to be done at some point I suppose, so it's not a total waste of time. Just thought I'd let you know, future posts to this blog may well be at a different address.

So where is TNT2 right now? I currently have a semi functional IDE which allows the loading and editing (at least the source) of a .tbproj file bundle. The editor recognises TNT syntax through a TNT2 language database file which can be created and altered via a separate and fully functional utility. The composite binary file format that will be output by the BCC (Byte Code Compiler) is finalised, and the final BC Syntax is just about there (read: working but subject to change as compilation becomes more robust). The internals of the runner's VM are in place and coded, that is the registry handling, stack and heap manipulation and general house keeping code. Low level (type 1) calls, the generic BASIC syntax such as 'if' or 'repeat' for example, as well as basic math operations and assignments, are hardwired into the engine for speed. Some type 2 calls are coded (extended basic syntax), mainly bit and memory manipulation stuff, and the methods for passing data between the call and the VM are finalised and mostly in place (the conventions work for the calls which are currently implemented, but may need revision as the later types go in). All calls which implement a function of the language are of type void (return no value) and accept no parameters, this is to aid the development of future extensions. Parameters are passed via a set of pseudo registers, or through the internal stack and returns use the same convention or are passed back on the SCR (Status Code Register), dependant on the call's 'subType'. A full description of the internal syntax conventions is to be written to support the Language Editor Utility, and will include a full breakdown of my 'type' structure, the VM internals and my own TNT2BNF interpretation for argument lists and semantic rules.

And Finally...
I'm using RB 2007 Professional (R4, which was released on my birthday by the way, nice present!) which compiles to native code and is actually pretty quick... It also compiles to native Windoze and Linux... Oh, and it supports 3D through Messa (Open Source OpenGL libraries)... on all three platforms... And cross platform networking... Mmmm, I wonder?

Watch this space!