Here is a more official build of the Sad Mac screen saver that I wrote last year. It is now properly code-signed and should install and run without any permission issues on macOS 10.12 and newer - Download SadMac.saver.zip

Puzzle

The Sliding Puzzle from After Dark was probably my favorite back in
the day. It just worked so well and smooth. And I think I specially
loved the ones that messed with your actual screen.

My re-implementation simply chops up a screenshot and then turns the
pieces into SpriteKit nodes. Those can then easily be moved
around. SpriteKit is pretty amazing. I have found it very simple to
turn ideas into working prototypes.

Mozilla

This one shows the new Mozilla logo and drops two sizes of Firefox
(Focus/Nightly) icons on it. There is lots of bouncing and I spin the
logo around if too many pile up.

Since the logo is not a simple rectangular bounding box, I had to
create an outline for the collission detection. I used a nice little
web based tool that let me draw the path on top of the image and
generated Objective-C code that.

Building on top of the Lua integration
work that I landed recently
in EWM, my Apple ][+ emulator, here
are two small improvements and a fun use case to show those off.

New Lua Callbacks

First, I have added two callbacks that let you intercept key
presses. Not emulated presses, but EWM application key downs and
ups. This means that you can now trigger scripts by connecting them to
a key combination.

For example, say you want to dump the Zero Page when you hit
Command-Z. That is now easy with just a few lines of code:

two:onKeyDown(function(two, mod, sym)
if mod == KMOD_GUI then -- Command on macOS and Meta on Linux
if sym == string.byte('z') then
ewm:hexdump(0x0000, 0xff) -- Dump the zero page
return true
end
end
end)

(The KMOD_GUI constant comes from SDL. I
hope to have some abstraction for that at some point.)

Second, it is now possible to inspect and modify memory. The cpu
global now has a memory property that you can index as an array:

What we are looking for is the value 05 for the number of lives or
the number of pepper shots we have left. There are multiple
occurences, so what we do is run into an enemy and see if the value
changes somewhere:

Easily spotted, the value at 0x66 changed from 0x05 to 0x04.

...
0060: 73 96 00 00 3f 96 04 05 00 00 05 05 00 00 07 00
... ^^

And if we get caught once more, by Mr. Pickle, and then use four
pepper shots, the values at 0x66 and 0x6a look like this:

...
0060: 73 96 00 00 3f 96 03 05 00 00 01 05 00 00 07 00
... ^^ ^^

I think we can safely say that we have found the following memory
locations:

CUR_LIVES = 0x66
MAX_LIVES = 0x67
CUR_SHOTS = 0x6a
MAX_SHOTS = 0x6b

How do we change them? Simple, we can define another key combo that
simply resets the memory locations to a bigger number:

Now every time you press Command-R, your lives and pepper shots are
set to 7.

We can take this one step further and simply make sure that the
CUR_LIVES and CUR_SHOTS never changes at all.

There are only a few instructions to store a value in the Zero Page,
so with a little bit of trial and error it is pretty easy to find out
that the values are set with an STA $66,X and STA $6A,X
instructions.

We can intercept those instructons by setting up a callback with
onBeforeExecuteInstruction and then in the callback we make sure
that the value is always 0x05:

After an almost eight month interruption by mostly work and life in
general, I am finally, and happily, back here writing about something
new I added to EWM, my Apple II+
emulator.

I always thought it would be interesting to integrate a scripting
language in the emulator, so that you can write little (or big) hacks
to modify the behaviour of not just the emulator but also the software
it runs.

For this release I have only implemented instruction interception;
this means you can run a Lua function before or after a specific
6502/65C02 instruction is executed.

That is not super exciting but it does open the door to some cool and
simple hacks that were previously only possible by patching software
the hard way. Now you can run a script on top of the original software
without having to make persistent modifications.

In later releases I am also going to make it possible to intercept
reads and writes to memory, interact with EWM, and maybe even more
specific things like callbacks for things that happen in the disk
controller.

Here is a small example function that uses the
onAfterExecuteInstruction callback to change the keybindings for
Frogger.

Here is an overview of some small improvements I made this week. It
has been hard to find quality time to work on this project so I am not
going as fast as during the Christmas break.

Blink that cursor

The Apple 1 emulation in EWM now blinks the cursor. I did not know
that it blinked until I saw some videos on YouTube.

I probably got the frequency wrong.

Control keys

In the Apple ][+ emulation, I now properly support Control-A to Control-Z. I tested this with the Apple II+ Dealer Diagnostics disk, which has a keyboard hardware test program. There is no date on it, but it is probably 1978 or so.

Disk images in .nib format

EWM can now load disk images in the .nib format. This is a format
that does not just contain a dump of the track and sector
data. Instead it has the raw encoded disk contents. It turned out that
is the exact same internal format that EWM uses for the disk emulation
code, so this was a pretty simple thing to do.

If you are interested in playing around with my emulator, you can find
the project at github.com/st3fan/ewm.

It has been difficult to find the time to hack on EWM since I went
back to work. Busy busy. But I did manage to make some small
improvements to better support the Raspberry Pi Zero.

The Raspberry Pi Zero
is a tiny single board computer with a 1 GHz single-core ARMv6 CPU,
512MB RAM and HDMI and USB connections. They are cheap, around $7
CAD plus shipping, and are capable of running Linux.

Sounds ideal for an emulator. But how fast are they?

To find out, I modified the cpu_test program included with EWM to
output the raw CPU speed:

So about 10x the speed of an Apple ][+. Not bad, considering I have
spent zero time optimizing the CPU emulation so far. And it is all
written in simple portable C without crazy tricks.

Graphics is more interesting. The Pi Zero has no hardware
accelerated graphics, at least not supported in Linux, so I have been
working on a pure software renderer for text, lores and hires
screen. It does not depend on OpenGL and just blits pixels to screen
buffers.

This is what the performance looks like when I run the scr_test
program:

(Green is monochrome mode, and it is slower for text because the way
I let SDL change the color of the default white text
characters. Probably easy to fix.)

The default scheduler in EWM is set to 30 FPS, which means one
timeslot in the ‘scheduler’ is 33 milliseconds.

Of those we will need about 5 milliseconds for executing enough CPU
instructions and another 5 for random stuff that happens in the event
loop.

That leaves just about enough time for a full screen refresh. But it
is a bit tight and I’ll be working on getting those numbers down. It
will be better if all modes render in at most 20 milliseconds or so.