ATBASIC ERROR in string substrings

[okwatts]

If you try and extract a substring using A$(4,5) it appears that it is treated as a numeric and the left Bracket is used as exponentiation.
ie if B$="AB" and you print B$(1) you get 5.20200002e+53
Edit: This is on nano6502. This is for printing. If you let A$=B$(1) then print A$ you get the correct result.

[ivop]

I can not reproduce this:

Could you show the exact steps you took and its output?

[okwatts]

Here is a photo of my screen.

…

On Thu, Oct 3, 2024, 12:55 p.m. Ivo van Poorten ***@***.***> wrote: I can not reproduce this: atari000.png (view on web) <https://github.com/user-attachments/assets/f9f058f0-7682-47bc-aa3a-513f4168d86d> Could you show the exact steps you took and its output? — Reply to this email directly, view it on GitHub <#163 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APALSOMZP6QRTXAGSRBJFRTZZWOMFAVCNFSM6AAAAABNVWEK2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJSGIYTMOJUHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[venomix666]

I can reproduce it on the BBC Micro (using b-em), see screenshot below, but not on the Atari800 (using the atari800 emulator).

[venomix666]

I can also reproduce it on the Oric, VIC20 and PET (all emulated) - so somehow it seems to only work on the Atari. Strange!

[ivop]

I suppose some Atari dependency is still left in the source code (Altirra was originally written solely for the Atari), hence it working correctly on the Atari but not on other systems.

[davidgiven]

I have vague memories that Atari basic uses hardware to generate random numbers, and that doesn't work on the CP/M-65 port, so it's plausible that there's some other Atari-specific code I've missed. But it's too long ago now and I'd have no idea what it is.

[ivop]

Yes, it reads the Atari Pokey chip's RANDOM register, which is a 17-bit LFSR. I see you replaced that with lda #0 in funRnd 😄

I could add sfc16 from here. That would add better random numbers than the original on the Atari 😉 A simple 16-bit LFSR could also be done, if adding 180 bytes would be too large. xorshift16 for example.

This printing of a sub-string bug does not seem related though. I have no idea where to search for it.

[eduardocasino]

I think I've found the problem.

Altirra Basic uses a variable, expType, to differentiate between numeric and string variables. From atbasic.s:

expType     dta     0       ;bit 7 = 0 for numeric, 1 for string

I've seen throughout the code that the developers try to save some bytes and cycles by assigning this variable with values intended for something else, like function tokens or address labels, which are known to have bit 7 set or cleared. For example, in this snippet from functions.s:

		;address += start
		ldy		#fr1+2
		sty		expType				;!! - set expression type to string!
		jsr		IntAddToFR0

Here, Y is an argument for IntAddToFR0 and fr1 is the address of the floating point register 1, which in the Atari 800 happens to be at ZP address 0xE0, so it has bit 7 set.

The probem is that, in the CP/M port, those ZP addresses are not fixed and may be assigned to locations above or below 0x80, depending on the memory map of the target system and it seems that, in many cases, it is below, so the expression type is being set to "integer" and printed as such.

I'm opening a pull request with this proposed fix:

--- a/third_party/altirrabasic/source/functions.s
+++ b/third_party/altirrabasic/source/functions.s
@@ -639,8 +639,9 @@ use_limit_as_end:
                ;##ASSERT dw(fr1+4) <= dw(fr0+4)

                ;address += start
-               ldy             #fr1+2
+               ldy             #$80
                sty             expType                         ;!! - set expression type to string!
+               ldy             #fr1+2
                jsr             IntAddToFR0

                ;capacity -= start

[ivop]

Good catch! On the Atari port of CP/M-65, fr1 is still above 0x80, hence the problem does not manifest itself.

[davidgiven]

Oof. Yikes. Thank you for finding this. That's the kind of optimisation which looks like a good idea until it isn't.