Endeavor to reply please.

[Mrs . Patricia Etteh]

l am MRS. PATRICIA ETTEH, former Speaker House Of Representative Of The Federal 
Republic Of Nigeria, l lost my political position as the speaker of the house, 
due to high level of conspiracy by my fellow colleagues, due to this fact, 
majority of my of assets has to be declared back to the government, what l am 
currently concerned about now are my foreign deposit, if any of these foreign 
deposits are discovered l will automatically loose it to the Government. 

On this note l need your immediate assistance to make an immediate change of 
beneficiary. 
 
Your effort will be rewarded. You can reach me on this email: [EMAIL PROTECTED] 
or [EMAIL PROTECTED]

Regards, 

Patricia Etteh





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Missing m68k builds for the point release

[Luk Claes]

Luk Claes wrote:
> Stephen R Marenka wrote:
>> On Mon, Dec 24, 2007 at 01:21:36PM +0100, Luk Claes wrote:
>>> Hi
>>>
>>> The following m68k builds are still missing for the point release
>>> scheduled Dec. 26th:

Due to some needed regeneration of files, the point release is a bit
delayed (probable a couple of days)...

>>> oldstable-security:
>>> centericq
>> needs-build.

building on crest

>>> qt-x11-free
>> building on kullervo.

I guess it's still building?

>>> samba
>> building on crest.

installed

>>> oldstable:
>>> pwlib
>> needs-build

building

>>> wesnoth
>> needs-build

building

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

aranym vs atafb

[Stephen R Marenka]

Howdy,

I've been trying to get d-i initrds to work with aranym without
trashing the screen [0]. I noticed something interesting in my testing
today.

[0] 

With the same kernel (2.6.18-4) and args ...

Args = root=/dev/ram load_ramdisk=1 ramdisk_size=2 debug=par
video=atafb:vga16 stram_swap=0 console=tty
debian-installer/framebuffer=false init=/bin/sh

The result is a trashed screen when atafb loads.

| atafb: screen_base 0170 real_screen_base 0170 screen_len 311296
| Determined 640x480, depth 4
|virtual 640x972
| Console: switching to colour frame buffer device 80x30


If I drop the Ramdisk = parameter from the aranym config, atafb loads as 
follows, and works just fine.

| atafb: screen_base 00c8 real_screen_base 00c8 screen_len 311296
| Determined 640x480, depth 4
|virtual 640x972
| Console: switching to colour frame buffer device 80x30


I tried all the atafb configurations listed, but I couldn't get a
working result and have a ramdisk. The Floppy setting doesn't trash 
the screen but we don't have any initrd's small enough.

I don't suppose we can build a bootable cdrom for atari?

Any ideas?

Thanks,

Stephen

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

68k & ppc mac motherboards

[DataZap]

Hi,

I have a bunch of older Mac motherboards and stuff. I really hate to throw
them away, so I thought I would offer them here. If anyone is willing to
pay shipping and handling I would be happy to send them. I can't remember
what they are from, but if you are interested, I would be happy to email
some pics.

Thanks,
Al



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: aranym vs atafb

[Michael Schmitz]

Hi,

> I've been trying to get d-i initrds to work with aranym without
> trashing the screen [0]. I noticed something interesting in my testing
> today.
>
> [0] 
>
> With the same kernel (2.6.18-4) and args ...
>
> Args = root=/dev/ram load_ramdisk=1 ramdisk_size=2 debug=par
> video=atafb:vga16 stram_swap=0 console=tty
> debian-installer/framebuffer=false init=/bin/sh
>
> The result is a trashed screen when atafb loads.
>
> | atafb: screen_base 0170 real_screen_base 0170 screen_len 311296
> | Determined 640x480, depth 4
> |virtual 640x972
> | Console: switching to colour frame buffer device 80x30

IIRC any addresses in that range (i.e. above 0xff) are aliased down to
fit in 24 bit (ST-RAM on the Falcon only decodes 24 bit, and the VIDEL
needs to use ST-RAM). Basically, you used up all available ST-RAM with the
ramdisk and now force the framebuffer to use an invalid address (one which
you can perfectly well write to, but the VIDEL cannot read from there).

What you see on the screen is whatever is located at address 0x0070
and thereabouts (may be kernel memory, may be data/buffer cache).

The ramdisk load code needs to make sure a ramdisk is not loaded where it
might interfere with other uses of ST-RAM (i.e. frame buffer or DMA bounce
buffers for SCSI). Where does the ramdisk get loaded at, anyway? Is the
kernel loaded in ST-RAM also?

> If I drop the Ramdisk = parameter from the aranym config, atafb loads as
> follows, and works just fine.
>
> | atafb: screen_base 00c8 real_screen_base 00c8 screen_len 311296
> | Determined 640x480, depth 4
> |virtual 640x972
> | Console: switching to colour frame buffer device 80x30

That screen base address is fine to use for atafb.

> I tried all the atafb configurations listed, but I couldn't get a
> working result and have a ramdisk. The Floppy setting doesn't trash
> the screen but we don't have any initrd's small enough.

We need to load them somewhere else, FWIS. Meaning in TT-RAM.

> I don't suppose we can build a bootable cdrom for atari?

Uh, nope. CD-ROM drivers are a bad can of worms as it were, no idea what
would even be supported by the CT60 (and it's all closed source). Unless
you count booting from MiNT (assuming that can even be done).

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Missing m68k builds for the point release

[Michael Schmitz]

> >>> The following m68k builds are still missing for the point release
> >>> scheduled Dec. 26th:
>
> Due to some needed regeneration of files, the point release is a bit
> delayed (probable a couple of days)...
>
> >>> oldstable:
> >>> pwlib
> >> needs-build
>
> building
>
> >>> wesnoth
> >> needs-build
>
> building

hobbes barfed on it on the first go (forgot to patch sbuild). let's see
how this attempt goes. If anyone else wants to beat me to it, have at it.

Michael



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]