nandland.com go board

[oystercatcher]

I cloned swapforth and have been looking at j1a. There is a subdirectory
called nandland-go which has a bin file that I loaded into the go board.
The 7seg displays show 88. I tried using python3 shell.py -h /dev/ttyUSB1
but the command always hangs output similar to previous reports.

I am able to connect to the go board with gtkterm at baud 115200
0 leds turns off the 7 seg displays and words gives a list

I ran the Makefile and compared its output with the supplied j1a.bin

the results are different as my file is smaller and after connecting with
gtkterm I see that words is much smaller maybe 145 instead of
around 200.

My system is fedora 27
yosys -V
Yosys 0.7 (git sha1 UNKNOWN, gcc 7.1.1 -fPIC -Os)

I presume I am missing something in my setup for yosys
as I am new owner of the go board and have been able to
get some small programs running.

[oystercatcher]

I found another project on sourceforge that I think is more current
https://sourceforge.net/projects/mecrisp/

I also noticed an error in yosys when I ran read_verilog on ../build/ram.v

[RGD2]

Things to try: it’s recommended to see if the latest git builds of the icestorm toolchain fix your problems, since they are evolving so rapidly. Follow the installation steps on Clifford’s project icestorm website. Main thing is to have the dependencies, but I’ve been able to get swapforth / j1a working on even macosx with homebrew and macports. It also works on SBC’s with Ubuntu or Debian (odroid-c2, xu4, maybe raspi 3), so long as you have at least a gig of ram. Also, low word count can also be due to an error during the post-bootstrap part of the swap forth build- ie, where #include swapforth.fs happens. If there’s a serial transmission error, the only hint is the one line with a question mark the at beginning - the rest of the upload (#include is executed within the python shell.py script, it just uploads the mentioned file) doesn’t notice and plows on. I usually do that step using verilator, and then do a final rebuild to include the new ram.v contents. (The newer versions of icestorm now support changing just the ram contents of a bit file, without having to do a full yosys /Arachne-pnr rebuild, but we haven’t integrated that into swapforth yet, AFAIK) Mecrisp-ice is very good if you want a more complete forth system, but will require a 4K/8K chip to fit its larger memory. (I think the nandland go is a 1K ice40?). What is it you would like to do with swapforth? Do you have a specific application in mind?

On Mon, 4 Jun 2018 at 5:46 am, oystercatcher ***@***.***> wrote: I cloned swapforth and have been looking at j1a. There is a subdirectory called nandland-go which has a bin file that I loaded into the go board. The 7seg displays show 88. I tried using python3 shell.py -h /dev/ttyUSB1 but the command always hangs output similar to previous reports. I am able to connect to the go board with gtkterm at baud 115200 0 leds turns off the 7 seg displays and words gives a list I ran the Makefile and compared its output with the supplied j1a.bin the results are different as my file is smaller and after connecting with gtkterm I see that words is much smaller maybe 145 instead of around 200. My system is fedora 27 yosys -V Yosys 0.7 (git sha1 UNKNOWN, gcc 7.1.1 -fPIC -Os) I presume I am missing something in my setup for yosys as I am new owner of the go board and have been able to get some small programs running. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AO8-GP7UChnaCtRMuw1SbXGfsSdZYKKgks5t5D0UgaJpZM4UYNk6> .

-- -- Remy

[oystercatcher]

I have tested the binary from   swapforth    as well as the one from  Mecrisp - Native code Forth for MSP430 and ARM Cortexfor the nandland.com  go  board.     The binary from  mecrisp   uses   picocom    called terminal  in their setup and it seems to work. Having a  cli  to the  p1a   is  amazing.               I don't know forth   but I remember that it was the os for the  solaris   boot rom  Thank you  for making forth  new again.    On Monday, June 4, 2018 7:29 AM, RGD2 <notifications@github.com> wrote: Things to try: it’s recommended to see if the latest git builds of the icestorm toolchain fix your problems, since they are evolving so rapidly. Follow the installation steps on Clifford’s project icestorm website. Main thing is to have the dependencies, but I’ve been able to get swapforth / j1a working on even macosx with homebrew and macports. It also works on SBC’s with Ubuntu or Debian (odroid-c2, xu4, maybe raspi 3), so long as you have at least a gig of ram. Also, low word count can also be due to an error during the post-bootstrap part of the swap forth build- ie, where #include swapforth.fs happens. If there’s a serial transmission error, the only hint is the one line with a question mark the at beginning - the rest of the upload (#include is executed within the python shell.py script, it just uploads the mentioned file) doesn’t notice and plows on. I usually do that step using verilator, and then do a final rebuild to include the new ram.v contents. (The newer versions of icestorm now support changing just the ram contents of a bit file, without having to do a full yosys /Arachne-pnr rebuild, but we haven’t integrated that into swapforth yet, AFAIK) Mecrisp-ice is very good if you want a more complete forth system, but will require a 4K/8K chip to fit its larger memory. (I think the nandland go is a 1K ice40?). What is it you would like to do with swapforth? Do you have a specific application in mind?

