First BASIC program (since the late 80s)

Dmian

Ok, I haven't written a BASIC program since I was a kid, and since I'm not a programmer, I wanted to do something simple and visual to get the rust off me.
This is the first thing I do in BASIC in more than 30 years, so be kind to me...

10 SCREEN 12:CLS 
20 w=PSIZE(0):h=PSIZE(1)
30 FOR i=1 TO 4096
40   PSET INT(RND(1)*w),INT(RND(1)*h),INT(RND(1)*255)
50   WAIT 5
60 NEXT i
70 WAIT 1000
80 SCREEN 1:CLS 
90 END

I had to add a couple WAIT there because the program was too fast for the OPi.
Also, I don't like how the system doesn't return to the original SCREEN setting, so I return to 1 (though I can probably find out which one is set and return to that, but I didn't want to add that level of complexity).
I'll keep playing with this, but I have to say that I'm having a lot of fun doing things in BASIC. It brings back a lot of memories. Cheers!

uli

I have written something yesterday that goes in the same direction: 😀

screen 14
stars = 150

dim star_x(stars)
dim star_y(stars)
dim star_z(stars)
dim star_v(stars)
dim star_color(stars)

for i=0 to stars
  call new_star(i)
next

do
  vsync
  cls
  for i=0 to stars
    star_z(i) = star_z(i) - star_v(i)
    if star_z(i) <= 0 then
      call new_star(i)
    endif
    x = star_x(i) / star_z(i) + psize(0) / 2
    y = star_y(i) / star_z(i) + psize(1) / 2
    if x < 0 or x >= psize(0) or y < 0 or y >= psize(1) then
      call new_star(i)
    endif
    pset x, y, star_color(i)
  next
loop

proc new_star(n)
  @z = @n + 1
  star_x(@n) = -30000 + rnd(60000)
  star_y(@n) = -30000 + rnd(60000)
  star_z(@n) = @z
  star_v(@n) = 2 + int(rnd(0) mod 2)
  star_color(@n) = rgb(255 - @z, 255 - @z, 255 - @z)
  return

While I was at it, I have fixed PSET not to throw an error when drawing pixels that are outside screen limits, and CLS to properly clear the screen in modes where the screen dimensions are not divisible by the font size.

Dmian

uli Looks really nice!
I had to get rid of the VSYNC though, because none of my monitors seemed to like it, and I got a black screen.
Also: I have no idea how to stop it when it's running. 😅

I thought of making little programs as a way to incrementally learn basic functions. This one is kind of a "one liner" type of funny program.
My idea is to keep making very simple programs that do one thing (loading a sprite, make it move, detect key presses, detect a collision, move a background, make a platform, implement a jump routine), and finally tie everything together and make a really simple game. That is not only for me, but for kids who want to learn BASIC programming, since I remember clearly what I wanted to do with computers when I first started... 😊
It is a nice way to remember how to program in BASIC and teach others.

I think I need to make one that makes lines, and another that makes circles, since I often see those used as benchmarks for old computers (see the CMM2). After those, I'll make more. Such fun!

Peek

Dmian
I tried your code on the H3 and it ran as expected, exiting when a key is pressed. I also tried on the original hardware and it worked as well, all I did was remove the screen commands from line 10 and line 70. I'll try again on the H3 after I update the firmware.

uli
I love the starfield program. The last time I tried using local variables with an array in a procedure it gave me a ton of issues. I assumed it was just not doable based on the warning I saw in the manual but it looks like I'll have to play around with it more.

Dmian

I simplified the program a bit, because I wanted it to keep running until a key is pressed:

10 SCREEN 12:CLS
20 w=PSIZE(0):h=PSIZE(1)
30 DO
40 PSET INT(RND(1)*w),INT(RND(1)*h),INT(RND(1)*255)
50 k=INKEY()
60 LOOP WHILE k=0
70 SCREEN 1:CLS
80 END

The problem I'm having is that it's not detecting the keypress. It keeps running, no matter what key I press. I have no idea what I'm doing wrong, but I must say that having a Reset button is a godsend 😄

SanguineBrah

Dmian I think you are confusing INKEY and KEY. It should be k=KEY(75) (75 being the key code for the K key).

SanguineBrah

Dmian I should also say that if you ever need to break out of a program, ctrl-c should always work and saves you from losing whatever's in memory by reseting.

Dmian

Same program, adapted for circles (WARNING! Flashing images):

10 SCREEN 15:CLS
20 w=PSIZE(0):h=PSIZE(1)
30 DO
40 col=INT(RND(1)*255)
50 CIRCLE INT(RND(1)*w),INT(RND(1)*h),INT(RND(1)*25+5),col,col
60 k=INKEY()
70 LOOP WHILE k=0
80 SCREEN 1:CLS
90 END

Dmian

SanguineBrah I may be wrong, but I think INKEY() reads the keyboard, and returns "0" if no key is pressed or the key value if a key is pressed. So, in theory, the loop continues as long as no key is pressed, and breaks when any key is pressed. I checked it with a simple program like this:

10 DO
20 k=INKEY()
30 LOOP WHILE k=0
40 PRINT k

I run it, and it worked, but it didn't work in the dots program. So maybe I'm missing something.
And yes, I tried CTRL+C (the first thing I usually go to), and many other usual execution breaking combinations like CTRL+Backspace, ESC, CTRL+ESC, etc., and nothing seemed to work, except for the (highly appreciated!) Reset button.
I'll keep checking to see if I missed something.

SanguineBrah

Dmian You're right, I'm misreading the reference entry for INKEY. I thought it was something to do with converting characters to keycodes.

uli

I just tried the starfield with both 1920x1080 (HDMI) and 1280x1024 (DVI), and it works perfectly fine, VSYNC and Ctrl-C included.

Could you do me a favor and try this with basicengine-firmware-h3-v0.89-167-g730c.zip as well as with a current build and see if there is any difference?

I have recently changed the LCD interrupt to use vblank instead of the scan line trigger because that gives more time for rendering the next frame. I have no idea why Charlie used the scan line instead of vblank; who knows, maybe there is something broken with it.

That said, in Engine BASIC pretty much everything is timed off the LCD controller interrupt, and if there were a problem with it, it would break the entire system, not just a few select features...

[BTW, the reset button stopped working for me all of a sudden because the system failed to boot off the SD card after a reset. It worked perfectly fine just days ago, with the same SD cards and the same board. Anyway, updating the SPL to v2017.05 fixed it for me, and I have therefore pushed a new SPL binary to the allwinner-bare-metal repository. There won't be a nightly build until I commit some change to the basicengine-firmware repo, though.]

Dmian

uli Before trying build 167 I saw there was a newer one (build 184). I thought that I could try that first, since I was using build 182: everything worked as expected! 😮
So I think the problem was with build 182. Just in case, I also tried flashing build 167: worked. Re-flashed 182: didn't work. So the problem must be there.
Now everything works, and I'm really happy! 😊
Thanks!

Dmian

Btw, I wanted to try to replicate the famous 1 line maze program of the C64, and here you have it:

10 FONT 2:DO:PRINT CHR$(141.5+RND(1));:WAIT 10:LOOP

Turns out it runs so fast without a wait that you can barely see a thing! 😆
But basically, it works as you remembered from the C64, only the character code is changed, and the FONT 2 is selected.

Dmian

Did I put the one for the lines? Well, the family wouldn't be complete without it, right? 😆

10 SCREEN 15:CLS
20 x=PSIZE(0):y=PSIZE(1)
30 DO
40 col=INT(RND(1)*255)
50 LINE INT(RND(1)*x),INT(RND(1)*y), INT(RND(1)*x),INT(RND(1)*y), col
60 k=INKEY()
70 LOOP WHILE k=0
80 SCREEN 1:CLS
90 END

And that's it for these simple tests. Now onto something that resembles more a game... 😊

Dmian

I adapted this program from one I saw on the BASIC-256 site:

10 n=1
20 cls
30 r=PSIZE(1)/2-60
40 cx=PSIZE(0)/2:cy=PSIZE(1)/2
50 rm=30
60 do
70 ccolor=rgb(int(rnd(255)), int(rnd(255)), int(rnd(255)))
80 for t = 0 to 6.28 step .002
90 x=r*sin(t)+cx
100 y=r*cos(t)+cy
110 xm=rm*sin(-t*3*n)+x
120 ym=rm*cos(-t*3*n)+y
130 circle xm,ym,1,ccolor,ccolor
140 wait 1
150 next t
160 n=n+1:if n>6 then n=1: CLS
170 loop

It's a simple spirograph.

Dmian

Ok, I need a little help of you, if you can...
I'm trying to move a sprite in the screen, but I must be doing something wrong or forgetting something really silly, because I can't, for the love of me, make the sprite move.
I have this code:

CLS: SCREEN 11 '320x256

posX = 151
posY = 122

LOAD PCX "char.pcx" AS SPRITE 0 TO posX,posY KEY rgb(255,255,255)
SPRITE 0 ON

DO
  p=PAD(0)
  IF p AND UP AND posY > 0 THEN
    posY = posY - 1
  ENDIF
  IF p AND DOWN AND posY < PSIZE(1) THEN
    posY = posY + 1
  ENDIF
  IF p AND LEFT AND posX > 0 THEN
    posX = posX - 1
  ENDIF
  IF p AND RIGHT AND posX < PSIZE(0) THEN
    posX = posX + 1
  ENDIF
  MOVE SPRITE 0 TO posX,poxY
  f = FRAME()
  VSYNC f+1
LOOP

And this little character: http://damianvila.com/basicengine/char.pcx
I'm using build 427, just in case.
Can you tell me what I'm missing?
Thanks a lot.

SanguineBrah

Dmian AND in basic is a bitwise operation, so: "IF p (being 8 if pressing up) AND UP (which is a synonym for 8)" should return 8 if they match. The "<" operator will return either -1 or 0, but if you AND that with the 8, you would get 0. You need to convert the first part to a boolean to be able to AND them in the way you want, so something like "IF p AND UP <> 0..."

Dmian

SanguineBrah Thanks! I guess I’m too used to Javascript, that has very peculiar ways of using logic.
Edit: Just to be clear, I was expecting the first part to be TRUE, hence evaluate with the second part, in classical short-circuit evaluation. 😝

Dmian

Ok, I just checked, and there must be something else happening here...
I did a couple tests, but the logic seems to work. I even checked if the position of the sprite was being modified (it is).
I used this code:

CLS: SCREEN 11 '320x256

positionX = PSIZE(0) / 2
positionY = PSIZE(1) / 2

LOAD PCX "char.pcx" AS SPRITE 0 TO positionX,positionY KEY rgb(255,255,255)
SPRITE 0 ON

DO
  p=PAD(0)
  IF p AND UP AND positionY > 0 THEN
    positionY = positionY - 1
  ENDIF
  IF p AND DOWN AND positionY < PSIZE(1) THEN
    positionY = positionY + 1
  ENDIF
  IF p AND LEFT AND positionX > 0 THEN
    positionX = positionX - 1
  ENDIF
  IF p AND RIGHT AND positionX < PSIZE(0) THEN
    positionX = positionX + 1
  ENDIF
  MOVE SPRITE 0 TO positionX,positionY
  f = FRAME()
  VSYNC f+1
  chx = SPRX(0)
  chy = SPRY(0)
  GPRINT 10,10,STR$(chx);":";STR$(chy)
LOOP

And the GPRINT statement shows that the position of the sprite is being recalculated, but I see the sprite always at the same position. Weird. I'll try with another build, just in case there's a bug or something.

SanguineBrah

Dmian
In the reference manual for MOVE SPRITE: "sprites that are placed completely outside the dimensions of the current screen mode will not be drawn"
I wonder if this is not taking account of the differences in H3's screen modes?

Dmian

SanguineBrah I really have no idea what's going on. I tried loading the Shoot-em-up demo, to compare, but it's not loading with this build. If I use SCREEN 5, like in that program, the system crashes.
Maybe there's something wrong happening with sprites and screen resolutions?
I'll keep investigating, and if I find something conclusive I'll let you know, and see if a bug needs to be reported (maybe Ulrich already knows about this).
Cheers.