@bernd_afa

Quote:

I think they cant reach the goal and make a stable working new API that is easy to use and comfortable.I see this on the "new OS4 features" this are small enhancements, but all increase work to write.we begin with the IExec->... Calls.

IExec-> and IDOS-> etc are hidden inside macros, so there virtually no difference.

JMP table is for emulated programs only.(680x0 oppcode, address to JMP too)
the translation of emulated registers to native functions are handled in side stub functions.

The interfaces only contains pointers to native PowerPC code, more then one interface can exist in a library this allows for different version of the same functions, no more incompatible libraries, at least theoretically.

Interfaces can be named, most common name is “main”, but expansion.library has interface called “PCI”

Quote:

No OS use this additional typing,

Simply write:

Gcc my_prog.c –o my.exe –D__USE_INLINE__ -lauto

The inline macros will take care of the rest.

Quote:

see SDL or opengl libs how they do, maybe for a Amiga Fan it is ok, but wy should somebody new do things that need more write work than other OS ?.open interfaces, get interface pointer.

AmigaOS4 opens and closes libraries and interfaces automatically whit compiler switch “–lauto” so there is less program code to type in, so there more work writing old AmigaOS3.x programs.

The interfaces might be useful for some things, but I don’t think they will magically give AmigaOS4.x SMP support or more memory protection.

AmigaOS4.1 also supports .so files, this enable you quickly port programs from Linux, AmigaOS4.x also has hi level of POSIX compatibility.

Quote:

Also a OS4 for SAM is still not here.

What have you been smoking? Don’t you read news?

Quote:

they need now over 7 months to make a SAM final version

There was tiny update not long ago, AmigaOS4.1 for SAM440ep was named beta because was not tested to same degree before the CD was produced, and yes it available, and you can buy it.

Last edited by NutsAboutAmiga on 14-Apr-2009 at 07:19 PM.
Last edited by NutsAboutAmiga on 14-Apr-2009 at 03:46 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@bernd_afa

Your english is pretty scarry and looks like a google translation. This makes difficult for me (and other probably) to read (and understand) you. Try to write shorter sentences it might help.

Now AFAIK every SAM boards are released with AmigaOS 4.1 so what are you saying ?
You are speaking about bugs in it, but did you experience them yourself ? Did you ever tried AmigaOS 4.x for a continious period longer than a few hours yourself, or did you make your mind based on forums ? If not them please refrain yourself from spreading FUD you don't even know personnaly.

Oh and last, of course AfAOS never had any bugs introduced by you and you always fixed them instantly...

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@bernd_afa

Quote:

I think they cant reach the goal and make a stable working new API that is easy to use and comfortable.I see this on the "new OS4 features" this are small enhancements, but all increase work to write.we begin with the IExec->... Calls.

The funny thing is that you managed to point out the very thing that allows a completely new, clean APIs to be added to the system in the future, with the old APIs still there for compatibility with old software. The interface system is exactly for that.

And no, it doesn't increase work for anyone, you can easily compile old-style code with -D__USE_INLINE__ and -lauto without having to add any code to open libraries or interfaces. However the new approach makes code much more readable as it's easy to see which library interface each function belongs to, e.g. seeing IAFA->Bernd() in a piece of code I will understand that the Bernd() function of AFA library is being called, whereas just seeing Bernd() in the code is not very informative. I also used the interface system for making the DvPlayer plugin system and saved me a lot of development time, I can simply use a unique interface name "dvplugin" which ensures that a dvplayer plugin is not mistaken with a system library for instance. Try doing that with the original Amiga library system.

Quote:

but when they change something, there are bugs and they slowley fixed it

Heh, well guess what, adding new functionality usually means new bugs are introduced regardless of how much care you take not to introduce bugs, unless it's something very trivial. I suppose you've never done any actual software development if you're not familiar with this.

Quote:

Also a OS4 for SAM is still not here.they need now over 7 months to make a SAM final version.

Don't forget that in the meantime they have also ported OS4 to another platform (Pegasos2). But you are probably correct that doing a completely new API from scratch is beyond Hyperion's current budget/resources.

Last edited by COBRA on 14-Apr-2009 at 08:18 PM.

@NutsAboutAmiga

Quote:

All parts of operating systems needs some kind of locking, this how you synchronize data so it does not get over written and corrupted

Traditional synchronization primitives are not the only way to accomplish this.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Nostromo Quote:

I must be the only person NOT interested in the porting of OO or any other open source software to OS4.1. I would like to use OS4.1 so I can use unique Amiga software.

I'm sure we would ALL love to be using "unique Amiga software", and avoid Linux ports. HOWEVER, in the real world we don't (yet) have all the programmers needed to do this, so we have to live with SOME Linux ports. And this is not so bad, because Linux ports can get quite good with time (see OWB).

If OS4 takes off (and the ports will help there) then maybe we can get more "unique Amiga software" like we had in the old days...


You seem be making the same mistake that people make about the price & performance of a Sam440. They think this is the final "end product", and then complain it can't compete in a mainstream market. But it was never meant to compete in a mainstream market, it was aimed as the FIRST STEP in a niche market, where later steps will hopefully increase performance & reduce price (but this takes time).

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

I for one can run Openoffice on my PeeCs, on Amiga Id prefer a Amigaflavoured wordprocessor etc, something that keeps the good from older Amiga software.
Something from the original Amiga software-ecosystem.

Btw Openoffice IS BLOATED ! Amiga needs to not COPY from others, but build on own strengths and fill its own niche fully before trying to attack other areas .. In my opinion , in the real world, Amiga is now in a retro computing niche, and possibly in a low memory / low power embedded computing niche (multimedia kiosk systems).
And in a FULLY Microsoft free world, an alternative computing world.
Of course an uptodate wordprocessor and other such software is neccessary and I gather OWB now fills the web browser need.

Anyway, fill the retro computing niche and possibly the ecofriendly lowpower computing niche first, thats my current idea !

Quote:

ChrisH wrote: @Nostromo Quote: I must be the only person NOT interested in the porting of OO or any other open source software to OS4.1. I would like to use OS4.1 so I can use unique Amiga software. I'm sure we would ALL love to be using "unique Amiga software", and avoid Linux ports. HOWEVER, in the real world we don't (yet) have all the programmers needed to do this, so we have to live with SOME Linux ports. And this is not so bad, because Linux ports can get quite good with time (see OWB). If OS4 takes off (and the ports will help there) then maybe we can get more "unique Amiga software" like we had in the old days... You seem be making the same mistake that people make about the price & performance of a Sam440. They think this is the final "end product", and then complain it can't compete in a mainstream market. But it was never meant to compete in a mainstream market, it was aimed as the FIRST STEP in a niche market, where later steps will hopefully increase performance & reduce price (but this takes time).

Last edited by Mr_DBUG on 14-Apr-2009 at 07:38 PM.

@NutsAboutAmiga

Quote:

Quote: I dream of the day I can have a memory mapped view of all file systems and not have to fopen()/fclose() (or your favorite equivalent) everything. You could combine that with transactional memory and perhaps do away with abstract locking mechanisms, too. Wouldn't that be a wonderful place to play? If you think how files are created, they are created by increasing the file system by adding blocks in sequences. This works perfectly well when append lines to text file, or append sequential frames to a movie.

And you really couldn't do away with the C standard library--not if you expected C developers to hop on board. (Could AmigaOS eventually sustain its own language or language implementation? Yes. Can it do it today? No.) But, you could still change the way people think about allocating storage. Silly interface musings:

AllocateCacheObject(length, blockSize, alignment, flags)
FreeCacheObject(object)

Flags can be things like CACHEF_VOLATILE (for traditional memory allocations), CACHEF_PERSISTENT (for non-volatile storage-backed objects, like files), etc. (You could also just add this fucntionality by extending AllocSysObject(). Maybe something like it already exists, albeit without the memory/storage abstraction. I don't have OS4, as everyone knows.)

Things like length, block size, etc. can be user-specified or dynamic, so persistent objects like files (whatever a file actually is--data in a raw relational file system, for example) can grow and shrink dynamically, just like database tables.

If you want to avoid fragmentation to improve performance, e.g. with video playback, you could provide hints to the object allocator to reserve space. Anyhow, lots of possibilities.

A lot of this type of stuff is already implemented in different forms, but it's not tied together by a single abstraction, which is what I was driving at.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@abalaban

Quote:

Now AFAIK every SAM boards are released with AmigaOS 4.1 so what are you saying ?

Nope, SAM boards are not released with AmigaOS 4.1, you have to buy it seperatly, and it is also considered a beta still.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Yes it is beta so what?
Do you know of any bugs?
Don't you think the Sam440ep user won't get updates and fixes?

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@kolla

I agree. "Beta" is just a word. "Gold" or "release quality" or whatever you want to use just means the developers have got the ratio of bugs to likely bug reports down to a manageable level. It's just risk management reflected in marketing.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Devices do caches internally, see WaitIO(), AbortIO(), SendIO() and DoIO(), but I guess the disk cache can theoretically better managed as part of the memory system, for example only free up caches when its needed, whit simple time stamp you can check if blocks should be freed or not.

I know the current memory system does some thing like this to speed up memory allocations, but its not the same thing.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

I know devices cache internally. I think you're missing my point. Forget the concept of main system memory for a moment. Instead, imagine memory as a board-level cache (like the SRAM-based second-level caches that used to be common).

During the bootstrap process, all non-volatile storage is mapped into the virtual address space via a novel hardware or software mechanism. In a 64-bit address space, a 1 TB hard disk could be mapped to something like $6000 0000 0000 0000 - $6000 00E8 D4A5 0FFF.

When a process needs access to data, it uses some other novel mechanism to procure access to the data--a search, a lock, an explicit open, etc. What's returned is a memory mapped via of the file, perhaps $6000 0000 1000 0000. On the first access, a cache miss occurs because the data hasn't been moved into board-level cache (main system memory). This is similar to how disk read caches work today, but the abstraction is different. The data is then read into cache, manipulated, and if necessary, written back to disk using a write-through or write-behind process, depending on the priority/urgency of the request. This is similar to how disk write caches work today.

Because all storage is now part of the memory subsystem, both caching and swapping work via the same abstraction. In many cases, it won't be necessary to swap inactive portions of cache to a separate area on disk as that data is already backed by an existing block on disk, so where possible, we've done away with swapping in the traditional sense.

How data is stored on disk is entirely up to the designer. It could be stored as a memory image, as with ROM. It could be stored as relational data, as with a database.

The idea is really about looking at storage and its integration with the system in a novel way. It's being done with other storage devices and buses--Secure Digital, for example--so why not with PATA, SATA, SCSI, SAS, et al?

EDITS: Typo city.

Last edited by Trev on 14-Apr-2009 at 10:35 PM.
Last edited by Trev on 14-Apr-2009 at 10:33 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev
What you describe (and keep repeating in this thread...) is pretty close to something I've wanted to see for some years, and I don't think the rough idea itself is new. But the difficulty comes with the design & implementation! IMHO the best approach is the built something like this ON TOP of an existing OS. Since OS4 does not support memory mapped files, Windows or Linux would have to be used. That'd prove the design works, even if it would be more efficient for the OS kernel to do it, and you don't need an OS coder to do it (who are pretty rare).

Since you seem to have so many idea how to go about it, I really think YOU should be the one to code it. Selling your idea to other people is very very very unlikely to result in any of THEM picking the idea & implementing it - as it is extremely unlikely that anyone else will find the idea as awesome as you (and me) think. That's what I did for a "Next Gen AmigaE language", and it only took me 7 years to produce PortablE . Most certainly selling the idea to a few (mostly) non-coders on a niche web site isn't going to get anyone else to do it for you.

Last edited by ChrisH on 14-Apr-2009 at 11:11 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

You're right on all accounts. But it's still fun to talk about it. (I guess I am repeating myself quite a bit. That's fun, too.) I think it could be implemented in OS3 (with an MMU) and OS4. In OS3, you could even patch the new system into exec and dos. I suppose you do that in OS4, too, but I don't know how well that would go over. A reserved region of memory and a library to use the new cache would be better for testing....

I'll just toss this into my wouldn't-it-be-cool project bucket. Seven years sounds about right.

EDIT: It would be a cool classic hardware hack, too: a SATA device (or something faster) behind RAM and a memory controller on an expansion/CPU slot accelerator. The storage device (not the RAM) could be mapped into memory with AddMemList and MEMF_FAST | MEMF_LOCAL (if I understand MEMF_LOCAL correctly) or AutoConfig. The expansion device would do all the work mapping addresses to storage, leaving the Amiga non the wiser.

Last edited by Trev on 14-Apr-2009 at 11:53 PM.
Last edited by Trev on 14-Apr-2009 at 11:50 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev



Memory mapped IO thing is best done on top of DOS.Library, should be easy to implement using the OS4 memory trap handler, just remember you where limited address space on 32bit CPU, and address space is shared on AmigaOS4.1 so its not so good idea right now,

4gb max, but remember that lots of address space is already in use for USB, Video memory, PCI, network, RAM and Swap.

And when you have 4gb Blue Ray ISO image on hard drive, then its impossible to map this file in to memory.

But on 64bit CPU things are where different, If you don't mind only running 64bit programs.

The disk cache idea is best implemented inside the devices, but will require some extra support API for this as extension to the memory system, so that memory system is able to free unused disk cached blocks when needed at request.

Then you have file system buffers (mostly to speed up directory listings) should also be part of cache system.

So basically AmigaOS should know 3 types of memory sates, free, cached and used.

Last edited by NutsAboutAmiga on 15-Apr-2009 at 12:02 AM.
Last edited by NutsAboutAmiga on 14-Apr-2009 at 11:53 PM.
Last edited by NutsAboutAmiga on 14-Apr-2009 at 11:52 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Good points. In the new model, there are no file systems and no directories, though. Users wouldn't have to know or care how their data is stored, and if they wanted to see "files," they could build views based on data attributes--type, content, date, owner, etc. just like search results. You could even build trees based on relations, similar to the way social networking sites work (poor example [maybe not?], but it's something today's users relate to).

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

I kind a like to organize files in to categories and under categories...
I don't understand way directories are so evil.
And not having directories will break lots of programs.

Last edited by NutsAboutAmiga on 15-Apr-2009 at 12:09 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Not really. A directory just becomes an attribute. So if I want something from Workbench:C/, perhaps I return all data tagged with "C" and "executable" ... or something like that. You could still represent data as a directory tree, it's just that the directory tree itself becomes much more dynamic. e.g.:

list Work:\date > 2009-01-02\

could show all objects that meet that criterion (assuming there's a Work: abstraction). You could do lots of really fun/cool things and still keep the old school folks happy. (Personally, I like directories, too, but there are times when a single abstraction won't work for a particular set of files, and you really wish you could view the set in three or more dimensions. Think pivot tables for file systems.)

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

So, is this "ambitious" project known yet? :)

_________________

@NutsAboutAmiga

>>Also a OS4 for SAM is still not here.
>What have you been smoking? Don’t you read news?

of course i think evrybody know that there a beta OS4 Sam Version out and no Final OS4 Version or a release Candidate Version.

but to be 100% precise .Also a OS4.1 "FINAL" for SAM is still not here for everybody to buy.

>IExec-> and IDOS-> etc are hidden inside macros, so there virtually no difference.

IExec->AllocMem is pure C code.when you look at bars&Pipes plugin interface they do the same calling conventions.but because other OS do not use it, and it need extra letters and need extra macros to make it easy so other OS dont use it.

also other OS have since long time memory protect, but no OS4 library interface, so its sure this is not important to use.

>Gcc my_prog.c –o my.exe –D__USE_INLINE__ -lauto

but when look on available OS4 sources there is this additonal typing in.
and this is what other devs see.the OS need lots of unnecessary typing and think wy i should choose this OS, sure it have now memory protect, but this have Linux or other too.also they see, OS4 is develop long long years slowly, seem not easy portable to other CPU as PPC.

So i think, most think Hyperion have done wrong all can do, and so there are not many that buy or code for OS4 and this result in Software situation and few software.

if they are really able to do a full memory protect AOS that work stable, i cant believe or it is a wonder.

If a change to X86 is too expensive, then a add of memprotect is even more too expensive.Also if OS4 is bad written and cant so easy as AROS or Mac OS x port to another CPU, adding memprotect is much much more work than port a OS to another CPU

They have done near nothing for full memprotect since many years.in the last 3 years not much is add to OS4.

this what OS4 offer as memory protect can on every system easy done.I think OS4 memory protect is windows 3.1 state.on windows 3.1 you get to privileg Violation when access some adress spaces that are forbid.

If OS4 really have good working memprotect, then it must be able to run at least unix programs with full memory protect.but it do not.because Unix apps use less amiga OS functions and Unix have memory protect API so it is far more easy to get 100% Unix memprotect.

also what OS4 miss, parameter checking,(AFA have this on some function add in safer system mode) this is too important for a memprotect OS, is easy to implement and avoid lots of crashes.

Cobra

>The funny thing is that you managed to point out the very thing that allows a >completely new, clean APIs to be added to the system in the future, with the old >APIs still there for compatibility with old software. The interface system is exactly >for that.

the interface have nothing to do with memprptect.

its simple C syntax.somwhere is a table with addresses that put in IExec var.

here are snippets of Bars&Pipes code (bars.h)that do same as OS4 interface.

you need the structure assign to a value and then can call with func->processclip(......

the func.

On 68k you can too create such structures and then can use too IExec->AllocMem.
but there is no reason to do


struct ToolMaster {
......
void (*processclip)(); /* Routine to process an entire clip. */
void (*deletetool)(); /* Routine to delete a tool. */
void (*removetool)(); /* Routine to close down. */
long (*savesize)(); /* Returns size prior to save. */

Last edited by bernd_afa on 15-Apr-2009 at 12:24 PM.
Last edited by bernd_afa on 15-Apr-2009 at 12:12 PM.
Last edited by bernd_afa on 15-Apr-2009 at 12:09 PM.
Last edited by bernd_afa on 15-Apr-2009 at 12:08 PM.