Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...
   All Posts (wawa)


(1) 2 3 4 ... 98 »


Re: Testing AROS abi v.1 32-bit

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
Quote:

nikolaos wrote:

Why do we have OWB in the abi v.1 build system and not Odyssey?


i have beed pushing this, but as far as i know odyssey builds very long, because its huge. nevertheless id put it into ports and build by demand or so.

kal has almost made it build with the build system but it didnt fully work, whatever his target was, x64 i guess. and he left without sharing his patches, that may be lost now,
the problem might be icu, which id probably hacily hardcoded for i386. deadwood indicates something like that, at the tima i tried to build it for m68k.

one way or the other this is no trivial taks which demands dedication, skill, patience and time, which all is sparce.

edit: eh, ah.. and odyssey requires newer gcc than 5, which is why im constantly pushing on getting gcc-6 fixed. default gcc in the toolchain, the nightlies are being built with, is 4.6.4.

Posted on: 1/17 3:11
Transfer the post to other applications Transfer


Re: Testing AROS abi v.1 32-bit

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
Quote:

nikolaos wrote:
The focus should be 64-bit but as we have limited hardware support, what I have this is supported with native gfx 2d and 3d is 32-bit.


Quote:

james007 wrote:
A fully supported Pi would also do the trick. That would be a perfect low level entry to get more/new users to our little club


and i say orderly advanced m68k target might in the end gain us the serious part of power user range of the remaining amiga scene, sick to sit back and observe since years how the platform is bleeding and being ripped apart otherwise. espcially now, when popular solutions such as vampire pave the way. it might even bring some developers over and the additional customership in numbers perhaps without comparison to the current aros followership.

however there certainly are still others who have different ideas and visions than we. we hardly will be able to impose anything on each other, especially in the current situation with less and less active devs.

Posted on: 1/17 3:03
Transfer the post to other applications Transfer


Re: A week in AROS...

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
unfortunatelly it doesnt solve m68k find (nlist.mcc) testcase i mentioned on the dev ml.

i see i need to return to testing it.

Posted on: 1/16 8:17
Transfer the post to other applications Transfer


Re: Testing AROS abi v.1 32-bit

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
Quote:

Pasquale wrote:
Could it be the future 32bit version of AROS? abi v.1 needs to compile everything for it,

things that are port of aros contribs and ports can and are being recompiled almost any thime. whatever source in aros archives that can be compiled against aros build system (i.e. contains mmakefile.src) can be usually recompiled or should be easy to fix.


Quote:
compiler included. Is it right?

native compiler and a good part of the toolchain is available in developer subdir. if it can succesfuly compile the whole aros, i dont know and has probably long not been tested, but might otherwise be enogh for a smaller project. other than that its easy to setup anc compile cross compiler toolchain on linux.


Quote:

Ok, another question: is it 2038 year bug free? Sorry, but i think this is a big problem, 20 years are very few...

seems so, but are you sure in twenty years, there will be amiga and aros fans alive?

Posted on: 1/16 4:48
Transfer the post to other applications Transfer


Re: A week in AROS...

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
Quote:

ncafferkey wrote:
Week of January 1st:

- Fixed code corruption (corrupt taglists) caused by compiler optimisation quirks. This may have caused bugs in various places throughout AROS: it is known to have affected some DataTypes at least (neil)


i dont see that commited in track journal. admittedly i have been particularly waiting for it. whats up?

edit: even though you probably refer to that earlier commit, that works with 4.6.4.

Posted on: 1/11 3:14

Edited by wawa on 2018/1/11 8:04:28
Transfer the post to other applications Transfer


Re: Probably my last post..

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
i think its more like year ago, when krzysztof took his leave, and still we have matthias.

Posted on: 1/9 4:03
Transfer the post to other applications Transfer


Re: Probably my last post..

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
It is an open system. everybody can engage, be it in testing or simple fixes.

