$VER: NoBypass 37.1 8.10.1999 by Simon N Goodwin, updated June 2000 NoBypass is a CLI tool to improve program compatibility on 68060s. This command toggles the enabling of the 68060 CPU bypass between the primary and secondary execution units. It's copyright 1999 Simon N Goodwin, first published as part of the Amiga Format Xmas 1999 stability feature, now freely distributable. This does not run from Workbench and should be run from a shell or inserted in your startup. The program is based on information from the Rev 3.1 Motorola 68060 errata. Background The 68060 is a brilliant chip but it's extremely complicated and was never officially supported by Commodore when the Classic Amiga was actively developed. As you'd expect from Motorola it's a clean design with very few bugs compared with Intel offerings, but there are a few traps for unwary programmers. These may affect Amiga 68060 systems because programs were written before the 68060 was known about, or by people unaware of the special features of the chip. Also some programs have bugs that only the super-fast 68060 reveals. The best solution to all these problems would be to get updated software, but in the absence of such updates NoBypass provides a more general cure. This tiny program could make your 68060 faster and/or more reliable. It has been distributed privately by the author, then put on a couple of web pages after Amiga enthusiasts found it helped their systems. I'm grateful to Frank Wille, Greg Donner and Marcel DeVoe for encouraging reports, and Thomas 'Thor' Richter for general CPU-related information and discussion. The program has been found to be beneficial with Mac emulation, some old Amiga software, and some VBCC programs, including Amiga Quake. It only fixes one specific type of problem, so it's hardly a panacea, but if this is just the problem you've got, it's ideal, and it's not known to cause any problems, other than a slight loss of speed in some cases. Web pages that have previously carries this fix, with my permision, include: http://www.gregdonner.org/gvp4060/gvp4060.html - the unofficial GVP-M home page http://devnull.owl.de/~frank/quake_e.html - the Amiga Quake port home page It may be worth consulting those pages for related information. This bug has also been discussed in my technical articles for Amiga Format, alas no longer published. Recent versions of the phase 5 68060 library and Fusion emulator contain a similar option, so this utility will be most useful to people who have some other 68060-based Amiga system (Apollo, GVP, QuikPak, etc) or 68K native emulator. Consult the errata on Motorola's SPS web site for gruesome details (look in http://www.mot.com/SPS/) or read the source which should make sense to skilled assembler programmers familiar with the 68060 CPU manual. I've not been able to reproduce this bug in my 'laboratory' but suspect it may be at the root of some if not most Mac emulation 68060 faults that currently require SuperScalar execution to be disabled. I know it's a small change but hope it's significant in some cases. Please let me know how you get on. I'm sharing it with the Amiga community via Aminet in the hope that we can build up a bigger database of programs that are affected. You should also look at FixGetMsg by Frederick H. G. Wright II, which fixes a problem caused by the 68060 outrunning the Amiga interrupt hardware. This fix is also on Aminet: util/.boot/FixGetMsg.lha, 2K. Finally, be wary of OXYpatcher which has at least one bug in its FPU emulation. I have attempted to report this to the author Achim Koyen after testing version 3.12 and 3.13, but received no reply. Mand2000 goes awry when counting more than 32K iterations in a floating point loop, because of a signed not unsigned test in the emulation patch routine. This only happens when OxyPatcher is used on a 68060 - not that you'd want to crunch 20 digit numbers through the Mandelbrot formula tens of thousands of times per pixel on any earlier processor! Mand2000 is a fine programe, but it's showing its 68882 roots. THE PROBLEM Enough background. What's it all about? Original 68060s (produced from mask set xF43G) have an obscure bug which means they may 'bypass' data already in a register when a long word value is written to memory then immediately re-read to a data register and operated upon. This only affects very stupid code or compilers - competent coders will not re-read a value they aleady have in a CPU register - and requires a characteristic sequence of instructions that generate, store and use values in rapid succession. It's quite hard to generate this case, but some programs may give different results on a 68060 than on other processors as a result. This problem was fixed in 68060 mask set xF84W and the scaled-down LC and EC060 mask set xF10H, but a lot of Amiga boards have the earlier version... THE CURE Motorola's recommended workaround for this bug is to disable one of the 68060s result-forwarding features, which tries to eliminate a pipeline stall when successive instructions store and reload data to and from the same address. This is not a common case so the workaround is expected to have "very limited performance impact on most programs" - and if it makes your naive compiled Amiga or Mac code work, it may be well worth it - and far less costly than disabling super-scalar operation entirely, the fix recommended to get some Mac emulation working (e.g. in Fusion). TESTING The state of bypass hardware can be seen by checking if bit 5 of the PCR register is set. You can do this with a bit of custom code if your assembler supports the full 68060 instruction set (HiSoft DevPac 3.18 and Barfly do) or CPU060 by Ralph Schmidt, shipped with phase 5 68060 accelerators, can be used to check the bit's state: System: 68060MC Mask 0-1f43G,2f43G-0g65V Revision 1 Settings: (INST: Cache Burst) (DATA: Cache Burst) (BRANCH: Cache) (Superscalar) (Store/Load Bypass disabled) Register: CACR=$80808000 PCR=$04300121 BUSCR=$00000000 If the bypass is enabled, as SetPatch and 68060.library leave it, you get something like this: (Store/Load Bypass) ... PCR=$04300101 USAGE Every time you run the program it attempts to TOGGLE bypassing. If bypass was previously on, it is turned off, and vice versa. The program returns 0 if successful and 60 if the Attn_Flags in Execbase indicate this is not a 68060, when it does nothing. It uses no memory resources except while running (and not after it has returned). If you have programs that fail in Superscalar mode, try them with Superscalar dispatch enabled after running NoBypass, and you may find they work, and faster than with Superscalar mode disabled. REPORTS Marcel DeVoe beta-tested this program on a 68060 and reported that it fixed Shapeshifter compatibility for the Sierra game, HOYLE ONE, which would otherwise abort unless the Superscalar features of the 68060 were turned off - retarding the Amiga side as well as relatively friendly Mac applications - but after running NoBypass the program works, and other code is hardly effected. It should also benefit Mac device drivers and other programs that are not compatible with the full Superscalar operation of the 68060. Marcel emailed as follows: "I just tried your program with a Sierra game, HOYLE ONE, which would always give me an abort with Pachandle failure whenever Klondike was clicked. "I always had to remember to disable SUPERSCALAR before running the game either via the shell or with a workbench program I have called "System060" which you can set caches via workbench. "Well so far your little program now eliminates that step. I haven't a chance to try it yet in Fusion, but I will let you know how it all goes. "Of course I don't have System 8.1 to truely test it with, having just OS7.5.5, but I did have problems with occasional printer hangs with my Epson printer with its driver through my Emplant board until I disabled Superscalar." Some users of Frank Wille's Quake 1.09 port report that benefits, too. I am keen to hear of other programs that certainly benefit. Please try with and without the patch (or run it again and retry, as each invokation toggles the patch) to ensure that this, rather than some other random factor, is making the difference, and send details of the program affected (version and size) and environment (your accelerator and CPU libraries) by email: Simon N Goodwin, simon@studio.woden.com Warwick, UK, June 2000.