CPC Basic 3

[Trebmint]

I think the trap with regard to negative numbers is not being able to assign a variable a negative number, so something like "dir%=-1" is illegal under CPC BASIC 3, which would prevent you from doing something like x%=x%+dir% if dir% was negative. Fortunately there is more than one way to do something in BASIC and I guess that would be another example where it can be substituted with something like "x%=x%-1".

I think the main issue with negative values (looking at the output) isnt negative values, but when a negative & positive are compared. The assembly show all the logical comparisions are done with SBC HL,BC, which will require the sign to be the same for correct results

[AMSDOS]

I think the main issue with negative values (looking at the output) isnt negative values, but when a negative & positive are compared. The assembly show all the logical comparisions are done with SBC HL,BC, which will require the sign to be the same for correct results

Unfortunately I'm unsure which program I was trying to interpret for CPC BASIC 3, and now I'm unsure where I encountered trouble with negative numbers. 

That's a general huge problem of BASIC compilers. They still use all the firmware and so the gain of speed is not so much. The real gain of speed could be IMHO archieved by replacing some of the slowest firmware calls by own routines (f.e. print char etc.).


Could you please post such an assembly listing here as an example? Maybe one of your space and stars program. I'm really curious how it would look like in the assembler output. 

I've attached a Disk Image with 3 Versions of the text version of Starscrl:


STARSCRL.BIN - CPC BASIC 3 version
STARASM.BAS - Assembly version
STARPAS.BIN - Hisoft Pascal version


The Assembly & compiled Pascal versions I made earlier seem to be operating on par with each other, but in those versions I'm using SCR HW ROLL to roll the Screen which might be why I'm getting a different result with CPC BASIC 3 version.


I've gone back to the original 10-Liner program (October 1990 ACU) and compiled that to produce the CPC BASIC 3 Version. The only change I had to make was the PLOT statement in Line 60 where:

Code Select Expand

PLOT RND*638,398,INT(RND*3)+1


becomes:

Code Select Expand

PLOT RND MOD 638,398,RND MOD 3+1


the program appears to be running a little bit faster than my Assembly/Pascal program and I tried variations with the PRINT CHR$(11)CHR$(11)  that is used to Scroll the screen. In the case of the original program it's rolling the screen twice, but when I changed that to roll the screen once, the output was still different, program still appeared faster than my Assembly/Pascal counterpart, all versions of the program show a flickery Spaceship, but in the CPC BASIC 3 version, the colour of the ship seems to be pulsating in colour (which I found annoying). Unsure if this is due to the use of LOCATE 1,1:PRINT CHR$(11)CHR$(11) though things appear to be done in a more timely in the other 2 versions, maybe because I'm using SCR HW ROLL which doesn't rely on me to Position the cursor at the top and perform a Cursor Up, though perhaps SCR HW ROLL is producing a more timely result?

[Trebmint]

Well looking at the output all I can say is CPC Basic 3 is very well done. Quicker or equal too any C compiler on the z80. It would appear the negative values were dropped purely as the neg/pos check made it too slow in the authors eyes especially as most games would use positive values. There's no easy way to define INTs and Signed or Not in Locomotive Basic. ROM calls are always going to make output look like fast Basic programs, shame there's no sprite/graphic stuff in there too as that would make it the obvious dev choice for many coders on the cpc


It does seem to get confused with longer expressions with a few parenthesis... so better stick to short non complex type. Great program though

[AMSDOS]

I found CPC BASIC 3 to be flexible to incorporate RSXes into compiled Binary, from that all I need to do is load the Sprite Driver, Activate that, Load the Sprite. This file demonstrates the use of Sean McManus' Easi-Sprite Driver from a Compiled CPC BASIC 3 program. The result is staggering.

[Morri]

I found CPC BASIC 3 to be flexible to incorporate RSXes into compiled Binary, from that all I need to do is load the Sprite Driver, Activate that, Load the Sprite. This file demonstrates the use of Sean McManus' Easi-Sprite Driver from a Compiled CPC BASIC 3 program. The result is staggering.

Got your Easi-Sprite example and I must say this is interesting. I am going to look hard at CPC BASIC 3 and might see if I come come up with something that incorporates both together. Hmmm, what to do...

[AMSDOS]

Got your Easi-Sprite example and I must say this is interesting. I am going to look hard at CPC BASIC 3 and might see if I come come up with something that incorporates both together. Hmmm, what to do...

So I think to get that example compiled, I used the previous attachment from that thread which uses ESD with the Locomotive BASIC. Most of that program compiles with CPC BASIC 3, apart from having the first lines to Load ESD or the Sprite. I'm not compiling the program to Run it in the Emulator cause obviously that wouldn't work without ESD or the Sprite present, so it gets compiled as a BIN file - or to Disk, I then copied ESD & the Sprite to that Disc & made a BASIC file to load it all together. In this case the CPC BASIC BIN resides at &4000 so can be loaded first, followed by the Sprite & ESD that sit higher in memory.


I'm unsure how the introduction of ESD would impact with the other RSXs CPC BASIC 3 uses, I have a feeling it would make the other RSXs available to CPC BASIC 3 inoperable and crash the system if they depend on KL LOG EXT too. Loading ESD & Activating that would see to that if that's the case.


If that's going to be an issue, it might be worth taking a look at ESD Advanced from the BASIC Idea which uses a series of Calls depending on what you need to do (there's routines for Force, Overlay, XOR Sprite and a fine Grab Routine), CPC BASIC 3 doesn't need to rely on RSXs, simply CALLing a routine like one would from Locomotive BASIC can also be applied here. It might even be interesting to see what CPC BASIC 3 does to ESD Advanced since it comes with a little presentation.

[AMSDOS]

Unsure if this is due to the use of LOCATE 1,1:PRINT CHR$(11)CHR$(11) though things appear to be done in a more timely in the other 2 versions, maybe because I'm using SCR HW ROLL which doesn't rely on me to Position the cursor at the top and perform a Cursor Up, though perhaps SCR HW ROLL is producing a more timely result?

I haven't been able to conclude why this CPC Basic 3 code is faster than my Assembly when it's clearly using more memory than my Assembly source, unfortunately I don't have the latest Assembly Source with me.


Initially I thought that SCR HW ROLL might of had something to do with it, but even after modifying the code to use one SCR HW ROLL, the output appears to be unaffected, along with that annoying little Pulsating Spaceship. 


The only other clue I can see in my earlier Assembly example is I'm using 2 Frames instead of 1 (which the CPC Basic 3 has), which might be what's happening.

[TFM]

It may be connected to the FRAME command. In detail: If it waits until the V-Sync gets reset or not. In your code IIRC you have a FRAME, then you print two chars, then FRAME again. You know what I mean?

[AMSDOS]

It may be connected to the FRAME command. In detail: If it waits until the V-Sync gets reset or not. In your code IIRC you have a FRAME, then you print two chars, then FRAME again. You know what I mean?

Yes it is, so once I remove the second FRAME from my Assembly version the program responds very similar to the CPC BASIC 3 version, so with a second FRAME put in after the PRINTing everything looks more timely.


So the output is very good, I had a look at the program from the code generated from Hisoft Pascal 4T and naturally found was not running quite as fast as the ASM/CPC BASIC 3 versions with one FRAME, though it's safe to say optimizations has some a long way since 1984.


It would be interesting to test out ESD Advanced under this compiler cause I recall the program having a little bit of flicking in it, unsure how Sean would feel about it, he was happy for me to use ESD in my compiled programs, though this is his demonstration program.

[Morri]

It would be interesting to test out ESD Advanced under this compiler cause I recall the program having a little bit of flicking in it, unsure how Sean would feel about it, he was happy for me to use ESD in my compiled programs, though this is his demonstration program.

I managed to get Sean's frog demo program working with CPCBasic in only a few minutes (Hope Sean doesn't mind  ). I had to delete a few lines and alter the rnd commands but it was pretty straight forward and the sprites appeared on screen nicely.
There was an increase in speed to the point where the falling frog was so flickery that you couldn't see him half the time. I added a couple of frame commands (call &bd19) and that helped but still flickery.
I've attached the dsk below but you'll see I butchered the code (deleted the scrolling message etc) but it was only to see if CPCBasic would work with ESD2's call commands (and it was a good chance to play around with CPCBasic). That side of things looks fine.

[AMSDOS]

I managed to get Sean's frog demo program working with CPCBasic in only a few minutes (Hope Sean doesn't mind  ). I had to delete a few lines and alter the rnd commands but it was pretty straight forward and the sprites appeared on screen nicely.
There was an increase in speed to the point where the falling frog was so flickery that you couldn't see him half the time. I added a couple of frame commands (call &bd19) and that helped but still flickery.

I've just dug out the other Frame Flyback I was familiar with:

