basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] Remaining bugs

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

Hi,

> 2) B2/JIT will crash once FPU tests for Speedometer 3.23 are done. This 
> does not occur with Speedometer 4.x, nor without JIT-FPU nor without JIT 
> at all. So, it's bound to be a JIT-FPU specific bug.

In the next B2/JIT release, I workarounded that by disabling compilation 
of FMUL instructions. This might hide a latent bug in the reg-stack 
allocator but people might have a look at the jitfpu_fmul_bug.txt file if 
they are inspired.

The block that got it wrong could be the last one and is 107 instructions 
long!

Bye,
Gwenole.

[B2-devel] Re: Illegal instruction

[[RSU]The_Assassin|BuF <the...@zi...>]

Dunno if you've read this already:
 http://developer.gnome.org/doc/API/gdk/gdk-visuals.html
is about gdk visual manipulation.
And here's gdk in general:
http://developer.gnome.org/doc/API/gdk/gdk.html

I'll try the patch and truecolor visual in a sec.

<~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~>
Stan Kochen <The_Assassin>
<-------------------------------->
Beyondunreal.com Forums <BuF>
http://www.beyondunreal.com
<-------------------------------->
ReSpawners United - Unreal Tournament clan <RSU>
http://www.clanrsu.couk.com/
<~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~>
________________________________________________
Don't E-Mail, ZipMail! http://www.zipmail.com/

Re: [B2-devel] Illegal instruction

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

On Fri, 22 Mar 2002, [RSU]The_Assassin|BuF wrote:

> D'oh! Check your code, there's prolly something between an
>  '#ifdef FLIGHT_RECORDER' which BII depends on.

Oh I see now, please try with the patch attached herein without 
FLIGHT_RECORDER set to 1.

> Still get the gdk-pixbuf bug when running fullscreen tho,
>  but windowed worx now. Shweeet! :)

Yeah, disturbing but I don't enough X at this time to trace why it 
wouldn't work with a DirectColor visual.

Bye,
Gwenole.

Re: [B2-devel] Bug in BlockMove EmulOp?

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

On Fri, 22 Mar 2002, Gwenole Beauchesne wrote:

> Christian, the FlushCodeCache() call for the BlockMove EmulOp looks 
> suspicious to me.

Don't care, I simply had a mixture of old and new implementation of 
BlockMove emul op, so it didn't help. ;-)

Bye,
Gwenole.

Re: [B2-devel] Illegal instruction

[[RSU]The_Assassin|BuF <the...@zi...>]

D'oh! Check your code, there's prolly something between an
 '#ifdef FLIGHT_RECORDER' which BII depends on. I enabled
 mon and flight_recorder and it worked great. After that I
 recompiled with mon enable and flight_recorder disabled
 and it crashed. CVS snapshots of both cxmon and b2 from
 about 30 mins ago.

Still get the gdk-pixbuf bug when running fullscreen tho,
 but windowed worx now. Shweeet! :)

bye,
  T_A

<~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~>
Stan Kochen <The_Assassin>
<-------------------------------->
Beyondunreal.com Forums <BuF>
http://www.beyondunreal.com
<-------------------------------->
ReSpawners United - Unreal Tournament clan <RSU>
http://www.clanrsu.couk.com/
<~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~>
________________________________________________
Don't E-Mail, ZipMail! http://www.zipmail.com/

[B2-devel] Bug in BlockMove EmulOp?

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

Hi,

Christian, the FlushCodeCache() call for the BlockMove EmulOp looks 
suspicious to me.

IMHO, register usage for BlockMove is the following:
D0: byte count
A0: source address
A1: destination address

JIT compiler is not affected since we used to soft flushing all the 
cache, anyway. What about the following ?

