______________________________________________________________________________ ---- Trackmo-DOS v3.0 ---- by: Emmanuel MARTY (Poison of NOVA) Release Date : 20 jan 1993 English documentation. ______________________________________________________________________________ I - Introduction Programming a demo is now a real sport on Amiga... At this writing, the most current form of demos, and the coolest too, is the 'trackmo' : a demo which loads itself in several times : that enables all deliriums, without being limited by memory space. But for the programmer, the coder of these kind of demos, life is hard... He doesn't only have to work on the demo itself, I mean effects, design, etc. ; he has also to imagine a disk system to load correctly all parts of the trackmo. The first way to do that is of course to use AmigaDOS, but this system is not really 'good-looking', and has a lot of drawbacks, for example the fact that all lamers can rip your files (except if they're crunched, and not always) ; and AmigaDOS is not specially fast to load files (I know it's not fast because the DOS system is very complex and powerful, but.. I have to defend my work !) ; and, last, the programmer has to resolve conflicts between his demo and the AmigaDOS (for dma, interrupts, etc.), that asks a knowledge of AmigaDOS to avoid some stupidities. So, let's forget the DOS. The second method, who looks a bit like what I want (heavily) to introduce here, is to put directly files on tracks, start the demo from bootblock, and then load all parts, either with trackdisk.device (which leaves same problems of system knowledge than the DOS method), or with a custom trackload routine, which is not easy to code but enables to make what you want.. So what am I doing here ? Actually, the use of a trackload routine is not at the level of all coders (the famous 'MFM' read/writing system is REALLY strange !), and anyway, trackload or trackdisk, saving files to be loaded in the demo on tracks is really boring (except with a program specially made for that - Hi Fireblade - !!), and it can generate errors (we don't write on the good track, or we don't write the good number of tracks...) ; we must too write somewhere on which tracks we wrote the files, etc. -- if it's on a paper and if you're (like me) a bit disorderly, you can loose it... So no method explained here can be used who wants to keep cool and code his effects instead of a low-level and boring routine which, finally, has only for function to load data. As I am myself partly human and coder, and as I already had the problem of loading data in a trackmo (the said trackmo is waiting to be finished because of a problem with graphics, but that's not the subject...), I decided to code for myself a little tool to clear one time for all this fucking trackload problem, staying at the same time easy to use ; but, after talking with a lot of coders (even well-known persons), I saw that a lot of them still save their data without any help by writing everything with trackdisk, as explained before ! That brought me to release the tool I first programmed for myself, and by making it better time after time, this is now version 3.0. I don't mean that this is the final project (I still have ideas to spend my winter evenings !) but let's say, if it didn't exist, I'd have to invent it... Ok. I know the system which is the hearth of TrackmoDOS and that I'll explain along this documentation has already been used in some demos (like routines by Hornet/ALCATRAZ "Odyssey" or Sim/RAZOR 1911 "Voyage", to take as example known productions) and almost every game, but no program bringing this technique to every coder has been written since today (someone told me that The Silents released a tool looking like mine (hack ! hack !), I must check that...), so it was time to make it. The loading method has advantages of DOS and Trackload without their main drawbacks. It consists in saving files directly on tracks (but with a dedicated program - which makes this save totally without your help, like a DiskMaster - we'll see it in next chapter), and identify files not with tracks and sectors (because of the mess I explained before), but simply with filenames, like under AmigaDOS. So it's the goal of this tool, enable you to create disks in a special format, which permits to save data on tracks and identifying them with names, it's the function of the program which will be now called "handler" ; then, obviously, loading back these tracked-files with a kind of operating system, the TrackmoDOS itself (it also handles memory, gives you a lot of infos about hardware, and a lot of other functions, we'll see it in depth in chapter 3) ; and, fianlly, debugging your demos in "direct-live" with a special monitor, the T-MON or TrackmoDOS Monitor (which has been a little bit remixed, I say that for all afficionados of my program), that can appear at any crash of your demo, or by a simple call from you, even if AmigaDOS is totally erased (I called it when Andromeda's "MIRROR" was running !), that enables you to see immediatly an error... So it's time to describe the three parts of this program, in three chapters.. That seems good. II - The Trackmo-DOS Handler (subtitle : the mess but reprogrammed) The first step in using the TrackmoDOS is obviously to create a disk in appropriate format (if that doesn't seem obvious to you, well, try DeluxePaint !) ; this diskformat is called "T-DOS", and the Handler.. handles it, yes yes yes. The said handler is the program you'll see when you run the tool : the two other parts, which will be explained later, are installed by this program where they must be (on T-DOS disks !), so they're assembled with the Handler : don't look for TrackmoDOS Operating System or T-MON on this disk ! Before beginning to explain the program, I'd like to warn my fans (my fan ?) that version 3.0 of this Handler is TOTALLY different from the previous ones, it's maybe normal because I reprogrammed it TOTALLY ! It's now a kind of future diskmaster which will pop up when you call the program... Your fast brain will immediately notice (except if you never ran the new Handler) that screen is divided roughly into four parts. The first one is the titlebar and has only for function to show a title.. But notice the box at top/right of the screen, it's the screen-to-back gadget (putting a screen to front one wouldn't have been very intelligent as you can't drag the screen ! This because all my attemps to create a custom dragbar just called the guru with various numbers, I think I even invented new ones.. Actually if you own kickstart 2.0 you can of course drag screen by pressing left amiga, left mousebutton and moving mouse !) ; well, let's keep on looking from top to bottom. You'll see two filerequesters which need 2/3 of screen. The left one is here to select AmigaDOS path (notice "volumes" gadget which displays available drives, volumes and assigns). When AmigaDOS directory is listed into the window, clicking on a subdirectory (white color) adds it to the path and the subdirectory is listed. Clicking on a file selects or deselects it ; it is for filetransfer functions, we'll see it in a moment (I think there's no use to explain why there is a scrollbar and two arrows)... The right filerequester is a bit different. It display T-DOS directory when a disk in this format is available. The window shows five gadgets that you can easily see, "df0:" to "df3:" and "AUTO". Everybody who knows my old Handler knows what's the use, but I must explain for the others.. Clicking on "df0:", "df1:", "df2:" or "df3:" locks T-DOS disk recognizing on the selected drive : when a T-DOS disk is put into it, the directory is displayed and the disk can be edited. The other diskdrives are ignored. Fifth gadget, "auto", tells to the program to look for a T-DOS disk in any drive : putting such a diskdrive will select it as active drive, read the disk and display the directory so the disk can be edited. When T-DOS files are listed, clicking on them selects/deselects them like AmigaDOS files, for filetransfer functions too, we'll see them in a few lines : the fourth and last part of the screen is a panel of 16 commands at bottom of screen which replaces a menubar which brought to suicide a lot of coders in previous versions. Well well well, it's maybe time to describe the functions because I broke my nuts to code them : "COPY TO" copies files from AmigaDOS disk to T-DOS disk. So you must have a ready T-DOS disk (don't panic, we'll see with 'Format' command how to create them) : all selected files in AmigaDOS window will be copied on t-DOS disk. For each file, the Handler asks you the name you want to use to identify it under T-DOS format ; because T-DOS limits filenames to 8 bytes (MS-DOS II.. the revenge of the son... arrgh !) (to keep a fast directory) ; and, as AmigaDOS uses really longer filenames... Well. For each file a requester will pop up asking you the new name. Pressing RETURN after typing name or clicking on "OK" will then copy file under asked name on T-DOS disk, but you can at any requester stop copy by clicking on "CANCEL". "GETBACK" copies files from T-DOS disk to AmigaDOS disk, if for example you don't want to .. get back .. data you saved under T-DOS format and erased after from AmigaDOS disks... Ok. This command works quite like previous one, every selected T-DOS file is transferred back in indicated AmigaDOS path ; but no requester will appear as there will be no filename length problem in this way... "FORMAT" (at least !) creates a T-DOS disk, in order to transfer files (with described "COPY TO" command) to load them back in your demo... A first requester appears to ask you a diskname for AmigaDOS. Yes, to avoid any conflict, T-DOS format does not use lower side of track 40 where there is root-block and, here, block allocation map and some other funny DOS structures (except if you desactivate this option in Preferences -we'll see it later- but there's no reason for doing that except winning 5 KB of diskspace or liking Checksum Errors on kickstart 1.3) ; so AmigaDOS can read this diskname, in case of.. The requester has got a CANCEL gadget which ..cancels.. formatting. But if you validate name by RETURN or click on "OK", another requester will ask you nicely a "T-DOS diskmark". Actually it wants a 4-bytes mark (4 alphanumeric chars) to identify the disk for TrackmoDOS, when your demo is on several disks : any disk has its own mark so it won't crash if the user inserts the wrong disk.. If you don't need a special mark, enter what you want, the phonenumber of your boy/girlfriend (first four numbers !).. Notice too that the requester hsa again a Cancel "gadget" (in fact ALL requesters have one, but chhhht...). If anyway you click on "OK", or, again, press RETURN (he's mad !), the disk is formatted in T-DOS format ; every track is initialized, and then TrackmoDOS operating system is installed on track 0 (lower side) of the disk to boot without your help, and then T-DOS directory is created. Disk is recognized immediatly by the program and you can then install files on it. I said that TrackmoDOS starts automatically when booting, maybe do you wonder how it starts your own program ? It's really simple : you just have to install (with "COPY TO" !) on your T-DOS disk a file called "MAIN" (uppercase !). TrackmoDOS will call it right after installing itself in memory, we will see how this file must look like in next chapter. "KILLALL" instantly ereases all T-DOS directory, so erases instantly all files on disk. It's actually the only way to erase a T-DOS file, as they are written sequentially on tracks (anyway you must know which files to install with your demo, don't you ?). So KILLALL resets directory, after a beauutifuuul requester, as always. "PROTECT" (obviously).. protects .. any T-DOS disk against reading by the Handler, FOREVER ! This means that when your demo is ready on the disk, to prevent your files from being looked, you just have to call "PROTECT". The Handler will not recognize your disk as a T-DOS disk anymore (Of course the TrackmoDOS Operating System which loads your files when your demo runs will keep on reading them, if not what would be the use ?) "INFO" gives you -really!- informations about current T-DOS disk... number of files, total diskspace allocated for files in bytes and sectors, free diskspace in bytes and sectors, allocation percentage... everything to make all statistics lovers come. "VALID" is probably the most delirious Handler command ! Calling it makes a quite .. wild.. effect which is really funnier than 'protect' : this command installs a custom disk-validator on your T-DOS disk (I said before that track 40 is allocated for AmigaDOS so it is also possible to save a short file on it like a disk-validator). This validator performs a simple but stunning effect, it starts your demo ! This means that inserting your disk ANYTIME (even if you're working with DeluxePaint !) will start the demo. To test this mad effect call VALID on any T-DOS disk (warning, you won't be able to modify it after that ! if you really wanna protect a disk against aggression, select VALID and PROTECT before removing the disk !) ; well, after VALIDating, remove and re-insert the disk (so the AmigaDOS will re-validate it), and look what happens !! Well here I have to say that I discovered a fucking drawback (it's not my fault !!) : on kickstart 2.0 or 3.0, the AmigaDOS programmers must have found that disk-validators are the root of a lot of disk crashes, so I suppose they replaced it by a ROM routine... All I know is that AmigaDOS 2.0 or 3.0 TOTALLY IGNORES my diskvalidator and of course does not autoboot the disk... I'm trying to work out another way of doing that autoboot but I think there's none.. Anyway you should VALIDate your disk when your demo is finished, coz it won't crash anyway on a new kickstart (because my disk-validator is not runned !), and on 1.2 or 1.3 kickstart it does that stunning effect ! Try ! "RENAME" permits, it's really a surprise I guess, to rename T-DOS files (I think you know how to do with AmigaDOS files ?) : for each selected T-DOS file, a requester pops up to ask you a new name for the file. Accepting by RETURN (or clicking on "OK", you should know it, now...) continues renaming, and, of course, clicking on "CANCEL" stops it, I know it's the fourth time I say it... "INSTMON" (for "INSTALL T-MON" (not enough space !)) installs on your T-DOS disk the TrackmoDOS Monitor to make it appear when a crash occurs (or when you call it) during your demo : TrackmoDOS Operating System loads it automatically when it is present on disk, as explained in next chapter. "DISABLE" says to TrackmoDOS Operating System that it musn't load T-MON even if the said T-MOn is present on disk. It's in case of the T-MON is present on your final demo disk (for debugging purposes) and you don't want it to be loaded (for loading time, lost memory space, or any other reason !). So just call DISABLE to turn off T-MON. "ENABLE" is the contrary of the previous command, if you changed your mind ! "SYSINFO" has no real link with T-DOS format handling, actually. This command, after working during one or two seconds, displays various informations about your machine, try and see ! "PREFS" displays a window which enables you to put some Handler functions in the way you want. This window displays at this writing 6 choices and 3 'gadgets'. The 6 choices correspond to 6 text lines with a little box on the left. When this box is empty, the corresponding choice is deactivated, and when the box is full, the choice is, guess.. activated.. Yeah you win the TV set !! Ok. The 6 choices are as following : "Protect track 40" : the name of this option says what's its use.. it tells to the FORMAT command if, when formatting a new T-DOS disk, track 40 must be allocated for avoiding conflicts between AmigaDOS and T-DOS, or not. If track 40 is allocated, you loose roughly 5 KB of precious diskspace, but you avoid checksum errors and you can VALIDate the disk... If you choose to deactivate this option (because you really need these 5 KB, or you like "Checksum Error 880" requesters on kickstart 1.x). I say again that this option effects only when FORMATTING a NEW DISK, it won't change the state of an already-formatted disk. "Write TrackmoDOS code" : this option tells to FORMAT if it must write the TrackmoDOS Operating System on disk when formatting... This option was created especially for multi-disks productions, as disk 2 or 3 of your demo musn't be bootable, only disk 1 must be installed with TrackmoDOS OS code... "Watch resetvectors" : even if the goal of my program is not to be an antivirus, the Handler can verify that reset vectors (capture and kickmem/tag) aren't modified, by for example a tiny virus... If reset vectors are hit (except if you set kickstart 1.3 resident patch with "setpatch r" command which is obviously not a virus, even if some programs believe that !), an alert appears in order to ask you if you want to clear reset vectors. Clicking on "Cancel".. cancels clearing vectors and de-selects vector watching to avoid a constant alert. So "OK" tells to the Handler to clear reset vectors. If it's not possible (when a virus sets the resetvectors all the time, under interrupt) the Handler will notice it and will ask you if you want it to perform an "hardreset", only known way to kill a virus of this kind.. So, "OK" to hardreset and "CANCEL" to cancel, as always... "Display dirs before files" : indicates if, when displaying a directory into AmigaDOS window, subdirectories must be displayed together before files or just appear between files.. Select what you prefer... "Custom iconify position" : enables you to define the iconify- window position on Workbench screen : ICONIFY command -see below- frees what is possible and turns the Handler into sleep-state in a small workbench window, until you wake up the program. This option makes you define the window position : workbench comes in front and a window with the same size as inconify window can be moved where you want the iconify window to be. Close window when the position is good. "Close workbench screen" : if this option is set, the program closes Workbench screen in order to get some chip memory (if the Handler can't close Workbench (windows still present ! -- I know a way to close Workbench even if windows are opened on it but as I'd not be able to open it again for the moment I'll work that out later...) option is deactivated) ; if option is unset, Workbench is opened again (if it is not possible when a real chipram lack occurs option is reactivated !) There's three gadgets "Save" "Use" and "Cancel" which work like good old Workbench 1.3 preferences : "save" saves (in S: directory) your preferences (like iconify position...) and accepts them ; "use" accepts preferences without saving them and "cancel" clears what you modified and comes backs to old prefs. "ICONIFY" iconifies the Handler like any good tool. Only a little Workbench window stays on screen. You just have to close it (or to click right mousebutton when window is active, but it's longer !) to call back the program. "ABOUT" displays a message like all 'about' commands... Clicking on "RESUME" removes it. "QUIT" quits of course the program (what, quitting ??? oh, you want to use TrackmoDOS... ok for this time...) after a beauutifuuul requester.. Talking about requesters, notice that all my requesters support following keyboard shortcuts : "Right Amiga + V" (OK) and "Right Amiga + B" (for CANCEL). About requests too, I must warn you that the famous "system request" requesters take a new look when my program is running (I must admit that someone called Fireblade forced me a little be) ; try ! Talking about Fireblade, too, you're maybe sad (or happy !) to not find his program linked with mine like previous versions.. It's only that his TDM (last version was 2.6 I think) does not support multiple filetransfer, so it doesn't work if I send it several files in the same time... Buuut I don't doubt that this strange coder will solve the problem if he wakes up one day, to oblige me to release another version.... Well, it's now easy for you to create T-DOS disks will all needed data for your demo, now your problem is to load back your data when it must be loaded, with a simple but powerful tool (don't laugh please !), called the, the... III - The TrackmoDOS, the true, the only one, is back... To handle with efficacity the T-DOS format, there were several ways, like for example giving a sourcefile with a trackload routine to load T-DOS files, but it was still to tiring for the lazy person I am sometmes. Listening only to my courage, I decided to program an 'environnment' (to not say here 'operating system', that would be pretentious !) for your demos which are free from some boring routines - we'll see that now. Trackmo-DOS program is installed by its little friend the handler on your demo disk, at track 0, lower side. The AmigaDOS starts then my custom bootblock, which, after loading all TrackmoDOS code, looks in libraries (for compatibility) to find memory expansions list, connected diskdrives, kind of CPU, coprocessor, agnus, denise, display, and ROM version ; it puts all of these infos in a structure you can access (we'll see later how). Then the program 'kills' AmigaDOS (warps in supervisor mode, resets dma, interrupts etc.), copies itself at adress $00000000 (so complete 68000 handling by TrackmoDOS). It starts its memory handler, and attempts to load the "T-Mon" monitor : if it's present, all 68000 exceptions are handled by it ; if not, TrackmoDOS does not cry and in case of an exception, a reset will be made and a guru will appear with exception code and -instead of task address-, PC value (address of crash). After this exception init, the program loads the T-DOS file called 'MAIN'. If this file does not exists, TrackmoDOS resets the Amiga (with the oh-so-nice violet color on screen) ; if MAIN is correctly loaded, TrackmoDOS gives it the control (at this point all dma and interrupts are off - the demo will have to set it by itself). This 'MAIN' file is of course the main program of your demo, so that it will start from bootblock without effort from you, like I said proudly in the introduction chapter. This program must be a normal load file (made of hunks -- no ORG !!), for reasons we're about to see. Trackmo-DOS is a small operating system, but it's working on a great machine called Amiga. And on this machine, we have the habit of having the memory handled by the system -- so we can't stand of handling it by ourselves (don't we ?). So, Trackmo-DOS handles memory like AllocMem and FreeMem of exec.library -- you ask a size (and, if you want, a special memory type (CHIP/FAST/BOTH)), Trackmo-DOS allocates memory, gives you the adress ; and when you've finished, you free the memory, point. So you don't catch headaches with testing if the machine has got or not memory expansions, at which adresses, etc.-- TrackmoDOS handles everything for you. What happens is that programs and data are loaded in dynamically-allocated memory, I mean, it's not recommended to load data or programs at a fixed ('absolute') adress, even if you can do such a thing. 'MAIN' is then loaded by TrackmoDOS with a routine that has the same effect than 'LoadSeg' of dos.library, that's why 'MAIN' must be a normal object file (with several hunks if you need !), even if running it from AmigaDOS would crash the machine, because of the kind of things that are done in the file... This 'LoadSeg simulator' routine is of course available for your programs (like many other ones), that enables you to divide your code in several parts (if it's very big and that you want the demo to run on 512 KB), so you can make a main program loading a lot of code parts without problems... This way of handling memory and programfiles looks like AmigaDOS, that's what I called 'use AmigaDOS' (cool memory handling) 'without its drawbacks' (slow speed etc.). I recommend you to program your demos in this way of dynamic memory allocation/deallocation, without using fixed-adress programs that could corrupt memory handling of Trackmo-DOS. Anyway, it gives routines to load data or programs with auto-memory allocating, so you shouldn't spend a lot of time to use this dynamic loading... ; that gives you too the big advantage of being compatible with all memory expansions because when TrackmoDOS starts, as I said, before killing system it gets memory expansions list from exec.library and this list will of course be valid forever... That means if a machine owns 2 MB chipram like new A1200 or A4000, they can be allocated for the demo ! So you can say proudly "I'm 500+ or 1200 compatible" without a big work -- and 68040-compatible too (if you don't do something against it !) because the trackload routine can work with such a processor ! Trackmo-DOS has got in addition some nice functions for decrunching PowerPacker DATA files (and this still very easily, so you can crunch all your data without having to do a depack-routine) (I'm working on a routine to handler a better packer but wait and see !), and to handle demos with several disks... All the problem is then to access all these wonderful functions. Stay cool, once again, it's SIMPLE : at adress $00000004 (so, adress $4), is a pointer, not on exec.library because it's dead, but on a structure called 'tdos.toolbox' that enables to call all routines I said and to get some interesting infos. An 'include' file (tdos.i) is given with this package, it lists all this structure and gives all functions offsets and other equates, but for remaining Seka-fans and for the needs of this doc, let's see this strange tdos.toolbox : - functions (negative structure ) : -4 size = FSize (filename)(a0) -8 ok = Load (filename,address)(a0) -12 adr = LoadAlloc (filename,memtype)(a0,d0) -16 adr = LoadSeg (filename,memtype)(a0,d0) -20 adr = MemAlloc (size,memtype)(d0,d1) -24 MemFree (adr,size)(a1,d0) -28 PPDepack (ppfile,endppfile,dest)(a0,a1,a2) -32 adr = PPLoad (filename,memtype)(a0,d0) -36 PPFree (adr)(a0) -40 ok = CheckMark ()() -44 WaitDisk (drive)(d0) -48 size = MemAvail (memtype)(d0) The number at the left of each function synopsys is of course the offset to use (with the base adress written at $4) to call it. 'FSize' gives you the size of a file. You must give it in a0 the address of T-DOS filename to examine. It returns in d0 the size of the file (or 0 if the file doesn't exist, or if there was a read/write error or the directory) 'Load' allows you to load a file at a special address in memory. You can, for example, by using FSize and memory allocation/deallocation functions explained below, allocate memory for the file (by getting its size with FSize) and loading it with Load (--well in fact this example is not so good because there is a function (see later !) doing everything I said for you, but...) ; well, anyway, it waits in a0 the address of T-DOS filename to examine, and in a1 the loading address. It will return in d0, 0 if everything went ok, or -1 in case of loading error (unknown file or read/write error)... 'LoadAlloc' loads a file after allocating automatically memory for it (that's why my previous example wasn't so useful...) : well, that's why I said it's simple to use dynamic-memory system. This functions needs in a0 the address of T-DOS filename to load, and in d0, type of memory to allocate. Known types for LoadAlloc (and for memory routines that we'll see soon, and which are of course called by LoadAlloc !) are like following : MEMF_CHIP ($0002) which forces LoadAlloc to load T-DOS file in chipram, MEMF_FAST ($0004) which forces the file to be loaded in fastram (shouldn't be used but...) MEMF_ANY ($0000) which indicates that we don't care of the memory type : if there's enough fastram, we allocate memory of this type, if not, we allocate chipram. This functions returns in d0, the address of loaded file ; d0=0 if a disk error occured ; d0=-1 if there was not enough memory to load the file. Notice too, that if afterwards you need the length of loaded file, which is also the size of allocated memory (so you'll need it to free that memory !), there's no use to call 'FSize' : the length of the last loaded file is always in a longword of tdos.toolbox structure called 'lastlength' (its offset will be given in next part...) ; so the normal use of LoadAlloc will be : load a file with LoadAlloc, check d0 for error, if none then get the address in d0 and the size in LastLength, use of data, and then free allocated memory by giving address and length to the memfree routine that we'll see in a moment. 'LoadSeg' acts like the same function in AmigaDOS. It handles loading of a program at a not-fix address, even if it's not written in 'relocatable' code, using a table called 'relocation table', automatically saved by the assembler with the code, when you save an 'object file'. So TrackmoDOS is able to load this kind of files, because of the way the memory is handled ; it's (I think) the best method with TrackmoDOS to divide your code into several parts, so that you can load each part when you need it (make a main code "MAIN" which only does that !). -- Well. LoadSeg waits in a0 the address of T-DOS filename to load, and in d0, type of memory to allocate, same values as LoadAlloc -- warning, LoadSeg does not exactly act as AmigaDOS function, all hunks are loaded in the same memory block, so in the same memory type, and all chipram-loading hunks are not loaded in chipram, but in the memory type you precise (this will be improved in next version - I coded a routine which works like real LoadSeg but I have no time to include it now...) ; well, for this reason, the allocated memory will be deallocated like LoadAlloc - the LastLength field holds the size of allocated memory for the relocated file, so you only have to give the address (returned by LoadSeg in d0, see later) and the size held in LastLength to free the file memory... ; so, when returning, d0 gives the address of the relocated file (address of the first word of the first hunk), ready to use... Or d0=0 if a disk error happened, d0=-1 if memory error, or d0=-2 (the little new) if wanted file was not an executable file. -- 'MAIN' file is of course loaded by TrackmoDOS with this function. A thing you must remember is that TrackmoDOS always load "MAIN" in chipram, that enables you to use copperlists and other chipram-eaters directly in main program. 'MemAlloc' works EXACTLY like AllocMem of exec.library. This function (internally called by almost all loading routines !) allocates -of course- memory dynamically, it's the basis of TrackmoDOS memory handling. It awaits, like AllocMem, the size of memory to allocate in d0, and type of memory (see LoadAlloc) in d1. It returns in d0 the address of allocated memory, or d0=0 if there was not enough memory of the required type (or not enough memory at all if memtype=MEMF_ANY). 'MemFree' is of course the complement of the previous function ; its goal is -you guessed it- to free (deallocate) memory, allocated by MemAlloc ; and LoadAlloc/LoadSeg, too.. It awaits in a1 the address of memory to free, and in d0, the size to free -- like FreeMem of exec.library. It returns nothing, asked memory is just deallocated (if memory is already free, TrackmoDOS crashes with a clean guru #81000009 'bogus exception failure', that's all !) 'PPDepack' is private. 'PPLoad' loads and depack a PowerPacker DATA file, without action from you, because this routine works (for you), like LoadAlloc. It awaits, like LoadAlloc, in a0, address of filename to load, and in d0, type of memory to allocate for the decrunched file. After loading and depacking, it returns in d0 the address of decrunched data ; d0=0 if a disk error occured ; d0=-1 if a memory error (not enough mem) occured. So this function permits to easily depack files (everything is done without your action !), I think it's cool to have such a function when demo files begin to take a lot of diskspace... 'PPFree' frees memory allocated by PPLoad. You MUST use this routine and not MemFree to deallocate memory got by PPLoad to depack file, because it's allocated in a special way, to limit the mem size to use to depack file (packed and depacked file take -when they're in the same time in memory- only the size of depacked file + 8 bytes !). Well, PPFree just needs in a0 the address given by PPLoad, and so will free properly the memory for you. Like MemFree it returns nothing, and it crashes if you give a wrong address. 'WaitDisk' waits a disk to be inserted in a diskdrive ; this is particulary useful for demos that needs two disks or more, so they can continue to load on external drives, it makes a cool effect ! (we'll see soon how to know EASILY which drives are connected). The command needs in d0 the number (from 0 (df0:) to 3 (df3:)) of the drive where it will wait a disk insert. Actuall, WaitDisk waits that a TDOS-formatted disk without read/write error is inserted in drive you choose (it loops since that). When a valid disk has been inserted, WaitDisk warps all loading routines on the drive you asked (so all LoadXXX will now load on the inserted disk). The commands finishes by loading the new T-DOS directory of the inserted disk. Yes, to save some time when loading, TrackmoDOS does not read the directory at each file loading, but keeps it in memory. We'll see in chapter five (for crazy coders !) how this directory is build, but it's not our problem here, and anyway it won't be necessary for a normal human being. -- Note : if the asked drive is the same as the one from where LoadXXX was loading since WaitDisk (the "current" drive), the command will wait that the user removes the disk from the drive, and then wait that it inserts another one ; if the asked drive is different from the "current" drive, WaitDisk will exit if a valid disk is already in the asked drive, or behave as normally (wait a valid disk) if the drive is empty. That means that the user can insert disk two of your demo in an external drive, so WaitDisk will immediatly recognize it (when you'll ask WaitDisk to load from an external drive, the drive you ask won't be the same as the "current" drive (normally df0:), so WaitDisk won't wait the disk to be removed) ; but of course, the poor owner of a single disk drive will have to remove disk one and then insert disk two ; that's why WaitDisk has two ways of behaving... 'Checkmark' is a complement to the previous command ; this function tests if a special "mark" is present on a disk inserted in the "current" drive, to verify that the user of your demo inserted the good disk (he might have inserted again disk 1, for example : as it is a valid T-DOS disk, WaitDisk will accept it !) ; so Checkmark avoids the problems of loading from an unknown disk... This function needs nothing in entry. It reads the first sector of the disk (the bootblock), gets the value at 'boot+8', and returns with this value in df0:. Normally on AmigaDOS disks this value at 'boot+8' is 880 ($370), which is the pos of the rootblock. But as we absolutely don't care about that, we can put here a special mark (4 bytes, a longword if you prefer, like f.ex. 'DSK2') that will be read by CheckMark to identify a disk. You can easily change this mark by editing the bootblock (AFTER formatting it with TrackmoDOS-Handler, of course !) with a disk editor. Then you'll only have to call WaitDisk and Checkmark, and test if the value returned in d0 by CheckMark is the value you wait (if not, you loop back on WaitDisk ! As the asked drive will now be the same as the current drive (set by the previous WaitDisk), there will be no problem, WaitDisk will wait a disk change)... 'MemAvail' gives you anytime the remaining memory space of any type. This function awaits, in d0, type of memory to scan (like MemAlloc, I mean MEMF_CHIP for chip memory only, MEMF_FAST for fast memory only, or MEMF_ANY for all memory), and so returns in d0 the remaining available space (in bytes) for the memory you asked. So this function works like AvailMem() from exec.library. The explanation of all functions is now finished, let's continue with the different (and meant to be interesting-) infos that TrackmoDOS gives ya. I mean... - the positive structure : offset name size --------------------------------- 0 tb_sysmark longword 4 tb_df0 byte 5 tb_df1 byte 6 tb_df2 byte 7 tb_df3 byte 8 tb_activedrive byte 9 tb_pad byte 10 tb_lastlength longword 14 tb_diskerror word 16 tb_totalchip longword 20 tb_totalfast longword 24 tb_agnustype byte 25 tb_denisetype byte 26 tb_displaytype byte 27 tb_proctype byte 28 tb_coproctype byte 29 tb_kickver byte 'tb_sysmark' is a mark which identifies the tdos.toolbox structure. It is the four letters 'tdos' in lowercase, that corresponds to the longword $74646F73. This mark has no function but showing that tdos.toolbox is here (adress held in $4 must always point on this mark, if it's not the case there's a big problem !!!)? 'tb_df0' to 'tb_df3' are flags that indicate connected diskdrives. Each of these four fields is equal to $FF if the diskdrive is connected, and $00 if not. So tb_df0 will always be equal to $FF, as df0: is 100% sure to be connected to the computer ! Actually, to test if an extra diskdrive is connected, you only have to test these flags (with a TST, branch instruction BEQ will jump if examinated drive is not connected). 'tb_activedrive' shows the current drive. This has not a wonderful use for you, but TrackmoDOS had to save it somewhere ! 'tb_pad' is a byte which's here to align again the following longword on an even address, so it has no particular function and it's normally to zero. Maybe this field will be really used in next versions of TrackmoDOS, so please don't use this field to record something... 'tb_lastlenght' is the famous LastLength field that every loading routine uses ! So that's here, in this longword, that you can get back the length of last loaded file (in fact, it's the length of last allocated memory, but...) 'tb_diskerror' is a word which holds the explanation of last disk error. I mean, if a loading function returns a zero ("disk error"), this field informs you about the problem, so that you can f.ex. display a correct message to the user (maybe not for a demo, but certainly for a musicdisk or a diskmag ! it makes a cool effect !). Well, at this writing, the four reasons that make a disk error, are : DE_READERROR (=$0008), when a 'hard' errors happens on disk (unreadable track , read/write error if you prefer !) ; DE_NODISK (=$0010), when there's no disk in the drive we try to load from !! ; DE_NOTDOS (=$0018) when you try to read a disk which is not a T-DOS format (user changed the disk ?) ; and DE_FILENOTFOUND (=$0020) to inform you that the error occured because TrackmoDOS couldn't find your file (wrong name ?).. Well, this is the end of the explanation of the positive structure. 'tb_totalchip' is a longword which keeps the amount of CHIP memory connected to the machine (in bytes). So you can know if the machine has got a CHIP expansion... 'tb_totalfast' is a longword which keeps obviously the amount of FAST memory connected to the machine (in bytes). 'tb_agnustype' shows which type of AGNUS is inside the machine where you run the demo : this field can take three different values : TB_NORMALAGNUS (=$10) for an OLD AGNUS (512 KB Chip-ram), TB_FATAGNUS (=$11) for a FAT AGNUS (1 MB Chip-ram) and TB_SUPFATAGNUS (=$12) for a SUPER FAT AGNUS (2 MB Chip-ram). 'tb_denisetype' tells which type of DENISE is present (I don't know, if a part of your demo needs PRODUCTIVITY mode, it's here you must look for a SUPERDENISE !) ; so the field can take two values : TB_NORMALDENISE (=$20) if the machine has got a good OLD DENISE, or TB_SUPERDENISE (=$21) if the machine uses a SUPER DENISE... 'tb_displaytype' shows what display is used by the machine : the two possible values are TB_DISPLAYNTSC (=0) for an American NTSC display and TB_DISPLAYPAL (=$FF) for a PAL European display (yeaah !) 'tb_proctype' tells what processor uses the machine. The values go from TB_68000 (=0) to TB_68040 (=4) for all different processors (no 68050 out for the moment ?). 'tb_coproctype' tells if a coprocessor is present. So two values can be found, TB_NOCOPROC (=0) or TB_COPROC (=$FF) if there's no coprocessor or one. 'tb_kickver' keeps the version number of Kickstart ROM, for pure info because system is dead. Notice you'll find Commodore VERSION number and not RELEASE number, that means tb_kickver will be 33 for a 1.2 ROM, 34 for 1.3 ROM, 36 for old 2.0 ROM (on first A3000 machines), 37 for actual 2.04 ROM (on A500+ and A600), and 39 for 3.0 ROM (A1200 and A4000)... Higher values will probably appear in the future (Kickstart 4.0 will see the light in sum years said Commodore West Chester team...) I say it again, all function offsets, positive structure fields and some equates (like def of MEM_CHIP...) are all in include file "tdos.i" given with this package and which can be included in sources with AsmOne or Devpac II/III (Seka users will insert this file directly in their source...). If you use this file, you should put it on the include disk (maybe "misc" directory ?) of your assembler. - Examples To make everything clear (if I can say that), here come now one or two examples of parts of 'main program', showing some TrackmoDOS functions (it's only examples, there's no use to try them !) First example, let's say we wanna load a music module with LoadAlloc, to laugh a bit (I suppose obviously that you have got the right musical routines -- anyway you don't need them, it's only an example !) : ; "opt c-" if Devpac incdir "include:" include "misc/tdos.i" ; we include TrackmoDOS offsets, equates etc. start lea music_name(pc),a0 ; we point on name of file to load moveq #MEMF_CHIP,d0 ; music always loaded in chipram !!! CALLTDOS LoadAlloc ; CALLTDOS macro (defined in tdos.i) calls ; a TrackmoDOS function, here 'LoadAlloc' tst.l d0 beq.s disk_error ; d0=0 -> disk error bmi.s mem_error ; d0=-1 -> memory error move.l d0,musicadr ; because 'MAIN' is a real object program, ; you can perfectly do that (auto-relocating), ; don't worry... move.l tb_lastlength(a6),msize ; after a CALLTDOS, a6 always point on ; tdos.toolbox basis ! so here we get the ; length of loaded file (and allocated mem) bsr mt_init ; it's the most current name of protracker ; module init routine... ... ; we do what we want... bsr mt_end ; we stop playing music (for example) move.l musicadr(pc),a1 ; we get back music address move.l msize(pc),d0 ; and length CALLTDOS MemFree ; we free its memory... ... music_name dc.b 'MOD.FUN',0 ; totally dummy name -- all names end with ; a zero, like AmigaDOS. But don't forget ; a name is limited to 8 bytes, all extra ; text will be ignored ! (the zero does not ; count of course in these 8 bytes) even musicadr dc.l 0 msize dc.l 0 ... Simple and clear, no ? (well, not really, I know... But it's at least as simple as AmigaDOS, so ...). Our second (AND LAST) example will put a light on WaitDisk & Checkmark functions which are a bit complex to undersand. We suppose that the disk to wait has got the mark 'DSK2' at the right place on its bootblock ; we suppose to that we're somewhere in the demo, when a disk change is needed... ... move.l 4.w,a6 ; we take tdos.toolbox base address moveq #1,d0 tst.b tb_df1(a6) ; df1: connected ? bne.s wait_disk2 ; yes, we use df1: moveq #2,d0 tst.b tb_df2(a6) ; df2: connected ? bne.s wait_disk2 ; yes, we use df2: moveq #3,d0 tst.b tb_df3(a6) ; df3: connected ? bne.s wait_disk2 ; yes, we use df3: moveq #0,d0 ; no extra drive, we use df0: (shit !) wait_disk2 CALLTDOS WaitDisk ; d0 already holds the drive number (see ; upper) -> we wait a disk in the good ; drive ... CALLTDOS CheckMark ; we read the disk mark cmp.l #'DSK2',d0 ; is this what we wait ? bne.s wait_disk2 ; if not, we wait another diskchange... lea filename(pc),a0 ; if yes, we can now load on the new moveq #MEMF_PUBLIC,d0 ; inserted disk ! CALLTDOS LoadAlloc ; (this loading is totally dummy but it's ; only to show that there's nothing special ; to do to load from the new disk.. All ; routines are "warped" on the new drive, ; so on the new disk too...) ... This example finishes my explanation of TrackmoDOS, I hope there's not too much DARK POINTS and that you'll then program your Trackmos really easier (Imagine the number of hours I spent to code all these routines ! And you've not seen everything !) ; so, end of this chapter, we'll now see something funnier... IV - The TrackmoDOS Monitor, let's call it T-Mon ! Every coder makes errors when he programs, it's normal, errare humanum est (or something like that). However, removing these errors ;is not simple in all cases ; the coder doesn't always know where the bug comes from, etc., and in a demo, the crash can happen anytime ; but as the system is "dead", you have no way to know what was the error. That's why I decided to write the "T-Mon" (to make again the things easier if it's still possible), a monitor, even a little debugger, designed to be used with the TrackmoDOS system, so it doesn't use any AmigaDOS function. In fact, when a crash generating an exception (odd address, illegal instruction, etc.) occurs, T-Mon is called, so you can, for example, disassemble from the PC (address of the crash if you prefer), see the error and correct it (T-Mon integrates an assembler).. You can continue your demo avec correcting the bug, or trace it instruction after instruction, there's no problem. T-Mon can be called by program too, even if there was no crash ; I don't know why you'd do that (maybe to see how it looks like), but you can do it. In fact, T-Mon is installed by TrackmoDOS in memory, at an address that depends of free memory (if you prefer, it's loaded by LoadSeg !). TrackmoDOS doesn't give you this address, that's because you don't need it : T-Mon catches 'line-f' 68000 exceptions (guru 0000000B.XXXXXXXX) in a special way -- these line-f call the T-MON when there's no unvolontary exception. A "line-f #$000" (line_f #$000 under AsmOne, or dc.w $F000 if your assembler doesn't support this instruction -- don't be afraid to put this dc.w into your code !!) will call the T-Mon ; when exiting the monitor your demo will continue right after the line-f, and dma, interrupts etc. will obviously be restored. However, there's something T-Mon can't guess when exiting the monitor : the address of copper-list to put when exiting (which should be the address of copper-list which was on screen before T-Mon call !) ; the best is to inform T-Mon about that in the very start of your program, so that if a crash occurs, and that you must return to your demo for a special reason, it will use the right copperlist. To give its address to T-Mon, you just have to do a "line-f #$001" (line_f #$001 under Asmone) (or dc.w $F001 if your assembler doesn't know the instruction ! I said, don't be afraid to put it right in your code), with the address of copperlist to use when exiting tmon in register a0, it's not very difficult. So, little example of main program : incdir "include:" include "misc/tdos.i" start lea my_coplist(pc),a0 ; we point on the copperlist line_f #1 ; and we precise its address to T-Mon ... ; we do what we want line_f #0 ; we force a T-Mon call ... ; program continues (when T-Mon exits) After a line_f #0, T-MON 2.0 lethal screen appears (it's a new version ! TrackmoDOS v2.0 was using T-MON v1.0, it's reaaally logical...) with a brief copyright text followed by a prompt ">" and a cursor : T-Mon is waiting for your orders. I don't want to explain here each function of the T-Mon, most of them are very normal (assemble, disassemble, copy memory, etc. - the most original thing in T-Mon is to be called under TrackmoDOS !), but I'd like to insist on some important points : First of all, you'll notice, if you already know the program, that line-editing has been greatly improved, now it looks like AmigaShell line editor (try and see) ! You can access complete list of functions by pressing keys F1 and F2 (F3 shows a tiny copyright message). T-Mon enables you to put calculations in arguments you give to the functions. It recognizes the three classic calculation basis -even if a lot of monitors forget them- (decimal : the number alone ; hexadecimal : a '$' and the number ; binary : a '%' and the number) ; it handles too addition "+", substraction "-", multiplication "*" and division "/". Then it's correct to write "A $50000+16" to assemble at adress $50010 ($50000 plus 16...) You exit assembler by pressing RETURN alone. T-Mon has got a (J)ump function (a JSR if you prefer) that permits to execute a 68000 routine. But, because the program is designed to debug your demo, when you want a Jump, T-Mon restores dma, ints, registers, processor state, etc. like they were before T-Mon, executes the asked routine, and then restores its own dma and ints. So remember that well when you'll do a Jump !! Program includes too a (J)ump no conte(X)t command which executes a 68000 routine without restoring "context" (dma, interrupts and processor mode) but only registers. It's a simple way to run routines which need supervisor mode (T-MON doesn't come back on user mode with this command) ; I think it can be useful ! I think I should speak a bit about ECHO ON/OFF command. This command starts/stop sending all text written by the monitor on SERIAL port (so you can connect another Amiga or a serial printer) ; you just have to select 9600 bauds, 1 stopbit and you'll be stunned to see your disassemblies and dumps on a screen of another amiga or on a serial printer, even if AmigaDOS is dead... All commands are easy to use (there's now two times more commands than version 1.0) and it would be boring for you and me to explain them here ; anyway their explanation can be found directly in T-Mon (with these keys F1 and F2). And at least an important note -- because it's totally impossible to know which keyboard you own (even AmigaDOS doesn't know that), and because I'm French, T-Mon uses normally AZERTY keybooard. But, don't throw the disk out of the window, because I wanted this package to be internationally used (if not, I wouldn't be here re-typing all the doc in english !!), you only have to press 'F10' to warp in QWERTY keymap mode. Pressing again F10 will bring you back in AZERTY mode. V - For little noiseparkers... For all dudes who would like to know more about how the T-DOS directory is build (if f.ex. you wanna code an utility saving or loading T-DOS files ?), here's complete explanations... T-DOS directory is located on a single track, track 0 upper site, I mean sectors 11 to 21 of the disk. This can remind you 8-bits or PC-compatible directories, but it permits a nice loading speed. Well. The four 16 bytes (the first 'line' of this directory) are special : the four first hold the mark "TDOS" (in uppercase) which indicates that the disk is in T-DOS format. The 12 last bytes are used by TrackmoDOS for internal purposes, don't change them !! Anyway you don't need them to operate on a T-DOS disk. The files begin at the 16th byte of this dir (the second 'line') and continue till the end of it : so the T-DOS format enables to save 351 files per disk, I think it will be enough. Each file takes 16 bytes in the directory, here's how : the 8 first, we can see it easily, are the filename, completed with zeros (and it must always be with zeros !) ; the four following bytes indicate the precise length of the file ; the 2 following bytes say on which sector the file begins ; and the 2 last ones indicate the number of sectors taken by the file. This number could have been found with the precise length, but I didn't know what to put in these 2 last bytes, and it's easier ! The end of directory occurs of course almost always before the limit of 351 files ; in this case, a zero for first byte of a 'line' says that it's the end of the dir. It's important too to know that the first track free for saving files is -you guessed it- track 1, lower side (beginning at sector 22 of the disk), that's right after the disk. So a dummy example of dir with files 'MAIN' (12532 bytes) and 'MUSIC' (195632 bytes) would look like this : +00 54444F53202A2053 79737465 6D20 5631 TDOS * System V1 ------name------ --size-- strt numb --name--- +16 4D55534943000000 0002FC30 0016 017F MUSIC........... +32 4D41494E00000000 000030F4 0195 0019 MAIN............ +64 0000000000000000 00000000 0000 0000 ................ .. ... Wee se that the first file 'MUSIC' starts on sector $16 (22, the first available for files), and is written on $17F (383) sectors, that's 383*512=196096 ($2FE00) bytes, needed to keep the 195632 ($2FC30) bytes taken by the file (TrackmoDOS, when loading, will of course allocate 195632 bytes, not 196096 !!) ; and file 'MAIN' starts at sector $195 (405), which correponds to 22+383, 22 is starting sector from previous file, and 383 number of sectors taken by this previous file. So we see that 'MAIN' is recorded right after MUSIC, it's what I called 'sequential writing' (if a file is written after 'MAIN', it will start on sector 430, because 430=405 (start sector of main) + 25 ($19), which is the number of sectors taken by 'MAIN'). The four line (+64) is filled with zeros, which indicates the end of directory, but warning, only the first byte marks the end of dir ; after a re-formatting (KillAll), the other bytes of the line can take any value. So that's only the first byte of the line and only it which indicates the end of the dir. If you want to read a file, you have to remember the following problem : if there's an asterisk (*) between "TDOS" and "System" on directory flags line, as in the example, it means that track 40 is allocated for AmigaDOS. So you must 'skip' it when loading a file. During a demo, directory is always at address $1800 (yes, an absolute address !! But it's because the dir is out of 'allocatable' memory for TrackmoDOS (I wanted it)). This address is guaranteed to stay the same for future versions of TrackmoDOS. At this address, the dir is exactly like it's written on disk, exactly like explained before if you prefer. All loading routines use this memory dir and never read it again ; the only case of directory loading is when you change the disk (and it's you who'll want this change, so you can preview !) ; well, all that text to say that, if you find a use, you can modify the memory directory, all loading routines will use it. For examle, it's not possible for the user of TrackmoDOS to load directly a track (because it's a low-level function ! And I want only TOP functions !!) ; but if you desesperatly want to do that, you only have to add a file, with a name, the precise length to load, the starting sector and the number of sectors -- then you only have to call Load or LoadAlloc with the new file to load wanted sectors ! Everything can seem complex, and it is. That's why I have an idea of creating an AmigaDOS library which will give you all needed routines to build your own Handler... Wait and see ! VI - Future compatibility I know want to talk about a different problem from compatibily with all Amigas : compatibility with future versions of TrackmoDOS. Yes, of course, if you code a demo, the actual program of TrackmoDOS will be written with it, so you don't have to care about compatibility ! If it works, it will work. But if you want to work later on a program workning under TrackmoDOS, you'll probably want to use the latest version (if I don't die before, I'll try to ameliorate some shitty points !).. So, here's some notes about what you must and musn't do to preserve compatibility will all TrackmoDOS versions : I already said it, I strongly recommend you to not load files at an "absolute" (fixed) address ; memory like TrackmoDOS handles it could be corrupted (TrackmoDOS handles memory like AmigaDOS, with memchunk principle, everywhere in memory, and you're not enabled to erase them !). So, even if you can directly load at an absolute address with Load(), I encourage you to use dynamic allocations. Memory zone (fixed, because it's out of 'allocatable' memory for TrackmoDOS) between $00001100 (end of TrackmoDOS program) and $00001800 (start of directory) is now a free space. This space is of course here to permit me to extend TrackmoDOS without moving the dir to another address. Well. If you don't want to keep compatibility with an higher version (when programming a demo that will be released soon !), you can use this mem zone for vars, or anything you want ;; but if you want to keep compatibility, don't use, of course, this zone. At least, a note that has nothing to do with compatibility itself but which has to do with programming under TrackmoDOS : it's useless to change the jump address in a function offset of tdos.toolbox, for example to change MemAlloc address to handle yourself memory, because you know that LoadAlloc, etc. call it -- All TrackmoDOS functions, when they call another one, do it directly, without going through the function offset (what ? Can't I program my way ?) VII - Changes from version 2.2 to version 3.0 - handler : totally new code - TrackmoDOS OS : _ memory handling totally re-coded to use all possible expansions. _ gets some infos about the hardware, by using libraries, in order to avoid compatibility problems (TrackmoDOS works perfectly under kickstart 2.0 or 3.0 !) _ function added : MemAvail _ fields added : totalchip, totalfast, agnustype, denisetype, displaytype, proctype, coproctype, kickver (hardware info flags) - T-MON : - re-designed - debugger and trackmodos-handling commands added - better code VIII - The sad end Now you must want (er.. I hope !) to use TrackmoDOS ; anyway I think I explained everything. I hope this program will permit you to make a Trackmo easily, by programming only the cool part of your code : effects, design etc. You'll certainly notice that TrackmoDOS-Handler is 'selfdetaching', it detaches itself from the CLI/Shell.. It means that, while running, it gives back the control to the CLI/Shell that you can continue to use ; or you can close the CLI/Shell from where you ran the TrackmoDOS-Handler, no problemo. The program shows no copyright message ; you've got the choice to give me a credit or not in your demo (a small "Disk routines by Poison/NOVA" will be enough !) -- you maybe think that everybody will look you as a lamer if you say that someone else coded the disk routines ; for my part I think that's lamers who don't give credits ; that's not the disk routines which will make that your demo is cool or not (well, a demo which runs on A500+ and recognizes extra drives is nice...) ; so giving me a credit, when you see all the work I've done, is not big -- that's the only thing I ask you in return of using this program, but once again, you've got the choice. For mad swappers : first, the program is ALREADY packed, so I'm sure you won't fuck up multitasking with trisomic crunchers ; second, forget NO file !! Well, put at least : "trackmodos" (main program), "trackmodos.doc.french" (french doc -- please, even if you don't need it, PUT IT on your swap !! I know some Frenchies who'll appreciate ! And -I'm sorry for all English chaps reading- French documentation is more delirious than this one, I couldn't traduct all bullshits in English !), "trackmodos.doc.english" (approximatively-english doc, this file), "libs/diskfont.library" (needed by the Handler for custom font loading, if it's not present program will NOT RUN !), "fonts/poison.font" (directory) and "fonts/poison.font/8" (Handler font, needed to run too !) ; and of course "tdos.i", assembler include file for AsmOne/Trash'm-One/Devpac. For your personal use, you need all these files except docs, but I repeat it, for a pack, PLEASE put ALL these files, at least (you can also include preferences files, TrackmoDOS-III.pref, in S: drawer). A last thing, everywhere in this doc I speaked about creating a trackmo, but you can of course, with this tool, program a musicdisk, a diskmag, or, why not, a game, the principle is the same ! If you wanna contact me, for telling me your remarks, ideas of improvements, love letters, money, or anything else, take your pen and write to : Poison / NOVA MARTY Emmanuel 10 Impasse du Romarin 34920 Le Crès FRANCE. Tel : (+33) 67-70-80-65 (ask for Emmanuel) If you've got a big problem... You can also send me disks (f.ex. to show me how you use my tool !), I answer to everybody and I send back all disks ! Note too that people who contact me will get the next versions of TrackmoDOS... A little hello to Fireblade/EREMATION, so.. I hope his TDM 3.0 will be out soon, even if he gave no info I think it'll be great.. If not I'll have to include a patch in the Handler but I'm too lazy for that... Thanx to Coronal/NOVA, Mushies/NGC, Cyprien, Xann/SILENTS, Blue Silence/NOVA, Nicolas, Speedpower/PROFECY, Fever, Audiomonster/MELON DEZIGN, DTS/NOVA, Kyle/ABYSS, all my contacts for 'moral support', and above all, my Laetitia for 'physical support'... Tiny hello to Colin Fox & Bruce Dawson, coders of req.library which is not used any more by the Handler (design purposes forced me to kill my lazyness..) Now I just have to end this piece of literature by wishing you good luck with the program, we'll see together again in next versions... - Poison of Nova ______________________________________________________________________________ IT'S FINISHED !! ______________________________________________________________________________