AllBASIC Forum
BASIC Developer & Support Resources => Interpreters => Topic started by: John on January 04, 2014, 11:00:19 AM
-
I have been playing with the Windows version of Napoleon Brandy Basic V Interpreter (http://sourceforge.net/projects/napoleonbrandy/?source=directory) under Wine and I have to say that it's very fast for an interpreter. The good news is that the graphics are done using SDL and the author indicated that the library should be compatible with Linux. My thought at this point is to wrap the NBB5 SDL graphics library as an extension module for ScriptBasic and call it bb5.so and use the BBC calling syntax used in NBB5. Here are a few screen shots of NBB5 running on Ubuntu 64 bit under Wine 1.6.
Basic 5 Documentation (http://files.allbasic.info/BBC/basic.txt)
This is 100K iterations in total.
(http://files.allbasic.info/BBC/bb5_sieve.png)
ScriptBasic comparison:
REM Sieve of Eratosthenes Prime Number Program
size = 10000
iterations = 10
FOR c = 1 TO iterations
count = 0
SPLITA STRING(size,"1") BY "" TO flags
FOR i = 0 TO size
IF flags[i] THEN
prime = i + i + 3
k = i + prime
WHILE k <= size
flags[k]= 0
k += prime
WEND
count += 1
END IF
NEXT
UNDEF flags
NEXT
PRINT "There are ",count," primes\n"
jrs@laptop:~/sb/sb22/test$ time scriba bb5sieve.sb
There are 2261 primes
real 0m0.142s
user 0m0.132s
sys 0m0.008s
jrs@laptop:~/sb/sb22/test$
This is rendered in real time by the pixel.
(http://files.allbasic.info/BBC/bb5_mandelbrot.png)
Seems easy to use.
(http://files.allbasic.info/BBC/bb5_graph.png)
-
I found my version of Brandy Basic 5 for Linux and fired it up. I now remember it's a console only interactive BBC BASIC with no graphics extensions. :(
jrs@laptop:~/Brandy/brandy-1.0.19/examples$ ./brandy
Brandy Basic V Interpreter Version 1.0.19 (Linux) 09/10/2005
Starting with 524288 bytes free
Basicvars is at &0x64a5a0, tokenised line is at &0x64a060
Workspace is at &0x7f4631599010, size is &80000, page = &0x7f4631599010, himem = &0x7f4631619010
>
jrs@laptop:~/Brandy/brandy-1.0.19/examples$ ./brandy sieve
10 iterations.
Doing 1
Doing 2
Doing 3
Doing 4
Doing 5
Doing 6
Doing 7
Doing 8
Doing 9
Doing 10
There are 2261 primes
Time taken=0.07 seconds
>list
1REM Sieve of Eratosthenes Prime Number Program
2:
3size%=10000
4iterations%=10
5:
6DIM flags%(size%)
7:
8T=TIME
9PRINT;iterations%;" iterations."
10FOR C%=1 TO iterations%
11PRINT"Doing ";C%
12count%=0
13flags%()=TRUE
14FOR I%=0 TO size%
15IF flags%(I%) THEN
16prime%=I%+I%+3
17K%=I%+prime%
18WHILE K%<=size%
19flags%(K%)=FALSE
20K%+=prime%
21ENDWHILE
22count%+=1
23ENDIF
24NEXT
25NEXT
26PRINT"There are ";count%;" primes"
27PRINT"Time taken=";(TIME-T)/100;" seconds"
28END
>
-
I was able to find a newer version of Brandy for Linux that uses SDL for the graphics part. (like the Windows version but doesn't seem as complete)
Brandy 1.20 w/SDL Ubuntu 64 bit
(http://files.allbasic.info/BBC/bb5_gdemo_u64.png)
-
I made a little more progress updating the Linux version of Brandy BASIC 5 with the latest Windows version that was announced on the BP.org site.
Update: I got the mouse working in Brandy BASIC V. (Ubuntu 64 bit version)
(http://files.allbasic.info/BBC/bb5_polygon_u64.png)
10REM POLYGON
20REM FROM AN ORIGINAL PROGRAM BY JOHN A COLL
30REM IBM VERSION / 23 MAR 86; MODIFIED 26 SEP 98
40CLS
50 MODE 32
60CLS
70VDU 26
80
90Width% = X%
100Height% = Y%
110
120
130
140DIM X(10)
150DIM Y(10)
160: count=0
170REPEAT
180count=count+1
190xorigin=RND(640*2)
200yorigin=RND(512*2)
210Radius=RND(300)+50
220VDU29,xorigin;yorigin;
230sides=RND(8)+2
240MOVE Radius,0
250MOVE 10,10
260:
270C=RND(64)-1:T=(RND(4)-1)<<6:GCOL 0,C TINT T
280FOR SIDE=1 TO sides
290angle=(SIDE-1)*2*PI/sides
300X(SIDE)=Radius*COS(angle)
310Y(SIDE)=Radius*SIN(angle)
320MOVE 0,0
330PLOT 85,X(SIDE),Y(SIDE)
340NEXT SIDE
350MOVE 0,0
360PLOT 85,Radius,0
370:
380REPEAT D=RND(64)-1:UNTIL (D AND 63)<>(C AND 6):GCOL 0,D TINT T
390FOR SIDE=1 TO sides
400FOR Line=SIDE TO sides
410MOVE X(SIDE), Y(SIDE)
420DRAW X(Line), Y(Line)
430NEXT Line
440NEXT SIDE
450IF count=50::count=0:delay%=10
460REM K% = INKEY(1)
470UNTIL FALSE
-
I got the Mandelbrot Set example to work at high resolution. (32 bit color) When I finish with the Windows Brandy BASIC V migration of enhancements to the Linux version, I'll post a Ubuntu 64 bit and Android version of the BASIC. I probably won't start the bb5.so SB extension module until sprites are working. I hope David Burnard (Napoleon Brandy Basic V Interpreter for Windows author) continues with his efforts. I will setup a Bitbucket project for the Linux/Android version of Brandy BASIC V when both the Windows version and the Linux version are in sync.
(http://files.allbasic.info/BBC/mandelbrot_u64.png)
REM From Rosetta code BBC Basic version
REM Modified to run under BB4W and Napoleon Brandy Basic
REM February 2013 by David John Burnard
REM January 2014 by John Spikowski - Ubuntu 64 bit version
t = TIME
sizex% = 800
sizey% = 600
maxiter% = 128
MODE 32
ORIGIN 0, sizey%
FOR x% = 0 TO 2 * sizex% - 2 STEP 2
xi = x% / 400 - 2
FOR y% = 0 TO sizey% - 2 STEP 2
yi = y% / 400
x = 0
y = 0
i% = 1
WHILE i% <= maxiter% AND x * x + y * y <= 4
xt = xi + x * x - y * y
y = yi + 2 * x * y
x = xt
i% = i% + 1
ENDWHILE
IF i% > maxiter% i% = 0
GCOL i% * 15, i% * 8, 0
PLOT 69, x%, y%
PLOT 69, x%, -y%
NEXT y%
NEXT x%
PRINT "Time taken = ";(TIME - t) / 100;" seconds"
END
-
The "artifacts" in the polygon drawing program are a bug in the RND() function in brandy basic
should return
RND returns a random integer 0 - &FFFFFFFF.
RND(n) returns an integer in the range 1 to n (n>1).
RND(1) returns a real number in the range 0.0 to .99999999.
fixed in windows version
-
Welcome David!
I haven't made all your changes yet to the Ubuntu version and was concentrating on getting the graphics working so I could mirror your examples.
I'll get the Bitbucket project going as soon as I'm in sync.
-
If you have used BBC BASIC in the past and would like to participate in the Brandy BASIC V beta testing, please register on the All BASIC Developer mailing list (http://lists.allbasic.info/mailman/listinfo/list) to help with the effort.
-
Once I catch up to David's Windows version, I would like to incorporate the SDL_terminal library into Brandy BASIC V. The main window will be for graphics and the terminal window for interactive programming and debugging. I'll use one of the undefined function keys to toggle the terminal window.
(http://files.allbasic.info/ScriptBasic/SDL/sdlterminal2d.png)
-
I may have gotten ahead of myself and made some assumptions that aren't true. The Brandy BASIC V version 1.20 for Linux seems to run fine. I made the RND() casting change but I really didn't see a big difference with the polygon example. Since both David's and the original Brandy BASIC site have SourceForge project sites I would be reproducing the effort with Bitbucket. I'm going to do a bit more testing under Ubuntu 64 bit before trying to compile it on Android.
The changes David made for the Windows version are specific to that OS and would require rethinking the approach in Linux. I will try to create a list of changes and see if anyone wants to try implementing them under Linux. I have enough to start porting the graphic part of Brandy BASIC V to a ScriptBasic extension module. (bb5.so) David is working on a cross platform font engine using TrueType fonts as a generation source. (he will have to explain in more detail) I'm looking forward to when sprite support is added and I hope it's cross platform.
(http://files.allbasic.info/BBC/saucer_u64.png)
REM A Flying Saucer ?
REM A simple but effective 3D drawing
MODE 32: ORIGIN 800,600
XS=2:YS=2
GCOL 14:OFF
A=700:B=A*A:C=600
FOR X=0 TO A STEP XS:S=X*X:P=SQR(B-S)
FOR I=-P TO P STEP 6*YS
R=SQR(S+I*I)/A
Q=(R-1)*SIN(24*R)
Y=INT(I/3+Q*C)
IF I=-P M=Y:N=Y
IF Y>M M=Y
IF Y<N N=Y
IF M=Y OR N=Y PLOT 69,NOTX,Y:PLOT 69,X,Y
NEXT:NEXT
REPEAT WAIT 1:UNTIL FALSE
(http://files.allbasic.info/BBC/fern_u64.png)
REM 'Fake' fractal fern
REM Original QBASIC program published in PC Magazine
REM BB4W version by David Williams
t = TIME
MODE 32: ORIGIN 200,100
OFF
GCOL 14
x=0
y=0
FOR i%=1 TO 80000
r = RND(1)
CASE TRUE OF
WHEN r<=0.1: A=0: B=0: C=0: D=0.16: E=0: F=0
WHEN r>0.1 AND r<=0.86: A=.85: B=.04: C=-.04: D=.85: E=0: F=1.6
WHEN r>0.86 AND r<=0.93: A=.2: B=-.26: C=.23: D=.22: E=0: F=1.6
WHEN r>0.93: A=-.15: B =.28: C=.26: D=.24: E=0: F=.44
ENDCASE
newx=A*x+B*y+E
newy=C*x+D*y+F
x=newx
y=newy
MOVE 600+96*x, 32+96*y
DRAW 600+96*x, 32+96*y
NEXT i%
PRINT "Time taken = ";(TIME - t) / 100;" seconds"
END
-
Fern under Napoleon Brandy BASIC , Windows 7, Dell Vostro 220 2.5Ghz Dual core Pentium 0.19s
Saucer under Napoleon Brandy BASIC , Windows 7, Dell Vostro 220 2.5Ghz Dual core Pentium 0.05s
How Do I insert images on this forum?
What spec is your PC John?
-
Also these examples are taken from Richard Russels BB4W, is he ok with you using them - his code is commercial !!
-
Also these examples are taken from Richard Russels BB4W, is he ok with you using them - his code is commercial !!
I'm surprised anyone is still trying to sell a novelty BASIC of a 80s vintage. I give credit to the authors of these relics if provided. What is the story behind Liberty BASIC and LBB? Did Richard buy the rights to Liberty BASIC or BBC BASIC or is he just trying to make a buck off nostalgic BASIC programmers? If Richard has any problems with what is going on here on the All BASIC Developer forum, have him contact me.
You can attach images and files to your posts (see Attachments and other options) below the left corner of your edit box. If you have a server or way to provide a URL to an image, encapsulate the URL with the BB IMG tag.
I'm developing on a Toshiba laptop. (64 bit dual core 2.1 ghz with 4 GB of system memory)
If adding a SDL_terminal for text to BBV isn't going to be a lot of work, I might take a shot at it. My interests is an Android version of BBV and using the graphic portion of BBV with ScriptBasic as an extension module. How much effort I put into BBV depends on your commitments to BBC BASIC.
-
Gentlemen,
Let me add my two cents to the discussion. I think it's worth it.
1. John, there must be something seriously wrong with your code performance. The benchmarks should be at least an order of magnitude faster than in your snapshots, as David correctly points out. We have compatible CPU's and good graphics cards so our figures shouldn't differ that much.
2. Also, unless your snapshot is heavily minified, there must be something very seriously wrong with BB4W's coordinate system. This code isn't compatible with standard BASIC's or other languages.
Firstly, this plot cannot fit into a window whose size it less than 1680x1050 pixels as the parameter values used won't permit it. Have a look at this code as it runs in FBSL's BASIC and Dynamic C in a 1500x1000 px window:
FBSL BASIC:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/UFO_BASIC.png)
FBSL DYNC:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/UFO_DYNC.png)
Secondly, BB4W Y coordinate is flipped upside down. I append a zip below for you to try FBSL's BASIC and C code. The zip also contains the latest Fbsl.exe binary. You can edit the script in any text editor and launch it for execution by either drag-and-dropping its icon onto Fbsl.exe's icon or typing > Fbsl.exe UFO.fbs at your command prompt on having switched to the directory where both the script and binary reside.
And lastly, reproducing this code in every other language I have yields the exact same results as seen in the FBSL snapshots.
3. Also these examples are taken from Richard Russels BB4W, is he ok with you using them - his code is commercial !!
I'm afraid this is not so, David. At least the UFO code doesn't seem to belong to Russel and frankly I don't know what it's doing in a commercial package.
The original code can be found on the Liberty BASIC site and it has been there for quite some time with comments written by its author in some rather shaky English. I'm sorry I don't have time enough to leaf through all of their numerous pages to give you a direct link but here's a link to my submission on FBSL forum (http://www.fbsl.net/phpbb2/viewtopic.php?p=9604#p9604) where the original script was attributed to LB and the author's comments were preserved intact. The submission dates back to December 2012.
I'm too lazy to dig into the Fern fractal case but I'm perfectly sure I'd find some evidence if I only go for it. ;)
-
David had mentioned in a e-mail that Brandy BASIC V using SDL is slower than his Windows implementation. My interest in BBV is portability and ease of enhancing the BASIC. Once I get this running on Android I hope to experiment with the ARM RISC features of BBC BASIC V.
The ARM architecture is similar to a Reduced Instruction Set Computer (RISC) architecture, as it incorporates these typical RISC architecture features:
* A uniform register file load/store architecture, where data processing operates only on register contents, not directly on memory contents.
* Simple addressing modes, with all load/store addresses determined from register contents and instruction fields only.
Enhancements to a basic RISC architecture enable ARM processors to achieve a good balance of high performance, small code size, low power consumption and small silicon area.
2. Also, unless your snapshot is heavily minified, there must be something very seriously wrong with BB4W's coordinate system. This code isn't compatible with standard BASIC's or other languages.
BBV uses a MODE screen resolution setting and everything is based off that. The BBC BASIC V method of graphics handling is interesting and seems to still have a strong following and maybe more so if it can phoenix its origin in RISC with ARM.
-
Here is an FloodFill example from the RosettaCode (http://rosettacode.org/wiki/Category:BBC_BASIC) site. (BBC BASIC)
A flood fill is a way of filling an area using color banks to define the contained area or a target color which "determines" the area (the valley that can be flooded; Wikipedia uses the term target color). It works almost like a water flooding from a point towards the banks (or: inside the valley): if there's a hole in the banks, the flood is not contained and all the image (or all the "connected valleys") get filled.
To accomplish the task, you need to implement just one of the possible algorithms (examples are on Wikipedia). Variations on the theme are allowed (e.g. adding a tolerance parameter or argument for color-matching of the banks or target color).
Unfilledcirc.png
Testing: the basic algorithm is not suitable for truecolor images; a possible test image is the one shown on the right box; you can try to fill the white area, or the black inner circle.
Note: BBC BASIC has a built-in flood fill statement, but to satisfy the terms of the task it is not used in this example.
(http://files.allbasic.info/BBC/floodfill_u64.png)
REM FloodFill - RosettaCode BBC BASIC
t = TIME
MODE 32
GCOL 15
CIRCLE FILL 640, 512, 500
GCOL 0
CIRCLE FILL 500, 600, 200
GCOL 3
PROCflood(600, 200, 15)
GCOL 4
PROCflood(600, 700, 0)
PRINT "Time taken = ";(TIME - t) / 100;" seconds"
END
DEF PROCflood(X%, Y%, C%)
LOCAL L%, R%
IF POINT(X%,Y%) <> C% ENDPROC
L% = X%
R% = X%
WHILE POINT(L%-2,Y%) = C% : L% -= 2 : ENDWHILE
WHILE POINT(R%+2,Y%) = C% : R% += 2 : ENDWHILE
LINE L%,Y%,R%,Y%
FOR X% = L% TO R% STEP 2
PROCflood(X%, Y%+2, C%)
PROCflood(X%, Y%-2, C%)
NEXT
ENDPROC
-
I'm not very sure but my speculation is that
MODE 32will only set the color bitness (32=True Color) within the window it draws to while
ORIGIN 800,600might set the [X,Y] point that drawing is supposed to start from.
I think these statements do not however account for why the [0,0] coordinate (point of origin) should be at the bottom left corner of canvas instead of its top left which is conventional for MS Windows graphics. This makes BB4W graphics code incompatible with other languages of the platform. Is there any way to tell the language to flip its axes before plotting?
Neither do they account for why the plot should be so small. Obviously BB4W uses some coordinate units other than pixels (perhaps twips?) or else applies scaling world transforms before actually plotting a point on the canvas.
Perhaps David can enlighten us on this subject? Graphics capabilities are my primary interest in a language. :)
-
John,
Thanks a lot for the effort of course but unfortunately this manual does not give a single answer to the questions I posed. It was top notch back in circa 1990 for 10MHz 8086 PC XT's with 10MB HDD's and color graphics adapters for some $1,300 apiece if you were lucky enough but it looks discouraging today with its incomplete support for 256 color palette graphics. Sorta counter-advertising, I'd say...
MODE 32 must have its own peculiarities this manual doesn't cover so my request to David still holds true.
-
100 Doors
Problem: You have 100 doors in a row that are all initially closed. You make 100 passes by the doors. The first time through, you visit every door and toggle the door (if the door is closed, you open it; if it is open, you close it). The second time you only visit every 2nd door (door #2, #4, #6, ...). The third time, every 3rd door (door #3, #6, #9, ...), etc, until you only visit the 100th door.
Question: What state are the doors in after the last pass? Which are open, which are closed?
(http://files.allbasic.info/BBC/doors_u64.png)
t = TIME
DIM doors%(100)
FOR pass% = 1 TO 100
FOR door% = pass% TO 100 STEP pass%
doors%(door%) = NOT doors%(door%)
NEXT door%
NEXT pass%
FOR door% = 1 TO 100
IF doors%(door%) PRINT "Door " ; door% " is open"
NEXT door%
PRINT "Time taken = ";(TIME - t) / 100;" seconds"
ScriptBasic
SPLITA STRING(101,"0") BY "" TO doors
FOR pass = 1 TO 100
FOR door = pass TO 100 STEP pass
doors[door] = NOT doors[door]
NEXT door
NEXT pass
FOR door = 1 TO 100
IF doors[door] THEN PRINT "Door ", door, " is open.\n"
NEXT door
jrs@laptop:~/sb/sb22/test$ time scriba doors.sb
Door 1 is open.
Door 4 is open.
Door 9 is open.
Door 16 is open.
Door 25 is open.
Door 36 is open.
Door 49 is open.
Door 64 is open.
Door 81 is open.
Door 100 is open.
real 0m0.005s
user 0m0.004s
sys 0m0.000s
jrs@laptop:~/sb/sb22/test$
FWIW The SB time is calculated starting from the load of scriba at the command line and ending when it exits back to Linux. The BBV version is only calculating the time it is executing the program.
I'm also thinking of extending the ScriptBasic SDL extension module I already have and piece meal in the BBV features. :o
-
Thanks Mike,
I'll include the saucer in future releases of Napoleon Brandy.
To answer your points,
The Co ordinate system in BBC Basic is true Cartesian, so X & Y axes are as per graph paper, graphical units are logical , originally 1280 x 1024 on the BBC Micro so the same co ordinates were used irrespective of the actual resolution, the logical units used were double the maximum physical resolution possible (640 x 512) on the Acorn Archimedes. It has become a de facto standard to have a 2:1 ratio on resolutions higher than that - so 800 x 600 uses logical co ordinates of 1600 x 1200 for it's plotting commands (I don't know why this is so, and it is possible to force a one to one ratio with the newer form of the RISC OS , MODE command (this is not supported by the SDL version).
The problem with the SDL version of Brandy Basic is that the Graphics primitives are mapped to SDL drawing primitives, which appear to be very slow! for my DOS and Windows port I wrote my own graphics functions to act directly upon a bitmap. The Bitmap is then Blitted to the screen , by use of an interval timer (50Hz under windows, DOS timer tick interrupt under DOS). This also mean't I could implement more (eventually all) of the BBC VDU plotting codes, these are clearly defined in the RISC OS Programmers reference manual.
The SDL library appears to include a fast and efficient Bit Blit function, I already have linux code to start a thread and initialize a 50 Hz timer so by linking my code with the SDL library a fast linux version could also be produced by blitting the memory bitmap to the screen. Keyboard handling code for linux would also need to be added, the existing code understands keyboard scancodes so I have a windows function to convert windows keystroke messages to scancodes, a similar function would be needed for SDL, It may be possible to reuse the keyboard code from the existing SDL version.
-
Hi Mike,
Screen Modes themselves are provided by the operating system and are not technically part of BBC BASIC, they are so fundamental though that when porting to other systems they must be implemented, these evolved during the development of the BBC Micro, Acorn Archimedes, Risc PC and then when finally RISC OS was separated from the hardware a universal MODE command was devised.
The BBC BASIC pdf, John sent you was from 1999, at that time the hardware did not support a 256 colour palette, later hardware did! and RISC OS was updated to support it, the palette handling existed already in the form of VDU 19 which had thoughtfully been given additional parameters for future expansion in the original BBC Micro. The Risc OS Programmers reference manual v5 is the reference tome I use. Mode 32 is technically a 256 colour screen mode, which has a fixed default palette, hence the limited colours in johns mandelbrot demo. If you wish to use a palette use the MODE"X800,Y600 C256" command or use MODE"X600,Y600 C32K" or MODE"X600,Y600 C16M" for true colour with no palette, the new form of the command is present a stub in the original version of the Brandy code, and is fully implemented in my Windows version. Also colours can be specified using R,G,B values -> GCOL 0,r,g,b
Palette changes can be effected with VDU 19,Logical colour number, 16, r,g,b
You might want to run up My basic and look at the mandelbrot demo from it.
BBC Basic for windows handles the palette/colour selection issue in different manner - INKEY(-256) gives a machine/OS number
87 indicates BB4W so I rewrote the demo from rosetta code to run on both.
-
Screen Modes defined in Brandy (derived from RISC OS screen Modes)
Mode 0 640 x 256 - 2 colours 1280 x 1024, 80 x 32 Chars
Mode 1 320 x 256 - 4 colours 1280 x 1024, 40 x 32 Chars
Mode 2 160 x 256 - 16 colours 1280 x 1024, 20 x 32 Chars
Mode 3 Text Only - 2 colours , 80 x 25 Chars - > with gaps
Mode 4 320 x 256 - 2 colours 1280 x 1024, 40 x 32 Chars
Mode 5 160 x 256 - 4 colours 1280 x 1024, 20 x 32 Chars
Mode 6 Text Only - 2 colours , 40 x 25 Chars - > with gaps
Mode 7 TeleText - 8 colours , 40 x 25 Chars
Mode 8 640 x 256 - 4 colours 1280 x 1024, 80 x 32 Chars
Mode 9 320 x 256 - 16 colours 1280 x 1024, 40 x 32 Chars
Mode 10 640 x 250 - 2 colours 1280 x 1000, 80 x 32 Chars
Mode 11 640 x 250 - 4 colours 1280 x 1024, 80 x 25 Chars
Mode 12 640 x 256 - 16 colours 1280 x 1024, 80 x 32 Chars
Mode 13 320 x 256 - 256 colours 1280 x 1024, 80 x 32 Chars
Mode 14 640 x 250 - 16 colours 1280 x 1000, 80 x 25 Chars
Mode 15 640 x 256 - 256 colours 1280 x 1024, 80 x 32 Chars
Mode 16 1056 x 256 - 16 colours 2112 x 1024, 132 x 32 Chars
Mode 17 1056 x 250 - 16 colours 2112 x 1000, 132 x 25 Chars
Mode 18 640 x 512 - 2 colours 1280 x 1024, 80 x 64 Chars
Mode 19 640 x 512 - 4 colours 1280 x 1024, 80 x 64 Chars
Mode 20 640 x 512 - 16 colours 1280 x 1024, 80 x 64 Chars
Mode 21 640 x 512 - 256 colours 1280 x 1024, 80 x 64 Chars
Mode 22 768 x 288 - 16 colours 768 x 576 , 96 x 36 Chars
Mode 23 1152 x 896 - 2 colours 2304 x 1792, 144 x 56 Chars
Mode 24 1056 x 256 - 256 colours 2112 x 1024, 132 x 32 Chars
Mode 25 640 x 480 - 2 colours 1280 x 960 , 80 x 60 Chars
Mode 26 640 x 480 - 4 colours 1280 x 960 , 80 x 60 Chars
Mode 27 640 x 480 - 16 colours 1280 x 960 , 80 x 60 Chars
Mode 28 640 x 480 - 256 colours 1280 x 960 , 80 x 60 Chars
Mode 29 800 x 600 - 2 colours 1600 x 1200, 100 x 75 Chars
Mode 30 800 x 600 - 4 colours 1600 x 1200, 100 x 75 Chars
Mode 31 800 x 600 - 16 colours 1600 x 1200, 100 x 75 Chars
Mode 32 800 x 600 - 256 colours 1600 x 1200, 100 x 75 Chars
Mode 33 768 x 288 - 2 colours 1536 x 1152, 96 x 36 Chars
Mode 34 768 x 288 - 4 colours 1536 x 1152, 96 x 36 Chars
Mode 35 768 x 288 - 16 colours 1536 x 1152, 96 x 36 Chars
Mode 36 768 x 288 - 256 colours 1536 x 1152, 96 x 36 Chars
Mode 37 896 x 352 - 2 colours 1792 x 1408, 112 x 44 Chars
Mode 38 896 x 352 - 4 colours 1792 x 1408, 112 x 44 Chars
Mode 39 896 x 352 - 16 colours 1792 x 1408, 112 x 44 Chars
Mode 40 896 x 352 - 256 colours 1792 x 1408, 112 x 44 Chars
Mode 41 640 x 352 - 2 colours 1280 x 1408, 80 x 44 Chars
Mode 42 640 x 352 - 4 colours 1280 x 1408, 80 x 44 Chars
Mode 43 640 x 352 - 16 colours 1280 x 1408, 80 x 44 Chars
Mode 44 640 x 352 - 256 colours 1280 x 1408, 80 x 44 Chars
Mode 45 640 x 200 - 4 colours 1280 x 800, 80 x 25 Chars
Mode 46 640 x 200 - 16 colours 1280 x 800, 80 x 25 Chars
I have defined additional screen modes for my own use in the Windows version ->
Mode PC Bios screen mode + 48 yields the matching BIOS screen mode
eg PC BIOS mode 0x12 -> 640x480 80x25 chars
eg PC BIOS mode 0x13 -> 320x200 40x25 chars
eg PC BIOS mode 0x8 -> 720x342 90x29 chars (when used with MSHERC.COM on DOS)
PS. if anyone has an MDA/Hercules monitor they could donate it would be appeciated
-
John,
You said you were not going to start a bit bucket project! now you have !!!
How do you intend to implement Shadow screen modes?
and a working palette in non true colour modes?
and what about teletext (mode 7) ?
To select a shadow screen mode add 128 to the screen mode number. Then use *FX 113 and *FX 112 to select the Displayed screen bank and the screen bank to write to!! See my graphbank.nap example.
For Custom size screen modes use
MODE "X600,Y600 C16M":MODE MODE+128
to set a Shadow mode. (replace the 600's with numbers divisible by 8 of your choice)
I really think you should consider starting from my code base for your linux version, unless you're aspirations are very limited.
Is it just that the linux build is broken at the mo? shouldn't take too much to get it to build again.
I think you'll come to appreciate the effort I have already put in when you get to start coding !!
Anyway you have my code to crib from if you don't want to use it as a start point -> have fun
-
Thank you very much, David,
Your information is finely detailed and very well presented and tells me much more than the manual that John sent.
I'm pouring your Napoleon from SourceForge right into my PC now and I'll come back to you for more info as soon as I've tasted its flavor. :)
Best regards,
-
John
Bit confused about the flood fill demo,
Colour/ GCOL format in MODE 32 (256 colour modes is)
BBGGRR
so
colour 0 is Black
colour 3 is Bright Red
colour 4 is Dark Green
colour 15 is Bright yellow
so your final image from this program should be red (colour 3) following the PROCflood(600, 200, 15) replacing the yellow with a dark green inner from the PROCflood(600, 700, 0) -> your image is yellow with a green inner suggesting the PROCflood(600, 200, 15) did not execute.
-
By the way mike
COLOUR Logical Colour,R,G,B
is a synonym for
VDU 19,Logical Colour,16,R,G,B
it's detailed in the ref manual
if you change the C16M for C256 in the mandelbrot demo it will this thus still work
run it then
execute
VDU 20
at the command prompt, this resets the palette to default.
-
Thanks David,
I'm still playing back the samples (haven't looked into the sources yet) and I confirm it's very, very nimble. :)
(http://i1240.photobucket.com/albums/gg490/FbslGeek/NBBV_SAUCER.png)
(http://i1240.photobucket.com/albums/gg490/FbslGeek/NBBV_FERN.png)
I'm not yet ready to discuss but I certainly like what I see. :)
-
What OS are you using Mike?
You can edit a program be typing edit<return> at the prompt ,
this dumps the code into notepad, edit it there then save the changes as you exit
run the edited program from the prompt by typing run<return>
This worked from Win95 through to Windows 7 -> broken in windows 8
I think I've fixed the windows 8 issue ready for release in v0.00.10 but I don't have a copy of windows 8 to test it on!!
-
My current dev platform is still 32-bit WinXP Sp3 Pro. It's very finely tuned to my needs and frankly I hate to see it die in a few months. I also own legit distros of 32-bit Vista Ultimate Sp1 and 7 Ultimate Sp1 as well as 64-bit 7 Ultimate Sp1 and 8 Consumer Preview and have them all installed and timely updated on my workstation on dedicated HD drives. My eldest son also owns a legit 64-bit 8.1 but we meet each other only about once a month.
So I have an opportunity to test and debug all my projects under any existing Windows environment in real time keeping my butt in my armchair. You can PM me your binary and test suite to try it under my 8 CP before you release it to public, if you like.
-
Thanks Mike,
Nice to meet someone who actually wants to help :-)
When I'm ready to release my next code I'll do just that, provided I still don't have a copy of 8 of course.
I'm using XP sp3 and VCC 6.0 myself, DJGPP for the DOS build on the same machine
running on a 2.1Ghz athlon 64 - lol
My PC at uni runs Windows 7 enterprise ed.
-
2.1GHz Athlon might be already a little too slow for modern realities. I'll be upgrading to i5-3470 3.2GHz any time soon and I think that's gonna keep me in the mainstream for a couple more years.
... It has become a de facto standard to have a 2:1 ratio on resolutions higher than that - so 800 x 600 uses logical co ordinates of 1600 x 1200 for it's plotting commands ...
Hehe, so it does apply a scaling transform to reduce the canvas size by 2 before blitting the final image into the window. That's exactly what I've been talking about even if not so clear and concise as you do. :) It also explains why your saucer looks so neat while 1:1 plots rendered in other languages are so scattered and untidy.
Talking about SDL, after some public tonguelashing by John on another BASIC forum, I've found out that both ATi and nVidia have released some decent hardware-accelerated proprietary video drivers for Linux platforms lately so HW-assisted 3D rendering in OpenGL is now not a problem under both pure Linux and that Wine half-breed thing they use to run the wealth of MS Windows graphics software on (:P John).
I don't however know if that concerns 2D blitting or if SDL can communicate with the drivers to have its blitting hardware-accelerated. This and also some recent findings by John that SDL's flood-filling may GPF if the outlines go off-canvas (evidently, due to SDL clipper bugs or glitches) are keeping me off of SDL when I'm pondering over my plans to extend FBSL to Linux too. Anyway, if you say SDL has a multithreaded software blitter then it may help somewhat but not so much as compared to system-wide HW-assisted blitting under MS Windows.
Feel free to let me know any time when you need my help. You may also e-mail me at my address which is now in your PM box. :)
-
Nice to meet someone who actually wants to help :-)
Thanks Mike for chipping in and giving David someone to work with on the Windows side of this. As I had mentioned in a previous post, my interests in BBV is stabilizing the Linux version and getting it running on Android. I created the Bitbucket project as my searches for BBV related resources kept turning up dead links. It doesn't seem the author has much interest moving the project forward.
It makes it difficult to merge your fixes with the BBV version as your version is obviously Windows centric with a Linux port as an after thought. I think we have a good mix of talent involved in the BBV projects and it should be a lot of fun.
-
John,
I think Napoleon isn't so far from Linux as it may seem. I'm reading David's docs now and I like his idea of using OpenGL under Linux. I even think the Windows engine should evolve in that direction too. If you want to know my opinion (the very inmost one), I'd prefer to see my FBSL-to-Linux extension to be based on that too. It would kill the headaches of SDL or any other home-brewed graphics library totally. It would help create truly multi-platform graphics API's unified and HW-accelerated on all existing platforms. That would leave only one problem to resolve which would be platform-independent window manager et voila, you have an incredibly fast GDI and GUI on any platform you want while program flow control and maths is naturally universal by definition.
MS Windows GDI graphics is very fast but OpenGL is much, much faster. At the same time, contemporary OpenGL drivers are top notch on any platform. No more comparative benchmarking, no more competition, no more distraction from the main task of adding useful features to the language proper for the benefit of its users.
Napoleon is a relatively small and straight-forward project which may be a nice place to test and polish up methods and strategies that might help others to carry on with their own projects on any platform.
-
I'm sticking with SDL at the moment for portability reasons. If I want to run BBV on Android anytime soon with touch, orientation, ... SDL is the only way for me to get there. I'm limited to a SDL/JNI interface on that platform.
@David: My biggest hangup at the moment getting BBV to run on Android is the printf / fprintf console I/O. Has your version been changed to redirect this to your graphics UI?
-
With regard to David Daniels (the author of Brandy Basic) not wishing to move it on, he confirmed this to me by email when I contacted him regarding my windows port.
He agreed I could add my name to the signon and that the name prefix of Napoleon was acceptable to him for my version.
He did say he was also pleased that people were still interested in the program :)
-
Thanks David for the RND() fix. The following line you added was needed.
push_int(TOINT( (randomfraction()*TOFLOAT(value))+1) );
Here is a new polygon.nap screen shot with your fix.
(http://files.allbasic.info/BBC/polygon_u64.png)
-
To be fair, this RND() and the random number seeding are the only bugs I've found in David Daniels original code -> Which is awesome, the speed of the underlying interpreter is a tribute to his abilities !!
I see my version of the graphbank demo is picking up some artifacts from whatever program you used for the video capture :-(
But yes the SDL version does not implement shadow screen modes, this provides two screen banks for the display, so one can be used for drawing and the other for display, then swap the blocks for classic old style double buffering!! the feature was added to the Acorn MOS on the BBC Master computer, before that on the BBC Micro model A & B this wasn't possible as it didn't have enough RAM. It has been carried forward into Arthur OS and RISC OS ever since.
Is it part of BBC Basic? not in the strictest sense! but very useful none the less.
Is it possible to direct SDL to render its graphics primitives off screen to a back buffer?
Richard Russell in BB4W ignored the Risc OS implementation and introduced his own *REFRESH command for controlling display of the off screen composition buffer -> both methods are perfectly valid and as Richard was part of the original team at Acorn he can change the language as he chooses, but I'm using the RISC OS programming reference as my specification !! Roger (now Sophie) Wilson's original branch of the language is what I grew up with! and is still current in RISC OS 5.
Also pattern fills were added to the MOS on the BBC Master -> patterntest.nap and carried forward from then on (with a new method to define the patterns introduced on the Acorn Archimedes). These are also implemented on my windows version. :-)
In addition Acorn produced a GFX Rom for the BBC B to add this and some other VDU code features which were built into the newer BBC Master.
-
As regards console IO my windows version does not use printf or fprintf at all now!
ALL OUTPUT CHARACTERS now pass though the VDU stream function emulate_VDU(); and true_emulate_VDU(); (this was not true of the original screen rendering codes) where they are rendered to the bitmap and/or are passed on to other channels (only other channel implemented at the moment is the serial port)
start
Win32Basic.exe -com:<Serial port number> (best done from within a windows shortcut)
*fx 2
and
*fx 3
then control serial port redirection as per RISC OS Programmers Reference Manual
I have an emulate_printf() function which can print strings as per printf() through the VDU function for debug purposes.
John,
I have already urged you not to reinvent the wheel, I believe my solution is actually quite elegant and just needs the appropriate keyboard read and bitblit write functions adding to run under linux. These functions are available in SDL.
-
John
The Shadow screen modes were added on the BBC Master in 1986, The book cover you've shown was from a book published in 1981, you aren't going to find anything about shadow screen modes in there !!!
-
Yes John
It's something I fixed in my version, see keyboard.c , the original used a sigint exception to detect the escape key (sort of works in the original DOS version), I detect it in the keyboard polling loop, you can carry my code over wholesale if you can't figure it out yourself.
I do not want to spend my time explaining every change I made to create Napoleon Brandy Basic and whilst I don't want to be rude, I don't approve of you resurrecting the original code base as a new project. Have you attempted to contact David Daniels and/or Colin Tuckley with respect to taking over the maintenance of their code?
As the code is open source you are of course free to take this course of action, but I will get very annoyed, under these circumstances, if you expect me to explain ALL of the changes I have made!!
PS. Possible stability issues with the Load, Run and Chain commands --> be careful how you proceed.
-
... if I can get it running but it will be a personal effort and more than likely I will not release it. (ML: italization is mine)
John,
Please reconsider your own words very carefully. Do you mean that if you have to exert your personal effort then you're not going to share your results in public? Then how can you expect someone else's effort to be shared with you unequivocally in return? And then how can you advocate open-sourcing at all if you don't seem to be prepared to share your own produce generously and unconditionally?
It seems like you have just scared away a nice guy and an eager and capable developer too. Yes, his project is MS Windows-"centered", as you put it, at this point. But so is Charles', Eros', and mine. Should we also go now? Do not look down on Windows so shortsightedly as I don't see very many Linux addicts here to share your company for a change.
And why didn't you ask me if I would want a dozen or so of my own messages to be gone without prior notice?
I did notice that the entire thread was gone from the forum. I think I wasn't the only one to notice it but we're already accustomed to such twists somehow. I think you had better leave it at that than revive the thread using such dubious phraseology.
-
OK John, let's leave it at that. Perhaps things are not as bad as they might seem to you or me; time will show. :-\
-
Thanks for restoring the thread, John!
It's already part of NBB's history and I guess there's nothing so bad in it as to have it buried so early. Time does fly and if all goes well, David will have his project polished soon enough to be ready to proceed to other platforms of his choice. Perhaps he feels he should have a perfectly working proto first before he moves on.
These are only my speculations, of course, but something's telling me he'll eventually calm down and will realize that steel gets only harder when tempered.
That's life. :)
-
John,
Please don't mess with these exception handlers unless you REALLY know what is behind them in your OS!
They are to handle system events (interrupts) , Sigint is the only one you need be concerned about!
#ifdef TARGET_DJGPP
sigintkey = __djgpp_set_sigint_key(ESCKEY);
#endif
#ifdef TARGET_MINGW
/* Launch a thread to poll the escape key to emulate asynchronous SIGINTs */
if (sigintthread == 0)
sigintthread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)&watch_escape, NULL, 0, NULL);
#endif
The code for the TARGET_DJGPP sets up an interrupt under DOS and links it with the Escape Key, this then diverts the interrupt to the exception handler routine! this means that the escape key is handled asynchronously to the basic interpreter, which was done to allow Escape to work even when in the middle of a System() call to the OS, used for *commands
Under a Linux console I believe the default key combination of Sigint is Ctrl C, hence the program breakout with this key combination !
The TARGET_MINGW code sets up a thread to monitor the Escape key using the polling function watch_escape(), this code should be applicable under linux but you may (or may not) have to rewrite the watch_escape() function !
#ifdef TARGET_DJGPP
(void) __djgpp_set_sigint_key(sigintkey);
#endif
#ifdef TARGET_MINGW
if (sigintthread != NULL) TerminateThread(sigintthread, 0);
#endif
This code removes the handlers before BASIC exits
The use of an asynchronous escape event causes a whole raft of possible problems which are not deterministic in nature, making debugging a nightmare, hence my decision to look for the Escape key in the keyboard polling loop, I then always know the calling point for the escape event and the behavior is deterministic. The down side is that you then need to implement emulation code for all the shell commands you would have called by the System() function but this command opens a console window (which is undesirable) anyway.
PS The "shell" type *commands in BB4W are all emulated too !
-
I really couldn't give a fig about android at this point in time, nor linux for that matter, for desktop PC's, Windows ( like it or not ) is still where the majority of systems are! Once Napoleon is complete for Windows, then MS DOS (because I have a soft spot for it, and it's my benchmark for the portability of my generic code) then I'll do a Linux port, Linux is a very good but minority operating system !!
I also think if you persist in resurrecting the original code you'll cause more harm than good !
so I hope as you said earlier this is just for your own entertainment !!
I know of other problems you will encounter along the way! if you persist. As I have told you privately I do not intend to do a linux or android port though you by proxy. I had hoped that pointing out the non deterministic nature of Escape key detection in the original, would have indicated the magnitude of the task of making Brandy complete and just as importantly stable. In addition Brandy never had complete VDU handling or sound support except under RISC OS where these features are supplied by the operating system.
I suggest you download rpcemu and a RISC OS 5 image from RISC OS open and fully acquaint yourself with BBC BASIC before you proceed any further. It is absurd having someone who openly admits to not being a BBC Basic programmer, trying to port a BBC Basic clone.
I have already wasted too much of my life on your lunacy, I think you just like winding people up :(
This is my last post in this thread, as far as I'm concerned this issue is closed.
-
Calling me an idiot and my efforts were absurd was the last straw.
Was his quitting his own initiative or rather your ban? I don't see him being that outright rude; harsh or straight-forward, yes, but obscene, no. Too bad, anyway... (http://www.fbsl.net/phpbb2/images/smilies/icon_ml_flaming.gif)
BTW suprisingly, your Napoleon is a spitting image of Mr. Putin (Russia's President) though he hasn't yet been seen promoting the gay movement. (http://www.fbsl.net/phpbb2/images/smilies/icon_lol.gif)
I don't have any Apple products so maybe AIR or Mike (with his emulator) can try it out on that platform.
I gather AIR is a retired developer, isn't he? (http://www.fbsl.net/phpbb2/images/smilies/icon_ml_winkwink.gif)
As for me, currently I'm only fiddling with Mac in my emulators but this year I'm planning to use what's left after my HW upgrade to Intel i5 for setting me up a Core2 Duo Hackintosh. My old MB, CPU chip and peripherals aren't exactly on Apple's supported HW list but they will do perfectly well for testing purposes. I don't really see why I'm supposed to spend a fortune on their branded gimmicks until I've tried that OS out thoroughly with my own hands. I do however inherit a legit box version of Snow Leopard from my son. It's not top-notch these days but still usable.
Perhaps then I'll do some actual coding too but until then, I can only offer a try-out of somebody else's software in my emulators.
Landscape versions of the below screen shots have been reduced from 1280 width to 800.
Does that first mesh sample support shadow modes?
-
I don't ban developers. David picked up his ball & bat and left the field.
So be it. Perhaps he reconsiders his decision some day...
He still farts around ...
LOL
How is your Linux project coming along?
It's not yet a project; I'm still getting used to Ubuntu after my old tiny little Slitaz installation that I was using for fun and experiments for a few years. I'm currently involved in another rather important coding activity I'm supposed to finish by the end of January. Perhaps then I'll have more time for getting a closer look at Linux' current programming practices and will eventually start trying to adapt FBSL to alien environments.
I really don't see bank swapping being hard to implement with SDL.
Looks rather similar to ordinary backbuffering. If so then it shouldn't really pose any issues as the technique is rather well-developed.
-
I gather AIR is a retired developer, isn't he?
He still farts around with his version of BCX (MBC3) and did the JADE (C++ version of C BASIC) project.
Wise Ass! LOL.
Been playing with PHP/JS/CSS/MySQL in my spare time lately...
AIR.
-
Glad to see you are still with us.
I got the Android version of Brandy BASIC V working finally. Not having UNICODE was a PITA. Do you want to give it a try on your Kindle?
-
Been playing with PHP/JS/CSS/MySQL in my spare time lately...
You should seriously consider adding jQuery to that list.
-
I am, along with Bootstrap.