Code Select Expand


.ff
ld b,&f5

.ffl
in a,(c)
rra
jr nc,ffl



it's supposed to be faster than the old MC Frame Flyback (&BD19) routine, so it might help with the Flicker.


I started making another Bouncing Ball w/ Backdrop with ESD2, but had problems when CPC BASIC 3 was producing a program which crashed, though as I found out "FOR y%=199 TO 0 STEP -8" causes lots of problems when it gets converted into assembly and the author also states this. It wasn't critical to start from the top and work down, so changed it the other way "FOR y%=8 TO 200 STEP 8" to get a satisfactory result. Initially I thought the negative number in a variable might of been causing problems and wasn't sure how else to do it, so made a moving ball that you move with the Cursor Keys:

Code Select Expand

10 MODE 0:INK 3,15:INK 7,25:INK 8,1:INK 9,19:INK 11,4
20 FOR y%=8 TO 200 STEP 8
30 FOR x%=0 TO 152 STEP 8
40 CALL &9C40,&4500,x%,y%
50 NEXT x%:NEXT y%
60 x%=100:y%=100:oldx%=x%:oldy%=y%
70 GOSUB 170:GOSUB 200
80 WHILE INKEY(18)=-1:oldx%=x%:oldy%=y%
90 IF (INKEY(0)<>-1) AND (Y%<>198) THEN oldy%=y%:Y%=Y%+1:p%=1
100 IF (INKEY(1)<>-1) AND (X%<>144) THEN oldx%=x%:X%=X%+1:p%=1
110 IF (INKEY(2)<>-1) AND (Y%<>16) THEN oldy%=y%:Y%=Y%-1:p%=1
120 IF (INKEY(8)<>-1) AND (X%<>1) THEN oldx%=x%:X%=X%-1:p%=1
130 IF p%=1 THEN GOSUB 250:GOSUB 170:GOSUB 200
140 p%=0
150 WEND:END
160 ' Save Screen
170 CALL &9CE4,&7000,x%,y%,8,16
180 RETURN
190 ' Print Ball
200 CALL &BD19
210 CALL &9C75,&4522,x%,y%
220 CALL &BD19
230 RETURN
240 ' Restore Screen
250 CALL &BD19
260 CALL &9C40,&7000,oldx%,oldy%
270 CALL &BD19
280 RETURN



Of course when I got the routine close to correct, I had no Frame Flybacks and the ball was Flickering in some places, so I added more and got more Flicking. So if I have some time tomorrow, I might get that other Frame Flyback routine onto it.


But I think there's always going to be that to deal with when writing directly to the active screen. Most people will say it's better to write to the second screen (or have 128k) to quickly switch screens.

I've attached the dsk below but you'll see I butchered the code (deleted the scrolling message etc) but it was only to see if CPCBasic would work with ESD2's call commands (and it was a good chance to play around with CPCBasic). That side of things looks fine.

Yes I found CPC BASIC will pass parameters quite well when dealing with CALL commands working out how many parameters there are, obviously this cannot be Run in an Emulator due to using external routines to get the program to perform and I was having some problems when saving it out as a BIN file, unsure why this was happening but when I loaded the file into an Emulator, there was nothing there. So it's just easier to save as a Disk Image. And once the OUTPUT.BIN file is with the sprite data & Sprite Driver a Loader program can be used to load it all it with the OUTPUT.BIN file last.


The only other headache I had was with the Sprite Definer, I was getting some sort of Overflow error and I was following the Instructions. I made a Background (Sprite 0) called it BCKGND, but insisted it should be called BLANK which was 8x8 in size, Sprite 1 that I called BALL A was 16x16, twice I nearly lost both Sprites and was playing funny buggers when I wanted to Save the Sprite Bank, eventually I managed to get them saved. But to use ESD2 Advanced the Sprite Definer is the most direct way of making Sprites for it cause it saves the information regarding the size of the Sprite which is at the Address the routine points at.
Otherwise it's off to ESD and using the GRAB tool to capture the Sprite that's been Drawn to Screen.

[AMSDOS]

I've just dug out the other Frame Flyback I was familiar with:

Code Select Expand


.ff
ld b,&f5

.ffl
in a,(c)
rra
jr nc,ffl



it's supposed to be faster than the old MC Frame Flyback (&BD19) routine, so it might help with the Flicker.

