Re: Help! text file avalanche!
Bill,
Although I was sort of responsible for the ORBITSAVE=sound feature, I haven't used it for years - since I was using it to be transformed into midi files in the late 90's or early 2000's. Anyway, I was checking today to see if it (fractint v 20.04.14) operated as expected, using DOSBox. It seems to work fine - once I was able to locate where the txt file was saved. However, I can't remember how to turn off the ORBITSAVE=sound from the command line - even restarting via <ins> doesn't clear it from writing the txt file. I shut down DOSBox and restarted it and fractint, then generated the default mandelbrot. No sound parameters were invoked at all, but still the SOUNDxxx.txt file was produced...empty, but still being made.
How did you turn orbitsave=sound on? Put it in sstools.ini? Otherwise, shutting down DOSBox and restarting should have worked.
Can you refresh my memory as to how to turn this off? Do we need a command line such as ORBITSAVE=off? I'm really not keen on generating a new .txt file every time I use fractint<g>.
Well, that's ugly. Ideally, you should be able to press <G> to bring up the prompt screen and then enter orbitsave=no to turn it off. However, the original orbitsave function was to cause IFS and LORENZ types to output an acrospin file. The orbitsave=sound feature commandeered the variable and provided no way to turn it off. I will fix it in the SDL version. Jonathan
How did you turn orbitsave=sound on? Put it in sstools.ini?
I always initiate it with the <G> command line. I wouldn't put it in the ini file since it is a rarely used function.
Otherwise, shutting down DOSBox and restarting should have worked.
Yes, and this morning when I sat down to work on this restarting DOSBox did disable the ORBITSAVE=sound function, so that is a big relief. Very cumbersome, but doable.
...the original orbitsave function was to cause IFS and LORENZ types to output an acrospin file. The orbitsave=sound feature commandeered the variable and provided no way to turn it off. I will fix it in the SDL version.
While adding the PC speaker in your SDL version is a huge step forward for those few of us who enjoy this feature (and in many ways, I prefer the sound card emulation of the old PC speaker) , it is still quite limited without the ability to use the sound card as in the DOS version, I will need to continue using the DOS version in DOSBox for the foreseeable future. Is there no practical way to add an ORBITSAVE=no to the DOS version? I don't recall this being a problem when using the DOS version on a DOS machine. I am attempting to fire up my 25yr old PII W98 to double check that (and sooo thankful not to have to deal with all the bugs and configuration issues in those days!). Surprise...the CMOS battery is dead... while waiting I had a thought. At some point, a decision was made to make the sound parameters "sticky" since there are so many of them. I have a feeling that decision may have been made after the last time I used the ORBITSAVE=sound feature and the problem may have been lurking there all this time, used by no one since! But now that the sound parameters are sticky, even disabling all of them by hand via <ctr><F> doesn't disable since there is nowhere to do so for the orbitsave. If this is the case, and it can't be easily fixed, I would MUCH rather deal with the very rare need to restart DOSBox than have the sound parameters not be sticky. On Mon, Apr 11, 2022 at 9:28 AM Jonathan Osuch <osuchj@mediacombb.net> wrote:
Bill,
Although I was sort of responsible for the ORBITSAVE=sound feature, I haven't used it for years - since I was using it to be transformed into midi files in the late 90's or early 2000's. Anyway, I was checking today to see if it (fractint v 20.04.14) operated as expected, using DOSBox. It seems to work fine - once I was able to locate where the txt file was saved. However, I can't remember how to turn off the ORBITSAVE=sound from the command line - even restarting via <ins> doesn't clear it from writing the txt file. I shut down DOSBox and restarted it and fractint, then generated the default mandelbrot. No sound parameters were invoked at all, but still the SOUNDxxx.txt file was produced...empty, but still being made.
How did you turn orbitsave=sound on? Put it in sstools.ini? Otherwise, shutting down DOSBox and restarting should have worked.
Can you refresh my memory as to how to turn this off? Do we need a command line such as ORBITSAVE=off? I'm really not keen on generating a new .txt file every time I use fractint<g>.
Well, that's ugly. Ideally, you should be able to press <G> to bring up the prompt screen and then enter orbitsave=no to turn it off. However, the original orbitsave function was to cause IFS and LORENZ types to output an acrospin file. The orbitsave=sound feature commandeered the variable and provided no way to turn it off. I will fix it in the SDL version.
Jonathan
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
Bill,
Yes, and this morning when I sat down to work on this restarting DOSBox did disable the ORBITSAVE=sound function, so that is a big relief. Very cumbersome, but doable.
Restarting Fractint should do it, but DOSBox may be saving everything in memory for a set amount of time before clearing it when you shut things down. That's a wild guess, with no merit.
While adding the PC speaker in your SDL version is a huge step forward for those few of us who enjoy this feature (and in many ways, I prefer the sound card emulation of the old PC speaker) , it is still quite limited without the ability to use the sound card as in the DOS version, I will need to continue using the DOS version in DOSBox for the foreseeable future. Is there no practical way to add an ORBITSAVE=no to the DOS version?
It is not impossible to fix the DOS version. I need to do it in DOSBox and I don't believe I still have the development environment set up. Haven't tried it in years. I think the last time I did, it took 30 minutes to compile. The sound card features would have to be emulated, since it is no longer possible to touch the hardware. I still don't have the PC speaker emulated quite right.
I don't recall this being a problem when using the DOS version on a DOS machine. I am attempting to fire up my 25yr old PII W98 to double check that (and sooo thankful not to have to deal with all the bugs and configuration issues in those days!). Surprise...the CMOS battery is dead... while waiting I had a thought. At some point, a decision was made to make the sound parameters "sticky" since there are so many of them. I have a feeling that decision may have been made after the last time I used the ORBITSAVE=sound feature and the problem may have been lurking there all this time, used by no one since! But now that the sound parameters are sticky, even disabling all of them by hand via <ctr><F> doesn't disable since there is nowhere to do so for the orbitsave.
Not being able to turn orbitsave off has always been a problem and it is a fluke that orbitsave=sound works at all. The following is TMI, but Tim might appreciate it. When the command is parsed, the current value of orbitsave is or'd with 2 (10 binary), setting the second bit. The logic then parses the Yes/No value (0 for No, 1 for Yes, and -1 for unknown) and or's the result with the current value of orbitsave. Since 'sound' or 's' is not 'y' or 'n', it is unknown and -1 (all ones in binary) is or'd. So all the bits are set. When the orbitsave variable is checked to see if we want to save to a sound.txt file, we check if (orbitsave & 2) is not equal to zero. Since orbitsave is all ones in binary, the check returns TRUE and we create the file. When orbitsave=sound is set, (orbitsave & 1) also always returns a TRUE, and we additionally generate an orbits.raw file for the acrospin data for the IFS and LORENZ fractal types. I will not fix the fluke, but will document it in the code.
If this is the case, and it can't be easily fixed, I would MUCH rather deal with the very rare need to restart DOSBox than have the sound parameters not be sticky.
The fix is easy. Compiling is less so. Jonathan
Jonathan, you and Tim have been such incredible resources for all these years! Thank you, thank you, thank you! On Tue, Apr 12, 2022 at 7:09 AM Jonathan Osuch <osuchj@mediacombb.net> wrote:
Bill,
Yes, and this morning when I sat down to work on this restarting DOSBox did disable the ORBITSAVE=sound function, so that is a big relief. Very cumbersome, but doable.
Restarting Fractint should do it, but DOSBox may be saving everything in memory for a set amount of time before clearing it when you shut things down. That's a wild guess, with no merit.
While adding the PC speaker in your SDL version is a huge step forward for those few of us who enjoy this feature (and in many ways, I prefer the sound card emulation of the old PC speaker) , it is still quite limited without the ability to use the sound card as in the DOS version, I will need to continue using the DOS version in DOSBox for the foreseeable future. Is there no practical way to add an ORBITSAVE=no to the DOS version?
It is not impossible to fix the DOS version. I need to do it in DOSBox and I don't believe I still have the development environment set up. Haven't tried it in years. I think the last time I did, it took 30 minutes to compile.
The sound card features would have to be emulated, since it is no longer possible to touch the hardware. I still don't have the PC speaker emulated quite right.
I don't recall this being a problem when using the DOS version on a DOS machine. I am attempting to fire up my 25yr old PII W98 to double check that (and sooo thankful not to have to deal with all the bugs and configuration issues in those days!). Surprise...the CMOS battery is dead... while waiting I had a thought. At some point, a decision was made to make the sound parameters "sticky" since there are so many of them. I have a feeling that decision may have been made after the last time I used the ORBITSAVE=sound feature and the problem may have been lurking there all this time, used by no one since! But now that the sound parameters are sticky, even disabling all of them by hand via <ctr><F> doesn't disable since there is nowhere to do so for the orbitsave.
Not being able to turn orbitsave off has always been a problem and it is a fluke that orbitsave=sound works at all.
The following is TMI, but Tim might appreciate it. When the command is parsed, the current value of orbitsave is or'd with 2 (10 binary), setting the second bit. The logic then parses the Yes/No value (0 for No, 1 for Yes, and -1 for unknown) and or's the result with the current value of orbitsave. Since 'sound' or 's' is not 'y' or 'n', it is unknown and -1 (all ones in binary) is or'd. So all the bits are set. When the orbitsave variable is checked to see if we want to save to a sound.txt file, we check if (orbitsave & 2) is not equal to zero. Since orbitsave is all ones in binary, the check returns TRUE and we create the file. When orbitsave=sound is set, (orbitsave & 1) also always returns a TRUE, and we additionally generate an orbits.raw file for the acrospin data for the IFS and LORENZ fractal types.
I will not fix the fluke, but will document it in the code.
If this is the case, and it can't be easily fixed, I would MUCH rather deal with the very rare need to restart DOSBox than have the sound parameters not be sticky.
The fix is easy. Compiling is less so.
Jonathan
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
Keep in mind I stopped developing Fractint many years before Jonathan did. I haven't done any development for multiple decades. Having said that, you folks are NOT going to believe this. I used to build my computers, and install removable racks for the hard drives. I keep computers until they die. My oldest living computer, named "Irv", which usually runs Linux, still has a Lian Li RH-32 removable rack. I have a closet full of old drives. I found an 80 gb drive in a Lian Li cartridge that originally booted on a still older, now dead, computer. I keep a spreadsheet detailing all my drives, and the notes for this drive says "boots XP on Irv!" This itself is a miracle, Windows old timers will remember how tied Windows was to the machine it was installed on. Here's the part you won't believe. I placed the 80 gb drive into Irv, booted, and XP came up. The desktop has an icon called "Fractint" that loads a XP Dos shell. I can not only run fractint on this machine, but I have a complete development environment! I have enough going on in my life right now that I am crazy to say this, but I think if Jonathan has source code changes he wants to make in the DOS version, I could likely build it. Tim On Tue, Apr 12, 2022 at 10:07 AM Bill Jemison <bill.jemison@gmail.com> wrote:
Jonathan, you and Tim have been such incredible resources for all these years! Thank you, thank you, thank you!
On Tue, Apr 12, 2022 at 7:09 AM Jonathan Osuch <osuchj@mediacombb.net> wrote:
Bill,
Yes, and this morning when I sat down to work on this restarting DOSBox did disable the ORBITSAVE=sound function, so that is a big relief. Very cumbersome, but doable.
Restarting Fractint should do it, but DOSBox may be saving everything in memory for a set amount of time before clearing it when you shut things down. That's a wild guess, with no merit.
While adding the PC speaker in your SDL version is a huge step forward for those few of us who enjoy this feature (and in many ways, I prefer the sound card emulation of the old PC speaker) , it is still quite limited without the ability to use the sound card as in the DOS version, I will need to continue using the DOS version in DOSBox for the foreseeable future. Is there no practical way to add an ORBITSAVE=no to the DOS version?
It is not impossible to fix the DOS version. I need to do it in DOSBox and I don't believe I still have the development environment set up. Haven't tried it in years. I think the last time I did, it took 30 minutes to compile.
The sound card features would have to be emulated, since it is no longer possible to touch the hardware. I still don't have the PC speaker emulated quite right.
I don't recall this being a problem when using the DOS version on a DOS machine. I am attempting to fire up my 25yr old PII W98 to double check that (and sooo thankful not to have to deal with all the bugs and configuration issues in those days!). Surprise...the CMOS battery is dead... while waiting I had a thought. At some point, a decision was made to make the sound parameters "sticky" since there are so many of them. I have a feeling that decision may have been made after the last time I used the ORBITSAVE=sound feature and the problem may have been lurking there all this time, used by no one since! But now that the sound parameters are sticky, even disabling all of them by hand via <ctr><F> doesn't disable since there is nowhere to do so for the orbitsave.
Not being able to turn orbitsave off has always been a problem and it is a fluke that orbitsave=sound works at all.
The following is TMI, but Tim might appreciate it. When the command is parsed, the current value of orbitsave is or'd with 2 (10 binary), setting the second bit. The logic then parses the Yes/No value (0 for No, 1 for Yes, and -1 for unknown) and or's the result with the current value of orbitsave. Since 'sound' or 's' is not 'y' or 'n', it is unknown and -1 (all ones in binary) is or'd. So all the bits are set. When the orbitsave variable is checked to see if we want to save to a sound.txt file, we check if (orbitsave & 2) is not equal to zero. Since orbitsave is all ones in binary, the check returns TRUE and we create the file. When orbitsave=sound is set, (orbitsave & 1) also always returns a TRUE, and we additionally generate an orbits.raw file for the acrospin data for the IFS and LORENZ fractal types.
I will not fix the fluke, but will document it in the code.
If this is the case, and it can't be easily fixed, I would MUCH rather deal with the very rare need to restart DOSBox than have the sound parameters not be sticky.
The fix is easy. Compiling is less so.
Jonathan
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
Why am I not surprised?! Tim, that is so "you"! Bill On Tue, Apr 12, 2022 at 9:38 AM Timothy Wegner <tim@tswegner.net> wrote:
Keep in mind I stopped developing Fractint many years before Jonathan did. I haven't done any development for multiple decades. Having said that, you folks are NOT going to believe this.
I used to build my computers, and install removable racks for the hard drives. I keep computers until they die. My oldest living computer, named "Irv", which usually runs Linux, still has a Lian Li RH-32 removable rack. I have a closet full of old drives. I found an 80 gb drive in a Lian Li cartridge that originally booted on a still older, now dead, computer. I keep a spreadsheet detailing all my drives, and the notes for this drive says "boots XP on Irv!" This itself is a miracle, Windows old timers will remember how tied Windows was to the machine it was installed on.
Here's the part you won't believe. I placed the 80 gb drive into Irv, booted, and XP came up. The desktop has an icon called "Fractint" that loads a XP Dos shell. I can not only run fractint on this machine, but I have a complete development environment!
I have enough going on in my life right now that I am crazy to say this, but I think if Jonathan has source code changes he wants to make in the DOS version, I could likely build it.
Tim
On Tue, Apr 12, 2022 at 10:07 AM Bill Jemison <bill.jemison@gmail.com> wrote:
Jonathan, you and Tim have been such incredible resources for all these years! Thank you, thank you, thank you!
On Tue, Apr 12, 2022 at 7:09 AM Jonathan Osuch <osuchj@mediacombb.net> wrote:
Bill,
Yes, and this morning when I sat down to work on this restarting DOSBox did disable the ORBITSAVE=sound function, so that is a big relief. Very cumbersome, but doable.
Restarting Fractint should do it, but DOSBox may be saving everything in memory for a set amount of time before clearing it when you shut things down. That's a wild guess, with no merit.
While adding the PC speaker in your SDL version is a huge step forward for those few of us who enjoy this feature (and in many ways, I prefer the sound card emulation of the old PC speaker) , it is still quite limited without the ability to use the sound card as in the DOS version, I will need to continue using the DOS version in DOSBox for the foreseeable future. Is there no practical way to add an ORBITSAVE=no to the DOS version?
It is not impossible to fix the DOS version. I need to do it in DOSBox and I don't believe I still have the development environment set up. Haven't tried it in years. I think the last time I did, it took 30 minutes to compile.
The sound card features would have to be emulated, since it is no longer possible to touch the hardware. I still don't have the PC speaker emulated quite right.
I don't recall this being a problem when using the DOS version on a DOS machine. I am attempting to fire up my 25yr old PII W98 to double check that (and sooo thankful not to have to deal with all the bugs and configuration issues in those days!). Surprise...the CMOS battery is dead... while waiting I had a thought. At some point, a decision was made to make the sound parameters "sticky" since there are so many of them. I have a feeling that decision may have been made after the last time I used the ORBITSAVE=sound feature and the problem may have been lurking there all this time, used by no one since! But now that the sound parameters are sticky, even disabling all of them by hand via <ctr><F> doesn't disable since there is nowhere to do so for the orbitsave.
Not being able to turn orbitsave off has always been a problem and it is a fluke that orbitsave=sound works at all.
The following is TMI, but Tim might appreciate it. When the command is parsed, the current value of orbitsave is or'd with 2 (10 binary), setting the second bit. The logic then parses the Yes/No value (0 for No, 1 for Yes, and -1 for unknown) and or's the result with the current value of orbitsave. Since 'sound' or 's' is not 'y' or 'n', it is unknown and -1 (all ones in binary) is or'd. So all the bits are set. When the orbitsave variable is checked to see if we want to save to a sound.txt file, we check if (orbitsave & 2) is not equal to zero. Since orbitsave is all ones in binary, the check returns TRUE and we create the file. When orbitsave=sound is set, (orbitsave & 1) also always returns a TRUE, and we additionally generate an orbits.raw file for the acrospin data for the IFS and LORENZ fractal types.
I will not fix the fluke, but will document it in the code.
If this is the case, and it can't be easily fixed, I would MUCH rather deal with the very rare need to restart DOSBox than have the sound parameters not be sticky.
The fix is easy. Compiling is less so.
Jonathan
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
It gets even better! Because I am a data security freak, years ago I copied the 80 gb XP drive onto a 120 gb drive. It too boots XP and has a development environment. So I can make changes to and not risk losing my old copy. Earlier I misspoke, I said "... I stopped developing Fractint many years before Jonathan did". Of course Jonathan hasn't stopped yet! Tim On Tue, Apr 12, 2022 at 11:34 AM Bill Jemison <bill.jemison@gmail.com> wrote:
Why am I not surprised?! Tim, that is so "you"!
Bill
On Tue, Apr 12, 2022 at 9:38 AM Timothy Wegner <tim@tswegner.net> wrote:
Keep in mind I stopped developing Fractint many years before Jonathan did. I haven't done any development for multiple decades. Having said that, you folks are NOT going to believe this.
I used to build my computers, and install removable racks for the hard drives. I keep computers until they die. My oldest living computer, named "Irv", which usually runs Linux, still has a Lian Li RH-32 removable rack. I have a closet full of old drives. I found an 80 gb drive in a Lian Li cartridge that originally booted on a still older, now dead, computer. I keep a spreadsheet detailing all my drives, and the notes for this drive says "boots XP on Irv!" This itself is a miracle, Windows old timers will remember how tied Windows was to the machine it was installed on.
Here's the part you won't believe. I placed the 80 gb drive into Irv, booted, and XP came up. The desktop has an icon called "Fractint" that loads a XP Dos shell. I can not only run fractint on this machine, but I have a complete development environment!
I have enough going on in my life right now that I am crazy to say this, but I think if Jonathan has source code changes he wants to make in the DOS version, I could likely build it.
Tim
On Tue, Apr 12, 2022 at 10:07 AM Bill Jemison <bill.jemison@gmail.com> wrote:
Jonathan, you and Tim have been such incredible resources for all these years! Thank you, thank you, thank you!
On Tue, Apr 12, 2022 at 7:09 AM Jonathan Osuch <osuchj@mediacombb.net> wrote:
Bill,
Yes, and this morning when I sat down to work on this restarting DOSBox did disable the ORBITSAVE=sound function, so that is a big relief. Very cumbersome, but doable.
Restarting Fractint should do it, but DOSBox may be saving everything in memory for a set amount of time before clearing it when you shut things down. That's a wild guess, with no merit.
While adding the PC speaker in your SDL version is a huge step forward for those few of us who enjoy this feature (and in many ways, I prefer the sound card emulation of the old PC speaker) , it is still quite limited without the ability to use the sound card as in the DOS version, I will need to continue using the DOS version in DOSBox for the foreseeable future. Is there no practical way to add an ORBITSAVE=no to the DOS version?
It is not impossible to fix the DOS version. I need to do it in DOSBox and I don't believe I still have the development environment set up. Haven't tried it in years. I think the last time I did, it took 30 minutes to compile.
The sound card features would have to be emulated, since it is no longer possible to touch the hardware. I still don't have the PC speaker emulated quite right.
I don't recall this being a problem when using the DOS version on a DOS machine. I am attempting to fire up my 25yr old PII W98 to double check that (and sooo thankful not to have to deal with all the bugs and configuration issues in those days!). Surprise...the CMOS battery is dead... while waiting I had a thought. At some point, a decision was made to make the sound parameters "sticky" since there are so many of them. I have a feeling that decision may have been made after the last time I used the ORBITSAVE=sound feature and the problem may have been lurking there all this time, used by no one since! But now that the sound parameters are sticky, even disabling all of them by hand via <ctr><F> doesn't disable since there is nowhere to do so for the orbitsave.
Not being able to turn orbitsave off has always been a problem and it is a fluke that orbitsave=sound works at all.
The following is TMI, but Tim might appreciate it. When the command is parsed, the current value of orbitsave is or'd with 2 (10 binary), setting the second bit. The logic then parses the Yes/No value (0 for No, 1 for Yes, and -1 for unknown) and or's the result with the current value of orbitsave. Since 'sound' or 's' is not 'y' or 'n', it is unknown and -1 (all ones in binary) is or'd. So all the bits are set. When the orbitsave variable is checked to see if we want to save to a sound.txt file, we check if (orbitsave & 2) is not equal to zero. Since orbitsave is all ones in binary, the check returns TRUE and we create the file. When orbitsave=sound is set, (orbitsave & 1) also always returns a TRUE, and we additionally generate an orbits.raw file for the acrospin data for the IFS and LORENZ fractal types.
I will not fix the fluke, but will document it in the code.
If this is the case, and it can't be easily fixed, I would MUCH rather deal with the very rare need to restart DOSBox than have the sound parameters not be sticky.
The fix is easy. Compiling is less so.
Jonathan
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
_______________________________________________ Fractint mailing list -- fractint@mailman.xmission.com To unsubscribe send an email to fractint-leave@mailman.xmission.com
Tim,
It gets even better! Because I am a data security freak, years ago I copied the 80 gb XP drive onto a 120 gb drive. It too boots XP and has a development environment. So I can make changes to and not risk losing my old copy.
When trying to use either a computer running XP or a virtual system running XP, I think my biggest problem might have been connecting to the subversion repository. I have the files from the subversion repository on a Windows 10 system and I think I can compile using DOSBox, it is just slow. Jonathan
participants (3)
-
Bill Jemison -
Jonathan Osuch -
Timothy Wegner