Layers.library V45 on the aminet

[wawrzon]

Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm specifically not talking about other old software.


Yes, Aros is an AOS derivative after all, and it would be nice to be able to get rid of that completely, because 68k can do better than AOS and Aros.

im not sure what you are proposing here. as i understand you want to get rid of os and bang the hardware. this is fine as long as all hardware you have is compatible to each other, which in reality is never completely the case. it certainly wasnt on amiga. but the os abstracting the hardware can compensate fr it and this is what we need it for. or do i understand you wrong?

[wawrzon]

For the record:

If anyone is interested in setting up a bounty for AOS sources then I'm willing to put down $1000. Personal, hobby, non-commercial money.
Make it for 3.1 only if that makes it any easier.

(The bounty should have some legal-speak that indemnify the buyer(s) if the rights are disputed at a later date.)

how are you going to make sure you are buying from the actual owner and that there will not be any claims from third parties in the future?

[wawrzon]

You would probably be astonished how hard it is to do proper line clipping if you have drawing styles (aka MinTerms), the FirstDot flag and line patterns involved. Graphics gets it *almost* right, cybergraphics messed it completely, and the latest P96 should probably be as fine as the original graphics, hopefully avoiding the one bug I remember in Gfx.

seems so. even though actually working now om aros68k there are cases where it fails to work properly, but then again, not enough reliable testing causes issues not to get fixed. it costed two years that my repeated reports were actually taken seriously and interpreted as completely lacking line clipping implementation on planar screens. thats fun, isnt it?

edit:Btw, im not saying something is wrong on developer side, just of more quality reports would happen it would be easier to fix not that obvious problem.

[wawrzon]

as just a noob tester im not likely fully entitled to talk about aros, so take my opinion with a prize of salt.
workbook is a problem or a question here, it has been meant as a basic desktop replacement for limited systems but isnt being developed now. for the time being there is scalos being incorporated into aros (contributions) and also magellan could be put there i guess. also wanderer is being updated afaik, so at some point we will have at least three full blown desktop alternatives. the simplistic floppy based replacement could still need some attention, if any 68k c/asm coder was interested to finish its implementation.

the main problem of aros 68k is low level stuff: device drivers, but also graphics library planar/chunky conversion, some clipping problems. generally efficiency also in exec (i dont know if its possible to reach the aos levels) and probably dos data transfer could be optimised. there is also still missing functionality in gfx drivers for amiga chipset.

having that things like aros version of poseidon could be reintroduced and made working with 68k hardware and existing drivers or their aros replacements if neccessary.

[wawrzon]

Given that I'm a mathematician, I kinna like the name. I believe the fixes for console could be re-done (there isn't really much), there's not much to do for RAM at all, but FFS requires at least a couple of tweaks (ACTION_CLOSE returning the wrong value, ACTION_FLUSH is not waiting, 4GB support, and I would strongly suggest to include NSD *and* TD64 support, and probably a couple of other issues I don't remember). SetPatch... Well, ExAllEnd() was broken, but there are probably more issues that got fixed. scsi.device  - I have no clue.

just make pfs3 the official filing system, it includes all functionality, is open and currently maintained by toni wilen and include ffs as is for legacy and backwards compatibility and you are done.

[wawrzon]

take the software and resell it yes of course, but in this case you have said it forbids you any source contributions to Aros even if there is no original line of code included just because you had access to the old sources. That is completely different...

good to take a lot of devs out of game

this argument is void in respect to reimplementing aos functionality in a clean room environment. if he had not signed the nda and not gained an insight into amiga system source code he would have no knowledge of its internals to contribute to aros. now, that he did and have its knowledge he could be extremly helpful if only there was a counterpart to cooperate and establish such a clean room approach. ability to read and understand the code en gross and communicate things clearly is as important as coding itself i guess.

[wawrzon]

That isn't legal even if you didn't sign an NDA. As long as you don't disclose anything that could only be learnt during your contract then you can contribute to AROS just fine.
 
 What you are describing sounds more like a non-compete clause, which isn't going to be in force by now (if they try to say it is then the court would rule that it was an unfair clause).

i trust that since thor and olsen seriously consider that there is a threat then there must be one. beyond all else they have personal experience with the commercial entities in question they have been working for and im sure they are basing their opinion on some experience, be it personal or general, which may be not available to others.

[wawrzon]

