Jump to content

Photo

TurboBasic XL v1.5 MADS source (disassembly)

TURBO-BASIC TURBO-BASIC XL Source Code disassembly

30 replies to this topic

#1 dmsc OFFLINE  

dmsc

    Chopper Commander

  • 237 posts
  • Location:Viņa del Mar, Chile

Posted Sun May 28, 2017 11:35 PM

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 :)

Attached Files



#2 Larry OFFLINE  

Larry

    River Patroller

  • 3,833 posts
  • Location:U.S. -- Midwest

Posted Mon May 29, 2017 10:54 AM

What tool was this disassembled with?

 

-Larry



#3 dmsc OFFLINE  

dmsc

    Chopper Commander

  • Topic Starter
  • 237 posts
  • Location:Viņa del Mar, Chile

Posted Mon May 29, 2017 11:03 AM

Hi!,
 

What tool was this disassembled with?


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

#4 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,490 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Tue May 30, 2017 12:37 AM

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



#5 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 12,462 posts
  • Location:United Kingdom

Posted Tue May 30, 2017 2:57 AM

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



#6 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Tue May 30, 2017 1:34 PM

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?



#7 Kyle22 ONLINE  

Kyle22

    River Patroller

  • 2,943 posts
  • Location:McKees Rocks (Pittsburgh), PA

Posted Tue May 30, 2017 5:05 PM

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



#8 pirx OFFLINE  

pirx

    Moonsweeper

  • 362 posts
  • Location:Poland

Posted Wed May 31, 2017 6:15 AM

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.



#9 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Wed May 31, 2017 8:07 AM

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, Wed May 31, 2017 8:15 AM.


#10 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Wed May 31, 2017 2:55 PM

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?



#11 pirx OFFLINE  

pirx

    Moonsweeper

  • 362 posts
  • Location:Poland

Posted Wed May 31, 2017 3:36 PM

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

 

Discussion (in pl_PL): http://atarionline.p...scussionID=3977

 

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



#12 1050 OFFLINE  

1050

    Dragonstomper

  • 753 posts

Posted Thu Jun 1, 2017 5:36 AM

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?

#13 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Mon Jun 5, 2017 8:04 AM

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.



#14 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Mon Jun 5, 2017 12:30 PM

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.

Attached Files



#15 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • 649 posts

Posted Mon Jun 5, 2017 2:54 PM

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



#16 dmsc OFFLINE  

dmsc

    Chopper Commander

  • Topic Starter
  • 237 posts
  • Location:Viņa del Mar, Chile

Posted Mon Jun 5, 2017 7:53 PM

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.

#17 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Tue Jun 6, 2017 5:00 AM

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.

Attached Files


Edited by peteym5, Tue Jun 6, 2017 8:03 AM.


#18 snicklin OFFLINE  

snicklin

    River Patroller

  • 2,045 posts
  • Location:Australia

Posted Tue Jun 6, 2017 12:51 PM

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.



#19 dmsc OFFLINE  

dmsc

    Chopper Commander

  • Topic Starter
  • 237 posts
  • Location:Viņa del Mar, Chile

Posted Sun Jun 11, 2017 11:38 PM

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

Attached Files



#20 luckybuck OFFLINE  

luckybuck

    Dragonstomper

  • 649 posts

Posted Mon Jun 12, 2017 2:53 PM

Thank you so much dmsc! :-)))



#21 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Tue Jun 13, 2017 1:32 PM

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.



#22 dmsc OFFLINE  

dmsc

    Chopper Commander

  • Topic Starter
  • 237 posts
  • Location:Viņa del Mar, Chile

Posted Tue Jun 13, 2017 7:35 PM

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 by dmsc, Wed Jun 14, 2017 6:16 PM.


#23 peteym5 OFFLINE  

peteym5

    Stargunner

  • 1,661 posts
  • Location:Buffalo NY USA

Posted Tue Jun 13, 2017 9:17 PM

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, 



#24 JAC! OFFLINE  

JAC!

    Stargunner

  • 1,490 posts
  • Always looking for GFX and MSX for my demos
  • Location:Lebach, Germany

Posted Wed Jun 14, 2017 12:52 PM

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. 



#25 dmsc OFFLINE  

dmsc

    Chopper Commander

  • Topic Starter
  • 237 posts
  • Location:Viņa del Mar, Chile

Posted Wed Jun 14, 2017 6:14 PM

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:

tstusr.png

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





Also tagged with one or more of these keywords: TURBO-BASIC, TURBO-BASIC XL, Source Code, disassembly

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users