³Lame No-Exit Demos.² -------------------¹ By Estrup/Static Bytes. In Top Secret issue 8, Zozo/Majic 12 wrote about the lameness of non-CLI-packs, e.g. because of the fact that you have to reset even after watching a small intro, because the boot-menu has to reload. I completely agree with Zozo, but I don't think making CLI-menus will solve the problem completely. Today, more and more demos have no exit, so you have to reset, no matter what type of menu the pack uses. 'But my demo uses the entire chip-memory', I hear a lot of coders crying. Well, maybe so, but all memory used by a demo doesn't have to be chip-memory. Even many swappers (no offense) know, that only graphics and samples have to be placed in chip-memory, thus allowing you to load code, scrolltext, tables and music-patterndata into fast-memory. A year ago, I wouldn't have done that either, but today, with the extremely low prices on memory expansions (at least, low prices compared to the ones before), everybody has got 1 MB, so I don't think that making demos '1 MB only' is unfair. As an example of a big program WITH exit, let's look at the slide-show from the Lowlife '91. It contains 290 KB of digitized pictures and about 140 KB of music. Together with the 'smaller' stuff, that is, the code, scrolltext, logo and fonts, the uncrunched version of the slide is a file of more than 483000 bytes. Even though it's that big, you can exit (for those of you who haven't noticed: Press both mousebuttons together for a while). For those of you who are used to just coding absolute, like: ORG $30000 LOAD $30000 - I'll now explain a better solution. Those of you who are experienced object-file-coders, just skip to the last part of this article. Now the 'better solution': First of all, do NOT just start using absolute addresses in fast-memory, like: ORG $c20000 LOAD $c20000 This is a VERY bad idea, 'cause fast-memory doesn't always use the addresses $c00000-$c80000. External A500 fast-memory ('real' fast-memory), together with ALL A2000 fast-memory uses the addresses $200000 onwards, so using absolute fast-memory addresses will just make Amigas with this kind of fast-memory crash. Also, the demo won't run on A2000's with 1 MB of chip-memory and no fast-memory. Actually, don't use fast-memory at all, instead you should use 'public-memory'. This way, your data will automatically be loaded into fast-memory if there is any, and if not, chip-memory. Now, how is this implemented in your code? Let's take a look at an example of a typical demo-source, without absolute addresses: The first part of your source should contain the code (except the copper-list(s)), scrolltext, tables and song (that is, the module, except the samples). All this can be placed in publicmem. To include external files, don't use >Extern "FileName",Address. Instead, do it like this: SinTable: IncBin "SinTableFile" Song: IncBin "mod.song" etc. When assembling, these files will automatically be loaded, and enough memory will be reserved for them. Thus, the address of "Song" will be the address of "SinTable" + the length of the SinTable-file. Note that you should NOT start your source with ORG and LOAD. Secondly, you must include the parts of your demo which need chip-memory. Here is an example: SECTION AnyName,DATA_C Your copper-list(s). Logo: IncBin "LogoFile" Font: IncBin "FontFile" Samples: IncBin "SampleFile" etc. The SECTION-command tells the system, that the following is a DATA-hunk (hunk: 'object-file-part') and that it HAS to be loaded into chipmem. As we haven't written any SECTION-command before the first part of the source, this will automatically be a CODE-hunk and placed in public-memory. At this point, I have to mention, that you, of course, have to split up your module into song and samples, and you also have to change the replay-routine a bit (the part of "mt_init" that calculates the addresses of the samples), but that's not too much work. Finally, place your screen-mem(s) and other memory-areas that are empty, when you run the program: SECTION AnyName,BSS_C Screens: ds.b 40000 (ScreenSize) etc. The BSS-hunk will not be saved with a length of 40000 bytes, only a hunk-header with a number, indicating the length, is saved. When this hunk is loaded (that is, when you run your demo), 40000 bytes of chip-memory will be reserved and cleared. Now, to save your demo, just assemble and type "WO". If you load it into PowerPacker , you will get a list, telling you the hunk-types and their sizes, so in this way, you can check that you've done it right. 'Are there no disadvantages?', I hear you ask. Well, of course. First of all, all external files are loaded every time you assemble your demo. If you have a harddisk, this is no problem, but if you don't, you can reduce your waiting time in several ways: 1. Use a very small module when coding, and just include the real one when the demo is finished. Usually, the graphics won't use too much memory. 2. Use the (good?) old way (ORG and LOAD) while coding, and 'convert' your source when it's finished. 3. Buy yourself a harddisk! Another disadvantage is, that some routines run remarkably faster when the code is placed in fastmem (such as fractal-routines). Of course, it would look quite weird, if a routine runs in 1 frame on machines with fastmem, and in 2 frames on e.g. A2000's with only chipmem. On the other hand, I guess most A2000 owners with 1 MB chipmem have a switch for 1/2 MB chipmem and 1/2 MB fastmem, so that's not too much of a problem. Anyway, I think the advantages are much bigger than the disadvantages. Like I mentioned in the beginning, it'll be possible to exit even big demos, and also, demos coded this way won't mess up your CLI-window etc., like some demos do, 'cause they use memory from $1c000 or so. In general, I think this way of coding demos could create a whole new meaning to the word "one-part-demo", 'cause it'll be possible to make one-part-demos much bigger AND 'exitable'. If anybody has any comments, questions, suggestions etc., I'd like to hear them. Just write to Top Secret, or contact me directly at: Christian Estrup Tornevangsvej 5 B 3460 Birkerod DENMARK phone: (+45) 4281 4849.