Jump to content
  • 0
rje

Generating a Memory Map "on the fly"

Question

Because we have MEMTOP and MEMBOT, I can write a little assembly routine that generates a partial memory map "in situ":

Quote

top_lo: .byte 0
top_hi: .byte 0
bot_lo: .byte 0
bot_hi: .byte 0 

ram_bank: .byte 0

Main:
sec ; set carry flag
jsr memtop
stx top_lo
sty top_hi
sec ; just in case
jsr membot
stx bot_lo
sty bot_hi
lda $9f61 ; will be $0000 with r38
sta ram_bank

rts

Since the X16's I/O and bank locations are fixed, I can hard-code those, and query for the current active banks.

Ideally, register loads will also get dumped to low RAM, but currently, well...

Is there anything else I can do to determine the current memory map of a running X16?

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

13 answers to this question

Recommended Posts

  • 0

The ROM build already generates maps, but not a single map, because the ROM is not just a single program. If you look in the build directory, you will see several .map files, one for each component. If you look in kernal.map, you will find the segment listing that starts like this:

```

Segment list:
-------------

Name                   Start     End    Size  Align
----------------------------------------------------
ZPKERNAL              000080  000087  000008  00001
ZPCHANNEL             000088  00008F  000008  00001
ZPFONTS               000090  000091  000002  00001
KVAR                  000200  000267  000068  00001
VARCHANNEL            000268  000293  00002C  00001
VARFONTS              000294  0002B9  000026  00001
KERNRAM               0002C4  0002E3  000020  00001
GDRVVEC               0002E4  0002FF  00001C  00001
KVECTORS              000314  000333  000020  00001
KVAR2                 000334  00038A  000057  00001
KERNRAM2              00038B  0003C9  00003F  00001
KVARSB0               00A000  00A0EE  0000EF  00001
EDITOR                00C000  00C6F7  0006F8  00001
SCREEN                00C6F8  00C966  00026F  00001
KBDBUF                00C967  00CA99  000133  00001

```

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

You could parse the assembly source code files and build a map of the variables, entry points, and jump tables.

That's something you'd only need to do once, per release, but it would be handy information. 

Edited by TomXP411

Share this post


Link to post
Share on other sites
  • 0

If you are using ca65, no need to parse the source, just generate a memory map at link time with the -m argument for cl65

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
1 hour ago, SlithyMatt said:

If you are using ca65, no need to parse the source, just generate a memory map at link time with the -m argument for cl65

That's good to know, thanks. 

One of the things that's been holding me back from working on software in the emulator is not having a memory map and having to re-calculate things with each ROM revision. 

For example, my menu program writes a load and run statement to the screen, then pushes two Returns into the keyboard buffer. Since I'd have to revise it with every new version of the ROM, I'm waiting until the ROM is stable before finishing the re-write. Having a good memory map would certainly help with that.

 

Edited by TomXP411
  • Like 1

Share this post


Link to post
Share on other sites
  • 0
18 hours ago, SlithyMatt said:

If you are using ca65, no need to parse the source, just generate a memory map at link time with the -m argument for cl65

Anyone done this for the current ROM version? I have compiled the current rom, but did not try the memory map thing

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, SlithyMatt said:

The ROM build already generates maps, but not a single map, because the ROM is not just a single program. If you look in the build directory, you will see several .map files, one for each component. If you look in kernal.map, you will find the segment listing that starts like this:

```

Segment list:
-------------
Name                   Start     End    Size  Align
----------------------------------------------------
ZPKERNAL              000080  000087  000008  00001
ZPCHANNEL             000088  00008F  000008  00001
ZPFONTS               000090  000091  000002  00001
KVAR                  000200  000267  000068  00001
VARCHANNEL            000268  000293  00002C  00001
VARFONTS              000294  0002B9  000026  00001
KERNRAM               0002C4  0002E3  000020  00001
GDRVVEC               0002E4  0002FF  00001C  00001
KVECTORS              000314  000333  000020  00001
KVAR2                 000334  00038A  000057  00001
KERNRAM2              00038B  0003C9  00003F  00001
KVARSB0               00A000  00A0EE  0000EF  00001
EDITOR                00C000  00C6F7  0006F8  00001
SCREEN                00C6F8  00C966  00026F  00001
KBDBUF                00C967  00CA99  000133  00001

```

