Jump to content
dmsc

TurboBasic XL v1.5 MADS source (disassembly)

Recommended Posts

Hi!,

As promised, here is my own disassembly of TurboBasic XL v1.5 (the original published one).

Assembling with MADS should generate the same binary as the original (byte for byte), if not, it is a bug and should be fixed.

Many labels are still in the original "LXXXX" form, but should be self explanatory from the assembly source, all labels for statement and function execution are of the form "X_", all labels for the syntax tables are "LS*", the corresponding syntax codes are "_S*". Where it made sense, I used the labels from AtariBasic sources, but probably better names and more consistency for many labels is needed, as I only worked in this sporadically over a long time.

Hope it's useful to interested people :)

EDITED: Current version of the disassembled sources is at https://github.com/dmsc/turbo-dis Edited by dmsc

Share this post


Link to post
Share on other sites
Hi!,
 

What tool was this disassembled with?


Initially, (I don't remember exactly), but I suppose dis6502. Then, manually edited over time.

Share this post


Link to post
Share on other sites

Amazing. Would have guessed the code ist much more than "just" 9000 lines.

Share this post


Link to post
Share on other sites

If we want to make changes or editions to Turbo Basic, we will need to make  changes to the compiler/run time. Is there source code for those as well?

Share this post


Link to post
Share on other sites

If we want to make changes or editions to Turbo Basic, we will need to make  changes to the compiler/run time. Is there source code for those as well?

I sure hope so...

Share this post


Link to post
Share on other sites

this is not THAT important for 10 liners community - these gems do not get compiled anyway. And seeing Turbo Basic cross compiler from mgr inż. Rafał I am positive we could get away without updated native compiler. What we need is fixed point arithmetic that would speed up these little games tremendously.

Share this post


Link to post
Share on other sites

Looking at the released 2.0 and disassembled 1.5, they are almost identical. I hacked the fix back into FOR and replicated the command to go into DOS. I also applied my optimization to 1.5 that indents when you LIST your program, saved about 4 bytes. It consolidated a JSR-RTS that was only called once. Better Labeling these sources will help tell us what is going on before trying to optimize and upgrade Turbo Basic.

 

I forgot to ask. Is Lomem is MyDOS lower than AtariDOS? I noticed before $2080, there are several pages of empty space. Seems like DOS ends several pages before the start of TurboBasic. Wonder if we can move everything back a few pages.

Edited by peteym5

Share this post


Link to post
Share on other sites

this is not THAT important for 10 liners community - these gems do not get compiled anyway. And seeing Turbo Basic cross compiler from mgr inż. Rafał I am positive we could get away without updated native compiler. What we need is fixed point arithmetic that would speed up these little games tremendously.

Can you post the link to this Turbo Basic Cross Compiler?

Share this post


Link to post
Share on other sites

I forgot to ask. Is Lomem is MyDOS lower than AtariDOS? I noticed before $2080, there are several pages of empty space. Seems like DOS ends several pages before the start of TurboBasic. Wonder if we can move everything back a few pages.


DOS 2.0     0x1501
MyDOS 4.50  0x1BE9
No it is not lower. The value is found at 0x070C in both AtariDOSes.
AtariDOS is typically used to denote the filesystem is of the
order of DOS 2.0 with center of disk VTOC and directory, file
numbers and link to next sector within each sector of all files
stored. With some variability within those general guidelines.

It's also used to denote the glaring difference between that
file storage system and the SpartaDOS file system method.
Take away is that MyDOS is an AtariDOS.

Moving right up against memlo is not a good idea since AtariDOS
can have it's default 3 open files count increased which moves
memlo up and the code that does that is variably buggy between
AtariDOSes. Some insist on using 256 byte buffers and others
prefer 128 byte buffers. Several pages of distance should be
left alone perhaps?

Share this post


Link to post
Share on other sites

I will leave that alone then. I put the Turbo Basic aside for now. If someone does want to go through, optimize, and label what does what better, that would be a good start. I only was able to apply one optimization with the code that controls how far the listing is indented when you type list. I am very sure other sections can be downsized also, just be careful and test everything you do with a test program. Slightly changing something can make your undated TurboBasic XL not be able to run basic code.

Share this post


Link to post
Share on other sites

I spent some time re-labeling stuff this morning. I re-labeled the "MATH PACK temporary variables" instead of those Lxxxx stuff.

 

I also figured out why v.2.0 had less memory available. Its low address was $2280 instead of $2080. I moved it back.

Share this post


Link to post
Share on other sites
Hi!
 

I spent some time re-labeling stuff this morning. I re-labeled the "MATH PACK temporary variables" instead of those Lxxxx stuff.


Thanks!

Some remarks:
- At line 4158, this is "Floating Point ASSIGNMENT" (as "setting the value of a floating point variable"), not "SIGN" as your remark says.
- You changed the label "VAR_PTR" to "CALC_VARTAB", I'm not sure the new name is better, as this routine gets a pointer to the variable (or array location) data, to read/store it's value.
- I see that you changed some of the "X_RTS" (do-nothing statements/functions) to the proper name, but you did not follow my "X_" convention for "execute statement/function" code.
- In the same, you added a label "GO_MARKE", but this is really the "#" statement, I labeled the "GO#" statement as "X_GO_S" (thinking on "Sharp" symbol), this should be "X_SHARP" or "X_LABEL".
- In the comments, "MATHPACK" *is* the 6502 floating point math package.
 

I also figured out why v.2.0 had less memory available. Its low address was $2280 instead of $2080. I moved it back.


Yes, that was the main modification in that source, probably to make it compatible with some other DOS.

Share this post


Link to post
Share on other sites

As you know, this is a work is a work in progress and I can change it back to your "X_" execute convention. I want to get a better understanding what does what before doing any advance optimization, but it looks like most of the floating point math sections should remain as is. At most I would probably would open up no more than a few hundred bytes anyway. I noticed there is a lot of JSR calling a JSR, then a 3rd JSR. One thing I do with my games and programs is if the JSR is only called once, copy and past the routine in place of the JSR and eliminate the RTS. Saves space and CPU cycles.

 

TB 2.0 appeared to be able to work with a mini disk utility program (DUP) but I could not figure out what advantage that would had. Some DOS functions are available in Turbo Basic. To do advance DOS functions, its better to be in DOS anyway.

 

I know a few want to include PM graphic functions, extended memory storage, string arrays. I personally want to add "ELSEIF" instead of "ELSE:IF" + extra "ENDIF" for each one. 

 

Here is what I changed the labels to so far.  I changed CALC_VARTAB to CALC_VARIABLE_POINTER.  Also in the Token Areas, I added a little comment to what the token values are. Not sure about function token values yet.

Edited by peteym5

Share this post


Link to post
Share on other sites

I think it would be quite interesting if people start rewriting this in a domain driven manner. For example, someone needs a version which has extra capabilities with file processing, but decides to rip out things like the 'locate' command which they may never use.

Share this post


Link to post
Share on other sites
Hi,

I went through the disassembled code during this weekend, and added a lot of labels and conditionals to fix two minor bugs, the resulting file is attached.

To compile and generate the exact tb15 binary, use:
mads turbo-mads.asm -l:turbo-mads.lst -o:tb15.com
To compile with the two bugs fixed, use:
mads -d:tb_fixes turbo-mads.asm -l:turbo-mads.lst -o:tb15.com

Share this post


Link to post
Share on other sites

What were the two bugs? I am tried to see if I can do any further optimizations, but there are large sections of the interpreter geared toward the BCD floating point. I am very sure I do not want to mess with those sections.

Share this post


Link to post
Share on other sites
Hi!,
 

peteym5, on 13 Jun 2017 - 3:32 PM, said:
What were the two bugs? I am tried to see if I can do any further optimizations, but there are large sections of the interpreter geared toward the BCD floating point. I am very sure I do not want to mess with those sections.

Search the sources for the word "BUG", the fixed ones are:

- A bug with adding/deleting lines when inside a FOR loop, the runtime stack is not correctly adjusted, try running this:
10 ? "START"
20 FOR J=0 TO 10
25 ? "J=";J
30 IF J=5 THEN DEL 10,10
40 NEXT J
50 END
The interpreter exits the FOR on the iteration 5, instead of counting up to 10.

- A bug with the parsing of IF statements without ENDIF, the end of statement is incorrectly checked. Test with:
10 ? 1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1:? 1;1;1;1;1;1;1;1;1;1;;;;;;:IF 1
20 ENDIF
If you remove one ";", the program runs correctly, but as shown it prints "ERROR 12".

Of the remaining bugs, IMHO the most difficult bug to fix is the missing newline in print (same as AtariBasic, a CONTROL-R or CONTROL-U as last character of a constant string to print suppresses printing of the newline character). I remember that [member=thorfdbg] said that he fixed this long time ago.

A good change that could be done is automatically detecting PAL/NTSC and using onw of two constants for calculation of TIME$, currently there is a constant 4320000 (= 50 * 60 * 60 * 24), labeled as JF_DAY in my source, for NTSC you need 5184000 (= 60 * 60 * 60 * 24). Edited by dmsc

Share this post


Link to post
Share on other sites

could you just to a LDA PAL, to detect if Turbobasic is running on a PAL or NTSC machine and write the appropriate value into JF_DAY. Maybe do the check during load, 

Share this post


Link to post
Share on other sites

Great. Good explanations. I'd suggest to have them included in the source or a separate readme.

 

Fix request: USR does not return the value stored in defined 16 bit register pair as ATARI BASIC does. This forces your to store the result somewhere else and DPEEK it. 

Share this post


Link to post
Share on other sites
Hi!,
 

Great. Good explanations. I'd suggest to have them included in the source or a separate readme.
 
Fix request: USR does not return the value stored in defined 16 bit register pair as ATARI BASIC does. This forces your to store the result somewhere else and DPEEK it.


I don't see the bug, see this program:

[attachment=513184:tstusr.png]

The USR returns the passed value, works with all 16bit numbers.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...