Monthly Archives: February 2019

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:

https://mace.software/files

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.

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).

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.

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!

Civilization – first run

Today we finally got for the first time Civilization to launch successfully. The major issues that were fixed were the preservation of unaffected 68k registers during native toolbox calls (especially D0 which memory manager uses for returning the result code), and fixing a invalid character in ADF filename.

There were some improvements (implementing some missing traps) and bug fixes to Dialog and Control managers needed to pass through the new game setup dialogs. Also, TextEdit is not yet completely implemented (and has some issues such as losing first character as seen in certain names in next screenshots), but works enough to allow passing through dialogs requiring text input.

The game appears to be playable and stable, although there’s some minor issues, such as main window appearing initially too large, status window missing, no scrollbars yet, and various other minor quirks.

Map view/movement, units, construction, technology and combat all seem to work ok. We were able to play this particular game all the way until first autosave, which would have required Standard File Package which we haven’t yet implemented.

Some progress on Test Drive II: The Duel

After some work on adding missing SANE (Pack4/Pack5) routines, loading of Test Drive II: The Duel is working. Also, there were some (due) improvements needed to OpenWD, which now handles also adding partial/full pathnames to the calls.

The intro and menus appear to work with music

Sadly, the in-game has still issues that may be CPU emulation-related. The in-car interiour and basic scenery is drawn ok, but the road is missing and all “3D” sprites are literally all over the place.

In-game screenshot with missing road and wacky sprites

Another weird-looking screenshot, just before crashing the game

Also after for driving some time, the game crashes – still some work to do here.

In the other news, various parts of toolbox and 68k emulation have been improved. Window highlighting bug was finally fixed, growing/zooming of windows works now (with the widgets on window title bars also visible), and literally half of Continuum’s graphics issues were fixed in 68k cpu emulation, so it’s also almost working now.