The United-TI Forum is Read-Only.

Goto page Previous  1, 2

25 Mar 2009 05:15:22 pm by Galandros
Galandros wrote: Ok. I will add soon the nspire compatibility and better instruction set of the z80 I found in OTBP that calcmaniac told me in IRC. Finding it was hard, but it was on my hard drive. I have been seeing Revsoft and Maxcoderz foruns so new links will appear. Also I feel like understanding and doing an tutorial to access multi pages APPS. It is a common question that I hope to get rid of. :P This reply acts kind of a to do note so I won't forget... xD VERY LATE EDIT: why not make a more general apps tutorial/guide. It is intended to be quick to shows and explains a bit about multi pages, header, alocating problems, etc.. a, I lost track of the instruction set. I know calcmaniac84 shared in IRC and I have one copy in my computer. It is very good because has everything and in one papper! Lots of tile mapping links added. I have also links for grayscale in 84/84 links but keep them for me. The tutorial is queued. gamedev.net and wikipedia are trusty sources of algorithms and/or techniques so enjoy them. EDIT: edited a Portuguese word

25 Mar 2009 05:32:10 pm by simplethinker
Here's one that I use. It's basically the tab file with T-states and slightly clearer argument explanations. The right-most column is the number of T-states. [attachment=2618:tab.txt]

03 Jun 2009 04:36:05 pm by Galandros
Before I forget, writing down notes here: Initial errors and debug: This things can freeze a calculator (it does "nothing") - loop forever (most times caused by the counter that is destroyed in some routine) - code execution gets out of your program area and enter into data or RAM page not to execution. (eg. in a apps I let the pc go behind the $8000 and so enters in a RAM page which has code execution protection, all because I forget a ret in a subroutine) Also I saw a nifty debug macro for spasm (I don't know about tasm) .echo > breakpoints.brk "\n" #define break() .echo >> breakpoints.brk $ To use just write break() and you find the pc to toggle the breakpoints in emulator. Easier than searching yourself the code in the debugger. Instead of seeing register in every breakpoint, a group of defines output some registers content to a log/buffer in safe ram. This won't work if the code crashes very hard. But when doing freaking math, investigating some routine output or other task that doesn't crash that hard, can be semi-useful. (breakpoints also do the job) Would worth to anyone this asset of routines to easily output to a safe ram some registers? They will all preserve registers. Its use would be like: init_log() ;initialize saferam by putting a zero on the first byte. That byte says how many 8-bit registers are in the log ;code log_de() ;de will be put into a safe ram and preserves all registers ;some more code log_a() ;ouput a this time ;etc.. I can do this if there is interest.

05 Jun 2009 11:23:36 am by Mapar007
Man, I feel I should really try Spasm 2... Which emulator do you use?

05 Jun 2009 01:09:54 pm by Galandros
Mapar007 wrote: Man, I feel I should really try Spasm 2... Which emulator do you use? wabbitemu. Unfortunately the debugger isn't finished... I have TI-Flash Debugger ready, too. I will try PindurTI today, I hope. EDIT: ah now I know why pindurti didn't worked to me. I tried to run a 84SE on it... Ugh, a working debugger, I should have used that before... Adds links >_> (Cemetech useful z80 routines (BASIC execution, I searched that one day without success), pindurti and wabbitemu)

05 Jun 2009 02:52:24 pm by magicdanw
I love PindurTI's debugger. I hope Wabbitemu gets at least all of the features that PTI has, if it plans on becoming a good tool for development and hackery

10 Jul 2009 11:31:09 pm by DigiTan
I know it's been said before, but I've been doing a ton of accidental ld a,(6)'s instead of in a,(6)'s. Even when you know it's wrong, those are tough to avoid!

03 Aug 2009 02:16:43 pm by Galandros
DigiTan wrote: I know it's been said before, but I've been doing a ton of accidental ld a,(6)'s instead of in a,(6)'s. Even when you know it's wrong, those are tough to avoid! That and something like: ld e,(xxxx) Only "a" register is valid. >.<" darkstone knight already said this but doing this would ease my coding sometimes... xD Yeah, I have been doing some z80 assembly and it is not that fun, at least for now. 4 lines or more of code/instructions to do what in most common languages you accomplish in 1. I only continue to see if seeing the shining result deserves my constant desespere while coding z80 assembly. Starting doing notes could help me... But when I am on a computer, paper and pencil seems always so far away and ridiculy I have them prepared without knowing... -.- I waste too many time thinking how to do things right (how array must be organized, how to implement things) and then see code and rewrite it.

26 Aug 2009 02:30:49 pm by Mapar007
Z80 is definitely my favorite language... I LOOVE the direct hardware control. It is so concrete, which, of course, has its advantages and disadvantages.

27 Aug 2009 08:26:22 am by simplethinker
There's another error in ASM in 28 days that I don't think has been posted here. The getpixel routine in day 24: Code:    AND   7    LD    A, $80    RET   Z    LD    B, A should be Code:    AND   7    LD    B, A    RET   Z    LD    A, $80

27 Aug 2009 12:30:59 pm by calc84maniac
simplethinker wrote: There's another error in ASM in 28 days that I don't think has been posted here. The getpixel routine in day 24: Code:    AND   7    LD    A, $80    RET   Z    LD    B, A should be Code:    AND   7    LD    B, A    RET   Z    LD    A, $80 Actually, it really should be: Code:    AND   7    LD    B, A    LD    A, $80    RET   Z

22 Dec 2009 10:38:01 pm by hotdog1234
I don't know if this one has been mentioned, but constants and labels cannot start with a number

23 Dec 2009 06:25:18 am by Mapar007
Actually, that depends on your assembler, but yeah... At least, it's bad style.

22 Jan 2010 01:02:16 pm by Galandros
You should bug me to update this... I have things to add and modify. :biggrin:

06 Apr 2012 11:22:06 am by jammasterz
I have a few tips that ive come up with. Good programming habbits: 1. Start by writing helping routines like displaying, keychecking and so on, and then use them in your code. 2. Do not optimize your code when its not done. Even though you know that XOR A is fatser than LD A, 0, use the other one, to avoid bugs and then when its fully tested- optimize it step by step. 3. If youre saving something to a specific memory location, try not using magical-variables. For example if you check some value at some address few hundread times in your code, and then you decided to change the adress, you have to change the code in few hundread places. Also it is very probable that you will make a typing mistake. Thats why i recommend using equates for adresses, for example variable .equ $9875 4. Even if you think its silly, do it. When you execute RET insturction, the calculator will jump to the adress that is on top of the stack. If you push something onto it, and forget to pop the calculator will most likely crash. I know its easy to count the amount of pushes and pops, but its not allways this easy. What i want you to be careful about is jumps within a routine. If you for example push something onto the stack in the beggining of the routine and the pop at the end there is no problem. But it may happen that you put a JP or JR instruction between PUSH and POP, which will cause the calculator to SKIP the POP instruction if a jump has occured. This is really important, and currently most difficult bug to find. I think everything else has been mentioned. Easy debugging method There is a very easy method to debug with, it may had been mentioned but ill explain anyway. If your program crashes do like this: 1. Remember exactly what youve done. 2. Then look at the code and simulate what happens in your head. Its definitely much harder if you used someones routines because you dont know what is happening inside them. Try reading routine documentation. When simulating its allways good to keep track of the stack on a piece of paper.

The United TI Forum is Read-Only.

Goto page Previous  1, 2