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.

marcus

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

Comments

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.

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.

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 ).

marcus

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.