Subject: More assembly questions

From: Owen Brand <[email-masked]>
Date: Wed, 5 May 2010 11:28:46 -0400

I'm learning a ton going through this Lottrup book, but it is really  
geared towards the Minimem and LBL.  In the DATA examples given, DATA  
is placed in the memory location currently displayed by the LBL.   
Obviously in EA, there is much more flexibility and it's not "line by  
line".  So, if I have--- say 4500 bytes to write into consecutive  
memory locations, how would I do it?  Should I write all the bytes  
(paste in editor) to DATA with a label and create a loop to write the  
BYTEs to my pre-specified memory locations?  I think my thinking is  
still very "XB" but I'm working to change that.

I realize labels eat up some memory, but as I learn, I will be using  
them a bit liberally... How many labels can be created in an assembly  
program?  Is there a limit?

Owen Brand

       **webmaster**
http://www.Opry99er.com

---

From: Barry Peterson <[email-masked]>
Date: Wed, 5 May 2010 11:07:48 -0500

> program? Is there a limit?
No labels don't use memory, just a few bites in the source file. Use a label
any time you'll refer to an address. I don't know that there's a limit.

---

From: mark wills <[email-masked]>
Date: Wed, 5 May 2010 16:42:56 +0000 (GMT)

TurboForth currently has 907 labels. There'll be a few more tomorrow ;-)

>
>From: Barry Peterson <[email-masked]>
>To: [email-masked]
>Sent: Wed, 5 May, 2010 17:07:48
>Subject: Re: [TI994A] More assembly questions
>
> >
>
>
>
> >
> >
>
>
>
>
>
>
>
>No labels don't use memory, just a few bites in the source file. Use a label any time you'll refer to an address. I don't know that there's a limit.
> 
> 
>
>
>

---

From: Owen Brand <[email-masked]>
Date: Wed, 5 May 2010 12:52:18 -0400

Excellent info... You might need to explain the example you gave me..  
Is this supposed to be contained inside a DECrementing loop?

MOV R5,R5

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 5, 2010, at 12:42 PM, mark wills <[email-masked]>  
wrote:

> No labels don't use memory, just a few bites in the source file. Use  
> a label any time you'll refer to an address. I don't know that  
> there's a limit.
>
>
>
>
>

---

From: "Tursi" <[email-masked]>
Date: Wed, 5 May 2010 09:53:28 -0700

> still very "XB" but I'm working to change that.

If you are copying to CPU memory, then you don't need the copy at all - just 
use the data directly by using the label it is at rather than the 
pre-specified memory location.

> program?  Is there a limit?

I don't know the limit offhand - there is one, but it's pretty big. Also, 
labels only take up memory during assembly, once the program is built, they 
do not use any memory to run. So if you do hit the limit, you just break 
your program up into multiple modules and assemble them separately (or use 
one of the Windows/Linux based assemblers, which will likely have much 
larger limits).

---

From: Owen Brand <[email-masked]>
Date: Wed, 5 May 2010 13:14:21 -0400

Thank you Tursi.  I'm starting to see that many of the "scary"  
elements of assembly to higher level language programmers are actually  
some of it's greatest strengths.  I have been learning to think  
differently about the methods of building logical programs... I have  
kind of learned everything backwards-- I think most people do though.   
BASIC and XB make you view operations in a completely narrow window.   
In assembly, you don't simply add 2 numbers together by typing 5+3,  
you load values into registers, you determine the best way to axhieve  
the desired result and it might NOT be to simply add 2 numbers  
together!!  That's the awesome thing I'm learning... When your options  
for "what you wanna do" are multiplied exponentially, you think and  
see more clearly the most efficient path.  Efficient  
thinking=Efficient code=efficient program.  This is not 100% true all  
the time, but that's on the programmer. :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: mark wills <[email-masked]>
Date: Wed, 5 May 2010 18:54:44 +0000 (GMT)

The great thing is, TMS99xx assembly really *is* very easy to learn, and to work with.

There are only 69 instructions. After a while, you can knock out assembly like knocking out XB. Assembly is just broken down into much smaller steps.

Regarding adding numbers, the unique architecture of the 99xx means there are multiple ways to skin the cat.

