STR$ in BASIC VI not following the documentation

According to https://www.riscosopen.org/zipfiles/platform/common/BASICRefManual.3.pdf?1613981974 STR$ should behave as if @% is &0A00 if the top byte isn’t set to 1. However, and my apologies if I am referencing out-of-date documents, the behaviour within BASIC VI is as if @% is &1100 rather than the documented &0A00.

There’s a discussion over here https://distillery.matrixnetwork.co.uk:3004/discussion/10/what-is-the-correct-behaviour-of-0 concerning the behaviour of @%, and I was rather surprised to discover how inconsistent RISC OS is with itself, let alone other implementations of BBC BASIC!

I would say on any version of BASIC; do not rely on the default output formatting, and specifically request the formatting you require.

as if @% is &1100

Do you really mean that? The second byte &11 is decimal 17, but it should only have values of 1-10, giving the digits in General format, or significant figues after decimal point in Exponent format, or number of digits after decimal point in Fixed format.

A code snippet to illustrate your problem would help.

That length seems valid to me for a 64-bit float.

According to page 367 of that manual:

The optional + sign is a switch affecting the STR$ function. If supplied, it forces
STR$ to use the format determined by @%. If it is not supplied, STR$ uses a default
format equivalent to @%=“+G0.10”

@Andre Timmermans:

That doesn’t match what I see.

STR$ uses a default format equivalent to @%=“+G0.10”

@% = “+G0.10” is the same as @% = &01000A00 (i.e. 10 significant figures), is it not? I agree with Michael that the behaviour of BASIC VI (i.e. BASIC64) in producing a value with 17 significant figures seems incompatible with this documentation.

Sorry – I missed the BASIC VI – and there was no mention of floating point.
I suspect that the BASIC documentation is based largely on BASIC V, as it is the one that is normally used. Although the manual does cover many of the differences, it does not seem to specifically include that difference.

I’d say this is a documentation error – when BASIC VI was introduced the manual wasn’t updated properly to reflect all the changes. Subsequent updates to the manual have improved things a bit, but it looks like some differences in @% and STR$ still got missed. E.g. for @% the documentation says “Byte 2 (yy), which can take values from 1 to 10, determines the number of digits printed” – 10 digits is the BASIC V limit, not the BASIC VI one.

Also – (and I think it’s related to https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/BASIC/-/commit/99e7d1205f6e7e981672b23e5257d64ee528c360 ) setting @% to &Bxx appears to be valid in newer builds of the BASIC module. (I’m currently running V1.84 of both BASIC V and VI.)

Very true – I increased the limit from 10 to 11 for BASIC V because 10 was too low for all numbers to have a unique decimal representation.

I’ll put together a list of corrections for the manual.

Taking a further look at this, the documentation states (page 368 in the PDF linked in the original post) the precision can take a value 1-10. We’ve established already that 11 is valid for newer BASIC V and 17 for BASIC VI. However, a value of 0 isn’t mentioned (thus probably “illegal”), but across the board all the way back to the BBC Micro, and in RISC OS BASIC V and VI it has the effect of using the maximum available precision. Is this by chance or by design, and if it is by design, surely this should also be documented as such? Indeed the string parser is quite happy to translate “G0.0” to @%=0.

There is explicit code to handle that case – but without checking for similar code in the 6502 source, it’s hard to say whether it’s by design or just copying a side-effect of the 6502 implementation.

        TST     FDIGS,#255
        BNE     FCONA
        TEQ     FMAT,#2
        ORRNE   FDIGS,FDIGS,#MAXDIGS   ;if not in format 2 use maximum digits instead of 0
FCONA ; ... remainder of code here

(format 2 == ‘F’)

https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/BASIC/-/blob/ba89c118c6a367b980925a9005d00dffea01397c/s/fp2#L375

That gave me a good pointer of what to look for. From Jonathan Harston’s disassemblies of 6502 BASIC 2, we have:

.L9EDF
LDX ws+&0402             :\ Get format byte
CPX #&03:BCC L9EE8       :\ If <3, ok - use it
LDX #&00                 :\ If invalid, &00 for General format
.L9EE8
STX &37                  :\ Store format type
LDA ws+&0401:BEQ L9EF5   :\ If digits=0, jump to check format
CMP #&0A:BCS L9EF9       :\ If 10+ digits, jump to use 10 digits
BCC L9EFB                :\ If <10 digits, use specified number
.L9EF5
CPX #&02:BEQ L9EFB       :\ If fixed format, use zero digits
\ STR$ enters here to use general format
\ --------------------------------------
.L9EF9
LDA #&0A                 :\ Otherwise, default to ten digits

BASIC 1 has similar (but it’s less commented, and maxes at 9 digits instead of 10):

.L9ED0
LDX ws+&0402
CPX #&03:BCC L9ED9
LDX #&00
.L9ED9
STX &37
LDA ws+&0401:BEQ L9EE6
CMP #&09:BCS L9EEA
BCC L9EEC
.L9EE6
CPX #&02:BEQ L9EEC
.L9EEA
LDA #&09

This from CMOS BASIC (see https://github.com/stardot/AcornDmosBasic/blob/master/src/DBAS07):

FCON LDX VARL+2 ;flag forcing E
 CPXIM 3
 BCC FCONOK
 LDXIM 0 ;Default to G format
FCONOK STX WORK
 LDA VARL+1
 BEQ FCONC
 CMPIM &0A
 BCS FCONA
;  In G,E formats varl is no. of sig figs >0
;  In F format it is no. of decimals and can be >=0
 BRA FCONB
FCONC CPXIM 2
 BEQ FCONB
FCONA LDAIM 10 ;enter here for str$, having set work to 0
FCONB STA WORK+1