Menu
▾
▴
basilisk-devel — Basilisk II development-related discussion
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(42) |
Oct
(17) |
Nov
(7) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(14) |
Feb
(8) |
Mar
(13) |
Apr
(10) |
May
(28) |
Jun
(28) |
Jul
(23) |
Aug
(7) |
Sep
(2) |
Oct
(24) |
Nov
(9) |
Dec
(2) |
| 2002 |
Jan
(58) |
Feb
(15) |
Mar
(57) |
Apr
(26) |
May
(7) |
Jun
|
Jul
(10) |
Aug
|
Sep
(19) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2003 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(14) |
Jun
(3) |
Jul
(7) |
Aug
(4) |
Sep
(7) |
Oct
(4) |
Nov
(11) |
Dec
(3) |
| 2004 |
Jan
(32) |
Feb
(21) |
Mar
(3) |
Apr
(11) |
May
(33) |
Jun
(42) |
Jul
(46) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(42) |
Dec
(23) |
| 2005 |
Jan
(5) |
Feb
(2) |
Mar
(12) |
Apr
(26) |
May
(8) |
Jun
(18) |
Jul
(21) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(10) |
Dec
(1) |
| 2006 |
Jan
(17) |
Feb
(17) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(7) |
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(7) |
Dec
(4) |
| 2007 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(17) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
| 2008 |
Jan
(14) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2009 |
Jan
(2) |
Feb
(22) |
Mar
(3) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(32) |
Nov
(9) |
Dec
|
| 2010 |
Jan
(18) |
Feb
(2) |
Mar
(14) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(6) |
Oct
(35) |
Nov
(4) |
Dec
|
| 2011 |
Jan
(4) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
(4) |
| 2012 |
Jan
(4) |
Feb
|
Mar
(8) |
Apr
(9) |
May
|
Jun
(176) |
Jul
(86) |
Aug
(20) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: Gwenole B. <gb...@di...> - 2002-01-18 12:57:46
|
On Fri, 18 Jan 2002, Gwenole Beauchesne wrote: > Any ideas? HandleZone() is in ROM. Still no clue. But I made a few mistakes. HandleZone() is actually in RAM and the thing I quoted above was probably the A-Trap dispatcher. > PS: Christian, it would be neat if cxmon could resolve the address of low > mem global by name, I currently get: > > [001ff0fc]-> m ExpandMem > *** Undefined variable > > [001ff0fc]-> m 2b6 > As I don't know by heart my table of Low Mem globals, I use mon_lowmem.h. > ;-) Silly me, easier to know that through the m68k opcodes in the left column. ;-) Bye, Gwenole. |
|
From: Gwenole B. <gb...@di...> - 2002-01-18 11:17:11
|
Hi, Problem: APD (Apple Personal Diagnostics) crashes at start in 68040 emulation mode under MacOS 8.1. However, it appears to work correctly in 68030+FPU emulation mode. The ROM is still the one from my LC630. Traceback: do_handle_screen_fault: unhandled address 0xc054cfff [IP=0x80b20ab] D0: 7fff7fff D1: 0000a126 D2: 00000126 D3: 00176064 D4: 7fff0000 D5: 01c20000 D6: 00000000 D7: 00000000 A0: 7fff7fff A1: 01d41190 A2: 001ff0fc A3: 7fff7fff A4: 01c2230c A5: 01fd277a A6: 01d38f86 A7: 01d38f4a USP=00000000 ISP=01d38f4a MSP=00000000 VBR=00000000 T=00 S=1 M=0 X=1 N=0 Z=0 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 0002e25a: 2010 6620 48e7 40c0 2f08 MOVE.L (A0),D0 next PC: 0002e25c Lastest basic blocks executed (most recent first) are copied hereunder. In other words, exploring why A0 would have the 0x7fff7fff value. [00000000]-> d68 0002e250 0002e25a 0002e250: 224d movea.l a5,a1 0002e252: 2a78 0b7c movea.l Twitcher2,a5 0002e256: 2008 move.l a0,d0 0002e258: 6724 beq.s $0002e27e 0002e25a: 2010 move.l (a0),d0 [0002e25c]-> d68 02009a20 02009a22 02009a20: 1401 move.b d1,d2 02009a22: 4eb0 2591 jsr ([$00000000,d2.w*4]) [02009a26]-> d68 020099f0 020099fe 020099f0: 2f01 move.l d1,-(a7) 020099f2: 2f09 move.l a1,-(a7) 020099f4: 3202 move.w d2,d1 020099f6: 2f4a 0014 move.l a2,($0014,a7) 020099fa: 0242 0100 andi.w #$0100,d2 020099fe: 6620 bne.s $02009a20 [02009a00]-> d68 020099b0 020099be 020099b0: 2f0a move.l a2,-(a7) 020099b2: 2f02 move.l d2,-(a7) 020099b4: 246f 000a movea.l ($000a,a7),a2 020099b8: 341a move.w (a2)+,d2 020099ba: 0c42 a800 cmpi.w #$a800,d2 020099be: 6530 bcs.s $020099f0 [020099c0]-> d68 001ff0ec 001ff0fa 001ff0ec: 2078 02b6 movea.l ExpandMem,a0 001ff0f0: 2068 02a8 movea.l ($02a8,a0),a0 001ff0f4: 2628 001c move.l ($001c,a0),d3 001ff0f8: 204b movea.l a3,a0 001ff0fa: a126 HandleZone Any ideas? HandleZone() is in ROM. PS: Christian, it would be neat if cxmon could resolve the address of low mem global by name, I currently get: [001ff0fc]-> m ExpandMem *** Undefined variable [001ff0fc]-> m 2b6 As I don't know by heart my table of Low Mem globals, I use mon_lowmem.h. ;-) Thanks, Gwenole. |
|
From: Christian B. <cb...@st...> - 2002-01-17 20:31:27
|
Hi! On Thu, Jan 17, 2002 at 01:19:23PM -0600, Brian Johnson wrote: > BTW, if someone could check in this patch or something similar, > I'd appreciate it. Done. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: Brian J. <bjj...@us...> - 2002-01-17 19:19:25
|
I tried the 15012002 snapshot on Irix, and it seems to configure and
run OK. I still see the timing problems I have for a while (moving
the mouse makes BII think time is moving faster: eg. the insertion
point blinks faster.) But that looks more like an Irix pthreads issue
than a BII problem. I'm still working on it.
I did have to make one change to get it to compile:
--- ether.cpp.orig Thu Jan 17 13:00:56 2002
+++ ether.cpp Thu Jan 17 13:01:20 2002
@@ -114,8 +114,8 @@
}
// Retrieve local IP address (or at least one of them)
- socklen_t sa_len = sizeof(sa);
- getsockname(udp_socket, (struct sockaddr *)&sa, &sa_len);
+ socklen_t sa_length = sizeof(sa);
+ getsockname(udp_socket, (struct sockaddr *)&sa, &sa_length);
uint32 udp_ip = sa.sin_addr.s_addr;
if (udp_ip == INADDR_ANY || udp_ip == INADDR_LOOPBACK) {
char name[256];
Irix's header files #define sa_len to some nutty foo.bar.natch sort of
thing, so it can't be used as a variable name. (BTW, if someone could
check in this patch or something similar, I'd appreciate it. It's
kind of a pain having to keep reapplying it locally.)
Thanks,
Brian J. Johnson
--------------------------------------------------------------------
"...if the church put in half the time on covetousness that it does
on lust, this would be a better world."
-- Garrison Keillor
|
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 17:32:40
|
It seems that Booting B2 with In Quadra mode WITHOUT any images doesn't give any errors... Of course - in that stage its useless unless a person got the OS 8.1 boot CD's or floppies, but it seems that there isn't a bug there (I think)... Hetz |
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 17:18:18
|
I just forgot something... I was talking to our local Apple dealer for purchasing Mac OS 8.1 CD and he told me that Quadra 900 cannot be installed with OS 8.1, only 7.6.1 But I can see that B2 can use Quadra with OS 8.1 Is he dumb? is the OS 8.1 that can be bought will run on B2? (well, if it will work on B2 - currently only the MacII can be used here). Thanks, Hetz |
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 17:09:43
|
Ok, I have erased my build of B2 and re-opened the CVS version The status now is this: In MacIIci mode it boots and everything seems works ok. In Quadra Mode I get: vm_acquire: 0x44b4d000-0x44c7b000 (1236992 bytes) vm_acquire: 0x44c7b000-0x44da9000 (1236992 bytes) vm_acquire: 0x44da9000-0x44da9130 (304 bytes) vm_acquire: 0x44daa000-0x44daa970 (2416 bytes) Illegal instruction: 000b at 0003cb54 with a nice "illegal instruction" in the mac emu window, so I cannot use it (even with Gwenole vma patch which he sent me privately). Now - may I ask if Gwenole or Christian can add a simple checking of which ROM the user got? a simple grep like this gives this output: strings PERFORMA.ROM | grep Quad | tail -2 X Quadra900, OÀ 1.0.4f1AQuadra Ethernet Driver v1.0.4f1; © Apple Computer, Inc. 1990-1992NV So, a sane checking could find out if there is a MacII rom or Qudra (or Performa) ROM and force the emulator to use this rom (and of-course, less bug reports). My conslusion - I probably used a MacII rom image without knowing it's MacII. My apologies to the developers. Hetz |
|
From: Christian B. <cb...@st...> - 2002-01-17 16:16:05
|
Hi! On Thu, Jan 17, 2002 at 12:10:19AM +0200, Hetz Ben Hamo wrote: > Unix]$ cat /home/hetz/.basilisk_ii_prefs > [...] > modelid 14 Have you tried it with "modelid 5"? Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 16:06:30
|
> > Fullscreen mode gives an error: > > Gdk-ERROR **: BadMatch (invalid parameter attributes) > > serial 29 error_code 8 request_code 1 minor_code 0 > > (although it switches to this mode, then shows the error). > > Yes, that's another problem I forgot to mention. ;-) I see... > > > Is it a stock RH-7.2 installation? > > > > Yes, with all the latest redhat official 7.2 updates (glibc, fam, etc) > > As I said yesterday, I'll be happy to let you login to one of my machines > > for testing, although the link is slow (my ADSL is dead now until our > > damn telco will fix it). > > OK, that's something to take under consideration in the event I can't > reproduce that on a similar configuration. Have you tried with gcc3 ? Well, compiling gcc 3.0.3 is not a fun part so much, anyone knows RPMS for gcc 3.0.3 location or something for RH 7.2? Thanks, Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-17 10:50:39
|
On Thu, 17 Jan 2002, Hetz Ben Hamo wrote: > Now - the funny thing is that those errors dissapear if I select MacIIci and > the mac boots ok (I'm using the free Mac OS 7.5.3 - no matter what processor > I select), but only in "banks" mode. Trying the same trick on normal (with > direct mode) build doesn't work. Indeed, a Mac IIci ROM has to be used with "modelid 5". It works in banks mode because an access to a memory area other than RAM, ROM, Video is a no-op. In direct addressing mode, the sigsegv handler catches it but then crashes. B2 could be modified so that the instruction causing the fault is skipped but this is becoming tricky to deal with other architectures. Another cause is probably in the video code. The blitters are probably still trying to address a region that is reclaimed. Working on a patch to test. > Fullscreen mode gives an error: > Gdk-ERROR **: BadMatch (invalid parameter attributes) > serial 29 error_code 8 request_code 1 minor_code 0 > (although it switches to this mode, then shows the error). Yes, that's another problem I forgot to mention. ;-) > > Is it a stock RH-7.2 installation? > > Yes, with all the latest redhat official 7.2 updates (glibc, fam, etc) > As I said yesterday, I'll be happy to let you login to one of my machines for > testing, although the link is slow (my ADSL is dead now until our damn telco > will fix it). OK, that's something to take under consideration in the event I can't reproduce that on a similar configuration. Have you tried with gcc3 ? Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 09:55:22
|
> Hmmm, looking at the Makefile you provided, you could not rebuild B2 since > make would have issued an error for "$/bin/cat" that doesn't exist either. > i.e. Replace "$/bin/cat" with "/bin/cat". ;-) ok, me fool ;) After fixing it and retrying B2 - I got the same error. > Anyway, please try the following instead: > $ apply the attached patch > $ make distclean > $ ./autogen.sh > $ make > > You will get an unoptimized (x86-wide) core. And getting the same crash again ;( > > I don't know if I mention it - but that happends also with the > > standard 0.9 version (not only with the JIT version)... yet same > > error... > > Does it also fail in --enable-addressing=banks mode? it boots the Mac, but with immidiate error in the mac which says: sorry, a system error occured. "System" Illegal Instruction On the console I see: Illegal instruction: 000b at 000349cc (in 68030 mode) If I try 68030 with FPU the error in the console is: Illegal instruction: 000b at 00034888 Now - the funny thing is that those errors dissapear if I select MacIIci and the mac boots ok (I'm using the free Mac OS 7.5.3 - no matter what processor I select), but only in "banks" mode. Trying the same trick on normal (with direct mode) build doesn't work. BTW - showing some guys around here a mac IIci emulation running fullscreen 1600x1280 surely made excitement ;) Fullscreen mode gives an error: Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 29 error_code 8 request_code 1 minor_code 0 (although it switches to this mode, then shows the error). > > Other suggestions? > Is it a stock RH-7.2 installation? Yes, with all the latest redhat official 7.2 updates (glibc, fam, etc) As I said yesterday, I'll be happy to let you login to one of my machines for testing, although the link is slow (my ADSL is dead now until our damn telco will fix it). Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-17 09:05:02
|
On Thu, 17 Jan 2002, Hetz Ben Hamo wrote: > It's still doesn't help - so it's not the optimization part. Hmmm, looking at the Makefile you provided, you could not rebuild B2 since make would have issued an error for "$/bin/cat" that doesn't exist either. i.e. Replace "$/bin/cat" with "/bin/cat". ;-) Anyway, please try the following instead: $ apply the attached patch $ make distclean $ ./autogen.sh $ make You will get an unoptimized (x86-wide) core. > I don't know if I mention it - but that happends also with the > standard 0.9 version (not only with the JIT version)... yet same > error... Does it also fail in --enable-addressing=banks mode? > Other suggestions? Is it a stock RH-7.2 installation? Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 23:23:20
|
ARRRRGGGGHHHH! It's still doesn't help - so it's not the optimization part. I don't know if I mention it - but that happends also with the standard 0.9 version (not only with the JIT version)... yet same error... Makefile enclosed. Other suggestions? Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 23:13:10
|
> I enclose a gzipped copy of the Makefile after the modification. Could
> you
> tell me if I did ok please?
Hmm, not really. You have:
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
$(OBJ_DIR)/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
instead of
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
/bin/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
there is no cat program in the obj/ directory. ;-) then make clean; make
> Oh? I thought that they did heavy optimization and made it proprietary.
Actually, AFAIK, this is still UAE-JIT inside but for QNX. As such,
source has to be provided. H&P actually *removed* an optimization they
say is bogus but without providing a hint at what the problem is
exactly, despite a vague note about ADDI/SUBI.
Their core is based on Bernie's latest snapshot released before he went
on holidays nearly one year ago. Since, there were little bug fixes
(register allocator, shift/rotate instructions).
B2/JIT includes all of that and keeps the above-mentioned optimization
and even other fixes not yet available in Amithlon. e.g. a little fix to
the JIT/FPU code generation on non-P6+ cores, more complete 68040 MOVE16
translations. I keep in touch with Bernie for any updates from him or
myself.
> The Amithlon 68k engine is wildly fast - it's showing like 1Ghz 68040
> processor.
> Do u think your JIT can achive this performance????
I will say the core is basically the same but I won't claim such a
thing. Fact is that it's indeed fast. Speedometer 4.x integer tests on a
Pentium III/800 show performance in between 10x-20x as of a Quadra
605/LC 475 (68040 @ 25 MHz). Other reports showed B2/JIT faster than
Executor too.
Your mileage may vary. However, memory usage is quite huge now. :-/ i.e.
for a 8 MB translation cache size (recommended value), you will need an
extra 8 MB for internal data structures of the JIT engine. Plus, the
usual B2 requirements which are: <RAM size> + <ROM size> + more or less
1 MB for various tables and other scratch memory areas. Yes, that's
fatty and this is unlikely to change.
Bye,
Gwenole (really going to sleep that time)
|
|
From: Gwenole B. <gb...@di...> - 2002-01-16 23:10:24
|
> I enclose a gzipped copy of the Makefile after the modification. Could
> you
> tell me if I did ok please?
Hmm, not really. You have:
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
$(OBJ_DIR)/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
instead of
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
/bin/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
there is no cat program in the obj/ directory. ;-) then make clean; make
> Oh? I thought that they did heavy optimization and made it proprietary.
Actually, AFAIK, this is still UAE-JIT inside but for QNX. As such,
source has to be provided. H&P actually *removed* an optimization they
say is bogus but without providing a hint at what the problem is
exactly, despite a vague note about ADDI/SUBI.
Their core is based on Bernie's latest snapshot released before he went
on holidays nearly one year ago. Since, there were little bug fixes
(register allocator, shift/rotate instructions).
B2/JIT includes all of that and keeps the above-mentioned optimization
and even other fixes not yet available in Amithlon. e.g. a little fix to
the JIT/FPU code generation on non-P6+ cores, more complete 68040 MOVE16
translations. I keep in touch with Bernie for any updates from him or
myself.
> The Amithlon 68k engine is wildly fast - it's showing like 1Ghz 68040
> processor.
> Do u think your JIT can achive this performance????
I will say the core is basically the same but I won't claim such a
thing. Fact is that it's indeed fast. Speedometer 4.x integer tests on a
Pentium III/800 show performance in between 10x-20x as of a Quadra
605/LC 475 (68040 @ 25 MHz). Other reports showed B2/JIT faster than
Executor too.
Your mileage may vary. However, memory usage is quite huge now. :-/ i.e.
for a 8 MB translation cache size (recommended value), you will need an
extra 8 MB for internal data structures of the JIT engine. Plus, the
usual B2 requirements which are: <RAM size> + <ROM size> + more or less
1 MB for various tables and other scratch memory areas. Yes, that's
fatty and this is unlikely to change.
Bye,
Gwenole (really going to sleep that time)
|
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 22:10:52
|
> Makefile (gzipped) enclosed. And I forgot to mention - it still does give the same problem with the Makefile I attached. ./BasiliskII Basilisk II V1.0 by Christian Bauer et al. ScratchMem starts at 0x44617000 (+/- 32 KB) Mac RAM starts at 0x4050f000 (00000000) Mac ROM starts at 0x4450f000 (04000000) Reading ROM file... Using /dev/dsp audio output LMGlob Ofs/4 Base 0x01d4 2 0x50f00000 0x01d8 3 0x50f04000 0x01dc 4 0x50f04000 0x01d8 17 0x50f0c020 0x01dc 17 0x04108000 0x01e0 5 0x50f16000 0x01e0 16 0x50f1e020 0x0b0a 6 0x00000000 0x0312 6 0x04108000 0x0266 7 0x00000000 0x0c00 8 0x50f10000 0x0c04 9 0x50f12000 0x0c08 10 0x50f06000 0x0cec 11 0x50f02000 0x0cc0 12 0x50f14000 0x0cec 13 0x50f26000 0x0c00 15 0x50f18000 0x0c04 15 0x04108000 0x0c08 15 0x04108000 0x0cec 18 0x00000000 do_handle_screen_fault: unhandled address 0x44ae0380 [IP=0x80cea47] D0: 00000000 D1: fffcffff D2: fffffffc D3: 0400000f D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000 A0: 0000003c A1: 00000002 A2: 00006bd0 A3: 00006fdc A4: 000067c4 A5: 045d1380 A6: 00000000 A7: 020009a6 USP=00000000 ISP=020009a6 MSP=00000000 VBR=00000000 T=00 S=1 M=0 X=1 N=1 Z=0 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 0402e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4 next PC: 0402e8ea Here is my config file: Unix]$ cat /home/hetz/.basilisk_ii_prefs disk /home/hetz/mac-emu/Basilisk_Linux_disk.dsk extfs / screen win/512/384 seriala /dev/ttyS0 serialb /dev/lp0 udptunnel true udpport 6066 rom /home/hetz/mac-emu/quadra.rom bootdrive 0 bootdriver 0 ramsize 67108864 frameskip 6 modelid 14 cpu 3 fpu true nocdrom true nosound false noclipconversion false nogui false keycodes true mousewheelmode 1 mousewheellines 3 Hetz |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 22:05:27
|
> Sorry, I don't have the Makefile handy but there are rules looking as: > > cpufast5.s: <dependencies> > <generation of cputmp5.s> > $(OBJ_DIR)/cpuopti < cputmp5.s >$@ || ... > rm -f cputmp5.s I enclose a gzipped copy of the Makefile after the modification. Could you tell me if I did ok please? > Replace $(OBJ_DIR)/cpuopti with a simple "cat" so that cpuopti is not > used. Indeed, it could be that cpuopti removes too many instructions > nowadays or registers are not properly saved in newcpu/m68k_run_1() > before the call to the instruction handler. > > Anyway, I will probably get rid of cpuopti for B2 1.0 if the JIT > compiler were to be integrated. Oh, please do, from my experience with other emulators that used JIT - it's a great thing... > > BTW, please also consider the use of gcc3, for example. Well, right now I'm in the middle of testing a better kernel for my needs. 2.4.17 sucks when you heavy overload it. Seems like 2.4.18-pre3-ac2 can do the job, still testing... > > BTW: Any chance that the JIT will be merge into the 1.0 branch? > > Once those are fixed, we can consider the integration. Note that the > latest B2/JIT is actually merged with the core from AmigaXL/Amithlon > from mid/late December 2001. i.e. probably production-quality. Oh? I thought that they did heavy optimization and made it proprietary. The Amithlon 68k engine is wildly fast - it's showing like 1Ghz 68040 processor. Do u think your JIT can achive this performance???? Makefile (gzipped) enclosed. Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 21:46:27
|
>> In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti >> used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti >> pass. > > I'm affraid I don't understand you well, could you give me an example > from > what to what to change please? Sorry, I don't have the Makefile handy but there are rules looking as: cpufast5.s: <dependencies> <generation of cputmp5.s> $(OBJ_DIR)/cpuopti < cputmp5.s >$@ || ... rm -f cputmp5.s Replace $(OBJ_DIR)/cpuopti with a simple "cat" so that cpuopti is not used. Indeed, it could be that cpuopti removes too many instructions nowadays or registers are not properly saved in newcpu/m68k_run_1() before the call to the instruction handler. Anyway, I will probably get rid of cpuopti for B2 1.0 if the JIT compiler were to be integrated. BTW, please also consider the use of gcc3, for example. > BTW: Any chance that the JIT will be merge into the 1.0 branch? There are currently 3 problems (not necessarily JIT-related): - B2/JIT crashes just after the FPU tests from Speedometer 3.x under MacOS 8.x on a Pentium III but not on a K6-2 for example. - The APD (Apple Personal Diagnostics) crash at start in either version of B2 (JIT or non-JIT) and either fpu core (original UAE, "IEEE", x86 optimized) in 68040 emulation mode but not in 68030+FPU. - The problem you are facing right now. :-) Once those are fixed, we can consider the integration. Note that the latest B2/JIT is actually merged with the core from AmigaXL/Amithlon from mid/late December 2001. i.e. probably production-quality. Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 19:21:28
|
> -fno-merge-constants is mandatory with "2.96"-RH/MDK, 3.0-RH/MDK, or FSF > 3.1. Probably due to a bug in the constants merging code. I have yet to > check with the current gcc 3.1 snapshots. Otherwise, B2 indeed crashes. > > Please try with s/-O2/-O0/ and keep -fno-merge-constants. Didn't help, same error. > > > I tried to compile with and without DGA support - same error. > > Sorry, I meant at runtime. ;-) OK ;) > > > Actually, it doesn't work well - I get on the "mac" - "sorry, a system > > error occured. "system" "illegal instruction" > > And on the console: Illegal instruction: 000b at 00034888 > > Thats on the 68030 with FPU, or with 68040. With the 68040 mode I get at > > the console: Illegal instruction: 000b at 0003c9dc > > Hmmm, then probably a cpu core bug. Please try this one: > > In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti > used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti pass. I'm affraid I don't understand you well, could you give me an example from what to what to change please? > > > I'm on IRC in irc.kde.org server (on channel #winehq) - feel free to > > contact me and I'll let you in to 1 of my machines if you want to test or > > change B2.. > > Sorry, I have another idea but I really have to go now. Sure, thanks for your assistance. BTW: Any chance that the JIT will be merge into the 1.0 branch? as soon as there will be basilisk II 1.0 (that also works for me) I'll publish it on slashdot - I can promise you that (I'm a slashdot author under the nick HeUnique). ;) Hetz |
|
From: Hetz B. H. <he...@kd...> - 2002-01-16 19:17:48
|
> -fno-merge-constants is mandatory with "2.96"-RH/MDK, 3.0-RH/MDK, or FSF > 3.1. Probably due to a bug in the constants merging code. I have yet to > check with the current gcc 3.1 snapshots. Otherwise, B2 indeed crashes. > > Please try with s/-O2/-O0/ and keep -fno-merge-constants. Didn't help, same error. > > > I tried to compile with and without DGA support - same error. > > Sorry, I meant at runtime. ;-) OK ;) > > > Actually, it doesn't work well - I get on the "mac" - "sorry, a system > > error occured. "system" "illegal instruction" > > And on the console: Illegal instruction: 000b at 00034888 > > Thats on the 68030 with FPU, or with 68040. With the 68040 mode I get at > > the console: Illegal instruction: 000b at 0003c9dc > > Hmmm, then probably a cpu core bug. Please try this one: > > In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti > used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti pass. I'm affraid I don't understand you well, could you give me an example from what to what to change please? > > > I'm on IRC in irc.kde.org server (on channel #winehq) - feel free to > > contact me and I'll let you in to 1 of my machines if you want to test or > > change B2.. > > Sorry, I have another idea but I really have to go now. Sure, thanks for your assistance. BTW: Any chance that the JIT will be merge into the 1.0 branch? as soon as there will be basilisk II 1.0 (that also works for me) I'll publish it on slashdot - I can promise you that (I'm a slashdot author under the nick HeUnique). ;) Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 18:44:14
|
On Wed, 16 Jan 2002, Hetz Ben Hamo wrote: > > Probably "someone" is trying to access above the SratchMemory area. It > > could be a compiler bug too. Please try compiling with optimizations off > > (edit the CXXFLAGS in Makefile). > > CXXFLAGS = -O2 -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 > -fno-merge-constants > ^^ thats what I modified, which brings the same problem (same error). > removing also the -fno-merge-constants make B2 screams "floating point > exception". -fno-merge-constants is mandatory with "2.96"-RH/MDK, 3.0-RH/MDK, or FSF 3.1. Probably due to a bug in the constants merging code. I have yet to check with the current gcc 3.1 snapshots. Otherwise, B2 indeed crashes. Please try with s/-O2/-O0/ and keep -fno-merge-constants. > I tried to compile with and without DGA support - same error. Sorry, I meant at runtime. ;-) > Actually, it doesn't work well - I get on the "mac" - "sorry, a system error > occured. "system" "illegal instruction" > And on the console: Illegal instruction: 000b at 00034888 > Thats on the 68030 with FPU, or with 68040. With the 68040 mode I get at the > console: Illegal instruction: 000b at 0003c9dc Hmmm, then probably a cpu core bug. Please try this one: In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti pass. > I'm on IRC in irc.kde.org server (on channel #winehq) - feel free to contact > me and I'll let you in to 1 of my machines if you want to test or change B2.. Sorry, I have another idea but I really have to go now. Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 18:26:51
|
> Probably "someone" is trying to access above the SratchMemory area. It > could be a compiler bug too. Please try compiling with optimizations off > (edit the CXXFLAGS in Makefile). CXXFLAGS = -O2 -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 -fno-merge-constants ^^ thats what I modified, which brings the same problem (same error). removing also the -fno-merge-constants make B2 screams "floating point exception". > > Playing with the .basilisk_ii_prefs file didn't help much, also tried > > several ROMs of Quadra, Performa, different processors emulation - didn't > > help a single bit. > > Are you operating in windowed mode or DGA? Still crashes even in 68030 > mode with/without FPU? I tried to compile with and without DGA support - same error. > > > The problem appear on version 0.9, current CVS snapshot, and the JIT > > version. It doesn't appear on the 0.8 version. > > > > BTW: the configure script seems to have some problems: trying to disable > > ESD (I'm using KDE) or VSOF (for testing) simply doesn't work. > > VOSF is mandatory for Direct and Real Addressing modes. B2 will work for > you if configured with --enable-addressing=banks. But that's not an > option, it has to work in other modes too. Actually, it doesn't work well - I get on the "mac" - "sorry, a system error occured. "system" "illegal instruction" And on the console: Illegal instruction: 000b at 00034888 Thats on the 68030 with FPU, or with 68040. With the 68040 mode I get at the console: Illegal instruction: 000b at 0003c9dc > I am looking forward to helping you but I can't reproduce here on my > system (Mandrake Linux 8.1 or Cooker). So may I suggest you compile B2 > with cxmon builtin and the attached patch? > > Have you tried with --diable-xf86-vidmode ? --enable-fpe=uae ? ./configure --disable-xf86-vidmode --enable-fpe=uae --disable-xf86-dga gives the exact same error. Now trying with your patch: Output of standard configure without any parameters: Unix]$ ./BasiliskII Basilisk II V1.0 by Christian Bauer et al. ScratchMem starts at 0x44617000 (+/- 32 KB) Mac RAM starts at 0x4050f000 (00000000) Mac ROM starts at 0x4450f000 (04000000) Reading ROM file... Using /dev/dsp audio output LMGlob Ofs/4 Base 0x01d4 2 0x50f00000 0x01d8 3 0x50f04000 0x01dc 4 0x50f04000 0x01d8 17 0x50f0c020 0x01dc 17 0x04108000 0x01e0 5 0x50f16000 0x01e0 16 0x50f1e020 0x0b0a 6 0x00000000 0x0312 6 0x04108000 0x0266 7 0x00000000 0x0c00 8 0x50f10000 0x0c04 9 0x50f12000 0x0c08 10 0x50f06000 0x0cec 11 0x50f02000 0x0cc0 12 0x50f14000 0x0cec 13 0x50f26000 0x0c00 15 0x50f18000 0x0c04 15 0x04108000 0x0c08 15 0x04108000 0x0cec 18 0x00000000 do_handle_screen_fault: unhandled address 0x44ae0380 [IP=0x80a17cc] D0: 00000000 D1: fffcffff D2: fffffffc D3: 0400000f D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000 A0: 0000003c A1: 00000002 A2: 00006bd0 A3: 00006fdc A4: 000067c4 A5: 045d1380 A6: 00000000 A7: 020009a6 USP=00000000 ISP=020009a6 MSP=00000000 VBR=00000000 T=00 S=1 M=0 X=1 N=1 Z=0 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 0402e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4 next PC: 0402e8ea testing: ./configure --disable-xf86-vidmode --enable-fpe=uae --disable-xf86-dga (with your patch): Unix]$ ./BasiliskII Basilisk II V1.0 by Christian Bauer et al. ScratchMem starts at 0x44617000 (+/- 32 KB) Mac RAM starts at 0x4050f000 (00000000) Mac ROM starts at 0x4450f000 (04000000) Reading ROM file... Using /dev/dsp audio output LMGlob Ofs/4 Base 0x01d4 2 0x50f00000 0x01d8 3 0x50f04000 0x01dc 4 0x50f04000 0x01d8 17 0x50f0c020 0x01dc 17 0x04108000 0x01e0 5 0x50f16000 0x01e0 16 0x50f1e020 0x0b0a 6 0x00000000 0x0312 6 0x04108000 0x0266 7 0x00000000 0x0c00 8 0x50f10000 0x0c04 9 0x50f12000 0x0c08 10 0x50f06000 0x0cec 11 0x50f02000 0x0cc0 12 0x50f14000 0x0cec 13 0x50f26000 0x0c00 15 0x50f18000 0x0c04 15 0x04108000 0x0c08 15 0x04108000 0x0cec 18 0x00000000 do_handle_screen_fault: unhandled address 0x44ae0380 [IP=0x809b5d4] D0: 00000000 D1: fffcffff D2: fffffffc D3: 0400000f D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000 A0: 0000003c A1: 00000002 A2: 00006d14 A3: 00007120 A4: 00006908 A5: 045d1380 A6: 00000000 A7: 020009a6 USP=00000000 ISP=020009a6 MSP=00000000 VBR=00000000 T=00 S=1 M=0 X=1 N=1 Z=0 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 0402e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4 next PC: 0402e8ea Segmentation fault Any other ideas? I'm on IRC in irc.kde.org server (on channel #winehq) - feel free to contact me and I'll let you in to 1 of my machines if you want to test or change B2.. Thanks, Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 17:22:48
|
On Wed, 16 Jan 2002, Hetz Ben Hamo wrote: > Basilisk goes up, gives black box for few seconds, switches to gray, then > boom: Hmm, interesting. The current bug I am investigating in the one that makes B2 crashes in Direct Addressing mode with Apple Personal diagnostics. It looks related to 68040 emulation as it works under 68030. > Unix]$ BasiliskII > Basilisk II V1.0 by Christian Bauer et al. > Reading ROM file... > Using /dev/dsp audio output > do_handle_screen_fault: unhandled address 0x42be0380 [IP=0x80a1730] > D0: 00000000 D1: fffcffff D2: fffffffc D3: 0230000f > D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000 > A0: 0000003c A1: 00000002 A2: 00006244 A3: 00006650 > A4: 00005e38 A5: 026d1380 A6: 00000000 A7: 0118fb5a > USP=00000000 ISP=0118fb5a MSP=00000000 VBR=00000000 > T=00 S=1 M=0 X=1 N=1 Z=0 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 > 0232e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4 > next PC: 0232e8ea Probably "someone" is trying to access above the SratchMemory area. It could be a compiler bug too. Please try compiling with optimizations off (edit the CXXFLAGS in Makefile). > Playing with the .basilisk_ii_prefs file didn't help much, also tried several > ROMs of Quadra, Performa, different processors emulation - didn't help a > single bit. Are you operating in windowed mode or DGA? Still crashes even in 68030 mode with/without FPU? > The problem appear on version 0.9, current CVS snapshot, and the JIT version. > It doesn't appear on the 0.8 version. > BTW: the configure script seems to have some problems: trying to disable ESD > (I'm using KDE) or VSOF (for testing) simply doesn't work. VOSF is mandatory for Direct and Real Addressing modes. B2 will work for you if configured with --enable-addressing=banks. But that's not an option, it has to work in other modes too. I am looking forward to helping you but I can't reproduce here on my system (Mandrake Linux 8.1 or Cooker). So may I suggest you compile B2 with cxmon builtin and the attached patch? Have you tried with --diable-xf86-vidmode ? --enable-fpe=uae ? Bye, Gwenole. |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 17:04:57
|
On Wed, 16 Jan 2002, Hetz Ben Hamo wrote: > If I recall correctly, DGA-2 on Linux works great as well as on FreeBSD, but > I doubt if it works on Solaris or even Mac OS X. DGA exists on Solaris with a better API, imho. It also permits you to do windowed DGA but that's trickier. > SDL has been improved a lot (and being used a lot by Loki Game ports which > all of them use SDL) and I think it could be an excellent replacement to what > we have today with the DGA. Yes, but the limiting factor, IIRC, is that SDL doesn't support 1-bit screens. Yeah, what about implementing that into SDL then? Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 16:51:00
|
On 11/25/2001, Gwenole Beauchesne wrote: "Usual tricks (VOSF, Direct Addressing) for the Unix port will be ported to MacOS X later. Those two hacks are sufficient to bring up to 2x performance improvement. Should it be enough ? Is there anyway to do sort of DGA (Direct Graphic Access) ? Eventually, someone may want to check SDL sources out." Excuse me, but isn't that a bit strange? If I recall correctly, DGA-2 on Linux works great as well as on FreeBSD, but I doubt if it works on Solaris or even Mac OS X. OTOH, SDL is available on Linux, BSD, Irix, Win32, BeOS, Mac OS (classic), Mac OS X, and even AmigaOS. SDL has been improved a lot (and being used a lot by Loki Game ports which all of them use SDL) and I think it could be an excellent replacement to what we have today with the DGA. It also means you could finally join many ports (Unix & Win32) since SDL is available for both of them and saving quite a lot of work.. It also supports all the DGA extensions (even Xv). Just my thoughts ;) Hetz |
9 messages has been excluded from this view by a project administrator.
