Ancient DOS Games Filler #52 - QBASIC Crash Course is online!

This one's a bit of a long one... yet some of you may feel it STILL goes by too fast, just because of the sheer amount of stuff covered. As stated in the title, this is a bit of crash course, but I did the video in such a way that hopefully even non-programmers will get what's going on. :)

Even nowadays, QBASIC is still relevant, because it's the fastest way to test out simple ideas as well as perform complex calculations ahead of time. It used to be freely available from Microsoft's website, though nowadays I think the only legit way to obtain a copy is through some MS-DOS disks or from a Windows 95/98 CD, as there should be a folder on those containing old DOS programs.

I also briefly show QuickBASIC as well, since I have both. QuickBASIC is like QBASIC's older brother, given that it came first, had a price tag attached to it, and has a LOT more features and functionality, including the ability to compile your programs into distributable executables.

I have BASICA sitting around on some disks as well, along with many of my EXTREMELY old programs which I wrote when I was between the ages of 10 and 12. I may dig those up someday just for sake of nostalgia. ;)

Haven't watched the video yet, but I would recommend that anyone still interested in BASIC check out FreeBASIC. I haven't used it much (I got a Linux port of Prospector Roguelike going for the author) but it runs on modern platforms.

BASIC is a good way to learn the basics of how computers and programming work, although Python might be just as good. The big thing that BASIC lacks as an on-ramp to modern programming languages is object-oriented design, although I think FreeBASIC supports some of that.

I first learned to program via BASIC, on a Heathkit H89, TI 99/4A, Tandy Color Computer 2 (aka Dragon?), then GW-BASIC (non-ROM BASICA from MS-DOS 3.2) followed by Borland Turbo BASIC and a little QBASIC on PC. Turbo BASIC let you compile standalone executables too, but I think QuickBASIC may have had some better graphics support (I never could figure out how to do a blit in Turbo BASIC that didn't overwrite every pixel, and I think I've seen QuickBASIC games do it).

Recovering my Turbo BASIC games and things is something I hope to do when I finally get around to archiving the rest of my floppies.

Edit: According to the FreeBASIC wiki (http://www.freebasic.net/wiki/wikka.php?wakka=CompilerAbout), it started as an attempt to make a modern GNU-based BASIC compiler that was compatible with QuickBASIC source, but that it has grown into something much more capable that supports lots of stuff including Allegro, SDL, OpenGL, etc.

Nice video! I was impressed by how you managed to get from zero to a user-friendly (by DOS standards) program in one hour. I think this neatly illustrates how BASIC, and QBasic in particular, is great for quickly getting to a point where you can develop simple but useful programs. I also liked the way you showed the entire development process from start to finish, complete with explaining your reasoning. If I were still teaching introductory programming, I'd be seriously considering adapting your example for one of the first lectures in the course (I'd have to do it without GOTO, though). Controlling the console properly in e.g. Python is a bit trickier, although curses comes pretty close.

A few comments about your list of statements to avoid while experimenting:

• KILL deletes files, so you might want to avoid that.
• CALL itself is pretty harmless; it just calls a SUB. It's CALL ABSOLUTE, which calls a machine-code subroutine at the specified address, which is very hard to use correctly unless you are into machine-code programming and can produce quite unpredictable (and possibly harmful) results if used incorrectly.
• One of the advantages of DOSBox is that you can limit the mounted directories to a sandbox containing only QBasic and whatever files you want to play around with and avoid messing up anything else. This is probably not going to be bullet-proof (you could probably circumvent this easily if you wanted to), but should provide a reasonable level of protection against deleting anything important.

Control+Scroll Lock seems to work pretty well in QBasic as a substitute for Control+Break, at least in the Linux version of DOSBox, so you can make infinite loops end. 😀

Random video comments:

