luckybuck Posted December 10, 2016 Share Posted December 10, 2016 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
TXG/MNX Posted December 12, 2016 Share Posted December 12, 2016 A good compiler that doesn't need a runtime would be the best ... 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted December 13, 2016 Share Posted December 13, 2016 (edited) 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 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted December 13, 2016 Author Share Posted December 13, 2016 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. Quote Link to comment Share on other sites More sharing options...
fujidude Posted December 14, 2016 Share Posted December 14, 2016 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). Quote Link to comment Share on other sites More sharing options...
+slx Posted January 9, 2017 Share Posted January 9, 2017 Nice idea, I vote for BASIC XE style PM commands... Quote Link to comment Share on other sites More sharing options...
Alfred Posted October 18, 2017 Share Posted October 18, 2017 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. Quote Link to comment Share on other sites More sharing options...
fujidude Posted October 20, 2017 Share Posted October 20, 2017 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. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted October 20, 2017 Author Share Posted October 20, 2017 https://atariwiki.org/wiki/Wiki.jsp?page=The%20ACTION%20Run%20Time%20Package Quote Link to comment Share on other sites More sharing options...
fujidude Posted October 22, 2017 Share Posted October 22, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted October 22, 2017 Share Posted October 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted October 22, 2017 Share Posted October 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted October 24, 2017 Author Share Posted October 24, 2017 @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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted October 24, 2017 Share Posted October 24, 2017 Action! doesn't natively support floating point, so the FP library is not required unless you are using the routines in it. Quote Link to comment Share on other sites More sharing options...
luckybuck Posted October 24, 2017 Author Share Posted October 24, 2017 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.