U-BASIC

[dmsc]

Hi!

 

There is a new version (1.8 ) available for download at my website, in case anyone is interested.

Tried to run UBI from BWDOS, it exits with the error "SpartaDOS must be v. >= 4". I suspect that the test is wrong, as it should work over BWDOS.

 

See attached ATR with BWDOS and the extracted UBI18.ARC.

ubi18.atr

[Roydea6]

For me it says ram under rom must be present.. Using your atr and AtariWin plus emulator.

[dmsc]

Hi again

 

Also, tried your basic in altirra, with this "floating-point speed test":

 

10 A=0.7071067811
11 B=0.0717243034
12 POKE 20,0:POKE 19,0
20 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
21 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
22 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
23 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
24 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
25 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
26 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
27 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
28 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
29 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
30 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
31 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
32 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
33 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
34 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
35 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
36 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
37 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
38 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
39 C=A*B+B*A+A*A*B+B*B*A+A*A+B*B+A*A*A+B*B*B
40 T=PEEK(19):Q=PEEK(20):IF T<>PEEK(19) THEN GOTO 30
41 ? T*256+Q,C

It performs 12*20=240 multiplications and 7*20=140 additions, then prints the elapsed time (in jiffies) and the result, that should be "1" (or 1.000000000042236228140376931065 with full precision)

 

The results are:

 

altirra basic + altirra OS : 50     1.0000000000
tbxl 1.5      + altirra OS : 43     0.9999999996
atari basic C + altirra OS : 66     1.0000000000
U-BASIC       + altirra OS : 67     0.9999999996  (shown as 0.999999999)

altirra basic + atari OS   : 119    0.9999999996
tbxl 1.5      + atari OS   : 44     0.9999999996  (4e-10)
atari basic C + atari OS   : 162    0.9999999996  (shown as 0.999999999)
U-BASIC       + atari OS   : 67     0.9999999996  (shown as 0.999999999)

As you see, it seems that the altirra floating point package is faster than the FASTFP package that you are using, and also is more accurate. As it is compatible with the OS math package, and the full source is included (under GPL license, see the file src/Kernel/source/Shared/mathpack.s in the altirra source ZIP), you could replace the math package with that.

[flashjazzcat]

It says both:

 

 

BeweDOS has the same signature as SpartaDOS ($53 at $700) but adds "BW" at $703. Poking $700 with zero before launching UBI.EXE is a temporary workaround.

Edited December 6, 2016 by flashjazzcat

[drac030]

Uhm, I forgot about the BW-DOS, my fault. Also it seems that a string lacks termination. Both things should be easily fixable.

 

As about the Altirra FP, I would like to avoid troubling myself with such things as GPL. If you want to use U-BASIC with Altirra FP, just load it under Altirra OS and set FASTFP=0 in UBI.CFG.

Edited December 6, 2016 by drac030

[dmsc]

Hi!,

 

Uhm, I forgot about the BW-DOS, my fault. Also it seems that a string lacks termination. Both things should be easily fixable.

 

As about the Altirra FP, I would like to avoid troubling myself with such things as GPL.

I respect your decision, but IMHO that is a shame , as the GPL is designed to just *encourage* contributions and reuse of the source, as you guarantee that anyone that uses your code and improves it will also make it available.

 

If you want to use U-BASIC with Altirra FP, just load it under Altirra OS and set FASTFP=0 in UBI.CFG.

Well, the main improvement in the multiplication routine is a different algorithm, using binary arithmetic, similar to the one used in TurboBasic XL but not unrolled, perhaps you could reimplement it from the description:

 

- Given "M1" and "M2" the numbers to multiply,

- Set to 0 the result [ R = 0 ]

- For each bit "b" (0 to 7) in a byte [ b = 2^j , j=0..7]:

-- For each byte "B" in "M1" [ B = (M1 * 100^i) % 100 , i=0..5]:

--- If bit "b" of "B" is "1", add "M2" to the result, shifted by the position of "B" [ if ( B&b != 0 ) R = R + (M2 * 100^i) ]

-- Duplicate "M2", by adding it to itself [ M2 = 2 * M2 ]

- Now, we have the final result, do normalization and return.

 

This is a standard binary multiplication algorithm, but with a loop over "bytes" to avoid doing a duplication on each iteration.

 

In TurboBasicXL, the values "M2", "2*M2", "4*M2"... are pre-calculated with an unrolled loop and stored in a table, so the inner loops are a lot faster.

[phaeron]

I respect your decision, but IMHO that is a shame , as the GPL is designed to just *encourage* contributions and reuse of the source, as you guarantee that anyone that uses your code and improves it will also make it available.

 

FYI, as of the latest test releases and for all future releases, the internal firmware is under a simple permissive license:

;	Altirra - Atari 800/800XL/5200 emulator
;	Modular Kernel ROM - Decimal Floating-Point Math Pack
;	Copyright (C) 2008-2016 Avery Lee
;
;	Copying and distribution of this file, with or without modification,
;	are permitted in any medium without royalty provided the copyright
;	notice and this notice are preserved.  This file is offered as-is,
;	without any warranty.

That having been said, I just found out that I accidentally introduced an overflow checking regression into FDIV at tip that I need to fix.

 

Two caveats about the AltirraOS math pack. First, there's a long standing minor incompatibility in FASC that I haven't gotten around to fixing, namely that 10^-3 prints as 1E-03 instead of 1.0E-03. Second, last time I benchmarked it against the Marslett math pack, it was faster at multiplication but slower at division.

[drac030]

I have uploaded U-BASIC v.1.8.1 to my website. The interpreter itself is identical as in 1.8, the only fixes have been made to the startup code, which should fix the problem with BW-DOS. I checked it at home, it appears to work with BW-DOS now.

 

I also have added new function to the UBI.CFG file parser: you can now give it FASTFP=D:FNAME.EXT. The "D:FNAME.EXT" file will get loaded at startup and placed in the memory instead of the default (Marslett's) Floating Point package. It has to be a simple, 2k raw dump of an FPP package, to be placed at $d800-$dfff.

 

@dmsc: I also find your ATR file (ubi18.atr) very interesting. How did you produce it?

 

EDIT: I ran the test from post #28 in U-BASIC running with the "precompiler" active and the results are as follows:

 

Altirra FP: 50 1

Marslett's FP: 52 0.999999999

Edited December 8, 2016 by drac030

[dmsc]

Hi!,

 

I have uploaded U-BASIC v.1.8.1 to my website. The interpreter itself is identical as in 1.8, the only fixes have been made to the startup code, which should fix the problem with BW-DOS. I checked it at home, it appears to work with BW-DOS now.

 

I also have added new function to the UBI.CFG file parser: you can now give it FASTFP=D:FNAME.EXT. The "D:FNAME.EXT" file will get loaded at startup and placed in the memory instead of the default (Marslett's) Floating Point package. It has to be a simple, 2k raw dump of an FPP package, to be placed at $d800-$dfff.

Good!, attached is a ZIP file with the Altirra mathpack sources, a simple file that includes the source with the proper equates and the resulting ".bin". To compile, use MADS with:

 

mads -o:fp-alt.bin compile-mathpack.s

The "mathpack.s" file is from Altirra sources, in file "src/Kernel/source/Shared/mathpack.s".

 

 

@dmsc: I also find your ATR file (ubi18.atr) very interesting. How did you produce it?

I used my "mkatr" program, at https://github.com/dmsc/mkatrwith the following procedure:

 

 mkdir ubi
 cd ubi
 wget http://drac030.krap.pl/ubi181.arc
 mkdir atr
 cd atr
 arc x ../ubi181.arc 
 mkdir FASTFP
 cd FASTFP
 arc x ../FASTFP.ARC 
 cd ..
 rm FASTFP.ARC 
 mkdir DOS
 cp /path/to/bwdos/XBW130.DOS DOS/
 cd ..
 mkatr ubi181.atr atr/DOS/ -b atr/DOS/XBW130.DOS atr/FASTFP/ atr/*.* atr/FASTFP/*

You could also produce a DOS-less, booteable atr with your program with:

mkatr  ubi-only.atr -b atr/UBI.EXE

If you also add a "-x" option, the image will be smaller, with no free space.

 

 

EDIT: I ran the test from post #28 in U-BASIC running with the "precompiler" active and the results are as follows:

 

Altirra FP: 50 1

Marslett's FP: 52 0.999999999

So, with the precompiler is as fast as altirra-basic! Good work.

altirra-mathpack.zip

ubi181.atr

Edited December 9, 2016 by dmsc

[_The Doctor__]

Is ubi181.atr in the dmsc post the latest greatest? Is fp a part of it? will it be part of the sparta toolkit?

 

just want to know before I start mucking about with it again...

[Kyle22]

Does a math pack that uses 816 code exist? Would it be faster than the other math packs?

[drac030]

It looks like loading the external FP package only worked in SpartaDOS X. So, version 1.8.2 on my website now.

 

@_The Doctor_: U-BASIC will not be a parto of the SDX Toolkit, it is a separate application program which does not belong to a class of DOS utilities (IMHO).

 

@Kyle22: MultiBASIC contains a 65C816 version of the Marslett's FP package. It is somewhat faster than the original, but not as greatly as you could expect.

 

@dmsc: I do not know if the differences are to the U-BASIC being now faster or just to the 50/60 Hz difference between our setups.

 

As for the mkatr program: it looks convenient really, but the file system produced by it is not completely correct.

 

1) the main directory is located not at the beginning of the disk, but somewhere in later sectors. On your atr it is sector 566 ($0236).

 

It is true that the documentation does not stipulate where the main directory should be located, but in practice there is a de-facto standard of putting it directly behind the bitmap. SDX and tools like CLX even rely on that, as a sort of filesystem sanity-check.

 

It is of course disputable if this sanity check is sane in itself but for the time being your atr is not writable by SpartaDOS X (error 181)

 

2) the atr features actual sizes indicated in the subdirectory entries located in the parent directory. This is why CLX complains about them as being invalid directory entries, because it assumes that such an entry can contain only 0 or 23 in that field. It is again a sort of sanity-check.

 

Since the documentation (IIRC) does not define this value, it can in fact be anything. I will fix it in the CLX so that it will check if the size is dividable by 23, so that it will not complain. For the time being, however, it does

 

3) when I disabled the sanity check #1 in SPARTA.SYS, the atr became writable from SpartaDOS X, but a write has destroyed the bootloader. To make the disk botable again I had to install the SDX bootloader (CLX /B) and do BOOT DOS>XBW130.DOS.

 

There is apparently a conflict between the bootloader installed by the mkatr and the method the SDX is treating the first 64 bytes (IIRC) of the sector 1.

[dmsc]

Hi!

 

@dmsc: I do not know if the differences are to the U-BASIC being now faster or just to the 50/60 Hz difference between our setups.

 

As for the mkatr program: it looks convenient really, but the file system produced by it is not completely correct.

 

1) the main directory is located not at the beginning of the disk, but somewhere in later sectors. On your atr it is sector 566 ($0236).

 

It is true that the documentation does not stipulate where the main directory should be located, but in practice there is a de-facto standard of putting it directly behind the bitmap. SDX and tools like CLX even rely on that, as a sort of filesystem sanity-check.

 

It is of course disputable if this sanity check is sane in itself but for the time being your atr is not writable by SpartaDOS X (error 181)

I followed the FS description in the manual, so I placed the main directory as the last file in the disk, as that makes the code simpler. I could change the code to put the main directory at the start, I suppose that what need to be on the start is the start of the sector map.

 

2) the atr features actual sizes indicated in the subdirectory entries located in the parent directory. This is why CLX complains about them as being invalid directory entries, because it assumes that such an entry can contain only 0 or 23 in that field. It is again a sort of sanity-check.

 

Since the documentation (IIRC) does not define this value, it can in fact be anything. I will fix it in the CLX so that it will check if the size is dividable by 23, so that it will not complain. For the time being, however, it does

I can modify my program to put a '23' or '0' as the size, but I'm intrigued, why the size is not updated? My code treats directories as normal files, I tough that SpartaDOS-X did the same.

 

3) when I disabled the sanity check #1 in SPARTA.SYS, the atr became writable from SpartaDOS X, but a write has destroyed the bootloader. To make the disk botable again I had to install the SDX bootloader (CLX /B) and do BOOT DOS>XBW130.DOS.

 

There is apparently a conflict between the bootloader installed by the mkatr and the method the SDX is treating the first 64 bytes (IIRC) of the sector 1.

I wrote that bootloader, see he sources at https://github.com/dmsc/mkatr/blob/master/src/asm/boot128.asmand https://github.com/dmsc/mkatr/blob/master/src/asm/boot256.asm

 

It different from the SpartaDOS-X and BWDOS ones, as tries to be more compatible with any binary file, as it jumps to the first load address if RUNAD is not writen and supports files of any size.

 

The bootloader starts at address $30 of the first sector, I followed the description in SpartaDOS-X and BWDOS manuals, both describe addresses up to 40 and 42, so should be no problem

 

Do you know which addresses are overwritten by SpartaDOS-X, and more to the point, why it overwrites sector 1?

[drac030]

Yes, the formatters usually put the bitmap directly after the boot region, the beginning of the main directory sector map after the bitmap, and the 1st sector of the directory directly after that.

 

As I am thinking about it, I will probably disable this sanity check in SPARTA.SYS for good. The reason is that I think I know the reason why it has been put there in the first place: they (ICD) had an undetected bug in the sector caching code which sometimes led to disk corruption. Now I believe that bug has been fixed, so perhaps there is no need to keep this sanity check there...

 

The size of the directory entry is not updated probably to make the code simpler and shorter. The actual directory size information is anyway kept in its header, so duplicating this info in the parent directory entry does not seem necessary.

 

As for the bootloader question, this needs investigation, I did not yet have time to look at it more closely.

Edited December 13, 2016 by drac030

[_The Doctor__]

hmmm I hope for Drac to take a leap towars making for us special uFbasic..... micro fast basic! fixed in the same way turbobasic and others did with appropriate use of integer vs floating for certain functions.... optimized Atari basic at the speed it should have been in the first place....

 

you've gone this far, it would be awesome to see it go all the way!

[drac030]

Uhm, how to put it

 

I am not developing another Turbo-BASIC XL. We already have one. The U-BASIC, even if it is not as fast, offers more memory, and this may prove advantageous to some people. E.g. if there is a BASIC program so large or so memory wanting that it could be only run from tape (i.e. without DOS), U-BASIC allows to run it under a DOS.

[_The Doctor__]

How cool would it be to have both worlds in one? I know you are most skilled from all the works you have accomplished so far. May I wish upon a star anyway?

[drac030]

I do have some plans regarding further development, so we will see.

 

Definitely it is very difficult to have both TBXL speed and U-BASIC memory buffer. But, since the U-BASIC has allowed to load external FP packages, anyone can separately develop a superfast mathpack (e.g. using 130XE ext RAM or 65C816 high RAM to store all the unrolled loops and stuff).

[Ray Gillman]

On 7/23/2015 at 8:54 AM, drac030 said:

Last Sunday I did the following:

 

1) grabbed the source code of the Atari BASIC rev. C

 

2) split it in two blocks, reassembled everything for addresses $C000-$CBFF and $E400-F7FF

 

3) added the so called FASTCHIP, the fast FP package written by Charles Marslett

 

4) wrote a bit (around 1k) of wrappers and initializing code

 

Since Sunday I also sat at it twice or thrice to do some debugging.

 

And here it is: http://drac030.krap.pl/en-ub-pliki.php

 

U-BASIC, i.e. the plain vanilla Atari BASIC, but prepared to run under the OS ROM. As a result, it gives about 8k more memory for programs than the standard one. Like here under SDX:

 

 

or here under MyDOS:

 

 

For comparison, here is the standard Atari BASIC under the same MyDOS:

 

 

U-BASIC is also a bit faster thanks to the fast FP package mentioned above.

 

Occupies 109 bytes in the main memory (always directly over the memlo). Appears to work.

 

I like how you got 43K free there please explain how this was accomplished.  As you can see I tried to duplicate this but only realize a very modest gain to 35K instead of 32K

 

It's still nice and must be possible to get more this was using SDX448

 

 

[Ray Gillman]

Yes I do get the same 39K under MyDos 4.53 - but how do you load Sparta to get even more?  Kudos on getting some added commands in there like the DIR command I like!
Dare to dream big.  How much more executable space is possible do you think?  Imagine 50K or more OR why not bank switched 100's of K workspace?
 

Edited November 13, 2019 by Ray Gillman

[Faicuai]

20 minutes ago, Ray Gillman said:

Yes I do get the same 39K under MyDos 4.53 - but how do you load Sparta to get even more?  Kudos on getting some added commands in there like the DIR command I like!
Dare to dream big.  How much more executable space is possible do you think?  Imagine 50K or more OR why not bank switched 100's of K workspace?
 

 

U-Basic is getting all that RAM, because it is using RAM-under-OS on XL memory map (most-likely $E000-$FFFF, or maybe a fragmented  allocation, like $C000-$CFFF and $E000-EFFF, for instance). This, in turns, frees up most of the nominal $A000-$BFFF window that BasicC-rom normally occupies, which is where most of the boost in free-RAM is coming from.

 

On the other hand, MyDos will never match SDX's memory management, because once SDX is configured with "BANKED" option, it will attempt to allocate extended-memory space for as any drivers and components as it can, thus reducing the bottom of memory footprint to as low as $0EFE, which is not possible in any DOS functionally comparable to SDX (teenie-weenie toy-like DOSes do not really count, as they are just one-way street solutions).

 

And one interesting example (which tops everything else) is Basic-XE, which once its extensions are loaded into ram, and once "extend" command is issued, it will map and use XE entended RAM banks as well, thus giving almost 100K of RAM back to the user, which is not bad at all, for being a Basic package.

 

Edited November 13, 2019 by Faicuai

[Ray Gillman]

I can't get the emulated XE to extend.  You can see it's loading and thinks it's extending but no FRE(0) ram
Second image is the dir of D1: can see the extensions disk is inserted even

[Faicuai]

1 hour ago, Ray Gillman said:

I can't get the emulated XE to extend.  You can see it's loading and thinks it's extending but no FRE(0) ram
Second image is the dir of D1: can see the extensions disk is inserted even

 

It is FRE(0) and FRE(1).

 

Your session shows successfully extended, already,

[Ray Gillman]

OK I got it so this is really 97544 free program space - 65K+32K wow that is a ton 

 

Edited November 14, 2019 by Ray Gillman

[drac030]

I have found a very bad bug in U-BASIC 1.8.3: memory corruption, when the user, entering a program, made a syntax error. I guess I must hardly ever make typing mistakes then, because I use U-BASIC very often as a handy script interpreter, and until yesterday I had never stumbled upon this.

 

Anyway, new version (with this bug fixed) is on my website.

Edited November 2, 2020 by drac030