Time to reinvent TrueBASIC from scratch (this time using C++)

The True Basic libraries and indeed Big John's Editor are all written in the language itself.

I will quote from the book "Back to BASIC" (K&K) the basic design parameters for the language.

1. It should be easy to learn for the beginner.
2. It should be a general purpose language, allowing the writing of any program.
3. Advanced features had to be added so that, if there was a price, it was paid by the expert, not the novice.
4. It should take full advantage of the fact that the user could interact with the computer.
5. It should give error messages that were clear and friendly to the user.
6. It should give fast response for small programs.
7. No understanding of the hardware should be necessary.
8. It should shield the user from the operating system.


Perhaps this "quote" above should be the proper place to start, perhaps with the gut feel from other parts of the book "Back to BASIC" by K&K, and of course the ANSI standard BASIC definition; in comparison to the documented and actual TrueBASIC core system working now.

Very likely the original (now without source) TBSystem.exe was written in a pre C (maybe 'B') or assembly language (MASM)-(?) which for historical purposes would be nice to know, but which for practical software engineering purposes is completely irrelevant in a modern context. TrueBASIC is still 'needed' and would continue to be desirable in many modern environments for the same reasons today that were relevant in the late 50's and early 60's for the day and environment of K&K. We will build the new system using C++ (GCC, CLang) in an environment that from the beginning of the development outset will strive for platform independence as a key necessary must.

Tons of work ahead, but the quicker the sooner; if not now, when? -if not me, who else? This time, we develop for Mac OSX and Linux, and port to Windows when appropriate. A full CVS versioning repository for software development should be employed so that the new source remains secure into the future. Version 7 editor(s) and associated libraries could still be written in TrueBASIC with a specific bronze, silver, or gold specific to the platform of choice (linux, mac, windows, droid, etc) the value add coming from a team of experts developing "with" the language (for price or not) and the core coming from a team actually constructing the language itself, for K&K legacy far into the future, maybe GPLv3 sourced.

Oh, me? I worked with IBM for almost thirty years and was 'retired' at an early age, a staff software engineer working in the Linux system environment for internal tools for the last seven years. My position before that was software support for the (then) AS/400 compilers (RPG, COBOL, C,). I've been back at school, still play around with computers (large and tiny), and drive a school bus part-time. I got my start in computers on the Wang 700 series programmable calcs (ML), and the IBM 360-44 main-frame (FortranII); yes, we had real ASR-33 teletypes attached to that monster! Ironically my early personal computer history involved using the bastardized BASIC(s) of the TRS-80 I, Timex Sinclair, and Commodore VIC-20. At heart, its still BASIC that I find fun and interesting, and after all these years its still BASIC that I come back to time and time again.


PS I suspect this forum is dead; might need to do something about that too!


Re: Time to reinvent TrueBASIC from scratch

