Basilisk II re-write

About BasiliskII, a 68k Mac emulator for Windows, MacOSX, and Linux that can run System 7.x through MacOS 8.1.

Moderators: Cat_7, Ronald P. Regensburg

Post Reply
ArtiomWin
Student Driver
Posts: 13
Joined: Mon Jun 26, 2017 7:48 am

Basilisk II re-write

Post by ArtiomWin »

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?
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Basilisk II re-write

Post by adespoton »

ArtiomWin wrote:How long would take to re-write emulator?
How long do you have?
ArtiomWin
Student Driver
Posts: 13
Joined: Mon Jun 26, 2017 7:48 am

Re: Basilisk II re-write

Post by ArtiomWin »

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.
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Basilisk II re-write

Post by adespoton »

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.
User avatar
rickyzhang
Apple Corer
Posts: 205
Joined: Mon Sep 15, 2014 7:59 pm

Re: Basilisk II re-write

Post by rickyzhang »

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
DLudwig255
Inquisitive Elf
Posts: 26
Joined: Wed Jul 26, 2017 10:50 pm

Re: Basilisk II re-write

Post by DLudwig255 »

rickyzhang wrote:For example, JIT was broken.
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?
User avatar
rickyzhang
Apple Corer
Posts: 205
Joined: Mon Sep 15, 2014 7:59 pm

Re: Basilisk II re-write

Post by rickyzhang »

DLudwig255 wrote: 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
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Basilisk II re-write

Post by Cat_7 »

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
User avatar
rickyzhang
Apple Corer
Posts: 205
Joined: Mon Sep 15, 2014 7:59 pm

Re: Basilisk II re-write

Post by rickyzhang »

Cat_7 wrote:Hi,

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:

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
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Basilisk II re-write

Post by Cat_7 »

User avatar
rickyzhang
Apple Corer
Posts: 205
Joined: Mon Sep 15, 2014 7:59 pm

Re: Basilisk II re-write

Post by rickyzhang »

Thank you! That's superb helpful.
There is an App for that!
https://github.com/rickyzhang82
ArtiomWin
Student Driver
Posts: 13
Joined: Mon Jun 26, 2017 7:48 am

Re: Basilisk II re-write

Post by ArtiomWin »

I'm here to explain suggestion in more details.
What new features you desperately want from WinUAE?
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.
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.
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.
User avatar
rickyzhang
Apple Corer
Posts: 205
Joined: Mon Sep 15, 2014 7:59 pm

Re: Basilisk II re-write

Post by rickyzhang »

ArtiomWin wrote: 1. MMU emulation (as it was required by A/UX and Linux distributions)
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:

Code: Select all

0126 #if REAL_ADDRESSING || DIRECT_ADDRESSING
0127 static __inline__ uae_u8 *do_get_real_address(uaecptr addr)
0128 {
0129     return (uae_u8 *)MEMBaseDiff + addr;
0130 }
0131 static __inline__ uae_u32 do_get_virtual_address(uae_u8 *addr)
0132 {
0133     return (uintptr)addr - MEMBaseDiff;
0134 }
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
uyjulian
Apple Corer
Posts: 244
Joined: Fri Aug 27, 2010 1:02 am

Re: Basilisk II re-write

Post by uyjulian »

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.
User avatar
rickyzhang
Apple Corer
Posts: 205
Joined: Mon Sep 15, 2014 7:59 pm

Re: Basilisk II re-write

Post by rickyzhang »

julialy wrote: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
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Basilisk II re-write

Post by adespoton »

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.
Post Reply