Updated BASIC Editor

[tom_seddon]

(3) When editing – it would be a good feature if you could follow a jump or procedure – possibly by holding down a key combination – and returning, in the case of a procedure.

I am not sure how hard this one would be.

This has been rolling around in my mind for a day or two, and I thought of this hacky idea for a pound shop cross reference type of function:

If you're looking at an identifier, preceded by 0+ spaces, preceded by PROC, you're looking at a proc name. (And something similar applies to FN names too.)

When you hit the xref key, run this check on the cursor position. If it passes, the cursor was on a proc name. Note that proc name, and do a FIND for all occurences of it.

This would potentially produce too many results. So, to make this actually work nicely, improve/hack the FIND mechanism so that when initiated by the xref command (rather than by FIND or IFIND), it runs the above proc name check on each found occurrence, and also checks that only the full name matches rather than the prefix. Each match only counts as an occurrence if these check passes - so if you search for proc X, say, "DEFPROCX:" counts as an occurrence, but "X%=5" doesn't, nor does "DEFPROCXYZ".

The detokenized text is easily available so I figure you'd just do all of this by matching strings. For bonus points, skip stuff in REM and DATA statements - probably not a big deal though.

For returning, why not a general-purpose find location stack, which might be useful for FINDs anyway? - there's potentially some space free in zero page before you hit $70 that could be used for this. (Note the official BASIC Editor Zero Page Promise! Money back guarantee if not 100% satisfied) Another option might be to book some space at the top of page 1. The stack pointer is initialized to $ff on entry to the rom, but I bet it could be $e0 and there'd be no problem. I figured you'd be good just storing line number/offset in line, so 3 bytes per entry. 32 bytes gives you 10 entries... just how complicated are your BBC BASIC programs anyway?!

For GOTO and GOSUB, I reckon the xref command should just check if you're on a number - any number - and use the existing go to line functionality (preceded by a push to the location stack). You could go to the trouble of checking that you're actually on a GOTO, but this would probably become a bit fiddly with the comma-separated ON...GOTO syntax.

--Tom

[Coeus]

This would potentially produce too many results. So, to make this actually work nicely, improve/hack the FIND mechanism so that when initiated by the xref command (rather than by FIND or IFIND), it runs the above proc name check on each found occurrence, and also checks that only the full name matches rather than the prefix. Each match only counts as an occurrence if these check passes - so if you search for proc X, say, "DEFPROCX:" counts as an occurrence, but "X%=5" doesn't, nor does "DEFPROCXYZ".

I did find a subroutine in the other ROM, which is what I have been looking at in the last day or so, called findproc:

Code: Select all

.'FINDPROC
 LDY#1
 LDA(&37),Y
 LDY#&F6 \PROC offset in cat' page
 CMP#&F2 \PROC token?
 BEQ Z946F
 LDY#&F8 \FN offset
 BNE Z946F

but I am not sure this does the right thing. I think it is intended to find a procedure once execution has started and BASIC has built a linked list of procedure and function names, using code shared with variable lookups which is the next thing in the module I have been looking at. Presumably, when editing, this list doesn't exist. I am not even sure if that subroutine is called in the 2nd ROM - it seems to be a bunch of stuff, including the keyword table and the code to tokenise and detokenise BASIC lines that have been disassembled from the BASIC ROM itself.

So when hitting this XREF key it would be possible to search backwards from the cursor for a possible PROC or FN and forwards for a character that is not valid in a PROC/FN name to give the thing to then give to the search function. Do you know if the editor knows the cursor position within the tokenised version of the current line? The only complication I can see is if there is a space between PROC and the name in the invocation and none in the DEFPROC or vice versa, assuming either of these is valid - I haven't tested it.

