0 Members and 5 Guests are viewing this topic.
.db $7F ; says next instruction uses an address relative to the start of the axiom.org $-1 ; since it's only used by Axe at compile time and not included in the final binary, tell the program counter it doesn't exist
Code: [Select].db $7F ; says next instruction uses an address relative to the start of the axiom.org $-1 ; since it's only used by Axe at compile time and not included in the final binary, tell the program counter it doesn't existSame for $49.
.AXE#Axiom(AXEMENUS)Menu(
009E78009E8A3FE69F1B9F1B000000000B3700487F0A0000E60000007BDE
This is usually caused by badly-aligned fields.
You need to add to the size word one for every .org $-1 you wrote in your routine. This is because although PC doesn't take care of the special bytes, they still exist in the axiom (and not in the final Axe program) so they must be taken into account when calculating the routine's size.
It's not Axe that corrupts things. It's the OS. And it's because the token hook definitions are misaligned, so the OS interprets then wrong. It tries to replace non-existing tokens with random strings of random size, so of course it doesn't work.
I tried a stupid program drawing a HLine between X1 and X2 with the three argument version, it didn't seem to do anything. Adding "L6" at the end solved the problem though, but isn't it meant to work if not specified ?
freq(260,0)
I looked at the source of that command and confirmed that it performs no port modulation if the second argument is less than the first. You might just be picking up on noise.
Apparently certain aspects of Axioms have been broken according to this post on CW. The same code compiles on an older version of Axe, but not the newer versions, and it's an Axiom thing. I haven't gotten around to testing to see if it is every axiom or Glib itself, but I thought you should know, since the discussion is going on elsewhere.
Author
Topic: Bug Reports (Read 454411 times)
