Acorn User 3/AUCD3.iso/funland/emulators/amiga/uae/Docs/FAQ

Text File | 1997-06-01 | 20KB | 356 lines

Some Frequently Asked Questions. Please read this carefully if you have
problems.

** COMMON PROBLEMS

Q: Sometimes, after UAE exits, there is no autorepeat for the keys!
A: Do "xset r on" (happens only in X, apparently mainly on Solaris boxes.
   Dunno why.). [Should be fixed by now. Note that this always happens when
   UAE crashes]

Q: When UAE starts up, it says "Illegal instruction: 4e7b". Why?
A: That's normal, it's just the Kickstart CPU type test.

Q: When UAE starts up, it says "Illegal instruction: 00f8" (many times). Why?
A: That's because your Kickstart ROM was compiled for the 68020.
   (could also happen when there's a bug in UAE)

Q: When UAE loads <insert your favourite game> it says "Non-standard sync".
A: Your favourite game is copy-protected. There are ways to transfer such
   disks, but it's complicated and I won't help you because it would be much
   too time-consuming to figure out all sorts of copy-protection schemes.
   I hope there will be a general solution some day, but for now you're
   unlucky.

Q: While it compiles, it says "xxx illegals generated" or "16 mismatches".
   Is this a problem?
A: No. I can use this information to tell whether there is a problem, and
   there isn't.

Q: How can I produce an @ symbol (or any other sign)? On my PC keyboard it's
   AltGr+Q, but that doesn't seem to work.
A: Look at the keyboard of your Amiga. Use the same combination that you would
   need on a real Amiga. These combinations differ across countries. Make sure
   you have loaded the right keyboard translation table for AmigaOS (e.g. in
   Germany, make sure there's a "setmap de" command in the startup-sequence)
   You can probably create a @ sign by pressing Alt+2, or Shift+2.

Q: The "configure" script does not find Tcl/Tk, but I have it installed!
A: The script checks for an executable called "wish4.0". There is currently
   no better test. Unfortunately, this executable is not always present,
   even though Tk 4.0 is installed. If that is the case, find the "wish"
   executable, go into the directory where you found it and type
   "ln -s wish wish4.0" (provided you have write rights in that directory,
   i.e. you are super-user). Then go back to the UAE directory, remove the
   file config.cache and rerun "configure". That should do the trick.


** INCOMPATIBILITIES

Q: UAE does not work with my Kickstart 1.2 image.
A: You may need to turn off the harddisk and fastmem emulation with the "-a"
   parameter. Kick 1.2 doesn't support the autoboot features that the harddisk
   emulation requires.
   You can tell that you are suffering from this problem if UAE gives you the
   message "filesys_bput called".

Q: What do I do if a game/demo/application doesn't work?
A: If you're trying to run a game or a demo, enable some slow RAM, and try
   running it again.  Some older software has compatability problems which
   slow RAM can sometimes fix.  If it's an application, check for obvious
   things like Kickstart version requirements, RAM, etc.  Also make sure the
   software you're trying to run isn't for AGA equipped machines.


** AMIGA DISKS, DISK IMAGES, HARDDISKS, CDROMS

Q: Is it possible to read Amiga disks with a PC?
A: Ask that in comp.emulators.misc :-) The answer is: NO! Unless you invent
   and build some extra hardware yourself, which no one appears to have done
   yet. You'd also need some extra software driver; the whole setup would be
   similar to the X1541 cable/software for C64 emulators.
   Some people have pointed out that you can buy a controller named "Catweasl"
   which apparently can read all sorts of disks on a PC, including Amiga
   disks. Please don't ask for details, I don't have the thing and I can't
   tell whether it works.

Q: Couldn't I attach an Amiga floppy drive to the PC somehow, and use that to
   read Amiga disks?
A: You can attach Amiga (low-density) drives to the PC, because they are
   completely identical to PC drives. This won't help you, because the problem
   is not the drive, but the PC floppy controller. You have to live with it.

Q: But the PC can read 11-sector formats!
A: Yes, but those sectors look a little different to the hardware.

Q: But the Amiga can read PC disks!
A: So what?

Q: But the PC can read Atari ST disks!
A: So what?

Q: But...
A: No way. If you still are convinced that it must be possible, prove it.
   Write a program to read Amiga disks with a standard PC controller, and I
   will apologize in public.

Q: How can I use DMS images?
A: Run DMS under UAE and use it just like you would on a real Amiga.
   Decompressing a DMS file to DF0: will overwrite the .adf file that is
   currently used to emulate df0:.

Q: How can I transfer non-DOS disks that are used by many demos?
A: With transdisk. The fact that they are unreadable by AmigaDOS does not
   mean they are unreadble by transdisk.
   Long explanation: There are two things to consider when talking about the
   "format" of a disk. First, the low-level format which divides each track
   into sectors in a special way. Most Amiga disks are in the standard Amiga
   format which has 11 sectors with 512 bytes each per track, with a total of
   880K per disk. There's also some extra information outside the sectors so
   that the floppy controller can find the sectors. PC disks use a different
   format, which is the reason why a PC controller can't read Amiga disks.
   If a disk is formatted this way, it can be copied with the normal AmigaDOS
   diskcopy program or the Workbench equivalent, and transdisk can handle it.
   Copy-protected disks have a different track layout (sometimes, they don't
   divide the tracks into sectors at all, or use more sectors, or put
   different things between the sectors. This type of thing can't be handled
   by diskcopy or by transdisk.
   Now, the second part of the "format" of a disk is the filesystem. If you
   want to put files and directories on a disk, you have to write some special
   information into some of the sectors on the disk. That information includes
   (for example) the name of the disk (e.g. "Workbench1.3"), and what files it
   contains. This information is called a "filesystem". The Amiga knows about
   several filesystems: There is the original filesystem (called OFS), and the
   newer Fast Filesystem (FFS) which was introduced with Kickstart 1.3.
   If you don't put a filesystem on the disk, the data in the sectors can still
   be read by programs like transdisk or diskcopy, but the data makes no sense
   to them. The point is, it doesn't have to. It only has to make sense for
   the Workbench which tries to determine what files there are on a disk. If
   the Workbench can't find a filesystem it knows about on the disk, it will
   be marked as a non-DOS disk (as opposed to an "unreadable" disk which you
   get if the low-level format is different from the standard).

Q: How can I change diskfiles?
A: Your version of UAE may have a user interface (the X11 version does) which
   enables you to do this. Read your system-specific README file for details.
   You can also use the "uaectrl" programs from the "amiga" subdirectory.

Q: Why is the floppy emulation so slow, after all the disk image is on a
   harddisk?
A: Because the disk rotation is emulated. This is necessary. Use the harddisk
   emulation wherever possible.

Q: <insert your favourite problem with the hardfile emulation here>
A: Don't use the hardfile. Use the filesystem emulation ("-m" option).

Q: How can I read Amiga CD-ROMs?
A: With the harddisk emulation. Give UAE the parameter "-M CD:/cdrom" if you
   are using a Linux system with the CD mounted at /cdrom, or "-m CD:D:\" if
   you are using DOS and D: is your CD-ROM drive (and if you have a different
   system you should be able to figure out what to do)

Q: Is it possible to read Amiga harddisks with a PC?
A: Yes. Linux 2.0 has an Amiga filesystem that can reportedly read Amiga
   OFS/FFS harddisks. Please don't ask for details, I didn't write the thing,
   and I don't use it (yet). I did use it to read .adf disk images, though.


** FUTURE PLANS

Q: When will version 1.0 come out, and what will be in it?
A: Rather soon, I hope. I have done almost all I wanted to do in 0.6.x, and
   for 0.7.x I'm only planning to repair the copper so it runs with some
   resemblance of speed. After that, there might be a 1.0 version.

Q: Will there be a shareware version or some registration fee for future
   versions of UAE?
A: No.

Q: Will you support CyberGFX (or some other standard) to make the Workbench
   run in a higher resolution?
   Couldn't you use ARDI's CPU emulation to speed it up?
A: UAE is free software. It comes with sourcecode. ARDI's Executor, and as
   far as I know all the Amiga graphics card "standards" are proprietary and
   sold commercially. The companies that make these programs have no reason at
   all to give away their code for free, because they wouldn't make any more
   money if they did.
   The only option for better graphics support is to rewrite the graphics
   library with a native equivalent. That's a huge amount of work.
   (yes, I really get asked this kind of thing! I don't know where people take
   these ideas from).

Q: Will there be any form of support for high-resolution graphics modes
   (e.g. Workbench in 1024x768)?
A: I don't know yet. I hope so, but there are some technical difficulties.
   There are several options how it might be implemented:
     - reimplement parts or all of the Amiga OS: Painful.
     - emulate graphics card hardware: _should_ be rather easy, once you get
       chipset documentation (maybe steal from Linux/68k, I think they have
       some support for graphics cards in their X server). You'd still need
       some form of commercial support software, i.e. a CyberGFX or EGS driver
       or whatever for the particular graphics card model that's emulated.


** UAE SPEED

Q: Would it be possible to speed it up by emulating the CPU native on, say,
   a 68k Mac?
A: I doubt it. UAE needs to be able to interrupt the CPU emulation anytime to
   perform tasks necessary for emulating the hardware. So you can't just let
   it run all by itself.

Q: Would it be possible to speed it up by using graphics accelerator boards
   for example by using the blitter in S3 chips?
A: I doubt it. I'm no PC graphics card expert, but probably the only thing the
   S3 blitter and the Amiga blitter have in common are seven lowercase
   letters. Even if they were similar you'd have to keep all Amiga chip
   RAM in the graphics memory and that would most likely make everything
   painfully slow.

Q: How about adding special support for the GUS/other wavetable boards that
   uses hardware features to speed up the sound emulation?
A: Again, due to the differences in Amiga and PC (in this case: GUS) hardware,
   this isn't really feasible. You _might_ get something like this to work in
   some special cases (ProTracker modules might be a case that could be made
   to work), but I don't think you can come up with something that emulates
   all of the Amiga sound hardware.
   The problem is that by just examining the values a program writes into the
   audio hardware registers, you can hardly figure out what a program is
   trying to do, and what it is going to do in the future. In contrast to
   that, it's easy to write a SoundTracker module player for GUS cards because
   you know exactly what you are playing, and how you have to do it.
   (That doesn't mean you can't use the GUS for sound output; you just can't
   use it to _speed up_ the sound output)

Q: Emulating all the hardware is a bad idea. Why don't you just emulate the
   OS? After all, that's what makes the Amiga the Amiga.
A: Short answer: I disagree.
   Long answer: The OS is half of what makes the Amiga the Amiga. It is a very
   nice OS, and there are some features that I miss in any other OS, but it is
   also severely lacking in terms of (for example) memory protection and
   filesystem performance.
   The other thing that made the Amiga special back in the 1980s is the custom
   chip architecture. If you look into old (1985) computer magazines, you will
   find that the capabilites of the Amiga OS are only mentioned as a side
   note, because people were not aware that it was revolutionary for a home
   computer. They were aware, though, that the Amiga could display 4096 colors
   at the same time and that it had a blitter and a copper that could do all
   sorts of stuff, like bouncing balls for instance. And I think it was the
   superiority of the hardware that made the Amiga a success.
   I see UAE as a program that is similar to C64 emulators: it allows you to
   run some old games and other programs that you can't replace with better
   equivalents on the PC. As such, it can already be used to run non-action
   games (like Monkey Island or Bard's Tale) at a satisfactory speed. Faster
   CPUs will eventually make it possible to run action games, just like faster
   CPUs have made it possible to emulate a C64 at full speed on a PC. UAE is
   not (primarily) meant for the Amiga PowerUser who is running high quality
   applications on his A4000 with a 68060 board, but for people like me who
   switched from an A500 to the PC a few years ago because they wanted to make
   money by developing software.
   Besides, emulating an OS is far more difficult IMHO. Especially if the
   platform you are emulating it on is completely different than the platform
   that is being emulated. You'd have to mess with endianness conversions and
   other nightmares. The AmigaOS wasn't designed with portability in mind
   either.

Q: How fast is it?
A: This is the most difficult question to answer. The easy way to answer is
   "It depends", but I'll try to do better. All timings I give here were
   measured on my machine, a P90, using SVGAlib, with the FASTER_CPU and
   DONT_WANT_SOUND options. Note that different versions of UAE generally run
   at different speeds, so take these timings with a grain of salt.
   The MC68000 emulation is more than twice as fast as a real A500. I measured
   this by letting PowerPacker try to compress itself (it already was
   compressed). It took UAE about 6 minutes, my A500 took about 15. You can
   get about twice the speed of an A500 for this type of program (not much
   graphics activity) or if you set the frame skip rate to a high value.
   For games and demos, the CPU speed does not matter, but the average frame
   time is important. UAE can calculate this automatically. The SVGAlib
   version gives the number when you exit the emulator, to obtain the value
   with the X version you need to interrupt it and type "c" in the debugger.
   A real A500 has a constant frame time of 20ms (50 Hz).
   If you have a game/demo that has lots of blitter activity, many copper/
   sprite effects, dual playfields and scrolling, no one can help you.
   Fortunately, this case is extremely rare. Normal games that have a number
   of blitter objects, scrolling and maybe some sprites run at 1/3-1/4 the
   speed of an A500 in the worst case, some run at 1/2 the speed. Lowering
   the frame rate helps enormously here, and at 1/5 frame rate, about
   everything runs somewhere between 50% and 100% the speed of an A500.
   This still isn't the full story (I bet you start to see why the question is
   hard to answer). A real A500 without fast memory gets slowed down to about
   half its speed in Hires 16 color mode. More bitplanes also slow UAE down,
   but not quite as much, so it can be several times faster than an A500 in
   that mode.
   Finally, some remarks about the m68k->i386 code compiler that is available
   in the Linux version of UAE. It shouldn't be used for games, it will
   completely kill your frame rate. It's possible to use it for Workbench
   applications, though, and the frame rate shouldn't be a problem in this
   case.
   I measured PowerPacker the same way as described above, and the time when
   using the compiler is slightly above 1 minute (10-15 times an A500). With
   the USER_PROGRAMS_BEHAVE option, it's as low as 40 seconds. I've also run
   the BeachBall benchmark from AIBB 6.5. This takes around 10 minutes on an
   A500, UAE is 3 times faster with the compiler. For some benchmarks that
   use function calls heavily, the compiler isn't a win (although the current
   version should no longer be slower like previous ones). I have little
   "real world" data, please let me know if you made any experiences with the
   compiler.

Q: How can I make it faster?
A: Run the emulator in the lowest screen mode (320x200), set it to 256 colors,
   make sure aspect correction is disabled, and set the frame rate to every 3rd
   frame.  Finally, disable sound (if you have a version that lets you compile
   your own executable, set "DONT_WANT_SOUND" in config.h). It won't look very
   nice, but it will run as fast as your machine allows.
   If you are running the X version, make sure you have commented out
   DONT_WANT_SHM in config.h. This option is "safer", but makes the emulator
   very slow. Even better, when you run configure, say "configure
   --enable-dga" if your X server (XFree86 3.2 or higher) supports it.


** MISCELLANEOUS

Q: Do I need a real Amiga to use this program?
A: Yes.

Q: Where can I download a Kickstart ROM/Amiga games?
A: Read the docs again. You can't. It would be illegal to put a ROM image or
   other copyrighted software on the net (yes, even if you once bought a
   specific Amiga game and sold it together with the computer, downloading the
   same game now would still be illegal. Sorry.)

Q: Does UAE run on the DEC Alpha/Sparcstations/SGIs/whatever?
A: UAE should run on all Unix systems that have at least X11R5 and a decent
   C compiler installed. So the answer is probably yes. Just use the generic
   Unix source and follow the instructions in README.UNIX to compile it.

Q: Why is there a blank area on the left side of the screen?
A: The Amiga can display graphics there, but usually doesn't because this
   would disable some sprites. The area is only used by some overscan demos.
   Normal screens are off-center. I'm not going to do anything about that.
   If you can't stand it, you can try to use 320x200 or 640x480 resolution,
   which will attempt to center the screen. This is near impossible to get
   right for every program. If your screen doesn't fit in lower resolutions,
   use 800x600.

Q: Where is a complete summary of all command line switches ?
A: In the README files. You can also generate it yourself by typing:
   uae -h > uae-help.txt

Q: Benchmark program <insert your favourite benchmark> gives weird results.
A: Amiga programs run by the emulator think the Amiga timers can be used to
   measure real time. But in UAE, they only measure "emulation time". Sysinfo,
   for example, gives the same results on all machines. So don't run
   benchmarks to test the emulator speed.
   Some benchmarks also use tight loops of DIV or MUL instructions to measure
   CPU speed, and in "emulation time" these instructions take as much time
   as any other instructions, and you'll get much too high values.
   If you enabled the "HAVE_RDTSC" option, running benchmarks makes some more
   sense. Still not a lot, since there is a minimum speed that the benchmark
   will report on every machine. The faster the machine, the more accurate
   will your results be.

Q: Wasn't this called the Unusable Amiga Emulator?
A: Yes. But no one thought the name was very fitting anymore, though. It was
   only really appropriate for v0.1, which couldn't even boot.