@wawa

A lot of (DOS) functions use negatives as error-codes, so putting any system-structures above 2GB can cause serious butt-hurt.

Giving each task it's own 4(2)GB sounds nice, but will run into troubles once you try to communicate between tasks.

A new (boxed) API might be the better approach.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Giving each task it's own 4(2)GB sounds nice, but will run into troubles once you try to communicate between tasks.

yeah that was my consideration too, just dint remember how to word that.

@pavlor

Quote:

Wow! Sounds too good to be true. milestone in history of AmigaOS

history of hyperion in a nutshell.

_________________
"ICE CREAM, ICE CREAM!" - Speedball 2.

"Look behind you, a three-headed monkey!" - Monkey Island

@Kronos

Precisely why legacy apps will all share the same 2Gb, and only new apps compiled specifically to support it would have their own private 4Gb, although parts of the shared 2Gb could be mapped in.

_________________
Playstation Network ID: xeron6

@xeron

Quote:

Precisely why legacy apps will all share the same 2Gb, and only new apps compiled specifically to support it would have their own private 4Gb, although parts of the shared 2Gb could be mapped in.

so, you confirm, i was actually right, writing above (post #350):
Quote:

of course, introducing separate address spaces would probably look like that, that those spaces would be placed above the 2gb limit available for legacy applications, leaving the lower adress space for those to use.

wow! im an expert, though!

@cheesegrate

Quote:

history of hyperion in a nutshell.

As loyal Amiga.Inc supporter I´m used to hope (and wait...) for miracles.

@Rob

Quote:

So any info on the netbook? Rumour from what you might call a reliable source suggests that it's not going to happen, can you confirm or deny this?

i think, no answer is usually supposed to be an answer, right?

@Kronos

Quote:

A lot of (DOS) functions use negatives as error-codes, so putting any system-structures above 2GB can cause serious butt-hurt.

Sorry I don't see the problem, its just about what type memory you allocate, Fast/chip memory is never going to be above 2GB anyway.

And so what happens if you change it to return 0, it should also be failure, maybe not right error code but who cares.

Quote:

Giving each task it's own 4(2)GB sounds nice, but will run into troubles once you try to communicate between tasks.

So its private memory (or virtualized memory), no big deal, for communication between programs you have sheard memory anyway.

Quote:

A new (boxed) API might be the better approach.

If you think that you most love UAE

Last edited by NutsAboutAmiga on 31-Mar-2013 at 10:35 PM.

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

@NutsAboutAmiga
Returning 0 on error won't help you when an app is written to interpret negatives as error is given a pointer above 2GB *doh*


Basicly, these features can only used by SW written with full knowledge of those new rules. Call a "old" piece of SW (like any library or MUI-class) not updated to those 4.2-APIs and s##t might fly.

So a new API is needed anyways and it might help if you did some research of what "boxed" means in this context before continuing the discussion (hint a emulator is one very special&extreme kind of "boxed").

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Our DOS wizard has no need for "boxes".

_________________

@wawa

Quote:

thats what i mean by "running after departed train". same applies to updating timberwolf to latest firefox source.

Afaik new firefox use less memory and has faster rendering. And better html5 support. All valid points to jump new sources.

@Kronos

Hm, why on earth should a 32 bit signed return code value of dos.library functions be any problem with memory allocated above the 2GB limit? 32 bit signed argument values/structure member values (arguments/structure values, not return codes!) were a problem regarding file sizes, file seek etc., but these problems are history for some time now.

@topic:

Im not convinced that all the improvements mentioned in the blog update will automatically improve the situation we face actually.

Theres still too much "unfinished" stuff within the OS resp. its components ("unfinished" here means, that there are problems with certain hardware components, drivers missing, drivers fail, prefs functions missing/unfinished and many more things not related to any of the improvements mentioned in the blog post).

Theres too much application software missing or even abandoned in favour of broken or severely limited ports from Linux/Unix world. I dont believe that SMP/Gallium3D/breaking the 2GB barrier etc. will help much regarding AmigaOS software. If I want to use Linux/Unix software, I could use a x86/x64 machine instead. Much cheaper and much less hassle.

But I dont want to use these, I want to use AmigaOS.

@whose

Well I agree, but I guess they need to get one thing done before they can do some thing else, personally I love to see some improvement on icon and list sorting, and some kind of import / export def icons prefs feature, where you can make install scripts that add new data types and also updates tool type icons.

The SMP support is welcome, and I hope it will help on video playback, and also help on USB stability on systems whit more then one core.

The 3D support is some thing I hope gets done soon, I bit boring not having 3d, I do miss running some old DEMOS, that is needed, I have my old computer but its not connected to a monitor, besides I like to see what X1000 can do whit 3D graphics.

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

@Kronos

A zero pointer is also illegal as it will overwrite the Execbase address at 0x00000004.

If you do:

If (((int) ptr) < 0 {
         printf(“Error code %d\n”, (int) ptr);
}

Last edited by NutsAboutAmiga on 01-Apr-2013 at 01:21 AM.

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

@NutsAboutAmiga

Quote:

Well I agree, but I guess they need to get one thing done before they can do some thing else,

have you counted?
new firefox port, warp3d for radeonhd, libreoffice, gallium/mesa, kernel (multicore, 64bit, separate address space), new cpus support, what else.. all assigned to same two people, be them genies, can take sometime.

Last edited by wawa on 01-Apr-2013 at 01:22 AM.

@wawa

Well one resource need to be freed, for one resource to do some thing else, there are more then one developer working one some thing, it should not be that hard to understand that number of task they are working on is not the same as the number of task need to get done to free up one resource/developer.

Last edited by NutsAboutAmiga on 01-Apr-2013 at 01:27 AM.
Last edited by NutsAboutAmiga on 01-Apr-2013 at 01:26 AM.

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

@wawa

Actually, running two instances of an OS on different core is multiprocessing, it's just a form of AMP instead of SMP. You can even do mixed AMP and SMP on the same machine, with multiple instances of SMP-aware OSes etc. For a developer, having one OS to write code on and another to test code on can be extremely useful. Normally you would do this with a virtual machine, but AMP is better imho.

See the link in my sig for how I would do this with a cheap quad core e500mc (but I bet you've already read that).

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@NutsAboutAmiga/wawa

Again, a lot of old apps (well actually all old apps that aren't 100% crap) will interpret values returned from DOS as LONG and fail at anything negative. Zeropointers and DOS-limits are a completly different issue.

From here you have 2 options:

1) make RAM above 2GB only available by special 4.2 functions. Sure sounds nice, but will complicate app-development and can end up messy (remember OS-structures are often allocated by the app and can be deeply nested)


2) make sure 4GB ready apps get a different OS-function than old one

2a) allow both to access the same functions (aka no box), lots of housekeeping problems when old and new code is mixed

2b) keep the APIs seperated (aka boxed) functions could still retain their old names, a lot of code has to be doubled, communications between new and old code only by dedicated functions

