Peter,
I am going to experiment with an MCP3202 ADC. While I intend to eventually use the Smart Pin SPI mode, I wanted to first bit bang it as a way learn some more about forth and the P2ES. It is something I've done with other languages and the P1.
I hope to eventually use the ADC Smart pin mode instead of the 3204.
Tom
search for SPI in TAQOS.SPIN2 for the bitbanged SPI routines
Peter,
I am going to experiment with an MCP3202 ADC. While I intend to eventually use the Smart Pin SPI mode, I wanted to first bit bang it as a way learn some more about forth and the P2ES. It is something I've done with other languages and the P1.
I hope to eventually use the ADC Smart pin mode instead of the 3204.
Tom
There are SPI instructions that will write up to 32 bits in 2us @180MHz so these are instructions you could look at later on as well as the Smart pin modes, which aren't very well documented so I haven't tried them yet.
Bit banging serial at the low level usually involves shifting data one bit at a time, testing a bit, and setting an output then clocking it etc. Here's a simple send serial method that can transmit just the number of bits you need. Reading involves the reverse where you read data and assemble while clocking, and justify and flip msb/lsb if needed at the end (sending will justify and flip at the start).
This is about the most basic as it gets method and takes about 22us to send 4 bits @180MHz.
--- define SPI pins
0 := *SCLK 1 := *MOSI 2 := *MISO 3 := *SS
--- Send n bits of data over SPI bus and leave chip selected
pub SEND ( data bits -- )
--- reset/idle select justify & flip msb<>lsb
*SS HIGH *SCLK LOW *SS LOW SWAP 32 3RD - << REV ( bits flipdata ) SWAP
FOR
--- set MOSI high or low according to next bit of data
*MOSI OVER 1 AND IF HIGH ELSE LOW THEN
--- clock data
*SCLK HIGH *SCLK LOW
--- shift data (actually performs a SHR)
2/
NEXT
DROP
;
Peter,
Thanks for the information. I had tried writing the section that would take the command and transmit it to a pin MSBFIRST. I originally wrote it so the program would print each bit (1s and 0s) to the terminal and flash 2 LEDs for each bit (one if HIGH and the other if LOW) so I could see if it worked. I tend to use a lot of variables, but see how you use constants where appropriate. I modified the original code to remove the prints & flashing LEDs and this is what I have so far:
0 := *SCLK 1 := *MOSI 2 := *MISO 3 := *SS \ As used by PJ
long numbits
: sendcmd ( data numbits )
32 swap - ( data numbits -- data 32-numbits )
<< dup ( -- data shifted to MSB )
numbits @ 0 DO
1 rol dup 1 AND
if *MOSI high
else *MOSI low
then
--- clock data from PJ
*SCLK HIGH *SCLK LOW
loop drop ;
I did not test the modified code yet, and I want to make sure I understand how yours works.
Thanks again,
Tom
Stack notation does not set anything, it is only a comment. So ( data numbits ) is totally ignored therefore "numbits @" will simply read the default 0 since nothing has been stored to it. Better to preserve the numbits on the stack, using a copy (in my case with the 3RD word) to calculate the left justification and then I SWAP the stack and use FOR since there is no need for a more complex ADO LOOP. Using REV is a quick way of flipping all the bits at once where bit31<->bit0 and bit30<->bit1 etc.
Since there are only two parameters it doesn't make any sense to use variables, just move then around the stack as needed. It's very rare that you need variables inside a function especially if you have factored the code in such a way that makes it easy for each function to manipulate the stack.
My sequence with SWAP 32 3RD - << REV ( bits flipdata ) is a quick and efficient way of doing that for instance as you can see from this sequence:
( data bits )
SWAP ( bits data )
32 ( bits data 32 )
3RD ( bits data 32 bits )
- ( bits data 32-bits )
<< ( bits data_left_justified )
REV ( bits data_flipped )
BTW, There is also the 1& word which is equivalent to 1 AND but much faster.
Peter,
Thanks for catching the numbits error. I sometimes get in trouble when I change from test code (with printing & other debug features). That's what happened this time. When I was debugging, after I defined sendcmd, I used the following to call it (pinnum was a variable in the earlier version, 26 was the "data")
5 numbits ! 2 pinnum ! 26 numbits @ sendcmd
That way I could test the code on different numbers of bits & data,
One problem I have is being too verbose. A lot of my forth code looks more like Reverse Polish BASIC I'm trying to carefully follow your programs since they are much more efficient.
Thanks for the info on 3rd and 1&. There are a lot of TAQOZ words that I don't know yet.
Tom, The SEND example I gave takes two parameters just so you can specify exactly the number of bits you need to send.
What helps I find is using a comment row rather than a column since I tend to cram a few words together on the one line, especially if they are closely related and having the line above allows me to spell it all out if it need be. But we are always encouraged to factor into smaller words that are easily understood. Another benefit of factoring wisely and after choosing an appropriate name is that you hardly need comments:
--- define SPI pins
0 := *SCLK 1 := *MOSI 2 := *MISO 3 := *SS
pri SENDBIT ( data -- data/2 ) *MOSI OVER 1 AND IF HIGH ELSE LOW THEN 2/ ;
pri CLOCKBIT *SCLK HIGH *SCLK LOW ;
pri SENDBITS ( data bits -- ) FOR SENDBIT CLOCKBIT NEXT DROP ;
pri START *SS HIGH *SCLK LOW *SS LOW ;
pri FIXBITS ( data bits -- data2 bits ) SWAP 32 3RD - << REV SWAP ;
--- Send n bits of data over SPI bus and leave chip selected
pub SEND ( data bits -- ) START FIXBITS SENDBITS ;
Peter,
Your last example is very readable and is the classic method of defining small bite size words and then defining the one word that ties them together. Is there a disadvantage in performance or memory use (thinking about the P1 or the P2 ROM) from factoring that way? And I see the advantage of line comments.
Tom, there is always a decrease in speed but not by much. The only real test is a real test, so I ran both with 4 bits of data and compared the results.
The original all-in-one
TAQOZ# 0 4 LAP SEND LAP .LAP 4,041 cycles= 22,450ns @180MHz ok
The factored code
TAQOZ# 0 4 LAP SEND LAP .LAP 4,737 cycles= 26,316ns @180MHz ok
But with one very minor change where we let SENDBIT fall through to CLOCKBIT by removing the ; and then only using SENDBIT in the FOR NEXT loop:
TAQOZ# 0 4 LAP SEND LAP .LAP 4,457 cycles= 24,761ns @180MHz ok
This is a quick test with the .LAP word in EXTEND as the ROM built-in one might not be reporting correctly.
TAQOZ# 4 numbits ! 11 numbits @ lap sendcmd lap .lap 4,169 cycles= 23,161ns @180MHz ok
TAQOZ# 8 numbits ! 11 numbits @ lap sendcmd lap .lap 7,561 cycles= 42,005ns @180MHz ok
So it still takes longer than the non-factored stack version which takes 4041 cycles vs the 4169 for the one that uses variables although the critical timing is the loop itself. But there is no real reason to use variables unless you want to set and forget like this:
: SBITS numbits ! ;
4 SBITS
$0C SEND
$03 SEND
etc
But having to store to a variable when it is much easier to manipulate the stack isn't very practical.
The latest version of TAQOZ is coming together and will be stored as a binary image in the ROM to be decompressed into RAM so we can cram a lot more into there. Since it no longer needs to be compiled along with Chip's and Cluso99's boot code, it no longer needs to be the mix of P2ASM code and data structures that it had to be. So now I have stripped out sections of the Forth code so that I have a minimal kernel which can then run on the P2 and then compile Forth source code through the terminal.
This memory image can then be compressed and the only P2ASM code I need to integrate into the boot ROM is the decompression routine which may only use 100 longs or less.
I'm thinking too that I can write an SD format and general disk utility tool that can be pasted in as needed but if we had a larger ROM than anything including a P2 assembler is possible to have just built into the P2 itself.
Sounds very good Peter. So far, roughly how much extra space did you manage to free up using the decompression routines you have been playing with? And what extra features have you been able to, or hope to, add to TAQOZ to make use of this larger space?
I'm shooting from the hip here but I figure if I make it compelling enough with a built-in assembler that handles standard P2ASM, AND includes disk tools and formatting, AND can talk via the serial console OR via VGA and keyboard, then maybe a larger ROM is something that Chip would consider since he already said that it is possible. This is not to say that PC tools don't have their place, but the thing is that they do have their place, and there is room for other kinds of tools that can reside on the P2 or mobile devices. Having tools on the P2 makes it easier to develop tools on other platforms, including PCs.
I'm shooting from the hip here but I figure if I make it compelling enough with a built-in assembler that handles standard P2ASM, AND includes disk tools and formatting, AND can talk via the serial console OR via VGA and keyboard, then maybe a larger ROM is something that Chip would consider since he already said that it is possible. This is not to say that PC tools don't have their place, but the thing is that they do have their place, and there is room for other kinds of tools that can reside on the P2 or mobile devices. Having tools on the P2 makes it easier to develop tools on other platforms, including PCs.
+1
But, there may not be space anymore, with all the added ADC logic
+1
But, there may not be space anymore, with all the added ADC logic
Well I just want to see the equivalent microphone to VGA demo that they ran so "easily" on the P1
I'm sure with the P2's versatile ADC modes it could probably detect sound vibrations directly in the silicon itself, or at least with a bit of wire
I'm shooting from the hip here but I figure if I make it compelling enough with a built-in assembler that handles standard P2ASM, AND includes disk tools and formatting, AND can talk via the serial console OR via VGA and keyboard, then maybe a larger ROM is something that Chip would consider since he already said that it is possible. This is not to say that PC tools don't have their place, but the thing is that they do have their place, and there is room for other kinds of tools that can reside on the P2 or mobile devices. Having tools on the P2 makes it easier to develop tools on other platforms, including PCs.
Sounds awesome. Really hope you can get an assembler in there with VGA/kbd, would be amazing to have that built in.
There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.
I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.
There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.
I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.
RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.
The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.
There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.
I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.
RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.
The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.
There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.
I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.
RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.
The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.
Support for this is not in the current ROM but of course you can paste in the code for it as soon as I make it available but the next ROM should automatically detect if it is connected and use those settings, very much like it does now in Tachyon for the P1.
A lot of those boards are huge whereas I just use a small 8-pin SOIC chip with a small supercap, so much simpler and no lithium safety worries or dead battery.
Like a few others have mentioned, I am having a hard time picking up Forth/TAQOZ. Fundamentally, Forth is pretty straight forward, but I am finding that I'm having two recurring problems:
1. The vocabulary (words?) are not intuitive to me. I'm guessing this is because it doesn't follow naming patterns I've become accustom to in other languages. I'm also assuming this is somewhat like learning any other language's support library APIs. That said, since it looks like TAQOZ is here to stay, Parallax needs an official page that documents all of the built-in words. I think Peter already has one you can start from. Secondly, there needs to be a HELP (or similar) word that tells the user where to find that documentation.
2. I'm finding Forth to be a write-only language. When I am thinking through the steps to write a snippet, I find it fairly straight forward (barring issue #1). However, when I read other people's snippets, I find it very slow and cumbersome. This is particularly the case when trying to divine one-character words, which are incomprehensible without external documentation. Again, I admit this may just be a matter of familiarity. I don't even know how many of these words are "standard Forth" (assuming that's even a thing).
If anyone has suggestions on how to overcome these two problems, I'm all ears!
Apart from that, the other reason I mention all this is that I am concerned about how TAQOZ will be perceived by the broader user base. I think Parallax needs to be really careful how it markets this feature. If people perceive TAQOZ as an integral part of the P2 and find it to be difficult to learn, then they will likely perceive the entire P2 as difficult to learn. I suspect the most effective way to market it is to not market it at all. Instead, consider it a "pseudo-hidden feature". It's there, but it's not the primary way the P2 is intended to be used. I'm certain that those who know Forth and those who want to hack on the P2 without needing anything else will "find" TAQOZ and use it.
I agree with a lot of what Seairth just said.
I'd market as an expert diagnostic tool.
It is very useful for seeing if your P2 is alive and well...
But, there needs to be better help...
Honestly, the way I would frame it, is as a learning tool, but only those people who are interested in bootstrapping or bringing Hardware from ground zero, or interested in other low-level type of operations.
A few people are going to end up like Peter, very adept, and they'd use it for all sorts of things.
Given smart docs, a fair number of people would be one or few liners. Assemble, power up, test...
I think having it there can speak to just how potent FORTH can be for early, bootstrapping type tasks. Anyone interested in all of that can definitely benefit from TAQOS. Great skill to have.
One could build up a little forth in a kb or two of assembly, then throw a dictionary at it and be up and running pretty darn quick. We all saw Peter do exactly that on P2.
Frame it that way, and those who are interested, or could be interested, know it is there and why.
Others can move on with no worries.
My .02
Re: write only
Yeah, one has to take the time to look at the words others have defined. Forth itself is tiny. It is what people do with it that takes time and skill to understand.
It literally becomes a language to solve a task, IMHO. There are always "core" words, those shipped with the system.
From there, people can, will define whatever they want.
...
2. I'm finding Forth to be a write-only language. When I am thinking through the steps to write a snippet, I find it fairly straight forward (barring issue #1). However, when I read other people's snippets, I find it very slow and cumbersome. This is particularly the case when trying to divine one-character words, which are incomprehensible without external documentation. Again, I admit this may just be a matter of familiarity. I don't even know how many of these words are "standard Forth" (assuming that's even a thing).
...
Very short words are likely driven by the hard ROM ceiling.
Maybe this needs a 'helper gui/terminal', that accepts longer words, but strips them when composing a TAQOZ line ?
Or, perhaps TAQOZ could even become 'word length tolerant', when it has a unique match, any following characters are skipped until a space ?
(tho that may also bump into the hard ROM ceiling..)
Hello Everyone
I created a word to calculate Fibonacci numbers, it is non-recursive. so I thought I would show everyone the code and the output.
I recently purchased a book called "STARTING FORTH" by Leo Brodie on Amazon.com for over $7.00. My new book has really helped me out in learning Forth.
What would be a technical argument against BlocklyProp outputting Forth/TAQOZ (instead of or perhaps in addition to C/C++)?
Quite a few... I'd imagine.
BlocklyProp already outputs well supported C
TAQOZ is very compact, and has limited libraries and would need a lot of upstream buy-in.
So it's not TAQOZ any more, but some loaded firmware variant, and you need to keep the loaded variant, and BlocklyProp in phase...
The most streamlined path for BlocklyProp on P2, would be to have fastspin made good enough to accept the BlocklyProp C language subset.
Progress on fastspin seems very rapid and it supports 3 high level languages.
What would be a technical argument against BlocklyProp outputting Forth/TAQOZ (instead of or perhaps in addition to C/C++)?
Quite a few... I'd imagine.
BlocklyProp already outputs well supported C
TAQOZ is very compact, and has limited libraries and would need a lot of upstream buy-in.
So it's not TAQOZ any more, but some loaded firmware variant, and you need to keep the loaded variant, and BlocklyProp in phase...
The most streamlined path for BlocklyProp on P2, would be to have fastspin made good enough to accept the BlocklyProp C language subset.
Progress on fastspin seems very rapid and it supports 3 high level languages.
Good points. All of which caused me to take a much closer look at fastspin and its kin. Is there a clear way to make functions and/or objects developed in fastspin usable inside TAQOZ?
Good points. All of which caused me to take a much closer look at fastspin and its kin. Is there a clear way to make functions and/or objects developed in fastspin usable inside TAQOZ?
Not so much a 'clear way'. TAQOZ is intended to load from ROM, and operate standalone.
The issues with external calls are mainly housekeeping ones : somehow, you need to collect final physical address, and physical address and sizes of any parameters, and manually pass all of that information to TAQOZ
If you make a mistake in any of that, how should TAQOZ report errors ?
Comments
search for SPI in TAQOS.SPIN2 for the bitbanged SPI routines
There are SPI instructions that will write up to 32 bits in 2us @180MHz so these are instructions you could look at later on as well as the Smart pin modes, which aren't very well documented so I haven't tried them yet.
Bit banging serial at the low level usually involves shifting data one bit at a time, testing a bit, and setting an output then clocking it etc. Here's a simple send serial method that can transmit just the number of bits you need. Reading involves the reverse where you read data and assemble while clocking, and justify and flip msb/lsb if needed at the end (sending will justify and flip at the start).
This is about the most basic as it gets method and takes about 22us to send 4 bits @180MHz.
--- define SPI pins 0 := *SCLK 1 := *MOSI 2 := *MISO 3 := *SS --- Send n bits of data over SPI bus and leave chip selected pub SEND ( data bits -- ) --- reset/idle select justify & flip msb<>lsb *SS HIGH *SCLK LOW *SS LOW SWAP 32 3RD - << REV ( bits flipdata ) SWAP FOR --- set MOSI high or low according to next bit of data *MOSI OVER 1 AND IF HIGH ELSE LOW THEN --- clock data *SCLK HIGH *SCLK LOW --- shift data (actually performs a SHR) 2/ NEXT DROP ;Thanks for the information. I had tried writing the section that would take the command and transmit it to a pin MSBFIRST. I originally wrote it so the program would print each bit (1s and 0s) to the terminal and flash 2 LEDs for each bit (one if HIGH and the other if LOW) so I could see if it worked. I tend to use a lot of variables, but see how you use constants where appropriate. I modified the original code to remove the prints & flashing LEDs and this is what I have so far:
0 := *SCLK 1 := *MOSI 2 := *MISO 3 := *SS \ As used by PJ long numbits : sendcmd ( data numbits ) 32 swap - ( data numbits -- data 32-numbits ) << dup ( -- data shifted to MSB ) numbits @ 0 DO 1 rol dup 1 AND if *MOSI high else *MOSI low then --- clock data from PJ *SCLK HIGH *SCLK LOW loop drop ;I did not test the modified code yet, and I want to make sure I understand how yours works.Thanks again,
Tom
Stack notation does not set anything, it is only a comment. So ( data numbits ) is totally ignored therefore "numbits @" will simply read the default 0 since nothing has been stored to it. Better to preserve the numbits on the stack, using a copy (in my case with the 3RD word) to calculate the left justification and then I SWAP the stack and use FOR since there is no need for a more complex ADO LOOP. Using REV is a quick way of flipping all the bits at once where bit31<->bit0 and bit30<->bit1 etc.
Since there are only two parameters it doesn't make any sense to use variables, just move then around the stack as needed. It's very rare that you need variables inside a function especially if you have factored the code in such a way that makes it easy for each function to manipulate the stack.
My sequence with SWAP 32 3RD - << REV ( bits flipdata ) is a quick and efficient way of doing that for instance as you can see from this sequence:
BTW, There is also the 1& word which is equivalent to 1 AND but much faster.
Thanks for catching the numbits error. I sometimes get in trouble when I change from test code (with printing & other debug features). That's what happened this time. When I was debugging, after I defined sendcmd, I used the following to call it (pinnum was a variable in the earlier version, 26 was the "data")
That way I could test the code on different numbers of bits & data,
One problem I have is being too verbose. A lot of my forth code looks more like Reverse Polish BASIC
Thanks for the info on 3rd and 1&. There are a lot of TAQOZ words that I don't know yet.
What helps I find is using a comment row rather than a column since I tend to cram a few words together on the one line, especially if they are closely related and having the line above allows me to spell it all out if it need be. But we are always encouraged to factor into smaller words that are easily understood. Another benefit of factoring wisely and after choosing an appropriate name is that you hardly need comments:
Your last example is very readable and is the classic method of defining small bite size words and then defining the one word that ties them together. Is there a disadvantage in performance or memory use (thinking about the P1 or the P2 ROM) from factoring that way? And I see the advantage of line comments.
Tom
The original all-in-one
The factored code
But with one very minor change where we let SENDBIT fall through to CLOCKBIT by removing the ; and then only using SENDBIT in the FOR NEXT loop:
Well I'm embarrassed, but I've learned a lot. Running my "Reverse Polish Basic" version with variables it is over twice as long.
My number of cycles is actually less than your longer versions, but the time is twice as long. Is that due to the delays in fetching the variable?
Tom
So it still takes longer than the non-factored stack version which takes 4041 cycles vs the 4169 for the one that uses variables although the critical timing is the loop itself. But there is no real reason to use variables unless you want to set and forget like this: But having to store to a variable when it is much easier to manipulate the stack isn't very practical.
This memory image can then be compressed and the only P2ASM code I need to integrate into the boot ROM is the decompression routine which may only use 100 longs or less.
I'm thinking too that I can write an SD format and general disk utility tool that can be pasted in as needed but if we had a larger ROM than anything including a P2 assembler is possible to have just built into the P2 itself.
But, there may not be space anymore, with all the added ADC logic
Well I just want to see the equivalent microphone to VGA demo that they ran so "easily" on the P1
I'm sure with the P2's versatile ADC modes it could probably detect sound vibrations directly in the silicon itself, or at least with a bit of wire
Sounds awesome. Really hope you can get an assembler in there with VGA/kbd, would be amazing to have that built in.
There has been a lot of talk about which 'SD Cards" TAQOZ will support and how TAQOZ might format them.
I think it would be a great, if TAQOZ could use the correct time and date from a "DS1302 Real Time Clock Module" or a similar part, when "writing to" or "formatting" a SD Card.
A "DS1302 Real Time Clock Module" is one of the first things I plan to put on my "64006-ES(e) - Mini-Prototype board"
RTC support for sure, DS1302 maybe not. Why? Well I used those chips around 20 years ago but I favor I2C bus devices and DS3231M style chips even more since they don't need a crystal and are more accurate. Anything SPI bus requires dedicated pins whereas I2C can be shared among many devices. At present I am checking to see whether P58 and P59 of the boots pins can be used since that would not require any other dedicated pins.
The RTC routines in TAQOZ V2 include a background timer function that tracks milliseconds from which time stamps and time and date are read without having to access the slow and awkward RTC chip. The RTC chip itself is read on boot and the time converted to milliseconds. At midnight the millisecond timer resynchronizes with the RTC and thereby also updates the date and day info. Reading a global variable for timestamp is way faster than trying to serially read a chip with archaic BCD registers.
Cool :cool: , so a Clock Board that uses a DS3231, like say Adafruit DS3231 Precision RTC Breakout or ChronoDot - Ultra-precise Real Time Clock should work?
Support for this is not in the current ROM but of course you can paste in the code for it as soon as I make it available but the next ROM should automatically detect if it is connected and use those settings, very much like it does now in Tachyon for the P1.
A lot of those boards are huge whereas I just use a small 8-pin SOIC chip with a small supercap, so much simpler and no lithium safety worries or dead battery.
1. The vocabulary (words?) are not intuitive to me. I'm guessing this is because it doesn't follow naming patterns I've become accustom to in other languages. I'm also assuming this is somewhat like learning any other language's support library APIs. That said, since it looks like TAQOZ is here to stay, Parallax needs an official page that documents all of the built-in words. I think Peter already has one you can start from. Secondly, there needs to be a HELP (or similar) word that tells the user where to find that documentation.
2. I'm finding Forth to be a write-only language. When I am thinking through the steps to write a snippet, I find it fairly straight forward (barring issue #1). However, when I read other people's snippets, I find it very slow and cumbersome. This is particularly the case when trying to divine one-character words, which are incomprehensible without external documentation. Again, I admit this may just be a matter of familiarity. I don't even know how many of these words are "standard Forth" (assuming that's even a thing).
If anyone has suggestions on how to overcome these two problems, I'm all ears!
Apart from that, the other reason I mention all this is that I am concerned about how TAQOZ will be perceived by the broader user base. I think Parallax needs to be really careful how it markets this feature. If people perceive TAQOZ as an integral part of the P2 and find it to be difficult to learn, then they will likely perceive the entire P2 as difficult to learn. I suspect the most effective way to market it is to not market it at all. Instead, consider it a "pseudo-hidden feature". It's there, but it's not the primary way the P2 is intended to be used. I'm certain that those who know Forth and those who want to hack on the P2 without needing anything else will "find" TAQOZ and use it.
I'd market as an expert diagnostic tool.
It is very useful for seeing if your P2 is alive and well...
But, there needs to be better help...
Honestly, the way I would frame it, is as a learning tool, but only those people who are interested in bootstrapping or bringing Hardware from ground zero, or interested in other low-level type of operations.
A few people are going to end up like Peter, very adept, and they'd use it for all sorts of things.
Given smart docs, a fair number of people would be one or few liners. Assemble, power up, test...
I think having it there can speak to just how potent FORTH can be for early, bootstrapping type tasks. Anyone interested in all of that can definitely benefit from TAQOS. Great skill to have.
One could build up a little forth in a kb or two of assembly, then throw a dictionary at it and be up and running pretty darn quick. We all saw Peter do exactly that on P2.
Frame it that way, and those who are interested, or could be interested, know it is there and why.
Others can move on with no worries.
My .02
Re: write only
Yeah, one has to take the time to look at the words others have defined. Forth itself is tiny. It is what people do with it that takes time and skill to understand.
It literally becomes a language to solve a task, IMHO. There are always "core" words, those shipped with the system.
From there, people can, will define whatever they want.
Maybe this needs a 'helper gui/terminal', that accepts longer words, but strips them when composing a TAQOZ line ?
Or, perhaps TAQOZ could even become 'word length tolerant', when it has a unique match, any following characters are skipped until a space ?
(tho that may also bump into the hard ROM ceiling..)
I created a word to calculate Fibonacci numbers, it is non-recursive. so I thought I would show everyone the code and the output.
I recently purchased a book called "STARTING FORTH" by Leo Brodie on Amazon.com for over $7.00. My new book has really helped me out in learning Forth.
HydraHacker
Quite a few... I'd imagine.
BlocklyProp already outputs well supported C
TAQOZ is very compact, and has limited libraries and would need a lot of upstream buy-in.
So it's not TAQOZ any more, but some loaded firmware variant, and you need to keep the loaded variant, and BlocklyProp in phase...
The most streamlined path for BlocklyProp on P2, would be to have fastspin made good enough to accept the BlocklyProp C language subset.
Progress on fastspin seems very rapid and it supports 3 high level languages.
Good points. All of which caused me to take a much closer look at fastspin and its kin. Is there a clear way to make functions and/or objects developed in fastspin usable inside TAQOZ?
Not so much a 'clear way'. TAQOZ is intended to load from ROM, and operate standalone.
The issues with external calls are mainly housekeeping ones : somehow, you need to collect final physical address, and physical address and sizes of any parameters, and manually pass all of that information to TAQOZ
If you make a mistake in any of that, how should TAQOZ report errors ?