stardot / matrixbrandy Goto Github PK

Basalt for RISC OS extends DIM to allocate Dynamic Memory Areas. In Matrix Brandy this can be a wrapper for malloc() and friends.

Syntax:
DIM HIMEM a% 4095: REM claim
DIM HIMEM a% 512: REM resize
DIM HIMEM a% -1: REM release

On Raspberry Pi, this program gives the expected result:

$ sbrandy -size 48000000 classic_small-test.bas
? 100
354224848179261915075

but on x86_64 I get:

$ sbrandy -size 48000000 classic_small-test.bas
Tried to take square root of a negative number at line 8610

A little bit of shotgun debugging (adding 8605 PRINT " *** F0: "; F0) sets variable F0 to 1.07374182e+09 where the same code on x86_64 sets it to -1.07374182e+09

Systems are:

• Raspberry Pi: gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516, Raspbian Stretch

• x86_64: gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0, Ubuntu 19.04

BBCSDL uses ]addr%% to access 64-bit values in memory. This should be added to Matrix Brandy.

This limitation prevents many game type setups from running smoothly, as in an arcade situation you may well want to press another key while one is held down.

As title, hitting ESCAPE doesn't trigger an escape when pressed in the SDL window.

The current RISC OS build needs a wimp slot set before the binary is run, typically:
WimpSlot 1200K
/.brandyRO

The binary is about 440K, which is smaller than the default 640K wimpslot, so there should be a way for the binary itself to claim the amount of memory it needs (and is 640K-440K=200K really too little to run?).
I've tried doing this, the code is commented out and maked "I can't get this working".

Sound is a glaring part of BBC BASIC that is currently missing from Brandy.

I've taken an initial look at the audio from BeebEm (which also uses SDL 1.2) but it is extremely tightly tied to the emulated sound hardware of the Beeb.

Recommend renaming:
keyboard-inkey.h to inkey.h
mos_swinums.h to swinums.h
mos_sys.c to swis.c

Gets rid of unncessessarily-long and unneccessary hyphenated names, gets rid of inconsitant hyphen/underline-ation, makes names more consitant with contents, eg, when looking for SWI handling I look for s... not m... Also, closer match to RISC OS source naming. ;)

I was fighting with this all yesterday get get a stable base before starting work on the keyboard code.
The current RISC OS build bombs out on startup.
See http://mdfs.net/Software/BBCBasic/Brandy/matrix/img/ for screenshots.

With a Wimp slot of 1200K from v21/18, it dies with an EMT error. On investigating, FAQs state this is due to there not being enough stack space on startup, so WimpSpace needs to be increased. However, doing that just results in a machine crash. I've tried upping WimpSlot to 12,000K and it still fails.
Version 1.21.18, 28 Dec 2018 works fine.
I've trawlled through the current code, have experimentally commented bits out and back again, and can't find what change has caused this. Unless anybody else can find the problem, my next step is to go back to v1.21.18 and incrementally add stuff back in until it falls over.

any chance of getting a windows build for this?

10 READ A$:PRINT A$
20 DATA "'/"""
should set A$ to the 3-character string '/"
it incorrectly sets A$ to the 1-character string '
Quotes in DATA strings should be parsed as in any other constant string, eg A$="->""<-" correctly sets A$ to the string ->"<-

Non-function special keys are not modified by modifier keys.
Shift/Ctrl/Alt plus arrows,Ins,PgUp,PgDn,End should EOR 0x10 or 0x20 with the keypress.
For example:
PgUp=&9F, Shift+PgUp=&8F
Up=&8F, Shift+Up=&9F
See http://mdfs.net/Docs/Comp/KeyMap/RISCOS

keyboard.c is a big mess, when I was working on the Napoleon fork four years ago I was about to print the whole lot out and edit it with scissors and tape. When the negative INKEYs is done, I'll have a look at tidying the whole lot up.

Reported by dhg2 @ Stardot.

10 A%=TRUE
20 IFA%:A$=TIME$ELSEA$=""

Gives 'Cannot find variable TIME$'.

Uncrunched:
20 IF A%:A$=TIME$ ELSE A$=""
works fine.

