Page 1 of 1

New version of WimBasic

Posted: Mon Apr 16, 2012 5:53 am
by wimoos
Hello all,

There is a new version of WimBasic available. Please check http://wimbasic.webs.com .

The main improvements include:
- fixes in the ROUND() function
- fixes in using defined functionkeys
- fix in the FIND command
- slight change in the SuperNumbers implementation: it no longer uses the IERROR vector, but now hooks in the LET-routine (where it should be).

Regards,

Wim.

Posted: Mon Apr 16, 2012 1:31 pm
by MicroPet
Forgive me if this is a silly question but can other people run programs written in WimBASIC on a stock Vic 20?

Posted: Mon Apr 16, 2012 1:41 pm
by Mike
MicroPet wrote:can other people run programs written in WimBASIC on a stock Vic 20?
Nearly all BASIC extensions must be loaded in and started before any program that uses them. These toolkits contain new routines to execute the additional commands and functions, and these routines do not 'magically' become part of your own program when you save it to disk.

WimBASIC is located in BLK5, so it must either be present as (EP)ROM in a cartridge or be soft-loaded with a RAM expansion that maps into BLK5. Either way, this isn't a stock VIC-20 anymore.

Yet another new version of WimBasic

Posted: Fri Jul 20, 2012 9:14 am
by wimoos
There is a new version of WimBasic available at http://wimbasic.webs.com

This new version contains a new command, called DIVMOD.
This command is used to calculate the quotient and the remainder of two unsigned integers (0..65535). The results are put in two variables DQ and DR.

Thanks to Marco for inspiration !

Also at the site a ZIP with a few sample programs in that make extensively use of WimBasic functions.

Enjoy!

Wim.

Yet another new version

Posted: Mon Oct 29, 2012 12:15 pm
by wimoos
This new version, that can be found at http://wimbasic.webs.com/wimbasic.zip has some major improvements:

1. Directory to screen (>$) now also works in VICE.

2. It is now possible to CHAIN programs using EXEC"(up-arrow)PROGRAM"

3. It is now possible to perform a calculated GOTO using EXEC"GOTO"+STR$(A+B*C)

Regards,

Wim.

And another new version

Posted: Tue Dec 25, 2012 11:03 am
by wimoos
In this version RENUM was fixed to handle the following properly:

IF cond THEN linenumber ELSE linenumber

The linenumber after ELSE would not be renumbered. To circumvent this, a colon before ELSE was needed. The new version fixes this

Also the following was not handled properly:

ON byte GOTO line1,,line2,line3 (note the missing number between the first and second comma).

This could gobble up the program. The new version fixes this.

WimBasic is available from http://wimbasic.webs.com as always.

Regards

Wim.

Posted: Tue Dec 25, 2012 1:27 pm
by buzbard
When I add wimbasic.prg in vice (xvic.exe) I get:

Code: Select all

Main CPU: JAM at $BBC1
I've noticed the same in the last few versions.

Posted: Tue Dec 25, 2012 4:41 pm
by buzbard
I was trying to attach it as a cartridge at $A000, but if I load it into RAM at $A000 it works ok.

And if I add zeros at the end to make the file exactly 8k +2 bytes (for load address) it works fine as a cartridge.

@wimoos: if you add:

Code: Select all

.org $bfff
.byte $ff
as the last 2 lines line of the source it should fill the remaining space with $FF so that it works as a cartridge image in vice.
Works in DASM anyway.

Posted: Wed Dec 26, 2012 2:43 am
by wimoos
@wimoos: if you add:
Code:
.org $bfff
.byte $ff
as the last 2 lines line of the source it should fill the remaining space with $FF so that it works as a cartridge image in vice.
Thanks for the suggestion, I fixed it


Regards,

Wim.

Re: New version of WimBasic

Posted: Mon Oct 19, 2015 7:03 am
by wimoos
Yet another new version of WimBasic is available.

I managed to create enough space to reinstate the HARDCOPY statement. In order to retain backward compatibility with ExBasic, I assigned it the same token value it had there. The token value for UNNEW thus changed: this should not present a problem.

Wrapping it up: WimBasic is ExBasic, minus the DEC() function, but plus a load of extra features (such as SuperNumbers, WHILE-WEND), bugs fixed and speed improvements ! Enjoy !

You can find WimBasic at http://wimbasic.webs.com

Regards,

Wim.

Re: New version of WimBasic

Posted: Wed Aug 30, 2017 11:57 am
by wimoos
After two years, I have released yet another new version of WimBasic, in which more improvements have been implemented.

The most noticeable improvements are around the PRINT USING statement.

In previous versions:
1) a formatting string containing double quotes would be misinterpreted
2) the syntaxis for printing to a file (PRINT USING#1, "<format>") was incorrect
3) the tape-buffer was used for temporary storage of the output string (limiting the output to 192 characters and interfering with tape I/O)
4) the implementation of rounding decimals was dodgy
5) the format string could possibly be hit by a garbage collection and lead to strange results

This is now fixed:
1) the format string may now hold double quotes and yield correct results
2) the syntaxis is now PRINT#1,USING "<format>", this also works with the CMD statement
3) regular stringbuffer storage is now used for the output string
4) the dodgy code is removed, so now it truncates (use ROUND() to obtain rounded values)
5) both the formatstring and the resultstring are now protected from garbage collections

This improvement taught me a lot about how strings are handled in the interpreter, and how the improvement should be realised so that it works transparently across garbage collections.

A garbage collection (GC) occurs during FRE(0), and also when top of arrays hits bottom of strings. That is, during creation of any variable or array, or during creation and manipulation of strings (INPUT/READ/GET, concatenation, CHR$, STR$, LEFT$/MID$/RIGHT$). In that sense, a call to $CD9E (formula evaluation) may trigger a GC.
A GC reorganizes all of string space by checking all stringdescriptors that are known through stringvariables (simple or array) or through the descriptorstack (used for temporary strings: a call to $D4CA puts it there, a call to $D6AA removes the top one). The descriptors are updated in the process of a GC.
So, when during processing of stringcontents a call to $CD9E is done (like it is in PRINT USING), relocation of the string that is being processed may happen. And thus lead to corruption. To resolve this, after returning from $CD9E, the address of the strings' contents needs to be re-established by following the descriptor (the descriptor itself is not moved: it is on the descriptor stack or in the stringvariable).

Pseudocode as follows:

Code: Select all

evaluate formatstring
save descriptor on stack when it is a temporary value
save address of descriptor
allocate buffer for resultstring
save descriptor on stack
save address of descriptor
establish adresses of the format and resultstrings from the descriptors
process formatstring
	copy literal characters from formatstring to resultstring
	process control characters in formatstring
		evaluate next numeric expression (*)
		perform STR$() of the result while fixing up numbers between -0.001 and 0.001
			(STR$ puts them in exponential notation, this leads to overflow notation)
		re-establish the addresses of the format- and resultstrings from the descriptors
		fill value following the group of format control characters into the resultstring
get descriptor for resultstring from stack and unpack it
print the resultstring
discard possible descriptor for formatstring from stack
print cr/lf when end-of-command, no cr/lf when semi-colon
otherwise signal format error

(*) may lead to garbage collection that relocates the buffers
Regards,

Wim.