basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] AmigaOS: changes committed

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

Hi!

On Sun, Oct 14, 2001 at 08:09:47PM +0200, J=FCrgen Lachmann wrote:
> I just committed some changes to the AmigaOS port.
> Video depth/resolution switching should now work.=20

Thanks! :-)

> This is tested with Window output and CyberCFX screen output. Since I
> haven't Picasso96 installed here, I couldn't test that setup here.

I will try it under P96 at home.

> Another small change (asm_support.asm) enables interrupts at the beginn=
ing
> of system traps.

This doesn't look correct to me. The supervisor bit shouldn't be cleared,
neither should there be any reason to explicitly enable interrupts.

> This fixes a sound problem with MacOS 8.1 - in audio.cpp, the "AddSourc=
e"
> call to the Apple Mixer always returned error -624 and sound output did=
n't
> work at all.

-624 is interruptsMaskedErr which seems to only happen on LockMemory() or
LockMemoryContiguous(). Still I think that the problem is somewhere else.

Bye,
Christian

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

[B2-devel] AmigaOS: changes committed

[L. <jue...@t-...>]

Hi,

I just committed some changes to the AmigaOS port.

Video depth/resolution switching should now work. 
This is tested with Window output and CyberCFX screen output. Since I haven't Picasso96 installed here, I couldn't test that setup here.

The inherent limitations for the video modes are not yet fully enforcerd.


Another small change (asm_support.asm) enables interrupts at the beginning of system traps. 
This fixes a sound problem with MacOS 8.1 - in audio.cpp, the "AddSource" call to the Apple Mixer always returned error -624 and sound output didn't work at all.
This fix might not be a final solution.


Regards,
Jürgen
-- 
Jürgen Lachmann jue...@t-... Blaubeuren Germany

[B2-devel] Re: OS X

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

--- Max Horn <ma...@qu...> wrote:
> At 10:46 Uhr +1000 12.10.2001, ni...@in... wrote:
> >...
> >>  BTW, Nigel, how is speed for you? On my G4/400, running Sys
> >>  7.5.3 in the emu, I can literally see it do redraws etc.
> >
> >	Same speed deficiencies. I haven't worked out if it is the
> >graphics environment (e.g. the barber pole, and having to have the
> >MacOS blit from an NSBitmap), or the emulation on a RISC
> >processor. I do remember that it was also quite slow on my Sun
> >Sparcstation 5 at work.
>
> Don't forget that you also have double buffering on from the MacOS,
> which in our case doesn't really help - turning on retained mode for
> the window might help.

A few general BasiliskII things to try:
- Get direct addressing working, if it isn't alreay.  It takes a _lot_
  of gunk out of the emulated memory reference path, and will improve
  performance dramatically.
- Get VOSF (video on seg fault) working, if it isn't already.  This
  lets you be _much_ smarter about blitting:  instead of redrawing the
  entire emulated frame buffer, you only need to redraw the parts
  which have been written since the last update.  If MacOS X's mmap()
  and signal handlers aren't up to the task, I'm sure you could do it
  with a Mach external pager.  That's exactly the sort of trick
  external pagers are good at (if I remember all those Mach papers I
  had to read in school.)
- Make sure that CPU_CAN_ACCESS_UNALIGNED ends up defined when you
  compile (PPC can do unaligned memory refs., can't it?  See
  Unix/sysdeps.h.)  That greatly simplifies the emulated memory
  reference path.
- Check out the optimized video blitter loops from video_blit.{cpp,h}
  in the CVS version.  If your blit is more than a simple bcopy, they
  should help somewhat.

On my SGI Octane with dual 195 MHz R10000 CPUs, BII with X11 (XShm
transport), direct addressing, VOSF, and MIPS-optimized unaligned
reference code is about as fast as a real IIci.  Not stellar, but very
usable, even for old games.  SGI's compilers are probably better than
GCC, but a 400MHz G4 has a lot more raw horsepower than my box... you
should be able to get BII running well.

> >
> >	It is fast enough to be usable in a pinch, though.
>
> Well if you compare it to the same version of Basilisk (latest
> release snapshot) but compiled with an X11 front end, it is quite a
> bit slower - this tells me we have a lot to improve :)

If there's some way you can map the frame buffer directly, rather than
going through the OS, that would give you the best performance.  Since
you're on a real Mac, you probably wouldn't have trouble with the
frame buffer layout (waving my hands wildly at this point....)

You might also want to try and write an OpenGL front end.  On SGI
boxes at least, OpenGL is the most optimized path to the frame buffer.
(And then I could steal it and use it on IRIX....)

						Brian J. Johnson

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

   "There is the greatest practical benefit in making a few failures
    early in life."
                                           -- Thomas Henry Huxley

[B2-devel] Re: OS X -

