I'm compiling a Taqoz v2.8 Glossary to put on the forum soon. I've got through the kernel words and now starting on extend.fth. There are a small number of words (31 so far) whose meaning and grammar aren't clear in the listings and the 'search' feature in the new forum is unimpressive. I'll put up a few 'mystery words' at a time. Why and how do you use:-
HUBEXEC
M!
DWIDTH
BIT!
I'm shoving it all in a calc spreadsheet for now as auto-completion saves loads of time. The final doc would be like the other glossaries.
Cheers, Bob
Peter if you like to have a cortex that makes fun, have a look at the new rp2040 from the raspi foundation, it has real gpio, not this crippled things cortex 3 or 4 offers
@bob_g4bby - HUBEXEC is a forgotten and redundant word that marked the end of TAQOZ kernel hubexec code in memory. The word itself does nothing and it requires a ' HUBEXEC to reveal the last address that the kernel will recognize as implied hubexec and just call it, just like it does cog/lut code, rather than trying to thread it. btw, this doesn't mean you can't have hubexec code elsewhere in memory, it just means that when you do, the code will require a (CODE) instruction to tell TAQOZ to call the code that follows.
' execute assembly code following this ASM instruction as a call and EXIT'
' CODE: <pasm2> end '
007c0 065 fd63f02d _CODE call PTRA
007c4 066 fd9fffe4 AEXIT jmp #EXIT
M! is just a wmlong which works just like a ! does except it skips leading zero bytes. So $12345678 avar ! would store 4 bytes but then writing $C0 avr ! will only write to the first byte leaving $123456C0.
TAQOZ# long avar --- ok
TAQOZ# $12345678 avar M! avar @ .L --- $1234_5678 ok
TAQOZ# $C0 avar M! avar @ .L --- $1234_56C0 ok
DWIDTH was added to the hubexec kernel to upscale 320x240 bmp frames to 640x480. Since then P2ASM was written which means that DWIDTH can now be removed from the kernel and added to the MEDIA module with some changes to take into account the different resolutions.
BIT! will take a flag and either SET or CLR bits in memory. BIT! ( mask addr flag -- )
@Surac - I familiar with M0, M0+, M3, M4, and M7 etc and while the RP2040 does indeed have better GPIO using state machines, it is nothing like a fast P2 drvx instruction which also encodes the "address" in the instruction and sets up the direction register as well. Then too, the P2 has smartpins. Besides, the RP2040 is still only an M0+. albeit a dual core and every peripheral needs to setup a base address for access and it doesn't have byte or halfword I/O access and there is a APB bridge setup penalty too for most of the peripherals. I find though that ARM anything these days is top-heavy with register setups and even when accessing peripherals via a "crippled" instruction set.
The fundamental requirement of an MCU is efficient I/O, and that is something ARM have never really addressed properly (pun intended).
If only it had some Flash on-board, I could use it for USB serial and storage though. This is where we need a P2X4C1M32P or something in a smaller package.
The word PW has inadvertently been defined twice. At line 1358 it sets pulse width for smartpin pwm. At line 1665, it initializes the RTC password feature. Suggest the password version is renamed some time.
I have an si5351 set up and recognised by Taqoz. I think I need to fix an issue with the commented out CREATE DOES> as a first step, lots of crashes when I create new defining words.
I managed to get CREATE DOES> working for Taqoz v2.8, as I needed to create some new data types:-
--- CREATE ... DOES> FOR TAQOZ V2.8 VER 1
{
CREATE / DOES> is the pearl of the Forth programming language, enabling the definition of new 'defining' words,
thus extending the compiler to suit the application - a very powerful feature. Here we test the new words out with two new data types,
WARRAY, a single dimension word array and CARRAY, a single dimension byte array
}
--- create new dev with dummy cfa (save ptr to it)
pub CREATE
[C] GRAB
[C] CREATE: --- Using the next word in the input stream as the name, create a VARIABLE type dictionary entry
[C] GRAB --- make sure CREATE: has run before anything more
HERE 0 REG W! --- save the address of the code after DOES> in the REG scratchpad area
AT ?EXIT 2+ HERE 2- W! --- convert the $006C compiled by CREATE: to a 'no operation' $0064
0 [C] || --- compile 0 to be over written later by DOES>
;
--- set new cfa to point back to DOES: code (skipped by DOES: itself)
pub DOES>
R> --- the first word location in the new word being defined
0 REG W@ --- retrieve the address stored on scratchpad
W! --- set the first word to execute as the address of the code after DOES>
;
--- example definition of a new 'array of words' data type - no bounds checking
pre WARRAY
CREATE
FOR
0 [C] ||
NEXT --- Create cnt bytes set to 0
DOES> ( index -- addr )
2* R> + --- the address of the first byte + index = the entry reqd
;
--- Create a new array MARRAY1 which can hold 10 word size values
10 WARRAY MYARRAY1
' MYARRAY1 $50 DUMP
--- now lets check the array addresses are formed correctly
0 MYARRAY1 .
1 MYARRAY1 .
2 MYARRAY1 .
3 MYARRAY1 .
--- now check write and read data works
: TEST1 ---
10 FOR I I MYARRAY1 W! NEXT ---
10 FOR I MYARRAY1 W@ . SPACE NEXT ---
;
TEST1
--- example definition of a new 'array of bytes' data type - no bounds checking
pre CARRAY
CREATE ( cnt -- )
FOR
0 [C] |
NEXT --- Create cnt bytes set to 0
DOES> ( index -- addr )
R> + --- the address of the first byte + index = the entry reqd
;
--- create a new array MARRAY2 which can hold 20 byte values
20 CARRAY MYARRAY2
--- now lets check the array addresses are formed correctly
0 MYARRAY2 .
1 MYARRAY2 .
2 MYARRAY2 .
3 MYARRAY2 .
--- now check write and read data works
: TEST2 ---
20 FOR I I MYARRAY2 C! NEXT ---
20 FOR I MYARRAY2 C@ . SPACE NEXT ---
;
TEST2
.S
Just to be safe try using AT ?EXIT 2+ instead of $64 in case there is some change to the kernel. On that note too, perhaps instead of compiling a dummy 0 you could always use AT EXIT || instead although it is unlikely that there is a missing DOES>.
OK, this final version of CREATE DOES> is smaller and faster in that each word defined no longer contains a pointless call to NOP. I'll be using this version in my si5351 driver:-
--- CREATE ... DOES> FOR TAQOZ V2.8 VER 2
{
CREATE / DOES> is the pearl of the Forth programming language, enabling the definition of new 'defining' words,
thus extending the compiler to suit the application - a very powerful feature. Here we test the new words out with two new data types,
WARRAY, a single dimension word array and CARRAY, a single dimension byte array
}
--- create new dev (save ptr to it)
pub CREATE ( -- )
[C] GRAB
[C] CREATE: --- Using the next word in the input stream as the name, create a VARIABLE type dictionary entry
[C] GRAB --- make sure CREATE: has run before anything more
HERE 2- 0 REG W! --- save the address of the code after DOES> in the REG scratchpad area
;
--- set new cfa to point back to DOES: code (skipped by DOES: itself)
pub DOES> ( -- )
R> --- the first word location in the new word being defined
0 REG W@ --- retrieve the address stored on scratchpad
W! --- set the first word to execute as the address of the code after DOES>
;
--- example definition of a new 'array of words' data type - no bounds checking
pre WARRAY
CREATE ( cnt -- )
FOR
0 [C] ||
NEXT --- Create cnt bytes set to 0
DOES> ( index -- addr )
2* R> + --- the address of the first word + index = the entry reqd
;
--- Create a new array MARRAY1 which can hold 10 word size values
10 WARRAY MYARRAY1
--- now lets check the array addresses are formed correctly
0 MYARRAY1 .
1 MYARRAY1 .
2 MYARRAY1 .
3 MYARRAY1 .
--- now check write and read data works
: TEST1 ---
10 FOR I I MYARRAY1 W! NEXT ---
10 FOR I MYARRAY1 W@ . SPACE NEXT ---
;
TEST1
--- example definition of a new 'array of bytes' data type - no bounds checking
pre CARRAY
CREATE ( cnt -- )
FOR
0 [C] |
NEXT --- Create cnt bytes set to 0
DOES> ( index -- addr )
R> + --- the address of the first byte + index = the entry reqd
;
--- create a new array MARRAY2 which can hold 20 byte values
20 CARRAY MYARRAY2
--- now lets check the array addresses are formed correctly
0 MYARRAY2 .
1 MYARRAY2 .
2 MYARRAY2 .
3 MYARRAY2 .
--- now check write and read data works
: TEST2 ---
20 FOR I I MYARRAY2 C! NEXT ---
20 FOR I MYARRAY2 C@ . SPACE NEXT ---
;
TEST2
.S
That's it - be aware that if you try to SEE words like MYARRAY1 or MYARRAY2, then the decompiler will run on past the end of these words as they are mostly just data and don't have a normal ending word compiled in. e.g. The structure of MYARRAY1 etc. is:-
A single word that is a Jump to the code that follows DOES> in the WARRAY word - so that all words created with WARRAY do the same thing
The rest of the word is a data structure as produced by the code following CREATE in WARRAY
The two words CREATE and DOES> lift the forth language from 'fancy macro assembler' to that of a full blown 'compiler' - but a compiler that the user has written to suit his application.
Some time ago I presented a simple melody player for Tachyon mainly as a demonstration of using Forth to write your own "language" to express you code. Now here is one for TAQOZ with some extras plus sound effects using nothing more than a smartpin for squarewave output.
This is the Ode to Joy tune which I have recorded and also some sound effects.
: ODE.1 1/4 E E F G | G F E D | C C D E | ;
: ODE.2 1/4 D 1/8 E F 1/4 E C | ;
: ODE.3 3/8 D 1/8 C 1/2 C ;
--- ODE TO JOY - factored common sections
: ODE
4:4
ODE.1 3/8 E 1/8 D 1/2 D 1/8 rest
ODE.1 ODE.3 1/8 rest
1/4 D D E C | ODE.2 | ODE.2 | C E d G bridge u E
E E F G | G F E D | C C D E | ODE.3 ;
and this is the terminal capture as I type all this in:
TAQOZ# ODE --- ok
TAQOZ# BEEP --- ok
TAQOZ# 2 BEEPS --- ok
TAQOZ# SIREN --- ok
TAQOZ# RING --- ok
TAQOZ# 2 RINGS --- ok
TAQOZ# ZAP --- ok
TAQOZ# SAUCER --- ok
TAQOZ# SAUCER ZAP SAUCER 3 ZAPS SIREN --- ok
Note: Why is it that we can attach almost any file except a plain audio file? First, I have to convert it to a proper video file which makes no sense. I notice FB has the same dumb restrictions.
I want to activate the event rising edge on pin 6. I found out that SETEDG is the right word.
But after "1 6 SETEDG" Taqoz seems to hang ?? Now I am lost.
This is the code from taqoz.spin2:
@dnalor, @"Peter Jakacki"
It hangs because there is a bug in SETEDG / POLLEDG, which use setse1 / pollse1, which is already in use in the terminal input I've redefined the two words to use setse2 / pollse2 in the attached file. I tested them from the terminal and they work as advertised.
Transferring binary data between PC and TAQOZ - e.g. testing array words, to set input arrays, perform a dsp function and read back and check the result in a couple of seconds.
Sending a 1024 block of 32 bit longs to the PC via EMIT is fine, it works as it is. Reading the same from the PC via WKEY won't work because the receive interrupt service routine is always looking for ESC ESC ESC ESC, ^T^T^T^T, ^U^U^U^U or ^Z^Z^Z^Z 'key strokes' which trigger debug activities and stop the binary transfer completing.
I don't see how I can use WKEY as part of a dumb serial port - anyone have a solution, please?
My fix for now would be to send to the P2 (say) $FF every fourth character, which would be thrown away as the array is received. That stream of bytes would never trigger the debug action from Taqoz. It's wasteful of bandwidth but still quite quick.
Ideally, could there be a flag that the programmer can set to turn the serial input dumb and this flag would always be reset on booting Taqoz?
I was just composing a longer message about my problems getting into the TAQOZ-prompt (P2 eval board). While diligently describing my problem I realized I hadn't tried out toggling the FLASH-switch on the board. And lo and behold, I'm happily FORTHing. Ok, I'm accessing the SD-card-contents (which was my goal), not really programming much.
@bob_g4bby as I just wrote, I know next to nothing about FORTH / TAQOZ. Just reading your problem though: might base64 solve your issue? I've used that in other contexts (e.g. JSON) to transfer binaries. The overhead is similar to what you are proposing, but the protocol IMHO simpler than your proposal.
Has anybody written a USB driver to emulate the ftdi so that boards can be built without it and yet connect directly to USB with nothing but passives and flash and crystal? That is one advantage, as I see it, in just about any other microcontroller board out there...and yet there is no such board for the P2.
@hinv said:
Has anybody written a USB driver to emulate the ftdi so that boards can be built without it and yet connect directly to USB with nothing but passives and flash and crystal? That is one advantage, as I see it, in just about any other microcontroller board out there...and yet there is no such board for the P2.
Do you mean sw on the P2, or a USB-board ?
FWIR USB P2-code thus far is for host on P2, talking to mouse/kbd etc , but it does need a moderate level of resource.
There is also the 'brick-risk ' issue where if you lose the USB-device code pre-load, you cannot get P2 back on line without a separate loading step.
There are many separate boards with FTDI, SiLabs etc that are very cheap, and newer parts like PL2303G and (even better) XR21B1420 can give higher sustained transfer speeds over FS-USB.
I've measured XR21B1420 at just above 10MBd average, one way, and with a virtual Baud clock of 480Mbd/N (N >= 40)
As far as I can tell from the intended syntax of WRPIN (there's nothing documented other than "as assembler") this should write FF to the 3.3V adc and give me 3.3 on pin 4, just like it does in pasm and spin.
As far as I've been able to tell, this does absolutely nothing, and 4 stays floating.
What am I doing wrong, or is there something amiss with the TAQOZ image on this board and I need to reflash?
@deets said:
I was just composing a longer message about my problems getting into the TAQOZ-prompt (P2 eval board). While diligently describing my problem I realized I hadn't tried out toggling the FLASH-switch on the board. And lo and behold, I'm happily FORTHing. Ok, I'm accessing the SD-card-contents (which was my goal), not really programming much.
Is there a way to boot direct to rom TAQOZ without manual intervention ?
No. The 3 character sequence is required.
You could probably create a simple stub program in Flash to jump to TAQOZ. I am not sure how to program TAQOZ into the Flash although you could program a later version into Flash.
As far as I can tell from the intended syntax of WRPIN (there's nothing documented other than "as assembler") this should write FF to the 3.3V adc and give me 3.3 on pin 4, just like it does in pasm and spin.
As far as I've been able to tell, this does absolutely nothing, and 4 stays floating.
What am I doing wrong, or is there something amiss with the TAQOZ image on this board and I need to reflash?
Hello everybody,
I have the same issue and can't get DAC working.
I'm using P2-EDGE module + P2 Edge Mini Breakout Board and ROM version of TAQOZ V1.1--v33h
I tried the commands above and got the same behavior, no DC on selected PIN.
When Peter Jakacki wrote Taqoz ROM he was using a P2 prototype on an fpga, so not a lot was known about the smartpins as the fpga couldn't emulate those. Thus, there isn't much support for analogue output. Taqoz Reloaded was written on an actual P2, is a superset of Taqoz ROM and supports analogue output:-
4 PIN 1000 mV would output 1V on pin 4
500 mV would output 0.5V
The word mV is defined in extend.fth found in directory 'TAQOZ\Forth' here. Unpicking that definition, it would be possible to work out what needs adding to Taqoz ROM to do the same thing.
Alternatively, installing Taqoz Reloaded is detailed in my glossary. It comes with an assembler, decompiler and other tools that make P2 exploration a fair bit easier.
Comments
I'm compiling a Taqoz v2.8 Glossary to put on the forum soon. I've got through the kernel words and now starting on extend.fth. There are a small number of words (31 so far) whose meaning and grammar aren't clear in the listings and the 'search' feature in the new forum is unimpressive. I'll put up a few 'mystery words' at a time. Why and how do you use:-
HUBEXEC
M!
DWIDTH
BIT!
I'm shoving it all in a calc spreadsheet for now as auto-completion saves loads of time. The final doc would be like the other glossaries.
Cheers, Bob
Thanks Bob. Looking forward to the doc.!
Peter if you like to have a cortex that makes fun, have a look at the new rp2040 from the raspi foundation, it has real gpio, not this crippled things cortex 3 or 4 offers
@bob_g4bby -
HUBEXEC is a forgotten and redundant word that marked the end of TAQOZ kernel hubexec code in memory. The word itself does nothing and it requires a
' HUBEXECto reveal the last address that the kernel will recognize as implied hubexec and just call it, just like it does cog/lut code, rather than trying to thread it. btw, this doesn't mean you can't have hubexec code elsewhere in memory, it just means that when you do, the code will require a (CODE) instruction to tell TAQOZ to call the code that follows.' execute assembly code following this ASM instruction as a call and EXIT' ' CODE: <pasm2> end ' 007c0 065 fd63f02d _CODE call PTRA 007c4 066 fd9fffe4 AEXIT jmp #EXITM! is just a wmlong which works just like a ! does except it skips leading zero bytes. So $12345678 avar ! would store 4 bytes but then writing $C0 avr ! will only write to the first byte leaving $123456C0.
DWIDTH was added to the hubexec kernel to upscale 320x240 bmp frames to 640x480. Since then P2ASM was written which means that DWIDTH can now be removed from the kernel and added to the MEDIA module with some changes to take into account the different resolutions.
BIT! will take a flag and either SET or CLR bits in memory.
BIT! ( mask addr flag -- )@Surac - I familiar with M0, M0+, M3, M4, and M7 etc and while the RP2040 does indeed have better GPIO using state machines, it is nothing like a fast P2
drvxinstruction which also encodes the "address" in the instruction and sets up the direction register as well. Then too, the P2 has smartpins. Besides, the RP2040 is still only an M0+. albeit a dual core and every peripheral needs to setup a base address for access and it doesn't have byte or halfword I/O access and there is a APB bridge setup penalty too for most of the peripherals. I find though that ARM anything these days is top-heavy with register setups and even when accessing peripherals via a "crippled" instruction set.The fundamental requirement of an MCU is efficient I/O, and that is something ARM have never really addressed properly (pun intended).
If only it had some Flash on-board, I could use it for USB serial and storage though. This is where we need a P2X4C1M32P or something in a smaller package.
Deleted
Peter, in EXTEND.FTH:-
The word PW has inadvertently been defined twice. At line 1358 it sets pulse width for smartpin pwm. At line 1665, it initializes the RTC password feature. Suggest the password version is renamed some time.
I have an si5351 set up and recognised by Taqoz. I think I need to fix an issue with the commented out CREATE DOES> as a first step, lots of crashes when I create new defining words.
I managed to get CREATE DOES> working for Taqoz v2.8, as I needed to create some new data types:-
--- CREATE ... DOES> FOR TAQOZ V2.8 VER 1 { CREATE / DOES> is the pearl of the Forth programming language, enabling the definition of new 'defining' words, thus extending the compiler to suit the application - a very powerful feature. Here we test the new words out with two new data types, WARRAY, a single dimension word array and CARRAY, a single dimension byte array } --- create new dev with dummy cfa (save ptr to it) pub CREATE [C] GRAB [C] CREATE: --- Using the next word in the input stream as the name, create a VARIABLE type dictionary entry [C] GRAB --- make sure CREATE: has run before anything more HERE 0 REG W! --- save the address of the code after DOES> in the REG scratchpad area AT ?EXIT 2+ HERE 2- W! --- convert the $006C compiled by CREATE: to a 'no operation' $0064 0 [C] || --- compile 0 to be over written later by DOES> ; --- set new cfa to point back to DOES: code (skipped by DOES: itself) pub DOES> R> --- the first word location in the new word being defined 0 REG W@ --- retrieve the address stored on scratchpad W! --- set the first word to execute as the address of the code after DOES> ; --- example definition of a new 'array of words' data type - no bounds checking pre WARRAY CREATE FOR 0 [C] || NEXT --- Create cnt bytes set to 0 DOES> ( index -- addr ) 2* R> + --- the address of the first byte + index = the entry reqd ; --- Create a new array MARRAY1 which can hold 10 word size values 10 WARRAY MYARRAY1 ' MYARRAY1 $50 DUMP --- now lets check the array addresses are formed correctly 0 MYARRAY1 . 1 MYARRAY1 . 2 MYARRAY1 . 3 MYARRAY1 . --- now check write and read data works : TEST1 --- 10 FOR I I MYARRAY1 W! NEXT --- 10 FOR I MYARRAY1 W@ . SPACE NEXT --- ; TEST1 --- example definition of a new 'array of bytes' data type - no bounds checking pre CARRAY CREATE ( cnt -- ) FOR 0 [C] | NEXT --- Create cnt bytes set to 0 DOES> ( index -- addr ) R> + --- the address of the first byte + index = the entry reqd ; --- create a new array MARRAY2 which can hold 20 byte values 20 CARRAY MYARRAY2 --- now lets check the array addresses are formed correctly 0 MYARRAY2 . 1 MYARRAY2 . 2 MYARRAY2 . 3 MYARRAY2 . --- now check write and read data works : TEST2 --- 20 FOR I I MYARRAY2 C! NEXT --- 20 FOR I MYARRAY2 C@ . SPACE NEXT --- ; TEST2 .SCheers, Bob
Just to be safe try using
AT ?EXIT 2+instead of $64 in case there is some change to the kernel. On that note too, perhaps instead of compiling a dummy 0 you could always useAT EXIT ||instead although it is unlikely that there is a missing DOES>.I will try this all out later on.
Other than that, that's just super Bob!
OK, this final version of CREATE DOES> is smaller and faster in that each word defined no longer contains a pointless call to NOP. I'll be using this version in my si5351 driver:-
--- CREATE ... DOES> FOR TAQOZ V2.8 VER 2 { CREATE / DOES> is the pearl of the Forth programming language, enabling the definition of new 'defining' words, thus extending the compiler to suit the application - a very powerful feature. Here we test the new words out with two new data types, WARRAY, a single dimension word array and CARRAY, a single dimension byte array } --- create new dev (save ptr to it) pub CREATE ( -- ) [C] GRAB [C] CREATE: --- Using the next word in the input stream as the name, create a VARIABLE type dictionary entry [C] GRAB --- make sure CREATE: has run before anything more HERE 2- 0 REG W! --- save the address of the code after DOES> in the REG scratchpad area ; --- set new cfa to point back to DOES: code (skipped by DOES: itself) pub DOES> ( -- ) R> --- the first word location in the new word being defined 0 REG W@ --- retrieve the address stored on scratchpad W! --- set the first word to execute as the address of the code after DOES> ; --- example definition of a new 'array of words' data type - no bounds checking pre WARRAY CREATE ( cnt -- ) FOR 0 [C] || NEXT --- Create cnt bytes set to 0 DOES> ( index -- addr ) 2* R> + --- the address of the first word + index = the entry reqd ; --- Create a new array MARRAY1 which can hold 10 word size values 10 WARRAY MYARRAY1 --- now lets check the array addresses are formed correctly 0 MYARRAY1 . 1 MYARRAY1 . 2 MYARRAY1 . 3 MYARRAY1 . --- now check write and read data works : TEST1 --- 10 FOR I I MYARRAY1 W! NEXT --- 10 FOR I MYARRAY1 W@ . SPACE NEXT --- ; TEST1 --- example definition of a new 'array of bytes' data type - no bounds checking pre CARRAY CREATE ( cnt -- ) FOR 0 [C] | NEXT --- Create cnt bytes set to 0 DOES> ( index -- addr ) R> + --- the address of the first byte + index = the entry reqd ; --- create a new array MARRAY2 which can hold 20 byte values 20 CARRAY MYARRAY2 --- now lets check the array addresses are formed correctly 0 MYARRAY2 . 1 MYARRAY2 . 2 MYARRAY2 . 3 MYARRAY2 . --- now check write and read data works : TEST2 --- 20 FOR I I MYARRAY2 C! NEXT --- 20 FOR I MYARRAY2 C@ . SPACE NEXT --- ; TEST2 .SThat's it - be aware that if you try to SEE words like MYARRAY1 or MYARRAY2, then the decompiler will run on past the end of these words as they are mostly just data and don't have a normal ending word compiled in. e.g. The structure of MYARRAY1 etc. is:-
The two words CREATE and DOES> lift the forth language from 'fancy macro assembler' to that of a full blown 'compiler' - but a compiler that the user has written to suit his application.
Peter,
DECOMP decompiles a word into source code, but It doesn't insert a [C] before any preemptive words compiled - just a minor issue.
Some time ago I presented a simple melody player for Tachyon mainly as a demonstration of using Forth to write your own "language" to express you code. Now here is one for TAQOZ with some extras plus sound effects using nothing more than a smartpin for squarewave output.
This is the Ode to Joy tune which I have recorded and also some sound effects.
: ODE.1 1/4 E E F G | G F E D | C C D E | ; : ODE.2 1/4 D 1/8 E F 1/4 E C | ; : ODE.3 3/8 D 1/8 C 1/2 C ; --- ODE TO JOY - factored common sections : ODE 4:4 ODE.1 3/8 E 1/8 D 1/2 D 1/8 rest ODE.1 ODE.3 1/8 rest 1/4 D D E C | ODE.2 | ODE.2 | C E d G bridge u E E E F G | G F E D | C C D E | ODE.3 ;and this is the terminal capture as I type all this in:
Note: Why is it that we can attach almost any file except a plain audio file? First, I have to convert it to a proper video file which makes no sense. I notice FB has the same dumb restrictions.
Deleted
I want to activate the event rising edge on pin 6. I found out that SETEDG is the right word.
But after "1 6 SETEDG" Taqoz seems to hang ?? Now I am lost.
This is the code from taqoz.spin2:
There is no waitse1. Why should it hang?
@dnalor, @"Peter Jakacki"
It hangs because there is a bug in SETEDG / POLLEDG, which use setse1 / pollse1, which is already in use in the terminal input I've redefined the two words to use setse2 / pollse2 in the attached file. I tested them from the terminal and they work as advertised.
Thanks.
True, a search in the taqoz.spin2 reveals the use of setse1 in InitSerial.
Transferring binary data between PC and TAQOZ - e.g. testing array words, to set input arrays, perform a dsp function and read back and check the result in a couple of seconds.
Sending a 1024 block of 32 bit longs to the PC via EMIT is fine, it works as it is. Reading the same from the PC via WKEY won't work because the receive interrupt service routine is always looking for ESC ESC ESC ESC, ^T^T^T^T, ^U^U^U^U or ^Z^Z^Z^Z 'key strokes' which trigger debug activities and stop the binary transfer completing.
I don't see how I can use WKEY as part of a dumb serial port - anyone have a solution, please?
My fix for now would be to send to the P2 (say) $FF every fourth character, which would be thrown away as the array is received. That stream of bytes would never trigger the debug action from Taqoz. It's wasteful of bandwidth but still quite quick.
Ideally, could there be a flag that the programmer can set to turn the serial input dumb and this flag would always be reset on booting Taqoz?
I was just composing a longer message about my problems getting into the TAQOZ-prompt (P2 eval board). While diligently describing my problem I realized I hadn't tried out toggling the FLASH-switch on the board. And lo and behold, I'm happily FORTHing. Ok, I'm accessing the SD-card-contents (which was my goal), not really programming much.
However I wonder if this bit of information is worth mentioning in the preamble of https://docs.google.com/document/d/e/2PACX-1vQKKl_A9gQ8VooCfrLOqw6a_rp9ddyAqiFeo1RopL2AtnHTaWIfvojYq-yfNlqoPD81a2EU1EJsQpRG/pub ? Those who are long time contributors might be aware of these things, but there is still a lot that newbees might find confusing and don't understand. I'm also happy for any pointers that explain that dip-switch set a bit more in depth to me.
@bob_g4bby as I just wrote, I know next to nothing about FORTH / TAQOZ. Just reading your problem though: might base64 solve your issue? I've used that in other contexts (e.g. JSON) to transfer binaries. The overhead is similar to what you are proposing, but the protocol IMHO simpler than your proposal.
@deets
Base64 sounds worth a try and more simple, thank you.
Has anybody written a USB driver to emulate the ftdi so that boards can be built without it and yet connect directly to USB with nothing but passives and flash and crystal? That is one advantage, as I see it, in just about any other microcontroller board out there...and yet there is no such board for the P2.
Do you mean sw on the P2, or a USB-board ?
FWIR USB P2-code thus far is for host on P2, talking to mouse/kbd etc , but it does need a moderate level of resource.
There is also the 'brick-risk ' issue where if you lose the USB-device code pre-load, you cannot get P2 back on line without a separate loading step.
There are many separate boards with FTDI, SiLabs etc that are very cheap, and newer parts like PL2303G and (even better) XR21B1420 can give higher sustained transfer speeds over FS-USB.
I've measured XR21B1420 at just above 10MBd average, one way, and with a virtual Baud clock of 480Mbd/N (N >= 40)
I mean running a usb serial device emulator to do away with the need to have any of those chips.
I’m not aware of such a thing. I looked a while ago. So far only USB Host mode is supported.
@garryj wrote the USB driver available. He said his next step would be to support USB HUB's.
He said that USB serial may be possible later.
Enjoy!
Mike
Possibly silly question, but in ROM TAQOZ I'm having issues with WRPIN
I'm trying to do a very simple DAC test.
4 PIN PIN@ .
%00000000000101101111111100000000 WRPIN
As far as I can tell from the intended syntax of WRPIN (there's nothing documented other than "as assembler") this should write FF to the 3.3V adc and give me 3.3 on pin 4, just like it does in pasm and spin.
As far as I've been able to tell, this does absolutely nothing, and 4 stays floating.
What am I doing wrong, or is there something amiss with the TAQOZ image on this board and I need to reflash?
I have a Kiss P2 with flash but without SD slot and am booting the 60s serial window, then typing > esc for TAQOZ#
Is there a forth method to serially load _P2_BOOT.BIX to flash ?
I'm using minicom which successfully interprets from a .FTH file
Is there a way to boot direct to rom TAQOZ without manual intervention ?
No. The 3 character sequence is required.
You could probably create a simple stub program in Flash to jump to TAQOZ. I am not sure how to program TAQOZ into the Flash although you could program a later version into Flash.
Hello everybody,
I have the same issue and can't get DAC working.
I'm using P2-EDGE module + P2 Edge Mini Breakout Board and ROM version of TAQOZ V1.1--v33h
I tried the commands above and got the same behavior, no DC on selected PIN.
What are we doing wrong?
When Peter Jakacki wrote Taqoz ROM he was using a P2 prototype on an fpga, so not a lot was known about the smartpins as the fpga couldn't emulate those. Thus, there isn't much support for analogue output. Taqoz Reloaded was written on an actual P2, is a superset of Taqoz ROM and supports analogue output:-
4 PIN 1000 mV would output 1V on pin 4
500 mV would output 0.5V
The word mV is defined in extend.fth found in directory 'TAQOZ\Forth' here. Unpicking that definition, it would be possible to work out what needs adding to Taqoz ROM to do the same thing.
Alternatively, installing Taqoz Reloaded is detailed in my glossary. It comes with an assembler, decompiler and other tools that make P2 exploration a fair bit easier.
Regards, Bob
Thank you very much Bob for your quick and detailed answer.
I will follow your instructions and try to run Taqoz Reloaded.