1. I really liked this video, although I'm already a software engineer who cut his teeth on BASIC. It may still go over people's heads, though, without some preceding information on basic concepts regarding how computers work (logic, memory, etc.). I remember having a roommate after college who started taking a programming class, and he thought it was all very magical until I stepped him through a program on paper and showed him what was going on in pretend memory.
2. I never thought about it, but it's interesting that MS-DOS uses carriage return + line feed when encoding line endings in text files, while modern Unix/Linux uses only line feed. Unix was around in the days where computers had *only* teletypes (printers with a keyboard attached) instead of monitors for output, but by the time MS-DOS showed up computers had screens. I therefore would have expected the line ending encodings to be the other way around between the two OSes.
3. Gemini: When/where did you learn BASIC programming? I'm surprised that you use 'z' instead of 'i' for your default loop variable. It used to be that everyone defaulted to i, j, k, which I think was a holdover from FORTRAN where the choice of letter determined the variable type. I *still* use 'i' sometimes in C++, but only when it's a really simple number counting loop (I always try to be more descriptive when doing iterators and such).
4. I still remember that in BASIC you can put a semicolon at the end of a PRINT line that comes before an INPUT line to put the question mark at the end of the prompt instead of on the next line. I didn't know about the comma thing; it may be QBASIC-specific, as I remember commas translating to Tab characters in Turbo BASIC.
5. I think QBASIC supports labels instead of line numbers? At the time, this was a more modern way of doing things, and was also supported by DOS batch scripts.
6. I thought SYSTEM launched a sub-shell, and typing EXIT would return control to the program? I think you could also provide a string after the SYSTEM command to cause the interpreter to run a DOS command. Also, I think there was a STOP command, which was like END except maybe for error conditions?
7. Regarding random number generation: One of the cool things about *nix is that the OS provides a random number generator "device" that uses various "noise" in the system to try to increase the randomness of the values generated. Seeded pseudo-random number generators are handy for getting repeatable random-ish results though.
8. You figured it out eventually, but energy per damage can be calculated as energy divided by damage. Your original calculation worked because the "per second" values cancel each other out.
9. I seem to remember that the reason there is a space on the left side of integer outputs in BASIC is because it's reserving room for a negative sign in case the value is negative. Kind of silly!
10. It's amazing that syntax highlighting took so long to become commonplace.
11. A more compatible way to print out arbitrary ASCII values is to use the CHR$ function, e.g. PRINT CHR$(192). You can even print out your own ASCII chart by doing something like this: FOR i = 0 to 255 : PRINT i; " "; CHR$(i) : NEXT i
12. The arrow-shaped characters have nothing to do with the cursor keys, as input and output are actually quite separate animals. I can't remember how cursor keys could be detected in Turbo BASIC.
13. Note that you can use GOSUB to jump to some code that you want to run, and end that code with RETURN, and it will automatically jump back to the next line after the GOSUB. This is great for calling the same code from multiple places or for at least not having to hard-code a GOTO point to jump back to.
14. Another handy thing for the DPS calculator would be the DEF command, which lets you define a calculation macro that takes arguments. This would save you from having to explicitly (re)calculate your output values because you could just invoke the functions as part of the print statement.
15. I should mention that Creative Computing / David H. Ahl magazines and books were a huge help/inspiration to me in the '80s for learning to program BASIC. I even used my Best of Creative Computing Vol 2 as inspiration for writing a game in my x86 assembly language class in college in the early 2000's, which blew away my classmates. The Wikipedia article on Creative Computing has some links to scans of the books and magazines. Most of them were for really old computers, though, so it may be a bit challenging to port them to QBASIC.

oh man, I remember having nothing but qbasic for quite a long time. remember making my own text adventure game. (think zork) Basic transferred very well into "real" programming in machine and C. I still have my micro-controller kits around (8051 FTW). Its really hard to tell people today just how much easier it is to program today compared to 20 years ago. It is now almost a lost art to program for a computer with very limited capabilities. I remember with my ti-99/4a how EASY it was to fill up 32kb of ram once you started working with graphics. Even simple ascii-art started to eat up precious space REAL quick.

I made a very twisted Deathrace-esque version of hangman in TP7. Can't say I was ever very impressed with BASIC. It could be made to work, but control flow was always so clunky.

luckybob wrote:

oh man, I remember having nothing but qbasic for quite a long time. remember making my own text adventure game. (think zork) Basic transferred very well into "real" programming in machine and C. I still have my micro-controller kits around (8051 FTW). Its really hard to tell people today just how much easier it is to program today compared to 20 years ago. It is now almost a lost art to program for a computer with very limited capabilities. I remember with my ti-99/4a how EASY it was to fill up 32kb of ram once you started working with graphics. Even simple ascii-art started to eat up precious space REAL quick.

