RE Spinneret, how do we embed control characters into strings with wTXSTR?
Also these two words are needed to set the destination IP and PORT when in "client" mode?
pub dPORT ( dstport -- ) sDPORT WIZ2! ; \ set the destination port
pub dIP ( dstip -- ) sDIP WIZ4! ; \ set the destination ip
So far this is only a basic setup and there are other functions to add for sure but I didn't want to unduly complicate it more than necessary at the present. I will implement some more streamline methods after I have weighed up some ways of handling this. As for wTXSTR you could remove the SEND operation at the end of it so that you could just concatenate strings until you were ready to send. In fact I have just modified this so that the SEND is moved to the wEMIT word. As for adding control characters to the TX string I would really just switch the EMIT output to wEMIT and use normal print strings and characters rather than directly creating string.
TERM $0C EMIT ." HELLO" 9 EMIT ." THERE" CR CON
So far this is only a basic setup and there are other functions to add for sure but I didn't want to unduly complicate it more than necessary at the present. I will implement some more streamline methods after I have weighed up some ways of handling this. As for wTXSTR you could remove the SEND operation at the end of it so that you could just concatenate strings until you were ready to send. In fact I have just modified this so that the SEND is moved to the wEMIT word. As for adding control characters to the TX string I would really just switch the EMIT output to wEMIT and use normal print strings and characters rather than directly creating string.
TERM $0C EMIT ." HELLO" 9 EMIT ." THERE" CR CON
This is my first attempt learning and using FORTH. It has been/is a real challenge/effort having only procedural language experience/bias. Funny the people I help at the maker space that have 0 experience are not afraid/intimidated to type into the Tachyon "window" and start building words, running tasks, doing things. I show them the equivalent arduino sketch and the glaze appears again.
I'm building my TCP/IP dictionary for the gadgets I command, and now I see why.
CHANGELOG:
130216 - Added MYWORDS which lists new words to start of current module (i.e. *.fth)
- added == symbol as an alias to CONSTANT but == may later on become compile time constants only
130113 - Enhanced the PINS? word to determine if a pin is pulled up or down by some sort of resistor or load
BUT, no MYWORDS to be found! Gets nothing but "???". I did a QWORDS and ctrl-F-ed my way through it ... NADA!!!!
CHANGELOG:
130216 - Added MYWORDS which lists new words to start of current module (i.e. *.fth)
- added == symbol as an alias to CONSTANT but == may later on become compile time constants only
130113 - Enhanced the PINS? word to determine if a pin is pulled up or down by some sort of resistor or load
BUT, no MYWORDS to be found! Gets nothing but "???". I did a QWORDS and ctrl-F-ed my way through it ... NADA!!!!
EXTEND.fth does have lots of little things added to it bit by bit and the changelog should reflect this. When I added MYWORDS I then changed it again so that MY set a termination pattern. Now I have just added assembler style words for variables which use an origin and specify the number of bytes per "variable". The variable is actually compiled as a constant so that the variable memory area is purely data without any bytecodes so it can be erased or copied etc. WORDS will gradually be enhanced to permit searching based on character match parameters and also attributes.
[B][COLOR=#000000]{ Create fixed variables by borrowing from assembler syntax using an origin and specify number of bytes for each variable[/COLOR]
[COLOR=#000000]This allows us to work from a fixed area in RAM and the variables end up being defined as constants.[/COLOR]
[COLOR=#000000]Usage: [/COLOR]
[COLOR=#000000] $4000 ORG[/COLOR]
[COLOR=#000000] 2 DS readptr \ allocates 2 bytes for readptr at $4000[/COLOR]
[COLOR=#000000] 2 DS writeptr \ allocates 2 bytes for writeptr at $4002[/COLOR]
[COLOR=#000000] #64 DS mybuffer \ allocates 64 bytes for mybuffer at $4004[/COLOR]
[COLOR=#000000][/COLOR]
[COLOR=#000000]or[/COLOR]
[COLOR=#000000] TABLE myvars #64 6 * ALLOT \ allocate long aligned memory for 6 sets of 64 bytes[/COLOR]
[COLOR=#000000] myvars ORG \ work from the start of the table[/COLOR]
[COLOR=#000000] #12 DS name[/COLOR]
[COLOR=#000000] 4 DS offset[/COLOR]
[COLOR=#000000] \ etc[/COLOR]
and w[B]hen we check this...[/B]
[/B]myvars . 2E30 ok
offset . 2E3C ok
[B][COLOR=#000000][FONT=Ubuntu Mono]} [/FONT][/COLOR][/B][B][COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR][/B]
what is the difference between (from TACHYON Kernel - STRLEN ' ( str -- len ))
byte DUP,CFETCHINC,DEC,_BYTE,$7E,SWAP,XCALL,xULT
and
byte DUP,CFETCHINC,_BYTE,$7F,SWAP,XCALL,xULT
i.o.w. why is the first used and not the second ??
Do I miss s.th. important?
EDIT: yes I did miss s.th. ...
this is a combined check for the 2 end of string conditions
either 0-terminated or 8-th bit terminated
if the char == 0 then DEC makes $FFFFFFFF so the loop terminates -> end found
if the char is not 0 then we compare the decremented char code with the $7E instead of $7F to check for the 8th bit. - pulling my hat Peter :cool:
I've been playing with CHARLCD.fth and discovered that WriteLCD works correctly only when #dbus starts at P0. That there is a definition for this suggests, to me anyway, that it was meant to work more generally. I got around the limitation for the time being by multiplying the stack data by 256 prior to OUTSET (my dbus is wired starting at P8).
Another thing: for some reason, when I redirect EMIT on my setup (ie, > LCD ." MultiLCD V1.0 ") I get a few garbage characters on the LCD and TACHYON goes out to lunch, like it's stuck in a loop calling LCDEMIT. I'm sure something is wrong on my end, but right now I have no idea what (still looking into it).
How hard would it be to create a simple word that can output a string to the LCD by calling LCDCHAR directly?
Finally, are there any built-in words for cleaning the dictionary (like, eg, "FORGET")?
I'm sorry for all the questions, and especially sorry if I've overlooked something obvious. Please keep in mind that I'm something of a Forth neophyte.
Thanks once more for all your good efforts. I've played with Forths for several micros (eg, AMFORTH), and TACHYON has been the easiest to get into and most productive thus far. I can actually see where you might do real work with it. Fun stuff too!
I've been playing with CHARLCD.fth and discovered that WriteLCD works correctly only when #dbus starts at P0. That there is a definition for this suggests, to me anyway, that it was meant to work more generally. I got around the limitation for the time being by multiplying the stack data by 256 prior to OUTSET (my dbus is wired starting at P8).
Another thing: for some reason, when I redirect EMIT on my setup (ie, > LCD ." MultiLCD V1.0 ") I get a few garbage characters on the LCD and TACHYON goes out to lunch, like it's stuck in a loop calling LCDEMIT. I'm sure something is wrong on my end, but right now I have no idea what (still looking into it).
How hard would it be to create a simple word that can output a string to the LCD by calling LCDCHAR directly?
Finally, are there any built-in words for cleaning the dictionary (like, eg, "FORGET")?
I'm sorry for all the questions, and especially sorry if I've overlooked something obvious. Please keep in mind that I'm something of a Forth neophyte.
Thanks once more for all your good efforts. I've played with Forths for several micros (eg, AMFORTH), and TACHYON has been the easiest to get into and most productive thus far. I can actually see where you might do real work with it. Fun stuff too!
Seems that there was a bug or two in this code. First off the WriteLCD word was not aligning the data to the correct bit position if the default data pins were not used. All this basically required was a SHL operation but it also meant a few little changes to the code to better support user pins so now there is the LCDPINS word plus tips on changing any other pins easily.
Second, there was a bug in the control code vector table as LOOKUP assumes that all vectors are 2 bytecodes long however I had a NOP for the null vector which is a single VM kernel bytecode and so this would have caused havoc, hence the out to lunch thing. Simply putting in two NOPs or another dummy definition is all that was required.
The reason that I don't create special words for LCD to output strings directly to it is because I find it so clunky for every I/O device to have named methods when there is no need to, hence the redirection words. This means that any output formatting capability that Tachyon has can been used to output to the LCD. Isn't it easy to type in: LCD ." Number 5 is alive, need input" rather than having duplicated methods for each device?
FORGET FORGET
I have been asked a few times about a FORGET word but as I pointed out at the time it doesn't matter if you load edited definitions when the old ones are still there. Since I use an editor or Google docs it's simply a matter of typing a ^C (or equivalent) to wipe out the stuff I've been playing with and then copy and paste. It's very quick that way, only takes seconds and there is no confusion. In the case of CHARLCD.fth it takes 3 seconds and I'm sure typing in FORGET CHARLCD.fth would probably take that long anyway. There's also some technical under the hood reasons why I don't bother with a FORGET and taking into consideration that while not having it does not impact anything or on productivity I therefore choose to forget FORGET.
Thank you for taking a look at this. I'll give the changes a try tomorrow.
Isn't it easy to type in: LCD ." Number 5 is alive, need input" rather than having duplicated methods for each device?
Now that it is working, I would say yes. (And that is more or less what I had in mind anyway: a single word that would take a string and direct it to some specified output - in this case LCDCHAR.)
FORGET FORGET
Okay, here is the situation. Right now it appears that I have two CHARLCD.fth modules stored, two versions. Probably this shouldn't be the case (I guess I did a BACKUP when I shouldn't have). Nor is it that big a deal, other than the clutter I get when I do QWORDS or MODULES. There's always the option, too, of wiping everything and starting over. Still, I couldn't help but wonder if there is a way to delete a word or module that has already been saved without having to go that route.
Thank you for taking a look at this. I'll give the changes a try tomorrow.
Now that it is working, I would say yes. (And that is more or less what I had in mind anyway: a single word that would take a string and direct it to some specified output - in this case LCDCHAR.)
Okay, here is the situation. Right now it appears that I have two CHARLCD.fth modules stored, two versions. Probably this shouldn't be the case (I guess I did a BACKUP when I shouldn't have). Nor is it that big a deal, other than the clutter I get when I do QWORDS or MODULES. There's always the option, too, of wiping everything and starting over. Still, I couldn't help but wonder if there is a way to delete a word or module that has already been saved without having to go that route.
Well I only feel the pain when I have backed up the module too It means that I need to type in COLD and reload EXTEND.fth and any other modules required. Bear in mind however that if you have a 64K EEPROM that you can RESTORE to back before the previous BACKUP. Maybe I will do something that at least makes loading in an edited module easier so that it forgets the previous module automatically when you load in the new one. The module is identified by the ".fth" suffix so this could trigger an automatic module search and replace.
FORGET'ing words in Tachyon involves reclamation of the vectors and header space as well as the code space but it mightn't be so messy any more like it seemed to be in the beginning.
BTW, you are always free to define your own specialized handlers for such things as sending strings directly to the LCDCHAR word but another of the advantages of keeping it as a single entry point (via EMIT) is that the display can be accessed over serial links as in the example at the end of the code document. So you can create your own custom serial LCD displays.
In this regard I could add many more functions to the LCD which I have done for my MultiLCD product (OEM) which emulates various industry standard serial LCDs as well as adds key matrix encoding, PS/2 keyboard interface, audio out, piezo transducer for tones, and SD card as well as RS485 etc.
As part of my plan to introduce more flexibility in listing the Forth words I have just added a simple filter that list only those words whose leading characters match the string given. This also works for QWORDS and you can use it as shown. Next step is to introduce wildcard matching.
Also added a simple wildcard that matches on any single character which is useful to find all words for instance that might have to do with adding: ANY + WORDS
NFA PFA EXT ATRS NAME
6842 1B40 Y43 ...: C++
6850 1B38 Y41 ...: W++
685D 1B30 Y3F ...: ++
6B15 0024 ...$ 1+
6B21 0020 ...$ +
6B40 00D8 ...$ +LOOP
6BFB 0059 ...$ C+!
6C08 0065 ...$ C@++
6C10 005D ...$ W+!
6C1D 0061 ...$ +!
7065 19BB ...: 2+
7475 1218 X9F ...: +CALL ok
Also added a simple wildcard that matches on any single character which is useful to find all words for instance that might have to do with adding: ANY + WORDS
NFA PFA EXT ATRS NAME
6842 1B40 Y43 ...: C++
...
7065 19BB ...: 2+
7475 1218 X9F ...: +CALL ok
You didn't mention it, but it also works wIth QWORDS ... neat! THANK YOU!
As part of my plan to introduce more flexibility in listing the Forth words I have just added a simple filter that list only those words whose leading characters match the string given. This also works for QWORDS and you can use it as shown. Next step is to introduce wildcard matching.
MATCH SD WORDS
I upload, after EXTEND a list of shortcut (mostky common commands aliased in lower case, like
: my MY ;
BUT ... when I tried to do it for word MATCH the system locked up hard
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600
NAMES: $6387...74C9 for 4418 (22846 bytes added) with 23067 bytes free
CODE: $0000...2869 for 5927 (4137 bytes added) with 22423 bytes free
CALLS: 0645 vectors free
AUTORUN BOOT
MODULES LOADED:
1840: EXTEND.fth Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
: match MATCH ;
The problem is QUITE REPEATABLE ... what's going on????
I get this using minicom on my mac with ANSI terminal emulation?
Propeller .:.:--TACHYON--:.:. Forth V21130216.1200
NAMES: $6322...74C3 for 4513 (20978 bytes added) with 22966 bytes free
CODE: $0000...2AD2 for 6449 (0593 bytes added) with 21806 bytes free
CALLS: 0634 vectors free
AUTORUN BOOT
MODULES LOADED:
2881: SEE.fth Tachyon Forth decompiler V1.0 130311.1000
1840: EXTEND.fth Primary extensions to TACHYON kernel - 130303.1430
SEE I2C! ..x:
22C7: $18
22C9: ." "
22CC: ." x"
22D1: ." "
22D5: NEXT
22D6: P
22D7: S
22D8: "
22DB: T
=0020 bytes ok
Try refreshing the source code page as there have been quite a number of changes to it since, same goes for the kernel and extensions too. There's also a SEEALL word that does a two pass decompilation so that it can reveal the BEGIN structures and correct indentation etc.
The decompiler is mainly used for debugging and is also handy when you don't have the source code in front of you. <Get it here>
As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.
[FONT=courier new]DECOMP I2CBUS
: I2CBUS
I2CSTOP $0100 0
DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0=
IF CR
IF
." Fast"
ELSE
." Slow"
THEN
." Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8
FOR 0 SI2C@ .BYTE <>
NEXT 1 SI2C@ I2CSTOP
THEN DROP 2 +LOOP I2CSTOP
;
( =0090 bytes ) ok
[/FONT]
P.S. I can see a little bug in this output, see if you can pick it and why.
The decompiler is mainly used for debugging and is also handy when you don't have the source code in front of you. <Get it here>
As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.
[FONT=courier new]DECOMP I2CBUS
: I2CBUS
I2CSTOP $0100 0
DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0=
IF CR
IF
." Fast"
ELSE
." Slow"
THEN
." Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8
FOR 0 SI2C@ .BYTE <>
NEXT 1 SI2C@ I2CSTOP
THEN DROP 2 +LOOP I2CSTOP
;
( =0090 bytes ) ok
[/FONT]
P.S. I can see a little bug in this output, see if you can pick it and why.
Okay after a refresh and rebuild all works as advertised. Seems there is that extra space floating in the mix, haven't looked at the source to see where it may originate from though.
The decompiler is mainly used for debugging and is also handy when you don't have the source code in front of you. <Get it here>
As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.
P.S. I can see a little bug in this output, see if you can pick it and why.
I tried this on a fresh build ... i.e. latest kernal and EXTEND ... running Zterm on a quad core Mac at 115200. ZTerm has never had a problem keeping up at 115200. Is there a problem ... or. more likely, where have I gone wrong?
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600
NAMES: $59AC...74C9 for 6941 (17908 bytes added) with 20544 bytes free
CODE: $0000...361B for 6910 (2048 bytes added) with 18917 bytes free
CALLS: 0373 vectors free
AUTORUN BOOT
MODULES LOADED:
2E1B: RGB8X8.fth 8x8 RGB LED Matrix Tool Kit - 20130310.1900
2C71: EXT_BBR.fth redirects for RFID/LCD/RGB/EMIC, UFO, et al. - 20130310.16000
2869: DECOMPILER.fth Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
I2CSTOP $0100
." "
." "
." " 5 us
." "
." =" =
IF +!
." "
ELSE
." ow"
THEN +
." vice at "
." }" ?DUP I2CSTART I
." "
." " .BYTE <>
NEXT 1 SI2C@ I2CSTOP
." " I2CSTOP
;
( =0090 bytes ) ok
I tried this on a fresh build ... i.e. latest kernal and EXTEND ... running Zterm on a quad core Mac at 115200. ZTerm has never had a problem keeping up at 115200. Is there a problem ... or. more likely, where have I gone wrong?
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600
NAMES: $59AC...74C9 for 6941 (17908 bytes added) with 20544 bytes free
CODE: $0000...361B for 6910 (2048 bytes added) with 18917 bytes free
CALLS: 0373 vectors free
AUTORUN BOOT
MODULES LOADED:
2E1B: RGB8X8.fth 8x8 RGB LED Matrix Tool Kit - 20130310.1900
2C71: EXT_BBR.fth redirects for RFID/LCD/RGB/EMIC, UFO, et al. - 20130310.16000
2869: DECOMPILER.fth Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
I2CSTOP $0100
." "
." "
." " 5 us
." "
." =" =
IF +!
." "
ELSE
." ow"
THEN +
." vice at "
." }" ?DUP I2CSTART I
." "
." " .BYTE <>
NEXT 1 SI2C@ I2CSTOP
." " I2CSTOP
;
( =0090 bytes ) ok
It's a mystery, can you do a "0 8000 IDUMP" and email me so I can check it out? Maybe if you just do a COLD and then load EXTEND.fth and then the decompiler and try it out without any of the other stuff first perhaps.
I added a HEXLOAD to EXTEND.fth which loads directly into EEPROM if the destination address is not RAM (>$7FFF). So I loaded your hex file into $8000 and then did the equivalent of a restore except I kept my first 64 bytes intact for my clock settings. Anyhow, the decompiler did exactly what it did with you and I tracked this back to the fact that you were using the dropbox version of Tachyon which is never as up-to-date as the Google docs version. So just in case I updated the dropbox version as it was missing the name header for (.") which caused the decompiler to get confused.
I've updated the CHARLCD.fth file with a big digit mode plus a few other extras. The command codes are documented in the source code and as you may know the driver includes a lot of little extras such as tone generation, software controlled backlight brightness and contrast. The big digit mode is very handy for reading from a distance and allows up to 4 large digits on a 20x4.
The driver is meant to be used a standard output stream device so rather than call methods which although possible is not desired as you simply send through the stream of controls and characters. This means you could substitute an output device or access it as a remote serial display.
I use 8-bit parallel mode as standard but it can easily be adapted to 4-bit mode if you really want.
Comments
So far this is only a basic setup and there are other functions to add for sure but I didn't want to unduly complicate it more than necessary at the present. I will implement some more streamline methods after I have weighed up some ways of handling this. As for wTXSTR you could remove the SEND operation at the end of it so that you could just concatenate strings until you were ready to send. In fact I have just modified this so that the SEND is moved to the wEMIT word. As for adding control characters to the TX string I would really just switch the EMIT output to wEMIT and use normal print strings and characters rather than directly creating string.
TERM $0C EMIT ." HELLO" 9 EMIT ." THERE" CR CON
This is my first attempt learning and using FORTH. It has been/is a real challenge/effort having only procedural language experience/bias. Funny the people I help at the maker space that have 0 experience are not afraid/intimidated to type into the Tachyon "window" and start building words, running tasks, doing things. I show them the equivalent arduino sketch and the glaze appears again.
I'm building my TCP/IP dictionary for the gadgets I command, and now I see why. " Thanks Peter" tw
BUT, no MYWORDS to be found! Gets nothing but "???". I did a QWORDS and ctrl-F-ed my way through it ... NADA!!!!
MY WORDS and MY QWORDS
typo in the doc
[B][COLOR=#000000]{ Create fixed variables by borrowing from assembler syntax using an origin and specify number of bytes for each variable[/COLOR] [COLOR=#000000]This allows us to work from a fixed area in RAM and the variables end up being defined as constants.[/COLOR] [COLOR=#000000]Usage: [/COLOR] [COLOR=#000000] $4000 ORG[/COLOR] [COLOR=#000000] 2 DS readptr \ allocates 2 bytes for readptr at $4000[/COLOR] [COLOR=#000000] 2 DS writeptr \ allocates 2 bytes for writeptr at $4002[/COLOR] [COLOR=#000000] #64 DS mybuffer \ allocates 64 bytes for mybuffer at $4004[/COLOR] [COLOR=#000000][/COLOR] [COLOR=#000000]or[/COLOR] [COLOR=#000000] TABLE myvars #64 6 * ALLOT \ allocate long aligned memory for 6 sets of 64 bytes[/COLOR] [COLOR=#000000] myvars ORG \ work from the start of the table[/COLOR] [COLOR=#000000] #12 DS name[/COLOR] [COLOR=#000000] 4 DS offset[/COLOR] [COLOR=#000000] \ etc[/COLOR] and w[B]hen we check this...[/B] [/B]myvars . 2E30 ok offset . 2E3C ok [B][COLOR=#000000][FONT=Ubuntu Mono]} [/FONT][/COLOR][/B][B][COLOR=#000000][FONT=Ubuntu Mono] [/FONT][/COLOR][/B]Do I miss s.th. important?
EDIT: yes I did miss s.th. ...
this is a combined check for the 2 end of string conditions
either 0-terminated or 8-th bit terminated
if the char == 0 then DEC makes $FFFFFFFF so the loop terminates -> end found
if the char is not 0 then we compare the decremented char code with the $7E instead of $7F to check for the 8th bit. - pulling my hat Peter :cool:
if I still miss s.th. ... please correct ...
MJB
I've been playing with CHARLCD.fth and discovered that WriteLCD works correctly only when #dbus starts at P0. That there is a definition for this suggests, to me anyway, that it was meant to work more generally. I got around the limitation for the time being by multiplying the stack data by 256 prior to OUTSET (my dbus is wired starting at P8).
Another thing: for some reason, when I redirect EMIT on my setup (ie, > LCD ." MultiLCD V1.0 ") I get a few garbage characters on the LCD and TACHYON goes out to lunch, like it's stuck in a loop calling LCDEMIT. I'm sure something is wrong on my end, but right now I have no idea what (still looking into it).
How hard would it be to create a simple word that can output a string to the LCD by calling LCDCHAR directly?
Finally, are there any built-in words for cleaning the dictionary (like, eg, "FORGET")?
I'm sorry for all the questions, and especially sorry if I've overlooked something obvious. Please keep in mind that I'm something of a Forth neophyte.
Thanks once more for all your good efforts. I've played with Forths for several micros (eg, AMFORTH), and TACHYON has been the easiest to get into and most productive thus far. I can actually see where you might do real work with it. Fun stuff too!
Seems that there was a bug or two in this code. First off the WriteLCD word was not aligning the data to the correct bit position if the default data pins were not used. All this basically required was a SHL operation but it also meant a few little changes to the code to better support user pins so now there is the LCDPINS word plus tips on changing any other pins easily.
Second, there was a bug in the control code vector table as LOOKUP assumes that all vectors are 2 bytecodes long however I had a NOP for the null vector which is a single VM kernel bytecode and so this would have caused havoc, hence the out to lunch thing. Simply putting in two NOPs or another dummy definition is all that was required.
The reason that I don't create special words for LCD to output strings directly to it is because I find it so clunky for every I/O device to have named methods when there is no need to, hence the redirection words. This means that any output formatting capability that Tachyon has can been used to output to the LCD. Isn't it easy to type in: LCD ." Number 5 is alive, need input" rather than having duplicated methods for each device?
FORGET FORGET
I have been asked a few times about a FORGET word but as I pointed out at the time it doesn't matter if you load edited definitions when the old ones are still there. Since I use an editor or Google docs it's simply a matter of typing a ^C (or equivalent) to wipe out the stuff I've been playing with and then copy and paste. It's very quick that way, only takes seconds and there is no confusion. In the case of CHARLCD.fth it takes 3 seconds and I'm sure typing in FORGET CHARLCD.fth would probably take that long anyway. There's also some technical under the hood reasons why I don't bother with a FORGET and taking into consideration that while not having it does not impact anything or on productivity I therefore choose to forget FORGET.
Now that it is working, I would say yes. (And that is more or less what I had in mind anyway: a single word that would take a string and direct it to some specified output - in this case LCDCHAR.)
Okay, here is the situation. Right now it appears that I have two CHARLCD.fth modules stored, two versions. Probably this shouldn't be the case (I guess I did a BACKUP when I shouldn't have). Nor is it that big a deal, other than the clutter I get when I do QWORDS or MODULES. There's always the option, too, of wiping everything and starting over. Still, I couldn't help but wonder if there is a way to delete a word or module that has already been saved without having to go that route.
Well I only feel the pain when I have backed up the module too
FORGET'ing words in Tachyon involves reclamation of the vectors and header space as well as the code space but it mightn't be so messy any more like it seemed to be in the beginning.
BTW, you are always free to define your own specialized handlers for such things as sending strings directly to the LCDCHAR word but another of the advantages of keeping it as a single entry point (via EMIT) is that the display can be accessed over serial links as in the example at the end of the code document. So you can create your own custom serial LCD displays.
In this regard I could add many more functions to the LCD which I have done for my MultiLCD product (OEM) which emulates various industry standard serial LCDs as well as adds key matrix encoding, PS/2 keyboard interface, audio out, piezo transducer for tones, and SD card as well as RS485 etc.
Right now I'm especially relieved to know the LCD problems are resolved. I was at a loss trying to figure out what, exactly, I could be doing wrong.
MATCH SD WORDS
NFA PFA EXT ATRS NAME
6146 2DA0 YDC ...: SDPOLL
6150 2D74 XDC ...: SD
615F 2CCD XDB ...: SDWR
6167 2CB0 YDA ...: SDRD
6180 2C8F YD9 ...: SDRDBLK
620C 2A8E XD2 ...: SDDAT!
6216 2A71 YD1 ...: SDERR?
6254 29F0 XCE ...: SDBUSY
6267 29E4 XCD ...: SDCLK
627B 29CB XCC ...: SD4@
6283 29C3 YCB ...: SD2@
628B 29BC XCB ...: SD!
6292 29B5 YCA ...: SD@
62AA 2992 XC9 ...: SDSEL
62B3 2988 YC8 ...: SDPINS
62D4 296B YC6 ...: SDCS
62DC 2940 XC6 ...: SDMASKS
63A0 281B YBB ...: SDBUF
63B3 27F1 YBA ...: SDCARD.fth
6585 21EB Y97 ...: SDA ok
MATCH [ WORDS
NFA PFA EXT ATRS NAME
6A64 1889 Y02 ...: [~
6FFF 0BC8 X3B ...: [SSD]
7008 0B78 X3C ...: [ESPIO]
7013 0BF8 X3D ...: [SPIO]
701D 0C30 X3E ...: [SPIOD]
7028 0C6C X3F ...: [SDRD]
7032 0CA4 X40 ...: [SDWR]
703C 0CE0 X41 ...: [PWM]
7045 0D14 X42 ...: [PWM!]
704F 0D40 X43 ...: [PLOT]
73F2 13D1 X9C .I.: [COMPILE] ok
ANY + WORDS
NFA PFA EXT ATRS NAME
6842 1B40 Y43 ...: C++
6850 1B38 Y41 ...: W++
685D 1B30 Y3F ...: ++
6B15 0024 ...$ 1+
6B21 0020 ...$ +
6B40 00D8 ...$ +LOOP
6BFB 0059 ...$ C+!
6C08 0065 ...$ C@++
6C10 005D ...$ W+!
6C1D 0061 ...$ +!
7065 19BB ...: 2+
7475 1218 X9F ...: +CALL ok
You didn't mention it, but it also works wIth QWORDS ... neat! THANK YOU!
I upload, after EXTEND a list of shortcut (mostky common commands aliased in lower case, like
: my MY ;
BUT ... when I tried to do it for word MATCH the system locked up hard
The problem is QUITE REPEATABLE ... what's going on????
EDIT: The problem is that they are immediate words as Tachyon compiles on the fly rather than waiting until the end of line. Try this:
: my [COMPILE] MY ;
IMMEDIATE
Hey I thought that goes without saying (that it works with QWORDS too).......
BTW, I have been working on a decompiler and it only took a few hours and I came up with this simple one. Try it.
I get this using minicom on my mac with ANSI terminal emulation?
Try refreshing the source code page as there have been quite a number of changes to it since, same goes for the kernel and extensions too. There's also a SEEALL word that does a two pass decompilation so that it can reveal the BEGIN structures and correct indentation etc.
<Get it here>
As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.
[FONT=courier new]DECOMP I2CBUS : I2CBUS I2CSTOP $0100 0 DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0= IF CR IF ." Fast" ELSE ." Slow" THEN ." Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8 FOR 0 SI2C@ .BYTE <> NEXT 1 SI2C@ I2CSTOP THEN DROP 2 +LOOP I2CSTOP ; ( =0090 bytes ) ok [/FONT]P.S. I can see a little bug in this output, see if you can pick it and why.
Okay after a refresh and rebuild all works as advertised. Seems there is that extra space floating in the mix, haven't looked at the source to see where it may originate from though.
I tried this on a fresh build ... i.e. latest kernal and EXTEND ... running Zterm on a quad core Mac at 115200. ZTerm has never had a problem keeping up at 115200. Is there a problem ... or. more likely, where have I gone wrong?
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600 NAMES: $59AC...74C9 for 6941 (17908 bytes added) with 20544 bytes free CODE: $0000...361B for 6910 (2048 bytes added) with 18917 bytes free CALLS: 0373 vectors free AUTORUN BOOT MODULES LOADED: 2E1B: RGB8X8.fth 8x8 RGB LED Matrix Tool Kit - 20130310.1900 2C71: EXT_BBR.fth redirects for RFID/LCD/RGB/EMIC, UFO, et al. - 20130310.16000 2869: DECOMPILER.fth Tachyon Forth decompiler V1.0 130312.1620 1840: EXTEND.fth Primary extensions to TACHYON kernel - 130303.1430 ---------------------------------------------------------------- DECOMP I2CBUS : I2CBUS I2CSTOP $0100 ." " ." " ." " 5 us ." " ." =" = IF +! ." " ELSE ." ow" THEN + ." vice at " ." }" ?DUP I2CSTART I ." " ." " .BYTE <> NEXT 1 SI2C@ I2CSTOP ." " I2CSTOP ; ( =0090 bytes ) okIt's a mystery, can you do a "0 8000 IDUMP" and email me so I can check it out? Maybe if you just do a COLD and then load EXTEND.fth and then the decompiler and try it out without any of the other stuff first perhaps.
That is the weirdest. I just tried a full build and it's all okay on this end. Any chance of the hex dump?
Hey Brian I use OSX and minicom at 234000 without any issues, I'll try ZTerm later and let you know.
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600 NAMES: $6218...74C5 for 4781 (20572 bytes added) with 22700 bytes free CODE: $0000...2D47 for 6810 (1026 bytes added) with 21177 bytes free CALLS: 0607 vectors free AUTORUN BOOT MODULES LOADED: 2945: DECOMPILER.fth Tachyon Forth decompiler V1.0 130312.1620 1840: EXTEND.fth Primary extensions to TACHYON kernel - 130316.1600 ---------------------------------------------------------------- DECOMP I2CBUS : I2CBUS I2CSTOP $0100 0 DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0= IF CR IF ." Fast" ELSE ." Slow" THEN ." Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8 FOR 0 SI2C@ .BYTE <> NEXT 1 SI2C@ I2CSTOP THEN DROP 2 +LOOP I2CSTOP ; ( =0090 bytes ) okThe driver is meant to be used a standard output stream device so rather than call methods which although possible is not desired as you simply send through the stream of controls and characters. This means you could substitute an output device or access it as a remote serial display.
I use 8-bit parallel mode as standard but it can easily be adapted to 4-bit mode if you really want.