Assembly on the 99/4A

[Gary from OPA]

2 minutes ago, dhe said:

@HOME AUTOMATION thanks for the tip. I was trying to stay away from org and seg directives, that will be a whole other learning exercise.

 

I have you folks to help me along, I have Classic99 which makes it so much easier to expose the inner working of the 4a then I would with real hardware.

 

I have to wonder, what percent of people purchased the E/A Module with the intent of learning assembly language and just gave up?

E/A was not designed to be learning one, even the manual states it that prior knowledge is required.

 

TI marketed the mini-memory with its line-by-line assembler as more of a learning tool, there was more tutorials and examples with it plus it was designed as stepping stone up from Basic so you should had a bit of programming mindset already from using Basic language.

 

As for the percentage of people that gave up trying after buying the E/A package most likely a high percentage back in the day.

[Tursi]

6 hours ago, mizapf said:

but won't work once you convert it to a memory image file (option 5).

THIS. (Unless you save the entire 24k, which is wasteful.) Likewise if you want to make a cartridge.

 

Loading the vector manually is a better plan for the long term than using AORG to do it. Likewise for any other data outside of your program space.

 

I wanted to mention, too, though this is probably obvious, the Classic99 "refusing" message is a Classic99 enhancement. The real hardware doesn't check if your vector makes sense and will blindly execute it, likely causing a crash if it's incorrect.

 

[HOME AUTOMATION]

2 hours ago, Tursi said:

(Unless you save the entire 24k, which is wasteful.) Likewise if you want to make a cartridge.

Not if you load the main program, closer to the vector.

 

2 hours ago, Tursi said:

Loading the vector manually is a better plan for the long term than using AORG to do it. Likewise for any other data outside of your program space.

...Better, perhaps in terms of writing flexibility/running in alternate environments, though wasteful of space.

[GDMike]

Learning the debugger in cl99 is rewarding 

[HOME AUTOMATION]

4 hours ago, dhe said:

I have to wonder, what percent of people purchased the E/A Module with the intent of learning assembly language and just gave up?

When I recall my early days, studying from the accompanying book, I seem to be about 7-8 years old. Though in reality, I couldn't have been less than 30.

 

One issue that always miffed me, was, TI's use of the hyphen, to join, rather than separate, terms. One that threw me for about a year, "ASSEMBLY-TIME CONSTANT".

Already being familiar with "Time Constants", as used in Electronics terminology. I interpreted this to mean (Assembly)(Time Constant)... having a seemingly disparate connotation, relative to "EQUATE". This helped to confuse my understanding of LABELS, also referred to as SYMBOLS, or NAMES, for more than a year.

[matthew180]

On 5/4/2024 at 12:12 PM, dhe said:

Do you have any recommendations, on how to not make the mistake?

 

Don't use assembly... ? 

 

Just kidding, you should absolutely learn assembly, it is worth the effort and can be very rewarding.

 

However, assembly language is only a mnemonic representation of machine code to help the programmer not have to write programs in hex or binary, so there are not going to be many ways to keep you from treating the data in an expected way.

 

My recommendation would be:

 

1. Use xdt99's ability to use longer names for labels to its full extent.  Picking good names for routines and variables is hard, but it is very important to help remind you what the data is and how you are supposed to use it.

2. Adopt simple prefixes or suffixes to name what the data is (i.e. integers start with `s16_` or `u16_`, bytes with `s8_` or `u8_`, addresses with `adr_` (address), etc.).  These days, with xdt99, I have no problem writing 9900 assembly that does not work with TI's assembler (it was good BITD, but we have better now).

3. Use equates to name "magic numbers" and memory addresses.

4. Use larger block comments before code to explain what it is doing, which gives context to the code that follows that you don't get by commenting each line of code (which I find less useful since it does not tell you "why" or "what" is going on, only "how").

 

The CPU's view of memory is simply an address that holds a value.  The CPU does not know if the data is a signed number, unsigned, an address, part of a larger value, or anything else.  It is up to the programmer to keep all that straight, know what any particular data value is supposed to be, and select the proper assembly instructions to work with the values as intended.

 