For returning, why not a general-purpose find location stack, which might be useful for FINDs anyway? - there's potentially some space free in zero page before you hit $70 that could be used for this. (Note the official BASIC Editor Zero Page Promise! Money back guarantee if not 100% satisfied) Another option might be to book some space at the top of page 1. The stack pointer is initialized to $ff on entry to the rom, but I bet it could be $e0 and there'd be no problem. I figured you'd be good just storing line number/offset in line, so 3 bytes per entry. 32 bytes gives you 10 entries... just how complicated are your BBC BASIC programs anyway?!

Are there any other commands that suddenly go off to some other part of the program. I think a lot of usefulness could be had by just remembering one previous location, so minimal workspace needed, that would allow to flip between two points in the program. That would also require only one key binding vs. two for a forward and back version. More than one entry is probably slightly better but if that starts to get complicated or space is short then I don't think going back more than one location matters that much.

For GOTO and GOSUB, I reckon the xref command should just check if you're on a number - any number - and use the existing go to line functionality (preceded by a push to the location stack). You could go to the trouble of checking that you're actually on a GOTO, but this would probably become a bit fiddly with the comma-separated ON...GOTO syntax.

I don't see the point of checking for an actual GOTO - just search back and forwards from the cursor to find digits and then search for that re-using as much code as possible from the existing goto line feature.

[daveejhitchins]

If you're looking at an identifier, preceded by 0+ spaces, preceded by PROC, you're looking at a proc name. (And something similar applies to FN names too.)
I'm probably missing something here and the following may be not feasible (!?): Wouldn't you just place the cursor at the beginning of a PROC, DEFPROC or GOTO - Do a search - fails > issue an error - finds a match > proceed to the line, saving the originating line number - lastly limit the number of jumps and add the ability to clear the search count. There are enough spare FUNC keys . . .

When you hit the xref key, run this check on the cursor position. If it passes, the cursor was on a proc name. Note that proc name, and do a FIND for all occurrences of it.

This would potentially produce too many results. So, to make this actually work nicely, improve/hack the FIND mechanism so that when initiated by the xref command (rather than by FIND or IFIND), it runs the above proc name check on each found occurrence, and also checks that only the full name matches rather than the prefix. Each match only counts as an occurrence if these check passes - so if you search for proc X, say, "DEFPROCX:" counts as an occurrence, but "X%=5" doesn't, nor does "DEFPROCXYZ".
Yes, that search could also be added to the functionally!

The detokenized text is easily available so I figure you'd just do all of this by matching strings. For bonus points, skip stuff in REM and DATA statements - probably not a big deal though.
Pass or fail, that would be a User Error! But would be a nice addition.

For returning, why not a general-purpose find location stack, which might be useful for FINDs anyway? - there's potentially some space free in zero page before you hit $70 that could be used for this. (Note the official BASIC Editor Zero Page Promise! Money back guarantee if not 100% satisfied) Another option might be to book some space at the top of page 1. The stack pointer is initialized to $ff on entry to the rom, but I bet it could be $e0 and there'd be no problem. I figured you'd be good just storing line number/offset in line, so 3 bytes per entry. 32 bytes gives you 10 entries... just how complicated are your BBC BASIC programs anyway?!
Wouldn't there already be a "general-purpose find location stack" that's used for the current FIND ? My largest program, or will be on completion, is the MGC MKII program.

For GOTO and GOSUB, I reckon the xref command should just check if you're on a number - any number - and use the existing go to line functionality (preceded by a push to the location stack). You could go to the trouble of checking that you're actually on a GOTO, but this would probably become a bit fiddly with the comma-separated ON...GOTO syntax.
I think the only way to go would be where the cursor is e.g. it MUST be at the start of a DEFPROC, PROC or GOTO!

