This engine is output as a separate binary if it gets used.
OK, but... why?
The fixed location is the choice of the original author. Inside the code there are things that have to be located on 256-byte boundaries and then subroutines have been placed to fill holes that such alignment restrictions create. So to rewrite this to allow the linker to place things places more problems on the user by forcing him to plan a memory map where some things are on 256-byte boundaries and then making use of any holes that may appear in the memory map. I thought users wouldn't gain much by doing that.
I'm trying to picture what's happening. I have a bit of code (my C) ORGed at 32768, and another bit of code (BiFrost) ORGed at 58625. Why does the linker not join them together into a single piece of code with a "hole" in the middle? I can see it might be a design decision. Loading 20KB of zeroes across an area of memory which might have something in it is a wasteful thing to do, so it's more efficient to break the code into chunks.
It's a bit of the latter - remember that this is supposed to be a tape so loading a bunch of zeroes is a waste of time and also increases chances of tape loading errors.
But it's also because there's no telling for sure what the user wants to do with the binaries. Sometimes a binary is not meant to be loaded, for example a section can be created to place the heap at a specific place in memory but you don't want to actually load the binary that results for that section because the heap is initialized at runtime. Sometimes the binary is destined for a different memory bank and that may be something the linker doesn't know about. Sometimes a binary is destined for an independent purpose, for example it's a machine code loader for tape or disk.
I'm just a bit thrown because I can't remember seeing a Spectrum program broken up into separate sections which are loaded individually.
At the minimum there's going to be loader, screen$, machine code. For 128 programs it's simplest to load each 16k bank separately.
Is it possible to have the appmake utility merge them into one piece of loadable code?
Yes you can get appmake to make binaries covering each defined memory bank (up to 64k).
For that example,
Code: Select all
zcc +zx -vn -SO3 -startup=1 -clib=sdcc_iy --max-allocs-per-node200000 bifrostldem.c ctile.asm -o bifrostldem -m
appmake +glue -b bifrostldem --clean
appmake +zx -b bifrostldem__.bin --org 32768 --blockname demo -o demo.tap
"appmake +glue" sniffs the map file to figure out what goes where and stitches together binaries for each defined 64k bank, filling in holes as required. Other memory banks must have "BANK_XX" in their section names where XX is a hex number. It also checks alignment of binaries having "align_dd" in their names where dd is a decimal power of 2.
Then "appmake +zx" makes a tap file out glue's output.
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot