68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
Yet another emulator - Granny Smith
Posted by: PappaDF on 2026-02-15 06:56:07
The world doesn't need yet another Macintosh emulator, but we all need a hobby, right? If anyone is interested, I've just released my small hobby project on GitHub - an embryo of a browser-first Macintosh emulator called "Granny Smith". You can try it out live here:

https://pappadf.github.io/gs-pages/latest

I strongly recommend using a Chromium-based browser for now - I've noticed some mouse movement issues in Safari.

It's extremely simple by design: the CPU instruction decoder is under 550 lines, and all opcode implementations total less than 1,000 lines. It's not at all cycle-accurate, just approximate, but accurate enough to pass the MacTest motherboard and floppy hardware tests without errors.

- Background checkpointing that stores state in IndexedDB, so you can reload the browser without losing your session
- Full checkpoint download/restore via drag-and-drop
- Mount compressed disk images (e.g., *.sit.hqx) directly through drag-and-drop
- Built-in AFP file server (work in progress) for accessing browser-side files from the emulated Mac

Just a prototype, so nothing is stable and well tested (yet). More details on the GitHub page: https://github.com/pappadf/granny-smith

Feedback and bug reports are of course very welcome!
Posted by: Chopsticks on 2026-03-28 17:59:18
I don't use any chrome based browsers myself, but i can confirm Firefox also has some mouse pointer issues, moving the the mouse pointer around seems to be 2-3 times slower on the emulation compared to my actual computer.
apart from that i was able to run system 6.0.7 fine. i only did some quick testing as i wasn't able to load any of my hdd images to do more.
Posted by: PappaDF on 2026-04-06 14:39:54
Thanks for the feedback! This is useful information! I haven’t tested with Firefox, but it’s obvious that I should.

There isn’t a good UI for setting/configuring HD images, yet. In theory, you should be able to just drag and drop, but this hasn’t been well tested. The only alternative at the moment is to do it from the terminal (attach-hd <path> [scsi-id]). I need to add a proper machine configuration panel or dialog. I’ve just merged SE/30 and 68030 support, so some kind of machine configuration interface is also needed to switch between models as well. I will fix that.
Posted by: PappaDF on 2026-04-10 17:46:51
Just added a new configuration dialogue - it's not perfect, but it makes it a bit easier to configure hdd images: https://pappadf.github.io/gs-pages/latest/ (still Chromium-based browsers only)
Posted by: luRaichu on 2026-04-10 19:42:14
Yet more claude slop once again!! Sad
Posted by: 3lectr1cPPC on 2026-04-10 21:40:05
Yet more claude slop once again!! Sad
Heaven forbid people work on hobby projects for fun.
Posted by: PappaDF on 2026-04-11 00:44:34
Yes, I've used Claude Code, Copilot, Gemini Code Assist, and Codex. This recently became my "playground" project for experimenting with them all. I debugged the MacTest application (hardware test suite) running on the Plus by hand- which took a very long time. I tried allowing Claude to use a "headless" app variant for bringing up MacTest on the SE/30 instead, and it was surprisingly efficient. So in the end, it is just a matter of efficiency.

I don't mind if you call it "slop". I have the utmost respect for people who refuse to touch Claude or Copilot- regardless of whether it's professionally or as in this case just for a hobby project. There is a certain beauty in 100% hand-made code that otherwise gets lost in the process.
Posted by: PappaDF on 2026-04-11 00:51:25
For full disclosure, I should probably add Mistral to the list as well. Mistral is surprisingly efficient at OCR-like tasks, i.e., converting PDFs and scanned reference manuals to Markdown in bulk. That has basically been the workflow recently - convert full reference manuals to cleaned-up Markdown, and let the agents work based on that.
Posted by: PappaDF on 2026-05-01 05:08:12
Installing A/UX from floppy/cd:
Posted by: PappaDF on 2026-08-27 15:53:38
Haven't posted any updates in this thread for months - my small emulator project has grown with a number of new models since end of April:
Current work-in-progress includes (any ideas for further development are of course welcome):
  • Apple Network Server 500 and 700 running AIX 4.1.5
  • Power Macintosh 9500MP running BeOS
  • Voodoo2 PCI Card
