• Please review our updated Terms and Rules here

QBasic - The Interpreted and Compiled Language.

CP/M User

Veteran Member
Joined
May 2, 2003
Messages
2,986
Location
Back of Burke (Guday!), Australia
I was wondering if anyone had any thoughts about how QBasic would deal with certain problems while shifting from it's Interpreted Form into the Compiled format, or if it's being written in a certain way to avoid certain problems.

I can only draw upon experiences from my own system (Amstrad CPC) and Locomotive BASIC. It's a fine language, though it wasn't bundled with Compiler as standard, so many 3rd Party software houses made their own Compilers based on the language, lots of them lack the use of Floating Numbers (not all, but many) and it's left me with the feeling that certain parts of the Language are omitted because they have written something which is emphasised on Speed rather than Accuracy, though again I don't know if it's due to the way an Interpreted language can do certain things which are more problematic in Z80 Assembly.
In recent years a Cross Compiler was written (under Windows), it too wants to create something which is close to that BASIC, but it also wants to enhance it's performance with speed, though it seems to sacrifice in a number of other areas, I have a List somewhere translated documentation of the differences & there's a Website if anyone wanted to see it. A few years ago I tried writing a Game for it, but some frustrating issues left me to leave that Compiler and code it in Pascal instead and I had no problems completing the project with that. Execution times were excellent and I only thing I had to worry about was running out of memory as I only had 20Kb.

I don't know if the problem is QBasic runs under DOS on 16-Bit Platform and 16-Bit Assembly has more provisions to make Interpreted Languages much easier to translate to. Please share your thoughts.
 
I could be wrong but QBASIC was just a tokenized BASIC. It was not a true compiler in the sense that it would create code like a C compiler. It did make better use of the line numbers and replaced them with actual addresses. Most BASICS of that time were simple but very inefficient. Most could be significantly improves if the subroutines used the most were at the beginning of the program with the lowest numbers. One could make a guess how they worked just knowing that.
Dwight
 
QBASIC is QuickBasic without the ability to emit executable files. The result is the same as running the program within QuickBasic for debugging purposes. About a year before QBASIC was added to MS-DOS, the MS Press book Learn BASIC Now had a similarly cut down version of QuickBasic.
 
QBasic (Quick Basic) is available in two forms that I'm aware of, both PC/DOS systems, nothing to do with CP/M.

There is the 'free' version, which comprises a cut down (I believe) IDE and in effect an interpretive version.

