| Author |
Message |
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
 Posted: 11 Jun 2008 07:17:18 am Post subject: |
|
|
I've been very busy with work recently, though I have nearly all of the keywords documented and have made numerous changes behind the scenes to make the host interface more robust. Hopefully I can get a limited implementation of BBC BASIC out for testing soon. :)
I have implemented the COLOUR statement to change the text foreground and background colours.
The above screenshot also demonstrates the useful LIST IF statement, which can be used to search for keywords or strings in program lines when LISTing.
Another feature I've added is a copy of the BBC Micro's copy key editing.
By pressing a cursor key when entering a line of code, the cursor splits into two - a read cursor and a write cursor. The write cursor remains on the end of the line you were editing (a solid block), but the read cursor can be moved to any location on the screen. Pressing the COPY key (in this case, I've commandeered the XTθn key for this purpose) reads the character that is under the read cursor and copies it to the write cursor, then increments both. This can be used to edit or duplicate existing lines.
I've also implemented ADVAL, which lets you poll a mouse connected to your calculator. ADVAL(0) returns the state of the buttons, ADVAL(1) returns the distance moved in the X-axis, ADVAL(2) returns the distance moved in the Y-axis and ADVAL(3) returns the amount the scrollwheel has been rolled.
If you wish to drop to a lower level, I've also started implementing data transfer via the link port as device files. For example, here's a program that flashes keyboard LEDs using "AT.DEV" for AT protocol communication.
Code:
10 keyb%=OPENOUT"AT.DEV"
20 DATA 2,4,1,4,-1 : REM LED flash pattern (-1 terminated).
30 REPEAT
40 READ l%
50 REPEAT
60 PROC_setled(l%)
70 PROC_pause(30)
80 READ l%
90 UNTIL l%=-1
100 RESTORE
110 UNTIL FALSE
120 END
130 :
140 DEF PROC_flushin
150 REPEAT
160 IF EXT#keyb% d%=BGET#keyb%
170 UNTIL NOT EXT#keyb%
180 ENDPROC
190 :
200 DEF PROC_setled(l%)
210 BPUT#keyb%,&ED
220 PROC_flushin
230 BPUT#keyb%,l%
240 PROC_flushin
250 ENDPROC
260 :
270 DEF PROC_pause(t%)
280 start%=TIME
290 REPEAT UNTIL TIME >= start%+t%
300 ENDPROC
Obviously this would be most useful with TILP.DEV to transfer data using TI's link protocol for multiplayer games, but as I don't have two calculators for testing plugging a keyboard in to the calculator was a bit easier. :)
As there may or may not be data waiting for us from the device, incoming data is buffered and you can check how much stuff is in the buffer by using EXT# (which usually returns the size of the file). In this way, if EXT# returns a positive value, that means there's stuff in the buffer and you can safely call BGET# to retrieve it.
In the above code, PROC_flushin is used to ignore any input from the keyboard. It checks the length of the buffer and tries to read data from it until it's empty.
PROC_setled(l%) sets the keyboard LED state, which is done by sending the control byte &ED followed by the LED state value. After each value is sent to the keyboard, PROC_flushin is called to ignore any response the keyboard tries to send.
PROC_pause(t%) is just a little procedure to pause for a particular number of centiseconds, using the TIME pseudo-variable.
Another addition is *REFRESH; a useful one copied from BBC BASIC for Windows. Normally, drawing commands output directly to the LCD; by stating *REFRESH OFF only the graph buffer is updated. You can then copy the data to the screen by calling *REFRESH, or *REFRESH ON to restore the original behaviour.
As far as graphics go; I may just release an initial version that only implements MOVE and DRAW; MOVE x,y sets the graphics cursor position, and DRAW x,y draws a line between the cursor and the specified position.
Which brings me on to my next question; how would you like graphics to be implemented? PLOT is the command used to draw graphics; I assume that most would like to see that expanded to at least support 8x8 sprites. In which case, which coordinate system would you like to use? (0,0) at the top-left with X pointing right and Y pointing down is usual in the assembly world, but BBC BASIC usually puts (0,0) at the bottom-left hand corner and points Y up. TI-BASIC appears to use a mixture of the two, depending on the command you use, which I'd rather avoid if possible. (I'd personally prefer (0,0) to be in the top-left as this would make all display routines consistent, even if it goes against what implementations of BBC BASIC usually do). |
|
| Back to top |
|
|
Ed H
Member
Joined: 30 Nov 2007
Posts: 138
|
| Posted: 11 Jun 2008 01:29:59 pm Post subject: |
|
|
I would also like (0,0) at the top-left. No particular reason. It just makes more sense there.
By the way, how does typing work? I notice that most of the language can be typed in as single characters. Do we still need to do [Alpha] or Alpha-lock to type in a bunch of letters? |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 11 Jun 2008 03:13:16 pm Post subject: |
|
|
Ed H wrote: By the way, how does typing work? I notice that most of the language can be typed in as single characters. Do we still need to do [Alpha] or Alpha-lock to type in a bunch of letters? BBC BASIC inputs regular ASCII text and tokenises it itself. Several commands are abbreviated, for example P. is equivalent to PRINT (so, if you type 10 P.<Enter> then LIST<Enter> it would display 10 PRINT -- in fact, LIST can be abbreviated to L.).
As most of the required typing deals with UPPERCASE text, pressing a key on its own will type the letter associated with it (for example, pressing * types an 'R'). 2nd works like shift, so 2nd+* types an 'r'. To type symbols, you'd press Alpha, so Alpha+* types an '*'. Finally, some keys have a yellow symbol on them, so 2nd+Alpha+* types a '['.
In all of the above cases, 2nd and Alpha are handled as modifiers rather than dead keys -- that is, you have to hold them down when pressing the actual key you wish to type.
In deference to tradition, 2nd+0 brings up a menu like the CATALOG on the regular TI-OS, except it's populated with BBC BASIC statements.
I've tried to keep the key mapping sensible (Alpha+S='$') though some of them might not make too much sense (2nd+Alpha+(-) ='~'), and for this reason all the symbolic characters are listed at the bottom of the 2nd+0 menu, as they are under the TI-OS. |
|
| Back to top |
|
|
TheStorm
Calc Guru
Joined: 17 Apr 2007
Posts: 1233
|
| Posted: 11 Jun 2008 09:08:55 pm Post subject: |
|
|
| Wow nice job benryves you have really thought this out, and Yeah I agree with haveing (0,0) be at the top left to keep it more native to the platform. |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 12 Jun 2008 05:17:16 pm Post subject: |
|
|
Regarding the speed issue; no doubt somebody is going to write a 5-line TI-BASIC program that runs at three times the speed and textures the cube at the same time, but here's a very simple 3D demo.
 
On the left is the program running on an 83+ SE at 15MHz, on the right on the regular 83+ at 6MHz. If you really wanted to do 3D in BBC BASIC you could probably get away with writing some of the more expensive operations -- such as transforming/projecting vertices in batches -- in assembly, but that would sort of go against the whole point of trying to write a program to test the speed of BASIC. :)
Here's the rather naïve code:
Code:
10 *REFRESH OFF
20 DIM p%(15)
30 fps%=0
40 lfps%=0
50 fpst%=TIME+100
60 REPEAT
70 rX=TIME/300
80 rY=TIME/400
90 SrX=SIN(rX)
100 CrX=COS(rX)
110 SrY=SIN(rY)
120 CrY=COS(rY)
130 pt%=0
140 FOR x=-1TO1STEP2
150 FOR y=-1TO1STEP2
160 FOR z=-1TO1STEP2
170 tX=y*CrX-x*SrX
180 tY=-x*CrX*SrY-y*SrX*SrY-z*CrY
190 tZ=3-x*CrX*CrY-y*SrX*CrY+z*SrY
200 p%(pt%)=tX*40/tZ+48
210 pt%=pt%+1
220 p%(pt%)=tY*40/tZ+32
230 pt%=pt%+1
240 NEXT
250 NEXT
260 NEXT
270 CLG
280 PRINTTAB(10,0)lfps%" FPS"
290 MOVE p%(0),p%(1)
300 DRAW p%(4),p%(5)
310 DRAW p%(12),p%(13)
320 DRAW p%(8),p%(9)
330 DRAW p%(0),p%(1)
340 DRAW p%(2),p%(3)
350 DRAW p%(6),p%(7)
360 DRAW p%(14),p%(15)
370 DRAW p%(10),p%(11)
380 DRAW p%(2),p%(3)
390 MOVE p%(4),p%(5)
400 DRAW p%(6),p%(7)
410 MOVE p%(12),p%(13)
420 DRAW p%(14),p%(15)
430 MOVE p%(8),p%(9)
440 DRAW p%(10),p%(11)
450 *REFRESH
460 fps%=fps%+1
470 IF TIME>fpst% THEN lfps%=fps%:fps%=0:fpst%=TIME+100
480 UNTIL INKEY(0)<>-1
490 *REFRESH ON
500 END
|
|
| Back to top |
|
|
elfprince13
Retired
Super Elite (Last Title)
Joined: 11 Apr 2005
Posts: 3500
|
| Posted: 12 Jun 2008 10:05:56 pm Post subject: |
|
|
| wow, that looks great! |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 23 Jun 2008 07:45:12 pm Post subject: |
|
|
qarnos - author of the superb Aether 3D engine - has been lending a hand with the graphics API and contributed a large amount of very useful code.
First up is fast 16-bit line clipping code that lets lines lie partially (or completely) off the screen. The graphics viewport can be set with VDU 24, demonstrated in the following screenshot (showing a graphics window that can be cleared and drawn to independently of the text area).
He has also written some ellipse plotting and filling code which can be used with the PLOT keyword. I've also added support for different bit operations when plotting - either plot (write the specified colour directly), bitwise OR/AND/EOR or invert.
   
