6502.org

I knew I doggedly stuck with 18.04 for good reason!

Dave

hoglet -- well, it is not a problem with the preloaded library. Works like a charm, but scared me for a few minutes.

Just one of the many bizzare problems to solve.

Apparently I must enjoy it, or I'd be doing something else, I suppose.

I am back at my lab, on a slightly-more-modern 8th-gen I7, and am happy to report that my build times are just under 20 seconds using the IDE (for my Tugman CPU SOC, it is under 10 seconds!).

I am in the process of reinstalling the opensource yosys/apycula/nextpnr toolchain and will report when I get that working. God knows I've installed it enough. Maybe this time I'll be able to get nextpnr-gowin to work in graphics mode (himbaechel does not, and my previous attempt with nextpnr-gowin in GUI mode crashes my laptop), and finally see the FPGA.

Also -- I found my password for enso, so I will be phasing out enso1 (I swore I tried that password many times!)

I have many other good news to report, but first I have to get settled in.

Looking forward to updates from the original enso!

Warning: original enso is just as grouchy as enso1!

Free Toolchain Notes
The free toolchain is an amazing achievement, but it has its issues.

It is slow. My Tugman project (an 18-bit CPU SOC taking up about 500 LUTs, ~6% of FPGA resources), builds in the Chinese IDE in 10 seconds flat on an 8th-gen I7 box. The free toolchain took 4 times as long. So I will not be using it for iterative develpment.

But it is a flexible tool for digging into the FPGA, viewing it in a way not possible in the IDE, and performing experiments to supplement our understanding of how it is wired up internally.

In particular, with some cajoling, it is possible to pull up an 'FPGA Editor'-like view of the fpga and trace BELs and wires.

But in order to do so, you need to use nextpnr-gowin (instead of the more up-to-date nextpnr-himbaechel) in --gui mode (because nextpnr-himbaechel does not show anything in gui mode!), and you need to patch nextpnr-gowin prior to compiling to prevent crashes... Yeah, I almost gave up on it but then figured it out anyway. The patch is documented here: https://github.com/rfuest/nextpnr/commi ... f6ab1f5e1c.

Anyway, the best starting point if you want to use it with Gowin is https://learn.lushaylabs.com/os-toolcha ... tallation/, except you want to add -DBUILD_GUI=ON (and make sure qt5 dependencies are met -- read the README.md). Also, build nextpnr-himbaechel, since you will be using that mostly, without gui).

There are a few hazards ahead -- getting the damn Python and pyenv to work, and in my case, having to `export LD_LIBRARY_PATH=~/.pyenv/versions/3.9.13/lib` anyway for some reason. I hate Python -- the most unstable crap language there is, but everything depends on it. When some jackass who maintains an unknown library decides to change the name of some variable from current_version to current-version, everything comes crashing down.

Apycula, the project reverse-engineering Gowin, has some interesting documentation, worth looking at on github.

https://github.com/YosysHQ
https://github.com/YosysHQ/nextpnr
https://github.com/YosysHQ/apicula

Command-line builds using GOWIN tools

Gowin tools have a built-in Tcl scripting capability. In particular, the binary gw-sh is a command-line version of the toolchain, which allows you to manually load the files, configure options, and run synthesis and/or pnr.

This would be very tedious, but you can send it a script containing something like: If you find that tedious, just open an IDE project like you always do, select 'console' at the bottom, and enter saveto script.tcl (use a name that would make sense, of course). It will have everything except the final run all, which you should add yourself.

See the appropriate manual (SUG100-4.1E_Gowin Software User Guide.pdf), and explore by dumping your project from the IDE, using saveto -all_options <filename>. You may have to remove some options that cause errors for some reason, but you get the idea.

For an extra credit, create a Makefile. Now you are a real power user.

I'm running out of steam.

I cleaned up my 65c02 system -- it now contains the bitstream, so you can

• * load the provided .fs bitstream with OpenFPGALoader or whatever;
  * build using the opensource toolchain with the attached Makefile;
  * build using the GOWIN IDE - the project file is attached;
  * build using GOWIN's gw-sh command-line tcl tool, using the attached tcl script.

https://tildegit.org/stack/Tangnano9K-65c02-experiments

Hi,
Tried out the 65c02 experiment core but nothing was seen on the Teraterm terminal. Any key presses will lit the led.
I also added the full path to the rom.init file and processed the project under Gowin Ide. The Gowin nano 9k uart examples all verified to be working.

I am away from the 9K board, and just got the 20K, so cannot test directly, but the same project (yes, the paths were off for the IDE) loaded into the 20K, and is showing "GOWIN 65c02 Send bin..."

Check that your terminal is set to 115200-8-N-1...

NOTE: copying the 9K files to the 20K, I had the reset button wired backwards, and the system ran as long as the button was held down! I can't verify if the 9K has the same issue -- give it a look. NO, the Nano20K buttons are wired to go high on press, while 9K buttons are grounded on press...