Yep. My capstone project for Computer Science in college was writing a game for the original Game Boy in C. I learned a lot about what kinds of tricks you need to pull to keep things running smoothly. Supplementing with some assembly probably would have helped, but there wasn't enough time to learn how to work that in.

speaking of BASIC, some older comercial games did released as .BAS files format and in that 5 1/4" floppy its also include Microsoft's BASICA.
I never knew why they aren't compiled into .COM or .EXE format.

There's a difference between a constant and a literal. In QBasic you have the keyword CONST to declare a constant. For example, CONST PI = 3.14. What you called a constant is actually a literal.

There are some other statements that can be harmful if used incorrectly: OUT, DEF SEG, POKE, WAIT.

Anyway, I did learn a thing thanks to this video: how to print a line at row 25 without scrolling. I used DEF SEG and POKE, but putting a ; after a PRINT statement is much better 😀.

For what it's worth, poking directly into video memory is a lot faster than PRINTing, at least in Borland Turbo BASIC. I remember making a little turn based color ASCII maze game in which the player was always in the center and the visible part of the level effectively scrolled as you moved. I think it was faster to render by direct memory writes than by using print and color statements.

I really need to try to rescue my old programs. They were mostly just little tech demo type things to see what I could do. I did make a little CGA Jurassic Park RPG where you fight dinosaurs while trying to collect frozen eggs or something, and later I made an Asteroids clone in C using DJGPP and Allegro.

konc wrote:

So I contacted via email the creator, hoping that the email on the page would still be valid. It was and he was kind enough to reply:
He said that of course he doesn't sell the game anymore. He is aware of the recent interest in retro gaming and many old games getting released as free, but he doesn't have any intention to release it as such. The sad part is that he isn't even considering to put any kind of additional effort on it, like make it available as a digital download for a revisited price.

He did offer me the option to make an exception and create a new floppy for me if I really wanted to, provided that I send the original price mentioned on the site, through normal mail, to a postage address, in a few words following the whole process as that time. Come on, I don't even have access to $ where I live to put them in an envelop and send them 😀 I admit I did think about it for a bit but I don't have the luxury to waste a working day to go to the bank, exchange currency, then the post office etc just to register this game that could be sent as an attachment and paid in seconds with minimum hassle for both of us. Oh well, I'll never get it I guess...

Jeez, some people's behavior I just don't understand. Simple logic just does not compute, or they are total assholes/weirdo's. It would have taken him much less effort to just accept a PayPal transfer and send it through email than to make a new floppy, pack it and post it at the post office.

...so I've actually been pretty sick the past few days. I'm not really ready to get back to working on stuff yet, but I am recovering for sure. I glanced over the comments left and will at least say a few things now so you guys don't think I'm dead or something. ;)

* The reason using POKE and aiming for the text mode screen buffer addresses is faster than PRINT is because it's doing zero formatting and only writing one byte of information, which is either going to adjust the character or both the foreground/background colour. PRINT is still infinitely more convenient. :B

* I'm used to calling literals "constants" because technically they ARE a form of constant as their state cannot change, which is what a constant is. You can start getting really in-depth into this with other languages by now separating out static values, enumerations, even calling the output produced by const and #define by different terms. But yeah, I know what I called "constants" are technically "literals". I'll clarify this better if I ever do another video like this.

* AFAIK, BASICA programs cannot be compiled into executables using period-specific software, but all versions of MS-DOS which came before QBASIC came with BASICA, so it wasn't a big deal. I could be wrong about that.

* I'm not sure if TXT files use both CR+LF or just CR... TBH, I'm more comfortable working with binary files than with text files anyways. :P

* I self-taught myself most of the programming I know, starting with BASIC when I was 10, mostly by reading books and trying out commands. The reasons behind the simple-letters I use are, quite frankly, pretty poor logic:
a = A single character being input, chosen because it's the first letter in the alphabet and I'm likely going to check multiple alphabet characters
c = A single character being checked, chosen because "char" starts with 'c'
f = A temporary floating-point value, chosen because "float" starts with 'f'
j = A random integer, chosen because many words associated with chaos, randomness and luck start with j, such as "joker", "jester", and "jackpot"
s = A temporary string, chosen because "string" starts with 's'
v = A temporary integer value that won't be used for iteration at all, chosen because it's a "value", which starts with 'v'
z = A temporary integer value that will be used for iteration, but not necessarily every time it's used, chosen because it's the last letter on the keyboard and the one I'm least likely to start any other more complex variable name with, given how little work I've done in 3D
cc, ffff, jj, zzz = Examples of what I do when I need more than one at a time

* There are definitely differences between QBASIC and BASICA and virtually all forms of BASIC out there. I mentioned the thing with RND() but there's countless others, such as CALL in BASICA becoming CALL ABSOLUTE in QBASIC, which is what I did indeed mean to say at the end of the video in terms of dangerous commands. :P

* "SYSTEM" was definitely not a shell command... since there was actually a "SHELL" command in QBASIC. The thing is, in an actual BASIC interpreter there's no way to close the thing out and return to the launching environment, thus "SYSTEM" was meant as a command which returned control to the system, whereas END would end execution of the program and return you to the interpreter. There was a STOP command which would suspend execution of the program, reporting the line number in the process and I'm not 100% certain what this was used for outside of debugging.

* Using CHR$ to print everything from 32 to 255, no problem. But remember, 0 through 31 are escape sequences and many of them actually DO something when output to a console, which is what BASIC output is, thus using a single CHR$ you can produce a tab, backspace by a character, produce a bell sound, there's even one which will activate a printer if one's attached!

* I didn't forget about GOSUB, it's just not very useful with tiny programs. :P

* I actually never really learned to use DEF to its full potential, but I did use things like DEFLNG when I needed my programs to have nothing to do with floating point. :P

* Yeah, I forgot about KILL. ;)

Anywhoo, gonna go back to being all kinds of sick now. I'll start replying to eMails and stuff again sometime in the next few days.

Gemini000 wrote:

* AFAIK, BASICA programs cannot be compiled into executables using period-specific software, but all versions of MS-DOS which came before QBASIC came with BASICA, so it wasn't a big deal. I could be wrong about that.

Makes sense, given that BASICA apparently had dependencies on stuff being in the IBM PC system ROM.

* I'm not sure if TXT files use both CR+LF or just CR... TBH, I'm more comfortable working with binary files than with text files anyways. 😜

CR+LF is still the standard even on Windows, much to my annoyance when working on cross-platform code.

* I self-taught myself most of the programming I know, starting with BASIC when I was 10, mostly by reading books and trying out commands.

Same here, by typing in programs and then messing with them, and then creating my own. I think I started out when I was more like 5 or 6 though, and it was early enough that a lot of people had come over to BASIC from FORTRAN.

The reasons behind the simple-letters I use are, quite frankly, pretty poor logic:

It's good to have a system, so that you're at least consistent with yourself! These days I mostly program in C++, so I pick descriptive names like lineCount or isInitialized.

* "SYSTEM" was definitely not a shell command... since there was actually a "SHELL" command in QBASIC. The thing is, in an actual BASIC interpreter there's no way to close the thing out and return to the launching environment, thus "SYSTEM" was meant as a command which returned control to the system, whereas END would end execution of the program and return you to the interpreter. There was a STOP command which would suspend execution of the program, reporting the line number in the process and I'm not 100% certain what this was used for outside of debugging.

Thanks, it's all coming back now. I've been marinating in C++ too long.

* Using CHR$ to print everything from 32 to 255, no problem. But remember, 0 through 31 are escape sequences and many of them actually DO something when output to a console, which is what BASIC output is, thus using a single CHR$ you can produce a tab, backspace by a character, produce a bell sound, there's even one which will activate a printer if one's attached!

Yeah, that must be why I learned POKE. If you POKE 0-31 directly into video memory, you get some cool extra characters like smiley faces and playing card suits.

* I actually never really learned to use DEF to its full potential, but I did use things like DEFLNG when I needed my programs to have nothing to do with floating point. 😜

It's nice for defining a formula that you need to use in multiple places. Sounds like something that was probably stolen from FORTRAN, but I'm not sure because I'm not old enough to have learned the latter 😜

Anywhoo, gonna go back to being all kinds of sick now. I'll start replying to eMails and stuff again sometime in the next few days.

Feel better!

HunterZ wrote:

It's good to have a system, so that you're at least consistent with yourself! These days I mostly program in C++, so I pick descriptive names like lineCount or isInitialized.

Oh don't get me wrong, I still use plenty of descriptive variable names, otherwise I'd be driving myself crazy. ;D

