Forum Update - Announcement about May 10th, 2018 update and your password.

Coexistence with TAQOZ

msrobotsmsrobots Posts: 1,952
edited June 9 in Propeller 2 Vote Up0Vote Down
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
I am just another Code Monkey.
A determined coder can write COBOL programs in any language. -- Author unknown.
Press any key to continue, any other key to quit

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.

Comments

  • 17 Comments sorted by Date Added Votes
  • Cluso99Cluso99 Posts: 13,770
    edited June 9 Vote Up0Vote Down
    While it would have been nice to be able to call TAQOZ, there was just no time to even discuss the possibility of if/how to do it.

    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.
  • Cluso99 wrote: »
    ..... However, I think the 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?



  • The ROM code achieves two things...
    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.
  • Peter JakackiPeter Jakacki Posts: 7,459
    edited June 9 Vote Up0Vote Down
    What's a measly 12k of Tachyon kernel (and dictionary) compared to 32k or more that could be loaded in and we know that would be far more than three times the functionality.
    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?


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • ..... 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 ;-)
  • MJB wrote: »
    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.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • msrobotsmsrobots Posts: 1,952
    edited June 9 Vote Up0Vote Down
    MJB wrote: »
    ...Or having your main() code running and requesting services from seperately running Tachyon ?? ... Who would want this / why?

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99Cluso99 Posts: 13,770
    edited June 10 Vote Up0Vote Down
    TAQOZ does not run in HUB ROM space. It gets copied to lower Hub and runs from cog and lower Hub. So it needs to be copied first before you can pass it anything.

    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.
  • Cluso99 wrote: »
    TAQOZ does not run in HUB ROM space. It gets copied to lower Hub and runs from cog and lower Hub. So it needs to be copied first before you can pass it anything.

    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.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • So I conclude a little bit.

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99Cluso99 Posts: 13,770
    edited June 16 Vote Up0Vote Down
    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 ???
  • Peter JakackiPeter Jakacki Posts: 7,459
    edited June 16 Vote Up0Vote Down
    TAQOZ doesn't get to be copied to lower hub RAM until it is called from the monitor. So even if you boot your code it will boot into cog0 and TAQOZ boot image only exists in hub ROM so you would have to call:
    fd02c              _Enter_TAQOZ
    
    That however uses cog 0 so you would have to transfer your code over to another cog, coginit #0,##_Enter_TAQOZ, and wait or check to see if this is loaded before you could use it. I'm not even sure about the autobaud information that TAQOZ reads as that may not be there anyway. So it is a little bit more complicated than just calling it. If I had more time to test out TAQOZ in "ROM" then we may have come up with a better way to have it resident. But we could never test it as ROM until late in the game and then we were also trying to squeeze it all in and test it etc.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • msrobotsmsrobots Posts: 1,952
    edited June 16 Vote Up0Vote Down
    Cluso99 wrote: »
    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Cluso99Cluso99 Posts: 13,770
    edited June 16 Vote Up0Vote Down
    The serial baud setup is quite easy. Let your program initialise the serial before starting TAQOZ. Both TAQOZ and the Monitor use whatever is setup by the booter. In your case, you set it up instead. In fact, you can call the serial setup routine in my Monitor ROM with the desired parameters if you want.
    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.
  • msrobots wrote: »
    Cluso99 wrote: »
    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

    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






  • msrobotsmsrobots Posts: 1,952
    edited June 16 Vote Up0Vote Down
    I try to explain again. The TAQOZ in ROM is a finite version, one that will never change and is available on any P2.

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    I try to explain again. The TAQOZ in ROM is a finite version, one that will never change and is available on any P2.

    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 - if this is what you want - it is all there - just go for it

    and the step below can follow later when you really need it
    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

Sign In or Register to comment.