Page 1 of 1
Basilisk II re-write
Posted: Thu Jun 29, 2017 7:23 am
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?
Re: Basilisk II re-write
Posted: Thu Jun 29, 2017 4:16 pm
by adespoton
ArtiomWin wrote:How long would take to re-write emulator?
How long do you have?
Re: Basilisk II re-write
Posted: Thu Jun 29, 2017 4:53 pm
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.
Re: Basilisk II re-write
Posted: Thu Jun 29, 2017 5:36 pm
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.
Re: Basilisk II re-write
Posted: Fri Jul 14, 2017 7:44 pm
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.
Re: Basilisk II re-write
Posted: Thu Jul 27, 2017 1:54 pm
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?
Re: Basilisk II re-write
Posted: Mon Aug 07, 2017 12:13 am
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.
Re: Basilisk II re-write
Posted: Mon Aug 07, 2017 5:58 am
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
Re: Basilisk II re-write
Posted: Mon Aug 07, 2017 5:20 pm
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
Re: Basilisk II re-write
Posted: Mon Aug 07, 2017 5:48 pm
by Cat_7
Re: Basilisk II re-write
Posted: Thu Aug 10, 2017 8:04 pm
by rickyzhang
Thank you! That's superb helpful.
Re: Basilisk II re-write
Posted: Fri Aug 11, 2017 8:11 pm
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.
Re: Basilisk II re-write
Posted: Sat Aug 12, 2017 12:32 am
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?
Re: Basilisk II re-write
Posted: Sat Aug 12, 2017 1:41 am
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.
Re: Basilisk II re-write
Posted: Sat Aug 12, 2017 2:52 am
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.
Re: Basilisk II re-write
Posted: Tue Aug 15, 2017 6:03 pm
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.