Are we? Ok, to be frank, I do not know (nor have personally met) Toni, nor have I looked at PFS3. Let me tell you why I'm a bit critical about PFS3 (and actually, most alternative filing systems in general, this is not specific to PFS3 which, as said, I really haven't tried).

First of all, the whole dos (Tripos) is written around the FFS construction, with all its weaknesses and benefits. For example, transferal of locks between two drives but the same medium (good), or the almost unimplementable ACTION_EX_NEXT. (bad)

FFS may not be "smart", but it may be faster than you think. Or "fast" depending on which type of operation you want to perform. If I just want to open one (or multiple) files, FFS needs not to read an entire directory (unlike FAT or ext) but uses a pretty fast hash-algorithm. All the information about a file is in a single block, and FFS can block-transfer data between the file on disk and the target buffer by going directly into the device. (Leaving the MaxTransfer and Mask aside). That's not unique to FFS, of course, but what is probably unique (and what I haven't seen anywhere else) is that while FFS is "busy" with a long DMA transfer, additional incoming requests can be handled simultaneously. That is, the FFS is a threaded file system and handles each request in a separate thread (not task, not process). Thus, one can fire off a request, and a second task can do the same at the same time, and FFS will be able to get the second request done while the first is running, provided there are no conflicts. I'm not sure whether PFS3 can do this, but SFS did not (back then, when I checked), and no other FS on the Amiga could.

FFS is *not* slow. Ok, it is slow in *one particular* discipline, and that's listing of directories. This is because every file requires a single block as file header. That is, when reading a directory, more IO transfers have to be made (unfixable) and a lot of disk-gronking happens (avoidable by smarter allocation). This is, as always, a compromize that has been made when FFS was constructed, and the compromize was simply to make "opening and reading of files" as fast as possible, with the drawback of "listing directories" being slow. Which operation is used most? I don't know, and I haven't measured, but my gut feeling is that the FFS decision to optimize for fast data transfer (and not for fast directory transfer) was actually not such a bad decision.

Other filing systems use more complex directory structures, with the benefit of making directory reading faster, but making file manipulation slower.

