Oldbitcollector,
First I want to add support for a mouse to the current keyboard I/O driver so that it wouldn't need yet another cog since the VGA cursor support takes a cog. That will take a while to get done. At that point I'll make it a configurable option.
Have a look at the BOE-BOT Basic I posted to see examples for adding commands (in this case for servo, PING, compass, and IR ranging with a serial command link instead of the keyboard/display). It's posted here: http://forums.parallax.com/showthread.php?p=635533.
Post Edited (Mike Green) : 3/19/2007 4:09:59 AM GMT
Yes, I've already begun hacking into the code itself. Thanks for the additional examples!
I'm a little disappointed with INPUTs current inability to handle variables, so I've begun seeing what I can do to deal with that. Useful example (based on another message in this thread)
<EXAMPLE DOES NOT WORK, yet>
1 FILES
5 INPUT "Pick a file to view";A$
10 OPEN A$,R
20 C=FILE
30 IF c<1 THEN GOTO 100
40 IF C<>10 THEN DISPLAY C
50 GOTO 20
100 PRINT " "
110 INPUT "End of file: <1 & ENTER>";a
{Posted for the benefit of someone looking for working code}
<THIS WORKS>
10 OPEN "FILE.TXT",R
20 C=FILE
30 IF c<1 THEN GOTO 100
40 IF C<>10 THEN DISPLAY C
50 GOTO 20
100 PRINT " "
110 INPUT "End of file: <1 & ENTER>";a
QUESTIONS:
Also, if I use the SPIN "file.spin":RUN command, does it currently run on unused cogs leaving FemtoBasic intact? I haven't been able to test this yet, as I haven't figured out how to create a file.spin.binary file on the PC. (Or do I have to download the binary back down from the chip itself somehow?
Again, sorry about the newbieness questions, but I think I'll continue to get up to speed quickly at the rate I'm going...
(A few more Femtobasic commands and I'll be able to create the old text version of Startrek with LED's for alerts)
1) The INPUT statement can actually handle arbitrary expressions including current variable values on the input line.
What it won't handle is any kind of string value. FemtoBasic has no string variables or functions at present and no
immediate plans to add them.
2) The SPIN command basically "throws away" the entire contents of RAM. The Spin interpreter normally provides for
only one program in memory. There is apparently a way to make the Spin interpreter use a different area than the
beginning of memory (locations 0-15) for its critical pointers, but I haven't tried yet to get that to work. The loader
for the SPIN command runs in its own cog and, when the program is being loaded, only references these critical
pointers. FemtoBasic is GONE at that point.
3) To save a binary file in the Propeller Tool, use the Save Binary File button in the Hex View window that comes up
when you use the F8 key or Ctrl-F8 key or the View Info item in the Run menu.
Mike, Would you mind showing a couple Femtobasic examples for INA and OUTA?
Something along the lines of
{Note: I'm pretty sure this code is INCORRECT. *pseudo-code*}
10 if INA(4) = 1 then print "Button pushed on pin 4": REM Button pushed on pin 4
20 if INA(4) = 0 then print "Push a button already!!": REM No button pushed on pin 4
and
10 OUTA(9) = 1 : REM Turn on LED on pin 9
20 PAUSE
30 OUTA(9) = 0 : REM Turn off LED on pin 9
1 REM Simple Tone Generator for FemtoBASIC
2 REM Time to make FemtoBASIC go faster.
10 input a
20 for x = 1 to 100
30 outa[noparse][[/noparse]10]=1
40 pause a
50 outa[noparse][[/noparse]10]=0
60 next x
70 goto 10
Would anyone else playing with FemtoBASIC care to join me
in starting a little code swapping thread? Perhaps we can develop
some additional documentation in the process.
I am trying to get FemtoBasic_SERIAL_MJC to talk. I am able to Load EEPROM, but after that, I can't get it to talk.
I am using COM6 as where my PropPlug is connected. After I download to eeprom, I start up HyperTerm (I know, there are way better, but it is there and free) and connect to COM6 at 9600 8N1 no flow controll.
Am I doing this right, or should I be connecting through other pins of the propeller with a MAX232 chip?
I just can't get it to talk.
My typing flickers the little blue light on the prop plug, but nothing on the little red light.
hinv,
It sounds like you're trying to use the version that comes with the Hydra. I can't help you with that one. Please download and use the version that you can download from the Propeller Object Exchange. The versions of FemtoBasic in the Object Exchange work with the PS/2 keyboard and either a VGA or TV display. There's a special version of FemtoBasic called BoeBotBasic, also in the Object Exchange, that uses the programming serial port for its console. It can also be compiled to use a different pair of pins for the serial port (and is used this way with an xBee adapter).
Both versions from the Object Exchange work fine with the ProtoBoard. I have a ProtoBoard based BoeBot and use BoeBotBasic with it.
Post Edited (Mike Green) : 7/17/2007 4:49:03 AM GMT
Thanks for the tip. I have BeoBotBasic working on my proto board now.
I did have to change the console lines to talk to booTx and bootRx.
I also had to fix dump as it was broken. That is when I found a serious limitation in SPIN: ALL LOCAL VARIABLES ARE LONGS! ugh!
There is also not out of bounds checking, or sigsegv to tell you that you are writing out of bounds.
I know you already know all of this, I just wanted to express my frustration after the frustration with fixing dumpMemory.
Anyway, I think it is done.
It does need a "buf[noparse][[/noparse]16]" in the var block on the byte line. Let me know what you think. I did make it 16 bytes /line to use the space on most 80 column terminals.
PUB dumpMemory(addr,size) | i, c, p, first
'' This routine dumps a portion of the RAM to the display.
'' The format is 8 bytes wide with hexadecimal and ASCII.
addr &= $7FFF
if addr + size > $7FFF ' truncate to end of code space
size := $8000 - addr
first := true
p := addr & $7FF8
repeat while p < (addr + size)
if first
ser.hex(addr,4)
first := false
else
ser.hex(p,4)
ser.tx(" ")
repeat i from 0 to 15 'If you want to display just 8 bytes/line, change the 15 to a 7
if p => addr and p < (addr + size)
c := byte[noparse][[/noparse]p]
ser.hex(c,2)
if c => " " and c =< "~"
buf[i] := c
else
buf[i] := " "
else
ser.tx(" ")
ser.tx(" ")
ser.tx(" ")
p++
buf[i] := 0 'terminate string
ser.tx("|")
ser.str(@buf)
ser.tx("|")
ser.tx(def#Cr)
ser.tx(def#Lf)
[/i][/i][/i]
Can you describe what was broken about DumpMemory? I've had several versions of this between FemtoBasic, BoeBotBasic, and the Propeller OS and the different versions of each. I know a couple of versions were buggy, but I thought I fixed the bugs.
This was from BOE-BOT_Basic 2007-04-08
The code assumes that buf0, buf1, and buf2 are allocated sequentially, and that writing to buf0 will flow into buf1's space. Apparently, this doesn't work as expected.
Well, that didn't show up as planned.
The last line should read:
The code assumes that buf0, buf1, and buf2 are allocated sequentially, and that writing to buf0 will flow into buf1's space. Apparently, this doesn't work as expected.
On BoeBotBasic, I also am not able to load or save my program
load give error "Invalid program size" even though I just did a save.
files gives the error "Can't mount SD card"
I couldn't find the pin numbers for the SDCard port.
Is it in there somewhere?
Doug,
I would need more information on just what you entered and what you're trying to do with the "Invalid program size" message. The LOAD command checks the validity of the saved program size. The SAVE command computes the amount of space taken by the partially tokenized Basic program and saves this as the first 16-bit word in the area set aside in EEPROM. The LOAD command makes sure this isn't too small (<4 bytes including the count) or too large (larger than the area set aside) before trying to load it. You'd get this message if you re-downloaded the BoeBotBasic interpreter after saving the Basic program (because the download wipes out the saved program).
The "FemtoBasic Manual" that's included in the Object Exchange zip file has a description of the SD Card wiring. Do make sure you have that version since it's the latest.
I don't remember what the "invalid program size" error was about, but I fixed the dumpMemory subroutine again, this time in DongleBasic.
I stuck with your 8 byte format, but I had to take out buf0, buf1, and buf2 again as it was just not displaying the ascii characters past the first of the 8.
Instead of posting it in a code block, and having the brackets taken out, I am attaching the whole file.
Thanks Doug. I'll fix it properly in the next release (3.006), probably over the weekend. I forgot to use "byte[noparse][[/noparse] @b0 ][noparse][[/noparse] i ]".
The Invalid Program Size message is due to a problem with EEPROM page write boundaries that I've now fixed. There are
a couple of other minor improvements as well ... like being able to SAVE / LOAD Basic programs to other EEPROM areas.
I'll be updating all the FemtoBasic derivatives.
All of the FemtoBasic derivatives have been updated to 3.006. Please let me know of any problems / bugs / etc.
Changes:
1) The documentation has been updated including for a version for the Hitt Consulting's Overlay Display
board that's not quite working properly yet.
2) The DUMP bug has been fixed properly and DUMP can display the contents of EEPROM as well as RAM.
3) LOAD and SAVE have been fixed and can now store the Basic program in arbitrary locations in EEPROM.
For those boards with EEPROM > 32K, this makes it possible to create libraries of Basic programs in EEPROM.
Note that the statements adjust the address upwards so that the program is stored starting two bytes before
the next 64 byte boundary (to make use of paged writes). The rest of the initial 64 byte page is untouched
and could be used to store a program name and other information, but FemtoBasic doesn't do this for you.
4) The uOLED version has support for a 5x7 font as well as the previous 8x8 font thanks to Duffer's new driver
version. A simple circle and arc drawing routine with a fill option have also been added (courtesy of Paul Sr.)
many thanks for FemtoBasic: this is a language my kids can play with right on the Propeller without delving into the complexities of Spin and assembly.
And since I have kids typing at it, needed some command line editing capability.
Fairly simple stuff, but I've found it useful. Here it is (replacement for GetLine in FemtoBasic.spin)
PRI getline | cp, ep, c
cp := 0 ' current cursor position
ep := cp ' last (end) cursor position this line
repeat
c := key.getkey
if c == bspKey
if cp > 0
if cp == ep
dsp.str(string(backspace," ",backspace))
cp--
ep--
else
' probably would be better to remove 1 char from line
' but for now just overwrite with a space
tline[noparse][[/noparse]cp--] := " "
dsp.str(string(backspace, " ", backspace))
elseif c == fReturn
if cp <> ep ' erase anything from cursor to end of line
repeat ep - cp
dsp.out(32)
dsp.out(c)
tline[noparse][[/noparse]cp] := 0
tp := @tline
return
elseif ((c == $DD) OR (c == $DE) OR (c == $DF))
'scroll lock, caps lock and numlock keys should be ignored as keystrokes
next
elseif (c == $C0)
' cursor left, but only if cursor not already at beginning of line
if cp > 0
if (cp <> ep)
dsp.out(tline[noparse][[/noparse]cp])
dsp.out($3)
cp--
dsp.str(string(dsp#CursLt, dsp#Color, $8)) ' cursor back, invert color
dsp.out(tline[noparse][[/noparse]cp])
dsp.str(string(dsp#CursLt, dsp#Color, dsp#Alt00)) ' put color back to normal
elseif (c == $C1)
' cursor right, but only up to last typed character
if cp < ep
dsp.out(tline[noparse][[/noparse]cp])
cp++
if cp < ep
dsp.str(string(dsp#Color, $8)) ' cursor back, invert color, write character
dsp.out(tline[noparse][[/noparse]cp])
dsp.str(string(dsp#CursLt, dsp#Color, dsp#Alt00)) ' put color back to normal
elseif cp < linelen-1
dsp.out(c)
tline[noparse][[/noparse]cp++] := c
ep := cp
Comments welcome
(edited because even inside a code section the square bracket characters cause formatting: variable i changed to cp)
Very nice. If you feel like expanding it, you could even add an insert function which would insert a blank at the current column by shifting the right side of the line further to the right and a delete function that would delete the current character by shifting the right side of the line to the left.
Have a look at the screen buffer editor module in the Propeller OS on Graham Stabler's Good Thread Index in one of the sticky threads at the top of the forum.
I am using the Composite (TV) aka tv_wtext driver.
I very definitely miss being able to have conditional compilation when programming the Propeller.
Commenting things in and out is not quite the same...
Nice routine! I've noticed that it doesn't seem to want to cursor back right once I've gone left.
That might make an interesting upgrade. Combine this with an EDIT # command and you'd
have a very solid feature for troubleshooting a bad line entry.
I'll have to see if I can find a way to incorporate this into my copy that uses the 8x8 font.
Comments
First I want to add support for a mouse to the current keyboard I/O driver so that it wouldn't need yet another cog since the VGA cursor support takes a cog. That will take a while to get done. At that point I'll make it a configurable option.
Have a look at the BOE-BOT Basic I posted to see examples for adding commands (in this case for servo, PING, compass, and IR ranging with a serial command link instead of the keyboard/display). It's posted here: http://forums.parallax.com/showthread.php?p=635533.
Post Edited (Mike Green) : 3/19/2007 4:09:59 AM GMT
I'm a little disappointed with INPUTs current inability to handle variables, so I've begun seeing what I can do to deal with that. Useful example (based on another message in this thread)
<EXAMPLE DOES NOT WORK, yet>
1 FILES
5 INPUT "Pick a file to view";A$
10 OPEN A$,R
20 C=FILE
30 IF c<1 THEN GOTO 100
40 IF C<>10 THEN DISPLAY C
50 GOTO 20
100 PRINT " "
110 INPUT "End of file: <1 & ENTER>";a
{Posted for the benefit of someone looking for working code}
<THIS WORKS>
10 OPEN "FILE.TXT",R
20 C=FILE
30 IF c<1 THEN GOTO 100
40 IF C<>10 THEN DISPLAY C
50 GOTO 20
100 PRINT " "
110 INPUT "End of file: <1 & ENTER>";a
QUESTIONS:
Also, if I use the SPIN "file.spin":RUN command, does it currently run on unused cogs leaving FemtoBasic intact? I haven't been able to test this yet, as I haven't figured out how to create a file.spin.binary file on the PC. (Or do I have to download the binary back down from the chip itself somehow?
Again, sorry about the newbieness questions, but I think I'll continue to get up to speed quickly at the rate I'm going...
(A few more Femtobasic commands and I'll be able to create the old text version of Startrek with LED's for alerts)
Oldbit
What it won't handle is any kind of string value. FemtoBasic has no string variables or functions at present and no
immediate plans to add them.
2) The SPIN command basically "throws away" the entire contents of RAM. The Spin interpreter normally provides for
only one program in memory. There is apparently a way to make the Spin interpreter use a different area than the
beginning of memory (locations 0-15) for its critical pointers, but I haven't tried yet to get that to work. The loader
for the SPIN command runs in its own cog and, when the program is being loaded, only references these critical
pointers. FemtoBasic is GONE at that point.
3) To save a binary file in the Propeller Tool, use the Save Binary File button in the Hex View window that comes up
when you use the F8 key or Ctrl-F8 key or the View Info item in the Run menu.
Something along the lines of
{Note: I'm pretty sure this code is INCORRECT. *pseudo-code*}
10 if INA(4) = 1 then print "Button pushed on pin 4": REM Button pushed on pin 4
20 if INA(4) = 0 then print "Push a button already!!": REM No button pushed on pin 4
and
10 OUTA(9) = 1 : REM Turn on LED on pin 9
20 PAUSE
30 OUTA(9) = 0 : REM Turn off LED on pin 9
Thanks
Oldbitcollector
Yes, it did work perfectly. My Atari joystick port for Femto is almost complete.
(Now if I can just get the random detections in .spin to go away..)
Thanks again Mike
Oldbitcollector
Like sound..
1 REM Simple Tone Generator for FemtoBASIC
2 REM Time to make FemtoBASIC go faster.
10 input a
20 for x = 1 to 100
30 outa[noparse][[/noparse]10]=1
40 pause a
50 outa[noparse][[/noparse]10]=0
60 next x
70 goto 10
Would anyone else playing with FemtoBASIC care to join me
in starting a little code swapping thread? Perhaps we can develop
some additional documentation in the process.
Oldbitcollector
I am trying to get FemtoBasic_SERIAL_MJC to talk. I am able to Load EEPROM, but after that, I can't get it to talk.
I am using COM6 as where my PropPlug is connected. After I download to eeprom, I start up HyperTerm (I know, there are way better, but it is there and free) and connect to COM6 at 9600 8N1 no flow controll.
Am I doing this right, or should I be connecting through other pins of the propeller with a MAX232 chip?
I just can't get it to talk.
My typing flickers the little blue light on the prop plug, but nothing on the little red light.
Any guesses?
Thanks,
Doug
It sounds like you're trying to use the version that comes with the Hydra. I can't help you with that one. Please download and use the version that you can download from the Propeller Object Exchange. The versions of FemtoBasic in the Object Exchange work with the PS/2 keyboard and either a VGA or TV display. There's a special version of FemtoBasic called BoeBotBasic, also in the Object Exchange, that uses the programming serial port for its console. It can also be compiled to use a different pair of pins for the serial port (and is used this way with an xBee adapter).
Both versions from the Object Exchange work fine with the ProtoBoard. I have a ProtoBoard based BoeBot and use BoeBotBasic with it.
Post Edited (Mike Green) : 7/17/2007 4:49:03 AM GMT
Thanks for the tip. I have BeoBotBasic working on my proto board now.
I did have to change the console lines to talk to booTx and bootRx.
I also had to fix dump as it was broken. That is when I found a serious limitation in SPIN: ALL LOCAL VARIABLES ARE LONGS! ugh!
There is also not out of bounds checking, or sigsegv to tell you that you are writing out of bounds.
I know you already know all of this, I just wanted to express my frustration after the frustration with fixing dumpMemory.
Anyway, I think it is done.
It does need a "buf[noparse][[/noparse]16]" in the var block on the byte line. Let me know what you think. I did make it 16 bytes /line to use the space on most 80 column terminals.
PUB dumpMemory(addr,size) | i, c, p, first '' This routine dumps a portion of the RAM to the display. '' The format is 8 bytes wide with hexadecimal and ASCII. addr &= $7FFF if addr + size > $7FFF ' truncate to end of code space size := $8000 - addr first := true p := addr & $7FF8 repeat while p < (addr + size) if first ser.hex(addr,4) first := false else ser.hex(p,4) ser.tx(" ") repeat i from 0 to 15 'If you want to display just 8 bytes/line, change the 15 to a 7 if p => addr and p < (addr + size) c := byte[noparse][[/noparse]p] ser.hex(c,2) if c => " " and c =< "~" buf[i] := c else buf[i] := " " else ser.tx(" ") ser.tx(" ") ser.tx(" ") p++ buf[i] := 0 'terminate string ser.tx("|") ser.str(@buf) ser.tx("|") ser.tx(def#Cr) ser.tx(def#Lf) [/i][/i][/i]Thanks,
Doug
Mike
and this is what it looked like before:
This was from BOE-BOT_Basic 2007-04-08
The code assumes that buf0, buf1, and buf2 are allocated sequentially, and that writing to buf0 will flow into buf1's space. Apparently, this doesn't work as expected.
Thanks,
Doug
The last line should read:
I meant writing to buf0\[noparse][[/noparse]4\] doesn't mean that you are automatically writing to buf1 space.
Well anyway, I can't seem to protect the brackets above without showing the backspaces, but you get the picture.
On BoeBotBasic, I also am not able to load or save my program
load give error "Invalid program size" even though I just did a save.
files gives the error "Can't mount SD card"
I couldn't find the pin numbers for the SDCard port.
Is it in there somewhere?
Thanks,
Doug
I would need more information on just what you entered and what you're trying to do with the "Invalid program size" message. The LOAD command checks the validity of the saved program size. The SAVE command computes the amount of space taken by the partially tokenized Basic program and saves this as the first 16-bit word in the area set aside in EEPROM. The LOAD command makes sure this isn't too small (<4 bytes including the count) or too large (larger than the area set aside) before trying to load it. You'd get this message if you re-downloaded the BoeBotBasic interpreter after saving the Basic program (because the download wipes out the saved program).
The "FemtoBasic Manual" that's included in the Object Exchange zip file has a description of the SD Card wiring. Do make sure you have that version since it's the latest.
I don't remember what the "invalid program size" error was about, but I fixed the dumpMemory subroutine again, this time in DongleBasic.
I stuck with your 8 byte format, but I had to take out buf0, buf1, and buf2 again as it was just not displaying the ascii characters past the first of the 8.
Instead of posting it in a code block, and having the brackets taken out, I am attaching the whole file.
Thanks,
Doug
The Invalid Program Size message is due to a problem with EEPROM page write boundaries that I've now fixed. There are
a couple of other minor improvements as well ... like being able to SAVE / LOAD Basic programs to other EEPROM areas.
I'll be updating all the FemtoBasic derivatives.
Changes:
1) The documentation has been updated including for a version for the Hitt Consulting's Overlay Display
board that's not quite working properly yet.
2) The DUMP bug has been fixed properly and DUMP can display the contents of EEPROM as well as RAM.
3) LOAD and SAVE have been fixed and can now store the Basic program in arbitrary locations in EEPROM.
For those boards with EEPROM > 32K, this makes it possible to create libraries of Basic programs in EEPROM.
Note that the statements adjust the address upwards so that the program is stored starting two bytes before
the next 64 byte boundary (to make use of paged writes). The rest of the initial 64 byte page is untouched
and could be used to store a program name and other information, but FemtoBasic doesn't do this for you.
4) The uOLED version has support for a 5x7 font as well as the previous 8x8 font thanks to Duffer's new driver
version. A simple circle and arc drawing routine with a fill option have also been added (courtesy of Paul Sr.)
I would like to thank you for all your hard work on the femtobasic version.
I can't wait to try them.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
many thanks for FemtoBasic: this is a language my kids can play with right on the Propeller without delving into the complexities of Spin and assembly.
And since I have kids typing at it, needed some command line editing capability.
Fairly simple stuff, but I've found it useful. Here it is (replacement for GetLine in FemtoBasic.spin)
PRI getline | cp, ep, c cp := 0 ' current cursor position ep := cp ' last (end) cursor position this line repeat c := key.getkey if c == bspKey if cp > 0 if cp == ep dsp.str(string(backspace," ",backspace)) cp-- ep-- else ' probably would be better to remove 1 char from line ' but for now just overwrite with a space tline[noparse][[/noparse]cp--] := " " dsp.str(string(backspace, " ", backspace)) elseif c == fReturn if cp <> ep ' erase anything from cursor to end of line repeat ep - cp dsp.out(32) dsp.out(c) tline[noparse][[/noparse]cp] := 0 tp := @tline return elseif ((c == $DD) OR (c == $DE) OR (c == $DF)) 'scroll lock, caps lock and numlock keys should be ignored as keystrokes next elseif (c == $C0) ' cursor left, but only if cursor not already at beginning of line if cp > 0 if (cp <> ep) dsp.out(tline[noparse][[/noparse]cp]) dsp.out($3) cp-- dsp.str(string(dsp#CursLt, dsp#Color, $8)) ' cursor back, invert color dsp.out(tline[noparse][[/noparse]cp]) dsp.str(string(dsp#CursLt, dsp#Color, dsp#Alt00)) ' put color back to normal elseif (c == $C1) ' cursor right, but only up to last typed character if cp < ep dsp.out(tline[noparse][[/noparse]cp]) cp++ if cp < ep dsp.str(string(dsp#Color, $8)) ' cursor back, invert color, write character dsp.out(tline[noparse][[/noparse]cp]) dsp.str(string(dsp#CursLt, dsp#Color, dsp#Alt00)) ' put color back to normal elseif cp < linelen-1 dsp.out(c) tline[noparse][[/noparse]cp++] := c ep := cpComments welcome
(edited because even inside a code section the square bracket characters cause formatting: variable i changed to cp)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
Have a look at the screen buffer editor module in the Propeller OS on Graham Stabler's Good Thread Index in one of the sticky threads at the top of the forum.
Question: Which text driver were you using? VGA or Composite?
Thanks
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.
I am using the Composite (TV) aka tv_wtext driver.
I very definitely miss being able to have conditional compilation when programming the Propeller.
Commenting things in and out is not quite the same...
Joao
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
That might make an interesting upgrade. Combine this with an EDIT # command and you'd
have a very solid feature for troubleshooting a bad line entry.
I'll have to see if I can find a way to incorporate this into my copy that uses the 8x8 font.
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buttons . . . check. Dials . . . check. Switches . . . check. Little colored lights . . . check.
— Calvin, of 'Calvin and Hobbes.