Very Preliminary New Macintosh Emulator

About Mini vMac and all other 68k emulators, including SoftMac, Executor, and MESS.

Moderators: Cat_7, Ronald P. Regensburg

Post Reply
TomHarte
Student Driver
Posts: 10
Joined: Tue May 07, 2019 4:42 pm

Very Preliminary New Macintosh Emulator

Post by TomHarte »

Hi; quick announcement: my little emulator, Clock Signal, now provides an additional option for 68000-based Mac emulation. Not necessarily a great option, but an additional one.

Positives:
  • is a full hardware emulator, right down to the shift register in the IWM being a one-shot PLL observing drive flux transitions;
  • is a completely native Cocoa application, supporting arbitrary window sizing and placement, and indeed arbitrarily many simultaneous Macintoshes; and
  • it emulates some other machines too, which might be a positive.
Negatives (abridged):
  • it currently emulates the 512ke only;
  • ... with no hard disk support;
  • being a full hardware emulator, drive accesses occur at real drive speed, making it feel slow;
  • being an initial implementation, it also is slow generally;
  • you're presently on your own as to remembering properly to shut down your Macintosh before closing the window.
Timing also isn't quite yet 100% with the original Macintoshes as I've yet to implement DTACK delays due to shared video memory, DIVS completes too quickly, and I'm currently sampling the interrupt input immediately before execution of an opcode through lack of good information — though I think it should be whenever the 68000 feeds its prefetch queue? I need to do more work on that.

Being the author, I'm confident there are other negatives that I remain blind to.

Every line of code is new to this emulator, it's open source and MIT licensed. Naturally the plan is to improve things from here, so hopefully some of those negatives will evaporate over time. I definitely intend to fix the timing issues, and want to support a wider range of Macintoshes, at least.

All feedback warmly welcomed!
TomHarte
Student Driver
Posts: 10
Joined: Tue May 07, 2019 4:42 pm

Re: Very Preliminary New Macintosh Emulator

Post by TomHarte »

I thought I'd post some more details on this because while the world definitely doesn't need a new Macintosh emulator, some discussion of it may at least be entertaining for some.

So: the emulator seeks to be cycle accurate. That's not actually much of an advantage for an emulator of the Classic Macintosh — unless you really want to experience things at exactly the speed they were, it's a detriment — but there it is. So each and every 68000 bus cycle is individually announced and timed, which allows each and every action to be properly intersected with the other components on the bus. This is the part of what makes this emulator slow that isn't just my coding abilities: there's a whole extra level of meta-information about what the processor is doing flying around. Just like in real life, the 68000 can't just pluck a value out of memory, it can merely declare an address and a read operation, and assume that somebody out there observed the bus cycle and responded.

As implied in the first post, the various adjoined components are similarly cycle-oriented. Disks have a current position and actually have to spin to pass data to the IWM, the IWM maintains a shift register and applies the programmer-supplied windowing constraints to discern incoming bits, etc. Video is fetched only when it should be fetched. Accesses to the 6522 force VPA and therefore occur on the 68000's divide-by-ten E clock. Mouse input is achieved by pushing a quadrature signal to the SCC and the 6522, the former generating the proper DCD interrupts, etc.

It's even likely that when the IWM writes data, it'll be recorded on the disk surface at a slightly different density than that which I generate from a disk image file, which will then be observable for the remainder of the lifetime of that machine.

I guess the only other potentially-interesting snippets are the way that audio and video are handled. The emulator is oriented around a one-dimensional video feed from which it will discern syncs, etc, and act accordingly. Since syncs are programmable on the Macintosh that's not useful here, but the rest of the signal processing that lies below is helpful: the output to your screen is finite-impulse-response filter on the input. Hence the arbitrary window sizing. There is no native window size. Similarly, audio is sampled internally at almost 4Mhz and then window filtered down to whatever rate your machine can output (half the machine clock being the least common multiple of the scan line and the 6522 clocks). Any hypothetical real-time varying of modal settings to enhance audio range should work — though I've chickened out and pretended it's PCM audio rather than PWM given that I haven't yet found anything on the duty cycles involved. Also it strikes me the real machine may have either an implicit or explicit low-pass filter, which I'd need to know about to implement.

Those things all being said, I've still a long way to go before I have an implementation I'm happy with — one that hits all of the implementation details properly, and provides a sufficient user experience.