This flexibility comes at a cost though, and assembly programmers need to be very meticulous and detail oriented.  You have to build a mental model of your data as you design and write your code.  With a small retro computer a human can keep all this detail in their head at once, and is one of the main aspects of retro computing that separates it from modern computing.

 

This is also why higher level programs were one of the first programs written for computers, with their abstractions and simplifications to what you can do with data, etc..  Such abstractions are needed to help make writing much larger programs even possible, but to also make computers usable and approachable for people who do not need or want to know how the computer works, but rather use it as a tool for doing other things (which may not even be computer related, i.e. writing a book, plans for building something, etc.).

[matthew180]

7 hours ago, dhe said:

I have to wonder, what percent of people purchased the E/A Module with the intent of learning assembly language and just gave up?

 

Heh.  It recent days, hit-or-miss.  People are probably curious, but quickly realize it takes a real amount of time and effort to learn enough to make a program, and probably decide they would rather do something else.  You can speculate about that all day long.

 

However, back in the day you didn't just buy the E/A Module (cartridge), that was mostly useless on its own.  You needed a 32K memory expansion, a disk controller, and disk drive; and that usually meant a PEB, but could also have been a collection of side-cars.  That is a pretty significant monetary investment, so people were probably a lot more careful about the decision and maybe knew more about what they were getting into?

 

However I knew nothing in 1983 (13yo) other than a vague idea of what assembly language was, and apparently my dad had more money than sense that day (or really believed in me?) when he bought the PEB package (TI was blowing them out by then, but it still cost about $400).

 

I had many many frustrating days and nights, sometimes ending in tears, trying to figure out assembly from the E/A manual and the Tombstone City source code[1].  But I am stubborn as hell, infinitely curious, I must know how things work, I pay attention to detail, and most importantly I knew all coin-op video games were written in assembly.  BASIC is sooo slow on the 99/4A (as we all know), and that was also a very strong motivator.  So, the choices were, 1. play marginal games, 2. program in slow BASIC / XB, 3. learn assembly and own the machine with all the power and speed in the world!  Muhaaa!!

 

I furiously typed in the E/A examples, some worked, some did not (as we now know, there are errors).  The first assembly program I tried to write was clearing the screen, trying to start simple, you know, like CALL CLEAR.  I wrote this: `CLR R1`.  I did not know what this "register" thing was that the "CLR" instruction needed, but that was the closest things to "CLS" that I could find, since that must be assembly for clear screen... (other BASIC dialects have CLS, so...)  It assembled!  It loaded!  It RAN!  It did *not* clear the screen.

 

It was not until I got the Lottrup book, which does start with simple programs like clearing the screen and animating the `@` symbol, that things really started to click for me.  Having to write a space character to every location on the screen was probably the first algorithm I was every directly exposed to, and it made so much sense.  I don't really recommend the book these days (for reasons explained in the early pages of this thread), but it absolutely opened the door to assembly and low-level computer programming to me BITD.

 

I still remember being so giddy about moving the `@` symbol across the top of the screen, and that I had to SLOW IT DOWN with a delay loop just to see it!  Oh assembly language, you are soooo cool!  I had to "slow it down!", something you would *never* have to do in BASIC where you spent your time screaming for it to go FASTER!  I bragged about that program, to anyone who would listen, for weeks.  I had many firsts on the 99/4A, and this was one of them.

 

Giving up was never an option that entered my conscious.  I do question my choice sometimes though, these days, as I scream at modern computers for entirely different reasons...

 

[1] (The Tombstone City source came with the E/A manual, and was a really cool move on TI's part, IMO.  Giving away source code to one of their commercial titles?!  It really contradicts TI's stinginess of wanting to have all developers pay them for a license to publish software for the 99/4A).

[apersson850]

9 hours ago, matthew180 said:

4. Use larger block comments before code to explain what it is doing, which gives context to the code that follows that you don't get by commenting each line of code (which I find less useful since it does not tell you "why" or "what" is going on, only "how").

That's a very important point. Something I've touched before here.

 

