Another doubt about custom memory map

ZX80, ZX 81, ZX Spectrum, TS2068 and other clones
Post Reply
fraespre
Member
Posts: 56
Joined: Mon Aug 19, 2019 8:08 pm

Another doubt about custom memory map

Post by fraespre »

Hi guys,

Starting to explain my doubt, I have to say that I have done the change described here:
https://www.z88dk.org/wiki/doku.php?id= ... es:sp1_ex1
Specifically in the "Changing the Memory Map" section. It's exactly the same changes, using "heap.asm" with same values and memory locations.
And everything works correctly ;)

Besides, I have thought the idea to take advantage of that memory heap slot (5 kb). I would like to locate some piece of code (not only data) into it. Something that will only executed once like a game intro, and it will be overwritten by the heap after, when the game starts.

So, I tested to put the "org" directive ( viewtopic.php?f=2&t=11567 ) into of specific module (a c-file joined by import directive) of my game, hoping that only c-module was located in the "org" position (into the heap) and the rest of code still follows in the same place.
( I know, I was very naive :p )

But two problems has appeared:

1.- Linker doesn't like the overlap.

Code: Select all

Error: Section LOWMEM overlaps section code_compiler by 4206 bytes
Error: Section code_compiler overlaps section CODE by 1707 bytes
zx: Aborting ... one or more binaries overlap
2.- The memory map is not correct.
Watching the memory allocations, I realized the linker has moved all compiled_code to the "org" location, instead of only the specific c-module as I wanted.

-------------------------------------------

Is it possible to do what I want to do?
Is there a simple/easy way?


thanks in advance
User avatar
jorgegv
Well known member
Posts: 287
Joined: Wed Nov 18, 2020 5:08 pm

Re: Another doubt about custom memory map

Post by jorgegv »

A quick and dirty solution could be the following:
  • Build your game INTRO as a standalone binary, ready to be loaded at a fixed address of your convenience (use an ORG directive to put it at that address). You can compile it and test it as a regular program
  • Build your final PROGRAM independently of the INTRO, and set the ORG for this program at an address that is above the fixed address chosen in the previous point + the binary size of the intro binary. This will instruct the linker to place the code above the memory where the intro will be loaded.
  • Write a custom BASIC loader that loads both programs in memory, each at their correct address
At this point you have two options for running your Intro and Program:
  • Call the intro from BASIC with a RAND USR instruction, and after that, call the main program with another RAND USR also from BASIC
or:
  • Just call your main program with a RAND USR from BASIC, and then at the very beginning of your main program you can call the Intro code (it is a known fixed address), and after the intro has run, initialize the heap with the heap address (known) and the heap size (known: the size of the intro binary), and run the program normally.
Be aware that if you choose the first option and return to BASIC for the program execution, the INTRO must be compiled so that it can correctly return to BASIC.
fraespre
Member
Posts: 56
Joined: Mon Aug 19, 2019 8:08 pm

Re: Another doubt about custom memory map

Post by fraespre »

thanks a lot Jorge for your suggestion!

I thought something similar, but without need to use the Basic interpreter glue the both parts.

Generate the binary files independently:
- The current game generates 2 files: LOWMEM.bin (5kb of Heat void) and COMPILED.bin (where I will Include a call to theoric location of the Intro).
- The intro with the ORG directive: INTRO.bin

Merge both files: LOWMEM + INTRO => LOWMEM (probably it will be the INTRO plus zeros until fill the Heap size)
And finally generate the Tap file as currently I do.

It's really ugly :-D , I have the hope that someone can give me a better solution using the linker.
Indeed, I would like that the main program code and the intro code could share some data structure using public labels and avoiding the need to calculate memory addresses.
Timmy
Well known member
Posts: 392
Joined: Sat Mar 10, 2012 4:18 pm

Re: Another doubt about custom memory map

Post by Timmy »

I find it strange that you don't want the Basic interpreter to glue the both parts. Every single program you have made, there's already a Basic glue program attached. Nothing would work if this doesn't happen (not that I care, of course).

I also find it interesting that you'd like to use the linker to do something that's not linking. But I don't expect that anything else.

At the moment I usually glue different programs using a GUI. It's so much more convienient and it gives so much more control. If I need to do it often, I use a batch script to do that. But that would mean someone needs to learn batch scripting, and maybe that's not what some C programmers can.
fraespre
Member
Posts: 56
Joined: Mon Aug 19, 2019 8:08 pm

Re: Another doubt about custom memory map

Post by fraespre »

Hi Timmy,
I think that resolving tags to give the final address of a compiled program is part of the linker functions. Another thing is whether you can indicate some preference on this final address in a specific piece of code ... as I want.
Don't forget that extracting this part of code as an external program is just an easy way to solve the problem, but it comes with limitations.

beyond this,
I want to try to define a custom memory map with a new Section (fex. Intro section) that use an "org" into the Heap memory. I will try to follow the Andydansby example (about 128 bank switching) to relate this new Section with the C code of the Intro module that I want to place there.
https://zxspectrumcoding.wordpress.com/ ... -lesson-4/
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Re: Another doubt about custom memory map

Post by dom »

I guess the problem with using custom sections is that -create-app doesn't know what to do with them.

So, how about hijacking a bank? So, if you set the ORG for bank0: -pragma-define:CRT_ORG_BANK_0=NNNN where NNNN is the address and then place your C file into that bank using #pragma bank 0 then the 128k snapshot that's created will have it in the right place, and if you're using classic the loader will inject it into the right place.

The only "downside" of this is that BSS/DATA don't end up in the banked code, but appended to your regular data/bss sections.
Post Reply