The build process is a mess

[fachat]

The build process for boot images is a mess.

For example, the C64 boot "ROM" segment addresses need to be manually managed in the Makefile depending on the size of the actually assembled segments. And then the available RAM needs to be fed back into c64rom.a65 to let lib6502 know what it can allocate.

I'd rather have some (set of) defined kernel and program images, and build them into a boot image using a proper tool automagically.

[fachat]

In cbm8x96, the segment addresses are in arch/cbm8x96/Makefile, the start of the ROM scan address ROMSTART is in rom.a65, as is the definition of lib6502 available memory and zeropage.

As .data is before .text, if it outgrows its border, the .text start address needs to be fixed in the Makefile and in the ROMSTART definition in rom.a65 (and potentially Memstart in rom.a65 as well)

[fachat]

Some notes on the target build system:

• create a /dist folder that includes all architecture-independent programs (apps, sysapps, slipapps, ...) and man pages.
• in the architecture folder, only build the architecture-specific part; also take what is needed/possible from the dist folder to create mountable disk images where applicable
• per architecture three main artifacts: -- kernel -- lib6502 -- init ROM
• All three should be assembled to target addresses, either as single files (cbm8x96, ...), or combined (pet32k,...), and a label file for all combined created (depending on architecture also translated to respective emulator input format)
• Zerostart / memstart / memend should be automatically determined from the build if possible

[fachat]

1. part is done - there is a dist folder, and no more need in each architecture to create a list of application files. Instead just take a pre-defined disk image and update with the architecture-specific boot files
2. label files can now be re-located according to how an o65 file has been re-located (e.g. see pet32k), so target address assembly is not strictly necessary anymore

Unifying the assembly of the kernel and init rom still is a challenge:

In pet32k, everything is assembled as a block, using -X to export, relocated afterwards to combine text, data and bss, and only the PET IRQ vector is linked to the kernel. In C64, a single image is assembled as block, to the correct addresses. c64rom.a65 contains .dsb statements to provide windows for I/O and screen buffers.

In CBM8x96, and CSA, the different memory maps present challenges with the holes and the need to work around those in the build process:

• CBM8x96 builds three images to position, that are loaded separately. The address setup takes care of the I/O window at $e8xx
• C64 builds one image, but in the c64rom.a65 .dsb statements skip over the I/O and screen buffer area between init rom and lib, and kernel
• CSA has an I/O window of 2k at $e800-$efff, so the kernel does not fit into the top 4k completely. Therefore the kernel has hooks in kernel.a65 to skip over the I/O window with .dsb during assembly. Otherwise assembly builds to place.

Overlap analysis is complicated by the fact that some systems easily allow overlaps - when memory mapping is involved. For example, the ROM programs in CSA are assembled separately, and all use the same data area - as they all have their own 4k of low memory.

Considering all this, the easiest way for now is to use .asserts to check for length overruns.

Therefore this ticket is taken out of 2.2

[fachat]

.. and will be revisited at a later time.