Index: emul_op.cpp
===================================================================
RCS file: /cvs/BasiliskII/src/emul_op.cpp,v
retrieving revision 1.29
diff -u -r1.29 emul_op.cpp
--- emul_op.cpp 18 Jan 2002 21:06:03 -0000      1.29
+++ emul_op.cpp 22 Mar 2002 22:33:16 -0000
@@ -532,7 +532,7 @@
  #endif

                 case M68K_EMUL_OP_BLOCK_MOVE:           // BlockMove() 
cache flushing
-                       FlushCodeCache(Mac2HostAddr(r->a[0]), r->a[1]);
+                       FlushCodeCache(Mac2HostAddr(r->a[1]), r->d[0]);
                         break;

                 case M68K_EMUL_OP_DEBUGUTIL:

Re: [B2-devel] Illegal instruction

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

Hi,

> Anyways, the fix you commited to cvs to fix the resolution
>  switching @ bootup didn't fix my prob so I'll post it up
>  here. This happens @ start too, black screen pops up and
>  then it crashes.

I need to know which ROM do you use, which MacOS is emulated, which 
modelid did you set. Basically, that's the ~/.basilisk_ii_prefs file + 
OS version.

> Here's what it says (I set all DEBUG defines to 1 btw) :

I'd rather you do the following:
1) cvs update current B2 CVS sources
2) cvs co/update current cxmon CVS sources that ought to be in the same 
level than B2
3) In uae_cpu/newcpu.cpp, set FLIGHT_RECORDER to 1
4) [make distclean]. Reconfigure and make sure "mon" debugger is enabled
5) Remake

Then, reload B2 and hope it will crash. You will enter the cxmon 
debugger. There, type in "log" to dump an history log of instructions 
executed into log.68k. I need that file.

Bye,
Gwenole.

[B2-devel] Illegal instruction

[The_Assassin][BuF <the...@zi...>]

Okay, sorry for the very uninformative topic. :)

Anyways, the fix you commited to cvs to fix the resolution
 switching @ bootup didn't fix my prob so I'll post it up
 here. This happens @ start too, black screen pops up and
 then it crashes.

Here's what it says (I set all DEBUG defines to 1 btw) :

SCSIReset
EmulOp 7129
EmulOp 712b
vCheckLoad DRVR (44525652) ID 4, data 0x4147f3e0, size
 26832
EmulOp 710c
SonyOpen
set_dsk_err(0)
do_handle_screen_fault: unhandled address 0x7
 [IP=0x8093da3]
D0: 00000000 D1: 00000052 D2: 44525652 D3: 00000004 
D4: 4147f3e0 D5: 000068d0 D6: 63303137 D7: bffff6ac 
A0: 00005c10 A1: 40365c80 A2: 080e59aa A3: bffff6bc 
A4: 403d2124 A5: 0000710c A6: bffff760 A7: 0078fb56 
USP=00000000 ISP=0078fb56 MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0
FP0: 0 FP1: 0 FP2: 0 FP3: 0 
FP4: 0 FP5: 0 FP6: 0 FP7: 0 
N=0 Z=0 I=0 NAN=0
00f6c3f8: 710c 4e75 710d 600e 710e ILLEGAL.L 
next PC: 00f6c3fa
VideoQuitFullScreen()

Before that comes alot of XPRAM junk you prolly wouldn't be
 interested in, I've attached the full log to the email
 anyways (zip'ed), in case you want to know the other
 stuff. I'm running B2 in windowed mode, so I don't know
 what the VideoQuitFullScreen() is for. I also don't have
 any scsi or sony devices connected to my linux box, I do
 have scsi emulation for my cdrw however.
Sys specs: Linux kernel 2.4.18, glibc 2.2.3 (dunno for sure
 if it's 3, it's 2.2.x however, know that), gcc 2.95.3, no
 idea what binutils version, rather recent however, I
 picked up everything in november/december, most of the
 other stuff is GNU too so you can probably guess the
 version. ;) (yep, it's LFS :D)
I compiled basilisk with CFLAGS="-O3 -march=i686
 -mcpu=i686" however the same problem occurs without them.
 Also, while processing cputmp1.s with the cpuopti proggy,
 it drops the line "Stack adjustment not matching" to the
 console.
If you need any more info just ask me.

Also, I dunno why you didn't do this in the first place,
 but here's a small patch which adds a debugging option to
 the configure script (--enable-debug) which equals to
 setting every DEBUG define to 1. It might be alot of
 debugging, but it could come in handy for probs like this
 where basilisk doesn't even start. Good for determining
 where exactly the prob occurs. And I rather just turn
 everything on and skip stuff I don't need. It's in the
 second attachment. (zip'ed too)

Hope you'll manage to fix stuff soon. I'm just an beginning
 C programmer. Maybe I'll tweak the current basilisk GTK+
 interface as a first step to gfx programming.
Just to let you know gtk 2.0.0 has been released a while
 ago, but I think you should focus on real bugs first
 before anything else.

Bye,
   T_A

<~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~>
Stan Kochen <The_Assassin>
<-------------------------------->
Beyondunreal.com Forums <BuF>
http://www.beyondunreal.com
<-------------------------------->
ReSpawners United - Unreal Tournament clan <RSU>
http://www.clanrsu.couk.com/
<~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~>
________________________________________________
Don't E-Mail, ZipMail! http://www.zipmail.com/

Re: [B2-devel] Crash in CVS version of B2

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

> I decided to setup the screen and the sound from the Monitors & Sound 
> option.
> After trying to play a bit with the alert sounds - B2 crashed horribly 
> with
> this output:

Could you reproduce that problem in plain MacOS 8.0?

> Illegal instruction: 00dd at 0f7e6420

Ouch, that one is not nice. Could you please get some more debug output 
from the following procedure:

1) Grab latest cxmon sources that you place at the same level than the 
BasiliskII source directory.

2) Edit newcpu.cpp and set FLIGHT_RECORDER macro to 1

3) Still in newcpu.cpp, add the following at the end of the op_illg() 
function handler just below the "Illegal instruction" log message.

#ifdef ENABLE_MON
         char *arg[4] = {"mon", "-m", "-r", NULL};
         mon(3, arg);
#endif

4) Reconfigure, and you should get mon debugger support on. Remake.

5) Then once you catch an illegal instruction again, you will enter 
cxmon where you could dump an history of instructions executed and the 
register contents. Type in "log", and it will generate a "log.68k" file.

Then you could send me that file. Thanks.

> do_handle_screen_fault: unhandled address 0x91155600 [IP=0x80c0d6f]
> D0: 00000000 D1: 00000200 D2: 081d7f28 D3: 0806cd39
> D4: 0000000b D5: 50aa0600 D6: 00000200 D7: 00000000
> A0: 0f7e64d4 A1: 0f7e64b8 A2: 00000000 A3: 08074cd3
> A4: 081fede0 A5: 50aa0600 A6: 00478600 A7: 0ffafba8
> USP=00000000 ISP=0ffafba8 MSP=00000000 VBR=00000000
> T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0
> FP0: 0 FP1: 0 FP2: 0 FP3: 0
> FP4: 0 FP5: 0 FP6: 0 FP7: 0
> N=0 Z=0 I=0 NAN=0
> 0f7e641e: dddd 00dd dddd 00dd dddd ADDA.L (A5)+,A6
> next PC: 0f7e6420

Probably garbage instruction executed. A5 contents is suspicious and 
remind me some HWBase for some LowMem globals. But that could be just 
garbage executed from last illegal instruction though.

Bye,
Gwenole.

[B2-devel] Crash in CVS version of B2

[Hetz B. H. <he...@kd...>]

Hi All,

Well, after struggling to find a CD with Mac OS 8.1, and Hebrew support for me 
(I live in Israel) and a good copy of Quadra 900 ROM - I have recompiled 
Basilisk 2 CVS and played with it.

I installed OS 8.0, upgraded to OS 8.1..

