Hey, I'd like to request that the archived file reading method be modified to allow reading from programs in RAM as well. I have an idea as to how this might be accomplished.

Currently, the file byte read routine takes two arguments: an address in HL (any offset is already added in) and a page number in A. If the address is not in the $4000-$7FFF range, it increases the page as much as needed and the pointer is then put into this range.

I'd like to suggest that the routine take three arguments: the start address in HL, the offset in DE, and the page number in A. This takes the load of adding the offset off of the calling code, too. For reads that have no offset, you can make a secondary entry point that loads DE with 0 and runs the routine.

Here's what I suggest for the start of the routine:
  bit 7,h
  add hl,de
  jr z,__inROM
  ld a,(hl)
  inc hl
  ld h,(hl)
  ld l,a
  ret
__inROM:
  ;Archived file reading happens here

And I couldn't figure out how to delete the poll... so I just decided to make a goofy question instead

^.^

I don't think we can.
(after 3 accidental topics with polls attached )

Hey, I'd like to request that the archived file reading method be modified to allow reading from programs in RAM as well. I have an idea as to how this might be accomplished.

Currently, the file byte read routine takes two arguments: an address in HL (any offset is already added in) and a page number in A. If the address is not in the $4000-$7FFF range, it increases the page as much as needed and the pointer is then put into this range.

I'd like to suggest that the routine take three arguments: the start address in HL, the offset in DE, and the page number in A. This takes the load of adding the offset off of the calling code, too. For reads that have no offset, you can make a secondary entry point that loads DE with 0 and runs the routine.

Here's what I suggest for the start of the routine:

Code: [Select]

  bit 7,h
  add hl,de
  jr z,__inROM
  ld a,(hl)
  inc hl
  ld h,(hl)
  ld l,a
  ret
__inROM:
  ;Archived file reading happens here

This is an interesting idea.  However, I think this would bring a lot of overhead into each use of Y1.  There would have to be an additional 2 bytes to push and pop the extra argument.  In addition, Y1 would become more of a special form than before and be difficult to parse.  For instance, now there would be a big difference between {Y1+1} and {1+Y1} in terms of how to process this and you wouldn't be able to do things like {Y1*2} either, not that you generally would, but its an additional restriction.  Another point would be that it might also require modifications to the copy routine as well to be consistent.

I think you'll be able to use sub()^rr in Axioms.

Pleeeeeeeeeeaaaaaaaaaaaaaase give us the ability to retrieve the address of our labels.  That would be absurdly useful for a project I've been working on in my spare time.  (Axe Terminal was a demonstration that shells are possible with Axe... this project is the realization of that idea)
How about using the _L token?  Like _LLB→A to store the address of label LB to A.
I think some features like this can open some doors for more advanced users, while still appealing to the beginner-indermediate crowd.

At the same time, you could add a feature to the Asm() command that allow inserting values like in the Data command, except in the code section instead of the data section. It would greatly increase the capabilities of inline assembly, and Axe might even make a good tool for hex programmers who want to easily use absolute labels and data pointers.