As long as someone is working on TB (You ARE, aren't you?) why not make it even more compatible with ANSI/ISO BASIC than it is now, while retaining the extra features it already has? What features? Real-time support and keyed sequential files come to mind to start with. And DEFINITELY lower the price! With all the low-cost or even free BASIC compilers available today, you'll be wasting your time if you keep it at the old prices.

TrueBasic in C++

Wrong number !!!

TB has great error checking, C++ has virtually none I have programmed in both languages.

C++ is faster in execution by about 2.5 times. C++ can also crash the computer many times during program development requiring reboot. C++ has no string variables: they are just another array. TB is significantly faster from problem initiation, coding, and result

A sterling case in point is an 39-body 3-D simulation of the solar system orbits using matrix arithmetic using 4-th order Runge-Kutta, including all major moons. I originally wrote the matrix solution to the differential equation set in 1983 in TB, just for my own curiosity. The core calculation code easily fits on one page. TB results agreed with NASA's results to 14-decimal places, after 100,000 years of simulation. Her is the core calculation TB code:

At an astronomy meeting over a year ago, I was approached by a math professor who proudly announced he had simulated the 3-body problem using a language called Maple, which was great for a math professor trying to teach the unwashed about differential equations. Maple is SLOW!!, being a multiple interpreted language.

Another member of our team used ForTran. His results did not agree with ours, principally because of number truncation from various precision conversions.

For end-to-end (problem to solution), True Basic is still my choice.

My ramblings

I always felt the Java Virtual Machine would be an excellent host for TrueBasic programs.

Some time ago I tried decoding the TRC format. I was able to write an interpreter for some very simple commands (in Java), but it was seriously time consuming and too many bytes in the format remained a complete mystery, including many bytes in the header. I found out the older compiler bundled with TB 6 generated much cleaner TRC files than the latest.

I still hope I'll make a breakthrough one day, but wouldn't hold my breath waiting for it.

I agree the best bet would probably wrote a new interpreter (or even better, a true compiler, LLVM would probably be an absolutely excellent choice) and "forget" about the existing system, TRC files, etc.. But who would like to invest so much time, energy and money in an age where super advanced programming languages are given away for free....

I wish TB could somehow obtain the rights for the "Back to BASICs" book. I really would love to read that book.


I am not a specialist in computer software, but an engineer who need simple tools to do calculations, graphics, drawings, input/outputs to command machines, data collection, automatic reports... TB allways was my favourite tool, after EXCEL. I know there are a lot of better alternatives, but I prefere to go deep into one (1) computer language (TB was the choice) than superficial in several ones.

Thank you for discussing this important subject in this forum,


Time to reinvent TrueBASIC from scratch

Mark Harris, I'm chiming in. Are you associated with True Basic Inc., or an angel interested party? I run production programs in True Basic 2.72 for Mac (in Classic on OS X 10.4 Tiger), and I would drool to get a version that runs in a current OS X even if only in the terminal (Unix) window.

Previous correspondence with True Basic Inc. indicates that they are not in a position to rebuild the TBsystem application, and so can't fix errors or add features, because they have misplaced their source code. (This is not unknown; Deneba lost Canvas 3.5 source code and had to issue an expiration fix as a hex edit.) So generating new source code is necessary, as is compiling to X86_64 for current/future versions of MacOS and Windows.

I don't love C++ but I'd be open to helping (if I'd be a help). Another thought might be to adapt the open-source Decimal Basic code, though it's in Pascal and has minor but significant differences from True Basic. True Basic 5 and later used a cross-platform programming platform, but it might be better to just use a common interpreter-execution module with separate GUI controls native to each platform. For example, Decimal Basic has a Mac version, but it doesn't take advantage of the native text or graphic frameworks, so it looks primitive.

Yes, excellent to see new life in this long-time moribund forum.

To clarify, update on the 'official' TB position

I wanted to add that we (TB official) do actually have the source code; what has been lost to time and transitions is the detailed documentation for the source and how it's structured. In the meantime, we've done what we can with limited resources to update and package the software to operate on modern platforms as much as possible, and remain viable.

A few years ago, John Arscott and I worked together to tackle the problem of how to restructure the TB assets available for modern platforms and systems, trying various DOS emulators, among other things. Unfortunately we weren't able to get to the MVP stage with those efforts. To my knowledge, John's got the most current and detailed understanding of how to access the TBsystem language engine separate from the built-in IDE and work on it.

At present we're working on a new website to provide an update and some better functionality - that is scheduled to go live early next month (April 2019).

While I am mainly focused on maintaining the commercial operation to service the existing customer base, I am also researching approaches to redevelop or repackage the language to keep it relevant, such as a way to host the language/compiler online in a platform-independent browser-based environment (e.g., the Sphere engine). The shift to cloud-based computing services is making this more and more commercially viable for TB. As soon as resources are available it's planned to pursue this (or some other approach) in earnest.

Any thoughts or suggestions are welcome. We at TB love our fans and long-time users and are (believe it or not!) working to keep things going with you in mind.

replicating the original True BASIC ; probably in stages

There are several 'starting' points to consider; primarily the original language specs from K&K.

Back to BASIC 1985;
True BASIC 1992 (MSDOS Version Specs)
True BASIC 1988 (Reference Large Desk)

Those works are primary sources (against the ANSI standard reference); and again, True BASIC must be replicated as perfectly as possible; ALL of the K&K principles outlined above must be followed religiously (as they did) and when eventually complete BASIC codes should port over without mods.

So what's different?

Obviously starting from a modern perspective (The Dragon Book, Modern Compiler Design, Engineering a Modern Compiler) and then targeting LLVM rather than specific assembler or machine codes. CLang works this way (uses LLVM). GCC G++ actually produces intermediate assembly (normally hidden under the covers) which is then translated and linked. LLVM is a better solution (in my opinion) especially if desiring the compiler to work across platforms (Intel, ARM, etc).

K&K intended BASIC to run on many machines without the 'beginner' requiring knowledge of the hardware, nor knowledge of the OS. In the long run it didn't really work out that way due to the over arching bias towards Windows programming; and without realizing the demand that would ensue eventually for the Linux and Mac environments.

Thanks for responding to my post-- there actually is 'somebody' out there reading and thinking about this yet; very nice ! (and nice to meet you)

Sorry for the time lag in response ( I've had the flu over the past week, bleah ).


Replicating the original True BASIC

Nice to meet you too! True BASIC will always have a special place in my programmer's heart, and hearing from another fan who is ambitious enough to focus on reanimating it is especially welcome.

As True BASIC was first published for the Macintosh, I wouldn't say it started with an overarching bias toward Windows; it has just appeared so because the major effort to port it to Windows chose a Windows-oriented cross-platform programming environment (which was so Mac-incompetent that it didn't even offer a Carbon port for OS X a few years later). Possibly as a result of this the main (only?) programmer does seem to be much more versed in Windows programming. The Macintosh version of this project, True BASIC 5, was a big step down from version 2, and actually ran slower as a native PowerPC application than True BASIC 2.7, a Motorola 680X0 application running in emulation.

I will say this for cross-platform compatibility, though -- True BASIC 5 and 6 do not have endian problems. While you'd expect floating-point numbers to exchange correctly (in NUM$ format, I assume), my programs write and read data files containing 2-byte integers concatenated as strings, and they work exactly the same way on both Mac and Windows, perfectly interchangeable. I'm not even sure why this works, but I appreciate it.

Having long used version 2.7 on the Mac, I would like to see the return of the command window and immediate mode, which speeds debugging dramatically. Also, this good old Mac version will journal vector graphics (in PICT format, an update to SVG or something is necessary) which avoid the manifest disadvantages of BOXKEEP bitmaps. I do like the LLVM backend to compile the True BASIC interpreter and run-time, but are you proposing it to execute "compiled" user code? Ambitious. Though I once proposed compiling user code to Java byte code and using their many-platform interpreter.

Focusing on the original language specs from K&K is a major key. True BASIC uniquely combines power with simplicity based on these ideas. I very much want to see it revived.

Also, flu, had that, bleah, get well soon.

Still alive

Been using TrueBasic since 1986. I'd like to use it again. Please rewrite it.ff