Topics

BB4W: different outputs on different PCs

Ian_Wade_G3NRW
 

Have just been testing a new BB4W program on a fast-ish 64-bit Windows 10 system. BB4W 6.02 a.

The program uses BPUT# to generate an output report something like this:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Auto Mode Frequency]
Raw Data Chan Mode Band Segment Dial
CH_00=0000184300030 00 CW 0.030.000 - 1.839.990 0.030.000 -
CH_01=0000200001010 01 LSB 1.840.000 - 2.000.000 1.843.000 -
CH_02=0000360300030 02 CW 2.000.010 - 3.599.990 2.000.010 -
CH_03=0000380001010 03 LSB 3.600.000 - 3.800.000 3.603.000 -
CH_04=0000527600030 04 CW 3.800.010 - 5.275.990 3.800.010 -

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Exactly as expected. No problem.

I then ran the identical program on a slow-ish 32-bit Windows 10 system. Same BB4W.

This time the equivalent report looks like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Auto Mode Frequency] [Ato F.req.uen
CH_00=0000184300030 CH00= 18.430.003
CH_01=0000200001010 CH01= 20.000.101
CH_02=0000360300030 CH02= 36.030.003
CH_03=0000380001010 CH03= 38.000.101
CH_04=0000527600030 CH04= 52.760.003
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In both cases I ran the program as interpreted BB4W code and as a .exe program.

I also inserted a long WAIT command before each BPUT# to give the slow machine time to catch up. No difference.

Any idea why the discrepancy?

--
Ian

Ian_Wade_G3NRW
 

OK, call off the dogs.

I have just done what I should have done earlier. I upgraded BB4W to 6.01a, and everything now works fine on the slow machine.

BB4W really shines!

--
Ian

On 05/05/2017 22:30, Ian_Wade_G3NRW wrote:
Have just been testing a new BB4W program on a fast-ish 64-bit Windows 10 system. BB4W 6.02 a.

The program uses BPUT# to generate an output report something like this:

Ian_Wade_G3NRW
 

Make the upgrade 6.10a. It's been a long week.

--
Ian

On 06/05/2017 07:52, Ian_Wade_G3NRW wrote:
OK, call off the dogs.

I have just done what I should have done earlier. I upgraded BB4W to 6.01a, and everything now works fine on the slow machine.

BB4W really shines!

--
Ian



On 05/05/2017 22:30, Ian_Wade_G3NRW wrote:
Have just been testing a new BB4W program on a fast-ish 64-bit Windows 10 system. BB4W 6.02 a.

The program uses BPUT# to generate an output report something like this:


J.G.Harston
 

It's always useful if you post the shortest possible program that replicates the problem. For instance:
Why does my print formatting go wrong, eg:
PRINT 10:PROCfred:PRINT 20:END
DEFPROCfred:@%=54354:ENDPROC

Answer: not preserved @%

--
J.G.Harston - jgh@... - mdfs.net/jgh

Richard Russell
 

On Fri, May 5, 2017 at 11:52 pm, Ian_Wade_G3NRW wrote:
I upgraded BB4W to 6.01a, and everything now works fine on the slow machine.

Coincidence.  There are no differences between v6.02a and v6.10a that could possibly explain it.  Indeed, no release of BB4W has ever had a bug or feature that caused data written to a file using BPUT# to be affected by the speed of the PC.  If the difference you claim to have seen was real, I don't believe it had anything whatever to do with BBC BASIC.

Richard.

Ian_Wade_G3NRW
 

I couldn't possibly comment, except to say that the *only* change I made on the slow machine was to upgrade BB4W. The difference was certainly real, in that my program's output was then *identical* to that on the fast machine.

Lesson learned: before wasting time in tracking down a possible "bug", make sure the software is up to date.

--
Ian

On 06/05/2017 13:40, Richard Russell wrote:
On Fri, May 5, 2017 at 11:52 pm, Ian_Wade_G3NRW wrote:

I upgraded BB4W to 6.01a, and everything now works fine on the
slow machine.

Coincidence. There are no differences between v6.02a and v6.10a that could possibly explain it. Indeed, no release of BB4W has ever had a bug or feature that caused data written to a file using BPUT# to be affected by the speed of the PC. If the difference you claim to have seen was real, I don't believe it had anything whatever to do with BBC BASIC.

Richard.

Richard Russell
 

On Sat, May 6, 2017 at 06:27 am, Ian_Wade_G3NRW wrote:
Lesson learned: before wasting time in tracking down a possible "bug", make sure the software is up to date.

Yes, absolutely, but in this particular case updating the software was NOT responsible for the change.  I know precisely what changes were made in v6.10a and there is zero possibility that it could have had an effect.  Also,  BB4W has never had any fault which could cause the speed of the PC to have an effect on the output to a disc file.

Richard.