Intybasic and JPL paging

[artrag]

Is there a way to know in intybasic which JPL page is hosting a given label ?

I see that the information is generated in the LST file, just after the address of the data falling in the pages

I would get the same information in order to code a macro like this

 

set_page(Select_options)    

as equivalent to 

set_page(2)    

 

where Select_options: is in page 2

ASM ORG $A000:2

 

Would it be possible ?

 

Is there in at least in ASM an operator that returns the rom page of a given label ?

 

[+DZ-Jay]

2 hours ago, artrag said:

Is there a way to know in intybasic which JPL page is hosting a given label ?

I see that the information is generated in the LST file, just after the address of the data falling in the pages

I would get the same information in order to code a macro like this

 

set_page(Select_options)    

as equivalent to 

set_page(2)    

 

where Select_options: is in page 2

ASM ORG $A000:2

 

Would it be possible ?

 

Is there in at least in ASM an operator that returns the rom page of a given label ?

 

I'm afraid that there is no such information available from the assembler pre-processor, much less the IntyBASIC language.

 

What we typically do in assembly language for this sort of case is to track the current page in an assembler symbol.  You wrap all your segment switches with a macro, and have the macro keep track of the state by persisting the parameters in assembler symbols.

 

In fact, this is what Joe Z.'s excellent CART.MAC macro library from the SDK-1600 does to abstract ROM segment and page-flipping:  It keeps track in array symbols the usage of each segment and page and, given a capacity size, uses it to determine which one to use next.

 

You won't be able to do this with IntyBASIC macros, since they do not support the ASM directive; but you can do it from assembler macros.  The macro below does this in a very simplistic way.  It defines an array of constant symbols containing the starting address of five ROM segments, and then takes a segment and page number to switch the segment.

 

It then keeps track of the current segment and page selected.

; Structure to manage ROM segments
_rom             STRUCT
                 ; Current state
@@curr_seg       SET 0
@@curr_pg        SET 0

                 ; Default segement starting addresses
@@segment[0]     EQU $5000
@@segment[1]     EQU $A000
@@segment[2]     EQU $C040
@@segment[3]     EQU $2100
@@segment[4]     EQU $7100
                 ENDS

; Macro to set the current ROM segment and page
; Given a segment number, it will use one of the
; starting addresses defined in the table above.
MACRO SetRomSegment(segment, page)
   ORG _rom.segment[%segment%]:%page%

                 ; Update state
_rom.curr_seg    SET %segment%
_rom.curr_pg     SET %page%
ENDM

 

Note that for this to work, you will have to avoid calling "ASM ORG" on your own, and always use the macro so that it can keep track of the state.

 

The CART.MAC library goes quite a bit further than this, keeping track of the usage of each segment by computing the difference between the current Program Counter value (accessible from the assembler using the symbol "$") and the starting segment address.  It maintains all this state in assembler symbols, and then gives you insight into the available space on each.

 

It also performs bounds checking to alert you when you have overflown a segment, and has the capability that, given a block size, it can pick the first available segment with enough capacity to fit it.  It's the best thing we have for memory management without a proper linker.

 

In my P-Machinery framework I do something similar, although it doesn't support page-flipping at this point.

 

If this is the sort of thing you are looking to do, you may be better off taking a look at CART.MAC and seeing how you could integrate it into your IntyBASIC program.  I believe Joe Z. has done this in the past for other projects, so I know it is possible.

 

     -dZ.

Edited July 19, 2021 by DZ-Jay

[+nanochess]

IntyBASIC only knows the address of the label. 

 

You need to handle manually the number of each page, and switch it before calling your procedure.