Mini vMac Updates: September 18

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

Moderators: Cat_7, Ronald P. Regensburg

Post Reply
User avatar
ClockWise
Site Admin
Posts: 4076
Joined: Mon May 20, 2002 4:37 am
Location: Uiwang
Contact:

Mini vMac Updates: September 18

Post by ClockWise »

Mini vMac development continues apace!

"The latest Mini vMac Development source snapshot improves instruction fetching. A badly behaved program can cause Mini vMac to crash, attempting to fetch an emulated instruction from random memory, which memory protection on a modern computer prevents. Since this is only a bad read, I don’t think any further harm is possible besides crashing Mini vMac. Most kinds of memory access emulated by Mini vMac have for a quite while have been designed to always be accurate and safe. But for speed, fetching the next instruction would simply increment a pointer to where the instruction is in real memory, and relative branches would just offset this pointer. Only for certain long branches would Mini vMac work out from scratch where the instruction is in real memory. This is good enough for all known correctly working software. But it is in theory possible to write code so that the pointer to the next instruction gets set to arbitrary memory that the operating system may not allow Mini vMac to access, resulting in a crash. And not just in theory, I have seen this happen in programs running in Mini vMac that were malfunctioning.

This bug is fixed by keeping low and high limits for the instruction pointer, and checking against them as the pointer is changed. When fetching the next instruction, it only needs to check against the high limit. And the increment and check is done after the current instruction is fetched, and so it could be done in parallel with other things. A modern computer can do several things at once as long as they don’t interfere with each other. So it shouldn’t affect speed too much.

Actually, at first it slowed things down a lot. But then I figured out it was because the compiler I use for development messed up with the C inline directive. I figured out how to get the compiler to inline if and only if I tell it to, which gained back all speed lost, and a little bit more. So now the build system defined macros MayNotInline or MayInline are used for every function in Mini vMac.

The ability to turn off USE_POINTER and FastRelativeJump for greater accuracy is removed from the source code, since they are now always accurate and safe.

These changes have only been made in the C implementation of CPU emulation so far. The PowerPC and x86 assembly languages versions are to be fixed next.

The same thing has been done to the assembly language source as previously was done API, sound, and language sources. They have been given unique names and moved to the main source folder. (Which has been renamed from “c_src” to “src” since it is no longer just C.) Also, instead of the build system transforming the PowerPC code for MPW, there are two PowerPC versions, and some scripts (in the new file “trans”) to help keep them in sync. The idea being moved to is that the build system only generates configuration files, and the source folder is the source, basically the same in the source archive and when being compiled.

The motivation for working on the CPU emulation is that I would like to make assembly language versions for ARM and X86-64, but there are issues, such as today’s safe instruction fetching, that would be a lot easier to deal with first, before there are more versions to keep in sysnc."

Source:

http://www.gryphel.com/index.html#news
User avatar
adespoton
Forum All-Star
Posts: 3235
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Mini vMac Updates: September 18

Post by adespoton »

Wow! That's a LOT of work he's done, and will make all porting work significantly easier.
User avatar
ClockWise
Site Admin
Posts: 4076
Joined: Mon May 20, 2002 4:37 am
Location: Uiwang
Contact:

Re: Mini vMac Updates: September 18

Post by ClockWise »

I wish I had some time to check it all out. Just a couple more months.

I'll send in a donation in lieu of feedback and bug reports.
User avatar
sentient06
Mac Mechanic
Posts: 187
Joined: Tue Mar 29, 2011 8:57 pm
Location: London, UK

Re: Mini vMac Updates: September 18

Post by sentient06 »

Do you reckon Basilisk II will fall from grace in favour of Mini vMac after introducing Mactintosh II emulation?
User avatar
adespoton
Forum All-Star
Posts: 3235
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Mini vMac Updates: September 18

Post by adespoton »

I don't, for a couple of reasons:
1) Mini vMac doesn't do full network emulation.
2) Mini vMac doesn't do 68040 emulation (Quadra ROM)

AFAIK, Paul isn't interested at this time in implementing either of those, so Basilisk II and MESS will be the only potential solutions, unless PCE adds further support. But MESS is still broken for network emulation and 68040 emulation, leaving BII as the only option.

Possibly someone will update qemu-system-68k to actually load and run virtual 68k hardware, but the investigations done to this point indicate that the qemu structure makes it non-trivial to implement the classic 68k hardware architecture.

For running non-networked Twiggy through 68020 Macs, Mini vMac does seem to be the future though. MESS has some 68020 instructions implemented that appear to still be lacking in Mini vMac, causing issues with the likes of Prince of Persia 2 (not the original game). Mini vMac 68020 emulation also still has some timing issues, as it is using the 68000 timing profile.
User avatar
sentient06
Mac Mechanic
Posts: 187
Joined: Tue Mar 29, 2011 8:57 pm
Location: London, UK

Re: Mini vMac Updates: September 18

Post by sentient06 »

I noticed Emaculation is slightly outdated concerning Mini vMac:

http://emaculation.com/doku.php/mini_vmac

v3.4 is not alpha anymore. v3.5 is the alpha at this point, according to the website:

http://www.gryphel.com/c/minivmac/alpha.html
User avatar
sentient06
Mac Mechanic
Posts: 187
Joined: Tue Mar 29, 2011 8:57 pm
Location: London, UK

Re: Mini vMac Updates: September 18

Post by sentient06 »

adespoton wrote: Possibly someone will update qemu-system-68k to actually load and run virtual 68k hardware, but the investigations done to this point indicate that the qemu structure makes it non-trivial to implement the classic 68k hardware architecture.
Is that because of the Old World ROMs?
User avatar
ClockWise
Site Admin
Posts: 4076
Joined: Mon May 20, 2002 4:37 am
Location: Uiwang
Contact:

Re: Mini vMac Updates: September 18

Post by ClockWise »

Thanks for the heads up!
sentient06 wrote:I noticed Emaculation is slightly outdated concerning Mini vMac:

http://emaculation.com/doku.php/mini_vmac

v3.4 is not alpha anymore. v3.5 is the alpha at this point, according to the website:

http://www.gryphel.com/c/minivmac/alpha.html
User avatar
adespoton
Forum All-Star
Posts: 3235
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Mini vMac Updates: September 18

Post by adespoton »

sentient06 wrote:
adespoton wrote: Possibly someone will update qemu-system-68k to actually load and run virtual 68k hardware, but the investigations done to this point indicate that the qemu structure makes it non-trivial to implement the classic 68k hardware architecture.
Is that because of the Old World ROMs?
Yes; that and proprietary hardware that needs to be properly emulated on top of the main core.
Post Reply