Altirra Extended BASIC

[+CharlieChaplin]

I ran a TBXL DOS diskette yesterday that had an autorun.bas file on it, and the autorun.bas file did not autorun...

 

Well, maybe someone (e.g. me) changed that into "Autorun.TBS" or something like that... just take a look...

[flashjazzcat]

 

It's not just about speed, but also how much space and registers a long call takes.

 

ATXBasic's bank mechanism works as follows...

 

Thanks for the explanation. I had to look up 'thunk' (since I'd never heard of the term before), but having done so, I realise I use thunks too.

 

I opted to keep the bank and destination address directly behind the JSR to the 'thunk' since I wanted to pass arguments in all three registers. It is pretty expensive, but by avoiding inter-bank calls in performance-critical situations, it works out well enough. Similar methods are used in the GOS ROM, U1MB/Incognito PBI BIOS (which use 4 x 2KB banks) and the XEX loader (which uses 2 x 8K banks). The advantage of the expensive method is that I don't need to care much whether the JSR macro results in bank traversal or not (the macro picks the appropriate method depending on whether or not the target is in the same bank), although obviously one tries to pre-optimise things by positioning code such that inter-bank jumps are kept to a minimum.

Edited October 22, 2018 by flashjazzcat

[phaeron]

Version 0.11:

• Source code now included.
• Init code fixed to not stomp on program vars after a warm reset.
• Numeric parser fixed to no longer accept "." as a valid number and to allow lowercase 'e' for exponents.
• Fixed an issue with LIST misadjusting indent after some IF statements.
• END. is now accepted as ENDIF.
• Long error messages for errors 14 and 15 were swapped.
• %GET and %PUT short forms are now allowed.
• List mode is now activated when reporting syntax errors.
• Underscores are allowed in variable names to match TBXL.
• Letters after %0-%3 no longer cause syntax errors.
• Secondary keywords in ON..GOTO and FOR..STEP can be typed in lowercase.

 

atxbasic-0.11.zip

[phaeron]

Version 0.12:

• EXP() wasn't reliably underflowing to 0.
• CLR no longer breaks labels and procedures when used in deferred mode.
• POINT now takes aexprs instead of avars (TBXL extension).
• Built-in help expanded significantly.
• Help can now be accessed with the Help button on OSes that support it.

Have to point out that the Help button is a PITA to hook the way that the XL/XE OS supports it, since the regular K: handler doesn't know anything about it.

 

atxbasic-0.12.zip

[+MrFish]

Nice online help system.

[phaeron]

Version 0.13:

 

• Division routine rewritten with faster algorithm.
• Minor optimization to inner execution loop.
• Fixed bug in power operator (^) with certain integer factors.
• Fixed DEG/RAD setting not being reset on RUN.

 

atxbasic-0.13.zip

[+Larry]

Wow! Even beats TBXL with Ahl's Benchmark. 36.6 sec vs 41.3 (and 405.3 for Atari Basic Rev C for a default).

[+Larry]

I think there is an issue with the way that error lines are handled. If I create a line that has a syntax error in Atari Basic or TBXL, then LIST the program, the lines are shown starting with (lineno) ERROR... In ATX these error lines just disappear.

[phaeron]

I never bothered implementing the code to encode syntax errors into the program from the parser -- didn't seem worth the effort.

[+Larry]

Understand, but if you are trying to debug a line with an error, it is useful. For instance, if the solution is to split the one into two lines, it is handy to create two identical (error) lines, then edit both lines to eliminate the error. But there are certainly work-arounds if it is a big deal to add it.

[_The Doctor__]

the line with the error should stay, when executed it should grind to a halt or dump out and so error in line so and so... I absolutely hated word error being stuck in my code and pushing the rest of the line past the truncation mark...

 

if it tells me error in line 10 I can look at ten and figure it out.

 

I someone wanted to make an error parsing utility separate from the interpreter that would be better I would rather the interpreter remain lean mean clean and fast

[flashjazzcat]

Just tried it and yes: it seems rather odd that the erroneous line is completely jettisoned, although that may simply be down to the fact that we're used to the Atari BASIC and TBXL behaviour. Not a problem for single lines since you can just edit it while it's still on screen (if you lose it, it's going to be an inconvenience typing it in again from scratch), but I can see this being a bit disconcerting if you happen to ENTER from disk a listed program which contains errors or minor syntax incompatibilities, only to find all the offending lines have completely vanished.

[+Larry]

@FJC

In one of his INSIGHT ATARI columns, Bill Wilkinson went through a somewhat similar scenario in his description of Atari Basic immediate syntax checking vs runtime checking in others (like MSB, IIRC). His scenario was that an obscure non-executed line was sent out in a commercial program, and then (somehow) the user executed that line and BINGO. I looked this AM through his Insight columns, but couldn't find the article with about a half-hour of searching, so I gave up. I know it is not quite the same as what you were mentioning, but it is along a similar vein.

 

If anyone has not read Bill's columns, they are still certainly educational and interesting, even though thirty some years have passed. You'll have to look around the web since they do not appear to be at Atarimania, but they are out there.

[Kyle22]

Would it be easy enough to simply display the line number in inverse video so it can be easily seen as the error line in the listing?

[+MrFish]

If anyone has not read Bill's columns, they are still certainly educational and interesting, even though thirty some years have passed. You'll have to look around the web since they do not appear to be at Atarimania, but they are out there.

 

Here's an index of his articles at AtariMagazines.com: Compute - Insight Atari

Edited November 26, 2018 by MrFish

[pirx]

phaeron rulz again with his beautiful code, it is so cool that I am pushing it now to my kindle and will read it instead of boooooring 12 rules for life and the brothers karamazov )))))))))))))

i love you avery.

 

of course my tbxl proggies fail due to hardcoded memory usage, but of course i'll fix this. flappy 10 liner of mine might have problems 'coz atx has a tad less fre(e) mem than tbxl, not much but still.

Edited November 26, 2018 by pirx

[phaeron]

Version 0.14:

• Modified multiply, divide, and square root algorithms for better performance.
• Fixed bug with division throwing range errors for values >1E+49.
• Fixed a bug that could cause corruption of the running program when RUN statement was executed from deferred mode to restart the program.

 

atxbasic-0.14.zip

[+CharlieChaplin]

Well,

here are some TB XL programs (mostly games, but also some applications and utilities) for testing with AXB. The images 1-16 do contain TB XL and a short menu which shows *.TUR files (maybe rename the files and then change the menu to show the files with extender .AXB or .AEB and load them with Altirra Extended Basic instead). The images 17 and 18 are somewhat chaotic, do have no menu and have been copied from various Happy Computer magazines (where TB XL was originally published). It is possible that some programs on image 17 or 18 require other programs to work (and these other programs are not on the same image, ahem)...

 

 

TBXL_Pgms.zip

[phaeron]

10 hours ago, CharlieChaplin said:

Well,

here are some TB XL programs (mostly games, but also some applications and utilities) for testing with AXB. The images 1-16 do contain TB XL and a short menu which shows *.TUR files (maybe rename the files and then change the menu to show the files with extender .AXB or .AEB and load them with Altirra Extended Basic instead). The images 17 and 18 are somewhat chaotic, do have no menu and have been copied from various Happy Computer magazines (where TB XL was originally published). It is possible that some programs on image 17 or 18 require other programs to work (and these other programs are not on the same image, ahem)...

Hey thanks, that's quite a collection. Some of those games are really good. I went through all the games at least and fixed the issues that I could.

 

Update:atxbasic-0.15.zip

• Implemented TBXL-specific INPUT form taking a prompt (INPUT "prompt";A$).
• Fixed an off-by-one in CIRCLE, depending on the OS in use.
• Fixed bugs with PAINT sometimes leaking on the right side, not filling one pixel below the seed point, and not doing INTERNAL conversion for character modes. Quite a number of programs failing were due to PAINT issues.
• Fixed a crash in the TIME$= statement.

Couldn't get these programs working:

• Incompatible due to $A000-BFFF address conflict: ATDRIVE.TUR, GRYZZLES,TUR, WOORLY.TUR, CITY.TUR, KNUFFEL.TUR, EA.TUR, MERKUR.TUR, PAINT256.TUR, UNTERLAE.TUR
• JEWELS.TUR and TRON.TUR can't run with DOS 2 loaded because they're too tight on memory.
• PINGPONG.TUR fails to load with an out of memory error because of a corrupted VNTD offset in the header, which causes AEB to think that the program is too big to fit.

The memory conflict issue is annoying, there's no good way to deal with this because the screen memory's at the top. Can't escape it by disabling the cart because there'd be no way to bank it back in without overlaying screen memory. The cartridge port also can't map outside of $8000-BFFF or $D500-D5FF... really wish that carts or extended memory could map to $2000-3FFF, would be so much nicer for this.

 

[+Philsan]

A compiler to run the programs without cart would be nice.

[billkendrick]

H/t to Steve Boswell for sharing this thread on Twitter today. I somehow missed this, and it's right up my alley! Looking forward to toying with it, and perhaps using for my next set of BASIC 10-Liners

[Steve Mynott]

Minor feature request. It would useful if typing "help" entered the help system.

 

D'uh ignore that I missed %H 

Edited June 29, 2019 by Steve Mynott

[+DrVenkman]

I haven't spent much time coding in the last, oh, 3 decades or so, but it's wonderful to see this version of BASIC being maintained and improved by the one singular living person who probably knows best how the Atari hardware and software works and cooperates together.

 

In a FB discussion with some friends recently we were discussing mathematical implementations for numerical modeling (*) and happened to run across a support article from Apple briefly discussing how they have moved the calculation engine for their Numbers spreadsheet to a 128-bit base. That got me wondering how well my various calculator apps, programs and old computers would be able to calculate the simple expression "2^128", and how many decimal places out the scientific notation the errors would creep in. 

 

The current version of Excel expresses the result (to 11 decimal places) as 3.40282366921E+38, which is the same result provided by my HP-48G and my iOS HP emulators. (**)

 

Atari BASIC, using the built in FP package gets bitten by rounding errors:

 

 

Altirra BASIC version 1.5 and BASIC XE seems to also rely on the same built-in FP package, or at least one with the same inaccuracies with large numbers:

 

 

Altirra Extended BASIC has a markedly more accurate result. Still not objectively "correct", but a couple decimal places closer. 

 

 

I don't expect anyone is coding astronomical, cosmological or subatomic problems via numerical modeling on our 8-bits, but it's always nice to see increased accuracy in the math when possible. 

 

ALSO: I probably should break down and start playing with Altirra Extended BASIC some more - looks like it's already great, on its way to pretty spectacular.  

 

(*) I last coded some orbital mechanics simulations as an undergrad studying aerospace engineering around 1988 or 1989. I coded in OSS Personal Pascal on my 1040ST because ST BASIC sucked ass and gave me terribly inaccurate results.

 

(**) The actual value, expressed as a number, is big. I mean, really freaking big: 340,282,366,920,938,000,000,000,000,000,000,000,000  ? 

[billkendrick]

I'm going through the doc PDF and it's excellent! (I've been wanting to try and go through and make a nice English doc for TurboBASIC XL; seems I don't need to!)

 

I love that you've called out which keywords are from BASICs beyond Atari BASIC (e.g., "(AEB, TBLX)")

 

I'd like to suggest you do that for some of the other concepts covered, e.g. hexadecimal aexp's, %0...%3, etc.

 

Thanks for your consideration, and amazing work. I look forward to playing with it! (I'll try it on my Ultimate SD Cart tonight, if I have time.)

[billkendrick]

Does AEB support bare "NEXT"s (no avar), like I recall TBXL supporting? (The docs don't show the avar being optional)