Interest at bounties for Aros 68k?

[gulliver]

@deadwood and wawa

The bounty on performance of OCS/ECS/AGA driver and extention with overscan support, seems pretty reasonable.

Well, of course you could certainly take time to create a good benchmark for graphics.library. I propose to use SysSpeed for the time being. It is not perfect by any means, but it certainly does provides some benchmark information regarding graphics.library, besides, there are many available saved modules which include results which are good for comparison purposes. So why waste time reinventing the wheel?

I agree with wawa that for the time being targetting aros68k below an A1200 specs should not be clever. I propose that instead of a "030/25 with some fast ram" it should be considered a more fair system a 68020 + 8MB fast. Let me explain why:
1.It could potentialy in a hopeful, not so distant future compete with AmigaOS 3.9 as viable alternative (same hardware requirements).
2.Current FPGA developments target 68020 and not the 68030 instruction set.
3.The majority of new accelerators (and the cheapest ones too) are 68020 based and not so many are 68030.

[matthey]

Originally Posted by gulliver

2.Current FPGA developments target 68020 and not the 68030 instruction set.

The 68020 and 68030 have practically the same integer ISA.

68020
o many new instructions and addressing modes
o instruction cache added

68030
o data cache added
o MMU added
o CALLM/RTM instructions dropped (no known use on Amiga)

68040
o larger caches
o MMU changed significantly
o FPU (compatible with 6888x using traps, new FPU instructions added)
o MOVE16 instruction added

68060
o larger caches
o MMU changes are minor
o FPU changes are minor (FINT/FINTRZ added back)
o MOVEP, CMP2, CHK2, CAS2 instructions trapped

[wawa]

Originally Posted by gulliver

I propose that instead of a "030/25 with some fast ram" it should be considered a more fair system a 68020 + 8MB fast.

i think it is practically all the same. aros, except patches loaded by setpatch is compiled for plain 68000 afaik. we can change target to 68020 perhaps to gain some speed, but i would put it undewr discussion first. by no means i would advocate to force 030 a requirement, but it may make a sense, since 030 instruction set is a subset of 020 as far as i understand, and this way fast execution on both may be actually guaranteed. does 030 provides bitfields for instance?

my intention is of course to go as low as possible on requirements, preferably past 030/25 we just need to see what is achievable.

[wawa]

I propose to use SysSpeed for the time being.

actually its what i was thinking of instead of sysinfo. tend to mix those two thogether. unfortunatelly it doesnt load as well :/

[wawa]

@deadwood
one of the issues with aros may be of a general nature but extremly visible on slow systems may be linked to layers. i observe that performing more operations on diggerent windows still leads to responsivity degradation. i have already some time ago proposed to contact thor in a clean room approach and adopt his strategy/algorythm he uses in his improved layers library. he told me it he could be consultet if need be.

[gulliver]

Originally Posted by wawa

@deadwood
one of the issues with aros may be of a general nature but extremly visible on slow systems may be linked to layers. i observe that performing more operations on diggerent windows still leads to responsivity degradation. i have already some time ago proposed to contact thor in a clean room approach and adopt his strategy/algorythm he uses in his improved layers library. he told me it he could be consultet if need be.

Thor layers.library is copyrighted to him (not to Amiga Inc. nor Haage&Partner), so if ask kindly, there is no need for clean room implementation, just use his code (if he is willing) and adapt it as required.

[wawa]

Originally Posted by gulliver

Thor layers.library is copyrighted to him (not to Amiga Inc. nor Haage&Partner), so if ask kindly, there is no need for clean room implementation, just use his code (if he is willing) and adapt it as required.

he refused this already, because he doesnt want to contaminate aros,but as it stands he would help without coding himself. i think we have to accept this position.

@deadwood:
of the three benchmark suites, aibb is the only that worked and still works. i think this is usable for reference.

[deadwood]

@gulliver and wawa

Can you try to draft the description of bounty for extention of drivers with overscan? I'm not familar what functionality is needed, what the user should be able to do, etc

[deadwood]

@wawa

Can you provide the links to SysSpeed and AIBB benchmarks you mention?

[deadwood]

Based on Clebin's description here is the proposal for first bounty:


===================================
Extend Workbook to become basic Workbench replacement

Workbook is AROS 68k minimalisting desktop. Today its usability is quite
limited. This bounty aims at extending the available functions to become a
replacement of Workbench as found in AmigaOS 3.1

Bounty will be completed when these functionalites are available in Workbook:

* Support standard .info files
* Manually position & snapshot icons and windows
* List-view
* Drag & drop icons to copy/move
* Make new directories
* Delete files & directories
* View/edit file information/tooltypes
* Leave out/put away
===================================


good/bad/things missing?

[matthey]

Originally Posted by wawa

i think it is practically all the same. aros, except patches loaded by setpatch is compiled for plain 68000 afaik. we can change target to 68020 perhaps to gain some speed, but i would put it under discussion first. by no means i would advocate to force 030 a requirement, but it may make a sense, since 030 instruction set is a subset of 020 as far as i understand, and this way fast execution on both may be actually guaranteed. does 030 provides bitfields for instance?

