Bug report : 1 Mar 2020 : PE6 Terminal, control character behaviour ?

Buzby

Senior Member
Rich (BB code):
#picaxe 28X2

sertxd("123456789",cr,lf)
sertxd("123456789")
sertxd(8,8,8,8,8,"-")
produces ...

123456789
1234-789

I would have expected the result to be '1234-6789'

What am I doing wrong ?

PE6 control codes.PNG
 
Last edited:

Buzby

Senior Member
It would be really cool if the terminal could utilise control characters better. This is what I expected when I read this line on page 16 of the PE6 document : "Control characters can be optionally used to navigate about the receive box".

I was expecting something that would let me move the cursor up as well as back, or even some VT100 emulation.

I have in the past used a 3rd party terminal to get the type of control needed, but that only worked with a real chip, and meant lots of cable swapping and switching windows.

Could it be possible to have an option in Settings that let the user select an alternative terminal program for PE6 simulation ?.

The PE6 Terminal is the most useful interface to the Simulator, it would be so much more useful if it could act as a 'screen', not just a 'lineprinter'.

Cheers,

Buzby
 

Buzby

Senior Member
I would guess it's some kind of bug or unanticipated interaction with the text display widget. It's something we would have to investigate.
Hi hippy,

Is there any confirmation that this is being investigated ?. I could really do with it working.

Cheers,

Buzby
 

hippy

Technical Support
Staff member
s there any confirmation that this is being investigated ?. I could really do with it working.
No and I wouldn't hold your breath; creating a VT100 emulator or similar, or even simpler, is something of an undertaking.
 

Buzby

Senior Member
A VT100 emulator is not what I was asking about. I was asking if the stuff already in PE6 is being investigated.

The dropdown in terminal settings has the backspace ( $08 )tickbox, but the result is not as expected.

I don't expect Rev-Ed to wtite a VT100 emulator at all. My suggestion is to allow PE6 to use a 3rd party terminal as an alternative to the built-in version. Interfacing to a 3rd party terminal window ( maybe even something from whatever library of stuff PE6 is built with ) will be much easier than any roll-your-own solution. One of the reasons we were told for developing PE6 was to simplify adding new functionality.

Cheers,

Buzby
 

Buzby

Senior Member
Are Rev-Ed looking into this backspace bug ?

The manual says backspace should work, but it doesn't.
 

Buzby

Senior Member
Are Rev-Ed looking into this backspace bug ?

The manual says backspace should work, but it doesn't.
 

Buzby

Senior Member
Thanks for your support !.

A look through the revision history shows this in PE 6.0.6.3

6.0.6.3
00385 BS [08] special function in Terminal now overwrites characters from current cursor position instead of at end of text.

So it looks like there was a different BS bug at first, but the fix for that bug has introduced another bug !.
 

Goeytex

Senior Member
Many other terminal apps process a BS as "destructive" that is , it overwrtes the previous character as it moves backwards. So I would not call this a bug, but rather an unexpected change. I actually prefer a destructive backspace in most cases.

Ideally the terminal app should allow you to choose whether the BS is destructive or not, but few do.
 

Buzby

Senior Member
The current BS behaviour in PE is neither 'destructive' nor 'non-destructive', it's just plain broken !.

If it was 'destructive', my code in post #1 would result in :
Before : 123456789
....After : 1234-

If it was 'non-destructive', the result would be :
Before : 123456789
....After : 1234-6789

The way it works now :
Before : 123456789
....After : 1234-789

A 'destructive' backspace is called Delete, and is coded in ASCII as chr 127, DEL.
Any terminal emulator that deletes when it should be doing a backspace is wrong, unless is has the option to select 'destructive' or not.

It's been over a year since I pointed out this incorrect behavior of PE, and still no fix for it.
 

Flenser

Senior Member
It's been over a year since I pointed out this incorrect behavior of PE, and still no fix for it.
Buzby,

You reported this terminal issue around the start of the pandemic so keep in mind that while children have not been attending school their teachers have likely not been purchasing many PICAXE products which has led to RevEd needing to put some staff, like Hippy, on furlough.
 

Buzby

Senior Member
Hi hippy,

That's a hopeful response, but as you know, my real requirement is for a more capable terminal, with addressable screen locations.

I fully understand that writing a VT100 emulation is beyond Rev-Ed's remit, and that's why I asked for the option to use a 3rd party application such as Terraterm or RealTerm.

Ten years ago we were told that one of the reasons for developing PE6 was that it would make 'fixes and new features' easier to implement.

A quick hexdump of PE6 shows the basis for impementing 3rd party functions has already been addressed, to some degree.

'Foreign_Quick_Syntax', 'Foreign_Simulation', and 'Foreign_Serial_Terminal' all appear as text strings in PE6.

Why would these strings be there if they don't have any purpose ?

Cheers,

Buzby
 

Buzby

Senior Member
Perhaps the "Foreign" just means non-Engllish?
I would not have thought that. If they were language related I would expect to either see more of them, or see 'foreign' words in there somewhere.

A 'foreign syntax check' could allow for a special version of a chip, like a 28X2_XP, which might have different features, which would then need a 'foreign simulator' for testing.

Adding a 'foreign terminal' should be a fairly simple task for a programmer experienced with the tools used to build PE6.

Even adding an X3 should not be too difficult, even I can make a good effort .....PE6_X3.PNG ... :)

( Yes !. That really does let me select a 20X3, compile it, and run a simulation, but I should have waited till April 1st before posting. )

Cheers,

Buzby
 

hippy

Technical Support
Staff member
Perhaps the "Foreign" just means non-Engllish?
Almost certainly. Looking through the executable for occurrences of "Foreign"...
Code:
Foreign_Quick_Syntax
Foreign_Serial_Terminal
Foreign_Simulation
Foreign
Foreign_TranslateFormControls
Get_Foreign_Serial_Terminal
Foreign_TranslateDockingManager
Foreign_Dictionary
The non-PE6 code I worked on used a variant of Foreign("The English Text") where it had text which should be translated at run-time, and I would guess it's similar for PE6. That Foreign only appears once because it's the name of the function, doesn't reflect the number of calls made to it. I don't know what the rest are but I guess they were the edge cases where the normal practice wasn't appropriate or are calls to routines which perform a set of translations. For example Foreign_TranslateFormControls would translate all the text of all controls on a particular form.

As for the lack of foreign language words and phrases in the executable; those are dynamically loaded from files in -

C:\ProgramData\Revolution Education\PICAXE Editor\Settings\Languages
 

papaof2

Senior Member
I would expect PE6 to check for the Language setting of the PC and then use the proper translation file(s) for that PC and it appears that's how it works.
 

Buzby

Senior Member
It does look the 'foreign' relates to language, but it should still not be too difficult for Rev-Ed to allow for a 3rd party terminal.
 

papaof2

Senior Member
The third party terminal shouldn't be hard but you won't know for certain until you see the code. Not every snippet of code is functionally correct, logical, readable and easily modified. Been there; had to fix that :-(

In the distant past, I purchased a C compiler for a 6809-based system and found that the toupper() and tolower() functions did not handle characters correctly - it's only supposed to process a-z and A-Z but the original programmer processed ALL characters, including numbers and punctuation. I learned enough 6809 assembly language to be able to correct that library. One of many "I need to learn another language" events ;-) I also learned enough PDP 11/70 to be able to patch the compiled code (no source avaiklable) on a Unix system which didn't work as we needed. I think that may give me hacker status ;-)
 

Buzby

Senior Member
The third party terminal shouldn't be hard but you won't know for certain until you see the code. Not every snippet of code is functionally correct, logical, readable and easily modified. Been there; had to fix that :-(

I disagree.

One of the benefits we were told PE6 would provide was the ease with which the PE6 developers would be able to add more goodies.

Modern high-level languages on a PC are nothing like assembler on a 40 year old microprocessor.

I'm not a developer of code that runs on Windows, except maybe with VB6 a few years ago, but I do know that nowadays with all the COM and OLE stuff, and whatever new inter-operatabiliy features there are, it should not be difficult to re-direct the terminal data to a 3rd party application.

This thread started when I reported a bug in the existing terminal system, a bug which has still not been fixed over two years later !.
 

Buzby

Senior Member
Will this bug ever get fixed ?
I seem to be talking to myself here !

I'm losing faith in Rev-Ed.

Why is such a simple bug being ignored for years ?.

Is it because Rev-Ed have not got enough staff who are capable of editing the source code to PE6 ?.

Was PE6 actually written in-house by Rev-Ed employees, or was it out-sourced to some fly-by-night who is no longer available ?

Whatever the reason, this lack of response doesn't look good.

Not a Happy Bunny,

Buzby
 

Buzby

Senior Member
A total of five employees does not seem enough to handle all the aspects of a business that deals with education establishments worldwide. This would seem to indicate that maybe certain aspects of the business are outsourced.

We can see that PE6 uses obfustication services from smartassembly.com. If a 3rd party developer was contracted to supply PE6, but retained control of the source code, then not even Rev-Ed would have the ability to fix bugs.

It looks like the last release of PE6 was 6.1.0.0 in 2018. That's five years ago.

Has Rev-Ed fallen out with the PE6 developer ?.
 

kfjl

Member
I would have fallen out with a developer who wrote buggy code for me, and then refused to fix it.
But falling out is childish and the people at Rev-Ed are big enough to give someone a second chance.
That's why the PE6 developer is currently hanging by his reproductive organs at Unit2, Foxcote avenue, until he has finished PE7 with support for ESP Basic.
 

papaof2

Senior Member
Possibly it wasn't so much refusal to fix as the inability to fix? Also known as "getting in over your head".

Or perhaps a discussion:
"You were contracted to do X, Y and Z. Y does NOT work."
"Yes, but the contract hours are up. That fix will take another 100 hours and I don't work for free."
"You did not meet the contract terms so you do NOT get the completion bonus of XXXX pounds/dollars/lira/yen/whatever."

Most programmers know their limits. Unfortunately, some are not willing to admit those limits to themselves and certainly not to a paying customer..

There are sometimes people in the hiring process who don't know enough about the programming process to know who NOT to hire.
And you might also hear "Better the devil you know than the one you don't." during hiring discussions.

Pick one or more reasons ;-)
 

Buzby

Senior Member
... That's why the PE6 developer is currently hanging by his reproductive organs at Unit2, Foxcote avenue, until he has finished PE7 with support for ESP Basic.
I'm not compaining about the lack of PE7, it's the simple fault in PE6 that's irking me.

One of the major reasons we were told PE6 was developed was because PE5 was difficult to maintain, and PE6 was going to be so much easier to fix and add new features.
 

kfjl

Member
I use LinAXEpad so I'm not complaining about the lack of PE7 either. I don't even use PE5 which works on linux. I don't like whistles and bells.

I was emitting a few camouflaged hypotheses:

If Rev-Ed is really working on PE7, they're not going to bother (waste money) fixing "cosmetic" bugs in PE6.
ESP is eating away at the arduino market. It's an arduino killer. Rev-Ed have superbly ignored it, even though ESP basic already exists.
So maybe Rev-Ed are just waiting to die and will carry on as long as at least one person can make a living out of it.

If I were a school kid I wouldn't be very interested in blinking leds if the kids from the neighboring school were playing with camera buggies controlled by their cell-phones.

And I certainly wouldn't like to be the led-blinking teacher!
 

pleiser

Senior Member
I seem to be talking to myself here !

