basilisk-devel — Basilisk II development-related discussion

[B2-devel] patch: subprocess as serial port

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

Everyone,

I have a (very) preliminary version of a patch which provides a way to
pipe serial input/output to programs instead of actual ports, as
requested in the second-to-last item of the "TODO" file.  Here's a
URL:

  ftp://ftp.frontiernet.net/pub/users/brianj1/B2_pty_020506.patch

(I'm not sure if this will work directly as input to patch; I had some
trouble with "cvs rdiff" and had to manually edit things a bit.)

Just put a pipe character ("|") at the beginning of the port device
file name, and BII will allocate a pseudoterminal, connect the master
side to the BII serial infrastructure, and run the rest of the port
device file name as a program using "/bin/sh -c", with the slave side
of the pty as its standard input, output, and error.  I.e. BII will
treat the process as a serial port, and the process will think it's
talking to a normal terminal.

On IRIX, the only platform I've tried, I can (sort of) open tcsh and
get a shell prompt.  I think the pty needs some slave-side
configuration to get everything working right.  But I can open a PPP
daemon (via a shell script to set the correct environment variables)
and talk TCP/IP between the Mac and the host.  It works great:  the
host takes care of routing among the Mac, the host, and remote
machines, so the Mac can connect to any machine the host can.  Now all
I have to do is upgrade to a version of MacOS which supports Appletalk
over IP....  Way cool.

The code in pty.c is stolen from GNU screen.  I probably need to steal
their slave-side setup code as well... it's big and ugly, though.  I
just hope it doesn't lead to too much autoconf madness.

Some questions:
- How should BII call wait() to clean up after the subprocess exits?
  From the serial port close handler?  From a separate pthread (so it
  can block)?  Currently I don't call it at all.
- Should I automatically drop privileges in the subprocess if BII is
  running setuid?  What's the philosophy for making BII
  security-conscious vs. just documenting the issues and saying, "if
  you install BII as setuid, you do so at your own risk"?
- Any other security concerns?
- Is the current code structure OK, or would you prefer that I move
  the PTY setup/fork/exec/etc. into a subroutine?

I also added a hook for midi support:  if the device name is "midi",
it's treated specially (returns an error for now).  I have no idea if
Mac MIDI drivers actually use the serial manager, or if this is the
best way to add MIDI to BasiliskII.  Or if I'll get around to finding
out within the next couple of years....

						Brian J. Johnson

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

   "The public needs NREN because 300 baud used to be fast and low-
    resolution graphics used to be pretty....  We wait impatiently,
    sure that we spend half our lives waiting for printers, and the
    other half waiting for disk drives.  Time is a commodity."
                                           -- Jean Armour Polly

[B2-devel] Re: New monitor stuff (was Re: Mac OS X fullscreen)

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

> vector<video_modes> my_modes;
> my_modes.push_back(...);
> my_modes.push_back(...);
> ...
> VideoMonitors.push_bach(new Foo_monitor_desc(my_modes), ...);

	That sort of misses out filling in each video_mode structure,
but yes, that is what I am currently using. It just seems strange
to build up a list of modes just for the purpose of copying them
into the base class's protected data space.


> Couldn't be any easier. :-)

	Well, I was proposing:

// for each display
{
     Foo_monitor_desc  *mon =3D new =
Foo_monitor_desc(currentDepth(display),
                                                      =
displayId(display));
     VideoMonitors.push_back(mon);


     int32 id=3D0x80;

     // for each mode of display
     {
         // if resolution differs from previous
             ++id;

         mon->add_mode(mode->x, mode->y, id,
                       mode->bytes_per_row, mode->depth);
     }
}

	That way, I don't need a static vector<video_mode>,
nor a static void add_mode() to build it up.


> You can even reuse the my_modes vector
> if monitors support the same set of modes.

	One man's positive is another's negative, I guess :-)

(In my case, I need to reset the vector for each monitor)

--
|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] New monitor stuff (was Re: Mac OS X fullscreen)

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

Hi!

On 2002.04.30 03:14 Nigel Pearson wrote:
> There is now a list of modes per monitor, but the
> only way to set this list up is at class construction time.

