@database CadOS faq
@node main "CadOS Frequently Asked Questions"
Q: Did you really need to write an OS just to code a demo? Wouldn't it be
   easier if you just wrote the demo? (from my imp8ient m8 owlz)
A: No, there are a lot of functions in the OS that would be repeated ad-
   infinitum if they weren't functions, such as loading. My demo would be
   less compatible if I didn't spot a bug, it wouldn't support things like
   file compression silently, it wouldn't check up on itself, it would take
   longer to write effects (because the usual way of making a screen is to
   write your own copperlist, calculating the display registers yourself.
   It would take up more memory because I would precalculate fades, etc...
   Besides, I've always wanted to write an OS :)

Q: Why don't you use small data and seperate hunks?
A: Because my data is too small to need 32k of variable storage, and
   multiple hunks creates too many relocs for my liking... :P
   Anyway, the MAIN reason I don't use other hunks is because some packers
   only work on 1 hunk, position independant. If you want to use external
   hunks, sure, do so. I don't mind! But remember to use chip hunks for
   things that would need chip memory! And DON'T use fastmem chunks! I've
   had enough bloody trouble with intros that fail to load, due to the fact
   they have hunks wanting MEMF_FAST memory!!! DO NOT USE MEMF_FAST, USE
   MEMF_PUBLIC !!!

Q: Why move the VBR?
A: Because you never know when some idiot will forget to check his memory
   allocation, and blunder on with a pointer to $0.l ... Also, if there is
   fastmemory on the computer, the VBR will move to fastmem and the whole
   demo will instantly speed up.

Q: Why don't you always write back to the _bplconX registers?
A: Because only some flags are going to affect global changes, like ECSENA.
   The original _WriteDispRegs routine used seperate bits for the global
   flags, which were chosen by me. That was far too slow, so I just decided
   to use the bplconX caches as masks instead.

Q: Why is there no multitasking?
A: Demos? Multitasking? What a strange concept! If you mean "why isn't
   everything system-friendly", well, that's a hotly debated topic on
   comp.sysa.amiga.programmer. Let me put it this way - if you are
   programming in a multitasking- and system- friendly way, then you can
   use AmigaOS's high-level routines which are almost like CadOS, except
   slower if they are not patched to use non-standard external hardware
   (ie using a 256 colour screen is slower with the OS, unless the user
   has a patch that activates a 64-bit CyberVision card :-)
   My personal opinion is that the OS is not designed to do demos with,
   but having heard rumours about new Amiga-like computers and operating
   systems, I hope that in the future OSes will be much more acceptable
   to processes that blantantly use up all resources and obscure all
   other programs, for that is what demos are all about.

Q: Could you add an option to make the demo run on an intuition screen?
A: No. Not unless the demo coder did that too.

Q: Why not add maths functions?
A: Not today, later. Besides, most coders code their maths routines inline.
   You'll just have to make do with the trig macros.

Q: Hey, why not allocate memory MEMF_REVERSE if it's <1k to help prevent
   fragmentation?
A: Because if the demo screwed, it'd probably kill most, if not all, of my
   ramdisk. The further the distance between important memory, and demo
   memory, the better. Memory protection would be even better.

Q: Why not code in some memory protection, then?
A: I don't have a clue how to work an MMU. Someone tell me!

Q: What about serial and trace mode debugging?
A: Later. It's a very useful concept.

Q: Couldn't you write a set of system interrupt handlers?
A: Yes, I could, but I'd prefer to have very little handling, so the
   programmer can write his own with little loss of performance.
   Unoptimised (ie. flexible) int-handlers take too much time to execute.
   If you want information on writing them, get the aminet file 
   dev/asm/Exceptions.lha

Q: Why did you waste time taking out all absolute addresses?
A: Because I'm addicted to writing position independant code. I have to
   concentrate hard to stop it. :)

Q: Why is there no routine for creating a chunky copper?
A: Because I can think of about 10 ways to make one. Custom makes are more
   fun, y'see. I might add one next time. Maybe. They're very easy to do.
   Look at src/plasma, src/fire and src/rotzoom for some examples :)
   Besides, I'm informed by many sceners that chunky coppers are out of
   date. "Like, you're looking at yesterday's effects, man" said one
   person. It seems to be the general consensus that "c2p" techniques are
   a better idea, even if they're not as fun to play with as chunky
   coppers.

Q: What are you thinking about for file decompression? (from eager packing
   utility author)
A: There are two considerations for file decompression. First is that the
   unpack code MUST be in an external library, because it keeps the size of
   CadOS down, and it also allows decrunch-bugs to be fixed. I like to use
   both PowerPacker and XFD, because PP has an 'overlayed' decrunch, that
   is that no more than the size of the decrunched file + 8 bytes is
   needed to load and decrunch the file. This means bigger files will load
   OK, and the demo needs less memory to run. I will always support
   overlayed decrunchers seperate from XFD, because of this reason.
   However, I will not support overlayed-one if they need a big or variable
   safety margin (the 8 bytes for powerpacker) because that memory then
   goes on to become part of the loaded file, and if it is big then it is
   going to be a big, unused block of memory after the file is loaded,
   that won't be available until the file's memory is freed. I will put up
   with XFD's need to have seperate blocks of memory, because it will
   decrunch ANY file.
@endnode