This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Iambian
766
« on: April 10, 2007, 10:27:00 am »
I've been around the dragonfire IRC network for as long as the server ever got started, and even some time before that. I've visited the channel #omnimaga, but I've never really joined the forum. Then I found this curious link on UnitedTI and I decided to have myself a look. Then after posting a few things here, I saw this "Introduce Yourself" thing. And so... I get to say...
Wazzu... er... hi.
767
« on: April 10, 2007, 10:16:00 am »
Size and speed optimization: If you make an unconditional CALL prior to a RET, you can replace that CALL with a JP instruction (since you're then going to be using that calling routine's RET). This won't work if the calling routine doesn't exit out using a RET, but that's up to you to decide. But if it works, that's one byte saved by not having to use a RET. If the calling routine is local enough, you can save another byte by using the JR instruction instead. i.e. c1--> | CODE | ec1 CALL Someroutine
RET
;more code
Someroutine:
XOR A
RETc2 |
ec2
can be condensed to this:
c1 --> | CODE | ec1 JR Someroutine
;more code
SomeRoutine:
XOR A
RETc2 |
ec2
If you can rearrange the code to make "SomeRoutine" appear right after the calling routine, you can save two more bytes by omitting JR altogether.
In this respect, it may do you some good to rearrange your ASM code to take advantage of this kind of optimization. Of course, you're going to have to be wary about errors resulting in the use of JR.
Oh, and as a response to the previous post that made a size optimization using a "LD A,(DE)", it's not exactly the same as using two NOPs. The "LD A,(DE)" is faster by one clockcycle. I understand that this is negligible, but I just wanted to point that out.
768
« on: April 10, 2007, 10:09:00 am »
QuoteBegin-calc84maniac+10 Apr, 2007, 7:28--> | QUOTE (calc84maniac @ 10 Apr, 2007, 7:28) | I use Omnicalc's Ram Recovery so I don't have to archive everything.   |
There will soon be a program that'll compete with the same RAM space that Omnicalc uses for RAM Recovery. But that's on a different topic.
I also use Calcsys to inspect memory addresses and areas around where a utility should've edited. I do this so that variables unreadable in the BASIC editor would be readable through this. I mean, I do want to make sure that what I wrote creates and edits in the proper fashion. This also helps in debugging.
769
« on: April 10, 2007, 10:05:00 am »
Is it too late to add in characters to the game? Since I only joined the forum recently... but I have been around nearly forever on IRC (dragonfire network).
I'd like to be some kind of dragon-like NPC that would teach related special techniques and provide "rare items" to those "qualified" to use them. For qualification, perhaps a boss battle or some kind of mini game?
Heh. Just a thought. But if you do decide to do it, and still need other stuff to go on, try using any the following stuff:
IRCop on dragonfire, is cherry-flavored, decent Z80 ASM programmer, obsessive-compulsive, minimalist, white and fuzzy, loves to play around, talkative on certain topics, always carries a USB flashdrive, loves Chinese and Mexican foods, somewhat insane, sometimes is random.
770
« on: April 09, 2007, 03:25:00 pm »
QuoteBegin-Insanity+9 Apr, 2007, 20:5--> | QUOTE (Insanity @ 9 Apr, 2007, 20:50) | | Even ASM? What about crashes? That's a lot of archive writes to have to back up every time before you test out a change to your program... (correct me if I'm wrong) |
*ESPECIALLY* ASM programs. Besides, the reasonable things you'd be editing would be numerical boundries and such. The chances of causing a crash if you're aware of what you are doing are small if you know you're doing something that won't cause such a thing. Now, if you were doing something that you know might cause a problem, then I can see where you're getting at.
But the kind of editing that I normally do are safe. If I do something that crashes the calc, then I know the next time I go back to the computer to make a certain change. You see, the most valuable aspect of debugging an ASM program is to make sure that the calc crashes if anything goes wrong. If it doesn't crash, then the programmer remains oblivious to any potential problems that may be experienced.
771
« on: April 09, 2007, 09:53:00 am »
I'd like to say "HI!" since it's my first (real) time I've posted on this board. Just had to try it out after registering But at any rate, I can disassemble just about anything for you. Or I could just upload to my site the utility that I used to perform the disassembly with. The latter is much more fun, since you absolutely *have* to use Calcsys to get it to do what you want, plus you have to "prime" the program in order for it to create what you need to change. (see! it's somewhat on topic!). For the utility, just make sure you have enough free ARC since the disassembly files are dumped there per iteration. Then, it's your responsibility to send to your computer to format and put in a text file. I have an mIRC script for that purpose. Usually, I use Calcsys to do quick references, such as how many bytes I need to skip in an archived variable before I can get to read the program data, what the keycodes are for the particular key(s) I need, find out what Celtic can do if I just modify the symbol table myself, edit a few things in preexisting projects when I have no computer to recompile and send to my calc, among other things. For the ASM developer, Calcsys is indispensible. It is just as much as a friend as Google is. Perhaps even moreso.
|
Show Posts