It's getting there, slowly but surely. I now have some free time in which I can work on this project, so progress will hopefully speed up a bit now!  (I know it's a bit rude to keep posting screenshots without any binaries, sorry). All screenshots above are running at 15MHz.
What graphics operations would you find useful? |
|
| Back to top |
|
|
magicdanw
pcGuru()
Calc Guru
Joined: 14 Feb 2007
Posts: 1110
|
| Posted: 23 Jun 2008 08:24:18 pm Post subject: |
|
|
| Wow! Nice, fast graphics, especially considering it's not native assembly code! Curious though, since many people have only 83+, how slow are the graphics at 9MHz? |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 23 Jun 2008 08:37:46 pm Post subject: |
|
|
magicdanw wrote: how slow are the graphics at 9MHz? At 6MHz, it's a little below half speed (as you'd imagine!) Here are the random ellipse, cube and "flower" programs running on a regular 83+:
Not blazingly fast, but holding up pretty well.
Last edited by Guest on 23 Jun 2008 08:38:21 pm; edited 1 time in total |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 06 Nov 2008 10:27:17 am Post subject: |
|
|
It's been a while, I know, but progress on BBC BASIC is still being made. The thread on MaxCoderz has a new URL.
Some new features include a real-time clock via the TIME$ pseudo-variable:
 
