SE/II Emulator

By Larry Nedry, Contributing Editor

From: Skaros

Re: Emulate an SE or a II?

Well, now that the 68030 seems to be becoming the standard cpu for the Mac what happens to all the software written for the other machines(Plus,SE,II) that won’t run on a 68030 machine. Well, if you paid buck$ then chances are your software is being upgraded and you can always buy the next version that is MacIIx compatible etc. But, isn’t there someone out there who knows how to write an emulator that would run on a CX and let you use all your favorite software that so far only works on a II or SE, for example, Dark Castle, Arkanoid, or Continuum. If SoftPC can write an app that lets you have an IBM XT equivalent in a window, what do I have to do to write something that lets me use my old programs. What do I have to patch to make it work. After all, the 68030 is a 16 MHz machine; an 8 MHz emulator should be a cinch. Although I’ve written a few small apps for myself, I don’t know enough about the Mac to do this. I’ve a hunch it’s even underneath knowing the toolbox--busses,wait states, and a whole lot of other stuff that I have little experience with. Can anyone shed a little light on the matter?

From: Frankh

Re: Emulate an SE or a II?

A probable source of incompatibility is the screen. Many old Mac games wrote directly to the screen, bypassing the Toolbox. Other headache sources may be software timing loops, and code that depends on certain hardware features of the older machines. I guess that with some work, you could set aside some ram to simulate the screen buffer and then send it to a video card, or intercept all calls to what used to be the screen buffer address. You could make all these patches, and sho’nuff, you’ll end up with a fast B&W Mac 512 (or 128K!) clone running on a CX.

Or...you can call up the companies in question and ask them when they’re coming out with a version that works on the newer machines.

From: Skaros

Re: Emulate an SE or a II?

You’re probably right because when I make the SE30 the main screen the game, oids, doesn’t run, but when the Rasterops driven Apple monitor is the main screen it runs in a half baked way - only using the upper half of the screen for the game. I can only get oids to do this when I’ve booted from sys4.2 When I’ve booted from 6.03, the game is “smart” enough to tell me it can only run on a II or an SE. I wonder what screen specific changes exist between the two Systems?

From: Apage

Re: Emulate an SE or a II

Some applications use self modifying code in order to boost performance. When the II first came out with the 68020 it causes problems with the instruction cache. When the code was modified the modified instruction was already in the cache and so the modification that was expected to take place wasn’t there and thus many programs bombed. The 68030 also has a data cache, so the problems with self modifying programs now reach deeper. There is an assembly language instruction (MOVECR (move to control register)) in the 020/030 instruction set. Use this to turn off the caches and see if that gets your programs running.

From: Skaros

Re: Emulate an SE or a II

Well I tried turning off the cache with a great Init called cache control by J.Hamilton. It doesn’t work. BUT, I got it to work using system 4.2!! But when I run the program it only uses half a screen at a time and then runs using the upper half of the screen. Interestingly this is a 256 color game named oids and I’m using a rasterops card with an Apple color monitor hooked to an SE30. The program doesn’t run when I make the Mac the main screen. Probably has to do with the way the game addresses the screen buffer. But, why should it be smart enough to say it can’t run when I’ve booted with sys6.03 but it goes ahead and runs crazy when I’ve booted with sys 4.2?

From: Frankh

Re: CRC code

I’m looking for a fast CRC generator (in Pascal, preferably). I translated some C code, but it was not all that fast...Any code (C or assembly would be OK too) would be appreciated.

From: Larry Nedry

Re: CRC code

Don’t use a CRC generator. Use a lookup table. MUCH FASTER!

There is a very good book on serial communications called “C Programmers Guide to Serial Communications” by Joe Cambell. It has everything you’ve every wanted to know about CRC’s.

From: Infosyn

Re: OOP, Think Pascal

Is there anyone else out there writing OOP stuff with Think Pascal? Have you also run into the problem of a method not being in memory when you call it? Symantec says the manual warns that it’s up to the programmer to make sure the requisite segment has been loaded, so I’ve been loading ‘em all at launch time. But with 300K of CODE in 36 units in 12 segments, it hurts! Anybody figured out a better way?

