On 11/13/2023 8:06 PM, MitchAlsup wrote:
> 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.
> <

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

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?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

On 2023-11-14 4:24 a.m., 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), ...
>
> ...
>
After searching around on the web for a font editor that could output
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.

BGB wrote:

> On 11/13/2023 8:06 PM, MitchAlsup wrote:
>> 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.
>> <

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

> It is possibly to go a little faster, but doing so has drawbacks:
> Less accurate cuts;
> Worse burrs;
> Higher risk of breaking the endmills.

On 11/14/2023 10:41 AM, MitchAlsup wrote:
> BGB wrote:
>
>> On 11/13/2023 8:06 PM, MitchAlsup wrote:
>>> 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.
>>> <
>
>> 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 11/14/2023 9:33 AM, Robert Finch wrote:
> On 2023-11-14 4:24 a.m., 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), ...
>>
>> ...
>>
> After searching around on the web for a font editor that could output
> 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.
>

I had mostly done my font artwork by first drawing stuff in Paint.NET,
and then writing a quick/dirty tool to process the glyph cells (from a
TGA image) and emit them in a hexadecimal form.

Where, I was typically using TGA as a working format for true-color
images, and BMP for indexed-color images (but, then get annoyed that
tools like Paint.NET don't support emitting BMP's with a fixed
user-specified palette, rather than a dynamically generated optimized
palette).

Say, for 16 color, one might want a standard VGA RGBI palette, not some
dynamically-generated one. Or, for 256 color, also a specified palette
(such as my 16 shades of 16 colors, or 13 shades of 19 colors, palettes).

So, in effect, in some cases I may need to first save the image to a
TGA, and then use a tool to convert them to a BMP of the needed
bit-depth and palette.

Or, in other cases, I might want to use RGB555/RGB565 hi-color BMP
images, which programs like Paint.NET can't export (only indexed color,
and 24/32 bit). Where, within TestKern and associated programs, most of
the graphics stuff thus far works internally in terms of RGB555.

Standard BMP uses biBitCount==16, and RGB565, but TestKern uses a variant:
biBitCount==15, and RGB555 (storage is still 16 bits).
The "more standard" variant being:
biBitCount==16, biCompression==BI_BITFIELDS
With 4 16-bit numbers glued onto the end of the BITMAPINFOHEADER.
These then define RGBA555 as a bit-mask.
WinCE had used this format.
But "easier" to allow biBitCount==15,
Which is then understood to mean native RGB555.
Granted, tools like Paint.NET wont load this...

But, kinda funny that some old/forgotten Win 3.x era tools manage to be
closer to what I would want in these areas, than most of the modern
equivalents.

Or, sometimes I might want an image in the form of a blob of C code that
I can add to a program (well, or use the "resource section", but there
are still pros/cons here).

At one point, partly by accident, my tools had created a BMP variant
which was almost the same as the normal BMP format, except that all the
fields ended up being natively aligned (rather than standard BMP where
everything ends up misaligned).

I could almost be tempted to revive this format, though probably
changing the magic from "BM" to " BM" or " BMP" or similar (as there is
some possible merit to "BMP, but with all the fields correctly aligned";
even if none of the tools that read BMP files will understand such a
format).

At the time, it didn't matter (and didn't get noticed immediately)
because I was also using them to store non-standard image data which
normal BMP tools wouldn't recognize anyways.

This would make sense for "resource section" images, which may be
accessed in RAM.

Generally, the resource section in BGBCC is effectively a WAD variant
(replacing the original Windows format), IIRC with the lumps being
exposed to the program as symbols with names like "__rsrc_lumpname".

So, say, there is an import line like:
mainicon=mainicon.bmp
With a symbol like:
__rsrc_mainicon
Set to the start of the lump data for this image.

Where, say, "mainicon.bmp" might be 32x32 in 4bpp RGBI or similar.

Well, all this is also in the "limbo" of TeskKern ever really getting a
proper GUI; beyond mostly small-scale experimentation thus far, and
annoyance at the difficulty of seeming inability to get window-stack
redraw and screen refresh "sufficiently fast" (even with a relatively
small number of windows).

Well, and the inability to do resolutions like 800x600 hi-color within
the available RAM bandwidth.

Like, "Meh, will need to settle with 640x480 256-color or similar...",
then be annoyed about the limitations of what is possible with a
256-color palette (and/or use color-cell modes).

On 11/14/2023 3:31 AM, Chris M. Thomasson wrote:
> 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?

Tracker music is pretty cool sometimes, and generally much preferable to
the "garage band butt metal" that largely displaced it in game
soundtracks in the 2000s and onward...

But, yeah, I had never used an Amiga personally, nor ever saw one IRL.

It was rare to even see a Mac, most of my life has been almost entirely
dominated by IBM PC clones running Windows; but in my life, I have seen
Windows steadily change over the decades; sometimes better, sometimes
not. I get annoyed at times with MS's seemingly repeated attempts to
make Windows look like a baby toy (like, seemingly every other version,
they try to f* the UI design in one way or another, and don't leave the
options to entirely undo the damage).

Then again, it is possible that many other people wouldn't agree with my
UI design sentiments either (and TestKern is still pretty far from
having a GUI as well; so I can't claim to have come up with anything
better).

Though, I can claim, with some confidence, that it is not "whatever the
hell was going on" with TempleOS...

Sort of imagining something sort of like Win2K mixed with Motif or
similar (then again, looking at it, Motif has a curious level of
similarity to the Win 3.x design in some ways as well).

Technically, this is part of why I had worked on a sort of PCM /
Wavetable mixing hardware for BJX2 (as an add-on to the existing FM
Synth module), but hadn't yet come up with a good API interface to allow
programs to submit patches, or define the association between these
patches and the currently playing MIDI channels.

Had also made a sort of quick/dirty patch-set for MIDI playback, but it
isn't particularly good (basically, was quickly looking for usable clips
in free sound-effects collections to fill out the general-MIDI
instrument set). Technically, samples based on the original GUS sample
set are better, but more legally questionable.

But, theoretically, could be used for hardware-accelerated S3M playback
(as-is, mixing S3M in software on the BJX2 core is relatively expensive).

Basically, it handles this playback mostly by reinterpreting the note
phase accumulator as a sample position, with a loop-start and loop-end
value, and some phase-control flags.
Say:
NoteOn:
Starts at sample 0, plays forward.

If Loop is Set, if position hits LoopEnd, it is updated to LoopStart.
Else (Loop is Clear), it advances to SampleEnd, and then loops on the
last sample (until the channel is cleared or overwritten).
If Reverse is set, the counter runs backwards, looping from LoopStart to
LoopEnd.

Generally, IIRC, the patch samples were understood as 8-bit A-Law (also
used by the PCM hardware; mostly as 16-bit linear PCM uses twice as much
memory; and 8-bit PCM sounds kinda like crap).

Typically, I was also using 16kHz as a default sample rate, as it seems
like a "good compromise" of quality and space/cost.
8kHz and 11kHz have poor audio quality.
32kHz and 44.1kHz need too much space (for not much more quality).
22kHz is also a reasonable balance, but 16kHz is cheaper.

One option is to make the software-defined patch numbers "global", but
this is questionable (what if, say, two programs are trying to use this
API). Though, one other option is to tie them to a given program
instance (and internally remapped in the backend), but, yeah...

Or, maybe, the program submits a patch and the backend gives it a handle
(more like "open()" or similar), the program then remaps its internal
patch numbers to the patch-handles, which can then be issued in
"ProgramChange" commands or similar.

Though, couldn't really use a standard WAVEFORMATEX header, as this
lacks the parameters needed for patches (would need a header that also
defines loop-control parameters and similar; though could likely define
a PATCHWAVEFORMATEX or similar, as a WAVEFORMATEX with MOD/S3M style
loop-control parameters glued on the end).

....

As for formats, I had mostly went with MOD and S3M.
I had less interest in the IT or XM formats as they seemed to add a bit
too much needless complexity over something like S3M.

Like, we don't need things like MP3 compressed patch samples or similar,
who even thought this was a good idea? ...

Granted, if I were designing a tracker format, it would probably likely
end up as something like a WAD variant with the patches as WAD lumps,
probably using A-Law or ADPCM, with the music data stored as a tweaked
version of the General MIDI stream format or similar (and/or the Doom
MUS format).

Am 15.10.2023 schrieb Michael S <already5chosen@yahoo.com>:

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

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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.

> How many others would buy that?

At our university many of them existed, but were replaced by windows
machines before I started to work there, I know that from old
documentation.

Marco Moock <mm+solani@dorfdsl.de> writes:
>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.

You can buy a "Talos II Secure Workstation" starting at $9898.24 from
Raptor Computing Systems <https://www.raptorcs.com/TALOSII/>.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> 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?

A few years ago, I was involved in the purchase of two Talos
II machines, based on POWER9, one of them for privte use, the
other for business, as a CFD workstation. At the time, the memory
performance of POWER exceeded everything that we had on offer for
Intel and AMD, and the price was comparable.

One disadvantage was the poor availability of commercial software,
you have to compile yourself. In this case, it did not matter;
the CFD machine was meant to run OpenFOAM, which it did.

Now, this is no longer attractive: For a variety of reasons,
RaptorCS did not make a Power10-based workstation, and today's
Intel and AMD chips have better memory performance than POWER9.

I have no idea what an IBM server would have cost, but I suspect
it would have been much more expensive.

