basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] B2-JIT from UAE-JIT "Ipswitch Town" approaching

[Christian B. <cb...@st...>]

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/

[B2-devel] B2-JIT from UAE-JIT "Ipswitch Town" approaching

[<gb...@di...>]

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.

Re: [B2-devel] Re: MacOS X port screenshot

[Christian B. <cb...@st...>]

Hi!

On Thu, Dec 07, 2000 at 12:53:22PM +1100, ni...@in... wrote:
> [Apple's DR Emulator]
> * I think we would need to be emulating a PowerMac before that code
>   could be used. (I have seen the problems in calling Mac ROM code
>   from Unix [MRG in NetBSD/Mac68k], and it isn't pretty)

The BeOS/ppc port can use the 68k emulation from a Mac ROM (classic image
file or NewWorld-style). The code for this is in the powerrom_cpu directory.
Only the interpretative emulation is used, however, because I had problems
with the interrupts in the DR emulator, and the DR emulator never gets
activated (MacOS on PPC machines does this at some point during bootup).

> 	My current hack for this is to give Basilisk a bitmap pointer
> that is offset by 1, so that it draws into the correct channels.
> Incredibly, it works (I thought I would have word alignment problems).

A similar problem on the Amiga with ShapeShifter was solved in the same way...

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] [ANN] JIT Basilisk II 04/12/2000

[Christian B. <cb...@st...>]

Hi!

On Tue, Dec 05, 2000 at 11:45:10PM +0100, Gwenole Beauchesne wrote:
> BTW, any objection in moving all FPU related files to a fpu/
> subdirectory of uae_cpu/ ?

None.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Re: A few questions

[Christian B. <cb...@st...>]

Hi!

On Tue, Dec 05, 2000 at 02:50:10PM +1100, ni...@in... wrote:
> 	I couldn't find this in 0.8.1, or the latest "snapshot".
> Maybe it is in the latest version of the CVS file?

Everything's in CVS. Forget the snapshots.

> [XPRAM watchdog]
> 	Fair enough. I see that the BeOS port has one too,
> but that the Amiga port does not. Interesting.

An oversight...

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] Re: =?us-ascii?Q?=5BB2-devel=5D_B2+SS=3D=3F?=

[Christian B. <cb...@st...>]

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/

[B2-devel] Re: MacOS X port screenshot

[<ni...@in...>]

Gwenole asked:

> 1) BTW, do you have a solution for direct addressing ?

	REAL_ADDRESSING builds just seemed to crash for me :-)
When I started investigating, I got lost in the mmap() stuff
(manpages for some functions in OS X public beta are missing),
so I decided that I would get everything else working first.

> e.g. does MacOS X
> supports POSIX Extended Signal Handlers, the ones that can take a
> siginfo_t structure informing you about the address of an illegal
> instruction for example ?

	Doesn't look like it has them.


> 2) Is there and will it be possible to use Apple's DR Emulator located
> in ROM ?

* Only 30% of the machines that currently run MacOS X (i.e. >= G3)
  actually have the DR 68k Emulator in ROM. The others get it from
  the NewWorld ROM file on the System disk.

* I think we would need to be emulating a PowerMac before that code
  could be used. (I have seen the problems in calling Mac ROM code
  from Unix [MRG in NetBSD/Mac68k], and it isn't pretty)





Lauri commented:

> >2) Has a cyan cast.
...
> I think I had the same problem once:
> 
> http://www.kearney.net/~mhoffman/basiliskII/online.JPG

	Emulating a Mac in a PC emulator. How sick ;-)

> The color distortion looks quite similar.

	You at least had some red. I have none!

	The problem is caused by differing representations of 32bit
data in Basilisk & MacOS X's windowing (Quartz):

Basilisk _RGB	ARGB
Quartz   RGB_	RGBA
         ----	----
         0GB0	AGBA

	My current hack for this is to give Basilisk a bitmap pointer
that is offset by 1, so that it draws into the correct channels.
Incredibly, it works (I thought I would have word alignment problems).

	The correct fix for this would be to have another intermediate
memory buffer, and either rotate each 32bit word before copying, or
copy with my 1byte offset, but the emulator is slow enough already!


	Another problem is that the bitmap drawing classes do not
currently support 16bit bitmaps. They support 1, 2, 4 and 8 bits per
sample, but not 5 (for 555). The classes do adjust between source
and screen depth however, so for now I am just using 32bit, and
letting it be dithered or truncated.

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

Re: [B2-devel] MacOS X port screenshot

[Lauri P. <lpe...@ni...>]

On Tue, 5 Dec 2000 11:04:47 +1100 (EST), you wrote:

>	OK. There is a version at:
>
>http://www.zing.com/picture/pb170d94c2499614696882e49f59d1c52/ff20c279.jpg
>
>
>Sorry that it:
>
>1) Is scaled down in size.
>   Looks like Zing does that on upload
>
>2) Has a cyan cast.
>   The Basilisk and MacOS X bitmap buffer layouts are in
>   different formats, and I haven't worked out a fast way
>   to copy the former to the latter with translation.

I think I had the same problem once:

http://www.kearney.net/~mhoffman/basiliskII/online.JPG

The color distortion looks quite similar. As far as I remember, I was
blitting in 15 bits mode when I should have done it in 16 bit mode,
or vice versa. Consequently I wrote some conversion routines.
In the current Windows port they are in x86 assembly, but some of
the  C code is still present in comments. The bitmasks seem to be 
derived from the memory.cpp frame_host_XXX_lput() functions.

The file is video_windows.cpp in zip archive

http://gamma.nic.fi/~lpesonen/BasiliskII/BasiliskII_win32_src_18062000.zip

The functions are memcpy15() and memcpy16(), unrolled by 4.

On a x86, code like this is not that slow since it pairs well:

 *p4++ = ((b1 & 0x007F007F) << 9) | ((b1 & 0x1F001F00) >> 8) | ((b1 &
0xE000E000) >> 7);

Lauri

Re: [B2-devel] MacOS X port screenshot

[<gb...@di...>]

Hi,

> http://www.zing.com/picture/pb170d94c2499614696882e49f59d1c52/ff20c279.jpg

It's looking very nice ;-)

1) BTW, do you have a solution for direct addressing ? e.g. does MacOS X
supports POSIX Extended Signal Handlers, the ones that can take a
siginfo_t structure informing you about the address of an illegal
instruction for example ?

2) Is there and will it be possible to use Apple's DR Emulator located
in ROM ?

Bye.

[B2-devel] [ANN] JIT Basilisk II 04/12/2000

[<gb...@di...>]

Hi,

I had updated JIT Basilisk a couple of weeks back and fixed the lazy
flusher. The compile_block() function now takes only 8% of the total
execution time compared to more than 50% in the past but without Lazy
Flushing!

That release is not in sync with Bernie's latest UAE-JIT IT Release but
it now enables JIT Compilation for FPU instructions. Unfortunately, that
is rather buggy and actually slower than JIT-FPU. bkoz: JIT-FPU
activated the old and buggy UAE FPU core.

That weekend, I started to reimplement the FPU core for supposedly
IEEE-754/854 behaved target FPU. That core also implements lazy
evaluation of FPU flags as Bernie did for his UAE-JIT IT Release. If
that FPE core works on our SPARC workstations then I will probably
commit it to the CVS as it makes scrollbars working too ;-)

BTW, any objection in moving all FPU related files to a fpu/
subdirectory of uae_cpu/ ?

Bye
-- 
Gwenolé Beauchesne - Web: <http://gwenole.beauchesne.online.fr/>
JIT Basilisk II, FAQ fr.comp.sys.mac.programmation

[B2-devel] Re: =?us-ascii?Q?=5BB2-devel=5D_B2+SS=3D=3F?=

[Christian B. <cb...@st...>]

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/

[B2-devel] Re: A few questions

