From: Christian B. <cb...@st...> - 2000-11-29 18:17:54
|
Hi! Because of the stagnant state of BeOS/ppc, the superiority of open sourced software, and the success of Basilisk II, Marc Hellwig and I (actually just me because Marc left the decision to me) have decided to make SheepShaver open source, too. The internal structure of both programs (B2 and SS) is quite similar (because B2 was modelled after SS) and in fact, the only difference for many source files is just the copyright header. With a little more work, I think that about 80% of the source files could be shared between both projects. The logical conclusion is thus to merge both projects in some way. The most extreme (but probably possible) way would be to put both 68k and PPC Mac emulation into one program. Which CPU architecture will be emulated is then decided by the type of ROM being used. A couple of thoughts about this: 1. The most important issue to be resolved is of course: how should this combined emulator be named? :-) "Basilisk III" sounds a bit boring and is also not completely accurate since Basilisk II was named this way because it (originally) emulated a Mac II class machine, not so much because it was the successor to the original "Basilisk". I also like the "SheepShaver" name. 2. SheepShaver only has native PowerPC support. There is no PowerPC emulation for other systems yet (I've started with a simple interpreter but this would need a lot more work to be usable, let alone efficient enough). 3. Some things need a little rearranging. We would now be concerned with 3 different configurations: - native 68k, emulated PPC (possible, but probably too slow to make much sense) - emulated 68k (could use 68k emulation from MacOS ROM), native PPC - emulated 68k, emulated PPC 4. Because there is only one set of MacOS memory access functions, it is necessary for the emulator to run in the same addressing mode, whether a 68k or a PPC Mac is to be emulated. Luckily, 68k and PPC have the same endianess and alignment restrictions. So on a native 68k machine, the PPC emulation will have to run in real addressing mode, which is possible (likewise for a native PPC machine). 5. The memory access subsystem will have to be separated from the CPU emulation (currently the memory access is from UAE's 68k emulator) to make it possible for 68k and PPC emulation to use the same memory module. 6. Due to the way SheepShaver works, it needs 12k of Low Memory globals (instead of 8k as B2, or 10k as a real PowerMac). But this shouldn't be a problem. 7. Because SheepShaver was designed for PPC systems, there are many places where it more or less directly jumps into MacOS code. These places will have to be rewritten carefully. 8. This especially affects the SheepShaver Ethernet driver which is completely different from the B2 one. It is a proper DLPI module for Open Transport and as such calls many OT functions for message and queue management, and it also requires OT headers which cannot be included in a source release. 9. Video mode selection is also different because SheepShaver provides run-time mode and depth switching (there is a nice and clean interface for PCI video drivers for doing this). But with some clever redesign, this should provide the 68k emulation with mode/depth switching, too. In any case, I would like to have at least one more stable release of Basilisk II (with JIT) before starting with this (probably not this year any more). Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: Lauri P. <lpe...@ni...> - 2000-11-29 22:58:55
|
On Wed, 29 Nov 2000 19:17:51 +0100, cb...@st... wrote: >Hi! > >Because of the stagnant state of BeOS/ppc, the superiority of open sourced >software, and the success of Basilisk II, Marc Hellwig and I (actually just >me because Marc left the decision to me) have decided to make SheepShaver >open source, too. Wow! Thank you on behalf of the open source community. > 1. The most important issue to be resolved is of course: how should this > combined emulator be named? :-) > "Basilisk III" sounds a bit boring and is also not completely accurate > since Basilisk II was named this way because it (originally) emulated > a Mac II class machine, not so much because it was the successor to the > original "Basilisk". I also like the "SheepShaver" name. Forgetting all healthy self-criticism, just brainstorming: SheepShearer SheepSaviour SheepHerder SheepSorter SheepDog SheepShaver++ Shepherd SharpShooter Nomad (they keep sheeps) Antilope (fast and beatiful) Jabberwocky (powerful) Nebula Constellation Seahorse Bearhunter Whirlpool Raincoat (as Macintosh) Orwell MODEM (MODular EMulator) Miranda (I just happen to like that name; but there is already a programming language w/ the same name) But Basilisk III is great too; the word "basilisk" tends to stirr positive associations: - the animal is sympathetic unlike some other reptiles - some species can walk on the water (making "impossible" true) - Basilisk, Basilisk II. > 2. SheepShaver only has native PowerPC support. There is no PowerPC emulation > for other systems yet (I've started with a simple interpreter but this > would need a lot more work to be usable, let alone efficient enough). If needed, I would be glad to help with the interpreter. Given the speed that the hardware keeps evolving, I think that an interpretive solution might be eventually useable. And I think I know someone on this list who has excellent track record concerning JIT cores :) Regarding the rest of the list: what parts do you feel that could be delegated to other people, to ease your "burden"? Clearly some items are beyond at least my knowledge. >Bye, >Christian Lauri |
From: Christian B. <cb...@st...> - 2000-12-05 22:20:38
|
Hi! On Thu, Nov 30, 2000 at 01:02:40AM +0200, Lauri Pesonen wrote: > [lots of names] > But Basilisk III is great too; the word "basilisk" tends to stirr > positive associations: The associations are probably not so positive amongst D&D players. :-) > - Basilisk, Basilisk II. Maybe I should just drop the "II" and revert to plain "Basilisk". > Regarding the rest of the list: what parts do you feel that could be > delegated to other people, to ease your "burden"? The PPC CPU emulation and the rewriting are probably the most "delegatable" items. Everything else is mainly small changes in a lot of places. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: <gb...@di...> - 2000-12-04 18:51:43
|
Hi, > Because of the stagnant state of BeOS/ppc, the superiority of open sourced > software, and the success of Basilisk II, Marc Hellwig and I (actually just > me because Marc left the decision to me) have decided to make SheepShaver > open source, too. Great! > 1. The most important issue to be resolved is of course: how should this > combined emulator be named? :-) - PDM Emulator Piltdown Man was the first PowerMac prototype which had a Centris case <http://www.applefritter.com/> Or "Portable and Definitive Macintosh Emulator" ;-) > 2. SheepShaver only has native PowerPC support. There is no PowerPC emulation > for other systems yet (I've started with a simple interpreter but this > would need a lot more work to be usable, let alone efficient enough). Talking about PPC Emulation, I realized when I finally set up a PPC cross-compilation system that PSIM was only twice as slow as UAE on the benchtest program that comes with PSIM. Taking into account the fact that PSIM emulates a complete MMU, that's not so bad, imho. There are other alternatives but I don't know their current status - Lauri's interpreter (most recent ;-) - Bill Huey's JIT Compiler - Bill Meyer's interpretive core (defintively stalled) > In any case, I would like to have at least one more stable release of > Basilisk II (with JIT) before starting with this (probably not this year > any more). Bernie Meyer has just released a new version of his JIT Compiler. That's really impressive but changes were so radical that this will take more time than I expected, and I am running into three very busy weeks :-/ BTW Christian, a PPC Emulation is a great project and I am willing to contribute. It happens that I am in final year (in computer science) now and I have a 4-month training period (internship) to carry out in February. Pure dream: what if a great company committed to Open Source Software gives me a chance to participate to such a project and others ? ;-) Bye, Gwenole. |
From: Christian B. <cb...@st...> - 2000-12-19 19:10:08
|
Hi! On Mon, Dec 04, 2000 at 07:55:38PM +0100, Gwenole Beauchesne wrote: > Talking about PPC Emulation, I realized when I finally set up a PPC > cross-compilation system that PSIM was only twice as slow as UAE on the > benchtest program that comes with PSIM. Hm... Makes me wonder how fast it can get just by throwing out unnecessary stuff (memory management). Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: <gb...@di...> - 2001-01-05 22:51:46
|
Hi, > On Mon, Dec 04, 2000 at 07:55:38PM +0100, Gwenole Beauchesne wrote: > > Talking about PPC Emulation, I realized when I finally set up a PPC > > cross-compilation system that PSIM was only twice as slow as UAE on the > > benchtest program that comes with PSIM. > > Hm... Makes me wonder how fast it can get just by throwing out unnecessary > stuff (memory management). For what it worth, here are the configure options I used for the fastest PSIM build I ran: --enable-sim-cflags="-g0 -O2" \ --enable-sim-decode-mechanism=padded-switch \ --enable-sim-icache=1024 \ --enable-sim-filter="-f 64" \ --enable-sim-inline \ --enable-sim-bswap \ --enable-sim-endian=big-endian \ --enable-sim-model=MODEL_ppc604 \ --disable-sim-model-issue \ --disable-sim-regparm \ --disable-sim-smp \ --disable-sim-jump \ --disable-sim-monitor \ --disable-sim-stdcall \ --disable-sim-xor-endian \ --disable-sim-trace \ --disable-sim-assert Yes, the "padded-switch" implementation yielded better results than a direct threaded core on my K6-2... |
From: <gb...@di...> - 2000-12-30 02:48:26
|
Hi, > Bernie Meyer has just released a new version of his JIT Compiler. That's > really impressive but changes were so radical that this will take more > time than I expected, and I am running into three very busy weeks :-/ I got stuck with a silly bug I introduced when copying the files :-( A development tarball is on my website: BasiliskII-JIT-20001229b.tar.gz There are still a few things to do but this is useable and incredibly faster (1.5x up to 2.0x !), especially FPU emulation. PS: Christian, could you please rerun your tests for "Julia's Dream" ? Alternatively, where may I find that application ? Thanks. PPS: I removed compiler.{cpp,h} in my sources. Do you still want those for future normal B2 releases (CVS) ? B2-JIT only does 68040 though it should also work for 68020 and 68030 cpus, but actually doesn't... Happy New Year! Gwenol=E9. |
From: Christian B. <cb...@st...> - 2001-01-01 22:05:40
|
Hi! On Sat, Dec 30, 2000 at 12:25:03AM +0100, Gwenole Beauchesne wrote: > A development tarball is on my website: > BasiliskII-JIT-20001229b.tar.gz These things appear and disappear faster than I can get them... I have BasiliskII-JIT-20001231a.tar.gz now. > PS: Christian, could you please rerun your tests for "Julia's Dream" ? This seems to work fine now, but I get lots of random crashes with the emulator. The average runtime is about 30 seconds before it crashes (usually "do_handle_screen_fault: unhandled address", but also "Illegal instruction"). This is on a PIII with Debian 2.2 and gcc 2.95.2. > PPS: I removed compiler.{cpp,h} in my sources. Do you still want those > for future normal B2 releases (CVS) ? Anything that is unneeded can go. > B2-JIT only does 68040 though it should also work for 68020 and 68030 > cpus, but actually doesn't... Caching issues? Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: <gb...@di...> - 2001-01-05 22:51:42
|
Hi, > > PS: Christian, could you please rerun your tests for "Julia's Dream" ? > > This seems to work fine now, but I get lots of random crashes with the > emulator. The average runtime is about 30 seconds before it crashes > (usually "do_handle_screen_fault: unhandled address", but also "Illegal > instruction"). This is on a PIII with Debian 2.2 and gcc 2.95.2. Yes, I also noticed that for small translation cache sizes. e.g. 256 KB or 512 KB. With a much higher cache, say 8 MB, things are more stable and also much faster. As for the cause to the problem, I am pretty sure it is related to the way I handle spcflags and the condition/process to get out of compiled code once a real ("hard") translation cache flush occured. I had experimented a few other approaches but with no avail :-/ It's probably not related to spcflags after all. You know, I find pretty hard to debug B2 because I can't use gdb. Indeed, whenever I set up a breakpoint, gdb would not stop and finally makes B2 to exit with a (-1) return value. Therefore, I am currently condamned to read and re-read the source code and experiment a few things with runtime disassemblers and some other techniques I am not proud of... > > PPS: I removed compiler.{cpp,h} in my sources. Do you still want those > > for future normal B2 releases (CVS) ? > > Anything that is unneeded can go. Actually, the JIT compiler normally does 68020 up to 68040. the original compiler was to support 68000 only. Is it worth "supporting" that CPU ? How many people do really emulate a Classic Mac ? ;-) > > B2-JIT only does 68040 though it should also work for 68020 and 68030 > > cpus, but actually doesn't... > > Caching issues? Yes, probably. I already had that problem in the past and fixed that in a previous release. The problem is that I don't remember how since I was fixing other bugs I thought unrelated to that problem. i.e. some day, I wanted to try in 68030 mode again and it automagically worked... But there is definitively a cache problem since the JIT compiler would also get disabled forever once the Desktop shows up. |
From: Christian B. <cb...@st...> - 2001-01-13 15:13:36
|
Hi! On Fri, Jan 05, 2001 at 11:56:29PM +0100, Gwenole Beauchesne wrote: > Indeed, whenever I set up a breakpoint, gdb would not stop and finally > makes B2 to exit with a (-1) return value. Therefore, I am currently > condamned to read and re-read the source code and experiment a few things > with runtime disassemblers and some other techniques I am not proud of... Have you tried (cx)mon? Maybe breakpoint support can be added to it. > Actually, the JIT compiler normally does 68020 up to 68040. the original > compiler was to support 68000 only. Is it worth "supporting" that CPU ? People using the Classic emulation are probably not in need of speed... Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |