TurboBasic XL v1.5 MADS source (disassembly)

[dmsc]

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

turbo-mads.asm

Edited December 16, 2017 by dmsc

[+Larry]

What tool was this disassembled with?

 

-Larry

[dmsc]

Hi!,

 

What tool was this disassembled with?

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

[+JAC!]

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

[flashjazzcat]

Makes sense for a 16-18KB binary. Divide by two (roughly estimated average 6502 instruction length) and you get 9,000.

[peteym5]

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?

[Kyle22]

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...

[pirx]

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.

[peteym5]

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 May 31, 2017 by peteym5

[peteym5]

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?

[pirx]

https://github.com/mgr-inz-rafal/tubac

 

Discussion (in pl_PL): http://atarionline.pl/forum/comments.php?DiscussionID=3977

 

Of course it is not really functional yet, but mgr inż. is known for delivering ))))))

[1050]

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?

[peteym5]

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.

[peteym5]

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.

TurboBasicXLMads.zip

[luckybuck]

Thank you so much peteym5 :-))))))))))

[dmsc]

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.

[peteym5]

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.

TurboBasicXLMads.zip

Edited June 6, 2017 by peteym5

[snicklin]

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.

[dmsc]

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

turbo-dis-20170611.zip

[luckybuck]

Thank you so much dmsc! :-)))

[peteym5]

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.

[dmsc]

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 @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 June 15, 2017 by dmsc

[peteym5]

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,

[+JAC!]

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.

[dmsc]

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:

 

 

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