[Max H. <ma...@qu...>]

At 10:46 Uhr +1000 12.10.2001, ni...@in... wrote:
>...
>>  What I would like to suggest is that we add a singleton
>>  EmulatorManager class that keeps track of the Emulator object (and in
>>  future versions, manages multiple). This would be a singleton class,
>>  similiar to NSApplication, i.e. you could call [EmulatorManager
>>  sharedEmulatorManager] to get the single instance.
>>
>>  This would then have some useful methods, like IsAnyEmulatorRunning
>>  (i.e. active and not paused) or something alike.
>>  Furthermore, it then would have a method to check if the emulator in
>>  the current key window is running (and not paused), and if that is
>>  true, then we don't intercept key events.
>
>	This would be an ideal situation. Even better would be
>if this class could check if the pointer is in the EmulatorView,
>and not send any events to it if it is not.
>
>	As an interim, how about we just pass all key events to
>the Emulator class, and ignore any OS defaults.

That would be bad. E.g. the small window widgets (close/mini/zoom) 
would not be highlighted, no buttons would work and no menu shortcuts.

Your really have to decide what events you want to handle yourself, 
and the rest you one should feedback into the regular handling.


>  That way, there
>is no need to check if an emulator is running. From memory, the
>EmulatorView will do the right thing (ignore) when it gets an
>event, and its emulator is not running. If not, should be simple
>to add.

See above :) That is the reason why I right now have only the key 
events intercepted, that doesn't hurt me much.

How about this: we add a method to Emulator (or some other class) like

- (BOOL)tryHandleEvent:(NSEvent *)event;

Then, our Applicaton class would have this code:

- (void)sendEvent:(NSEvent *)event
{
	if (![emulator tryHandleEvent:event])
		[super sendEvent:event])
}

I.e. this way the decision logic would be inside of the Emulator 
object... or the EmulatorManager or where we put it.



>
>...
>>  BTW, Nigel, how is speed for you? On my G4/400, running Sys 7.5.3 in
>>  the emu, I can literally see it do redraws etc.
>
>	Same speed deficiencies. I haven't worked out if it is
>the graphics environment (e.g. the barber pole, and having to
>have the MacOS blit from an NSBitmap), or the emulation on a
>RISC processor. I do remember that it was also quite slow on
>my Sun Sparcstation 5 at work.

Don't forget that you also have double buffering on from the MacOS, 
which in our case doesn't really help - turning on retained mode for 
the window might help.

>
>	It is fast enough to be usable in a pinch, though.

Well if you compare it to the same version of Basilisk (latest 
release snapshot) but compiled with an X11 front end, it is quite a 
bit slower - this tells me we have a lot to improve :)

BTW, I managed to modify your code to make it run with Basilisk CVS!!

It works slightly better than using that CVS code directly - instead 
of staying black, the screen turn into black/white stripped, but then 
again nothgin happens :/


>
>
>
>>  P.S.: do you happen to know a Cris Pearson from Tasmania? :)
>
>	Nope.
>(which, considering the small size of Tassie, is surprising :-)

LOL :)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] Re: OS X -

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

...
> What I would like to suggest is that we add a singleton 
> EmulatorManager class that keeps track of the Emulator object (and in 
> future versions, manages multiple). This would be a singleton class, 
> similiar to NSApplication, i.e. you could call [EmulatorManager 
> sharedEmulatorManager] to get the single instance.
> 
> This would then have some useful methods, like IsAnyEmulatorRunning 
> (i.e. active and not paused) or something alike.
> Furthermore, it then would have a method to check if the emulator in 
> the current key window is running (and not paused), and if that is 
> true, then we don't intercept key events.

	This would be an ideal situation. Even better would be
if this class could check if the pointer is in the EmulatorView,
and not send any events to it if it is not.

	As an interim, how about we just pass all key events to
the Emulator class, and ignore any OS defaults. That way, there
is no need to check if an emulator is running. From memory, the
EmulatorView will do the right thing (ignore) when it gets an
event, and its emulator is not running. If not, should be simple
to add.

...
> BTW, Nigel, how is speed for you? On my G4/400, running Sys 7.5.3 in 
> the emu, I can literally see it do redraws etc.

	Same speed deficiencies. I haven't worked out if it is
the graphics environment (e.g. the barber pole, and having to
have the MacOS blit from an NSBitmap), or the emulation on a
RISC processor. I do remember that it was also quite slow on
my Sun Sparcstation 5 at work.

	It is fast enough to be usable in a pinch, though.



> P.S.: do you happen to know a Cris Pearson from Tasmania? :)

	Nope.
(which, considering the small size of Tassie, is surprising :-)

-- 
| Nigel Pearson, ni...@in...    | "Reality is that which,   |
| Telstra iDevelopments, 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] OS X -

[Max H. <ma...@qu...>]

At 14:14 Uhr +1000 10.10.2001, ni...@in... wrote:
[...]
>  > As for various of the problems mentioned in the README (regarding
>>  double clicks, intercepting Cmd-key shortcuts etc.), that is because
>>  the approach you used to hook into the system is not so good for this
>>  kind of application. A view just doesn't get it all.
>>
>>  The solution usually is to subcalls NSApplication, and provie an own
>>  sendEvent method. There you can intercept any events you want, and
>>  pass the ones you are not interested to the original implementation.
>
>	Excellent. I hadn't thought of that. I eagerly await your code!

I hacked up something for the keyboard input, and it works quite 
well! Now what needs to be changed: it should only intercept the 
keyboard events when the emulator is running and not paused. sadly 
this is not fully trivial with the current code.

What I would like to suggest is that we add a singleton 
EmulatorManager class that keeps track of the Emulator object (and in 
future versions, manages multiple). This would be a singleton class, 
similiar to NSApplication, i.e. you could call [EmulatorManager 
sharedEmulatorManager] to get the single instance.

This would then have some useful methods, like IsAnyEmulatorRunning 
(i.e. active and not paused) or something alike.
Furthermore, it then would have a method to check if the emulator in 
the current key window is running (and not paused), and if that is 
true, then we don't intercept key events.

As to the mouse events, I still have to look into this; we only want 
to intercept events that go into the EmulatorView, but ignore the 
rests (so that the various buttons keep working).


BTW, Nigel, how is speed for you? On my G4/400, running Sys 7.5.3 in 
the emu, I can literally see it do redraws etc.


Max

P.S.: do you happen to know a Cris Pearson from Tasmania? :)
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] Re: basilisk-devel digest, Vol 1 #114 - 1 msg

[Max H. <ma...@qu...>]

At 14:14 Uhr +1000 10.10.2001, ni...@in... wrote:
>  > OK, got the source for the OS X version, thanks.
>
>	Thanks for looking through all my hacky source code, Max!

Thanks for creating it in the first place :)

BTW, a lot of files have no legal header at all. You should insert 
one (even if it is just the default ProjectBUilder header) with your 
name and the creation date. if you want to GPL something, then add 
also the GPL into the header.


>
>>  I am already using 10.1 + 10.1 dev tools, which meant I first had a
>>  hard time using the ObjC parts - the problem is that several files
>>  (e.g. main.h) use C++ constructs,
>
>
>	Hmmm. The only C++ism I could see in main.h was 'bool',
>which is defined by main_MacOSX.h. As soon as I can get a copy
>of 10.1, I will re-check compilation.

Well it turned out that alot of this C++ism was introduced in the CVS 
version. My fault, sorry.


>
>
>...
>>  The simple fix was to change the suffices to .mm which turns
>>  on the ObjectiveC++ compiler on OS X 10.1
>
>	If it is going to be built with the Obj-C++ compiler,
>then all the glue functions in cpp_glue_MacOSX.{cpp,h} can go.

Yeah. But this probably should wait till you have 10.1 + dev tools, too :)

[...]


>  > Oh, and I am not so convinced that this is good style:
>>
>>  void	errorPanel   (const char *text),
>>	warningPanel (const char *text);
>
>	What is bad style? The function names? The multi-line decl?
>The actual purpose of the functions?

Sorry I was not clear :) Well, the multi-line decl is something I 
find very unusal. However, I don't see how it would be harmful right 
now, so if you like it, keep it :)



[...]

>  > #####################################
>>  In Emulator.m/.h, you use a variable called "clock" which somehow
>>  clashes with the unix function of the same name somehow.
>
>	Hmm. It doesn't clash under 10.0. Anyway, I have called it
>'RTC', and renamed clockInterrupt() as RTCinterrupt().

It worked ok unchanged in conjunction with the release version of 
Basilisk. However, this is becasue the CVS version seems to include 
some extra headers, which define the conflicting symbol.



[...]


>...
>>  #####################################
>>  In Emulator.m. method SpeedChange, you call
>>
>>  [redraw changeIntervalTo:redrawDelay * 1e6
>>	units:NNmicroSeconds ];
>>
>>  However, this doesn't make sense to me looking at how
>>  changeIntervalTo:units: is implemented - why don't you simply change
>>  the first parameter of that function to accept a double? then change
>>  the above mentioned call to
>>
>>  [redraw changeIntervalTo:redrawDelay
>>	units:NNSeconds ];
>
>	The NNTimer class uses nanosleep, which uses integers to set
>its delay period. I decided to stick with passing integers into its
>methods, hence the need to send the delay as a multiple of a small
>time delta.
>
>
>...
>>  Could you give me a quick hint what NNThread and NNTimer are needed
>>  for - what advantage do they have over NSThread and NSTimer?
>
>	They are not, strictly speaking, _needed_. They are mainly
>an elegance thing. I created them to simplify all the pthread stuff
>in main_unix.cpp. Their history:
>

[..cut off explanation of NNThread/NNTimer...]

>
>	Now, instead of all this, I could have used one NSThread,
>which called a modified main() from main_unix.cpp, and have the GUI
>thread locate the Mach kernel thread of that main() and manipulate
>its state, but that just felt really ugly. Much tidier to individually
>create the threads and timers from Obj-C, and then toggle their state
>all at once.

OK, that is all fine by me. I didn't want to suggest you switch to 
NS* anyway, I was more interested in understanding the reasons 
without spending hours over the code :)



Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [B2-devel] More on the OS X port

[Max H. <ma...@qu...>]

At 8:28 Uhr +0200 10.10.2001, Gwenole Beauchesne wrote:
>On Tue, 9 Oct 2001, Max Horn wrote:
>
>[About the MacOS X port]
>
>Sorry, I haven't touched to B2 for a while and won't do it before two
>weeks.  My goal was to get it fully compiled within the Terminal.
>
>>  it now runs, but the speed is very disappointing, both with and
>>  without -O3. The Xfree86 based version on the same machine using XonX
>>  is quite a bit faster.
>
>Do you mean that the CVS version in Direct Addressing mode now works ?

No. As I said, CVS is completly unusable for me (that is, I get to 
see the prefs screen, but when I start the emulation, the screen just 
stays black).
This was done using the latest release.

But I just see there were some CVS changes... hm, I really should 
subscribe to your CVS-notification ML :)


>If so, they finally corrected mmap() and some other functions in 10.1.

Looking at the code & configure.in, mmap is not even used one OS X, 
but vmallocate is.

>Can you please check that the addressing mode is set to "direct" in the
>configure summary (or look for a #define'd DIRECT_ADDRESSING in
><config.h>)  ?

config.h doesn't contain this, but yeah, -dDIRECT_ADDRESSING is 
passed in the CVS version.
It is not, however, in the non-CVS-version.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [B2-devel] More on the OS X port

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

On Tue, 9 Oct 2001, Max Horn wrote:

[About the MacOS X port]

Sorry, I haven't touched to B2 for a while and won't do it before two
weeks.  My goal was to get it fully compiled within the Terminal.

> it now runs, but the speed is very disappointing, both with and
> without -O3. The Xfree86 based version on the same machine using XonX
> is quite a bit faster.

Do you mean that the CVS version in Direct Addressing mode now works ? If
so, they finally corrected mmap() and some other functions in 10.1. Can
you please check that the addressing mode is set to "direct" in the
configure summary (or look for a #define'd DIRECT_ADDRESSING in
<config.h>)  ?

Thanks,
Gwenol=E9.

[B2-devel] Re: basilisk-devel digest, Vol 1 #114 - 1 msg

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

> OK, got the source for the OS X version, thanks.

	Thanks for looking through all my hacky source code, Max!


> I am already using 10.1 + 10.1 dev tools, which meant I first had a 
> hard time using the ObjC parts - the problem is that several files 
> (e.g. main.h) use C++ constructs,


	Hmmm. The only C++ism I could see in main.h was 'bool',
which is defined by main_MacOSX.h. As soon as I can get a copy
of 10.1, I will re-check compilation.


...
> The simple fix was to change the suffices to .mm which turns 
> on the ObjectiveC++ compiler on OS X 10.1

	If it is going to be built with the Obj-C++ compiler,
then all the glue functions in cpp_glue_MacOSX.{cpp,h} can go.


> Maybe some of my problems are also because I am trying to mix this 
> with the CVS version of Basilisk?

	Yes. The tarball I sent you is only for Basilisk 0.9 & OS10.0.
I think it compiled against this tarball:

http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_31052001.tar.gz

though it may be this one:

http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII_src_17022001.tar.gz


...
> As for various of the problems mentioned in the README (regarding 
> double clicks, intercepting Cmd-key shortcuts etc.), that is because 
> the approach you used to hook into the system is not so good for this 
> kind of application. A view just doesn't get it all.
> 
> The solution usually is to subcalls NSApplication, and provie an own 
> sendEvent method. There you can intercept any events you want, and 
> pass the ones you are not interested to the original implementation.

	Excellent. I hadn't thought of that. I eagerly await your code!


> Oh, and I am not so convinced that this is good style:
> 
> void	errorPanel   (const char *text),
> 	warningPanel (const char *text);

	What is bad style? The function names? The multi-line decl?
The actual purpose of the functions?


...
> #ifdef __cplusplus
> }
> #else
> 
> // These are called from Objective-C methods only
> extern void errorSheet   (NSString *msg1, NSString *msg2, NSString 
> *button, NSWindow *win),
> 			warningSheet (NSString *msg1, NSString *msg2, 
> NSString *button, NSWindow *win);
> 
> #endif
> 
> This ain't no good, either, it causes a catch 22 - if I turn on C++ 
> extensions, I can't compile because those definitions are gone.

	Well, yes, but Obj-C++ didn't exist when I hacked this together.
The compiler supported either C++ or Obj-C.

...
> The proper way of doing this is to check the __OBJC__ macro

	Thanks. Done.

...
> #import <Foundation/NSArray.h>;
> 
> Please remove the ; it causes a compiler error in the new dev tools 
> (rightfully). In fact the line is not needed at all since it is 
> already covered by Cocoa.h

	Deleted.

> Same in PrefsEditor.h, there is a line
> #include "Emulator.h";

	Corrected.


> #####################################
> In Emulator.m/.h, you use a variable called "clock" which somehow 
> clashes with the unix function of the same name somehow.

	Hmm. It doesn't clash under 10.0. Anyway, I have called it
'RTC', and renamed clockInterrupt() as RTCinterrupt().

...
> 	[emul	terminate];  emul	= nil; [emul	release];
> 
> This is nonsense!

	Oops. Those lines should have been:

    [emul terminate]; [emul release]; emul = nil;

	Have corrected.


...
> #####################################
> In Emulator.m. method SpeedChange, you call
> 
> [redraw changeIntervalTo:redrawDelay * 1e6
> 	units:NNmicroSeconds ];
> 
> However, this doesn't make sense to me looking at how 
> changeIntervalTo:units: is implemented - why don't you simply change 
> the first parameter of that function to accept a double? then change 
> the above mentioned call to
> 
> [redraw changeIntervalTo:redrawDelay
> 	units:NNSeconds ];

	The NNTimer class uses nanosleep, which uses integers to set
its delay period. I decided to stick with passing integers into its
methods, hence the need to send the delay as a multiple of a small
time delta.


...
> Could you give me a quick hint what NNThread and NNTimer are needed 
> for - what advantage do they have over NSThread and NSTimer?

	They are not, strictly speaking, _needed_. They are mainly
an elegance thing. I created them to simplify all the pthread stuff
in main_unix.cpp. Their history:


	Right from the start, I wanted the ability to suspend the
Basilisk emulator. Later on, I had the idea of multiple emulators
(e.g. test a program under both OS 6 and 7, in separate windows).
So, I wanted a thread class that gave me:

* An easy way to suspend and resume the threads

* Threads that I could start off in an inactive state
  (like pthread_create_suspended_np() )


	I started off with wrappers to pthread calls with Mach style
thread manipulation, and then added:

* The option to allocate an ObjC autorelease pool

* A large variety of method syntaxes

* Timers which:
  - used NNThreads for totally independant operation
    (e.g. if I had 5 timers, one of their methods could
          never return, but the others would keep firing)

  - had similar method syntax to the Threads
    (e.g. I can start, suspend or resume both NNThreads and NNTimers)

Note that NNThread currently uses NSThread (for GUI safety),
but could easily use pthread, cthread or Mach Kernel threads.




	Now, instead of all this, I could have used one NSThread,
which called a modified main() from main_unix.cpp, and have the GUI
thread locate the Mach kernel thread of that main() and manipulate
its state, but that just felt really ugly. Much tidier to individually
create the threads and timers from Obj-C, and then toggle their state
all at once.


	Sorry, that wasn't very quick.

-- 
| Nigel Pearson, ni...@in...    | "Reality is that which,   |
| Telstra iDevelopments, 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] More on the OS X port

[Max H. <ma...@qu...>]

OK, I gave up trying with the CVS (it seems to much has changed to 
get this working easily), and indeed, with the source of the latest 
release it fits in much better (I had to remove one typedef bool in 
one header, though).

I can start the app now. But it crashed when I tried to "boot", the 
reason being inside the code that creats the NSBitmapImageRep (i had 
set the display depth to 8 bit, but it turns out this is ignored 
anyway?).
This code is baaaaad:

	bitmap = [NSBitmapImageRep alloc];
	[bitmap initWith....

You should *NEVER* do this!!! always do it like this:

	bitmap = [NSBitmapImageRep alloc];
	bitmap = [bitmap initWith....

or maybe direcly

	bitmap = [[NSBitmapImageRep alloc] initWith....


The reason is that the init methods return the actual object, which 
might very well be different from the originally alloced object (e.g. 
for singleton classes), or even NULL, as in this case. This is 
especially "interesting" if one considers the commment in the same 
line:

// If NULL, allocate own data

Well, you will never detect this NULL with the current code :)


Next, the Build Styles are being abused: setting -O3 in the 
development build style, but no optimizations (e.g. default) in the 
deployment style is not very logical. I reverted it to the default, 
which set -O0 for development builds (making it much easier to use 
the debugger).


it now runs, but the speed is very disappointing, both with and 
without -O3. The Xfree86 based version on the same machine using XonX 
is quite a bit faster.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] Re: MacOS X port

[Max H. <ma...@qu...>]

OK, got the source for the OS X version, thanks.


I am already using 10.1 + 10.1 dev tools, which meant I first had a 
hard time using the ObjC parts - the problem is that several files 
(e.g. main.h) use C++ constructs, which is not allowed in the ObjC 
file (at least in 10.1, the compiler is now properly checking the 
code :). The simple fix was to change the suffices to .mm which turns 
on the ObjectiveC++ compiler on OS X 10.1

Maybe some of my problems are also because I am trying to mix this 
with the CVS version of Basilisk? That would explain why i get this 
error:

video_MacOSX.cpp:65: `struct monitor_desc' has no member named `bytes_per_row'

I added some .mode. in there that helped.


As for various of the problems mentioned in the README (regarding 
double clicks, intercepting Cmd-key shortcuts etc.), that is because 
the approach you used to hook into the system is not so good for this 
kind of application. A view just doesn't get it all.

The solution usually is to subcalls NSApplication, and provie an own 
sendEvent method. There you can intercept any events you want, and 
pass the ones you are not interested to the original implementation.

There are some variations of this technique, which all have some pro 
and cons. I will take a closer look at the current code, trying to 
understand how it all fits together, then I am convinced I will be 
able to give a better judgment of the situation.


Oh, and I am not so convinced that this is good style:

void	errorPanel   (const char *text),
	warningPanel (const char *text);

But well, maybe a matter of taste (it is actually the first time i 
ever I see this :)

#####################################
In main_MacOSX.h:

#ifdef __cplusplus
}
#else

// These are called from Objective-C methods only
extern void errorSheet   (NSString *msg1, NSString *msg2, NSString 
*button, NSWindow *win),
			warningSheet (NSString *msg1, NSString *msg2, 
NSString *button, NSWindow *win);

#endif

This ain't no good, either, it causes a catch 22 - if I turn on C++ 
extensions, I can't compile because those definitions are gone. If I 
turn them off, I can't compile because main.h uses C++ code. Bad.
The proper way of doing this is to check the __OBJC__ macro



#####################################
In controller.h, there is a line
#import <Foundation/NSArray.h>;

Please remove the ; it causes a compiler error in the new dev tools 
(rightfully). In fact the line is not needed at all since it is 
already covered by Cocoa.h

Same in PrefsEditor.h, there is a line
#include "Emulator.h";


#####################################
In Emulator.m/.h, you use a variable called "clock" which somehow 
clashes with the unix function of the same name somehow. It shouldn't 
but it does. Just rename the variable.


#####################################
In Emulator.m:

	[emul	terminate];  emul	= nil; [emul	release];

This is nonsense! It doesn't crash because ObjC is graceful and just 
does nothing when you send a message to nil, but please remove the 
[emul release] part (and the same for the other cases where this is 
done.


#####################################
In Emulator.m. method SpeedChange, you call

[redraw changeIntervalTo:redrawDelay * 1e6
	units:NNmicroSeconds ];

However, this doesn't make sense to me looking at how 
changeIntervalTo:units: is implemented - why don't you simply change 
the first parameter of that function to accept a double? then change 
the above mentioned call to

[redraw changeIntervalTo:redrawDelay
	units:NNSeconds ];


#####################################
In various places, floats, double and ints are mixed up. Not bad but 
causes warnings.


#####################################
Could you give me a quick hint what NNThread and NNTimer are needed 
for - what advantage do they have over NSThread and NSTimer?


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] Re: MacOS X port

[Max H. <ma...@qu...>]

At 10:59 Uhr +1000 08.10.2001, ni...@in... wrote:
>  > Now i got curious and looked through your CVS and the mailing list
>>  archives. I came upon a message that seemed to discuss a proper port
>>  to OS X (not just using X11). I wonder what happened with that?
>
>	I developed it, and am waiting for Gwenole (or Christian) to
>check in my source.
>
>
>>  can one get it somewhere? Any information?
>
>	I can e-mail you the source or application tarball, or if you
>have an ftp server, ftp them to you.

I don't have an FTP server; if the email is less than 10 MB, that 
should be fine, otherwise maybe you can upload it someplace?


I look forward to seeing it! If there is anything I could help 
with... I have experience with Cooca, and also am one of the major 
authors behind the OS X port of SDL (http://libsdl.org). As such I 
also have some knowledge of building/customizing automake/autoconf 
based buildsystems for OS X (avoiding any use of Project Builder), 
including the "bundling" of the created executables etc.


Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] Re: MacOS X port

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

> Now i got curious and looked through your CVS and the mailing list 
> archives. I came upon a message that seemed to discuss a proper port 
> to OS X (not just using X11). I wonder what happened with that?

	I developed it, and am waiting for Gwenole (or Christian) to
check in my source.


> can one get it somewhere? Any information?

	I can e-mail you the source or application tarball, or if you
have an ftp server, ftp them to you.

-- 
| Nigel Pearson, ni...@in...    | "Reality is that which,   |
| Telstra iDevelopments, 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] List alive? CVS problem

[Max H. <ma...@qu...>]

At 21:58 Uhr +0200 07.10.2001, Christian Bauer wrote:
>Hi!
>
>On Sun, Oct 07, 2001 at 08:29:05PM +0200, Max Horn wrote:
>>  Is this list alive at all?
>
>Yes.

Good :)


>
>>  Is there a way I can change some of the settings while it runs
>>  (like "inserting" a different disk).
>
>Not really.
>
>  > Sadly, I cannot switch below 16.7M colors, the original purpose I
>>  wanted to try Basilisk was to get some 16-Color-games to run (walk?
>>  :) again.
>
>The CVS version has that capability.

If it worked, I am sure it would have... sadly there is no way for me 
to test this :/


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [B2-devel] List alive? CVS problem

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

Hi!

On Sun, Oct 07, 2001 at 08:29:05PM +0200, Max Horn wrote:
> Is this list alive at all?

Yes.

> Is there a way I can change some of the settings while it runs
> (like "inserting" a different disk).

Not really.

> Sadly, I cannot switch below 16.7M colors, the original purpose I 
> wanted to try Basilisk was to get some 16-Color-games to run (walk? 
> :) again.

The CVS version has that capability.

Bye,
Christian

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

[B2-devel] List alive? CVS problem

[Max H. <ma...@qu...>]

Is this list alive at all?


Anyway, I cannot get the CVS version of basilisk to run properly on 
OS X (under XFree86). The last release works fine, but the CVS 
version, once I start the emulation, only shows a black screen. Not 
knowing much about the internals of Basiliks, I am not sure where i 
should start looking for possible problem source :/

But 0.9.1 work, and boy, it is cool :) Is there a way I can change 
some of the settings while it runs (like "inserting" a different 
disk).

Sadly, I cannot switch below 16.7M colors, the original purpose I 
wanted to try Basilisk was to get some 16-Color-games to run (walk? 
:) again. It just prints out a lot of
WARNING: Unknown VideoDriverStatus(18)
or
WARNING: Unknown VideoDriverStatus(16)
This is using a System 7.5.3 install, BTW.

when I try to change the settings. That was one of the reasons I 
wanted to try CVS, as I hoped this was fixed there, but as I said, 
the CVS version is not working at all.


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

[B2-devel] OS X port

[Max H. <ma...@qu...>]

Hi there,