On Mon, 4 Jun 2018 at 5:46 am, oystercatcher ***@***.***> wrote: I cloned swapforth and have been looking at j1a. There is a subdirectory called nandland-go which has a bin file that I loaded into the go board. The 7seg displays show 88. I tried using python3 shell.py -h /dev/ttyUSB1 but the command always hangs output similar to previous reports. I am able to connect to the go board with gtkterm at baud 115200 0 leds turns off the 7 seg displays and words gives a list I ran the Makefile and compared its output with the supplied j1a.bin the results are different as my file is smaller and after connecting with gtkterm I see that words is much smaller maybe 145 instead of around 200. My system is fedora 27 yosys -V Yosys 0.7 (git sha1 UNKNOWN, gcc 7.1.1 -fPIC -Os) I presume I am missing something in my setup for yosys as I am new owner of the go board and have been able to get some small programs running. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AO8-GP7UChnaCtRMuw1SbXGfsSdZYKKgks5t5D0UgaJpZM4UYNk6> .

-- -- Remy — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RGD2]

Picocom / gtkterm (And kindof, also shell.py) are all just acting as a terminal to send / display characters over the serial interface. So, they're interchangeable to a degree.

swapforth's shell.py is convenient as it allows for some 'pseudowords' (those that start with #) which are executed within itself, and also, it uses readline so you can edit your lines before sending them using the cursor keys, as well as use the history (ctrl-r to search, and up/down arrow to browse the last lines sent), and this is convenient if you're used to it. It also has tab-completion for words on the system at the moment it is connected. (you can disconnect/reconnect to get it to refresh this list, it's actually running 'words' without showing you, but it's not smart enough to notice dynamically that new words appear with the use of :, or that words may dissappear with the use of new or other marker-defined 'save points').

Any generic terminal emulator is going to send the keystrokes as it gets them, so you don't get tab-completion or even line editing, as those are not included in swapforth. It's still usable though, and you can usually still get terminal emulators to 'send' other text files, which is the equivalent to #include in shell.py. It's highly recommended to work this, way, and document how you build your final application and from what, since otherwise it's really easy to just 'play with it' until it works in forth directly, and then forget how it works / why you did it that way sometime when a couple years later you really want to change it just a little. (also, it's impossible to share your work, except as a compiled 'binary' image taken using the #flash word, which actually dumps out the j1a's ram contents to a file, so it can be 'baked' into the next FPGA recompile).

Anything that talks rs232 serial at the expected rate and format (without sending too many characters at once) will work. You could change the design, add a max232 adaptor, and have a 'real' D9 or D25 port if you wanted. Or you could get a esp8266, put https://github.com/jeelabs/esp-link on it, and wire it to the tx and rx pins on your fpga (which you can change in the pcf if you want them anywhere else), then use your smartphone to talk to your swapforth machine without anything else nearby, just connecting to the hotspot and web-terminal the esp-link module will provide. (Olimex have '8266 modules/boards which include battery supply/charge circuitry, so you could make it completely portable fairly easily. They also do some very interesting looking ice40hx1k and 8k boards also, although you will need an additional arduino or ft2232 board for programming the ice40 on their boards, as they don't have the usb-serial converter onboard).

Swapforth on the j1a is pretty amazing. It's basically ideal for run-time reprogramming / parameter tweaking of a custom FPGA-based control system for experimental purposes. (or just 'adhoc' control purposes also).

It's surprisingly fast in terms of 'forth words per second', even compared to mecrisp on much faster clocked arm microcontroller chips (they would have about a 30x performance advantage for just being ASIC CPU's and not being a soft-core on a FPGA, but they have to emulate forth's stack machine ISA / 'VM' with a named-register ISA and ram-emulated stacks, which is slower than the j1a's 'native' forth machine approach).
Being in an FPGA means that after benchmarking has determined the bottle-necks, you can easily add bespoke digital logic to accelerate the slow parts and end up with extremely good overall system performance, far better than bit-banging IO or trying to react to async inputs by polling an input. You can copy/paste the rs232 interface and add more if you want, or roll your own SPI or I2C masters or slaves, so communications don't require any of the j1a's time.

[oystercatcher]

Thanks for the information as I came to this project as a novice at pretty much everything
around fpga's and forth. I am interested in learning about the processor design and how
it was implemented in verilog and icestorm.

Is it possible that my build of j1a.bin is ok but the failed connection with python3 shell.py /dev/ttyUSB1 prevents an update that provides the additional words.

I am going back to try the build from swapforth using picocom and see if I can do
a transfer for that include file.

Sorry I don't quite understand the process as yet but I think I get the idea that
after the transfer of the include file completes; forth will have the added words
and then it is possible to create a usable j1a.bin file.

[jamesbowman]

If I recall, the nandland does not reset on UART connection.
So maybe try connecting with python3 shell.py /dev/ttyUSB1 then while it's hanging hit reset on the board?

[oystercatcher]

I have tested the binary from https://sourceforge.net/projects/mecrisp/files/mecrisp-ice-1.3.tar.gz
and it is working with a cli and forth. I also tested their toolchain and had a working binary on the
nandland go board.

Lots to study.