I'm losing faith in Rev-Ed.

Why is such a simple bug being ignored for years ?.
I've been similarly frustrated by the lack of responsiveness from Rev-Ed in maintaining their software stack, especially on non-windows platforms, which are much more limited and infrequently updated than even PE6 is. See the discussion here for a chronicle of my and many other's complaints for years for the lack of updates to support 64 bit (intel) MacOS and Apple Silicon (ARM) MacOS. In that thread are links to some command line utilities we've developed in free over the years to help supplement the missing features from the non-PE6 development tools.

Given how hobbyists like myself are so (relatively) quickly able to add and improve features in our free time, it's definitely striking to compare that to the frequency of official updates from Rev-Ed.

On the plus side (arguably, anyway), there does seem to be a new version of PE6 released, 6.2.0.0, which includes the release note:
00658 Removed non-functioning 0x08 option from Terminal
So it seems they've finally dealt with this bug, but perhaps not in the most ideal way (removing the feature, rather than correcting broken functionality).
 

papaof2

Senior Member
Perhaps there was only one programmer who understood the coding for that feature and he/she is no longer with Rev-Ed?
When I did corporate coding by the hour, I tended to leave notes and possible future direction of the software as comments in the code both for myself and for whoever followed me but not every by-the-hour programmer does that.
 

Buzby

Senior Member
... So it seems they've finally dealt with this bug, but perhaps not in the most ideal way (removing the feature, rather than correcting broken functionality).
Ha ha !.

Shades of Advanti West Coast cancelling trains so they can't arrive late !.
 

Technical

Technical Support
Staff member
We have exactly the same programming staff here that developed PE6 from the start. If 000658 was a simple fix it would have been corrected.

Briefly, the PE6 terminal display uses the same syntax colouring control that is used for code highlighting, which does allow some nice terminal features such as line numbers as well as colouring. However one limitation is that it was never designed for accepting multiple different textstreams from various different routes asynchronously (it has a lot of processing to do to complete syntax colouring on the fly). So displaying a textstream originating from the serial port (instead of the normal keyboard) is fine, but the 0x08 command was unique in that it was then attempting to interrupt and relocate (and then also overwrite) locations in the existing textstream (whilst other text/new commands could still be coming in via the serial port - this is the nature of the bug in the first post above - caused by multiple consecutive 0x08 commands). No other terminal feature was attempting to do this.

After extensive testing it was concluded that this bug could only be fully fixed by rewriting the syntax colouring control, which could have then impacted the main text editor, which is not something we are prepared to do. As this 0x08 terminal option was very obscure, and very few people would ever use (in fact only one person has ever raised a support issue about it) - but the text editor is used by all PE6 users - we believe this is the correct decision.

There are also quite literally dozens of free third party terminal applications available, we quite like https://webserial.io/ (as used within the online Blocky / code editor at https://picaxecloud.com).
 

Buzby

Senior Member
... There are also quite literally dozens of free third party terminal applications available, we quite like https://webserial.io/ (as used within the online Blocky / code editor at https://picaxecloud.com).
I don't want to use an online cloud based system, I want to use PE6. ( Also, the webserial.io API won't run on Firefox, so it tells me when I try. )

In the posts that originated this conversation I suggested that PE6 should be configured to allow the use of a 3rd party serial as an alternative to the built in terminal. This was in response to the fact that we were told the new terminal in PE6 would allow screen navigation, but it didn't. ( I wasn't expecting a full VT100 emulation, just some up/down/left/right escape sequences. )

From what you have written about the 'syntax colouring control', it looks like the problem could be solved by writing a specific control just for use by the terminal. This would not need all the fancy fluff that the existing control has, and would not affect any other part of the code. In fact, this new 'control' could just be a link to a 3rd party terminal. If it's too difficult to allow the end user to select which terminal emulator to use, then use a decent open source emulator, like TeraTerm.

I like PE6, mostly.
 
Top