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

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

Sorry, I don't remember what resolutions we were working with ... we
worked variously 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
fitthe projector resolution, which was 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 PC "workstations" running
either Linux or NetBSD (depending), and back-end VME "compute server"
chassis 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 an average exposure
calculation would take on x86, we knew that doing it on the
workstations was not viable: computing in the background while letting
the operator continue working would delay start of printing
unacceptably in an emergency situation where the operator might want
to quickly produce multiple films from different orientations or
croppings of the same volume. Conversely, computing in the foreground
would delay the operator unacceptably which would interfere with [what
we thought of as] "normal" usage where the operator might be expected
to collect and save multiple image sets, possibly from multiple
patients, and then sit down to review and make films.

We maybe 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 combination was so much faster [on our codes] that it
would be able to serve multiple workstations acceptably fast in the
normal case, and would not delay emergency prints beyond availability
of the projector unit.

Final rotated/cropped volumes would be sent to the compute server and
ultimately to the projector and 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 each 1mm deep slices of the final hologram, and from there to
determine what points actually needed to be exposed to produce the
desired interference image.

Multiple exposures produced an interference "negative" which, once
developed, could be used repeatedly to create final "positive"
holograms. The holograms were, by design, dimensionally accurate: 1cm
in the source volume was 1cm in its hologram - so, e.g., a surgeon
could in theory measure some feature in the image and that measurement
would be - within 1mm - the same as in the body.

In practice the volume we could render was limited to, roughly, a 20cm
cube centered at the plane of the film [and yes, the film could be
reversed on the viewer to to see things that were "behind" it].

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

Sorry, I must have accidentally sent a draft. Ignore the 1st one.

On Wed, 01 Nov 2023 20:26:55 -0400, George Neuner
<gneuner2@comcast.net> wrote:

> :
>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
^^^
at more reasonable prices.

On 11/1/2023 4:46 PM, George Neuner wrote:
> 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.
>>>>>>>> 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
>>
>
> 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.

Humm... Good point. I remember a 1024^3 power volumetric image would
start to crunch my computer. 1024 images at 1024x1024 resolution. I need
to study your response. Will get back to you. Actually, you might be
able to help me...

>
>
> 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 11/1/2023 4:46 PM, George Neuner wrote:
> 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.
>>>>>>>> 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
>>
>
> 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].
>
>
>

Fwiw, here is some of my work wrt volumes broken out into geometric
forms, real time, opengl and GLSL shaders:

https://youtu.be/KRkKZj9s3wk

https://youtu.be/oVCjAaY1pOY

Btw, I made the music as well, via MIDI. ;^)

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

Some more of my work:

https://youtu.be/iF75LSbzIVM

https://youtu.be/yZbO0314gRo

https://youtu.be/HwIkk9zENcg

Thomas Koenig wrote:

> 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.
<
It implements enough of the ISA to smell like a 68K to the compilers
and assembly language programmers.

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.

George

On 11/10/2023 10:35 AM, George Neuner wrote:
> 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.

Excellent! Thank you so much. I am tight on time right now, will get
back to you. Fwiw, check this out:

https://youtu.be/XpbPzrSXOgk

Imagine it as a full blown hologram! That would be interesting, well,
for me at least. :^) Thanks again.

Thomas Koenig wrote:

> 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:
>>> >> 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,
>>> >>> and there were no easy gains there.
>>> >> What could they do that would make it better than an ARM or RISC V chip
>>> >> running at the same speed? Transactional memory?
>>> >>
>>> >
>>> > 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.
>>> >
>>> 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
>>> 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.
<
This reasoning works well enough as long as the register state of the
other thread adds no cycles to the pipeline not access time to the
Decode stage. GPUs switch threads every cycle, so do barrel processors,
x86s not so much.
<
> 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.
<
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.
<

John Dallman wrote:

> 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.
<
RISC-V seems to have enough momentum to avoid being written off in the
large general computing realm. Whether it gets there, whether the
Chinese money behind it helps or harms long term, is all playing out
as we watch.
<
Current RISC-V products are not good enough to land design-wins right
now--although that might change soon.
<
>> > 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.
<
Power lives only so long as IBM continues to fund design teams. For the
people willing to pay for its performance(s) it has a developed niche.
<
> 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

On 11/12/23 13:19, 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.
And talk to farmers who bought a John Deere tractor and need to fix it.

Brian G. Lucas wrote:

> On 11/12/23 13:19, 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.
> And talk to farmers who bought a John Deere tractor and need to fix it.
<
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.

