I say quirk since I am not sure it is a bug although I am inclined to say it it.
My Orwell computer is using MS Basic. I took the OSI version and have been modifying and adding to that as I work though my reviews of the 80s Usborne books. I just found some interesting behavior in a listing from "Creepy Computer Games" in a game called Ghost Guzzler.
This game prints a number on screen that moves across to the right. On the right is a : (your ghost guzzler) and another number you control. You make your number match the moving one and when the moving one hits the guzzler it eats it if it's the same. If different you lose a life. The line of code in BASIC of interest is this:
120 PRINT TAB(I);N;TAB(18);":";Y
Where I is the position of the number. N is the number and Y is your changing number.
I starts at 1.
When I run this it it starts printing the number in the third column, not the first one. This seems to be for two reasons.
1. In this version of MS Basic TAB seem indexed from 0. So TAB(0) is the first column, TAB(1) is the second column.
2. When you print a numeric variable it will print it with a space in front of it.
These two things together mean the first character is actually printed in column 3.
Out of interest I found an online Vic 20 emulator and that shows the same behaviour. I also found an online Applesoft emulator and that doesn't. It handles TABs differently and also doesn't print a space before variables.
So I compared the assembly. The relevant bits are below:
MS BASIC (My Orwell BASIC):
Code:
L29DE:
lda POSX
cmp Z18
bcc L29EA
jsr CRDO
jmp L2A0D
L29EA:
sec
L29EB:
sbc #$0E
bcs L29EB
eor #$FF
adc #$01
bne L2A08
L29F5:
pha
jsr GTBYTC
cmp #')'
bne SYNERR4
pla
cmp #TOKEN_TAB
bne L2A0A
txa
sbc POSX
bcc L2A0D
beq L2A0D
L2A08:
tax
L2A0A:
jsr OUTSP
dex
bne L2A0A
L2A0D:
jsr CHRGET
jmp PRINT2
Applesoft Basic:
Code:
1320 *--------------------------------
1330 * TAB TO NEXT COMMA COLUMN
1340 * <<< NOTE BUG IF WIDTH OF WINDOW LESS THAN 33 >>>
1350 PR.COMMA
DB03- A5 24 1360 LDA MON.CH
DB05- C9 18 1370 CMP #24 <<< BUG: IT SHOULD BE 32 >>>
DB07- 90 05 1380 BCC .1 NEXT COLUMN, SAME LINE
DB09- 20 FB DA 1390 JSR CRDO FIRST COLUMN, NEXT LINT
DB0C- D0 21 1400 BNE PR.NEXT.CHAR ...ALWAYS
DB0E- 69 10 1410 .1 ADC #16
DB10- 29 F0 1420 AND #$F0 ROUND TO 16 OR 32
DB12- 85 24 1430 STA MON.CH
DB14- 90 19 1440 BCC PR.NEXT.CHAR ...ALWAYS
1450 *--------------------------------
1460 PR.TAB.OR.SPC
DB16- 08 1470 PHP C=0 FOR SPC(, C=1 FOR TAB(
DB17- 20 F5 E6 1480 JSR GTBYTC GET VALUE
DB1A- C9 29 1490 CMP #')' TRAILING PARENTHESIS
DB1C- F0 03 1500 BEQ .1 GOOD
DB1E- 4C C9 DE 1510 JMP SYNERR NO, SYNTAX ERROR
DB21- 28 1520 .1 PLP TAB( OR SPC(
DB22- 90 07 1530 BCC .2 SPC(
DB24- CA 1540 DEX TAB(
DB25- 8A 1550 TXA CALCULATE SPACES NEEDED FOR TAB(
DB26- E5 24 1560 SBC MON.CH
DB28- 90 05 1570 BCC PR.NEXT.CHAR ALREADY PAST THAT COLUMN
DB2A- AA 1580 TAX NOW DO A SPC( TO THE SPECIFIED COLUMN
DB2B- E8 1590 .2 INX
DB2C- CA 1600 NXSPC DEX
DB2D- D0 06 1610 BNE DOSPC MORE SPACES TO PRINT
1620 *--------------------------------
1630 PR.NEXT.CHAR
DB2F- 20 B1 00 1640 JSR CHRGET
DB32- 4C D7 DA 1650 JMP PRINT2 CONTINUE PARSING PRINT LIST
1660 *--------------------------------
DB35- 20 57 DB 1670 DOSPC JSR OUTSP
DB38- D0 F2 1680 BNE NXSPC ...ALWAYS
It seems there is a difference in how it checks for how many spaces to print and when it does the decrement of the counter for the number of spaces (which is in x) but I haven't quite got my head around why in the first case it always prints one extra space?
So, would you call this a bug or not? I think it is. Interestingly it means if you enter the listing as it is in the book the program won't work properly on VIC20s!
I am writing up the actual review to the book now and will post the link here when done.
Simon