TI calculator/Z80 Hobby
-
Start with a character output routine, that prints a character to a serial port, or to the display. Expand that to a string print, then add hex numbers. Now you can add debug statements, without having to single step anonymous code... It's the way I always started with new hardware!
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
-
After BASIC, I lived in 6502 and 8086 assembly language for years, in addition to a smattering of embedded system processors, one of which was a cool extension to the Z80 but I can't remember which one. Even in assembly language though, I never did anything with the Motorola CPU's, 6800, 68000, etc. Contrary to what Robert said, throw away everything you've learned about high level languages. Think in terms of 4 (or is it 2?) puny little variables, a pointer or two, and a whole lot of little cells to put stuff into and grab it out of. Forget structure, if-then-else, switches, loops, etc, and think in terms of signed compares, equality compares, and increments and decrements. Oh, and create a consistent "interface" for subroutines. What registers are the input registers, what registers are the output registers? Personally, I would love to toss out all this object oriented crap and, with enough little subroutines, I imagine I could code just as quickly in assembly. Marc
Marc Clifton wrote:
Motorola CPU's, 6800
Believe it or not, that realization was made two weeks into the endeavor. I also wagered that someone without knowledge of any high-level language could maybe do better at assembly.
Marc Clifton wrote:
Motorola CPU's, 6800
I did some 6800 in college in a random mechanical engineering class I took just for the heck of it. That was fun. Controlled stepper motors, interpreted sensors, etc. Thanks for the guidance. This CP crowd has delivered for sure on this topic.
-
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"
Roger Wright wrote:
You're about to enjoy your profession far more than your peers will ever know...
Roger, you're such a perv :laugh:.
Software Zen:
delete this; -
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 taken up assembly programming as a livelihood. No, really! Anyway, to help lure young men, er I mean new engineers, to my project I use a reverse polish notation calculator (insert Polish joke here) to show how easy fun possible! Try going to Computer Science Lab they have some nice resources for you: http://www.computersciencelab.com/index.htm[^]
-
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 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 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.
Unlike all of you here I guess, being deprived to get genuine high language software, I had no choice but to write my every firmware (starting from Z80 up to IAP Flash MCUs like SST89E58RD) on a text editor. Lately I was fortunate to use "Crimson Editor" and its DOS shell to launch the command line of my very old TASM.exe. Before it, I was using, as a text editor, the last software package I had the right to buy which is the BorlandC 3.1 (which also helps me write DOS programs now to transfer data between PCs and my designed boards via COM or LPT... so now my customers need to drag and drop files on my DOS program icons to update their boards). In brief, you may say, the history of most of you is actually alive on our dear planet... Earth. Kerim
-
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"