As stated on https://github.com/pappadf/granny-smith, it has all been designed to be AI-friendly, and AI tools have indeed been used throughout the work. (I know that this is a red flag for some people, and I fully respect that.)
Posted by: adespoton on 2026-09-15 16:13:44
Wait... you're putting ANS in the same emulator as 68k and PPC Macs?

That said, I've been looking for a proper ANS emulator; you can run AIX 4.x on PC-compatible hardware, but it's not quite the same as actual ANS hardware, and I don't have anywhere to store an ANS 😀

I'd love to see this as a sandbox in which to test out emulation of peripheral frameworks and external hardware -- I like that MAME and DingusPPC (and even QEMU) go the old school route and emulate from first principles via hand coding, but using Granny Smith as a way to figure out "this can work, and this is how" and then take that knowledge into hand-coded emulation to build out the supported hardware would be awesome 🙂

One thing I'd love to see via emulation is emulated printers where the emulator saves the output to PDF on the host, but on the guest system the "printer" can be interacted with via the built-in printer drivers. I'd also like to see things like scanners and phonenet emulated (from the host, open an image file, and then the scanning software on the guest "scans" that image using the same scanning software we used to use -- or you spin up a lab of emulated Mac Pluses and virtually connect them all over phonenet, make sure to terminate the network, and then it behaves just like the real thing)

It'd also be neat to be able to emulate a CD or DVD burner where the guest system thinks it's legitimate hardware, and you can write data out to an image file on the host 🙂 We could expand this out to virtual Zip drives and other esoteric storage media. Doing all this in a way that allows for mixing and matching between virtual and real hardware would be awesome; some sort of a glue layer that could handle old peripherals "plugged into" the emulator, or just emulating the hardware where desired.
Posted by: PappaDF on 2026-09-15 17:15:11
Wait... you're putting ANS in the same emulator as 68k and PPC Macs?

Yes, why not? 🙂

The ANS is almost just a variant of the TNT family, i.e. very close to normal PowerMac 8500/9500... I see every different OS/kernel I can get up and running (Mac OS, A/UX, AIX, now the latest Windows NT) as yet another opportunity to get test coverage... Almost every new OS kernel trigger some new issue...

It's up and running with AIX: https://youtu.be/_4h7tP0lUMk

I've also been able to both install and boot Windows NT for PowerPC on that model (there's a thread on tinkerdifferent)

I'd love to see this as a sandbox in which to test out emulation of peripheral frameworks and external hardware -- I like that MAME and DingusPPC (and even QEMU) go the old school route and emulate from first principles via hand coding, but using Granny Smith as a way to figure out "this can work, and this is how" and then take that knowledge into hand-coded emulation to build out the supported hardware would be awesome 🙂

I'm all for it! If anything in here can be of value for any other emulator - use it as a prototype! That is why the license is very permissive (MIT).

In addition to peripherals, I would like to think that CPU test vectors (https://github.com/pappadf/m68k-test, https://github.com/pappadf/powerpc-test) could be of immediate value to other emulator projects.

A third thing that other emulators could leverage are perf numbers for interpreter design (https://github.com/pappadf/emu-core-bench)

One thing I'd love to see via emulation is emulated printers where the emulator saves the output to PDF on the host, but on the guest system the "printer" can be interacted with via the built-in printer drivers.

I have something cooking in that area... But I went all in and made it more complicated (than perhaps necessary), so it has taken more time than I expected...
Posted by: joevt on 2026-09-15 17:31:40
Wait... you're putting ANS in the same emulator as 68k and PPC Macs?
ANS is basically Power Mac 9500 hardware with some included PCI devices. DingusPPC can boot PowerSurge machines. My fork of DingusPPC has some ANS stuff and can enter Open Firmware for all 5 known ANS ROMs. I haven't booted anything with it yet. It doesn't have the graphics controller emulated yet (should be easy) but you can use a different PCI graphics controller. It doesn't emulate the fast/wide SCSI controllers (less easy) but you can use the external SCSI controller.

One thing I'd love to see via emulation is emulated printers where the emulator saves the output to PDF on the host, but on the guest system the "printer" can be interacted with via the built-in printer drivers.
I think I recall these being implemented somewhere. At least an ImageWrite II (for Apple II emulators usually). For Macs, there's PrintToPDF in Mac OS 9. Mac OS X has a built-in Print to PDF option. But it would be nice to emulate the actual printers.

I'd also like to see things like scanners and phonenet emulated (from the host, open an image file, and then the scanning software on the guest "scans" that image using the same scanning software we used to use
Being able to add emulated SCSI devices such as a scanner would be interesting. Usually only hard drives or CD-ROM drives are emulated. InfiniteMac has BlueSCSI emulation for some of the emulators. This allows using the BlueSCSI software to transfer files for example.

or you spin up a lab of emulated Mac Pluses and virtually connect them all over phonenet, make sure to terminate the network, and then it behaves just like the real thing)
I think it's relative easy to connect two emulators via an emulated serial port. LocalTalk uses some complicated features of the SCC though. Connecting multiple emulators via their emulated serial ports is a different kind of problem on top of that (they all have to see each other's bus traffic - some kind of broadcasting method needs to be implemented). For SCSI or LocalTalk network, termination is not a concern since the physical/analog nature of communications is usually never emulated.

It'd also be neat to be able to emulate a CD or DVD burner where the guest system thinks it's legitimate hardware, and you can write data out to an image file on the host 🙂 We could expand this out to virtual Zip drives and other esoteric storage media. Doing all this in a way that allows for mixing and matching between virtual and real hardware would be awesome; some sort of a glue layer that could handle old peripherals "plugged into" the emulator, or just emulating the hardware where desired.
Virtual machines do this for USB. You connect a real USB device and tell the host to connect to it as a guest. It might be possible to do this for SCSI and FireWire devices? This works by passing the commands from the guest to the host device. Passing ADB might also be possible using a USB device that exposes an ADB bus - such as the Griffin iMate (Mac OS X driver source code is available).

Some virtual machines can pass an entire PCI device. This is more difficult because you need to involve an IOMMU to support DMA for bus mastering devices. If you're not dealing with DMA, then a normal PCI device driver to capture the device is sufficient. For example, a graphics controller connected to the host could work in the guest Open Firmware environment where DMA for 2D/3D acceleration usually does not get used.

Other interesting stuff to emulate:
- The ANS LCD screen (DingusPPC just writes the text to the console)
- flashable ROM - Every New World Mac has flashable ROM. For Old World Macs, a flashable ROM SIMM can be installed. I implemented flushable ROM in DingusPPC for PowerSurge machines to see how the Apple flash utility works.
- Video input - The Power Mac 7500/8600/8600 has video input. I have source code for the planb video input component for Mac OS 9 and Mac OS X. Granny Smith already has video input for the Quadra 840AV and 660AV. It might be interesting to be able to pipe video from the host file system or a video capture device or YouTube.
Posted by: PappaDF on 2026-09-18 17:15:37
Yes, why not? 🙂

The ANS is almost just a variant of the TNT family, i.e. very close to normal PowerMac 8500/9500... I see every different OS/kernel I can get up and running (Mac OS, A/UX, AIX, now the latest Windows NT) as yet another opportunity to get test coverage... Almost every new OS kernel trigger some new issue...

It's up and running with AIX: https://youtu.be/_4h7tP0lUMk

I've also been able to both install and boot Windows NT for PowerPC on that model (there's a thread on tinkerdifferent)

Here is a small example:

https://youtu.be/E61rIaY2BjY
Posted by: impressionist on 2026-09-25 08:41:44
Pretty interesting for a lot of reasons. If the combination of the emulator implementation, SAIL specs, etc can all be sufficiently validated this could be very helpful for facilitating FPGA or lower reimplementation of those parts. How are you doing the Rage 128 emulation? I've been curious about the Rage II, Pro, and 128 generations (roughly early G3 era) for a while but last I looked there wasn't much documentation available.
Posted by: Arbee on 2026-09-25 09:17:06
There's very good documentation on the 2D portion of the Rage, which is how the Dingus guys and I both pulled that much of it off. The actual polygon info is redacted in the documents I've seen though, so I'd be curious to know about that too.

The SAIL specs seem solid, I just used them to validate MAME's in-progress DSP3210 and it runs the Quadra AV stuff fine after passing.
Posted by: impressionist on 2026-09-25 10:32:42
I see, yes. I hope to see 3D as part emulating the early iMac experience. I suspect it's doable if one had a real PCI card and could log bus traffic between that and an emulator with the OEM drivers running various workloads. I've also wondered about building new upgrade silicon kind of like an AV Quadra on a chip (CPU + DSP + DMA all in one)....
Posted by: Andrew-R on 2026-09-25 18:38:01
There is bunch of AI-assisted repos with r128 stuff now ...


those two I tested with OSX 10.4.11 and GLView 3.37 (on x86-64 macos and Linux)

github.com

GitHub - lyons88/qemu-mac99-smp

Contribute to lyons88/qemu-mac99-smp development by creating an account on GitHub.
github.com github.com


github.com

GitHub - makuhlmann/qemu-system-ia64: A QEMU-based experimental IA-64 full system emulator

A QEMU-based experimental IA-64 full system emulator - makuhlmann/qemu-system-ia64
github.com github.com
github.com

GitHub - syunnPC/qemu-system-ia64: A QEMU-based experimental IA-64 full system emulator

A QEMU-based experimental IA-64 full system emulator - syunnPC/qemu-system-ia64
github.com github.com

This one worked on most usual Little-endian host (x86, aarch64) but not on big-endian host 🙂


github.com

GitHub - frostbite-forks/Bochs: Bochs - Cross Platform x86 Emulator Project

Bochs - Cross Platform x86 Emulator Project. Contribute to frostbite-forks/Bochs development by creating an account on GitHub.
github.com github.com
Posted by: PappaDF on 2026-09-25 18:59:14
Pretty interesting for a lot of reasons. If the combination of the emulator implementation, SAIL specs, etc can all be sufficiently validated this could be very helpful for facilitating FPGA or lower reimplementation of those parts. How are you doing the Rage 128 emulation? I've been curious about the Rage II, Pro, and 128 generations (roughly early G3 era) for a while but last I looked there wasn't much documentation available.

Most manuals can be found online now. Regarding Rage 128, the key ones that I've looked at are:

RAGE™ 128 VR / RAGE™ 128 GL Register Reference ManualRRG-G04100-C Rev 0.021999
RAGE™ 128 Register Reference GuideRRG-G04100-C Rev 0.011998
RAGE™ 128 Software Development GuideSDK-G04000 Rev 0.011999
RAGE™ 128 PRO Register Reference GuideRRG-G04500-C Rev 1.011999 (© 1999, rev. 2000)
RAGE™ 128 VR and 128 GL Graphics Controller SpecificationsGCS-C04100 Rev 0.051998

...you can find all of them with google/similar. I typically transcribe them to markdown first, so that tables etc. becomes easier to search.

(My Rage 128 model is still work in progress.)
Posted by: impressionist on 2026-09-26 19:44:13
Oh interesting. I'm surprised that's enough to reproduce the hardware's behavior, I would think it would require PCI traffic logs and corresponding framebuffer images, although the documentation would give a much clearer idea of coverage. In any case cool to see movement.
1 >