@ddni

Quote:

slightly OT but amigakit now sell 2GB RAM for.... X1000

I take it this is an expansion as the X1000 comes with 2GB as standard.

4GB Amiga anyone?

_________________
Sam

@Hyperionmp


Sorry to disappoint you but..

How many years did it take to get USB2 support again? And is still alpha? Please stick to reality statements. SMP on Amiga is a dream for years..

Additional dissapointment now...

Morphos team looked at SMP when they had potential real world BIG customers and it was thought to be not possible in a real world way. Now, as you know, these developers are some of the best in the amiga world and are very capable of minor miracles. (just as your team has pulled of impressive stuff not to marginalize) point is Hyperion as a company really needs to live in reality and not make wish promises.

Last edited by realize on 03-Sep-2011 at 11:40 PM.
Last edited by realize on 03-Sep-2011 at 11:37 PM.

@ddni

Quote:

slightly OT but amigakit now sell 2GB RAM for.... X1000

BTW --- are those beta tester machines really meant to ship with a single 2GB SIMM?

So far. all photos of running boards have had a single SIMM --- but that would mean only one of the PA6T's two memory controllers are utilised...

@number6

Quote:

Working link for users of IBrowse:

Yeah, I found it hard to beleive that "Microsoft® is not responsible for the content below" which is blank!

Last edited by Hypex on 04-Sep-2011 at 07:35 AM.

@X1000_Booster

Quote:

I wonder though if anyone will be porting OS3.1 or 3.5 to this new Amiga?

I doubt it. The closest to OS3.1 is OS4.0 which was built from the sources. And OS3.5 (as well as OS3.9) is closed source so unable to be ported and not avail to the OS4 team. We're almost past it so it shouldn't be long before OS4 and most likely OS4.2 actually matches and beats the featureset of OS3.9.

Last edited by Hypex on 04-Sep-2011 at 07:36 AM.

@X1000_Booster

Quote:

Thank you for the info. I got nothing against OS4.x though, but I don't think it is the actual AmigaOS. The reason why...I have read it is based on a third party kernel called ExecSG. Who knows what that is but it's probably Linux with an Amiga API wrapper.

That would more accurately describe MorphOS which sits the Amiga system (ABox) on top of a Quark microkernel (QBox).

I am always amused when people accuse OS4 of sitting on top of Linux. I mean, c'mon, if that were the case it would be running on an x86 PC with full 3D, USB3 and flash support!

Why do you think AmigaOS4 runs on Linux? What do you think the Amiga part means? Is it because the AmigaOne machine only ran Linux at the start? This is the only logical argument I can find for accusing OS4 of running on top of Linux. And despite being an old discreditied canard I still see it being raised today.

ExecSG stands for Exec Second Generation. That "third party kernel" is OS3.1 ported to PPC as OS4.0.

@Hyperionmp

Quote:

Obstacles to an efficient implementation were removed (e.g. the use of Forbid) and replaced in many OS components over the years (e.g. DOS).

At this point I'd like to point out that this has not been removed from yellow alerts. Somehow it was missed on the Sam which has only USB input devices but it is crucial this is fixed before the X1000 comes.

I see no reason why a yellow alert, which is really only a warning and not a red alert, must disable multitaskking. For the most part it affects the one task that was running so why not just suspend that task instead? And being that the input.device can no longer rely on reading mouse events from an interrupt driver (but instead a USB task) this leaves the system with dead input for ten seconds at a time. That is not a friendly system!

Apart from that alerts still need to push the screen down again. Since screen dragging has been reimplemented for years now there is no excuse! Overwriting the screen when it should be pushed down just looks daft.

And while we still have yellow alerts these issues will remain.

Last edited by Hypex on 04-Sep-2011 at 08:15 AM.

@umisef

Quote:

I guess one part of that clear picture is deprecating the 68k support?

I don't see the point of that. You might as well run AROS. Though 68k compatibility has caused ExecSG to retain more than a fare share of legacy.

Quote:

While OS4's support for 68k code already has an inherent race condition (68k read-modify-write instructions were atomic on all 68k Amigas, but are not in OS4's task-based emulation)

For non-JIT this shouldn't matter as the emulator would just be reading codes and performing actions based on interpreting those codes,

But for JIT, where I know you have experence in regarding PPC, is where this would matter. However, as long as the modification is detected and the JIT cache reloaded cleanly, this shouldn't be a problem.

