Troubleshooting

Q. After assembly, the file is not executable.

A. This can be caused by two reasons: First of all, make
sure you haven't forgot the 'warpreq' command before the
source-code. If you haven't forgot this command, the error is
caused by a familiar bug in Storm PowerAsm. To prevent
this bug from being there, remove all the 'sections' from the
source-code. The executable should work now. If not, you might
have to learn some files that weren't learned before.

Q. The assembler gives errors just after porting a source-
code.

A. See Trial And Error...

Q. The status-display is empty.

A. Install the font in your fonts: directory.

Q. After directory-processing, several symbols have been
interpreted in a wrong way.

A. This is caused by symbols which haven't been learned and
are therefore not understood correctly. Make sure you have
learned all the source-code files that are needed for the
source-code that has to be ported. Also, always flush the
learn-file when a new project is started.

Q. How much faster can programs get after porting from 68k?

A. Ported programs can become MUCH faster and even get close 
to real PPC-assembly speed. Sadly, context-switches are very
slow so the coder should make sure that CPU-intensive 
algoritms are not strained by too much 68k calls. 

However, only one command has to be altered when a native PPC 
port of Workbench is finished: This means that all the PPC680x0-
ported programs will run without context-switches on future
Workbench-revisions.

Q. What is QB loading???

A. This was a left-over from older revisions of PPC680x0. It
causes bugs when the low-word of a calculated address or value 
is higher than $7fff. On the other side it is a tad faster than
the normal loading-mechanism for PowerUp, so experienced
programmers may find it useful sometimes. It is useless for
WarpUp, though...!

Q. What happened to AltiVec support?

A. Ask phase5...

Q. The special effects bar runs flickery on gfx-boards. What now?

A. Try to synchronize the 'invisible' OCS/ECS/AGA screen to
the gfx-board screen by selecting a refresh-rate that is equal,
double or half the vertical-blank frequency of the graphic-board
screen. This should solve the problem.

Q. Why is there not much PowerUp support?

A. Because PowerUp-support is no longer useful since nearly 
everyone moved over to WarpUp. There's no reason to use PowerUp 
anymore as WarpUp is simply more flexible.

Q. Labels are not converted correctly. What's going on?

A. This problem can be caused by two reasons: First of all,
   PPC680x0 does not support complex brackets. Therefore, the
   following cannot be done:

       move.l   ((3*4),d0),d1

   Make sure the program does not contains brackets in between
   brackets. Also, several sums will cause strange results.
   This should do the job:

       move.l   (12,d0),d1

   However, complex immediate values ARE supported:

       move.l   #(3*2+(3*6/2)-1)*3,d0

   is converted correctly.

   The second reason for incorrect label conversion is a
   fault of the user, caused by not flushing the learnfile.
   When a source-code contains:

_SysBase        equ     $4
  
   and you have converted it using PPC680x0, the learnfile
   contains data claiming that '_SysBase' is a value.
   Assembling the output-file will cause a 'double symbol'
   error, which means that the line has to be removed. For
   example:

;_SysBase       equ     $4

   will remove the line. However, the learnfile MUST be
   flushed to make PPC680x0 know about the changes. Elsewise
   the learnfile will keep on claiming that '_SysBase' is
   equal to $4!

Q. Any notes about register usage?

A. Yes: Don't use r0-r2 or r28-r31 as they are in use by 
   PPC680x0s emulation code system. r13 is the WarpOS Stack 
   Pointer, so don't use this one as well! And finally, remember 
   that BCD emulation has been implemented for compatibility 
   only: Using them will flush r11 and r12.