Amiga Trackloaders

[Jobbo]

I've done a modest amount of Amiga coding in the distant past and now again recently.


However, I've only ever made self contained executables or intros.


When targeting a 1meg A500 it seems like most games and demos choose to push things further with a custom trackloader.


Are there some standard trackloader systems that games and demos commonly use?


What could I use if I was making a demo and wanted to go this route?


It seems like the main advantage is that you can access more Ram and have enough control over loading that it's possible to effectively stream data.


Are there more advantages? Or any disadvantages? (other than hd install etc).


Some demos like Sanity Interference are so-called dentros. These are interesting because they seem to be just large intros. But they're doing more than seems practical to fit in Ram all at once. Is there some alternative approach these dentros employ?


Anyway I'm really curious what feedback people have. It seems like it would be pretty hard to put together a trackloader from scratch!

[StingRay]

Rob Northen's loader has been used quite often (and is easy to find), Ross on this very forum has created a very optimised loader which can be used too, PHX (also on this very forum) has created his own loader as well. So these are at least 3 you can choose from and there are more of course.

As for advantages: being able to use all memory, faster loading than using plain old Amiga DOS and generally just having control over the complete system.

[phx]

Originally Posted by Jobbo

Are there more advantages?

I would add that you can use more of the disk space, because there are no administrative blocks from the file system anymore. Most important advantage for me is that it is the only safe method to load data when taking over the system and killing the OS.

Or any disadvantages? (other than hd install etc).

Maybe that you have to do your "filesystem" yourself and set up a directory with start and end blocks. Also handling multiple disks and multiple drives would be up to you.

It seems like it would be pretty hard to put together a trackloader from scratch!

Not really. There are CIA port-bits for starting the motor, selecting the side and stepping the head. And registers for starting the Disk DMA in Paula/Agnus. You only have to make sure that you do all this within the time limits given in the HRM (like step-delay, settle-delay, etc.).

[Antiriad_UK]

I think the planet rocklobster source has trackloader code in it as well.

The last thing I wrote on my a1200 was a trackloader, it did clever stuff like reading DOS disks and checking which drive had the right disk. Never used it, and can't understand it now

[redblade]

Originally Posted by StingRay

As for advantages: being able to use all memory, faster loading than using plain old Amiga DOS and generally just having control over the complete system.

StingRay how much memory do you have access to straight from the bootblock?

WinUAE AmigaDOS 1.3, OCS 512K RAM, 1 Disk Drive shows

Available	In-Use		Maximum		Largest
426400		89464		515864		425544 NTSC
417440		98424		515864		416584 PAL

32K for a 640x200x2 Screen buffer, maybe 64K if it's double buffered. I never knew the kickstart ROM needed that much memory for variable storage.

[FSizzle]

Coming back to the Amiga after 20 years I wrote my first track loader a few years back and it was super fun. First writing it in C and then again in asm for my bootblock.

I think like anything low level on the Amiga, it is for you to decide if this sounds like a fun and interesting challenge or not.

It seems like it would be pretty hard to put together a trackloader from scratch!

As phx mentions, the timings must all be right as per the HRM. The reason this is tricky is because while the HRM lists the timings very clearly, WinUAE is very tolerant of bad timings so doesn't help debugging this and it's very easy to write code that fails on real hardware (and even sometimes only on certain models) due to varying timings of the particular drive model.

The biggest gotcha however, I think, is one I ran into that caused sporadic problems only on real hardware and only very occasionally.
It was caused by an undocumented behavior (at least wrt the HRM) relating to how many syncwords will be present in your buffer once a read has completed. Trivial to manage when you know about it, but hard to debug when you don't. Again, this only happens on real hardware.

Finally, you need to be super careful about not stepping the motor incorrectly on some models as it can physically damage the drive. This sounds terrifying, but the good news is that this part can be perfected in the safety of an emulator before you get anywhere near the real thing

[Toni Wilen]

Originally Posted by FSizzle

As phx mentions, the timings must all be right as per the HRM. The reason this is tricky is because while the HRM lists the timings very clearly, WinUAE is very tolerant of bad timings so doesn't help debugging this and it's very easy to write code that fails on real hardware (and even sometimes only on certain models) due to varying timings of the particular drive model.

They really can't be validated easily because there are trackloaders that do use wrong timings but usually they still work because published specs are 100% guaranteed to work even in worse conditions (for that model).

There is even least one demo that does really short steps back to back accidentally. Drive must only step once in this situation. Undefined behavior is not in drive specs so finding good timing range is almost impossible, without breaking something else. And almost certainly there is at least some drive model that fails to work with this demo.

When to report fail is the problem. Different mechanisms have different timing parameters, HRM reports one model. (AFAIK original A1000 drives were much worse than A500 drives)

I guess optionally validating against HRM parameters would work but there are still many unknowns to make it useful except as: step pulse was too quick, don't do it.

Can't even report steps <0 because of no-click programs.
At least steps track >80 are logged

The biggest gotcha however, I think, is one I ran into that caused sporadic problems only on real hardware and only very occasionally.
It was caused by an undocumented behavior (at least wrt the HRM) relating to how many syncwords will be present in your buffer once a read has completed. Trivial to manage when you know about it, but hard to debug when you don't. Again, this only happens on real hardware.

This will happen in emulation but timing window is very small (there is 3 different cases, many loaders fail to handle the rare one but usually they also still work because they accidentally or not detects it as corrupted read and retry). Usually it also requires use of raw floppy image (extended adf) because adf has too static "geometry". Also note that to duplicate rare issues, there is usually need to keyboard reset the emulation and try again. Start emulator (or with hard reset) with disk inserted = 100% identical behavior every time.

[FSizzle]

Thanks Toni - your insight is always appreciated.

The faults in my case all entirely lied with my code, and debugging them on real Amigas is simply the reality that is required to run reliably. For me it was part of the process and satisfying to resolve.

I think you interpreted my comments this way, but to be clear: there is zero criticism of WinUAE here. The fidelity of the emulation is incredibly impressive.

I guess WinUAE could conceivably have emulation options to try to emulate less tolerant drives or warn about certain unsafe behaviors, which would be useful to a very small set of users. Most users would never want these things enabled as they would prefer their software just be more likely to work even if it has bugs.

[SpeedGeek]

@thread

I have edited this threads title because A500's don't have the monopoly on trackloaders... and hopefully, that's not such a big surprise.

[mcgeezer]

Originally Posted by Jobbo

I

Anyway I'm really curious what feedback people have. It seems like it would be pretty hard to put together a trackloader from scratch!

I'd really say it depends on what you are doing and what you are targetting.

When I did Rygar I used Ross's loader... and it is very very good. However the problem came when I wanted to support CD32.

If you make any sort of track loader then you are limiting yourself to anything with a floppy drive, that means no loading from hard drive or CD.

Just keep in mind that it might be worth the memory hit for expanded compaibility.

WHDload would be your friend though if you go the track load route - but CD32 would be a problem.

Geezer

[pink^abyss]

Originally Posted by Jobbo

When targeting a 1meg A500 it seems like most games and demos choose to push things further with a custom trackloader.

As amiga coding is already complex enough for me, i decided to dodge trackloaders. For my games and demos i compress all data and unpack at runtime. I see the 512kb of non chipram as my 'data' storage from where i usually depack to chipram. I like the lower complexity, HD installation by default, and i can go back to the system anytime. As drawback i loose some chipram to the system and the maximum data size is (a bit) smaller then a full disk. Tho never had a real problem with that..

[defor]

Might be worth a try:
SOS - Sanity Operating System Version 2.6 (1994)
Chaos and Mr.Pet / Sanity used it in their productions.
(I haven't tested it myself though)

[Jobbo]

Thanks all for the suggestions. I'm probably not going to delve into writing my own right now since I don't actually have a pressing need for one yet. But it sounds like it would be fun at some point.

I'll probably just try to make do putting together a single executable. I could imagine taking the same approach as Pink and just compressing things as much as possible.

What I'd be curious to know is how something like Sanity Interference works? Seems, I'll have to look more closely at that demo to see if it's doing any trackloading.

When you start Sanity Interference it says it is a "file trackmo". I wonder what that means?

[Galahad/FLT]

Originally Posted by Jobbo

Thanks all for the suggestions. I'm probably not going to delve into writing my own right now since I don't actually have a pressing need for one yet. But it sounds like it would be fun at some point.

I'll probably just try to make do putting together a single executable. I could imagine taking the same approach as Pink and just compressing things as much as possible.

What I'd be curious to know is how something like Sanity Interference works? Seems, I'll have to look more closely at that demo to see if it's doing any trackloading.

When you start Sanity Interference it says it is a "file trackmo". I wonder what that means?

Lots of demos were trackloading, right from the days of Red Sector Megademo, Scoopex's Mental Hangover, absolutely nothing unique at all, lots of demos used track loaders, in fact I'd say the percentage that didn't were in a minority.

[Jobbo]

You've missed the point.

As I said, Sanity Interference is a "Dentro".

It's on a dos disk and the single file executable is 480k.

However, there is so much happening in that demo that it seems possible it might do some mid-demo loading. But it probably doesn't.

Still wonder if any demos did take such an approach?

[mcgeezer]

Ross' track loader reads DOS FFS, crazy to reinvent the wheel really.

[Galahad/FLT]

Originally Posted by Jobbo

You've missed the point.

As I said, Sanity Interference is a "Dentro".

It's on a dos disk and the single file executable is 480k.

However, there is so much happening in that demo that it seems possible it might do some mid-demo loading. But it probably doesn't.

Still wonder if any demos did take such an approach?

Sorry I had a different demo in my head.

If you read most of the text in the loading part at the start, the majority of what they say is tongue in cheek nonsense including "file trackmo".

There is no in demo loading, its all done as a single file that unpacks to extra memory.