Imagine you wanted to add two numbers at memory locations LOCA and LOCB:

LOCA DATA 100
LOCB DATA 252

Coders on 'other' processors could be forgiven for writing something like this:

MOV @LOCA,R0
MOV @LOCB,R1
A R0,R1
MOV R1,@LOCB

So, we read the values into registers, add them, and store the answer back in memory location LOCB.

On our chip, we can do:

A @LOCA,@LOCB

The memory to memory architecture makes this possible. Often, on the 99xx you don't need to use registers at all (though there are sometimes advantages for doing so, like smaller (i.e. faster) instructions).

M

>
>From: Owen Brand <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Sent: Wed, 5 May, 2010 18:14:21
>Thank you Tursi.  I'm starting to see that many of the "scary" elements of assembly to higher level language programmers are actually some of it's greatest strengths.  I have been learning to think differently about the methods of building logical programs... I have kind of learned everything backwards-- I think most people do though.  BASIC and XB make you view operations in a completely narrow window.  In assembly, you don't simply add 2 numbers together by typing 5+3, you load values into registers, you determine the best way to axhieve the desired result and it might NOT be to simply add 2 numbers together!!  That's the awesome thing I'm learning... When your options for "what you wanna do" are multiplied exponentially, you think and see more clearly the most efficient path.  Efficient thinking=Efficient code=efficient program.  This is not 100% true all the time, but that's on the programmer. :)     
>
>Owen Brand 
>
>
>       **webmaster** 
>http://www.Opry99er.com
>
>On May 5, 2010, at 12:53 PM, "Tursi" <[email-masked]> wrote:
>
>
>

---

From: Owen Brand <[email-masked]>
Date: Wed, 5 May 2010 15:34:12 -0400

Yea man... This is gonna be fun.  :) First assembly program--  
"Berylrogue".  By the Faire I hope.  :). Cartridge, perhaps?

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 5, 2010, at 2:54 PM, mark wills <[email-masked]>  
wrote:

> There are only 69 instructions. After a while, you can knock out  
> assembly like knocking out XB. Assembly is just broken down into  
> much smaller steps.
>
> The memory to memory architecture makes this possible. Often, on the  
> 99xx you don't need to use registers at all (though there are  
> sometimes advantages for doing so, like smaller (i.e. faster)  
> instructions).
>
> M
>
>
>
> elements of assembly to higher level language programmers are  
> actually some of it's greatest strengths.  I have been learning to  
> think differently about the methods of building logical programs...  
> I have kind of learned everything backwards-- I think most people do  
> though.  BASIC and XB make you view operations in a completely  
> narrow window.  In assembly, you don't simply add 2 numbers together  
> by typing 5+3, you load values into registers, you determine the  
> best way to axhieve the desired result and it might NOT be to simply  
> add 2 numbers together!!  That's the awesome thing I'm learning...  
> When your options for "what you wanna do" are multiplied  
> exponentially, you think and see more clearly the most efficient  
> path.  Efficient thinking=Efficient code=efficient program.  This is  
> not 100% true all the time, but that's on the programmer. :)
>
> Owen Brand
>
>        **webmaster**
> http://www.Opry99er.com
>

---

From: "Beery" <[email-masked]>
Date: Wed, 05 May 2010 21:50:31 -0000

Owen,

Not knowing anything about your application or how big it might become, you may want to store in a file those 4500 bytes for access and read them in from a record, image, etc.

With 4500 bytes of data, I would typically assume this is some kind of video data.  Is this data something that can be created on the fly, or is it basically a "screen shot" type deal if that is the case?

There are many ways to handle the approach.  It just depends upon how you want to tackle it and whether speed is a necessity.

Beery

---

From: Owen Brand <[email-masked]>
Date: Wed, 5 May 2010 18:05:19 -0400

Thanks for the response.  It is a map-- a giant map that will be  
scrolled across and displayed on the screen. I'm still learning basic  
directives, instructions, syntax... But I will have better stuff to  
share as I learn.  I'm hoping to have a good code segment to show  
soon... Hear feedback on efficiency, ideas on how to improve what I  
got.  There are some very great helpers in our community.  We're  
blessed to have such friendly, knowledgable programmers.

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 5, 2010, at 5:50 PM, "Beery" <[email-masked]> wrote:

> Owen,
>
> Not knowing anything about your application or how big it might  
> become, you may want to store in a file those 4500 bytes for access  
> and read them in from a record, image, etc.
>
> With 4500 bytes of data, I would typically assume this is some kind  
> of video data. Is this data something that can be created on the  
> fly, or is it basically a "screen shot" type deal if that is the case?
>
> There are many ways to handle the approach. It just depends upon how  
> you want to tackle it and whether speed is a necessity.
>
> Beery
>

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 01:07:31 -0400

Lottrups book liberally uses

        BLWP @>6028

to display text on screen.  Am I to infer that there is a built in  
routine which prints to the screen?  The book does not say what value  
is stored at memory location >6028, so I'm not sure this is literal  
for all forms of 9900 assembly, or whether it is simply a LBL thing.

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: "Tursi" <[email-masked]>
Date: Wed, 5 May 2010 23:25:41 -0700

The Line-By-Line assembler doesn't have built-in DEFs for the VDP access 
functions, so they use the raw addresses, which are loaded when the MiniMem 
gets initialized. Suffice to say, that won't work in Editor/Assembler.

In E/A, rather, you call the functions by name, at least to start. As you 
gain experience you can write your own functions which execute much faster, 
but for now, when you see those functions you need to know which one they 
are using. The most common ones are:

VMBW - VDP Multiple Byte Write - VDP Address to write to in R0, CPU address 
to read from in R1, count in R2
VSBW - VDP Single Byte Write - VDP Address to write to in R0, byte to write 
in the high byte of R1
VSBR - VDP Single Byte Read - VDP Address to read in R0, returned in the 
high byte of R1

To use them, you need to "REF"erence them, like so:

    REF VMBW,VSBW,VSBR

Then you call them just like in the examples you are seeing
 (load the registers first)
  BLWP @VMBW

I found REF/DEF a little confusing when I first started, but all they are is 
a way to access labels in another file. In this case, the Editor/Assembler 
itself loads a bunch of functions (there are more than those three). When 
you want to make your label available to another file, you "DEF"ine it. This 
tells the assembler to make that label available to any other program via 
LOAD AND RUN.

"REF"erence is used to tell LOAD AND RUN that you want to use a label from 
another file. LOAD AND RUN goes through all the REFs and makes sure there is 
a matching DEF somewhere before letting you run the program. So, for 
instance:

FILE1 might look like this:

* Make the mapdata available to other files
 DEF MAPDAT

* Actually define the map data
MAPDAT DATA >4849,>204F,>5745,>4E00
 END

You save that, and assemble it as FILE1/O (for instance). Then make a FILE2:

* Export the start label so we can run this
 DEF START
* Reference the VDP functions and the MAPDATA we need
 REF VMBW,MAPDAT

* Now run the code
START
  LI R0,40              * Address on the screen (1 line down, 8 chars in)
  LI R1,MAPDAT * Address of the source data
  LI R2,7                 * number of bytes
  BLWP @VMBW
LP
  LIMI 2
  JMP LP                 * Wait for QUIT

  END

Save that, and assemble as FILE2/O.

Now, go into LOAD AND RUN. Load FILE1/O, then load FILE2/O. Then press 
enter, and enter the program name START.

Exercises:
What happens if you load FILE2/O first?
What happens if you change the data in FILE1 and reassemble, but do NOT 
change FILE2?
What happens if you load only FILE1/O? Why? (Make sure you reset before the 
next question).
What happens if you load only FILE2/O? Why?

I'll let you try and and ask questions before I go too deep into what 
happened.

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Thu, 6 May 2010 11:36:33 +0200

>6028 is indeed the VMBW address in MiniMemory.
For that, in E/A you just add

REF VMBW

at the top of your source file. Then, when you load the resulting object 
file with option 3 (Load and Run) of E/A module, the E/A Loader will 
automatically resolve the reference of VMBW. As a matter of fact, the true 
address of VMBW in option 3 of E/A will be loaded by E/A in the DEF/REF 
table that starts at >3FF8, going downwards, when option 3 of E/A is used 
for the first time: at this point of time, the DEF/REF table contains just 
the Predefined Symbols.  VMBW is just one of Predefined Symbols, as VSBR 
and so on.

When the E/A loader finds a REF in your object code, it will look in the 
above DEF/REF table and see if there is a match. If so, the REF in your 
code will be resolved. Later on, when you Run the object, all the 
REFerences in your OBJs must be resolved, either because they were among 
the Predefined Symbols or because they were defined in some other obj 
files you have loaded after the first one. If that doesn't happen, then 
you have the infamous "UNRESOLVED REFERENCE" error.

In other words, and as Tursi has already well explained in a previous 
post, for each REF in your source code there must be a corresponding DEF 
in the DEF/REF table. Once you have done that, everything will be handled 
automatically (and automagically) by the E/A module.

Have fun!

Paolo

----- Original Message ----- 
From: "Owen Brand" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 06, 2010 7:07 AM
Subject: Re: [TI994A] More assembly questions

        BLWP @>6028

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: mark wills <[email-masked]>
Date: Thu, 6 May 2010 10:32:00 +0000 (GMT)

I confidently predict those 4500 bytes of map data can be reduced to ~500 bytes.

Mark

>Sent: Wed, 5 May, 2010 23:05:19
>Subject: Re: [TI994A] Re: More assembly questions
>
> >
>
>
>
> >
>
>
>
>
>
>
>Thanks for the response.  It is a map-- a giant map that will be scrolled across and displayed on the screen. I'm still learning basic directives, instructions, syntax... But I will have better stuff to share as I learn.  I'm hoping to have a good code segment to show soon... Hear feedback on efficiency, ideas on how to improve what I got.  There are some very great helpers in our community.  We're blessed to have such friendly, knowledgable programmers. 
>
>Owen Brand
>
>
>       **webmaster** 
>http://www.Opry99er.com
>
>>>>--- In TI994A@yahoogroups. com, Owen Brand <owenbrand@. ..> wrote:
>>>>>
>>>>>        **webmaster* *
>>>>> http://www.Opry99er .com

---

From: mark wills <[email-masked]>
Date: Thu, 6 May 2010 10:37:40 +0000 (GMT)

One other thing, consider moving this discussion to the SWPB list, which is specifically set up for discussing TMS99xx machine code. It would be useful to have all these discussions archived on the SWPB list.

I have no objection to reading/answering the posts here at all, but I always go "yay!" when I see a post on SWPB, because it tends to fall by the wayside a little. Also, Urbite is on SWPB ;-)

Mark

>
>From: mark wills <[email-masked]>
>Sent: Thu, 6 May, 2010 11:32:00

---

From: "Beery" <[email-masked]>
Date: Thu, 06 May 2010 13:18:29 -0000

Owen,

There are always a bunch of folks willing to help.  Please realize there are always a multitude of ways to skin the cat.

Myself, I have had no formal programming training.  I'm sure there is stuff I have written that could be shorter.  When it does what I need at the speed I need, I am satisfied.

Beery

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On May 5, 2010, at 5:50 PM, "Beery" <bmiller@...> wrote:
> 
> > Owen,
> >
> > --- In [email-masked], Owen Brand <owenbrand@> wrote:
> > >

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 10:18:27 -0400

I'll try this out today, Tursi... Thank you for help and excellent  
explanation.  I'm starting to understand a bit about how things work.   
So, my next step is to try this bad boy out.. If I change MAPDAT to  
house an actual 15x15 screenshot and change the number of bytes (R2)  
from "7" to "225," then that should be sufficient to do so, yea?

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 10:40:29 -0400

Thanks Paolo.  Your advice is always very clear and useful.  :) I hope  
to put out a cartridge game within the year.... I'm starting small...  
A rouguelike game (ASCII dungeon crawler) which will be very  
minimalistic in content as well as graphics... Just to get me goin.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 12:44:00 -0400

1) If I load F2O first and then F1O, nothing changes--- same message  
displayed.

2) If I change DATA, the message is different, but it loads and runs  
fine

3) File 1 will not load and run by itself-- no START label

4) File 2 will not load and run by itself because there is a REF but  
no DEF for MAPDAT

"Hi" to you too, Tursi.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 12:47:52 -0400