I appreciate that most of these implementation decisions are at best unnecessary and at worst counterproductive for a Macintosh emulator; having one that pretends I've arbitrarily many floppy drives, loads everything instantly and integrates with the native mouse cursor is more user friendly and therefore I've no misapprehensions when it comes to my limited potential audience.

That being said, I realise I forgot to mention one thing in my initial post: in addition to being a fully-native Cocoa application on the modern Mac, the emulator also has a separate SDL target that makes it useable in more traditional UNIX-type environments. It doesn't really have a UI there though, the intention that you file associate it with the appropriate disk image files, and launch the piece of Macintosh software you want by double-clicking the disk image. The emulator has a long-time dedication to seeking invisibility as I don't think anybody really wants to spend their time using an emulator, they just potentially want to use classic software.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Very Preliminary New Macintosh Emulator

Post by adespoton »

Thanks for your contribution! A cycle exact emulator definitely has its place here, as, if nothing else, it should allow us to debug issues in other emulators by comparing execution (and taking advantage of the excellent metadata passing you're doing).

Looking forward to seeing the progress of this emulator! I'd love to see full SCSI emulation added :)
TomHarte
Student Driver
Posts: 10
Joined: Tue May 07, 2019 4:42 pm

Re: Very Preliminary New Macintosh Emulator

Post by TomHarte »

Alas, I'm currently regressing rather than advancing: the immediate effort is back on the 400kb drives so that I can enable Macintosh 128k and 512k emulation. Specifically I think I'm still off on the correct interpretation of the drive-speed pulse-width modulation. But hopefully the penny will drop on that soon and I'll be able to start looking onwards to the Plus and SE.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Very Preliminary New Macintosh Emulator

Post by adespoton »

If you can get the 400kb working, shouldn't that also translate to being able to handle the HD20? I thought it used the same drive-speed pulse-width modulation with a driver (first an INIT, later in ROM for the Plus) that presented it the same way as the 400Kb drive.
TomHarte
Student Driver
Posts: 10
Joined: Tue May 07, 2019 4:42 pm

Re: Very Preliminary New Macintosh Emulator

Post by TomHarte »

I was considering the HD20 prior to or alongside SCSI, thanks to the fantastic work reverse-engineering it that Steve Chamberlin has carried out and documented over at Big Mess o' Wires. Having some sort of hard disk support would definitely aid me in testing, if nothing else.
TomHarte
Student Driver
Posts: 10
Joined: Tue May 07, 2019 4:42 pm

Re: Very Preliminary New Macintosh Emulator

Post by TomHarte »

Minor updates on this:

I have so far failed to find a working formula for PWM disk rotation speed, despite the fact that it should be easy in principle. I'm aware of different ways to fake it that would allow me to pretend I'm emulating a 128kb or 512kb Macintosh when I'm actually not emulating it, but that doesn't seem to be of any utility when I can just be honest about drive speed automation and emulate a 512ke.

Specifically, I believe there should be a direct linear relationship between what's in the PWM buffer — filtered over time — and drive speed. But I've been unable to find one that correct predicts the drive speed in all zones. There is a calibration routine in the ROM so I sort of wonder whether the numbers I have are so far off that I'm causing the Mac to act incorrectly in its calculations of proper PWM values from then on. But it could really just be any other latent issue.

If anybody just knows, authoritatively, the function hat should map from the contents of the PWM buffer to rotation speed, I could knock this thing out almost immediately.

In response to that failure I have set off in the other direction and been working on the Mac Plus and SCSI. That's going quite well. In the last day or so I've reached the point where I can format a disk image, copy over a System folder and finally leave floppy drive access speeds behind. There's still a lot of cleaning up to do, and barely-implemented parts that luckily do just enough but I'm confident that'll be the next thing to make it to a binary release.

As per the general tenor of the thing, my SCSI support involves emulating the 5380, a SCSI bus and a target on the other end of it, so it's much faster than the floppy but still limited by hardware bus speeds. I have however taken the view that since there's no defined speed for a SCSI device, I might as well implement a fast one. The SCSI bus speed is the only limiting factor. So that's around a quarter of a megabyte per second.

I also at least want to find a way to give the user the option of forcing the emulated Mac to skip its cold boot memory test. Then I think the thing will really start to be usable.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Very Preliminary New Macintosh Emulator

Post by adespoton »

I seem to recall that the cold boot memory test can be skipped by inserting a JMP in the appropriate location; we used to hack ROMs to use on the romulator that could do that, among other things.
Post Reply