Atari Ultimate Basic through crossbreeding?

[luckybuck]

Hi together,

 

Today is a very sad day, because, I could close my investigations regarding the source code of TurboBasic XL. Frank, the author, has left us years ago, his team hasn't anything left, nor his family. The last member of his familiy I found a few weeks ago. Therefore, at this point, we can only reverse engineer the TurboBasic XL code. :-(((

 

Maybe Lorentz can do this once more, like for Star Raiders?

 

Anyway, with the now available codes:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Articles#section-Articles-SourceCode

 

we should be able to build the Atari Ultimate Basic, up to a 64 K cart like SpartaDOS, which uses just 8 K from the best of all versions:

 

 

What do you think?

Edited December 10, 2016 by luckybuck

[TXG/MNX]

A good compiler that doesn't need a runtime would be the best ...

[fujidude]

I would like to point out that the run-time listed for Action! isn't really a run-time like one might think for a BASIC compiler. The Action! run time is merely a collection of prefab functions to take advantage of some of the Atari8 hardware etc. One can use the Action! language to roll their own program from start to finish, and no "run-time" is ever required either by the programmer or the end user. It is just a library of pre-written routines to save the developer the trouble of rolling his own.

Edited December 13, 2016 by fujidude

[luckybuck]

You are both right and I was wrong. It is just an idea, to build a Basic with no wishes left. All in one cart. The Integer Basic (please take a look at the benchmarks) is incredible fast and very close to a compiled Basic version. In Action, I find the scrolling of the whole programm really good, further to read in nearly everything.

[fujidude]

Honestly, from a high level programming perspective, I think anyone would be wise to invest a little in learning Action! or C because the capabilities are so broad and flexible that they approach that of assembly, but with the ease and convenience of a high level language. Obviously, the ultimate in capability and flexibility is assembly, but it's harder to master and use. To me, the one big advantage to BASIC is that it is interpreted. That allows the development cycle to speed up quite a lot compared to edit, recompile, and run. It's also what makes it slow and require an actual run time to be linked with a compiled BASIC (when even available).

[+slx]

Nice idea, I vote for BASIC XE style PM commands...

[Alfred]

I would like to point out that the run-time listed for Action! isn't really a run-time like one might think for a BASIC compiler. The Action! run time is merely a collection of prefab functions to take advantage of some of the Atari8 hardware etc. One can use the Action! language to roll their own program from start to finish, and no "run-time" is ever required either by the programmer or the end user. It is just a library of pre-written routines to save the developer the trouble of rolling his own.

 

That's not entirely true. Multiply/divide as well as parameter copying are among the few cartridge routines which are part of the runtime package that must be present for a standalone executable to execute.

[fujidude]

 

That's not entirely true. Multiply/divide as well as parameter copying are among the few cartridge routines which are part of the runtime package that must be present for a standalone executable to execute.

 

Hmm that doesn't seem right at all. I'm pretty sure the available "run-time" (actually just Action! source code) covers everything and the presence of a cartridge is not required.

 

Can you post a quick code snippet that requires the presence of the cartridge if the run-time is used? I would like to test it out.

[luckybuck]

https://atariwiki.org/wiki/Wiki.jsp?page=The%20ACTION%20Run%20Time%20Package

[fujidude]

https://atariwiki.org/wiki/Wiki.jsp?page=The%20ACTION%20Run%20Time%20Package

 

That's just a bit wide of a scope. Can you site something more specific? It seems to me you might be getting this from section 2.3 of the Run-time Docs (RTD)? If so then yeah, I think I see what you mean. See the following code snippet:

PROC main()
    INT x, y, z
    x = 3
    y = 5
    z = x * y
RETURN

Is what you're saying the compiler is incapable of producing code for the * operand, and instead must directly use pre-fab code built into the cartridge?

Edited October 22, 2017 by fujidude

[Alfred]

I don't know all the cases, but yes, I believe it always requires the runtime multiply/divide routine where at least one of the variables is 16 bits. I'm not sure of the case where both elements are 8 bit, but I expect it is required. MOD function also needs it.

 

SArgsCopy (sp?) is used when there is 4 or more bytes of parameters, say a couple of strings or several words. In those cases Action! embeds the addresses after the JSR to the SArgs copy routine. The copy then fixes up the return address on the stack.

 

Multiplication and division are always treated as signed, so if you are multiplying two numbers and the result is > 32767 you will get an unexpected result. My advice has always been to ignore the built in routines and use your own unsigned multiply code if you need it, cuz Action!'s is not to be trusted.

[Alfred]

See SYSLIB.ACT for the required routines. Left and right shift as well. Also some I/o primitives which you'll need if you use any of the Printxx or Inputxx routines. Also includes the default Error proc.

[luckybuck]

@fujidude: I am so sorry, but I have programmed in ACTION!, just BASIC and Assembler.

 

@Alfred: as far as I know, there is an ACTION! floating point library, too. At least on the Wiki, please check out.

[Alfred]

Action! doesn't natively support floating point, so the FP library is not required unless you are using the routines in it.

[luckybuck]

Yes, sure, that is one reason, why ACTION! is that fast. But for those in the need for, Clinton offered them those libraries. And the idea was out to port this technique to Basic: -> Integer Basic.