[<ni...@in...>]

	Christian answered a few of my questions:

> > [NMI/Reset]
...
> There's a TriggerNMI() in cpu_emulation.h which is
> currently unimplemented for the UAE CPU emulation

	I couldn't find this in 0.8.1, or the latest "snapshot".
Maybe it is in the latest version of the CVS file?


> (it works under AmigaOS, though). I think the BeOS port
> once had a "reset" capability, but it seems to have got lost somehow.
> Adding a Reset680x0() function might be in order.

	Calling newcpu.cpp's m68k_reset does all the resetting,
but because the emulator is an independant thread, most of the
time the emulator tells me "Your Mac program just did something
terribly stupid"


...
> > (e.g. why does Unix need an XPRAM watchdog?
> 
> The XPRAM contents are normally only saved when B2 quits. To avoid changes
> to the XPRAM from getting lost when the emulator crashes, a background
> thread looks for XPRAM changes every minute and saves the XPRAM if necessary.

	Fair enough. I see that the BeOS port has one too,
but that the Amiga port does not. Interesting.

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

[B2-devel] MacOS X port screenshot

[<ni...@in...>]

> On Tue, 28 Nov 2000 11:41:15 +1100 (EST), ni...@in...
> wrote:
> 
> If anyone wants to see what it looks like, I will mail the list
> a screen dump.

Lauri answered:
> Welcome to the list. Yes please, I would love to see it. But could you
> please upload it somewhere and send the URL instead if it's
> a large image.

	OK. There is a version at:

http://www.zing.com/picture/pb170d94c2499614696882e49f59d1c52/ff20c279.jpg


Sorry that it:

1) Is scaled down in size.
   Looks like Zing does that on upload

2) Has a cyan cast.
   The Basilisk and MacOS X bitmap buffer layouts are in
   different formats, and I haven't worked out a fast way
   to copy the former to the latter with translation.

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

[B2-devel] New emulator's name

[<ni...@in...>]

[merging B2 & SS]
>  1. The most important issue to be resolved is of course: how should this
>     combined emulator be named? :-)

	Maybe "Basilisk III, the return of the SheepShaver" ?
Someone could probably produce a picture/icon that looked like
a cheesy movie poster.

	Or, you could always use something boring like MAE
(Macintosh Application Environment).

	I doubt that Apple will be using that name again :-)

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

Re: [B2-devel] B2+SS=?

[<gb...@di...>]

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.

Re: [B2-devel] B2+SS=?

[Lauri P. <lpe...@ni...>]

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

Re: [B2-devel] Hello, and a few questions

[Lauri P. <lpe...@ni...>]

On Tue, 28 Nov 2000 11:41:15 +1100 (EST), ni...@in...
wrote:

>  If anyone wants to see what it looks like, I will mail the list
>  a screen dump.

Welcome to the list. Yes please, I would love to see it. But could you
please upload it somewhere and send the URL instead if it's
a large image.

Lauri

[B2-devel] =?us-ascii?Q?B2+SS=3D=3F?=

[Christian B. <cb...@st...>]

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/

Re: [B2-devel] Hello, and a few questions

[Christian B. <cb...@st...>]

Hi!

On Tue, Nov 28, 2000 at 11:41:15AM +1100, ni...@in... wrote:
> * Since this isn't an X windows port, I really cannot use
>   the Unix directory for video and main. So, is a directory
>   'MacOSX' at the same level as Amiga, BeOS and Unix OK?

This is better, especially if you intend to switch from autoconf/Makefiles
to an IDE.

> [NMI/Reset]
>   The sensible way to do this would seem to be to define two new
>   interrupt flags in main.h, e.g.:
> 	INTFLAG_NMI = 32	// Non maskable interrupt
> 	INTFLAG_RESET = 64	// Hard reset
>   and handle those in the emulator.