Funny thing is, I actually read ! symbols as "not" in my mind when writing things out. A common do/while loop for me often ends with something like:

while (!done);

Which I mentally read as "while not done".

I read & symbols in a similar way. I know it's a dereferencing symbol in C++ but I most often use it to get the memory address of a variable, so when I write something like this:

myPointer = &checkedValue;

I'm actually mentally reading it as: "myPointer equals address of checkedValue".

I'm also very careful with the length of my variable and function names. If I know I'm going to be using a particular name reference a LOT, I make it as short as I can while still being somewhat descriptive. For instance, a frequent thing I've had to do with past projects is convert an arbitrary coordinate into a tile coordinate of whatever sort of tiling system I've got going on, such as a 2D map. I often need to call such functions inline while doing checks so I make the names for them really short such as tileX() and tileY(). For something I only need to check at a few spots in thousands of lines of code, I don't mind larger names. For instance, one of the function names in my own I/O handler is GCtrl_HasXInputBeenTouched(), which is only ever needed to determine if certain things should be referencing keyboard keys or XInput buttons, all of which is processed in one shot, so having the function name that long is fine. :B

Actually, that's one thing that's been bugging me with my secret project is that, because it's a multi-game thing, I rapidly ran into variable naming issues as the linker will get confused if you use the same variable name at a global level in two different C/CPP files. Yeah, I could just use namespaces, but then that would make access to all of my extern variables, all of which have really short names because of how frequently they're accessed, just that much more annoying.

For instance, I have extern variables set up for my own custom timing routines, since there's actually FOUR timing variables to keep track of, each of which are only two letters long because of how often they need to be accessed:

rt = Real time elapsed in seconds between previous timer check and current
ct = Current time elapsed in seconds since timers reset
ft = Number of logic frames ticked between previous timer check and current
at = Adjustment factor, being a number between 0.0 and 1.0, indicating what percentage of the current logic frame has elapsed

...yes, I actually read "at" as "A, T", even though it should technically be "af", but the rest of the values end in t so I figured I'd stay consistent. This was YEARS ago in early 2007 when I wrote my custom timing routines so the terminology I first used has stuck ever since and thus I keep using it. The point though was that using namespaces instead of just being careful with my global variable names would suddenly make it painful to use extern variables like these. :P

Gemini000 wrote:

* AFAIK, BASICA programs cannot be compiled into executables using period-specific software, but all versions of MS-DOS which came before QBASIC came with BASICA, so it wasn't a big deal. I could be wrong about that.

Wrong on two counts 😉 IBM/Microsoft had a compiler for BASICA programs (v1.00 was from 1982), which was actually very widely used - you'll often find strings like "RETURN without GOSUB" if you hex-edit a random shareware (or even commercial) .EXE from the early/mid '80s, or see the (optional) "BASRUN.EXE" runtime included. Also, MS-DOS came with GW-BASIC.

Gemini000 wrote:

Oh don't get me wrong, I still use plenty of descriptive variable names, otherwise I'd be driving myself crazy. ;D […]
Show full quote

HunterZ wrote:

It's good to have a system, so that you're at least consistent with yourself! These days I mostly program in C++, so I pick descriptive names like lineCount or isInitialized.

Oh don't get me wrong, I still use plenty of descriptive variable names, otherwise I'd be driving myself crazy. ;D

Funny thing is, I actually read ! symbols as "not" in my mind when writing things out. A common do/while loop for me often ends with something like:

while (!done);

Which I mentally read as "while not done".

I read & symbols in a similar way. I know it's a dereferencing symbol in C++ but I most often use it to get the memory address of a variable, so when I write something like this:

myPointer = &checkedValue;

I'm actually mentally reading it as: "myPointer equals address of checkedValue".

That all sounds normal for a C developer.

I'm also very careful with the length of my variable and function names. If I know I'm going to be using a particular name reference a LOT, I make it as short as I can while still being somewhat descriptive. For instance, a frequent thing I've had to do with past projects is convert an arbitrary coordinate into a tile coordinate of whatever sort of tiling system I've got going on, such as a 2D map. I often need to call such functions inline while doing checks so I make the names for them really short such as tileX() and tileY(). For something I only need to check at a few spots in thousands of lines of code, I don't mind larger names. For instance, one of the function names in my own I/O handler is GCtrl_HasXInputBeenTouched(), which is only ever needed to determine if certain things should be referencing keyboard keys or XInput buttons, all of which is processed in one shot, so having the function name that long is fine. :B