vector<video_modes> my_modes;
my_modes.push_back(...);
my_modes.push_back(...);
...
VideoMonitors.push_bach(new Foo_monitor_desc(my_modes), ...);

Couldn't be any easier. :-) You can even reuse the my_modes vector
if monitors support the same set of modes.

Bye,
Christian

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

[B2-devel] New monitor stuff (was Re: Mac OS X fullscreen)

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

	Trying to implement the new "class monitor_desc" stuff,
I am a little confused about how to store a monitor's modes.


Christian previously proposed:

> 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:
>
>     class monitor_desc {
>     public:
...
>       // Get current video mode
>       const video_mode &current_mode(void) const {return =
*current_mode;}
...
>       // List of supported video modes
>       vector<video_mode> modes;
...
>     }


	video_*.cpp for AmigaOS, MacOSX and Unix used to find out the
modes supported by the main monitor, and then store each of those
using add_mode(). There is now a list of modes per monitor, but the
only way to set this list up is at class construction time.


	I think it would be easier if the base class had an method to
add modes for that particular instance of the monitor. That way, we
just need a loop that iterates monitors, creates new *_monitor_desc
object for each monitor, and then adds the modes supported by that
monitor to the object's list.


	So, any chance of something like:

// Add mode to list of supported modes
void monitor_desc::add_mode (uint32 width,
                              uint32 height,
                              uint32 resolution_id,
                              uint32 bytes_per_row, video_depth depth)
{
         video_mode mode;
         mode.x =3D width;
         mode.y =3D height;
         mode.resolution_id =3D resolution_id;
         mode.bytes_per_row =3D bytes_per_row;
         mode.depth =3D depth;
         modes.push_back(mode);
}

--
|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] SheepShaver sources in CVS

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

Hi,

>> Do you want to take a look at the current sources?
> Yep.

<http://gwenole.beauchesne.online.fr/sheepshaver/patches/>
Files: gmo_cpu.patch and gmo_cpu.tar.bz2

1) The patch simply adds some configury and [U]VAL64 macros to 
<sysdeps.h>. Note that I deliberately disable detection of the ppc 
processor (see __DISABLE bits).

2) The tarball contains the actual emulator sources slightly modified 
from the original ppc750sim-1.0 package. Note that the purpose of this 
test emulator is not speed but to have something that is known to work 
and thus making design choices for the SheepShaver PPC emulator.

Bye,
Gwenole.

Re: [B2-devel] SheepShaver sources in CVS

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

Hi!

On 2002.04.24 21:57 Gwenole Beauchesne wrote:
>> The "emul_ppc" directory contains a partially implemented PPC opcode
>> interpreter but it can't boot MacOS yet
> 
> Could you tell me why please?

I wish I could. :-)

I'm seeing this:

SIGSEGV
  r0 00000000   r1 68fff748   r2 00000000   r3 200236af
  r4 00000000   r5 00000861   r6 00000000   r7 ffffff80
  r8 00000081   r9 00000000  r10 20000000  r11 00000270
r12 00000861  r13 00000000  r14 00000000  r15 00000000
r16 20022ece  r17 20005930  r18 2000342e  r19 40861870
r20 00000000  r21 20ffff88  r22 00000000  r23 00000000
r24 00000014  r25 00000020  r26 00000000  r27 00004080
r28 00000000  r29 40c98d20  r30 40c60000  r31 68fff000
  lr 40c98d20  ctr 40c60200   cr 20101023  xer 00000000
  pc 40c98d24 fpscr 00000000

Appearently, it tries to execute 68k code at or near address 0x14.
Reason as of yet unknown (I wasn't able to figure it out after
two hours of debugging and gave up). Maybe there's some subtle
bug in the PPC emulation or in the ROM patches.

> Actually, I integrated the alternate PowerPC 750 emulator and filled in 
> missing bits with those from the current core in SheepShaver. It no longer 
> crashes but goes to nowhere. i.e. screen remains black after a certain 
> amount of time.

That sounds promising. If you add a thread that just increments 0x16a,
it might actually start booting.

> [interrupts]
> Talking about those, I wonder how it should be implemented. Technical Note 
> TN1137 says that the MacOS interrupt architecture on PPC emulates the one 
> on m68k.

