New: Console Mode editions of BBC BASIC

for discussion of bbc basic for windows/sdl, brandy and more
User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 6:10 pm

Soruk wrote:
Fri Jul 10, 2020 5:06 pm
Paste hiccup is fixed for me (and all my paste testing has been programs with line numbers). No more hanging on either Linux or RasPi. Keeping an eye out for the spurious characters....
Whilst I can see that select() returning an error condition (which my earlier code interpreted as meaning something was available on stdin) could have been responsible for the spurious characters, it's hard to understand how it could have caused a hang, so I wonder if the apparent improvement was a coincidence. Time will tell. :?

As a non-Linux expert (and that's putting it mildly!) I'm surprised that select() should ever return an error in normal circumstances. I mentioned that I had already caught it returning true and then false again on the RPi, without reading anything in between, so perhaps that was the reason for that anomaly as well. Maybe there's an inherent race hazard or something that means it cannot always say reliably whether a character is waiting, and has to return an error meaning "I don't know"!

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Fri Jul 10, 2020 6:40 pm

New version is working nicely for me - thanks!

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 6:43 pm

Soruk wrote:
Thu Jul 09, 2020 8:08 pm
BASIC V on the Archimedes introduced TEXTLOAD which can read in a text-form program
I notice that it says here that TEXTLOAD is a BASIC VI (BASIC64) feature, which is probably why I don't remember Sophie ever mentioning it back in the day:

"Features in BASIC VI...
The TEXTLOAD command can load a file that is either a BASIC program, or a BASIC program that was saved as a text file. In the latter case, TEXTLOAD automatically renumbers the program. TEXTSAVE stores a BASIC program as a text file, and strips out the line numbers
".

I wonder why it was felt desirable to introduce a new immediate-mode command rather than simply modify LOAD to recognise whether the file is tokenised or plain-text (not difficult) and be able to load either. I think that's what I would choose to do if I was tempted to add that capability to any of my BASICs.

Presumably when it says TEXTSAVE "strips out the line numbers" it's intelligent enough not to strip out any referenced by GOTO, GOSUB or RESTORE (like the equivalent feature in BB4W and BBCSDL)! I don't think I'd want to bother with a save-as-plain-text feature as an immediate-mode command.

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 6:52 pm

BigEd wrote:
Fri Jul 10, 2020 6:40 pm
New version is working nicely for me - thanks!
That's encouraging. Anything more that you'd like added to satisfy your needs? I'm not promising that I will, just interested! :wink:

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Fri Jul 10, 2020 7:25 pm

Nothing to request by way of features, thanks.

But I've just noticed something untoward: I ran a bit of "speed.bbc" and then hit Escape. Then I chained "8queens.bbc" and it started... but detected an Escape at line 460. And again on a re-run. And again. So it looks like the Escape isn't cleared, or is replicated, or something.

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 7:44 pm

BigEd wrote:
Fri Jul 10, 2020 7:25 pm
So it looks like the Escape isn't cleared, or is replicated, or something.
Hmm, I've not seen that, and needless to say I can't reproduce it here (in Windows). I'll try it later on my Mac.

If I was to guess the cause, it would be that an escape sequence that is being received in response to a cursor-position query is being seen as the escape key being pressed. I mentioned in an earlier post that I'd had to tune the timing which distinguishes between the two. All it would take is something in the system introducing a short pause between the escape character and the rest of the sequence for it to be seen as the escape key. It is an inherently fragile system, but I don't know of any other way of distinguishing between the two. :(

Time to give up and abandon the Console Mode editions I think: far too dependent on statistical factors, which is not how I like my software to work.

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Fri Jul 10, 2020 7:54 pm

It is the case, unsurprisingly, that this is a session in which I'd pasted a 75 line program. But without any apparent misbehaviour.

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 8:11 pm

Am I missing anything? On stdin I can receive an escape sequence from the keyboard (e.g. from a cursor key), an escape sequence in response to a cursor-position query, or an isolated escape character as a result of the Esc key being pressed. Is there an alternative or better way of distinguishing the Esc key from the sequences other than timing?

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Fri Jul 10, 2020 8:30 pm

This Q&A suggests that one can distinguish between ESC being the final or only character to be read, versus the case where ESC is followed by more characters. That is, an escape sequence will all be available to a read(), it won't be dribbled out.

Soruk
Posts: 763
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Soruk » Fri Jul 10, 2020 10:09 pm

Richard Russell wrote:
Fri Jul 10, 2020 6:43 pm
Soruk wrote:
Thu Jul 09, 2020 8:08 pm
BASIC V on the Archimedes introduced TEXTLOAD which can read in a text-form program
I notice that it says here that TEXTLOAD is a BASIC VI (BASIC64) feature, which is probably why I don't remember Sophie ever mentioning it back in the day:

"Features in BASIC VI...
The TEXTLOAD command can load a file that is either a BASIC program, or a BASIC program that was saved as a text file. In the latter case, TEXTLOAD automatically renumbers the program. TEXTSAVE stores a BASIC program as a text file, and strips out the line numbers
".

I wonder why it was felt desirable to introduce a new immediate-mode command rather than simply modify LOAD to recognise whether the file is tokenised or plain-text (not difficult) and be able to load either. I think that's what I would choose to do if I was tempted to add that capability to any of my BASICs.
That is exactly what Matrix Brandy does.
Richard Russell wrote:
Fri Jul 10, 2020 6:43 pm
Presumably when it says TEXTSAVE "strips out the line numbers" it's intelligent enough not to strip out any referenced by GOTO, GOSUB or RESTORE (like the equivalent feature in BB4W and BBCSDL)! I don't think I'd want to bother with a save-as-plain-text feature as an immediate-mode command.
That documentation looks wrong - unless TEXTSAVE in newer versions strips out line numbers.
TextLoad.png
It was new in RISC OS 3.1 (maybe 3.0? I don't have a copy of that ROM), ARM BBC BASIC V version 1.05. I checked RISC OS 2 (BASIC V v1.04) and it isn't there. I don't have the RISC OS 2 discs to check that version of BASIC VI (as it isn't in the ROM).
Last edited by Soruk on Fri Jul 10, 2020 10:31 pm, edited 2 times in total.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 10:17 pm

BigEd wrote:
Fri Jul 10, 2020 8:30 pm
That is, an escape sequence will all be available to a read(), it won't be dribbled out.
It doesn't work for me; it's one of the first things I tried. If you think about it, the method I am currently using, which is to measure the time between seeing the escape character and the rest of the sequence being received, would always measure it as (virtually) zero, because according to that article the entire sequence should be available immediately. So I could set a really short timeout and still reliably distinguish an escape sequence from the escape key, but that's not what I find in practice.

The big difference, I think, between what I am trying to achieve and what examples like that one are wanting to do, is that it's acceptable for their reads to be blocking: they don't need to do anything until input arrives and they can happily just sit there waiting for it. But in the BBC BASIC context that's not acceptable, typically a BASIC program is running and doing useful things whilst it is 'waiting' for escape to be pressed. That's why I am using select() to test for the availability of input whereas they are just waiting in read().

In principle I could use a blocking read too but only if I do it in another thread! It wouldn't matter if that thread was waiting in read() since the interpreter's thread would continue to run. But that would be a major rewrite with no guarantee it would work any better.

How repeatable is the issue of the 8queens program thinking the escape key has been pressed when it hasn't? Does it happen every time you run that program, irrespective of what you did beforehand? Is it only that one program that seems to do it, or do others? Is there any pattern to it at all?

Soruk
Posts: 763
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Soruk » Fri Jul 10, 2020 10:24 pm

Richard Russell wrote:
Fri Jul 10, 2020 6:10 pm
Soruk wrote:
Fri Jul 10, 2020 5:06 pm
Paste hiccup is fixed for me (and all my paste testing has been programs with line numbers). No more hanging on either Linux or RasPi. Keeping an eye out for the spurious characters....
Whilst I can see that select() returning an error condition (which my earlier code interpreted as meaning something was available on stdin) could have been responsible for the spurious characters, it's hard to understand how it could have caused a hang, so I wonder if the apparent improvement was a coincidence. Time will tell. :?
Spurious character issue, for me, has disappeared completely, both Linux x86_64 and RasPi.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Fri Jul 10, 2020 11:06 pm

Soruk wrote:
Fri Jul 10, 2020 10:24 pm
Spurious character issue, for me, has disappeared completely, both Linux x86_64 and RasPi.
Great, but clearly the Console Mode editions are fatally flawed because the discrimination between an escape sequence and pressing the escape key is not sufficiently reliable. I should probably have made them all multi-threaded from the start so I could avoid the use of select() entirely (the Windows edition is anyway, because it doesn't support select). BB4W and BBCSDL are both multi-threaded and need to be, but I convinced myself that the Console Mode editions didn't. :cry:

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Sat Jul 11, 2020 12:09 pm

Richard Russell wrote:
Fri Jul 10, 2020 10:17 pm
How repeatable is the issue of the 8queens program thinking the escape key has been pressed when it hasn't? Does it happen every time you run that program, irrespective of what you did beforehand? Is it only that one program that seems to do it, or do others? Is there any pattern to it at all?
Oddly enough, it seems always to detect escape at line 460, having printed, or started to print, solution 23. Oh no, hang on, solution 27 one time at least. But always the same line:

Code: Select all

  460 IF Y%=8 THEN PRINTTAB(58,29)" "
and nothing to do with a history of pasting, or whether it's the first program run or others have been run previously.

Programs hanoi and speed and snake and 15puzzle run fine. chess seems to be running OK too.

(Edit: I just checked an older version from 28 June, and that doesn't have this problem. The versions from 7th and 10th of July do have it.)

There must be a solution, I feel. I see the ncurses library has a parameter ESCDELAY which defaults to 1 second - surely too large a default for our purposes but it shows that the same kind of logic is needed.
Specifies the total time, in milliseconds, for which ncurses will await a character sequence, e.g., a function key. The default value, 1000 milliseconds, is enough for most uses. However, it is made a variable to accommodate unusual applications.
I run emacs in a console window, and always have, and of course emacs needs to read both the escape key as a discrete input and also escape sequences. I don't know how it does it. vi will also need to do it (if it's the kind of vi which allows cursor movement using the cursor keys.) I do see that the vi mode inside emacs uses a timeout - it is of course written in lisp, but here's the comment block (emphasis mine):

Code: Select all

;; So we try to recognize those events that correspond to the escape key and
;; turn them into `escape' events (same as used under GUIs).  The heuristic we
;; use to distinguish the two cases is [b]based, as usual, on a timeout[/b], and on
;; the fact that the special ESC=>escape mapping only takes place if the whole
;; last key-sequence so far is just [?\e], i.e. either we're still in
;; read-key-sequence, or the last read-key-sequence only read [?\e], which
;; should ideally never happen because it should have been mapped to [escape].

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Sat Jul 11, 2020 12:57 pm

BigEd wrote:
Sat Jul 11, 2020 12:09 pm
I just checked an older version from 28 June, and that doesn't have this problem. The versions from 7th and 10th of July do have it.
It was a necessary change to fix the problems Soruk was having on the Raspberry Pi, so not something I can reverse.
I see the ncurses library has a parameter ESCDELAY which defaults to 1 second - surely too large a default for our purposes but it shows that the same kind of logic is needed.
Most interesting, thanks. The delay I'm using is currently 100 ms, which sounds as though it ought to be long enough, but I could try increasing it a bit. So long as Esc is used only to abort a running program it probably doesn't matter if it's quite slow, but of course you can disable the 'error generating' action (*ESC OFF in my BASICs, *FX something in Acorn's) and then an excessively long response time could be annoying.

Soruk
Posts: 763
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Soruk » Sat Jul 11, 2020 2:02 pm

Richard Russell wrote:
Sat Jul 11, 2020 12:57 pm
I see the ncurses library has a parameter ESCDELAY which defaults to 1 second - surely too large a default for our purposes but it shows that the same kind of logic is needed.
Most interesting, thanks. The delay I'm using is currently 100 ms, which sounds as though it ought to be long enough, but I could try increasing it a bit. So long as Esc is used only to abort a running program it probably doesn't matter if it's quite slow, but of course you can disable the 'error generating' action (*ESC OFF in my BASICs, *FX something in Acorn's) and then an excessively long response time could be annoying.
*FX229,1 disables the effect of ESCAPE but still generates code 27 which PRINT GET can pick up. *FX200,1 disables the ESCAPE key entirely, PRINT GET picks up nothing. Though, that's Acorn's OS rather than the BASIC, but of course on non-Acorn platform these OS features have to be emulated.
Matrix Brandy BASIC VI (work in progress)

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Sat Jul 11, 2020 2:07 pm

(Just tested, and as expected, *ESC OFF allows 8queens to run to completion.)

(BTW, I wasn't hinting that any change should be reversed, just noting which versions did or didn't have the 8queens problem.)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Sat Jul 11, 2020 2:39 pm

Soruk wrote:
Sat Jul 11, 2020 2:02 pm
of course on non-Acorn platform these OS features have to be emulated.
Hmm, nice dig at my BASICs! I never have emulated them, indeed generally I don't support *FX commands (latterly I have supported *FX15 and *FX21 in a limited way, but that's all). Apart from anything else, there are scores of *FX commands so it's a Pandora's box I don't want to open.

It makes more sense for Matrix Brandy, which is marketed as an emulator, to do so, but I don't feel a need to emulate the majority *FX commands when there are much more fundamental differences between my BASICs and Acorn's (not least screen resolutions and colours).

In my BASICs you can disable the error action of the Escape key with *ESC OFF but there's no way of stopping it generating a code at all (I've no idea why Acorn thought that might be useful, really).

Soruk
Posts: 763
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Soruk » Sat Jul 11, 2020 2:42 pm

Richard Russell wrote:
Sat Jul 11, 2020 2:39 pm
Soruk wrote:
Sat Jul 11, 2020 2:02 pm
of course on non-Acorn platform these OS features have to be emulated.
Hmm, nice dig at my BASICs!
Not a dig at all and I mean no disrespect at all to your BASICs. I wouldn't dream of it.

As Matrix Brandy does aim to give more of a RISC OS feel, I choose to emulate using *FX / OSBYTE than separately implementing a way to disable ESCAPE. It's just the way our platforms have developed evolved. I also only implement a small selection, though more than upstream.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Sat Jul 11, 2020 2:57 pm

There's only one remaining 'simple' change that I've been able to make, and that is for the Linux (including Raspberry Pi) and MacOS editions to handle console input the way the Windows edition does: in a separate thread. This really ought to be a retrograde step, because it introduces even more timing uncertainty (thread scheduling and context switches now contribute to the input latency). But it does have the advantage that I can dispense with calling select() altogether, which may be of some value since - for reasons I don't understand - it has been misbehaving for me.

I have made this change in version 0.20, available from the usual place. I am far from confident that it will help, and it could even make things worse. Unfortunately my testbeds here are not very representative of typical users: my Linux platform is an ancient AMD Athlon 64 (single core) CPU and my Mac testbed is a Mac Mini which is desperately slow.
For the moment I've left the Escape delay as 100ms, even though that is far lower than the default of 1 second used by ncurses, so as not to make too many changes at the same time. Anything much longer than that risks being unacceptable if Esc is being used as an 'ordinary' character, returning code 27 to GET or INKEY.

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Sat Jul 11, 2020 3:36 pm

That's working well for me - thanks!

Soruk
Posts: 763
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Soruk » Sat Jul 11, 2020 4:07 pm

I'll test in a bit, out for a walk with the mini monster...
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Sat Jul 11, 2020 4:53 pm

BigEd wrote:
Sat Jul 11, 2020 12:09 pm
Oddly enough, it seems always to detect escape at line 460
Just to come back on that one, I don't think it's particularly "odd" because it's only going to fail (in that manner) when the response to a 'query cursor position' escape sequence is misinterpreted as the Esc key being pressed, and it's one of the few places in the program where such a query will be made (the PRINT statement has no terminating semicolon so does a CRLF, and the LF triggers the cursor position query). Most of the other PRINT statements have a trailing ; and won't provoke a query. So at least failing at that line has the merit of making sense, even if the reason for the escape sequence being misread isn't clear.

I know of at least one way in which the approach I'm currently adopting can fail. To make it possible to paste a significant amount of text I am, as you know, aborting the cursor position query when the keyboard buffer is approaching being full. But the escape sequence has already been sent so eventually the response is going to be received on stdin (indeed probably multiple responses, maybe dozens or hundreds of them) after the pasted text. These are normally harmlessly discarded but if a genuine cursor position query is sent at the same time, one of those long-delayed responses may well be used to provide the (incorrect) cursor position!

The Windows approach of 'jamming' the response at the front of the stdin queue seems to be better than the Linux one of adding it after the pasted text, but one can understand how that might not have occurred to the programmers. Anyway if it's a remote terminal connected via a serial or ethernet link it may be impossible to 'jump the queue' (and it's in just such a situation that my 100ms delay might not be enough).

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Sat Jul 11, 2020 5:32 pm

> the PRINT statement has no terminating semicolon so does a CRLF, and the LF triggers the cursor position query

Aha! Thanks, makes good sense.

Soruk
Posts: 763
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Soruk » Sat Jul 11, 2020 9:47 pm

Soruk wrote:
Sat Jul 11, 2020 4:07 pm
I'll test in a bit, out for a walk with the mini monster...
Working for me too. Pasting, ESCAPEing from a program.
Matrix Brandy BASIC VI (work in progress)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Sun Jul 12, 2020 10:15 am

Soruk wrote:
Fri Jul 10, 2020 5:06 pm
A typed CTRL-U shouldn't disable VDU, instead it should delete the line.
Strictly speaking, it should delete the part of the line to the left of the cursor (caret). The distinction is moot with Acorn's BASICs/OSes since the line input routine doesn't normally allow you to position the cursor anywhere other than at the end of the line, so the line to the left of the cursor is necessarily the entire line!

But that's not the case with my BASICs which support Ctrl+U: BB4W, the 32-bit x86 editions of BBCSDL and the latest Console Mode version. They all support line editing, so you can move the cursor through the line with the arrow keys; in that case Ctrl+U won't (and shouldn't) necessarily delete the entire line. Indeed, if the cursor is at the beginning of the line it will have no effect at all.

User avatar
1024MAK
Posts: 10080
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by 1024MAK » Sun Jul 12, 2020 1:41 pm

I have a question, I realise that these versions are designed to run on modern computers using terminal programs that run on the same system as the application that is using them.

Some OS allow pipes to reroute data streams from/to other services. I happen to have a real “VT-100” like terminal. Would one of these running on a modern computer work with the input/output routed to a RS232 serial port (either a real RS232 port or via a virtual port to USB and then via a USB/RS232 converter)?

Mark

User avatar
BigEd
Posts: 3173
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by BigEd » Sun Jul 12, 2020 1:56 pm

(I would certainly think so! Provided the terminal in question obeys the same escape sequences as BBC Basic is sending and using, which is some variation on VT100: "Fortunately most consoles/terminals, on all popular OSes, are designed to accept VT-100 escape sequences." I say variation, because VT100 was a monochrome device. I do have a VT320, but I've never tried to hook it up.)

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Sun Jul 12, 2020 3:53 pm

1024MAK wrote:
Sun Jul 12, 2020 1:41 pm
Would one of these running on a modern computer work with the input/output routed to a RS232 serial port (either a real RS232 port or via a virtual port to USB and then via a USB/RS232 converter)?
In principle, yes. The escape sequences are VT-100 compatible (although of course some are extensions that cannot work on a physical terminal, such as changing the number of rows and/or columns to emulate MODE). My main concern would be whether my 100ms timeout was long enough; if the real terminal (at whatever baud rate it is connected) takes more than 100ms to respond to the 'query cursor position' escape sequence, my code will think that Escape has been pressed. Really the only way to find out is to try it.

User avatar
Richard Russell
Posts: 1552
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: New: Console Mode editions of BBC BASIC

Post by Richard Russell » Mon Jul 13, 2020 11:40 am

I have updated the Console Mode editions of BBC BASIC to version 0.21.

The main change in this release is that the LOAD command (only available in immediate mode) will now load a program in plain-text format as well as in ('Russell') tokenised format; it will accept both CRLF and LF line endings (but not reliably LFCR, which I think Acorn machines can sometimes generate). Line numbers will be automatically added if necessary. It still won't load Acorn-format tokenised programs (the BB4W and BBCSDL IDEs will), although no error will result.

Version 0.21 may be downloaded from the usual place:

Post Reply

Return to “modern implementations of classic programming languages”