Photoshop 1.0 (and MacApp support)

The past week we’ve been busy working on optimizations on the 68k CPU and various improvements to the toolbox API. One of the improvements has been adding support for Apple’s MacApp MethodDispatch routine, which is used by Object Pascal and C+- (yes, that’s “C plus minus”, Apple’s proprietary C++ version which was briefly out before official C++ came to Mac). Basically, MethodDispatch is the virtual function table dispatcher commonly seen in C++ programs, but instead of being bundled in the application, it is actually implemented by the operating system as a toolbox trap – although with special calling convention, which cannot be called directly through A-line traps, but needs to be invoked through jump from 68k code. It handles selecting the correct implementation for class functions which can be inherited and overridden.

With the new MacApp method dispatching support, we should now be able to try running any MacApp-based applications – one cool such application, which is written in Objective-Pascal, is the first version of Adobe Photoshop:

About box and intro screen of Adobe Photoshop 1.0

Most of the dialog boxes appear to display (almost) correctly, although color picker, text input and popup menu support are missing so there’s little that can be done here:

Color separation preferences dialog in Photoshop

And just to test out how it works, we did a quick “Hello world” drawing using Photoshop drawing tools inside MACE:

“Hello world” from MACE!

Although implementing the method dispatching routine was fairly trivial, some time was taken by other features used by Photoshop, such as crude International Utilities/Script Manager support, PrGlue dispatcher for printing (or as in current case, telling application that printers are not available), proper Gestalt support, and various bug fixes even to some fairly low-level things as handling of empty regions in UnionRgn calls, rewriting the 80-bit “Extended” floating-point format conversion in SANE, etc… A few other test applications did benefit of those additions, but we’ll post more about them later!

Ps. In case you are interested how MacApp-based application code looks like, the original Object Pascal source code for the first Mac Photoshop was at some time ago published as open-source and is available on github: https://github.com/amix/photoshop

Microsoft BASIC first run

After spending a few days fixing bugs/issues, we can now successfully start up Microsoft BASIC 2.10, and run BASIC sample code applications with it. It looks a bunch of stuff is now working:

  • The BASIC sample apps seem to all be opening up and running the basic code is working fine in the BASIC interpreter.
  • Sample code listing, formatting and scrolling (by dragging text selection with mouse) appears to be working.
  • Trace and single-stepping seem to work ok using “Run” menu (and stopping using cmd+period).
  • The BASIC sample apps seem to be able to draw text and pictures, read files, and create menus, windows and dialogs.

There’s still a few issues to iron out though:

  • Only binary version of MS BASIC works, decimal version has some issues.
  • Standard File Package is still unfinished, so opening BASIC applications for testing is done temporarily using hard-coded SFReply records.
  • TextEdit input does not work yet properly, so for now we can only run existing sample apps. Interestingly, MS BASIC uses custom text input field which appears to do all the text drawing/selection itself without TextEdit, but depends on it for text input. This also prevents “Command” window from being much of use.
  • SOUND command does not appear to work yet, and there’s no visible signs of attempted calls to .Sound driver or sound hardware, so it needs further investigation. This may be related to sound missing from a few other test applications.

StretchBits (and font scaling)

An important feature which was implemented a few days ago is the StretchBits trap. It was actually implemented for the first “Stunt Copter” prototype, but as it’s effects are visible in many places, I felt proper to write a separate blog entry for it just to demonstrate a few cases where it had big impact on the content:

Railroad Tycoon map & minimap AFTER adding StretchBits
Railroad Tycoon map & minimap BEFORE adding StretchBits

Before implementing StretchBits, calls to it were directed as a placeholder to StdBits, which would show the content partially depending on the context, but causing graphic glitches as can be seen. On the Railroad Tycoon map, the “Map” uses both double-size scaling to draw the map, and half-size scaling for the mini-map on the right hand side. Also, the “New Train” screen uses stretching to scale locomotive PICT resources to fit the List Manager list it uses:

Railroad Tycoon “New Train” screen AFTER adding StretchBits
Railroad Tycoon “New Train” screen BEFORE adding StretchBits

Also the text rendering benefits of this, as text can now be scaled to arbitrary sizes, which is quite important when drawing bitmapped fonts in non-exact resolutions, such as in Missile:

Missile AFTER adding StretchBits/font scaling

Missile BEFORE adding StretchBits/font scaling

The scaling algorithm has some room for improvement, as it for now only has the generic method for scaling bits one pixel at a time. For now, this seems to be enough to allow working on other missing features.

Progress on Haiku port

With help of the new build system, we have now foundation to make porting to other host platforms easier. Currently, Pukka is working on Rasperry Pi port, while I today managed to get the emulator to compile and run on Haiku for the first time!

“Stunt Copter” running on Haiku, with console output on the terminal

With the support for multiple application-specific build targets, we could immediately get all the (currently functional) test apps to run. Below is screenshot of a few of them running at the same time:

Dark Castle, PT-109, Railroad Tycoon and Stunt Copter running on Haiku