I decided to setup the screen and the sound from the Monitors & Sound option. 
After trying to play a bit with the alert sounds - B2 crashed horribly with 
this output:

Basilisk II V1.0 by Christian Bauer et al.
Reading ROM file...
Using /dev/dsp audio output
WARNING: RmvTime(10057c86): Descriptor not found
Illegal instruction: 00dd at 0f7e6420
WARNING: Unknown VideoDriverStatus(24) <-
WARNING: Unknown VideoDriverStatus(20) <-I assume that those are
WARNING: Unknown VideoDriverStatus(24) <- the video changing modes
Illegal instruction: 00dd at 0f7e6420
WARNING: Unknown VideoDriverStatus(24) <- that I played with
WARNING: Unknown VideoDriverStatus(20) <- on the mac emu
WARNING: Unknown VideoDriverStatus(24) <-
WARNING: Unknown VideoDriverStatus(20) <-
do_handle_screen_fault: unhandled address 0x91155600 [IP=0x80c0d6f]
D0: 00000000 D1: 00000200 D2: 081d7f28 D3: 0806cd39
D4: 0000000b D5: 50aa0600 D6: 00000200 D7: 00000000
A0: 0f7e64d4 A1: 0f7e64b8 A2: 00000000 A3: 08074cd3
A4: 081fede0 A5: 50aa0600 A6: 00478600 A7: 0ffafba8
USP=00000000 ISP=0ffafba8 MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0
FP0: 0 FP1: 0 FP2: 0 FP3: 0
FP4: 0 FP5: 0 FP6: 0 FP7: 0
N=0 Z=0 I=0 NAN=0
0f7e641e: dddd 00dd dddd 00dd dddd ADDA.L (A5)+,A6
next PC: 0f7e6420

Whats worse is that if I'll try to "reboot" the OS - the image won't be 
recoginzed by the B2, so I have to reboot from the CDROM, shut down, and 
reboot from the OS image on my Linux.

Machine: P4 1.5Ghz, 512MB, KDE 3.0 CVS, XFree 4.1.0, nvidia 2802 driver, gcc 
2.96 latest, Mac OS 8.1, Quadra 900 ROM (and B2 set as Quadra 900), emulated 
as 68040.

Any suggestions?
Thanks,
Hetz

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi!

On Mon, Mar 18, 2002 at 11:08:47PM +0100, Gwenole Beauchesne wrote:
> Do you commit?

Done.

Bye,
Christian

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

[B2-devel] Remaining bugs

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

Hi,

Yet two important bugs to fix before looking at the JIT merge:

1) Apple Personal Diagnostics will crash once the main screen is drawn 
but prior to displaying any menu. It looks like trying to access 
something at 0x7fff7fff. I first though that was a FPU problem but it 
occurs with/without all 3 FPU cores in 68040 mode (tested with a patched 
main.cpp for FPUType).

In 68030 mode, I get the menu drawn but APD will crash some time after I 
move the cursor around. Probably an "off-by-one" error while popping 
from the stack. In the 030 case, one of the address to BlockMove was 
wrong (value was something 0x7fff0...).

I seem to be the sole guy having that problem. Even strangier, I think I 
already got the same problem long time ago, that got automagically fixed 
somehow then it's back broken for me nowadays. I will check the cpu 
cores.

2) B2/JIT will crash once FPU tests for Speedometer 3.23 are done. This 
does not occur with Speedometer 4.x, nor without JIT-FPU nor without JIT 
at all. So, it's bound to be a JIT-FPU specific bug.

BTW, any takers for the "scrollbar bug" when emulating m68k fpu 
registers with only double precision?

Bye,
Gwenole

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi,

> Here's a patch that prevents the depth switch on startup (and also 
> removes
> the "zapped PRAM penalty time"):

It works great, thanks! Do you commit?

Bye,
Gwenole.

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi!

Here's a patch that prevents the depth switch on startup (and also removes
the "zapped PRAM penalty time"):

Index: main.cpp
===================================================================
RCS file: /cvs/BasiliskII/src/main.cpp,v
retrieving revision 1.11
diff -r1.11 main.cpp
104a105,134
> 	// Load XPRAM default values if signature not found
> 	if (XPRAM[0x0c] != 0x4e || XPRAM[0x0d] != 0x75
> 	 || XPRAM[0x0e] != 0x4d || XPRAM[0x0f] != 0x63) {
> 		D(bug("Loading XPRAM default values\n"));
> 		memset(XPRAM, 0, 0x100);
> 		XPRAM[0x0c] = 0x4e;	// "NuMc" signature
> 		XPRAM[0x0d] = 0x75;
> 		XPRAM[0x0e] = 0x4d;
> 		XPRAM[0x0f] = 0x63;
> 		XPRAM[0x01] = 0x80;	// InternalWaitFlags = DynWait (don't wait for SCSI devices upon bootup)
> 		XPRAM[0x10] = 0xa8;	// Standard PRAM values
> 		XPRAM[0x11] = 0x00;
> 		XPRAM[0x12] = 0x00;
> 		XPRAM[0x13] = 0x22;
> 		XPRAM[0x14] = 0xcc;
> 		XPRAM[0x15] = 0x0a;
> 		XPRAM[0x16] = 0xcc;
> 		XPRAM[0x17] = 0x0a;
> 		XPRAM[0x1c] = 0x00;
> 		XPRAM[0x1d] = 0x02;
> 		XPRAM[0x1e] = 0x63;
> 		XPRAM[0x1f] = 0x00;
> 		XPRAM[0x08] = 0x13;
> 		XPRAM[0x09] = 0x88;
> 		XPRAM[0x0a] = 0x00;
> 		XPRAM[0x0b] = 0xcc;
> 		XPRAM[0x76] = 0x00;	// OSDefault = MacOS
> 		XPRAM[0x77] = 0x01;
> 	}
> 
146c176
< 	// Set default video mode
---
> 	// Set default video mode in XPRAM

Bye,
Christian

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

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi!

On Mon, Mar 18, 2002 at 07:49:59PM +0100, Gwenole Beauchesne wrote:
> When the XPRAM file is empty, a cscSetMode command is issued even prior to
> having the HappyFace. At this time, the MainDevice and CrsrDevice handles
> are nil.

Same here. So, obviously, a check is needed in switch_mode().

> Does anyone know what sort of table is at 0x2120?

That would be the master pointer table of the system zone.

> BTW, I also looked up the UTableBase and only found at the 48th entry the 
> handle 0x2124.

That's probably the video driver.

Bye,
Christian

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

Re: [B2-devel] Video switching problem and VOSF/DA

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

On Sun, 17 Mar 2002, Christian Bauer wrote:

> > 1) VidLocal.dm_present=0 so I run the code though I am using MacOS 8.0+
> 
> This seems suspicious. Under MacOS 8.0 I have dm_present=1 and also valid
> handles in MainDevice and CrsrDevice.

I have "valid" handles at the crash time. But they were handles pointing
to the old screen buffer. When the XPRAM file is empty, a cscSetMode 
command is issued even prior to having the HappyFace. At this time, the 
MainDevice and CrsrDevice handles are nil. This is checked by entering 
cxmon at the end of video.cpp/switch_mode().

I came up with two "traces" to which handle is containing the old screen 
buffer address. One under Linux/pcc and the other under Linux/x86. Both 
used the same ROM (LC/Quadra 630) and system (MacOS 8.0fr).

### Linux/ppc

VideoDriverControl(pb=0x100fb06, dce=<value lost>):
  SetMode 0080

uint32 gdev = ReadMacInt32(0x100faea || 0x100fb4e);
gdev = ReadMacInt32(0x2120 || 0x100f930 || 0x100f944 || 0x100fada || 
0x100faee || 0x100fb28)
uint32 pmap = ReadMacInt32((0x9460 || 0x100fb26) + 0x16);
pmap = ReadMacInt32(0x2110 || 0x0100fab6);
WriteMacInt32(0x94b0, frame_base);

