basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] MacOS 8.1/ppc boots ;-)

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

> is this on a PPC native machine or X86 machine?

Emulated PPC on PBG4 since {rom,rsrc}_patches.cpp are not little endian 
aware yet. That's next step. ;-)

[B2-devel] MacOS 8.1/ppc boots ;-)

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

Hi,

I have just nuked two silly bugs in the interpreter and MacOS 8.1 
completely boots. I can even make some tests on my PBG4:
<http://gwenole.beauchesne.free.fr/sheepshaver/> ;-)

Yes, that's slow as I enabled only the interpreter and all sort of 
runtime checks in order to know who the hell did nuke the stack 
pointer. That turned out to be the interrupt handler. It sometimes 
happened that we were just lwz r1,XLM_IRQ_NEST and triggered an 
interrupt, henceforth generating and saving sp - 64 => something like 
0xffffffc0.

The current solution is probably slow but I put back the usual spcflags 
checking and introduced two new NativeOp so that XLM_IRQ_NEST is handed 
atomically, at least as seen in emulated ppc world.

Concerning MacOS 8.6, it now tells me a system error occured. 
Unfortunately, it does not crash thus making more difficult to track 
down why we got there.

Oh BTW, MacOS 8.1 is silly and tries to lmw on unaligned EA. This also 
happens in native mode. So, I don't know if MacOS 8.1 is the real 
problem or it is something introduced from SheepShaver.

Bye,
Gwenole.

Re: [B2-devel] SheepShaver updates

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

Hi,

> - There is now a new PowerPC emulator checked in. This is from a toy 
> experiment from a few months ago. With the emulator SheepShaver 
> crashes just before MacOS 8.6 loads up extensions. I don't know yet 
> whether it's due to a bug in the core or the glue to SheepShaver. If 
> someone is willing to proofread the core, he is welcome. ;-) Last time 
> I read it, I spotted out only 1 or 2 bugs and the test Linux/ppc 
> programs I have handy still work fine. So, it could just be a pb in 
> the SheepShaver glue code.

I have fixed a couple more bugs. The current tests cover more than 10K+ 
instructions over specific values to trigger various CR/XER flags 
updates [*]. All tests now perform correctly against a real ppc 7410 
(PB G4). However, things are still not working correctly in SheepShaver 
side. I guess I messed the glue again. :-(

[*] Sorry but you will have to be very patient during compilation, if 
you intend to enable them all at once.

Bye,
Gwenole.

Re: [B2-devel] SheepShaver updates

[Christian B. <Chr...@un...>]

Hi!

On Sun, Sep 07, 2003 at 06:50:01PM +0200, Gwenole Beauchesne wrote:
> Note: this will compile on x86 [...]

Uhm, not quite: :-)

g++ -I../kpx_cpu/include -I../kpx_cpu/src -I../include -I. -DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g -O2 -I../../../mon/src -I../../../mon/src/disass  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include  -c ../kpx_cpu/sheepshaver_glue.cpp -o obj/sheepshaver_glue.o
../kpx_cpu/sheepshaver_glue.cpp: In function `void sigsegv_handler(int, siginfo_t*, void*)':
../kpx_cpu/sheepshaver_glue.cpp:455: `struct mcontext_t' has no member named `regs'
make: *** [obj/sheepshaver_glue.o] Error 1

(this is on Red Hat 9)

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] SheepShaver updates

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

On Sun, 7 Sep 2003, Gwenole Beauchesne wrote:

> Concerning cache invalidation, this is simply not handled yet. The plan 
> is to mark pages read-only on icbi instructions, then write to those 
> will actually clear caches (predecode cache, native code cache). Due to 
> the way cache invalidation works on ppc  (icbi/isync/etc.), this is the 
> best idea I came up with. Feel free to suggest others.

Grpmf, this cannot work, new instructions are already written by the time 
icbi occurs. ;-) Better record address ranges from icbi, and actually 
invalidate on isync instructions.

[B2-devel] SheepShaver updates

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

Hi,

I have just committed changes from my old local tree to CVS:
- For better MacOS 8.6 support, you may have to turn on fake 
SCSIGlobals in rom_patches.cpp. I reckon this is a workaround.
- There is now a new PowerPC emulator checked in. This is from a toy 
experiment from a few months ago. With the emulator SheepShaver crashes 
just before MacOS 8.6 loads up extensions. I don't know yet whether 
it's due to a bug in the core or the glue to SheepShaver. If someone is 
willing to proofread the core, he is welcome. ;-) Last time I read it, 
I spotted out only 1 or 2 bugs and the test Linux/ppc programs I have 
handy still work fine. So, it could just be a pb in the SheepShaver 
glue code.

