Assembly on the 99/4A

[+Vorticon]

Sorry one more question: how does one convert the .obj file produced by asm994a to a TIFILES file useable on real hardware? What file parameters should I set in TIDIr to do the conversion?

[+Lee Stewart]

26 minutes ago, Vorticon said:

Sorry one more question: how does one convert the .obj file produced by asm994a to a TIFILES file useable on real hardware? What file parameters should I set in TIDIr to do the conversion?

 

Check the option in asm994a for copying to “TI Disk”. Asm994a will create a TIDISK image for you, which you can rename later or change to one you may have created before running the assembler. You can rename the image (MYDISK.TIDISK, say) to MYDISK.DSK because the formats are the same. You can always copy the file from the image to your Windows file system.

 

...lee

[+Vorticon]

That worked. Thanks!

[RXB]

Just me but I load the XB Assembly Code once with the XB Loader then same with

 

CALL INIT

CALL LOAD("DSK#.XBFILENAME") ! This loads the XB Assembly Program Object code uncompressed.

CALL PSAVE(2,"DSK#.FILENAME1,3,"DSK#.FILENAME2") ! This save 2 files in Program Image format of RAM from >2000 to >3000 and >3000 to >4000

 

Now you have created 2 Program Image Files you can load using:

 CALL PLOAD(2,"DSK#.FILENAME1,3,"DSK#.FILENAME2") ! No call init needed as you saved that portion of RAM >2000 to >3000

 

Also RXB 2020 allows you do do this anywhere in 32K RAM.

RXB has loaded 844K of SAMS this way with my game IN THE DARK

 

[Tursi]

42 minutes ago, Vorticon said:

That worked. Thanks!

You can also load in Classic99 in Editor/Assembler and save it back out, I often do that just out of laziness. xdt also has really good command-line conversion tools if you have Python available.

 

[+Vorticon]

14 minutes ago, Tursi said:

You can also load in Classic99 in Editor/Assembler and save it back out, I often do that just out of laziness. xdt also has really good command-line conversion tools if you have Python available.

 

I do have Python but I'm too lazy to install xdt ?

[Switch1995]

I've been reading/studying a ton of ASSM over the past couple of months.  I feel like I'm ready to start simple programming.  Now the question is:  to ISR/have access to standard libraries or no-ISR/write your own routines?   Looking at the benchmarking thread:

 

Language     First Pass    Optimized
GCC            15 sec         5 sec
Assembly       17 sec         5 sec
Machine Forth  17 sec         7 sec
Camel99 (DTC)  43.2 sec      25 sec
TurboForth     48 sec        29 sec
Camel99 (ITC)  48 sec        28 sec 
Compiled XB    51 sec       none yet
FbForth        70 sec        26 sec
GPL            80 sec       none yet
ABASIC        490 sec       none yet
XB           2000 sec      none yet
UCSD Pascal  7300 sec       263 sec

The difference in performance improvement of going from XB to "traditional" Assembly or XB to optimized Assembly is negligible (but the improvement from traditional ASSM to optimized is 300%, so that makes this a tough decision).  I'm leaning towards sticking with the traditional structure.  I think that will be easier to debug once my skill develops and programs get longer.    Decisions...  Decisions....

 

 

[+9640News]

A different subject than what was just posted a few minutes ago on the subject of Assembly Language.

 

MyWord for the Geneve was written in assembler.  I have been trying to figure out how this piece of software was pieced together and assembled.  One of the pieces of source code loads a number of object files into VDP, then does a save.  The code uses a REF statement for LOADER.  No where in any of the other pieces of code can I find a LOADER label and/or DEF statement. 

 

As GenASM and the GenPROG package was not around at the time, this leads me to believe there may have been another development package that could have had a library function called LOADER that may have been separate?????  I am pretty sure this LOADER just sets up everything for a DSRLNK.

 

Sound familiar to anyone?

 

There are also patch source files, so everything is a bit of a mystery I am trying to resolve to get to having a compilable package.

 

 

[+FarmerPotato]

On 10/4/2021 at 12:16 PM, Vorticon said:

I do have Python but I'm too lazy to install xdt ?

It’s not so much an install as a download and run it!

I put the directory in my path or in a Makefile variable. I use Cygwin on PC, or just MacOS as-is. (But with Python 3.)
 

[+FarmerPotato]

1 hour ago, 9640News said:

A different subject than what was just posted a few minutes ago on the subject of Assembly Language.

 

MyWord for the Geneve was written in assembler.  I have been trying to figure out how this piece of software was pieced together and assembled.  One of the pieces of source code loads a number of object files into VDP, then does a save.  The code uses a REF statement for LOADER.  No where in any of the other pieces of code can I find a LOADER label and/or DEF statement. 

 

As GenASM and the GenPROG package was not around at the time, this leads me to believe there may have been another development package that could have had a library function called LOADER that may have been separate?????  I am pretty sure this LOADER just sets up everything for a DSRLNK.

 

Sound familiar to anyone?

 

There are also patch source files, so everything is a bit of a mystery I am trying to resolve to get to having a compilable package.

 

 

If it’s just loading standard object files—grab the source to the E/A support routines and try LOADER? 
(a copy of the source is in my SuperSave thread.) 

 

 

[+FarmerPotato]

2 hours ago, Switch1995 said:

I've been reading/studying a ton of ASSM over the past couple of months.  I feel like I'm ready to start simple programming.  Now the question is:  to ISR/have access to standard libraries or no-ISR/write your own routines?   Looking at the benchmarking thread:

 

Language     First Pass    Optimized
GCC            15 sec         5 sec
Assembly       17 sec         5 sec
Machine Forth  17 sec         7 sec
Camel99 (DTC)  43.2 sec      25 sec
TurboForth     48 sec        29 sec
Camel99 (ITC)  48 sec        28 sec 
Compiled XB    51 sec       none yet
FbForth        70 sec        26 sec
GPL            80 sec       none yet
ABASIC        490 sec       none yet
XB           2000 sec      none yet
UCSD Pascal  7300 sec       263 sec

The difference in performance improvement of going from XB to "traditional" Assembly or XB to optimized Assembly is negligible (but the improvement from traditional ASSM to optimized is 300%, so that makes this a tough decision).  I'm leaning towards sticking with the traditional structure.  I think that will be easier to debug once my skill develops and programs get longer.    Decisions...  Decisions....

 

 

Not sure what you mean by non-ISR.. sprite motion is in the console ISR for one. 
 

If you’re just starting out, use what’s built in to the E/A environment. Like VMBW etc. 

 

Benchmarks are irrelevant to choosing how to start. An easier path is to add some assembly routines into your XB program. 

[+Lee Stewart]

2 hours ago, Switch1995 said:

Now the question is:  to ISR/have access to standard libraries or no-ISR/write your own routines?

 

Actually, without interrupts enabled, you still have access to all library routines in the console or those loaded by the Editor/Assembler cartridge, excepting only ISR-mediated sound and sprite automotion.

 

...lee

[RXB]

4 hours ago, Switch1995 said:

I've been reading/studying a ton of ASSM over the past couple of months.  I feel like I'm ready to start simple programming.  Now the question is:  to ISR/have access to standard libraries or no-ISR/write your own routines?   Looking at the benchmarking thread:

 

Language     First Pass    Optimized
GCC            15 sec         5 sec
Assembly       17 sec         5 sec
Machine Forth  17 sec         7 sec
Camel99 (DTC)  43.2 sec      25 sec
TurboForth     48 sec        29 sec
Camel99 (ITC)  48 sec        28 sec 
Compiled XB    51 sec       none yet
FbForth        70 sec        26 sec
GPL            80 sec       none yet
ABASIC        490 sec       none yet
XB           2000 sec      none yet
UCSD Pascal  7300 sec       263 sec

The difference in performance improvement of going from XB to "traditional" Assembly or XB to optimized Assembly is negligible (but the improvement from traditional ASSM to optimized is 300%, so that makes this a tough decision).  I'm leaning towards sticking with the traditional structure.  I think that will be easier to debug once my skill develops and programs get longer.    Decisions...  Decisions....

 

 

Wonder where RXB 2022 would rank in this list depending on what is being done:

 

[Switch1995]

9 minutes ago, RXB said:

Wonder where RXB 2022 would rank in this list depending on what is being done:

 

I've got a physical copy on order with @arcadeshopper, looking forward to playing around with it.

[RXB]

21 minutes ago, Switch1995 said:

I've got a physical copy on order with @arcadeshopper, looking forward to playing around with it.

Do you have FinalGROM as the same copy used for Classic99 runs from FinalGROM too.

[Switch1995]

2 minutes ago, RXB said:

Do you have FinalGROM as the same copy used for Classic99 runs from FinalGROM too.

Yeah, there is a "collector" value as well...

[Asmusr]

5 hours ago, Switch1995 said:

I'm leaning towards sticking with the traditional structure.  I think that will be easier to debug once my skill develops and programs get longer.    Decisions...  Decisions....

I have never needed the ISR for anything. Disabling it gives you full control over the machine and the scratch pad memory.

[+9640News]

11 minutes ago, Asmusr said:

I have never needed the ISR for anything. Disabling it gives you full control over the machine and the scratch pad memory.

I have seen the ISR used in a couple of places.  In the AfterHours BBS program, it is used to display the clock on the screen, as well as trigger a 3 minute inactivity timer kicking the user offline on the TIPI/Telnet connection does not have any key sent/received.

 

Beery

[RXB]

52 minutes ago, Asmusr said:

I have never needed the ISR for anything. Disabling it gives you full control over the machine and the scratch pad memory.

Pretty much limits you to Assembly only.

[Asmusr]

7 minutes ago, RXB said:

Pretty much limits you to Assembly only.

Assembly is what we're talking about.

[matthew180]

10 hours ago, Switch1995 said:

Now the question is:  to ISR/have access to standard libraries or no-ISR/write your own routines?

 

Not sure what "standard libraries" you are referring to, but if they are anything in ROM/GROM then the more pressing decision is, do you have CPU cycles to burn?  The ROM/GROM routines were designed for code compactness, not execution efficiency.

 

Also, it is not one or the other, you can call the ROM/GROM routines without using the ISR, you just have to obey all the rules of scratchpad use; which is usually more of a pain the ass than the routines are worth (IMO).  Don't be afraid to write you own routines, it is not that hard (you can get lots of help on the forum), and you will find the ROM/GROM do not offer much of what you will typically need anyway.

 

10 hours ago, Switch1995 said:

The difference in performance improvement of going from XB to "traditional" Assembly or XB to optimized Assembly is negligible (but the improvement from traditional ASSM to optimized is 300%, so that makes this a tough decision).

 

I guess I need to go review the cited benchmark, but I don't understand what you mean by "traditional" assembly.  You are coding in assembly, or you are not.  You can use ROM/GROM routines, or not.  You can optimize, or not.

 

It seems like you are stuck with analysis paralysis.  There is no right or wrong way, but there is a difference in writing code or not writing code.  Explore, have fun with it, see for yourself what works and what does not.

 

10 hours ago, Switch1995 said:

I'm leaning towards sticking with the traditional structure.  I think that will be easier to debug once my skill develops and programs get longer.    Decisions...  Decisions....

 

Still not sure what the traditional structure is?  Everyone who writes assembly programs does things a little differently, I have never seen any consistency to the point where things could be considered traditional as far as the 99/4A is concerned.

 

Debugging with an active ISR is going to be *harder* than not using an ISR.  Also, trying to co-exist with the ISR, calling ROM/GROM routines, with all the scratchpad memory-use rules is, IMO, waaaay harder than just disabling the interrupts and owning the machine.

 

You should review page 35 of this thread.  Sorry I can't cite the exact posts since the post-numbers have been removed.  There are also game-loop examples in this thread for just about any kind of ISR vs non-ISR use.

 

The best thing you can do, IMO, is just start with some simple programs to put some tiles on the screen, etc..  There are VDP routines posted early in this thread which let you use the VDP directly without any hidden ROM functionality.

 

[Switch1995]

Sorry for the confusion.  I guess what I mean by "traditional" is what the books I've been reading from the early 80's converge on.  Example:

 

 

I'm just weighing the pros/cons of sticking with the "old" guidance for a while until I get my legs under me.

[Switch1995]

33 minutes ago, matthew180 said:

There is no right or wrong way, but there is a difference in writing code or not writing code.  Explore, have fun with it, see for yourself what works and what does not.

Good advice. Thanks!

[matthew180]

7 hours ago, Switch1995 said:

I'm just weighing the pros/cons of sticking with the "old" guidance for a while until I get my legs under me.

 

The older code does not mean it is somehow easier to understand or use, and sometimes it is the opposite due to the abstractions without explanation.

 

Interesting example to use, clearing the screen.  There are several problems with that code, and a lot of it is the abstraction (REF/DEF, VSBW), bad workspace practice, and inefficiency (VSBW) for what the code needs to do.  Usually you are using assembly to avoid abstraction, and to have control of the machine and the rest of the hardware.  Check out pg. 2 in this thread, and specifically this post:

 

https://forums.atariage.com/topic/162941-assembly-on-the-994a/?do=findComment&comment=2019059

 

(I really wish the post numbers had not been removed)

 

[+Lee Stewart]

4 hours ago, matthew180 said:

(I really wish the post numbers had not been removed)

 

Yeah—removing post numbers was certainly an unwelcome deprovement! By your link, you figured it out, but for forum users who haven’t, the link for each post is the “Posted ...” tag to the right of the commenter’s member ID.

 

...lee