I've only just had a glance at Tom's changes. These are "my" thoughts:
Insert mode is now the default. - agree with this one.
The COPY key deletes forward, like SHIFT+DELETE. - I think the Shift Delete is more than good enough!
Use SHIFT+left arrow to move the cursor to the beginning of the line, and SHIFT+right arrow to move it to just past the end. - not possible on the Electron. However, there are spare Function keys!
Use CTRL+left/right arrow to move the cursor between places where you can (probably) add a new statement. The cursor stops at the beginning of a line, after a :, or just after the end of a line. - as above. Again, there are spare Function keys!
If the program has a REM> (see above), press SHIFT+f9 to save it from edit mode, like ZSAVE, or CTRL+f9 to save it and run it, like ZRUN.
If the first line is a REM>, you can use *BZ to do a ZSAVE from inside BASIC, and use *BR to do a ZRUN.
Would love this feature! I'm happy with just Save and Run from the command screen e.g. none of the extra, as above - but there would be a need for a Save As! This would negate the requirement of the UPDATE command.

HIBASIC Editor
Would be a really nice feature to add.

Dave H.

[elk1984]

I now have PCBs and will be making some up over the next few days. They'll cost around £15 for the ROM Module, User Guide and Keystrip - including UK P&P.

Hi Dave, did you produce any of these? Is it a cartridge for the Electron?


Elk1984

[daveejhitchins]

I now have PCBs and will be making some up over the next few days. They'll cost around £15 for the ROM Module, User Guide and Keystrip - including UK P&P.

Hi Dave, did you produce any of these? Is it a cartridge for the Electron?


Elk1984

I have the 'module' version now, however, not had chance to look at the cartridge version, as yet. I'll announce when it's ready.

Dave H.

[hoglet]

(continued from here)

Ah, excellent, I'm glad to hear you've become a convert. I've long liked this ROM, ever since I first encountered it at school around 1990. Despite some mystifying defaults, now fixed, I immediately found it a really nice upgrade over the ordinary copy-key-heavy basic editing experience. And so, here I still am, in 2022

I've posted a few wip bits to the wip/stuff branch in the repo:

• leave mode alone on startup - unless <40 columns, in which case select mode 135

That seems reasonable to me.

[*]do an initial pass on the code to try to eliminate any mode-indexed tables. There are still some special cases for mode 7 in particular (the annoying doubled-up interlaced sync+video scanline counter affects the cursor start/end settings...) but those are handled by checking for mode number 7 specifically

FYI, PiTubeDirect has a couple of additional teletext modes: MODE 70 (which is 60x25) and MODE 71 (which is 80x25).

So I'm wondering if you could include these in the special casing?

If you want a more generic way to determine if a mode is a teletext mode, then it can be inferred from the VDU variables:
https://beebwiki.mdfs.net/OSBYTE_%26A0

Maybe bytes-per-character (&4F) would be best, as this is 1 in teletext modes, and >1 in all other modes?

I can add this to the PiTubeDirect VDU variables that OSBYTE &A0 returns.

[*]set CRTC registers using VDU 23,0

I've just added support for VDU 23,0 (regs 10/11 only) this is working nicely against your wip branch.

It does gets confused in MODE 70/71, because these are not currently give the teletext special treatment by the Basic Editor.

[*]foreground is colour 1, background is colour 0. This setting currently sticks on exit back to basic... not sure what the fix for this is. I could do a VDU 20 then COLOUR 128 then COLOUR 7, I suppose? But while that'd cover the 8-bit modes, is it good enough for the extended set?
[/list]

Initially I thought this was a good idea, because it's fiendishly difficult to determine the current text foreground colour:
https://beebwiki.mdfs.net/Reading_current_colours

But this change does cause a minor issue with the PiTubeDirect cursor.

PiTubeDirect's cursor is implemented in software (like on the Electron) by XORing the cursor (logic colour white) into the framebuffer. That's fine in 2-colour modes. But in 4 colour modes, colour 1 inverted becomes colour 2 (yellow by default). And in 16-colour modes, colour 1 inverted becomes colour 6 (cyan by default).

It's not an issue on the Beeb, because the cursor operates by inverting the physical colour (i.e. after the palette).

It should be possible on the Pi to implement a hardware cursor (using the GPU to do the XOR compositing). But so far I haven't been successful at getting this to work yet. Maybe I should try again, because it would make the code much simpler and more robust.

As the branch name might suggest, this is a bit of a work in progress. I'll feel more confident about it once I've actually used it in anger for a while. But I note that it's saved a nice 40-odd bytes, as well as (hopefully) ensuring compatibility with a wider range of VDU drivers, so I'm happy.

I'll continue to use this for testing.

I do still need to look into this bit of code though: https://github.com/tom-seddon/basic_edi ... .s65#L2299

I've also done nothing about the 32 row limit so far other than add a GitHub issue about it: https://github.com/tom-seddon/basic_editor/issues/24

I'll add a couple of comments to that issue.

P.S. I wonder how much use the foreground/background colour selection actually gets. I always use the default white on black. Maybe I could strip this all out?

I do like editing with a blue background.

Rather than actively change the colours, could you instead be careful to never actually change MODE?

(i.e. use VDU 12 to clear the current text area, rather than MODE 22,n)

Dave

[Coeus]

P.S. I wonder how much use the foreground/background colour selection actually gets. I always use the default white on black. Maybe I could strip this all out?

I do like editing with a blue background.

Rather than actively change the colours, could you instead be careful to never actually change MODE?

I quite like having green text on a black background, probably because, BITD, I had a Phillips green screen monitor as well as the RGB output connected to a modified TV so for reading 80 column text I'd use the green screen and for colour things, the TV.

So I also quite like BE setting that colour scheme for me and I have also patched the version of the ROM I use to make that the default - creating a *EXEC file to set up defaults as suggested in the manual seems a bit long winded especially as there doesn't seem to be a way to have BE execute it automatically upon entry. That, in turns, is presumably for tape systems where one would not want it searching for an EXEC file on TAPE each time you start it.

It's also not really an issue if the colour palette is left unmodified on return to BASIC. Many programs change mode and establish their own palette if required anyway.

[tom_seddon]

If you want a more generic way to determine if a mode is a teletext mode, then it can be inferred from the VDU variables:
https://beebwiki.mdfs.net/OSBYTE_%26A0

Maybe bytes-per-character (&4F) would be best, as this is 1 in teletext modes, and >1 in all other modes?

Good idea. I've made this change and will push later. (If bytes per character < 2, it's a teletext mode.) That also eliminated the other mode check I mentioned, so the ROM now never checks the mode number.

PiTubeDirect's cursor is implemented in software (like on the Electron) by XORing the cursor (logic colour white) into the framebuffer. That's fine in 2-colour modes. But in 4 colour modes, colour 1 inverted becomes colour 2 (yellow by default). And in 16-colour modes, colour 1 inverted becomes colour 6 (cyan by default).

Hmm, how about if the ROM sets colours 128 and 127 on startup, and then uses VDU 19,127,n;0;? Would that work any better? Would that cover 256 colour modes as well? (I never had an Arc, so I don't know how the 256 colour modes might work!)

That would certainly work for all the Beeb modes, especially since the ROM is no longer supporting mode 2. So doing a colour 127 is selecting what would be the default text colour anyway.

I'll add a couple of comments to that issue.

Thanks! I'm going to spend a bit of time on this later, and I'll add any further notes there.

Rather than actively change the colours, could you instead be careful to never actually change MODE?

(i.e. use VDU 12 to clear the current text area, rather than MODE 22,n)

It should already never change mode in normal operation, other than the possible mode 135 switch on startup (already discussed), or by request with the MODE command. But it does do a VDU20 on startup. Maybe it shouldn't. BASIC leaves the colours alone, so perhaps the editor should too?

--Tom

[hoglet]

Hmm, how about if the ROM sets colours 128 and 127 on startup, and then uses VDU 19,127,n;0;? Would that work any better? Would that cover 256 colour modes as well? (I never had an Arc, so I don't know how the 256 colour modes might work!)

I don't think that will work as you expect, because COLOUR 127 and VDU 19,127 will very likely refer to different logical colours.

In RISC OS (and in PiTubeDirect), 256 colour modes use a 6-bit COLOUR and a 2-bit TINT, rather than an 8-bit COLOUR. This was because the existing commands VDU 17/18 already used bit 7 to distinguish between foreground and background. So a new API (VDU 23,17) was added to provide the 2-bit TINT.

I think the value written to the frame buffer ends up being BBGGRRTT, where BBGGRR come from COLOUR (VDU 17/18) and TT comes from TINT (VDU 23,17).

On machines like the Archimedes there were also constraints on the palette in 256 colour modes, because there were only 16 palette registers. On the Pi the 256 colour modes have a flat 256-entry palette, so those restrictions don't exist.

So if you want to set the text foreground to logical colour 255, you need to do something like:

Code: Select all

VDU 17,63
VDU 23,17,0,192,0,0,0,0,0,0

where the VDU 23,17,0 is setting the text foreground tint (in bits 7/6).

Similarly, to set the text background to logical colour 0:

Code: Select all

VDU 17,128
VDU 23,17,1,0,0,0,0,0,0,0

where the VDU 23,17,0 is setting the text background tint (in bits 7/6).

Then VDU 19 will work as expected on logical colours 0 and 255 (at least on PiTubeDirect it should).

This is a significant pain!

But it does do a VDU20 on startup. Maybe it shouldn't. BASIC leaves the colours alone, so perhaps the editor should too?

Ah, I missed that.

I did try setting a colour scheme up first, and noticed it was reset, so assumed it was doing a mode change.

Dave

[tom_seddon]

I've made a new release, 1.46: https://github.com/tom-seddon/basic_edi ... r/releases

Not all that much has changed, but it now generates a relocatable ROM for possible use with MOS 3.50.

--Tom

P.S. the 32 row limit and colour selection issues have not been forgotten... as you can maybe tell from the release cadence, this has just not been a priority project for me recently, not least because it mostly does what I need. But I would like to get this stuff fixed!

[rharper]

I had a look at the new BASIC Editor and was interested in the Electron version which was a single ROM rather than the original dual ROM for the Electron.
I could not find any reference to the function key controls and they were not the same as the original Electron ones.
So I have made a function key strip for this Electron Basic Editor. It is a LibreOffice Calc file that gives a strip essentially the same dimensions as the original View/ViewSheet ones.
I could not find any response to 0, I, P, H, X or M.
R and Z both gave a 'No REM' error which is not an error listed in Appendix D of the guide. There were lots of REMs in the test file.
Ray
Strip edited to include information supplied below.

[tom_seddon]

I had a look at the new BASIC Editor and was interested in the Electron version which was a single ROM rather than the original dual ROM for the Electron.
I could not find any reference to the function key controls and they were not the same as the original Electron ones.
So I have made a function key strip for this Electron Basic Editor. It is a LibreOffice Calc file that gives a strip essentially the same dimensions as the original View/ViewSheet ones.
I could not find any response to 0, I, P, H, X or M.
R and Z both gave a 'No REM' error which is not an error listed in Appendix D of the guide. There were lots of REMs in the test file.
Ray

Thanks! I need to add a link from the releases page to the documentation page - the current arrangement is unhelpful if you're not a regular GitHub user. There is some documentation for the updates, hopefully complete though perhaps a bit brief, including an Electron key reference and some notes about the REM> and the "No REM>" error is referring to: https://github.com/tom-seddon/basic_edi ... ocs/doc.md

I'll add a note about the No REM> error. Since the original docs have an error list the list of updates should include a note about new errors too.

--Tom

[Mince]

I posted a file with the key strip for the Electron a while back but it’s originally an OmniGraffle file. There’s a PNG of it here: https://www.stardot.org.uk/forums/viewt ... 7&start=60

The OmniGraffle file makes it easy to produce new strips but the PDF is fine just to print.