Category Archives: Productivity

HyperCard 1.0.1 works now (kind of)

As mentioned in the previous post about file system write support, one major motivation for experimenting with it this point was the interest about getting HyperCard to work on MACE. So, after we added it a few days ago, and after fixing a few bugs, we already got quite a few default stacks (included with HyperCard) to at least open up and display something! Below is a HyperCard screenshot extravaganza what we can do right now (click on pictures to see full size!!!):

As you can see, there’s a lot of stuff appearing correctly, but also a lot of things still broken and needing work. Cool stuff that works:

  • Most of cards open up and actually do sensible stuff
  • Most of drawing tools work (see the mess we made in the Home card!). I think they also share a lot of code with MacPaint tools, as some have same toolbox bugs present in both MacPaint and HyperCard

Stuff that needs a lot of work still:

  • Corrupted texts appearing here and there around places (such as between months in calendar & weird mess in some lists)
  • Bunch of error messages popping up here and there
  • Font setup dialog is not displaying font names correctly as using some still unimplemented selectors at least in List Manager
  • Cannot get back to Home stack, which apparently does not close correctly and cannot be reopened without restarting entire HyperCard application
  • HyperCalc stack does not appear to work well at all, all fields are empty and the “help” popup does not appear
  • File system writing needs improvements, especially to add the Standard File package so we wouldn’t anymore have to use the hard-coded filenames
  • TextEdit support is not yet complete, so most of text input does not yet work (with the exception of text drawing tool, which like MacPaint does not use TextEdit)
  • A bunch of other misc bugs here and there

Anyway the current status looks quite promising, and as eventually bugs will get hunted down & features added, the state of this application should improve over time.

File system write support (and MacPaint kind of works)

This week we reached a major milestone! From the encouragement on the work on HyperCard on 68KMLA forums, we got inspired to attempt tackling one major obstacle that was preventing it from working – file system write support!

As we mentioned earlier last year, when we last fall added the file system API, we did so using abstraction on top of AppleDouble file format. As Mac file system has the special dual nature of being split to data and resource forks, the AppleDouble format helps managing this in the emulated file system. Data fork, as mentioned earlier, is saved directly in its own file, while resource fork is merged with other file metadata in the AppleDouble header file. With this distinction, adding support for writing to data forks was really just trivial mapping of file manager write calls to the data file. Resource fork writing is a bit tricky, but we currently force the AppleDouble headers to keep resource fork as last element in the file, which allows us to offset also write operations from the beginning of resource data, and allows us to expand/shrink file easily, as end of resource fork is the actual end of header file. (One side note, setting EOF of files doesn’t have a standard C file operation, so we’re for now using the POSIX extension “ftruncate” which works at least on Mac OS X, but may lead to portability issues.)

Currently there’s very limited set of features for writing to file system implemented, basically just “Create” and “Write” file manager calls. For example, resource manipulation does not yet work as it will require a number of routines added to the Resource Manager to support it. However, one test application that directly benefited from this new feature was our beloved MacPaint, as it requires two scratch files to be present on startup volume/folder to function. This was nice, as it allowed us to add a few other missing features, such as PackBits (which also benefitted other apps and picture recording).

Hello from MacPaint!

Although all tools don’t yet work perfectly, most of basic drawing functions are solid enough to not only allow drawing, but the experimental file writing also allows saving of MacPaint files, which appear to be readable by the Preview application in development host system Mac OS X 10.12!

FatBits and some test pixels drawn (including ‘hello’ done with the MacPaint text tool)

Additionally, many other applications have seen improvements from this, as now we can save Civilization games and continue playing them! (Although Standard File package is still using hard-coded SFReply records).

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:

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.

Old-style FONTs (and Harrier Strike Mission II)

Today we tried running Harrier Strike Mission II for the first time. The game appears stable, but runs way too fast, and the 3D drawing has some minor glitches causing some polygons to go to wrong place.

However, the most interesting part of this game was how it’s drawing its user interface. On the first run, this is the weirdness that we got:

Main menu, before old-style FONT support
In-game UI, before old-style FONT support

As you can see, there was a lot of text all over the place, as we didn’t have yet old-style FONT loading in place (up to this point only FOND & FONT/NFNT combination, which most of previously tested apps/games used). So, after implementing some “TODO” parts in our Font Manager implementation, we ended up with this:

Main menu after implementing old-style “FONT” loading support
In-game view after implementing old-style “FONT” loading support

It’s rather interesting to see fonts used in such way. As a nice bonus of this, we also got the tool palette icons to appear in MacPaint, which are also implemented as a custom old-style FONT:

The tool palette of MacPaint is now visible too!

MacDraw & basic shapes

After some effort, we now have basic shape drawing working in MacDraw. One fun part of this was implementing FixDiv, which uses the binary long division algorithm like the original one on Mac. MacDraw uses this routine excessively to handle document grid sizing and coordination of all shapes drawn on the canvas.

“Hello” from the MACE team (with MacDraw’s custom MDEFs usable). No scrollbars visible yet though, have to get on finishing the CDEF 1 soon…

There was also a minor bug in MenuSelect causing zero item selections in MacDraw’s custom menus, but after a quick fix we can now also use them.

Contrary to many other applications, MacDraw uses a different approach to implementing custom menus – instead of providing a MDEF and assigning it to the menu using the menu definition proc ID in resource, it has its MDEF code as part of the program, and creates a fake handle which it assigns to the menu manually. Because of this, we had to tweak the memory manager handle operations to silently fail on such handles, and instead return the proper memAZErr (-113) in D0/MemErr.

Still no text drawing though, and there’s minor tweaking required for line drawing, but it’s looking promising at the moment.

The “About” box of MacDraw