Author Topic: help with my Axiom  (Read 2890 times)

0 Members and 1 Guest are viewing this topic.

Offline bored_student

  • LV3 Member (Next: 100)
  • ***
  • Posts: 44
  • Rating: +3/-0
    • View Profile
help with my Axiom
« on: October 05, 2013, 06:11:34 am »
Hi
I'm making an Axiom for Axe and something with the REP_NEXT macro doesn't work
Code: [Select]
.dw AXM_4_END
 .db AXM_NONAPP
 .db tok_Scan,0
 .db AXM_SUB
 .db AXM_2ARGS
 .org 0
 ...here comes some asm-code
 ex de,hl
 REP_NEXT ;this is .db $7F / .org $-1
 ld hl,_4entry
 ex (sp),hl
 push hl ;jump to (hl)
 ret
_4entry:
 ...here comes some code again
 ret

 .org $+1 ;I though you should increase the program origin to match the real size
AXM_4_END:

.dw AXM_END

after this code there are the token replacements
they don't work in this case but when I leave the REP_NEXT and the .org $+1 they work without any problems
Sorry for my bad English, I'm German.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: help with my Axiom
« Reply #1 on: October 05, 2013, 11:56:39 am »
This has always been a bit of a design issue with the current Axiom system. The .org $-1 in the REP_NEXT macro ensures that the program counter variable is correct for the rest of the command when the 1 byte from the .db $7F is removed during compilation. However, subtracting one from the program counter variable has the side effect that, at the end of the command, the program counter will be [# of REP_NEXT's used] less than the actual size of the command's source code, which includes .db $7F bytes from REP_NEXT instances. This means that the common way of including the size of the command in the header by just putting a label at the end of the command and using that as the size (provided you start the command with .org 0) will result in the size value being [# of REP_NEXT's used] too small.

Solution: The simple but dirty solution is to simply count the number of REP_NEXT's used in the command and add that to the size value in the header, which in your case would be .dw AXM_4_END+1. Also, if you ever use any OFS_NEXT(#) macros, make sure to add 2 for each of those used.
« Last Edit: October 05, 2013, 12:10:36 pm by Runer112 »

Offline bored_student

  • LV3 Member (Next: 100)
  • ***
  • Posts: 44
  • Rating: +3/-0
    • View Profile
Re: help with my Axiom
« Reply #2 on: October 09, 2013, 05:25:44 am »
I did think about that solution before, but it didn't work either.
So I put a  ".org $+1"  just before the  "AXM_4_END:"
Shouldn't that work too?  :-\
« Last Edit: October 09, 2013, 05:26:08 am by bored_student »
Sorry for my bad English, I'm German.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: help with my Axiom
« Reply #3 on: October 09, 2013, 09:26:21 am »
It seems like that should work... Make sure that your Axiom is an appvar and not a program, as token replacements won't work for the latter. You can convert Axioms in program form into appvar form by either manually editing the type byte on-calc with a hex editor like Calcsys, or simply including the Axiom in an Axe program and compiling it.

If that's not the source of the problem, what happens if you manually insert .db $7F \ .org $-1 where the REP_NEXT should be? I'm wondering if it's possible that your assembler is parsing it as the REP_NEXT(x) macro instead, which works slightly differently. I think my assembler (SPASM) had problems with that, which I temporarily fixed by renaming REP_NEXT(x) to OFS_NEXT(x) next in the include file, since what it really does is replace the next value plus the given offset x.

If that doesn't work, I don't have any immediately clear suggestions. In that case, could you possibly post or privately send me the full code of the Axiom so I can try to debug it?

Offline bored_student

  • LV3 Member (Next: 100)
  • ***
  • Posts: 44
  • Rating: +3/-0
    • View Profile
Re: help with my Axiom
« Reply #4 on: October 12, 2013, 01:03:45 pm »
Thank you a lot  ;D
I will try it. But for now it isn't a problem anymore because I found
a way to write the code without the 16bit load command.
« Last Edit: October 13, 2013, 10:15:37 am by bored_student »
Sorry for my bad English, I'm German.