The verilator testbench extended with possibility to dump the memory with all defined words to the hex file.

[wzab]

When working with the real hardware, the user defined words are stored in the file which must be later on transmitted via UART (e.g. the swapforth.fs) . That means, that initialization of the J1B may be time consuming.
Unfortunately, it is not possible to add the files with additional words to the list of files compiled by the crossassembler, as their format is different (e.g, they do not contain header definitions).
To allow the user to create the memory image with all currently defined words in a "nuc.hex" compatible format, I have added a virtual IO device to the Verilator testbench.
Each read from the $2345 IO port dumps the current program/data memory to the mem_dump.hex file.
If this file is used instead the original nuc.hex in the synthesis, the J1B in FPGA will have the same word definitions as the simulated J1B had at the moment of memory dumping.
That proces may be used even if the target J1B is equipped with the hardware not simulated in the Verilator testbench (the new words are only defined, not executed, so the lack of the related hardware is not a problem).
Connected with the possibility to define the "cold" word (which is executed immediately after the FPGA is configured and/or J1B exits the reset state), the proposed feature allows to synthesize J1B with embedded procedures for target board initialization. After the "cold" word returns, normal interactive work is resumed.

I have also added two scripts:

1. localtest_interactive: It allows to use the Verilator testbench to play with swapforth and to develop new words.
2. localtest_gen_hex: It automatically loads swapforth.fs and user.fs (with user defined words) and dumps the memory to the mem_dump.hex as described above.

[RGD2]

I have something similar for the j1a, but I handle getting the flash by using the #flash build/nuc.hex command built into the python serial client, no extra IO device needed.

Could you use that?

The reason being, it's the same way as getting the nuc.hex image back out of actual hardware as from the sim. This seems less complicated to me, but I don't know whether it works for the j1b varient.

I have a new make target set up to facilitate this make sim_connect, which in j1a/verilator/Makefile looks like:

sim_connect: build/lib/python/vsimj1a.so ../build/nuc.hex
    python shell.py -p ../ -p ../../common

This is called from another phony target in j1a/Makefile which just runs it make -C verilator sim_connect.
I have an explicit 'project.fs' file I use to #include the actual application source, which lives out of tree.
It does something like:

#include swapforth.fs
#include ../../myproject/myapp.fs
:noname initapp quit ; init !
: help ." Some help message here in case someone who doesn't know how swapforth works chances across this. Version something of myapp from somewhere.  " cr ;
#flash ../build/nuc.hex

This I call from with something like:

cd ../swapforth/j1a
make clean sim_connect

Then I #include the project.fs, disconnect and run make j4a which builds my varient of the j1a with different io, and also flashes the eeprom on the dev board.

Note that when I'm just working on the "myapp.fs" code I usually use a "clean" hardware with swapforth on it, periodically #including that after resets.

There's also a "make bootstrap" target which does essentially the same thing with verilator and just swapforth.fs, which allows building the image including swapforth.fs without first building the one with just nuc.fs.

But again, all of this is for j1a and not j1b, and I'm not sure how/whether we can possibly organise so that work like this propagates naturally across j1 varients.

I think that could work if we deliberately keep each varient in its own derived branch, so that merges from the parent branches allow such work to be sensibly propagated down the tree of derivatives.
But at the moment each derivative is slowly diverging like so, and maybe such a drastic reorganisation of swapforth is an early optimisation.

[wzab]

Of course I do not insist on having this functionality to be included in the mainstream version. It is just a proposal.

In fact i was not aware of the availability of the "#flash" command. My fault.

I have compared the hex files produced by #flash and by my virtual IO and I can see a few differences.
Some of them are obvious (unused memory is left as 0xfffffff by #flash and as 0x00000000 by my routine - it is good for real FLASH, and can be easily changed), but some of them are not so obvious:

4185c4185
< 0000000a
---
> 00000010
4192c4192
< 00000009
---
> 0000000b
4195c4195
< 00000009
---
> 0000000b
4198c4198
< 00000000
---
> 00000010
4201,4203c4201,4203
< 34333224
< 6f692035
< 32692040
---
> 65682030
> 64206572
> 32706d75
4307c4307
< 00000010
---
> 0000000a
4598,4599c4598,4599
< 00000000
< 478c0000
---
> 37340000
> 478c3333
4604c4604
< 00000000
---
> 000047d8

Additionally the "$2345 io@" is faster (but the execution time of #flash is also minimal).

PS. In my fork I have also some changes, that may be useful (introduced only in the VHDL version of the J1B). I have added "io_ready" signal allowing J1B to work with slower I/O devices. I have also added a very simple Wishbone controller (now used only to control the I2C controller from OpenCores).
Those modifications are available in the "wb_i2c" branch.