basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Re: New SIGSEGV code to be committed

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

Hi,

> The new code seems to work fine on IRIX, just like the old code did.

Is your SGI box using siginfo_t or a sigcontext subterfuge ?
[Look at your config.h for the appropriate #define]

> At least in 68030 mode.  Whenever I try to use 68030+FPU or 68040, I get
> all kinds of nasty FP bugs, usually including wild references and core
> dumps.  See bug 422776.  Is this a known problem with the UAE FPU core
> on big endian or non-x68 systems?  I'm using MacOS 7.5.5.

What do you mean with wild references ?

When the FPE is enabled, do you get core dumps because the sigsegv
handler fail to handle the faultive address or do you get some SIGBUS
error because of possible mis-aligned accesses in the FPE code ?

BTW, do MIPS processors support 128-bit FP precision ?

> (Although the new code does change the symptoms of the problem a bit:
> now direct addressing core dumps (with an appropriate message from the
> segv handler) and real mode hangs Speedometer.)

Could you tell me the address reported by the segv handler and the
MEMBaseDiff offset value ?

I used to get a crash in real mode with Speedometer under Linux/x86.
Probably the patch I added in rom_patches.cpp make it hang on a
big-endian system ?

Can you disable the patch and tell me if it crashes for you too ?
[Search for "Speedometer" in rom_patches.cpp]

Actually, I no longer get any crash in real mode under Linux/x86 because
the system could map the entire Mac RAM and ROM from 0, i.e. not only
0x2000 bytes for the LowMem globals.

Bye,
Gwenol=E9.

Re: [B2-devel] B2+DGA=OK

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

Hi,

> I don't think that it's really necessary to suid B2. I've set up my Linux
> box to assign permissions for /dev/sheep_net and the MacOS partition to
> the user logged in at the console and this works just fine.

Do you accomplish the same for /dev/mem (XF86 DGA) ? For fbdev dga under
Solaris that's not a problem either since permissions are held by the
user logged in at the console too.

Bye,
Gwenol=E9.

Re: [B2-devel] Plan for 0.9 release ?

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

Hi,

> > Was I supposed to fix some things=A0?
>=20
> IIRC you said something about VOSF blitters and RGB masks that would have
> to be fixed.

Ah yes, that happened with Brian's SGI box. I think it is fixed now.
However, what I intended to do in the future is a generic handling of
blitters according to the current X11 RGB masks instead of making strong
assumptions about them beforehand. The specialised blitters will still
have to be used for "optimal" performance.

We could also complete the blitters so that all known RGB masks
configurations are covered correctly.

> > Providing an emulation of extended-precision FP would require too much
> > work that probably doesn't worth the effort (speed-wise, usability). An=
y
> > thoughts ?
>=20
> I don't know whether the added precision is really needed but it might be
> a desirable feature.

Ouch, I will then have to bug hunt why, in double-precision, MacOS 8
scrollbars don't scroll whereas the window contents do scroll. In
extended-precision, the scrollbars behavior is as expected.

[B2-devel] Basilisk II V0.9 released

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

Hi!

Basilisk II V0.9 is now official. You can get it from

  http://www.uni-mainz.de/~bauec002/B2Main.html

SourceForge will be updated as soon as it lets me in...

This also marks the end of the 0.9 feature freeze.
Keep those patches coming! :-)

Bye,
Christian

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

Re: [B2-devel] Re: Memory mapping

[Gwenole B. <gbe...@ma...>]

On Wed, 30 May 2001, Christian Bauer wrote:

> On Wed, May 23, 2001 at 10:41:45AM +1000, ni...@in... wrote:
> > =09Sure. What I actually meant was, what is this mmap() doing:
> >
> > RAMBaseHost =3D (uint8 *)mmap(0, mapped_ram_rom_size,
> >                             PROT_READ | PROT_WRITE,
> > =09=09=09    MAP_PRIVATE, zero_fd, 0);
> >
> > =09So, how is this really any different to:
> >
> > RAMBaseHost =3D (uint8 *)malloc(mapped_ram_rom_size);
>
> Hm, at first glance I can't see the reason. It looks like gbeauchesne wro=
te
> that part (rev. 1.19 vs. 1.20 of that file); maybe he knows. Perhaps it
> simplifies some things by just having to munmap() the area when quitting
> istead of either munmap() or free()?