The date and time features use the hardware clock on the TI-84+ and an inaccurate (but compatible) software clock on the TI-83+.
There are also PLOT commands for drawing sprites:
 
One other graphics feature I have yet to integrate into BBC BASIC (but have written the Z80 code for) is flood-filling.
  
It's a pretty fast implementation (and supports clipping to the viewport, hence the first screenshot doesn't fill the entire screen, even though it "leaks"). The first and second images are slower than they would be in practice as they repaint the screen to show the way the flood fill works. The flood-filler supports patterns too.
All the above examples are of trivial programs, so I've also started throwing together a Lights Out game as a more practical example.
This was useful as it reminded me that there was no way to poll keys directly, only ways to read characters (and the cursor keys don't produce characters, so couldn't be polled). Of course, BBC BASIC has direct access to hardware ports, but I want to avoid that where possible for more cross-platform methods. Adding proper INKEY support (negative arguments) resolved that issue.
Source code for the analogue clock and Lights Out game are on my website to give you an idea of how BBC BASIC could be used.
I'm working hard on the documentation, too, in CHM form. It's based on the BBCBASIC(86) documentation.
Hopefully a beta is just around the corner! |
|
| Back to top |
|
|
SonicBoom95
Member
Joined: 31 Jan 2008
Posts: 237
|
| Posted: 06 Nov 2008 04:41:19 pm Post subject: |
|
|
| Oh, wow. I may never touch TI-BASIC again...provided that these programs can be given to other users without BBC BASIC. Is that true? |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 06 Nov 2008 05:49:39 pm Post subject: |
|
|
Amazing.
I am excited to see that off. With that BASIC our dreams for a alternative to TI-BASIC is true.
Don't forget to use TI-84+ extra RAM pages  As long it is released...
And my ideia to make a attempt of useful and pioneer to TI-83 is completely destroid in pieces.  |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 06 Nov 2008 06:37:07 pm Post subject: |
|
|
SonicBoom95 wrote: Oh, wow. I may never touch TI-BASIC again...provided that these programs can be given to other users without BBC BASIC. Is that true? BBC BASIC programs are not compiled, they are interpreted, so you will need to have the "BBCBasic" Flash application installed to run them. BBC BASIC provides a complete (command-line driven) programming environment on the calculator itself, though I have knocked together some tools that let you edit BBC BASIC programs on a PC before transferring to the calculator. It would not be very practical to write standalone BBC BASIC programs, as the interpreter is 12KB on its own!
Galandros wrote: Don't forget to use TI-84+ extra RAM pages As long it is released...
Quote: And my ideia to make a attempt of useful and pioneer to TI-83 is completely destroid in pieces. |
|
| Back to top |
|
|
DigiTan
Unregistered HyperCam 2
Super Elite (Last Title)
Joined: 10 Nov 2003
Posts: 4468
|
| Posted: 06 Nov 2008 07:49:05 pm Post subject: |
|
|
Holy!... BASIC really got taken up a notch!
Bam!  |
|
| Back to top |
|
|
angel14995
Member
Joined: 13 Oct 2007
Posts: 181
|
| Posted: 06 Nov 2008 09:25:57 pm Post subject: |
|
|
I say, this is going to be sweet. I just hope that some people decide to start using it to create better 3D games.
Also, why is Mirage being used? It just seems weird to me if the programs are interpreted by that special application that you would need Mirage. |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 06 Nov 2008 10:13:52 pm Post subject: |
|
|
angel14995 wrote: I say, this is going to be sweet. I just hope that some people decide to start using it to create better 3D games. I wouldn't be so sure that it's capable of creating impressive 3D games on its own - the spinning cube is just eight points, after all - but you can mix assembly code directly into the BASIC program (via the integrated inline assembler) to get significant speed boost. The focus is to have something easy and relatively flexible, not speed.
That's not to say someone can't write a hand-optimised assembly function that takes an array of points and transforms them, rather than doing these expensive operations in BASIC! In a similar vein, one could embed an assembly raycaster routine into their program, but have the game logic (input, game menus, enemy AI) running in BASIC.
Quote: Also, why is Mirage being used? It just seems weird to me if the programs are interpreted by that special application that you would need Mirage. The MirageOS screenshots are from the flood-filling algorithm demo app, which was a regular assembly program. The flood-filling routine has been written (and works, as you can see) but hasn't actually been integrated into BBC BASIC just yet. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 07 Nov 2008 07:24:10 am Post subject: |
|
|
benryves wrote: I do not own a TI-83+SE or TI-84+ so do not know much about the additional RAM page situation. BBC BASIC requires linear memory, and I don't know how happy the TI-OS would be to have these additional RAM pages swapped in. It's something I'm interested in learning about, but for the time being (and probably in the first beta) it will leave the unused RAM pages alone. I also saw Maxcorderz forum. But is going to be just an amazing add in an already stable release.
Maybe you can test that trough other person. I personally can't because I really need the calculator and can't take any risk. Is not the same but is possible with good communication.
benryves wrote: There are plenty of programming language-related projects left to explore.
[post="128540"]<{POST_SNAPBACK}>[/post]
Maybe but I can't support hard competiton for now. That project is just very good.
But my ideia was also a interpreted language somewhat created by me. It remains a good alternative language to asm but compiled. Pugboy project can reveal interesting. C could be good?
....................
Wow add assembly into BBC BASIC?
How a great add.
This BASIC can (almost as you stated) replace completely TI-BASIC in games. But in math, TI-BASIC will survive.
Or am I wrong? (I wish yes...)
Last edited by Guest on 07 Nov 2008 07:39:12 am; edited 1 time in total |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 07 Nov 2008 11:29:58 am Post subject: |
|
|
Galandros wrote: But my ideia was also a interpreted language somewhat created by me. It remains a good alternative language to asm but compiled. Pugboy project can reveal interesting. C could be good? The Z80 doesn't seem too-well suited for C, as the various free Z80 C compilers out there aren't very good. I haven't really explored it very well myself, though.
Quote: Wow add assembly into BBC BASIC?
How a great add. It's useful. Here's an example from the CP/M version of BBC BASIC (Z80), used to sort an array of real numbers.
Quote: This BASIC can (almost as you stated) replace completely TI-BASIC in games. But in math, TI-BASIC will survive.
Or am I wrong? (I wish yes...) The TI-OS built-in programming language has full access to TI-OS features. As the TI-OS is designed specifically with maths in mind it has good maths features. BBC BASIC is an isolated environment, and so can't use the maths features provided by the TI-OS (it still has all the useful BASIC mathematical functions and operators you'd expect). However, unlike the TI-OS, you can define your own functions and procedures, so if you needed a function to calculate the mean of a list (a function that's not built-in) you could always write your own. |
|
| Back to top |
|
|
benryves
Active Member
Joined: 23 Feb 2006
Posts: 564
|
| Posted: 11 Nov 2008 08:59:55 pm Post subject: |
|
|
BBC BASIC now has its own forum on MaxCoderz.
There were questions earlier in the thread concering speed, so here's an interesting speed comparison between BBC BASIC and the native TI-OS programming language. The test is the Sierpinski Triangle program in the guidebook (17-7):-
Code:
:FnOff :ClrDraw
:PlotsOff
:AxesOff
:0→Xmin:1→Xmax
:0→Ymin:1→Ymax
:rand→X:rand→Y
:For(K,1,3000)
:rand→N
:If N≤1/3
:Then
:.5X→X
:.5Y→Y
:End
:If 1/3<N and N≤2/3
:Then
:.5(.5+X)→X
:.5(1+Y)→Y
:End
:If 2/3<N
:Then
:.5(1+X)→X
:.5Y→Y
:End
:Pt-On(X,Y)
:End
Translated into BBC BASIC, it looks like this:-
Code:
10 REM Sierpinski Triangle by Texas Instruments.
20 REM Taken from the TI-83 Plus Guidebook.
30 CLG
40 X=RND(1):Y=RND(1)
50 FOR K=1 TO 3000
60 N=RND(1)
70 IF N<=1/3 THEN X=.5*X : Y=.5*Y
80 IF 1/3<N AND N<=2/3 THEN X=.5*(.5+X) : Y=.5*(1+Y)
90 IF 2/3<N THEN X=.5*(1+X) : Y=.5*Y
100 PLOT 69,X*96,64-Y*64
110 NEXT K
On a regular TI-83+ (6MHz) the TI-OS program takes 7 minutes and 8 seconds to complete. The BBC BASIC program takes 2 minutes and 21 seconds. That's quite a speed difference!
Here it is running on an emulated 83+SE at 15MHz. |
|
| Back to top |
|
|
angel14995
Member
Joined: 13 Oct 2007
Posts: 181
|
| Posted: 11 Nov 2008 09:44:19 pm Post subject: |
|
|
| Amazing.... Now did you redo the book's program and see how fast it could be from someone on here optimizing it? Or is it as optimized as possible, excluding things like ending parentheses? |
|
| Back to top |
|
|
|
Project Ideas/Start New Projects => Your Projects