The sound output took a bit tweaking to get to work, as for some reason Haiku’s SDL2 implementation did not handle unsigned 8-bit audio (native Mac format) so we had to briefly hack in support for converting it to signed 16-bit PCM on the fly. Sadly, modifier keys don’t work yet, and mouse input is broken, but emulation, file system, rendering and sound output appear to be working ok for now.

There’s however still much to do, and ports aren’t yet a priority, so these ports will probably see less action in the near future until we get all the other tasks done.

EDIT: Here’s a short video of first level of Prince of Persia running in MACE on Haiku:

Prince of Persia running in MACE on Haiku running in VirtualBox on Mac OS X

First prototype application!

Today, after working hard for whole week, we got the first public prototype preview application package available for trying out how M.A.C.E. works! For the prototype preview, we chose the public-domain game “Stunt Copter”, created by the late Duane Blehm. You can try it on the files section:

Please bear in mind, the project is still in early prototype phase, so there are still a number of things to improve, such as fullscreen/retina support and other features.

1 year anniversary of MACE! New build system and app bundles

Okay, after a few days of hard work, the CMake-based build system is finally starting to shape up. In the old setup, running apps would require altering the configuration headers and copying files manually, but with this new system, we can have JSON profiles for machines and applications, and batch-build any of them.

As coincidentally today marks the exact day this project was rebooted one year ago, it’s fitting to celebrate it with new milestone feature: Adding experimental Mac OS X “.app” bundle support, which takes everything configured to be part of an application, and creates a single, double-clickable app bundle for easy launching:

Stunt Copter running as an application bundle created with MACE

There’s still bunch of work to do before first public preview version, but it’s getting very close – hopefully by the end of this week. We plan to do this with the public-domain (free) game “Stunt Copter”, as it’s one which appears to be 99% complete for running in MACE.

A message you hopefully won’t be seeing too often…

Remote Debugging (et al)

Today Pukka added remote control interface to the 68k debugger. Earlier the debugger commands had to be entered in the Xcode console. From now on, any device with Telnet (with ANSI escape code support) can be used for debugging the emulated programs even from the other side of the world.

Stunt Copter debugged remotely

In other news, Pukka’s 68k debugger also can now be compiled and run on his Rasperry Pi using manually created makefile:

68k debugger test on Rasperry Pi 3 model B

Meanwhile, I rewrote the VBL interrupt handling code, so now it handles all edge cases and works reliably. Also, I started work on restructuring project for first demo build:

  • Started work on Haiku GCC compatibility
  • Enforced all warnings on (with “warnings as errors” option) – which already surfaced one region blitter bug that was causing graphic corruption in Pipe Dream and got fixed
  • Include SFTP server as source/destination storage in build process
  • Started investigating and experimenting CMake as a one potential build generation tool

Desk accessory support

Tonight I was feeling whimsical, so I decided to quickly add something fun to the emulator: Desk accessory support.

We already had full support for device drivers (DRVR resources) needed for the “.Sound” and “.NativeFS” virtual file system drivers, and as everybody knows, pre-System 7 type desk accessories are basically just drivers with some bells and whistles added to make them fit in the Mac’s toolbox & event system.

This required adding of a few routines used for DAs (and drivers):

  • OpenDeskAcc
  • SystemClick
  • SystemEvent
  • SystemTask

(supporting menus also will require SystemMenu, but we’ll get to it later – this is enough to get Calculator DA to work).

Desk accessories in the Apple menu

This also required tweaking the test code in AppendResMenu to add the actual driver resources, which surfaced a bug in resource manager code which was fixed.

The *real&actual* Calculator DA (borrowed for now from System 6) running in the 68K emulator

This allows us to now use real DAs coded in 68K in the emulator – to test this we borrowed Calculator DA from actual System 6, and it seems to work pretty good. You can check it out on this video (check out bonus at the end!):

Video of Calculator DA in action. Audio bonus at end of video 🙂

We also had to add a few missing SANE selectors (FADDX, FSUBX, FDEC2X, and FX2DEC), and through that got introduced to the interesting “Decimal” format, which appears to be binary version of the E-notation used in the Scientific notation of floating point numbers. Hopefully the quickly hacked FX2DEC implementation is accurate enough, at least Calculator seems to be happy with it so far…

(Ps. Yep, the WDEF 1 is still missing close box – it was added super quickly tonight so not 100% complete yet…)

Multi-line TETextBox

After spending the weekend working on a bunch of TextEdit routines, we finally have multi-line support in the static TETextBox, which is used in dialogs to display the static text items. Until now, we only had single-line display working, while multi-lines were displayed as blanks.

Multi-line static text items in Stunt Copter’s “About” box
Multi-line static text item in Lemmings’ copy protection dialog

Another nice benefit is, that as TESetText, TECalText, TEUpdate and related hooks were implemented for non-styled text, we are much closer to having actual text input fields also working properly – although there’s still a lot more work to get there.