Welcome, Guest. Please login or register.

Author Topic: Screen resize slowdown 80Mhz 060  (Read 9311 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: Screen resize slowdown 80Mhz 060
« on: July 14, 2012, 10:21:52 AM »
Quote from: XDelusion;700033
OK, so MCP and SYSPeed don't play well together.

With MCP I get the lower read out, without it I get:

MIPS: 104.27
MFLOPS: 42.05

Though without it BOOM runs like crap.

I presume MCP is working as it should and is only causing SYSPeed to produce an incorrect reading?

Here is the order in which our lord and savior Franko suggested for my startup-sequence:

Startup-Sequence order after setpatch:

C:Cmq060
C:blazeWCP
C:fblit
C:ftext
C:mcp


MCP may patch over CMQ060's exec.library/CopyMem() and exec.library/CopyMemQuick() patches with much inferior code. There are some test results with how poor the CMQ CopyMem patches are for the 68060 here:

http://aminet.net/util/boot/CopyMem.readme

CopyMem060 is a little faster than Piru's new CMQ060 for the 68060:

http://aminet.net/util/boot/CopyMem.lha

MCP may interfere with or patch over other improved patches as exec.library/SetPatch() has no way of preventing or arbitrating new patches from patching over the same functions. The newer MCP versions are for UAE and the older ones are outdated. It's nice to have all the patches in one that can be selectively enabled and disabled but MCP isn't worth the trouble anymore in my opinion.
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show all replies
Re: Screen resize slowdown 80Mhz 060
« Reply #1 on: October 05, 2012, 12:46:38 AM »
Quote from: NovaCoder;710323

Tried the MMU libs 060 (+mmu.library), seem to be stable but they also seemed to run Quake slower than than standard (patched) Apollo libs, also not sure how compatible it is with RemapApollo.  I might still try to use them to create a 3.1 boot floppy to run some demos that don't seem to get on with my standard 3.9 setup.


With the Mu 68060.library I use this line in my S:Startup-Sequence

MuFastZero MOVESSP ON

This makes the Mu 68060.library a little faster (instead of a little slower) than most other 68060 libraries. It is less compatible with a few very old programs.

Quote from: NovaCoder;710323

I also built the exec v44.1 but it only comes as a 3.1 complete rom image (which you can't seem to split for some reason), this is no good for me because I'm running RemapApollo with 3.9 and patching the built in 3.1 rom image with the Boing bag updates (loaded as modules).   I'm not even sure if it's such a great idea to run v44.1 exec.library if you are running 3.9.


Piru's exec.library is missing some functions that are necessary for AmigaOS 3.9.

Quote from: NovaCoder;710323

I updated my CopyMem 060 patches to the faster version listed in this thread.  This didn't effect the frame-rate in Quake though, even running without any memory copy patches doesn't seem to have any real-world effect?


CopyMem060 isn't much faster than CMQ060. The only time the speed difference might be noticeable would be a lot of small copies in a short amount of time. You do save a little memory over CMQ060. The patch is worth running on a 68060 over the AmigaOS 3.9 copy functions. If you want to "see" the difference, scroll around in a newer version of AWeb with and without CopyMem060 installed ;).

If you have a Warp3D compatible gfx card, let me know. I have some patches that will speed up GLQuake by a few frames. You might try MuRedox/OxyPatcher with other Quakes and see if it's any faster.