Posted on: 1/8 11:49
Transfer the post to other applications Transfer


Re: Bars'n'Pipes port

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
looked at it again and it appears that stuff like:
Quote:

screen->BitMap.Depth

i quick fixed with:
Quote:

screen->BitMap_OBSOLETE.Depth

is probably simply properly replaced with:
Quote:

GetBitMapAttr(screen->RastPort.BitMap, BMA_DEPTH)


..ehrrm.... or rather:
Quote:

screen->RastPort.BitMap->Depth


sorry..

Posted on: 1/3 16:13

Edited by wawa on 2018/1/3 17:15:46
Edited by wawa on 2018/1/3 17:16:50
Transfer the post to other applications Transfer


Re: Bars'n'Pipes port

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
Quote:

ncafferkey wrote:
@wawa

2. It looks like a change was made from the original Amiga sources to work with AROS's obsolete device-based handlers. It's likely the original code (under #else) will work there now, but this may need some changes to BSTR handling.


i guess the obsolete aros code could be guarded by
#if defined(__AROS__) && !defined(AROS_ABI_V1)
for the time abiv0 is still in circulation? does the latter be defined automatically when compiling abi v1?

Posted on: 1/3 14:29
Transfer the post to other applications Transfer


Re: Find bugged, useless and unusable

Joined:
2010/8/30 7:20
Group:
Member
Posts: 976
Offline
what concerns finder i slightly updated makefiles to the current aros status and can compile it with aros toolchain. however it crashes within MUIA_Window_Menustrip, FinderV3GUI.c line 224:
[KRNTrap signal 11SysBase b02151e0KernelBase b0215f44
    SP
=b0766d10  FP=b0766d28  PC=af1c5340
    R0
=00030002  R1=b026c424  R2=00000000  R3=b0a66bbc
    R4
=b0a66e90  R5=b0a66ab4
*** Logged alert:
Program failed
Task 
0xB074C480 Finder
Error
0x80000002 Hardware bus fault/address error
PC   
0xAF1C5340
Module intuition
.library Segment 1 .text (0xAF1B4280Offset 0x000110C0
Function Intuition_44_SetMenuStrip (0xAF1C52F0Offset 0x00000050
CPU context
:
EAX=0x00030002  EBX=0xB026C424  ECX=0x00000000  EDX=0xB0A66BBC
ESI
=0xB0A66AB4  EDI=0xB0A66E90  ESP=0xB0766D10  EBP=0xB0766D28
EIP
=0xAF1C5340  ESP=0xB0766D10  EFLAGS=0x00010202
Stack trace
:
0xB08040BE muimaster.library Segment 1 .text 0x0003FD1E
0xB080776C muimaster
.library Function Window__OM_SET 0x00000D2C
0xB0809F5F muimaster
.library Function Window_Dispatcher 0x0000038F
0xB07D5319 muimaster
.library Function metaDispatcher 0x00000019
0xAF1C4522 intuition
.library Function Intuition_108_SetAttrsA 0x00000032
0xB07581F4 Finder Segment 1 
.text 0x00000164
0xB0759048 Finder 
Function CreateApp 0x00000E4F
0xB075964C Finder 
Function main 0x00000022
0xB0758149 Finder Segment 1 
.text 0x000000B9
0xB075ADCB Finder Segment 1 
.text 0x00002D3B


commenting out menus in that line the application starts and works as expected i guess. without access to the menus of course, cant tell how to fix it for now.

Posted on: 1/3 14:22

Edited by wawa on 2018/1/3 15:31:17
Transfer the post to other applications Transfer



 Top
(1) 2 3 4 ... 98 »




Search
Top Posters
1 paolone
paolone
4366
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3894
4 nikolaos
nikolaos
3703
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2668
7 mazze
mazze
2216
8 clusteruk
clusteruk
2111
9 Kalamatee
Kalamatee
2024
10 damocles
damocles
1789
© 2004-2017 AROS Exec