From: Chenette

Re: OOP, Think Pascal

I’ve had trouble with dangling or missing handles causing the method not found error. Are you trying to dereference any nil handles?

From: Infosyn

Re: OOP, Think Pascal

I wish it were that easy. Unfortunately this is a serious design flaw in Think Pascal. Normally all globally referenced routines have addresses in the application’s jump table, so the Segment Manager “automatically” ensures that the respective segment is in memory before you call it. But with a method, there’s no such guarantee. And LSP does not have any internal way to keep track of which segment each method is in, so it’s currently entirely up to the programmer to make sure that the correct segments are in memory. (At least that’s the way Symantec describes it.)

But there are evidently other factors at work here, and I was hoping someone had discovered an easy work-around. For example, “sometimes” you can avoid the address error crash by moving the *declaration (not the definition) of the method to a different segment. This part is unclear to me (as you can tell.) Symantec is fully aware of the situation and is almost willing to say they are working on it, I guess. I was hoping someone else knew the straight scoop on this.

From: Siegel

Re: OOP, Think Pascal

The important thing to remember is that the object declaration must be in a segment which is loaded and which stays loaded. The best segment for this purpose is the main segment.

It’s OK to have object declarations in one file and method bodies in another; in fact, it’s much more flexible that way.

From: Siegel

Re: OOP, Think Pascal

By way of clearing up some confusion, let me explain:

The problem you describe is more a drawback of the object pascal architecture than it is a bug in THINK Pascal. In every program, ALL globally referenced routines do have entries in the jump table, but methods are a special case; they’re referenced by means of a class info proc, which is generated when a class of object is declared. In this sense, they’re not globally referenced, which explains why (for example) you can’t take the address of a method as a callback for a Toolbox routine.

The Class Info Proc needs to be in a segment which is initially loaded, and which stays in one place while those methods are used. The best way to ensure this is to have the class declarations in a file which is kept in the main segment, and have the class’s method bodies in another unit which can be placed in any segment; there’s no need for the method bodies themselves to be loaded, only the class declaration.

It is up to the programmer to ensure that the class declaration’s segment is in memory, and the simplest way to do so is to place the class declarations in the main segment, which is never unloaded and which is loaded at launch time.

Rich Siegel, Symantec.

From: Walrus

Re: REAL PROGRAMMERS materialFrom: Fling

Re: Getting APPL’s WDID

Does anybody know a fast, simple method of obtaining the application’s working directory ID. I need to open a companion help file, which should be located in the same directory as the launched application.

From: Mrteague

Re: Getting APPL’s WDID

It’s quite simple - do a GetVol call when you start the application - it will return you the volume name, and the volume refNum, which will be a WDRefNum when you are in a directory (which is set before the Launch trap when launching the application).

From: Siegel

Re: Getting APPL’s WDID

The cheapest way to do this is to open your associated file using a value of 0 as the “vRefNum”, since that specifies the default. The PMSP will then look in the same folder as the application, and if that fails, it’ll look in the system folder.

From: Mrteague

Re: Getting APPL’s WDID

I would add one warning to that method - if you do anything that changes the default directory (like maybe after a SFGetFile/SFPutFile call), then a vRefNum of 0 will give you the *current* default directory, which may *NOT* be the same one that the application originally started with, in case the distinction is important (like Config files etc).

From: Zweig

Re: Think C 4.0 DA Class

Does anyone know where I can find a desk accessory class for Think C 4.0. It looks like they want to support it since there’s an OOPS.A4 library, but I don’t see any clean way to override the menu bartender class or the swictchboard class to handle the DA events. If anyone knows someone who’s done it, please let me know. Thanks.

From: Siegel

Re: Think C 4.0 DA Class

The TCL was not intended for writing DA’s; Code Resources, drivers, and DA’s can be written using Object C, but you’ll pretty much have to roll your own classes.

From: Jumpcut

Re: TCL & List manager?

On the slim chance that somebody may have done my work for me, I was wondering if anyone has a class for a list window under TCL, i.e. a subclass of CDirector and/or CWindow that handles one-column lists. I don’t want to use CDocument, as there is no file connected with this list in any normal manner. Has anybody done this, and would like my eternal thanks and gratitude or do I have to dig in and learn this stuff? Does anyone, in fact, use the Think Class Library other than me? Are there organizations to help us rehabilitate?

From: Apage

Re: TCL & List manager?

I’m working on a subclass of CPane that might be able to help. It would enable you not only to specify objects in the list, and have them returned as objects upon selections, but by use of a superclass I’m defining with it you can alter the behavior of each list item by overriding some default methods. For instance, in the case of a directory in a list of files it would open as soon as you selected it, or appear in a different color to separate it from file entries. However, be advised that I am not looking to give this code away free.

From: Jumpcut

Re: TCL & List manager?

Thanks, but I got my CListPane working. Or nearly working. It creates a list, but it has problems resizing it (it only resizes properly about half the time). I just buckled down and really learned the darn class library. Now it feels great knowing how the thing works, but what really stinks is that I have dreams about it. THAT’s scary. What so you tell your friends? “All my dreams lately have been object-oriented.” They just think I’ve been cloistered with my Mac for too long now...

Another TCL thing: the printing methods work, but only when I set the partition to about 800K. Otherwise I get a “Mac OS error ID -108” which is out of memory. Any ideas? I would like this app to run on any Mac.

From: Jumpcut

Re: PICT resources in dialogs

I use pretty PICTs in my dialog boxes with no problems. I can’t remember if I had to send to the front or back, but I know that they are the highest number in the DITL (whether that’s front or back, I can’t remember.) All of the other items, buttons, editText, etc. are lower numbers. And it works fine for me.

Try making the PICT the highest number. Related note: Adobe Typeface Manager will intercept the drawing of your PICTs if they’re not just bitmaps, like if you created them in MacDraw, so it can really screw up whatever meticulous arrangement you may have spent hours working on in ResEdit. Some days it doesn’t pay to be a perfectionist.

From: Wesm

Re: Compiling MacApp & Error 405

I’m having a hard time with the Pascal compiler with MPW. I just purchased MacApp, and haven’t been able to successfully compile any of the sample programs. Invariably, the compiler aborts with error 405, “Error opening include file”. The file it chokes on is typically {PInterfaces}Types.p or Quickdraw.p. The shell variables seem to be set up correctly. Does anyone out there in MacAppLand know what’s going wrong?

From: Maniac

Re: Compiling MacApp & Error 405

I had a problem w/ MacApp that I solved by increasing the memory for MPW to 2meg. I made a copy of MPW first in another folder w/ the ‘essential’ files and then increased its size. That way, I can run the default or the big memory version as needed. --Mark

From: Dhands

Re: MacApp and Commands

I can’t subclass any of the commands defined in the file UMacApp.TApplication.p (i.e. TNewDocCommand). I get a compile time error that TNewDocCommand is undefined. The unit USES UMacApp and has no trouble finding other standard MacApp commands. How can I include in my unit the commands defined in UMacApp.TApplication.p?

From: Rastamon

Re: MacApp and Commands

The reason you can’t OVERRIDE commands such as TNewDocCommand, is that those objects are defined in the IMPLEMENTATION section of the code (ie.UMacApp.TApplication.p), rather than in the INTERFACE section (ie. UMacapp.p).

You really don’t need to OVERRIDE these commands, though. What you should *really* do is OVERRIDE the method(s) that gets called by the DoIt method of the command you are interested in. In the case of TNewDocCommand, you can just OVERRIDE TApplication.OpenNew.

From: Spud

Re: BigCursor?

Remember the BigCursor program -- the one that doubled the size of the cursor? Well, it doesn’t seem to work on the Mac II. Does anybody out there in ModemLand know why it wouldn’t work on newer machines (remember, it was released in 1984), and maybe offer a suggestion as to how I could update the program to work with new CPU’s and/or color cursors?

From: Spud

Re: BigCursor?

It doesn’t matter. It bombs in color and B&W. You might say it does not discriminate on the basis of color... Y’know, I even asked Apple’s Developer Tech Sport department, and even THEY didn’t know how to enlarge the cursor! It can’t be THAT hard of a hack, can it???