This happens whether it is entered in Brandy or as prewritten code with the tokenised line:
[tokenIF]A%:A$=[tokenTIME]$[tokenELSE]A$=""

Not sure where it's occuring. In "normal" BASIC the fnTIME routine called by evaluating tknTIME does:
if byte[next]<>'$' branch to TIME
next++
do TIME$

Version 1.22.9 (MinGW/x86/SDL) 06 Jan 2021

Sometimes, eg:
PRINT blah blah;SPC 4
is performed as
PRINT blah blah;SPC 4;
It should perform the same as:
PRINT blah blah;SPC 4;:PRINT

*EXEC (no filename) fails. It displays a message instead of closing any existing EXEC file.

*EXEC's functionality is:
If EXEC file open, close it
If filename present, open it, EXEChandle=filehandle

the same as *SPOOL.

Implement *REFRESH from BB4W / BBCSDL:

*REFRESH OFF stops the screen from being updated, so anything you draw or print won't be seen until you ask for the screen to be updated with *REFRESH. And *REFRESH ON makes it so the screen gets updated automatically again. It's useful for eliminating flicker problems from animations.

The following code gives me an "Address exception at line 310" error. I don't think this should happen. I think it's damaging the state of brandy somehow, because once the bug has happened, I can strip this code down to something smaller that also causes the error but then after restarting brandy the stripped down code no-longer causes the error. So it's tricky to pin down how to recreate this bug, but this block of code appears to do so consistently. Hence, to replicate the bug it's safest to restart brandy then run this code.

It also might be something to do with the parser, because putting a "THEN" into line 310 after the IF fixes the bug.

Also weird (this might be another bug), if we move lines 300 and 310 to lines 90 and 95, then the error message changes to "'=' (function return) encountered outside a function at line 95"

10MODE 13
20oversize%=4
30y_oversize%=4
40DIM streamers% 1000
50sfy1%=0:sfy2%=4:sfx1%=8:sfx2%=12:sfm%=16:sfcol%=20:sftype%=21
60DIM sfX%(y_oversize%):FOR I%=1 TOy_oversize%:sfX%(I%)=20+I%*4:NEXT
80PROCstreamer(2,3,71,1,0)
90PROCincrease_streamers
100END
110
120DEF PROCstreamer(x1%,y1%,x2%,y2%,col%) LOCAL dy%,m,y,x,I%
130dy%=y1%-y2%
140m=(x2%+0.5-x1%)/dy%
150y=(y1%+oversize%-1)DIV oversize%oversize%
160x=x1%-(y-y1%)m
170x=x/oversize%
180IF m>0 x-=m/y_oversize%
190:
200!(streamers%+sfx1%)=x1%:!(streamers%+sfx2%)=x2%
210!(streamers%+sfy1%)=y1%:!(streamers%+sfy2%)=y2%
220?(streamers%+sfcol%)=col%
230!(streamers%+sfm%)=m2^16
240FOR I%=1 TOy_oversize%
250!(streamers%+sfX%(I%))=((x+m(1-I%)/y_oversize%)*2^16)OR&80000000
260NEXT
270ENDPROC
280
290DEF PROCincrease_streamers LOCAL x1%,x2%,y1%,y2%,m%
300y1%=3
310IF 0<y1% ?(streamers%+27)=?(streamers%+27)AND&7F ELSE ?(streamers%+27)=?(streamers%+27)OR&80
320ENDPROC

The following code works under RPCEmu but not under Brandy:
10num_rows%=6
20DIM vec(2)
30DIM matrix(num_rows%,2)
40DIM result(num_rows%)
50result()=matrix().vec()

On brandy it produces an error message "Type Mismatch. Arrays must have the same dimension at line 50". If I change the shape of vec and result to (2,1) and (num_rows,1) respectively, so that the "dot" operation applies to "matrix dot matrix" then it works. But it seems BBC Basic V/VI could also understand how to do "matrix dot vector".

I've checked the above code under RPCEmu and it produces no error.

With the current build PAGE now unexpectedly returns &8F00. That causes all sorts of problems with programs that see PAGE=&8F00 as meaning the program is running on ARM BASIC (as distinct from running on RISC OS which is the OSBYTE 0 value).