The ppc emulator is not sophisticated yet and features only a basic 
predecode phase. This is to evolve but I first wanted to fully boot 
into MacOS. Slow down factor is still around 25 vs. native code on 
average, as measured on my PB G4 @ 400 MHz.

Concerning cache invalidation, this is simply not handled yet. The plan 
is to mark pages read-only on icbi instructions, then write to those 
will actually clear caches (predecode cache, native code cache). Due to 
the way cache invalidation works on ppc  (icbi/isync/etc.), this is the 
best idea I came up with. Feel free to suggest others.

Note: this will compile on x86 but won't work until little endian fixes 
are checked in too. ;-)

Bye,
Gwenole.

Re: [B2-devel] AC_HEADER_STDC not exactly broken

[>> G-L. / <st...@wi...>]

Michael Sliczniak wrote:

> Stephan,

St=E9phan ;)

> Are you using the latest configure.ac from cvs?=20


> The newer configure.ac in cvs have 'AC_EGREP_CPP(xyes,' and that fixed =

> a bug where the utility yes was called in previous versions. You might =

> experiment with the version of the configure.ac from the Darwin real=20
> mode patch I sent out to the list a few weeks back. There I have this=20
> quoted properly. For me the AC_EGREP_CPP and AC_HEADER_STDC tests both =

> succeed with that version on both Darwin and FreeBSD. It is entirely=20
> possible that because the AC_HEADER_STDC test does not succeed other=20
> things break and __daddr_t_defined should have been defined or some=20
> such on your system.

I just updated my cvs snapshot and it fixed the problems. My previous=20
version wasn't _that_ old though... Maybe just a tad too old, I guess

> BTW, the mailing list archive on sf seems to have stopped archiving in =

> early July. Does anybody know what is up with that?
>
> mzs

There's been alot of oddities going on at sf. I stopped bothering a=20
couple of months ago.
It is weird though, you should be glad the cvs isn't located at sf. ;)

--=20
> > G-LiTe /
<st...@wi...>
--

Re: [B2-devel] AC_HEADER_STDC not exactly broken

[Michael S. <msl...@co...>]

Stephan,

Are you using the latest configure.ac from cvs?

On Thursday, August 21, 2003, at 05:25 AM, >> G-LiTe / wrote:

> What _does_ seem to be broken here is the two calls for AC_EGREP_CPP 
> to detect which gcc version is installed.

The newer configure.ac in cvs have 'AC_EGREP_CPP(xyes,' and that fixed 
a bug where the utility yes was called in previous versions. You might 
experiment with the version of the configure.ac from the Darwin real 
mode patch I sent out to the list a few weeks back. There I have this 
quoted properly. For me the AC_EGREP_CPP and AC_HEADER_STDC tests both 
succeed with that version on both Darwin and FreeBSD. It is entirely 
possible that because the AC_HEADER_STDC test does not succeed other 
things break and __daddr_t_defined should have been defined or some 
such on your system.

> In file included from sysdeps.h:36,
>                 from ../main.cpp:21:
> /usr/include/sys/types.h:117: syntax error before `;' token
>
> Which comes down to this piece of code in types.h:
>
> #ifdef  __USE_BSD
> # ifndef __daddr_t_defined
> typedef __daddr_t daddr_t;
> typedef __caddr_t caddr_t;   // <- 117
> #  define __daddr_t_defined
> # endif
> #endif
>

Maybe you should run this particular test manually with the -E option 
and see what the preprocessor generates.

BTW, the mailing list archive on sf seems to have stopped archiving in 
early July. Does anybody know what is up with that?

mzs

Re: [B2-devel] AC_HEADER_STDC not exactly broken

[>> G-L. / <st...@wi...>]

What _does_ seem to be broken here is the two calls for AC_EGREP_CPP to 
detect which gcc version is installed.
The defines in the test and everything are okay, yet both tests fail and 
return no. (Possibly also the reason why STDC_HEADERS isn't defined? It 
won't compile unless I set that manually in config.h)
Then there's a second error while compiling:

In file included from sysdeps.h:36,
                 from ../main.cpp:21:
/usr/include/sys/types.h:117: syntax error before `;' token

Which comes down to this piece of code in types.h:

#ifdef  __USE_BSD
# ifndef __daddr_t_defined
typedef __daddr_t daddr_t;
typedef __caddr_t caddr_t;   // <- 117
#  define __daddr_t_defined
# endif
#endif

I don't see anything really wrong in the code unless caddr_t is already 
defined. I was wondering if this could be another configure problem 
though, if one of the #ifdef's should actually be failing there?
Autoconf 2.57, automake 1.7.5, m4 1.4, glibc 2.3.2, gcc 3.2.3, Gentoo 
linux 1.4.3.10.

Michael Sliczniak wrote:

> Hi all,
>
> Regarding the cvs commit with the following log message:
>
> Check for readline headers in the headers check section as otherwise, and
> I don't exactly know why, AC_HEADER_STDC would fail with newer autoconf
> versions.
>
> In the patch I send for Darwin real mode I moved the check earlier in 
> the configure.ac file. This corrected the problem. This is a good idea 
> anyway since other autoconf built-in tests  use the results of 
> AC_HEADER_STDC so it is a good idea to be sure to do that early on 
> before other things that compile or run the preprocessor as part of 
> the test.
>
> mzs
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Dice.com.
> Did you know that Dice has over 25,000 tech jobs available today? From
> careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
> best hiring companies. http://www.dice.com/index.epl?rel_code=104
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

-- 
> > G-LiTe /
<st...@wi...>
--

[B2-devel] AC_HEADER_STDC not exactly broken

[Michael S. <msl...@co...>]

Hi all,

Regarding the cvs commit with the following log message:

Check for readline headers in the headers check section as otherwise, 
and
I don't exactly know why, AC_HEADER_STDC would fail with newer autoconf
versions.

In the patch I send for Darwin real mode I moved the check earlier in 
the configure.ac file. This corrected the problem. This is a good idea 
anyway since other autoconf built-in tests  use the results of 
AC_HEADER_STDC so it is a good idea to be sure to do that early on 
before other things that compile or run the preprocessor as part of the 
test.

mzs

[B2-devel] Re: Darwin real mode

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

	Fabulous work, Mike. I have not compiled or tested any of this yet,
but it looks like you have been very thorough.

> On my home machine Nigel's Aqua version takes 24s to startup while 
> this X
> version takes only 9s.

	Cool!

> I will work on getting that patch together next week but as it
> is that the Aqua version does not build out of cvs without some small
> tweaks, maybe Nigel has some patches that he might want to send out 
> first.

	I haven't had time to scratch myself lately, so just make whatever
changes you think are necessary. We can work out any conflicts later :-)

--
| Nigel Pearson, ni...@in...   | "Now the world has gone to 
bed,
| Telstra BI&D, Sydney, Australia         |  Darkness won't engulf my 
head,
|   Office: 8255 4222    Fax:  8255 3153  |  I can see by infrared,
|   Mobile: 0408 664435  Home: 9792 6998  |  How I hate the night." 
-Marvin

[B2-devel] PATCH: Darwin real mode

[Mike S. <msl...@co...>]

Hi All,

The patch for Darwin real mode under X is ready and attached. Please
expand and untar the file under your BasiliskII directory. Then run
the included patchall.sh script.

I have verified that direct and bacnks modes work as well. To build
with real addressing mode use:

./autogen.sh --enable-addressing=real

There is one potential serious bug I found along the way but I am not
confident enough to say so. In posix_sem.cpp there is line that contains:

nanosleep(NULL, &req);

But nanosleep takes as its first parameter how long to sleep and as its
second it fills in how much time remained for the sleep. This will make
the while loop very rapidly, but maybe that was the intention? I beleive
that the the code should in fact be:

nanosleep(&req, NULL);

but I left it the old way and added a stupid comment until I hear from
someone with a more definitive answer.

There are some new files:

? src/Unix/bless.sh
? src/Unix/Darwin
? src/Unix/Darwin/lowmem.c
? src/Unix/Darwin/pagezero.c
? src/Unix/Darwin/sys_darwin.cpp
? src/Unix/Darwin/testlmem.sh
? src/Unix/posix_sem.h

You will notice a new directory src/Unix/Darwin. This is where all of the
Darwin under X specific stuff goes.

bless.sh and Darwin/testlmem.sh have to have execute bits set. bless.sh 
is
a simple shell script that returns success. It is needed because there 
is a
new step in the build process that I call blessing the executable. In the
case of Darwin it allows for Basilisk access to low memory globals. In 
all
other systems this bless.sh script is called which does nothing. The
rule creates a file named blessed if it succeeds and this is how make 
knows
whether that step has been performed. Darwin/testlmem.sh is a test that 
is
run from configure that checks to see if the Mach-O hack to enable low 
mem
globals works.

posix_sem.h used to be named semaphore.h but for whatever reason my setup
on FreeBSD the preprocessor would keep including this semaphore.h 
instead of
the one in /usr/include even when I used the <> form instead of the "" 
form.
I made some changes to semaphore.h so that it picks the correct 
semaphore.h
from the system includes and works around systems like Darwin when there 
is
a sem_init but it is unimplemented. Then I renamed it to posix_sem.h to 
match
the posix_sem.cpp. All the UNIX code that needs semaphores simply 
includes
posix_sem.h and this does the right stuff based on the configure test 
results.

The other files that changed were:

M src/Unix/Makefile.in
M src/Unix/acinclude.m4
M src/Unix/audio_oss_esd.cpp
M src/Unix/configure.ac
M src/Unix/ether_unix.cpp
M src/Unix/main_unix.cpp
M src/Unix/posix_sem.cpp
M src/Unix/serial_unix.cpp
M src/Unix/sigsegv.cpp
M src/Unix/sigsegv.h
M src/Unix/sys_unix.cpp
M src/Unix/video_vosf.h
M src/Unix/vm_alloc.h
M src/Unix/Irix/audio_irix.cpp
M src/Unix/Solaris/audio_solaris.cpp

I rolled the Mach exception handling mechanisms into sigsegv.cpp and 
this is
the major reason this patch took me a whle to prepare. This way the Mach 
code
is less likely to break over time. People might verify that I have not 
broken
any of the sigsegv code on their favorite systems. I was pretty careful 
about
the changes and I verified that it still works on FreeBSD.

In traditional Mach you do not get the GPR's and faulting PC on the 
exception.
It takes more work to get this info but it is not needed for the VOSF 
code. I
changed the VOSF handler to take the faulting address as it sole 
parameter.
This makes the common case, VOSF handling, faster under Mach.

ignoresegv also works under Darwin.

At one point I noticed that if you had seriala or serialb in your
.basilisk_ii_prefs file the emulator would hang. Nigel's Aqua version of 
the
emulator puts that into the file. If that happens, just remove those 
entries
and it should run again. It seems that the emulator would try to do 
serial
even if the device files specified did not exist. I do not know if that 
is
still a problem.

On my home machine Nigel's Aqua version takes 24s to startup while this X
version takes only 9s. It is pretty straight forward to make changes to
the the Aqua version to enable real mode. I had it for an earlier version
without the VOSF support. There was a roughly two fold improvement in
performance. I will work on getting that patch together next week but as 
it
is that the Aqua version does not build out of cvs without some small 
tweaks,
maybe Nigel has some patches that he might want to send out first.

Also, Brian independantly discovered the same EGREP configure script 
problem
I fixed as well. It really is a quoting problem, the yes should have been
[yes], but I have used the test that autoconf itself uses of [choke me] 
instead
of the recent commit with xyes which is not quoted correctly.

mzs

[B2-devel] PATCH: new file lowmem.c

[Michael S. <msl...@co...>]

Hi all,

I have b2 running in real addressing mode with video on segv under X in 
Darwin. The changes are not trivial so I will send them out in parts 
with explanation to make feed back easier. There are two main additions 
conceptually.

A mechanism to enable mapping the low memory globals:
I wrote a utility to modify the __PAGEZERO segment of the executable to 
allow this.

A mechanism to enable faulting on video buffer accesses:
I added code to use the extended mach exception present in Darwin.

Also there were other changes that I added along the way, mainly to 
support both X/Aqua builds to work.

I am still writing the necessary autoconf tests and reviewing some of 
the changes.

I have attached lowmem.c which is the source to the utility which 
enables low memory global access. It is intended for it to live in 
src/Unix/Darwin and it will be built and used during the 
configure/build process.

As a note, the Aqua port under src/MacOSX updates the entire view each 
time it is updated. Some more changes than what I have ready would need 
to be added to get that to work with VOSF so that only the areas in 
need of updating are actually redrawn. (I am referring to 
setNeedsDisplay in Emulator.mm, this needs to be changed to 
setNeedsDisplayInRect with code analogous to that in the UNIX version 
that determines which areas are in need up updating.)

mzs

Re: [B2-devel] Oops, fixed patch

[Michael S. <msl...@co...>]

Brian I had the same problem with ESD and GTK, not installed on my 
system. Here is the fix:

% cat `aclocal --print-ac-dir`/basiliskii.m4
AC_DEFUN(AM_PATH_GTK, $3)
AC_DEFUN(AM_PATH_ESD, $3)

This makes these tests return the failure argument  in autoconf.
Thanks for the yes fix.

On Thursday, July 17, 2003, at 12:48 PM, Brian Johnson wrote:

> Sorry, I forgot to remove the ESD hack from the previous patch I sent
> out.  Fixed patch attached.
>
> 						Brian J. Johnson
>
> --------------------------------------------------------------------
>
>   "He who will not reason is a bigot; he who cannot is a fool;
>    and he who dares not is a slave."
>                                            -- Sir William 
> Drummond<diffs>

[B2-devel] Oops, fixed patch

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

Sorry, I forgot to remove the ESD hack from the previous patch I sent
out.  Fixed patch attached.

						Brian J. Johnson

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

  "He who will not reason is a bigot; he who cannot is a fool;
   and he who dares not is a slave."
                                           -- Sir William Drummond

[B2-devel] PATCH: configure.ac tweak

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

Folks,

Here's a small tweak to the configure.ac file.  Without this fix, the
configure script tries to execute "yes" as a command when testing for
GCC, which hangs waiting for the "yes" command's never-ending stream
of "y\n"'s to complete.

With this fix (and an unreleated configure.ac tweak to disable probing
for ESD, which is broken in my autoconf setup) CVS BasiliskII compiles
and runs out-of-the-box on IRIX 6.5.21, using prerelease MIPSPro 7.4.1
compilers.  This is a first for BasiliskII:  it's always needed some
small patches in the past to deal with IRIX's broken header files.

Congratulations on writing a portable emulator!

						Brian J. Johnson

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

   "IP over ATM?  You mean I can read my email from a cash machine?"
                                           -- David Barr

[B2-devel] PATCH: audio format switching for IRIX

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

Here's a patch which adds audio format switching to the IRIX audio
driver.  I also reorganized things a bit to more closely match the
OSS/ESD driver.  Could someone please apply it?  Thanks.

It seems to work fine, except for 8-bit mono mode.  I use the same
conversion algorithm as audio_amiga.cpp (and experimented with several
others), but the sound comes out highly distorted, and pretty much
unrecognizable.  Can anyone point me at a description of the Mac's
sample buffer layout when this mode is in use?

FYI to anyone building this on IRIX:  the released MIPSPro 7.4
compilers have some really nasty bugs with C++ code optimization, and
can't build a working BasiliskII with any optimization turned on.
(And the emulator performance suffers terribly, of course, without
optimization.)  This will be fixed in the 7.4.1 release.

Thanks for a great emulator,

						Brian

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

  "My software never has bugs.  It just develops random features."
                                           -- Quoted by Khan Tran

Re: [B2-devel] SheepShaver: new cpu core

[Christian B. <Chr...@un...>]

Hi!

On Mon, Jun 02, 2003 at 12:08:56PM +0200, Gwenole Beauchesne wrote:
> If someone is willing to proofread the core (simple but boring), you are
> welcome. ;-)

Unfortunately, I'm a little pressed for time at the moment, but it's nice
to know that somebody is still working on PPC emulation. :-)

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] src/Unix/main_unix.cpp: compilation fix

[Todd V. <tv...@po...>]

This fixes compilation in the no-threads case for an emulated 68k, where
SIG_IRQ is neither defined nor used.

Index: main_unix.cpp
===================================================================
RCS file: /cvs/BasiliskII/src/Unix/main_unix.cpp,v
retrieving revision 1.52
diff -u -r1.52 main_unix.cpp
--- main_unix.cpp	14 May 2003 06:50:05 -0000	1.52
+++ main_unix.cpp	16 Jun 2003 17:59:43 -0000
@@ -615,7 +615,9 @@

 	// Start 60Hz timer
 	sigemptyset(&timer_sa.sa_mask);		// Block virtual 68k interrupts during SIGARLM handling
+#if !EMULATED_68K
 	sigaddset(&timer_sa.sa_mask, SIG_IRQ);
+#endif
 	timer_sa.sa_handler = one_tick;
 	timer_sa.sa_flags = SA_ONSTACK | SA_RESTART;
 	if (sigaction(SIGALRM, &timer_sa, NULL) < 0) {

-- 
-- Todd Vierling <tv...@po...>

[B2-devel] SheepShaver: new cpu core

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

Hi,

I finally wrote a new PPC emulation core (kpx_cpu) last week. It's derived
from Microlib's, Christian's, psim altogether. ;-)

<http://gwenole.beauchesne.free.fr/kheperix/>

Only interpretive emulation is available now. It's 15% faster than 
microlib's (in real addressing mode too). It's even more accurate insofar 
as I can now complete the N-queens test from ssbench.

TODO:

- Fix FPU emulation bugs on x86.

- Integrate into SheepShaver. Right now, testing is done with
Linux/ppc/dietlibc binaries, namely some ssbench benchmarks.

- Implement a predecode/predecode+refine cache. The framework for the 
refine trick is already in place and it would be enough to instantiate 
more templates. This is important before implementing a JIT specific to 
some architectures.

If someone is willing to proofread the core (simple but boring), you are
welcome. ;-)

Bye,
Gwenole.

[B2-devel] down is up

[Christian B. <Chr...@un...>]

Hi!

down.physik.uni-mainz.de (our CVS) is now reachable again. I will remove the
'gromit' alias sometime within the next few weeks.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] SheepShaver: uncertain fixes

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

Hi,

The following set of workarounds enables me to run MacOS 8.6 correctly 
under SheepShaver. In order of appearance:

- When patching the Shutdown Manager to not call FE0A opcode, it can 
happen that the bra is not intended here. Indeed, on a NewWorld ROM 
v1.6, there is a bsr.l to the matched pattern at wp[-2]. For now, I 
added a check for a beq instruction before patching.

- There is a fake SCSI Manager installed. However, for some reason, 
MacOS insists in injecting some code that makes it access SCSIGlobals 
natively (with ppc code). I have various traces for volunteers but I 
gave up for now with this workaround: make SCSIGlobals point to some 
read-only scratch area.

- Someone is overwriting scratch area at 0x0000. Since we don't have 
SonyVars, it's a good idea to revert to the old value there, i.e. 
0x40810000. This is not the proper fix but I failed to analyze this 
problem better. Only thing I remember is that there is no .Sony driver 
to replace in this newworld rom.

- Restart/Shutdown would always crash for me. I still don't know how we 
come under such circumstances but it appears that patching the Process 
Manager (I think that's it according to some webpages) that way makes 
it work for me.

Any thoughts?

Bye,
Gwenole.

Index: src/rom_patches.cpp
===================================================================
RCS file: /cvs/SheepShaver/src/rom_patches.cpp,v
retrieving revision 1.4
diff -u -b -r1.4 rom_patches.cpp
--- src/rom_patches.cpp	17 May 2003 08:42:34 -0000	1.4
+++ src/rom_patches.cpp	20 May 2003 20:31:28 -0000
@@ -2013,7 +2013,7 @@
  	wp = (uint16 *)(ROM_BASE + base);
  	if (ROMType == ROMTYPE_ZANZIBAR)
  		*wp = htons(M68K_RTS);
-	else
+	else if (ntohs(wp[-2] == 0x6700))
  		wp[-2] = htons(0x6000);	// bra

  	// Patch PowerOff()
@@ -2134,6 +2134,12 @@
  	D(bug("Installing drivers...\n"));
  	M68kRegisters r;
  	uint8 pb[SIZEOF_IOParam];
+
+#if DISABLE_SCSI
+	// Fake SCSIGlobals
+	static const uint8 fake_scsi_globals[32] = {0,};
+	WriteMacInt32(0xc0c, (uint32)fake_scsi_globals);
+#endif

  	// Open .Sony driver
  	WriteMacInt8((uint32)pb + ioPermssn, 0);
Index: src/rsrc_patches.cpp
===================================================================
RCS file: /cvs/SheepShaver/src/rsrc_patches.cpp,v
retrieving revision 1.2
diff -u -b -r1.2 rsrc_patches.cpp
--- src/rsrc_patches.cpp	12 Apr 2003 10:14:07 -0000	1.2
+++ src/rsrc_patches.cpp	20 May 2003 20:31:29 -0000
@@ -319,6 +319,14 @@
  				// Don't call FE0A opcode (7.6, 7.6.1, 8.0, 8.1, 8.5, 8.6)
  				p[1] = 0x7000;
  				D(bug(" patch 3 applied\n"));
+			} else if (p[0] == 0x6c00 && p[1] == 0x016a && p[2] == 0x2278 && 
p[3] == 0x0134) {
+				// We don't have SonyVars (8.6)
+				p[-4] = 0x21fc;	// move.l $40810000,($0000)
+				p[-3] = 0x4081;
+				p[-2] = 0x0000;
+				p[-1] = 0x0000;
+				p[0] = 0x6000;
+				D(bug(" patch 4 applied\n"));
  			}
  			p++;
  		}
