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 (Kalamatee)


(1) 2 3 4 ... 201 »


Re: File sharing with Windows 7

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
A> look up changing registry settings to use an older SMB protocol on windows.

B> hope someone updates the smb client to support newer protocols.

Posted on: 7/1 5:44
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: So... what are we?

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
An operating system...

Please don't try to box AROS into a cubby hole that suits your description, it is not that (though it may fulfil that role for you).

Posted on: 6/28 18:46
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: smp only x86_64?

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
There are no plans to make it work for 32bit x86 - and anyone intending this is discouraged from doing so.

Posted on: 6/28 18:45
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Max filesize

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
Quote:

GreenNight wrote:
Quote:

Yanosh wrote:
How big a file can be on SFS?


Max. file size 4 GB
https://en.wikipedia.org/wiki/Smart_File_System

Quote:

Yanosh wrote:
DirectoryOpus 4 show the filesize of these files with a negative and totally wrong number.


The filesystems on the Amigaoids are more or less restricted to the possibilities of a 32Bit computer.


They are only restricted by -:

A> software being written before the 64bit DOS extensions,
B> software not using those extensions since there is no actual "API" call replacements, and they require direct communication to the filesystem.

None the less, it is the filesystem which determines the max size, and >4GB is possible so long as you correctly speak to the filesystem.

Quote:

I would like to have a file system and all the tools (for example packers) handling files with much more than 4GB of size.

But even if SFS could handle more than 4GB filesize, you will run into problems with tools, that where developed with a 2GB filesize maximum in mind.



FWIW, I proposed providing a stub "dos64" link library or shared library on AROS that implements the 64bit versions of the normal DOS functions, or wraps the 32bit normal code to 64bit structures - and use that in all AROS binaries so they work with larger files/file systems. I still think this is something that needs pursued as part of ABI v1 before it is considered finalised.

Posted on: 6/28 18:37
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Vampire hyper threading and aros smp

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
Quote:

cdimauro wrote:
Quote:

paolone wrote:
I don't understand where the problem is, exactly. We have already 4 AROS flavours for PC: i386 ABIv0, i386 ABIv1, x64 and x64-SMP, all of them targeting somehow the same processors, all of them being (partially or totally) incompatible to the others and (almost) all of them having someone who takes care of them. Adding a 68K-SMT specific flavour for Vampire users derived from M68K shouldn't be a issue at all, providing that SOMEONE ELSE will take care of it, so Toni, me and anyone else who don't need Vampire specific stuff, can continue using/following the classic M68K version. That's how open source works, by the way.

I guess someone from the Vampire team can make his own flavour of AROS M68K, introducing everything he needs for his own architecture, and caring about backwards compatibility with older software, and that's all. Then builds can be added to the AROS page. Am I wrong?

Toni can correct me if I misunderstood him, but I think that he's worried about the possibility that the current AROS 68K branch could be (heavily) polluted with a lot of "alien" (to this family) code.

Looking at the new features introduced, the possibility is quite concrete.

So, it's not only a question of introducing a new "flavor".

To avoid this situation, it would be better that some Apollo developer can create an ad-hoc branch which forks the 68K one, and applies over it all required changes. This way the 68K flavor will not be touched.

@cybergorf++


Ok, lets clear up some things.

First - supporting the Apollo core doesn't mean doing invasive changes in AROS any more than supporting different flavours of existing m68k processors. Apart from minimal support in the kernel, everything else is in disk based, or "vampire specific" drivers/modules. Optimizing things requires the library/device/resource to patch its function table at runtime with support, the same as on amigaos. We could make it look for "cpu version" specific libraries but as yet that is not the case and not really warranted.

Any other changes to make AROS run better on vampire directly benefit the m68k build since they mostly revolve around optimizing things to better perform on lower powered hardware. This should also benefit other platforms, but may be less noticeable due to the overall speed of the cpu.

Secondly - supporting "hyper threading" (*) on the Apollo core is unlikely to be done to the same degree as smp on x86_64, because it would require a "completely incompatible" to m68k-amigaos/aros build, as well as the core to be properly supported in the gnu toolchain so that AROS can be built for it. Since there are other more important issues to be resolved I don't think this is an avenue worth pursuing particularly at the time being. It is quite feasible for the Apollo devs to use the extra functionality for specific code to run, via some subsystem in the same manner that ppc is handled on blizzard cards - but implementing that is outwith the scope of AROS itself.

P.S - peoples personal gripes/petty quibbles regarding the hardware are of no interest/consequence to AROS. They are no reflection of what is supported or will be. The Vampire hardware (and Apollo core) exist, and as such we will support them as we would any other hardware on any other platform (including virtual or emulated).

* - i will be contraversial possibly in saying that the Apollo works internally like a hyper threaded cpu - but isn't (yet) usable as the "normal" definition of one (which is, that it is treated as 2 separate logical cpu cores). I'm sure there are some ways to make it use both pipelines, but to properly expose a hyper threaded "core" needs them to act like/be exposed as two distinctly separate processors to the operating system - with their own register context aswell as other registers/counters etc to control and interact with them. Please dont think this is an attempt to put down the apollo core or make it sound any less of an accomplishment than it is - since even if it isnt completely a usable option just now, it means the bulk of exposing a "real" hyper-threaded smp like cpu is not far off. It also makes a lot of sense to the internal design of the core and how it is abstracted, for them to further develop it (imho). If anything it should give the Vampire users some indication that things are moving along nicely.

Posted on: 6/28 18:29

Edited by Kalamatee on 2017/6/28 19:07:11
Edited by Kalamatee on 2017/6/28 19:14:53
Edited by Kalamatee on 2017/6/28 19:20:38
Edited by Kalamatee on 2017/6/28 19:21:11
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: (JANUS-UAE) Is today's nightly build for 68K running for you?

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
Quote:

o1i wrote:
Enabling debug in cia_init.c:

[EXECInitCodecalling InitResident (92 81 "hiddclass.hidd")
[
EXECInitCodecalling InitResident (80 01 "cia.resource")
CIA-A 10062418


hang.


# Add debug between the last displayed output and the next debug statement, to try and pinpoint where it fails.

# Examine the generated asm and make sure the ordering of operations on base->hw is correct


Posted on: 6/19 4:59
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Probably my last post..

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
Thank you very much everyone that has sent me money - I believe I have enough to pay off my debts now so will be going to see my landlord tomorrow.

Posted on: 6/12 12:22
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Probably my last post..

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
Quote:

Overflow wrote:
Pardon for me asking to be spoonfed details on how dire your situation is...

The funds we are getting together will be enough to keep you in your current apartment?


IF I can get it paid within the week, yes - when it goes to court, then possibly but it depends on my landlord and I would incur additional debts for the expenses.

Quote:

Not that either yes or no will stop us from helping out. Just trying to see if we are able to help you keep your gear ontop of your apartment.

Rough situation you are in, and its obvious Pateron payments will be too late for the most timecritical issues/demands you are facing. Can you comfirm you email adress to be used with paypal?


That's correct, and its my username @gmail.com

Posted on: 6/10 16:52
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: AROS68K: Development Methodology And Bounties

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
A couple of things that may improve the m68k experience -:

# Implement the Blur/Gradient operators in Cgfx, and make Zune/Decoration use those versions instead of the hard coded versions (*).
# Provide asm optimized m68k versions of the library functions (**).
# Provide asm optimized m68k ConvertPixel related code in the gfx.hidd.
# Make Zune use optimized/buffered rendering functions instead of performing pixel operations directly.

(*) - there are a few other operators that could be implemented and used in other code/subsystems.
(**) - x86 should e.g. use SSE optimized versions.

Posted on: 6/10 16:45
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer


Re: Probably my last post..

Joined:
2004/3/29 9:54
From Scotland "The Cold"
Group:
Member
Posts: 2023
Offline
Thanks for the support guys - it is greatly appreciated. Without wanting to go into my personal life too much, I have rent arrears and other debts incurred over the past year and it has pretty much come to a head. I have been issued with court proceedings regarding eviction, which means if I don't get it paid soon I will have an additional debt of 340 from court expenses, as well as being kicked out if it hasn't been paid. Since I don't really have anything of value I would/will have to sell my computer gear to try and pay it, failing that it will have to go to the dump since I do not have anywhere to store my things or way to pay for it.

I am not really able to move somewhere else since i have an obligation to have my 3 children (they dont live with me permanantly), which as you can imagine is a bit of a struggle with the above also going on.

Posted on: 6/10 16:27
_________________
Click to see original Image in a new window
Transfer the post to other applications Transfer



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




Search
Top Posters
1 paolone
paolone
4341
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3887
4 nikolaos
nikolaos
3677
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2622
7 mazze
mazze
2213
8 clusteruk
clusteruk
2097
9 Kalamatee
Kalamatee
2023
10 damocles
damocles
1789
© 2004-2017 AROS Exec