FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

DEBUGGING

Handle conflicts with RAM Doubler


I've written a pretty vanilla FBII program. It's been running perfectly on a variety of systems and configurations. I just ran it on a machine using RAM Doubler and it didn't work. Disabling RAM Doubler and it worked.

In particular, it didn't play a 'snd ' resource from an external file. The code leading up to it, freely plagarized from the Handbook and Turovich, is:

LOCAL FN PlaySound
  oldresrefnum% = FN CURRESFILE
  srcresrefnum% = USR OPENRFPERM("extfile.rsc",SYSTEM(_aolVol),_fsRdPerm)
  LONG IF srcresrefnum% <> 0
    snd& =3D FN GETRESOURCE (_"snd ",resourceid%)
    LONG IF ((FN RESERROR =3D _noErr) AND (snd& <>0))
      DEFSTR LONG
      snd$ = "&"+MKI$(snd&)
      SOUND snd$
    END IF
  END IF
  CALL CLOSERESFILE(srcresrefnum%)
  CALL USERESFILE(oldresrefnum)
END FN

Any idea why this would not work with RAM Doubler but would any other time?
Thanks in advance.

Jeff Schwartz


Version 1 of RAM Doubler screwed up resources during save operations. I had heard that newer versions did not, but never bothered to by RAM Doubler since the extra RAM is cheaper than the software.

some other items that I overlooked...

LONG IF srcresrefnum% <> 0

should be

LONG IF srcresrefnum% > 0 :REM (-1, -192, etc. are possible error codes)

You can skip _all_ of your CURRESFILE, USERESFILE stuff. The file is made current when it is opened and dropped to the previous top when it is closed.

There is no advantage at all to setting a specific USERESFILE with GETRESOURCE. GET1RESOURCE uses a specific file, all others use almost anything that is open.

Your sound call conversion stuff is not necessary. Use... "SOUND %resourceid%".

-STAZ ')'


I've had problems with RAM Doubler (or something else unknown) and the FB "SOUND" statement using sound resource numbers; I fell back on SOUND "soundName", where "soundName" is the name of the "snd " resource, and all the problems went away...

Bill


Is your snd resource purgeable? I don't know how RAM Doubler works, but I wouldn't be surprised if it likes to purge purgeable resources and/or shrink your heap (thus possibly initiating a purge), so that it can grab the extra memory.

If that's the case, I'm hypothesizing that your snd resource was purged and that's why it didn't play (It _seems_ like it ought to be still there, since you're dealing with it so soon after you open the res file--but who knows what evil lurks in the heart of Ram Doubler?) If a resource is purgeable, then having a valid (nonzero) handle for it is no guarantee that it's actually in memory. If you are using purgeable resources, then I'd recommend modifying your code like this:

snd& = FN GETRESOURCE (_"snd ",resourceid%)
LONG IF ((FN RESERROR = _noErr) AND (snd& <>0))
  CALL HNOPURGE(snd&) 'makes it temporarily unpurgeable.
  CALL LOADRESOURCE(snd&) 'reloads it--just in case
DEFSTR LONG

Rick