MOV *R2,R2 ; Fetch value pointed to by R2 to R2

MOV *R3,R3 ; Get pointer to next block

 

Unless you're learning how the different instructions and addressing modes are working, the first comment is worthless. It just tells you what the instruction does.

The second line's comment instead tells you what the purpose of using the instruction is. Here to traverse a linked list where the pointer to the next item is first in the current one.

[Tursi]

13 hours ago, HOME AUTOMATION said:

Not if you load the main program, closer to the vector.

 

...Better, perhaps in terms of writing flexibility/running in alternate environments, though wasteful of space.

You write your software however you like. I'm not dictating laws here. 

 

[GDMike]

My all time favorite TI times was used discovering Assembly and how to think in assy.

Forth is another one that requires being saturated in its depths before you can fully make good use of it.

 

 

[+TheBF]

25 minutes ago, GDMike said:

My all time favorite TI times was used discovering Assembly and how to think in assy.

Forth is another one that requires being saturated in its depths before you can fully make good use of it.

I think the reason they are similar to grasp is because Forth is actually the "Assembly Language" of Chuck Moore's idea of what a computer should be be.

(Two stacks, memory, disk, an i/o terminal and about 35ish "instructions")

If it stayed at that level it's not bad but then we pile on a few hundred little "programs" (words) and our human wetware strains to memorize everything. 

[Gary from OPA]

51 minutes ago, GDMike said:

My all time favorite TI times was used discovering Assembly and how to think in assy.

Forth is another one that requires being saturated in its depths before you can fully make good use of it.

 

 

My mentor that first helped me learn some assembly once I joined the local 9t9 users group was so good that he just read the hexcode, he was a human disassembler and compiler, he didn't need to use programs could just type the opcodes out directly and the code would work and give him a program image file and he could transcript the hex into assembly for you.

 

He never used comments either when coding and also made use of the registers completely, rarely using outside data statements with @ in his coding.

 

You can see example of one of his coding routines in some of my GitHub repos look for the blwp keyboard cursor routine it is sometimes labeled by James or Jim Ballantyne. Sadly near his natural life on earth before he upgrading to coding in the heavens he went blind but that didn't stop him from coding on his ti99 systems and running code even tho he could no longer see the screen.

 

************************************ Data Passed= Screen Address
* Cursor routine by Jim Ballantyne *              CPU Buffer Address
************************************        Byte  Offset (left movement)
KB     DATA >8320,$+2                       Byte  Length
       MOV  *R14+,R0                 RETURN     = R0 contains length
       MOV  *R14+,R1                              of input
       MOVB *R14+,R3
       MOVB *R14+,R2
       SRL  R3,8
       SRL  R2,8
       BLWP @VMBW
       A    R1,R3
       MOV  R1,R4
       A    R1,R2
       DEC  R2
       MOV  R2,R5
       S    R0,R1
       MOV  R1,R6
       CLR  R7
KB1    CLR  R9
KB2    MOV  R3,R0
       S    R6,R0
       LI   R1,>1E1E
       MOVB *R3,R1
KB3    SWPB R1
       BLWP @VSBW
       CLR  R8
KB4    MOVB R8,@>8379
KB5    CB   @>8379,@TC1
       JL   KB6
       INC  R7
       INC  R8
       C    R8,@TC2
       JL   KB4
       JMP  KB3
KB6    LIMI 2
       LIMI 0
       BLWP @KSCAN
       MOVB @>837C,R2
       JNE  KB7
       MOVB @>8375,R2
       JLT  KB5
       C    R7,@TC3
       JL   KB5
       MOV  @TC3,R7
       JMP  KB8
KB7    CLR  R7
KB8    MOVB *R3,R1
       BLWP @VSBW
       LI   R2,>A00
       DEC  R2
       JGT  $-2
       MOVB @>8375,R2
       JLT  KB5
       CI   R2,>1000
       JHE  KB9
       SRL  R2,7
       MOV  @KFT(R2),R11
       MOV  R3,R2
       RT