This reads as follows: 0x2120 is some *Device handle that will lead to a
baseAddr containing the old screen buffer base.
i.e. **((**<SomeDevice=0x2120>).gdPMap).baseAddr = <old_frame_base>

### Linux/x86

VideoDriverControl(pb=0x100fb06, dce=0x9240):
  SetMode 0080

uint32 gdev = ReadMacInt32(0x100faea || 0x100fb4e);
gdev = ReadMacInt32(0x2120 || 0x100f930 || 0x100f944 || 0x100fada || 
0x100faee || 0x100fb28)
uint32 pmap = ReadMacInt32((0x9490 || 0x100fb26) + 0x16);
pmap = ReadMacInt32(0x2110 || 0x0100fb3c);
WriteMacInt32(0x94e0, frame_base);

Note that in both runs, 0x2120 is a recurrent valid handle to some Device 
leading to the old frame_base.

Does anyone know what sort of table is at 0x2120?

BTW, I also looked up the UTableBase and only found at the 48th entry the 
handle 0x2124.

I am a little confused by now.

Bye,
Gwenole.

Re: [B2-devel] Re: Mac OS X fullscreen

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

Hi!

On Mon, Mar 18, 2002 at 10:13:43AM +1100, Nigel Pearson wrote:
> 1) Can I somehow subclass monitor_desc it in this situation?

You _have_ to subclass it, as it is an abstract base class.

> 2) Would the definition of this vector have to be in video_<host>.cpp
>     to enable me to subclass it?

The vector<monitor_desc *> (or map<>) would be in video.cpp. This doesn't
interfere with subclassing (that's why it uses pointers, not monitor_desc
themselves).

> b) Preventing having to search through stuff is why I would like to add
>     a generic platform-specific field into the two video struct/classes

You could map<> your resolution_id.

Bye,
Christian

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

[B2-devel] Re: Mac OS X fullscreen

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

Christian proposed:

> Now would be a good time to do that augmentation. Here's a draft:
>
> - struct video_mode remains as it is now
> - the global VideoModes vector is removed
> - struct monitor_desc gets transformed into an abstract base class:
...
> - the global VideoMonitor variable gets replaced by a=20
> vector<monitor_desc *>
>   which is filled in by VideoInit()


	That looks OK, though for Mac OS X I still have a desire to =
store an
extra field in the monitor_desc, and ideally an extra one in video_mode.

1) Can I somehow subclass monitor_desc it in this situation?

2) Would the definition of this vector have to be in video_<host>.cpp
    to enable me to subclass it?

...
> - the Mac video driver code can determine the monitor_desc its=20
> associated
>   with by looking at its dCtlSlotId and scanning the monitor_desc =
vector
>   (or maybe it would be better to have a map<uint8, monitor_desc *>?)

a) I think having a map<> would be much tidier

b) Preventing having to search through stuff is why I would like to add
    a generic platform-specific field into the two video struct/classes

--
|Nigel Pearson, ni...@in...  |=93Now the world has gone to =
bed,|
|Telstra iDevelopments, Sydney Australia| Darkness won=92t engulf my =
head,|
|  Office: 9206 3468    Fax:  9212 6329 | I can see by infrared,        =
|
|  Mobile: 0408 664435  Home: 9792 6998 | How I hate the night.=94 =
-Marvin|

RE: [B2-devel] Hello

[Daniel L. <da...@ma...>]

Ok, yes it is a bit out of date - the latest one there is jan 2001, but
I'll see if I can do anything with it. As I said, I'm very much a novice
at programming, but trawling through your code, might help me learn, and
I might be able to contribute sometime to getting a more recent win32
port. It might just be getting the sysdeps.h file from this old copy,
and trying a compile against it with the latest cvs source. I don't
understand header files though, what they do, and how they do it,
but.... I'll give it a go, wish me luck :-p