@Hypex

Quote:

For non-JIT this shouldn't matter as the emulator would just be reading codes and performing actions based on interpreting those codes,

It doesn't matter whether things are JITed or not.

Take the old classic "ADDQ.B #1,TDNestCnt(A6)", which was compiled inline into plenty of 68k code, because that's one of many such macros in include_i/exec/ables.i[1].

That instruction reads a byte from a particular offset from A6, adds one to it, and writes it back. On a real 68k, all of this happens in a single instruction. And a real 68k only services interrupts between instructions --- so any given interrupt happens either before that read-modify-write, or after.
UAE-style full system emulation faithfully reproduces this behaviour --- "interrupts" are only checked between emulated instructions. Amithlon-style emulation (which deals with actual interrupts, rather than simulated ones) does, too --- the actual interrupt just sets a flag in the emulator, and the emulation loop checks that flag between instructions[2]. And because the OS's task switching happens to be done in the emulated interrupt, this means that one task's ADDQ is atomic with respect to another task's ADDQ.

Task-based emulation is different. You have an emulator running as a bog-standard task under the PPC scheduler. So this emulator, whether it be JITed or not, will take that ADDQ and translate it into (at least) three PPC instructions --- one to read the byte from memory, one to increment the byte, and one to write it back to memory. And if you are unlucky, a timer interrupt might happen after the read, but before the write, and you get a task switch.
And if you are even more unlucky, some other task will modify that byte. Say the other task also increments it. If we started at 0, then task 1 read "0", then was interrupted. Then task 2 incremented the value to 1, and did its thing. Eventually, task 1 becomes active again, adds 1 to the "0" it read before, and writes the result (i.e. "1") back to memory. UH-OH! We started with 0, incremented twice, and what have we got? Not two, but one!

That could never happen on a real 68k, or with UAE style emulation --- there is no risk of any other task changing the in-memory value between the read and the write part of a read-modify-write instruction. With OS4's task-based emulation, it can happen, but is improbable[3] --- it needs an interrupt at just the right moment, hence the term "race condition".


[1]: Aren't exposed OS structures fun? I'd love to hear how anyone hopes to get SMP going while supporting code like that!
[2]: In fact, most of the time it will execute a fair number of instructions before checking the flag...
[3]: Actually, in this specific piece of code, it can be shown that the result will always be correct, because there will never be a task switch if the initially read value is different from 0, nor will the in-memory value ever be different from 0 on task-reactivation in the case of a mid-instruction task switch. But that's beside the point...

Last edited by umisef on 04-Sep-2011 at 10:14 AM.

@Hyperionmp

Words are cheap and promises were often enough broken.
Yeah , sure this time it's all on schedule and rocking...

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@umisef

Quote:

Task-based emulation is different. You have an emulator running as a bog-standard task under the PPC scheduler. So this emulator, whether it be JITed or not, will take that ADDQ and translate it into (at least) three PPC instructions --- one to read the byte from memory, one to increment the byte, and one to write it back to memory. And if you are unlucky, a timer interrupt might happen after the read, but before the write, and you get a task switch. And if you are even more unlucky, some other task will modify that byte. Say the other task also increments it. If we started at 0, then task 1 read "0", then was interrupted. Then task 2 incremented the value to 1, and did its thing. Eventually, task 1 becomes active again, adds 1 to the "0" it read before, and writes the result (i.e. "1") back to memory. UH-OH! We started with 0, incremented twice, and what have we got? Not two, but one!

That’s way you have forbid() and permit(), and mutex's, to prevent two separate tasks from doing bad things.

You create a Mutex you obtain it, and release it when your done, this prevents many programs to do the same thing at the same time.

Forbid() and Permit() does the same but on a global scale,

you don't need to think about registers as they are saved when task switches happens, so does not matter if read, stored in r1, incremented and written back.

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

@Hypex

Quote:

I doubt it. The closest to OS3.1 is OS4.0 which was built from the sources. And OS3.5 (as well as OS3.9) is closed source so unable to be ported and not avail to the OS4 team.

OS 3.5 and 3.9 mainly consisted of 3.1 with third party components. Most if not all developers who signed contracts with Hagge & Partner also signed contracts with Hyperion. This is why thing like Reaction, Amidock and the Workbench prefs are present in OS4.

