Jump to content
IGNORED

Mini-HOWTO: Making your own bootable disk image


dmlloyd

Recommended Posts

I figured I'd post this bit of info here because I had a bit of trouble reconstructing this bit of arcane knowledge from the currently available sources of documentation.

 

Basically the problem is this: you have a game/your own custom DOS/whatever, and you want to make a bootable disk or disk image. If you did your homework by reading Mapping the Atari and other reference materials, you'd discover that the format of the Atari boot sector is as follows:

 

Byte 00: Boot flag (must be 0)
Byte 01: Number of consecutive sectors to load for the boot program
Byte 02-03: The address where the boot image (including these header bytes) is loaded
Byte 04-05: The boot initialization address
Byte 06+: Boot image entry point

 

Basically how it works is that the OS loads the first sector, reads the address from bytes 02-03 and the count from byte 01, and loads that many sectors from the start of the disk to that boot address; it then does a JSR to byte 6 of your image. At this point you may, of course, take control of the system and do whatever you like; however if you want to pass control back to the system (like Atari DOS does for example), just end your subroutine with a CLC/RTS pair. The CLC is very important (and very undocumented!) - if you don't do it, the OS will think there was a problem, and will print BOOT ERROR and restart the boot process.

 

One important thing to note. Most DOSes will set the boot image address to $0700 or thereabouts. However this is not necessary - you can set it anywhere in RAM you want (as long as it doesn't overwrite anything important, like the OS data area or the screen/display list RAM). For example if you're writing a game, you could load the boot routine at $0600 to gain a bit more continuous RAM for other uses.

 

After your boot routine returns, the subroutine at the boot initialization address is called. This is just a regular subroutine that ends with RTS.

 

That's it! Have fun...

Link to comment
Share on other sites

Could you even start loading at $0480? Provided you aren't using any of the FP routines I guess, or does the OS use this area at boot time somehow?

 

I don't see why not. Maybe you could go back even to $03C0 if you don't use printer or cassette... or even farther if you use few or no IOCBs :)

Link to comment
Share on other sites

If you did your homework by reading Mapping the Atari and other reference materials, you'd discover that the format of the Atari boot sector is as follows...

At this point you may, of course, take control of the system and do whatever you like; however if you want to pass control back to the system (like Atari DOS does for example), just end your subroutine with a CLC/RTS pair. The CLC is very important (and very undocumented!)

 

Mapping The Atari is a must have book, invaluable. But the official Atari docs are even more. This is all documented (including the carry bit funcitionality) in the Operating System User's Manual, part of the famous (but seems not as much as it should) Technical Reference Notes (available for download here).

Link to comment
Share on other sites

This is all documented (including the carry bit funcitionality) in the Operating System User's Manual, part of the famous (but seems not as much as it should) Technical Reference Notes (available for download here).

 

Does anyone know of any efforts to scan this and put it up on atariarchive? This would definitely make it more accessible to the masses.

Link to comment
Share on other sites

$480 is the lowest practical address to commence Stage 1 of the boot.

 

Of course, if you take over the boot process, then you could overlay lower addresses. But, in reality you'd just be better off using some of those locations for work variables, buffers etc.

 

Actually, in theory if you wanted, you could probably have a single sector boot which loaded at $100. Then your code would have to continue the process at an early stage.

 

Another thing of note - you should stick to the OS convention for booting, otherwise the BOOT flag at location 9 mightn't get set properly.

 

And, you should store your program's RUN address at locations $A,B once it's loaded successfully. Otherwise, you might get the Self-Test when the user hits Reset. Although you can just not bother RTSing when the Init code is called indirectly (through locations $C,D).

 

 

PDF versions of the OS and Technical Ref are available - I've put them into files in a thread around here somewhere.

Link to comment
Share on other sites

Basically the problem is this: you have a game/your own custom DOS/whatever, and you want to make a bootable disk or disk image. If you did your homework by reading Mapping the Atari and other reference materials, you'd discover that the format of the Atari boot sector is as follows:

 

Byte 00: Boot flag (must be 0)
Byte 01: Number of consecutive sectors to load for the boot program
Byte 02-03: The address where the boot image (including these header bytes) is loaded
Byte 04-05: The boot initialization address
Byte 06+: Boot image entry point

 

A side remark: There is no need for the boot flag to be zero. It is simply ignored by the Os. The reason why it is there is that very early models of the 810 had a bug that could, occasionally, garble the very first byte read from disk, so Atari just reserved this byte and marked it as "boot flag". It has no purpose except avoiding trash-data.

 

The boot strap address should be at least $480 or above. The area $400 to $480 is used by the Os as bootstrap buffer, i.e. the sectors of the boot file are first loaded into this buffer and then copied into place. If you load into the bootstrap buffer, strange side effects will happen. Such tricks have been used in some games to obfuscate the bootstrap process, e.g. "Bandits" does this. So anything below $480 should be avoided.

 

So long,

Thomas

Link to comment
Share on other sites

  • 2 years later...

The links for the examples were broken. Here are the current links

 

Bootloader with Sector Counter: http://wiki.strotmann.de/wiki/Wiki.jsp?page=Bootloader%20with%20Sectorcounter

Boot from Cassette : http://wiki.strotmann.de/wiki/Wiki.jsp?page=Boot%20from%20Cassette

 

I updated because I was looking for a way to write my own bootable program. I think the bootloader with sector counder example will do the trick.

 

 

 

Basically the problem is this: you have a game/your own custom DOS/whatever, and you want to make a bootable disk or disk image. If you did your homework by reading Mapping the Atari and other reference materials, you'd discover that the format of the Atari boot sector is as follows:

 

Byte 00: Boot flag (must be 0)
Byte 01: Number of consecutive sectors to load for the boot program
Byte 02-03: The address where the boot image (including these header bytes) is loaded
Byte 04-05: The boot initialization address
Byte 06+: Boot image entry point

 

A side remark: There is no need for the boot flag to be zero. It is simply ignored by the Os. The reason why it is there is that very early models of the 810 had a bug that could, occasionally, garble the very first byte read from disk, so Atari just reserved this byte and marked it as "boot flag". It has no purpose except avoiding trash-data.

 

The boot strap address should be at least $480 or above. The area $400 to $480 is used by the Os as bootstrap buffer, i.e. the sectors of the boot file are first loaded into this buffer and then copied into place. If you load into the bootstrap buffer, strange side effects will happen. Such tricks have been used in some games to obfuscate the bootstrap process, e.g. "Bandits" does this. So anything below $480 should be avoided.

 

So long,

Thomas

Link to comment
Share on other sites

Well I remember that the tape version of bruce lee has a run address of 0417h or was it 0418h (so i am guessing it loads code at 0400h)

 

I also seem to recall that DI's fighter pilot also loaded data at 400h (can't remmember if that were the disk or tape version)

Edited by carmel_andrews
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...