Ahhh... F1O doesn't have a REF for it's DEF either

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: "Tursi" <[email-masked]>
Date: Thu, 6 May 2010 09:49:13 -0700

You'll learn faster by playing with it - I specifically structured the 
example and the exercises to help make certain points more clear (Paolo gave 
away one of the answers already, but that's okay. ;) )

After you try it, report your results, then we'll discuss why. At least, 
that's the way I'd prefer to do it. :)

--------------------------------------------------
From: "Owen Brand" <[email-masked]>
Sent: Thursday, May 06, 2010 7:18 AM
To: <[email-masked]>
Subject: Re: [TI994A] More assembly questions

---

From: "Tursi" <[email-masked]>
Date: Thu, 6 May 2010 09:57:46 -0700

Hehe.. good answers. :) All correct!

> 1) If I load F2O first and then F1O, nothing changes--- same message

This demonstrates that the order doesn't matter... the LOAD AND RUN step 
includes a "linker" whose job it is to match the DEFs with REFs. It can 
handle them coming in any order, so long as they are all matched up before 
you try to run.

> 2) If I change DATA, the message is different, but it loads and runs

Right! The idea was to show that the actual program code is successfully 
linking with the data file, and that they are not related until the actual 
load step.

> 3) File 1 will not load and run by itself-- no START label

Right! No way to start it.

> 4) File 2 will not load and run by itself because there is a REF but

Correct! The idea of this exercise was to let you see the error message this 
generates.

>Ahhh... F1O doesn't have a REF for it's DEF either

This actually does not matter... DEF just makes a label available - nobody 
actually HAS to use it.

However, because REF says that you ARE using someone else's label, the 
corresponding DEF must exist somewhere, otherwise LOAD AND RUN can't resolve 
the label to a real address.

Now to answer your question about 15x15 maps - if you tried just changing 
the data and the count, you would not have seen what you expected. The 
reason is that the screen is a continuous list of bytes, 32 characters wide. 
So multiple lines of your map would run together as it copies the data raw. 
In order to draw that, you will need a separate VMBW call for each line, and 
add 32 to the VDP address each time (for one screen line), while adding 15 
to the CPU address (for one map line).

Sent: Thursday, May 06, 2010 9:44 AM

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 13:37:12 -0400

Thanks man.  I'll be trying out my screen draw of a 15x15 window later  
today.  I might start trying an entire screen first, just to save the   
32 and 15 increments.  I will have to load it up to start at screen  
location "0" and set it to load 768 bytes.  Question, how many data  
words can be written to a data line?  Is it simply limited to the  
operand field's physical length?

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: Marc Hull <[email-masked]>
Date: Thu, 6 May 2010 12:39:05 -0700 (PDT)

As many as you can fit on a source code line.

--- On Thu, 5/6/10, Owen Brand <[email-masked]> wrote:

From: Owen Brand <[email-masked]>
Subject: Re: [TI994A] More assembly questions
To: "[email-masked]" <[email-masked]>
Date: Thursday, May 6, 2010, 12:37 PM

  

      Thanks man.  I'll be trying out my screen draw of a 15x15 window later today.  I might start trying an entire screen first, just to save the  32 and 15 increments.  I will have to load it up to start at screen location "0" and set it to load 768 bytes.  Question, how many data words can be written to a data line?  Is it simply limited to the operand field's physical length? 

Owen Brand
       **webmaster* * http://www.Opry99er .com
On May 6, 2010, at 12:57 PM, "Tursi" <yahoogroup@harmless lion.com> wrote:

    

you try to run.

load step.

generates.

actually HAS to use it.

------------ --------- --------- --------- --------- --

From: "Owen Brand" <owenbrand@opry99er. com>

To: <TI994A@yahoogroups. com>

---

From: tursi <[email-masked]>
Date: Thu, 6 May 2010 13:11:28 -0700 (PDT)

> Thanks man.  I'll be trying out my screen draw of a 15x15 window later today.  I might start trying an entire
> screen first, just to save the  32 and 15 increments.  I will have to load it up to start at screen location
> "0" and set it to load 768 bytes.  Question, how many data words can be written to a data line?  Is it simply
> limited to the operand field's physical length? 

