Basilisk II re-write
Moderators: Cat_7, Ronald P. Regensburg
Basilisk II re-write
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?
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?
- adespoton
- Forum All-Star
- Posts: 4279
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: Basilisk II re-write
How long do you have?ArtiomWin wrote:How long would take to re-write emulator?
Re: Basilisk II re-write
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.
- adespoton
- Forum All-Star
- Posts: 4279
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: Basilisk II re-write
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.
- rickyzhang
- Apple Corer
- Posts: 205
- Joined: Mon Sep 15, 2014 7:59 pm
Re: Basilisk II re-write
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.
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
https://github.com/rickyzhang82
-
- Inquisitive Elf
- Posts: 26
- Joined: Wed Jul 26, 2017 10:50 pm
Re: Basilisk II re-write
Out of curiosity, do you know what was broken about JIT? Did it flat-out not work?rickyzhang wrote:For example, JIT was broken.
Also, to your knowledge, was JIT broken in Basilisk II, in UAE, or both?
- rickyzhang
- Apple Corer
- Posts: 205
- Joined: Mon Sep 15, 2014 7:59 pm
Re: Basilisk II re-write
Sorry, I don't know the technical reason. But it might relate to how compiler generate target code. In Mac Clang, it never works.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?
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
https://github.com/rickyzhang82
Re: Basilisk II re-write
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
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
- rickyzhang
- Apple Corer
- Posts: 205
- Joined: Mon Sep 15, 2014 7:59 pm
Re: Basilisk II re-write
Cat_7,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
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
https://github.com/rickyzhang82
Re: Basilisk II re-write
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
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
- rickyzhang
- Apple Corer
- Posts: 205
- Joined: Mon Sep 15, 2014 7:59 pm
Re: Basilisk II re-write
Thank you! That's superb helpful.Cat_7 wrote: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
There is an App for that!
https://github.com/rickyzhang82
https://github.com/rickyzhang82
Re: Basilisk II re-write
I'm here to explain suggestion in more details.
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.
1. MMU emulation (as it was required by A/UX and Linux distributions)What new features you desperately want from WinUAE?
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.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.
- rickyzhang
- Apple Corer
- Posts: 205
- Joined: Mon Sep 15, 2014 7:59 pm
Re: Basilisk II re-write
I'm reading BII source code in addressing.ArtiomWin wrote: 1. MMU emulation (as it was required by A/UX and Linux distributions)
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 }
There is an App for that!
https://github.com/rickyzhang82
https://github.com/rickyzhang82
Re: Basilisk II re-write
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.
- rickyzhang
- Apple Corer
- Posts: 205
- Joined: Mon Sep 15, 2014 7:59 pm
Re: Basilisk II re-write
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.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.
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
https://github.com/rickyzhang82
- adespoton
- Forum All-Star
- Posts: 4279
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: Basilisk II re-write
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.
After breaking enough things, you'll get a feel for what code lines up with what (lack of) functionality.