• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Best emulator for vintage 68k development

Sort of … the linked webpage lets you customize a version and have a script on the website build it for you, then you can just download the custom build. You don’t actually need to compile it locally. It’s super easy and great.
 
Sort of … the linked webpage lets you customize a version and have a script on the website build it for you, then you can just download the custom build. You don’t actually need to compile it locally. It’s super easy and great.
This is what I did for an old program that I am trying to resurrect. The development host I needed was a very specific Mac II and I just used this service - as Crutch said, very easy and works great.
 
So I was thinking about this all of last night and got intrigued about making a custom Mini vMac for testing purposes. One of the features of DOSBox that I like is the ability to slow it down to a ridiculous speed so you can see where your code is running slow, especially with graphics routines. I'd love to be able to run vMac at 0.5x speed or even slower so that I can watch my screen draw routines and see where they are least efficient. I looked through the Options list and seems you can set the default run speed to one of the options (1x to 32x or all out) but can't set a custom speed to less than 1x. Setting it to something outside of those options I assume would require modification to the source and compiling it yourself, unless I'm missing something here?
 
This is exactly, precisely what I want to do. I am coding up an arcade-type game and I want to push the limits of the frame rate on the slowest Macs by finding out where to optimize. Using a profiler would be 100x more work than just visually seeing the slowness.
 
In theory, it should be possible to do exactly that. I downloaded the source code, but it's massive, and I'm not familiar with how it is organized, so it would be quite time consuming to find the correct section of code to edit. If I have some time this weekend, I might start looking through the source files to see if I can find the section that relates to speed. Unless someone here is familiar with the source for vMac, I think it will be quite an endeavour, and not sure if it will be worth the time for the payoff.
 
You wouldn't be able to do this by adapting the existing speed code. The emulation runs per tick, and to speed it up it adds 'extra' ticks between the 'real' ones. And the 'real' ones are pinned to real time. Instead, to slow it down, you'd need to reduce the number of 68k cycles per tick, which is defined by CyclesScaledPerTick in PROGMAIN.C. That said, though, I think you'd be taking Mini vMac out of what it was designed to model to run it with this set really slowly, and I'm not sure how accurate the results would be to actual hardware.
 
Well, it could plausibly run at the equivalent of 5 MHz, since there's a precedent: the Mac XL, aka Lisa 2.

That said, of all the emulator options, Mini vMac is probably the closest to the real hardware as any of them, and since, for all intents and purposes, the Mac XL behaved – from a software perspective, at least – basically like a slow Mac Plus with a big (for its time) display, it seems that running Mini vMac somewhat slower than 1x and giving it a slightly bigger display size would create a similar result.

Make any sense?

c
 
Display imaging on a modern machine is so fast I don’t see how it would notably slow down the emulator at all, if that’s what you’re suggesting.

Anyway despite my comment above I am personally fine with the level of speed control offered by Mini vMac. My problem is that it doesn’t allow > 8 MB RAM. (And Basilisk doesn’t support Macsbug or allow for speed control.)
 
Back
Top