KF7    MOV  R4,R3
       MOV  R3,R0
       S    R6,R0
       MOV  R3,R2
KF2    LI   R1,>2000
KF2A   BLWP @VSBW
       INC  R0
       MOVB R1,*R2+
       C    R2,R5
       JLE  KF2A
       JMP  KB1
KF3    C    R2,R5
       JHE  KF2
       MOVB @1(R2),R1
       BLWP @VSBW
       INC  R0
       MOVB R1,*R2+
       JMP  KF3
KF4    SETO R9
       JMP  KB2
KFB    AI   R3,-39
KF8    DEC  R3
       C    R3,R4
       JHE  KB1
       JMP  KF9A
KFA    AI   R3,39
KF9    INC  R3
       C    R3,R5
       JLE  KB1
KF9A   MOV  R2,R3
       JMP  KB1
KFE    MOV  R4,R3
       JMP  KB1
KB9    CI   R2,>2000
       JL   KB5
       MOVB R2,*R3
       C    R3,R5
       JHE  KBAA
       INC  R3
       ABS  R9
       JEQ  KBA
       MOV  R3,R1
       MOV  R5,R2
       S    R3,R2
       INC  R2
       BLWP @VMBR
       DEC  R1
       INC  R2
       BLWP @VMBW
       JMP  KB2
KBA    MOVB R2,R1
       BLWP @VSBW
       JMP  KB1
KBAA   MOVB R2,R1
       BLWP @VSBW
KFD    CB   *R5,@KF2+2
       JNE  KFDA
       DEC  R5
       C    R5,R4
       JHE  KFD
KFDA   INC  R5
       S    R4,R5
       MOV  R5,*R13
       RTWP
KBF    CLR  *R13
       RTWP
KFT    DATA KB5,KB5,KF2,KF3,KF4,KB5,KB5,KF7
       DATA KF8,KF9,KFA,KFB,KB5,KFD,KFE,KBF
BIT0   DATA >8000
TC1    DATA >0600
TC2    DATA 3
TC3    DATA 10

 

[apersson850]

6 hours ago, Gary from OPA said:

He never used comments either when coding...

 

You can see example of one of his coding routines in...

Judging from the example you show you should all take a really good look. That's the source code produced by a completely worthless programmer.

If such a programmer had been employed where I work we would have him fired.

[GDMike]

7 minutes ago, apersson850 said:

Judging from the example you show you should all take a really good look. That's the source code produced by a completely worthless programmer.

If such a programmer had been employed where I work we would have him fired.

Even Barney would keep comments. 

[Gary from OPA]

45 minutes ago, apersson850 said:

Judging from the example you show you should all take a really good look. That's the source code produced by a completely worthless programmer.

If such a programmer had been employed where I work we would have him fired.

His real life job was designing, coding and programming the whole backend for MasterCard payment processing system, do he was a very talented programmer and if you are the only one on the team you really don't need comments.

 

I normally add in the comments after I finished a section so it could be better understood by others but if you know the system inside and out and how it works they really not needed.

[Stuart]

While grabbing my popcorn to enjoy the debate on MasterCard apparently employing a programmer who didn't believe in using comments to do their backend, here's a little snippet of code I've just come across to allow relocatable code (relocatable as in write it to an EPROM then plug that EPROM anywhere in the memory map). It uses a BL to determine the start address of the code, then uses indexed addressing to address the various data. I thought that was neat.

 

        LWPI >FF90       LOAD W.P.
        LI   R1,>045B    R1 = RT INSTRUCTION
        BL   R1          LOAD R11 WITH ADDRESS OF NEXT INSTRUCTION
        AI   R11,-10     ADJUST TO START ADDRESS
        MOV  R11,R10     R10 = BASE ADDRESS
        ...
        ...
        ...
        XOP  @CRLF(10),14
        XOP  @BANNER(10),14  OUTPUT BANNER/DATE
        BL   @BOUNDS(10)   SET MEMORY BOUNDS
        ...
        ...
        ...

 

 

[+TheBF]

 

Amazing.

 

[+TheBF]