Not really. The INTFLAGS are for decoding level 1 interrupts. There's a
TriggerNMI() in cpu_emulation.h which is currently unimplemented for the
UAE CPU emulation (it works under AmigaOS, though). I think the BeOS port
once had a "reset" capability, but it seems to have got lost somehow.
Adding a Reset680x0() function might be in order.

>   Now, I can see that TriggerInterrupt() sets a bit to tell
>   something else to handle an interrupt, but I cannot see what
>   actually processes the InterruptFlags variable.

EmulOp()/M68K_EMUL_OP_IRQ tests them.

> (e.g. why does Unix need an XPRAM watchdog?

The XPRAM contents are normally only saved when B2 quits. To avoid changes
to the XPRAM from getting lost when the emulator crashes, a background
thread looks for XPRAM changes every minute and saves the XPRAM if necessary.

>       why does Unix use this:
> #ifdef NANOSLEEP
> 		struct timespec req = {1, 0};
> 		nanosleep(&req, NULL);
> #else
> 		usleep(1000000);
> #endif
>       to sleep for a minute when sleep(60); would suffice?)

I think I just copied the sleep code from some other function. I also like
nanosleep() better than sleep() because it doesn't mess with signals.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] Hello, and a few questions

[<ni...@in...>]

	Hi. I am working on porting B2 to MacOS X (Unix + new GUI).
Christian suggested I join this list, so here I am.


	Firstly, the question you must be asking yourself ...
Why would I want to emulate a Mac on a Mac? (apart from insanity)

1) Mainly because OS X only supports the emulation of programs
   that run under OS 9. I have some programs that only work under
   OS 8.5, some that require a 68020, and some that only work on
   a monochrome Mac

2) I don't have a copy of OS 9, and I am not planning on buying
   a copy just yet (hoping that Apple will bundle it at a discount)



	Here is what I have been doing:

* Installed a compiler (OS X PB doesn't come with one by default),
  and tried to compile Unix source for B2. Config failed,
  because OS X PB doesn't come with an X windows server by default

* I installed a demo X windows server, Xtools. After some fiddling
  around with the config files (OS X libraries are a bit different)
  and some header files (missing pthread & nanosleep prototypes),
  I got a version that mostly worked
  (some screen bit depths failed, but that may be the X server)

* I decided that a port to the "native" windowing system would be
  of more use to most people (I may also port to one of the free
  X servers later), so I have been learning about the foundation
  class libraries (Cocoa) and the developer kit (ProjectBuilder.
  Nice integrated application for building C, C++, Java and
  Objective-C, which invokes gcc and gdb to do all the hard work)

* At the moment, I have a B2 that outputs into a window at 24bit
  depth, but that doesn't yet accept input (will do soon), and is
  really slow (there is a task that draws the frame base into the
  window a few times a second).

  If anyone wants to see what it looks like, I will mail the list
  a screen dump.

* The native GUI classes are only in Objective-C and Java. To make
  my life easier, I decided to go the Obj-C route, but this means
  that I have a lot of "wrapper" functions defined in C++ land,
  so that C can call the standard B2 C++ routines.



	Now, some items for discussion:

* The "flavour" of Unix that OS X uses is called Darwin.
  Any objections to there being a 'Unix/Darwin' directory
  for the low-level Unix stuff ? (audio, ether et c.)

* Since this isn't an X windows port, I really cannot use
  the Unix directory for video and main. So, is a directory
  'MacOSX' at the same level as Amiga, BeOS and Unix OK?

* I would like to have the ability to "Interrupt" and "Restart"
  a hung B2 emulation (most real Macs have two buttons for this).
  The sensible way to do this would seem to be to define two new
  interrupt flags in main.h, e.g.:
	INTFLAG_NMI = 32	// Non maskable interrupt
	INTFLAG_RESET = 64	// Hard reset
  and handle those in the emulator.

  Now, I can see that TriggerInterrupt() sets a bit to tell
  something else to handle an interrupt, but I cannot see what
  actually processes the InterruptFlags variable.



	I also have heaps of questions about the source code

(e.g. why does Unix need an XPRAM watchdog?
      why does Unix use this:
#ifdef NANOSLEEP
		struct timespec req = {1, 0};
		nanosleep(&req, NULL);
#else
		usleep(1000000);
#endif
      to sleep for a minute when sleep(60); would suffice?)

but they can certainly wait until I have got a bit more code working,
and then built against the latest versions (I am using 0.8.1?)

-- 
| Nigel Pearson, ni...@in... | "Reality is that which,   |
|   Telstra NW-D, Sydney, Australia.    |  when you stop believing  |
| Office: 9206 3468    Fax:  9212 6329  |  in it, doesn't go away." |
| Mobile: 0408 664435  Home: 9792 6998  | Philip K. Dick - 'Valis.' |

Re: [B2-devel] JIT compiler: experimental release

[<gb...@di...>]

Hi,

[Supposed compiler bug]
> Or is there a constraints error my asm templates ?

Well, it appears I simply forgot the "ecx" register constraint...
I uploaded a new tarball with the fix.

Bye.
-- 
Gwenolé Beauchesne

[B2-devel] JIT compiler: experimental release

[<gb...@di...>]

Hi,

I have uploaded an experimental release (hmm, actually everything is
experimental ;-) at:
<http://gwenole.beauchesne.online.fr/basilisk2/files/>
File: BasiliskII-JIT-devel-20001101a.tar.gz

Features:
- The lazy flusher should work correctly now.
- spcflags "optimization" like in the Windows port
- exclusive spcflags handling

In fact, the new spcflags features doesn't seem to improve speed on my
machine. Those of you who have tremendous machines with Pentium III
processors, could you please try the new release ?
- first, with the JIT compiler only
- then, with --enable-spcflags-hack --enable-spcflags-excl in addition.

I will make a full release when I implemented register caching for the
interpreter and probably for the compiler. i.e. keeping the most used
variables into native registers, for as much time as possible. The
variables I plan to cache are: regs.pc_p, regflags, a pointer to the
regs structure.

BTW, I finally caught a gcc 2.95.2 compilation bug :-/
See in uae_cpu/compiler/compemu_support.cpp, down in the
m68k_run_compile() function: blocklen wouldn't get incremented depending
on where the incrementation is done... Do you have other compilers to
test with ? Or is there a constraints error my asm templates ?

Strange enough, cpu levels lower than 4 now appear to work although
slowly. That might be because the compiler got disabled for long periods
of time ?

Another person reported that the cpuopti.c optimization I made (see near
line 206) would not work with compilers earlier than 2.95. In fact, I
think I should manually push and pop the registers before running the
instruction handler in m68k_run_*. Counting on gcc to save those is
probably is Bad Thing...

Bye
-- 
Gwenolé Beauchesne

Re: [B2-devel] VOSF problems with NetBSD/m68k resolved

[Christian B. <cb...@st...>]

Hi!

On Fri, Oct 13, 2000 at 08:15:29PM +0200, Gwenole Beauchesne wrote:
> Sorry for being too lazy to build a log2 lookup table or a search for the
> position of the most significant bit set. Beat me. ;-)

/me puts a brown paper bag over gbeauche's head :-)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] JIT Basilisk II public release

[<gb...@di...>]

Hi,

The JIT-enabled BasiliskII is now publicly available at:
<http://gwenole.beauchesne.online.fr/basilisk2/>

Note: online.fr or free.fr are the same.
-- 
Gwenolé Beauchesne

Re: [B2-devel] VOSF problems with NetBSD/m68k resolved

[<gb...@di...>]

Hi,

> I figured out what caused the VOSF on NetBSD/m68k to fail. It was the
> floating-point calculations used to convert the page size to a shift count.
> With a page size of 4096, it returned 11 instead of 12 due to rounding
> errors.

Well spotted! Sorry for being too lazy to build a log2 lookup table or a
search for the position of the most significant bit set. Beat me. ;-)

Bye.
-- 
Gwenolé Beauchesne