TI calculator/Z80 Hobby
-
I like the idea. The main issues revolve around the craptastic Zilog Developer Studio not letting my wheel scroll the page and also, when debugging in the TI-83 emulator, 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.
You use a mouse to program Z80? When I were lad we used switches and we were grateful...
-
Wow,
Z80assembly is wonderful, IMHO far better than6502derivatives! Enjoy yourself programming it. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]I hope you're not trying to spark a religious war! My BBC is most certainly better than your Spectrum :-P
-
I hope you're not trying to spark a religious war! My BBC is most certainly better than your Spectrum :-P
Russell Jones wrote:
I hope you're not trying to spark a religious war!
We don't need. War is over. We've won it. ;P
Russell Jones wrote:
My BBC is most certainly better than your Spectrum :-P
Maybe. However the ZX made me a Klingon Developer. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Wow,
Z80assembly is wonderful, IMHO far better than6502derivatives! Enjoy yourself programming it. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
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.
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
-
Thanks. There are actually some good resources for those translations online. The trouble I run into is when I attempt to wing it myself and then realize that the "ld" command does not work with every combination of registers that exists like the one I had happened to type. My real beef is with the ancient IDE I am using and weak debug tools.
puromtec1 wrote:
IDE
puromtec1 wrote:
debug tools
You've been spoilt by these modern nancy boy tools and languages!
Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
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.
