A little of topic but can you tell me why you chose to put Tachyon Forth on the Prop and not a conventional micro-controller, like a PIC or AVR?
Just curious.
regards,
rich
It's more of a case of using the Prop with Spin and PASM and wanting faster and more compact code as well as interactive development. Before coming to the Prop I had previously used the ARM chips in some designs and I had written a bytecode Forth for that which enabled to develop very compact and fast applications and in fact my entry to the Circuit Cellar ARM Design contest was based around this Forth and generating bit-banged VGA (I still get enquiries about this).
So initially I was quite happy to use Spin and borrow from the OBEX as well and I couldn't quite see how I might write a Forth for this Chip, certainly not in the same manner as I had done with the ARM chip. After I started using BST instead of the Spin tool it was possible to view the listing and make adjustments to the code to make it fit where I wanted it to go. Also, rethinking about how Forth bytecode itself (not the PASM) could be coded within the limits of the Spin tool syntax was another hurdle that was overcome by reducing all bytecode references to "bytes" that directly addressed the first 256 longs of the VM cog.
So to answer your questions I never considered ever using PICs or AVRs for running Forth as these architectures are normally 8-bit and too limited whereas the 32-bit architectures were ideal for Forth. PICs and AVRs I only used in very low-end applications, usually as a peripheral and at this level resources are limited but assembler is more than adequate.
Some time ago I started playing with handling infix notation in Forth, at least in the text interpretive stage. Here is a simple demonstration of this but it looks like I should also be able to compile this as well since the operations are stacked and execute at the end of each statement, in fact they are compiled prior to execution anyway.
LONG pbj ok
ok
PRINT pbj ok
0
ok
pbj := 1234 ok
PRINT pbj ok
1,234
ok
pbj := pbj @ * 100 ok
PRINT pbj ok
123,400
ok
PRINT 15 + 23 * 10 - 2 ok
199
PRINT 15 + DUP ok
30
PRINT " THIS IS A STRING" ok
THIS IS A STRING
If we always expect a space or more between all symbols then I think it's possible to have Forth appear as Basic, maybe even PBASIC (but a lot lot faster)
BTW, I'm not intending to write a Basic in Forth, when I look at some of the PBASIC source code rather than follow GOTO I just shudder but maybe someone might be keen.
Still trying to get that DMM reading into Tachyon :blank:
With an automated input from the DMM in the format: "DC 12.34 uA<CR>" the forth input function loses the dp position because the value is accepted as a number and DPL must be used on strings. Is there a way around this?
Still trying to get that DMM reading into Tachyon :blank:
With an automated input from the DMM in the format: "DC 12.34 uA<CR>" the forth input function loses the dp position because the value is accepted as a number and DPL must be used on strings. Is there a way around this?
I was wondering how you went but the dp position is available at the time it encounters the units such as uA etc. I can give you code that works but if you just want a hand then post your code so we can tell you where the problem is.
I've had a 14 year old boy, a son of a friend wanting to spend some time during his school holidays learning about what I do. He is a very bright boy and even the "gifted" programs at his well equipped school have been too dumbed down so I thought it practical if we did a project from scratch together so that he could get a taste for the various aspects of it. Earlier in the year I had him over for a half-day and gave him a quick intro and a run-through with stepper motor control using when of my Prop boards hooked into those cheap Ebay baby steppers and "Forth" I gave him that system so that he could experiment further.
Anyway, I have been meaning to do an RFID access control for a dumb electric gate which just uses the normal "clickers" and to also add automatic timers so that the gate would definitely be closed by late at night in case someone forgot. So after running through some design decisions I had him pasting a board, placing parts (explaining what each part did), cooking it up, soldering parts etc as well as testing various sections then bringing a board to life with a TF kernel.
Bit by bit we tested out the hardware, the RFID, the EEPROM file system, the reporting functions etc. Now he's got a really good taste of it even though it took me about six times longer to do the project! Plus he can even interrogate the unit at anytime with his phone using Blueterm. I have now tasked him in his spare time with writing a smartphone app using Bluetooth serial.
For anyone who is interested in RFID or even just control systems written in TF then this source code document may be useful.
I've had a 14 year old boy, a son of a friend wanting to spend some time during his school holidays learning about what I do. He is a very bright boy and even the "gifted" programs at his well equipped school have been too dumbed down so I thought it practical if we did a project from scratch together so that he could get a taste for the various aspects of it. Earlier in the year I had him over for a half-day and gave him a quick intro and a run-through with stepper motor control using when of my Prop boards hooked into those cheap Ebay baby steppers and "Forth" I gave him that system so that he could experiment further.
Anyway, I have been meaning to do an RFID access control for a dumb electric gate which just uses the normal "clickers" and to also add automatic timers so that the gate would definitely be closed by late at night in case someone forgot. So after running through some design decisions I had him pasting a board, placing parts (explaining what each part did), cooking it up, soldering parts etc as well as testing various sections then bringing a board to life with a TF kernel.
Bit by bit we tested out the hardware, the RFID, the EEPROM file system, the reporting functions etc. Now he's got a really good taste of it even though it took me about six times longer to do the project! Plus he can even interrogate the unit at anytime with his phone using Blueterm. I have now tasked him in his spare time with writing a smartphone app using Bluetooth serial.
For anyone who is interested in RFID or even just control systems written in TF then this source code document may be useful.
Really nice for you to share so much of your time with Jack and the results with us, thanks Peter.
If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?
If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?
All of this under control of your Forth language.
regards,
rich
Peter has mentioned he is working on "loadable modules" so that we can use say F32 pasm as a loadable module for full float support. The idea I believe is that we (tachyon users) will be able to create our own modules to use this way. Hello OBEX!!
If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?
All of this under control of your Forth language.
regards,
rich
It is my intention to have the facility to load a PASM module by name either from EEPROM or SD card into a specified cog, Quite possibly it would take this format when invoked:
" VGATEXT.COG" 5 LOADCOG
or something similar. I have played with a method of loading the EEPROM or SD in the first place by pasting a copy of the PASM listing which I know BST can do. The information is fairly easy to extract as lines of actual code are always in this format:
0018(0000) F0 97 BF 0A | getCommand rdlong cmdPtr, par wz ' wait for command
We only really need the cog address (0000) and the long F0 97 BE 0A etc and the name of the module can be extracted from the header:
Object Address : 0010 : Object Name : F32PASM
So this is one method of loading the files as source code into TF where it can generate a binary file that can be loaded into a cog at runtime.
I may have some time this month to actually test it out fully and then it would be a matter of converting code from the OBEX by stripping away all the Spin fluff and insert the few changes for hub access. This means that each cog needs to have it's own hub area for parameters which at present is already in place but there are only 8 bytes (tasks) which will need to be expanded to around 32. Perhaps this could even be a simple pointer in a fixed location that points to a parameter block so that TF could define the area and set the pointer when it loads the cog.
I will post more about how this works as I nut it out, and of course I will try to make referencing it as smooth as possible.
EDIT: just imagine, a pick and choose OBEX library loadable at runtime, all target resident and it only needs a 64k or more EEPROM instead.
That would be a great feature.
I'm a very lame programmer, so using existing code is mandatory.
I also miss a multiple serial (4 port serial style). Obviously the proposed approach would open all the obex. If the users will be able to adapt the objects in the obex and share them of will be a real boost.
Thanks for your efforts!
Massimo
Hi Peter,
I was thinking of extending 1wire to multiple sensors, found a forth implementation for SEARCHROM
and then discovered, that at the bottom of your file is some commented out code for it.
I just tried to run 1WIRE version 121025 with single DS1820+ and works fine.
The searchrom code did nur work.
1WBIT@ and 1WBIT! are not defined.
I used 1WBITRD and !WBITWR instead ... but SEARCHROM just prints "Search ROM" repeatedy
and never stops ...
is this version 121025 the latest out there?
Is SEARCHROM still untested? - looks like.
or is still some code missing?
thanks, MJB
p.s. Brian Riley - did you try more than 1 sensor?
Hi Peter,
I was thinking of extending 1wire to multiple sensors, found a forth implementation for SEARCHROM
and then discovered, that at the bottom of your file is some commented out code for it.
I just tried to run 1WIRE version 121025 with single DS1820+ and works fine.
The searchrom code did nur work.
1WBIT@ and 1WBIT! are not defined.
I used 1WBITRD and !WBITWR instead ... but SEARCHROM just prints "Search ROM" repeatedy
and never stops ...
is this version 121025 the latest out there?
Is SEARCHROM still untested? - looks like.
or is still some code missing?
thanks, MJB
p.s. Brian Riley - did you try more than 1 sensor?
I never got around to finishing the code for that, I had a problem with how they wrote the flowchart I think, such a convoluted nightmare as if it were translated from a mix of Fortran and Cobol!! So I was going to redo the algorithm until it flowed more like a world of goo and fitted in one line, well close to that anyway.
I just found some C code for this, it is only 430 lines long, I had thought I was doing something wrong when my Forth code grew to 64 lines. Maybe there's hope.
I never got around to finishing the code for that, I had a problem with how they wrote the flowchart I think, such a convoluted nightmare as if it were translated from a mix of Fortran and Cobol!! So I was going to redo the algorithm until it flowed more like a world of goo and fitted in one line, well close to that anyway.
I just found some C code for this, it is only 430 lines long, I had thought I was doing something wrong when my Forth code grew to 64 lines. Maybe there's hope.
Wow you are right about being convoluted. Found these examples/code to be not so ugly except for the second link, one wire advance search. Funny they make a chip as a 1-wire master that can be interfaced via serial (understandable) but I2C too? Nothing like layering complexity.
Peter,
It's probably a simple question answered before, but how do you switch the console to another pair of I/O pins?
Hi Mike, nice to see you around here.
Don't know about switching the console post boot but in the Tachyon source you will find this block:
' Standard Port assignments
scl = 28
sda = 29
txd = 30
rxd = 31
Seems very straight forward to change the assignments here, compile/load the kernel again onto the target and add in Extend.fth and other goodies as required.
Mike,
in the past I changed the pin assignement in the source too, but if you check the getting started guide there is a "REDIRECTING OUTPUT", so I'm rather confident you can do it on the fly.
I would like to load in EXTEND, SDCARD, and MULTIFAT via the USB programming port, then permanently switch to another pair of I/O pins connected to a WiFly module so that Tachyon comes out of reset talking to the WiFly module.
I would like to load in EXTEND, SDCARD, and MULTIFAT via the USB programming port, then permanently switch to another pair of I/O pins connected to a WiFly module so that Tachyon comes out of reset talking to the WiFly module.
Don't forget to add a header file after extend, a bit like QS.fth so that any peripherals are automatically configured although you can still force them using the SDPINS at runtime.
I don't seem to have a mechanism for redirecting the actual serial receive cog although the serial output is very easily redirected by setting the transmit mask in COGREG 6 ( mypin MASK 6 COGREG!). It would seem that if you did change the serial receive cog's rxpin after compile that you might lose the ability to talk to it again from USB. If that's not a problem then I will look at what can be done.
Of course there is redirection too but if you are intending to wipe and reload code from the WiFly module then redirection is no good.
A cheat would be to patch the EEPROM directly if you know the address of the mask which in this version is $7E40 so that "mypin MASK $7E40 E!" would patch the EEPROM. The txd mask is at $7B94. If I put these two masks in fixed locations then it should be a breeze to patch them so that you change the default.
EDIT: The other approach is to simply tie the Prop's TXD to both the USB and WiFly module and then connect the TXDs from the USB and WiFly through diodes to the P31 with a pullup as well.
Don't forget to add a header file after extend, a bit like QS.fth so that any peripherals are automatically configured although you can still force them using the SDPINS at runtime.
.
.
.
A cheat would be to patch the EEPROM directly if you know the address of the mask which in this version is $7E40 so that "mypin MASK $7E40 E!" would patch the EEPROM. The txd mask is at $7B94. If I put these two masks in fixed locations then it should be a breeze to patch them so that you change the default.
.
.
.
Diabolical, I like how you think/work Peter! Get it working, then optimize.
The WiFly module is an experiment. Using USB serial for the setup and testing is much easier than trying to download EXTEND and the other modules via WiFi. I may try that otherwise.
@Peter,
There's one place in TERMINAL's initialization where you convert txd to a mask and do an OUTSET. All other references to the serial I/O pins use txmask and rxpin for txd and rxd respectively. It would be easy to just fetch txmask to do the OUTSET, then only txmask and rxpin would need to be patched in the EEPROM to get them to be used on a reboot. The high speed serial driver is already launched and would have to be relaunched with the updated rxpin and that's too much work for something that only needs to change on a reboot.
I loaded the modules using teraterm and wifly and the process I experienced is equivalent to the "wired" one, so I'm probably missing something.
The eeprom patch looks intriguing...
Massimo
Massimo,
I have not been able to connect via Telnet using my home WiFi network which seems to work well otherwise. There may be something about the default router configuration that's interfering. If I configure the WiFly module as a soft AP, then it works, but I have to change networks on my desktop Mac to get to the WiFly AP and that is awkward because of other stuff I'm doing. I'll figure something out.
The WiFly module is an experiment. Using USB serial for the setup and testing is much easier than trying to download EXTEND and the other modules via WiFi. I may try that otherwise.
@Peter,
There's one place in TERMINAL's initialization where you convert txd to a mask and do an OUTSET. All other references to the serial I/O pins use txmask and rxpin for txd and rxd respectively. It would be easy to just fetch txmask to do the OUTSET, then only txmask and rxpin would need to be patched in the EEPROM to get them to be used on a reboot. The high speed serial driver is already launched and would have to be relaunched with the updated rxpin and that's too much work for something that only needs to change on a reboot.
The OUTSET is not required anymore but neither does it do any harm either as once I was skint for a cog long and I left out setting the pin as an output. I will get onto updating the source to allow boot-time console assignment. In the meantime, you can cheat
Mike, I had issues connecting with my router when using the wrong crypt. The Wifly supports "WPA-PSK (TKIP), and WPA2-PSK
but not WPA2-TKIP"
My router's default settings were WPA2-TKIP, so I had to change to WPA2-PSK. After that everything worked.
Maybe there is a similar issue..
Massimo
Since txd & rxd are constants, why not do the following: e.g., #6 TO txd #7 TO rxd BACKUP, then reboot.
TO is defined as : TO ' 2+ ! ;
NickL
But this will be the result:
txd --> txd <-- NOT FOUND
rxd --> rxd <-- NOT FOUND
0 20 DUMP
0000_0000: D0 1D B9 04 6E A7 10 00 AC 7E B4 7E 80 7E B8 7E ....n....~.~.~.~
0000_0010: 00 00 00 00 70 7E 00 00 3F 18 61 01 00 00 00 00 ....p~..?.a..... ok
#6 TO rxd ok
0 20 DUMP
0000_0000: 06 00 00 00 6E A7 10 00 AC 7E B4 7E 80 7E B8 7E ....n....~.~.~.~
0000_0010: 00 00 00 00 70 7E 00 00 3F 18 61 01 00 00 00 00 ....p~..?.a..... ok
CLKFREQ . 6 ok
So since txd and rxd do not exist at the Forth level you will find that TO happily obliges but since TF always leaves a zero for any failed tick operation you end up saying "#6 0 1+ !" (it's a 1+, not 2+) and the poor clkfreq word gets clobbered.
Comments
It's more of a case of using the Prop with Spin and PASM and wanting faster and more compact code as well as interactive development. Before coming to the Prop I had previously used the ARM chips in some designs and I had written a bytecode Forth for that which enabled to develop very compact and fast applications and in fact my entry to the Circuit Cellar ARM Design contest was based around this Forth and generating bit-banged VGA (I still get enquiries about this).
So initially I was quite happy to use Spin and borrow from the OBEX as well and I couldn't quite see how I might write a Forth for this Chip, certainly not in the same manner as I had done with the ARM chip. After I started using BST instead of the Spin tool it was possible to view the listing and make adjustments to the code to make it fit where I wanted it to go. Also, rethinking about how Forth bytecode itself (not the PASM) could be coded within the limits of the Spin tool syntax was another hurdle that was overcome by reducing all bytecode references to "bytes" that directly addressed the first 256 longs of the VM cog.
So to answer your questions I never considered ever using PICs or AVRs for running Forth as these architectures are normally 8-bit and too limited whereas the 32-bit architectures were ideal for Forth. PICs and AVRs I only used in very low-end applications, usually as a peripheral and at this level resources are limited but assembler is more than adequate.
Continuing Peter's intial code here's a simple Mode 2 A2D read word , CH@
LONG pbj ok
ok
PRINT pbj ok
0
ok
pbj := 1234 ok
PRINT pbj ok
1,234
ok
pbj := pbj @ * 100 ok
PRINT pbj ok
123,400
ok
PRINT 15 + 23 * 10 - 2 ok
199
PRINT 15 + DUP ok
30
PRINT " THIS IS A STRING" ok
THIS IS A STRING
If we always expect a space or more between all symbols then I think it's possible to have Forth appear as Basic, maybe even PBASIC (but a lot lot faster)
BTW, I'm not intending to write a Basic in Forth, when I look at some of the PBASIC source code rather than follow GOTO I just shudder but maybe someone might be keen.
Still trying to get that DMM reading into Tachyon :blank:
With an automated input from the DMM in the format: "DC 12.34 uA<CR>" the forth input function loses the dp position because the value is accepted as a number and DPL must be used on strings. Is there a way around this?
I was wondering how you went but the dp position is available at the time it encounters the units such as uA etc. I can give you code that works but if you just want a hand then post your code so we can tell you where the problem is.
Anyway, I have been meaning to do an RFID access control for a dumb electric gate which just uses the normal "clickers" and to also add automatic timers so that the gate would definitely be closed by late at night in case someone forgot. So after running through some design decisions I had him pasting a board, placing parts (explaining what each part did), cooking it up, soldering parts etc as well as testing various sections then bringing a board to life with a TF kernel.
Bit by bit we tested out the hardware, the RFID, the EEPROM file system, the reporting functions etc. Now he's got a really good taste of it even though it took me about six times longer to do the project! Plus he can even interrogate the unit at anytime with his phone using Blueterm. I have now tasked him in his spare time with writing a smartphone app using Bluetooth serial.
For anyone who is interested in RFID or even just control systems written in TF then this source code document may be useful.
Really nice for you to share so much of your time with Jack and the results with us, thanks Peter.
Absolutely!
If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?
All of this under control of your Forth language.
regards,
rich
Peter has mentioned he is working on "loadable modules" so that we can use say F32 pasm as a loadable module for full float support. The idea I believe is that we (tachyon users) will be able to create our own modules to use this way. Hello OBEX!!
It is my intention to have the facility to load a PASM module by name either from EEPROM or SD card into a specified cog, Quite possibly it would take this format when invoked:
" VGATEXT.COG" 5 LOADCOG
or something similar. I have played with a method of loading the EEPROM or SD in the first place by pasting a copy of the PASM listing which I know BST can do. The information is fairly easy to extract as lines of actual code are always in this format: We only really need the cog address (0000) and the long F0 97 BE 0A etc and the name of the module can be extracted from the header:
Object Address : 0010 : Object Name : F32PASM
So this is one method of loading the files as source code into TF where it can generate a binary file that can be loaded into a cog at runtime.
I may have some time this month to actually test it out fully and then it would be a matter of converting code from the OBEX by stripping away all the Spin fluff and insert the few changes for hub access. This means that each cog needs to have it's own hub area for parameters which at present is already in place but there are only 8 bytes (tasks) which will need to be expanded to around 32. Perhaps this could even be a simple pointer in a fixed location that points to a parameter block so that TF could define the area and set the pointer when it loads the cog.
I will post more about how this works as I nut it out, and of course I will try to make referencing it as smooth as possible.
EDIT: just imagine, a pick and choose OBEX library loadable at runtime, all target resident and it only needs a 64k or more EEPROM instead.
I'm a very lame programmer, so using existing code is mandatory.
I also miss a multiple serial (4 port serial style). Obviously the proposed approach would open all the obex. If the users will be able to adapt the objects in the obex and share them of will be a real boost.
Thanks for your efforts!
Massimo
I was thinking of extending 1wire to multiple sensors, found a forth implementation for SEARCHROM
and then discovered, that at the bottom of your file is some commented out code for it.
I just tried to run 1WIRE version 121025 with single DS1820+ and works fine.
The searchrom code did nur work.
1WBIT@ and 1WBIT! are not defined.
I used 1WBITRD and !WBITWR instead ... but SEARCHROM just prints "Search ROM" repeatedy
and never stops ...
is this version 121025 the latest out there?
Is SEARCHROM still untested? - looks like.
or is still some code missing?
thanks, MJB
p.s. Brian Riley - did you try more than 1 sensor?
I never got around to finishing the code for that, I had a problem with how they wrote the flowchart I think, such a convoluted nightmare as if it were translated from a mix of Fortran and Cobol!! So I was going to redo the algorithm until it flowed more like a world of goo and fitted in one line, well close to that anyway.
I just found some C code for this, it is only 430 lines long, I had thought I was doing something wrong when my Forth code grew to 64 lines. Maybe there's hope.
Wow you are right about being convoluted. Found these examples/code to be not so ugly except for the second link, one wire advance search. Funny they make a chip as a 1-wire master that can be interfaced via serial (understandable) but I2C too? Nothing like layering complexity.
http://www.maximintegrated.com/app-notes/index.mvp/id/126]
http://www.maximintegrated.com/app-notes/index.mvp/id/187
It's probably a simple question answered before, but how do you switch the console to another pair of I/O pins?
Don't know about switching the console post boot but in the Tachyon source you will find this block:
Seems very straight forward to change the assignments here, compile/load the kernel again onto the target and add in Extend.fth and other goodies as required.
Have fun
https://docs.google.com/document/d/1a2j0thJWkBpulZiL4v7GukSL_utJouoau3ZDgPKEiIc/pub
in the past I changed the pin assignement in the source too, but if you check the getting started guide there is a "REDIRECTING OUTPUT", so I'm rather confident you can do it on the fly.
Massimo
Don't forget to add a header file after extend, a bit like QS.fth so that any peripherals are automatically configured although you can still force them using the SDPINS at runtime.
I don't seem to have a mechanism for redirecting the actual serial receive cog although the serial output is very easily redirected by setting the transmit mask in COGREG 6 ( mypin MASK 6 COGREG!). It would seem that if you did change the serial receive cog's rxpin after compile that you might lose the ability to talk to it again from USB. If that's not a problem then I will look at what can be done.
Of course there is redirection too but if you are intending to wipe and reload code from the WiFly module then redirection is no good.
A cheat would be to patch the EEPROM directly if you know the address of the mask which in this version is $7E40 so that "mypin MASK $7E40 E!" would patch the EEPROM. The txd mask is at $7B94. If I put these two masks in fixed locations then it should be a breeze to patch them so that you change the default.
EDIT: The other approach is to simply tie the Prop's TXD to both the USB and WiFly module and then connect the TXDs from the USB and WiFly through diodes to the P31 with a pullup as well.
Diabolical, I like how you think/work Peter! Get it working, then optimize.
Why you prefer to load the modules via USB and not directly via the Wifly?
Massimo
@Peter,
There's one place in TERMINAL's initialization where you convert txd to a mask and do an OUTSET. All other references to the serial I/O pins use txmask and rxpin for txd and rxd respectively. It would be easy to just fetch txmask to do the OUTSET, then only txmask and rxpin would need to be patched in the EEPROM to get them to be used on a reboot. The high speed serial driver is already launched and would have to be relaunched with the updated rxpin and that's too much work for something that only needs to change on a reboot.
The eeprom patch looks intriguing...
Massimo
I have not been able to connect via Telnet using my home WiFi network which seems to work well otherwise. There may be something about the default router configuration that's interfering. If I configure the WiFly module as a soft AP, then it works, but I have to change networks on my desktop Mac to get to the WiFly AP and that is awkward because of other stuff I'm doing. I'll figure something out.
The OUTSET is not required anymore but neither does it do any harm either as once I was skint for a cog long and I left out setting the pin as an output. I will get onto updating the source to allow boot-time console assignment. In the meantime, you can cheat
but not WPA2-TKIP"
My router's default settings were WPA2-TKIP, so I had to change to WPA2-PSK. After that everything worked.
Maybe there is a similar issue..
Massimo
Since txd & rxd are constants, why not do the following: e.g., #6 TO txd #7 TO rxd BACKUP, then reboot.
TO is defined as : TO ' 2+ ! ;
NickL
Right! Forgot about this feature of Tachyon "contants", thanks.
So since txd and rxd do not exist at the Forth level you will find that TO happily obliges but since TF always leaves a zero for any failed tick operation you end up saying "#6 0 1+ !" (it's a 1+, not 2+) and the poor clkfreq word gets clobbered.