Hmm, seems like a residual code from a previous experiment. More
seriously, VOSF needs to mmap() the framebuffer area in order to make
further calls to mprotect() on it. It is not guaranted that malloc()
returns a mmap'ed area though Linux/glibc's implementation tends to call
mmap() for big chunks rather than sbrk() or whatever. [1]

Now, as for mmap()'ing RAM and ROM as well. IIRC, this comes from Solaris'
man page about mmap() and malloc() telling not to mix them if we don't
want to be trashed to hell. In other words, this may segfault but I
reckon I have not tried it.

[1] Just checked a linux/glibc man page about mprotect() and it appears
POSIX.1b says that mprotect() can be used only on regions of memory
obtained from mmap().

Bye,
Gwenol=E9.

Re: [B2-devel] Re: Memory mapping

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

Hi!

On Wed, May 23, 2001 at 10:41:45AM +1000, ni...@in... wrote:
> 	Sure. What I actually meant was, what is this mmap() doing:
> 
> RAMBaseHost = (uint8 *)mmap(0, mapped_ram_rom_size,
>                             PROT_READ | PROT_WRITE,
> 			    MAP_PRIVATE, zero_fd, 0);
> 
> 	So, how is this really any different to:
> 
> RAMBaseHost = (uint8 *)malloc(mapped_ram_rom_size);

Hm, at first glance I can't see the reason. It looks like gbeauchesne wrote
that part (rev. 1.19 vs. 1.20 of that file); maybe he knows. Perhaps it
simplifies some things by just having to munmap() the area when quitting
istead of either munmap() or free()?

Bye,
Christian

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

[B2-devel] B2 snapshot

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

Hi!

A new snapshot of the CVS is on the B2 site. I'm making binary packages for
the 0.9 release now, so if there are any urgent fixes, today and tomorrow
will be the last opportunity for getting them in.

Bye,
Christian

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

[B2-devel] Re: Memory mapping

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

I asked:
> What is this mmap() actually doing, apart from allocating memory?

Christian answered:
> It can allocate memory at a program-specified address
> (and optionally read- or write-protect the area).

	Sure. What I actually meant was, what is this mmap() doing:

RAMBaseHost = (uint8 *)mmap(0, mapped_ram_rom_size,
                            PROT_READ | PROT_WRITE,
			    MAP_PRIVATE, zero_fd, 0);

	From my reading of the manpage:

* The load address (0) is ignored because MAP_FIXED isn't set

* MAP_PRIVATE makes a copy of mapped_ram_rom_size bytes from
  zero_fd when the process first writes to the memory block



	So, how is this really any different to:

RAMBaseHost = (uint8 *)malloc(mapped_ram_rom_size);
memset(RAMBaseHost, mapped_ram_rom_size, sizeof(uint8));

	or

RAMBaseHost = (uint8 *)calloc(mapped_ram_rom_size, sizeof(uint8));

-- 
| 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] Re: New SIGSEGV code to be committed

[Brian J. J. <bjj...@us...>]

> I am about to commit updated SIGSEGV code that cleans up configure and

> may support more platforms (AIX, Irix, OSF/1). Christian, would you
> please check the code for NetBSD/m68k ?

The new code seems to work fine on IRIX, just like the old code did.

At least in 68030 mode.  Whenever I try to use 68030+FPU or 68040, I get
all kinds of nasty FP bugs, usually including wild references and core
dumps.  See bug 422776.  Is this a known problem with the UAE FPU core
on big endian or non-x68 systems?  I'm using MacOS 7.5.5.

(Although the new code does change the symptoms of the problem a bit:
now direct addressing core dumps (with an appropriate message from the
segv handler) and real mode hangs Speedometer.)

--

                                                Brian

--------------------------------------------------------------------

  "I use not only the brains I have, but all I can borrow."
                                           -- Woodrow Wilson

Re: [B2-devel] B2+DGA=OK

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

Hi!

On Sun, May 20, 2001 at 11:27:36PM +0200, Gwenole Beauchesne wrote:
> OK, in that case, that makes people realize how bad it could be to
> setuid root a program.

I don't think that it's really necessary to suid B2. I've set up my Linux
box to assign permissions for /dev/sheep_net and the MacOS partition to
the user logged in at the console and this works just fine.

Bye,
Christian

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

Re: [B2-devel] SheepShaver/Linux ?

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

Hi!

On Sun, May 20, 2001 at 11:27:35PM +0200, Gwenole Beauchesne wrote:
> Now that SheepShaver is freely available for BeOS/PPC, do you have any
> plans for the Linux (beta) version ?

I've been working on it quietly for some time. It no longer depends on
MacOS header files so it's closer to a releasable state now. There are
still some things that I want to clean up, though, such as throwing out
the ncurses video output module. :-)

> Does it require (runtime?) patches to the Linux kernel like Mac-On-Linux ?

No.

> BTW, I seem to remember a mail where Christian said that it may be
> possible to make MacOS run in real addressing mode.

Well, that's what B2 does on AmigaOS and NetBSD/m68k.

Bye,
Christian

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

Re: [B2-devel] Plan for 0.9 release ?

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

Hi!

On Sun, May 20, 2001 at 11:27:34PM +0200, Gwenole Beauchesne wrote:
> I thought B2 0.9 was to be released a few weeks ago. What needs to be
> done before such an event happens ?

You need to say "Go for it!".

> Was I supposed to fix some things=A0?

IIRC you said something about VOSF blitters and RGB masks that would have
to be fixed.

But if nobody has any objections, I will try to build B2 0.9 on all syste=
ms
I have access to. If that succeeds, it will be released.

> Providing an emulation of extended-precision FP would require too much
> work that probably doesn't worth the effort (speed-wise, usability). An=
y
> thoughts ?

I don't know whether the added precision is really needed but it might be
a desirable feature.

> Another problem arises then: is it possible to port powerrom_cpu to
> Linux/ppc ?

It sure is possible but powerrom_cpu doesn't enable the DR emulator yet.

Bye,
Christian

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

Re: [B2-devel] New SIGSEGV code to be committed

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

Hi!

On Sun, May 20, 2001 at 10:27:14PM +0200, Gwenole Beauchesne wrote:
> Christian, would you please check the code for NetBSD/m68k ?

Ok.

Bye,
Christian

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

Re: [B2-devel] Memory mapping

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

Hi!

On Tue, May 22, 2001 at 11:24:48AM +1000, ni...@in... wrote:
>    What is this mmap() actually doing, apart from allocating memory?

It can allocate memory at a program-specified address (and optionally
read- or write-protect the area).

Bye,
Christian

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

[B2-devel] Re: OS X port screen size

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

> [Running B2 under MacOS X]
> 
> Yes that's fine but I could not get a screen larger than 512x386.

	The screen size, unfortunately, is currently hard coded
(at the top of EmulatorView.m). It was done that way because the
window containing the Emulator is pre-drawn by the .nib file
(i.e. the NextStep Interface Builder data file).

	As soon as I work out how to resize a pre-instantiated
window to a particular size, I will send you a patch.


> I have not really looked at the code yet since my knowledge of
> Objective C tends to NULL.

	So was mine 7 months ago. (not that it is much greater yet)

-- 
| 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] Memory mapping

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

1) Mac OS X mmap() doesn't work.
   It always sets errno=ENOTSUP - Not Supported.
   I may be able to use a Mach primitive in the future,
   but for now, REAL_ADDRESSING is out of the question.

2) main_unix.cpp currently does this for DIRECT_ADDRESSING:

	// Create areas for Mac RAM and ROM
#if REAL_ADDRESSING || DIRECT_ADDRESSING
...
	{
		RAMBaseHost = (uint8 *)mmap(0, mapped_ram_rom_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, zero_fd, 0);
		if (RAMBaseHost == (uint8 *)MAP_FAILED) {
			ErrorAlert(GetString(STR_NO_MEM_ERR));
			QuitEmulator();
		}
		ROMBaseHost = RAMBaseHost + aligned_ram_size;
	}
#else
	RAMBaseHost = (uint8 *)malloc(RAMSize);
	ROMBaseHost = (uint8 *)malloc(0x100000);
	if (RAMBaseHost == NULL || ROMBaseHost == NULL) {
		ErrorAlert(GetString(STR_NO_MEM_ERR));
		QuitEmulator();
	}
#endif



   Now, because mmap() always fails, direct addressing also seems
   out of the question. But, my question is, why can't we just do
   a malloc() in this case?

   What is this mmap() actually doing, apart from allocating memory?

-- 
| 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] Re: Minor 0.9 patches, OS X source archive ready(?)

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

[Running B2 under MacOS X]

>       As a workaround, use a text editor to modify the fields in
> the newly created .basilisk_ii_prefs file in your home directory.
> That should get you going.

Yes that's fine but I could not get a screen larger than 512x386. I have
not really looked at the code yet since my knowledge of Objective C
tends to NULL.

Bye,
Gwenol=E9.

Re: [B2-devel] B2+DGA=OK

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

Hi,

> > Shouldn't we have two separate binaries: the prefs editor and the emulator
> > itself ?
> 
> I like self-contained programs better.

OK, in that case, that makes people realize how bad it could be to
setuid root a program. In the case of a Gtk+ application, that simply
won't work anymore.

Sorry, I was just too lazy to su root or recompile B2 without the Gtk+
prefs editor. ;-)

[B2-devel] SheepShaver/Linux ?

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

Hi,

Now that SheepShaver is freely available for BeOS/PPC, do you have any
plans for the Linux (beta) version ? Does it require (runtime?) patches
to the Linux kernel like Mac-On-Linux ?

BTW, I seem to remember a mail where Christian said that it may be
possible to make MacOS run in real addressing mode. I am really
wondering how since that would greatly simplify ppc emulation as far as
the address translation part of a MMU is concerned. Other parts (e.g.
memory protection) can still be achieved in an efficient way, imho.

Thanks.

[B2-devel] Plan for 0.9 release ?

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

Hi,

I thought B2 0.9 was to be released a few weeks ago. What needs to be
done before such an event happens ? Was I supposed to fix some things=A0?
Please refresh my mind.

I uploaded improved code for SIGSEGV handling into mainline. At that
time, I hadn't checked if B2 was branched or tagged, so I hope that I
didn't break too many things.

When could the following be inserted:
- MacOS X support
- runtime depth switching
- Improved FPU emulation

The latter is partially implemented in B2/JIT. It should now be possible
to port its FPE (sort-of IEEE-based) code to non-x86 platforms provided
that the target processor supports extended floating-point precision
(96/128-bit, IEEE 854?). I established this condition because that was
the only means I found to have working scrollbars in MacOS 8. Probably
scrollbars were not working properly in double-precision because of some
other bug ?

That brings the issue of target processors that can't do more than
double-precision (8 bytes, e.g. PPC). Providing an emulation of
extended-precision FP would require too much work that probably doesn't
worth the effort (speed-wise, usability). Any thoughts ?

At some point, I wanted to port the JIT compiler to PPC but Apple's one
is probably a better choice if we don't JIT compile FPU instructions.
Another problem arises then: is it possible to port powerrom_cpu to
Linux/ppc ?

Besides, I would like to play with Reversed Address Space again now that
direct addressing works fairly well and byte-swapping is probably now
the issue on little endian systems.

Bye,
Gwenol=E9.

[B2-devel] New SIGSEGV code to be committed

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

Hi,

I am about to commit updated SIGSEGV code that cleans up configure and
may support more platforms (AIX, Irix, OSF/1). Christian, would you
please check the code for NetBSD/m68k ?

BTW, I had hoped this code could bring Direct Addressing support to
FreeBSD. Unfortunately, that miserably fails. More precisely, if you
extract the test code from configure.in and compile it: it runs as
expected. If you run it within configure, it fails. I figured out that,
though I only catch SIGBUS signals, I get a signal code equals to
T_TRCTRAP (debug exception) instead. The supposed fault_address is
therefore wrong. Any idea ? I am running FreeBSD 4.1.

Bye,
Gwenol=E9.

Re: [B2-devel] MMU stuff

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

Hi!

