Jump to content
IGNORED

Mini Memory Line-by-Line Assembler


coolio

Recommended Posts

I just got ahold of a working Mini Memory, but I do not have the cassette tape with the line-by-line assembler. Does any body know where I could get a WAV file or something containing the line-by-line assembler?

 

Thanks!

 

https://onedrive.live.com/redir?resid=E30817C72F629AFF!82332&authkey=!AMPp0WpqiqJY3sE&ithint=folder%2cwav

 

Yep, here ya go.

  • Like 1
Link to comment
Share on other sites

Same here: I learned much about TMS-9900 using the Line-by-line assembler with the Mini Memory. A great experience. I would like to write a monitor like what I used on the Commodore (Warp Speed's, in particular, was really nice) to do essentially "immediate mode" assembly programming on the TI.

Link to comment
Share on other sites

When I was a kid,I got mini memory after begging for it for a long time. I was very disappointed that the manual didn't go into detail about how to program in assembly language. I mainly used it to save basic programs (and watch LINES).

 

A few months ago, I decided to finally learn TMS9900 assembly language, and did so with Compute!'s Beginner's Guide to Assembly Language on the TI-99/4A. I think using the Line-by-line Assembler helped by making me think about what I wrote due to the difficulty of changing it later.

 

I never want to use it again. The Line-by-line Assembler got my assembly skills into shape, so now I can appreciate the conveniences of using editor/assembler, instead of thinking about how e/a is so primitive compared to modern tools.

Link to comment
Share on other sites

 

Elaboration requested...

TurboForth (and fbForth) have assemblers. However, they are not assemblers in the form that we are familiar with. They actually extend Forth itself, so that assembly language becomes part of Forth. You just type your machine code in, and, er, that's it really.

 

Here's how it works with editor assembler:

 

  • Load editor
  • Type in some assembler code
  • Save assembler code to a DV80 file
  • Exit editor
  • Load assembler
  • Assemble DV80 file to DF80 file
  • Errors? Goto step 1 :grin:
  • Exit Assembler
  • Load DF80 file
  • Run assembler program
  • Crashed/not working? Turn off power, turn on power, goto step 1 :mad:
  • Repeat until you can't be bothered any more

Here's how it works in Forth:

 

  • Type in assembler code right there at the Forth command line, like a Forth colon definition
  • Try it

Of course, since you're writing assembler you can crash it hard if there's an error in your code. Requiring you to turn off/on again. But, the entire Forth system is in a cartridge, so it's really fast to get up and running again.

 

Forth assembler code has a different syntax to regular assembler code. That's the learning curve, and the price that you pay for the flexibility.

 

For example: In standard assembler:

 

LI R1,1234

 

Becomes:

 

1234 R1 LI,

 

The instruction comes last. Why you ask? Well, it's very simple. LI is the assembler for Load Immediate instructions! Here's how it works:

 

1234 goes on the stack as normal. R1 is a word that just pushes 1 to stack. LI is a mini assembler that knows how to write LI opcodes into memory. LI takes the 1234 and the 1 off the stack, understands that it has to write the opcode for LI R1,1234 and does it.

 

And that's how it works for all the assembler instructions. Each assembler instruction assembles itself. How cool is that?!

 

You can also do IF ENDIF and BEGIN UNTIL at the machine code level:

 

For example:

 

 

      MOV R0,R0 ; test R0
      JNE xxxx ; if not zero, then skip
      INCT R2 ; otherwise increment R2 by 2
xxxx INC R1 ; then increment R1

 

Can be written as:

 

 

R0 R0 MOV \ test R0
EQ IF \ is R0==0?
  R2 INCT \ if yes then add 2 to R2
ENDIF
R1 INC \ increment r1

 

Which is much better in my opinion. There's no requirement for labels at all. You don't need them as the IF..ELSE..ENDIF will take care of it without the need for labels at all!

 

Here's some code to write a character to every position on the screen:

 

 

$8C02 CONSTANT VDPA  \ address of VDP address register
$8C00 CONSTANT VDPW  \ address of VDP write register
     
ASM: WIPE ( ascii --)
   \ create assembly language word “WIPE” 
   R0 CLR,              \ screen address 0
   R2 960 LI,           \ counter (40 column mode assumed) 
   *SP SWPB,            \ get ASCII value on stack in high byte
   BEGIN,               \ begin a loop
      R0 SWPB,          \ get address low byte
      R0 VDPA @@ MOVB,  \ write low byte to address register
      R0 SWPB,          \ get address high byte
      R0 VDPA @@ MOVB,  \ write hi byte to address register
      *SP VDPW @@ MOVB, \ write to VDP write register
      R0 INC,           \ move to next address
      R2 DEC,           \ decrement counter
   EQ UNTIL,            \ repeat loop if R2 is not 0
   SP DECT,             \ remove ASCII value from the stack
;ASM                    \ end definition of assembly language word

 

Look ma! No labels! :P All done with structured looping, AT THE MACHINE CODE LEVEL!

 

And there, ladies and gentlemen, endeth the First Lesson.

 

Forth. Are you experienced yet? :-D

  • Like 2
Link to comment
Share on other sites

I learned assembly using it. I highly suggest downloading Fundamentals of TI 99/4A Assembly Language book by Morley which uses exclusively the Mini Memory module. You can find it here: http://www.hexbus.com/tibooks/

COMPUTE!'s beginner's guide to assembly language on the TI-99/4A is the book that I used to learn assembly language. It is available in the "Development Resources" at the top of the page. Morley's book teaches some fairly abstract ideas such as 64 bit addition; Lottrup's book has you redefining characters and writing them to the screen. Both are good, but in different ways.

Link to comment
Share on other sites

COMPUTE!'s beginner's guide to assembly language on the TI-99/4A is the book that I used to learn assembly language. It is available in the "Development Resources" at the top of the page. Morley's book teaches some fairly abstract ideas such as 64 bit addition; Lottrup's book has you redefining characters and writing them to the screen. Both are good, but in different ways.

 

IMHO, the Morley book is essential at gaining a good understanding of the basics of machine language programming, such as number manipulation, conversion, etc... From there, Lottrup's or Molesworth's books guide you through more TI specific and practical programming skills. I started with Morley, then moved on to Molesworth, before I even so much glanced at the TI E/A manual :D

There is unfortunately no effortless way to learn assembly on any system, no matter what the book titles suggest. The good news though is that once you know assembly language on one machine, learning it for another is much easier because the base concepts are the same.

Link to comment
Share on other sites

I learned assembly language from Matthew's excellent thread, with the E/A manual as reference:

 

http://atariage.com/forums/topic/162941-assembly-on-the-994a/

 

All of my demos and games has been based on Matthew's template.

 

If you like assembly language and want to make a longer programs you will probably want switch to doing the editing and assembly on a PC.

  • Like 1
Link to comment
Share on other sites

I know! How frikken cool is that??!!! But I take credit for none of it. It's been around in the Forth universe for literally decades, waiting patiently for the enlightened few ;)

 

Willsy, will TurboForth allow me to manipulate and display the bitmap screen if I do it from within embedded assembly? My hunch is probably no because I would be messing up TF's environment...

Link to comment
Share on other sites

I think the answer is yes. It depends on how much block access you want to do. It's likely that the bitmap display will spill over into the block buffers (the block buffers are in VDP RAM in TF to give more space in CPU ram for programs). There are up to 6 block buffers, but you can change how many buffers are available. The minimum is 1. The blocks are reserved in VDP starting at higher addresses.

 

See here.

 

In TF V1.2 there is a word called #BUF ("number of buffers"). It's a variable, read with @ and written with !

 

 

#BUF @ .
6 ok:0

 

To set it to 1 it's simply:

 

 

1 #BUF !

 

Then it will only use 1 block buffer. As you probably know, the block buffers are a kind of cache that hold up to six blocks in memory, to save on round-trips to the disk drive. If you're working in emulation, or have a ram disk or equivalent on real iron, then you could work with a single block buffer and not really see any difference when editing blocks etc.

 

FWIW: I tend to not use blocks at all until my application is finished. I write in Notepad++ and paste it into TF using Classic99.

 

Of course, there are other areas of VDP that bitmap mode would overwrite, such as the PAB for user files. But if you're not using files in your application then you could ignore that. If you are, then just write some code (doesn't have to be assembler) to save them into CPU memory (into an ALLOTed buffer) and restore them when you need them.

 

It can be done. I've just never got around to implementing the bit-map plot/unplot/line/circle stuff. That stuff aint my bag, man!

Link to comment
Share on other sites

 

Willsy, will TurboForth allow me to manipulate and display the bitmap screen if I do it from within embedded assembly? My hunch is probably no because I would be messing up TF's environment...

 

You can certainly do it in fbForth—though, of course, you still must be mindful of VRAM real estate. It's much easier to use the bitmap graphics words in fbForth to start with. And—with the fbForth 2.0 cartridge, all of the graphics words are in the resident dictionary. VRAM space is very limited in bitmap mode—even with fbForth's block buffers in low CPU RAM. If you want to do file I/O in bitmap mode, there's really only room for setting simultaneously open files (SOF) to 2. If you were to actually need file I/O, the best choice would probably be to use a blocks file because, then, SOF can be 1. Furthermore, I/O from blocks files uses the Forth buffers, so there's no need for extra PAB and file buffer space in VRAM.

 

...lee

Link to comment
Share on other sites

I know! How frikken cool is that??!!! But I take credit for none of it. It's been around in the Forth universe for literally decades, waiting patiently for the enlightened few ;)

 

THAT WAS SHOCK AND HORROR! Really now, object oriented assembly... next you'll be asking the assembler to handle memory allocation for you. ;)

 

Actually it's a neat hybrid.. but doesn't the assembly have to be careful not to mess with your register workspace?

Link to comment
Share on other sites

 

THAT WAS SHOCK AND HORROR! Really now, object oriented assembly... next you'll be asking the assembler to handle memory allocation for you. ;)

 

Actually it's a neat hybrid.. but doesn't the assembly have to be careful not to mess with your register workspace?

 

There are free registers that cannot be expected to survive from one word (definition) to the next that are free for use. In fbForth, they are R0 – R7, R11, R12 (unless CRU is used). In TurboForth, they are R0 – R2, R7 – R11, R13 – R15. Of course, you can always do a context switch (LWPI) to use a different set of registers, as long as you switch back before exiting the code for the word you are defining. You can always reach the Forth registers through R13 if they happen to be important for your definition.

 

...lee

Link to comment
Share on other sites

My CALL EXECUTE(cpu-address) in RXB uses that Lee.

LWPI was the only way to allow direct access to Assembly in XB with no problems of messing up registers.

 

The killer cool thing about LWPI is that before you switch you can load all the Registers before the call that way no passing is needed.

 

Like it says in many Computer Language books "The passing of parameters can take more space and speed then having previously set up parameters always predefined."

That means if you have set routines that little use of passing values is needed as the predefined section already has those values.

 

LWPI fits perfectly into that concept and why TI used LWPI in the first place.

 

Moving data back and forth takes time and space we have little of in the TI.

Edited by RXB
Link to comment
Share on other sites

<snip>

 

Moving data back and forth takes time and space we have little of in the TI.

 

I don't agree at all with that. Moving data from one place to the other is the fastest way to do something on a TI. It's faster than any DSR.

 

For example, load Disk Utilities from any device. Use a ramdisk if you want. Then time the load process against the same thing in the 512k Utilities cart, which loads the same thing by direct memory moves from the banked >6000 Rom space. Not even close.

 

Then there's the possibility of increasing the memory of the 512k Rom cart to 2meg, I'm droolin'. :)

 

Gazoo

Edited by Gazoo
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...