BeOS/main_beos.cpp has a comment at the top that explains how interrupts
work (also, grep for SIGUSR1). This might actually be easier on an emulated
PPC.

> Do you want to take a look at the current sources?

Yep.

Bye,
Christian

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

Re: [B2-devel] SheepShaver sources in CVS

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

Hi,

> The "emul_ppc" directory contains a partially implemented PPC opcode
> interpreter but it can't boot MacOS yet

Could you tell me why please? I do run into a crash at boot but I wonder 
if this is the problem you mentionned.

Actually, I integrated the alternate PowerPC 750 emulator and filled in 
missing bits with those from the current core in SheepShaver. It no 
longer crashes but goes to nowhere. i.e. screen remains black after a 
certain amount of time. This is probably due to the fact that there is 
no handling of interrupts, hence no video refresh. Quite problematic. ;-)

Talking about those, I wonder how it should be implemented. Technical 
Note TN1137 says that the MacOS interrupt architecture on PPC emulates 
the one on m68k. That doesn't tell me much as I am only a poor 
user-level implementor.

Do you want to take a look at the current sources? I'd probably have to 
give PSIM a try but it's quite big nevertheless complete.

Bye,
Gwenole.

[B2-devel] There goes the neighbourhood...

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

Okay, start laughing...
I accidently deleted about half of my Linux system,
 including some important files and the BasiliskII sources
 (which also included my GUI stuff). I, ofcourse, couldn't
 use it anymore because my /lib and /bin dirs have been
 totally wiped out. I was damn lucky my own project was
 still there. (just a silly game I used to try some
 graphical stuff)
Mr. Wiseguy here thought using root as the main account
 wouldn't do harm. (well, hey, it was my computer, not
 connected to any other computers and nobody else uses it,
 nothing like this happened to me before)

I'll probably have a new linux system setup in a few days,
 though I don't if I'm gonna start over on the GUI thing. I
 don't think I'll have it done before 1.0 anymore, sorry.
 :/

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

Re: [B2-devel] SheepShaver patches

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

Hi!

On Tue, Apr 09, 2002 at 07:51:01PM +0200, Gwenole Beauchesne wrote:
> * File: romtype_gossamer.patch

Ok.

> - Nvram3+ patch locations seem real magic numbers to me. How did you get 
> them for TNT, Gazelle, etc. ?

I don't remember. I think I looked for similar code fragments.

> * File: decode_parcels.patch

Ok.

> * File: check_termcap_first.patch

Ok.

> * File: sheep_threads.patch

Ok, I guess (maybe I should update my Linux/ppc installation).

> * File: video_15bit.patch

Ok. Eventually, the whole graphics subsystem should be replaced by the B2 one.

Bye,
Christian

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

Re: [B2-devel] JIT Compiler for B2/1.0?

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

Hi!

On Mon, Apr 15, 2002 at 10:51:38PM +0200, Gwenole Beauchesne wrote:
> Christian, is it OK for you?

Yes.

Bye,
Christian

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

Re: [B2-devel] JIT Compiler for B2/1.0?

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

Ho, ho ho...

Wait a minute - I think I tried it a while ago and when the JIT engine was 
enable - It gave me garbage whenever I moved the mouse and as an extra bonus 
- some vertical lines on the emulated screen...

Would you be kind enough to point me to a CVS Snapshot so I can try it before 
you commit please? I promise to report bugs ASAP...

Thanks,
Hetz

On Monday 15 April 2002 11:51 pm, Gwenole Beauchesne wrote:
> Hi,
>
> If nobody objects, I will integrate the JIT compiler for Basilisk II
> 1.0. I believe it is stable enough now. Supported tagets are Linux/x86
> and FreeBSD/x86 [*]. The previous bugs I came by are fixed, namely the
> crash in Speedometer 3.23.
>
> Christian, is it OK for you?
>
> The other problems I had are not JIT specific:
> 1) Crash when starting Apple Personal Diagnostics. Problem gone when I
> upgraded from MacOS 8.0 to MacOS 8.1.
> 2) Fullscreen DGA does not work with DirectColor visuals, at least for
> me.
>
> [*] FreeBSD support is based on user reports since my FreeBSD partition
> is dead now.
>
> Bye,
> Gwenole.
>
>
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] JIT Compiler for B2/1.0?

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