On Thu, May 17, 2001 at 11:00:55AM +1000, ni...@in... wrote:
>    (MacPerl's LowMem.pm, and LowMem.h from Apple's Universal Headers)
>    and it seems that 0x0CB2 is the address. 0x0CB1 appears unused

0xcb2 is a flag that indicates whether the MMU is in 24-bit or 32-bit mode.
The "mmu " Gestalt in the 1MB Mac ROMs looks at 0xcb1.

>    case M68K-EMUL_OP_PATCH_BOOT_GLOBS;
>    ...
>         WriteMacInt8(r->a[4] -26, 0)			// No MMU
> 
>    to write 1 gives me mmu=1, but 2 gives 0,
>    and 3, 4 or 5 cause the Mac emulation to never boot.

This is actually the same flag as 0xcb1 (ROM system init sets the BootGlobs
flag and it gets later copied to 0xcb1), so 1=AMU, 2=reserved, 3=68851,
4=68030, etc. When this flag is <>0, the ROM/MacOS startup code will most
likely also access other information in the BootGlobs that isn't there
(MMU tables for 24/32 bit modes).

> > Maybe it's enough poke a value != 0 there after MacOS has started.
> 
> 	Poke? Looks like BASIC is gone, but not forgotten ;-)

C64 rulez! :-)

Bye,
Christian

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

[B2-devel] MMU stuff

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

I wrote:
> > [NetBSD/mac68k booter]
> > I am the maintainer of the program
> 
> Are you also the maintainer of the NetBSD/mac68k Installer?

	No. There hasn't really been a maintainer of it for years.
They are trying to move away from the installer, though, toward
a "sysinst" kernel based system.



> The byte at 0xcb1 holds the MMU type:
>   0: None
>   1: AMU
>   3: 68851
>   4: 68030
>   5: 68040
>   6: EMMU (PowerPC)

	Didn't work for me.

1) I just had a look at some documentation,
   (MacPerl's LowMem.pm, and LowMem.h from Apple's Universal Headers)
   and it seems that 0x0CB2 is the address. 0x0CB1 appears unused

2) Doing this:

   (* (unsigned char *) 0x0CB2) = 3;
   printf("mmu=%ld\n", GetGestalt(gestaltMMUType));

   in a MacOS program still outputs 0.

3) Fiddling around in emul_op.cpp, changing this line:

   case M68K-EMUL_OP_PATCH_BOOT_GLOBS;
   ...
        WriteMacInt8(r->a[4] -26, 0)			// No MMU

   to write 1 gives me mmu=1, but 2 gives 0,
   and 3, 4 or 5 cause the Mac emulation to never boot.
   (haven't investigated why)

4) I had a look at the InitMMU stuff in rom_patches.cpp,
   but there are too many uncommented magic numbers there
   for me to understand what it is doing!




> Maybe it's enough poke a value != 0 there after MacOS has started.

	Poke? Looks like BASIC is gone, but not forgotten ;-)


-- 
| 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] Re: basilisk-devel digest, Vol 1 #72 - 4 msgs

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

Hi!

On Wed, May 16, 2001 at 09:54:53AM +1000, ni...@in... wrote:
> [NetBSD/mac68k booter]
> I am the maintainer of the program

Are you also the maintainer of the NetBSD/mac68k Installer?

> 	Agreed. I just want to hack it in to my own copy of B2,
> for this one program I am testing.

The byte at 0xcb1 holds the MMU type:
  0: None
  1: AMU
  3: 68851
  4: 68030
  5: 68040
  6: EMMU (PowerPC)

Maybe it's enough poke a value != 0 there after MacOS has started.

Bye,
Christian

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

[B2-devel] Objective-C++

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

I wrote:
> Mac OS X's development classes come in either Objective-C or
> Java versions. There is no Objective C++ compiler yet.

Christian asked:
> What is Objective C++?

	Um, basically it is C++ with Objective C dynamic stuff added.
See http://www.schemaresearch.com/osx_objcplusplus


	The relevance to B2 is that, if I had an Objective-C++
compiler, I could code all the MacOS X stuff in C++ classes which
B2's code would be able to call directly, and vice-a-versa.

	As it is at the moment, I have "wrapper" functions and
'extern "C"' function prototype declarations.

-- 
| 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.' |