Thomas Koenig <tko...@netcologne.de> writes:<
MitchAlsup <Mitch...@aol.com> schrieb:[68881]
Where "worked" meant that::
FABS was 35 cycles !!
That is weird, that is just setting a bit.
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Likewise, just an NEG...
It (and x87 originals) were so bad at IEEE 754 that this opened up the door to RISCs.
I think the main source of the slowness whas that both 8087 and >68881/68882 used CORDIC.That cannot be the reason for FABS FADD FNEG.
It is an interesting question what sort of performance would haveThe 88100 contains 165,000 transistors, contains a pipelined integer
been possible with the transistor budget of the 8087, around 45000 >transistors, or 155000 for the 68881, if Wikipedia is to be believed.
CPU and a pipelined FPU. It only does 32-bit and 64-bit FP (not
80-bit), and the latency for fadd.ddd is 6 cycles, and for fmul.ddd is<
9 cycles. The FUs are pipelined, but register read and write is 32
bits at a time, so you can start an fadd.ddd only every second cycle.
If I understand the FP1 Extra stuff in Table 7-6 correctly, it can
start an fmul.ddd only ever 4 cycles.
FP absolute and FP negation are implemented with integer instructions
and take 1 cycle (I think).
According to <https://archive.org/details/ieee_micro_v8n3_june_88/page/n54/mode/1up>,<
the MIPS R3010 contains 75,000 transistors; it runs at 25MHz and takes
2 cycles for an FP DP add, and 5 cycles for an FP DP multiply
(compared to 26 and 46 for the 68882). According to Figure 1 and
Table 3, the R3010 was 16-27 times faster than a VAX11/780, and more
than 3 times faster than a VAX 8700. The Weitek 1164/1165 in the Sun
4/260 roughly matched the VAX 8700, and both were 3-7 times faster
than the VAX 11/780. The 68881 (in a Sun 3/260) roughly matched the
VAX 11/780.
In find the title of the next article funny: "Intel's 80960: An
Architecture optimized for Embedded Control". I only realized a few
years ago that it was anything but.
Going to the next article, it is about the Weitek 3164 (probably a
successor to the 1164 mentioned above). I did't find a transistor
count for the WTL3164, though.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
I don't remember if it was at all possible to use a 68881 with a 68000.
But maybe by "68000" you meant the 68020 and later.
On 2023-10-27, Opus <ifo...@youknew.org> wrote:<
On 27/10/2023 18:41, Bernd Linsel wrote:
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the 68881/2 were designed for use with a 68020 (and later 68030) and not for the 68000 itself.
I don't remember if it was at all possible to use a 68881 with a 68000. But maybe by "68000" you meant the 68020 and later.
68000 was 16 bit, 68020 I think 32 bit, correct me if I am wrong...<
--
7-77-777, Evil Sinner! https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/
On Saturday, October 28, 2023 at 5:24:44 PM UTC-5, Branimir Maksimovic wrote:
On 2023-10-27, Opus <ifo...@youknew.org> wrote:
On 27/10/2023 18:41, Bernd Linsel wrote:
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the 68881/2 were designed for use with a 68020 (and later 68030) and not for the 68000 itself.
<I don't remember if it was at all possible to use a 68881 with a 68000. But maybe by "68000" you meant the 68020 and later.
68000 was 16 bit, 68020 I think 32 bit, correct me if I am wrong...<
68000 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and 16-bit data bus.
68008 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and a 8-bit data bus.
68010 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and a 16-bit data bus.
68020 was a 32-bit architecture on a 32-bit µarchitecture with a 24-bit address bus and a 32-bit data bus.
--
7-77-777, Evil Sinner! https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/
On Saturday, October 28, 2023 at 5:24:44 PM UTC-5, Branimir Maksimovic wrote:
On 2023-10-27, Opus <ifo...@youknew.org> wrote:
On 27/10/2023 18:41, Bernd Linsel wrote:
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the 68881/2 were designed for use with a 68020 (and later 68030) and not for the 68000 itself.
<I don't remember if it was at all possible to use a 68881 with a 68000. But maybe by "68000" you meant the 68020 and later.
68000 was 16 bit, 68020 I think 32 bit, correct me if I am wrong...<
68000 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and 16-bit data bus.
68008 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and a 8-bit data bus.
68010 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and a 16-bit data bus.
68020 was a 32-bit architecture on a 32-bit µarchitecture with a 24-bit address bus and a 32-bit data bus.
--
7-77-777, Evil Sinner! https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
:
I don't remember if it was at all possible to use a 68881 with a 68000.Au contraire, the -881 worked with all 68k family processors, at least
But maybe by "68000" you meant the 68020 and later.
up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
It (and x87 originals) were so bad at IEEE 754 that this opened up the door to RISCs.
See e.g.
http://www.bitsavers.org/components/motorola/_appNotes/AN-0947_MC68881_Floating-Point_Coprocessor_as_a_Peripheral_in_a_M68000_System_%5BMotorola_1987_37p%5D.pdf
--
Bernd Linsel
On Saturday, October 28, 2023 at 8:01:20 PM UTC-4, MitchAlsup wrote:
On Saturday, October 28, 2023 at 5:24:44 PM UTC-5, Branimir Maksimovic wrote:
On 2023-10-27, Opus <ifo...@youknew.org> wrote:
On 27/10/2023 18:41, Bernd Linsel wrote:
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the
68881/2 were designed for use with a 68020 (and later 68030) and not for
the 68000 itself.
<I don't remember if it was at all possible to use a 68881 with a 68000.
But maybe by "68000" you meant the 68020 and later.
68000 was 16 bit, 68020 I think 32 bit, correct me if I am wrong...<
68000 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and 16-bit data bus.
68008 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and a 8-bit data bus.
68010 was a 32-bit architecture on a 16-bit µarchitecture with a 24-bit address bus and a 16-bit data bus.
68020 was a 32-bit architecture on a 32-bit µarchitecture with a 24-bit address bus and a 32-bit data bus.
--
I think the 68008 was only a 20 bit address bus.7-77-777, Evil Sinner! https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/
The 68020 was 32 bit address bus.
- Tim
MitchAlsup <MitchAlsup@aol.com> schrieb:
On Friday, October 27, 2023 at 5:07:00 PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
On 27/10/2023 18:41, Bernd Linsel wrote:Au contraire, the -881 worked with all 68k family processors, at least
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the >>>> 68881/2 were designed for use with a 68020 (and later 68030) and not for >>>> the 68000 itself.
I don't remember if it was at all possible to use a 68881 with a 68000. >>>> But maybe by "68000" you meant the 68020 and later.
up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
That is weird, that is just setting a bit.
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Likewise, just an NEG...
It (and x87 originals) were so bad at IEEE 754 that this opened up the door to RISCs.
I think the main source of the slowness whas that both 8087 and
68881/68882 used CORDIC.
It is an interesting question what sort of performance would have
been possible with the transistor budget of the 8087, around 45000 transistors, or 155000 for the 68881, if Wikipedia is to be believed.
MitchAlsup <MitchAlsup@aol.com> schrieb:
On Friday, October 27, 2023 at 5:07:00 PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
On 27/10/2023 18:41, Bernd Linsel wrote:Au contraire, the -881 worked with all 68k family processors, at least
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the >>>> 68881/2 were designed for use with a 68020 (and later 68030) and not for >>>> the 68000 itself.
I don't remember if it was at all possible to use a 68881 with a 68000. >>>> But maybe by "68000" you meant the 68020 and later.
up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
That is weird, that is just setting a bit.
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Likewise, just an NEG...
It (and x87 originals) were so bad at IEEE 754 that this opened up the door to RISCs.
I think the main source of the slowness whas that both 8087 and
68881/68882 used CORDIC.
It is an interesting question what sort of performance would have
been possible with the transistor budget of the 8087, around 45000 transistors, or 155000 for the 68881, if Wikipedia is to be believed.
MitchAlsup <MitchAlsup@aol.com> schrieb:
On Friday, October 27, 2023 at 5:07:00 PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
On 27/10/2023 18:41, Bernd Linsel wrote:Au contraire, the -881 worked with all 68k family processors, at least
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <sc...@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the >>>> 68881/2 were designed for use with a 68020 (and later 68030) and not for >>>> the 68000 itself.
I don't remember if it was at all possible to use a 68881 with a 68000. >>>> But maybe by "68000" you meant the 68020 and later.
up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
That is weird, that is just setting a bit.
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Likewise, just an NEG...
It (and x87 originals) were so bad at IEEE 754 that this opened up the door to RISCs.
I think the main source of the slowness whas that both 8087 and
68881/68882 used CORDIC.
It is an interesting question what sort of performance would have
been possible with the transistor budget of the 8087, around 45000 transistors, or 155000 for the 68881, if Wikipedia is to be believed.
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
On 2023-10-27, Opus <ifonly@youknew.org> wrote:
On 27/10/2023 18:41, Bernd Linsel wrote:68000 was 16 bit, 68020 I think 32 bit, correct me if I am wrong...
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <scott@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page, the >>> 68881/2 were designed for use with a 68020 (and later 68030) and not for >>> the 68000 itself.
I don't remember if it was at all possible to use a 68881 with a 68000.
But maybe by "68000" you meant the 68020 and later.
68000 was 32 bit architecture on a 16 bit bus.
On 29/10/2023 02:15, Joe Pfeiffer wrote:
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
On 2023-10-27, Opus <ifonly@youknew.org> wrote:
On 27/10/2023 18:41, Bernd Linsel wrote:68000 was 16 bit, 68020 I think 32 bit, correct me if I am wrong...
On 27.10.2023 15:01, Thomas Koenig wrote:
Scott Lurndal <scott@slp53.sl.home> schrieb:
When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.
Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.
There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881
As I remember and they seem to state as well on this wikipedia page,
the
68881/2 were designed for use with a 68020 (and later 68030) and not
for
the 68000 itself.
I don't remember if it was at all possible to use a 68881 with a 68000. >>>> But maybe by "68000" you meant the 68020 and later.
68000 was 32 bit architecture on a 16 bit bus.
The 68000, IIRC, had a 16-bit ALU (as well as the 16-bit databus). The register set was 32-bit wide, and the instructions all supported 32-bit
sizes (along with 8-bit and 32-bit). But a full 32-bit ALU would have
been too big and expensive. The idea was that the architecture would be competitive with existing 16-bit devices while being "forward
compatible" with planned fully 32-bit versions.
(It is hard pick messages out of the clutter as the
denial of service attack msg flood from GG continues)
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
:
I don't remember if it was at all possible to use a 68881 with a 68000. >>>> But maybe by "68000" you meant the 68020 and later.Au contraire, the -881 worked with all 68k family processors, at least
up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time[...]
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
On 10/29/2023 9:06 PM, George Neuner wrote:
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup[...]
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
:
I don't remember if it was at all possible to use a 68881 with a 68000. >>>>> But maybe by "68000" you meant the 68020 and later.Au contraire, the -881 worked with all 68k family processors, at least >>>> up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
DICOM volumetric images?
On Mon, 30 Oct 2023 14:16:40 -0700, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 10/29/2023 9:06 PM, George Neuner wrote:
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup[...]
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote:
On 27.10.2023 22:54, Opus wrote:<
:
I don't remember if it was at all possible to use a 68881 with a 68000. >>>>>> But maybe by "68000" you meant the 68020 and later.Au contraire, the -881 worked with all 68k family processors, at least >>>>> up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
DICOM volumetric images?
Yes. We were post-processing for holographic film rendering.
On 10/31/2023 7:19 PM, George Neuner wrote:
On Mon, 30 Oct 2023 14:16:40 -0700, "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 10/29/2023 9:06 PM, George Neuner wrote:
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup[...]
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote: >>>>>> On 27.10.2023 22:54, Opus wrote:
:<
I don't remember if it was at all possible to use a 68881 with a 68000. >>>>>>> But maybe by "68000" you meant the 68020 and later.Au contraire, the -881 worked with all 68k family processors, at least >>>>>> up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
DICOM volumetric images?
Yes. We were post-processing for holographic film rendering.
Nice. I am wondering if you can you remember the general resolutions you
were working with at the time? 2048^3 resolution? Fwiw, I had to do a
lot of work in volumetrics to help me visualize some of my n-ary vector >fields. Here is some of my work for an experimental mandelbulb of mine:
https://nocache-nocookies.digitalgott.com/gallery/17/11687_15_03_15_8_18_09.jpeg
https://www.fractalforums.com/index.php?action=gallery%3Bsa%3Dview%3Bid%3D17187
:^^^
Ultimately the compute servers ended up based on 68040, but the
software was developed initially on 68030 using first 68881 and then
68882. The first units shipped with 68030/68882. We switched to
68040 when they became available
On 10/31/2023 7:19 PM, George Neuner wrote:
On Mon, 30 Oct 2023 14:16:40 -0700, "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 10/29/2023 9:06 PM, George Neuner wrote:
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup[...]
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote: >>>>>> On 27.10.2023 22:54, Opus wrote:
:<
I don't remember if it was at all possible to use a 68881 with a 68000. >>>>>>> But maybe by "68000" you meant the 68020 and later.Au contraire, the -881 worked with all 68k family processors, at least >>>>>> up to the 040.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
DICOM volumetric images?
Yes. We were post-processing for holographic film rendering.
Nice. I am wondering if you can you remember the general resolutions you
were working with at the time? 2048^3 resolution? Fwiw, I had to do a
lot of work in volumetrics to help me visualize some of my n-ary vector >fields. Here is some of my work for an experimental mandelbulb of mine:
https://nocache-nocookies.digitalgott.com/gallery/17/11687_15_03_15_8_18_09.jpeg
https://www.fractalforums.com/index.php?action=gallery%3Bsa%3Dview%3Bid%3D17187
On Tue, 31 Oct 2023 20:40:59 -0700, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 10/31/2023 7:19 PM, George Neuner wrote:
On Mon, 30 Oct 2023 14:16:40 -0700, "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 10/29/2023 9:06 PM, George Neuner wrote:
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup[...]
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote: >>>>>>> On 27.10.2023 22:54, Opus wrote:
:<
I don't remember if it was at all possible to use a 68881 with a 68000.Au contraire, the -881 worked with all 68k family processors, at least >>>>>>> up to the 040.
But maybe by "68000" you meant the 68020 and later.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
DICOM volumetric images?
Yes. We were post-processing for holographic film rendering.
Nice. I am wondering if you can you remember the general resolutions you
were working with at the time? 2048^3 resolution? Fwiw, I had to do a
lot of work in volumetrics to help me visualize some of my n-ary vector
fields. Here is some of my work for an experimental mandelbulb of mine:
https://nocache-nocookies.digitalgott.com/gallery/17/11687_15_03_15_8_18_09.jpeg
https://www.fractalforums.com/index.php?action=gallery%3Bsa%3Dview%3Bid%3D17187
Sorry, I don't remember what resolutions we were working with ... we
worked with MR, CT and radiograph imagery.
What I worked on did not need to know the source resolution because by
the time my code got the imagery, it already had been cropped to fit
the projector resolution: at most 1024x768. Depth was limited to, at
most, 80-100 slices: recall that ALL the spatial content of a hologram
gets compressed into the single interference image, so too much
content can cause the hologram to become light saturated and to lose fidelity.
Our system ultimately included front-end "workstations" running either
Linux or NetBSD (depending), and back-end "compute servers" running
VxWorks co-located with the control units in each film printer.
The workstations needed to be (reasonably) interactive - allowed no
more than a couple of seconds to update the display. They did not
even attempt to do 3D rendering, but rather provided a quick-n-dirty approximation of the hologram that would result from rendering the
selected volume in the selected orientation. The operator could
rotate and crop the volume and step through the approximated
"hologram" image, to get an idea of what would ultimately be rendered
on film.
The original idea was for the workstations to do exposure calculations directly, and just have storage and a queue manager in the film
printer. We desired to use x86 chips as much as possible because they
were cheap relative to others even in industrial SBC.
But then testing with various CPUs showed just how poor existing x86
were at doing floating point. 80386/80387 was unacceptably slow even
just doing the display approximations. Fast 80486dx could manage
display for our initial target resolutions - but we expected
resolutions to increase, and even the fastest 80486 was not capable to
do exposure calculations in any reasonable amount of time. In the
end, we went with Pentium [still expensive at the time] and dropped
the whole notion of workstations doing the exposure calculations.
when we realized just how ridiculously long even average exposure calculations would take on a PC , we knew that this solution was was
not viable: computing in the background while letting the operator
continue working would delay the time to start printing unacceptably
in an emergency situation where the operator might want to quickly
produce multiple films from different orientations/croppings of the
same volume. Conversely, computing in the foreground would delay the operator for unacceptable periods which would interfere with "normal" operation where the operator was expected to take care of several
patients and then sit down to do reviews and make films.
We could have provided both options, but switching between them in an emergency situation could have been complicated, so we decided it
would be better to go with a dedicated compute server on the back end.
Once that decision was made, we explored how best to do it (with
reasonable cost), and after some experimenting we realized that the 68030/68882 was so much faster that it would be able to serve multiple
80386 workstations in the normal case, and not delay prints beyond availability of the projector unit in the emergency case.
Final rotated/cropped volumes would be sent to the film printer. The
"lens" [actually a clear LCD] could be moved in 1mm increments to
expose the film, so ray tracing was performed to determine the desired contents of each pixel on 1mm deep slice of the final hologram, and
from there to determine
Then calculations were done to determine what points actually needed
to be exposed to produce the desired interference image on film.
, and how bright each point needed to be. And finally it took the
point information and mapped that onto movements of the LCD and
shutter times for the laser.
That produced a hologram "negative" which, once developed, could be
used repeatedly to make "positive" holograms. The holograms were, by
design, dimensionally accurate: 1cm in the source volume was 1cm in
the hologram. In practice it was limited to, roughly, a 20cm cube
centered on the plane of the film [yes, the film could be reversed on
the viewer to to see what was "behind" it].
On Tue, 31 Oct 2023 20:40:59 -0700, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 10/31/2023 7:19 PM, George Neuner wrote:
On Mon, 30 Oct 2023 14:16:40 -0700, "Chris M. Thomasson"
<chris.m.thomasson.1@gmail.com> wrote:
On 10/29/2023 9:06 PM, George Neuner wrote:
On Fri, 27 Oct 2023 17:43:05 -0700 (PDT), MitchAlsup[...]
<MitchAlsup@aol.com> wrote:
On Friday, October 27, 2023 at 5:07:00?PM UTC-5, Bernd Linsel wrote: >>>>>>> On 27.10.2023 22:54, Opus wrote:
:<
I don't remember if it was at all possible to use a 68881 with a 68000.Au contraire, the -881 worked with all 68k family processors, at least >>>>>>> up to the 040.
But maybe by "68000" you meant the 68020 and later.
Where "worked" meant that::
FABS was 35 cycles !!
FADD was 51 cycles !!
FMUL was 71 cycles !!
heck even FNEG was 35 cycles !!!
Which still was much faster than doing it in software on the CPU.
Mid 90's to 2000 I was doing a lot of medical imaging. At that time
MRI 'pixels' were 32-bit floating point and we were starting to see
64-bit pixels on the latest units.
DICOM volumetric images?
Yes. We were post-processing for holographic film rendering.
Nice. I am wondering if you can you remember the general resolutions you
were working with at the time? 2048^3 resolution? Fwiw, I had to do a
lot of work in volumetrics to help me visualize some of my n-ary vector
fields. Here is some of my work for an experimental mandelbulb of mine:
https://nocache-nocookies.digitalgott.com/gallery/17/11687_15_03_15_8_18_09.jpeg
https://www.fractalforums.com/index.php?action=gallery%3Bsa%3Dview%3Bid%3D17187
Sorry, I don't remember what resolutions we were working with ... we
worked with MR, CT and radiograph imagery.
What I worked on did not need to know the source resolution because by
the time my code got the imagery, it already had been cropped to fit
the projector resolution: at most 1024x768. Depth was limited to, at
most, 80-100 slices: recall that ALL the spatial content of a hologram
gets compressed into the single interference image, so too much
content can cause the hologram to become light saturated and to lose fidelity.
Our system ultimately included front-end "workstations" running either
Linux or NetBSD (depending), and back-end "compute servers" running
VxWorks co-located with the control units in each film printer.
The workstations needed to be (reasonably) interactive - allowed no
more than a couple of seconds to update the display. They did not
even attempt to do 3D rendering, but rather provided a quick-n-dirty approximation of the hologram that would result from rendering the
selected volume in the selected orientation. The operator could
rotate and crop the volume and step through the approximated
"hologram" image, to get an idea of what would ultimately be rendered
on film.
The original idea was for the workstations to do exposure calculations directly, and just have storage and a queue manager in the film
printer. We desired to use x86 chips as much as possible because they
were cheap relative to others even in industrial SBC.
But then testing with various CPUs showed just how poor existing x86
were at doing floating point. 80386/80387 was unacceptably slow even
just doing the display approximations. Fast 80486dx could manage
display for our initial target resolutions - but we expected
resolutions to increase, and even the fastest 80486 was not capable to
do exposure calculations in any reasonable amount of time. In the
end, we went with Pentium [still expensive at the time] and dropped
the whole notion of workstations doing the exposure calculations.
when we realized just how ridiculously long even average exposure calculations would take on a PC , we knew that this solution was was
not viable: computing in the background while letting the operator
continue working would delay the time to start printing unacceptably
in an emergency situation where the operator might want to quickly
produce multiple films from different orientations/croppings of the
same volume. Conversely, computing in the foreground would delay the operator for unacceptable periods which would interfere with "normal" operation where the operator was expected to take care of several
patients and then sit down to do reviews and make films.
We could have provided both options, but switching between them in an emergency situation could have been complicated, so we decided it
would be better to go with a dedicated compute server on the back end.
Once that decision was made, we explored how best to do it (with
reasonable cost), and after some experimenting we realized that the 68030/68882 was so much faster that it would be able to serve multiple
80386 workstations in the normal case, and not delay prints beyond availability of the projector unit in the emergency case.
Final rotated/cropped volumes would be sent to the film printer. The
"lens" [actually a clear LCD] could be moved in 1mm increments to
expose the film, so ray tracing was performed to determine the desired contents of each pixel on 1mm deep slice of the final hologram, and
from there to determine
Then calculations were done to determine what points actually needed
to be exposed to produce the desired interference image on film.
, and how bright each point needed to be. And finally it took the
point information and mapped that onto movements of the LCD and
shutter times for the laser.
That produced a hologram "negative" which, once developed, could be
used repeatedly to make "positive" holograms. The holograms were, by
design, dimensionally accurate: 1cm in the source volume was 1cm in
the hologram. In practice it was limited to, roughly, a 20cm cube
centered on the plane of the film [yes, the film could be reversed on
the viewer to to see what was "behind" it].
Michael S <already5chosen@yahoo.com> schrieb:<
On Friday, October 13, 2023 at 10:13:25 PM UTC+3, John Dallman wrote:
Gone: MIPS, PA-RISC, Alpha, 68000.
68K still sold today in form of ColdFire. But those are microcontrollers
rather than general-purpose computers.
ColdFire does not implement the whole 68000 instruction set
(at least according to Wikipedia), some instructions and some
addressing modes are not implemented.
On 11/1/2023 4:46 PM, George Neuner wrote:
[...]
Excellent, thanks for you the info! Btw, do you mind if I ask you some >technical questions from time to time? Can any volumetric image be
converted into a hologram? I think so...
On Wed, 8 Nov 2023 23:26:01 -0800, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 11/1/2023 4:46 PM, George Neuner wrote:
[...]
Excellent, thanks for you the info! Btw, do you mind if I ask you some
technical questions from time to time? Can any volumetric image be
converted into a hologram? I think so...
I believe you are correct that any volumetric image can be rendered as
a hologram, but I can't say for certain ... I haven't really studied
it enough.
A company I was working for at that time was contracted to implement
the software and UI side of the hologram project. Our main business
was in machine vision - mainly industrial QA/QC - but from that we had
both image processing experience and also industry connections to
printing technology.
The NDAs are long expired, so I can talk about [the parts I know of]
what we did, but wrt the image processing, apart from some system
specific implementation tweaks, we were just following someone else's recipes.
MitchAlsup <MitchAlsup@aol.com> schrieb:<
On Saturday, October 14, 2023 at 1:17:44 PM UTC-5, BGB wrote:
On 10/14/2023 11:33 AM, Michael S wrote:<
On Friday, October 13, 2023 at 9:13:04 PM UTC+3, John Levine wrote:I also personally have difficulty imagining what exactly one could do in >>> a CPU that would give it much advantage for database tasks that would
According to John Dallman <j...@cix.co.uk>:
Overall, Oracle's vertical integration plan for making their database >>> >>> work better on their own hardware was not a success. It turned out that >>> >>> Oracle DB and SPARC Solaris were already pretty well-tuned for each other,What could they do that would make it better than an ARM or RISC V chip >>> >> running at the same speed? Transactional memory?
and there were no easy gains there.
It seems, by time of acquisition (late 2009) it was already know internally
that Rock (SPARC processor with TM support) is doomed. Although it was not
enounced publicly until next year.
not otherwise make sense with a general purpose CPU.
Bigger caches and a slower clock rate help data base but do not help general >> purpose. More slower CPUs and thinner cache hierarchy helps. Less prediction >> helps too.
<
So, instead of 64KB L1s and 1MB L2s and 8MB L3s:: do a 256KB L1 and
8MB L2 with no L3s.
<
It does not mater how fast the clock rate is if you are waiting for memory to
respond.
Hm, but 256k L1 would increase the L1 latency, correct?
Maybe this is a reason why SMT is popular in certain processors:
If a core is waiting for memory, it might as well switch to another
thread for which the outstanding request has already arrived.
Another reason, I'm told, is that SMT can be a reaction to<
software licensing - some licenses in the commercial field are
are paid per physical core, and if SMT can squeeze out a few
percent of performance, even a more expensive processor might be
more cost-effective.
In article <c2399332-9696-4749-adc4-8d9b071c060dn@googlegroups.com>, already5chosen@yahoo.com (Michael S) wrote:<
Growing, but not yet fully-established: RISC-V.Is RISC-V really present in general-purpose computing?
Not yet, but it seems to have an adequate design and enough momentum to
get there. /Staying/ there is a different question.
<In established niches, but not growing out of them: POWER, IBM Z.IBM POWER - not sure about it. POWER holds on for as long as IBM
able to make POWER chips that are competitive (or better exceeding)
x86-64 and ARM64 in absolute performance and at the same time not
ridiculously behind in price/performance. It looks to me like POWER
is in the same rat race that effectively killed SPARC and IPF. They
just manage to run a little better.
It's also used to run IBM i, which is a pretty big niche that's quite
easy to forget. It could be replaced, since the concept of the system is
that the hardware is replaceable, but IBM would try hard to avoid the
costs of doing that.
John
If I buy a Lathe, I can use it forever.And talk to farmers who bought a John Deere tractor and need to fix it.
If I buy a SW license, I cannot use it forever.
See the problem here.
On 11/12/23 13:19, MitchAlsup wrote:<
If I buy a Lathe, I can use it forever.And talk to farmers who bought a John Deere tractor and need to fix it.
If I buy a SW license, I cannot use it forever.
See the problem here.
Brian G. Lucas wrote:
On 11/12/23 13:19, MitchAlsup wrote:<
If I buy a Lathe, I can use it forever.And talk to farmers who bought a John Deere tractor and need to fix it.
If I buy a SW license, I cannot use it forever.
See the problem here.
Had they bought one from the 1980's they would have no problem fixing it.
<
And John Deere is doing their brand no favors with this newish policy.
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still running Windows XP), although if it is licensed to a particular hardware system,
that system's life may limit your use, and you may not get vendor support.
But I think the problem you are referring to is the limit on the number
of copies you can make, or simultaneous users you can have.
this is due to the obvious difference that, as opposed to a lathe, it is trivial to make an arbitrary number of copies, or have multiple
different users use it simultaneously. This difference accounts for the different licensing terms. It makes things better for the software
vendor, which, at least in theory, allows for more software to be created.
Of course, YMMV
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile
I love this part:
Note This function is a Microsoft-specific extension to the Windows
Sockets specification.
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile
On 11/13/2023 2:44 PM, Stefan Monnier wrote:
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile
I love this part:
Note This function is a Microsoft-specific extension to the Windows
Sockets specification.
Comic relief, indeed!
Fwiw, I love this part as well:
_______________________
Server versions of Windows optimize the TransmitFile function for high performance. On server versions, there are no default limits placed on
the number of concurrent TransmitFile operations allowed on the system. Expect better performance results when using TransmitFile on server
versions of Windows.
_______________________
;^D
I guess, it "would be" a similar situation with the newer PlayStation
and XBox consoles, except that I guess Sony and MS have been keeping
the servers alive (so PS3 and XBox360 still work), but sucks if
a person is running a Wii or WiiU or similar (apparently, these are
all scheduled go offline in 2024).
But, hardware depending on online servers to work, will not last
forever, in any case.
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still running Windows XP), although if it is licensed to a particular hardware system,
that system's life may limit your use, and you may not get vendor support.
But I think the problem you are referring to is the limit on the number
of copies you can make, or simultaneous users you can have. Of course,
this is due to the obvious difference that, as opposed to a lathe, it is trivial to make an arbitrary number of copies, or have multiple
different users use it simultaneously. This difference accounts for the different licensing terms. It makes things better for the software
vendor, which, at least in theory, allows for more software to be created.
I guess, it "would be" a similar situation with the newer PlayStation
and XBox consoles, except that I guess Sony and MS have been keeping
the servers alive (so PS3 and XBox360 still work), but sucks if
a person is running a Wii or WiiU or similar (apparently, these are
all scheduled go offline in 2024).
I suspect the Wii shouldn't be affected because AFAIK mine's never been connected to the Internet (I blacklisted its MAC address) yet it's
worked fine for the games we bought.
Maybe some of the games require some remote service, but definitely not
all of them.
But, hardware depending on online servers to work, will not last
forever, in any case.
Proprietary software is a curse, indeed.
On 11/13/2023 4:00 PM, Stephen Fuld wrote:Yes
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still running
Windows XP), although if it is licensed to a particular hardware system,
that system's life may limit your use, and you may not get vendor support. >>
But I think the problem you are referring to is the limit on the number
of copies you can make, or simultaneous users you can have. Of course,
this is due to the obvious difference that, as opposed to a lathe, it is
trivial to make an arbitrary number of copies, or have multiple
different users use it simultaneously. This difference accounts for the
different licensing terms. It makes things better for the software
vendor, which, at least in theory, allows for more software to be created. >>
Yeah, this is a fundamental difference...
To copy a lathe would require the time and expense both to buy all of
the materials and machine all the parts.
Then one may find that it ends up costing more than it would have costInvariably
just to buy another one.
And, despite the lathes and mills typically costing $k, one isYes
hard-pressed to make something of comparable quality for cheaper.
For stability, one needs things like a lot of weight, and the OEM has<
the advantage that they can cost-effectively sand-cast big chunks of
cast iron (where cheaply making big cast iron parts is a technology
mostly out of reach of home shops).
Other alternatives are things like:
Abrasive sand (such as garnet sand or slag) mixed with epoxy:
Not cheap;
Concrete: Not very good;
Needs to be encased in metal or epoxy to not suck;
One may still need garnet sand or slag for the needed density;
Silica sand is cheaper, but not really dense enough.
If the machine is too light, then it would rattle or vibrate excessively during cuts (AKA: chatter) which would ruin the quality of the machined parts.
Though, I guess if a person had access to a waterjet, they could cut the parts out of a bunch of steel plate as layers, and then braze all the
layers together. Labor would likely still cost more than being able to
pour cast iron though.
For other parts, having machines purpose built to make one specific part
will make those parts cheaper than using more general purpose machines
to make all the parts.
....
So, say, I don't really fault Grizzly or Tormach for the cost of their machines, it is unlikely they could make them for all that much cheaper
and still make a profit.
Though, now having one of the Tormach CNC machines, limits can still be noted:
Tries to use a 1/2 inch drill on some stainless steel:
Say, to enlarge a hole from 3/8 to 1/2 inch.
Starts to drill, eats into steel a little, spindle: "NOPE!",
Spindle stalls and machine goes into a faulted state.
So, one needs to go: 1/4" (OK), 3/8" (Also OK), to 7/16".
And then mill the hole the rest of the way via an endmill.
Say, because 1.5 kW at 10k RPM (in high range), doesn't mean it can
drill a 1/2" hole at 700 RPM. Granted, this works out to around 1 lb-ft
or 192 oz-in of torque (so, not very much torque even by cordless drill standards).
Well, or one can put it into low range by manually moving a belt, but
this kinda sucks as well, as then one has the torque to run the drill,
but not really enough RPM range for the endmill, ... (too bad, say, they couldn't have put a CVT or similar in the thing).
So, say, vs a CNC converted Bridgeport:<
Tormach:
+ Tighter tolerances
Holds +/- 0.005 easily
Smaller is still hard (+/- 0.002 is still pushing it)
+ Has flood coolant;
+ Has tool changer;
+ Can dynamically change RPM.
- Less travel.
+ Though, still more than my G0704 (at least in Y and Z).
+ Faster
Can make quick work of aluminum and similar, ...
- Not so much torque.
Works fine if mostly using 1/8, 3/16, and 1/4 inch endmills.
7/16 and 5/8 (*2), don't get too aggressive here with cuts.
3/4: Only if you are milling plastic...
Bridgeport:
- Maybe gets +/- 0.005 if you are feeling lucky
+/- 0.015 mostly OK.
+ More powerful spindle;
Not much issue drilling holes in steel.
+ More X/Y/Z travel;
- No coolant;
- RPM is controlled by moving V belts.
- Using R8 collets and drawbar sucks.
- The software is buggy and likes to crash frequently, ...
*2: Machine came with some ER20 tool holders (in BT30), but these can't handle larger tools. Also got some ER32 / BT30 tool holders, which can<
handle 5/8 and 3/4" tools, but these can't really be used for general
purpose milling (bigger tools being more for if one needs a lot more
flute length).
I guess, one can use a shell-mill/face-mill, but one is limited to<
fairly small face mills and fairly light cuts (mostly defeating the
advantage vs going back and forth using a 7/16 or 5/8 mill or similar).
Contrast, the G0704 will try to spin a bigger mill, but the machine will<
just sorta rattle and hop all over the place while doing so.
BGB wrote:
On 11/13/2023 4:00 PM, Stephen Fuld wrote:
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed to
a lathe, it is trivial to make an arbitrary number of copies, or have
multiple different users use it simultaneously. This difference
accounts for the different licensing terms. It makes things better
for the software vendor, which, at least in theory, allows for more
software to be created.
Yeah, this is a fundamental difference...
To copy a lathe would require the time and expense both to buy all ofYes
the materials and machine all the parts.
Then one may find that it ends up costing more than it would have costInvariably
just to buy another one.
And, despite the lathes and mills typically costing $k, one isYes
hard-pressed to make something of comparable quality for cheaper.
For stability, one needs things like a lot of weight, and the OEM has
the advantage that they can cost-effectively sand-cast big chunks of
cast iron (where cheaply making big cast iron parts is a technology
mostly out of reach of home shops).
Other alternatives are things like:
Abrasive sand (such as garnet sand or slag) mixed with epoxy:
Not cheap;
Concrete: Not very good;
Needs to be encased in metal or epoxy to not suck;
One may still need garnet sand or slag for the needed density;
Silica sand is cheaper, but not really dense enough.
If the machine is too light, then it would rattle or vibrate<
excessively during cuts (AKA: chatter) which would ruin the quality of
the machined parts.
It is not weight per seé, it is stiffness between the piece holding the
part
and the spindle applying forces to remove chips from the part.
<
Though, I guess if a person had access to a waterjet, they could cut
the parts out of a bunch of steel plate as layers, and then braze all
the layers together. Labor would likely still cost more than being
able to pour cast iron though.
For other parts, having machines purpose built to make one specific
part will make those parts cheaper than using more general purpose
machines to make all the parts.
....
So, say, I don't really fault Grizzly or Tormach for the cost of their
machines, it is unlikely they could make them for all that much
cheaper and still make a profit.
Though, now having one of the Tormach CNC machines, limits can still
be noted:
Tries to use a 1/2 inch drill on some stainless steel:
Say, to enlarge a hole from 3/8 to 1/2 inch.
Starts to drill, eats into steel a little, spindle: "NOPE!",
Spindle stalls and machine goes into a faulted state.
So, one needs to go: 1/4" (OK), 3/8" (Also OK), to 7/16".
And then mill the hole the rest of the way via an endmill.
Say, because 1.5 kW at 10k RPM (in high range), doesn't mean it can
drill a 1/2" hole at 700 RPM. Granted, this works out to around 1
lb-ft or 192 oz-in of torque (so, not very much torque even by
cordless drill standards).
Well, or one can put it into low range by manually moving a belt, but
this kinda sucks as well, as then one has the torque to run the drill,
but not really enough RPM range for the endmill, ... (too bad, say,
they couldn't have put a CVT or similar in the thing).
So, say, vs a CNC converted Bridgeport:<
Tormach:
+ Tighter tolerances
Holds +/- 0.005 easily
Smaller is still hard (+/- 0.002 is still pushing it)
+ Has flood coolant;
+ Has tool changer;
+ Can dynamically change RPM.
- Less travel.
+ Though, still more than my G0704 (at least in Y and Z).
+ Faster
Can make quick work of aluminum and similar, ...
- Not so much torque.
Works fine if mostly using 1/8, 3/16, and 1/4 inch endmills.
7/16 and 5/8 (*2), don't get too aggressive here with cuts.
3/4: Only if you are milling plastic...
Bridgeport:
- Maybe gets +/- 0.005 if you are feeling lucky
+/- 0.015 mostly OK.
+ More powerful spindle;
Not much issue drilling holes in steel.
+ More X/Y/Z travel;
- No coolant;
- RPM is controlled by moving V belts.
- Using R8 collets and drawbar sucks.
- The software is buggy and likes to crash frequently, ...
The difference between 0.005 and 0.001 on a Bridgeport is metrology and
care. If you can't measure something you cannot compensate for it--this
goes double during setup where you sweep the clamped part to determine
that it is held flat in the vise and normal to the milling direction.
<
*2: Machine came with some ER20 tool holders (in BT30), but these<
can't handle larger tools. Also got some ER32 / BT30 tool holders,
which can handle 5/8 and 3/4" tools, but these can't really be used
for general purpose milling (bigger tools being more for if one needs
a lot more flute length).
I have a whole set of ER-40 collets an R8 spindle adapter and a 5C adapter
so the collets can be used in Mill or lathe.
<
I guess, one can use a shell-mill/face-mill, but one is limited to<
fairly small face mills and fairly light cuts (mostly defeating the
advantage vs going back and forth using a 7/16 or 5/8 mill or similar).
Granted a Bridgeport is limited, but so are 100,000 pound 36" lathes with 75-foot beds run by 50 HP motors.
<
Contrast, the G0704 will try to spin a bigger mill, but the machine<
will just sorta rattle and hop all over the place while doing so.
So, you mill in smaller chunks. I have a fly cutter than can cut 4140 at
5" width on my G0704--albeit far from the speeds and feeds appropriate
for a Cincinnati doing the same job.....
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still running Windows XP), although if it is licensed to a particular hardware system, that system's life may limit your use, and you may not get vendor support.
But I think the problem you are referring to is the limit on the number
of copies you can make, or simultaneous users you can have. Of course, this is due to the obvious difference that, as opposed to a lathe, it is trivial to make an arbitrary number of copies, or have multiple
different users use it simultaneously. This difference accounts for the different licensing terms. It makes things better for the software
vendor, which, at least in theory, allows for more software to be created.
Stephen Fuld wrote:
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have. Of
course, this is due to the obvious difference that, as opposed to a
lathe, it is trivial to make an arbitrary number of copies, or have
multiple different users use it simultaneously. This difference
accounts for the different licensing terms. It makes things better
for the software vendor, which, at least in theory, allows for more
software to be created.
I am still using my licensed version of Photoshop CS2, which is almost
20 years old. It was the last version with a permanent license but in
order to transfer the SW to a new PC I had to contact Adobe's license servers.
After 5-10 years they terminated the last remaining license server but instead allowed owners to download a personal copy that does not require licensing. I am guessing it could be watermarked with my personal
details so it could be traced?
On 11/14/2023 1:02 AM, Terje Mathisen wrote:
Stephen Fuld wrote:
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed to
a lathe, it is trivial to make an arbitrary number of copies, or have
multiple different users use it simultaneously. This difference
accounts for the different licensing terms. It makes things better
for the software vendor, which, at least in theory, allows for more
software to be created.
I am still using my licensed version of Photoshop CS2, which is almost
20 years old. It was the last version with a permanent license but in
order to transfer the SW to a new PC I had to contact Adobe's license
servers.
After 5-10 years they terminated the last remaining license server but
instead allowed owners to download a personal copy that does not
require licensing. I am guessing it could be watermarked with my
personal details so it could be traced?
For a while, I had been using "Cool Edit Pro" for audio editing, but
what eventually wrecked this was it no longer working natively after
Windows moved to 64 bits, and the lack of any really good/convenient
ways of emulating older versions of Windows which:
Continued to still work;
Allowed some way to share files between the host machine and VM.
For whatever reason, I have had very little success getting hardware virtualization to work, and all the "mainstream" VMs went over to
requiring it, eventually leaving me with little real option other than
QEMU and DOSBox (running Windows 3.11).
Then ended up mostly going over to Audacity (pros/cons apparently).
Then, in more recent years, someone had released something (as a sort of Windows plug-in) to make Win16 software work again on 64-bit Windows.
But, haven't felt much need to go back to Cool Edit, but the old MS
BitEdit and PalEdit tools lack any good modern equivalent (basically,
sort of like Paint, but built specifically for 16-color and 256-color
bitmap images, with direct control over the color palette and operating directly in terms of said palette).
Newer programs like Paint.NET can be used in a vaguely similar way, but
lacks the ability to work explicitly with a 16 or 256 color palette (nor
any real usable support for indexed-color graphics).
Similarly "GraphX2" seems to be in a vaguely similar direction, but its
UI is very weird (apparently inspired by some programs on the Amiga).
Could almost write a tool for this, but it would be "pretty niche" in
any case (and if it were a popular use-case, presumably someone else
would have done so?...).
Sometimes, there are cases where one wants to work with low-res graphics
in terms of individual pixels and a fixed color palette (rather than
high-res true-color graphics). Needing to use another image specifically
as a color palette in an otherwise true-color oriented program is
annoying and counter-productive.
Maybe also useful would be an option for it to also be able to display
pixel data in binary or hexadecimal, or load/dump images in a
hexadecimal notation (bonus points if in a C based notation), ...
...
On 11/14/2023 1:02 AM, Terje Mathisen wrote:
Stephen Fuld wrote:
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you
*can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed to
a lathe, it is trivial to make an arbitrary number of copies, or have
multiple different users use it simultaneously. This difference
accounts for the different licensing terms. It makes things better
for the software vendor, which, at least in theory, allows for more
software to be created.
I am still using my licensed version of Photoshop CS2, which is almost
20 years old. It was the last version with a permanent license but in
order to transfer the SW to a new PC I had to contact Adobe's license
servers.
After 5-10 years they terminated the last remaining license server but
instead allowed owners to download a personal copy that does not
require licensing. I am guessing it could be watermarked with my
personal details so it could be traced?
For a while, I had been using "Cool Edit Pro" for audio editing, but
what eventually wrecked this was it no longer working natively after
Windows moved to 64 bits, and the lack of any really good/convenient
ways of emulating older versions of Windows which:
Continued to still work;
Allowed some way to share files between the host machine and VM.
For whatever reason, I have had very little success getting hardware virtualization to work, and all the "mainstream" VMs went over to
requiring it, eventually leaving me with little real option other than
QEMU and DOSBox (running Windows 3.11).
Then ended up mostly going over to Audacity (pros/cons apparently).
Then, in more recent years, someone had released something (as a sort of Windows plug-in) to make Win16 software work again on 64-bit Windows.
But, haven't felt much need to go back to Cool Edit, but the old MS
BitEdit and PalEdit tools lack any good modern equivalent (basically,
sort of like Paint, but built specifically for 16-color and 256-color
bitmap images, with direct control over the color palette and operating directly in terms of said palette).
Newer programs like Paint.NET can be used in a vaguely similar way, but
lacks the ability to work explicitly with a 16 or 256 color palette (nor
any real usable support for indexed-color graphics).
Similarly "GraphX2" seems to be in a vaguely similar direction, but its
UI is very weird (apparently inspired by some programs on the Amiga).
Could almost write a tool for this, but it would be "pretty niche" in
any case (and if it were a popular use-case, presumably someone else
would have done so?...).
Sometimes, there are cases where one wants to work with low-res graphics
in terms of individual pixels and a fixed color palette (rather than
high-res true-color graphics). Needing to use another image specifically
as a color palette in an otherwise true-color oriented program is
annoying and counter-productive.
Maybe also useful would be an option for it to also be able to display
pixel data in binary or hexadecimal, or load/dump images in a
hexadecimal notation (bonus points if in a C based notation), ...
...
On 11/13/2023 8:06 PM, MitchAlsup wrote:
BGB wrote:
On 11/13/2023 4:00 PM, Stephen Fuld wrote:Yes
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses, you >>>> *can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed to
a lathe, it is trivial to make an arbitrary number of copies, or have
multiple different users use it simultaneously. This difference
accounts for the different licensing terms. It makes things better
for the software vendor, which, at least in theory, allows for more
software to be created.
Yeah, this is a fundamental difference...
To copy a lathe would require the time and expense both to buy all of
the materials and machine all the parts.
Then one may find that it ends up costing more than it would have costInvariably
just to buy another one.
And, despite the lathes and mills typically costing $k, one isYes
hard-pressed to make something of comparable quality for cheaper.
For stability, one needs things like a lot of weight, and the OEM has<
the advantage that they can cost-effectively sand-cast big chunks of
cast iron (where cheaply making big cast iron parts is a technology
mostly out of reach of home shops).
Other alternatives are things like:
Abrasive sand (such as garnet sand or slag) mixed with epoxy:
Not cheap;
Concrete: Not very good;
Needs to be encased in metal or epoxy to not suck;
One may still need garnet sand or slag for the needed density;
Silica sand is cheaper, but not really dense enough.
If the machine is too light, then it would rattle or vibrate
excessively during cuts (AKA: chatter) which would ruin the quality of
the machined parts.
It is not weight per seé, it is stiffness between the piece holding the
part
and the spindle applying forces to remove chips from the part.
<
Or, some combination of machine stiffness, inertia, and having enough weight+inertia to keep the thing firmly anchored in place on the floor.
Like, when I tried at one point to mill steel with a 1" ballnose endmill
on a CNC converted G0704, I quickly stopped this as, as soon as the
endmill started cutting the steel, it seemed like the whole thing was
going to rattle itself apart...
Though, I guess if a person had access to a waterjet, they could cut
the parts out of a bunch of steel plate as layers, and then braze all
the layers together. Labor would likely still cost more than being
able to pour cast iron though.
For other parts, having machines purpose built to make one specific
part will make those parts cheaper than using more general purpose
machines to make all the parts.
....
So, say, I don't really fault Grizzly or Tormach for the cost of their
machines, it is unlikely they could make them for all that much
cheaper and still make a profit.
Though, now having one of the Tormach CNC machines, limits can still
be noted:
Tries to use a 1/2 inch drill on some stainless steel:
Say, to enlarge a hole from 3/8 to 1/2 inch.
Starts to drill, eats into steel a little, spindle: "NOPE!",
Spindle stalls and machine goes into a faulted state.
So, one needs to go: 1/4" (OK), 3/8" (Also OK), to 7/16".
And then mill the hole the rest of the way via an endmill.
Say, because 1.5 kW at 10k RPM (in high range), doesn't mean it can
drill a 1/2" hole at 700 RPM. Granted, this works out to around 1
lb-ft or 192 oz-in of torque (so, not very much torque even by
cordless drill standards).
Well, or one can put it into low range by manually moving a belt, but
this kinda sucks as well, as then one has the torque to run the drill,
but not really enough RPM range for the endmill, ... (too bad, say,
they couldn't have put a CVT or similar in the thing).
So, say, vs a CNC converted Bridgeport:<
Tormach:
+ Tighter tolerances
Holds +/- 0.005 easily
Smaller is still hard (+/- 0.002 is still pushing it)
+ Has flood coolant;
+ Has tool changer;
+ Can dynamically change RPM.
- Less travel.
+ Though, still more than my G0704 (at least in Y and Z). >>> + Faster
Can make quick work of aluminum and similar, ...
- Not so much torque.
Works fine if mostly using 1/8, 3/16, and 1/4 inch endmills.
7/16 and 5/8 (*2), don't get too aggressive here with cuts.
3/4: Only if you are milling plastic...
Bridgeport:
- Maybe gets +/- 0.005 if you are feeling lucky
+/- 0.015 mostly OK.
+ More powerful spindle;
Not much issue drilling holes in steel.
+ More X/Y/Z travel;
- No coolant;
- RPM is controlled by moving V belts.
- Using R8 collets and drawbar sucks.
- The software is buggy and likes to crash frequently, ...
The difference between 0.005 and 0.001 on a Bridgeport is metrology and
care. If you can't measure something you cannot compensate for it--this
goes double during setup where you sweep the clamped part to determine
that it is held flat in the vise and normal to the milling direction.
<
The Bridgeport in this case was modified to use ballscrews, with NEMA34 steppers (IIRC, 1740 oz-in) connected to the leadscrews via timing belts
and pulleys (similar setup on my G0704; just using 470 oz-in NEMA23 motors).
Both machines can get "in the area" of 0.005", but don't seem to get
this with much repeatability (say, one cuts the same hole, and one time
it might be 0.004 over, or 0.004 under, or, ...).
Things like rotating a feature, changing the feedrate, etc, may also
effect what size it cuts.
This seems to be less of an issue on the Tormach machine (1100MX), which seems to usually get +/- 0.001, but for parts asking for this, this is
more of a problem.
Though, have noted that feedrate does effect accuracy (it seems to cut a little oversize if using faster feedrates or deeper cuts).<
Some settings I had found that seem to work fairly well (on the Tormach):
Aluminum with 3/16 endmill:
RPM: 6500
Feed: 17.0 inch/minute
Depth: 0.015
Aluminum with 1/8 endmill:
RPM: 8500
Feed: 19.0
Depth: 0.010
...
For the Bridgeport, was generally using (for 1/8 and 3/16):
RPM: ~ 3000
Feed: 6.5 inch/minute
Depth: 0.010
The G0704 is hard-pressed to go much over around 1500 RPM, so ~ 3.0 inch/minute.
It is possibly to go a little faster, but doing so has drawbacks:
Less accurate cuts;
Worse burrs;
Higher risk of breaking the endmills.
For steel, I usually reduce the depth of cut to around 0.005, but can
get away with 0.010 or 0.015 for bigger endmills. RPM and feedrate need
to be reduced by around half.
For stainless steel, need to go down lower (to around 1/3).
For brass, around 2/3 or 3/4 the speeds used for aluminum.
*2: Machine came with some ER20 tool holders (in BT30), but these<
can't handle larger tools. Also got some ER32 / BT30 tool holders,
which can handle 5/8 and 3/4" tools, but these can't really be used
for general purpose milling (bigger tools being more for if one needs
a lot more flute length).
I have a whole set of ER-40 collets an R8 spindle adapter and a 5C adapter >> so the collets can be used in Mill or lathe.
<
OK.
Don't have any ER40, mostly ER20 and ER32.
Ended up getting several sets of ER collets, mostly so that one can set
up multiple tools of the same size.
I guess, one can use a shell-mill/face-mill, but one is limited to<
fairly small face mills and fairly light cuts (mostly defeating the
advantage vs going back and forth using a 7/16 or 5/8 mill or similar).
Granted a Bridgeport is limited, but so are 100,000 pound 36" lathes with
75-foot beds run by 50 HP motors.
<
I was talking about the Tormach here.
The Bridgeport is at an advantage in terms of "raw power", since while
it has the same theoretical motor power as the Tormach, it is geared
down with belts (so, more effective/usable power). Putting high load on
the spindle on the Bridgeport also doesn't cause the machine to go "Oh
Crap!" and immediately fault out (for better or for worse).
So, say:
Bridgeport: 2 HP 3-Phase, driven via a VFD, with belts.
Generally, was keeping the VFD in the 50-70 Hz range,
using the belts for coarse adjustment.
Travel: 30 x 14 x 16
Tormach: 1.5 kW Servo (~ 2 HP), powered off 230 VAC single phase.
However, spindle seems to be "Requested speed or die immediately".
So, the spindle doesn't slow down, it stops and the machine faults.
Its belt only has too positions:
200 .. 10000 RPM, with weak torque;
40 .. 2000 RPM, slower but more torque.
Travel: 17 x 10 x 16
G0704: 1 HP PMDC motor.
High Range: ~ 0 .. 1500 RPM (depends on temperature)
Low Range: ~ 0 .. 500 RPM (IIRC).
Travel: 18 x 6 x 11
Though, the ballscrew conversion negatively effected Y travel,
So mine is only ~ 4 inch.
Despite having a theoretically weaker motor, the G0704 is still a bit
more capable in terms of "put a hole in this piece of steel using this drill".
Like, it can in-fact drill a 1/2 inch hole in a piece of steel...
Vs, say, needing to circular interpolate the hole using a 7/16 endmill
(a lot slower, but needs a lot less torque).
Granted, for its weaknesses in terms of torque and similar, the Tormach
does win in terms of having flood coolant and an automatic tool changer
and similar (and a lot cheaper than any of the Haas machines).
Granted, it is preferable to have the machine be like "Oh Crap!" and
fault, than try to continue on and break the tool (it is still plenty
well capable of snapping 1/8 inch and 3/16 mills and similar, or
snapping off a 7/64 bit if it gets stuck, ...).
But, it seems like there is a fair bit of a power differential between, say:
Snapping off a 7/64;
Stalling on a 3/8 bit;
Actually drilling a hole with 1/2.
It does also at least still at least beat the "put holes in stuff" power
of a cordless Drill Master drill I have (with an epic NiCd battery
pack). Like, this drill doesn't do well for anything much beyond wood or plastic (and even plastic is asking a lot of it; or any wood much harder
than yellow pine...).
Granted, less "scary" than other cordless drills:
Other cordless drills, if they get stuck, will try to yank themselves
out of ones hand;
The Drill Master will just sort of meekly push against ones' hand and
give up (with roughly the force that my cat uses when ramming me with
his head).
Torque is also low enough that one can free-hand hold whatever they are drilling without it breaking loose (and possibly causing injury),
including relatively small items (if the drill can actually drill it,
that is).
Though, would be nicer if its battery life wasn't also crap.
Though, as noted, can technically also get a lot more "drilling power"
via a hand-drill, or by turning the chuck by hand (may be needed if it
gets stuck). Technically, can also use the drill to power-tighten and power-release bits by holding the chuck (since its stall torque is less
than my grip power...).
Contrast, the G0704 will try to spin a bigger mill, but the machine<
will just sorta rattle and hop all over the place while doing so.
So, you mill in smaller chunks. I have a fly cutter than can cut 4140 at
5" width on my G0704--albeit far from the speeds and feeds appropriate
for a Cincinnati doing the same job.....
OK.
I was trying at one point to use a 1" ball nose mill (mostly trying to
mill something with a Z radius), but was not happy at the results...
The Bridgeport had no complaints though...
BGB wrote:
On 11/13/2023 8:06 PM, MitchAlsup wrote:
BGB wrote:
On 11/13/2023 4:00 PM, Stephen Fuld wrote:Yes
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses,
you *can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed
to a lathe, it is trivial to make an arbitrary number of copies, or
have multiple different users use it simultaneously. This
difference accounts for the different licensing terms. It makes
things better for the software vendor, which, at least in theory,
allows for more software to be created.
Yeah, this is a fundamental difference...
To copy a lathe would require the time and expense both to buy all
of the materials and machine all the parts.
Then one may find that it ends up costing more than it would haveInvariably
cost just to buy another one.
And, despite the lathes and mills typically costing $k, one isYes
hard-pressed to make something of comparable quality for cheaper.
For stability, one needs things like a lot of weight, and the OEM<
has the advantage that they can cost-effectively sand-cast big
chunks of cast iron (where cheaply making big cast iron parts is a
technology mostly out of reach of home shops).
Other alternatives are things like:
Abrasive sand (such as garnet sand or slag) mixed with epoxy:
Not cheap;
Concrete: Not very good;
Needs to be encased in metal or epoxy to not suck;
One may still need garnet sand or slag for the needed density; >>>> Silica sand is cheaper, but not really dense enough.
If the machine is too light, then it would rattle or vibrate
excessively during cuts (AKA: chatter) which would ruin the quality
of the machined parts.
It is not weight per seé, it is stiffness between the piece holding
the part
and the spindle applying forces to remove chips from the part.
<
Or, some combination of machine stiffness, inertia, and having enough
weight+inertia to keep the thing firmly anchored in place on the floor.
Like, when I tried at one point to mill steel with a 1" ballnose
endmill on a CNC converted G0704, I quickly stopped this as, as soon
as the endmill started cutting the steel, it seemed like the whole
thing was going to rattle itself apart...
Though, I guess if a person had access to a waterjet, they could cut
the parts out of a bunch of steel plate as layers, and then braze
all the layers together. Labor would likely still cost more than
being able to pour cast iron though.
For other parts, having machines purpose built to make one specific
part will make those parts cheaper than using more general purpose
machines to make all the parts.
....
So, say, I don't really fault Grizzly or Tormach for the cost of
their machines, it is unlikely they could make them for all that
much cheaper and still make a profit.
Though, now having one of the Tormach CNC machines, limits can still
be noted:
Tries to use a 1/2 inch drill on some stainless steel:
Say, to enlarge a hole from 3/8 to 1/2 inch.
Starts to drill, eats into steel a little, spindle: "NOPE!",
Spindle stalls and machine goes into a faulted state.
So, one needs to go: 1/4" (OK), 3/8" (Also OK), to 7/16".
And then mill the hole the rest of the way via an endmill.
Say, because 1.5 kW at 10k RPM (in high range), doesn't mean it can
drill a 1/2" hole at 700 RPM. Granted, this works out to around 1
lb-ft or 192 oz-in of torque (so, not very much torque even by
cordless drill standards).
Well, or one can put it into low range by manually moving a belt,
but this kinda sucks as well, as then one has the torque to run the
drill, but not really enough RPM range for the endmill, ... (too
bad, say, they couldn't have put a CVT or similar in the thing).
So, say, vs a CNC converted Bridgeport:<
Tormach:
+ Tighter tolerances
Holds +/- 0.005 easily
Smaller is still hard (+/- 0.002 is still pushing it)
+ Has flood coolant;
+ Has tool changer;
+ Can dynamically change RPM.
- Less travel.
+ Though, still more than my G0704 (at least in Y and Z). >>>> + Faster
Can make quick work of aluminum and similar, ...
- Not so much torque.
Works fine if mostly using 1/8, 3/16, and 1/4 inch endmills.
7/16 and 5/8 (*2), don't get too aggressive here with cuts.
3/4: Only if you are milling plastic...
Bridgeport:
- Maybe gets +/- 0.005 if you are feeling lucky
+/- 0.015 mostly OK.
+ More powerful spindle;
Not much issue drilling holes in steel.
+ More X/Y/Z travel;
- No coolant;
- RPM is controlled by moving V belts.
- Using R8 collets and drawbar sucks.
- The software is buggy and likes to crash frequently, ...
The difference between 0.005 and 0.001 on a Bridgeport is metrology and
care. If you can't measure something you cannot compensate for
it--this goes double during setup where you sweep the clamped part to
determine
that it is held flat in the vise and normal to the milling direction.
<
The Bridgeport in this case was modified to use ballscrews, with
NEMA34 steppers (IIRC, 1740 oz-in) connected to the leadscrews via
timing belts and pulleys (similar setup on my G0704; just using 470
oz-in NEMA23 motors).
Both machines can get "in the area" of 0.005", but don't seem to get
this with much repeatability (say, one cuts the same hole, and one
time it might be 0.004 over, or 0.004 under, or, ...).
Things like rotating a feature, changing the feedrate, etc, may also
effect what size it cuts.
This seems to be less of an issue on the Tormach machine (1100MX),
which seems to usually get +/- 0.001, but for parts asking for this,
this is more of a problem.
Though, have noted that feedrate does effect accuracy (it seems to cut
a little oversize if using faster feedrates or deeper cuts).
Some settings I had found that seem to work fairly well (on the Tormach):
Aluminum with 3/16 endmill:
RPM: 6500
Feed: 17.0 inch/minute
Depth: 0.015
Aluminum with 1/8 endmill:
RPM: 8500
Feed: 19.0
Depth: 0.010
...
For the Bridgeport, was generally using (for 1/8 and 3/16):
RPM: ~ 3000
Feed: 6.5 inch/minute
Depth: 0.010
The G0704 is hard-pressed to go much over around 1500 RPM, so ~ 3.0<
inch/minute.
I rarely use my C07300 with a spindle speed above 500 RPM, and mostly
use 270 RPMs for milling.
On 2023-11-14 4:24 a.m., BGB wrote:
On 11/14/2023 1:02 AM, Terje Mathisen wrote:After searching around on the web for a font editor that could output
Stephen Fuld wrote:
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses,
you *can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed to
a lathe, it is trivial to make an arbitrary number of copies, or
have multiple different users use it simultaneously. This
difference accounts for the different licensing terms. It makes
things better for the software vendor, which, at least in theory,
allows for more software to be created.
I am still using my licensed version of Photoshop CS2, which is
almost 20 years old. It was the last version with a permanent license
but in order to transfer the SW to a new PC I had to contact Adobe's
license servers.
After 5-10 years they terminated the last remaining license server
but instead allowed owners to download a personal copy that does not
require licensing. I am guessing it could be watermarked with my
personal details so it could be traced?
For a while, I had been using "Cool Edit Pro" for audio editing, but
what eventually wrecked this was it no longer working natively after
Windows moved to 64 bits, and the lack of any really good/convenient
ways of emulating older versions of Windows which:
Continued to still work;
Allowed some way to share files between the host machine and VM.
For whatever reason, I have had very little success getting hardware
virtualization to work, and all the "mainstream" VMs went over to
requiring it, eventually leaving me with little real option other than
QEMU and DOSBox (running Windows 3.11).
Then ended up mostly going over to Audacity (pros/cons apparently).
Then, in more recent years, someone had released something (as a sort
of Windows plug-in) to make Win16 software work again on 64-bit Windows.
But, haven't felt much need to go back to Cool Edit, but the old MS
BitEdit and PalEdit tools lack any good modern equivalent (basically,
sort of like Paint, but built specifically for 16-color and 256-color
bitmap images, with direct control over the color palette and
operating directly in terms of said palette).
Newer programs like Paint.NET can be used in a vaguely similar way,
but lacks the ability to work explicitly with a 16 or 256 color
palette (nor any real usable support for indexed-color graphics).
Similarly "GraphX2" seems to be in a vaguely similar direction, but
its UI is very weird (apparently inspired by some programs on the Amiga).
Could almost write a tool for this, but it would be "pretty niche" in
any case (and if it were a popular use-case, presumably someone else
would have done so?...).
Sometimes, there are cases where one wants to work with low-res
graphics in terms of individual pixels and a fixed color palette
(rather than high-res true-color graphics). Needing to use another
image specifically as a color palette in an otherwise true-color
oriented program is annoying and counter-productive.
Maybe also useful would be an option for it to also be able to display
pixel data in binary or hexadecimal, or load/dump images in a
hexadecimal notation (bonus points if in a C based notation), ...
...
in formats I needed, I decided to roll my own. It is pretty basic but
can be used to create bitmap images for sprites in addition to fonts.
It outputs raw, memory file, and verilog code as output data. It is
called GlyphEdit. It support 8bpp, 16bpp, and 32bpp for sprite images.
IIRC it is a VB program, and might make a starting point to support
other graphics.
On 11/14/2023 1:24 AM, BGB wrote:
On 11/14/2023 1:02 AM, Terje Mathisen wrote:
Stephen Fuld wrote:
On 11/12/2023 11:19 AM, MitchAlsup wrote:
<
If I buy a Lathe, I can use it forever.
If I buy a SW license, I cannot use it forever.
See the problem here.
Well, there are differences. First of all, for many sw licenses,
you *can* use the software "forever" (i.e. lots of people are still
running Windows XP), although if it is licensed to a particular
hardware system, that system's life may limit your use, and you may
not get vendor support.
But I think the problem you are referring to is the limit on the
number of copies you can make, or simultaneous users you can have.
Of course, this is due to the obvious difference that, as opposed to
a lathe, it is trivial to make an arbitrary number of copies, or
have multiple different users use it simultaneously. This
difference accounts for the different licensing terms. It makes
things better for the software vendor, which, at least in theory,
allows for more software to be created.
I am still using my licensed version of Photoshop CS2, which is
almost 20 years old. It was the last version with a permanent license
but in order to transfer the SW to a new PC I had to contact Adobe's
license servers.
After 5-10 years they terminated the last remaining license server
but instead allowed owners to download a personal copy that does not
require licensing. I am guessing it could be watermarked with my
personal details so it could be traced?
For a while, I had been using "Cool Edit Pro" for audio editing, but
what eventually wrecked this was it no longer working natively after
Windows moved to 64 bits, and the lack of any really good/convenient
ways of emulating older versions of Windows which:
Continued to still work;
Allowed some way to share files between the host machine and VM.
For whatever reason, I have had very little success getting hardware
virtualization to work, and all the "mainstream" VMs went over to
requiring it, eventually leaving me with little real option other than
QEMU and DOSBox (running Windows 3.11).
Then ended up mostly going over to Audacity (pros/cons apparently).
Then, in more recent years, someone had released something (as a sort
of Windows plug-in) to make Win16 software work again on 64-bit Windows.
But, haven't felt much need to go back to Cool Edit, but the old MS
BitEdit and PalEdit tools lack any good modern equivalent (basically,
sort of like Paint, but built specifically for 16-color and 256-color
bitmap images, with direct control over the color palette and
operating directly in terms of said palette).
Newer programs like Paint.NET can be used in a vaguely similar way,
but lacks the ability to work explicitly with a 16 or 256 color
palette (nor any real usable support for indexed-color graphics).
Similarly "GraphX2" seems to be in a vaguely similar direction, but
its UI is very weird (apparently inspired by some programs on the Amiga).
Could almost write a tool for this, but it would be "pretty niche" in
any case (and if it were a popular use-case, presumably someone else
would have done so?...).
Sometimes, there are cases where one wants to work with low-res
graphics in terms of individual pixels and a fixed color palette
(rather than high-res true-color graphics). Needing to use another
image specifically as a color palette in an otherwise true-color
oriented program is annoying and counter-productive.
Maybe also useful would be an option for it to also be able to display
pixel data in binary or hexadecimal, or load/dump images in a
hexadecimal notation (bonus points if in a C based notation), ...
...
Bust out some Protracker... ;^)
https://youtu.be/kEBW8A3bw-Q
Amiga?
IBM Z has established niche.
IBM POWER - not sure about it. POWER holds on for as long as IBM
able to make POWER chips that are competitive (or better exceeding)
x86-64 and ARM64 in absolute performance and at the same time not ridiculously behind in price/performance. It looks to me like POWER
is in the same rat race that effectively killed SPARC and IPF. They
just manage to run a little better.
Is IBM's Power the same that Apple used in older Macs?
Then it wasn't a niche, IBM made it one.
IBM also sold POWER workstations, but sadly discontinued that.
Marco Moock <mm+solani@dorfdsl.de> writes:
IBM also sold POWER workstations, but sadly discontinued that.
Would you buy one?
At what cost?
How many others would buy that?
Am 16.11.2023 schrieb anton@mips.complang.tuwien.ac.at (Anton Ertl):
Marco Moock <mm+solani@dorfdsl.de> writes:
IBM also sold POWER workstations, but sadly discontinued that.
Would you buy one?
Maybe yes.
At what cost?
Depends on the performance, power consumption, spare part availability
etc.
IBM also sold POWER workstations, but sadly discontinued that.
In article <c2399332-9696-4749-adc4-8d9b071c060dn@googlegroups.com>, already5chosen@yahoo.com (Michael S) wrote:
Growing, but not yet fully-established: RISC-V.Is RISC-V really present in general-purpose computing?
Not yet, but it seems to have an adequate design and enough momentum to
get there. /Staying/ there is a different question.
In established niches, but not growing out of them: POWER, IBM Z.IBM POWER - not sure about it. POWER holds on for as long as IBM
able to make POWER chips that are competitive (or better exceeding)
x86-64 and ARM64 in absolute performance and at the same time not
ridiculously behind in price/performance. It looks to me like POWER
is in the same rat race that effectively killed SPARC and IPF. They
just manage to run a little better.
It's also used to run IBM i, which is a pretty big niche that's quite
easy to forget. It could be replaced, since the concept of the system is
that the hardware is replaceable, but IBM would try hard to avoid the
costs of doing that.
Marco Moock <mm+solani@dorfdsl.de> writes:
Is IBM's Power the same that Apple used in older Macs?
Yes, at that time it was called PowerPC.
Then it wasn't a niche, IBM made it one.
It seems to me that Apple made it more niche than it was at the time.
IBM also sold POWER workstations, but sadly discontinued that.
Would you buy one? At what cost? How many others would buy that?
Yup. And I vaguely recall that Power, probably with a bunch of
application specific peripherals, was a major player in the
automotive engine control space. If that is/was true, then it
represents huge volumes.
And I vaguely recall that Power, probably with a bunch of
application specific peripherals, was a major player in the automotive
engine control space. If that is/was true, then it represents huge volumes.
On Wed, 8 Nov 2023 23:26:01 -0800, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 11/1/2023 4:46 PM, George Neuner wrote:
[...]
Excellent, thanks for you the info! Btw, do you mind if I ask you some
technical questions from time to time? Can any volumetric image be
converted into a hologram? I think so...
I believe you are correct that any volumetric image can be rendered as
a hologram, but I can't say for certain ... I haven't really studied
it enough.
A company I was working for at that time was contracted to implement
the software and UI side of the hologram project. Our main business
was in machine vision - mainly industrial QA/QC - but from that we had
both image processing experience and also industry connections to
printing technology.
The NDAs are long expired, so I can talk about [the parts I know of]
what we did, but wrt the image processing, apart from some system
specific implementation tweaks, we were just following someone else's recipes.
However, an expert in the microcontroller market told me in IIRC 2016
that NXP is deemphasizing other architectures in favor of ARM.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
However, an expert in the microcontroller market told me in IIRC 2016
that NXP is deemphasizing other architectures in favor of ARM.
I wonder how much of that is the relative techincal merits of the two architectures and how much is the toolchain.
Arm provides development tools for embedded systems, including linkers
that do link time optimization and layout control. For POWER, IBM has
fine tools if you want to run AIX, linux, or i, but for embedded, I'm guessing not so much.
John Levine wrote:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
However, an expert in the microcontroller market told me in IIRC 2016 >>>that NXP is deemphasizing other architectures in favor of ARM.
I wonder how much of that is the relative techincal merits of the two
architectures and how much is the toolchain.
A recent paper shows ARM is essentially equivalent to RISC-V in instruction >counts. https://dl.acm.org/doi/pdf/10.1145/3624062.3624233
mitchalsup@aol.com (MitchAlsup) writes:
A recent paper shows ARM is essentially equivalent to RISC-V in instruction >>counts. https://dl.acm.org/doi/pdf/10.1145/3624062.3624233
What is the point of comparing instruction counts? It seems to be a
rather useless metric.
The paper compares against some nebulus "ARMv8-A" architecture, for which >there are nine distinct versions, each with different mix of instructions.
Even then the dominating factors in performance is going to be
the implementation of the architecture
and the quality of implementation
of the architecture in the compilers.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
However, an expert in the microcontroller market told me in IIRC 2016
that NXP is deemphasizing other architectures in favor of ARM.
I wonder how much of that is the relative techincal merits of the two >architectures and how much is the toolchain.
Arm provides development tools for embedded systems, including linkers
that do link time optimization and layout control. For POWER, IBM has
fine tools if you want to run AIX, linux, or i, but for embedded, I'm >guessing not so much.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
However, an expert in the microcontroller market told me in IIRC 2016
that NXP is deemphasizing other architectures in favor of ARM.
I wonder how much of that is the relative techincal merits of the two architectures and how much is the toolchain.
Arm provides development tools for embedded systems, including linkers
that do link time optimization and layout control. For POWER, IBM has
fine tools if you want to run AIX, linux, or i, but for embedded, I'm guessing not so much.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 69:03:30 |
| Calls: | 6,915 |
| Files: | 12,380 |
| Messages: | 5,431,893 |
