Hello, forum.
I'm here with an idea (it's not new). Since Basilisk II uses UAE engine to emulate CPU, and development of WinUAE has greatly progressed last few years, I think Basilisk II should be updated and re-based to WinUAE. This would enable advantages such as MMU support (required by A/UX), emulation of peripherals, and possibility of adding emulation of PowerPC (Power Macintoshes) and x86 (MacCharlie, DOS compability cards). How long would take to re-write emulator?

How long do you have?

I was about needed workload. Actually I don't have programming skills, but I've asked if the work on re-writing would be hard.

The work on re-writing would be hard. That's why nobody's really worked on BII at all since 2009. Same goes for SheepShaver.

I'm not sure what is your motivation to rewrite BII emulation part. What new features you desperately want from WinUAE?

For example, JIT was broken. But in my experience there is no need to be fixed given the fact that nowadays CPU is fast enought. I haven't experienced sluggishness in the old Mac game I got. I'm happy to live without JIT.

If it ain't broken, don't fix it.

_________________
There is an App for that!
https://github.com/rickyzhang82

Out of curiosity, do you know what was broken about JIT? Did it flat-out not work?

Also, to your knowledge, was JIT broken in Basilisk II, in UAE, or both?

Sorry, I don't know the technical reason. But it might relate to how compiler generate target code. In Mac Clang, it never works.

I planned to study how JIT or emulation works. But I can only find technical design in BII and one paper from QEMU. If you are interested in this, I can send you the link and paper. Although source code is out there, it will take some significant time to figure it out.

_________________
There is an App for that!
https://github.com/rickyzhang82

Hi,

There is a problem with gcc above 4.6 to compile the jit.
It seems the ret statement in the assembly doesn't get placed at the end of code blocks. 64 bit jit would require rewrite in x64 assembly.

Some time ago I contacted a Qemu developer regarding 64 bit dyngen (as Qemu also used dyngen before moving the tcg). This is what he answered:

The binary formats for 32 bit and for 64 bit applications
differ. See http://en.wikipedia.org/wiki/Portable_Executable for details.
You can also use objdump to see the header data from *.o files.
In your case, obj/basic-dyngen-ops.o is 64 bit Windows code.
Try "file obj/basic-dyngen-ops.o" to see this.

QEMU's dyngen.c never supported the 64 bit Windows binary format:

/* Check COFF identification. */
if (fhdr.f_magic != I386MAGIC) {
error("bad COFF header");
}

32 bit Windows uses the code marked with preprocessor macro
CONFIG_FORMAT_COFF.
For 64 bit Windows, you will need new code which is similar but not
identical.

Best,
Cat_7

Cat_7,

Do you have or know the technical details of how dygen works in JIT? I read QEMU paper on JIT. But I don't know the details and how this works in BII. I wish I could understand it and write something down.

thanks,
Ricky

_________________
There is an App for that!
https://github.com/rickyzhang82

Hi,

I'm sorry, the answer I received was way over my head

But here are some pointers:
http://gsoc.cat-v.org/people/nwf/dyngen-demo

Dyngen code from 2007 (so after development of basilisk had stopped) https://github.com/hackndev/qemu/blob/master/dyngen.c

Paper on dyngen: https://www.usenix.org/legacy/event/use ... ellard.pdf

http://songcy1984.blogspot.nl/2009/05/qemu-dyngen.html

http://www.cs.cmu.edu/~412/lectures/L05_QEMU_BT.pdf

https://android.googlesource.com/platfo ... tcg/README

then there is this: http://www.minix3.org/theses/kouwe-qemu.pdf

Best,
Cat_7

Thank you! That's superb helpful.

_________________
There is an App for that!
https://github.com/rickyzhang82

I'm here to explain suggestion in more details.


1. MMU emulation (as it was required by A/UX and Linux distributions)
2. Full SCSI/IDE emulation (Softmac has it, also SCSI support was in build 142)
3. Since WinUAE can emulate full range of 68k processors, new Basilisk should be expected to emulate all 68k models from 128k (maybe even Twiggy prototype) to 68040-based Quadras and Powerbooks (and with QEMU PPC core plugin range would be extended up to PowerPC G4, so new emulator would be successor of both Basilisk II and Sheepshaver)
4. Emulation of expansion cards (NuBus graphic cards, Apple IIe card, DOS cards/addons, etc.)

So, maybe it's not about porting new WinUAE engine to current Basilisk II, but about making new emulator with old name.

You can turn off JIT in WinUAE, so it would be optional here. Also, the JIT compiler in WinUAE can only be used with 68020 or higher emulated CPUs, and is not compatible with MMU emulation.

I'm reading BII source code in addressing.

68000, 68010 and 68020 CPU has no MMU. Only 68030 above has built-in MMU. I bought Inside Macintosh Volume VI. In Memory Management section, it did mentions that since 68030 CPU it supports 32bit virtual addressing.

I'm curious if BII implement MMU. So far I don't think so in src/​uae_cpu/​memory.h:


If BII didn't implement MMU, how can it emulate 68030 and above MMU operation instruction?

_________________
There is an App for that!
https://github.com/rickyzhang82

To get a better idea of what needs to be ported to the newer WinUAE core (if you are going to use it), it would be a good idea to track down the original source code of the UAE variant that BasiliskII uses, and diff the original cpu-emulation source with BasiliskII's cpu-emulation source.

If diff is just few commit differences, it may be easy for human to read. But for project like this, I doubt it has any value to do a diff.

One of major obstacle for anyone to make any improvement in emulation core is that there is no decent technical documentation. If you don't understand what is under the hood, you can't renovate it without breaking.

_________________
There is an App for that!
https://github.com/rickyzhang82

One of the rules of black box porting: Break often and quickly, and document what you did to cause the break

After breaking enough things, you'll get a feel for what code lines up with what (lack of) functionality.