Pinball Construction Set in Mini vMac

[FerazelX]

I have determined that the issue (or issues) lies in CODE resource 1.

I have also run MacsBug (which runs in Mini vMac!) on it as well.

Illegal Instruction at 001C36AE 'CODE 0001 03AE'+00956

1-Jan-12 6:40 PM (since boot = 39 seconds)

Current application is ÒPinballConstructionSet(E)-v2.5Ó., System $0710

ROM version $0075, $6000, $55AA (ROMBase $00400000)

VM is off

NIL^ = $00410000

Stack space used = +46; max used space = +424

Address 001C36AE is in the ÒPinballConstructionSet(E)-v2.5Ó heap at 001

It is 00000956 bytes into this heap block:

Start Length Tag Mstr Ptr Lock Prg Type ID File

¥ 001C2D58 00001500+00 R 001C1658 L P CODE 0001 03AE

68000 Registers

D0 = 00000020 A0 = 0031B104 USP = 00000000

D1 = 0000A9F4 A1 = 001C274B SSP = 00410000

D2 = 001C27B6 A2 = FFFFFFFF

D3 = FFFFFFFF A3 = FFFFFFFF

D4 = FFFFFFFF A4 = 001C24BE

D5 = FFFFFFFF A5 = 0031B0E4

D6 = FFFFFFFF A6 = 0031A44E PC = 001C36AE

D7 = 00000000 A7 = 0031A430 SR = SmxnZvc Int = 0

Disassembling from 001C36A2

'CODE 0001 03AE'

+0094A 001C36A2 ADDQ.W #$8,A7

+0094C 001C36A4 MOVEM.L -(A2),D0/D2/D3/D5/D6/A0/A5/A7

+00950 001C36A8 ASR.L D2,D1

+00952 001C36AA DC.W $E1FE ; ????

+00954 001C36AC BGT.S 'CODE 0001 03AE'+00982 ; 001C36DA

+00956 001C36AE *DC.W $7F26 ; ????

+00958 001C36B0 SMI (A1)+

+0095A 001C36B2 DC.W $9432 ; ????

+0095C 001C36B4 DC.W $1DCB ; ????

+0095E 001C36B6 DC.W $732D ; ????

+00960 001C36B8 _BitNot ; 00408334

+00962 001C36BA MOVE.W A2,-(A4)

+00964 001C36BC BVS.S 'CODE 0001 03AE'+009AC ; 001C3704

Heap zones

24 923K 00001400 to 000E808D SysZone^

24 0K 000014C4 to 000016B7

24 10K 000724D8 to 00074CD7

24 2551K 000E808E to 00365D2F

24 15K 001C155C to 001C515B ÒPinballConstructionSet(E)-v2.5Ó A

24 247K 0031BABC to 003599F7 ÒFinderÓ

24 30K 003279E4 to 0032F1E3

24 170K 0032F1EC to 003599EB

Checking all heaps

The System heap at 00001400 is ok

The heap at 000014C4 is ok

The heap at 000724D8 is ok

The heap at 000E808E is ok

The ÒPinballConstructionSet(E)-v2.5Ó heap at 001C155C is ok

The ÒFinderÓ heap at 0031BABC is ok

The heap at 003279E4 is ok

The heap at 0032F1EC is ok

Totaling the ÒPinballConstructionSet(E)-v2.5Ó heap at 001C155C

Total Blocks Total of Block Sizes

Free 0003 #3 00000DE0 #3552

Nonrelocatable 0001 #1 00000108 #264

Relocatable 0011 #17 00002CD8 #11480

Locked 0004 #4 00002104 #8452

Purgeable and not locked 0000 #0 00000000 #0

Heap size 0015 #21 00003BC0 #15296

The target heap is the System heap at 00001400

Totaling the System heap at 00001400

Total Blocks Total of Block Sizes

Free 0013 #19 00057126 #356646

Nonrelocatable 005D #93 0005BEA6 #376486

Relocatable 00E6 #230 00033C82 #212098

Locked 001F #31 0001F8FA #129274

Purgeable and not locked 0030 #48 0000BD90 #48528

Heap size 0156 #342 000E6C4E #945230

Displaying File Control Blocks

fRef File Vol Type Fl Fork LEof

0002 System Starter DiÉ zsys dW rsrc #997332

0060 Starter DiÉ ¥¥¥¥ dw data #73728

00BE Starter DiÉ ¥¥¥¥ dw data #73728

011C Finder Starter DiÉ FNDR dW rsrc #377469

017A Finder Preferences Starter DiÉ pref dW rsrc #360

01D8 Desktop DB Starter DiÉ BTFL dW data #26624

0236 Desktop DF Starter DiÉ DTFL dW data #228898

0294 Pinball CoÉ ¥¥¥¥ dw data #11264

02F2 Pinball CoÉ ¥¥¥¥ dw data #33792

0350 Desktop Pinball CoÉ FNDR dW rsrc #2131

03AE PinballConstructionSeÉ Pinball CoÉ APPL dW rsrc #149880

040C StdLog Starter DiÉ TEXT dW data #6532

#40 FCBs, #12 in use, #28 free

Displaying resource information:

> Map $001C1690, flags $0000, file $03AE = PinballConstructionSet(E)

S Map $00001498, flags $000D, file $0002 = System

Calling chain using A6 links

A6 Frame Caller

Return addresses on the stack

Stack Addr Frame Addr ISA Caller

0031A43E 68K 00066B2E 'scod BFAC 0002'+0005A

0031A43A 68K 00066B2A 'scod BFAC 0002'+00056

Closing log

 

[Cory5412]

Is this just a worklog or asking for help?

Unfortunately, I suspect that the real progress to be found would be in making mini vMac emulate the hardware in a more true way, instead of just emulating toolbox calls.

I don't know how complicated a Mac is compared to, say, the Super Nintendo, but if scales up proprortionally at all, getting this working could be a very interesting affair.

http://arstechnica.com/gaming/news/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator.ars

(Although I suspect that accurate Mac emulation may scale in a different way -- it has one or two more powerful processors, but it has fewer chips overall, I believe.)