@@ -479,6 +487,19 @@
  				break;
  			}
  			p++;
+		}
+
+	} else if (type == FOURCC('s','c','o','d') && id == -16465) {
+		D(bug("scod -16465 found\n"));
+
+		// Don't crash in Process Manager on reset/shutdown (8.6)
+		static const uint8 dat[] = {0x4e, 0x56, 0x00, 0x00, 0x48, 0xe7, 
0x03, 0x18, 0x2c, 0x2e, 0x00, 0x10};
+		base = find_rsrc_data((uint8 *)p, size, dat, sizeof(dat));
+		if (base) {
+			p16 = (uint16 *)((uint32)p + base);
+			p16[0] = 0x7000;	// moveq #0,d0
+			p16[1] = M68K_RTS;
+			D(bug(" patch 1 applied\n"));
  		}
  	}
  }

[B2-devel] Windows Port Build 142 Missing vc5opti.cpp

[Jim W. <ma...@em...>]

Hello everyone,

I had to download the source to build 141 from Simon's website to get
vc5opti.cpp.

http://www.pona.net/basilisk/lpesonen.htm

Also wanted to note that building "Basilisk II Windows port: assembler
optimized version" results in various errors of which I've been unable
to resolve completely due to lack of programming knowledge. I am using
MASM 6.15 and VC++ 6 SP5 on Windows 2000 Pro SP3. I problem I can't get
past right now is the nested macro:

cmovdef MACRO opname, ccode
  opname MACRO dst, src
    local x, y
    x:
    bsf dst, src
    y:
    nop
    org x+1
    db 40h + ccode
    org y
  ENDM
ENDM

Which results mainly in the three errors:

.\asm\opdefs.inc(23) : error A2008: syntax error : macro
 cmovdef(1): Macro Called From
  .\asm\opdefs.inc(23): Include File
.\asm\opdefs.inc(23) : error A2012: PROC, MACRO, or macro repeat
directive must precede LOCAL
 cmovdef(2): Macro Called From
  .\asm\opdefs.inc(23): Include File
.\asm\opdefs.inc(23) : error A2034: must be in segment block

And while following the directions for "Building Basilisk II Windows
port, old version", build68k is not creating the source files, instead
choking with the following command prompt output:

#include "sysdeps.h"
#include "readcpu.h"
struct instr_def defs68k[] = {

I guess I need to spend more time investigating, but thought I'd pass
along this info.

Thank you for your time.

Jim Watters

[B2-devel] Re: New version?

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

> I'm following this list for quite a while (although not many emails
> here ;) and I was beginning to wonder - how about creating a new
> version with the current CVS version?

I'm getting close to finishing the sound driver for IRIX (although I
probably won't have any time to work on it for the next two weeks),
and would like to get those changes into the next "official" B2
release.  Once the release is out, I'd be happy to package it up for
IRIX and get it into the SGI Freeware CDs.

						Brian J. Johnson

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

   "Scientists don't solve mysteries, they only rename them."
                                           -- Unknown (to me at least)

[B2-devel] SheepShaver FE0A and F1CE replacements

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

Hi,

While debugging failure to boot my MacOS 8.6 CD, I realized with the 
emulator that code generated for FE0A and F1CE opcodes replacements did 
not really match the comments. ;-) Fixed in CVS but could you please 
check what you intended to do with those still works?

I also have a workaround to complete the boot but I won't commit that 
since it's not really a fix. Indeed, the hack is simply to add a new 
patch to gpch 750 so that contents at 0x000 is written back with 
0x40810000. MacOS is writing to there through SonyVars, which we don't 
have. I really don't know what's going on there so I will have a closer 
look later.

Bye,
Gwenole.