@MJB - not sure why you think Forth is mostly Spin. Sure it used VGA_512x384_Bitmap.spin at the time but that is the PASM with just a few lines of start and stop still in Spin during reset.
Plot only sets a pixel and the current color is dictated by PEN and PAPER but there have been so many different types of display I have interfaced. If you want plot to set 2 bits then that should be very easy to do but I would do this all in high level first to get it functional.
pub and pri were added for a couple of reasons, first off they were immediately identifiable as a definition to those familiar with Spin etc and while pri works the same as pub it also sets a private bit in the header so that a RECLAIM can go and strip that header if it is private. Stripping headers is done both for memory and also for security.
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S. The macro-assembler is being written in Forth itself so that a final system with an M4/M7 can be self-hosting. The STM32F476 is one I'm playing with also. If P2 comes out in a couple of years then I can use that as well but certainly I will have quite a range to choose from and not be stuck.
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S. The macro-assembler is being written in Forth itself so that a final system with an M4/M7 can be self-hosting. The STM32F476 is one I'm playing with also.
Sounds interesting. There are also Nuvoton parts, with Wide Vcc, now available from their on-line store, plus eval boards.
@MJB - not sure why you think Forth is mostly Spin. Sure it used VGA_512x384_Bitmap.spin at the time but that is the PASM with just a few lines of start and stop still in Spin during reset.
....
this: VGADEMO.FTH does not look like all Forth code to me ;-) ...
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S. The macro-assembler is being written in Forth itself so that a final system with an M4/M7 can be self-hosting. The STM32F476 is one I'm playing with also. If P2 comes out in a couple of years then I can use that as well but certainly I will have quite a range to choose from and not be stuck.
I like TACHYON very much, so if you ever leave the forums leave some crumbs so I can follow ...
And if you now make the TACHYON for ARM let me know where I can find and follow it.
I recently found a guy who makes eFORTH for the tiny STM8 and since I happen to have this little W1209 I thought I have a look.
Tachyon running there would even be better :-)
But STM32 and STM8 might not be that compatible.
@MJB - not sure why you think Forth is mostly Spin. Sure it used VGA_512x384_Bitmap.spin at the time but that is the PASM with just a few lines of start and stop still in Spin during reset.
....
this: VGADEMO.FTH does not look like all Forth code to me ;-) ...
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S. The macro-assembler is being written in Forth itself so that a final system with an M4/M7 can be self-hosting. The STM32F476 is one I'm playing with also. If P2 comes out in a couple of years then I can use that as well but certainly I will have quite a range to choose from and not be stuck.
I like TACHYON very much, so if you ever leave the forums leave some crumbs so I can follow ...
And if you now make the TACHYON for ARM let me know where I can find and follow it.
I recently found a guy who makes eFORTH for the tiny STM8 and since I happen to have this little W1209 I thought I have a look.
Tachyon running there would even be better :-)
But STM32 and STM8 might not be that compatible.
Oh, that VGA DEMO version was one I started working on to look the same as the original Parallax VGA and TV demo that had all the buttons and symbols on the screen. The original Spin code was left in a comment block for reference but I never did anything more with it, it needs to be removed.
The version I was talking about is my original VGA DEMO from August 2012 that I used to test out the nascent Tachyon and the 512x384 Bitmap memory usage was possible because I still had a very basic kernel. Maybe I can do this again one day on P2 or on an ARM in the meantime.
I will continue to use the P1 of course and maybe just maybe there might be a P2 in 2018/19 so I won't disappear. Running Tachyon on ARM will alleviate any commercial pressures I face and the Cortex M7's DSP will be very useful for some projects. With my Pingnet I can easily team up several small ARM chips on a single I/O but there are some things that the P1 does well too, so they may coexist, Propeller and ARM, with both running Tachyon and connected by Pingnet.
BTW, I have STM8 kits too but unless I'm doing something super simple there's not much reason to use it, the ARM chips are so cheap and better able to host Forth. eforth has never been something that I would design a product with, ok to play with, and very simple to implement, but slow and simple. Just keep an eye on the Tachyon folder for new additions besides V3 and V4, so you may have various cores and chips added and I may even update Tachyon for the latest frozen P2 as my part to help test the chip since TF2 does a bit more than just blink LEDS This will end up as a TF2 subfolder along with the main subfolders.
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S.
@MJB - not sure why you think Forth is mostly Spin. Sure it used VGA_512x384_Bitmap.spin at the time but that is the PASM with just a few lines of start and stop still in Spin during reset.
....
this: VGADEMO.FTH does not look like all Forth code to me ;-) ...
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S. The macro-assembler is being written in Forth itself so that a final system with an M4/M7 can be self-hosting. The STM32F476 is one I'm playing with also. If P2 comes out in a couple of years then I can use that as well but certainly I will have quite a range to choose from and not be stuck.
I like TACHYON very much, so if you ever leave the forums leave some crumbs so I can follow ...
And if you now make the TACHYON for ARM let me know where I can find and follow it.
I recently found a guy who makes eFORTH for the tiny STM8 and since I happen to have this little W1209 I thought I have a look.
Tachyon running there would even be better :-)
But STM32 and STM8 might not be that compatible.
Oh, that VGA DEMO version was one I started working on to look the same as the original Parallax VGA and TV demo that had all the buttons and symbols on the screen. The original Spin code was left in a comment block for reference but I never did anything more with it, it needs to be removed.
The version I was talking about is my original VGA DEMO from August 2012 that I used to test out the nascent Tachyon and the 512x384 Bitmap memory usage was possible because I still had a very basic kernel. Maybe I can do this again one day on P2 or on an ARM in the meantime.
...
I found it in the V4 folder, so thought it is s.th. relevant ... shouldn't be there then ??
Just keep an eye on the Tachyon folder for new additions besides V3 and V4
I sure will
maybe we'll have a 'TACHYON for other HW' thread then soon ?
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S.
Yes, it is cheaper for me to buy from E14 for $8.90 AUD vs $9.95 USD from Mouser. I have other XMC boards as well to play with of course. In fact I have boxes full of ARM dev boards in addition to my FPGA boards and systems, and many other CPUs etc. I think the XMC1100 is quite useful since it has 16k RAM and I have bare chips in 16-pin TSSOP I can prototype with. The bootloader allows simple serial bootload.
... Just keep an eye on the Tachyon folder for new additions besides V3 and V4, so you may have various cores and chips added and I may even update Tachyon for the latest frozen P2 as my part to help test the chip since TF2 does a bit more than just blink LEDS This will end up as a TF2 subfolder along with the main subfolders.
Great, Cool
I'd be keen to see some benchmark 'before' and 'after' numbers for TF2 speed with the new Bytecode/wordcode opcodes Chip has just added.
Peter - do you have an analogous thread in some other forum for ARM tachyon development? It would be interesting to see it grow.
I mentioned in the P2 forum that I may just build up my P2 development system as a full stand-alone system with bit-bashed VGA graphics to host my macroassemblers for the P2 and ARM written in Tachyon Forth. That way it is easy to expand the macroassembler and I get to test out the P2 as well. So perhaps initially under a new thread in the P2 forum I can talk about the stand-alone system and then maybe other thread for the macroassemblers with targets for P2, P1, and ARM (etc).
I have a BemicroCVA9 board mounted onto a motherboard that has dual SD, Ethernet, various communications ports, VGA, USB, RTC, and two Puppy module pods, so there is plenty of room of this board for a standalone system. The VGA will just be bit-bashed graphics so any P2 FPGA will be able to generate 4 or 8-bit color.
--- Output a byte to the LCD as a character
pri LCDDAT ( ch -- )
*rs HIGH
pri WriteLCD ( data -- )
--- write data (set after clear)
*lcd OUTCLR 2* 2* OUTSET
--- min 450ns pulse chip enable
H H L
;
I'm having problems to follow that piece of code:
push pin# for data/control register onto stack
set pin high
push mask for data pins onto stack
clear outputs designated by mask
shift value on stack (character to output) left by two to be in line with data pins
OUTSET: set pins corresponding to bits set:
here my question: are only 1-bits positions touched, 0-bits left unchanged?
if this is the case, it is not possible to set/reset outputs in one command?
---OUT does that, found it!
H: set a output pin high, but how is the output addressed?
The same question for L
There is no masked write instruction, so the best way to write a bit field to a long is to clear the bits using the mask ( $3FC OUTCLR ) and then set the bits after shifting the data into the correct bit position from bit2 ( 2* 2* OUTSET). This is what it does:
So the other bit positions are not affected, only the bits we need to write because we use ANDN to clear the bit mask, and OR to set the bits.
H and L are fast pin operations that use PIN to select the pin. The code ( *lcdce PIN L ) at the start of BitBlt sets that pin and makes it a low output. Since no stack items are pushed or popped this instruction executes in 8 instruction cycles.
Peter-
Just starting with Tachyon (Tachyon triggered my interest in Prop), so based on your recent comments, I downloaded V4.1 I don't know what to do with the binary, so I loaded Propeller IDE. When I build I get this:
Tachyon V4.1.spin(6079:23) : error : Expected a variable
Line:
coginit(3,@loader, @loadpars)
Offending Item: loadpars
If I comment out the line, it builds, loads and runs. Is the loader init needed?
I figured out how to load a binary with PropellerIDE. Working through the V3 Introduction to Tachyon, I get this:
( 0001 $18C0 ok ) : STAR "*" ??? in STAR at "*"
I figured out this works:
( 0001 $18C0 ok ) : STAR 42 EMIT ;
@reybob, Welcome to the Parallax forums, and especially the Tachyon threads!
Admittedly I forgot about the loader cog and loadpars does not need the @ operator since loadpars is a relative address to"registers". BST was compiling this anyway but I've patched it so it should compile properly now.
V4 is a bit different from V3, mainly under the hood with using wordcode instead of bytecode but also some other changes I thought I'd make with a new version. One of these was specifying character literals with 'A' rather then "A" as sometimes it was hard to distinguish a " A" which is a string vs "A" which is just the literal. There are a lot of symbols used in Forth that while useful for typing interactively are also hard to see in source code. Take the print number word . for instance, it's just a dot that depending upon the font etc may not be readily discernible so I prefer to use aliases for these such as PRINT and also use pub and pri as well to start a definiton. But then again sometimes I go the other way with == instead of CONSTANT since I find that big words like these can drown out the name, i.e:
4 CONSTANT W
vs
4 == W
The constant name stands out in the second example, much easier to read and works the same.
The other thing you will find with Tachyon is that the interactive console compiles word by word as it is encountered. This means you can't backspace to the previous word but you can have a really long line as there is no need for a terminal input buffer. Also it means too that you can use "compile only" words such as DO LOOP IF THEN BEGIN AGAIN etc interactively in exactly the same way as you would inside a definition. When you hit the enter key the line has already been interpreted and compiled so there is no delay since it executes immediately. Also there are no special (.") words etc so I could just type:
10 FOR CR PRINT" HELLO WORLD" NEXT
and it will do exactly the same as it would inside a definition. Notice the clearly readable PRINT" rather than the tiny ." so you know it definitely is a PRINT and not an inline string perhaps.
V4 during entry also constructs numbers digit by digit so it is much faster than V3 and much faster than other Forths which search the dictionaries before trying to convert it to a number. The number convention is to use decimal by default and prefix all $hex and %binary numbers with an optional prefix for #decimal numbers. Be careful with V4, I haven't included basic backspace editing for numbers or definitions and strings yet
Load SEE.FTH if you want to see how the words are constructed.
( 0082 $301C ok ) : STAR '*' EMIT ;
( 0083 $3020 ok ) SEE STAR
301C $002A (42)
301E GOTO EMIT
( 0084 $3020 ok ) : STARS FOR STAR NEXT ;
( 0085 $3028 ok ) SEE STARS
3020 FOR
3022 STAR
3024 NEXT
3026 EXIT
There's a few optimizations with wordcode that allow 15-bit literals to be encoded into a single wordcode and an EXIT to be implied by simply jumping instead of calling as in the case of "GOTO EMIT". In the case of STAR wordcode has no memory savings over bytecode but it only required two hub accesses vs four and so it is faster even in that regard alone. FOR and DO are actual instructions rather than those immediate operations that other Forths have that compile a runtime version and compute a branch, but this is all done in Tachyon using fast branch stacks in addition to a loop parameter stack, safely leaving the return stack for return addresses and the data stack for what it does best. The loop indices are also accessible from a called function. btw, the top four items of the datastack are fixed registers so that the Propeller which does not have indexed addressing can directly operate on it efficiently. Also you may not find any PICK and ROLL so as to encourage clean and concise and factored stack use but there are 3RD and 4TH operators to make a copy of those items. That's some Tachyon tips in a nutshell but please feel free to ask questions.
Looks as if Tachyon is gaining some momentum. Starting with Tachyon in a jumpstart way is not possible if you expect to jump into a swimming lane and start to swim like Michael Phelps. It reminds more in being a reality show moderator and start precidency. Unprecedented, because impossible.
Tachyons are solutions to an equation, that result in negation of laws of physics, but those can not be negotiated. But Tachyon allows you to enter the RPN world, where many tasks can be solved more easily.
So I jumped into Tachyon and I'm swimming like a lump of lead.
I have to explain: In Tachyon every word has just one meaning but by executing words in a sequence you can invert or xor the meaning and couple back so within a short moment you don't know what happens to you.
I look to a dictionary german english to find the right words and realize: lump - person der (auch: das) Trampel Pl.: die Trampel - Mensch [ugs.]
That was not intended. So a lump of lead doesn't mean the situation, where a lump leads a country, is means a piece of metal, not peace created by metal. So as I do not swim, I dive into Tachyon and hope to find and run out at the shore before I run out of breath.
If someone is interested in Peters IoT5500, what comes out to be a good starting point, I still have some of those board here in good old Germany and we also prepared some Quickstart compatible products to drive real hardware. Also, I started my learning curve with the LameStation and proplem and me we are currently creating a driver for the lcd display, with support from Peter.
As Peter has already demonstrated, even P2 can run Tachyon and this path should lead to a selfcontained system before any wall is erected!
By the way, I just have an idea, I get from my layout efforts: If I have to connect two high pin density objects that are located east and west of the PCB, I collect all the signal and make a high speed serial transmission line.
This line I place on the south side of the PCB. Now the middle area is free to place any standard component there.
So what it all highways from east coast to west are bundled in the south, very close to the borderline, and have them of hyper loop type. Then so much traffic will be there, that no living object can pass from north to south and vice versa. This is my contribution to the call for buildingtheborderwall.com
...
So what it all highways from east coast to west are bundled in the south, very close to the borderline, and have them of hyper loop type. Then so much traffic will be there, that no living object can pass from north to south and vice versa. This is my contribution to the call for buildingtheborderwall.com
that's what bridges over multi lane highways are for ;-)
- to open the border so neighbours can see each tother ...
@ErNa, I think you understand Tachyon better than I understand you. Do you understand?
One of the ways of looking at Forth in general is to think of it as the assembler code of a virtual stack machine. Now in assembler we are used to those tiny operations that don't really do much, but by building and calling subroutines we can even write a compiler for P1. In Forth the calls are implicit and practically every Forth word gets compiled in a similar fashion to assembler where every instruction assembles to a machine code. This is very different to HLLs in general of course.
Do you like assembler? See that post about STARS a few posts back? That is "assembler" that can modify its own assembler and be molded to the application. When I write Forth I don't have to guess what and where that generated code might look like, whether there is a function for it in the library, whether after learning about the functions whether that function can actually do what I want, or whether I have to do what it wants, or whether that library has a bug, or whether it interpreted what i said a different way from what I meant because of incorrect syntax. No, what you see is what you get. Forth does just as you tell it, it doesn't second guess that you "need" to convert types in a warm and fuzzy way, and the only errors it really throws up are typos.
If I want to design and build a PCB I don't work from pre-assembled kits trying to fit one to another and then adding bits to make them work together, I just use the components and put them exactly where I want them the way I want to use them. That way I get exactly what I want and that is also the way I work with software much to the chagrin of many for some reason. Is that because it works so well?
.
.
.
The STM32F476 is one I'm playing with also.
.
.
.
Wow, to see Tachyon unleash the power of this little beast at 8.06/ea qty 1 to the average guy/gal would be fantastic.
Still really enjoy Tachyon on the Prop but I will be checking the folders for additional chips, yes I'm still working with the ESP8266 too, neat little SOC.
@Peter,
I started to build an iot5500 with V4 and there seems COMPACT is not yet existing so no wonder I got in the last step (EASYNET.FTH):
1855 $3D38 ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
( 1032 $4BF8 ok ) Dictionary full! *error*
( 0001 $4BF8 ok ) -----------------------------------------------------------
Is this a known open issue?
Only came across it myself yesterday as up until then it was all fitting in. So now I need to look at adding the fixed length EEPROM dictionary feature I intended to add at the start of embarking on V4. Back in V3 the COMPACT word would move the whole hub dictionary into hash indexed blocks which are read in as a block and the name would be found there but there was a lot of wasted space and complicated. So V4 simply creates a 16 byte entry for the name leaving up to 12 characters for the name which is more than enough in fact but if someone wants to use a long name then it simply stays in hub memory.
This means that V4 is designed to work with a hybrid dictionary, searching hub first, and then EEPROM and since each name in EEPROM is on a 16 byte boundary as well as being in alphabetical order it makes it a bit easier and faster to search. In the meantime I may just try to free up some memory so you can still load EASYNET.
.
.
.
The STM32F476 is one I'm playing with also.
.
.
.
Wow, to see Tachyon unleash the power of this little beast at 8.06/ea qty 1 to the average guy/gal would be fantastic.
Still really enjoy Tachyon on the Prop but I will be checking the folders for additional chips, yes I'm still working with the ESP8266 too, neat little SOC.
That's one of the M7s but one that I happen to have a Nucleo-144 board for so I'm quite interested in running an M7 at 216MHz with Floating Point and DSP as well as 1MB Flash and 320kB RAM. I've compared P1 running Tachyon at 20MHz CPU clock with M3s running Mecrisp at 72Mhz and while Tachyon runs slower, it isn't by much. P2 is faster. Remember too that Mecrisp compiles inline assembly code rather than interpreting threaded code. The branch stack in Tachyon certainly speeds things up during looping for starters but there are other design features that max the P1.
That's one of the M7s but one that I happen to have a Nucleo-144 board for so I'm quite interested in running an M7 at 216MHz with Floating Point and DSP as well as 1MB Flash and 320kB RAM.
"To recap, here’s the full feature list for Zero W:
1GHz, single-core CPU
512MB RAM
Mini-HDMI port
Micro-USB On-The-Go port
Micro-USB power
HAT-compatible 40-pin header
Composite video and reset headers
CSI camera connector
802.11n wireless LAN
Bluetooth 4.0
"
Native Tachyon on that would be interesting
However, P2 is probably a better target, near term, to confirm the FPGA image.
: means start definition of a word !LCD
Is there a special meaning of the ! in the word name !LCD or is it just for fun?
What is the meaning of COGREG, what the difference to COGREGS
Do I get this right: 4 COGREG brings the address of the 4th cogregister to the stack, but what does COGREG! do?
: means start definition of a word !LCD
Is there a special meaning of the ! in the word name !LCD or is it just for fun?
What is the meaning of COGREG, what the difference to COGREGS
Do I get this right: 4 COGREG brings the address of the 4th cogregister to the stack, but what does COGREG! do?
I know, I do all this to become productive ;-)
There are certain conventions I use and while the ! suffix indicates a store operation, I use ! as a prefix to indicate a default initialization value, pronounced INIT SP when prefixed.
So LCD itself may refer to selecting the LCD as an output device so that LCD PRINT" HELLO WORLD" will print to the LCD the same as it would to the console.
COGREGs are fixed REGister locations in COG memory that are used by special functions such as RUNMODs and by some other cog code such as (WAITPEQ) etc where they leave a result in a COGREG. So COGREG itself simply returns the address in the cog of that register. COGREG! will store to the register etc.
In regards to PLOT it needs to know the start address of the pixel buffer and the left shift required to address each line of pixels. Binary shifts are much faster than trying to multiply the Y.
Pixel = Pixel start address + X + Y<<shifts
Have a look at PING which uses these registers. Remember that trying to push and pop registers from the data stack slows things down, so having fixed register that are only accessed as needed is a way to improve efficiency and performance....and productivity.
pub PING ( trig echo -- us )
MASK 3 COGREG! --- setup WAITPxx mask
DUP HIGH >R R> LOW --- 10us trigger (dummy cycles)
(WAITPEQ) (WAITPNE) --- detect high period
0 COGREG@ 1 COGREG@ - --- calculate high period
CLKFREQ #1,000,000 / / --- convert cycles to us
;
Comments
so ... did some source code reading ... in NEW V4 folder on dropbox
VGA uses Chip's 2006 tiled color bitmap driver
On top Peter has his 32*15 character driver.
I did not see [PLOT] being used.
Like old DOS character graphics are supported + Parallax Fonts
VGADEMO.fth puzzled me a while until I realized it is mostly SPIN code.
Peter's use of pub / pri in Tachyon irritated me a while ;-)
I am still not very clear on actual use and implementation.
Plot only sets a pixel and the current color is dictated by PEN and PAPER but there have been so many different types of display I have interfaced. If you want plot to set 2 bits then that should be very easy to do but I would do this all in high level first to get it functional.
pub and pri were added for a couple of reasons, first off they were immediately identifiable as a definition to those familiar with Spin etc and while pri works the same as pub it also sets a private bit in the header so that a RECLAIM can go and strip that header if it is private. Stripping headers is done both for memory and also for security.
I've been busy playing with my M4 and M7 ARM chips but I am implementing Tachyon on an M0 at present. The XMC1100 runs on 5V just as well as 3.3, has 16k RAM, 64k Flash, on chip 64MHz trimmed clock, in a tiny 16-pin TSSOP that I am using as those itty-bitty chips, except with a full Forth O/S. The macro-assembler is being written in Forth itself so that a final system with an M4/M7 can be self-hosting. The STM32F476 is one I'm playing with also. If P2 comes out in a couple of years then I can use that as well but certainly I will have quite a range to choose from and not be stuck.
Did you look at the new nibble/byte/word P2 opcodes for use in the 'byte code' engine of forth ?
How much improvement do they bring to Tachyon V4 ?
VGADEMO.FTH does not look like all Forth code to me ;-) ...
I like TACHYON very much, so if you ever leave the forums leave some crumbs so I can follow ...
And if you now make the TACHYON for ARM let me know where I can find and follow it.
I recently found a guy who makes eFORTH for the tiny STM8 and since I happen to have this little W1209 I thought I have a look.
Tachyon running there would even be better :-)
But STM32 and STM8 might not be that compatible.
Oh, that VGA DEMO version was one I started working on to look the same as the original Parallax VGA and TV demo that had all the buttons and symbols on the screen. The original Spin code was left in a comment block for reference but I never did anything more with it, it needs to be removed.
The version I was talking about is my original VGA DEMO from August 2012 that I used to test out the nascent Tachyon and the 512x384 Bitmap memory usage was possible because I still had a very basic kernel. Maybe I can do this again one day on P2 or on an ARM in the meantime.
I will continue to use the P1 of course and maybe just maybe there might be a P2 in 2018/19 so I won't disappear. Running Tachyon on ARM will alleviate any commercial pressures I face and the Cortex M7's DSP will be very useful for some projects. With my Pingnet I can easily team up several small ARM chips on a single I/O but there are some things that the P1 does well too, so they may coexist, Propeller and ARM, with both running Tachyon and connected by Pingnet.
BTW, I have STM8 kits too but unless I'm doing something super simple there's not much reason to use it, the ARM chips are so cheap and better able to host Forth. eforth has never been something that I would design a product with, ok to play with, and very simple to implement, but slow and simple. Just keep an eye on the Tachyon folder for new additions besides V3 and V4, so you may have various cores and chips added and I may even update Tachyon for the latest frozen P2 as my part to help test the chip since TF2 does a bit more than just blink LEDS
I sure will
maybe we'll have a 'TACHYON for other HW' thread then soon ?
Yes, it is cheaper for me to buy from E14 for $8.90 AUD vs $9.95 USD from Mouser. I have other XMC boards as well to play with of course. In fact I have boxes full of ARM dev boards in addition to my FPGA boards and systems, and many other CPUs etc. I think the XMC1100 is quite useful since it has 16k RAM and I have bare chips in 16-pin TSSOP I can prototype with. The bootloader allows simple serial bootload.
Great, Cool
I'd be keen to see some benchmark 'before' and 'after' numbers for TF2 speed with the new Bytecode/wordcode opcodes Chip has just added.
I mentioned in the P2 forum that I may just build up my P2 development system as a full stand-alone system with bit-bashed VGA graphics to host my macroassemblers for the P2 and ARM written in Tachyon Forth. That way it is easy to expand the macroassembler and I get to test out the P2 as well. So perhaps initially under a new thread in the P2 forum I can talk about the stand-alone system and then maybe other thread for the macroassemblers with targets for P2, P1, and ARM (etc).
I have a BemicroCVA9 board mounted onto a motherboard that has dual SD, Ethernet, various communications ports, VGA, USB, RTC, and two Puppy module pods, so there is plenty of room of this board for a standalone system. The VGA will just be bit-bashed graphics so any P2 FPGA will be able to generate 4 or 8-bit color.
(Which reminds me - I should try out micropython on an ESP8266 board)
--- Output a byte to the LCD as a character pri LCDDAT ( ch -- ) *rs HIGH pri WriteLCD ( data -- ) --- write data (set after clear) *lcd OUTCLR 2* 2* OUTSET --- min 450ns pulse chip enable H H L ;I'm having problems to follow that piece of code:push pin# for data/control register onto stack
set pin high
push mask for data pins onto stack
clear outputs designated by mask
shift value on stack (character to output) left by two to be in line with data pins
OUTSET: set pins corresponding to bits set:
here my question: are only 1-bits positions touched, 0-bits left unchanged?
if this is the case, it is not possible to set/reset outputs in one command?
---OUT does that, found it!
H: set a output pin high, but how is the output addressed?
The same question for L
There is no masked write instruction, so the best way to write a bit field to a long is to clear the bits using the mask ( $3FC OUTCLR ) and then set the bits after shifting the data into the correct bit position from bit2 ( 2* 2* OUTSET). This is what it does: So the other bit positions are not affected, only the bits we need to write because we use ANDN to clear the bit mask, and OR to set the bits.
H and L are fast pin operations that use PIN to select the pin. The code ( *lcdce PIN L ) at the start of BitBlt sets that pin and makes it a low output. Since no stack items are pushed or popped this instruction executes in 8 instruction cycles.
Just starting with Tachyon (Tachyon triggered my interest in Prop), so based on your recent comments, I downloaded V4.1 I don't know what to do with the binary, so I loaded Propeller IDE. When I build I get this:
Tachyon V4.1.spin(6079:23) : error : Expected a variable
Line:
coginit(3,@loader, @loadpars)
Offending Item: loadpars
If I comment out the line, it builds, loads and runs. Is the loader init needed?
( 0001 $18C0 ok ) : STAR "*" ??? in STAR at "*"
I figured out this works:
( 0001 $18C0 ok ) : STAR 42 EMIT ;
B
Admittedly I forgot about the loader cog and loadpars does not need the @ operator since loadpars is a relative address to"registers". BST was compiling this anyway but I've patched it so it should compile properly now.
V4 is a bit different from V3, mainly under the hood with using wordcode instead of bytecode but also some other changes I thought I'd make with a new version. One of these was specifying character literals with 'A' rather then "A" as sometimes it was hard to distinguish a " A" which is a string vs "A" which is just the literal. There are a lot of symbols used in Forth that while useful for typing interactively are also hard to see in source code. Take the print number word . for instance, it's just a dot that depending upon the font etc may not be readily discernible so I prefer to use aliases for these such as PRINT and also use pub and pri as well to start a definiton. But then again sometimes I go the other way with == instead of CONSTANT since I find that big words like these can drown out the name, i.e: vs
The constant name stands out in the second example, much easier to read and works the same.
The other thing you will find with Tachyon is that the interactive console compiles word by word as it is encountered. This means you can't backspace to the previous word but you can have a really long line as there is no need for a terminal input buffer. Also it means too that you can use "compile only" words such as DO LOOP IF THEN BEGIN AGAIN etc interactively in exactly the same way as you would inside a definition. When you hit the enter key the line has already been interpreted and compiled so there is no delay since it executes immediately. Also there are no special (.") words etc so I could just type: and it will do exactly the same as it would inside a definition. Notice the clearly readable PRINT" rather than the tiny ." so you know it definitely is a PRINT and not an inline string perhaps.
V4 during entry also constructs numbers digit by digit so it is much faster than V3 and much faster than other Forths which search the dictionaries before trying to convert it to a number. The number convention is to use decimal by default and prefix all $hex and %binary numbers with an optional prefix for #decimal numbers. Be careful with V4, I haven't included basic backspace editing for numbers or definitions and strings yet
Load SEE.FTH if you want to see how the words are constructed.
There's a few optimizations with wordcode that allow 15-bit literals to be encoded into a single wordcode and an EXIT to be implied by simply jumping instead of calling as in the case of "GOTO EMIT". In the case of STAR wordcode has no memory savings over bytecode but it only required two hub accesses vs four and so it is faster even in that regard alone. FOR and DO are actual instructions rather than those immediate operations that other Forths have that compile a runtime version and compute a branch, but this is all done in Tachyon using fast branch stacks in addition to a loop parameter stack, safely leaving the return stack for return addresses and the data stack for what it does best. The loop indices are also accessible from a called function. btw, the top four items of the datastack are fixed registers so that the Propeller which does not have indexed addressing can directly operate on it efficiently. Also you may not find any PICK and ROLL so as to encourage clean and concise and factored stack use but there are 3RD and 4TH operators to make a copy of those items. That's some Tachyon tips in a nutshell but please feel free to ask questions.
Tachyons are solutions to an equation, that result in negation of laws of physics, but those can not be negotiated. But Tachyon allows you to enter the RPN world, where many tasks can be solved more easily.
So I jumped into Tachyon and I'm swimming like a lump of lead.
I have to explain: In Tachyon every word has just one meaning but by executing words in a sequence you can invert or xor the meaning and couple back so within a short moment you don't know what happens to you.
I look to a dictionary german english to find the right words and realize: lump - person der (auch: das) Trampel Pl.: die Trampel - Mensch [ugs.]
That was not intended. So a lump of lead doesn't mean the situation, where a lump leads a country, is means a piece of metal, not peace created by metal. So as I do not swim, I dive into Tachyon and hope to find and run out at the shore before I run out of breath.
If someone is interested in Peters IoT5500, what comes out to be a good starting point, I still have some of those board here in good old Germany and we also prepared some Quickstart compatible products to drive real hardware. Also, I started my learning curve with the LameStation and proplem and me we are currently creating a driver for the lcd display, with support from Peter.
As Peter has already demonstrated, even P2 can run Tachyon and this path should lead to a selfcontained system before any wall is erected!
By the way, I just have an idea, I get from my layout efforts: If I have to connect two high pin density objects that are located east and west of the PCB, I collect all the signal and make a high speed serial transmission line.
This line I place on the south side of the PCB. Now the middle area is free to place any standard component there.
So what it all highways from east coast to west are bundled in the south, very close to the borderline, and have them of hyper loop type. Then so much traffic will be there, that no living object can pass from north to south and vice versa. This is my contribution to the call for buildingtheborderwall.com
that's what bridges over multi lane highways are for ;-)
- to open the border so neighbours can see each tother ...
One of the ways of looking at Forth in general is to think of it as the assembler code of a virtual stack machine. Now in assembler we are used to those tiny operations that don't really do much, but by building and calling subroutines we can even write a compiler for P1. In Forth the calls are implicit and practically every Forth word gets compiled in a similar fashion to assembler where every instruction assembles to a machine code. This is very different to HLLs in general of course.
Do you like assembler? See that post about STARS a few posts back? That is "assembler" that can modify its own assembler and be molded to the application. When I write Forth I don't have to guess what and where that generated code might look like, whether there is a function for it in the library, whether after learning about the functions whether that function can actually do what I want, or whether I have to do what it wants, or whether that library has a bug, or whether it interpreted what i said a different way from what I meant because of incorrect syntax. No, what you see is what you get. Forth does just as you tell it, it doesn't second guess that you "need" to convert types in a warm and fuzzy way, and the only errors it really throws up are typos.
If I want to design and build a PCB I don't work from pre-assembled kits trying to fit one to another and then adding bits to make them work together, I just use the components and put them exactly where I want them the way I want to use them. That way I get exactly what I want and that is also the way I work with software much to the chagrin of many for some reason. Is that because it works so well?
I started to build an iot5500 with V4 and there seems COMPACT is not yet existing so no wonder I got in the last step (EASYNET.FTH):
Is this a known open issue?
Wow, to see Tachyon unleash the power of this little beast at 8.06/ea qty 1 to the average guy/gal would be fantastic.
Still really enjoy Tachyon on the Prop but I will be checking the folders for additional chips, yes I'm still working with the ESP8266 too, neat little SOC.
Only came across it myself yesterday as up until then it was all fitting in. So now I need to look at adding the fixed length EEPROM dictionary feature I intended to add at the start of embarking on V4. Back in V3 the COMPACT word would move the whole hub dictionary into hash indexed blocks which are read in as a block and the name would be found there but there was a lot of wasted space and complicated. So V4 simply creates a 16 byte entry for the name leaving up to 12 characters for the name which is more than enough in fact but if someone wants to use a long name then it simply stays in hub memory.
This means that V4 is designed to work with a hybrid dictionary, searching hub first, and then EEPROM and since each name in EEPROM is on a 16 byte boundary as well as being in alphabetical order it makes it a bit easier and faster to search. In the meantime I may just try to free up some memory so you can still load EASYNET.
That's one of the M7s but one that I happen to have a Nucleo-144 board for so I'm quite interested in running an M7 at 216MHz with Floating Point and DSP as well as 1MB Flash and 320kB RAM. I've compared P1 running Tachyon at 20MHz CPU clock with M3s running Mecrisp at 72Mhz and while Tachyon runs slower, it isn't by much. P2 is faster. Remember too that Mecrisp compiles inline assembly code rather than interpreting threaded code. The branch stack in Tachyon certainly speeds things up during looping for starters but there are other design features that max the P1.
I also see mention today of a Pi Zero W, for $10
https://www.raspberrypi.org/blog/raspberry-pi-zero-w-joins-family/
"To recap, here’s the full feature list for Zero W:
1GHz, single-core CPU
512MB RAM
Mini-HDMI port
Micro-USB On-The-Go port
Micro-USB power
HAT-compatible 40-pin header
Composite video and reset headers
CSI camera connector
802.11n wireless LAN
Bluetooth 4.0
"
Native Tachyon on that would be interesting
However, P2 is probably a better target, near term, to confirm the FPGA image.
The Nucleus demo board is $23 from Mouser.
BEWARE... It appears that only 16KB RAM may be usable as code space ???
: !LCD lcdmem 4 COGREG! 4 3 COGREG! [PLOT]: means start definition of a word !LCDIs there a special meaning of the ! in the word name !LCD or is it just for fun?
What is the meaning of COGREG, what the difference to COGREGS
Do I get this right: 4 COGREG brings the address of the 4th cogregister to the stack, but what does COGREG! do?
I know, I do all this to become productive ;-)
There are certain conventions I use and while the ! suffix indicates a store operation, I use ! as a prefix to indicate a default initialization value, pronounced INIT SP when prefixed.
So LCD itself may refer to selecting the LCD as an output device so that LCD PRINT" HELLO WORLD" will print to the LCD the same as it would to the console.
COGREGs are fixed REGister locations in COG memory that are used by special functions such as RUNMODs and by some other cog code such as (WAITPEQ) etc where they leave a result in a COGREG. So COGREG itself simply returns the address in the cog of that register. COGREG! will store to the register etc.
In regards to PLOT it needs to know the start address of the pixel buffer and the left shift required to address each line of pixels. Binary shifts are much faster than trying to multiply the Y.
Pixel = Pixel start address + X + Y<<shifts
Have a look at PING which uses these registers. Remember that trying to push and pop registers from the data stack slows things down, so having fixed register that are only accessed as needed is a way to improve efficiency and performance....and productivity.
pub PING ( trig echo -- us ) MASK 3 COGREG! --- setup WAITPxx mask DUP HIGH >R R> LOW --- 10us trigger (dummy cycles) (WAITPEQ) (WAITPNE) --- detect high period 0 COGREG@ 1 COGREG@ - --- calculate high period CLKFREQ #1,000,000 / / --- convert cycles to us ;