I think you are asking about the DATA command in the assembler, right? It 
depends on the assembler used, but I think you can fill the line in 
Editor/Assembler. Not sure! I usually put only 8 elements in a line myself 
(and 16 on the PC where I have a wider screen) just for the sake of easy 
counting. ;)

---

From: Marc Hull <[email-masked]>
Date: Thu, 6 May 2010 13:17:11 -0700 (PDT)

Hey Owen...

here is a tip.  When drawing character on the screen and they are type able (regardless of whether or not you are redefining them)  try the TEXT directive.  It will save your finger extra work and your brain needless conversions.....

n Thu, 5/6/10, Owen Brand <[email-masked]> wrote:

 

    

Owen Brand

    

you try to run.

load step.

generates.

actually HAS to use it.

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 16:17:20 -0400

Thanks--- 8 seems to be a good #.... 4 DATA command lines per screen  
row.  That'll be one long ass source listing, compared to what I've  
done thus far.  :) Mark Wills can speak to long sourcefiles  
though.... :) his turboForth source must be a fargin dictionary by  
now!!!  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 6, 2010, at 4:11 PM, tursi <[email-masked]> wrote:

> > Thanks man.  I'll be trying out my screen draw of a 15x15 window  
> later today.  I might start trying an entire
> > screen first, just to save the  32 and 15 increments.  I will have  
> to load it up to start at screen location
> > "0" and set it to load 768 bytes.  Question, how many data words  
> can be written to a data line?  Is it simply

---

From: mark wills <[email-masked]>
Date: Thu, 6 May 2010 20:29:43 +0000 (GMT)

TurboForth IIRC is split across 27 source code files ;-)

>Sent: Thu, 6 May, 2010 21:17:20
>Thanks--- 8 seems to be a good #.... 4 DATA command lines per screen row.  That'll be one long ass source listing, compared to what I've done thus far.  :) Mark Wills can speak to long sourcefiles though.... :) his turboForth source must be a fargin dictionary by now!!!  :)
>
>Owen Brand
>
>
>       **webmaster** 
>http://www.Opry99er.com
>

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 16:31:40 -0400

Yea--- I did my first "Hello World" program using TEXT.  I thought  
Tursi's source was good...  :) Make me type it in to see what he was  
saying... That way I wouldn't just mentally run the program while I  
read it.  I also had to determine which lines started with a label and  
which started with an opcode.  That was a good exercise.  My second  
program went through 3 assemblies before I figured out exactly what I  
was doing wrong.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 6, 2010, at 4:17 PM, Marc Hull <[email-masked]> wrote:

> Hey Owen...
>
> here is a tip.  When drawing character on the screen and they are  
> type able (regardless of whether or not you are redefining them)   
> try the TEXT directive.  It will save your finger extra work and  
> your brain needless conversions.....
>
>
>
>
> later today.  I might start trying an entire screen first, just to  
> save the  32 and 15 increments.  I will have to load it up to start  
> at screen location "0" and set it to load 768 bytes.  Question, how  
> many data words can be written to a data line?  Is it simply limited  
> to the operand field's physical length?
>
> Owen Brand
>
>        **webmaster* *
> http://www.Opry99er .com
>

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 16:34:16 -0400

I meant 2 lines of DATA at 8 words per line.  I keep having to remind  
myself to remember both bytes, left and right, in a word.  :)

Owen Brand

        **webmaster**
http://www.Opry99er.com

On May 6, 2010, at 4:17 PM, Owen Brand <[email-masked]> wrote:

>> > screen first, just to save the  32 and 15 increments.  I will  
>> have to load it up to start at screen location

---

From: tursi <[email-masked]>
Date: Thu, 6 May 2010 13:43:18 -0700 (PDT)

> here is a tip.  When drawing character on the screen and
> they are type able (regardless of whether or not you are
> redefining them)  try the TEXT directive.  It will save
> your finger extra work and your brain needless
> conversions.....

hehe.. I meant to mention that, the only reason I used DATA was to hide 
the message. ;)

---

From: "Matthew" <[email-masked]>
Date: Thu, 06 May 2010 21:08:13 -0000

