Retro-BASIC programming Editors and IDEs

@cjs’s excellent post on EDSAM always makes me want to do some “native” development on an Apple II. I did a little bit of BASIC this past summer, writing some BASIC routines to compare various aspects of execution between an HP-85, Apple II, and CoCo, and on the Apple I was using the Beagle Bros. Program Writer by Alan Bird (search for “Program Writer”), which I found much superior to the BASIC prompt editing that I did “back in the day”.

What retrocomputer BASIC programming environments do forum members enjoy using? Most of our retrocomputers have a very simple line editor in ROM, but other environments are available for many machines. For my own part, I wish I had known about Program Writer in the 80s!

3 Likes

An (opinionated) account on the comparative experience may be nice.

My own BASIC experience has been limited to a (my) PET 2001 emulation lately. For writing programs, a modern editor is far superior, mostly for the amount of text that can bee seen at once and for fast scrolling. (Small wonder, a facility to import files was one of the first features I added to the emulator.) For small edits and sketching screen output, the built-in full-screen editor of the PET is actually preferable. With an emulator, it isn’t hard to get the best of both worlds. I guess (based on a quick glance at the manual), Beagle Bros. Program Writer is much like that, but on the original machine. (Fine!)

For my own part, I found Program Writer to be a large improvement over the Applesoft BASIC editing facility. Unlike the Commodore 64 or HP-85, both of which have rudimentary “screen” editing in ROM, or the TRS-80 Color Computer, which has some line editor features (including copying, insertion, and deletion), Applesoft BASIC is limited essentially to re-typing program lines that require changes. There are also very limited facilities for renumbering lines; DOS 3.3 includes a RENUMBER program that can perform some renumbering, but ProDOS does not. These limitations make development of Applesoft BASIC programs a more trying exercise than even other, more or less contemporary, 8-bit BASICs.

Program Writer is a RAM-resident screen editor specifically for BASIC programs — in fact, it is not capable of editing non-BASIC text, as far as I can tell. It appears to use the Applesoft BASIC tokenizer and memory reporesentation of BASIC statements to store the working program, and has no native concept of opening or saving a “file”. However, for BASIC programming it provides a simple yet quite usable full screen editor with language-specific features such as renumbering, variable listings, and line splitting. It also has normal editing features such as search and search-and-replace.

Using Program Writer is most similar to using a rudimentary single-file command-line editor on DOS or Unix; think of something like GNU Nano or MS-DOS EDIT.COM with only one file open. You enter the editor with the command && at the Applesoft ] prompt, then edit your BASIC program, quitting the editor to run it. The arrow keys can be used for simple navigation, and more complex navigation and editing facilities use the open-Apple key as a modifier. Loading a new file is accomplished with the BASIC LOAD command before opening the editor, and saving entails quitting the editor and running SAVE in BASIC.

Because Program Writer uses the BASIC program representation as its program store, edits made at the BASIC REPL are reflected the next time you enter the editor. This tight integration with Applesoft BASIC makes it feel a little bit like an IDE; editing, testing, examining, and debugging all flow relatively naturally into one another, with simple edits and examinations at the BASIC prompt and more complex program creation in the editor.

Some of the nicer polished touches of Program Writer include excellent 80 column support, with a keybinding (open-Apple X) to toggle between 40- and 8-column modes, and Language Card support for placing the resident editor in Language Card RAM to leave more room for BASIC code in the main RAM. There is also a “small” version of the editor, with more limited features, for writing larger BASIC programs on machines that do not have a Language Card. Program Writer runs normally under both DOS 3.3 and ProDOS, and provides the same interface in both cases.

1 Like

It’s not clear if you are aware that Integer BASIC and Applesoft both use the built-in monitor’s GETLN routine, which recognizes several Escape codes for cursor XY movement and three types of screen clearing (entire, cursor to end of current line and cursor to end of screen). The left arrow moves the cursor left and quietly deletes one character from the input buffer, and the right arrow copies the character under the cursor into the input buffer and moves the cursor right.

It was undoubtedly very primitive, but it was a vast improvement over retyping lines you were trying to copy or correct. Integer BASIC and Applesoft both had LIST commands that added a lot of white space to “improve” readability without consuming RAM or hampering performance. Applesoft actually took this to a level I found to be excessive, but a POKE 33,33 before LISTing a line you wanted to edit helped to at least suppress the extraneous carriage returns and lead-in spaces at the beginnings of continuation lines.

