03-Dec-2022 11:29 GMT.
UNDER CONSTRUCTION
Anonymous, there are 228 items in your selection (but only 28 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 228]
[News] OS4 progress since pre-releaseANN.lu
Posted on 08-Jun-2004 21:47 GMT by Peter Gordon228 comments
View flat
View list
Hans-Jorg Frieden has posted a detailed status update on the progress of OS4 to Amigaworld.net. Brief summary:

· Picasso96 and MUI PPC native
· Kernel supports PPC performance monitor and Altivec
· Moovid (released with OS3.9 as "action") is now running native, and can play DivX and other common formats
· GCC 3.4.0 is ported
· The C libraries are much faster. As a result AmiPDF is up to 60 times faster.
· Serial and floppy drivers coming soon
· USB is working and supports HID devices like keyboards and mice as well as HID joysticks and steering wheels, and USB mass storage devices like USB sticks, flash card readers, 7-in-1 card readers and cameras
· A1 IDE device now has working UDMA support. Also, interrupts are no longer polled but delivered properly. This means that the device does not require any CPU time for transfers.

This material will in due course be released for download to registered users of the Developer Pre-release on our web site at: http://www.hyperion-entertainment.biz

There is more detail in the original AW.net posting.
OS4 progress since pre-release : Comment 201 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 13:50 GMT
Personly I don't understand the root to this debate, it it the one costumer leaving MorphOS due to bing treated badly the MorphOS developers?

if not then I don't understand the debate, the old API needed a face lift it was so old that one can compare it whit wooden wheels, and slow, while now API is just a indirect jsr, the old one contained a jmp and a jsr, taking well known patch called system patch as an example you can look at the improvements just by starting it, and how the api and system functions are responsible for large part of the performance of the OS, one most consider new ways to doing things,

The so called portability issue is a none issue as I'm concerned, just make fake table and it all works perfectly

just type

// BEGIN SETUP some fake lib funcs
void run_me()
{
printf("old lib func1\n");
}

void test_a()
{
printf("old lib func2\n");
}

void test_b()
{
printf("old lib func3\n");
}
// END

// BEGIN put this inn a header file
typedef struct
{
void (*run_me) ();
void (*test_a) ();
void (*test_b) ();
} test_api;

test_api *foo;

void setup_api()
{
if (foo = (void *) malloc(sizeof(test_api)))
{
// Assign old api's to new api
foo -> run_me = &run_me;
foo -> test_a = &test_a;
foo -> test_b = &test_b;
}
}
// END

int main()
{
// Setup ABI for MOS
setup_api();

// test new api, use new writing style on MOS
foo -> run_me();
foo -> test_a();
foo -> test_b();

// free ABI
free(foo);
}
OS4 progress since pre-release : Comment 202 of 228ANN.lu
Posted by itix on 10-Jun-2004 14:06 GMT
In reply to Comment 201 (Kjetil):
Sorry but I lost you... But look, this is how library vectors work in MorphOS: 68k library: JMP $12345678 PPC library callable from 68k code: TRAP $12345678 PPC library using SysV ABI: ILLEGAL $12345678 There is only one table, every entry is 6 bytes long, 68k code can patch PPC vectors and vice versa (thus SnoopDOS still works) and you can continue using RTF_AUTOINIT.
OS4 progress since pre-release : Comment 203 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 14:10 GMT
In reply to Comment 202 (itix):
68k lib

JSR (EXECBASE)-120
..
JMP $123456678
..
RTS
OS4 progress since pre-release : Comment 204 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 14:20 GMT
In reply to Comment 202 (itix):
SnoopDOS works on AmigaOS40, it do not make any diff
OS4 progress since pre-release : Comment 205 of 228ANN.lu
Posted by Fabio Alemagna on 10-Jun-2004 14:24 GMT
In reply to Comment 203 (Kjetil):
You don't get it... the 68k prrogram will jump to the function vector as usual, and the emulator will act accordingly depending on the opcode found there, whilst the PPC programs will simply take the function's address and jump to it directly.
OS4 progress since pre-release : Comment 206 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 14:38 GMT
In reply to Comment 205 (Fabio Alemagna):
68k is legacy
OS4 progress since pre-release : Comment 207 of 228ANN.lu
Posted by Fabio Alemagna on 10-Jun-2004 14:46 GMT
In reply to Comment 206 (Kjetil):
> 68k is legacy

Give me a break. And, besides, what's that got to do with anything?
OS4 progress since pre-release : Comment 208 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 14:47 GMT
In reply to Comment 207 (Fabio Alemagna):
Way care to understand some thing thats old and outdated?
OS4 progress since pre-release : Comment 209 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 14:54 GMT
In reply to Comment 207 (Fabio Alemagna):
My understanding for the AROS api is that it supports this new writing style, way do you care,

I can understand the point about how large an PPC Int should be, how ever this is an other issue,
OS4 progress since pre-release : Comment 210 of 228ANN.lu
Posted by Fabio Alemagna on 10-Jun-2004 15:31 GMT
In reply to Comment 208 (Kjetil):
> Way care to understand some thing thats old and outdated?"

:-o I've not asked you to learn 68k asm, I and itix have simply explained to you how calling a library function works on MOS.
OS4 progress since pre-release : Comment 211 of 228ANN.lu
Posted by Fabio Alemagna on 10-Jun-2004 15:33 GMT
In reply to Comment 209 (Kjetil):
> My understanding for the AROS api is that it supports this new writing style,
> way do you care,

Which new style are you talking about?

> I can understand the point about how large an PPC Int should be, how ever this
> is an other issue,

