Starting on Amiga, experienced on other platforms

Hi guys,

I'm a newcomer on the Amiga programming scene, while I'm having years of experience coding games on other platforms (Speccy, CPC, MSX, PC, iOS, GBA...). I did some stuff on the 90s but nothing really pretty cool there.

I've downloaded a toolchain from this board, called "The Super Simple WinUAE Tool Chain For Amiga Demo Programmers". I must admit that I've been a proactive user of Amiga OCS computers, and I think I'm having deep enough knowledge on how Amiga works at graphics and sound level. Unfortunately, I'm not used coding Amiga stuff so I need some help...

First, when coding old computer stuff, I am used to write my binaries directly to the disk then use a custom bootloader to load and setup everything, instead of using the operating system. I know most of the Amiga OCS games of the time were using this technique. The toolchain I've downloaded is mounting up a DH0 device so AmigaDOS shell is loaded before everything. I was expecting something like writing a custom bootloader at track 40 then going on from there. Here comes my first question: Is AmigaDOS residing in ROM or is it loading from disk? Does it reside in a particular memory address or is it relocated each time?

Is there, with the toolchain mentioned above or with any other tool available to manage ADF files to create a custom format disk with a custom bootloader and so on?

Basically, I want the whole control of the computer. I don't want to AllocMem and all this sh*t. I want to take full control of the hardware (as mentioned somewhere in the AHRM). I want to know if someone of you guys is able to do so in Windows using a toolchain like the one mentioned.

Thank you guys! I'll wait for ya answers! Greetz!

Sorry but I've missed my second question! It is just asking for links and docs with an explanation of how to use blitter bobs THanks again!

[Retrofan]

Well, just to say welcome aboard, also from Spain. I'm sure you'll get your answers very soon here ... Great to have a programmer.

[Codetapper]

I'm not saying this is the best way, but this is what I've done.

I wrote a small program (in Delphi) that has a list of files I want written to the disk. It allocates 901120 bytes of memory (exactly the size of a disk) and writes all the files on $200 byte boundaries starting from $1600 (track 1).

It then writes a simple filetable on track 0 containing the filename, offset and length of each file.

Then it copies a simple bootblock into position which loads the main file and runs it. In my case, the file relocates itself so it didn't matter where it ended up in memory. That contained the main loader (Rob Northen) so it can load any other file off the disk.

After assembling all the files I need, I just run the program and it spits out the ADF file which lets me test the game.

(And I would recommend you use Rob Northen's loader if it's going to be a disk only game as it's easy to use and thoroughly tested).

[StingRay]

Originally Posted by merry

Is there, with the toolchain mentioned above or with any other tool available to manage ADF files to create a custom format disk with a custom bootloader and so on?

To create a bootloading disk all you need is an assembler and, depending on the used assembler, maybe a tool to write your code directly to disk and calculate the bootblock checksum and stuff like that. AsmOne has all these features included for example and is quite easy to use IMHO. It has quite a few bugs though but is still my assembler of choice.

Originally Posted by merry

Basically, I want the whole control of the computer. I don't want to AllocMem and all this sh*t. I want to take full control of the hardware (as mentioned somewhere in the AHRM). I want to know if someone of you guys is able to do so in Windows using a toolchain like the one mentioned.

To take full control of the system you do not need AllocMem() at all! Just disable DMA/interrupts, install your own copperlist etc and switch on the DMA/interrupt channels you need. Check registers DMACON/INTENA in the HRM. If you're going to use this in a bootblock you might want to copy the boot code to a safe location in memory so you can then use all the memory in whatever way you want.

[phx]

I'm creating an ADF image with an assembler source, which contains the boot block and INCBINs all the stuff you want to have on the disk. For example:

        include "exec/io.i"

; exec.library LVOs
DoIO            equ     -456


        org     0                       ; don't care, all code is PC-relative


        ; AmigaDOS boot blocks (1024 bytes)
boot:
        dc.b    "DOS",0
        dc.l    0                       ; checksum will be inserted here
        dc.l    880                     ; root block does not matter

;---------------------------------------------------------------------------
boot_code:
; a6 = SysBase
; a1 = trackdisk IoStdReq

        lea     $70000,a5               ; program start address

        move.l  #ProgEnd-ProgStart,IO_LENGTH(a1)
        move.l  a5,IO_DATA(a1)
        move.l  #ProgStart-boot,IO_OFFSET(a1)
        jsr     DoIO(a6)                ; load it

        jmp     (a5)                    ; start

        ; fill the rest of the boot blocks with zero
        cnop    0,1024


;---------------------------------------------------------------------------
        ; Block 2: the program to load

ProgStart:
        incbin  "myprogram.bin"
        cnop    0,512
ProgEnd:

        end

Then I have a portable C source, which make an 880K image and calculates the checksum:

/*
 * 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[0]);  
  }
  else
    fprintf(stderr,"Usage: %s <image data>\n",argv[0]);

  return rc;
}

All is controlled with a Makefile. So a single "make" will build my whole project into a ready-to-test ADF image.

[phx]

Originally Posted by merry

links and docs with an explanation of how to use blitter bobs

We would have to use the search-engine in the same way as you could do for finding links.

So just some notes:

- The Hardware Reference Manual contains all you need to know about the Blitter.

- The usual procedure in each frame is:
1. Redraw the saved background for all BOBs.
2. Do scrolling and tile animations.
3. Calculate new BOB positions.
4. Save the background behind new BOB positions.
5. Draw the BOBs over the background using a mask.

- You have to calculate a mask for all your BOB images, so you can tell the blitter which pixels are taken from the BOB image and which from the background, when blitting them.

- Drawing a masked BOB uses all three Blitter sources. A is the mask, B is the image, C and D are pointer to the destination bitmap. The formula is D = A&B | !A&C (Minterm = $CA). Draw one word more than the BOB width to allow shifting. Mask out the last word: BLTAFW=$ffff, BLTALWM=0.

- Saving and restoring the background is a simple D=A copy without shifting. Start with the first bitmap word and copy one word more than the BOB is wide.

- To reduce the number of Blitter starts required you may consider to keep the BOBs and the bitmap in interleaved format.

[Hewitson]

Why would you want to create a disk-only software in 2013? That would be insane.

[phx]

Originally Posted by Hewitson

Why would you want to create a disk-only software in 2013? That would be insane.

Because retro hardware is our hobby. When writing an OCS game for the A500 you cannot expect that there is more than a floppy disk drive.

[Lonewolf10]

Originally Posted by Hewitson

Why would you want to create a disk-only software in 2013? That would be insane.

No, not really.

Games and demo's are easier to distribute when they are limited to disks only (emulated or physical). No worrying about whether the end user is going to have the necessary libraries, or other game files, in the right place. No worrying about locating where the game files are stored on the harddrive. Best of all you can shut down the OS and have full control over the Amiga. There is no worrying about restoring the system to former settings and no chance of other programs interferring with games and causing occasional glitches.

[Thorham]

Originally Posted by Lonewolf10

Games and demo's are easier to distribute when they are limited to disks only (emulated or physical). No worrying about whether the end user is going to have the necessary libraries, or other game files, in the right place. No worrying about locating where the game files are stored on the harddrive.

That's not quite right. A program that doesn't need any libraries and other system files will happily run from anywhere.

Using custom track loaders is only useful for floppy only systems and systems with very little RAM. As soon as programs start needing extra memory and an HD, it's better to use some kind of OS framework (turning off the OS is fine, just make sure you can turn it back on).

Thank you so much to everyone for sharing your knowledge with me. At this time, first of all I'll write a Windows-based utility to create my disk images in a phx-like style. @phx, great to share your code!!! I'll keep you informed of my progress. Greets!!