(The previous CTRL+left/right functionality - move cursor between lines - is replaced by the new CTRL+up/down shortcut. Not exactly the same, just very similar.)

Can't remember what I ended up doing, but at the very least, CTRL+up/down isn't properly discussed in the docs.

It's been over 3 years! The editor is fairly stable at this point, but I did a few fixes last year.

Original BASIC Editor set Mode 7 for command mode, and some other mode for edit mode.

Updated version runs command mode in the same screen mode as edit mode, so that any shadow MODE (when selected - which appears to be impossible to detect) is retained when selected. This is fine in MODE 7/135, but the scrolling sucks in the 16K/20K bitmap modes. (The text window is N-3 rows: ~18.5K in MODE 0, ~14K in MODE 3. ~9K in MODE 4, and that ain't brilliant either.)

Assuming a fix for #2, the program name probably won't need a HUD entry. So there's just used bytes/free bytes left. Include this in the prompt instead, there's no need for a text window at all, and it can use hardware scrolling.

Free bytes in the command prompt would probably be enough.

12345>

Would it need something vaguely mnemonic, to indicate that's bytes free?

12345f>
-12345>

Or used/free?

12345u+12345f>

(etc., etc.)

They're called from the service routines! Wants noting...

Ctrl+f9 and ctrl+shift+f9 are free in edit mode. Use Ctrl+f9 to run (like Turbo C++), and (if there's a REM>) ctrl+shift+f9 to save+run.

Would be nice to be able to do this from command mode too, but it gets input via OSWORD 0, so it seems like it would get a bit too involved...

The detokenize routine is very slow - but it can be improved!

Copies 256 bytes using the needlessly generic memmove routine.

Currently 30 bytes of code to make 2 copies - could be 2 little inlined loops, 11 bytes each:

ldx #0
-
lda $400,x
sta $700,x
inx
bne -

Might as well just always use the REM> name, if it's there. Make it work like (I think?) BASIC V - SAVE saves it to the REM> name if there is one, or error if not. SAVE XXX saves it to XXX.

(Just find the REM> suffix, and use that as the file name for OSFILE. It's CR-terminated, and the filing system can check the rest. Save 15 bytes of zero page and a bit of code.)

Should really grab the value of PAGE from BASIC's zero page and use that instead. Then do PAGE=&xxxx|M before the OLD|M. Is there space?

While looking at this code, should probably make sure it's checking that BASIC is the active language first...

Want this for when working in lower-case assembly language... it's annoying to have to use NOCASE when entering the ROM each time.

Looks like it might inhibit .proc stripping: https://sourceforge.net/p/tass64/bugs/44/

Saves 40 bytes if removed...

Does A mean Above, or After? Does B been Before, or Below? I can never remember. There must be a more mnemonic pair of options here. Or maybe I just need to add a little note to my F key strip.

This repo dates from the time before I fully appreciated the benefits of CI. Should get it set up with AppVeyor so there's a proper release list and all that. Downloading individual binary files from inside the repo is a bit tedious, and it'd be much easier if each release had a zip of .rom files.

Really awful performance on long lines. Seems OK in Mode 7, though, kind of... maybe this is an OSWRCH bottleneck?

Command mode uses the current mode. At the time, I couldn't figure out how to detect the shadow RAM state properly, so this seemed safest. (Though, this is actually possible! - I think by querying the VDU status byte - there's something on Beebwiki about it.)

This is fine - except if you start in a 20 column mode. Then it sucks. Would be nice to select mode 7/128 (as appropriate) in this case.

(Or maybe be more clever. If you're in mode 2, why not go for mode 0? The program clearly fits, no reason not to have 80 columns. And for mode 5, you could switch to mode 4: same 40 columns as Mode 7, but 32 rows. If in a shadow mode, can do mode 128 in either case.)

Half-formed idea - pick up the value of ERL on entry, so it can be visited easily after discovering there's an error that needs editor work?

Or would it be better to just do this from in BASIC, using *FX138 to insert "*BE"+CHR$13+STR$ERL+CHR$13 in the ON ERROR bit or whatever? That should work already.

Looking at the code for the service entry it seems that at some point it was intended to accept the *BE command in either upper or lower case, hence this bit of code:

check_be:
                ; *...
                lda ($f2),Y
                and #$df
                cmp #"B"
                bne ply_and_svc_done

with the and $df to map lower case to upper case before the comparison. After checking the CR, the code to check the 2nd character doesn't do the same, though:

check_command:
                ; *B?|M
                dey
                lda ($f2),y

                ldx #LANGUAGE_MODE_NORMAL
                cmp #"E"
                beq enter_language

With the addition of a similar AND this can be made to accept either case:

check_command:
                ; *B?|M
                dey
                lda ($f2),y
                and #$df

                ldx #LANGUAGE_MODE_NORMAL
                cmp #"E"
                beq enter_language

I don't really know what the cause of this but it appears to be a combination of starting the editor with a TUBE and not being in MODE 7.

I have an BBC Master with an internal PiTubeDirect (running EggEater and upgraded to Fer-De-Lance) — I don't have a real TUBE co-pro and this might be the problem, but I don't get many (if any) other problems with it. If someone has a real TUBE co-pro, they could find out if it's a PiTubeDirect-specific issue, but I'm assuming not as things like ELITE work fine.

If I power on then Ctrl+Break the machine (I have the default MODE as 7) and type *BE, the editor starts up OK.

However, if I type MODE 6 (or any MODE other than 7) then type *BE, I just get "The BASIC Editor" then the machine hangs. Pressing Ctrl+Break recovers, although the TUBE co-pro is disabled. A second Ctrl+Break recovers the TUBE.

It makes no difference if I use the HiBASIC version or the BASIC version. I got this with 1.43 and still get it with 1.44.

It doesn't matter if I pick the various different 6502 processor options in PiTubeDirect (0, 1, 2 and 3 in Fer-De-Lance).

It doesn't matter if I pick a shadow screen mode or a normal screen mode (not that that makes much difference under the TUBE, I suppose).

I'm running MOS 3.50 but it does the same thing under 3.20.

I haven't even remotely tried to debug it, I admit! I'm not sure my EXMON skills are up to it!

Thanks and appreciation for your work on this editor.

See https://stardot.org.uk/forums/viewtopic.php?p=360513#p360513

https://stardot.org.uk/forums/viewtopic.php?p=220956#p218222

The Mode Reset error (caused by loading a program too large for the current screen mode) no longer has any effect, so you're left stuck in the wrong mode with the program all over the screen.

Quick fix would be to select MODE 135 (i.e., MODE 7 on a B), give the error, and cross fingers.

Another option would be to check file size with OSFILE and just not load it if it won't fit. (And something similar should apply to APPEND.)

editor_mode_id is 1 (command) or 2 (edit) - but this is a bit daft. It should be 0 (one) or not 0 (t'other), so that the code can do beq/bne after loading the value.

Should do a VDU12 or something...

Hello — not sure if this is actually a valid issue, but should this work on an Electron?

If I load in the regular (non-Hi) version 1.44, it sort-of works: I can mostly edit a file, but it hangs if I try scrolling the screen. Oddly the cursor doesn't flash, either.

I haven't done any investigation but I was wondering whether you knew it would be a major piece of work to get it running, or it should work and there are just some potential minor issues that need resolving (not that I'm expecting you to do it, particularly!).

I've also tried the Acornsoft 1.32 and 1.35 versions: 1.32 just hangs when I try to start it; 1.35 seems to show no cursor and hangs when I scroll, in the same way, so I don't think your updates have broken anything!

Thanks!

Renumbering with F4 takes ages. Is it doing a load of OSWRCH calls?

Maybe if nothing else it could clear the screen first. Even if that's slower, you've at least got something to watch.

Hi Folks,

Thanks for an excellent tool!

With PiTube co-pros readily and cheaply available for the beeb, have started experimenting with HiBasic and Advanced Basic so as to take advantage of the likes of While/Endwhile. Does the Basic Editor recognise the 'new' keywords? Using 1.45 it looks to change While to 'LOADACS' and Endwhile to 'EDIT'?

Thanks,
Andrew

Note

There is something at $700, but I've never previously had any reason to wonder what it is, or how much more of it there might be...

More investigation required.

You can get 33+ rows using the pi copro in native frame buffer mode. And I suppose you might be able to get it with !65Host on an Arc too.

Store stuff in the $60...$6f region (or whatever it is) that BASIC doesn't use. Might need a simple checksum or something to detect when it gets overwritten.

Have plain SAVE (abbreviation S) do a save under the default name, if there is one.

ZSAVE is then redundant.

Still need ZRUN (or equivalent) - does it need a new name? ZRUN now makes no sense, but the abbreviation Z is at least unique.

Sometimes *BZ just prints the program name, without the Saving: prefix. This must be because of