Simply, you may do that:
- allocate byte in scratchpad:
DATA MYBYTEmov MYBYTE,#15

- allocate some bytes:
DATA MYBYTES,4mov R0,#MYBYTES

- define a bit flag:
FLAG BLINKjnb BLINK,.m1

The idea is in defining RAM areas: The stack is placed above flags area (bit-addressable locations), free memory is limited with ram top (7Fh) and ram bottom (top of the stack).
Implicit allocation gives some insurance of not overlapping of data with checking for crossing boundaries, if there is an insufficiency of resources the warning will be flagged - then some rearrangement can be performed.

Also there is a macro for easy selection of the bank of registers:
SELECT_BANK 1
keep in mind that this selection does not preserve previous bank settings, so, PUSH PSW/POP PSW in procedure must be present to restore bank on return.

also, there is an orgx - a variant of org with aligning, usefull for binary output

These are some interesting subjects for a macro design. Just as an exercise I made a different variant of the DATA macro that allows to defined data in virtual blocks and preserves the order of defined variables in memory, while still allocating them off the top of the 30h-80h area. The new feature of VIRTUAL block continuation (implemented both in fasmg and fasm 1) is perfect for this:

The main difference in logic is calculating of DATA_BOTTOM: DATA_BOTTOM is similar to STACK with STACK_SIZE offset, but STACK now is LAST_FLAG_ADDR, so, bit-addresable bytes unused for flags are now wasted, stack is shifted in their area and area for data is increasing.
It looks as it works, but there is a problem appeared: it does not work with listing macro :S Thus, I've got some proofs through monitor program (see picture).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum