 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : What's with the "[?7h" prompt?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 10026 |
On all new FW versions of both the PM builds, this is the default command prompt. What's up with this? How do I disable it and just go back to the standard > prompt? This is NOT visible on the VGA or HDMI output, but only on the console. Is this something to do with advanced graphics control of the connected terminal? I tried turning colourcode OFF, but it made no difference to the console prompt - it's still there.... Smoke makes things work. When the smoke gets out, it stops! |
||||
phil99 Guru  Joined: 11/02/2018 Location: AustraliaPosts: 3366 |
Perhaps a fresh download and reinstall the firmware as my Picos have the normal prompt with the latest firmware. Alternatively SUB MM.PROMPT PRINT "> "; END SUB |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6589 |
VT terminal code ESC [?7h turns on auto-wrap mode MMCC ignores it but you shouldn't be seeing it on any VTxxx terminal Jim VK7JH MMedit |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2547 |
from GFXguide.pdf: "AutoWrap at end-of-line is hard-wired on, and cursor positioning is permanently fixed to absolute - location (1,1) being top-left of the terminal screen irrespective of any top or bottom margins set with DECSTBM." because it is hardwired on (who would ever want to turn it off???) the sequence ESC [?7h is treated as not being a valid escape sequence and sent on to the video output routines. the ESC character is non-displaying, so you end up just see the remaining "[?7h" part. this is how GFXterm handles all escape sequences it can not process. however, i would expect you to also still see a ">" either before or after the "[?7h" text. can you please check this? i am not aware of any terminal emulator that defaults to turning AutoWrap off, and can see no good reason why anyone would want to adjust the setting. if anyone can think of a good reason, i'd be interested in hearing it. most likely the escape sequence was inserted into the mmbasic source code by a friendly AI trying to help out. if you ask Peter nicely, i am sure he can correct the error. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11790 |
Auto wrap needs to be off otherwise print ; can cause a wrap. And on the last line a scroll. MMBasic used to circumvent this by setting the character width to 81. Now it does it properly. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2547 |
hi Peter, on a real VT100 terminal, generally print; where the cursor finishes up directly to the right of the rightmost column would not cause a carriage-return or linefeed. instead, the arrival of the next printable character would generate the carriage-return and linefeed. this is not an issue, as a real VT100 terminal has space on the CRT to the right of the text area where the cursor can sit. on both GFXterm and TeraTerm this is handled by holding the cursor in the rightmost column on screen, but internally (hidden from the user) recording the location as being to the right of it. are you able to provide a circumstance where the behavior of GFXterm and TeraTerm has in the past proven problematic? cheers, rob :-) Edited 2026-08-29 03:03 by robert.rozee |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2547 |
gemini sums it up more elegantly: Q: with a VT100 terminal, where is the cursor positioned after a character has been printed in the rightmost column? A: "After printing a character in the rightmost column, the cursor remains positioned at that rightmost column rather than wrapping immediately. How VT100 Line Wrapping Works + Deferred Wrap: DEC VT terminals use a deferred wrap mechanism (sometimes called a soft-wrap or "VT100 glitch"). + Current Position: The character is drawn in the final column, but the cursor does not advance or wrap yet. + Next Action: The cursor waits in an anomalous "pending wrap" state at the edge of the screen. + The Wrap Trigger: The cursor only moves to the first column of the next line when the next printable character arrives." i had always assumed that a real VT100 'parked' the cursor to the right of column 80, but it looks like it instead does what GFXterm and TeraTerm do - further proof of the perils of assumption! cheers, rob :-) Edited 2026-08-29 04:39 by robert.rozee |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
