Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
148 user(s) are online (119 user(s) are browsing Forums)

Members: 0
Guests: 148

more...

Headlines

Forum Index


Board index » All Posts (Rogue)




Re: Future AmigaOS
Quite a regular
Quite a regular


@Billsey

Quote:

Billsey wrote:

So, what you're talking about is really like running two OS's at once on the same machine, with one acting as "overseer", so to speak.


Basically yes. It's not actually a new concept, the Mach kernel can do this already.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Future AmigaOS
Quite a regular
Quite a regular


@jahc

Quote:

jahc wrote:

If this plan goes ahead, does that mean current OS4 apps will run under a sandbox with the older kernel, and that the newer OS4.x apps will have enhanced features, and maybe a better form of memory protection?


I wouldn't call it a sandbox, rather a virtual environment. The old system will run in its own address space as a separate task. It's not like a UAE or anything like that. It might or might not be able to become aware of the outside world, we still need to clear up the details.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: DMAing between PCI cards
Quite a regular
Quite a regular


@Spirantho

Quote:

Spirantho wrote:

It's not a problem per se, it's just a side-effect of not being able to allocate contiguous blocks of memory. Once I can do that it should just work. I hope!


Does the chip not support a scatter/gather list?

Quote:
Bog standard A1XE G4@800. Interrupts worked fine when I was using the Bt8x8 chipset, but the CX2388x chipset raises the interrupt from what I can see but the interrupt routine never gets called. The registers on the Cx2388x say it's raised, I can read the interrupt register and it's triggered - it just never calls the routine. It may be a peculiarity of the Cx2388x chipset though.


Have you looked at the PCI device, whether it has a PCI pin and line assigned?

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Techie questions regarding the nuw Amiga OS4 update
Quite a regular
Quite a regular


@Hans

Quote:

Hans wrote:

So large allocvec allocations might be fragmented physically in memory? I didn't realize that; although it's only important when you're writing a driver.


Fragmentation only affects physical addresses. The CPU will not see anything of that nature on user code, i.e. you will be able to access memory normally. But yes, as a matter of fact any allocation might (and very likely will) be scattered, anything beyond 4k which is the current page size.

For just about anybody, this will not have any consequence. This is ONLY interesting for memory that is used in a DMA operation. Even there, though, you don't need to have contiguous memory if you use StartDMA which makes a scatter/gather list for you. It of course assumes that the DMA operation in question supports Scatter/Gather.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Techie questions regarding the nuw Amiga OS4 update
Quite a regular
Quite a regular


@Spirantho

Quote:

Spirantho wrote:

It means that absolutely no way anyone outside of the people with the Beta SDK can allocate a contiguous chunk of memory - which isn't good for device drivers like I'm writing!


Yeah, I'm aware of that, OTOH there aren't that many driver writers. Like I said I need to see what I can do.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Techie questions regarding the nuw Amiga OS4 update
Quite a regular
Quite a regular


@Spirantho

Quote:

Spirantho wrote:

It's actually just the includes I need. I need to be able to allocate a contiguous lump of memory, approximately 432KB (768x576 - PAL resolution, in other words) and it's impossible without AllocVecTags(). The function's there in the library, I just can't use it without the correct include.

I've found a way of making it use one DMA chunk per line but that means 576 different DMA lists. Yummy. I think a contiguous lump would make life rather easier...


Darn, I wasn't aware that AllocVecTags wasn't out there yet... that is indeed a problem.

I'll see what can be done about this, but a new SDK is currently not very likely to be released.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: DMAing between PCI cards
Quite a regular
Quite a regular


@Spirantho

Quote:

Spirantho wrote:
@Rogue

Excellent... so I should just need to IMMU->GetPhysicalAddress( OverlayBitmapAddress ) or whatever, and then I should be able to StartDMA() on it?


Not even that, you just need to look up the address in the PCI range of the graphics card. For the moment, you can even skip this step because they are always mapped one-to-one.

Quote:
In the meantime I'll just carry on what I'm doing at the moment (DMAing into main memory, then copying into frame buffer overlay memory). Or at least what I'm trying to do at the moment, albeit in 2K DMA chunks!


I am not aware that there should be any kind of problem with the DMA buffer size. For starters, 4k should be safe since that is the page size.

Quote:
Now if I could just work out why the interrupt routine isn't being triggered even when the interrupt is being raised... but that's a different matter entirely I'll worry about when I've got things displaying again.


What machine is this card in? Does it have a bridge?

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Techie questions regarding the nuw Amiga OS4 update
Quite a regular
Quite a regular


@Spirantho

You need to add "SERIAL" to the kernel command line. Otherwise, memory buffers are now the default for debug output, and C:DumpDebugBuffers will get you the output.

I am sorry for the delay of the SDK, but one major factor in this is a problem with binutils stripping too much for the shared object support, resulting in unusable binaries when you strip them.

Since my time is limited, and my knowledge of binutils is even more limited, this is dragging on. Just releasing the autodocs and includes will not do much good.

(edit) I am not aware of any problem with DMA with buffers of more than 2k. As a matter of fact, I am very sure that the IDE devices use larger DMA transfers.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: DMAing between PCI cards
Quite a regular
Quite a regular


@Spirantho

StartDMA on a framebuffer address will probably not work because there is no VMarea for the range. That's probably a bug, I'll have to check it.

PCI addresses should always be mapped in one piece, though, so you should be safe for now to just translate virtual to physical (through the PCI range structure) and use the physical address (which is also quite likely the same as the virtual address) for the DMA operation. Can't promise that this works, but it should.

We'll see that this bug gets fixed in the next release.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: ACK proven untrustworthy
Quite a regular
Quite a regular


@xeron

Quote:
The dos library fully supports it. Its true that the only publically available filesystem that supports it is SFS2, yes, but note the term "publically available"? Thats right. End users can use >4Gb files on AmigaOS4, not just betatesters.


Well, it's actually irrelevant who supports it or not. If you have OpenGL and no driver for a GeForce 2, does that mean you don't have OpenGL support? I don't think so. Just because not all file systems support it (and let's face it, SFS2 means already half of the publicly available file systems support it) doesn't mean it is not supported.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: ACK proven untrustworthy
Quite a regular
Quite a regular


@Helge

Quote:

Helge wrote:

Please excuse my ignorance (I also only know little about AmigaOS internals), but to me it seems like a good thing to move to the incompatible API better sooner than later.
Why? Because there isn't much OS4 software now. When OS4 is more popular in the future (after Hyperion has hopefully won the lawsuit), a break in compatibility will be more difficult and much more software would need to be rewritten.


As Xeron points out, there is always the possibility to go the MacOS X/Classic route.

Our plan is to move everything up one layer, i.e. make the HAL a software implementation based on a newer kernel, with the old system running as a separate task but using services from the new system.

The compatibility break is inevitable. We've seen it again and again, last time with the pager support - the current (beta) kernel supports swapping to disk. However, there are a lot of exceptions of memory that can simply not swapped (mostly because of the memory protection issues again).

As of now, there are other, more urgent things to do (Classic version for example), but once we're done with the current plans, moving ahead will include breaking compatibility, taking what we think is good and defining in AmigaOS, and leave the rest behind.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: ACK proven untrustworthy
Quite a regular
Quite a regular


@Billsey

Quote:

Billsey wrote:

I know pretty little about it, too. It?s been quite a while since I read your OS4 reports in Club Amiga Magazine. Am I following the wrong course when I think that this has to do with the OS being single user versus multi-user?


It's a shame that something CAM doesn't exist anymore, really...

It doesn't have anything to do with multi-user vs. single user really. The problem is that almost everything in AmigaOS is open. Like, for example, programs receiving an IntuiMessage go and peek into the message without going through an API, and they also peek into system structures like struct Window. As long as that is so, there is little that can be done in terms of full memory protection.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: ACK proven untrustworthy
Quite a regular
Quite a regular


@keisangi

You are right. you are apparently unable to discuss in a sane manner, therefore I can only suggest you... nevermind, I am not going to stoop that low.

(edit) For the record, I always find it somewhat funny to see people say "AmigaOS needs this" and "AmigaOS needs that". FWIW, we're not stupid, regardless of what you may think. It also isn't like we do not know what AmigaOS needs. However, unlike yourself, we actually need to work on it not moan and bitch about it ad nauseam, and that is a slight bit more work than holding your breath and stomping your foot on a forum.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: ACK proven untrustworthy
Quite a regular
Quite a regular


@keisangi

Quote:

keisangi wrote:
This thread was locked when the disscusion became difficult to answer for tetisoft or other offical developpers..


If you would post and argue like an adult, it might even be possible to discuss with you. However, you argue like a spoilt 13 year old brat that tries to hold his breath when he doesn't get what he wants.