On 10/15/2023 8:21 AM, 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.
>
>>> 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.

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.

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

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>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.

That was Motorola's business, and it was then spun off to Freescale,
which was bought by NXP. NXP still sells Power Architecture
processors (and they also switched the name from PowerPC to Power,
like IBM):
<https://www.nxp.com/products/processors-and-microcontrollers/power-architecture:POWER-ARCHITECTURE>

However, an expert in the microcontroller market told me in IIRC 2016
that NXP is deemphasizing other architectures in favor of ARM.

And indeed, when I look at the web page above, I see "S32 Automotive
Platform" right above "Power Architecture", and when I click on "S32
Automotive Platform", it says: "Scalability across products based on
Arm Cortex-A, Cortex-R and Cortex-M cores with ASIL D capabilities".

OTOH, when I click on "Power Architecture", it says: "Automotive Power
Architecture Microcontrollers" and "Power Architecture" is on the same
level on the website as "Arm Microcontrollers", and "Arm Processors",
not among "Additional MPU/MCUs Architectures" or "Legacy MPU/MCUs"
(like Coldfire).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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.

I am getting ready to ask you some questions. Fwiw, here is one of my
recent tests of a volumetric fractal of mine. Low res test at 256^3:

https://i.ibb.co/8XfnmrR/image.png

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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

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

mitchalsup@aol.com (MitchAlsup) writes:
>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

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.

The number of instructions generated to solve a particular problem isn't
necessarily representative of workload performance.

scott@slp53.sl.home (Scott Lurndal) writes:
>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.

Yes, especially given the rather different philosophies behind RISC-V
(simple instructions with compressed versions for space and fuse
instructions on more sophisticated implementations) and ARM A64 (make
good use of the fixed 32-bit width to put in functionality that is
expected to help performance).

Still, one interesting result is that RISC-V's compare-and-branch
instructions provide a significant reduction in the number of executed
instructions, while A64 uses separate compare and branch instructions.
This is also something that I have found in my work on adding carry
and overflow flags to all GPRs in RISC-V: One won't be using them for
most branches.

>The paper compares against some nebulus "ARMv8-A" architecture, for which
>there are nine distinct versions, each with different mix of instructions.

It's not nebulous, the paper explicitly specifies that it's the code
you get from the two gcc versions used with -march=armv8-a+nosimd. I
assume that this is the A64 instruction set in the original AMDv8-A,
not in 8.1 or later.

>Even then the dominating factors in performance is going to be
>the implementation of the architecture

Definitely, in particular for a benchmark like STREAM which is
designed to measure the memory subsystem of the CPU and not at all
anything related to the instruction set.

>and the quality of implementation
>of the architecture in the compilers.

The paper notes that this plays a role, and that's why they used two
different compiler versions. It also notes that it is harder for the
compiler to generate optimal code for A64 than for RISC-V, because
there are many more options.

They compare simulated version of "sifive-7-series" and Cortex-A55,
because they are both 2-wide in-order microarchitectures.

I have results (for a different set of benchmarks) of hardware Sifive
U74, Cortex-A55, Cortex-A53, and Bonnell (all of which are two-issue
in-order microarchitectures). I have not processed them for comparing
the executed instructions or the cycles (the work focussed on
comparing the effect of certain optimizations and compared those), but
if there is demand, I can do that.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

John Levine <johnl@taugh.com> writes:
>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.

I am sure that Motorola/Freescale/NXP have their own toolchain for
Power, and there is also the GNU toolchain, but you may be right. NXP
probably does not want to maintain n toolchains for n architectures
indefinitely, so they want to consolidate on as few architectures as
possible.

And maybe they have decided (at least in 2016) that paying the ARM tax
is cheaper than forever maintaining the Power toolchain and especially
developing new Power designs that would have been the result of
consolidating on Power. Maybe the fact that TI and STM are also
consolidating on ARM also played a role: NXP's customers probably
don't want to become too dependent on NXP, and asked for ARM. Now,
with the recent moves by ARM to raise its licensing fees, maybe they
are regretting this decision.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Fri, 17 Nov 2023 18:37:06 -0000 (UTC)
John Levine <johnl@taugh.com> 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.
>
> 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.
>

Arm stopped independent tools development at least 5 years ago,
probably even earlier. Today all "Arm" tools are either re-branded LLVM
or plain LLVM.

IBM POWER tools are irrelevant for Moto->Freescale->NXP automative
PPC microcontrollers. This MCUs are based on various variants of e200
core that have VLE encoding as its distiguishing feature. The smollest
and pobably the most attractive member of the family can't run clasic
fixed-width PPC32 ISA at all.
And that before we consider that IBM probably didn't update 32-bit
back-end for their compiler since year 2000.

https://en.wikipedia.org/wiki/PowerPC_e200