On Monday, December 12, 2022 at 2:38:09 AM UTC-5, Jurgen Pitaske wrote:
> On Monday, 12 December 2022 at 01:12:21 UTC, Myron Plichota wrote:
> > On Saturday, December 10, 2022 at 1:56:41 PM UTC-5, gnuarm.del...@gmail..com wrote:
> > > Instead of all the crap, why not just answer the question? What is it about the Gowin BSRAM that makes you say, "Semi dual port mode is not a solution to my design problem."
> > 1) You don't appear to have an interest in performing a BugsBoard transplant.
> > 2) Even if you do, you deserve to fail.
> What an ugly character this guy is.
> But the Forth community here has to live him/it until he dies,
> or he gets more direct feedback from others here and leaves to bother other groups that cannot throw him/it out.
>
> A little statistic regardig this post:
>
> 327 people looked at it
> 7 people reacted and posted
>
> So, I think this is a great post of yours, especially when Verilog can be expressed in Forth;
> but for now it might be actually the wrong group to post it in as the reaction shows.

I admit that I opened my mouth on clf while my success was fresh and the proven volume of BugsBoard working code was in its infancy. This was intentional because I had no wish to subject the audience to a dumptruck load of source code, and I wanted to see what flak would result before I proceeded on my merry way. I risked learning something, and I did indeed learn about the proverbial crabs in the bucket.

The pedantic legalist, Lorem Ipsum (signed Rick C.) more or less demanded an essay from me on why I don't recommend his favorite Gowin FPGA for a BugsBoard transplant, and I counter-challenged him to understand the proven Verilog that resulted in actual 1 clock cycle random read access of *synchronous* FPGA RAM proven on Lattice iCE40 and Xilinx Spartan 7 implementations. I noticed on another thread that he, in a rare moment of humility, admitted that he is a VHDL guy, and does not understand Verilog. Yet he declared me to be a troll. (Oh the irony!)

I am inclined towards charity, so I will share with Rick a clue: the Gowin "Semi Dual Port" RAM mode as portrayed in section 3.4.8 of the official datasheet does not suggest a viable solution of ram1c.v because unlike the iCE40 and Spartan 7 datasheets, there is no way to bypass a pipeline register in the read path. Perhaps despite my grasp of iCE40 and Spartan 7 datasheets, Rick will ace me at my own game with something like ram1c.v on the Gowin silicon, and I would love to read of his success in realizing similar clock-by-clock performance in the HDL language of choice. But I am not holding my breath to see the day.

I see 3 persistent efforts to rub Forth programmers' noses in reality:
1) improving virtual machines on 64-bit commodity desktop/laptop hardware
2) improving virtual machines on 16 or 32-bit commodity microcontroller hardware
3) implementing native machines on FPGAs that bypass all of the above

I am of the #3 persuasion, but I have total respect for those persuing #1 and #2.

The opportunity for Forth to take over ze veld is long gone. The C bastards won, and as an admitted acceptor of the aftermath, I have found it expedient to find a way to advance my agenda, even unto resorting to designing hardware in Verilog, and generating code for said hardware using Python3.

Chuck Moore created the original monster, and has inspired me to do my best to bite off chunks that I can chew.

I wish that clf culture relaxed a wee bit and became famous for promoting the merits of fundamental Forth programming precepts.