Ahh okay, great. understood.

So in this example ZPKERNAL has 8 bytes reserved in ZP from 80 to 87. what is stored in this area?  Is there a more details listing of what is exactly mapped in each ZP/Address?

 

 

Share this post


Link to post
Share on other sites
  • 0

If it's an exported label within the code, it will show up in the map. Otherwise, you'll need to look through the source.

Share this post


Link to post
Share on other sites
  • 0

Look in the "*.sym" files.  They have addresses and symbol names.  (They're designed to be read by a debugger.)

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Hi all, 
I created a ZP Map from the .sym files in excel and also for all the individual .sym files (e.g. BASIC and others). So you can now search for symbols, sort the list (to be an ordered list by address etc.) and do other stuff with it.

The Map enables you to convert from older releases of the ROMs (and EMU) to the current versions. Esp for the BASIC programs where people are poking in some ZP addresses and you have no clue what it was for and where it is now. 

Inside the excel you will also find the full rom.sym map of R34, so you can search here for addresses and look the symbol up in the other table ..

Memory Map R38.xlsx

Share this post


Link to post
Share on other sites
  • 0
On 8/14/2020 at 9:14 PM, TomXP411 said:

One of the things that's been holding me back from working on software in the emulator is not having a memory map and having to re-calculate things with each ROM revision. 

For example, my menu program writes a load and run statement to the screen, then pushes two Returns into the keyboard buffer. Since I'd have to revise it with every new version of the ROM, I'm waiting until the ROM is stable before finishing the re-write. Having a good memory map would certainly help with that.

The ROM is designed in a way that (unlike on the Commodore 64), it should not be necessary to read/write any magic zero page ($0080-$00FF) or KERNAL ($0334-$03FF) variables.

Well, at least this is the plan. I'm aware that not everything that people want to do is possible just using API calls. Whenever you run into this, please file an issue on GitHub against x16-rom.

In this case, what you want is an API to inject keys into the keyboard buffer, which is a fair request. File an issue! 🙂

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, Michael Steil said:

The ROM is designed in a way that (unlike on the Commodore 64), it should not be necessary to read/write any magic zero page ($0080-$00FF) or KERNAL ($0334-$03FF) variables.

Well, at least this is the plan. I'm aware that not everything that people want to do is possible just using API calls. Whenever you run into this, please file an issue on GitHub against x16-rom.

In this case, what you want is an API to inject keys into the keyboard buffer, which is a fair request. File an issue! 🙂

To be honest, I did not know what this ZP is or why you would need it. I just patched a BASIC program to run under r37+ of the emulator and there was one poke in it. As I had no clue what it actually does, I looked up the old memory address (as of r34 and translated it to the new location). I am no friend of such pokes as it makes the reading of the code painful and currently unstable (things change currently).

I simply removed it now. Still do not understand what the AIM of the orignial programmer was, cannot see any reason to use it.

Share this post


Link to post
Share on other sites
  • 0

I had a quick look at the sym files but I don't understand how it works.

For instance, when looking for GRAPH_set_colors I see this:

Quote

 

build/x16/basic.sym
110:al 00FBD9 .GRAPH_set_colors

build/x16/kernal.sym
11:al 00E18E .GRAPH_set_colors
1149:al 00E18E .GRAPH_set_colors

build/x16/monitor.sym
135:al 00FC37 .GRAPH_set_colors

 

Three different addresses. However from the documentation it reads that it should be $ff29  - another address again.

Can anyone shed some light on this?  

Share this post


Link to post
Share on other sites
  • 0
7 hours ago, desertfish said:

For instance, when looking for GRAPH_set_colors I see this: [...] Three different addresses. However from the documentation it reads that it should be $ff29  - another address again.

GRAPH_set_colors is a KERNAL API, so there is an entry in the KERNAL jump table for it ($FF00-$FFF3), so that it doesn't matter where the implementation is located.

$E18E in the KERNAL symbols points to the implementation, which will change in every new ROM version. The symbols in in BASIC and MONITOR are helper functions that bank switch to the KERNAL bank and call $FF29. They will also change with every version.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use