BASIC programming tips

[Bryce]

Without a read error half way through, it's just not the same

Bryce.

[redbox]

I've got one for all of you BASIC aficionados...

I have a 16-bit number in myvar (i.e. from range 0 - 65535).  I want to convert it to high byte & low byte.

If I do this:

Code Select Expand


myhighbyte = myvar / 256 : highbyte = FIX ( myhighbyte )
lowbyte = myvar MOD 256


...then I get overflow errors. 

Any ideas?

[arnoldemu]

myhighbyte = myvar \ 256 : lowbyte = myvar AND 255

try that.


\ is integer division.

AND can be used as both for ANDing a value, and as a statement joiner (a=3 AND b=4).

MOD may use float division, same with FIX.

[redbox]

myhighbyte = myvar \ 256 : lowbyte = myvar AND 255

try that.

Thanks.

Still getting overflow when myvar = 33924.

Does it only work within signed limited (i.e. -32768 to 32768)...?

[arnoldemu]

Thanks.

Still getting overflow when myvar = 33924.

Does it only work within signed limited (i.e. -32768 to 32768)...?

33924 is probably being stored as a float value internally. yes, seems it is.
can you do it as a hex value? e.g. a=&c000

[arnoldemu]

Thanks.

Still getting overflow when myvar = 33924.

Does it only work within signed limited (i.e. -32768 to 32768)...?

a% will be signed
a will end up being floating point
c=&aaaa actually ends up being unsigned 16-bit.

[redbox]

a% will be signed
a will end up being floating point
c=&aaaa actually ends up being unsigned 16-bit.

So is there anyway to turn floating point variable into unsigned 16-bit?

[Urusergi]

I've got one for all of you BASIC aficionados...

I have a 16-bit number in myvar (i.e. from range 0 - 65535).  I want to convert it to high byte & low byte.

If you have a number from range 0 - 65535 then it's necessary to convert to 16 bit number (-32768 - 32767)

Code Select Expand

alter=VAL("&"+HEX$(myvar))

[Grim]

If you have a number from range 0 - 65535 then it's necessary to convert to 16 bit number (-32768 - 32767)

Code Select Expand

alter=VAL("&"+HEX$(myvar))

See UNT, which uses the Firmware Math function INTEGER TO REAL (No need to reinvent the wheel :)

Code Select Expand


alter=UNT(myvar)
I'm not sure however that a BASIC keyword exists to do the other way around (eg. based on the Firmware Math function REAL TO INTEGER).


One way to avoid all that mess with variable type:

Code Select Expand


myvar = 33924
hi = int(myvar / 256)
lo = myvar - 256*hi

It should work whatever type myvar is.

[redbox]

Thanks guys, much appreciated.

I went with Grim's last example (as I'd come close to this myself but didn't get the order/syntax right) and it's all working now.

Sometimes a bit of BASIC is a lot quicker than C or Python

[Urusergi]

