Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables [Bug Reports]

Forum Index

Board index » Development » Bug Reports » Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

Browsing this Thread: 1 Anonymous Users

Bottom

Previous Topic

Next Topic Register To Post

(1) 2 3 »

Anonymous

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#21

We don't need the 3.1 Sources we need the Philosophy!

AROS already came to the Point it is wozhout the Sources, why should we need them now?

salass00

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#20

Home away from home

As far as I'm aware the closest thing to an OS-friendly way of obtaining the seglist of a running process in AmigaOS < 4.0 is to access the SegArray stored in pr_SegList.


struct SegArray {

    ULONG NumEntries;

    BPTR  SegLists[];

};



BPTR GetSegList(void) {

    struct Process *proc = (struct Process *)FindTask(NULL);

    struct SegArray *sa = (struct SegArray *)BADDR(proc->pr_SegList);

    return sa->SegLists[2];

}

The pr_SegList entry and what it points to is documented in the AmigaDOS manual.

Posted on: 2015/12/31 12:02

OlafS3

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#19

Home away from home

I think Hyperion would sue everyone who would admit to use the sources and even try to get rid of a uncomfortable competition (Aros or MorphOS) so it is better to stay away from it. The clean room approach is harder and needs much more time but much safer.

Posted on: 2015/12/31 11:31

paolone

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#18

Home away from home

Quote:

cdimauro wroTe
But if this could legally affect AROS (which AFAIK 'til now was implemented with a "clean room" approach), then it's better to forget such sources.

That's exactly what I think too. According to Olaf Berthel they are in an almost unusable shape anyway. So no need of being legally menaced by anyone, just to peek into them.

Posted on: 2015/12/31 10:47

p.bes
Icaros Desktop AROS distribution mantainer

cdimauro

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#17

Home away from home

Quote:

paolone wrote:
Never underextimate people's fantasy and lack of better things to do. Original OS 3.1 sources leaked some days ago (it is yesterday's news on AW.net) and brave people may try to give it a revamp. And this would end up in the usual C&D email from copyright holders...

It might help to solve the problems which we discussed in this thread, since there are a lot of undocumented stuff.

Reverse engineering takes too much time.

But if this could legally affect AROS (which AFAIK 'til now was implemented with a "clean room" approach), then it's better to forget such sources.

Posted on: 2015/12/31 8:21

cdimauro

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#16

Home away from home

Quote:

SamuraiCrow wrote:
Quote:

cdimauro wrote:
BTW, the Amiga o.s. is still alive. It's not like the old ECS chipset, which is part of the retro history, and will never see an evolution (the same for AGA).

The Vampire 2 accelerator is supposed to implement an improved AGA chipset in the FPGA as is the FPGArcade Replay board. AROS 68k compatibility is necessary to implement access to these features because AmigaOS is at a dead end on 68k.

AFAIK they are working on adding RTG support, and recently shown some picture of it.

Extending the old chipset can be made, of course, but it doesn't make sense if the purpose is to continue to stick to legacy and weird features and design decisions.

There should be a clear and wise vision of what to do. Just patching the old chipset only because "I'm an hardware engineer: I can do it" to add some missing stuff isn't my recommended way for revamping the old platform.

Of course, then there should be a lot of work to support it, and I fail to see who will take this huge burden, since the plain (ECS, AGA) AROS/68K support isn't that good (have you took a look at the performance, emulating a regular Amiga?).

/OT

Posted on: 2015/12/31 8:18

paolone

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#15

Home away from home

Never underextimate people's fantasy and lack of better things to do. Original OS 3.1 sources leaked some days ago (it is yesterday's news on AW.net) and brave people may try to give it a revamp. And this would end up in the usual C&D email from copyright holders...

Posted on: 2015/12/30 15:31

p.bes
Icaros Desktop AROS distribution mantainer

SamuraiCrow

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#14

Home away from home

Quote:

cdimauro wrote:
BTW, the Amiga o.s. is still alive. It's not like the old ECS chipset, which is part of the retro history, and will never see an evolution (the same for AGA).

The Vampire 2 accelerator is supposed to implement an improved AGA chipset in the FPGA as is the FPGArcade Replay board. AROS 68k compatibility is necessary to implement access to these features because AmigaOS is at a dead end on 68k.

Posted on: 2015/12/30 14:30

cdimauro

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#13

Home away from home

Then ask the author to fix his badly written code.

BTW, the Amiga o.s. is still alive. It's not like the old ECS chipset, which is part of the retro history, and will never see an evolution (the same for AGA).

In fact, we have AROS/68K which is based on the Amiga o.s. APIs and where badly written code creates issues that take time to developers for creating patches only for the lazyness of such lamers.

Posted on: 2015/12/30 13:43

Hannibal

Re: Amiga replacement rom in WinUAE fails to run Shrinkler-packed executables

#12

Just popping in

I agree with Toni. My view (as someone not involved with AROS, other than I support it in my toolchain) is that there is a difference between "lamers don't know how to write good code" (there are lots of those) and superstar programmers like Blueberry that find undocumented functionality, verify it is identical on all target platforms (in this case all officially released kickstarts), uses it as part of something great.

I think that this is no different from finding and using undocumented hardware features (like the ECS 7 bitplane bug)

Anyway, I verified that Toni's fix works. Shrinkler is the best packer for sizecoding these days, and I expect many 4k/64k demos will use this for the next many years, so this makes me very happy