On 11/13/2023 2:05 PM, MitchAlsup wrote:
> Brian G. Lucas wrote:
>
>> On 11/12/23 13:19, 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.
>> And talk to farmers who bought a John Deere tractor and need to fix it.
> <
> 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.

Probably some executive somewhere: "But, a tractor is premium, of course
they will take it to the dealership for oil changes and servicing...".

Next up, they start using micropayments for each "extra perk" the user
tries to use (like apparently in some newer cars):
Want air conditioner? Want windshield wipers? ...
You are going to need to pay to use those...

Farmer then pays by the minute every time the "thresher" component is
active, and the thresher can't be used at all if their farm lacks a
nearby 5G cell-tower or similar, etc.

Similar to like, say, if one has a car that micro-payments the AC, and
then finds that the AC shuts off whenever they drive out on rural roads
or similar because of interruptions to cell-coverage (and thus inability
for the car to make the micropayments).

Or, they do like some other companies, and maybe "auto brick" the
tractor if it gets too far outside the EOL period, and then hits an "End
of Service" situation.

....

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.

Of course, YMMV

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 11/13/2023 2: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.

Side note, and related... Iirc, IOCP on windows client versions only
allowed for 2 IOCP TransmitFile functions to be concurrent at the same
time. The server version allowed much more before non-paged memory ran
out...

https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile

wow, this was back in nt 4 days.

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

-- Stefan

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

On 11/13/2023 2:57 PM, Chris M. Thomasson wrote:
> 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
>

By the server version or this music will play forevermore in Windows 12...

https://youtu.be/tQ13aroz7eE

;^D

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

Well, unless it is Apple or Nintendo...

I guess that ironically, apparently lot of older Nintendo platforms are
outliving some of the newer ones because the older ones had physical
media and didn't depend on an always-online internet connection to work,
but the newer consoles do, so when Nintendo pulls the plug on the
servers, the consoles are effectively bricks from then on.

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 guess apparently 3DS devices will still partially work, in that they
can still use previously installed games, and don't require an active
internet connection or signing in to play games.

But, hardware depending on online servers to work, will not last
forever, in any case.

On the other side of things, people are still running the original NES
and NES clones, but apparently the original cartridges are becoming rare
and expensive; being gradually replaced by mock cartridges that
internally load ROMs from an SDcard (well, among other things; excluding
the occasional people that do something hacky and run Doom or Quake on
the thing via cartridge magic).

But, I guess people have to be careful what they do, and keep it
low-key, to avoid getting angry C&D letters from Nintendo's lawyers...

Theoretically though, in cases where it is both a clone console and not
using any of their original IP (say, in the case of running Doom or
Quake via an FPGA and ARM core or similar), the lawyers should have no
say in the matter so long as the person doesn't invoke any of their
trademarks.

> 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 cost
just to buy another one.

And, despite the lathes and mills typically costing $k, one is
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.

Bridgeport: "Yeah, fine, whatever." (the Bridgeport will also cut with a
7/8" or 1" endmill without complaint).

....

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

Stefan

On 11/13/2023 6:44 PM, Stefan Monnier wrote:
>> 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.
>

OK.

I don't have one, but this is what I heard from videos that were talking
about it online. It sounded like it was an "always online" thing that
required people to be signed in to use the console.

I guess, good to know if it is not.

>> But, hardware depending on online servers to work, will not last
>> forever, in any case.
>
> Proprietary software is a curse, indeed.
>

Yeah.

Better when everything (hardware and software) is open, and not
dependent on whether some corporation continues to find it profitable
(or continues to exist, for that matter).

Often times, the "artifacts" continue to still be relevant to people,
long after the companies that created them have ceased to exist (like,
all the "retro guys" who are still obsessing on Commodore computers and
similar, decades after the company has ceased to exist, *...).

*: Though, I guess the trademarks have still been passed around and used
occasionally (like, I guess a few years back some company did some
"Commodore 64" branded smartphones or similar, along with using the
various Commodore logos and a similar pasted all over what was otherwise
a generic Android smartphone, as a thing apparently to try to keep the
trademark alive; but then there was apparent dispute between several
parties as to who actually owns the various logos and trademarks, ...).

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 of
> the materials and machine all the parts.
Yes
> Then one may find that it ends up costing more than it would have cost
> just to buy another one.
Invariably
> And, despite the lathes and mills typically costing $k, one is
> hard-pressed to make something of comparable quality for cheaper.
Yes

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