If CALL &FFxx/USR &FFxx access a BBC filing system entry block, then PAGE needs to be <&FFFF so that common code that does, eg:
IF PAGE<&FFFF THEN CALL &FFDD ELSE do something else

As currently the only &FFxx entry point implemented is a subset of OSBYTE/OSWORD, PAGE should return a value >&FFFF. Probably larger than &1FFFF as Basic128 has PAGE=&10000.

If a program pseudovar is used in an IF/THEN statement, a Type mismatch error occurs. Probably an issue from adding 64-bit integers. Could be due to an INT32/INT64 type being misinterpretated. Examples:

PRINT ~PAGE, ~TOP, ~LOMEM, ~HIMEM
1E80020 1E8151C 1E81524 1F00020
PRINT PAGE>1,TOP>1,LOMEM>1,HIMEM>1
-1 -1 -1 -1
IF PAGE>1 THEN PRINT "HELLO"
Type mismatch: number wanted
IF TOP>1 THEN PRINT "HELLO"
Type mismatch: number wanted
IF LOMEM>1 THEN PRINT "HELLO"
Type mismatch: number wanted
IF HIMEM>1 THEN PRINT "HELLO"
Type mismatch: number wanted

And just to make sure it's not the command after the THEN:

IF PAGE>1 THEN REM
Type mismatch: number wanted

Tested on and affects DJGPP, MinGW and WinSDL builds, so probably not build specific.
This kills all the test programs that examine the program's environment! :(

"X=&4D Matrix Brandy BASIC (ie ASC"M") for all builds from V1.22.6 except RISC OS."