Then there is the full (commercial) version which has the same language, the same IDE, but the extra facilities to provide the immed interpreter, and the compiler (which has both a semi interp form using a run-time module, or a full compiler which creates a stand-alone .EXE file.

As far as I know, the latter is a full compilation. I have version 4.0, with the full (3 volume) manual set.

Geoff
 
This was my favorite BASIC, the commercial version. It could also emit OS/2 native executables, and i used it to write a simple but absolutely critical OS/2 program for a customer years ago. Won massive brownie points.
 
I really loved QuickBasic. Something about the way it worked clicked with me when I was in my early teens. Anyway to the topic, the compiler stopped being able to compile my program when it got to a certain point - I can't remember what size that was, perhaps something like 60kb.
 
Sorry, I've been confused, probably because of my limited knowledge and what I have been referring to as QBasic, I should of referred to it as QuickBASIC (which is Interpreter/Compiler).

I found more than a Satisfactory explanation of it on Rosetta Code, which refers to QBASIC as an Interpreted Version based on QuickBASIC 4.5 with the Compiler removed.

Interesting I didn't know it could produce OS/2 program.

Being on Rosetta Code a little bit, I'd read about other languages based on QuickBASIC, such as QB64, and on other forums I've seen people use that to produce Arcade style games for the PC.
 
There was also BASIC PDS (Professional Development System) that added significantly more developer features and libraries. I assume it also produced better code output.

I believe all 'interpreted' versions still reduced the BASIC script into a pre-parsed binary representation that was much quicker to execute in the run-time.
 
I really loved QuickBasic. Something about the way it worked clicked with me when I was in my early teens. Anyway to the topic, the compiler stopped being able to compile my program when it got to a certain point - I can't remember what size that was, perhaps something like 60kb.

Ugh, I had the same problem! I was working on a pretty cool RPG engine, but lost all interest when I realised it would't compile.

Anybody ever try [url="https://www.portal.qb64.org/]QB64[/url]? It's a fully 64bit reimplementation for modern computers. Pretty fun to mess around with, and it even has a bunch of commands that were sorely missing.
 
Hm, never heard of QB64. My go-to is FreeBasic, a revival/extension for Windows and *nix on x86/x64. It's not particularly fast for a modern compiled language, but I find it pretty useful for hacking up quick-and-dirty scripts/utilities and algorithm tests - plus, it's the quickest way to get from zero to simple framebuffer graphics on a modern OS that I know of, as it has a QB-compatible graphics library.
 
I can only draw upon experiences from my own system (Amstrad CPC) and Locomotive BASIC. It's a fine language, though it wasn't bundled with Compiler as standard, so many 3rd Party software houses made their own Compilers based on the language, lots of them lack the use of Floating Numbers (not all, but many) and it's left me with the feeling that certain parts of the Language are omitted because they have written something which is emphasised on Speed rather than Accuracy, though again I don't know if it's due to the way an Interpreted language can do certain things which are more problematic in Z80 Assembly.

Since writing that back in March, the only conclusion I could work out of that, is to treat each language on it's own merrit and not "assume" the compiled BASIC language will do the same as the Interpreted BASIC language.
My main problem until recent times being number handling is different, so Interpreted BASIC worked in Integer numbers (-32768..32767) and Real numbers, but the compiled BASIC uses Word (0..65535) and Byte (0..255), I also had to get clever about where a Pixel was drawn, so for a Starfield to be updated correctly, it was placed in a random place on some coordinates divisible by 4, this would mean that when a Pixel reached one side of the screen, it would land on 0 and allow the code to update a pixel on the far side of the screen.
Once I had that sorted, I was able to improve the small game I coded in 2016, to improve the visibility, I wasn't going to plan on coding another version of this (from the one I made with Pascal), but it just seeemed good to figure out some problems I had with the code earlier on and resolve those issues instead of just assuming it wasn't going to be possible. I contribute that flaw from reading "Real Programmers Don't Use Pascal", which makes Assembly the goto language if it can't be resolved in another, but then suggests that if it cannot be done in Assembly, it's not worth it, though maybe it's just me looking for a scapegoat.
 
I had pretty similar path than you.
Moved from limited VIC-20 basic to CPC 464 / Locomotive basic. Loved to learn
with it and really liked, that I could actually program long enough code, that would work as a game.
Yeah, there are games for VIC with basic, but I had no memory extensions and 3,5 kb of available ram
was just not enough for me to do anything funny.

Then, I moved on to gw-basic. I don't think I really got to like it, but when I moved on to QB 4.5,
I absolutely loved it. I do remember making long enough code, that started to have difficulty to be
converted into .exe files. I never figured out what was problem with it. It may have been my 'freestyle'
way of coding and using variables. I had learned programming by myself with limited documentation
and I never defined any variables, just went on ahead using them with no definitions. Perhaps more
careful programming style would have made it easier for the compiler to make a working .exe file (?).
I guess, I could have reused variables more careful too - I believe, I might have many times just
made a new variable when ever I felt like it or needed a new one without any care, that used
variables have reserved memory space.
 
I had pretty similar path than you.
Moved from limited VIC-20 basic to CPC 464 / Locomotive basic. Loved to learn
with it and really liked, that I could actually program long enough code, that would work as a game.
Yeah, there are games for VIC with basic, but I had no memory extensions and 3,5 kb of available ram
was just not enough for me to do anything funny.

I never had a VIC-20, but I always remember Libraries having Books for the VIC-20 loaded with BASIC games and I think it was around the time I was getting into Emulation, the Campus I was studying at had one too, so I photocopied some of the interesting games I think just in case I came across an emulator, and then in the late 90s I came across one, I can't remember what it was called and from memory I think it had to operate with Windows 95 in the background, though I don't remember much about it, I vagulely remember typing in something because of the Character Graphics it had being very difficult to work out and working out which key did what, I think I would of got a Photo of a VIC-20 Keyboard just to get a copy of the Graphical Keys and I think I would of been emulating with the Maximum amount of Memory it had.


Then, I moved on to gw-basic. I don't think I really got to like it, but when I moved on to QB 4.5,
I absolutely loved it. I do remember making long enough code, that started to have difficulty to be
converted into .exe files. I never figured out what was problem with it. It may have been my 'freestyle'
way of coding and using variables. I had learned programming by myself with limited documentation
and I never defined any variables, just went on ahead using them with no definitions. Perhaps more
careful programming style would have made it easier for the compiler to make a working .exe file (?).
I guess, I could have reused variables more careful too - I believe, I might have many times just
made a new variable when ever I felt like it or needed a new one without any care, that used
variables have reserved memory space.

GW-BASIC was another language I came across Books on, I sort of felt it was similiar to the Amstrad's Locmotive BASIC, with it's own set of commands that do all the work, for example in GW-BASIC LINE uses 4 sets of coordinates which set where the Line begins to it's Destination, in Locomotive BASIC your can either use MOVE or PLOT to place the Graphics position at that position and then use DRAW to where the Line is meant to go. Years ago I came across some old Computer Archive Online called Carousel I think and in that there was stuff coded in those old BASICs as well as stuff in other Languages, I remember downloading some Animation of a Walking Man which was coded in GW-BASIC, which was a little graphic of a Man walking along the screen using some of the other Graphical handling abilities of the language.

Am I wrong in suggesting QuickBASIC 4.5 moved away from that and go a more structured approach to coding? I'm guessing it was trying to go a more procedural routine and adopt the concepts of Internal variables, though allow for Global variables if needbe. The limitation with Turbo Pascal back then was programs operated in Real Mode, which means programs were limited to 640Kb, so I guess QuickBASIC 4.5 had the same trouble where it couldn't operate in the Extended Modes, in the same manner the earlier Turbo Pascal 1 to 3 on IBMs couldn't run past 64k because they were limited to COM files.
 
I can only say from my own user experience, that I really liked to be
freed from using line numbers and about the ability to call subroutines by their name.
I also liked to use do-loop and select case routines.

In my personal opinion, the biggest draw back was the graphics limitations. Even back then
screen 13 that gave 320x200 pixels at 256 colors, was pretty limited. I remember at some
point some limited support for sound blaster became possible, perhaps a library created
by hobbyist or something ?

I think QB64 removed these limitations, but on the other hand, it needs windows.
About a year ago, I felt the need to try, if I could still make anything with QB.
I then decided that I will try to make a spider game, that I used to play at school with
Compis computer (0x86 or 1x86/cpm). I chose to make it with QB45, then it would be
the same user experience as programming, when I was young and also, I could be able
to transfer the ready game to same era computer as well. I have to say, that I have
worked for 4 years as programmer with html/ asp / sql / javascript, which pretty much
killed my desire to work as a programmer (probably I was not in optimal working environment),
BUT the instant I re-tried QB45, the FUN was right back to coding :). I was a bit rusty on
QB syntax, but it all came back very quick. I got it up to maybe 80% ready, fully playable
but not polished version. Maybe one day I will finish it up.
 
Hello 'CP/M User' - regarding your comments about Locomotive Basic.

As far as I know, Locomotive Basic (Mallard, for the Amstrad PCW etc) does not support the commands you refer to. There was in fact no graphics support at all, except for using GSX and the various complications involved.

However, I have just discovered that there WAS an add-on for LB called WALBASIC, originating with a French company (WALDATA). That provided exactly the commands you refer to, via a m/c module loaded above &HD000 and the commands CALLed, although I'm told that if you could buy the offical package then BASIC.COM must have been patched in some ways and the new commands became fully part of the system and no longer needed the CALL.

I never knew back then that this system existed. I am just now playing with the cut down module (using CALLs) and it's certainly interesting.

As you mention the system, I wonder if you had WALBASIC, and what you know about it.

Correction? Since writing this, I note that 'Locomotive Basic' may be the version specific to the CPC computers, and this version may well have included the commands referred to (PLOT, DRAW, etc). A separate Locomotive produce called 'Mallard Basic' was more specifically for CP/M (and supplied with the PCW range) and my comments refer to that. I am still, however, interested in any information about the WALBASIC system.

Geoff
 
Last edited:
Hello 'CP/M User' - regarding your comments about Locomotive Basic.

As far as I know, Locomotive Basic (Mallard, for the Amstrad PCW etc) does not support the commands you refer to. There was in fact no graphics support at all, except for using GSX and the various complications involved.

However, I have just discovered that there WAS an add-on for LB called WALBASIC, originating with a French company (WALDATA). That provided exactly the commands you refer to, via a m/c module loaded above &HD000 and the commands CALLed, although I'm told that if you could buy the offical package then BASIC.COM must have been patched in some ways and the new commands became fully part of the system and no longer needed the CALL.

I never knew back then that this system existed. I am just now playing with the cut down module (using CALLs) and it's certainly interesting.

As you mention the system, I wonder if you had WALBASIC, and what you know about it.

Correction? Since writing this, I note that 'Locomotive Basic' may be the version specific to the CPC computers, and this version may well have included the commands referred to (PLOT, DRAW, etc). A separate Locomotive produce called 'Mallard Basic' was more specifically for CP/M (and supplied with the PCW range) and my comments refer to that. I am still, however, interested in any information about the WALBASIC system.

Geoff

Hi Geoff,

Unfortunately my Username is rather confusing these days :(

When I first signed up here in 2003 when this forum was new I was dabbling with CP/M for the IBM PC/XT, though I grew up using an Amstrad CPC464 and then later got an Amstrad CPC 6128 which I still have. Initially when I signed up on the CPCWiki Forum held the title of CP/M User as well because I had switch coding in Turbo Pascal 3 from the IBM PC version with CP/M-86, to the Amstrad CPC version, but the trouble I found was I was too dependent with the Amstrad CPC Firmware and I don't think I was popular writing CP/M .COM files with System Specific code in it, so I switched Usernames on the CPCWiki forum to the rather daft AMSDOS and switched from Turbo Pascal 3 to the early Hisoft Pascal 4T, which compiles Pascal code to BINary files and operates outside the CP/M Environment. Switching from Compilers there are differences and similarities, though it has allowed me to create similar programmes, the only snag which I probably would have encountered with TP3 is a Limited working space, so HP4T is fine for small scale projects.

The only thing I've been using CP/M with these days is BBC BASIC for the Amstrad CPC through my Winape Emulator, which has been setup to be an CPC464 with 128kb. I made some modifications to create a CP/M Plus DSK to allow it to work on the 464 and play around with BBC BASIC which is a bit different since the earlier BBC Computers have bigger screen resolution, though otherwise interesting to Translate. On that platform Graphics are also present, though I understand a more Generic version of BBC BASIC exists, which this version has been based on.

From a PCW perspective using Mallard BASIC, I believe many of the Graphical aspects aren't there, I've seen some Mallard BASIC code which handles things differently to Clear the Screen since CLS isn't present. Unfortunately, I'm rather confused which Language came first, Locomotive Software wrote Locomotive BASIC and Mallard BASIC, I was under the impression Locomotive BASIC came first with the Amstrad CPC464 in 1984, but if Locomotive Software had already created Mallard BASIC, which is Locomotive BASIC minus all the Firmware goodies to handle Graphical Aspects, then I won't argue with that since Languages are usually built up, instead of being stripped down.

Having a look at the WALBASIC on the CPCWiki forum, it looks very interesting and it should allow PCW users to translate Locomotive BASIC from an Amstrad CPC to the PCW. Having a look at how it handles Input, it looks a little different from the way Locomotive BASIC handles input, for example I'm not sure what KEY(n,a,c) represents for the Locomotive BASIC side of things even after translating the French, so I'm guessing represents INKEY()=0 which in Locomotive BASIC handles the Key Number and returns 0 when it's pressed and -1 when not pressed. FuncKey sounds like INKEY$, though I would of thought Mallard BASIC would of had INKEY$, KEYB simply waits for a Keypress, on a CPC it's CALL &BB18 which does that and the last one works like SPEED KEY on the CPC, which determines how fast the keystokes will be.
 
I think QB64 removed these limitations, but on the other hand, it needs windows.

That seems to be it's only limitation, although there are Linux and MacOS versions, there's no reason why DOS programmes had to be limited to 640Kb and indeed I used to play some impressive Free DOS games on my Pentium which came with some Driver to extend the Memory range and I think I had to tell DOS in a Batch file to set aside some Memory, the Sound Blaster I think was also configured either there or in the CONFIG.SYS file which was assigned a Port or an Standard Address which the Games could use.

I don't know what's happening with Free Pascal these days, but when it began around 20 years or so it was promoted as being Compatable with Turbo Pascal with 32 bit capabilities while also including a number of versions for Windows, DOS & even OS/2 Warp got one.
 
Back
Top