Quote:

We're almost past it so it shouldn't be long before OS4 and most likely OS4.2 actually matches and beats the featureset of OS3.9.

I think the 3.9 feature set was exceeded quite some time ago in the 4.0 days.

@umisef

Quote:

Take the old classic "ADDQ.B #1,TDNestCnt(A6)"

Non atomic modification of SysBase->TDNestCnt should not be a problem because TDNestCnt is saved/restored during context switches. If a task gets interrupted and something else runs (interrupt or other task) and then later the task continues to run again SysBase->TDNestCnt will be back to the same valuje as it was before the interruption.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @X1000_Booster Quote: I wonder though if anyone will be porting OS 3.1 or 3.5 to this new Amiga? This will run AmigaOS 4.2 when its ready, AmigaOS 1.0 to 3.9 will require EUAE. AmigaOS 4.X is for PowerPC/Power CPU architecture AmigaOS 3.X for MX68000 CPU's architecture needs emulator. AmigaOS 4.X has a integrated emulator for MC680x0 CPU's so system friendly software runs. Many old games and demos are not rally system friendly, so you need EUAE. If you are just interested in old games just buy MiniMig. If you are mostly interested in OS and applications then X1000 is your choice. If you are hardware geek and like all games and programs to run, don't mind low clcok speed then NatAMI is your choice. If you think X1000 is too expensive buy a new Sam460 or used Sam460/Sam440/AmigaOne-XE computers see Classified ads

You should not forget to mention AROS, which runs on any pc and gets better and better as well as MorphOS which provides a pretty high compability to AOS3.x and comes with many of the usual 3.x days extensions as system parts (MUI, CGX, AHI).

Brief overview over MorphOS: http://via.i-networx.de/wim.htm

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@umisef
Quote:

BTW --- are those beta tester machines really meant to ship with a single 2GB SIMM?

Yes. Unless people want more for a linux based set up at the beginning.

Quote:

So far. all photos of running boards have had a single SIMM --- but that would mean only one of the PA6T's two memory controllers are utilised...

Would it? Are you talking about the serial nature of the chip controllers or the data
crossbar. I would appreciate any enlightenment you could provide on this point .

I am also wondering about the the non SMP nature of OS4 at the present and why that
would matter [use of the second controller] when only a single cpu is being utilized.

@NutsAboutAmiga

Quote:

That’s way you have forbid() and permit(), and mutex's, to prevent two separate tasks from doing bad things.

But the thing is --- on real 68k processors, read-modify-write wasn't a "bad thing". It was guaranteed to be atomic. Which means you could implement all sorts of nifty lockless data structures, which were guaranteed to work right.

A 68k emulator should emulate a 68k. That includes making the same guarantees. The only way to do that with a task-based 68k->PPC emulator is to call Forbid()/Permit() (or Disable()/Enable()) for every single emulated 68k instruction that executes more than one memory access.

It's possible, but it would make a TI99/4A look fast....

@Georg

Quote:

Non atomic modification of SysBase->TDNestCnt should not be a problem because TDNestCnt is saved/restored during context switches

Or rather, it is guaranteed to be 0 during context switches, because if it isn't, context switches are Forbid()den... That's what footnote[3] was about.

But that's just a very special case. For example, incrementing/decrementing library reference counts is almost certainly done the same way, and can go horribly wrong if there is a task switch at the wrong moment.

@kindergip

Quote:

I am also wondering about the the non SMP nature of OS4 at the present and why that would matter [use of the second controller] when only a single cpu is being utilized.

Memory controllers and CPU cores are completely independent.

Using only one out of the two memory controllers means that the peak available main memory bandwidth is halved.

@umisef

My God you sure sounds like someone who knows this game. I surely would hope someone like you took over the openoffice port or something.

Seems like such a let down this port ? - did the guy quit it or what

please umisef, even though I'm not at liberty to say anything about your "problems" with hyperion and therefore surely cant condemn it, I really must say I wish you were "on our side"

_________________
On Planet Boing Trevor is God

@Hondo

Nevermind.
Wait!
No nevermind.

Last edited by Mechanic on 04-Sep-2011 at 07:22 PM.
Last edited by Mechanic on 04-Sep-2011 at 07:22 PM.
Last edited by Mechanic on 04-Sep-2011 at 06:58 PM.