I modified my routine to use this Frame Flyback routine and the result I got was a Ball that moved smoothly the first few top lines and then it disappears the further down the screen I go. I've only called the routine once (Line 200) in my Print Ball. When I let go of the key though the Ball Displays itself. I remember one of Kevin's routines did that, though I think you got more of the screen with his, mine seems to be the first few lines at the top of the screen and then it disappears if you hold the key down.


Anyone know what I'm doing wrong?


Should I put a loop around that Frame Flyback routine?


Or should I just have more Frame Flyback Calls where those &BD19 were?


I can probably test this and see what I come up with.

[arnoldemu]

The monitor beam is catching up with your deleting and then drawing code.


So as you move down, the monitor displayed the erased version before you had time to draw it.

There are ways to avoid it but the drawing becomes more complicated. delete and draw a line at a time.

[AMSDOS]

The monitor beam is catching up with your deleting and then drawing code.

Hmmm.

So as you move down, the monitor displayed the erased version before you had time to draw it.

Yes.

There are ways to avoid it but the drawing becomes more complicated. delete and draw a line at a time.

I've put 2 Frame Flybacks routines (line 200) in my Print Ball routine, which gave me something that looks similar to 2 x &BD19s.


A FOR loop in line 130 before GOSUB 200 had little effect, partly because I was limited (1 to 255) and M/C Loops are so much faster than a BASIC one.


What I need is more Key Control, I tried this with SPEED KEY, but INKEY() doesn't appear to be governed by this, so I might have to go back to INKEY$() to control the Input more.

[Trebmint]

You really need a flipped screen display. Always one of the main issues with sprites was they could just disappear or at best flicker as its hard to determine which side of the raster they are.
Using two screens you can work on the back screen and then wait until the Flyback and flip the finished screen into view. This has the advantage of basically not having to worry about ordering of screen redraw to minimize flicker, and therefore is the fastest and best looking. The obvious disadvantage is that it requires two screens.

[AMSDOS]

You really need a flipped screen display. Always one of the main issues with sprites was they could just disappear or at best flicker as its hard to determine which side of the raster they are.
Using two screens you can work on the back screen and then wait until the Flyback and flip the finished screen into view. This has the advantage of basically not having to worry about ordering of screen redraw to minimize flicker, and therefore is the fastest and best looking. The obvious disadvantage is that it requires two screens.

I'll have a look into this, though I imagine the Sprite Routine will need adjusting to accommodate writing to both screens.


At the moment I've got a fairly good result by using INKEY$ and am controlling the Speed of the Key with Speed Key, which draws a nice Smooth image of my Ball in 3/4 of the screen. But maybe it's just a fluke! 

[AMSDOS]

I found this BASIC routine on Rosetta Code (compatible with Locomotive BASIC) to calculate using the Bresenham algorithm which works nicely and was able to use the Fast Plot for Mode 1 as well, but when I ran it though Locomotive BASIC it didn't seem any faster (probably due to the calculations involved probably), but when I tried to get this going in CPC BASIC 3, no good. I changed ABS function into it's RSX equivalent and also dropped the INT in Line 1550 since Integers are the default, but still no luck, probably the negative numbers causing problems, so I changed those to 65535 as suggested in the Manual, but still had no Luck.  I'm guessing it maybe -DY or -DX, usually in Locomotive BASIC one can use NOT instead of "-", not am not sure. Any ideas?

Code Select Expand



1500 REM === Draw a line. Ported from C version
1510 REM Inputs are X1, Y1, X2, Y2: Destroys value of X1, Y1
1520 DX = ABS(X2 - X1):SX = -1:IF X1 < X2 THEN SX = 1
1530 DY = ABS(Y2 - Y1):SY = -1:IF Y1 < Y2 THEN SY = 1
1540 ER = -DY:IF DX > DY THEN ER = DX
1550 ER = INT(ER / 2)
1560 PLOT X1,Y1:REM This command may differ depending on BASIC dialect
1570 IF X1 = X2 AND Y1 = Y2 THEN RETURN
1580 E2 = ER
1590 IF E2 > -DX THEN ER = ER - DY:X1 = X1 + SX
1600 IF E2 < DY THEN ER = ER + DX:Y1 = Y1 + SY
1610 GOTO 1560


[arnoldemu]

DX,DY etc are not integers, add % to make them integers and it'll go faster.

[AMSDOS]

DX,DY etc are not integers, add % to make them integers and it'll go faster.