1 Like

Funny how things can be better than they seem - if you have special knowledge. Maybe it’s the acquisition of this arcane knowledge which is one of the appeals of retrocomputing.

Acorn’s BBC Micro has line editing, of a sort. You can append or delete from the input line, and copy characters from anywhere on screen (even the bitmapped screen modes.) It’s still fairly limiting. The Master, a successor machine, had an EDIT command offering a true full-screen editor, with facilities like search and replace, and file insert. There’s some documentation of this version, and an enhanced version, here.

1 Like

I am aware of this for the line that I am editing, but I was not aware (if this is what you are saying?) that it would work on LISTed lines in the scrollback. Editing the line currently being typed is … not great, but not terrible, in Applesoft BASIC. I do not know how to edit a line from the listing, however.

It takes a bit of practice, but it’s doable.

  1. LIST the line you want to edit. If it’s longer than one line, you can POKE 33,33 before LISTing it to prevent some of the most annoying additional white space.

  2. All Apple ][s have ESC-A through ESC-D for cursor movement, the ][+ add IJKM to move and stay in Escape mode, and the //e adds the arrow keys into the mix. However you decide to get there, ESC and cursor up to the beginning of the line.

  3. For //e or newer, make sure you’re out of Escape mode before copying and/or editing with the right and left arrows, then press RETURN to complete. If you want to insert something in the middle, you can ESC back over something that you already copied to make room for more text.

  4. Enter TEXT or POKE 33,40 to return the screen to normal operation.

2 Likes

In all this time, I had no idea! I’m going to try it, maybe later tonight if possible. :slight_smile:

Excellent! If you have a //e or newer, just remember that the right and left arrow keys move the cursor but don’t copy or delete while you’re in Escape mode. I just press space when I get to the desired position to make sure I’m back in standard mode before I start copying.

1 Like

Well, I just tried it on a //e.

It’s not as easy as the HP-85 or C64 (it took me several tries to get things right), but it’s not too bad at all! It’s a pity I never learned this as a kid, keying in BASIC programs from listings and correcting my errors! Both this technique and Program Writer were unknown to me in those pre-Internet days. We had the Apple //c reference manual, but I don’t remember it from there (I don’t think it has a lot of information about Applesoft BASIC, but it does cover the monitor; I likely never put two and two together, if it’s there); I’m sure we had an Applesoft BASIC manual, too, but I no longer have it and really don’t remember spending much time with it. I recall learning from some BASIC tutorial book that almost certainly didn’t mention this sort of thing.

This implementation does have the advantage that, unlike the HP-85, whatever other garbage happens to be on screen (say, from the syntax error when you mistyped the line the first time!) doesn’t automatically cause a chain of syntax errors as you curse at the computer and hunt for the kill line key. :wink:

Thanks for sharing this!

Yeah, I had a C=64 back in the 80s too, and the first time I got an ?OUT OF DATA ERROR while editing a program it took me a while to realize that I was accidentally trying to execute the READY. prompt.

I’ve not done any “true” retro programming for some time, but what I remember when I was madly into the Apple II was two things: One was called PLE (or GPLE) - (Global) Program Line Editor. It would “list” a line into a buffer then you had some nice control keys to edit that line - a facourite of mine was to start a comment with a Ctrl-M, so when LISTed it would ovrwrite the line number and REM statement - pretty, I guess.

It also featured an easy way to get lower case into an Apple that had been retro fitted with a lower case character generator ROM but no lower case keyboard…

The other thing I used on the Apple II was TED II+ which was an IDE of sorts for assembly writing. I used that to generate ROM images for an in-house designed 6502 controller board we were using as part of a factory automation project in the early 80’s - the other half was (eventually) BBC Micros with most of that being in BCPL which had it’s own screen editor as part of the system.

In other (non BASIC) projects at that time - ‘ed’ and ‘em’ on the PDP11 Unix v6 system. A hideous line editor on the Primes, YALOE (Yet Another Line Editor) that ran under North Star DOS (a cp/m look-a-like) and the UCSD P-System.

Fun time? Maybe, but I guess we just got used to it!

Vim, Nano and my own nano-like editor today…

Cheers,

-Gordon

2 Likes

Thanks to the internet, you can check out Appendix B online for free. If you want the actual paper and ink manual, PM me your snail mail address, and I’ll try to dig mine out of the attic and send it to you gratis, no strings attached.

1 Like

Indeed, the richness of documentation available on the Internet has made many of these platforms much more available today than they were “back in the day”! This thread is an excellent example — I learned about screen editing on a computer I’ve used for almost 35 years —, but so, too, have I been able to find things like service manuals and reference manuals for machines that I would never have been able to find in the 70’s or 80’s.

Another great resource is the availability of “war stories” from those who have been there and done that. The Computer History Museum oral history collection, for example, or Brian Kernighan’s interview with Ken Thompson at VCF East 2019. This year at virtual VCF West, there were two interviews with Bill Mensch about the development of the 6502. The list goes on and on! In addition to interviews, there are other histories and memoirs.

Now if only I could rescue them all before they wind up in the scrap heap… :slight_smile:

2 Likes

BASIC was unusual in its (clearly unwise) tight integration of line numbers as both labels and line identifiers for editing. Though other languages, such as early FORTRAN, did sometimes use numbers as labels, these were not line numbers in the BASIC sense: not every line was required to be numbered (most were not) and labels need not be in monotonically increasing numerical order. (You can see an example here.)

This was so weird that it actually introduced what I would call a new major form of program editing to the world, to go along with punched cards, traditional line editing (best known from Unix ed but available in many other implementations on all sizes of computers) and screen editors along the lines of Emacs and vi.

(I should make it clear here that though line editors such as ed may appear superficially similar to editing in a typical BASIC environment, it is actually vastly different. I believe that anybody who’s made extensive use of both and learned them well, as I have, would agree that the former is significantly faster and more powerful than the latter.)

It would be interesting to see a study of how this came about, since even by 1964 when BASIC was introduced programmers had long realized the value of using arbitrary symbolic names (without ordering requirements) over numbers to reference things. (This was one of the major advances made by assembly language!) Even the designers of BASIC themselves subscribed to this to some degree, choosing to use letters and symbols rather than numbers to reference storage, and not requiring the ordering of these to match any particular ordering of the source code.

Anyway, this binding of explicit line numbering and labels made having a “renumber” command of some sort (often an external program) nearly essential for any large program under active development. A number of BASICs have this built in, but I had to use something external on the Apple II; there were a wide variety available but I don’t recall any of them.

And back when the Apple II+ was my primary platform, I too used GPLE. (Program here; sadly I cannot seem to find a copy of the manual though I’m sure I’ve seen one somewhere.) These days even for BASIC I generally do cross-development (with a Linux/Unix or occasionally modern Windows platform as host), which as well as being faster and easier for more than trivial amounts of code also provides easier backup, version control, and so on.

Small changes during testing and debugging I still usually do on the machine itself, but since the changes are small, there’s little need for anything special in terms of editing. I may use an EDIT command or “screen editing” if that’s available, but as often as not it’s about as quick to retype the line, especially given the typically impoverished cursor movement commands offered in these environments.

1 Like

JOSS was developed slightly before BASIC and also numbered every line, though with two part numbers. This was a natural thing to do when a language was edited in a paper terminal while for languages edited in individual cards you needed some other scheme to implement labels.

2 Likes

DEC FOCAL also used two-part line numbers, and the Wikipedia article on FOCAL suggests that this is a direct influence of JOSS.

I’m not convinced it was unwise at all - this was 1964 and screen editors were some years in the future and even line editors in their infancy, but the key thing with BASIC was that it was designed to be interactive from day 1.

This IMO is what set it apart from just about everything else at the time - card decks, compiling, batch processing and so on. You typed the program in, ran it, and got results there and then.

(And lets quietly ignore the timesharing aspect of it at that time too!)

So line numbers were the editor as well as the labels for GO TO/GO SUB targets too rather than some additional line-editor commands to lean and use on those old 10cps printing terminals…

-Gordon

1 Like

Well, no. LISP had already been doing that for years. And without line numbers of any kind. BASIC came along a year after a 17-year old kid had finished implementing an interactive LISP system on a machine with 4096 (18-bit) words of memory.

L Peter Deutsch’s PDP-1 LISP was a significant event in computing history, but it came out in 1963 so “doing it for years” is a slight exaggeration.