Something that I notice with Jim's code that I never realized before, is that pulling multiple parameters from another workspace is the same amount of code you would use if you made a stack. 

       MOV  *R14+,R0                 RETURN     = R0 contains length
       MOV  *R14+,R1                              of input
       MOVB *R14+,R3
       MOVB *R14+,R2

 

I have a POP macro in my assembler that emits this same code with:

R0 POP, R1 POP, R2 POP, R3 POP,

 

[Gary from OPA]

15 minutes ago, TheBF said:

Something that I notice with Jim's code that I never realized before, is that pulling multiple parameters from another workspace is the same amount of code you would use if you made a stack. 

       MOV  *R14+,R0                 RETURN     = R0 contains length
       MOV  *R14+,R1                              of input
       MOVB *R14+,R3
       MOVB *R14+,R2

 

I have a POP macro in my assembler that emits this same code with:

R0 POP, R1 POP, R2 POP, R3 POP,

 

It is kind common in many cases of using blwp routines to have a data statement right after which is used to pass the parameters to the routine from the main code. In this case the vdp screen address for the input line, the cpu version of what you want displayed and edited, then finally the length with if you want a starting offset useful for path entries. For example:

 

        .......
example BLWP @KB
        DATA 5x40,path,>0520
        ......
        
        
path    TEXT 'DSK3.                           '

 

So above would display path string on line 5 of the screen if 40 column mode and have the cursor blinking after the period . With a maximum input length of 32 characters. For allowing you to input a filename, etc. and if you want backspace to change the dsk3 part. And his routine handles all the various fctn keys for insert, delete, etc.

Edited May 7 by Gary from OPA

[apersson850]

9 hours ago, Gary from OPA said:

His real life job was designing, coding and programming the whole backend for MasterCard payment processing system, do he was a very talented programmer and if you are the only one on the team you really don't need comments.

 

I normally add in the comments after I finished a section so it could be better understood by others but if you know the system inside and out and how it works they really not needed.

Read this very carefully, because that attitude is exactly what singles out a lousy and incompetent programmer.

If you do your own hobby programming at home, for nobody's amusement but yourself, then sure, do as you like. But if you do it professionally you must do everything so you can walk away from it today and somebody else can take over with the least possible effort.

Your description fits a completely talentless programmer.

[apersson850]

3 hours ago, TheBF said:

Something that I notice with Jim's code that I never realized before, is that pulling multiple parameters from another workspace is the same amount of code you would use if you made a stack. 

To pop it yes, but supplying it as data after the call means you don't have to push it first.

[Gary from OPA]

33 minutes ago, apersson850 said:

Read this very carefully, because that attitude is exactly what singles out a lousy and incompetent programmer.

If you do your own hobby programming at home, for nobody's amusement but yourself, then sure, do as you like. But if you do it professionally you must do everything so you can walk away from it today and somebody else can take over with the least possible effort.

Your description fits a completely talentless programmer.

It might apply to some or most but not all. I worked alongside James on many projects and he was one of the best not talentless at all. He understood the system and programming better than most and his lack of commenting was in no way because he was lousy or incompetent programmer.

[HOME AUTOMATION]

⌨️

0001        DEF  ADVANC
0002 ADVANC AI   R0,-1 PROGRAMMER RECEIVES ONE DEMERIT
0003 REWARD JNQE OUT    
0004 IMPROV BL   @ADVANC
0005        END

🚮

[apersson850]

4 hours ago, Gary from OPA said:

He understood the system and programming better than most and his lack of commenting was in no way because he was lousy or incompetent programmer.

Sure you can understand the system, but the lack of documentation is the pure definition of a lousy and incompetent programmer. So obviously he was that.

[JasonACT]

I once criticised my sister as being a fence sitter, but I find myself comfortably sitting next to her just now.

 

Code reviews, I've done one or two, my worst though was a guy who kept saying "that's just an opinion" until I asked "what if..." and he shut up.

 

I can't read all code though, and I kind of hate C++ and the black box it often comes with (C - I have no issues with).

 

Comments or not, if it's put out there, I'm kind of grateful.