See UNT, which uses the Firmware Math function INTEGER TO REAL (No need to reinvent the wheel

Code Select Expand


alter=UNT(myvar)


Oh! well, I didn't know that command     Thanks 

One way to avoid all that mess with variable type:

Code Select Expand


myvar = 33924
hi = int(myvar / 256)
lo = myvar - 256*hi

It should work whatever type myvar is.

Then, this code...

Code Select Expand


myvar = 33924
hi = int(myvar / 256)
lo = unt(myvar) and 255


is 2 bytes less, and it's a little faster, isn't it?

[Grim]

Code Select Expand


myvar = 33924
hi = int(myvar / 256)
lo = unt(myvar) and 255

is 2 bytes less, and it's a little faster, isn't it?

Indeed! It's better that way! (smaller, faster and still works with any numeric type)

[Sykobee (Briggsy)]

See UNT, which uses the Firmware Math function INTEGER TO REAL (No need to reinvent the wheel

Code Select Expand


alter=UNT(myvar)
I'm not sure however that a BASIC keyword exists to do the other way around (eg. based on the Firmware Math function REAL TO INTEGER).

Wouldn't you just co-erce the result of FIX, INT or ROUND into an integer type? i.e., a%=ROUND(3.14,0) would give an signed integer with a value of 3.


I've just tested (painfully, annoying french keyboard mapping) in CPCBox and this works (just add 40000 and check for Overflow)


BASIC's PRINT keyword treats "unsigned" integers as signed integers, so the value=&FFFF method is only useful for assigning a 16-bit value directly.

Code Select Expand


myvar = 33924
hi = int(myvar / 256)
lo = unt(myvar) and 255


hi and lo here are still reals, using 5 bytes and being slightly slower. I'd definitely rather use hi% and lo%, or DEFINT h,l :-)
Sadly I can't confirm this because there is no \ key in CPCBox.

[Urusergi]

hi and lo here are still reals, using 5 bytes and being slightly slower. I'd definitely rather use hi% and lo%, or DEFINT h,l :-)
Sadly I can't confirm this because there is no \ key in CPCBox.

Yes! It's a bit faster using % 

[Grim]

Wouldn't you just co-erce the result of FIX, INT or ROUND into an integer type? i.e., a%=ROUND(3.14,0) would give an signed integer with a value of 3.

Nay. ROUND, FIX, CINT, INT & co are real-to-real functions, they expect a real (ie. 40-bit float) as input (and will convert the input automagically if necessary) and output a real. So ROUND(33000) is exactly the same as writing 33000 directly, both result with the same real number. So when trying to fit that real number into a signed integer variable (a%), if the real is beyond the signed integer range (-32768 to 32767), the conversion will overflow (eg a%=33000).

The issue Redbox had was that he was trying to apply 16-bit signed integer operations (such as MOD or AND like in myvar MOD 256) to unsigned 16-bit values stored as real number (For real! Aye! Ye're still there floating with me? :)

So in that case, we can keep it real all along (myvar - 256*hi) or switch to 16-bit signed integer (unt(myvar) and 255). The later is more efficient, and even more so when the variables are also cast to signed integer, aye! :)

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

[Sykobee (Briggsy)]

Nay. ROUND, FIX, CINT, INT & co are real-to-real functions, they expect a real (ie. 40-bit float) as input (and will convert the input automagically if necessary) and output a real. So ROUND(33000) is exactly the same as writing 33000 directly, both result with the same real number. So when trying to fit that real number into a signed integer variable (a%), if the real is beyond the signed integer range (-32768 to 32767), the conversion will overflow (eg a%=33000).

The issue Redbox had was that he was trying to apply 16-bit signed integer operations (such as MOD or AND like in myvar MOD 256) to unsigned 16-bit values stored as real number (For real! Aye! Ye're still there floating with me?

Thanks - I was specifically responding to the question posed: "I'm not sure however that a BASIC keyword exists to do the other way around (eg. based on the Firmware Math function REAL TO INTEGER)." to which the answer is that you need to consider what you want to do with the decimal places first (using the real->real functions).  If you know there are no decimal places (or overflow risk), then I presume you can do integer%=real to cast?


What I meant by co-ercing was exactly that of specifying the target variable for the function as a signed integer, i.e., a cast.  Yes, there are opportunities for overflow, and you need to consider this in your design. :-)

[AMSDOS]

I've been having a look at some early BASIC programs from 1984, this particular program from 60 Programs for the Amstrad CPC464 presents an interesting challenge because this game is harder on a 664/6128 while at the same time still being playable.


The challenge in this program is the M/C routine at the end of the program, which sets up TXT RD CHAR (&BB60). An interesting Firmware instruction because it returns different ASCII results and the program below is certainly in that category. For this program "Dambusters" on a 464 TXT RD CHAR will return a zero result if the area is something in it (including graphics). For 664/6128 machines using BASIC 1.1, it has the COPYCHR$(#0) which is used to return a Text Based character, ASCII values can be returned if ASC(COPYCHR$(#0)), however what happens (and this also occurs in the Firmware TXT RD CHAR), is different results occur even when graphical are present, so values don't change until TXT characters are found.



The easiest solution I could come up with in this program was to modify Line 490 from:

Code Select Expand

490 FOR A=1 TO 5:SOUND 1,220,4:SOUND 1,90,4:NEXT A:LOCATE X+1,20:CALL 360:K= PEEK(367):IF K=32 THEN 510


to:

Code Select Expand

490 FOR A=1 TO 5:SOUND 1,220,4:SOUND 1,90,4:NEXT A:LOCATE X+1,20:CALL 360:K= PEEK(367):IF (X>12 AND X<21) AND K=32 THEN 510


so now the program behaves like the 464 version, the program will also work on a 464, though it doesn't fix the difference between TXT RD CHAR on the different machines.

Code Select Expand

10 REM DAMBUSTERS
20 REM @ PAUL STANLEY.
30 MODE 1:BORDER 4:INK 0,16:INK 1,0:INK 2,20:INK 3,6:WINDOW #1,1,40,1,25:PAPER #1, 0:PEN #1,1:CLS
40 HS=0
50 GOSUB 960
60 GOSUB 770
70 GOSUB 620
80 BORDER 1:INK 0,0:INK 1,24:INK 2,20:INK 3,6:WINDOW #0,5,36,1,25:PAPER #0, 0:PEN #0,1:CLS #0
90 PEN 2:LOCATE 1,1:PRINT"SCORE:0":PEN 1
100 PEN 3:LOCATE 19,1:PRINT"HI-SCORE:";:PEN 2:PRINT HS:PEN 1
110 LOCATE 1,22:PRINT CHR$(24); STRING$(64,58);CHR$(24)
120 FOR F=1 TO 150 :PLOT 64+RND*506,RND*400+128,2:NEXT
130 G=0:FOR F=1 TO 5:PLOT G*2+64,15+F*2+48,2:DRAWR 508-4*G,0:G=G+2:NEXT
140 PLOT 100,72,2:DRAWR 216,40:PLOT 532,72:DRAWR -216,40
150 PLOT 64,64,3:DRAWR 0,32:DRAWR 8,0:DRAWR 16,16:DRAWR 4,- 4:DRAWR -16,-16:DRAWR 0,-20
160 PLOT 572,64,3:DRAWR 0,32:DRAWR -8,0:DRAWR -16,16:DRAWR -4,-4:DRAWR 16,-16:DRAWR 0,-20
170 D=1:S=0:A=1:P=17
180 Y=9
190 X=INT(RND*20)+6
200 PRINT CHR$(22);CHR$(1);:FOR F=1 TO 5 STEP 2:PEN 1:LOCATE X+1,6:PRINT MID$(B$,F,1);MID$(B$,F+1,1);:SOUND 1,120,4:PEN 0:LOCATE X+1,6:PRINT MID$(B$,F,1);MID$(B$,(F+1),1);:NEXT F
210  FOR F= 1 TO 4:PEN 1:LOCATE X+1,6-F:PRINT MID$(B$,5,1);MID$(B$,6,1):LOCATE X+1,6+F:PRINT CHR$(232);
220 SOUND 1,180,4:PEN 0:LOCATE X+1,6-F:PRINT MID$(B$,5,1);MID$(B$,6,1);: LOCATE X+1,6+F:PRINT CHR$(232);:NEXT F:PEN 1:PRINT CHR$(22);CHR$(0);
230 F=INT(RND*25)+3:G=5+INT(RND*11)
240 A$=CHR$(231)+CHR$(232)+CHR$(233)+CHR$(234)+CHR$(235)+CHR$(235)+CHR$(236):HT=10
250 PEN 1: LOCATE X+1,Y+1:PRINT  CHR$(22);CHR$(1);MID$(A$,A,1);CHR$(22);CHR$(0);
260 F=F-(INKEY(1)=0 AND F<29)+(INKEY(8)=0 AND F>2):G=G-(INKEY(2)=0 AND G<17)+(INKEY(0)=0 AND G>3)
270 PEN 2:LOCATE F+1,G+1:PRINT CHR$(22);CHR$(1);"+";CHR$(22);CHR$(0);:PEN 1
280 LOSS=LOSS+LEEK
290 IF LOSS>1000 THEN 550
300 IF INKEY (47)=0 THEN IF S<10 THEN GOSUB 430
310 SOUND 1,100,4
320 PEN 0: LOCATE X+1,Y+1:PRINT CHR$(22);CHR$(1);MID$(A$,A,1);CHR$(22);CHR$(0);
330 PEN 0: LOCATE F+1,G+1:PRINT CHR$(22);CHR$(1);"+";CHR$(22);CHR$(0);:PEN 1
340 PLOT 100,72,2:DRAWR 216,40:PLOT 532,72:DRAWR -216,40
350 Y=Y+D
360 IF RND>0.6 THEN F=F+INT(RND*1.5)-INT(RND*1.5)
370 IF F<0 THEN F=0
380 IF RND<0.4 THEN G=G+INT(RND*1.5 AND G<18)-INT(RND*1.5)
390 IF Y=HT THEN P=P+1:D=1:A=A+1
400 IF Y=P THEN SOUND 1,180,4:A=A+1:D=-1:HT=HT-3
410 IF A=7 THEN 490
420 GOTO 250
430  PLOT 90,112,2:DRAW (F+1)*16+54,(24-G)*16+8,2:PLOT 546,110,2:DRAW (F+1)*16+54,(24-G)*16+8,2
440 S=S+1
450 PLOT 90,112,0:DRAW (F+1)*16+54,(24-G)*16+8,0:PLOT 546,110,0:DRAW (F+1)*16+54,(24-G)*16+8,0
460 IF G=Y THEN IF X=F THEN 480
470 RETURN
480 SC=SC+10: LOCATE 7,1:PRINT SC;:LOCATE F+1,G+1:PRINT CHR$(238);:SOUND 1,180,4:SOUND 1,120,4:SOUND 1,90,4:SOUND 1,50,4:LOCATE F+1,G+1:PRINT" ";: GOTO 170
490 FOR A=1 TO 5:SOUND 1,220,4:SOUND 1,90,4:NEXT A:LOCATE X+1,20:CALL 360:K= PEEK(367):IF (X>12 AND X<21) AND K=32 THEN 510
500 LOCATE X+1,20:PRINT"  ";:GOTO 170
510 LOCATE X+1,21:CALL 360:K=PEEK(367):IF K<>58 THEN 540
520 LEEK=LEEK +1
530 LOCATE X+1,21:PRINT" ";:LOCATE X+1,22:PRINT CHR$(237);:GOTO 170
540 LET LEEK = LEEK +2:LOCATE X,20:PRINT"   ";:LOCATE X,21:PRINT"   ";:LOCATE X,22:PRINT CHR$(237);CHR$(237);CHR$(237);:GOTO 170
550 LOCATE 6,11:PRINT"- G A M E  O V E R -":LOCATE 3,14:PRINT"PRESS ANY KEY TO PLAY AGAIN": FOR F= 1 TO 20:SOUND 1,(F+100),4:NEXT
560 IF SC>HS THEN HS=SC
570 LOSS=0:SC=0:LEEK=0
580 IF INKEY$<>"" THEN 580
590 IF INKEY$ = "" THEN 590
600 CLS: RESTORE: GOTO 80
610 GOTO 610
620 SYMBOL AFTER 230
630 SYMBOL 231,0,0,0,16,0,0,0,0
640 SYMBOL 232,0,0,0,24,24,0,0,0
650 SYMBOL 233,0,0,0,56,56,0,0,0
660 SYMBOL 234,0,0,0,60,60,60,0,0
670 SYMBOL 235,0,0,126,126,126,126,0,0
680 SYMBOL 236,0,0,254,254,254,254,254,0
690 SYMBOL 237,73,145,73,37,74,145,74,73
700 SYMBOL 238,153,58,36,219,219,36,58,153
710 SYMBOL 239,0,0,0,8,62,0,0,0
720 SYMBOL 240,0,0,24,255,66,0,0,0
730 SYMBOL 241,0,0,1,255,37,0,0,0
740 SYMBOL 242,0,0,128,255,164,0,0,0
750 B$=CHR$(239)+" "+CHR$(240)+" "+CHR$(242)+CHR$(242)
760 RETURN
770 LOCATE 11,1:PRINT CHR$(24);"D A M B U S T E R S":LOCATE 11,2:PRINT"  @ PAUL  STANLEY  ";CHR$(24)
780 PRINT:PRINT"The year is 1943.You are in charge of a powerful Beam weapon with which you are to protect a Dam from the bouncing bombsof the British attackers."
790 PRINT
800 PRINT"They  have  several  Lancaster  bombers which fly towards you and release their dangerous bombs, which might miss their target."
810 PRINT
820 PRINT"However,your task is not all that simplefor your weapon is unable to reach the  Lancasters so you must just shoot at thebombs instead.                          You can move your cross-hair sights withthe cursor keys."
830 PRINT:PRINT:PRINT"        PRESS ANY KEY TO CONTINUE."
840 IF INKEY$="" THEN 840 ELSE CLS
850 LOCATE 11,1:PRINT CHR$(24);"D A M B U S T E R S":LOCATE 11,2:PRINT"  @ PAUL  STANLEY  ";CHR$(24)
860 PRINT:PRINT:PRINT
870 PRINT"Even adjusting the sights is difficult  because there is a strong Wind which    causes  your  sights  to move  about."
880 PRINT
890 PRINT"USE THE SPACE BAR TO FIRE."
900 PRINT:PRINT
910 PRINT"Because  of  the power of your weapon,  after 10 shots it is drained of power   and will only be ready by the next time an aeroplane attacks.Your battle is over";
920 PRINT"when too much water has poured through  the broken Dam."
930 PRINT:PRINT:PRINT:PRINT"         PRESS ANY KEY TO START."
940 IF INKEY$="" THEN 940 ELSE CLS
950 RETURN
960 RESTORE 970:FOR x=360 TO 366:READ a:POKE x,a:NEXT:RESTORE: RETURN
970 DATA 205,96,187,50,111,1,201

[Gryzor]

Damn that was hard

[AMSDOS]

Damn that was hard

Yesterday was a funny day gaming wise, I typed in this game and in it's unchanged condition the game is still playable  with BASIC 1.1 except if you don't shoot down one of the bombs, the bomb puts a hole in your Dam guaranteed which causes the Dam to Leak until no water is left and it's game over. It's funny though how you can keep on shooting Bombs and increasing your score even when the Dam is leaking.    In BASIC 1.0 I cracked the game once until I got up to a score of 620 or so and got a Memory Full error. Not sure why that happened.


It's probably not the best example of TXT RD CHAR being used, other 464 games are unplayable with BASIC 1.1 because of TXT RD CHAR, the simple answer is BASIC 1.1 Firmware cannot perform what TXT RD CHAR does on a 464, which is simply detect if anything is within the cursors position, if it's text based an ASCII result it all well and good for all machines, but if it's something graphical, the 464 will return the result of 0, if it's only graphical the 1.1 Firmware will return 32.


So the way I see it, the error here is a fundamental firmware routine was changed, so it's no longer possible to return a 0 result if it's a 664/6128. Certainly hair pulling stuff given Dambusters was written in 1984 in possibly one of the first books to come out for the 464. I can only wonder if it was a deliberate ploy to modify the 1.1 firmware.


I can write another example of where this fault stands out and simulate the results on those machines if you like.

[AMSDOS]

I made my own test program for TXT RD CHAR and found an interesting discovery. Initially the program was working on all machines, which means even graphics can return results of 0 if they are in that cursor position. This left only one test to do, the colour of the graphics. This test seems to confirmed the explanation of the different results on the different computers. On a 464, it doesn't seem to matter what colour of the graphics is, however this seems to be a big deal with BASIC  1.1s Firmware when the TXT RD CHAR check is carried out. A difference in PEN colour won't trigger the 0 result from TXT RD CHAR, unless it's in the same colour, where's a 464 will return 0 if any graphic in any colour is present in that position.
Test this program below by changing line 70 to include a PEN 2 at the start and the Ball will bounce in the inner square and watch how it escapes the square when the Ball is in a different colour.


On the 464 the Ball will continue to bounce in that square regardless of the colour of it.



Is that unusual? 

Code Select Expand

10 MODE 1:INK 1,26:BORDER 2
20 SYMBOL 255,60,126,126,126,126,126,126,60
30 BALL$=CHR$(255)
40 X=14:DIR=1
50 GOSUB 1000:GOSUB 2000:GOSUB 3000
60 WHILE INKEY(47)=-1
70 CALL &BD19:CALL &BD19
80 LOCATE X,11:PRINT CHR$(255)
90 LOCATE X+DIR,11:CALL 360:RESULT%=PEEK(367)
100 IF RESULT%<>32 THEN DIR=NOT DIR-1
110 OLDX=X:X=X+DIR
120 LOCATE OLDX,11:PRINT" "
130 WEND:MODE 2:CALL &BC02:END
1000 PLOT 200,150,2:DRAW 200,300:DRAW 350,300:DRAW 350,150:DRAW 200,150
1010 RETURN
2000 LOCATE 2,5:PRINT CHR$(150);STRING$(36,CHR$(154));CHR$(156)
2010 FOR Y=6 TO 20:LOCATE 2,Y:PRINT CHR$(149):LOCATE 39,Y:PRINT CHR$(149):NEXT Y
2020 LOCATE 2,21:PRINT CHR$(147);STRING$(36,CHR$(154));CHR$(153)
2030 RETURN
3000 FOR addr=&168 TO &16F
3010 READ a$
3020 POKE addr,VAL("&"+a$)
3030 NEXT addr:RETURN
3040 DATA cd,60,bb,32,6f,01,c9,00

[Singaja]

Hi. I've been a ghost reader for a little and I guess it's high time to say hi everyone ;-) I stumbled upon this article about overscanning, and was astonished it could be done in pure Basic. Inspired I browsed through all this crtc stuff on the wiki and ended up with this ;-)

Code Select Expand


10 BORDER 0
20 OUT &BC00,2
30 OUT &BD00,46
40 OUT &BD00,45
45 OUT &BD00,45
50 OUT &BD00,44
60 OUT &BD00,45
65 OUT &BD00,45
70 OUT &BD00,46
80 OUT &BD00,47
85 OUT &BD00,47
90 OUT &BD00,48
100 OUT &BD00,47
105 OUT &BD00,47
106 OUT &BC00,2
110 GOTO 20

I'd love to add this blinking tape effects on the borders ,can it be done in basic?

[ZbyniuR]

How to put machine code in Basic without FOR READ POKE NEXT DATA. Short and fast way, just in one PRINT.

Line 5 is need only once to generate 32 characters. Place them in quotes in PRINT in line 10. Now line 5 is no needed any more. Save and RUN and press any keys.

This is LDIR demonstration. Working after reset or after SYMBOL AFTER 240.

Of course CAT is just tu show whatever on screen. Because CALL HIMEM+13 make copy from &c000 to &4000, and CALL HIMEM+1 opposite.

5 FOR a=1 TO 63 STEP 2:PRINT CHR$(1)CHR$(VAL("&"+MID$("19F02101401101C001D019F13FEDB0C92101C01119F2014001D03FEDB0C90432",a,2)));:NEXT:EDIT 10
10 PRINT"":CAT:CALL HIMEM+13:WHILE-1:CLS:CALL &BB18:CALL HIMEM+1:CALL &BB18:WEND

[AMSDOS]

Following on from the last program, I was able to store a series of INK Palette Colours in a String, and get it's VALue when setting those INKs.
Because values range from 00 to 26, I need a second variable to increment by 2 & Single Values have to start with a '0'.


I've lengthened the program with a little Demo, the actual routine occupies Lines 100 to 150.

Code Select Expand

10 CALL &BC02
20 MODE 0
30 GOSUB 160
40 CALL &BB18
50 MODE 0:GOSUB 100
60 CALL &BB18
70 PEN 1
80 END
100 cols$="00261102010306162522151319181409"
110 i%=1
120 FOR p%=0 TO 15
130  INK p%,VAL(MID$(cols$,i%,2))
140  i%=i%+2
150 NEXT p%
160 FOR p%=0 TO 15
170  PEN p%
180  PRINT "Pen ";p%
190 NEXT p%
200 RETURN



I was also able to setup a Graphical Figure using a String Array, but thought this might be more useful. 

[ZbyniuR]

Palette in string?

10 c$="\0@@\1zz\2kk\3bb\4aa\5cc\6ff\7pp\8yy\9vv\:oo\;mm\<ss\=rr\>nn\?ii":PRINT c$

Type it but instead "\" put ctrl+"\" and effect is the same, without FOR-NEXT. This is exactly your palette.

[AMSDOS]

Palette in string?

10 c$="\0@@\1zz\2kk\3bb\4aa\5cc\6ff\7pp\8yy\9vv\:oo\;mm\<ss\=rr\>nn\?ii":PRINT c$

Type it but instead "\" put ctrl+"\" and effect is the same, without FOR-NEXT. This is exactly your palette.

What about Graphics?