Hi,

If nobody objects, I will integrate the JIT compiler for Basilisk II 
1.0. I believe it is stable enough now. Supported tagets are Linux/x86 
and FreeBSD/x86 [*]. The previous bugs I came by are fixed, namely the 
crash in Speedometer 3.23.

Christian, is it OK for you?

The other problems I had are not JIT specific:
1) Crash when starting Apple Personal Diagnostics. Problem gone when I 
upgraded from MacOS 8.0 to MacOS 8.1.
2) Fullscreen DGA does not work with DirectColor visuals, at least for 
me.

[*] FreeBSD support is based on user reports since my FreeBSD partition 
is dead now.

Bye,
Gwenole.

Re: [B2-devel] 3 questions

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

Hi,

> I'm following this list and I've seen some emails mentioning further
> development of B2 to run OS 8.6 and 9.x - is this for the X86 platform? 
> if
> so, whats it current status?

This is not B2 but SheepShaver, though it now shares around 80% of B2 
sources, IIRC. SheepShaver is a runtime environment to run MacOS on PPC 
machines. If it can be extended to work with my (ROM, OS) couples then 
it will likely be extended with a software PowerPC emulator for 
non-native ports.

I am currently reworking the rom_patches so that they could be more 
generic and hopefully work with my NewWorld ROMs (MacOS 8.6+). I have 
just had a hacking party with NOP'ing instructions that check the 
performance monitor and other (unknown to me) SPRs, namely 944 and 951. 
I am almost finished with patch_nanokernel_boot() now.

> Another question - is there an open source or commercial Mac emulator 
> that
> emulates PowerPC chip and can run OS 9 that you know of?

I don't know of any that is available yet. Samuel from the Mac-on-Linux 
project also plans to add a PPC emulator. But I'd prefer contributing to 
SheepShaver since it has a higher-level and more challenging emulation 
engine.

> Last question (this one for Gwenole) - any chance that the JIT 
> modifications
> will be soon rolled into the main B2 tree?

Ah yes, I forgot to check for something about that today. I am willing 
to include the JIT compiler to B2 1.0 since it is stable enough for me. 
Besides, the JIT core is already used in "production", as far as AmigaXL 
(and Amithlon) is concerned. Indeed, I merged with their latest publicly 
available code. Besides, there will probably be more people testing it 
that way.

Bye,
Gwenole.

Re: [B2-devel] A really weird bug

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

Hi,

> If B2 crashes and I try to restart it with my hard disk image - it 
> doesn't
> boot. I need to start my CDROM Mac Boot CD, shut it down, and then my 
> hard
> disk image will boot...

1) B2 should not crash. ;-)
2) Have you tried moving/deleting the xpram file (~/.basilisk_ii_xpram)?

Bye,
Gwenole

[B2-devel] A really weird bug

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

Hi,

I've seen this bug few times and I don't know if I had reported it...

If B2 crashes and I try to restart it with my hard disk image - it doesn't 
boot. I need to start my CDROM Mac Boot CD, shut it down, and then my hard 
disk image will boot...

Any suggestions for this problem?

Thanks,
Hetz

[B2-devel] 3 questions

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

Hi people,

I'm following this list and I've seen some emails mentioning further 
development of B2 to run OS 8.6 and 9.x - is this for the X86 platform? if 
so, whats it current status?

Another question - is there an open source or commercial Mac emulator that 
emulates PowerPC chip and can run OS 9 that you know of? 

Last question (this one for Gwenole) - any chance that the JIT modifications 
will be soon rolled into the main B2 tree?

Thanks,
Hetz

Re: [B2-devel] Supporting MacOS 9.X ROMs

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

Hi,

>> 3) I noticed that there are many assumptions that specific code to be
>> patched is to be found at some specified offset.
>
> Well, they all were at these offsets in the ROMs I had. :-)

Sure but this is not compatible with me then. ;-)
Anyway, I started to convert that to a generic approach 
(generic_rom_patches.patch).

Bye,
Gwenole

Re: [B2-devel] Supporting MacOS 9.X ROMs

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

Hi!

On Tue, Apr 09, 2002 at 12:39:01AM +0200, Gwenole Beauchesne wrote:
> Would it be possible to move the ROM image decompression from
> system-specific parts (Unix/main_unix.cpp, BeOS/main_beos.cpp) to a common
> place such as rom_patches.cpp?

This would be better.

> 2) At some point it might be preferable to differentiate the old 
> NewWorld ROM that is fully LZSS compressed from the new NewWorld ROM 
> that is parcels-based.

Yup.

> 3) I noticed that there are many assumptions that specific code to be 
> patched is to be found at some specified offset.

Well, they all were at these offsets in the ROMs I had. :-)

> 4) Could it be possible to have SheepShaver CVS commits forwarded to 
> basilisk-cvs@ too ?

This should work now.

> 5) Do you think that the 'prop' parcels are supposed to be inserted into 
> the decoded ROM image according to the drivers that would have been 
> loaded on the real machine?

I'm only familiar with MacOS <=8 ROMs and I don't know or think anything. :-)

> 6) BTW, what system do you use?

7.6.1, 8.1 and 8.5.

Bye,
Christian

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

[B2-devel] SheepShaver patches

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

Hi,

I placed a few patches to SheepShaver for review at:
<http://gwenole.beauchesne.online.fr/sheepshaver/patches/>

I can commit any of them upon approval.

* File: romtype_gossamer.patch
Attempt support for Gossamer (PowerMac G3 DT) ROM images. Unfortunately, 
it segfaults right at start without any happy mac logo. Current issues 
with it are:
- Nvram3+ patch locations seem real magic numbers to me. How did you get 
them for TNT, Gazelle, etc. ?
- "Don't read PVR from 0x5fffef80 in DriverServicesLib (via 0x316)" is, 
umm, unpatched.

* File: decode_parcels.patch
Patch main_unix.cpp to enable decoding of parcels-based ROM images, 
including MacOS 9.2.X ROMs.

* File: check_termcap_first.patch
Patch configure.in so that puts() in termcap lib is checked before 
readline. Cosmetic change for cxmon.

* File: sheep_threads.patch
Patch Unix/Linux/sheepthreads.c to match current kernel and glibc 
headers here

* File: video_15bit.patch
Minor workaround to get things working on my 15-bit TiBook LCD 
display. ;-)

Bye,
Gwenole.

[B2-devel] Supporting MacOS 9.X ROMs

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

Hi,

I would like to finally have a running MacOS SheepShaver prior to 
integrating the "GM" (Gilles Mouchard) PowerPC 750 emulator, for test 
purposes. Unfortunately, this is far from being done since I still can't 
run the systems I have handy (MacOS 8.6 & MacOS 9.1+). Hereunder are 
random queries I came up with so far.

1) We need to properly decode the ROM image. This is implemented through 
the code I posted earlier. Would it be possible to move the ROM image 
decompression from system-specific parts (Unix/main_unix.cpp, 
BeOS/main_beos.cpp) to a common place such as rom_patches.cpp?

2) At some point it might be preferable to differentiate the old 
NewWorld ROM that is fully LZSS compressed from the new NewWorld ROM 
that is parcels-based. Indeed, it is without surprises that 
patch_nanokernel_boot() currently fails with newer ROMs.

3) I noticed that there are many assumptions that specific code to be 
patched is to be found at some specified offset. However, none of them 
match a ROM v3.8 nor the one from MacOS 9.2. Instead, it could be 
interesting to have things as follows for the first "Don't read PVR", 
for example. Like in Basilisk II, actually.

// Don't read PVR
static const uint8 pvr_read_dat[] = { 0x7d, 0x9f, 0x42, 0xa6 };
if ((base = find_rom_data(0x3103b0, 0x310ab0, pvr_read_dat, 
sizeof(pvr_read_dat))) == 0) return false;
D(bug("pvr_read1 %08lx\n", base));
lp = (uint32 *)(ROM_BASE + base);
if (lp[6] != 0x2c0c0001) {
	if ((base = find_rom_data(base + 4, 0x310ab0, pvr_read_dat, 
sizeof(pvr_read_dat))) == 0) return false;
	D(bug("pvr_read2 %08lx\n", base));
	lp = (uint32 *)(ROM_BASE + base);
	if (lp[6] != 0x2c0c0001)
		return false;
}
*lp = htonl(0x81800000 + XLM_PVR);	// lwz	r12,(theoretical PVR)

4) Could it be possible to have SheepShaver CVS commits forwarded to 
basilisk-cvs@ too ?

5) Do you think that the 'prop' parcels are supposed to be inserted into 
the decoded ROM image according to the drivers that would have been 
loaded on the real machine?

6) BTW, what system do you use? I am getting upset that none of mine 
runs. :-/

Thanks,
Gwenole.

Re: [B2-devel] Compressed NewWorld ROMs

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

Hi!

On Mon, Apr 08, 2002 at 01:01:57AM +0200, Gwenole Beauchesne wrote:
> Feel free to comment.

Sweet. :-)

Bye,
Christian

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

Re: [B2-devel] Compressed NewWorld ROMs

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

Hi,

> Hope that more is coming.

And here is the current implementation. It decodes a MacOS 9.2 ROM quite 
nicely. Now, ROM_BASE + 0x30d064 now yields "NewWorld". I haven't 
integrated it in SheepShaver though.

Caveat: I used ROAM to dump my MacOS 9.2 ROM as probably patched by 
MacOS X. Therefore there are some minor differences in the middle near 
0x256001. But common bits converge again afterwards.

Feel free to comment.

Bye,
Gwenole.

Re: [B2-devel] Compressed NewWorld ROMs

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

Hi,

> decompressing it in the v3.8 ROM case? This would be weird or they 
> probably compressed several hunks/resources independently ? That might 
> explain why in newer ROMs (v3.x), strings|grep -i lzss yield more 
> results than with v1.x ROMs.

That's it and they call that "parcels"! Actually, this kind of ROM can 
be checked for at rom_tmp + lzss_offset and contains 'prcl' there. 
parcelDataCompressionType of a parcel could be 'lzss' or some other type 
I have yet to determine but I'd expect raw copy with no special tag name.

Hope that more is coming.

Bye,
Gwenole.

Re: [B2-devel] Compressed NewWorld ROMs

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

Hi,

> The decoding routine should be somewhere in the ELF part. Maybe you can 
> get
> the parameters from there.

OK, the ROM Trampoline code is generally located at rom_tmp + 
elf_offset + 0x100; I then dumped trampoline code of both v1.6 and v3.8 
NewWorld ROMs. Searching for $0fee (dict_idx) is sucessful in both cases 
and the decompression routines are exactly the same. Besides, what you 
implemented in decode_lzss() turns out to exactly match that code in 
higher level language. ;-)

I came up to the same solution with crf0 - crf2 propagation and partial 
redundancy elimination for run_mask computations. So, I am pretty sure 
the implementation is correct.

There are some differences in the code preceding the call to the 
decompression routine betwen the above-mentioned ROMs. I have not looked 
at them in further details yet but I suspect some pattern is first 
applied to the uncompressed ROM area prior to decompressing it in the 
v3.8 ROM case? This would be weird or they probably compressed several 
hunks/resources independently ? That might explain why in newer ROMs 
(v3.x), strings|grep -i lzss yield more results than with v1.x ROMs.

Bye,
Gwenole

[B2-devel] GTK+ 1.2 or GTK+ 2.0?

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

Hi,
  I'm trying to do some stuff on improving the GUI. Just a
 small question, the old GTK+ 1.2 or GTK+ 2.0? GTK+ 2.0 has
 been released a while ago and includes many improvements
 and new things. (such as truetype font support, better
 native language support, and some fixes, like that
 progress bar you wanted so bad has been made easier to
 handle according to the docs. ;) )
It'll probably take a while until new distributions include
 the new gtk+, probably until GNOME 2.0 has been released,
 because that is based on gtk+ 2.0.
Glade currently doesn't support GTK+ 2.0 either, though
 that only concerns developers, ofcourse. Though this makes
 it also easier the still keep supporting the old gtk.
I'll try to upload some screenshots when I've done some
 work. The fun part will probably be to make it actually
 work. :)

P.S. The site should be updated, the basilisk II forum at
 delphi has been relocated to
 http://forums.delphiforums.com/basilisk2/start
Also Newton's Macintosh emulation page seems to be down.

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