I haven't measured, but I consider it hard to construct a filing system that requires less disk operations to actually find and open a file on disk than the FFS. That seems to be a good choice if I/O is slow and the CPU is fast. Maybe that's the wrong assumption today (I don't know) but before I would pick another FS, I would prefer to see some hard facts about the performance of PFSn, and I do not only mean speed.

Are all important packets implemented? Correctly? Does it support hard and soft links? File notes? File Dates? Does it operate correctly if multiple tasks operate simultaneously on the disk? Does it perform well if multiple tasks operate on the disk? How many disk operations does it take to open a file? Create a file? Write a file? List a directory? How does it behave if we try to corrupt the disk? Turn the system off (FFS is not exactly a top performer here, don't tell me, I know).

My personal feeling is that the FFS has reached a certain level of stability given that it has been around for such a long time that it's hard to replace it by anything more stable. If any, I would only make minor changes that are backwards compatible to existing FS-structure, such as improving the block-allocation policy (keep directory blocks close to each other, do not scatter them, avoiding the disk gronking) or improving the 64-bit support.

Oh, and last but not least: You surely want a file system that can read your existing disks. From what I read I believe PFS3 can handle this?

i cannot exactly tell if pfs3 is threaded, but i do even guess it incidentally is. toni, who unfortunately is only a member on eab, but not here, could answer this in detail. the original coder whose name i dont remember was posting here i guess but im not sure anymore, the other person who comes to my mind is piru who did initial port and fixes to current gcc.

im absolutely not advocating sfs whatever in this respect, since from my user experience is rubbish, sorry to say.

also i did not say pfs is able to read ffs formatted media. sory, i realize it sounds like i did. what i wanted to say was, to keep ffs as is for legacy.

[wawrzon]

We'll have to agree to disagree here.  To me this is a symptom of a larger issue with AROS that is related to the current discussion.

IMHO, it's not a viable replacement for the original OS until it can run in reasonably similar resources and 4KB of wasted disk space, bandwidth and memory on a single command is patently ridiculous.

Working on the commands in c: is a stepping stone for me to get a workflow down while I become acquainted with the code base.

i agree that these are some of reasons that prevent aros to become real alternative on 68k.

perhaps some aros developer could comment on that. is it some linking issue, perhaps against the arosc lib?

woulnt it be good to disassemble and examine asm of some possibly simple aros68k c: command to actually exactly check where the differences and problems are in order to optimize them away if possible.

[wawrzon]

You don't have to, just look at the code and compile it yourself.

Disassembly is rarely needed to find stuff like this, you just need someone to care about it.

Edit: Let me rephrase, lest people think that I don't like the AROS devs.  It's not "care" as in giving a damn, I meant care as in making that one of your priorities.

im not blaming you in any way, i think you bring some valid points, im just trying to figure out how they could be solved, in absence of better proposals.

the idea to disassemble a binary wasnt exactly to discover what actually gets statically linked or the like, what can be read from sources, just if there is anything particularly strange that happens at compile time. afair aros version of gcc needs to be patched downstream to produce proper aros binaries, it doesnt get pushed and maintained upwards for obvious reasons so some crap might happen, and it might be possible to fix, if it was the case.

[wawrzon]

I'm not sure what will become of this work, but here's a sample. I'm having trouble getting a table to format right in here, so read if you can, sizes are in bytes.

These aren't cherrypicked, they're just the ones I've done and tested enough to feel confident in them working like the originals.

Code: [Select]

Command OS3.1 Mine AROS (Vision 2.7)
AddBuffers 444 356 2168
Break 432 504 3732
ChangeTaskPri 460 476 3096
DiskChange 312 248 2052
Lock 536 628 2788
MakeDir 464 364 2732
MakeLink 700 556 2528
Relabel 584 580 3312
SetClock 668 636 4840
SetDate 688 724 3212

Total 5,288 5,072 30,460



hello! i trust you and i noticed it myself, but one of the possibilities would be for example, that the binaries have not been stripped and still contain the debug symbols. this might amount to the 1/3to half of the size.

[wawrzon]

I think Thomas is right on the money about startup and C library code.

My guess is that there's about 2k of startup/clib code duplicated on each command, but it may also be gcc contributing.

Most of my changes involved using native methods that would be in ROM, doing my own startup (2-3 lines of C code, wouldn't work in x86 AROS) and using C that I knew would compile to better assembly.

IMHO it's more readable now and I fixed several bugs along the way. AROS AddBuffers for example won't work correctly on a real ROM, but this works on both back to v37 KS.

I had more of it done with SAS/C but switched to vbcc this weekend for c99 support and a better compiler.

its not like they dont want to support vbcc, there has been even some work put towards it, though first of all there is not enough human resources, so they must concentrate on compilers that are offering most up to date features, best multi-platform backend support, best posix compatibility, and active maintenance, backed up by huge team. i think in this respect relying on 4.x.x gcc is a right and reasonable trade off.

i would definitely love if you could help to improve aros68k, but its up to you of course and aros maintainers. if need be you could talk directly to toni wilen or via eab. i think even discussing things with him could be valuable given experience you have gathered. im aware though, that toni being winuae man, is less interested in performance optimizations for real hardware as long as he considers them premature, that means as long as implementation is incomplete and not very well tested.

[wawrzon]

There's an unreleased version of this library for OS3.x (the OS4 version is based on it). It's about 1/8th the size of the Warp3D 4.2 release version, fully supports every v4 array/element/index size primitive and is up to 2x faster at rendering triangle/strip/fan lists.

Those gains were from refactoring the C and then rewriting some vertex fetch routines in assembler. The latter did not give much gain since in the end the bus is the bottleneck.

and here we go again. things that could improve the experience on 68k are held back to remain os4 exclusive. of course you and the genuine source owners have every right to do what they please, but imagine what might have happened if you published your work as open source backend to wazp3d. perhaps it could even have become a template for volunteers king for opportunity to write other w3d drivers, and literally everyone could gain from it including os4 community.

[wawrzon]

sighhhh......

[wawrzon]

Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.



I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.

yes i remember it was technical issues of course. im not sure if this article is fully up to date, it must have been written by jason.

one issue not privilidgeing vbcc is of course that it is a native 68k compiler (afaik) and aros heavily depends on automatized cross compiling on servers to have actual nightlies ready at hand for testing by everybody. though since people are adding their preffered platforms to compile on i imagine vbcc could also be accepted if it was doable. what concerns missing features like different asm inline syntax (if i understand it right), we have here matthey who is helping with vbcc and vasm for input on that matter.

[wawrzon]

That is great :-)


@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.

who? magorium? i doubt he needs my help, anyway he didnt asked for any so..