Wrong. INKEY-256 must return the platform, NOT the interpeter. It's a call to the HOST, NOT the interpreter. It's "Check machine type" not "Check interpreter type". Doing this builds in another IF this THEN dothis ELSE an exception ELSE another excpetion ELSE another exception. There are pre-existing methods of determining what functionality the interpreter has (http://beebwiki.mdfs.net/What_BASIC_is_running), they must be used, not abusing the "what is the OPERATING SYSTEM call, and it breaks the principal of "test for functionality not for psychic ability". It must return the values originally in the target.h file, these ones and similar:
X=&FB Beos (Brandy Basic)
X=&FA DOS with DJGPP extender (Brandy Basic)
X=&F9 Linux
X=&F8 MacOS X (Brandy Basic)
X=&F7 FreeBSD
X=&F6 OpenBSD
X=&F5 Amiga (Brandy Basic)
X=&F4 GNU FreeBSD (Brandy Basic)
X=&F3 GNU (Brandy Basic)

10 REM - Market Day 20 MODE2 30 FOR X=0 TO 7 40 VDU19,X+8,X,0,0,0 50 NEXT 60 ROW=1100 70 REPEAT 80 SIZE=(60-ROW/20)*4 90 ROW=ROW-SIZE-2 100 FOR COLUMN=1 TO 15 110 MOVE COLUMN*SIZE,ROW-100 120 GCOLRND(255),0 130 PLOT0,SIZE,0 140 PLOT81,-SIZE,SIZE 150 PLOT1,SIZE,-SIZE 160 PLOT81,0,SIZE 170 NEXT 180 UNTIL ROW<=0

Starting to see a problem as a bunch of listings I have tried don't seem to work at all as described in the book. I get not implementing something difficult like sound, but there seems to be things that were commonly used in the listings that just break a great deal of stuff that you will find in the magazines and books for the beeb.

When I run this code, the triangle should be entirely off the top of the screen (i.e. not drawn at all), but the code leaves the top-most line of pixels on the screen coloured white. Hence I believe there is a clipping bug.

10MODE 9
20MOVE-15.6,1290.12:MOVE170.41,1169.88:PLOT85,-25.85,1369.835

The following code misses out a pixel in the right-hand polyline, but I don't think it should do. The left one doesn't miss it out. Also, why is the left polyline straight?
10MODE73
20VDU29,1606;1286;
30GCOL3,15
40MOVE -565,269:PLOT 13,-566,289:PLOT 13,-565,300
50MOVE 565,-269:PLOT 13,566,-289:PLOT 13,565,-300

Note that plot 13 draws a line but misses out the end point. So the consecutive plot statements should not xor any overlapping point out of existence. But this does seem to be happening on the right hand line.

The pointer vanishes when you move it over the output window. Rather disconcerting!

How many colours should mode 73 have? The document https://github.com/stardot/MatrixBrandy/blob/master/docs/ScreenModes.txt says 4, but it seems there are many more.

When trying to run the following code flash does not seem to be rendered in Mode 7.

`10 MODE 7

20 PRINT CHR$(141);CHR$(157);CHR$(129);

CHR$(136); "THE LOT"

30 PRINT CHR$(141);CHR$(157);CHR$(129);

CHR$(136); "THE LOT"`

Using test program at http://mdfs.net/temp/vdata.zip

Unzip, will give:
ViewData Acorn tokenised BASIC program
0 Teletext page file

From Brandy, CHAIN "ViewData". Teletext test page displayed ok. Press Escape. Gives error:
Cannot find function 'FNerr'
LIST
Program has vanished.
LOAD "ViewData"
LIST 1140,1160 - the function definition is there.
PRINT FNerr
Cannot find variable 'flg%' at line 1150
Ok. flg%=0:PRINT FNerr
Cannot find variable 'flg%' at line 1150
Yerwot???

If I edit line 1150, delete flg% then retype it, doing flg%=0:PRINT FNerr works. If I RUN the program it goes back to the initial problem, FNerr not found, program vanishes.

I'm trying to track down what is causing this and trying to create a minimum test case.

Matrix v1.22.10 (MinGW/x86-32/SDL) 14 Feb 2021

Is there a reason for GET/GET$/INKEY/INKEY$ and elsewhere to use constructions like this?
do {
ch=emulate_get() & 0xFF;
} while (ch==0);

It means that Ctrl-@ is never passed back to the caller.

Has anybody tested Brandy on Windows 8.1? I've been temporarily using my neighbour's Win8.1 laptop for testing and GitHubing.

Brandy Win/DJPP gives 'Cannot run on this version of Windows' - fairly expected as it's a DOS target.
Brandy Win/MinGW runs fine.
Brandy WinSDL gives 'SDL.dll not present' (I believe, as it's in Chinese). Trying to install SDL.dll with regsrv32 gives 'Module SDL.dll failed to load ... The module could not be found'

Works fine on her Win8.0 desktop.

Action:

export EDITOR=micro
brandy

or

EDITOR=micro brandy

Expected result: the EDIT command should open the temporary file in the editor of my choice

Actual result: the EDIT command opens the temporary file in vi, the editor of my very last resort.

Platform: Ubuntu Linux 19.04, x86_64

A side effect of mode7flipbank being called from emulate_inkey.

I've just tried to update my fork with the latest code, but am getting:
Can’t automatically merge. Don’t worry, you can still create the pull request.

but without any actual option to continue to create the pull request :(

Building with USE_ANSI defined should instruct the VDU driver to use ANSI control codes (eg esc[...m for colours), but building throws loads of errors. A USE_ANSI build has probably not been tested for some time and modifications for other targets have broken it.

I generalised calls from the VDU driver to read the SHIFT keys to a kbd_modkey() call. At the moment the only caller is the VDU driver for paged scrolling, and it passes an argument of 1, kbd_modkey() just tests the SHIFT key but it should be generalisable for other modifier keys - for instance pausing scrolling with Shift+Ctrl.

I have two thoughts about the parameter to pass: the key number or a bitmap of keys.
With keynumber, kbd_modkey(1) would test SHIFT, kbd_modkey(2) would test CTRL, kbd_modkey(3) would test ALT, so kbd_modkey(1) | kbd_modkey(2) would test for Shift+Ctrl.
With a bitmap, kbd_modkey(1) would test SHIFT, kbd_modkey(2) would test CTRL, kbd_modkey(4) would test ALT, so kbd_modkey(3) would test for Shift+Ctrl.

Thinking forward, which would be the most useful? bitmap optimises the caller, but keynum optimises the callee. The equivalent call in the BBC MOS returns a bitmap.

BBCSDL has these supported. It is not a stretch to implement these calls for Matrix Brandy also. The framework exists as OSCLI, OSBYTE and OSWORD are supported already. (Taken from the AArch64 BASIC thread on riscosopen.org)

	case 0xFFE0: // OSRDCH
		return (int) osrdch () ;

	case 0xFFE3: // OSASCI
		if (al != 0x0D)
		    {
			oswrch (al) ;
			return 0 ;
		    }

	case 0xFFE7: // OSNEWL
		crlf () ;
		return 0 ;

	case 0xFFEE: // OSWRCH
		oswrch (al) ;
		return 0 ;

	case 0xFFF1: // OSWORD
		osword (al, (void *) xy) ;
		return 0 ;

	case 0xFFF4: // OSBYTE
		return osbyte (al,xy) ;

	case 0xFFF7: // OSCLI
		oscli ((char *) xy) ;
		return 0 ;

Reported by dhg2 and scruss at *. :

I've noticed some keyboard/input related bugs. If you run this:

REPEAT:PRINT GET:UNTIL0

then press any of the arrow keys, page up/page down, Insert, End, or F1 through F12, it seems like two keypresses are recorded into the keyboard buffer. So a 0 appears, and then a number representing the key that you pressed.

Also, if the Capslock is off, pressing the Capslock key seems to put a 0 on the keyboard buffer. This causes another problem where if you switch the capslock on and then start typing at the prompt, the next letter you type after turning on the capslock won't appear. So if you type "one (capslock)two", "one WO" will appear on the screen.

While packaging MatrixBrandy 1.21.7 for openSUSE linux, I see this in the log:

I: A function overflows or underflows an array access. This could be a real error,
   but occasionaly this condition is also misdetected due to loop unrolling or strange pointer
   handling. So this is warning only, please review.
W: brandy arraysubscript src/tokens.c:2206, 2214

and

brandy.x86_64: I: binary-or-shlib-calls-gethostbyname /usr/bin/brandy
The binary calls gethostbyname(). Please port the code to use getaddrinfo().

Here's why about the latter.

They should be (1,2) and (2,2) scaling respectively, with a 2px gap between each line. Currently, this is not happening and they are displayed on a (1,1) scaling with no gaps.

MODE &87 doesn't select MODE 7, it is treated as an unknown MODE and selects MODE 0. All other shadow MODEs are correctly selected. The flaw is in
graphsdl.c -> setup_mode() where:
modecopy = mode;
mode = mode & MODEMASK; /* Lose 'shadow mode' bit */

needs to be before the first paragraph.
(Can't do an upload from here otherwise I'd fix it.)

hello,

i am getting the error building the latest MaxrixBrandy. i have installed the SDL1.2 package mentioned.

ld: library not found for -lrt

I've updated target.h to add "/SDL" to the startup string for SDL builds, but Git won't let me request it to be pulled. Look in my fork to find it.

When opening a file or network stream, for example H%=OPENUP "ip4:"+H$
this is not handled correctly, and the code block is passed ip4:"+H$ - which obviously doesn't work, additionally, th

Current workarounds are to either build the string then pass the completed string as OPENUP H$ works, alternatively H%=OPENUP("ip4:"+H$) works too.

I'm trying to run some of my old Archimedes BASIC IV code under Brandy. Most work great - thank you! However this bug came up:

Example code:

10step=5
20FOR ang%=0 TO 359 STEP step
30PRINT ang%
40NEXT
RUN
Error: "Type Mismatch. Number wanted at line 20".

If I run this under RPCEmu I get the numbers printed out 0, 5, ..., 355.

In full screen mode, the screen is not automatically updated (except in Mode 7, which does regular refreshes to support VDU136/Flash), and leaving fullscreen leaves a corrupted display. In both cases *REFRESH will force a display update but does not resolve the automatic updates. Cursor placement is also very wrong.

None of this affects the Linux build.

COLOUR 129:COLOUR 3:PRINT "Hello":VDU 20:PRINT "there"
should print 'there' in colour 7 on colour 128 (white on black), but actually prints in the same as 'Hello'.