Quote:
some users around even started to agree with some parts of my statments about problems AmigaOS and clones systems are facing for stubbornly trying to keep compatibillity with an api from past era (1993).


Oh I agree with some of the points (except for the fact that OS 4 has large file supports since a while). It's just that since you cannot argue without insulting someone, or being "funny", there is no way I am going to discuss anything with you.

Quote:
AmigaOS need to evolve with todays standard.. and when i say "today" i'm being nice cause utf8 / large files support / modern browser / and getting an OS stable and protected from it's own tasks! is in almost every systems around since quite a while.


As I said, large file support is already in, as you would know if you had any idea what you are talking about.

You know pretty little about AmigaOS obviously if you think you can build in all-out memory protection into it - this is not possible in the current incarnation, and it will need to move to an incompatible API at one point to achieve this. That will happen, mind you, but not just now.

It just goes to prove you are not thinking about what you ask, you are just stomping your foot, calling everybody fools, and bitch about "uptimes".

Quote:
- or: it may not be possible to implement thoses at all ?


See above.

Quote:
the thread was locked .. how convenient..


It probably didn't have much to do with convenience but rather with your behavior.

Quote:
but then i might be deleted or ignored again..
but i don't mind .. thoses problems are big enough to show themselves to anyone.. thoses questions will be asked again by others .. they simply cannot be ignored.


I am not afraid of these questions, and I don't mind answering them. I just want them asked in a mature manner. If you would learn how to communicate, we might talk, but apparently, you are totally unable to do that, and as long as that is the case, I'm sorry you will get ignored, or someone will tell you his opinion about you - and believe me, I am holding back with it.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Late feedback on July Update
Quite a regular
Quite a regular


@LyleHaze

That is indeed the first time I hear about this sort of issue. Do you have a serial line attached? It might be interesting to see if there is anything on the serial output prior to lockup.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: QEMU in PPC emulation mode
Quite a regular
Quite a regular


@AmiKit

I doubt the truth of that. While I think that it wouldn't be difficult at all to run OS 4 on top of QEmu, I don't believe those that claimed to have done it.

It would take me a week or so to adapt the kernel to work on it, possibly less. But I would work from the source code.

Unless of course the person in question had access to the source code in which case he violated trust and all sorts of agreements and compiled Thomas and my code for a different platform. I hope that this is not the case.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: ... when ?
Quite a regular
Quite a regular


@keisangi

It's all quite easy.

There is a limited amount of hours per day (24 when I last counted) so there is a certain limit as to what you can do. Add to that the fact that resources are wasted elsewhere, the result is slow progress.

That does not mean, however, that nothing is going on. Quite the contrary.

Memory protection is already implemented to a certain degree, but there are limits as to what can be done with the current AmigaOS. We plan to address this in a future version (think something like 4.x with x > 0) by introducing a few architectural changes I won't go into right now.

This also goes for other areas. International character support is one of these, right now, the graphics library API is somewhat limited, but plainly, the need for e.g. different writing directions is underwhelmingly small, and there are other areas in the OS that have a much higher priority.

These things will be addressed over time.

Finally, let me remark that once you stop posting like a 13 year old, I might be more inclined to discuss things.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: OS4 Native version of Hyperion' s Games
Quite a regular
Quite a regular


Right now chances for ports of these games are pretty slim beyond what has already been released, for a number of reasons:

- Hyperion is working on OS 4 and hence does not have much free capacity
- Free updates would mean unpaid work, something that Hyperion cannot afford at this time.

I'm sorry, I would prefer things to be different.

(usual disclaimer, I don't speak for Hyperion)

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Switching to SATA - worth it?
Quite a regular
Quite a regular


@joerg

Quote:
U-Boot supports the sii3112, it doesn't support the sii3114.


IIRC out latest U-Boot 1.2.0 build does support the sii3114. I'd have to check the source code, but I am pretty sure it does.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top


Re: Update woe's
Quite a regular
Quite a regular


@Arnie

If possible, boot your system without startup sequence (by holding down the Control key on your keyboard or using both mouse buttons to get into early startup menu) and then enter the following:

set echo on
execute s/startup-sequence

See if it hangs somewhere. My bet would be AddNetInterface. If that is the case, look into the PDF that came with the update for a fix.

Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Go to top



TopTop
« 1 ... 20 21 22 (23) 24 25 26 27 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project