TI calculator/Z80 Hobby
-
I've taken up assembly programming as a hobby that I do at night time for the TI-83/84 calculators which has a Z80 processor. I did some assembly in college years back and have some interest in it again. However, this stuff just does not roll off the fingers like the high level languages I use at work. Does anyone here swim in assembly? Do you have any Jedi mind tricks in use while you code? I have all the needed resources/documentation, so I can figure out how to do anything I need. It is just the molasses between the keyboard and coder that is the problem.
You might find the Z80 simulator at homepage.ntlworld.com/grwilson/IDE.html enjoyable.
-
I've taken up assembly programming as a hobby that I do at night time for the TI-83/84 calculators which has a Z80 processor. I did some assembly in college years back and have some interest in it again. However, this stuff just does not roll off the fingers like the high level languages I use at work. Does anyone here swim in assembly? Do you have any Jedi mind tricks in use while you code? I have all the needed resources/documentation, so I can figure out how to do anything I need. It is just the molasses between the keyboard and coder that is the problem.
Good old Z80 assembler. I did that way back in the 80's. Just a bit better than the I8080. One trick was to zero out all of memeory using as few instructions instructions as possible.
-
I've taken up assembly programming as a hobby that I do at night time for the TI-83/84 calculators which has a Z80 processor. I did some assembly in college years back and have some interest in it again. However, this stuff just does not roll off the fingers like the high level languages I use at work. Does anyone here swim in assembly? Do you have any Jedi mind tricks in use while you code? I have all the needed resources/documentation, so I can figure out how to do anything I need. It is just the molasses between the keyboard and coder that is the problem.
I've written a ton of program for the TI-84(and 83)+ Including some half-baked OS's that only had a command line.. not very useful lol As to Jedi mind tricks.. they're not really needed for z80 IMO - the execution speed is always known in advance, there is no pipelining or other trickery, just a table with "instruction X takes Y clock cycles" (I use the one at asm in 28 days) Oh and use Latenite and Brass instead of notepad and TASM if you want to make your life easier :) Latenite (zip only - has no associated website)[^] Brass[^]
-
I've taken up assembly programming as a hobby that I do at night time for the TI-83/84 calculators which has a Z80 processor. I did some assembly in college years back and have some interest in it again. However, this stuff just does not roll off the fingers like the high level languages I use at work. Does anyone here swim in assembly? Do you have any Jedi mind tricks in use while you code? I have all the needed resources/documentation, so I can figure out how to do anything I need. It is just the molasses between the keyboard and coder that is the problem.
Basicly, as said, you write it all on paper. In those Good Old Days someone mentioned I wrote the adress, the opcode, the hexcode:
0000 MOV A,C2 3E C2
0002 ADI B1 C6 B1
0004 JNZ 0010 C2 10 00
0007 STA 8000 32 00 80
000A .........and so on. As soon as you discover an error and have to insert or remove an instruction, every jumpadress has to be recalculated. Of course, it was a great relieve when I could start to use assembler with symbolic adresses. Otherwise, you create bulletproof subroutines and place them in the beginning so you are certain that THEY at least need no rewriting. The basic programming elements are, as always, Sequence, Choice and Loop. Just learn those three and you can program in any language. That is, if you know how to program, you first make the program in your head, THEN look what languages are available, and choose the one best fit for your task. ( For some strange reason I have never found VB to be the best fit :omg: ) "Nothing exist, everything is opinions"
-
Document the design first and keep it up to date to stay sane! Defining unit tests prior to or concurrent with unit coding can help clarify issues. Use version control! I would typically do top down design: program, package (files), data structures, procedures/functions/routines, data etc. Quite often, uncertainty dictated a bottom up approach for code and debug/unit test. Assuming your development tools support: Start each file and code unit with Header Comments: name, purpose, calling sequence, parameters, caveats/limitations etc. Intermix High level language (or pseudo code) comments with resulting assembly code. Keep code size of procedures/functions etc. reasonable for "your own" head. Use a naming convention which works for you. Three letter abbreviations with dashes or underscores work for me, but I document abreviations in file comments. I prefer jump destination lables that begin same as the routine name with numeric suffixes (get_chr, get_chr10,get_chr20). Keep unit test documentation and code either in same file as unit code (using conditional assembly control) or in a file with a related filename (example: comm.asm and comm.tst). Be ready to refine, redesign and recode. That just proves you are making progress. Check your public library and used book stores for books on assembly language programming. Study any available relevant code. You can get good ideas, even from bad code.
Jack Unger
-
First thing I'd suggest is change from doing Z80 assembler to MSIL assembler (what everything in .Net gets converted to). This will allow you to use a modern debugger (if you can call Visual Studio that) with breakpoints, inspection, immediate window and all the other goodies you're probably missing. It also gives you the ability to use any .Net library/framework code so you don't have to write as much yourself, if you don't want to. The only thing is, there's probably more documentation available for the Z80 than for MSIL. If you're really committed to the Z80, have you looked for some emulators? I wonder if there are some that support a richer debug environment than the tools you're currently using. I haven't gone looking, but am aware that there are some Z80 based emulators (like for the C64 and TRS-80) for the PC. Those packages might have a better environment to work with. Finally, when you talk about the high level languages you use at work, does that include C? Is part of the challenge you're facing from working directly with memory and pointers? If C's &, * and ** operators are foreign to you, then assembly would be much tougher since there's a direct relationship between them. If this is true, as an intermediate step you might try getting really comfortable using pointers in C, where everything else would be more familiar, and then get back into the assembly. Related to this last point, for me personally, I find it's not the code that's hard to track but the memory. I don't print out the code, like others in the thread have suggested, but I do write down a memory map so I know what's pointing where and what values memory contains. Perhaps this might help. Good luck!
Thanks for your ideas. I've got c/c++ background. I think i need to keep pencil and paper for the memory map. That is for sure. I have the zilog zds for writing code and compiling. Then I run the .hex file in the TI calculator emulator. I'd like to find something better. It is not bad. It is just old as dirt.
-
I remember programming the Zilog Z80... moved on to Motorola soon afterwards (6800 and 68000 families). Heck, I even still remember some of the hexadecimals of specific instructions. Wonders of the mind. Grok C9? I always liked to write the code down, pencil and paper. It had to work perfectly in your own head or forget about it. When I became good enough at it, I wrote the simplest IDE so that I wouldn't mess up jumps and such. Debugging? Funny. There was no debugging back when. It crashed or worse. Simple as that. It was another world. Thanks for bringing up the memories... now move on to a modern CPU, unless you have a very good reason to stick to the Z80.
-
Good old Z80 assembler. I did that way back in the 80's. Just a bit better than the I8080. One trick was to zero out all of memeory using as few instructions instructions as possible.
-
I've written a ton of program for the TI-84(and 83)+ Including some half-baked OS's that only had a command line.. not very useful lol As to Jedi mind tricks.. they're not really needed for z80 IMO - the execution speed is always known in advance, there is no pipelining or other trickery, just a table with "instruction X takes Y clock cycles" (I use the one at asm in 28 days) Oh and use Latenite and Brass instead of notepad and TASM if you want to make your life easier :) Latenite (zip only - has no associated website)[^] Brass[^]
-
Basicly, as said, you write it all on paper. In those Good Old Days someone mentioned I wrote the adress, the opcode, the hexcode:
0000 MOV A,C2 3E C2
0002 ADI B1 C6 B1
0004 JNZ 0010 C2 10 00
0007 STA 8000 32 00 80
000A .........and so on. As soon as you discover an error and have to insert or remove an instruction, every jumpadress has to be recalculated. Of course, it was a great relieve when I could start to use assembler with symbolic adresses. Otherwise, you create bulletproof subroutines and place them in the beginning so you are certain that THEY at least need no rewriting. The basic programming elements are, as always, Sequence, Choice and Loop. Just learn those three and you can program in any language. That is, if you know how to program, you first make the program in your head, THEN look what languages are available, and choose the one best fit for your task. ( For some strange reason I have never found VB to be the best fit :omg: ) "Nothing exist, everything is opinions"
-
You might find the Z80 simulator at homepage.ntlworld.com/grwilson/IDE.html enjoyable.
-
Put on your state machine hat and be prepared to use a lot of state transition diagrams. Pencil and paper are definitely required tools. I started by writing an assembler and O/S for the Intel 8080, and thought the Z-80 was God's gift to programmers. It was a generational advance over what I learned on. Draw a register map, and copy it many times. Ditto for a memory map. Do your initial designs in RTN (Register Transfer Notation) and make copious notes about each step on separate pages. Insert highlighted memory and register map pages as needed to see what you're doing to each. On each sheet, write notes to yourself about what you are trying to do, because you'll forget tomorrow. It's tedious, but far more rewarding intellectually than drawing cute pictures with the Windows APIs. Have fun! You're about to enjoy your profession far more than your peers will ever know... :-D
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
Niiice. I'll check out these tools. I *might* return to this sub thread in the future for a follow-up. Thanks for your ideas. There really isn't an assembly forum in this site IIRC.
Here's one: MaxCoderz[^] The author of Latenite and Brass hangs out there too - and even the author of PindurTI (popular TI-83+ emu) and the author of WabbitEmu (best TI-83+ emu IMO) btw, the official "flash debugger" by TI has many bugs - so bad that you can't reliably debug on it (code that works on it can fail on hardware and vice versa)
-
Here's one: MaxCoderz[^] The author of Latenite and Brass hangs out there too - and even the author of PindurTI (popular TI-83+ emu) and the author of WabbitEmu (best TI-83+ emu IMO) btw, the official "flash debugger" by TI has many bugs - so bad that you can't reliably debug on it (code that works on it can fail on hardware and vice versa)
-
I'll just paste what I said above. During debug "i really don't know where the !@#$ I am a lot of times while I step through the instructions, since my nice labels are removed at compilation time."
-
Abhinav S wrote:
puromtec1 wrote: assembly programming as a hobby Why don't you pick up a hobby which has something to do with the outdoors instead?
Extreme assembly half way up a mountain?
Help me! I'm turning into a grapefruit! Buzzwords!
