Hey! Has anyone implemented a renumber command to EhBASIC? I don't feel I should be re-inventing the wheel if it's already been done. Not only that, but I haven't yet dug into what's involved and so don't know how big a challenge it might be. I don't think it's going to be impossible but I don't know if it's worth the effort whilst I'm also adding file system support to my ToE.

EDIT:- I just started nosing into how EhBASIC organises lines of BASIC and it appears to be a linked list structure. This is a nice clue.

Since this post has been up for a little while and nobody has replied, I’m going to assume this is an untrodden path and put it on my todo list. If I produce anything to be proud of I’ll post it.

I'd agree - do keep us up to date on your developments!

It's an intersting challenge indeed.

I remember a renumber being written in sweet16 for Apple Integer Basic - and I'm sure I had one for Applesoft (a MS based Basic like EhBASIC is), so there have been other solutions.

What I remember from writing my own BASIC (written in C, not an 8-bit micro type BASIC) is that it wasn't as straightforward as I wanted - probably because I wanted to be able to renumber sections rather than the whole program, so I could have subroutines at 1xxx, 2xxx, 3xxx and so on, so not just scanning the code for GOTO/GOSUB but also checking if the new renumbered line would clash with an existing line number. Renumbering sections could cause an effective cut & paste of lines too.

Don't forget ON x GOTO Q,R,S ... (and ON IRQ ...)

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I thought the IRQ support on EhBASIC was somewhat broken, but that is a good point I'd forgotten about.

I don’t know why, but I woke up in the middle of the night with the idea of a two pass method of renumbering that mostly works. Then I realised that there would be a problem if someone put say for instance a GOTO that went to a nonexistent line... Oh dear.

The same situation would exist for references to non-existent GOSUB targets. Either way, it shouldn't be a problem. Renumbering a BASIC program is always a relative operation, not absolute. So what you'd do is renumber the broken GOTO or GOSUB and it would continue to be broken. It would be the programmer's problem, not yours.

Digressing a bit, in Business BASIC (BB), encountering a broken GOTO will direct execution to the first statement found after the non-existent one. For example, suppose statements progress from 980 to 990 to 1000. Also, suppose an instruction on 980 conditionally executes GOTO 991. Rather than halt with an error due to the reference to the non-existent statement, the BB interpreter will execute GOTO 1000, since that is the nearest statement that is numerically higher than the desired target.

I never really got into EhBASIC because of its Micro-soft BASIC origins. My first exposure to BASIC was in doing development in BB on minicomputers, an activity that progressed to development in Thoroughbred's Dictionary-IV environment. Thoroughbred's BASIC engine allows instructions to refer to labels instead of statement numbers, e.g., JSR PRINTCHR instead of JSR 12345, effectively eliminating the need to refer to statement numbers.

I started doing BB development right before I bought my first computer—a Commodore 64. When I first tinkered with the C-64's BASIC—customized from Micro-Soft's 1970s-era interpreter, I was quite disappointed with its crudeness, as I was accustomed to working with BB and its capabilities. I was also dismayed with the poor floating point accuracy and performance—the "excess 128" format used to represent floating point is notorious for silly conversion errors. Needless to say, I wrote very little software in BASIC on that machine and the C-128s that followed it.

While it might be impractical with a BASIC running on a 65C02, use of labels would likely be feasible with a BASIC written specifically to run on a 65C816 system with extended memory. In such a system, there would be sufficient RAM to store the necessary lookup tables that would correlate a statement such as JSR PRINTCHR with the target subroutine's address in the program text. Looking up an address in a sorted table goes a lot faster than walking through the program text in search of the target.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just to note: we've already had a mention of an assembler with symbolic labels that runs on a plain 6502 system. It's worthwhile to distinguish the simplest single-pass assembler with something more feature-complete, but a mistake to imagine that an '816 is needed.

Don't forget EHBasic allows RUN and RESTORE to be followed by line numbers (but I suppose any quick look at EHBasic's keyword list will tell you that).

I wrote one of these once for the C128 version of Basic. It already had a RENUMBER keyword, but I wanted mine to allow renumbering subsections instead of the whole program. IIRC the trickiest thing was that renumbering potentially changes the length of the text representation of the number, eg., GOSUB 827 becomes GOSUB 1200 (the 2-byte line numbers at the start of each line are no problem, of course). That means potentially a lot of text needs to be repeatedly moved around (still a lot faster than renumbering by hand). If the new line numbers are on balance physically larger than the ones they replace, then there is also some possibility that the renumbered program will not fit into the available program space (unlikely, but not impossible).

IIRC to avoid repeated text shifting I copied the renumbered program as I went along into the RAM bank normally used for Basic variables (no need to worry about preserving them during this process). If the end result fit, I copied it back into the program bank. Again IIRC, the most annoying thing was that GOTO could be either one or two tokens rather than always one like everything else, so a special case check had to be made.

On the (1980) Apple II DOS 3.3 System Master (DOS 3.2 also, I believe), there was a program called RENUMBER for renumbering Applesoft programs (it also allowed you to load two Applesoft programs in memory at once and merge them). It could be probably be adapted to EhBASIC fairly easily, since the two BASICs have more or less the same tokenized format.

Relevant Applesoft and EhBASIC differences include: the byte values of the tokens aren't the same, Applesoft doesn't support RESTORE followed by a line number, they use different zero page locations for things like the start of program pointer, and the renumber utility uses the & command which doesn't exist in EhBASIC but can be replace with CALL address (the & command is just a JMP to $3F5).

The program on the System Master is the object code, so disassembling it would probably be a useful first step. (It's actually a file with a short BASIC program, which is all you see if load and list the file, but hidden after that is a machine language routine to install the renumber utility in RAM, followed by the actual renumber utility itself.)

Also on the System Master is a (Applesoft) program called RENUMBER INSTRUCTIONS, which, when you run it, describes how to use the renumber utility. Even if you decide to roll your own renumber utility, it might be worth studying just to give some food for thought about which features you want.

There was also disk called Applesoft Tool Kit (I don't remember for sure, but I think there may have been a ProDOS version or equivalent of it also), which had a program called APA (Applesoft Programmer's Assistant) that not only included renumbering and merging, but also automatic line numbering, a cross reference utility, and a couple of other things beyond what RENUMBER had. If all you're interested in is renumbering then disassembling RENUMBER is going to be easier than disassembling APA with all its extra goodies, but again, looking through the documentation might be fruitful.