Bootblock

[jarre]

Which program is the best to write a binary to the bootblock, and is instant werking, include boot checksum etc etc....

[phx]

What is your goal? Do you have a specific boot block which you want to write once to a disk, or do want to write a boot block, or even a whole ADF, as an automated part of a build process?

There may be tools for the first case. You can also write blocks to disk with AsmOne, for example.

For both cases it might be best to write a small, portable C program to perform that task. So you can even use it on other architectures, in case you are cross-developing, and include it in a Makefile.

When I am building an ADF for one of my games, I have one source which contains the whole disk, starting with the boot block and using INCBIN to include the remaining disk contents (for a trackloader).

Then I have a portable C tool which takes this image, pads it to 880K with zeros and calculates the boot block checksum. The result is a working ADF. Maybe this helps:

/*
 * Makes a disk image of 901120 (0xdc000) bytes.
 * Calculates boot block checksum.
 */

#include <stdio.h>
#include <string.h>
#include <stdint.h>

#define DISKSIZE (0xdc000)

uint8_t image[DISKSIZE];


static void boot_chksum(uint8_t *p)
{
  uint32_t oldchk,chk=0;
  int i;

  memset(p+4,0,4);
  for (i=0; i<1024; i+=4) {
    oldchk = chk;
    chk += ((uint32_t)p[i+0] << 24) | ((uint32_t)p[i+1] << 16) |
           ((uint32_t)p[i+2] << 8) | p[i+3];
    if (chk < oldchk)
      ++chk;  /* carry */
  }

  chk = ~chk;
  p[4] = (uint8_t)((chk >> 24) & 0xff);
  p[5] = (uint8_t)((chk >> 16) & 0xff);
  p[6] = (uint8_t)((chk >> 8) & 0xff);
  p[7] = (uint8_t)(chk & 0xff);
}


int main(int argc,char *argv[])
{
  FILE *f;
  int rc = 1;
  size_t len;

  if (argc == 2) {
    if (f = fopen(argv[1],"rb")) {
      len = fread(image,1,DISKSIZE,f);
      if (len > 0) {
        if (len < DISKSIZE)
          memset(image+len,0,DISKSIZE-len);
        boot_chksum(image);
        fwrite(image,1,DISKSIZE,stdout);
        rc = 0;
      }
      else
        fprintf(stderr,"Image read error!\n");
    }
    else
      fprintf(stderr,"Cannot open '%s'!\n",argv[1]);  
  }
  else
    fprintf(stderr,"Usage: %s <image data>\n",argv[0]);

  return rc;
}

[hop]

Originally Posted by phx

When I am building an ADF for one of my games, I have one source which contains the whole disk, starting with the boot block and using INCBIN to include the remaining disk contents (for a trackloader).

I'm trying to achieve this using VASM, building with

vasmm68k_mot.exe -Fbin -no-opt file.asm

The bootblock (less than 1024 bytes) is at the start of the file, so I figured I could position some non-bootblock data in the binary image using ORG directives:

; BB Header
		dc.b 'DOS',0    ; BB_ID - Always has to be DOS\0
		dc.l $54A6B95C  ; BB_CHKSUM - Fix up with FixBootblockChecksum after assembling
		dc.l 880        ; BB_DOSBLOCK - Rootblock location for DOS disks
; ---------------------------------------------------------------------------
; BB_ENTRY

		move.l #GFX_BUFFER_SIZE_BYTES,d0 ; byteSize
		moveq #0,d1                      ; attributes

		; <snip>

GfxName:        dc.b 'graphics.library',0
DosName:        dc.b 'dos.library',0

		; end of bootblock

		ORG 1024
		; TODO: Why does this data appear immediately after the 
		; bootblock data and not at offset 1024?
		dc.b 'Some data...',0

                END

This assembles without warning, but the later data does not appear at the correct offset - it appears directly after the last non-zero byte of the bootblock. Thanks for any insight - perhaps I have misunderstood this process.

vasm 1.9 (c) in 2002-2022 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.5 (c) 2002-2021 Frank Wille
vasm motorola syntax module 3.15d (c) 2002-2022 Frank Wille
vasm binary output module 2.1 (c) 2002-2021 Volker Barthelmann and Frank Wille

[phx]

Originally Posted by hop

This assembles without warning, but the later data does not appear at the correct offset - it appears directly after the last non-zero byte of the bootblock.

That's because you forgot the

ORG 0

at the beginning of the bootblock source.

Explanation: vasm has two modes. Absolute mode, when your code starts with an

ORG

directive. And relocatable mode, when your code starts with a

SECTION

directive (or any section-alias, like CODE, DATA, BSS). If you start writing code without any such directive, it will default to

CODE

. Which is what happened here.

To make it even more complicated,

ORG

has also two modes. In absolute mode (i.e. when you start your source with an ORG) it behaves as expected and sets an absolute start address. But within a section you can relocate code with ORG to a fixed address. Which means all labels following this ORG get absolute addresses. Although this relocated block is still embedded in the previous section! This is why the data follow directly after your code.

What would have worked in any case is

RORG 1024

. RORG (Relative Org) always sets a new offset relative to the current section.

[hop]

Many thanks for the explaination. I had just found this post in which you demonstrated this technique, but I couldn't figure out what rorg was doing. From the manual it sounded like it was Reverse ORG!

rorg <expression>[,<fill>]
Sets the program counter <expression> bytes behind the start of the current
section. The new program counter must not be smaller than the current one.
The space will be padded by the optional <fill> value, or zero.

I guess not realising there was an implicit section caught me out, but the word 'behind' still makes no sense to me. I think perhaps your explaination from the previous post should be pasted into the manual!

I think perhaps ORG is the correct thing to use in my case, because I want to know the exact offset on disk to load the data from.

I wanted to put ASSERT *<=1024 at the end of the bootblock code to make sure it does not overrun, but I guess always putting ORG 1024 after the bootblock will allow this to be caught by error 3001: sections must not overlap

[phx]

Originally Posted by hop

the word 'behind' still makes no sense to me. I think perhaps your explaination from the previous post should be pasted into the manual!

A language thing. In german "hinter" could also mean the positive direction. I'm always happy to receive feedback from native speakers to improve our documentation! Thanks. Fixed.

I think perhaps ORG is the correct thing to use in my case, because I want to know the exact offset on disk to load the data from.

Yes.

I wanted to put ASSERT *<=1024 at the end of the bootblock code to make sure it does not overrun, but I guess always putting ORG 1024 after the bootblock will allow this to be caught by error 3001: sections must not overlap

Correct. No need to check that explicitely. Also RORG would show an error, when the offset is bad.