Copy Link
Add to Bookmark
Report
Saxonia Issue 02 Part 048
Bootblocks and trackloaders
By Rumrunner/VOID
[l
I have always enjoyed trackloaded productions as well as different
bootblocks, like utility boots. I still watch a lot of trackmos, not
only because of the lack of new productions to watch, but also because
they impress me in a way that's hard for a filedemo to do.
If we go back in time, the utility boot became quite popular. It offered
some useful functions, like turning extramemory on and off, switching on
and off extra diskdrives and so on. Most of them also checked the state
of coolcapture and coldcapture vector and told if there was any
possibility of a virus being present. Thereby, having a utility boot on
your workdisk could save you from hours of boring recovery work after the
nasty actions of a virus. Since most people didn't use a harddrive, who
bothered to load in the usual viruschecker when you were to boot off
another disk with another utility ten minutes later? I know for sure I
never did.
When we take a look at the demos from the early 1990's most of them were
trackloaded. Among the first trackloaded demos (and other productions)
were of course the megademos. One of my favourites is the first Phenomena
megademo where Mr Gurk blits 200 bobs on screen in oneframe in one of the
parts. Also enjoyable is the musicdisks from Burning Independence. And
ofcourse there are a whole lot of other interesting products.
Most of these mentioned above is perhaps not regarded as real trackloaded
productions, because many of them doesn't use ownwritten trackloaders.
For some time, it was common to keep the exec intact and use the
trackdisk.device to load tracks from disk. So there are examples where
megademos store needed information, like the state of the intena, dmacon
and such before taking over the system in each part. When you exit that
part and the demo loads the next one, enough of the system is left open
that the trackdisk.device does it's work.
People soon found out the advantages of using trackloaders, among the
most important is more available memory. This was in the days where
coders wanted to push the computer to the limits, and releasing a demo
that worked on 512k was better than releasing one needing fast. However,
using the trackdisk.device, you are not free to use memory every way you
like, as you have to keep the parts of memory that concerns
trackdisk.device and exec intact. So soon the first real trackloaders
appeared. They either took over the system right from the bootblock, or
loaded a couple of tracks to memory, then jumped into this code, taking
over the system and relocating the code (for instance the loader) to
whatever parts of memory. This took more work than using trackdisk, as
you had to set up such as stacks yourself. You also had to remember
where in memory you had different parts, if you didn't put everything
you needed in one block, in that case, it was easy to use branches and
you didn't have to resort to jsr's. Anyway, if you take a look at the
code in most trackmos, you will find that several routines is called
by a jsr to the right place. Even if you had to keep track of these
adresses, there were some advantages to working this way. For instance,
if there was one module played during several effects, you could simply
jump to the same player adress in each part, you didn't have to worry
about changing it in the interrupt. If you played music from one
interrupt, let's say the level 6 one, you could simply leave it there
all of the time, and run all effects from different level 3 interrupts,
whereas if you had the module in the same block as the code for one
effect, you had to take precautions when loading the next effect and
the data for it.
Let's now take a little break and remember some remarkably good
trackloaded and trackdisk loaded productions :[1
- Multica demo by Andromeda
- Global Trash demo by Silents
- Hardwired demo by TSL and Crionics
- Seven Seas slideshow by Andromeda
- Stolen Data diskmag by Anarchy (issues 6 and 7 with one code and
issues 9 and 10 with another)
- Desert Dream demo by Kefrens
- Dane demo by Kefrens
- and many more[0
Then, about 1994 something happened. More and more people started to buy
harddrives and also the Amiga 1200 come strongly into the scene. People
started to see the advantages fileloaded productions have and wanted
more of them. Also there were some badly written trackloaders that messed
up on faster computers, mostly due to processor timing like [2
moveq #-1,d0
wait:
dbf d0,wait[0
which works good as long as everybody has the same processor, but with
faster processors, even with cache, the wait simply becomes too small.
Those loaders using either rastertiming or CIA timing works well though.
I would say that old demos are more likely to run if they are trackloaded
then the case is if they are filedemos. Try for instance to watch the
old classic [1 Hunt for seventh October[0 by [2 Tec/Cryptoburners[0 on an Amiga
1200. I have never been able to get it to work, no effects are shown on
screen. The music plays well though. Then, try to load a trackloaded demo.
Most of the time, if works, if not completely they way it was supposed to.
I have noticed some demos which have trouble with the timing in other
parts than the loader, such as music speed and the most strange bug I
have seen must be the one I found in Global Trash. If you take a closer
look at the vector disk on screen, first at an Amiga 500 and then on an
Amiga 1200, there's a difference. Have you found out what? IT's the
metallic slide covering the readarea on the disk. It opens when run on
Amiga 500, when run on Amiga 1200 it doesn't for some reason or another.
So, like said, the trackloaders started to fade away. The last ones I
know of is some demos from The Electronic Knights made some time around
1998.
Now, will trackloaders and bootblocks be gone forever. No, although they
will perhaps not make an appearance again until I finish my routines.
That's right, some time ago, I found a document explaining the adresses
used for steeping disks and selecting side and such, so I started to make
a trackloader. So far, it steps well but there's a little problem with
the reading which I haven't sorted out yet. When it all works, I hope
to be able to put the whole loader on bootblock, thus saving the work
of loading it in and then relocate it to an appropriate adress.
Also I have started to take a look at bootblocks, after I found out the
structure of it. I guess all those who are interested knows it, but here
it is anyway :[2
dc.b "DOS",0
dc.l 0 ;this is used for checksum
dc.l 370 ;this is the rootblock which tells the
;os where to find the filesystem, block
;370 is track 40
... ;rest of code [0
Now, what the standard bootblock does is simply to do a loadresident to
find dos.library, put the adress in a structure and exit if it finds
dos.library. Upon exiting the bootblock, the computer will load the
CLI which we all know. If there's no dos.library, the bootblock will
exit with a returncode telling about the error, however I don't know
how you should be able to not find dos.library, as it is located in ROM.
The only explanation I can think of must be if you use a kickstart
remapper for instance to get kickstart 3.1 on a system which has kickstart
3.0 chips installed. I never bother to check if it has found dos.library
(or graphics.library for that matter) in any of my programs.
So, I have a lot of work left to do, but expect to see some trackloaded
stuff in the future, I work on a piece of code intended for a musicdisk,
and perhaps I will decide to trackload this. Then, we'll see if people
still bother to put a disk in the drive and reset the computer.
I think that it's a pity that most parties only allows contributions to
competitions in archive formats such as LHA, this means that trackloaders
are not allowed. I don't know if this is because of lazyness from the
organiser's side or whatever else it could be, but I don't like it.
Trackloaders are a feature of the Amiga and should as such be allowed
in Amigademo competitions.
