eForth reborn on a late Christmas Present - a new new born Microprocessor in FPGA

[Jurgen Pitaske]

Dear Ting,

A late Christmas present.

I could convince Steve Teal
to code a microprocessor in VHDL
that I had been carrying around for the last 25 years.

And eForth was implemented by Steve as well.

Together with many tools that Steve did in addition.

He did all of the work, I just supplied what I had from then.

A big THANK YOU to Steve.
See it all on github.


https://github.com/Steve-Teal/eforth-misc16?fbclid=IwAR3J4bW3B0UruEk-_k3J8uzhDp6uX20InJJesv545WFu-gVok14Dd65Nj8Q

misc16-eforth

This project implements eForth on the MISC16, a 16-bit minimal CPU which only has a single instruction 'mov'.
The resources included here:
• Python based MISC16 assembler and simulator
• C based MISC16 simulator
• MISC16 assembly eForth
• VHDL MISC16 CPU core

History of MISC16

The MISC16 project started with an article by Douglas W. Jones:
http://homepage.cs.uiowa.edu/~jones/arch/risc/
Juergen Pintaske saw the article and discussed the approach with his colleagues.
At the time he had visited ARM and ARC in the UK, and this design looked like a “low-cost” ARC,
where additional functions can be easily added memory mapped,
without influencing the rest.
The result was the original hardware version, tested on a CPLD board,
developed in VHDL by Harry Siebert and the Mixed Mode ASIC Design Team.
Some Forth people in Munich were involved later as well after the board was up and running,
mainly Bernd Paysan.
Later on, Juergen Pintaske found out, that this design had been slightly modified at FH Nuremberg
and there then even been implemented as ASIC,
manufactured by AMS as a student project.

Juergen asked Mixed Mode, if this Mixed Mode Design can be published and used elsewhere,
as nobody was using it,
which was granted.

MISC16 Architecture

The MISC16 has a 16-bit address bus,
memory locations 0x0010-0xFFFF can be used for RAM, ROM, and IO,
the first 16 locations are reserved for a memory mapped ALU and Program Counter which implement virtual instructions.
+---------+-------------+------------------+
| Address | Source | Destination |
+---------+-------------+------------------+
| 0x0000 | PC | PC |
| 0x0001 | PC+2 | PC if A < 0 |
| 0x0002 | PC+4 | PC if A = 0 |
| 0x0003 | PC+6 | - |
| 0x0004 | - | PC if C = 1 |
| 0x0005 | - | - |
| 0x0006 | - | - |
| 0x0007 | [A] | [A] |
| 0x0008 | A | A |
| 0x0009 | - | A = A - source |
| 0x000A | - | - |
| 0x000B | - | A = A + source | ADD
| 0x000C | - | A = A xor source | XOR
| 0x000D | - | A = A or source | OR
| 0x000E | - | A = A and source | AND
| 0x000F | - | A = source >> 1 | SHIFT Right
+---------+-------------+------------------+
Program execution begins at address 0x0010,
after which the program counter increments by 2 with each instruction
until it is modified by an instruction whose destination is the program counter (PC).
Reading PC yields the program counter while it’s still pointing to the address of the instruction doing the read,
PC+2 is the next instruction and so on for PC+4 and PC+6.
A is the accumulator which can be used as an index register for indirect addressing.
The accumulator is the destination of the arithmetic and logic operations
and can be used to conditionally load the program counter for conditional jumps.
The carry flag C is also used to conditionally load the PC,
it is modified by the add and subtract instructions, for subtract it becomes borrow.
The carry flag is used in the shift right instruction (0x000F),
here it has the least significant bit of the accumulator shifted into it and its old value shifted into the most significant bit.

Assembler

The Python script 'misc.py' implements a very simple MISC16 assembler; it only understands 5 keywords:
+-----+---------------------------------------+
| mov | Move instruction |
| equ | Assign a constant integer to a symbol |
| db | Define a byte |
| dw | Define a word |
| org | Change current assembler pointer |
+---------------------------------------------+
The assembler uses Python 3.

The following command line will assemble the eForth image,
generating a binary image,
an FPGA memory initialisation file
and a listing file.
python misc.py eforth.asm eforth.bin eforth.lst eforth.mif

The listing file can be viewed with a text editor
and used as an insight into the syntax of the assembly language.

The binary file can be used with the C based simulator
and the .MIF file for using to initialize FPGA block memory with Intel Quartus.
If you don't need all the output files these can be left off and they won't be generated.

Simulator

By not specifying any output files, misc.py will run the simulator after a successful assembly.
A version of the simulator written in C is included;
the source code resides in a single file and can easily be built by gcc or another C compiler.

When compiled, it is run by specifying the binary image on the command line.

misc eforth.bin

License
misc16-eforth is distributed under the terms of the MIT license.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Enjoy
Have a nice rest of the Festive Season
and All the Best for 2022.

Kind regards

Juergen Pintaske

[Rick C]

I have to admit I am getting lazy in my old age. So I'm not willing to do a lot of work to investigate YAMC (Yet Another MISC CPU) without having at least some idea of what this MISC does that the other sixteen thousand eight hundred 'n' twenty one MISC CPUs I've seen don't do or at least does a little bit better. Juergen's description doesn't indicate that and it doesn't provide enough detail to understand how it works. The link to github seems to provide the same text as above which is the readme.md file. I don't actually see a description of the MOV instruction, any indication of the instruction size or coding, word width or the addressable unit size (bytes? words?). It says the PC is incremented by 2 for each instruction, but is that 2 words, 2 bytes??? What exactly does the MOV instruction do?

All files in the repository other than the readme.md file are source code or the license. So I guess someone will need to reverse engineer these files and hopefully produce an architecture and instruction description. Or is all the needed information here and I simply missed it somehow?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

LOL LOL LOL LOL LOL LOL LOL LOL LOL LOL

You are really getting oldas you say.
And your eyes are getting worse as well, so you cannot follow the link to the original Article
Where it is described and as well links to other implementations..

Does it matter?
Not really, as you cannot even read/grasp that this email had been addressed sent toTing.

This was NOT addressed to you.

PLEASE DUMP YOUR SHIT ELSEWHERE and stay out of my posts.

[Rafael Deliano]

> You are really getting oldas you say.

Not only him.

/ The result was the original hardware version, tested on a CPLD board,
/ developed in VHDL by Harry Siebert and the Mixed Mode ASIC
/ Design Team. Some Forth people in Munich were involved
/ later as well after the board was up and running, mainly
/ Bernd Paysan.

Text gave no indication that this was quite some
time ago: 1997 in Munich.
The german Forth-journal VD is still around.
The archive is online:
https://wiki.forth-ev.de/doku.php/vd-archiv

Paysan did an article ( in german ) then:
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>

The Mixed Mode board with the Forth on it was on the Forth e.V.
booth on (small) industry trade fairs like "Echtzeit" and "embedded" then.

On page 38 is a photo of the monthly meeting of the Munich Group
with Paysan:
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
I have none with Pintaske who showed up there sometimes then.

So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
The M in MISC was "minimum RISC", it was low performance.
It did not have much of real world practicality. The Jones-CPU had
no connection to Forth, and only a cross-assembler for software.
Pintaske did sales at Mixed Mode, this was a publicity stunt for the
company. He contacted Forth e.V. to get a HLL for it. Decent software
seemed necessary if it would ever move to the real world.

MfG JRD

[Jurgen Pitaske]

On Tuesday, 28 December 2021 at 09:20:56 UTC, Rafael Deliano wrote:
> > You are really getting old as you say.

> Not only him.
>
> / The result was the original hardware version, tested on a CPLD board,
> / developed in VHDL by Harry Siebert and the Mixed Mode ASIC
> / Design Team. Some Forth people in Munich were involved
> / later as well after the board was up and running, mainly
> / Bernd Paysan.
>
> Text gave no indication that this was quite some
> time ago: 1997 in Munich.

> The German Forth-journal VD is still around.

> The archive is online:
> https://wiki.forth-ev.de/doku.php/vd-archiv
>

> Paysan did an article ( in German ) then:

> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
> Paysan "Gforth auf MISC portiert" <Gforth ported to MISC>
>
> The Mixed Mode board with the Forth on it was on the Forth e.V.
> booth on (small) industry trade fairs like "Echtzeit" and "embedded" then.
>
> On page 38 is a photo of the monthly meeting of the Munich Group
> with Paysan:
> https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
> I have none with Pintaske who showed up there sometimes then.
>
> So then: in 1997 FPGAs were smaller, putting a CPU on them was new.
> The M in MISC was "minimum RISC", it was low performance.
> It did not have much of real world practicality. The Jones-CPU had
> no connection to Forth, and only a cross-assembler for software.
> Pintaske did sales at Mixed Mode, this was a publicity stunt for the
> company. He contacted Forth e.V. to get a HLL for it. Decent software
> seemed necessary if it would ever move to the real world.
>
> MfG JRD

Thank you very much for the additional information, Rafael.
Some of this I had not seen before.
So next week it will be the 25th year then from the first implementation.

And the board was shown on Embedded 97. Brings back nice memories.
This was shortly before I left MM and went to the UK.
There I did a completely different job - so MISC was in the background.

Only 2 slight corrections:

I did not contact contact Forth eV,
but was then part of the Munich Forth Group, and Bernd was there as well.
Actually, if you not not look too closely - it nearly looks like me then.
The guy on the right.
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2007-0304.pdf
page 38

This MISC Project was not just a Publicity Stunt.
We used this project to show/discuss the Mixed Mode capabilities to customers for
----VHDL-Design
----PCB design and
----Software design, with the Assembler as example
To discuss this with our customers
who were interested in IP, and the other design services we provided;
and it nearly made it into ASIC projects at Fraunhofer Stuttgart.
They actually re-wrote the VHDL.

As well I assume that many customers I showed it to,
were a bit too experienced to see it as a publicity stunt.
From then:
Marketing, Market Introduction,
Sales, Contract Design, ASIC Design,
Embedded Software development
for companies in Germany/Austria/Switzerland like:
Ericsson, Infineon, Siemens, SciWorx, TRW ...

[Jurgen Pitaske]

By the way, this project was never planned to attack Intel - neither then nor now.
So performance does not matter really - just is it fast enough for where it is used.
It is an interesting design exercise - and I am happy it is there now;
how small a CPU can be to do something useful
- here actually to run FORTH - another publicity stunt according to the mind set of some people here?

I had posted this MISC information here as it might be of interest to some
- and especially as a Thank You to Steve and Ting.
Without them it would not have been possible.

And it is the second joint activity after The FIG FORTH Manual,
where Steve designed a reduced feature CDP1802 to run the Forth successfully.
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM
And this link to the Forth books is definitely a promotional activity ...

[Rick C]

So did you find any info on the processor architecture like instruction format?

From what is provided, I agree that this CPU seems to have no particular connection to Forth. It is not stack oriented. The only "feature" I can see is that it might be smaller than some other designs. It must have some such advantages because it would be exceedingly slow. I have looked at other such one instruction designs and they require many instructions to accomplish what other designs do in a single instruction.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

+------- --+-------------+------------------+
| Address | Source | Destination |
+------- --+-------------+------------------+
| 0x0000 | ---PC----- | PC------------- |
| 0x0001 | PC+2---- | PC if A < 0 -| DECISIONS
| 0x0002 | PC+4---- | PC if A = 0 -| DECISIONS
| 0x0003 | PC+6---- | - --------------|
| 0x0004 | - ------------|- PC if C = 1 | DECOSIONS
| 0x0005 | - ----------| - --------------|

| 0x0006 | - | - |
| 0x0007 | [A] | [A] |
| 0x0008 | A | A |

| 0x0009 | - ------------| A = A - source --- |
| 0x000A | - -----------| - -------------------------|
| 0x000B | - -----------| A = A + source | ADD
| 0x000C | - -----------| A = A xor source | XOR
| 0x000D | - -----------| A = A or source | OR
| 0x000E | - -----------| A = A and source | AND
| 0x000F | - -----------| A = source >> 1 | SHIFT Right
+-------------+-----------+-----------------------------+

This is all you have.
It was the simplicity that was interesting at the time.
A Microprocessor IP that was easy to build and to explain - a Lattice 1016 or 1032 at the time - now FPGA.
The VHDL code here fits onto 4 pages of paper. Copied it from github
OK, UART and IO not includeed.
Performance was secondary.
At the time in 1997 we called it UPS processor
This 16 bit processor just shifts 16 bit data packages from address A to address B. Or into the ALU.
All of the instructions are here in this list
The ALU is memory mapped as well as you can see.

BUT:
Use 4 of these blocks in parallel, and you have a 64 Bit wide Processor
- address range as required in the application
Add any IO or other functionality - the processor just needs to know the addresses of the memory map.
Or have a few of these small processors on the same FPGA, until you run out of ressources.

And read more here as given in the post above http://homepage.cs.uiowa.edu/~jones/arch/risc/
Example code is there as well.

[Rafael Deliano]

> So did you find any info on the processor architecture like instruction format?

"Hard" information on a "soft" CPU is always tricky. Paysan states in
the article he got from Mixed Mode a simulator "with the then currently
used instruction set". So MixedMode hadn't finalized.
Together with Jens Wilke he did a 3 day(&night) port over the weekend
and sent the Intel-Hex to MixedMode.
They first did a 20 primitive version but came to the conclusion
that even on a Pentium that was to slow. In the article he lists the
47 primitives that were used.

> it would be exceedingly slow.

Paysans Forth is big and was intended for PCs. So it might not be ideal.
On the other hand their usual demo was as fas as i can remember
Tetris VT220 terminal style. Thats what visitors on the
trade fair got to see. It had no serious speed problem.

MfG JRD

[Rafael Deliano]

> By the way, this project was never planned to attack Intel - neither then nor now.

Neither was RTX2000 chosen by Harris to be the fastest RISC. But
with its ASIC-Bus intended for combination with application specific
IO in standard cell design.
The same thing was assumed for FPGA-CPUs: they could never compete on
performance with real CPUs or controllers, but could more tightly couple
to IO. And then be competitive in an narrow application.
It did not turn out that way. FPGAs got bigger, people invented
more complex pseudo-RTX CPUs. Without much thought what would
be a reasonable application for the new toy.

> So performance does not matter really - just is it fast enough for where it is used.

This year the old dutch/german/UK "Elector" magazine had their 60th
anniversary. They fondly remembered their projects with the old
ROM-based Intel 8051 BASIC-controllers. These were slow. Didn't
much bother the people that used them. They were cheap & easy
to use, thats what was relevant.

One could probably exhume the MISC16 for magazines like (the german)
MAKE: or Elector in combination with an application like "multiple motor
controller for robot programmable in HLL language" that is implemented
on the same FPGA.

MfG JRD

[Rick C]

Lol. I don't know what it takes to run Tetris. I would not use such a demo to evaluate a soft CPU in an FPGA. I use soft CPU cores for management of operations on a chip which is high speed, real time. Responding to a key press is not the sort of application I would be looking for a soft core to handle. No offense intended.

J. seems to think the table in the documentation of the functions connected to the first 16 locations in memory are adequate documentation. But these locations are accessed by the MOV command which is not documented at all that I can see. Do you know how the MOV command is structured? With a 16 bit address it would seem cumbersome to include a source and destination, but maybe that's all the instruction is, a pair of addresses?

Who knows? Without basic info like I've already pointed out is lacking (like data word size and whether the address is byte or word oriented) it's hard to know how this thing works.

I'm curious, but not enough to put a bunch of effort into reverse engineering it. I'm certainly not going to try to get J. to calm down enough to discuss it. I have no idea why he has to fly off the handle so easily. He really comes across as a loon when he is like that. The worst is when he's arguing with Hugh or that Peter Forth guy whatever his real name is. Talk about loons, that guy really takes the cake!

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

As I said higher up
- read tghe fucking documentation and SW examples - else please keep your mouth shut and dump elsewhere.

[Rick C]

On Tuesday, December 28, 2021 at 11:42:50 AM UTC-5, Rafael Deliano wrote:
> > By the way, this project was never planned to attack Intel - neither then nor now.
> Neither was RTX2000 chosen by Harris to be the fastest RISC. But
> with its ASIC-Bus intended for combination with application specific
> IO in standard cell design.
> The same thing was assumed for FPGA-CPUs: they could never compete on
> performance with real CPUs or controllers, but could more tightly couple
> to IO.

Not sure what that means. FPGA based CPUs can run very fast. More importantly, they can be designed to run as fast as required and not faster wasting resources. They are typically much less expensive than a separate CPU as they are mostly used when an FPGA is already in the design. The other advantage is they can be added in whatever quantity might work best. I have assigned an entire CPU to one task to make sure it meets the timing requirements.

> And then be competitive in an narrow application.
> It did not turn out that way. FPGAs got bigger, people invented
> more complex pseudo-RTX CPUs. Without much thought what would
> be a reasonable application for the new toy.
> > So performance does not matter really - just is it fast enough for where it is used.

That is absolutely true. But if you have a slower design it suits fewer design applications.

> This year the old dutch/german/UK "Elector" magazine had their 60th
> anniversary. They fondly remembered their projects with the old
> ROM-based Intel 8051 BASIC-controllers. These were slow. Didn't
> much bother the people that used them. They were cheap & easy
> to use, thats what was relevant.

Yup. They were used for many things. Soft cores in FPGAs don't necessarily need to be "fast", just fast enough. But that's a moving target and if your only advantage is size but a much faster design is only slightly larger, which design do you think will fit more applications? If you are going to the effort of designing a soft core CPU, why spend time messing with a design that will only be optimal in a small number of apps? That sounds like the GA144 approach. Do one thing really well and see if anyone finds a use for it.

This design hasn't been measured for size has it? How many 4 input LUTs and FFs does it use?

> One could probably exhume the MISC16 for magazines like (the german)
> MAKE: or Elector in combination with an application like "multiple motor
> controller for robot programmable in HLL language" that is implemented
> on the same FPGA.

Ok

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

On Tuesday, 28 December 2021 at 16:00:42 UTC, Rafael Deliano wrote:
> > So did you find any info on the processor architecture like instruction format?
> "Hard" information on a "soft" CPU is always tricky.

Paysan states in
> the article he got from Mixed Mode a simulator "with the then currently
> used instruction set". So MixedMode hadn't finalized.

This is wrong and you should know it if you were involved
- otherwise you just try to interpret the article

> Together with Jens Wilke he did a 3 day(&night) port over the weekend
> and sent the Intel-Hex to MixedMode.

This whole port activity had nothing to do with the original design and with Mixed Mode.
The port of Forth was never used / demonstrated later,
as long as I worked there.
So it was a private student exercise who wanted to know if they can replicate what worked already..

How well it worked and how many bugs might have been still in there - nobody knows.
But it was not relevant.

> They first did a 20 primitive version but came to the conclusion
> that even on a Pentium that was to slow. In the article he lists the
> 47 primitives that were used.
> > it would be exceedingly slow.
> Paysans Forth is big and was intended for PCs. So it might not be ideal.

Why do you not say it: it was too bloated for such a little processor.
So, a bad choice on Bernd's side to start with this package in the first place.
Funnily enough, It now seems to run eForth well enough as the video shows.

> On the other hand their usual demo was as fas as i can remember
> Tetris VT220 terminal style. Thats what visitors on the
> trade fair got to see.

> It had no serious speed problem.

Either there were speed problems or not
- or are you making this up after 25 years to make MM look bad??

As a summary: I do not like your negativity.
Mixed Mode and the 2 other companies were about 30 SW and HW designers at the time
- they knew what they were doing.
And finished the design as far as needed for this IP Demo Project.

Now to say that a couple of students - using a language that nobody at MM had experience with -
did not work as it should is a bit far fetched.
>
> MfG JRD

[Marcel Hendrix]

On Tuesday, December 28, 2021 at 5:42:50 PM UTC+1, Rafael Deliano wrote:
> Neither was RTX2000 chosen by Harris to be the fastest RISC.

Well, at the time I was a student still, and I remember quite vividly that
I believed (for some reason) that the RTX2000 was the fastest processor
around. I bought a development board but was not impressed.
Of course, in that before-the-internet era it was very difficult to get
essential documentation and access critical benchmarks. We had to make
do with Jeff Fox's interpretations of CM's personal communications.
Of course, all that has radically changed for the good.

-marcel

[Rafael Deliano]

>> he got from Mixed Mode a simulator "with the then currently
>> used instruction set". So MixedMode hadn't finalized.

> This is wrong and you should know it if you were involved
> - otherwise you just try to interpret the article

I stated whats written in the article and how Paysan saw it then.

> The port of Forth was never used / demonstrated later,
> as long as I worked there.

It was unpaid, semiofficial. I, Wilke and Paysan did a visit
to MixedMode to say hello to the R&D staff there and have a short
meeting about what to do. The board/HW was loaned by the company
and later returned. The top brass of the company wasn't involved.

>> Paysans Forth is big and was intended for PCs.

> Why do you not say it: it was too bloated for such a little processor.

Paysan was by then probably working at the university at his own
stackprocessor-project and therefore interested enough to do
a port. Since it was unpaid you had to take what was on offer.
And since you got results fast and good enough to demo there
is no reason to complain.

>> Tetris ... It had no serious speed problem.

> Either there were speed problems or not
> - or are you making this up after 25 years to make MM look bad??

There were obviously no detailed requirements by MixedMode on
performance. For Paysan as soon as Tetris was running decently
he considered a port stable and the job done.

> As a summary: I do not like your negativity.
> Mixed Mode and the 2 other companies were about 30 SW and HW designers at the time
> - they knew what they were doing.
> And finished the design as far as needed for this IP Demo Project.

It was your pet-project and may have had some backing with the R&D staff
at MixedMode. It had much less backing from the bean-counters at the top
of the company as it was unclear how ever to earn money with it.
I am not making this up: your words then before you left for UK.
I have a bloody good memory.

Much as Rick now i had then problems understanding how that thing works.
Paysan had to explain it me and i have long since forgotten.
So Paysans Forth may have been the high point concerning software
then. There was never any talk of MixedMode doing a C-compiler.
It is highly unreasonable to expect a customer micro-coding in assembler
with that instructions set any real world
application. Even if some sort of macro-assembler would have
been available: there is a tradeoff in size of the CPU and
code-density. Usually a very unfavourable one.

MfG JRD

[Jurgen Pitaske]

As it seems you know the MM organisation better than me - I give up.
And it actually does not matter.
And if you do not understand this processor, this does not matter either.
This project has achieved what was planned then.
It would have been nice to achieve more then - but there we are.

Steve seems to understand the processor very well
and as well knows what he is doing
in rebuilding the VHDL
and adapting the eForth to run.
And an Assembler.
You might not know - but Assembler is still used nowadays where required.

Success in all areas - but I am sure you find negative aspects here as well.
I am grateful for all of Steve's efforts to bring this processor back to life.
Basically the second processor he coded in VHDL for me.
How useful is MISC now?
We will find out over time.
This is not for money or business.
This is for fun - and this has been achieved.
Actually 2 times - then and now.

[Jurgen Pitaske]

It seems Professor Emeritus Douglas Jones
who wrote the article in the first place,
did like the implementation Steve did,
and added a comment in his article based on my email to him.

https://homepage.cs.uiowa.edu/~jones/arch/risc/

In late December 2021,
Juergen Pintaske pointed me at Steve Teal's VHDL implementation
of Juergen's MISC16 variant on the Ulitmate RISC.
This has a slightly closer coupling between the move engine and the ALU,
enough that you can just call the two of them a CPU,
and it has been manufactured as an ASIC.
An eForth interpreter has been written for it,
so it can actually be used with an (arguably) high-level language.
The whole project, including VHDL code,
the eForth interpreter in assembly,
a cross assembler writtein in Python
and a C emulator for MISC16
is available on Github.

[Rick C]

On Saturday, January 1, 2022 at 2:37:21 AM UTC-5, jpit...@gmail.com wrote:
> It seems Professor Emeritus Douglas Jones
> who wrote the article in the first place,
> did like the implementation Steve did,
> and added a comment in his article based on my email to him.
>
> https://homepage.cs.uiowa.edu/~jones/arch/risc/
>
> In late December 2021,
> Juergen Pintaske pointed me at Steve Teal's VHDL implementation
> of Juergen's MISC16 variant on the Ulitmate RISC.
> This has a slightly closer coupling between the move engine and the ALU,
> enough that you can just call the two of them a CPU,
> and it has been manufactured as an ASIC.
> An eForth interpreter has been written for it,
> so it can actually be used with an (arguably) high-level language.
> The whole project, including VHDL code,
> the eForth interpreter in assembly,
> a cross assembler writtein in Python
> and a C emulator for MISC16
> is available on Github.

Sounds great. Now to get significant numbers of people to adopt it just requires appropriate documentation. That was a big failure of the GA144. Tools were written, but with little documentation.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

The project for 2022.

[Rick C]

Ok. Great. What is the purpose of this MISC CPU? I don't recall just how small it is. Is there a LUT4 count? We can provide it to Jim Brakefield to add to his data on soft CPUs. He doesn't require source code, but I think he is willing to evaluate designs if they are provided. I'm not sure if he does any testing other than compiling to see how many LUTs it uses and likely looks at the code to see the clocks/instruction, etc., but I'm not sure. I didn't look. Does this design have a test bench?

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[James Brakefield]

Move processors are rare. This one has only 10 move operations
(conditional branches counted as one instruction).

Ugh, the design is a bare core: no block RAM for memory.

I used Vivado and the fastest part with free tools: xczu3cg-sfvc784-2-e
And added a clock constraint file.
Will place and route with a clock speed greater than 500MHz.
Uses ~197 LUT6 and ~78 DFF.
Normal MIPS/instruction for 16-biitter is 0.67.
In this case reduced MIPS/inst to 0.22 yielding a KIPS/LUT of 558.
(a move processor requires many loads and stores than normal cpu)

Steve Teal in his 1802-pico-basic design included the block RAM,
so, would encourage him to do likewise here.
Would result in a more meaningful Fmax.

[Jurgen Pitaske]

Thank you very much for your testing and feedback, I will forward to Steve.
I started this MISC16 as a fun project again to see what can be achieved now.
Steve kindly helped to bring it back to life again and now in FPGA.
As said before, where it ends and how useful it is we will see.
Probably depends on the application.
As said as well, it is a fun project - so actual performance is secondary.
And I only posted it here,
as Steve went through the work
to adapt an eForth with all of the coding details on github for people who are interested.
As Steve has proven, this core is fast enough to run a Forth.
Or the other way around: this eForth could be adapted to run on a custom microprocessor
with very minimal ressources, as you stated:

[Ilya Tarasov]

> Ugh, the design is a bare core: no block RAM for memory.
>
> I used Vivado and the fastest part with free tools: xczu3cg-sfvc784-2-e
> And added a clock constraint file.
> Will place and route with a clock speed greater than 500MHz.
> Uses ~197 LUT6 and ~78 DFF.
> Normal MIPS/instruction for 16-biitter is 0.67.
> In this case reduced MIPS/inst to 0.22 yielding a KIPS/LUT of 558.
> (a move processor requires many loads and stores than normal cpu)
>
> Steve Teal in his 1802-pico-basic design included the block RAM,
> so, would encourage him to do likewise here.
> Would result in a more meaningful Fmax.

It seems almost everything has gone due to synthesizer optimization.
Nothing unusual for newbies. 78 DFFs means almost all register were collapsed
because they are unused at all with current schematic. Block RAM is required, and
second port is required too. 500 MHz is non-realistic.

Zynq UltraScale+ is a large FPGA with 100k+ cells. What do you expect to achieve with
0.5% of resources used? :)

[James Brakefield]

Ran Steve Teal's other design: pumpkin.
It has program and instruction memory.
For small programs Vivado will use LUT RAM instead of block RAM.
For hello_world_top as top, result was 166 LUTs and 67 DFF.
With myco as top, Vivado still preferred LUT RAM
So forced use of block RAM giving 230 LUTs, 131 DFF and half of a block RAM.
hello_world came in at 625 MHz and myco came in at 450 MHz.

mrisc16 and pumpkin both have small instruction sets which typically results in great Fmax.
For larger designs and larger ISAs and additional memory address modes
these numbers will shrink considerably, to say nothing of adding IO or SOC IP.

I run Zynq UltraScale+ because high Fmax is more fun.
(and am trying to rerun all the designs to get a more uniform comparison)
Artix-7 and Spartan-7 are much more affordable. And will use about the same
numbers of DFF and LUTs for a given design.
Expect Fmax to be 33% lower, after all Artix is 28nm and UltraScale is 16nm.

Arria-2 is the fastest Intel family with free tools.
Intel Cyclone V also has free tools and also has the equivalent of 6LUTs.
LUT4 families typically use 50% more LUTs than LUT6 devices.

Using modern FPGA family parts 200MHz operation should be possible.
Coding style and design complexity have a big influence on Fmax.
Also, DFF numbers should be taken with a grain of salt.
The tools will use additional DFF to improve timing by relaying signals closer to their loads.
In other cases a family will not support LUT RAM due to set/reset operation and
will convert small RAMs to a mass of DFF and multiplexers.

I started this project to find the best or most efficient processors.
At 1K LUTs to the dollar and with many designs using less than 1K LUTs,
and with operation at, say, 200MHz there is considerable opportunity
for small memory custom processors.

[Jurgen Pitaske]

I forwarded it all to Steve,
and he asked if you have had a look at his latest core published already and have some feedback there as well - 6502 :
https://github.com/Steve-Teal/mx65?fbclid=IwAR3PEvSKxA4M5wmeUB7BLl_wYsBF4LHSDezWjLBVzv-aSDYvXIHLradREE0

[James Brakefield]

Yes, ran mx65 into zynq UltraScale+
485 LUTs, 148 Dff, 1.5 Block RAM, 370 MHz
485 LUTs is on the low side for 6502 designs, although not the only 6502 design in that range.
https://github.com/jimbrake/cpu_soft_cores uP_by_style_210618.pdf has the 6502 cores grouped together

[Jurgen Pitaske]

Thank you very much James, forwarded to Steve already.

[Ilya Tarasov]

> I started this project to find the best or most efficient processors.
> At 1K LUTs to the dollar and with many designs using less than 1K LUTs,
> and with operation at, say, 200MHz there is considerable opportunity
> for small memory custom processors.

Can you describe why do you need this core and what is it's purpose in your system(s)?
Without understanding system-level goals you may play with old CPU cores for a long
time, with no valuable results.

Try a simple thing - delete all outputs in your module. Check it's size will be zero cells,
because with no outputs connected no cells are required to drive missing outputs. Continue
with higher level - with no peripherals connected all core activity becomes useless. With no
stated goals you may reproduce 6502, 8051, Z80, 8086 or anything else - having no goals
to achieve you cannot compare your project vs missing goals.

[James Brakefield]

The spreadsheet (all 45 columns and ~900 rows) is a collection, and I add to the collection frequently.
Try to avoid too many redundant designs, so "educational" designs with less than 16 instructions,
MIPS designs and RISC-V designs often don't make the cut.
In this case, was curious about it supporting Forth and what kind of design it was.
Then looked at Steve Teal's other designs and was impressed with his VHDL style.

|> ...delete all outputs in your module...

This may surprise some, that with no outputs, a design can and will be reduced to zero LUTs.
Added a column to the spreadsheet to indicate a "SOC" or design with peripherals.
Also have column to indicate the top file of the design.
And columns for number of instructions and number of addressing modes.
The intent is to provide others with a means to narrow their focus.
Keeping the spreadsheet current in all its columns is beyond my patience.
Will update the github files with current spreadsheet and sheet PDFs.

My personal goals are to implement a variety of architectures with a uniform style
in order to properly evaluate performance, resource utilization and code density.
For instance a 24-bit and up instruction RISC design and
a 16-bit and up instruction stack/accumulator design.

Judging by your publications and Xcell article we have similar interests.

[Rick C]

Not everyone designs CPUs purely for profit. Many see this as an exercise and a hobby... or are just a bit obsessed.

I do agree that CPUs are best designed with specific goals in mind. The absolute smallest CPU is not of much value unless it is capable of doing the work required. If you don't know what that work is, there's no way to know if the design is useful, as you said.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

[Ilya Tarasov]

> |> Can you describe why do you need this core and what is it's purpose in your system(s)?
> The spreadsheet (all 45 columns and ~900 rows) is a collection, and I add to the collection frequently.
> Try to avoid too many redundant designs, so "educational" designs with less than 16 instructions,
> MIPS designs and RISC-V designs often don't make the cut.
> In this case, was curious about it supporting Forth and what kind of design it was.
> Then looked at Steve Teal's other designs and was impressed with his VHDL style.

Well, it seems this is a kind of collection/overview. If you have so many designs in your collection, did
you try to analyze it? Why do you highlighting one design, if so many are possible to implement?

> |> ...delete all outputs in your module...
>
> This may surprise some, that with no outputs, a design can and will be reduced to zero LUTs.
> Added a column to the spreadsheet to indicate a "SOC" or design with peripherals.
> Also have column to indicate the top file of the design.
> And columns for number of instructions and number of addressing modes.
> The intent is to provide others with a means to narrow their focus.
> Keeping the spreadsheet current in all its columns is beyond my patience.
> Will update the github files with current spreadsheet and sheet PDFs.

...

> My personal goals are to implement a variety of architectures with a uniform style
> in order to properly evaluate performance, resource utilization and code density.

Why don't you try to write it by yourself? What is the reason to search designs in github?

> For instance a 24-bit and up instruction RISC design and
> a 16-bit and up instruction stack/accumulator design.
>
> Judging by your publications and Xcell article we have similar interests.

Yes, and Xcell was long time ago. I feel no troubles to use proper CPU in proper case.
Yes, I have an uniform approach to create 2-, 3- and 5-stage CPU with stack, 1-address,
2-address, 3-address (and even VLIW) microarchitectures. This is not an issue. More
important is to provide mutual co-optimization and support system-level tasks.

[Jurgen Pitaske]

Well, for the CPU in question in this thread that I started here, this goal has been achieved.
it is very small - goal achieved - useful
connected via UART - goal achieved - useful
connectable via IOs - goal achieved - useful
Plus has an eForth - had not been planned but works - more than goal achieved - useful

[Wayne morellini]

Marcell, the previous Novix was said to be fastest at the time. I forget how this works out, as the first Arm computer was says to be fastest, maybe latter. They were both compared to Vax mini computers

[Marcel Hendrix]

The VAX was already ancient at that time, but comparing
with VAX-MIPS was popular at that time, yes.

The Novix certainly had impressive *real-time* performance.
I connected a floppy controller chip, a software 1-bit ADC,
and a 14-bit serial DAC to it (wire-wrapping was still possible
in those days :-). These I could indeed control using high-level
Forth. I wrote the project up up as a telephone-answering
machine for an MPE real-time contest but it got ignored.
I have to agree that the commercial potential of my entry
sucked rocks.

After the answering machine my Novix interest waned.
I wanted high performance audio and video, but the
needed peripherals were too expensive for me at the
time. The video camera that I connected to the Novix
board never worked properly because it could not
generate jitter-free sync signals in high-level Forth.
Or maybe it could, but I did not have a proper
oscilloscope to debug it.

At that time I was much more impressed by the transputer
(now *that* was a really visionary chip) and the 68000.
The fact that these had FPUs, supported vast amounts
of RAM, and were supported by a useful OS, was more
appealing than real-time performance that I could not
put to proper use.

-marcel

[Rick C]

I never figured out if the Transputer was really a great chip or just a weird idea. I saw one fairly large project that used it, government stuff in fact. But they programmed it in C rather than Occam. They used it as intended with a network of nodes scattered through the system.

The only real problem I saw was that INMOS didn't pursue the usual path of integrating peripherals onto an MCU type of device, rather they were designing a much more powerful CPU that had all the fancy features of pipelining and parallelism, the T9000. But it was too large a bite for them to chew and the company ran out of funds, so they killed the project. At least that's the story I recall from, what? 30 years ago? I still have one of their boards somewhere that plugs in an ISA slot. Too bad I don't have an ISA slot anymore. lol

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

[Anton Ertl]

Marcel Hendrix <m...@iae.nl> writes:
>On Friday, January 28, 2022 at 7:31:32 PM UTC+1, Wayne morellini wrote:
>> Marcell, the previous Novix was said to be fastest at
>> the time. I forget how this works out, as the first Arm
>> computer was says to be fastest, maybe latter. They
>> were both compared to Vax mini computers
>
>The VAX was already ancient at that time, but comparing
>with VAX-MIPS was popular at that time, yes.

The VAX 11/780 was the yardstick to compare with long after the Novix
was introduced in 1985. E.g., the first SPEC benchmark in 1989, later
called SPEC CPU89 was scaled such that the VAX 11/780 produced a
rating of 1.

The VAX 11/780 was also considered to be a fast machine for quite a
long time (by later standards); it took until the introduction of the
VAX 8600 in 1984 (6 years after the VAX 11/780) until a faster VAX
appeared (the 8600 was twice as fast). This was before the extremely
fast clock speed advances that CMOS saw from the late 1980s to the
early 2000s.

However, the VAX 11/780 had a 5MHz clock, with an instruction
typically taking 10 cycles. The ARM1 ran at 6MHz, with an instruction
typically taking 1 or 2 cycles; it needed to execute more instructions
for the same program, but the end result was still a lot faster than
the VAX 11/780. Of course, speed is not everything, as you can see by
the fact that VAXes still were bought, even though they were much more
expensive than an ARM Archimedes.

The Novix 4016 ran at 7.5MHz, and also took 1 or two cycles per
instruction, and I expect that it performed similarly to the ARM1 on
16-bit data.

>At that time I was much more impressed by the transputer
>(now *that* was a really visionary chip) and the 68000.
>The fact that these had FPUs, supported vast amounts
>of RAM, and were supported by a useful OS, was more
>appealing than real-time performance that I could not
>put to proper use.

Yes, real-time performance is not everything, either.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

[Wayne morellini]

