PE6 Terminal, control character behaviour ?

[Buzby]

#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 ?

 

[hippy]

What am I doing wrong ?

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.

 

[Buzby]

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]

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]

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]

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]

Are Rev-Ed looking into the backspace bug ?

 

[Buzby]

Are Rev-Ed looking into this backspace bug ?

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

 

[Buzby]

Are Rev-Ed looking into this backspace bug ?

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

 

[Technical]

All feature requests/bugs are logged on our ticket system.

 

[kfjl]

All feature requests/bugs are logged on our ticket system.

And then we pull the chain...

 

[erco]

Are Rev-Ed looking into this backspace bug ?

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

Hear, hear!

 

[Buzby]

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]

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]

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]

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.

 

[erco]

Sounds like a great project for the Covid lockdown!

 

[Buzby]

Is this bug ever going to be fixed ?

 

[hippy]

Not sure what the status of the issue is but have given it a bump

 

[Buzby]

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

 

[papaof2]

Perhaps the "Foreign" just means non-Engllish?

 

[Buzby]

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 ..... ...

( 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]

Perhaps the "Foreign" just means non-Engllish?

Almost certainly. Looking through the executable for occurrences of "Foreign"...

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]

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]

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]

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]

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 !.