Keep in mind that the definition of "word" changes based on the platform.  Also, you should try to think of the bytes in terms of MSB and LSB and also note that depending on the CPU, the MSB will not always be on the "right" (lower memory address.)

Matthew

--- In [email-masked], Owen Brand <owenbrand@...> wrote:
> On May 6, 2010, at 4:17 PM, Owen Brand <owenbrand@...> wrote:
> 
> > On May 6, 2010, at 4:11 PM, tursi <yahoogroup@...> wrote:
> >

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 18:26:16 -0400

Here's one for ya.  Tursi--- I tried to combine these two programs  
together--- make one source file.  I keep getting MULTIPLE SYMBOLS or  
something. I made a few changes to the listing to try to make them  
work together-- but I have been unsuccessful.  Any ideas?

Owen Brand

        **webmaster**
http://www.Opry99er.com

---

From: Owen Brand <[email-masked]>
Date: Thu, 6 May 2010 18:46:53 -0400

After a few changes, trying to get different results, here's whats
left of the code.  By now I've probably broken it beyond easy repair, but I
thought I'd post it so you guys can tell me how obviously wrong I am and I
can learn a thing or two.  =)  I bet it's something just blatantly obvious
and I just havent caught it.

       DEF  START
       REF  VMBW,MAPDAT
START
       LI   R0,0
       LI   R1,MAPDAT
       LI   R2,768
       BLWP @VMBW
LP
       LIMI 2
       JMP LP
       DEF  MAPDAT
MAPDAT DATA >2020,>4245,>5259,>4C20    ;
       DATA >2048,>5020,>3335,>2020    ;
       DATA >2020,>2020,>4C49,>5645    ;
       DATA >5320,>3220,>2020,>2020    ;
.
.
.
.
.
continues for a total of 768 bytes

On Thu, May 6, 2010 at 6:26 PM, Owen Brand <[email-masked]> wrote:

> something. I made a few changes to the listing to try to make them work
> together-- but I have been unsuccessful.  Any ideas?
>
>
> Owen Brand
>
>         **webmaster**
> http://www.Opry99er.com <http://www.opry99er.com/>
>

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Fri, 7 May 2010 02:01:50 +0200

Since MAPDAT DATA is now in the same source file that will use it, there's 
no need to REF it. Therefore, no need to DEF it either. So, just leave 
VMBW alone in the REF line, and do away entirely with the line that reads 
DEF MAPDAT.

Have fun!

Paolo
----- Original Message ----- 
From: "Owen Brand" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 07, 2010 12:46 AM
Subject: Re: [TI994A] More assembly questions

left of the code.  By now I've probably broken it beyond easy repair, but 
I

       DEF  START
       REF  VMBW,MAPDAT
START
       LI   R0,0
       LI   R1,MAPDAT
       LI   R2,768
       BLWP @VMBW
LP
       LIMI 2
       JMP LP
       DEF  MAPDAT

---

From: tursi <[email-masked]>
Date: Thu, 6 May 2010 19:00:14 -0700 (PDT)

> together-- but I have been unsuccessful.  Any ideas?

The first rule of programming is "Details matter". So the exact error 
message is important. :)

Anyway, multiple symbols mean you have told the system to use the same 
symbol name more than once. I don't think you can ref and def inside the 
same file, this is probably the problem. The reason is this:

When you do a REF, a spot is allocated in the name table for that label. 
It can only be resolved by a DEF. However, if you also use that label, now 
you have two copies of it - the REF, and the inline one, so the assembler 
assumes you have accidentally used the same name, and warns you.

I can't check right now at work, so apologies if that's wrong, but just 
clean up the REF/DEFs at the top - you should only need the REF VMBW.

When starting out, it's definately nice to have all code and data in one 
file, because you can avoid so much of this. But as your code gets larger, 
breaking it up really helps with the assembly time, because there's less 
code to rebuild when you make a change in one place. :)

---

From: "Beery" <[email-masked]>
Date: Fri, 07 May 2010 15:33:07 -0000

MDOS source is spread across many many more files.  I'm just guessing, but there may be 15 to 20 or more object files that are loaded to create the final image file.

Beery

--- In [email-masked], mark wills <markrobertwills@...> wrote:
> >From: Owen Brand <owenbrand@...>