The high-speed claim was probably from mixing it up with the previous novix introduction. The problem with the novice is, except for embedded, it was really something you competed against 8 or 16 bits up to the 8086 use. A thirty two bit version cell with extra cell peripheral circuits, fpu etc, was really needed for adaption against 386+, ARM, 680x0. Even if it was 32 bit internal data with external 16 bit bus and words, just to slot in with other external chips in use. They were off to a good start, until the money issue (who was that?) which stuffed things around long enough to let the market pull ahead. His 32 bit original shboom, would have been great, and potential against the trabsputer, except, at the time, it was typed to the apollo workstation take over bid, which ultimately HP won, I think, to get technology to use in the power PC. The entire industry was stuffed up, going the x86 instead of forth, and the of 396 instead of arm. All these years latter, Arm is the natural successor that should have won them back then (they were going to take on the PC, but likely, the industry resisted). In those days, often it was either Chuck or Arm with the superior processor concept (the shboom and the strong arm, were both leaders, but the shboom 1 never got out). When I met Chuck, he was starting to talk about 21 bits then, and that just instantly set alarm bells off, as you had to match the concepts and hardware around the chip. Sure enough, programmers and system developers did not line up. But, what does somebody who gets it right know!? I mean. It often goes wrong for me as well, but often not by my own doing. The concept of the novice was inferior to the misc as well. Misc could have come along in the 1970's 8 bit era, and dominated over the top of them, hi bong it a chance to be naturally developed similar to the x86 series got. It's all natural business play, but not many have that ability, replacing it with the ability to successfully manage businesses into the ground. So, we got no forth or MISC revolution, not least because of the incompetency of the industry, who kept on backing the horse that held them back (x86, power pc, mips, over arm and forth CPU's, diverting develent away from them). Of the whole crowd, the Acorn Arm made natural progress despite being held back, and Intel did to, because of the industry incompetence.

Anyway, the rtx was basically a strong correlation with forth code, and multiple operation per second. So, it would be done in forth, if it could be done, but a colour video feed at SD frame size at 30fps through a 16 bit frame grab word, would be somewhere over 21 MB/s, plus timing padding even higher speed rates. Meaning over 10mhz of CPU bandwidth just to access the data, meaning preferably 100mhz+ CPU speed, Even grabbing a double packed 8 bit pixels, you still would want 100mhz plus to do useful things to them. I imagine you were using a 1/4 VGA camera? Very ambitious, what we're you trying to do with them?

[Kerr-Mudd, John]

All this deserves an airing in afc, IMHO (xpost added).

--
Bah, and indeed Humbug.

[Rick C]

On Saturday, January 29, 2022 at 9:02:48 AM UTC-4, Kerr-Mudd, John wrote:
> All this deserves an airing in afc, IMHO (xpost added).

Hmmmm... AFC...

American Football Conference

Automatic Frequency Control

Anti-Friction Coating

Adult Foster Care

Assistant Fire Chief

Anti-Fog Coated

Audit and Finance Committee
.
.
.

Ok, I give up. What does AFC mean?

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

[Kerr-Mudd, John]

On Sat, 29 Jan 2022 05:19:55 -0800 (PST)
Rick C <gnuarm.del...@gmail.com> wrote:

> On Saturday, January 29, 2022 at 9:02:48 AM UTC-4, Kerr-Mudd, John wrote:
> > All this deserves an airing in afc, IMHO (xpost added).
>
> Hmmmm... AFC...
>
> American Football Conference
>
> Automatic Frequency Control
>
> Anti-Friction Coating
>
> Adult Foster Care
>
> Assistant Fire Chief
>
> Anti-Fog Coated
>
> Audit and Finance Committee
> .
> .
> .
>
> Ok, I give up. What does AFC mean?
>

THe clue was in the name of the xposted NG that you've dropped:

news:alt.folklore.computers.

[Rick C]

Yeah, I don't know how I missed understanding this stood for a group I've never heard of.

Anyway, at least your post makes sense now.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

[Wayne morellini]

On Saturday, January 29, 2022 at 11:02:48 PM UTC+10, Kerr-Mudd, John wrote:
> On Sat, 29 Jan 2022 04:44:34 -0800 (PST)
> Wayne morellini <waynemo...@gmail.com> wrote:
>
> > On Saturday, January 29, 2022 at 10:11:29 AM UTC+10, Marcel Hendrix wrote:
> > > On Friday, January 28, 2022 at 7:31:32 PM UTC+1, Wayne morellini wrote:
> > > > On Wednesday, December 29, 2021 at 5:28:29 AM UTC+10, Marcel Hendrix wrote:
> > > > > On Tuesday, December 28, 2021 at 5:42:50 PM UTC+1, Rafael Deliano wrote:

..

> All this deserves an airing in afc, IMHO (xpost added).

What is news:alt.folklore.computers about? I can't find a faq on it. Alternative facts or alternative history?

I see this thread over there already. A bit of disgruntled: 'this is how things could have been' post, doesn't really deserve a such a thread. It's gone. It was bad, a pity! What are we going do now, surely the industry is not going repeat the same mistakes by ignoring solutions by people? I am being ironic. We are decades behind where we should be, and thousands of years as a race. But, that's people.

[Kerr-Mudd, John]

On Sat, 29 Jan 2022 06:57:41 -0800 (PST)

Wayne morellini <waynemo...@gmail.com> wrote:

> On Saturday, January 29, 2022 at 11:02:48 PM UTC+10, Kerr-Mudd, John wrote:
> > On Sat, 29 Jan 2022 04:44:34 -0800 (PST)
> > Wayne morellini <waynemo...@gmail.com> wrote:
> >
> > > On Saturday, January 29, 2022 at 10:11:29 AM UTC+10, Marcel Hendrix wrote:
> > > > On Friday, January 28, 2022 at 7:31:32 PM UTC+1, Wayne morellini wrote:
> > > > > On Wednesday, December 29, 2021 at 5:28:29 AM UTC+10, Marcel Hendrix wrote:
> > > > > > On Tuesday, December 28, 2021 at 5:42:50 PM UTC+1, Rafael Deliano wrote:
>
> ..
>
> > All this deserves an airing in afc, IMHO (xpost added).
>
>
> What is news:alt.folklore.computers about? I can't find a faq on it. Alternative facts or alternative history?

Just old guys reminiscing about computers/ processors. That's what seems to be happening here too.
Never mind.

> I see this thread over there already. A bit of disgruntled: 'this is how things could have been' post, doesn't really deserve a such a thread. It's gone. It was bad, a pity! What are we going do now, surely the industry is not going repeat the same mistakes by ignoring solutions by people? I am being ironic. We are decades behind where we should be, and thousands of years as a race. But, that's people.

[Jurgen Pitaske]

Dumping your Humbug wherever you are ?

You are probably just one of these old guys there
reminiscing about computers/ processors as you say.

Piss off and stay out of my thread if you cannot contribute something useful.
Start your own thread if you can.

[Rick C]

John, you had better listen to him. He means business and isn't going to mess around. He will gather personal info on you and threaten to post it publicly. Hmmm... Isn't that called blackmail?

There are some real loons in this group. Far more than the average, even in newsgroups, and that says something.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

[Wayne morellini]

On Sunday, January 30, 2022 at 7:56:12 AM UTC+10, gnuarm.del...@gmail.com wrote:
> On Saturday, January 29, 2022 at 3:40:53 PM UTC-5, jpit...@gmail.com wrote:

> > On Saturday, 29 January 2022 at 20:28:38 UTC, Kerr-Mudd, John wrote: l

..

> > > --
> > > Bah, and indeed Humbug.
> > Dumping your Humbug wherever you are ?
> >
> > You are probably just one of these old guys there
> > reminiscing about computers/ processors as you say.
> >
> > Piss off and stay out of my thread if you cannot contribute something useful.
> > Start your own thread if you can.
> John, you had better listen to him. He means business and isn't going to mess around. He will gather personal info on you and threaten to post it publicly. Hmmm... Isn't that called blackmail?
>
> There are some real loons in this group. Far more than the average, even in newsgroups, and that says something.
>
> --
>
> Rick C.
>
> --- Get 1,000 miles of free Supercharging
> --- Tesla referral code - https://ts.la/richard11209

Rick you were the one talking to him, and he has some really weird email address. Are you Mudd Rick?

I don't know if what Juergen is saying is blackmail, it's public knowledge, but you certainly have suddenly been trying to find ways to discourage him, and modified your behaviour. I wouldn't be casting stones. Of I looked back in history before, they were followed around, would I find a few people acting differently? These are people who contributed their own bit worthy of respect. But, are hassled by people determined to deliver nothing but hassle. One can't take such people following around seriously. 90% less rubbish without the following around.

Thank you Rick Richard Collins, Arius.

[Jurgen Pitaske]

Well, they are it seems so old, that they have forgotten the definition and what consequences are.
Blackmail is if you want to get paid not to relase something.
It is all open in the public domain here already - and spread anyway.

Just as a benefit for them, as they seem not to grasp what they say, what google said:

demand money or another benefit from (someone)
in return for not revealing compromising or damaging information about them.
"they use this fact to blackmail him, trying to force him to vote for their candidate"

[Rick C]

Wayne, this is not the first time you have responded to my post intended to another. I would like you to cease your harassment. You have no need to communicate with me other than to disrupt my use of this group. Please stop it.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

[Kerr-Mudd, John]

On Sun, 30 Jan 2022 03:10:37 -0800 (PST)
Rick C <gnuarm.del...@gmail.com> wrote:

> On Saturday, January 29, 2022 at 10:42:15 PM UTC-5, Wayne morellini wrote:
> > On Sunday, January 30, 2022 at 7:56:12 AM UTC+10, gnuarm.del...@gmail.com wrote:
> > > On Saturday, January 29, 2022 at 3:40:53 PM UTC-5, jpit...@gmail.com wrote:
> > > > On Saturday, 29 January 2022 at 20:28:38 UTC, Kerr-Mudd, John wrote: l
> >
> > ..
> > > > > --
> > > > > Bah, and indeed Humbug.
> > > > Dumping your Humbug wherever you are ?
> > > >
> > > > You are probably just one of these old guys there
> > > > reminiscing about computers/ processors as you say.
> > > >
> > > > Piss off and stay out of my thread if you cannot contribute something useful.

Sure. I just thought (foolishly) there'd be something in common. Bye.

[Wayne morellini]

I'm sorry Rick, but you don't get to pretend to blame somebody else yet again, like it's not what you have done, and try to act like me doing it, which I've seen you do a number of times, and demand. You don't get to spray aserrations around that others here are "loons" after you have been involved in that, you still have a sign on you about past actions. But, you post this, instead of confirming you are not this new character who you were engaging, who parachuted in out of nowhere. You surely see, how this might appear a bit strange timing, and considering the past, it might be productive to confirm it's not a gag.

I'm happy to engage Mudd, if he is real. But, I'm just going to reply to him, about matters you normally would pick out.

[Rick C]

Yeah, there are crazies here for sure. Say something relatively innocent and they can take offense and go to war.

People wonder why newsgroups are not very popular anymore. There are moderated places to have technical discussions where people aren't allowed to say things like, "Piss off and stay out of my thread..."

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

[Wayne morellini]

John. I think it was that your post was very cryptic, and I still don't know where ever the other group is about things which is supposed to have happened behind scenes, alternative history revision (such as "what if") or making fun. If it is "what if" and one could post over there, I might be interested in posting, but enough has been said.

P.S. If you're not Rick, my apologies, I don't mean to offend. It's just a truck load of history, and the timing was just a bit close to other events by an overactive poster.

Thanks.

[Wayne morellini]

Oh good grief! All innocent and nice again. Notice how many of us act in regard to others where ever it suites us or not?

[Jurgen Pitaske]

The Idiots Guide to Groups and Communities:

In moderated places you would not dare to be as agressive as you can here.
As result people would not have to throw your shit back at you.

You might not undestand this anymore,
that talking is to transmit to a receiving end or a group..
If they do not like what you say they will react - you had not prepared it well.

If you do not aim at the group what you say,
please write it onto a piece of toilet paper in the process and down it goes ...
Nobody can be offended - but you got rid of it.

[Rick C]

I have tried to explain to you many times, in many threads, that your "throwing shit back at people" is still "throwing shit" and makes you look every bit as bad as those you claim are attacking you.

The weird thing is you have gotten much more aggressive with this idea and perceive that someone is "throwing shit" at you from every little thing. Your response is on a hair trigger, as it were. What you think is an appropriate response is not at all appropriate. It is not proportional. It is very much out of line by social norms.

This is why I think you are off your rails. If you dealt with customers in a manner remotely like this, it is no wonder you are no longer in that sort of position. I have to wonder if you are in the same camp as Hugh and some of the others you spend your time "throwing shit" with. I do think of Hugh as being mentally ill. There's no other way to explain his irrational hatred of Elizabeth Rather and the persecution he perceives from nearly every one here. I would ask you to take a look at yourself, but I've tried that before when your hatred was directed at others and you would not, so I have no reason to think you would now that your hatred is directed at me.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

Who do you think you are to try to teach others about behaviour ?????

Social behaviour is not your strength as you have shown in many places here.

If I have the time I will do a nice PDF collection for download for others to enjoy ( or not).
And your behaviour started this discussion here
and you caused it,
and you know it.

And as I said before:

Piss off and stay out of my threads.
You know what happens if you get agressive here.
It seems you have nothing else to do.
It is your standard behaviour and you love it.

And again, as it seems you have not grasped it:

[Rick C]

I am someone who can see the negative effects of your behavior even if you can't. I'm not the only person who has tried to talk to you about this. Mostly though, people just avoid talking to you when you are like this.

> Social behaviour is not your strength as you have shown in many places here.
>
> If I have the time I will do a nice PDF collection for download for others to enjoy ( or not).
> And your behaviour started this discussion here
> and you caused it,
> and you know it.

I never realized I was so powerful as to control your actions. That's amazing!

> And as I said before:
>
> Piss off and stay out of my threads.

Sorry to tell you that you don't own the Internet or this newsgroup or even this thread. Posting here is a start of a public discussion where anyone may participate. I would have expected you to learn that a long time ago.

> You know what happens if you get agressive here.
> It seems you have nothing else to do.
> It is your standard behaviour and you love it.

Nothing I have done is aggressive. You just imagine it that way. When I say you seem to be off your nut, that's not aggressive, that's just describing your behavior.

> And again, as it seems you have not grasped it:
> The Idiots Guide to Groups and Communities:
>
> In moderated places you would not dare to be as agressive as you can here.
> As result people would not have to throw your shit back at you.

I would not be replying to your post because the moderator would not allow you to behave this way.

It is very telling that you see this as a shit slinging contest when it is just a conversation. I suppose you've never heard the expression about sticks and stones...

> You might not undestand this anymore,
> that talking is to transmit to a receiving end or a group..
> If they do not like what you say they will react - you had not prepared it well.

Yes, you are reacting, much as a child would. A very profane child.

> If you do not aim at the group what you say,
> please write it onto a piece of toilet paper in the process and down it goes ...
> Nobody can be offended - but you got rid of it.

I suggest you follow your own advise.

The only thing I've done to be embarrassed about is responding to you as if there were some reason to think you might understand the situation. Are you like this in person as well? That is scary.

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

As said:
PISS OFF - AGAIN YOU SAID NOTHING USEFUL AND NOTHING REGARDING FORTH ANYWAY.

[Rick C]

I don't understand you. You claim I say nothing useful, but you keep reading it and replying to it. Seems to me that you like this conversation. Sorta like the feller huntin' the bear!

--

Rick C.

+-+ Get 1,000 miles of free Supercharging
+-+ Tesla referral code - https://ts.la/richard11209

[Jurgen Pitaske]

UP YOURS

[Jurgen Pitaske]

[Jurgen Pitaske]

[Rick C]

See, this is the sort of intellectually stimulating discussion we often see in clf.

At least I mentioned this Forth group this time.

Do you really not see what you are doing? If you just calmed down and responded in a reasonable manner, it would be a civil discussion. I'm not the one hurling profanities. What has you so worked up? What have I said that was so provocative? If this is pissing you off so much, why do you keep replying?

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209

[Kerr-Mudd, John]

On Mon, 31 Jan 2022 13:14:17 -0800 (PST)

Rick C <gnuarm.del...@gmail.com> wrote:

> On Monday, January 31, 2022 at 3:56:51 PM UTC-5, jpit...@gmail.com wrote:
> > On Monday, 31 January 2022 at 20:50:19 UTC, Jurgen Pitaske wrote:
> > > On Monday, 31 January 2022 at 20:48:48 UTC, Jurgen Pitaske wrote:
> > > > On Monday, 31 January 2022 at 19:18:52 UTC, gnuarm.del...@gmail.com wrote:
> > > > > On Monday, January 31, 2022 at 1:05:59 PM UTC-5, jpit...@gmail.com wrote:
> > > > > > On Monday, 31 January 2022 at 18:01:35 UTC, gnuarm.del...@gmail.com wrote:
> > > > > > > On Monday, January 31, 2022 at 9:45:47 AM UTC-5, jpit...@gmail.com wrote:
> > > > > > > > On Monday, 31 January 2022 at 13:50:12 UTC, gnuarm.del...@gmail.com wrote:
> > > > > > > > > On Monday, January 31, 2022 at 4:05:42 AM UTC-5, jpit...@gmail.com wrote:
> > > > > > > > > > On Sunday, 30 January 2022 at 19:16:50 UTC, gnuarm.del...@gmail.com wrote:
> > > > > > > > > > > On Sunday, January 30, 2022 at 7:27:02 AM UTC-5, Kerr-Mudd, John wrote:
> > > > > > > > > > > > On Sun, 30 Jan 2022 03:10:37 -0800 (PST)
> > > > > > > > > > > > Rick C <gnuarm.del...@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Saturday, January 29, 2022 at 10:42:15 PM UTC-5, Wayne morellini wrote:
> > > > > > > > > > > > > > On Sunday, January 30, 2022 at 7:56:12 AM UTC+10, gnuarm.del...@gmail.com wrote:
> > > > > > > > > > > > > > > On Saturday, January 29, 2022 at 3:40:53 PM UTC-5, jpit...@gmail.com wrote:
> > > > > > > > > > > > > > > > On Saturday, 29 January 2022 at 20:28:38 UTC, Kerr-Mudd, John wrote: l
>

Good Grief. I thin I've seen enough of forth.

[Rick C]

Yeah, that happens a lot in this group. The funny part is everyone wants to blame it on someone else. As a school teacher explained to me once, it takes two to tango.

Whatever. If you like Forth, you can get benefit from this group by simply ignoring the nonsense you don't like. Sort of like watching TV shows and leaving the room during the commercials.

You can have relatively meaningful conversations here. It's not so often than anyone summons Beetlejuice.

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209

[dxforth]

On 1/02/2022 12:19, Rick C wrote:
> On Monday, January 31, 2022 at 4:26:08 PM UTC-5, Kerr-Mudd, John wrote:
>> On Mon, 31 Jan 2022 13:14:17 -0800 (PST)
>> Rick C <gnuarm.del...@gmail.com> wrote:
>>
>> > On Monday, January 31, 2022 at 3:56:51 PM UTC-5, jpit...@gmail.com wrote:
>> > > On Monday, 31 January 2022 at 20:50:19 UTC, Jurgen Pitaske wrote:
>> > > > On Monday, 31 January 2022 at 20:48:48 UTC, Jurgen Pitaske wrote:
>> > > > > On Monday, 31 January 2022 at 19:18:52 UTC, gnuarm.del...@gmail.com wrote:
>> > > > > > On Monday, January 31, 2022 at 1:05:59 PM UTC-5, jpit...@gmail.com wrote:
>> > > > > > > On Monday, 31 January 2022 at 18:01:35 UTC, gnuarm.del...@gmail.com wrote:
>> > > > > > > > On Monday, January 31, 2022 at 9:45:47 AM UTC-5, jpit...@gmail.com wrote:
>> > > > > > > > > On Monday, 31 January 2022 at 13:50:12 UTC, gnuarm.del...@gmail.com wrote:
>> > > > > > > > > > On Monday, January 31, 2022 at 4:05:42 AM UTC-5, jpit...@gmail.com wrote:
>> > > > > > > > > > > On Sunday, 30 January 2022 at 19:16:50 UTC, gnuarm.del...@gmail.com wrote:
>> > > > > > > > > > > > On Sunday, January 30, 2022 at 7:27:02 AM UTC-5, Kerr-Mudd, John wrote:
>> > > > > > > > > > > > > On Sun, 30 Jan 2022 03:10:37 -0800 (PST)
>> > > > > > > > > > > > > Rick C <gnuarm.del...@gmail.com> wrote:
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > > On Saturday, January 29, 2022 at 10:42:15 PM UTC-5, Wayne morellini wrote:
>> > > > > > > > > > > > > > > On Sunday, January 30, 2022 at 7:56:12 AM UTC+10, gnuarm.del...@gmail.com wrote:
>> > > > > > > > > > > > > > > > On Saturday, January 29, 2022 at 3:40:53 PM UTC-5, jpit...@gmail.com wrote:
>> > > > > > > > > > > > > > > > > On Saturday, 29 January 2022 at 20:28:38 UTC, Kerr-Mudd, John wrote: l
>> >
>> Good Grief. I thin I've seen enough of forth.
>
> Yeah, that happens a lot in this group. The funny part is everyone wants to blame it on someone else. As a school teacher explained to me once, it takes two to tango.

It takes one to dominate and the other to submit.

Accept your place in the forth hierarchy. Resistance is futile.

https://youtu.be/rtEaR1JU-ps

[Wayne morellini]

On Tuesday, February 1, 2022 at 7:26:08 AM UTC+10, Kerr-Mudd, John wrote:
> Good Grief. I thin I've seen enough of forth.
> --
> Bah, and indeed Humbug.

It's just somebody trying to paint himself good, and paint others bad, stringing people along, when he knows how the other person he's toyed with is going to react. Somebody, who acts superior, but obviously isn't. Who, if it was a moderated group, I would have gotten banned fairly quickly.
Who, I can't verify any importance or significance too, just intellectually campaigning on inner turmoil in others, which as far as intellectualism goes, is the equivalent of a rant of no use. An alternative history, would be that this stuff is all useful and intellectually significant. We don't know, if he even just writes the microcontroller code for a candle stick holder molding press at a navel base. I was partly interested in making candies once, seems like a nice idea. He is very silent about anything at all significant he has done, and doesn't seem to understand anything significant posted here.

I can understand the lovely significant work others have done here, with my appreciation. But, I don't believe him to be the military's previous backwards AI program, but genuinely believe he is a real person, though, I have no firm proof he is the person he says he is. I come across many people, who act a bit like this, who show little to know understanding or ability of design, not proving to me, that he is not of the other 99.9%, or 99.99%+, as far as good design skills go in the general community. That's a guess, but I've still got the talent to see it.

Somebody here, keeps on threatening to post up his conversations, in front of potential business opportunities, so he is intently attempting to make them look bad compared to himself. However, he has gotten in front of business opportunities here, and we are not happy to see him paint himself up, and carry on this campaign, not worthy of anybody significant. He is unnecessary to the success of people who having issues. Just a terrible waste of our time. But, we are drawing a line under this chapter of history, but he is still coming back, to win, but is not realising that is finished. You can love somebody, but it's up to them to reciprocate.


On another matter:

Jurgen, stop letting anyone get to you. Dispassionately refer to them, and their actions. People can see more clearly. You deserve your own success.

[Jurgen Pitaske]

I am having a break here regarding MISC16,
waiting now to get the MAX board,
breadboard-friendly, and see the eForth run .
Switching some LEDs on and off or more,
https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/MAX1000-Intel-MAX-10/?gclid=CjwKCAiAl-6PBhBCEiwAc2GOVIEO-uP2mkqTEIOC_PXUxhgBZC4lUDb5VewiLIs8Jp-wbqcgKFSdLxoCxcgQAvD_BwE

A new book about MISC16 is in the planning,
so there will be an interesting time ahead and a lot of my spare time needed.

[Mark Wills]

It's not Forth - it's usenet!!

[Wayne morellini]

Or LessUsefullNet, these days.

[Jurgen Pitaske]

Wayne, I think it is not correct to blame the tool,
if the user cannot control how to use it.

[Jurgen Pitaske]

I just had another look at the 3 MISC articles from then - unfortunately in German -
and they are really from January 1997 - so 25 years ago ...
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf

[Jurgen Pitaske]

And for the fun of it the translation of the first article here, written in German by Bernd Paysan

Porting MISC https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf
Gforth ported to MISC
by Bernd Paysan pay...@informatik.tu-muenchen.de; Stockmannstrasse 14; D-81 477 Munich
The ability to quickly port a Forth system to other systems and new processors is one of Forth's most popular selling points. But how long does that take? Three man-months? Three weeks? Three days!
We took the following field report from the newsgroup /de/comp/langforth from 2/4/97
Tags: Gforth port MISC
Of course, we also have people at our monthly Munich Forth meetings (well, mostly in the singular ;-) who just don't want to believe that you can do everything much faster with Forth, especially porting to a new CPU. And the person is not at all a PC goof who simply says, "Why a new CPU, my Intel is compatible anyway'', but works in an ASIC company ("Mixed Mode"), which meanwhile also have tinkered with a very small CPU. Now the design is finished, the boards are ordered, but there is no running development software (except an assembler) in sight. Only the unbelievable "One weekend" as an answer to the question "How long does it take to port a Forth to it?".
And in three weeks or so there will be 'Embedded Systems Exhibition', and there should be 'something going on' at the Mixed Mode stand! Well, at some point you will be taken at your word, and it started last Friday at 5 p.m. (by then the simulator was ready, that was a requirement).
The opponents on the one hand:
a processor with "one command: the move". Well, so that something can be calculated, there is an ALU mapped into the address space. Indirect addressing is done by patching the operands for an instruction (there is no opcode because an instruction needs a 0-bit opcode).
Purpose of the processor: Sit somewhere on an FPGA, and take up as little space as possible. So a kind of customer specific PIC, but for low quantities.
On the other hand Jens Wilke, ex-sysop, ex-VD editor and youngest Drachentraeger of the Fothr Group, I, and gforth, actually a desktop Forth, with C instead of assembler underneath. Well, there was a bit of preparatory work involved: the number of necessary primitives was reduced to around 20. Also, gforth's CrossCompiler has always been able to generate 16-bit images, although this has never been used. That's what happened when creating 64-bit images.
The fight: After the people from Mixed Mode handed us the simulator and the current command set, we started on Friday at 7 p.m. Write the assembler (approx. 20 constants ;-), create Intel hex dump, because the simulator reads that, not just binary. At the same time, Jens reduces the number of necessary primitives even further. At some point the primitives were written, then testing began (must have been around midnight). Of course, first of all, belly landing: The addresses are word addresses, but the cross compiler generates byte addresses. So, rewrite primitives. Eventually it's 3 a.m. and I'm going home. Jens continues to work until 6 a.m.
Next problem: The cross-compiler relies on the CLoader, and doesn't spit out the correct code. That was corrected on Saturday evening. The Forth already runs a few steps and then stops. Meanwhile, Jens has written his own simulator, which is faster, and is almost at the prompt. However, it turns out that the doc is wrong, and that the self-written simulator and primitives fit together, but not with the chip ;-). So, on Sunday remove the last bugs from the primitives, build a few more primitives (otherwise you won't get to the bugs in a finite amount of time ;-), and send them to the MixedMode people as an Intel hex file sometime around 1 am (as promised). As announced, you can see how the system runs on real hardware at Embedded. And there's more about the processor and gforth as an EC development system at the Forth conference. Anyway, one thing became clear to me:
It's not enough to reduce everything to a few primitives. That runs slowly on a Pentium. They have to be the right ones, and you have to choose the primitives in such a way that each new primitive gives a decent performance boost (this concerns for example good primitives for implementing dmod, um* and (find)).
The current status is 47 primitives (of which 7 methods to execute words):
:docol :docon :dovar :douser :dodefer :dofield :dodoes
! @X! X@ execute :s ?branch
branch (loop) xor or and + -
2/ O= 0<> = U< l+ cell+
8<< 8>> C@ 2*
>r r> sp@ sp! rp@ rp! drop
lit dup r@ over swap d+ d2*+
Imodstep