Modern IDEs do wonders here. I've been using Eclipse CDT to do C++ development on Linux for a year or two now, and I'm way more productive than I was in older stuff like Visual SlickEdit.

Actually, that's one thing that's been bugging me with my secret project is that, because it's a multi-game thing, I rapidly ran into variable naming issues as the linker will get confused if you use the same variable name at a global level in two different C/CPP files. Yeah, I could just use namespaces, but then that would make access to all of my extern variables, all of which have really short names because of how frequently they're accessed, just that much more annoying.

If you're doing pure C, I'd recommend at least using some structs or something. For C++ global variables are considered a bad idea because it can all be encapsulated by classes that own the data and can provide access as appropriate.

VileRancour wrote:

Wrong on two counts ;) IBM/Microsoft had a compiler for BASICA programs (v1.00 was from 1982), which was actually very widely used - you'll often find strings like "RETURN without GOSUB" if you hex-edit a random shareware (or even commercial) .EXE from the early/mid '80s, or see the (optional) "BASRUN.EXE" runtime included. Also, MS-DOS came with GW-BASIC.

I had a feeling there might've been a compiler but I was never able to learn much about an official one on my own accord the times I tried to in the past. What I ended up uncovering instead were third-party compilers built well after BASICA and QBASIC were relevant.

Also, I never understood the difference between BASICA and GW-BASIC. My Tandy 1000 SX system disks have BOTH and as a kid I just used BASICA instead of GW-BASIC for no particular reason I can remember.

HunterZ wrote:

If you're doing pure C, I'd recommend at least using some structs or something.

My coding style is a mix of C and C++, which would probably really bug purists who prefer straight C or straight C++. That said, while still coding the first game for my project and upon realizing all the conflicts which could potentially happen from having multiple games in one project, not to mention some of the naming ridiculousness I was going through, I came up with an alternative strategy of encapsulating as much of each game as possible into their own class objects, with the "global" variables simply made public and the pointer name being extremely small to minimize typing.

I see what you're saying WRT constants, but I don't agree.

Yes, a literal cannot be changed at runtime, much like a constant, but a constant has an identifier that can be used elsewhere. It's an important enough distinction, I think, that it's wrong to say that one is the other.

I understand that you know what you mean, and when you're a one-man-team, you're the only person it needs to make sense to, but if you want to teach others to program I think it's important to get the details consistent.

E.g. now, if you made a sequel, and decided to talk about the CONST keyword, you'd need to explain that what you previously called a constant isn't /really/ a constant. See where I'm coming from?

I don't mean to shit all over your work, it's a really top notch video, but I think this is an important distinction that needs to be made. 😁

Gemini000 wrote:

Also, I never understood the difference between BASICA and GW-BASIC. My Tandy 1000 SX system disks have BOTH and as a kid I just used BASICA instead of GW-BASIC for no particular reason I can remember.

Apparently BASICA uses code that is baked into a ROM on the IBM PC, while GW-BASIC does not require that?

HunterZ wrote:

If you're doing pure C, I'd recommend at least using some structs or something.

My coding style is a mix of C and C++, which would probably really bug purists who prefer straight C or straight C++. That said, while still coding the first game for my project and upon realizing all the conflicts which could potentially happen from having multiple games in one project, not to mention some of the naming ridiculousness I was going through, I came up with an alternative strategy of encapsulating as much of each game as possible into their own class objects, with the "global" variables simply made public and the pointer name being extremely small to minimize typing.

I programmed in straight C for a couple years before learning C++, and I've been programming full-time in C++ for almost a dozen years now. I've had the opportunity to learn a bit of Boost lately, which is pretty neat but horribly documented; late last year I threw someone else's Boost.Asio-based socket API in the trash and replace it with one of my own that had a much simpler API and better encapsulation of Boost.Asio. Today I had to throw out some overzealous use of Boost shared_ptr's - the guy I've been working with decided to use a bunch of them to point to a singleton object, which caused a crash when it was automatically destroyed as a result during the shutdown process. I've probably spent the majority of my career fixing and redesigning other people's busted crap!

Gemini000 wrote:

cc, ffff, jj, zzz = Examples of what I do when I need more than one at a time

The programming part of my brain just went "OW!" 😉