Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: sicky on November 13, 2003, 10:29:45 AM
-
Just an update for the SEAL http://www.seal-amiga.co.uk showing of OS4 running on AmigaOne.
I have now got my AmigaOne booting directly (with lots of help from NeRP) from it's hard drive. No TFTP required, no PC anywhere in sight.
Come along this Friday (14th Nov from 7pm til 11pm) and see it for yourself.
Coffee/tea and doughnuts will be available (free of charge) for the thirsty and hungry!
See you there
-
Hooray. 3 (or more?) years waiting for Amiga OS and they're up to the stage where it boots.
Stay tuned folks, give them another ten and OS4 will be internet-ready...
-
RedWarrior wrote:
Hooray. 3 (or more?) years waiting for Amiga OS and they're up to the stage where it boots.
Stay tuned folks, give them another ten and OS4 will be internet-ready...
Whatcha on about?
Nobody has been working on OS4 for 3 years.
Only 1 Year.
Rebuiulding an OS aint easy man!
-
I can't believe people are still willing to argue about the same old ####. FFS think of something interesting to say!
@sicky
Hope the demo goes well...
-
@ RedWarrior
"Stay tuned folks, give them another ten and OS4 will be internet-ready..."
I have been on the internet (broadband) from day one with OS4!
What is it with you people? :-(
-
@sicky
... well im excited :-)
-
Everyone knows its a work in progress
Thats why I replied.
His sarcastic remarks could fool someon whos not full in the picture, if ya know what I mean man!
-
For anyone out there who doesn't live far away, the demonstration is tonight. :-)
-
thats cool man..post some good pics.. I wanna see.
Note to all: Keep it clean, or you may not be able to post on here for quite some time. I'm getting tired of the childish CRAP.
-
Good luck to the team behind OS4, we believe in you :-)
-
Come along this Friday (14th Nov from 7pm til 11pm) and see it for yourself.
Man our GROUP would love to be there.... only problem ... our boat is in the drydock...
No really, we would love to be there, or even host an event...
We talked about it last night at our bimonthly meeting...
Looking forward to seeing OS4 LIVE in the US !!!!!!!!!!!!!
-
Hooray. 3 (or more?) years waiting for Amiga OS and they're up to the stage where it boots.
Give you another ten years and you might even get funny.... :-D :-D
-
I have been on the internet (broadband) from day one with OS4!
Hey Sicky,
Keep up the great work.....
Only wished that we could be there.. to see the demo...
Great Job!
-
Hey Sicky,
Like that avatar....
But then are you 5'6" or 5'9" ???
Looks like you might be slouching a bit...
:-)
-
Give you another ten years and you might even get funny....
Or grown up :-)
-
@ TallAmigan
"Like that avatar....
But then are you 5'6" or 5'9" ???
Looks like you might be slouching a bit..."
Actually I'm 1/4" short of 6ft, that image is a 4 layer image (constructed with ArtEffect 4) made from 1: silk screen (background), 2: height chart made up in Draw Studio, 3: Me 4: Prisoner number board (was actually holding an old copy of Amiga Format)! There are several members with the "usual suspects" theme on the SEAL website here http://www.seal-amiga.co.uk/members.html
BTW, how tall is a TallAmigan? :-)
-
sicky wrote:
Coffee/tea and doughnuts will be available (free of charge) for the thirsty and hungry!
See you there
Whoa! Free doughnuts?
(sound of rapid footsteps, a door slamming, car door slamming...)
-
@Hans-Jörg
Hey if you ever release a 68K OS4, I got a stack of A500s I want to bundle it with;-)
-
For anyone out there who doesn't live far away, the demonstration is tonight.
Sigh, just not up to swimming the Atlantic tonight. But thanks for the invite.
Yes, A1 ready and waiting.
-
Hey if you ever release a 68K OS4, I got a stack of A500s I want to bundle it with
Oh yeah, the A500 version... That will be right next on the list after the C-128 version is out ;-)
-
CannonFodder wrote:
Nobody has been working on OS4 for 3 years.
Only 1 Year.
Allmost exactly 2 years (if we only count the Hyperion-effort,
and not AInc's daydreams prior to that).
Rebuiulding an OS aint easy man!
Well anybody who said that in the beginning was cruzified for it.
(just to counter all those "someone has to eat his words"-remarks
that seem to have gotten so popular lately).
-
Why is there always someone wanting to bring people down?
Just think about someone who might think to themself "Ooh, I wonder if the Amiga is still going" - they do a google search, they see this site, read the threads with people at each other's throats, and decide they're better off with their PC if, this is what the Amiga 'community' is all about?
-
@ Cyberus
"they do a google search, they see this site, read the threads with people at each other's throats, and decide they're better off with their PC if, this is what the Amiga 'community' is all about?"
You're right there, people should just grow up, if they do not agree with someone elses opinion then... so what!
There are too many self-righteous people here :-(
-
Supporting Positivity in the Amiga Community (http://homepage.ntlworld.com/christopher.sheffield/positivity.html)
I think if enough good-natured people like ourselves show that we're sick of this, maybe it will end :-)
-
It will be nice when it goes on sale at last. I just hope they get computer stores and dept stores as well to sell them like in the past. Remember the days of walking into Sears ans looking at C128/64 and Amiga 500 systems....
How close are we to a release date?
-
Rogue wrote:
Oh yeah, the A500 version... That will be right next on the list after the C-128 version is out ;-)
What should be noted on this potential 68k release it's not that it would be intended to buy by Amiga classic users, as it is obvious, but for the ones who have Amithlon Amiga Forever or former Amiga users with UAE, there's a market as already proved trough Amithlon & Amiga4ever, so while not being on your priorities list you should think at it at least if you could release such a beast on par with 4.1 for example.
It could bring you more developers, and a native virtual processor that most developers know well...
-
I think at this point it would be better for the emulation solutions to start supporting the PPC, that way moving forwards instead of dragging everything backwards.
-
RedWarrior wrote:
Hooray. 3 (or more?) years waiting for Amiga OS and they're up to the stage where it boots.
Stay tuned folks, give them another ten and OS4 will be internet-ready...
troll....
-
pixie wrote:
What should be noted on this potential 68k release it's not that it would be intended to buy by Amiga classic users, as it is obvious, but for the ones who have Amithlon Amiga Forever or former Amiga users with UAE,
Who would make the license arrangements with Amiga Inc and pay the fees? Abit? Asus? Bernie?
there's a market as already proved trough Amithlon & Amiga4ever, so while not being on your priorities list you should think at it at least if you could release such a beast on par with 4.1 for example.
It could bring you more developers, and a native virtual processor that most developers know well...
Your thoughts are good, it would make sense in many ways, at least for Hyperion. And so would a Mac port, and a Pegasos port. But if Amiga Inc would have been interesting in getting their OS widely spread in these ways, then they would have gone that road long time ago, don't you think?
I believe that they look at the "Amiga One" as one entity, a product consisting of hardware from MAI/Eyetech, an operating system from Hyperion, and trademarks from Amiga Inc.
-
Who would make the license arrangements with Amiga Inc and pay the fees? Abit? Asus? Bernie?
Who ever makes the emulator, if indeed they do need a license. Generally, I would say they wouldn't need one because they would simply emulate existing hardware, but they may need a license to support the AmigaOne BIOS. Not sure that's required, but if it is, then they would need a license for that. Not a big deal though, no different from AmigaForever's included ROM's.
- Mike
-
@Kronos:
Well anybody who said that in the beginning was cruzified for it.
Yeah, the same old story. Everybody said it before, everybody already knew it, everybody was smarter than us.
Everybody was so knowledgable that they knew in the beginning that our concepts do not work that we will never get it to run, never get it to run on the AmigaOne, or that we will have "a big surprise" when we try to run it on the AmigaOne. Yeah, yeah. Been there, done that.
Try another record. This one becomes boring.
What was that sentence that you always like to put under your posts?
"Flame on" :flame:
(BTW, where'nt you involved with the OpenOffice Amiga port?)
-
@Rouge
Don't know about "everybody", but those who did say that it would take
2 years or more were right on spot, and those that were demonized
the most for it, did know the size of such a project instead of just
guessing.
It also seems that you did have a few "suprises" down the road, or how
should one otherwise explain that you promised/hinted a release
for the next few months over the whole 2 years ?
Or to put it another way:
They have been prooven just as much right/wrong with their
predictions as you where with yours.
But the main point is that I find it outright funny (in a nasty way ;-) )
that you and other "reds" seem to feel the need to spice up every
positive OS4-items with that same old drama-tantrum.
Isn't the news worthy enough on it's own ?
People have been complaining about bbrv's PR-skills, but sofar he
been smart enough to stay clean of that line.
Sometimes it even looks like "proving them wrong" is the main
motivation behind OS4, something that is IMO better avoided.
Bout OpenOffice:
The story was a bit like this:
I was in email-contact with Volker, and told him that I may add something
if he manages to get a descent team together. He than saw that as enough
to list me as a team-member in an Amiga-Arena-Interview (to my suprise).
He did set up a maillist, and some people were assigned tasks, while
I promised to do the printing-system once the main-port was atleast
somewhat working. I participated in some discussions about how to do the
GUI-conversion, but it became apperant that the available human resources
were way to small for such a huge task.
Thats when I decided to go back to my own little project (which
is progressing slowly, but nicely btw).
-
that_punk_guy wrote:
I think at this point it would be better for the emulation solutions to start supporting the PPC, that way moving forwards instead of dragging everything backwards.
Hmmm, that's a good idea! I've been reading loads of Emulation technical documents recently. It would be fun to add a PPC ZII (BlizzPPC?) autoconfig device to UAE :-)
Though, right now, I'm actually looking at 68K emualtion for obvious AROS related reasons :-D
-
On the subject of ppc emulation...
I can recall back when I was coding some stuff for powerup kernel, there actually was an interpetive PPC emulator for testing PPC code on 680x0 only systems.
It was dog slow (obviously), but it worked. It was not aimed at speed, obviously!
I cant for the life of me recall what it was called, but it demonstrates that ppc emulation is possible (if not feasable at a reaslistic speed).
PPC emulation is a tall order. For instance, consider the 680x0 emulation. It works by having a function LookUp Table (LUT) with an entry for each opcode. Since the opcode is 16-bits wide, thats 65536 of them!
The interpreter calls functions that emulate the opcode, the JIT calls functions that generate the native code for the instruction emulated instead.
Moving this approach to PPC is very hard. PPC opcodes are 32-bits wide. So a naive LUT for every opcode isnt feasable - it would be 16G in size (assuming each function pointer in the table is 32-bits wide) :-o
Masking the bits required for the opcode and basing a LUT on that is naturally the way to go, but then you have to add checks for all the special instructions that don't conform to the "opcode ra, rb, rc" format. And there are lots of those, too...
In short. Fast PPC emulation - its a tricky bugger ;-)
-
Moving this approach to PPC is very hard. PPC opcodes are 32-bits wide. So a naive LUT for every opcode isnt feasable - it would be 16G in size (assuming each function pointer in the table is 32-bits wide)
Masking the bits required for the opcode and basing a LUT on that is naturally the way to go, but then you have to add checks for all the special instructions that don't conform to the "opcode ra, rb, rc" format. And there are lots of those, too...
So much for "RISC" :-D
But, yes, emulating the PPC would be a nightmare :-)
-
bloodline wrote:
So much for "RISC" :-D
:lol: Yeah - ironic really. You think 'fewer instructions' equates to 'simpler to emulate' but in fact it's not really the case at all here.
Of course, in the hardware, individual groupings of bits in the instruction map out to different sections of the hardware etc. as the opcode is decoded. Such mappings are usually hardwired into the decode circutry and effectively 'instantaneous' (maybe one stage in the pipeline) as far as it goes.
Emulation of this level of operation decode behaviour would obviously be ludicrously complex and slow.
But, yes, emulating the PPC would be a nightmare :-)
If it were no more complex than say 680x0, it would have been done quite some time ago. There's probably more commercial demand for ppc emulation than 680x0 emulation...
-edit-
...and all this is before you get into the really hard part (specifically MMU emulation) :-o
-
bloodline wrote:
Though, right now, I'm actually looking at 68K emualtion for obvious AROS related reasons :-D
:-o :-o
(finally!) :-)
:pint: :-D :-D
-
Karlos: Yeah - ironic really. You think 'fewer instructions' equates to 'simpler to emulate' but in fact it's not really the case at all here.
Isn't true RISC code about 1.5 times bigger than CISC code in executable format?
I'm no electrical engineer, obviously, but are all 32 bits used for instructions, or instructions AND data? How many instructions are there on a PPC?
I don't doubt emulating PPC is tough and slow, but does *any* CPU has 65K+ instructions. :-?
-
-edit-
Sorry, bit of an essay :lol:
-/edit-
Waccoon wrote:
Isn't true RISC code about 1.5 times bigger than CISC code in executable format?
Quite often RISC code is bigger than CISC (there are exceptions however), but its not really much of an issue. RISC architectures tend to have highly orthogonal instruction sets (that is all instructions are the same size).
On the other hand CISC instruction sizes can vary like anything. For example, a simple 680x0 'move' instruction can be from 1 to 12 16-bit words long depending on the addressing modes used.
Data usually makes up large parts of any executable. To be flat honest, code I have compiled for both 680x0 and PPC have resulted in pretty similar sized programs, certianly not 50% larger.
Go figure...
I'm no electrical engineer, obviously, but are all 32 bits used for instructions, or instructions AND data? How many instructions are there on a PPC?
I don't doubt emulating PPC is tough and slow, but does *any* CPU has 65K+ instructions. :-?
Not 65K instructions, no. However it isn't about the actual number of instructions, rather it is about the total number of potential opcodes, which in turn depends on the opcode size.
Consider the 680x0 again. It has less than 50 instructions at the assembler level (think of add, addx, etc).
However, at the binary level, the instruction opcode is 16-bits wide. The pattern of bits in the opocde have particular meanings. You can see this in any 680x0 Programmer Manual.
For instance, consider the basic 680x0 integer add instruction. In assembler we can write it thus:
add. , d
add. d,
Where
is the operand size (.b, .w, .l)
is the effective addressing mode
is the number of the data register (0-7)
Just from the above description we can see that actually there is a lot of implicit information here. This information is encoded into the 16-bit instruction word as follows
Bits 0-2 are the address register in the
Bits 3-5 are the mode
Bits 6-8 are the operation mode (size/sense)
Bits 9-11 is the data register number N
Bits 12-15 are the opcode identifier (here 1101)
So in reality there are literally hundreds of possible 16-bit values that correspond to different variations of the above 'add' instruction. Depending upon the effective address mode used, several extension 16-bit words may follow the instruction word.
As I said, emulation of the 680x0 often simply has a table of all the possible 16-bit values that point to functions to handle each specific opcode case.
All of the nonsense values will point to the same function that emulates an illegal instruction trap.
This approach is used because it simplest, hence quickest (and also constant time taken) to lookup a function in a table and call it.
Any other solution that more intelligently breaks the opcode word down into parts involves more stages, increases the complexity and hence the time taken, which is very bad for any emulation.
Back to PPC...
The same breakdown of opcode words into meaningul fields found on the 680x0 also applies ot PPC opcodes.
The PPC, being a RISC system has only a small number of instructions, but like the 680x0 encodes much other data into its 32-bit instruction word.
For example, a typical 'inst rA, rB, rC' type instruction has to encode 3 registers, each of which needs 5 bits (there are 32 integer registers and 2^5 = 32).
Additionally, RISC architectures such as the PPC tend to define subtle variations of instructions. For example there are integer arithmetic instruction variants that do not update the chip status registers - if you dont need to check them, why update them? This means that when writing (or generating) optimal code cycles can be saved etc. by using instruction variations that eliminate redundant work.
So, although the PPC may only define a handful of instructions (similar to 680x0), the number of possible opcode values is very large indeed.
You simply cannot use the same table 'entry every opcode possible' strategy as for 680x0 emulation becasue 2^32 = 4billion entries in the table :-o !
Now as I hinted earlier, the trick is to isolate the part of the 32-bit opcode that defines the instruction, mask out the register fields etc. and make a tables of those (now much smaller). There would then be several tables, each with only a few dozen entries.
However, this is exactly the sort of thing I said we needed to avoid when talking about 680x0 emulation because it increases complexity. Masking out the bits takes time and also there are many instructions that dont follow the same bit patterns that you have to check for.
You can imagine the overhead in first checking that the instruction isn't one of many special cases, then masking out the instruction identifier bits, shifting them down to get an index number, indexing the table, finally calling the function etc. etc.
Unfortunately, the choice either is this, or a 4G entry table (basically impossible).
In short, its a performance nightmare.