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.
I found when learning FORTRAN 40 years ago, that most of the struggles that people had in learning the language was that they could not break down their ideas into small enough steps. The problem with assembly languages is the same, but maginified even more. A line of code that you might write in a modern computer language may take a page of assmebly instructions. The "trick" for writing assembly was to get very comfortable with what the CPU actually does. Once one begins to think about the capabilities of the CPU and how it really accomplishes the tasks we programmers set it to, assembly becomes easier. Higher computer languages remove us from considering the capabilities of the CPU and have lead to bloat of the operating systems and of our programs.
Clayton
-
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!
-
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!
-
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.
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
-
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.
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!
-
Think in a high level language prior to writing the assembly. You need to understand how to convert the basic high level constructs, if, for, while, switch and the like into the assembly language. It's then just a matter of playing the role of a human non-optimizing compiler by translating each high level atatement into the assembly code.
My first thought is "What are you smoking?" My second is "High level language development has stunted your brain." As a grizzled old programmer who happily flipped front panel switches to load boot programs in the "Goode Olde Days" (which never really existed), the approach of "Think in high level terms and then be a bad compiler" seems totally whacked. Good assembly/machine language programmers are (were) vastly more efficient than the compilers. You know what you want to do, the compiler is only guessing from the hints you give it in high level code. First, you have to understand that the machine is an alien which is not going to learn your language, you have to learn its and think in its terms. I'm also from the "less is more" mindset. I did benchmarks on 6502's, 8080's, Z-80's, etc and found the processors with the lesser number of registers were far more efficient. You didn't stuff a number into a register and then K's of execution later magically whip out a value a subsequent programmer/debugger would have no idea where it came from. In the example of the three registers of the 6502, you used them immediately & with good reason and that made programming and debugging easier. But I must admit I had the most fun programming 386 32 bit assembly (using a FORTH compiler) since you had 4 GB register reach and there were very few (if any) special registers (none of that HL register pair crap or base register addressing that gave you 1024 different ways to specify the same address).
Psychosis at 10 Film at 11
-
My first thought is "What are you smoking?" My second is "High level language development has stunted your brain." As a grizzled old programmer who happily flipped front panel switches to load boot programs in the "Goode Olde Days" (which never really existed), the approach of "Think in high level terms and then be a bad compiler" seems totally whacked. Good assembly/machine language programmers are (were) vastly more efficient than the compilers. You know what you want to do, the compiler is only guessing from the hints you give it in high level code. First, you have to understand that the machine is an alien which is not going to learn your language, you have to learn its and think in its terms. I'm also from the "less is more" mindset. I did benchmarks on 6502's, 8080's, Z-80's, etc and found the processors with the lesser number of registers were far more efficient. You didn't stuff a number into a register and then K's of execution later magically whip out a value a subsequent programmer/debugger would have no idea where it came from. In the example of the three registers of the 6502, you used them immediately & with good reason and that made programming and debugging easier. But I must admit I had the most fun programming 386 32 bit assembly (using a FORTH compiler) since you had 4 GB register reach and there were very few (if any) special registers (none of that HL register pair crap or base register addressing that gave you 1024 different ways to specify the same address).
Psychosis at 10 Film at 11
Nice Brainic. Welcome to CodeProject. My first thought was "What a Douche" I've punched cards, flipped switches, and counted more bytes, bits and cycles than I would care to remember. 30+ years in the embedded software business makes me plenty grizzled. I direct the suns rays with a magnifying glass to etch my code onto the hard drive. The OP was looking for advice on getting started with assembly programming. Starting from a high level construct and working down to assembly is a sound practice that produces well structured, easy to understand, and easy to debug code. Once he masters that he's free to optimize and lobotomize to his hearts content. I've worked with tons of unstructured assembly and it all sucked. It doesn't matter what the language, you start with a sound design, a sensible structure and when you get it all working you go back and twiddle the bits that need twiddling. Of course memory size and the machine's capabilities have loads to do with how clever you have to be to cram 4K of ideas into 300 bytes of memory, but this comes after you have learned the basics. Peace.
-
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 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.
-
My first thought is "What are you smoking?" My second is "High level language development has stunted your brain." As a grizzled old programmer who happily flipped front panel switches to load boot programs in the "Goode Olde Days" (which never really existed), the approach of "Think in high level terms and then be a bad compiler" seems totally whacked. Good assembly/machine language programmers are (were) vastly more efficient than the compilers. You know what you want to do, the compiler is only guessing from the hints you give it in high level code. First, you have to understand that the machine is an alien which is not going to learn your language, you have to learn its and think in its terms. I'm also from the "less is more" mindset. I did benchmarks on 6502's, 8080's, Z-80's, etc and found the processors with the lesser number of registers were far more efficient. You didn't stuff a number into a register and then K's of execution later magically whip out a value a subsequent programmer/debugger would have no idea where it came from. In the example of the three registers of the 6502, you used them immediately & with good reason and that made programming and debugging easier. But I must admit I had the most fun programming 386 32 bit assembly (using a FORTH compiler) since you had 4 GB register reach and there were very few (if any) special registers (none of that HL register pair crap or base register addressing that gave you 1024 different ways to specify the same address).
Psychosis at 10 Film at 11
BrainiacV wrote:
First, you have to understand that the machine is an alien which is not going to learn your language, you have to learn its and think in its terms.
I couldn't agree more. Writing assembler is just different. You don't have all the support of tons of lovely libraries. In some ways liberating because you are forced to focus - in many ways very frustrating. I mean, just implementing multiplication takes a while, so ... you don't when you can get away with not doing it :). I spent 2-3 years in high school programming Z80 machines and wrote assembly directly by "thinking Z80". Never thought in e.g. Pascal first - that would only complicate things. Things were of course easier back in those days because the OS was quite a lot simpler than today. CP/M had a complexity where you could actually remember all the system calls :) . Cheers -- Jan
-
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.