Sorry I should of explained that I used DEFINT a-z and just followed the Inputs for the routine with GOSUB 1520, to draw some lines, but I was comparing the use of that PLOT with @Executioner (s) Fast Plot for Mode 1, could see some improvement, but not quicker than GRA LINE ABSOLUTE, but must be the Algorithm causing the delay. I wanted to see how CPC BASIC 3 would transform it, though am having trouble translating for it. Negative variables or digits I think.

[ervin]

Prepare to be shocked by the speed improvement!


Almost a year ago, I managed to get a general bresenham routine working in ccz80.
I've converted that ccz80 code to CPC Basic 3, and I present to you the results.

I don't know if it's the same as your algorithm, but I thought you might find it interesting regardless.
Bresenham's starts at line 1000.

Code Select Expand

10 mode 1
20 border 2

30 fx1=1:fy1=199
40 fx2=0:fy2=0

50 for i=1 to 20
60 gosub 1000
70 fy1=fy1-10
80 fx2=fx2+16
90 next i

100 fx1=0:fy1=0
110 fx2=319:fy2=0

120 for i=1 to 20
130 gosub 1000
140 fx1=fx1+16
150 fy2=fy2+10
160 next i

170 fx1=319:fy1=0
180 fx2=319:fy2=199

190 for i=1 to 20
200 gosub 1000
210 fy1=fy1+10
220 fx2=fx2-16
230 next i

240 fx1=319:fy1=199
250 fx2=0:fy2=199

260 for i=1 to 20
270 gosub 1000
280 fx1=fx1-16
290 fy2=fy2-10
300 next i

310 end

1000 x=fx1
1010 y=fy1

1020 if fx2>fx1 then dx=fx2-fx1 else dx=fx1-fx2
1030 if fy2>fy1 then dy=fy2-fy1 else dy=fy1-fy2

1040 if fx1>fx2 then s1=-1 else if fx2>fx1 then s1=1 else s1=0
1050 if fy1>fy2 then s2=-1 else if fy2>fy1 then s2=1 else s2=0

1060 if dy>dx then gosub 2000 else swp=0
1070 e=dy+dy-dx

1100 for j=1 to dx
1110 plot x,y

1120 while e<32768:rem while e>=0
1130 if swp=1 then x=x+s1 else y=y+s2
1140 e=e-(dx+dx)
1150 wend

1160 if swp=1 then y=y+s2 else x=x+s1
1170 e=e+(dy+dy)

1180 next

1190 return

2000 t=dx:dx=dy:dy=t:swp=1
2010 return


For anyone interested, here is the ccz80 version.

Code Select Expand

include "cpc6128.ccz80";

byte swap;

word fx1,fy1;
word fx2,fy2;
word x,y;
word dx,dy;
word s1,s2;
word t;
word e;

mode(1);
border(2,2);

fx1=0;fy1=199;
fx2=0;fy2=0;

repeat(20)
{
    gosub BRES_LINE;
    fy1-=10;
    fx2+=16;
}

fx1=0;fy1=0;
fx2=319;fy2=0;

repeat(20)
{
    gosub BRES_LINE;
    fx1+=16;
    fy2+=10;
}

fx1=319;fy1=0;
fx2=319;fy2=199;

repeat(20)
{
    gosub BRES_LINE;
    fy1+=10;
    fx2-=16;
}

fx1=319;fy1=199;
fx2=0;fy2=199;

repeat(20)
{
    gosub BRES_LINE;
    fx1-=16;
    fy2-=10;
}

return;

BRES_LINE:

x=fx1;
y=fy1;

if (fx2>fx1)
    dx=fx2-fx1;
else
    dx=fx1-fx2;

if (fy2>fy1)
    dy=fy2-fy1;
else
    dy=fy1-fy2;

if (fx1>fx2)
    s1=-1;
else if (fx2>fx1)
    s1=1;
else
    s1=0;

if (fy1>fy2)
    s2=-1;
else if (fy2>fy1)
    s2=1;
else
    s2=0;

if (dy>dx)
{
    t=dx;
    dx=dy;
    dy=t;
    swap=1;
}
else
    swap=0;

e=dy+dy-dx;

repeat(dx)
{
    plot(x,y);

    // while e>=0
    while (e<32768)
    {
        if (swap==1)
            x+=s1;
        else
            y+=s2;

        e-=dx+dx;
    }

    if (swap==1)
        y+=s2;
    else
        x+=s1;

    e+=dy+dy;
}

return;


[Prodatron]

Can you try this?

Code Select Expand