The 68020 has all bitfield instructions and all addressing modes including tricky ones for FPGA CPU cores. There is negligible difference between a 68020 and 68030 for integer instructions. Most code compiled for the 68020 or 68030 will have no differences. Most code compiled for the 68881 or 68882 will have no differences. Most code compiled for the 68030, 68040 or 68060 will execute on a 68020. Some code using the 68020 ISA instead of 68000 ISA will be significantly faster and other code will have no changes. There is no reason to require more than the 68020 ISA (compile for the 68020 or 68020-68060 with scheduling for a 68060 preferably) unless direct FPU instructions are used (probably not necessary).

Originally Posted by deadwood

Can you provide the links to SysSpeed and AIBB benchmarks you mention?

http://aminet.net/util/moni/sspeed26.lha
http://aminet.net/util/moni/AIBB_65.lha

[wawa]

note that sysspeed doesnt load on aros even after proper installation, there is no crash report. likely some zune problem. aibb seems to be working perfectly. i vaguelly remember there was an exception under the tests, but so far everything gave proper results.

i also installed the amiga version of scalos, which loads but causes privilege violation error. i know i have made it working once to certain extent, but since none helps with that i tend to forget what i did once and next time everything starts from the beginning.

[kolla]

People seem to forget that there are 68000 systems that are much faster than the proposed "bottom line" of A1200 with 020. Anyways, both 68000 and 68020+ can easily be supported, this is AROS, not OS3.9 - there _will_ be 68000 support, whether you like it or not

Btw - PeterK's icon.library works excellent on 68000 (also with AROS) - but it is assembler, not portable C.

[wawa]

Originally Posted by kolla

Btw - PeterK's icon.library works excellent on 68000 (also with AROS) - but it is assembler, not portable C.

perhaps some critical bits and pieces could be made target dependant inlines..

[Toni Wilen]

Originally Posted by gulliver

LIBS/68040.library (680x0.library exists but see note no. 1)

This is by design, it is more compatible this way!

AmigaOS setpatch and/or 680*0.libraries can't be aros compatible, they do undocumented patching and aros has built-in 68040 and 68060 FPU support. Simple Enforcer-like MMU debugging code is also ROM built-in (can be enabled very early in boot), it also would not be AOS 680*0 library compatible.

AROS actually has extra code to force AOS setpatch to become no-op and also not to load 68040 or 68060 library which would only cause instant crash

AROS library is only needed to enable copyback (sets up MMU tables) and missing instruction emulation.

[clebin]

Originally Posted by deadwood

Based on Clebin's description here is the proposal for first bounty:

good/bad/things missing?

Thanks Deadwood. I just read your earlier question. I'd agree with others that a lightly expanded A1200 (ie. with RAM expansion) or similar is a good baseline.

I can see that there's a bit disagreement about the value of Workbook. It would be nice to hear Jason McMullan's take on it, but the question for me is, are Workbook and Wanderer's goals compatible? Yes, you can optimise Wanderer but if the bigger push is to add functionality, that's not really the point.

The fact that Wanderer hasn't advanced much beyond Workbench wasn't deliberate - with more developers it might have (and still might) turn into Ambient, regardless of 680x0 performance. Workbook is more a less a finite development - clone Workbench and it's "finished". Beyond that, all you can do is optimise.

I was interested in Kalamatee's post on Aros-exec about his Wanderer plugin architecture and how you could move all but the most basic functionality into plugins. If that makes the goals of low-end 68k and high-end x86 compatible, then I'm all for it. My only concern is that it's been talked about for a long time and unless it makes it into mainline AROS, it's discouraging development on things like Workbook while the problem for low-end Amigas still exists.

[deadwood]

Updated bounty text:


=============================

Workbook is AROS 68k minimalisting desktop. Today its usability is quite
limited. This bounty aims at extending the available functions to become a
replacement of Workbench as found in AmigaOS 3.1

Bounty will be completed when these functionalites are available in Workbook:

* Support standard .info files
* Manually position & snapshot icons and windows
* List-view
* Drag & drop icons to copy/move
* Make new directories
* Delete files & directories
* Rename files & directories
* View/edit file information/tooltypes
* Leave out/put away
* Make Show All Files/Show Only Icons work as per description

This functionality needs to be available in ROM version of Workbook, that is
booting a disk only containing LoadWB command will allow usage of Workbook with
these functionalities.

Additionaly the following functionalities can be added at the descrection of the developer:

* Support for ToolMenu

These functionalities are not required to mark bounty as completed.

[deadwood]

@All

I'm still looking for someone who can give the initial description of the overscan bounty. I do not have the general Amiga knowledge needed to understand what is needed (= I don't know what overscan is, what it is used for and how it is used)

[gulliver]

@Toni Wilen

Thanks, I didnt know

@deadwood

About Overscan:

http://amigadev.elowar.com/read/ADCD.../node0314.html

[deadwood]

Is Overscan a feature of Amiga chipset only or did any RTG cards available for Amiga had that capability too?