Using and improving Exbasic

Mike · Post by **Mike** » Sun Nov 07, 2010 3:26 pm

wimoos wrote:I think I must have built the string from the other end, so an L-I expression was executed unneccesarily 255 times.

Indeed that variant easily "yields" execution times around 190 ticks, or so. OTOH, the speed limiting factor seems to be the overhead of string concatenation and assignment, so you can't expect the routine to become much faster in BASIC (regardless of pure CBM or slightly enhanced but still general string ops in WimBasic). If string reversal was a cricital bottleneck in a program, that was a candidate for a quick translation to ML, doing an in-place operation.

Using Left-MID$ makes it possible to reuse stringspace, thus saving memory and costly garbage collections.

The string routines in CBM BASIC *are* tuned to quick turn-around times. And still quite compact, with little house-keeping necessary in the average case (without GC).

Of course adding a backdescriptor speeds up the GC tremendously with just a small extra memory footprint for each active string (2 bytes). Still, with V2 BASIC you need a least a high 2 figure number of strings for the GC to become easily noticed: in VICtoria Gold for example the fill procedure for the regions in the maps extensively uses data in strings - and stops now and then for 1/2 second in a GC.

If a program needs to handle larger amount of strings, you can always translate those parts to ML, as above. That's what I did with the storage and word-wrap procedures in MG BROWSE. If I had written those routines in BASIC they'd be two orders of magnitude slower, regardless of GC's or not. But string processing in ML is moving data around with no strings attached - much easier to program that in BASIC. And exactly those parts I left in BASIC for the main program of MINIPAINT (preparation of file names for tape/disc access).

Edit:

wimoos wrote:

Code: Select all

40 FORI=0TOL/2:£X=PEEK(£R-I):POKE£R-I,PEEK(£Q+I):POKE£Q+I,£X:NEXT

With an even string length, that FOR loop exchanges the middle two characters twice. The FOR loop should run from 0 to L/2-1 instead.

wimoos · Post by **wimoos** » Sun Jan 16, 2011 9:00 am

As I couldn't resist, I have made some more improvements to WimBasic. Amongst others:

- Joystick support through the USR() function (as discussed in an earlier post of Mike). USR() returns 0, -1, 1, -22, 22, -23, 23, -21, 21, depending on the position of the joystick. Of course, only as long as the USR vector is unchanged. No support for the fire-button here, unfortunately.

- RESUME <linenumber> now checks for the existence of the line, before processing actually resumes.

Regards,

Wim.

wimoos · Post by **wimoos** » Sat Apr 02, 2011 8:10 am

The latest version of WimBasic contains an improved implementation of ON ERROR GOTO and RESUME.
Also, SWAP and VARPTR now support SuperNumbers.
RENUM no longer renumbers references to linenumber 0.

Available now at http://home.kpn.nl/oost4231/wimbasic.zip !

Diddl · Post by **Diddl** » Sat Apr 02, 2011 8:12 am

thanks for WimBASIC!

wimoos · Post by **wimoos** » Fri May 20, 2011 11:25 am

A new version of WimBasic is out now. It contains support for specifying the auxiliary color, to be used in multicolor applications. This is done by adding an optional parameter to the GROUND statement.

Also, some minor fixes were applied. Take a look at http://wimbasic.webs.com for a complete list of all fixes and improvements.
Download the latest version of WimBasic from http://home.kpn.nl/oost4231/wimbasic.zip

Enjoy and regards,

Wim.

Diddl · Post by **Diddl** » Sat May 21, 2011 1:32 pm

Wow, the list of revision details will be longer and longer.

Especially the XOR staement is very useful for me.

Mike · Post by **Mike** » Sat May 21, 2011 2:19 pm

Diddl wrote:Wow, the list of revision details will be longer and longer.

I'd like to see some example programs written with WimBasic, which make substantial use of the new commands, and go beyond trivial applications - like simply showing off what a certain new command could be used for -, instead implement something in the order of a bigger game or tool.

Especially the XOR statement is very useful for me.

C=XOR(A,B) can simply be replaced with C = A AND NOT B OR B AND NOT A. No need to allocate 8K RAM with a BASIC extension for this.

GreyGhost · Post by **GreyGhost** » Sun May 22, 2011 12:17 am

I kinda see it as a toolbox. Most of the time I grab the same tools over and over again, but every now and then I need that special tool to do a specific job. As for memory what is 8k? I haven't seen any program out there max out a fully expanded Vic except maybe Reams of Quest.

Besides, I think Wimoos mentioned before that it was a learning experience for him. So, let the man work and have some fun. That's what it all is now, right?

Mike · Post by **Mike** » Sun May 22, 2011 4:52 am

GreyGhost wrote:I kinda see it as a toolbox. Most of the time I grab the same tools over and over again, but every now and then I need that special tool to do a specific job.

Obviously you then wrote some programs with WimBasic. How about sharing them?

As for memory what is 8k? I haven't seen any program out there max out a fully expanded Vic except maybe Realms of Quest.

fcbpaint-0.5 and MAXIGRAFIK spring to my mind here immediately, and there are surely some other ones released in the last few years which could be added to these two examples.

Besides, I think Wimoos mentioned before that it was a learning experience for him. So, let the man work and have some fun. That's what it all is now, right?

There's nothing wrong about that point of view. But the topic header reads 'Using and improving Exbasic'. Thus far I've only seen improvements of Exbasic (with the occasional 'how to use' example programs shown inbetween), but no real world use of WimBasic itself.

Over the course of one and a half year it should have been possible to write some serious application which makes good use of the tool set presented by WimBasic. Instead, Wim is still tinkering around with the extension itself. Happened to me, too, with a BASIC extension I once wrote for the C128. That one started out with a core set of features, but over one year got extended with lots of bolts. I just thought it was nice to include this command and that command, up to creeping featurism. But no big application was ever written with it.

IMO, the right way was to think about the specific needs of a certain application which mostly could be written in BASIC, save for some time critical parts. Which then might be implemented as commands of a BASIC extension. If the extension then is written with generalisability in mind, that gives a chance to reuse it for other programs.

GreyGhost · Post by **GreyGhost** » Sun May 22, 2011 8:47 am

Nope, I have written one program using Wimbasic, and that was just to play around with it. But, that also isn't where my focus is at the moment. The term "toolbox" refers to any BASIC extension. If what you say is written in stone, then why deviate from the stock BASIC v2.0 in any way. I can probably count on my hands and toes how many programs I have seen for the super expander, and that's been 30 years ago.

I think you are being very critical of the work Wimoos has put into this project. If you don't like it, by all means don't use it. As I said before, it's a labor of love, for all of us here.

Mike · Post by **Mike** » Sun May 22, 2011 9:18 am

GreyGhost wrote:If what you say is written in stone, then why deviate from the stock BASIC v2.0 in any way?

I already mentioned some valid reasons to extend BASIC in an earlier posting in this thread, to rephrase those:

- a sole BASIC implementation of a routine runs too slow to meet requirements,
- the implementation uses lots of BASIC statements: condensing these into a new parametrized command improves readability,
- a faulty and/or inaccurate implementation of a command/function in BASIC is replaced,
- implementation of a function in BASIC is impossible (like interrupt handling, error trapping, keyboard/editor extensions, drive/tape speeders) but desired to be usable from BASIC,
- providing a means to write more structured programs (i.e. including IF ... THEN ... ELSE, loop constructs, procedure calls).

I think you are being very critical of the work Wimoos has put into this project. [...] As I said before, it's a labor of love, for all of us here.

Do you really think I do not appreciate the work involved with such a project? You know, I've got several heavy-weight projects under my hood in the last years as well. As far as criticism is allowed, I'm merely stating facts about how WimBasic has been used to write programs thus far. Whether or not further investment is done in its development is of course at the discretion of Wim himself.

GreyGhost · Post by **GreyGhost** » Sun May 22, 2011 1:47 pm

In any case, Wimoos, keep up the great work and as always I admire and appreciate any and all programming achievements done on my favorite machine.

wimoos · Post by **wimoos** » Tue Dec 05, 2017 4:33 am

No changes to the algorithm, only to memory locations (and useful routine-entries) used. It saved some bytes

Code: Select all

LA8F7	JSR  $DC1B	; round acc#1
		JSR  $DC2B	; determine SGN
		BEQ  LA942	; SQR(0) = 0 , that's easy
		BMI  LA8F4	; <0 is not allowed
		LDA  $61		; get exponent
		PHA			; save it
		AND  #$01      	 
		ORA  #$80      	 
		STA  $61		; normalize exponent [0.5-2.0>
		LDA  #$04		; iterate 4 times
		STA  $0D
		JSR  $DBCA	; acc#1 to Zp $57-$5B
		LDA  #$BC		; float value 1.0
		LDY  #$D9      	 
LA933	JSR  $D867	; add to acc#1
		DEC  $0D		; count iteration
		BEQ  LA921     	 
		DEC  $61		; divide acc#1 by 2
		JSR  $DBC7	; acc#1 to Zp $5C-60
		LDA  #$57		 
		JSR  $DB0F	; divide Zp$57-$5B into acc#1
		LDA  #$5C
		BNE  LA933	; branch always
;
LA921	PLA			; retrieve exponent
		LSR  A		; adjust it
		ADC  #$40      	 
		STA  $61       	 
LA942	RTS 
;
LA8F4	JMP $D248		; ILLQUANT

Denial

Using and improving Exbasic

New version available

Some more improvements

New version

Re: Using and improving Exbasic