1500 REM === Draw a line. Ported from C version
1510 REM Inputs are X1, Y1, X2, Y2: Destroys value of X1, Y1

1511 X1=X1+32768:X2=X2+32768:Y1=Y1+32768:Y2=Y2+32768

1520 DX = ABS(X2 - X1):SX = -1:IF X1 < X2 THEN SX = 1
1530 DY = ABS(Y2 - Y1):SY = -1:IF Y1 < Y2 THEN SY = 1
1540 ER = -DY:IF DX+32768 > DY+32768 THEN ER = DX
1550 ER = INT(ER / 2)
1560 PLOT X1-32768,Y1-32768:REM This command may differ depending on BASIC dialect
1570 IF X1 = X2 AND Y1 = Y2 THEN RETURN
1580 E2 = ER
1590 IF E2+32768 > -DX+32768 THEN ER = ER - DY:X1 = X1 + SX
1600 IF E2+32768 < DY+32768 THEN ER = ER + DX:Y1 = Y1 + SY
1610 GOTO 1560


Didn't test it, but it could solve the problem when comparing negative with positive integers?

[AMSDOS]

Can you try this?

Code Select Expand



1500 REM === Draw a line. Ported from C version
1510 REM Inputs are X1, Y1, X2, Y2: Destroys value of X1, Y1

1511 X1=X1+32768:X2=X2+32768:Y1=Y1+32768:Y2=Y2+32768

1520 DX = ABS(X2 - X1):SX = -1:IF X1 < X2 THEN SX = 1
1530 DY = ABS(Y2 - Y1):SY = -1:IF Y1 < Y2 THEN SY = 1
1540 ER = -DY:IF DX+32768 > DY+32768 THEN ER = DX
1550 ER = INT(ER / 2)
1560 PLOT X1-32768,Y1-32768:REM This command may differ depending on BASIC dialect
1570 IF X1 = X2 AND Y1 = Y2 THEN RETURN
1580 E2 = ER
1590 IF E2+32768 > -DX+32768 THEN ER = ER - DY:X1 = X1 + SX
1600 IF E2+32768 < DY+32768 THEN ER = ER + DX:Y1 = Y1 + SY
1610 GOTO 1560


Didn't test it, but it could solve the problem when comparing negative with positive integers?

Unfortunately that gave me something which started drawing a Line one way & then back onto itself (what what it appeared). I altered the -1 that SX & SY have in Lines 1520 & 1530 which almost gave me the result I was after, but froze. I tried this in Locomotive BASIC prior to that which gave me an overflow error, this appeared to be the same.

Code Select Expand



1500 REM === Draw a line. Ported from C version
1510 REM Inputs are X1, Y1, X2, Y2: Destroys value of X1, Y1

1511 X1=X1+32768:X2=X2+32768:Y1=Y1+32768:Y2=Y2+32768

1520 DX = ABS(X2 - X1):SX = 32768:IF X1 < X2 THEN SX = 1
1530 DY = ABS(Y2 - Y1):SY = 32768:IF Y1 < Y2 THEN SY = 1
1540 ER = -DY:IF DX+32768 > DY+32768 THEN ER = DX
1550 ER = ER / 2
1560 PLOT X1-32768,Y1-32768:REM This command may differ depending on BASIC dialect
1570 IF X1 = X2 AND Y1 = Y2 THEN RETURN
1580 E2 = ER
1590 IF E2+32768 > -DX+32768 THEN ER = ER - DY:X1 = X1 + SX
1600 IF E2+32768 < DY+32768 THEN ER = ER + DX:Y1 = Y1 + SY
1610 GOTO 1560




But thanks trying anyway.


@ervin I'll eventually get around to looking at your routine, if it's speedy with an ordinary PLOT, the fast plot will probably send it off it's head.

[rk last]

Im a newbie to CPCBASIC and have experienced a problem whilst trying to run circle.bas.

After typing run, the CPCE emulator opens with call &4000 displayed.  Pressing RETURN runs the program and ends with a syntax error?

[AMSDOS]

So is the program returning to basic or just producing some weird syntax error loop?

If it's looping then perhaps it needs an end command at the exit point of the program to tell cpcbasic to return to basic?

[ervin]

Im a newbie to CPCBASIC and have experienced a problem whilst trying to run circle.bas.

After typing run, the CPCE emulator opens with call &4000 displayed.  Pressing RETURN runs the program and ends with a syntax error?

My apologies if this is a silly question, but are you compiling the program before RUNning it?