I just downloaded BasiliskII_src_31052001.tar.gz, and got it working 
with almost no changes on MacOS X (had to upgrade config.guess/.sub 
manually). I am a member of the fink project 
(http://fink.sourceforge.net), and plan to make a fink-basilisk 
package.

Now i got curious and looked through your CVS and the mailing list 
archives. I came upon a message that seemed to discuss a proper port 
to OS X (not just using X11). I wonder what happened with that? can 
one get it somewhere? Any information?



Thanks,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890

Re: [B2-devel] Probably a FAQ but couldn't find it

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

On Mon, 17 Sep 2001, Ben Collins wrote:

> So I thought a nice emulator running on my PIII would do well, and
> even better if I could run it without X once linux was installed (and
> ssh to the system :)

A better solution is to setup a cross-compiling environment. It would be
faster than running (though you can't) it under an emulated environment,
even with a JIT compiler.

I know, in the past, the kernel for Linux/mac68k [debian] was
cross-compiled. You can setup a similar thing for compiling the glibc.
Note that you will need kernel headers, binutils configured to target
m68k, and obviously the compiler.

Random links:
<http://gfs.lcse.umn.edu/~grant/Linux/cross.html>
<http://penguinppc.org/embedded/cross-compiling/>

> Problem is, it doesn't seem that any of the m68k emulators have mmu
> support, which means no Linux. Anyone worked on or working on this?

I don't know anyone working on MMU support. *I* don't intend to do that
either. If I had time, I'd better toying with a PPC core. Everything
gets simplified if MacOS can run it in real addressing mode. ;-)

Bye,
Gwenole.

[B2-devel] Probably a FAQ but couldn't find it

[Ben C. <bco...@de...>]

Well, I am very interested in getting Linux/m68k running under
emulation. I have lots of work dealing with GNU Libc for this port, and
I don't have room amongst the 12 other systems to get an m68k, nor do I
have time for the slowness of it (glibc takes over 12 hours to compile
on m68k). So I thought a nice emulator running on my PIII would do
well, and even better if I could run it without X once linux was
installed (and ssh to the system :)

Problem is, it doesn't seem that any of the m68k emulators have mmu
support, which means no Linux. Anyone worked on or working on this?

-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bco...@de...  --  bco...@op...  --  bco...@li...  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

[B2-devel] 64-bit blitters

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

I gave the new 64-bit video blitters a try.  On my SGI Octane, the
16-bit Speedometer video test score improved 8.7% with the 64-bit
blitters, at 30hz.  Unfortunately, there isn't a 32-bit Speedometer
video test.

The 1-8 bit test scores were unaffected, as you'd expect.  The
Blit_Expand_x_To_y() routines could do maximally-sized reads too, or
at least some loop unrolling.

						Brian J. Johnson

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

  "One problem thoroughly mastered is of more value than many poorly
   mastered."
                                           -- Booker T. Washington

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

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

> What the hell is an "floating-point assist fault" ? Software/kernel
> emulation of some FPU instructions ?

Yes. IA64 uses a floating-point software assist module (FPSWA), loaded
as an EFI driver, to implement some floating point details.  See

  http://developer.intel.com/design/IA-64/Downloads/245415.htm

(BTW, I do IA64 firmware development as my "day job".)

						Brian J. Johnson

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

  "The highest reward for a person's toil is not what they get for it,
   but what they become by it."
                                           -- John Ruskin

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

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

On Wed, 18 Jul 2001, Brian Johnson wrote:

> Here's what I got on a recent CVS build.  Using 68030+FPU, direct
> addressing, I started up the calculator and entered 4 / 3.  When I
> typed the 3, B2 core dumped with a SIGBUS:

OK, thank you for the report, I will try to investigate but don't expect
it to be soon, unfortunately. I will have plenty of work untill October,
at least...

Anyway, if this can reassure you, I also get FPU emulation problems on
ia64. Results are totally wrong and the following shows up in
/var/log/messages:

Aug 19 15:24:41 lion kernel: BasiliskII(3200): floating-point assist fault
at ip 40000000000d71f1
Aug 19 15:24:41 lion kernel: BasiliskII(3200): floating-point assist fault
at ip 40000000000cf141
Aug 19 15:24:59 lion kernel: BasiliskII(3200): floating-point assist fault
at ip 2000000000280bd1
Aug 19 15:24:59 lion kernel: BasiliskII(3200): floating-point assist fault
at ip 2000000000280bf1
[...]

What the hell is an "floating-point assist fault" ? Software/kernel
emulation of some FPU instructions ?

> > Could you tell me the address reported by the segv handler and the
> > MEMBaseDiff offset value ?
>
> I'm having trouble tracking it down...   perhaps it got optimized
> away.

In main_unix.cpp, around line 351, you can put a printf() for MEMBaseDiff.
Anyway, in Direct Addressing, MEMBaseDiff == RAMBaseHost so if DEBUG is
set to 1, the D(bug(...)) will trigger it.

Re: [B2-devel] Problems with Speedometer 4.x & depth switching

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

On Wed, 11 Jul 2001, Brian Johnson wrote:

> (BTW, we should be able to greatly increase blitter performance by
> doing 64-bit loads and stores on machines which can do them directly.
> Something to think about.)

Done in CVS but I don't see any improvement on the ia64. :-/ Probably not
significant since gcc is known to generate sub-optimal code for now...

Bye,
Gwenole.

[B2-devel] IRIX patches

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

I've attached a few more patches for Irix, which get UDP tunnelling
working and fix a few compillation problems.

The fix to ether.cpp is necessary because SGI's header files #define
sa_len as a path through the structs and unions they use for their
sockaddr_in structure.  So it breaks badly if you use it as an
ordinary variable name.

I also had to replace socklen_t with int in ether_unix.cpp, since
SGI's headers don't define socklen_t.  I have no idea how standard (or
not) it is....  Perhaps BasiliskII should provide its own typedef for
socklen_t if the system header files don't?

I added a "WANT_ESD=no" to the IRIX portion of configure.in, since the
IRIX always uses audio_irix.cpp, which doesn't use ESD.  However, ESD
is available on SGI's freeware web site, and someone building BII may
have it installed.  Unfortunately, by the time the platform-specific
portion of configure.in runs, ESD has already been detected, and
CFLAGS, LIBS, etc. adjusted accordingly.  So setting WANT_ESD to "no"
only affects the report printed by configure.  What's the clean way
around this issue?

						Brian J. Johnson

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

  "Think big thoughts but relish small pleasures."
                                        -- Life's Little Instruction Book