Cheers, Danny

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.336 / Virus Database: 188 - Release Date: 11/03/2002
 

[B2-devel] B2 screenshot of the week

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

Hi!

Poor HDT BenchTest getting totally confused by B2's I/O speed:
  http://wwwthep.physik.uni-mainz.de/~cbauer/hdt_benchtest.png

:-)

Bye,
Christian

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

Re: [B2-devel] Hello

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

Hi!

On Sat, Mar 16, 2002 at 08:06:43PM -0000, Daniel Llewellyn wrote:
> Actually, I'm a very amature programmer, but I want to help in any way
> possible.

Welcome! :-)

>  1. Can the source be directly recompiled for windows? And

The Win32-specific portions of the source are not part of the CVS archive.
The latest Win32-compilable source is probably the one on
  http://www.nic.fi/~lpesonen/BasiliskII/
which is likely to be out-of-sync with the main sources by now.

>  2. If not, how difficult is it for a newb like me to create a port to
> the win32 platform from the existing code available at the main website?

Making a basic working version shouldn't be difficult, but getting the
graphics up to reasonable speed could get involved.

Bye,
Christian

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

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi!

On Sat, Mar 16, 2002 at 09:35:52PM +0100, Gwenole Beauchesne wrote:
> 1) VidLocal.dm_present=0 so I run the code though I am using MacOS 8.0+

This seems suspicious. Under MacOS 8.0 I have dm_present=1 and also valid
handles in MainDevice and CrsrDevice.

> Do you have any Inside Mac reference for VDSwitchInfo struct and related 
> things (DCE and param block)?

You need this:
  http://developer.apple.com/techpubs/hardware/Developer_Notes/System_Software/Display_Device_Driver_Guide.pdf

And probably also this (beware! this deals with PCI drivers and some of the
information contained doesn't apply to B2's video driver):
  http://developer.apple.com/techpubs/hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/

Bye,
Christian

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

Re: [B2-devel] Video switching problem and VOSF/DA

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

>> Suggested fix:
>> [[CrsrDevice] + 0x0016] = frame_base in video.cpp/switch_mode() ?
>
> Sounds good.

Unfortunately this doesn't work. Another problem rose while trying this 
fix. Still, in video.cpp/switch_mode(), there is code to patch frame 
buffer base address (for MacOS versions <7.6).

1) VidLocal.dm_present=0 so I run the code though I am using MacOS 8.0+
2) [MainDevice] yields 0 so gdPMap is probably wrong. We should add a 
check for gdev
3) [CrsrDevice] also yields 0

Do you have any Inside Mac reference for VDSwitchInfo struct and related 
things (DCE and param block)?

Thanks,
Gwenole, trying to reproduce the problem on Linux/ppc now.

[B2-devel] Hello

[Daniel L. <da...@ma...>]

Hi guys on the list. I wanted to send in a message, to let you know that
there is at least one person other than Gwenole and Christian following
this list :-p I'm not by any stretch of the imagination a good
programmer. Actually, I'm a very amature programmer, but I want to help
in any way possible. My platform is windows XP, and as such, I have a
vested interest in the win32 port, but this hasn't been updated since
january of last year. Therefore I have two questions:
 1. Can the source be directly recompiled for windows? And
 2. If not, how difficult is it for a newb like me to create a port to
the win32 platform from the existing code available at the main website?

Cheers, Daniel

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.336 / Virus Database: 188 - Release Date: 11/03/2002
 

Re: [B2-devel] Video switching problem and VOSF/DA

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

Hi!

On Sat, Mar 16, 2002 at 06:00:24PM +0100, Gwenole Beauchesne wrote:
> Suggested fix:
> [[CrsrDevice] + 0x0016] = frame_base in video.cpp/switch_mode() ?

Sounds good.

Bye,
Christian

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