Coexistence with TAQOZ
msrobots
Posts: 3,709
As mentioned before I really would have liked to have a callable version of TAQOZ running in a COG while other programs run in HUB.
Sadly Peter did not get this done with his current implementation, or did he?
The current version of TAQOZ and Clusso99's Monitor/Debugger gives me hope to acomplish my goal. So lets see:
TAQOZ needs currently one COG, the lower 64KB of HUB and some place in HUB for stacks and dictionary, not sure where it is in HUB now, but recall to have read that this is somehow settable via TAQOZ.
So one should be able to restrict TAQOZ to one or two HUB areas and one COG thus leaving 7 COGS and the remaining HUB for a USER program.
The simplest way would be to use two other pins for a serial connection from user program to existing pins of TAQQZ serial prompt,
Now the user program can talk serial to a parallel running TAQOZ subsystem.
It is not easy to explain to Peter, since his point of view is that once in TAQOZ there is no need for SPIN or C. And I still think that it is a waste of ROM space if we end up in a either/or situation.
Being able to write a SPIN/C/PASM/BASIC/BLOCKLY/whatever program that can use TAQOZ onliners by just writing them out serial make a very easy 'mailbox' system.
And since TAQOZ allows inherently the ability to switch consoleIO to different targets, it might even be possible to avoid pins for communication.
What is needed for that?
-The loader needs to be able to load something behind TAQOZ low HUB area without overwriting TAQOZ. One can do this right now by hand with the current ROM.
-TAQOZ redirection instead of two extra pins and two wires. or is it possible to use some Smartpin feature that two COGS can use the existing 2 serial pins to let the 2 COGs talk to each other?
-SPIN/C/PASM/BASIC/BLOCKLY/whatever need to build a normal image or one keeping the running TAQOZ alive.
Any thoughts?
Mike
Sadly Peter did not get this done with his current implementation, or did he?
The current version of TAQOZ and Clusso99's Monitor/Debugger gives me hope to acomplish my goal. So lets see:
TAQOZ needs currently one COG, the lower 64KB of HUB and some place in HUB for stacks and dictionary, not sure where it is in HUB now, but recall to have read that this is somehow settable via TAQOZ.
So one should be able to restrict TAQOZ to one or two HUB areas and one COG thus leaving 7 COGS and the remaining HUB for a USER program.
The simplest way would be to use two other pins for a serial connection from user program to existing pins of TAQQZ serial prompt,
Now the user program can talk serial to a parallel running TAQOZ subsystem.
It is not easy to explain to Peter, since his point of view is that once in TAQOZ there is no need for SPIN or C. And I still think that it is a waste of ROM space if we end up in a either/or situation.
Being able to write a SPIN/C/PASM/BASIC/BLOCKLY/whatever program that can use TAQOZ onliners by just writing them out serial make a very easy 'mailbox' system.
And since TAQOZ allows inherently the ability to switch consoleIO to different targets, it might even be possible to avoid pins for communication.
What is needed for that?
-The loader needs to be able to load something behind TAQOZ low HUB area without overwriting TAQOZ. One can do this right now by hand with the current ROM.
-TAQOZ redirection instead of two extra pins and two wires. or is it possible to use some Smartpin feature that two COGS can use the existing 2 serial pins to let the 2 COGs talk to each other?
-SPIN/C/PASM/BASIC/BLOCKLY/whatever need to build a normal image or one keeping the running TAQOZ alive.
Any thoughts?
Mike
Comments
But, once the P2 boots, anything is possible. We can even "patch" the ROM since it's really in RAM. We have the ability to load significant amounts of code from Flash or SD or download too, from the base resources that SD/TAQOZ/Monitor gives us.
BTW, I specifically wrote my routines to be callable from the ground up. I only had to tweek the SD routines to make them totally general purpose. The Monitor routines have always been callable, from way back in 2013 when I started work on this. The Monitor section provides top level interactive access to all the underlying routines, and those routines are also available for user code to call, which also includes the Monitor.
However, IMHO TAQOZ is more for running interactive one-liners. It has access to all the hardware. What you can do with TAQOZ is amazing. It's fast and uses little resources. And, you can write substantial programs in TAQOZ. However, I think teh ROM version of TAQOZ is a stepping-stone to a full-blown version of TAQOZ where you will d even more amazing things. ROM TAQOZ is a "taste" of things - a pretty big "taste", but a taste none-the-less.
I am thinking the same.
If you are going to load extra code anyhow, then you have a Flash/SD available for code storage and can easily load a full version of TACHYON - no need to restrict yourself to what is in ROM.
So the question is probably more how can Tachyon and other programs coexist and benefit from each other.
Tachyon and TAQOZ runs in low memory so an area needs to be reserved and other programs set up accordingly.
Then we go into the question of how do those programs cooperate - AND how to make sure they do not conflict.
The current P1 Tachyon already provides some mechanisms to load cogs with 'ROMS' ... kind of COGlets.
I think it depends on the model you have in mind.
Could be Tachyon as master using other code e.g. a fast FFT / float-package ... written in another language. - surely something like this will happen.
Or having your main() code running and requesting services from seperately running Tachyon ?? ... Who would want this / why?
1. The ability to boot further code
2. Without further code booting, the ability to utilise the ROM to test ou the P2. That is what TAQOZ and the Monitor can do, all without having FLASH or SD, just a serial connection.
TAQOZ would be very useful for debugging prototypes or faulty hardware and also for interactively experimenting with a P2 chip with the absolute minimum of resources, even a smartphone.
The booter though allows us to load a new "ROM" at the top of memory if we wanted too.
Imagine having a choice between TAQOZ in mask ROM or Tachyon firing up from SD, and talking to a VGA monitor and USB keyboard and mouse etc, just like a PC, and with a GUI interface and Internet connectivity. Which would you use?
sounds like what Chip has been dreaming of
the Propeller-PC
just have to convert/convince him to go for Tachyon/Forth ;-)
I'm typing using forum software in Firefox on Linux and I don't care what it's been written in, as long as it works. The O/S would provide an environment to edit your files, compile using fastspin, spin2, gcc, Tachyon, or whatever and run it from there. Imagine debugging your program while it is running in other cogs, displaying buffers, registers, and code etc. While a PC IDE is nice, an IDE on the P2 would not be dependent upon the latest O/S version and having the "right" hardware and 32GBs of RAM.
ME.
The reason for that was what I tried to explain in my first post.
people familiar with C/SPIN/BASIC/PASM can program and run stuff in any language they want, but STILL be able to just talk to a parallel running basic TAQOZ to run words / one liners by just sending/receiving strings.
What a smart transition. First they call just existing words, but then need to optimize their string sending/parsing and write some own words to use.
Sooner or late any C/SPIN/… program will use short forth scripts to modify the ROM booted TAQOZ and call them like sub routines.
And since TAQOZ is in ROM any program can assume a starting point after reset, like any p1 program new there would be a sin table.
Enjoy
Mike
Then you need to patch it so you can pass one-liners.
So, it would be better to load a new TAQOZ that supports this and more.
I think you are missing the point of TAQOZ vs TACHYON. TAQOZ is an interactive ROM version to be used to explore the P2 without the need to load anything. Once you have the need to load anything, it's easier to also load a better, more featured TAQOZ/TACHYON. At least, this is what I understand Peter has done.
That pretty much says it I think. If P2 was like many other CPUs with a large ROM and Flash and a smaller RAM then having a beefier and reusable TAQOZ would make more sense. As it is, of the 512K of RAM, TAQOZ only takes up 12K and does more than it even needs to. Once there is user code running, then there is a boot memory device, and if there is a boot memory device, then it is easy to have a full version of Tachyon running.
Cluso99 says that he build the SD routines as callable since he sees like me the usability of them being in ROM after reset if not overwritten. One program can assume they are there. He also states that doing the same for TAQOZ was not discussed, understandable.
MJB and Peter seem still to miss the question in the title of this thread. Also understandable because they want to replace TAQOZ at boot time with Tachyon and see no need in talking to the bootable TAQOZ. For what? is their mindset.
I on the other hand would like to be able to run a program written, in a language of my choice, say Spin2, Pasm2, PropGCC2 and use the ROM-build in TAQOZ kernel like I can use it now in interactive mode running in one COG, using the lower XX kb of HUB ram and some upper xx KB of Hub-ram?
While my Program resists in between top and lower Memory requirements TAQOZ has, leaving TAQOZ running in its COG and redirecting the TAQOZ console to my program as a serial driver object or whatever will make sense.
So without loading Tachyon I could use all the goodies the ROM build in TAQOZ has, with a known memory footprint and in ROM so there after reset.
Kind of reusable like Clusso99s SD routines.
And I still have the rest of the HUB and COGS for my software, not written in FORTH, just containing some useful FORTH snippets as command strings for the TAQOZ object.
doable?
Mike
TAQOZ is not usable in ROM. TAQOZ needs to copy itself to lower Hub RAM, and then some into Cog, before it runs in cog. It's not callable as routines. It's only callable as a whole, which is then interactive with the user.
TAQOZ is a reduced version of Tachyon. If you are loading your own code, then what is wrong with loading a more complete version of TAQOZ ie Tachyon as well ???
Yes Cluso99, I am aware that TAQOZ needs HUB ram, In all 3 of my posts I mention that my user program would be loaded and compiled to accommodate for this.
I also mentioned in all of them posts my reasoning behind NOT loading a different version as is already in the ROM, the reason is to have ONE standard version of TAQOZ and not a running Target, changing every time Peter works on it.
It is about long living source code. On the P1 for example I can be sure to find the font at a certain address, or the sine table. Even SPIN is fixed and my code written 8 years ago can relay on them addresses not changing since build into the silicone of the particular chip.
I also understand that the P2 ROM is not ROM at all and can be patched, or even overwritten. But lets just assume the programmer is aware of this and that after a reset he or she knows that the ROM is there as burned into silicone.
So in opposite to use TACHYON 'scriptlets', which might or might not work with any current TACHYON version even 2 month later, I would like to use TAQOZ 'scriptlets', thus being assured that the ROM build in TAQOZ kernel and its dictionary is there and my code will work even 10 years later, on any new P2 board.
Yay Peter, finally a useful answer.
Ok,
I load my program, reserving space for TAQOZ and at program start switch myself to say COG 1. Then I could start TAQOZ by calling _Enter_TAQOZ from COG 0.
I might need to patch some ROM position where TAQOZ gets its autobaud value to set the speed I would like to use.
Now TAQOZ uses serial and runs just nice and fine in parallel to my own software.
Is that correct, so far?
This would allow the build in TAQOZ to not just check and test connected HW, but also be able to check and test the running user program, being invisible and able to report about pins, HUB, whatever.
As a plus I would like to be able to use the parallel running TAQOZ subsystem from my running user program to run 'scriptlets' as mentioned before.
am I getting nearer to explain what I am looking for?
Mike
The next part is a little harder. You need to replace TAQOZ's serial input routine so you can pass in the one-liner. I know TAQOZ interprets the line as it comes in, so you cannot (as far as I understand) pass it a buffer (string) command. Peter can better answer this.
BTW I still don't follow you adversion to using a more complete loadable version of Tachyon. You can use a frozen version if you like. Ten at least, it would be easier to add Tachyon functionality at a later date.
Hi Mike,
I think I have an idea of what you want and from my sure incomplete understanding of TAQOZ/Tachyon I am suggestng another aproach than the one you have in mind.
I really like interactive systems with Read-Eval-Print loops
from the old BASIC via LISP/Prolog/Smalltalk/Beanshell for JAVA/LUA and of course Tachyn/Forth.
I am using a ESP8266 running NodeMCU/Lua as a server ans send command strings via serial from my prop.
So let'S have a closer look:
I understand you want to run TAQOZ as a service to execute your scriptlets.
Do you want to keep the serial/terminal line connected to TAQOZ ?
Or will you use the terminal for your own purposes'?
This has some implications on how to set things up.
Once TAQOZ is started as Peter pointed out above,
TAQOZ is running an interrupt routije to get serial characters into a receive buffer,
from which the TAQOZ gets it'S input.
So to interface you could eiter stop the interrupt routine if you will not use the terminal directly n TAQOZ or just let it running.
Knowing where the buffer and buffer pointers are in HUB RAM your code can put characters into the buffer to feed commands/ to TAQOZ.
Teh you need to get a handle on the output.
Default TAQOZ does not use buffered output (I think)
So it needs to be patches to write to some HUB buffer area, where your program can pick it up.
So you need to know quite some internals and apply some patches to make it work.
Now to how I would approach it:
instead of the ROM version I would go for a full Tachyon, apply the needed modifictions,
and then YOU FREEZE the code - you are not dependent on Peters moving target implementations of Tachyon, which really can pe a pain (I know!!)
If you do not want to change it this code can be stable forever - it is yours then.
You make a binary to load from SD - and it is a stable as silicon - you never need to touch it again - but you might not trust yourself on this ;-) ....
But it will provide you with a far greater universe of functionality than the ROM version can accomodate.
So I can only see benefits of this approach - no drawbacks ...
so what do you think I am missing ... ?
MJB
If there is any chance to get TAQOZ 'scriptlets' be interchangeable between different programmers using different languages, then the whole TAQOZ in ROM thing would simply make more sense to me.
You know, programming in C and just talk to a local TAQOZ serial, like you would talk to a RTC via I2C or a sound chip for voice out or a second P2 as IO/extender, bare like it is, without flash and SD.
Combining the power of FORTH with other languages without the need to really understand FORTH, just sending and receiving strings to and from a sub-system. That is what I am calling 'scriptlets' in my posts.
So - yes I currently will be able to write a Spin program talking to a second bare P2 over serial just using the build in commands of TAQOZ, maybe define some 'macros' with own words.
No need to load, boot, program anything on the second P2. Just use the build-in TAQOZ as a programmable IO-extender/signal-processor/whatever you want to call it. This is supposed to be working already.
What I try to accomplish here is not just to do this with a second P2, but with the same P2 my own software is running on.
The hard way and most compatible with a second P2 would be to use two extra pins on the first P2 to either talk to a second P2 or without a second P2 just connect those two extra pins to the existing serial pins, effectively using 4 pins to talk to each other over serial.
And the user program running on COG 1-XX can with any serial driver call TAQOZ running on COG 0.
Sure it would be better if one could use some mailbox in HUB instead of 4 pins, and Peter is using the console-redirection a lot, it is one of the main nice things of TACHYON that you write some formatted output to a file/flash/I2C LCD/where ever and then write CON to have your console back on serial.
I might be completely wrong here, but I guess if Peter wants to write a word redirecting TACHYONS console to a 'classical' Spin/Pasm mailbox in HUB ram, he can do so. And like waiting/checking for a key stroke he will wait and check for the content of the mailbox addresses to change, same with output.
The loader of my program, starting my self into COG 1, patching the ROM for serial and starting TAQOZ could then also patch the ROM loaded dictionary in lower HUB ram to add that word to the currently still full known dictionary.
Mike
and the step below can follow later when you really need it