So, I never claimed that a non-boxed isn't possible, just that it isn't the best way (maybe not even the easiest).

As an extra + "boxing" would also allow to:
- make all pointers/tags 64bit
- hide all system-structures
- create a new messaging system not based on passing random pointers around

-> real MP suddenly became feasable

Last edited by Kronos on 01-Apr-2013 at 08:55 AM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Man you sound like you should be on the team and help to solve the puzzle

_________________
On Planet Boing Trevor is God

@cheesegrate

Quote:

history of hyperion in a nutshell.

While there is no Amiga related company without controversies of some kind,
porting few great games to AmigaOS and making and developing AmigaOS
seems to be one of the best software related profiles in Amiga world of all times.

Quote:

@Hondo Quote: Man you sound like you should be on the team and help to solve the puzzle

No 1st April joke intended - Kronos seems to be knowledgeable person, and it would be great if he was at least beta tester, if not a developer for AmigaOS 4.

Quote:

@whose [quote] Im not convinced that all the improvements mentioned in the blog update will automatically improve the situation we face actually. Theres still too much "unfinished" stuff within the OS resp. its components ("unfinished" here means, that there are problems with certain hardware components, drivers missing, drivers fail, prefs functions missing/unfinished and many more things not related to any of the improvements mentioned in the blog post). Theres too much application software missing or even abandoned in favour of broken or severely limited ports from Linux/Unix world. I dont believe that SMP/Gallium3D/breaking the 2GB barrier etc. will help much regarding AmigaOS software. If I want to use Linux/Unix software, I could use a x86/x64 machine instead. Much cheaper and much less hassle. But I dont want to use these, I want to use AmigaOS.[/quote

This is the big goals, high end list that will bring most joy to X1000 and SAM 460 users.
As it may be big breakthrough to more common standards and expectations, its not to be neglected. And these are exactly things ment to be impossible for AmigaOS.

Hope there will be more small tweaks of mentioned details under the hub - full support of SAM460 and X1000 boards would be expected. As well as better PPC apps support - lets say "MorphOS kind of level of software compatibility".

However, in spite we all love the old apps they become more limited day by day (those that are not in continued development) and even Linuxish ported apps offer stop gap and advanced productivity - try e.g. Gimp vs Art Effect, just as example.

Last edited by vox on 01-Apr-2013 at 01:10 PM.

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja