I'm lirtosiast, and I want to start learn z80 assembly and use it as a stepping stone to ez80, which as I understand it will be more relevant in the calculator world nowadays.

Tutorials I've read:

* The first six days of "Learn TI-83 Plus Assembly In 28 Days", properly this time.
* Sundry other resources on z80 heaven and wikiTI, an estimated twenty hours.

Progress in coding / plans:

Done:
* Copy "Hello World" program from 28 Days tutorial, play around with it

Not done:
* Code these programs
* Understand Iambian's cellular automaton algorithm
* Disassemble and understand tr1p1ea's Game of Life program
* Understand some of Xeda's math routines

What I know (will update):

* Binary/hex
* Bitmasking
* The names of registers
* The stack
* 40% of the instruction set

What I don't understand, in no particular order:

* SMC
* Internal workings of the TI-BASIC parser
* Interrupts
* I/O; graphics
* Almost everything not listed.

Tools I plan to use:

SourceCoder to write and assemble any code (I don't know how to use a good text editor, so I'll probably change this when I need to.)

Don't hesitate to point me to an external source if that's the best way to get me the information, because I'll err on the side of asking more questions.

To ease the great burden that explaining things to me will be, I will attempt to give an idea of how my mind works.
I have coded in TI-BASIC for a while, so I'm now familiar with most aspects of the language; I can especially write TI-BASIC math routines and optimize. My other coding skills are insignificant; I have rudimentary knowledge of Java (nothing beyond what the AP Computer Science curriculum teaches), and I'm learning Python (6 weeks in); if I have the time I also want to learn the code-golf langages APL, CJam, and Pyth. I have seven years of competitive math under my belt, so I have strong intuition for mathematical concepts. My goal is to optimize everything I can to hell and back.

I will number my questions for maximum clarity, starting with this:

1) a. The tutorial says #include includes the file you name. Do we therefore need to have the actual file on our machine, or is it included with the assembler? What if we're using SourceCoder?

Great to see you're trying assembly! That reminds me, I should pick up where I left off a few months ago...

In answer to your question: using #include is (kinda-sorta) comparable to importing packages in Java or including a library in C/C++, meaning that you have to have the actual file. Both SourceCoder and the Doors CS SDK come with the necessary files, so just start your program with #include ti8*.inc.
I think KermM's working on allowing you to #include your own files with SourceCoder as well.

I don't know about the #include for the ofline PC, (I pressume you need it in the dev directory?) but I do know that sourcoder already has the ti83plus.inc file, and the cse include file.

See M. I. Wights post above for some more information.

SourceCoder actually already has this feature. Simply add the include file as another ASM program within the project, then include it via #include "THATPRGM.asm". In-browser editing, assembling, and testing of your programs can be quite a boon, I've found.

I can't stress enough that reading a tutorial is not enough to learn a language. In fact, if the choice is between only testing code, and only reading the text of the tutorial, you should always choose the code. Along with a good tutorial, you should test all the code in the tutorial, try tweaking it, find other programs to examine and try to understand, and so on.

Thanks Kerm! I'll be sure to write as much as I can. Right now I'm trying to understand Iambian's 2D cellular automaton code, and write some math routines.

I'm sure I'll have more questions, but some for now:

When I eventually learn enough ez80 to need a testing environment, I don't think I'll need a physical CE, but I definitely want to work on jsTIfied, given the ease of testing.

2a) Will jsTIfied have ez80 support soon?

2b) I want to legally obtain a ROM image; would I be able to dump the ROM from a broken CE (which would probably be cheaper to buy)? Are there any broken CE's yet?

3) Is rlca \ rlca \ rlca \ rlca the fastest way to swap the two nibbles in A?

4) Will it corrupt our calculator if we change register values in a program? (What if we change shadow registers and index registers?) What about OP1-OP6?

5) Do you have suggestions for a first project in z80? I don't want to write a game, as I don't feel I could yet code usefully at that level.

A number of us, including unknownln, Mateo, Eeems, and myself, are working together on this. We all have a lot on our plates and keep forgetting to prioritize it, though, so please nag us (especially UnknownLoner, who has been doing some really cool stuff).

Probably, and no, respectively.

You must disable interrupts before you use shadow registers; no chance of corruption to everything else. As long as you leave the stack at the right level and don't corrupt the VAT, the OS will be perfectly happy when your program ends.

Hmmm, how about something where you move a letter around the screen with the arrow keys?

I've dropped this for a while; been swamped with summer work but hope to start again as soon as possible. However, I have more questions:

6) How does RclAns work internally?
7) Does the order in which variables are created affect their position in the VAT, and thus lookup speed?
Would it be possible to create named lists, programs, etc. that contain non-alphanumeric characters?
9) Day 21 of Asm in 28 Days says "The VAT starts immediately before the end of the hardware stack and is divided into two parts. The first part holds the names of real, complex, matrix, picture, GDB, and equation type variables. This region starts immediately after the Hardware Stack at the fixed address SymTable." I looked it up in the include file, and symTable is $FE66. The hardware stack, according to Day 6, starts just 426d bytes away at $0000, grows down, and is about 400 bytes. Does the VAT then grow down, just like its individual entries?

If you haven't already, I highly suggest you download and keep TI's system routines documentation and developer guide at hand. The former documents many B_CALL's and the latter documents the OS and how to design programs for it in general.

In this case, the answer to your question is right in the documentation of _RclAns, which remarks that the entire code is call AnsName \ jp RclVarSym. Although I guess then you might ask how those work, but neither of their documentation provides any such insight. However, one can fairly safely assume that the implementation of AnsName is trivial and that RclVarSym walks through the symbol table until it finds the variable's entry, and then looks up it data location and copies its value to OP1.


Yes. Although if your program is designed in such a way that variable lookup speed is a significant bottleneck, you may want to consider redesigning your program. But if it's really important, you could manually rearrange entries in the VAT so that the ones you access most appear earliest.


In assembly, definitely, and many programs do this. But don't expect any OS code that does more than look up or create such variables to work correctly. For example, I believe that programs that start with a lowercase letter show up at the bottom of the program menu but the selection cursor skips over them, and programs that start with a character whose value is 0x80 or larger don't show up at all. Other things may or may not work correctly, but you'd probably have to test them yourself.


Yes.