The past few weeks have been a bit quiet for us, as we’ve been both busy doing important work and personal life stuff, so we haven’t had as much time recently to spend on this project. We will continue progress soon when each of us gets more spare time, but meanwhile here’s a bit of entertainment for meanwhile:
As mentioned a few weeks ago, the audio output – which previously was not working in MS-BASIC – suddenly started working as Pukka fixed some 68k CPU bugs. At that time, I recorded a short video of the “Music” sample program running with audio included – and as there’s no other news to share at this time, we hope this “filler” video will keep you entertained for the time being!
Although we could make Indy launch already a while ago, for some reason we did not get any graphics to display. However, after Pukka fixed some more CPU bugs (including ror.l instruction), we suddenly got everything appear on the screen:
Interestingly, the game uses Sound Driver to play intro music, *but* after intro completes, it switches to Sound Manager. As we don’t have yet Sound Manager implementation, we added some empty stubs that just return error for the caller, and it seems Indy is happy with that as we can now proceed in the game all the way until getting stuck on quests 🙂
At this point we also noticed that we had accidentally handled the Style parameter of TextFace as 8-bit value instead of 16-bits as we should have, so the style calls had not been working until now that we fixed it. Indy uses these styles to adjust appearance of text on the UI buttons:
Here’s also a short video of the intro (with audio), and few first minutes of the gameplay:
One of our favourite games, Apache Strike, is now partially working. The game has a weird way of checking machine memory by writing/reading value beyond RAM space, which had just to be handled with special case to not raise a page mapping error from virtual memory system. The music (it’s using Sound Driver) is working OK, and main menu is shown properly:
However, some unresolved CPU bug seems to be causing the 3D rendering to fail, with only vertical lines appearing on the screen. Also controls don’t work yet, but it might be because we don’t yet completely support moving the mouse location by writing to low memory cursor globals from applications.
Here’s a short video with just the main menu and the music playing in background:
Pukka had been working long on the disassembler, and we were finally able to get first version of it integrated with the emulator. Below is a simple partial disassembly of Tetris audio mixer VBL, executed from Xcode debugger command prompt:
Although the disassembler itself still has some minor quirks to fix, there were some interesting bits we found about the Tetris mixer code in this disassembly:
Unlike Sound Driver, which has 4-channel mixer, Tetris uses a 6-channel mixer
The audio is downsampled from 22256 Hz to 11128 Hz by writing each sampled byte twice (the $7000(A6) at 00030C18 is supposed to be 2(A6) in disassembly)
The division of summed samples by 6 is done by pre-calculated lookup table (which has 6×256 = 1536 entries)
The pitch of channels is controlled by directly writing the fixed-point pitch into mixer code at addi.l instructions from 30BAA to 30BC8
With recent updates to Control Manager, and fixes to CPU emulation, we can now proceed in Tetris all the way to gameplay:
It’s not perfect yet, as clearing horizontal rows causes weird graphical corruption on screen – but it appears to be quite stable, music working and levels can be played through (although the graphical glitch makes it playing bit difficult). Here’s also a short video of the status of running Tetris in MACE at this point (with audio):
The past few weeks turned out rather interesting. After getting the basic Device Manager API written, we needed to have some simple test case to try it out – and as mentioned in the previous post, Sound Driver was an interesting potential use case. So that’s what we did…
The “Classic Mac” sound hardware
To get sound output abstracted in the emulator, we needed a bunch of stuff to support it, which includes:
Host platform abstraction for sound device: This allows us to create a SDL output buffer, and handle transfer to sound data from emulator to the host.
Hardware abstraction for sound: This separates “Classic Mac” type sound from future “Sound Manager” type generic audio output, and also ties the “Classic Mac” VIA to the audio output to control square wave generator, volume, alternative sound buffer, etc.
Vertical retrace simulation: More about this below
And also the Sound Driver DRVR
Vertical retrace interrupt simulation
One challenge in the old “Classic Mac” type computers is, that the sound output is deeply tied into the video signal generation, and especially the timings depend a lot on the frequency this generator works. In attempt to match this hardware as closely as possible, we added a secondary thread to simulate vertical retrace interrupts. As some might know, simulating hardware interrupts using threads is very tricky: On real hardware, interrupts are non-preemptive (except when allowed by the status register, as VBL interrupt handler does to keep Ticks low-mem variable in sync), but on multithreading system main thread could at any time pre-empt the interrupt thread.
To prevent this, we devised a locking scheme, which attempts to ensure that the interrupt service never gets cut off by main thread. At this moment it’s not a problem, as there is not yet actual 68K code running on main thread, but that we need to prepare for that in future, especially when VBL service routines written in 68K code might interrupt 68K code running on main thread!
In any way, the interrupt simulator currently reads the full sound buffer on each simulated VBL interrupt, and outputs the result through the hardware abstraction layer. The biggest challenge here at moment is keeping the SDL’s audio thread and VBL thread in sync, as the frequency of SDL sound output needs to match *exactly* the rate at which VBL thread is providing the sound data. It appears to be quite OK at the moment though, with occasional minor ticks here and there – currently the biggest source of breaks in audio appears to actually be the Xcode debug console, which seems to not be very thread-friendly…
Square-wave generator test
One neat feature of “Classic Mac” sound hardware is the built-in square-wave generator. Absent from later macs, this feature was very practical way of generating sound output without using almost any CPU resources. Controlled by the VIA, it was the first sound feature we implemented:
The Sound Driver
With sound hardware emulation in place, we could finally implement the Sound Driver. It took a day to decipher the old “.Sound” DRVR code, but after understanding how it works, we were able to whip up a C implementation which has equivalent functionality. In the process, we finalized an initial implementation for Vertical Retrace Manager.
After adding four-tone support, we needed a way to test this, so we wrote a test song by hard-coding it in C-language using set of frequencies as described in Inside Macintosh II-237 “Sound Driver” chapter, and used FTSynthRec to feed them to the virtual “.Sound” DRVR combined with a custom VBL task: