On Sunday, 2 January 2022 at 22:49:58 UTC, James Brakefield wrote:
> On Sunday, January 2, 2022 at 2:26:54 PM UTC-6, Ilya Tarasov wrote:
> > > 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? :)
> 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.

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

On Monday, January 3, 2022 at 3:07:49 PM UTC-6, jpit...@gmail.com wrote:
> On Sunday, 2 January 2022 at 22:49:58 UTC, James Brakefield wrote:
> > On Sunday, January 2, 2022 at 2:26:54 PM UTC-6, Ilya Tarasov wrote:
> > > > 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? :)
> > 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.
> 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

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

On Monday, 3 January 2022 at 21:34:31 UTC, James Brakefield wrote:
> On Monday, January 3, 2022 at 3:07:49 PM UTC-6, jpit...@gmail.com wrote:
> > On Sunday, 2 January 2022 at 22:49:58 UTC, James Brakefield wrote:
> > > On Sunday, January 2, 2022 at 2:26:54 PM UTC-6, Ilya Tarasov wrote:
> > > > > 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? :)
> > > 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.
> > 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
> 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

Thank you very much James, forwarded to Steve already.

> 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.

On Tuesday, January 4, 2022 at 7:08:39 AM UTC-6, Ilya Tarasov wrote:
> > 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.

|> 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.

|> ...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.

On Tuesday, January 4, 2022 at 8:08:39 AM UTC-5, Ilya Tarasov wrote:
> > 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.

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

> |> 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.

On Wednesday, 5 January 2022 at 02:53:16 UTC, gnuarm.del...@gmail.com wrote:
> On Tuesday, January 4, 2022 at 8:08:39 AM UTC-5, Ilya Tarasov wrote:
> > > 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.
> 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

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

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:
> > 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

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

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:
> > > 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
> 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 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

On Friday, January 28, 2022 at 8:11:29 PM UTC-4, 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:
> > > > 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
> > 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 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.

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

Marcel Hendrix <mhx@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

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:
> > > > 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
> > 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 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

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?

On Sat, 29 Jan 2022 04:44:34 -0800 (PST)
Wayne morellini <waynemorellini@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:
> > > > > 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
> > > 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 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
>
> 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 proces
sor 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?

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

--
Bah, and indeed Humbug.

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

On Sat, 29 Jan 2022 05:19:55 -0800 (PST)
Rick C <gnuarm.deletethisbit@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.
--
Bah, and indeed Humbug.

On Saturday, January 29, 2022 at 10:03:01 AM UTC-4, Kerr-Mudd, John wrote:
> 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.

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

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.

On Sat, 29 Jan 2022 06:57:41 -0800 (PST)
Wayne morellini <waynemorellini@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.

--
Bah, and indeed Humbug.

On Saturday, 29 January 2022 at 20:28:38 UTC, Kerr-Mudd, John wrote:
> 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.
> --
> 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.

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:
> > 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.
> > --
> > 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

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.

On Sunday, 30 January 2022 at 03:42:15 UTC, 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.
> > > 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.

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"

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.
> > > 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.

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

On Sun, 30 Jan 2022 03:10:37 -0800 (PST)
Rick C <gnuarm.deletethisbit@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.

--
Bah, and indeed Humbug.