/me feels stoned
OS4 progress since pre-release : Comment 212 of 228ANN.lu
Posted by itix on 10-Jun-2004 15:42 GMT
In reply to Comment 206 (Kjetil):
There is no need to carry 68k compatibility forever. Drop 68k emulation and ignore op code in front of jump address.
OS4 progress since pre-release : Comment 213 of 228ANN.lu
Posted by Don Cox on 10-Jun-2004 15:43 GMT
In reply to Comment 211 (Fabio Alemagna):
"/me feels stoned"

Perhaps if you and Kjetil were both stoned, you would understand each other.

;-)
OS4 progress since pre-release : Comment 214 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 15:59 GMT
In reply to Comment 213 (Don Cox):
:o) LOL......
OS4 progress since pre-release : Comment 215 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 16:02 GMT
In reply to Comment 211 (Fabio Alemagna):
IEXEC -> OpenLibrary() etc....
OS4 progress since pre-release : Comment 216 of 228ANN.lu
Posted by Anonymous on 10-Jun-2004 16:34 GMT
brainswirl.activate(LEVEL_KJETIL)
OS4 progress since pre-release : Comment 217 of 228ANN.lu
Posted by Anonymous on 10-Jun-2004 16:36 GMT
In reply to Comment 216 (Anonymous):
Wohaaa.. I can taste the sound of my keyboard.
OS4 progress since pre-release : Comment 218 of 228ANN.lu
Posted by Kjetil on 10-Jun-2004 16:40 GMT
In reply to Comment 212 (itix):
There is no need to carry 68k compatibility forever. Drop 68k emulation and ignore op code in front of jump address.

Yes ELF replaces hunks, table based API replaces old JMP based API, 68k will never be system friendly, the only safe place to store 68k is inn UAE or port it, so it becomes system friendly and take care to fallow the new rolls,

While we wait for all programs to be safe, I can think of any other Amiga system then AmigaOS40, that will keep my files safe from cache overwrites, or programs that jump out inn to unknown memory to execute illegal instructions, or will keep track of my program stack for me, or will track system resores, so when program crashes I can free that memory.
OS4 progress since pre-release : Comment 219 of 228ANN.lu
Posted by itix on 10-Jun-2004 22:06 GMT
In reply to Comment 202 (itix):
> PPC library callable from 68k code:> TRAP $12345678 PPC entries have more magic than this (it rather points into emulation trap than contains trap directly in the function table), but practically it is same.
OS4 progress since pre-release : Comment 220 of 228ANN.lu
Posted by Ketzer on 11-Jun-2004 05:35 GMT
The inherent profiling capabilities are just too cool.
OS4 progress since pre-release : Comment 221 of 228ANN.lu
Posted by Kjetil on 11-Jun-2004 08:12 GMT
In reply to Comment 220 (Ketzer):
What he do not explain to you how it deals whit RTS, and how RTS works inn his library function, how will the library deal whit ruturning to ppc and 68k code, RTS will not know what code it should return to. :o)
OS4 progress since pre-release : Comment 222 of 228ANN.lu
Posted by Fabio Alemagna on 11-Jun-2004 09:47 GMT
In reply to Comment 221 (Kjetil):
I don't think there's anything misterious about RTS: the emulator is PPC code, it's the emulator that jumps to the PPC function, the PPC function returns to the emulator, and the emulator returns to the 68k program.
OS4 progress since pre-release : Comment 223 of 228ANN.lu
Posted by itix on 11-Jun-2004 12:56 GMT
In reply to Comment 221 (Kjetil):
You should download MOS SDK and find out how ppcinlines work. Everything works like it was in AmigaOS, even D0 and other registers are there. Register mappings described in NK 3.9 are still valid ;^)
OS4 progress since pre-release : Comment 224 of 228ANN.lu
Posted by Ketzer on 12-Jun-2004 05:46 GMT
In reply to Comment 221 (Kjetil):
And I didnt ask for that explanation either. Anyway, a profiler isnt exactly useful for 68k code on A1 anyway, is it?
OS4 progress since pre-release : Comment 225 of 228ANN.lu
Posted by Crumb // AAT on 12-Jun-2004 08:20 GMT
In reply to Comment 199 (itix):
I mean that there's an API to do that kind of memory management.
OS4 progress since pre-release : Comment 226 of 228ANN.lu
Posted by Crumb // AAT on 12-Jun-2004 08:31 GMT
In reply to Comment 200 (itix):
"What is the best in OS4 and MOS is that they throw away those kludges. You can assume everyone have one USB solution, one PCI solution, you have AHI and so on."

I agree 100% :-)

And we don't have to forget that we have moved from the classic hardware and these new OSes are multiplatform (even if at the moment both companies only release their OSes for their own hardware solutions now they can port it much more easily)
OS4 progress since pre-release : Comment 227 of 228ANN.lu
Posted by Dan on 12-Jun-2004 09:47 GMT
AmigaOS4 is a positive step, being a pegasos/morphos user I would still like to see AmigaOS4 for Pegasos and possible x86 platform to ensure the survival of the Operating System. I can't see nor is there justification for AmigaOS4 for AmigaOne when only a handful of these boards will be sold due to the excessive price. I think Hyperion has to turn there focus on Business mode and ensure sales of AmigaOS4 being porting it to Pegasos and/or x86 platform.
OS4 progress since pre-release : Comment 228 of 228ANN.lu
Posted by itix on 12-Jun-2004 09:51 GMT
In reply to Comment 225 (Crumb // AAT):
> I mean that there's an API to do that kind of memory management. Now, are you sure? I recall someone asked this possibility in AWN and Hyperion answered with question is it really necessary. (It was about some emulator.)
Anonymous, there are 228 items in your selection (but only 28 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 228]
Back to Top