[Wayne morellini]

My apologies Juergen. I was meaning, the actions of certain people, were trying to make Usenet less useful. My original post stating Usenet was degraded by them over time, got lost in posting. I don't want to dwell on it here, so just reposted the short version.

[Jurgen Pitaske]

No issue we all know what is happening

[Jurgen Pitaske]

And as I had a bit of time and collecting all of the available material about MISC16, it had to be grabbed, cleaned up and translated anyway:

Article 2 in Vierte Dimension:

Embedded Systems '97
The former “Real-Time” trade fair with the FORTH e.V. stand is now taking place in Wiesbaden in September and has also changed organizers. In spring there is "Embedded" under a different name, but at the same place and with the same organizer. The decisive difference is that "Embedded" is successful. In the early days, the "Echtzeit" was sparsely occupied with exhibitors and the structure of the exhibitors was fairly uniform: medium-sized German industrial companies. There was often more stand personnel than visitors in the hall.
For "Embedded", the unfavorable location of the exhibition hall in Sindelfingen has been alleviated by a free shuttle bus to the S-Bahn station and parking lots. Above all, it has been possible to attract a wide range of exhibitors. At the upper end are the large semiconductor manufacturers such as Motorola. At the lower end, 1-man companies and "EMUF manufacturers". At the same time, all the important publishers and magazines. And semiconductor distributors. The fair is still so small that you can do it in one day without foot pain. And it still doesn't have the rush of the 'Electronica', you can take your time for talking. The success of the "Embedded" is reflected in the number of 4,500 visitors in 1996, which was even exceeded.
FORTH was also represented this year, albeit sparingly and mostly hidden. Most obvious was FORTH at Forth Engineering, that is Wolf Wejgaard demonstrating HOLON on the 68HC11. He had a small booth in a good location that couldn't be missed. In addition, he had set up his presentation clearly and visually well visible.
He also gave the lecture at the accompanying congress and not Beierlein as announced.
Otherwise you had to search to find FORTH. Gforth for the MISC was at Mixed Mode. Flyers and excerpts from the ANS standard as well as diskettes were distributed there. At the Glyn booth I had a CCD demo with flyers explaining Forth. Lascar no longer exhibited Triangle's boards. But you could show on request a demo device with the latest system from Triangle there. The number of units sold in Germany is too low to justify active sales. They are now using PC 104 there. Naturally, FS Flesch was also there. LMI still has it in the catalogue, but FORTH is a thing of the past there. Ditto Diessner. Temic focused on 8051/ISparclets. But the GEMAC stand had only one topic: MARC4. And plenty of informational material from Temic.
What was not to be seen was also positively noted: a disorganized booth of FORTH e.V., where hobbyists in SWAP-dragon-T-shirts scared potential users from the industry. If FORTH e.V. wants to appear at trade fairs, one should put in the money and preparation to make an adequate appearance possible. For the years to come, a joint stand for several FORTH providers/users would be desirable. A participation as single companies is not promising because the costs are too high.
Rafael Deliano

[Jurgen Pitaske]

There are 3 articles in Vierte Dimension 1997 about the MISC and so here the third translation.

( and it takes 25 years to find out, that the picture there is wrong:
it should be the MISC Instruction Set, but is an LCD Interface ...
The relevant instructions for the MISC16 as of today you can find here:
https://github.com/Steve-Teal/eforth-misc16

and the 3 articles from 1997 are here
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d1997_1.pdf



MISC
by Rafael Deliano Steinbergstr. 37; D-82110 Germering
In VD 4/96 the topic CPU in FPGA was presented in general. Here is a concrete example. The ASIC design house Mixed Mode presented the first version of the MISC processor at the "Embedded Systems" trade fair at the end of February. MISC stands for "Minimum Instruction Set Computer". The MOVE machine was chosen as the architecture here.
Tags: MISC FPGA MOVE machine
The MOVE machine concept is of recent origin [1] [2] and was apparently first realized in Germany in 1990 as part of a diploma thesis at the Nuernberg University of Applied Sciences [3]. The 16-bit CPU at that time was manufactured in prototype numbers at AMS in Graz, occupies 2300 gates and, according to the (quite optimistic) information of the Nuremberg developers, comes close to the 68000 in terms of computing power. For the implementation of Mixed Mode, the boundary conditions were considerably tougher, because the CPU was to be housed in an FPGA. The Lattice 6192 component used has been in production for half a year and thus represents the state of the art that has been achieved with FPGAs. It holds the 2000 gates of the CPU and even has some internal RAM, enough for stacks anyway. Its QFP package with 208 pins has enough pins to lead out the data and address bus, each with a width of 16 bits. 32k Word EPROM and 32k Word SRAM are installed externally on the demo board.
A MOVE machine has only one command:
MOVE source, destination
The command fetches a data word from "source" and stores it in "destination". Since there is only one instruction, you don't need the opcode. Only the two 16-bit addresses are still in memory:
source , destination
In practice, one accesses the basic commands of the CPU here in the same way as one previously accessed I/0. Example: the "command" for addition is actually a target address, namely 000Bh, and reads: "ACCU+source->ACCU". The sum of the accumulator and the source address ends up back in the accumulator. The memory therefore contains these two addresses as commands:
source , 000Bh
This minimum CPU was defined according to this scheme, the instruction set of which is in the picture. A UART was also integrated at the same time, which is permanently set to 9600 baud 8N1. By combining the microcode instructions, Mixed Mode was able to define an assembler that has about 40 instructions and is similar to what is found on a conventional CPU.
However, users today are no longer inclined to program their CPUs in assembler. In addition, the MISC with 16-bit data word width and 64k address space is perfectly suitable for a high-level language. While Mixed Mode was developing a C compiler for it at C speed, they contacted the FORTH company about a FORTH compiler. After Bernd Paysan and Jens Wike had been presented with the MISC specs on Friday at 5 p.m., they managed to port Gforth by Sunday 1 a.m. (at night) in just over 48 hours. For the trade fair, which took place two weeks later, it was planned that Tetris would run as a demo on the MISC via the UART on an ANSI terminal. The layout of the printed circuit board, and problems with the FPGA in particular, led to delays. The hardware was on the first day of the trade fair. Although then available, but far too unstable to be able to demonstrate something live. At least the visitors could take along plenty of information material and a simulator on diskette with MISC and Gforth. While most new RISCs do not get beyond a VHDL simulation model and only a few are cast in silicon, the MISC is now also supported by compilers.

[1] Jones "The Ultimate RiSC" Computer Architecture News June 1988 p.48-55
[2] Griffin,,The UItimate UItimate RiSC? Computer Architecture News Jm 1989 pp. 26-32
[3] Eichele, Leuschner "A new Risc architecture" Franzis-"Electronics" 17190 p. 49-54

[Wayne morellini]

I was wondering. We keep waiting for GA, to deliver something for everybody. But, the Forth standards groups could make an open source design, for anybody to manufacture. But, based on colorforth instruction set, as "ForthMini", or "Forth-" and official extensions to it (which is 386x compatible). I'm a fan of the slotted environment, and 4 bit slots (with some memory based instructions of course), as you can't get memory to keep up with instruction speed. The memory word width addressing would be equivalent to the chip data path width, to expand memory foot print, with seperate read, write, storage executable read, video, and specialist processing/sound banks possible. Which means that the 16 bit will have up to 21 bit words of memory. However, this means there needs to be a way to peer and modify into the banks. Which might be a section of memory that can be mapped into any bank, but segment aligned by the most significant bit boundaries (if 10 bits of memory words is used for the window, that leaves a memory based register of 11 bits, to where you can point the segment. But, as you would have 16 bits available in a memory register, 26 bit words of banks is possible. Any of the banks could almost be setup to be used in anyway, but those extra 5 bits could come on handy for storage addressing, which would be about 128MB on a 16 bit. The shared bus (though video and specialist processing can have their own buses) will reduce performance, but it's really about low energy embedded design. A manufacturer can put in extra busses and higher clock rate.

But, there is room for 8 bit, 16 bit and 32bit versions, and people like yourself and Ting already have items out there. There could be a second ultra light version of the 16 bit, and 8 bit, suitable for smaller FPGA usage, where VLIW is used.

I've tried to contact Bernard on the commercial chips on his s design last week, but didn't hear back. So, I don't know what he's up to.

Anyway, the chip designs, maybe based on current design, and come in RAW cell form suitable to be put into a chip that only has memory interfaces, and maybe some data links, from which an array can be made. The CE form is more like the mup21 concept, but with counter based clocked video, and sound, and CE interfaces and USB, wifi, mobile like hardware cells attached (maybe all open sourced cells). The last is the Embedded controller, with embedded control interfaces. I have to point out, that ARM, has pushed a lot of useful high speed interfaces through standards groups in the past, which would be useful to support, which could be added to any of these.

The best part is, you can mix these three core types in an array. So, an array can have 8, 16 or 32 bit array, with an 8, 16, 32 bit embedded and or CE core on the outside, providing interface services. Like ARM, different manufacturers can adopt them into a range. While it is great to have x86 or ARM system, there will still be a need for low energy low cost stock controllers. They are Simple Instruction Set Controllers (SISC). Misc has become over simplified which makes it difficult.

The point of these, is simple little work horses you could use in projects for decades, that are so simple, they don't have to be redesigned, except in new interfaces, unlike ARM. The 8 bit is a more functional replacement for 4 bit, the 16 bit, is a more functional alternative to 8 bit. The 32 bit is a more functional alternative to 16 bit. As these cores are so simple, their transistor counts will be closer to the next level down, but their performance a lot better.

Anyway, that's the idea.

[Jurgen Pitaske]

There is Bernd's b16
- designed probably 20 years ago and now running in thousands or even millions of products.
https://bernd-paysan.de/b16.html
Unfortunately there is not much official documentation
about the applications it is used in successfully now.
Such information could definitely trigger more designs
as there is a success story ( not talked about much in the Forth community or else ).

There are many machines that can run Forth Words.
But it has not caught on.
Neither in the Maker community.
It seems to be easier to use a standard microprocessor - and most probably cheaper.
There is probably no pressure for GA to update a chip that is about 10 years old.
This means to me, that it is either good enough for the applications it is used in,
or too expensive to update, looking at the return that might come out.

[Rick C]

The reason GA has not "updated" the GA144 is because they have not sold the chips they bought 10 years ago. The problems with the GA144 are very fundamental. They did not consider any use case when it was designed. It was a lab toy which they thought they could sell based on it's uniqueness. However it's uniqueness is actually it's down fall. They didn't even consider the need for I/Os that can handle voltages above 1.8V. That was because they didn't know how to provide 5V tolerant (or even 3.3V tolerant) I/Os on the same chip as the 1.8V processors. If they could have, they would have.

The other problem with the general community using a MISC chip is the need to learn this strange and alien language called Forth. I've had sales people laugh when I said I used Forth in my work... and that was the ones who had heard of Forth.

There are no killer apps for Forth software or Forth-ish chips because they don't actually do anything better than the "tip of the spear" chips from the multi-national MCU makers. Even if a MISC was made in a modern process with low power and high speed, the many limitation of the GA144 or any other MISC will prevent it from ever being a big seller. It may be ideal for some small function embedded in an ASIC, but as you have seen, they are not very visible and so not going to promote MISC.

In fact, there are small register based designs that have support from C compilers. These are the designs that may get noticed and spread around many other designs. Consider that the J1 is faster and smaller than the microBlaze and yet, the microBlaze is used much, much more widely. This is a Forth vs C issue more than a MISC vs register CPU battle.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209

[Wayne morellini]

Well, I heard it was being manufactured here, but I still couldn't even find it with the manufacture name. I asked Bernard where I could find information on them, and haven't heard back. So, nothing I can do about this.

> There are many machines that can run Forth Words.
> But it has not caught on.

That's purely based on how it was managed.

> Neither in the Maker community.

I wouldn't expect them to know much, plus they already have an ecosystem. it needs to use as an alternative processor for Arduino and Pi, but then you don't have the software ecosystem. That's why I suggest precompiled javascript and is API support, to give something of an ecosystem, where you can just use forth, and JS api's, if you want to. New people familiar with JS can come on, and learn F- to get more performance. It's not a matter about replacing Arduino or Pi, it's about a slow grow alternative to attract its own users. It can then swim or sink.

> It seems to be easier to use a standard microprocessor - and most probably cheaper.
> There is probably no pressure for GA to update a chip that is about 10 years old.
> This means to me, that it is either good enough for the applications it is used in,
> or too expensive to update, looking at the return that might come out.

The problem with GA, is it needed to have the ability to do a universal flat programming model for everybody else, and needed a more universal integrated system as the original misc chips did. You remember, that shboom was supposed to be the best C programming language chip, before it was redone, but didn't get to the market in original form. It is the prelude to the misc chips, and a high performance design of the time. So, misc isn't the issue, it's how one implements things. I don't have to think about a specific usage so much, past doing the numbers to see if it has performance, if I design it to be universally programmable and to have best efficiency and performance for efficiency, with the required interfaces and integration People will decide if it fits their design or not. They can do the.numvets to see if it is so. We live in a mature embedded market, there is normally development kit, easy programming, expected hardware processing features and software services interfaces, expected IO interfaces, and expected libraries. Low energy or high performance, or low cost, is only part of that. With those things, you still have to play catch up. Which is why I advocate pulling on another ecosystem then play catch up. If the user can use C and JS, then they can start there or use that alongside of F-, to fill in the lack in its ecosystem, and from there a system can catch up and develop its own ecosystem. But, these are all big business concerns, not like anybody who sells some chips or some boards. It's a different mindset about victory and not just doing what we like, and how we are used to doing it. One could come along and say, they should design a 16 bit CPU like the mup22, but just with memory interface, and expect to sell 100's of billions of them, and become the richest man in Earth. It's not going work, it's not the early to mid 1970's. It requires strategy and a lot of work. Like, I could use something like yours or Benard's on a small retro console like hobbyist product, bit there are other options, and as you go to other applications, a lot more complete options. So, there is a bare minimum amount of features and works to be competitive, then better energy, efficiency, performance and cost matters. The manufacturer developer says, it can do it easily, outdo the competition, and or save 10-100 million dollars, especially if they think of using a cross all products duct lines as standard because it is below the cost price of an arm, and similarly priced but better than an 8 bit or 4 bit. I'm a bit of the Jack Tramiel school, who used to lower costs for the same, or better, quality, so nobody else could afford to compete in the home computer market. Interestingly, the MOS fab is still sitting out there in California.

[Jurgen Pitaske]

I assume you mean Bernd Paysan in Germany and his b16 ?
I assume he is very busy - I sent him some MISC16 links as well and did not get feedback.
https://bernd-paysan.de/b16.html

[Wayne morellini]

Yep. I wanted to find a commercial manufactured ASIC version to look at.

[Rick C]

I think you are going to find these ASICs are used in products rather than being chip level products that are sold. Most ASICs are never sold outside the company who designed them.

What sort of things would you want to see?


--

Rick C.

---+ Get 1,000 miles of free Supercharging
---+ Tesla referral code - https://ts.la/richard11209

[Paul Rubin]

Wayne morellini <waynemo...@gmail.com> writes:
>> https://bernd-paysan.de/b16.html
> Yep. I wanted to find a commercial manufactured ASIC version to look at.

I remember Bernd saying that a b16 controlled battery charging in some
older iPhones (no idea about current models). Because there were 1e8's
of those phones manufactured, it was worth significant effort to save a
fraction of a penny on each one.

[Wayne morellini]

That's right. That's how high end economics work, 10's of millions of fractions of cents. But, most of those chips, we don't know what they were and where they were used, like with GA. They were paying the bills somehow for a while. However, if there was a line item for any manufacturer to use, that would be good. However, I'm interested if any were for items with video audio functions. If I were to arrange a retro project, I might start with a z80, but after that, it:s worth looking at something else. 64k and 128k, is a fair bit, if I'm using repeat tiling and mapping only some tiles to individual graphics. A lot of early games were like that, or less than that. The Atari VCS was rather primitive. They could have done a little bit more, and many more advanced games wouldn't have suffered so much, and maybe ET, would have been more enjoyable :). The astrocade offered more but the colour pallet used in games was awful. Mattel concentrated on official sports tie ins, with some interesting graphical choices. The Atari 5200 was just behind, and they didn't include the VCS compatibility. The commodores 64, just offered something better, free of licensing, development systems and contracts to tie content to consoles, which freed it. The Nintendo was maybe superior in graphics, with some interesting colour choices, and contracts that tied up content, which crushed things. Even though the Atari 7800 was what the 5200 should have been, and likely superior to the Nintendo, if they had used more memory and upgraded it, rather than using 2 year old mothballed product from the video game crash. It wasn't until the Genius, that the console industry really broke free, and that was virtually an upgraded msx like machine, that didn't go far enough. It was, as far as I know, a simple sprite based system without advanced graphics like the 7800 arcade based architecture, or the Super NES. Even the original game boy supported more sprites on screen, no restrictions, than many systems in earlier times. A mup like 16 bit misc chip optimised on the 6502's fab process could offer enough performance to do all the types of games up to the Nintendo, maybe Genesis, given the storage memory and enough clock gain on the process (as we have seen excellent clocking on past misc chip designs). I don't know about the 7800, considering its hardware was often not taxed to it's highest, and there wasn't much memory or clock. Anyway, that basically is the range of sprite game play, up to quarter VGA, to that point, excluding Amiga and SNES, and maybe the Genesis, which is pretty good. Memory performance being a limit tiny factor that has to be there to match the Genesis (likely 4mhz or more 16 bit memory access. You can still have processor time at 2mhz, but you don't have as much performance to match the rest of it), but what could you do in the early 1980's could easily match the prior systems here. Going back to 1977, we again, could match systems over 5 years out. It's all interesting comparative alternative architecture archaeology. We see, without adding specialist coprocessing, there is a performance advantage on going to the architecture. But, from the 7800, Amiga and SNES, it was growingly all about graphics coprocessing performance, and in the PC, all sorts of parallel coprocessing.. the mixture of different cores and use of an array compensates fur this somewhat, especially if your energy consumption is low enough. But, with a misc design. I was planning (years back) on adding counters and simple DMA to do displays and transfers, which if you control certain aspects of where things are moved from and too, you can move graphics, you get closer to the 7800 or Amiga like features. A few little graphics features and you have significant ability in 2D graphics, even movable objects. My misc intent extends to everything. Eben my minimalistic 3D system from the 1990's is not that much more complex than 2D, and as sophisticated as high end 3D with a fraction of the complexity, because it doesn't try to emulate through effects, it simulates, drastically cutting down the complexity of the render part, getting rid of most of the GPU, while allowing the environment and lifting to be dynamically manipulated to simulate special effects. A pixel or object can be given special rendering ability to add effects, and external effects are just an rendering object. All this should be common place by now, after that kid who sat at the computer next to the one I was using when I first came up with the scheme, and sometimes was behind me. Anyway, I can only remember so much about the over all solution set now, but the industry seems to have now caught up to the quality aims.

Anyway, misc plus a few counters and DMA features, and new types of graphics features, seems interesting.


.
.

[Wayne morellini]

Firstly, I searched for my post on Google, to see if the thread title had changed from Jurgens original thread, as it doesn't show up on Google groups correctly. The search for the post's text, turned up nothing. But I found Google has banned comp.lang.forth, which is a bit staggeringly ridiculous. As can be seen here:

https://lwn.net/Articles/827233/

Then, we should ban Google?

Secondly, is this thread title change to comp.lang.forth banned etc? Do you guys see my previous post that starts "That's right. That's how high end economics work,".

Remember, Google doesn't really exist without us

[Jurgen Pitaske]

Yes I can see it it is a long one.

[dxforth]

Choosing a different prostitute means nothing if one is hooked on the services
prostitutes offer.

[Jurgen Pitaske]

DXFORTH NEWS:
No Forth
No eForth
No MISC
No FPGA
No ASIC
How do his preferences fit into my thread here?

eForth reborn on a late Christmas Present - a new new born Microprocessor in FPGA

His advice probably based on his experience and preferences:

> Choosing a different prostitute means nothing if one is hooked on the services
> prostitutes offer.

I wonder who of the people here are interested to know,
that dxforth is hooked on prostitutes.
I assume wrong place here to find some ...

[dxforth]

I wouldn't know but this publisher might :)

https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0/m/TxO52x4cAQAJ

[Wayne morellini]

On Saturday, February 12, 2022 at 11:12:10 AM UTC+10, dxforth wrote:
> > Remember, Google doesn't really exist without us
> Choosing a different prostitute means nothing if one is hooked on the services
> prostitutes offer.

Not useful. Plus, in this case, you mixed up the identity of the subject there. So, nobody is interested in the subject of the article. Well, a way to defeat, is to be continually negative to the point of defeat. Years ago, I was developing the cutting edge operating system design. But operating systems began including many times more baggage than their own code, Flash was released free on the web (another market opportunity gone) and Bill Gates announced they spent 100 mam years on developing the newest windows. So, it was hopeless, the big boys had blotted out the space. I made the logical, positive, decision and ceased designing. I trusted Microsoft, Apple, Linux, then Android, to do the right thing. But, not enough competency was not to be found. Those who were competent, like QNX, Tantric technologies, Geoworks and Acorn, Europress even, did not did not have the competency to make it big. If I hadn't given in to the negative situation, I could have developed a transportable code platform, and a mobile platform to compete with flash, java script and android, that could be developed in to all the other levels of operating systems people , and the world could have been a better place and we could have done well etc. Of the three of us who started around 1986, only Java succeeded, the least competent of us all. That's what people with little competency understand, it requires multiple people with multiple competencies to make success
Rather than negative people arrogantly demanding single people deliver it all.

So, despite how negative it might appear, it's about how to make it succeed.

[dxforth]

On 13/02/2022 22:23, Wayne morellini wrote:
>
> Years ago, I was developing the cutting edge operating system design. But operating systems began including many times more baggage than their own code, Flash was released free on the web (another market opportunity gone) and Bill Gates announced they spent 100 mam years on developing the newest windows. So, it was hopeless, the big boys had blotted out the space. I made the logical, positive, decision and ceased designing.

ISTM Gates made his fortune by facilitating more than designing. Other than BASIC
I don't know what he personally created or was involved with but he seems to have
had sufficient business prowess to know what clients were worth chasing and where
to source programmers.

[Wayne morellini]

Yet, even Microsoft normalised the error rate in Windows. Good design and hiring would have largely got rid of them. A lot of the Microsoft products were bought in. Bill did a version of Basic. He got interested in the financial side, I read, decades back.

But, the point was, that despite how negative the situation looked. The actions of others allowed other avenues to get the message out. I could have done a game watch, as a simple OS example, say (simple operating system target) and web plug in, expand out to a basic cross game development software system, and expand from there. By the time, I was pretty IP heavy, and wanted to quickly accelerate to developing my unique ray tracing occulling system in the third year of the OS. So, was looking at rapid expansion to be able to afford the development and IP costs (look at the latest Unreal Engine, to get an idea of where I was heading ultimately) and that of the rest of the system By the time I backed off and decided to do a dumbed down simple version of an gaming OS (the user manual interactive API interface of the old one, was enormous, mapping every bodily control segment spatially ad well as external controls. It could have gone to every muscle, full VR body control, which was the future, as well as the relative self organising GUI technology, which I backed off of any way as the calculations would have made it slower like a normal OS), I was getting sick from chemical poisoning and pathology etc. But. If you can see it. You have to design it, because you will eventually not be able to anymore. But, yes, it could have been recorded, while designing a simpler version. A lot of the big complex things, let the body mapping control data structures, you get a design team to figure out the details, as you can afford to.

So, your language, and misc, aren't dead, but still have opportunity to be made into something more. Negativity will crush that. The time for forth to contribute much, is drawing to a close, as the Ind story prepares to shift away.from standard processing, to new paradigms, that Forth had little place in.

[dxforth]

On 16/02/2022 01:40, Wayne morellini wrote:
> ...

> So, your language, and misc, aren't dead, but still have opportunity to be made into something more. Negativity will crush that. The time for forth to contribute much, is drawing to a close, as the Ind story prepares to shift away.from standard processing, to new paradigms, that Forth had little place in.

Negativity or pessimism is what happens when optimism fails to deliver. Unlike
creativity - which is insight - optimism is indulgence in dreaming about future
gains. It's fair to say there's been a lot of the latter in forth.

[Wayne morellini]

Realities. I wouldn't say there has been too much correct dreaming of realistic things in forth, that's the issue. Three finger keyboard, bah, I've got a watch with a one finger keyboard, and it's an exponentially bigger pain (I'm being facetious). "Novel" idea, means you have an idea that is in the range where most ideas are not that practical. Everything that keeps me from misc, is such ideas. Right novel is good, less right novel, is not so good. Bad novel is bad, which includes people that can't discern good novel.. one has to go past these people, in particular, and move to the correct. That's how reality works, but that is only the start. Delivering something which can be sold, or supported, is another thing.

I'll illustrate a historical example. In the early days of Apple, I heard, Steve Wozniak wasn't interested in basic or something, but instead was working on an easier way to do assembler, because that is what the computer club enthusiasts were interested in. If Steve Wozniak had got his way, maybe we could have had 100,000 such programmers world wide, instead of 100,000,000. I'm rather tired, so please forgive the quality of writing here. What your small group thinks, doesn't matter that much, compared to what works. Here, we have people pushing novel ideas as a norm, that normal people don't support. They actually expect normal people to confirm and learn to program in those novel ideas. Forget it. We. An do the best for others with efficiency. Because, of we look at colorforth as a machine forth, we are sort of getting what Steve Wozniak was on about. On the other side of the coin, some novel ideas are so much better and efficient, it is worth supporting. Implementing for low machine code focused programmers, then going up for services and apps, then going up to scripting. However many levels that are practical to give you good results with those users. In my own language ambition the same language spanned all, but at each level human coding error would add more inefficiency, till you get to website scripting. But, the underlying structures minimised the efficiency hit of the scripting. The language would be prescriptive, but expandable, to lead to maximum efficiency in all those expanded words. Now Pad Al was invented, and it's inventor did some more remarkable stuff, then he did Python, is that right? Pascal has died back, but Python has been a raging success. Chuck has done Colorforth and other things, but did not do his Python, to replace Forth. I don't expect him to do it now. Such things often require an agile younger mind, over experience. I'm younger and it's beyond me, except I was already drafting such a thing with a machine code like virtual is as it's environment. So, some stuff, and stuff is still in there, to be traded out. It was even going have post fixed ability at the compiler level, but with only certain ways of programming delivering best performance. Simple, almost basic like level of understandability. At least that is what I'm thinking now in my old age it was going be a hard and fast lesson in programming and the instruction set and API interface description in a hundred or so pages. Would have been something. Does it mean it's bad? No! Just the opposite, unrealised correct potential. Which means it's still worth doing , but commercially less so, but such systems will still be desirable along side new paradigms.
.

[Jurgen Pitaske]

Today arrived the pre-programmed MAX1000 FPGA Board :
The Word List as printed out via Teraterm today:


words
cold quit while repeat aft until again begin next for else then
if ; : ." abort" $" .( \ ( constant variable create , .s ' dump
dm+ words @execute word cmove [ ] number? rot ?dup +! query
accept bl tib u.r .r spaces within min max decimal hex ? . abs
u. #> sign #s # hold > < / fill d+ */ */mod mod /mod m/mod m* *
um/mod um* 2drop u< - dnegate negate not 2dup <# pad here dp
base allot char count type + = space cr 2* 2/ 1- 1+ um+ xor or
and 0= 0< depth pick over swap dup drop >r r@ r> c@ c! @ ! ?key
key emit exit execute ok


Now I can go back to MSP430 Board eForth book and have a read and try out the examples.
https://wiki.forth-ev.de/doku.php/en:projects:430eforth:start